変幻する実行可能知識 12知識駆動ソフトウェア・ライフサイクル2004年2月から11回にわたって, ソフトウェアを実行可能知識として, ソフトウェアを作るということを知識の変換過程として見る立場から, さまざまな問題をそぞろ考えてきた. 連載を読んでいただければ分かるように, 特に確固とした体系だった概念があるわけではない. 大方は山田の脳内幻想だ. とは言うものの, ここらでひとつもっともらしい名前を付けて, この先へ進む手がかりを作ってから, ひとまずは連載を終えようと思う. 「知識」「知識」というような安易な物言いには反発を覚える人もいるだろうし, いったいその定義は何なんだという人もいるだろう. その通りだと思う. でも他に「これ」を表すいい言葉が見当たらないのだ. 問題領域や解決領域に充ち満ちているもの, その一部は言葉や図に表すことができ, その一部は言葉や図にすることはできないけれどその領域に属している多くの人が共通に感じて/知っており, その一部は意識することすらないけれどその領域をいつの間にか制約している, そういうもののことだ. 定義はできなくても確かに存在しているものがある. それを他に言葉がないからとりあえず「知識」と呼んでおこう. 「ソフトウェア・ライフサイクル」さて, その知識が駆動する = ドライブするのがソフトウェアのライフサイクルだ. ソフトウェアとは実行可能知識のことだった. 知識が駆動するのはなぜ単なるソフトウェア開発ではなく, ソフトウェア・ライフサイクルでなくてはいけないのだろうか. それはソフトウェアを実行可能知識と見る立場からは, ソフトウェアを開発するというのはソフトウェアの全体の中のごく一部でしかないからだ.  ソフトウェア・ライフサイクルとは, ある領域 (下のぐにょぐにょ) に満ちている知識の一部を実行可能知識 (= ソフトウェア) として無理矢理すくい取って (上の小さな玉), それがまた下のぐにょぐにょに落ちていって, 波紋を起こしながらバウンドして, ...というのを繰り返す過程だ. 小さな玉は最後には下のぐにょぐにょに同化して消えていく.  このすべての過程が知識によって駆動されている. 開発とはせいぜい最初に小さな玉を持ち上げようとする努力に相当する程度のものだけれど, 我々としてはこの過程全部 - つまり玉が生まれようとするところから, バウンドを繰り返して, 領域全体にささやかな影響を与えながら消えていくまで - を捉えたいわけだ. 要求も, 開発も, 運用も, 業務の日常も, 保守も... 「駆動」「駆動」という言葉はモデル駆動開発やモデル駆動アーキテクチャ (MDA) のおかげで, 今やちょっとした流行語だ. だからここでもちょっとだけそれにあやかろう:-) 知識, というか知識の海 (= 問題領域) はいつも変化し続けている. 海流がある. 海流は何ヶ月か何年かの周期で蛇行を繰り返すかもしれない (エルニーニョだ). 海流の回りでは小さな渦巻きがたくさん起きるだろう. 風が吹けば波も立つ. 海底の地形に応じて巨大な波が陸地に押し寄せることもある. そういった知識の海の変化が小さな, ときには大きな水しぶき (= ソフトウェア) を作り出し, 既にある水しぶきに影響を与える. 逆に海があまりに穏やかで単なるぬるい水たまりに過ぎないのならば, 何も起こらない. つまり駆動とは変化が力 (フォース) となって伝わっていくことだ. 変化がまったくなくても, すべてがでたらめに変化し続けていてもそれは一定の方向に駆動する力にはならない. 力が伝わるためには何らかの摩擦のようなものも必要になる. 「知識駆動ソフトウェア・ライフサイクル」知識駆動ソフトウェア・ライフサイクルなるものを仮にそのようなものだとすると, 重要なのは次のようなことだということになる.
もちろんa) ~ d)はみんな相互に関連しあっている. どれかひとつの項目だけが突出してよくできるというよりは, 4つの項目すべてがうまくバランスしている方が効果的だろうと思われる. さて, そのために, 例えば... 1. アーキテクトとは?アーキテクトは何をするのか? アーキテクトと言うからにはアーキテクチャを作るのがアーキテクトだ. アーキテクチャはどんな色, 形, 臭い, 重さ, 大きさなのだろうか? アーキテクチャはいったいどこに存在しているのだろうか? 設計書はアーキテクチャか? 仕様書はアーキテクチャだろうか? ソース・コードの中にアーキテクチャが隠れているというのか? それは美味いか? 気持ちいいか? それとも不快なものか? アーキテクチャは多分どこにもない. そしてアーキテクチャはどこにでもある. ソース・コードの隅々に. プロジェクト・ルームのホワイトボードの上に. ミーティング中のクライアントの落書きの中に. メンバの頭の中に. 建築の世界ならば, アーキテクチャとは実際に作られた建築物であると同時に, そのスタイルであり, 構造であり, 発表された論文である. ソフトウェアのアーキテクチャとは, できあがったソフトウェアそのものであると同時に, 知識のソフトウェアへの作り込みである. 知識を建築物に作り込むのと同じように, 知識をソフトウェアに作り込むのがソフトウェア・アーキテクトだ. だからソフトウェアを作るのに関わる全員がアーキテクトなのだ (= アーキテクト・ビルダの考え方,「パターンランゲージによる住宅の建設」C. アレグザンダー他, SDライブラリ, 1991, 鹿島出版会). 「能力構築競争 - 日本の自動車産業はなぜ強いのか」(藤本隆宏, 中公新書, 2003, 中央公論社) によれば, 自動車をメディアとしてみると「作り込み型」の製品カテゴリに入り, 日本の製造現場は「摺り合わせて作り込む」のが得意だったから自動車産業はこんなに成功したのだという. その特徴は
我々はどうか? トレードオフの克服はおろか, 生産性は低く, 品質も低く, 柔軟性も低い. 過去の事例への依存と安全性 (ことなかれ) にとらわれるあまり, ソフトウェア開発プロセスもその結果出てくるプロダクトも硬直化が進むばかりだ. 我々の組織, プロジェクトは学習し続けているだろうか (勉強会や読書会をするとか, そういうことではない). 2. 要求への知識の作り込み要求は変わる. 要求はきりがない. どこまで行ってももっと細かい話が出てくる. そもそも確固として一貫性のある要求などと言うものは肝心のユーザに取ってすらあらかじめ存在しているわけではない. だからユーザにインタビューして, すべての要求を聞き取ってから次のステップに進むというやり方がうまくいく可能性はない. ではどうすればよいか. 要求を出し, それを受け取る, というのはひとつのコミュニケーションだ. だから要求 (らしきもの) を受け取ったらそれをどう受け取ったのかを返さなければならない. まぁ顧客と一杯やりながら, というのもひとつの手ではあるかもしれないけれど, それはあまりに心許ない. 今までは「要求定義書」とか「仕様書」のようなものを作ればいいと思われていたけれど, 時間がかかる割にはユーザに「正しく」理解してもらえる可能性は低い. 我々にできる唯一のことはその要求を「動かして」みせることだ. それが我々の仕事なのだから. できればユーザから要求を聞きながらその場で作って動かす. でもそれが無理だとしたら, せめて来週には... それによって次の一歩を踏み出すことができる. 「動かす」方法はいくつかある. 一番簡単なのはユーザ・インタフェースの紙芝居を作ることだ. PowerPointでもFlashでも, なんだったらスケッチブックに書いてもいい (例えば「ペーパー・プロトタイピング - 最適なユーザインタフェースを効率よくデザインする」, Carolyn Snyder, 2004, オーム社). もう少し裏の仕掛けまで作り込もうと思えば, さまざまなスクリプト言語や簡易的な開発環境もある (Groovy, Squeak, Naked Object, Plone/Archetypesなどなど). ただし安易に「動くもの」を作ると, ここまでせっかくユーザから聞き取り, 形にした有形無形の知識がまた散り散りバラバラになって見えなくなってしまう. できれば「動くもの」がそのまま仕様であってほしい. これはひとつの大きな課題だ. 3. 設計への知識の作り込みもし「要求を動かしたもの」を継続的に洗練していって最終的な製品になるならば, 設計のような作業は必要なくなる. でも少なくとも今のところ, なかなかそうはいかない. いずれにしても, 動かすには動かすための知識の作り込みが必要になる. 「何を動かすか」に対して「どうやって動かすか」という知識だ. 設計とは「何を動かすか」と「どうやって動かすか」の折り合いをどうつけるか, ということだと言ってもいい. さらに設計をしたり設計したものを実現するのは一人ではなく, 複数の人間が関わってくる. その折り合いをどうつけるか, ということもである. 設計の本質の一部は「折り合いをつける」ことだとして, そのためには発見し, 試行錯誤し, 協調するというプロセスが必要になる. 現状のほとんどの設計ツール (そんなものはあるのか? IDE? UML? MDA?) はそのようなプロセスを支援してくれない. そのような目的でWikiWikiやCMSなどを使っているプロジェクトもあるだろうけれど, よほど強力なモチベーションがなければなかなか続かないものだ. 第一WikiWikiなどは蓄積型メディアなので, メンバ全員が同じときに同じことに注目すべきプロセスには向いていない. ではミーティングか? 普通にダラダラミーティングしているだけではしかたがない. 例えばマインド・マップ. マインド・マップでは関連に名前を付けることはできないし, 基本的にツリー構造だからそれが気になるのならば, 例えばコンセプト・マップも使える. ここまで来ればオントロジと50歩100歩だ. もっとダイナミックなプロセス・ガイドラインが必要と思えば, 例えば「問題解決のための高速思考ツール」(デビッド・ストレイカー, 2005, エスアイビー・アクセス) などが役に立つだろう. ここでも課題はある. 上記のような道具はPCの小さな画面で一人で使っていてもあまり意味がない. 大きなホワイト・ボードやスクリーンの前でみんなが巻き込まれながら使ってこそのツールである. 一方ではこの成果を他のソフトウェア・ツール (モデリング・ツール, 開発環境など) とシームレスにつなぎたい. この二つは今のところ両立させにくい. 4. 開発への知識の作り込み開発時にどうやって知識を作り込むかについては, 例えばエクストリーム・プログラミングなどが非常に有効な解法を与えている. ただし誰でも簡単に正しくストーリ・カードを書けるかといえばそんなことはないし, 誰でも簡単に正しくストーリをタスクに分解できるかといえばそんなこともない. エクストリーム・プログラミングではこの辺りがどうも「さっと飛ばされている」ような気がしないでもない. この点が前述した, 要求への知識の作り込みと設計への知識の作り込みにつながってくる. 5. 知識の一生知識は生きている. 生まれたときには新鮮かもしれないが, 誰にでもは分かってもらえない. 矛盾もあるし, 間違ってもいる可能性が高い. でもその中には本当に重要なアイデアがある. それが成長するにつれ, いじり回され, 形式化されていく. もちろんそれは知識にとって必要なことだ. ただしそのうちに知識はしなびてくる. 作り込まれた知識もいずれは寿命が来る. その最期を看取り, 次の世代へと引き継ぎ, 再生させてやらなければならない. つまり知識の作り込みのプロセスには終わりがない. そこで, 最初に戻る. |