トップ 一覧 検索 ヘルプ RSS ログイン

駄文-2009年10月の変更点

  • 追加された行はこのように表示されます。
  • 削除された行はこのように表示されます。
!!!2009年10月の駄文

!2009年10月26日……要件ドキュメントの要件

久々に仕事で「要件定義書」を書いた。
普段下流工程ばっかりやっているので要件定義書を書くのは超久々だったのだが、やっぱりなんというか、「要件定義書とは何なのだろう?」と思ってしまう。

例えば、建築事務所に家を注文する時にお客が「こういう間取りがいい」「こういうテラスをつけて欲しい」などと注文をつけることを設計士と顧客の間で合意する為の設計文章がシステム開発の要件定義書。

でもさ、確かに図がついているからといって一般の人達が要件定義書なんか見てハッキリとその家(=システム)を想像できるのか?
それにシステムそのものを使った業務というものをリアルに想像できるのか?

家だったら「模型」という手段がある。
それなりにお金も期間もかかるだろうが、ある程度リアルにその建物の使い勝手を想像することが可能になるのではないだろうか?

一方、コンピュータシステムは家よりもよっぽど簡単に「模型」を作ることができる。
正確に言えば模型というよりもハリボテに近いのだが、それでも材料費も工期も家よりかはもっともっと安価にできる。

しかも、家とは違ってほとんどの場合のシステム開発では、ハリボテがそのまま本番システムの開発土台になりえるのだ。
そういった意味で家に対する模型よりもシステムに対するハリボテはよっぽど費用もかからずかつ有意義なのだ。

SEの中には「客に変なもの見せるとそれが先入観になってしまってコンサルティングを変な方向に持って行ってしまうことがある」と言う人もいるが、「変な先入観」というのは「変な」という語が付けられるように、お客の頭の中にあるイメージとハリボテの間のギャップを可視化できる。
ハリボテがなければ変かどうかの見分けもつかない。

もっと突っ込んだ言い方をすれば本来客が持っているべきイメージを「要件定義」という名の下にSEが取り上げてしまっているのである。

確かに客は大抵の場合システム開発に関してはシロウトだが、業務に関してはSEよりも熟達しているはずで、自分たちの「やりやすさ」の為にお客のイメージを取り上げてしまう事は結局はシステムが実際に使われるシチュエーションの最高のアドバイザーを除け者にしているということになるのではないだろうか?

「やりやすい」事はシステム開発の場合コストに直結する。
だからコストが伸びない事は客にとっても重要な事なのだと言えなくも無いが、お客は果たしてそれで満足するのだろうか?

それに、客とのやり取りを直接見ていない下流の開発者にしてみても、上流開発者から下流開発者に対しての「情報バケツリレー」があって、その間で伝聞が変化したり漏れたりする事だってある。
SEは必ずしもプログラミングのプロではないので、実装を行うに従って上流で検討漏れがある場合だってある。

そういうことの認識齟齬を埋めるのには「とにかく形があって動くように見える」ハリボテは非常に強力なツールになりえるのだ。

模範的なSEはそういったイメージギャップを詳細な要件定義書と設計書によって埋めようとするが、「書」は動かない。
システムには「動き」があって、4次元的な時間軸方向に広がりのあるものなのだ。
いくらドキュメントに図や画像を増やしたところで2次元記述である「書面」ではその断面しか見えないのだ。

しかも笑ってしまう事に、詳細で画像いっぱいの要件定義書や設計書を書こうとすれば書こうとするほど、より現実的な外見をもったハリボテが必要になるし、ほとんどのプロジェクトではドキュメント作成用に裏でハリボテを作っていたりする。

こうなってしまうとまさに「なにをいわんや」だ。

いわば、お客の望む絵を描くことを依頼された画家に指示を出す為に、設計者がその詳細な絵を書いて、それをポラロイドに撮って渡しているようなものだ。
また、システム開発を皮肉った漫画にあるように、「盲目の人たちが象について語る」みたいなコメディーをまじめな顔してやっているのだ。
中にいる人とお客は笑うに笑えないのだが。

今時、よっぽど特殊な事情でもない限り、システムのハリボテはノートパソコンで持って歩ける。
SEはPGにハリボテを作らせてそれをお客とレビューし、そのハリボテを「要件定義書」として納品してしまえばいいのだ。
それに近い開発スタイルが「XP」というヤツだが、日本の大手SIerはそれを外道だと思い込んでいる節がある。

モナリザの複製画を作るのに文章で「顔がどうの」「色合いがどうの」「ポーズがどうの」「背景がどうの」って伝えようとしているのである。
(しかも、変化するドキュメントに目次を付けたりだとか、同じ対象を指す事象に付けた名刺の統一作業とか、「ドキュメント」という名の付いた納品物を作るのにはシステムの本質とは全く関係ない雑事が山のように付きまとう。)

そんなわけで、私は「要件定義をすることは別に要件定義書を作ることではない」と常々考えている。
何とかならないかなぁ…。

{{comment}}
----

{{trackback}}

[[新・Tsubasa's日記(駄文)]]に戻る