発注主は業務要件で話しをします。設計者はそれを聞き取って、製造に回します。
それを、要件定義、外部設計、内部設計、製造過程といいます。といまさらな話です。
この過程はスパイラルにせよWaterFallにせよ、変わることはありません。
ところが、要件定義を細かくしたものが、外部設計。 外部設計を細かくしたものが、内部設計と捉えている人がいます。
外部設計を細かくしても製造は出来ません。含有関係でもありません。OOP型では顕著ですが、従来の手続き型でも、部品化を進める面でも、そのようにはならない筈ですし、別の視点で捉える必要があります。
家を作る時、6畳間、8畳間が欲しいというのは、要件句であり、外部設計書では、部屋のサイズが表に出てきます。
しかし、材料の切り出しや細部の設計図には、空間のサイズは隠れます。
６畳間という部屋は、柱と壁を実装した結果できる空間であり、設計図は、柱と壁の設計図はありますが、６畳間という設計図は存在しません。
「内部設計書は、外部設計書を詳細にしたものだから、外部設計書に登場する用語はすべて、内部設計書に登場するはず。登場しない語句をみつけたら、突き返す」と主張されるレビュアーがいらっしゃいます。彼と話していて、上記の話を思い浮かべて、違うだろうと感じたのです。彼曰く、「外部設計書で製造本数は確定する。工数見積もりの根拠になりうる資料である。」
うーん。今のご時世にその主張でプロジェクトを進めるのは、どうでしょう。
たとえば、照会画面と更新画面の項目内容が同一で、入力可否程度に差しか無ければ、使い回すか、Baseから継承するように、実装設計しませんかねぇ。
実装知識がないと、トータルの製造工数を出しにくくなっていますが、設計と開発を分業化するという視点でみると、後退していると言う主張も成り立つようです。
一人の開発者としては、もっと製造知識を持って欲しいのですが、「知らないと適切な設計ができない」というのは、進歩がないと言われると、そのような気もします。その面は発展途上なのかもしれませんね。