2011年05月03日

設計書には業務理由を明記すべき

多くの設計書では、何をすべきかがシステム屋目線で記述されています。
例えば基本設計書、私のローカルな言葉では、「業務機能 機能処理フロー設計」、「業務機能 詳細設計」にあたりますが、これらは全て、なぜそれをしなければならないのか、顧客の業務の理由を明確に記述すべきだと考えます。

理由は主に下記4点です。
1. 顧客が機能の必要性を理解出来ないこともあります。
もしシステム開発に対して積極的な姿勢でない場合、レビューを実施しても疑問も感じずスルーしてしまいがちです。
その後、バグがあったとしても、お互いにレビューした/瑕疵だと強く主張することになります。
そういうリスクはなくなりませんが、多少は顧客にも機能の必要性を理解しやすくしたいと考えています。
2. テスト仕様書を作成する際に、業務上のあり得る/あり得ないも含めてシナリオを作成しやすくなります。
基本設計書フェーズでは結合テストやさらに上位のテストが実施されているはずです。
このタイミングではホワイトボックスやブラックボックスというよりはむしろ、より業務に近いシナリオベースでテストが記述されることも多いと思います。
よって、業務理由が記述されていれば、このシナリオの妥当性が分かりやすくなります。
3. 後任の担当者が理解しやすくなります
後から入ってきた担当者は業務も知らない、何も知らないケースが多く、それなのに担当に割り当てられます。
その際の教育負荷の軽減につながります。
4. 保守業務が多少楽になります。
あとから見たときに、なぜこのような実装になっているかがわかります。
よって、業務が変わっとしても実装の影響等が分かりやすくなります。

設計書への記述としては記述する範囲が狭くなりますが、2段組がベストです。
左に設計、右に関係する業務やなぜこうするのか、業務的な理由、システム的な理由、資料へのリンクや説明や議事録のパスなどが記述されているのが良いと考えます。
こうすると設計に時間がかかると思われます。しかし、その方があとの工程や引き継ぎが楽になります。
posted by Kiruahさん at 09:17| Comment(0) | TrackBack(0) | ノウハウ
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/44688961
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック