だいぶ前に書いたのを発掘したので、メモとして残しておきます。
アーキテクチャの定義にはいろいろあるが、だいたいにおいて「できあがった姿」を云々するものである、という点においては共通していると思う。
いっぽう、開発プロセスという言葉だっていろんな解釈があるけれども、「作っているときのはなし」であることには異論がないと思う。
とすると、アーキテクチャと開発プロセスは別個のものなんだろうか。互いに独立しているものになるのだろうか？
そんなことはない。アーキテクチャへの要求の一部として、「開発中の生産性」「品質を確保する仕組み」「要員に求められるスキル」などが求められる。完成したアーキテクチャは「この部分はこんな体制でこういう手順で作るといいと思うよ(そうすれば要求が満たせるよ)」という内容を含んでいるはずだ。
「いいと思う」だけで、実際にそうした体制や手順を導入するための努力をしないのは無責任である。アーキテクチャを作るのはアーキテクトの責務だが、そのアーキテクチャを活かすために、開発プロセスまで手を出すべきなのもアーキテクトだ。
開発プロセスとアーキテクチャはそれでは、どのくらい絡み合ってしまうのだろうか。せっかくなので分離しているほうが、いろいろと都合はよい気がする。
完成したシステムのソースコードの一般的な構造は、アーキテクチャが規定する。ソースにいたるまでの作業でどんなことを考慮しなにを決定しなくてはならないのか、規定するのはもアーキテクチャである。それぞれの考慮や決定の順序や担当分けは開発プロセスの範疇になる。ソースを作る過程と中間成果物を決めるのが、開発プロセスである。
例) 10人前の握りずし(上・2人前はサビ抜き)を作る
- アーキテクチャ：
- シャリの上にネタを載せる。
- 1ネタ2貫ずつ。
- 1人前ずつ桶に入れる。
- プロセス：
- 以下を各ネタに対して繰り返す:
- ネタをｎ人前×２つ切る。
- 以下を各桶に対して繰り返す;
- シャリをにぎる。
- (サビ入りなら)わさびをつける
- ネタを乗せる。
- 桶に格納する。
- 以下を各ネタに対して繰り返す:
別のプロセスとして、桶1つずつを完成させていく手順も考えられる。アーキテクチャはそこまでは規定していない。
こう考えると、アーキテクチャは開発プロセスに先行するものであり、アーキテクチャに変化があると開発プロセスにも影響が出る(かもしれない)。開発プロセスの位置づけは、アーキテクチャによって規定されたものをいかにうまく作るか？を考えるものになる。
たぶん開発プロセスの他にも、アーキテクトが手を出すべき対象はあるんだろう。技術音痴なボスをうまく丸めこむとかね。そこで求められるアーキテクトは「アーキテクチャだけをきっちり作る」という人材ではない。「アーキテクチャについて詳しくて、アーキテクチャを活用するためのいろいろな活動をする人」こそが求められる。
アーキテクチャと開発プロセスのくだりは、アーキテクチャセントリックな考え方だと思う。ほかのアプローチがあっても不思議ではない。開発プロセス以前の「開発方法論」というやつらも、おそらく同様の発想のものなんだろうな。方法論に人間という要素を加味したのが開発プロセス、って感じで。
