詳細設計書ってあるじゃないですか。

「詳細設計書ってあるじゃないですか。」
「あるね。」
「『必要ですか』って聞かれたんですけど。」
「そう。」
「必要ですかね。」
「何て答えたの。」
「成果物で決めているなら必要でしょう、って。」
「成果物なら必要だね。」
「『じゃあ、成果物じゃなければ必要ないんでしょ』って聞かれて。」
「何て答えたの。」
「詳細設計書で何を伝えたいか決まっているの、って。」
「質問で返したんだ。」
「まぁ、そうですが。でも、質問の意味が解らないし。」
「そしたら。」
「設計する人とコード書く人が同じならいらいですよね、って。」
「質問が変わった気があるね。」
「まあまあ。」
「それで。」
「同じ人なら確かにいらない、って。」
「マジで。」
「はい。」
「とっても限定されている条件下での話、だよね。」
「うーん、そうかも…しれないですね。」
「今のビジネスでそんな条件下、存在するんかい。」
「わからないです。」
「まぁ、知らくても普通かな。」
「あ、はい。」
「何を暗黙の前提にしたかを吐いた方が良いんと違う。」
「外部設計で仕様が明確、外部設計からコードが書けるスキルを持っている…、です。」
「足らないな。」
「足らないですか。」
「足らないね。」
「何がですか。教えてくださいよ。」
「バイバイ。」
「エェェェ。」
「うそうそ。」
「あのね、
　1)顧客の要件、品質が外部設計で明確である、
　2)開発チームは少人数である、
　3)開発メンバのコンテキストが高い、
　4)開発メンバが運用までやる又は運用後のメンテナンスをしない、
何より、
　5)詳細設計以降からリリースまで成果物でも提出物でもない。」
「1)はどうしてですか。」
「なんで設計工程わけてドキュメントも段階的に書いているか、考えればわかるんじゃないの。」
「2)は。」
「100人の大規模プロジェクトでそんな奴ばっかり集められると思ってるのか。あほか、いくら余計にかかると思っているんだ。」
「ですねよー。じゃあ、3)は。」
「技術レベル低い人とのコミュニケーションで忙殺されるくらいなら詳細設計書いちゃうんじゃないの、キミたち。」
「そんなことないですよ、新人教育だってしますよ。4)は。」
「引き継ぐなら、実現仕様をどうやって伝えるんだ、って話だよ。」
「コードを見ればわかる…。」
「そりゃわかるよね。でも、なんでそうコードを設計したのかはわかるのかね。」
「えっと、5)はそうですよねー。」
「そうじゃねーよ、じゃあ、その間顧客が大人しくしているのかって。Webサービスにしたってリリースするまで社内のお偉いさんがちょこちょこ聞きに来るんじゃないの、進捗は、品質は、コストは、って。」
「き、来ますよね。絶対に。」
「作れ、と言っているわけじゃないんだよ。外部設計、いや、要件定義でいきなりコードをデザインしてプログラムできるなら知れが一番いいんだよ。」
「出来る人もいると思いますが…。」
「思うじゃないんだよ、人も数人だろうが、たくさんだろうが居るんだろう。全員ができるかどうか、なんだよ。プロジェクトなんだから。それがプロジェクトで必要なスキルセットになるんだから。」
「全員はちょっと。」
「人だって、出たり入ったりするんだろう。じゃあ、何を使って伝えるんだい。プログラムを作れる製造図面を書いて渡せばいいんだよ。製造図面を自分が引き取ろうが、他人に渡そうがそれも大事なことじゃない。もっとも、それの名前なんて興味はないね。」
「詳細設計いらないって言っている奴はどこまで考えて言っているのかご教授願いたいね。そんな斬新な、あ、ワタシにとっては、だけどね、勉強したいさ。楽になるなら。」
「まあまあ。」
「何の話だっけ。」
「詳細設計書が必要かどうか、っていう話です。」
「詳細設計なんてなくてプログラムが作れて、品質が良いならない方がうれしいね。プロマネとしては。」