ソフトウェア設計とストーリーの記述について実行可能な知識とソフトウェア(10)

アーキテクトが見るものが形だとすれば、後者が見るものは時間である。形を表したものがモデルだということにすれば、時間を表したものはストーリー(物語、歴史)だといってもいいかもしれない。(本文より)

» 2005年04月13日 12時00分 公開
[山田正樹,メタボリックス]

 「アーキテクト」とは形を作る者の謂いだ、ということをこの連載の最初に話した。アーキテクトの立場からすれば、ソフトウェアとは何かの「形」のように見えているというわけだ。でももちろんそれ以外の見方もある。ソフトウェアはたとえ出来上がった後でも静かに固まってじっとしているわけではない。ああ、こんなソフトウェアがあったらなぁという顧客や開発者の思いから始まって、その思いを具体化し、動かしてみて、思ったようにはいかず、何度も作り直し、使っているうちにだんだんユーザーの手になじみながら、アップデートされていく、ソフトウェアの見え方もある。

 アーキテクトが見るものが形だとすれば、後者が見るものは時間である。形を表したものがモデルだということにすれば、時間を表したものはストーリー(物語、歴史)だといってもいいかもしれない。例えばエクストリーム・プログラミングでは、ユーザーの要求のことをストーリーと呼ぶが、これはあながち気取って変わった言葉を使っているだけではない。やはり何かソフトウェアのもう1つの本質というようなものがそこにはあるのだ。

  ソフトウェアにはいくつもの時間が流れている。つまりいくつもの物語が重なっている。まずそのソフトウェア自身が物語を持っている。そのソフトウェアがどのように使われるか、という物語だ。ソフトウェアに対する顧客やユーザーの要求を洗い出したり、基本的な設計を行うのに、ユーザーが欲しい機能を列挙していくのは一般的なやり方だけど、このやり方はうまくいかないことが多い。とにかくバラバラな機能だけが盛りだくさんで、結局使い物にならないシステムになりがちだからだ。つまりここに形はあっても物語がない。物語がないものを人は使いたがらない。

 ユーザーの要求を洗い出したり、基本的な設計を行うもう1つの方法はシナリオを書くやり方だ。ある人 (たち)があることをするのにどんな順序でどうやってやるか、どうやればいいかを具体的に1つ1つ考えていく。例えば買い物に行くのに「買い物とは販売者から金銭ないしはそれに類するものと交換に商品を入手するプロセスである」と定義して、販売者を見つける機能、金銭などを保存する機能、金銭などを使用する機能、必要な商品を記憶して判断する機能などを身に付けてから出掛けるよりは、「えーと今日はあそこで16mmホロゴン(CONTAX Gシリーズ用カールツァイスの超広角レンズ)を買うんだよな。もう取り置きになっていて、レジでお金を、おっとそうだお金が足りないし、クレジット・カードが使えないから銀行のカードを持っていってお金降ろさなくちゃ、そうそうポイント・カードもね……」というようにシナリオ・ベースで考えた方が忘れ物は少なくなる。

 ただし、1つのシナリオはある個別の具体的な状況における1つの事例を表しているにすぎない。だからいくつかのシナリオだけを満たすシステムを作って十分かというとそういうわけにはいかない。シナリオだけから完全な要求を作るためには無限個のシナリオが必要になることになる。といって、「形から入る」やり方はやりたいことを完全に表しているように見えて、実はいろんな重要なところを落としているし、形を組み上げて時間の流れの中で実際にうまく動くことを保証しているわけではない。その点は既存パターンを多用する場合にも同じことがいえる。ソフトウェアを作るという、問題そのものが不明確で、決まった解法もなく、資源が制約された共同作業では、シナリオのような帰納的でソフトな方法が重要になってくるのである。




 シナリオはいくつかの場面で使うことができる。顧客やユーザーの領域で物事が実際にどう動いているかという知識を得るとき(分析シナリオ)、顧客やユーザーの領域で何をどう変えればよいのかを検討するとき(設計シナリオ)、顧客やユーザーの要求に沿ったシステムが実際にどう動くかをチェックするとき (検証シナリオ)などなど。つまりシナリオはある領域における具体的な知識がそれに隣り合う別の領域からどう見えるかを表している。

ALT 図1 システムの領域とユーザーの領域

 演劇やドラマが、生ビデオのような事実をそのまま切り取っただけのものではなく、作者や演技者の解釈の集合から成り立っているように、シナリオも現実を模倣しているだけのものではない。システムの目からビジネスを見るとどのように具体的に見えるのか、ビジネスの目から見るとシステムは具体的にどう見えるのかという相互の「解釈」を同時に表している。シナリオは具体的であり、なおかつ抽象的なのである。分析シナリオや検証シナリオがユーザーの領域やシステムの領域からある程度「与えられる」のに比べると、設計シナリオは無数の選択肢の中から、分析シナリオや検証シナリオとの整合性を保ちつつ、ユーザーの領域とシステムの領域を往復しつつ、「作られて」いく。

ALT 図2 設計シナリオの作られ方

 そう考えると、われわれの知識変換過程としてのソフトウェア開発というのは、2つの知識領域をつなぐユーザーから見た物語と開発者から見た2つの物語を紡ぎ出す過程と見ることもできそうだ[*]。この2つの物語ができるだけ矛盾なく、自然につながっているということが、うまくソフトウェアを作ることができたということに対応する。


[*]
場合によってはさらに違う立場の人、例えば顧客が、違う物語を見ているかもしれない。その場合には物語の数はさらに増えていくことになる。


 ここまで話してきたのは成果物としてのソフトウェアが持つ物語であった。この物語の書き手は顧客であり、開発者であり、場合によってはユーザーも参加する。この物語を読み解くのは主にユーザーである。保守担当者がこの物語を読まなければならない羽目に陥ることもあるかもしれない。

 そして、ソフトウェアにはもう1つの物語がある。成果物としてのソフトウェア自身が1つの物語だとしたら、その物語を書く過程というのももう1つの物語だ。下世話にいってしまえば「プロジェクトX」みたいなものだ。残念ながら僕らのプロジェクトは「プロジェクトX」ほどドラマチックでも大成功でもないかもしれないけれど(少なくともプロジェクトが終わった直後には。どんなプロジェクトでもそんなものだろう。物語はプロジェクトが終わった後にも作られるのかもしれない)。僕たちのこの物語はプロジェクトの関係者がみんなで書く物語であり、みんなで読む物語である。この過程としてのソフトウェア開発という物語にも、成果物としてのソフトウェアという物語と同じような構造がありそうな気がしているのだが、その話はまたいつか……。

著者プロフィール

山田正樹

(株)ソフトウェア・リサーチ・アソシエイツ 、(株)ソニーコンピュータサイエンス研究所を経て、1995年(有)メタボリックス設立。代表取締役。アーキテクチャ、モデリング、マネージメント、コラボレーションなどを含む広い意味でのソフトウェア・プロセス・エンジニアリングが専門。ソフトウェア・ツール開発、メンタリング、コンサルティングなどを行っている。


Copyright © ITmedia, Inc. All Rights Reserved.