実装のための設計書を要件定義だと解釈すると、現場で機能しない理由が透けて見える

「上流工程」でユーザと要件定義するとき、ユーザと開発者が何回も会議したりして共同で作っていきますよね。ユーザが一方的に要件定義書を作るわけじゃないですよね。

プログラム設計書を粒度が小さい要件定義だと解釈すると、設計者による一方的な設計書があればプログラムが出来るはず！って辺りが矛盾する。自分に課せられた仕事は相手と調整の余地はあるが、他人に依頼する仕事は調整は認めないなんてね。

だからこそ、設計者による一方的な設計書が妥当だと判断する基準の一つが設計者のプログラム技術の有無だろう。「それはできません」「いやできるでしょ」「それならお前がやってみろ」メソッドへの設計者側の武器がプログラム技術となる。

…プログラム設計書は、プログラマがプログラムの解説資料として作るのか、「上流」担当者がプログラマに指図書として作るのか、もちょっと混乱してるような。前者なら仕様書っていう呼び方もある。設計書は後者と解釈するのが妥当な気はする。

ちなみに、API仕様ならjavadoc等としてソースに埋め込むのが主流じゃね？ソース読めない（読まない、ではない）のにjavadocなら読めるって人も聞いたこと無いけどね。

いずれにせよ、プログラムに限らず、お仕事の依頼ってのは依頼先との調整をしないと駄目ってこった。一方的な「指示」で、他人が思い通り動くかっつの。