レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

基本設計で、実装技術を意識してはいけないという呪縛

基本設計書は、顧客が見るから実装技術を意識してはいけない。

と、昔から呪文のように刷り込まれていたけど、


これ、、呪いが掛かってる。

基本設計で実装技術を記述するのは違うでしょうけれど、

基本設計で実装を意識して設計してはいけないということではない。


のに、やたらと実装を無視するように、囁かれてる気がしますね。



たしかに、顧客に見せる資料に、「HttpRequestオブジェクトが・・・」とか
「Transaction Isolation Levelは ”Serializable”で。」とか書かれてたら
顧客を混乱させるから駄目でしょうけど、
顧客に見せなければいいだけで、考えとく分には必要ですよね。


少なくとも、WebアプリケーションではRequestもSessionも意識しなくちゃ設計できませんし
Web層フレームワークも意識するべきです。
また、ほとんどの場合RDBMSの構造も意識しないと設計できません。



ところで、いまだに基本設計書で、DBのクエリを書くのに、

[取得元テーブル]
顧客テーブル [結合] 受注伝票
[結合条件]
顧客テーブル.顧客ID = 受注伝票.顧客ID
[絞込み条件]
受注伝票.受注No =画面の受注No

という記述が根強く存在してゲンナリします。



解決策は、

こんなの書かなきゃいい。

ですが、

設計書に書かなかったらレヴューできないしお客さんからOKもらえない。

といわれてしまいます。


あんな日本語SQLを、お客さんが見てレヴューできるわけないとも思いますが、
それに対する解決策は

これぐらいの検索なら実装して見せたらいい。

だと思います。


アプリ画面で見せるのが最良でしょうけれど、

無理ならSQLをコンソールで叩いた結果で良いでしょう。


顧客のためを思って書いた設計書なのか、

来るべき言い訳のタイミングのために書いた設計書なのか、


を考えてみると、結構後者も多いのではないでしょうか。


顧客のためを思うなら、設計書の記述としては

ボタンが押されたら受注データを検索。
※詳細は、添付のSQLの実行結果を確認。

で、よいかと。