「鈴木さん、うちの会社では以前システム開発委託で失敗したんです」とは、昨年当社のコンサルティングサービスを受けられた会社の社長さんの弁。お話を聞いてみると「要件定義できた、開発も進んだ、形式上は完成した、納品もされた。しかし納品されたものは期待しているものではなかった。結果的にお金を無駄にしてしまった。」とのこと。要するに要求事項を開発者に伝えきれなかったということです。要求を伝えきる…これは一見簡単そうに見えて実に難しいものです。

一般に要件定義作業は顧客である委託元とソフトの開発者（リーダー）との間で議論を積み重ねて要求事項を明文化する作業となります。ソフト開発のスタイルにもよりますが、要求されている機能を一覧化し、機能概要を解説し、その説明ができるポンチ絵がセットになっていることが多いものです。書類の量は時として大量なものになるので、委託元にどさっと渡してもなかなか目を通して確認することができません。この確認が粗すぎた場合、冒頭の様にせっかく開発したものが委託元の想像していたものと違う、という実に残念な事故が発生します。この要件定義作業の難しさを助長しているのが、「資料の清書に拘りすぎるからだ」と私は考えています。

要件定義作業とはいっても人間同士の会話が基本となります。定例会を開催し、要求されている機能を順番に議論し、それを明確にするために資料を作り、それを確認に回す、という手順の繰り返しで要件定義作業は進みます。ところが、この人間対人間の会話作業のやり方が問題なのです。開発者側の頭の中は常にロジックをどう実現するか、という思考であふれています。対する委託元の社長や担当者の頭の中は、ソフトウェアの動きや業務の流れをメインに考えています。当然、両者の考え方は当初から大きくずれており、ただでさえ合意点に向かって正確・適切に議論を導くことがそもそも難しい状況です。そしてその困難な議論の末に得た結論を、開発者は持ち帰ってソフトを使ってきれいに清書したものがアウトプットされていきますが、それは会議の後の作業になるので、内容は開発者の理解できた範囲のものに限られ、さらに会議後の思考により生み出された想像されたものが含まれてしまったり、議論の行間に陥った情報は逆に載りません。そんなすれ違いが積み重なった結果、要件定義書の束が完成し、その確認がきちんとできないままソフトウェア開発が進行し、結果的に悲劇に至るのです。

では、どうすればそれを回避できるのでしょうか？私は「オフィスソフトなど使って清書する暇があるなら、会話の中で手書きのスケッチをどんどん描くべきだ」と考えています。これは何もシステム開発に特化した考え方ではなく、いわゆる「ファシリテーショングラフィクス」の一貫とお考え頂くべきでしょう。ファシリテーショングラフィクスとは、簡単に言えば会議の議論の中身を文字だけではなく絵で描いてゆく、という考え方です。長ったらしい文章で説明するよりも、ホワイトボードや模造紙に絵を描いてしまった方が議論が進む、というものです。要件定義の打ち合わせも、「後からポンチ絵を描いて提出する」のではなく、手書きでも良いので会議の中で描いてしまうべきなのです。できあがった書類は乱雑なものになりがちですが、これで充分用を為すだけでなく、文章に起こしたりきれいに清書したりする際にそぎ落とされてしまう情報もきちんと中に入っています。しかもリアルタイムに全員がそれを見ているので、余計な確認作業も不要です。

「殴り書きの書類などお客様に提示できないよ」とお考えになる開発者が多いかと思いますが、役に立たない・誤解だらけの清書を提出するよりもずっと生産性と品質が高いものになります。

IT化のために殴り書きの絵を使う・・・ちょっと納得できないという方もいらっしゃると思いますが、是非お試しになることをお勧めします。