- 顧客が本当に必要だったものという風刺画
- 風刺画は、伝言ゲームの難しさを語っている
- 伝言ゲーム×２回に対する対策
- 結論：顧客が本当に必要なものかどうか、外部設計レベルまで踏み込んで顧客に確認してもらおう
顧客が本当に必要だったものという風刺画
顧客が本当に必要だったものという、有名な風刺画がある。
顧客は、木の枝に紐で繰りつけられたタイヤのブランコが欲しかったのだが、中間成果物や最終成果物がすべて思っていたものと違ったというものだ。詳しくは、下記のリンクでご確認いただきたい。
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科 (nicovideo.jp
風刺画は、伝言ゲームの難しさを語っている
上記の風刺画は、システム開発において、関係者間で認識を合わせるのがいかに難しいのかということを物語っている。下記図に、顧客、設計者、プログラマがいた場合における、一般的な開発フローを示した。
顧客は要件定義書を書き、設計者はそれをもとに設計書を書く。プログラマは、その設計書をもとにプログラムを書く。この工程のやっかいな点は、ドキュメントベースの伝言ゲームが2回行われている点だ。しかも、最初に伝言を行う者は、システム開発のプロではない。
ざっと考えただけで、下記のようなリスクが存在する。
- ①：顧客が、頭に思い描いていることを、うまく要件定義書に落とし込めない
- ②：設計者が、要件定義書の内容を誤って解釈する
- ③：設計者が、頭に思い描いていることを、うまく設計書に落とし込めない
- ④：プログラマが、設計書の内容を誤って解釈する
- ⑤：プログラマが、頭に思い描いていることを、うまく実装に落とし込めない
伝言ゲーム×２回に対する対策
伝言ゲームが2回行われているという点で、システム開発が成功する確率はぐっと低くなる。では、どうするべきか？
答えはシンプルである。伝言ゲームを行う必要はなく、①と②と③の作業をなるべく一緒に行い、ドキュメントを確認しながら認識合わせを行えばよいのである。
しかしながら、顧客がそんな時間とれるわけないだろう、参加してもらっても意味ないだろうという話がある。確かにそのような面もあるかもしれないが、全部の設計書を確認しろといっているわけではない。
筆者の提案は、外部設計書のみ、顧客も一緒に確認するというものだ。
設計書には、外部設計書と内部設計書(別の機会で説明)が存在する。外部設計書までを顧客と確認し、お互いに認識を一致させることができれば、少なくとも、システムの外観(振る舞い)において、こんなんじゃなかったという事態になることはない。
ただし、設計書まで踏み込んで確認会を行うことは、大変な労力を必要とする。それでも、その労力と手戻りのリスクを天秤にかければ、最初に労力をかけたほうがよいとなるはずである(手戻りりコストについては別の機会で説明)。
顧客を巻き込んで開発をするためには、これをやらないとどうなってしまうのかということを丁寧に説明し、顧客を開発にコミットさせていかなければならない。エンジニアはPCとだけ向き合っていればいいというわけではなく、顧客と向き合い続けなければならないのだ。
