変幻する実行可能知識 10「ものがたるといふこと」「アーキテクト」とは形を作る者の謂いだ, ということを最初に話した. アーキテクトの立場からすれば, ソフトウェアとは何かの「形」のように見えているというわけだ. でももちろんそれ以外の見方もある. ソフトウェアはたとえできあがった後でも静かに固まってじっとしているわけではない. ああ, こんなソフトウェアがあったらなぁという顧客や開発者の思いから始まって, その思いを具体化し, 動かしてみて, 思ったようにはいかず, 何度も作り直し, 使っているうちにだんだんユーザの手に馴染みながら, アップデートされていく, ソフトウェアの見え方もある. アーキテクトが見るものが形だとすれば, 後者が見るものは時間である. 形を表したものがモデルだと言うことにすれば, 時間を表したものはストーリ (物語, 歴史) だと言ってもいいかもしれない. 例えばエクストリーム・プログラミングでは, ユーザの要求のことをストーリと呼ぶが, これはあながち気取って変わった言葉を使っているだけではない. やはり何かソフトウェアのもう一つの本質というようなものがそこにはあるのだ. ソフトウェアにはいくつもの時間が流れている. つまりいくつもの物語が重なっている. まずそのソフトウェア自身が物語を持っている. そのソフトウェアがどのように使われるか, という物語だ. ソフトウェアに対する顧客やユーザの要求を洗い出したり, 基本的な設計を行うのに, ユーザが欲しい機能を列挙していくのは一般的なやり方だけど, このやり方はうまくいかないことが多い. とにかくバラバラな機能だけが盛りだくさんで, 結局使い物にならないシステムになりがちだからだ. つまりここに形はあっても物語がない. 物語がないものは人は使いたがらない. ユーザの要求を洗い出したり, 基本的な設計を行うもう一つの方法はシナリオを書くやり方だ. ある人 (たち) があることをするのにどんな順序でどうやってやるか, どうやればいいかを具体的に一つ一つ考えていく. 例えば買い物に行くのに「買い物とは販売者から金銭ないしはそれに類するものと交換に商品を入手するプロセスである」と定義して, 販売者を見つける機能, 金銭などを保存する機能, 金銭などを使用する機能, 必要な商品を記憶して判断する機能などを身につけてから出かけるよりは, 「えーと今日はあそこで18mmホロゴンを買うんだよな. もう取り置きになっていて, レジでお金を, おっとそうだお金が足りないし, クレジット・カード使えないから銀行カード持って行ってお金降ろさなくちゃ, そうそうポイント・カードもね, ...」というようにシナリオ・ベースで考えたほうが忘れ物は少なくなる. ただしひとつのシナリオはある個別の具体的な状況における一つの事例を表しているに過ぎない. だからいくつかのシナリオだけを満たすシステムを作って十分かというとそういうわけにはいかない. シナリオだけから完全な要求を作るためには無限個のシナリオが必要になることになる. といって, 「形から入る」やり方はやりたいことを完全に表しているように見えて, 実はいろんな重要なところを落としているし, 形を組み上げて時間の流れの中で実際にうまく動くことを保証しているわけではない. その点は既存パターンを多用する場合にも同じことが言える. ソフトウェアを作るという, 問題そのものが不明確で, 決まった解法もなく, 資源が制約された共同作業では, シナリオのような帰納的な方法が重要になってくるのである. 参考: シナリオはいくつかの場面で使うことができる. 顧客やユーザの領域でものごとが実際にどう動いているかという知識を得るとき (分析シナリオ), 顧客やユーザの領域で何をどう変えればよいのかを検討するとき (設計シナリオ), 顧客やユーザの要求に沿ったシステムが実際にどう動くかをチェックするとき (検証シナリオ) などなど. つまりシナリオはある領域における具体的な知識がそれに隣り合う別の領域からどう見えるかを表している.  演劇やドラマが, 生ビデオのような事実をそのまま切り取っただけのものではなく, 作者や演技者の解釈の集合から成り立っているように, シナリオも現実を模倣しているだけのものではない. システムの目からビジネスをみるとどのように具体的に見えるのか, ビジネスの目から見るとシステムは具体的にどう見えるのかという相互の「解釈」を同時に表している. シナリオは具体的であり, なおかつ抽象的なのである. 分析シナリオや検証シナリオがユーザの領域やシステムの領域からある程度「与えられる」のに較べると, 設計シナリオは無数の選択肢の中から, 分析シナリオや検証シナリオとの整合性を保ちつつ, ユーザの領域とシステムの領域を往復しつつ, 「作られて」いく.  そう考えると, 我々の知識変換過程としてのソフトウェア開発というのは, 二つの知識領域をつなぐユーザから見た物語と開発者から見た二つの物語を紡ぎ出す過程と見ることもできそうだ (注). この二つの物語ができるだけ矛盾なく, 自然につながっているということが, うまくソフトウェアを作ることができたということに対応する. 注: 場合によってはさらに違う立場の人, 例えば顧客が, 違う物語を見ているかも知れない. その場合には物語の数はさらに増えていくことになる. ここまで話してきたのは成果物としてのソフトウェアがもつ物語であった. この物語の書き手は顧客であり, 開発者であり, 場合によってはユーザも参加する. この物語を読み解くのは主にユーザである. 保守担当者がこの物語を読まなければならないはめに陥ることもあるかも知れない. そして, ソフトウェアにはもう一つの物語がある. 成果物としてのソフトウェア自身がひとつの物語だとしたら, その物語を書く過程というのももうひとつの物語だ. 下世話に言ってしまえば「プロジェクトX」みたいなものだ. 残念ながら僕らのプロジェクトは「プロジェクトX」ほどドラマチックでも大成功でもないかも知れないけれど (少なくともプロジェクトが終わった直後には. どんなプロジェクトでもそんなものだろう. 物語はプロジェクトが終わった後にも作られるのかも知れない). 僕たちのこの物語はプロジェクトの関係者がみんなで書く物語であり, みんなで読む物語である. この過程としてのソフトウェア開発という物語にも, 成果物としてのソフトウェアという物語と同じような構造がありそうな気がしているのだが, その話はまたいつか... |