本当の基本設計って…なんだろう？

基本設計書ってどこまで書けばいいんですか？何を書けばいいんですか？

自分が思う基本設計

最近、結構まじまじで判らない。自分の認識では、以下のような情報を含む資料が「基本設計書」だとおもっている。

納品先の担当者でも判る機能の説明や挙動説明が記載されている。
利用者の目に触れるところ、外部システムと連携するところなど、「外殻」の要件を確実に記述している。
不要であればプログラマチックな記述は避ける。

設計関連資料、特に要件定義書や基本設計書は、物作りのガイドラインであると同時に、注文主との取り決めを記述したものにもなるので、自らの首を絞めるようなことをかくべきでは無い。出来ないことやコストオーバーすることを書いても後でとばっちりくらうのは同じ開発チームの人間。最終的に細かい部分を詰める必要はあるにしても、まだ詳細がわからない、実装方法等によって何通りもの手法が考えられる部分を、実際に実装を行わないような人が「えいやっ！」と決めるべきでは無い、と思ってる。

でもどうやら違う場合が多いみたい。ふぅ。

具体的には？

たとえば、業務で使う製品コードが2系統あって、それを入力して部品情報を一覧表示するような機能が必要であるばあい、「こういう機能が必要」は要件定義の話だとおもう。で、基本設計書には「こういう機能を実現するには」をもれなく書く。

たとえば、

製品コードは2系統ある。
それぞれのコードは入力欄にキーボードで入力されるが、桁数の上限を超えられないようにする（上限はどちらも3桁）。
2系統のうちどちらで検索するかは選択欄を設けて事前に選択できるようにする。選択が行われないと、検索ボタンは押せない。
検索結果は、画像と下記の項目を画面上に並べて表示する（該当件数は必ず1件になる）。
該当するデータが無い場合は「指定されたコード###に該当する製品情報がありません。」とメッセージを出す。

みたいなレベルでいいんじゃないかと。このレベルまでを表や文章、箇条書きや図を用いて説明すれば、まずはぶれない基本部分の合意が得られるはず。もちろん納品先がエンジニア集団だったり顧客側についているシステム開発部門であればもう一歩踏み込んでもいいだろうけれど。

ぐだぐだになる例

で、こういう基本設計書を書くとお客さん側も自分たちの実装担当者もグダグダになる。

製品コードはコード番号マスター「CD0020」から取得して選択可能とする。
それぞれのコードはTextCode.Textに入力。Text.LeaveイベントでLengthチェックを行う。（上限はどちらも3桁）。
コード種別はラジオボタンで選択する。
検索結果はGridにImageMasterテーブルのPROD_IMGカラムの内容から取得した画像と、コードデータを表示する。
該当するデータが無い場合はメッセージID IM00049を表示する（ボタンタイプ: OK、パラメータ0=検索キー）。

ぐだぐだになってしまう理由は大きく2つ。

お客さんは正直、何が書いてあるのか、それが正しいのか分からない。
開発者は正直、自分たちで決めたいところが変に決まっていて、作業しづらい。

いやもうそれ詳細設計だろ。そして、コントロール名とか基本設計段階で勝手に決めんな！変な命名すんな！そして、細かく書いている割には、画像データを取得する際にどういう手順を踏むか、とか、ほかのイレギュラーケースはどうするとか、記載された以外のメッセージを出すことになったらどうするとかってのが考慮されていない。下手すると「実装段階でメッセージ追加になったので、基本設計まで戻ってメッセージ設計書を書き換える」なんてことにもなる。

最悪、クラス構成とかメソッド名まで書いてあったりして、「基本設計に書いてあるクラス構成やメンバー構成に合わせて実装する」なんてことに。だから、詳細設計なる資料はまともに書かれなかったりする。なぜって、必要無くなるし、そして何より、実装担当者は自分で考える機会をそぎ落とされて、やる気ロストだし。

というわけで、難しい。実際こういうのある。まじで。書いてる人はよかれと思ってやってるのかもしれないけれど、コボル時代やVB5.0初心者時代の知識で、基本設計書段階で、今のプログラミングに踏み込んだ記載とかされても正直迷惑なのです。やめていただきたい＞年配者＆その下僕と化した後継者たちよ。