知り合いの会社と新しく提携することになったのだが、その際に、僕が開発したJavaのアプリケーションフレームワークを説明することになった。まだ途中なのだが、ぶっ続けで説明をしても、12時間では終わらないと思う。それは、内容が非常に多岐に渡っているからだ。

システムに求められること
僕は、システムに「柔軟性」という前提を求めている。これには、いくつかの意味がある。
まず、バグへの対応。人間が作るものである以上、バグは存在する。大切なのは、そのバグに速やかに気づき、原因が分かることだ。バグは、原因がわかってしまえば、どうにかなるものだ。これは、簡単そうで、意外に多くのアプリケーションに問題がある。エラーに気づくためには、あるいは原因が分かるためには、どういった監視が行われていれば良いのかというのは、実際には、細かいノウハウが必要になる。

エンタープライズ·ソリューションの定義は何ですか

次に、仕様変更への対応。仕様は常に変わるものだ。そのためオブジェト志向を用いして、ビジネスの動きをトレースし、それを、なるべくそのままシステム化する必要性がある。そのためには、設計手法やコード構築に一定のルールが必要だ。

さらに、メンバー変更への対応。もちろん、ビジネス的な仕様を理解している人間がいなくなるのは厳しいが、開発メンバーが変わってしまうことで、仕様変更やバグに対応できなくなるのは問題だ。フレームワークによって、「どういう内容のことは、どこに書かれている」というのが明確になっていれば、バグのトレースは、それほど難しいことではない。

そして、技術変更への対応。特にJavaは、技術変更の要求が強い。実際、弊社では、HTMLを用いた開発がほとんどなくなり、Flashに移行してしまっている。しかし、プレゼンテーション層以外の部分については、まったく変更がない。また、IDEについても、EclipseとNetBeansのような競争によって状況は変化するだろう。

ネオンの色を与えるもの

どういうフレームワークが必要になるのか
上記の柔軟性を実現するためには、非常に広範囲にわたるフレームワークが必要になる。まずは、設計ではUMLによる設計、設計からのコードの自動生成。プログラミングでは、ビジネスロジックとプレゼンテーションの分化、それらのレイヤーをつなぐコードの書き方、プレゼンテーション層の書き方。テストでは、単体テストの実施、個人端末でのブラウザからDBまでのテスト。環境面では、開発ツール、ソースコード管理。細かくは、ログの出力ルールに、例外処理ルールなどなど。
このフレームワークにとって、Enterprise Architect(UMLツール)も、CVSも、Eclipseも、Strutsも、JUnitも、Flashも、なにもかも交換可能なパーツに過ぎない。ま、モノによっては、変更の負荷が大きいものもあるが、それに余りある効果があるなら喜んでフレームワークに組み込みたい。

トップのインターネットのマーケティングサイト

ライフサイクル
結局、システムに限らずモノにはライフサイクルがある。デザインされて、作られて、使われて、フィードバックをして、使われて...そして、他のものに引き継いで終わる。この流れを意識していないとモノ作りはできない。いいものが出来たけど、メンテナンスが難しい、できない、変更しにくい。これでは、意味がない。また、環境の変化も重要だ。メンバーの交代、ツールの変更、あるいは場所の変更。こういった広い視野でモノ作りをみれないと、良いモノは創れない。

逆に言えば、ツール各社は、こういった点について、もっと包括的な協力とアイデアを出すべきだろう。最近は、システムに限らず、オフィスツールからデザインツールまで「スイート（Suite）」が流行っている。しかし、その製品群だけで、こういったライフサイクルを完全にカバーできないことは多い。また、製品間の連携方法が各社依存であったりもする。囲い込みをせずに、もっとオープンな視点で協力と競争をしてもらいたいものだ。

もちろん、ユーザー側にも問題はある。巷では、製品ばかりにスポットが当てられていて、そこに振り回されてしまうことが多い。そうではなくて、モノ作りライフサイクルを意識した明確な考え方があれば、「このツールは、どこにどう使えるな」という判断が出来る。発想をツールからはじめるのではなくて、ライフサイクルから考えなくてはいけないのだ。そこから合理的な費用対効果も導けるし、導入効果も図りやすい。

で、悩みが。僕自身はライフサイクルがある程度は意識出てきているのが、それを人に説明するとなると、長大な時間がかかるのが問題。ドキュメンテーションを真面目にしていないのが問題なのだが。ま、その会社の人が、ドキュメント（英語）を作ってくれるらしいので、それに期待かぁ？