アーキテクト再考：実行可能な知識とソフトウェア（12）

建築の世界ならば、アーキテクチャとは実際に作られた建築物であると同時に、そのスタイルであり、構造であり、発表された論文である。ソフトウェアのアーキテクチャとは、出来上がったソフトウェアそのものであると同時に、知識のソフトウェアへの作り込みである。（本文より）

（1）アーキテクトとは？

　アーキテクトは何をするのか？ アーキテクトというからにはアーキテクチャを作るのがアーキテクトだ。アーキテクチャはどんな色、 形、におい、重さ、大きさなのだろうか？ アーキテクチャはいったいどこに存在しているのだろうか？ 設計書はアーキテクチャか？ 仕様書はアーキテクチャだろうか？ ソース・コードの中にアーキテクチャが隠れているというのか？ それはうまいか？ 気持ちいいか？ それとも不快なものか？

　アーキテクチャは多分どこにもない。そしてアーキテクチャはどこにでもある。ソース・コードの隅々に。プロジェクト・ルームのホワイト・ボードの上に。ミーティング中のクライアントの落書きの中に。メンバーの頭の中に。

　建築の世界ならば、アーキテクチャとは実際に作られた建築物であると同時に、そのスタイルであり、構造であり、発表された論文である。ソフトウェアのアーキテクチャとは、出来上がったソフトウェアそのものであると同時に、知識のソフトウェアへの作り込みである。知識を建築物に作り込むのと同じように、知識をソフトウェアに作り込むのがソフトウェア・アーキテクトだ。だからソフトウェアを作るのにかかわる全員がアーキテクトなのだ（＝アーキテクト・ビルダの考え方「パタンランゲージによる住宅の建設」（C. アレグザンダー 他、SDライブラリー、1991、鹿島出版会）。

　「能力構築競争 - 日本の自動車産業はなぜ強いのか」（藤本隆宏、中公新書、2003、中央公論新社）によれば、自動車をメディアとして見ると「作り込み型」の製品カテゴリに入り、日本の製造現場は「摺り合わせて作り込む」のが得意だったから自動車産業はこんなに成功したのだという。その特徴は、

• 高い生産性と製造品質、短い生産リードタイムというような両立の難しい属性のバランスを取ることができた（トレードオフの克服）
• 製品の変化や多様性への対応など高いフレキシビリティを達成した
• ある種の組織学習メカニズムが組み込まれていた

の3点であるとしている。

　われわれはどうか？ トレードオフの克服はおろか、生産性は低く、品質も低く、柔軟性も低い。過去の事例への依存と安全性（事なかれ）にとらわれるあまり、ソフトウェア開発プロセスも、その結果出てくるプロダクトも、硬直化が進むばかりだ。われわれの組織、プロジェクトは学習し続けているだろうか（勉強会や読書会をするとか、そういうことではない）。

（2）要求への知識の作り込み

　要求は変わる。要求にはキリがない。どこまで行ってももっと細かい話が出てくる。そもそも確固として一貫性のある要求などというものは肝心のユーザーにとってすら、あらかじめ存在しているわけではない。だからユーザーにインタビューをして、すべての要求を聞き取ってから次のステップに進むというやり方がうまくいく可能性はほとんどないといっていい。ではどうすればよいか。

　要求を出し、それを受け取る、というのは1つのコミュニケーションだ。だから要求（らしきもの）を受け取ったらそれをどう受け取ったのかを返さなければならない。まぁ顧客と一杯やりながら、と いうのも1つの手ではあるかもしれないけれど、それはあまりに心もとない。いままでは「要求定義書」とか「仕様書」のようなものを作ればいいと思われていたけれど、時間がかかる割にはユーザーに「正しく」理解してもらえる可能性は低い。

　われわれにできる唯一のことはその要求を「動かして」みせることだ。それがわれわれの仕事なのだから。できればユーザーから要求を聞きながらその場で作って動かす。でもそれが無理だとしたら、せめて来週には……、それによって次の一歩を踏み出すことができる。「動かす」方法はいくつかある。一番簡単なのはユーザー・インターフェイスの紙芝居を作ることだ。PowerPointでもFlashでも、なんだったらスケッチブックに書いてもいい（例えば「ペーパー・プロトタイピング - 最適なユーザインタフェースを効率よくデザインする」Carolyn Snyder、2004、オーム社）。もう少し裏の仕掛けまで作り込もうと思えば、さまざまなスクリプト言語や簡易的な開発環境もある（Groovy、Squeak、Naked Object、Plone/Archetypesなどなど）。

　ただし、安易に「動くもの」を作ると、ここまでせっかくユーザーから聞き取り、形にした有形無形の知識がまた散り散りバラバラになって見えなくなってしまう。できれば「動くもの」がそのまま仕様であってほしい。これは1つの大きな課題だ。

（3）設計への知識の作り込み

　もし「要求を動かしたもの」を継続的に洗練していって最終的な製品になるならば、設計のような作業は必要なくなる。でも少なくともいまのところ、なかなかそうはいかない。いずれにしても、動かすには動かすための知識の作り込みが必要になる。「何を動かすか」に対して「どうやって動かすか」という知識だ。設計とは「何を動かすか」と 「どうやって動かすか」の折り合いをどうつけるか、ということだといってもいい。さらに設計をしたり設計したものを実現するのは1人ではなく、複数の人間がかかわってくる。その折り合いをどうつけるか、ということでもある。

　設計の本質の一部は「折り合いをつける」ことだとして、そのためには発見し、試行錯誤し、協調するというプロセスが必要になる。現状のほとんどの設計ツール（そんなものはあるのか？ IDE？ UML？ MDA？）はそのようなプロセスを支援してくれない。そのような目的で WikiWikiやCMSなどを使っているプロジェクトもあるだろうけれど、よほど強力なモチベーションがなければなかなか続かないものだ。 第一、WikiWikiなどは蓄積型メディアなので、メンバー全員が同じときに同じことに注目すべきプロセスには向いていない。

　ではミーティングか？ 普通にダラダラとミーティングしているだけでは仕方がない。例えば、マインド・マップ（「マインド・マップ の基本と応用」）。マインド・マップでは関連に名前を付けることはできないし、基本的にツリー構造だからそれが気になるのならば、コンセプト・マップも使える。ここまで来ればオントロジと五十歩百歩だ。もっとダイナミックなプロセス・ガイドラインが必要だと思えば、「問題解決のための高速思考ツール」（デビッド・ストレイカー、2005、エスアイビー・アクセス）などが役に立つだろう。

　ここでも課題はある。上記のような道具はPCの小さな画面で1人で使っていてもあまり意味がない。大きなホワイト・ボードやスクリー ンの前でみんなが巻き込まれながら使ってこそのツールである。一方ではこの成果をほかのソフトウェア・ツール（モデリング・ツール、開発環境など）とシームレスにつなぎたい。この2つはいまのところ両立させにくい。

（4）コードへの知識の作り込み

　コードにどうやって知識を作り込むかについては、エクストリーム・プログラミングなどが非常に有効な解法を与えている。ただし、誰でも簡単に正しくストーリー・カードを書けるかといえばそんなことはないし、誰でも簡単に正しくストーリーをタスクに分解できるかといえば、そんなこともない。エクストリーム・プログラミングではこの辺りがどうも「さっと飛ばされている」ような気がしないでもない。この点が前述した、要求への知識の作り込みと設計への知識の作り込みにつながってくる。

（5）知識の一生

　知識は生きている。生まれたときには新鮮かもしれないが、誰にでも分かってもらえるわけではない。矛盾もあるし、間違ってもいる可能性も高い。でも、その中には本当に重要なアイデアがある。それが成長するにつれ、いじり回され、形式化されていく。もちろんそれは知識にとって必要なことだ。ただし、そのうちに知識はしなびてくる。作り込まれた知識もいずれは寿命が来る。その最期をみとり、次の世代へと引き継ぎ、再生させてやらなければならない。つまり知識の作り込みのプロセスには終わりがない。

（6）最後、最終、終末、完了、終了……

　唐突だが、12回にわたったこの連載もここで終わる。テーマは 「ソフトウェア・プロセスとは知識を動くものへと変換する過程」ということだった。この続きはそれぞれのプロジェクトで。