Whatを効率的に構築するためのHow（技法・作法）を考える－その１

さて、だいぶ寄り道をしましたが、今回からはHowの話になります。これまでは、Whatを主体に議論してきましたが、そのWhatをどのようにして作っていったらいいのかいうことです。このHowはWhatによって大きく違ってきますので、初めにきちんとWhatを決めておいたわけです。

Howから入っていくと、似て非なるものや同じものを繰り返して作ったりすることになります。あるいは、人によって作り方も変わることにもなります。従来型のシステム開発は逆にこうしたやり方をベースにビジネスモデルができていたのです。すなわち、人を抱え、その人たちに仕事を与え、その工数で売り上げるというモデルですから、再利用性を高めたり、標準化して開発生産性を上げるインセンティブは乏しいわけです。

話をもとに戻しましょう。これまでのWhatの議論で導かれたものは、パターン化できるものはパターン化して、できないものは、その部分を謂わばブラックボックス化するという考え方です。マクロフロー部分（アクティビティの流れ、LAPでいうHappy Path）は定型的なのである程度パターンとしてもつことになります。

一方、ミクロフロー（アクティビティの中身、Ontologicalなふるまい）では、人間系の要素が入り込むので定型化できないので、情報共有の場というあいまいさを許容したものにし、そのインターフェースをきちんと定義して取り合うことにしています。

ということで、アクティビティの粒度とプロパティを定義しておけば、業務システムは、そのアクティビティの置き方（構成や順序）とその機能とUIを作っていけばいいことになります。

もちろんこれだけの簡単なことではありません。アクティビティの機能といっても様々ですから、それをどうやって作っていくかも問題になります。ただし、このときでも要件に対していちいちコードを書くのではなく、コンポーネントという考え方をとることが重要です。

アクティビティもコンポーネントの一種で、ビジネス機能コンポーネントと呼べるものになります。それ以外にも、システム機能コンポーネントがあります。例えば、バリデーション、検索、印刷、アカウント管理、メール送信とかいったものがそれです。

そう言うとおわかりだと思いますが、こうしたコンポーネントは一度作ったら使い回しができそうだ、あるいはどこからか持ってくればいいといったことが思いつくことでしょう。ですから、究極的にはレゴ細工のように組み立てていけばいいのです。

結局、以前に提示した4つの道具を使ってどういう業務システムを作るのかというのとその道具をどうやって作るかになります。

さて、前置きが長くなりましたが、次回からそのあたりの具体的なHowのことを議論していきます。