arclamp.jp アークランプ

あけましておめでとうございます。新年ということで、大上段に構えて、エントリを書いてみました。なんともえらそうなタイトルなのですが、あまり気にせず。気になる方は、つっこみをば。

手法が固まりつつあった2004年
2004年は、ヒューマンな面からも、ソフトウェアの面からも、開発手法の確立期にあったといってよいと思う。

まず、ヒューマンな面で言えばアジャイル開発の導入が進んだこと。一昨年のXPの実践と失敗があったおかげで、昨年は、一定の理解のもとにアジャイルの導入が進んだ。XP、FDD、スクラム、RUPなどが利用できるシチュエーションとともに紹介されたと思う。

次に、ソフトウェアの側面で言えば、アジャイルに呼応するように、フロントエンドからバックエンド、そして開発環境、テストまで一通りの基礎手法が確立されたと考えている。

- UI層：？？？
- UIフロー層：StrtusのようなXML定義によるUIフロー制御
- ロジック層：Spring、SeasarのようなXML定義によるDIコンテナ
- パーシステンス層：Hibernate、iBatisのようなXML定義によるO/Rマッピング
- 開発環境：Eclipseのプラグインでそれぞれを連携
- テスト：JUnit、CactusのようなUnitTestと、FindBugs、PMDのような静的コード分析

これらは、すべてアジャイルに適している。フレームワークやEclipseのプラグインによって、スキルセットが比較的低いエンジニアであっても、設計書通りに開発を行うことが可能だ。

ただし、UI層については、大いに課題を残したことを忘れてはいけない。JSFやFlashの台頭があるもの、どちらも決定打とはならないだろう。2006年、あるいは2007年を待つ必要性があるかもしれない。
また、実際にどのプロダクトを使用するのかというのもデファクトスタンダードがあるわけではない。Strutsにしても、FlexをUIにしたい場合には使いないわけだから、Strutsに完全に依存するのは誤りなのである。O/Rマッピングについても、各ツールごとにクセがある。このクセを理解せずに使用すると、効果は薄れ、逆にデスマーチが聞こえてくることになる。依存性の回避というのは2005年でも継続すべきポイントだ。

2005年の課題はビジネスへのフォーカス
そして、2005年の課題は、"ビジネスへのフォーカス"だと考えている。

まず、エンジニアリング側でのフレームワーク技術が固まってきたということは、既存のエンジニアリング部分での差別化がもはや図れなくなることを示す。
これまでであれば、EJBが使える＝大規模開発可能ということが差別化ポイントになりえたわけだが、EJB3.0でO/Rマッピングツールの考え方を導入することから分かるように、市場の90%の案件では分散環境は必要なく、EJBを採用するメリットがないことが分かってきている。そして、前段に上げたフレームワークは、すべてオープンソースで揃えることが可能だ。

ところで、究極的にエンジニアリングを突き詰める手法としては、すでにXPが完成形に近いといえる。クライアントとバーバルのコミュニケーションをとり、クライアント自身がリスクテイクすることで開発を進める。XPの前提である変化ヲ抱擁セヨとは、クライアントの要望どおりにシステムができることを示しているが、逆に言えば、クライアント側に明確な要望がないといくらでも迷走できることを示してる。
しかし、実際の企業案件でXPを採用することは難しい。特に、スキルセットをもったメンバーを揃えることが不可能なはずだ。（ここら辺の失敗事例はあまり聞かないが、そもそもXPをはじめることすらできないのが現状だろう。）

まとめると、

- フレームワーク技術によってエンジニアリング自体に差別化ができなくなってきている
- 一方で、エンジニアリングを最優先した開発手法には限界がある

というのが現状である。

理想の手法とは
この解決に必要なのは、一般的な企業案件でも採用できる開発手法の確立と、それにあわせたフレームワーク技術のさらなる発展である。

僕自身が考える方向性は、ビジネスフローのモデル化だ。
そもそも、ビジネスの変化に対応するためには、ビジネスプロセスをそのままモデル化したシステムを作ればよいと唱えられてきたことだ。しかし、うまくいかない場合がある。それは、モデル化の対象がエンティティ、つまりオブジェクトに集中している点だ。オブジェクト指向は、データと振る舞いを一緒にすることでカプセル化を行っている。しかし、実際のビジネスプロセスにおいては、振る舞いとはアクターが行うものである。これは、ユースケースでのシナリオの書き方を見ても一目瞭然である。
つまり、どこかの時点で、プロセスをエンティティによって表現しなおしているはずだ。しかし、人間の思考範囲の限界から言っても、各担当者の意見を集約し、企業内のすべてのビジネスプロセスから、矛盾なくエンティティを抽出されることはないと言ってよい。同じ単語なのに違うものであったり、違う単語なのに同じもであったりするわけだ。

では、エンティティのモデル化を極力しなければ良いというのが僕の考えだ。アクターと、そのフローをモデル化し、エンティティは、１つのフローの入力・出力としてだけ存在する。ま、ここから先の具体的な仕組みについては、僕なりに実験を行いながら、少しずつ完成させていきたいと思う。

最後に
2005年のエンタープライズソフトウェア開発業界に対して、僕のテーマは2つだ。
1つ目は、現実的に「ツールの選択と、依存性の回避」。
2つ目は、理想的に「ビジネスフロー・プロセスのモデル化」
これらを、ブログや雑誌を通じて紹介できればと思う。とりあえず、春ごろまでに1つ目のテーマに沿った記事を書く予定だ。2つ目についても、早い段階でなにか発表できればと考えている。

2005年もソフトウェア開発は、確実に進歩する。