はじめに

有名なプログラマージョーク

プログラマの夫に「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」と言ったら、夫は牛乳を6パック買ってきた。

プログラマーを笑う自虐ジョークとして使われがちですが、
良い題材なのでこれを元に要望 と 要件定義 と 設計 と 実装 の違いを纏めてみましょう。

下記、それぞれのフェーズの原理原則論を記載します。

各フェーズの原理原則

1. 要望

顧客(妻)の要望 を書き出す：顧客の仕事

• 買い物に行って牛乳を1つ買ってきて、卵があったら6つお願い。

2. 要件定義1（ダイジェスト）

顧客の要望から曖昧な点を除いて復唱する：PMの仕事

上記だとプログラマーの夫は牛乳を6本買ってきました。夫は妻に、要望をより具体的な形で復唱する必要があります。
ここでは、卵を6つ買ってくるという事を確認することで事故を防ぐことができます。

• 牛乳を1本買ってくる
• 卵があったら卵を6個買ってくる

3. 要件定義2（詳細）

顧客の要望をより具体化して復唱する：PM(プロジェクトマネージャー) SE(システムエンジニア)の仕事

プログラマーの夫は賢いので、先程の要件定義1(ダイジェスト)だけで妻の望みの結果を出すことができます。
しかし、ミッションクリティカルなお使いで一つでも間違ったら死を意味する夫婦関係の場合、以下のように詳細な定義を与えてやり、妻に確認を取る必要があります。

• 牛乳1本の容量は1Lであるとする
• 牛乳とは品目で牛乳となっているものを示し、低脂肪乳などの乳飲料を含まない
• 購入する牛乳の乳脂肪分は○%以上である
• 卵とは鶏卵の生卵のことを示し、うずらの卵等、他の動物の卵を含まない
• 牛乳があったら1本買ってくる
• 卵が6個以上あったら6個買ってくる
• 卵が5個以下しか無かったらあるだけ買ってくる
• 卵の購入最小単位が定められている場合、最小購入単位の倍数で6個を超える最小の数だけ購入する
• 牛乳の値段がある価格より高い場合は牛乳を購入しない
• 卵の値段がある価格より高い場合は卵を購入しない
• 牛乳の消費期限がある期間より短い場合は牛乳を購入しない
• 卵の消費期限がある期間より短い場合は卵を購入しない
• 合計金額が予算オーバーの場合は牛乳だけを購入する
• (牛乳が無いとできない料理を想定している場合)牛乳の購入条件を満たさない場合は卵も購入しない
• 牛乳の購入に至らなかった場合も、販売店のはしごはしなくても良いものとする

4. 設計

要件定義を元に具体化する：SE(システムエンジニア)の仕事

夫がより賢い場合、自分でお使いに行かずに、ロボットに指示を的確に伝えることでお使いを実施しようとします。
このとき、ロボットによりわかりやすい言葉で上記の要件定義を書き換えます。これを設計といいます。
この設計段階で何らかの不足事項が発見された場合には、要件定義を見直します。
多くの場合はこの設計は妻には確認する必要がありません。

• 前提条件

• 牛乳の購入に至らなかった場合も、販売店のはしごはしなくても良いものとする

• 牛乳の定義

• 1本の容量は1Lであるとする

• 品目で牛乳となっているものを示し、低脂肪乳などの乳飲料を含まない

• 卵の定義

• 鶏卵のことである

• 鶏卵の中でも生卵であること

• 牛乳の購入条件

• 賞味期限がある一定期間以上であること

• 乳脂肪分は○%以上である

• 値段が一定基準以下であること

• 値段が総予算を超えていないこと

• 店舗に1本以上の在庫があること

• 牛乳の購入本数

• 最大で1本

• 卵の購入条件

• 賞味期限がある一定期間以上であること

• 値段が一定基準以下であること

• 店舗に1個以上の在庫があること

• (牛乳が無いとできない料理を想定している場合)牛乳の購入条件を満たしていること

• 牛乳、卵の合計金額が総予算を超えていないこと

• 卵の購入個数

• 卵の購入最小単位が定められている場合、最小購入単位の倍数で6個を超える最小の数だけ購入する

• ただし、卵の在庫が少ない場合は購入可能な個数だけを購入する

5. 実装

設計を元に実行可能な手順書に翻訳する PG(プログラマー)の仕事

ロボットが日本語の解釈実行をできない場合、ロボットに分かる言葉に翻訳する必要があります。
これが実装であり、プログラミングですが、本質は翻訳作業です。
さらにこのプログラムが正しく実装されたことを確認するテストコードのプログラミングもこのフェーズに含まれます。

まとめると以下の通りです。

• 1. 要望：顧客の仕事
• 1. 要件定義1（ダイジェスト）：PM(プロジェクトマネージャー)の仕事
• 1. 要件定義2（詳細）：PM(プロジェクトマネージャー)SE(システムエンジニア)の仕事
• 1. 設計：SE(システムエンジニア)の仕事
• 1. 実装：PG(プログラマー)の仕事

実際の現場

ここまで書いたのは理想論であり、実際の現場では異なっています。
典型的なのは以下のパターンです。

• 1. 要望：顧客の仕事
• 1. 要件定義1（ダイジェスト）：PM(プロジェクトマネージャー)SE(システムエンジニア)の仕事
• 1. 要件定義2（詳細）：PG(プログラマー)の仕事
• 1. 設計：PG(プログラマー)の仕事
• 1. 実装：PG(プログラマー)の仕事

ほぼ全部PGのお仕事！！

つまり、実装はできないけど設計はできると言う自称PMやSEは実際は設計どころか、要件定義2の詳細化すらやっておらず、PG以下に丸投げをしている現場が数多くあります。
（※個人の観測範囲および感想であり、所属会社を代表する意見ではありません。）

もちろん、細部の設計に囚われすぎると全体の仕事ができなくなるのはわかりますが、その状態でプログラマーは 5. 実装 のフェーズだけやってるただの翻訳者だなんて言うのは恥ずかしいのでやめましょう。

最後に

• 買い物に行って牛乳を1つ買ってきて、卵があったら6つお願い。

という一見なんでもない要望をなぜエンジニアは難しく考えてそのシステム化に莫大な工数を計上するのかという問題に関して少しでも相互理解となれば幸いです。
その答えはエンジニアは顧客の要望にきちんと向き合ってちゃんと考えているからです。