「プログラマーの夫に買い物を頼んだら」というジョークから見る要件定義の重要性

スポンサードサーチ

プログラマーという人たちを皮肉ったジョークとして、「プログラマーの夫に買い物を頼んだら」という有名なお話があります。

A wife asks her husband, a programmer, “Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?”

日本語訳：妻がプログラマの夫に言いました。「買い物にいって牛乳を1つ買ってきてちょうだい。そして、もし卵があったら6つお願い。」

A short time later the husband comes back with 6 cartons of milk and his wife asks, “Why did you buy 6 cartons of milk?”

日本語訳：少しした後、夫は牛乳を６つ買って帰って来たので、妻は「なんで牛乳を６つも買ってきたの？」と尋ねました。

He replies, “They had eggs.”
日本語訳：彼は答えました。「卵があったから。」

妻は夫に以下の２つの要望を伝えたつもりでした。

• 牛乳を１つ買ってきて欲しい
• 卵が売っていれば卵も6個買ってきて欲しい

ところが、夫は以下のように牛乳を買う一つの要望だと理解をしていました。

• 牛乳を１つ買ってくる
• 卵が売ってなければ牛乳は１つでいいが、卵が売っていれば牛乳を6つ買ってくる

これは、プログラミングでよく使われる「If～then」という条件分岐がネタになっています。

条件分岐というのは、「もし○○だったら××し、△△だったら□□しろ」というように、ある条件で次の行動を振り分けるものです。

この場合、この条件設定が間違ったことによって、正しい買い物ができなかった、というジョークです。

しかし、ここで妻を発注者であるクライアント、夫を受注者である制作会社やシステム開発会社、SIerと置き換えてみると、クライアントの要望を制作会社やシステム開発会社、SIerが実装したら全然要望と違うものが出来上がった、という笑うに笑えない事態が発生します。

こういった事はなぜ起こってしまうのでしょうか？

それは、クライアントの要望を要件定義に落とし込む際に、クライアントと制作会社やシステム開発会社、SIerの双方が、同じ事を話しているつもりでも、実はお互いが全く違う事を考えていた、というのがITの世界では数多くみられるからです。

具体的に今回の買い物を例にみてみましょう。

要望

妻の要望は、先ほどあげたように二つ。

• 牛乳を１つ買ってきて欲しい
• 卵が売っていれば卵も6個買ってきて欲しい

妻のゴールは、この二つです。

これに対し、夫は買い物を成功させるために、買い物に行く前に要件定義をおこないます。

要件定義

要件定義とは、顧客の要望から曖昧な点を除き、システム化できるように明確化することです。

ところが、夫は妻の要望を正しく理解できず、要件定義に失敗してしまいました。

そのため、「牛乳を買う」ことだけにフォーカスしてしまい、「卵を6個買う」というタスクがすっぽりと抜けてしまいました。

基本設計、詳細設計及び開発

要件定義が失敗したために、プログラミングにおける基本設計、詳細設計及び開発についてはそのまま間違った形で行われてしまいます。

この場合、実際に買い物を実行する段階で、正しいルートでスーパーにたどり着き、欲しいブランドの牛乳を手に入れて帰ったとしても、「牛乳を1つだけ購入する」ことや、もう一つのタスクである「卵を6個買う」ということが実現できませんでした。

要件定義で重要な事は？

こういった事態を招かないためには、どのような対策が必要だったのでしょうか？

今回のケースの場合では、夫は要件定義をした段階で、要件定義が妻の要望を満たしているのかを、より具体的な形で妻に確認する必要がありました。

つまり、「今から牛乳を１つ買いに行くが、卵が売っていれば牛乳を6つ買ってくるけど大丈夫？」というように、要件定義で決めた内容を再度妻に確認する、ということです。

WebサービスやWebシステム、基幹システムなど、様々なシステムを導入するプロジェクトにおいて、実際にシステムを構築する上で避けて通れないのが要件定義です。

この要件定義がうまくいかないと、システムを実装する段階で問題が発生して、プロジェクトが最終的に失敗する可能性もあります。

「プログラマーの夫に買い物を頼んだら」という話であれば笑い話になりますが、実際のプロジェクトでこんな事が発生してしまい、訴訟となっていまっているプロジェクトも多数あります。

そのため、発注者であるクライアントは、自分たちの要望が正しく要件定義に落とし込まれているかを必ず確認する必要があり、また受注者である制作会社やシステム開発会社、SIerは、発注者であるクライントの要望を正しく要件定義に落とし込めているかを、クライアントが納得できるようなものを用意して確認をする必要があります。

ここが曖昧なまま進むプロジェクトは絶対に失敗しますので、発注者はプログラマーの妻にならないために、受注者はプログラマーの夫にならないために、お互いに歩み寄りながらコミュケーションを密に行う事が重要です。

ただし、そうはいっても発注者のクライアントは受注者側から出てくる要件定義書を読み込んで理解するためには、かなりの知識を付けていく必要もあり、なかなかこのあたりが一朝一夕には上手くいかないので、その知識習得の時間を買うためにお互いの通訳としてコンサルタントを入れるのもおすすめです。

スポンサードサーチ