はじめに
システムを開発する際に、要件定義の後におこなう作業が基本設計です。
※ここでは基本設計と呼ぶことにします。
※プロジェクトによって呼び方も変わることもあります。
何を基本設計のフェーズで整理をすればシステムの実現ができるのか、
また、何を誰に伝えるための設計書なのか、
自分の経験をまとめて次世代の足しにするのが目的です。
基本設計の難しさ
基本設計は難しい…
昔々、プログラマー上がりの私はとにかくひたすら処理を書いた。
もちろん、そんな設計書が基本設計書の要件を満たしているわけもなく
お客さんからは何言ってるのか分からないとリジェクトされた。
もう一人はプログラミング経験が無く上流から入った人が居た。
きれいな絵を使い、どんなシステムであるべきかがきれいに書かれていた。
お客さん受けはもちろん良かった、でも、開発チームからは具体的に何をしたらいいかわからないとリジェクトされた。
難しさの根本は、お客さん、開発チーム双方が同じ文書を読むと言うこと。
つまり、お客さんという文化と、開発チームという文化の双方の翻訳機にならなければならないと言うことだ。
もちろん、双方の共通言語なんてない。
でも、長い々時間設計を通して何となくわかったことは、次の二つの観点がクリアされた設計書を作成すると、それなりに通じたという事実だ。
お客さんの知りたいこと
お客さんは、RFPや要件定義書としてどんなシステムが欲しいかは知っています。
しかし、どうすれば実現できるか、具体的なイメージは持っていません。
- どんなシステムなのか視覚的に納得したい。
- 本当にこのシステムがあればちゃんと業務がまわるのか確認したい。
- 作業風景はどうかわる？余計な仕事は増えない？
今している仕事がどう変わるのか知りたい。
開発チームの知りたいこと
その設計書に開発するに必要な情報が網羅されているのかが気がかりです。
私がプログラマーの時は特に以下の情報があれば何とかしていました。
- システム開発の基本方針
- 論理データ設計
- データ状態遷移図
- 画面/機能遷移図
- 画面開発方針（デザイン、動作、データとのマッピング）
- 他の連携システムの情報や、インターフェース
何を書こう
いろいろと、試行錯誤を繰り返した結果今はこんな章立てで設計をしています。
大風呂敷を広げてしまいそうなので、一旦章立てをあげてそれぞれ説明する形式にします。
要件定義の繰り返し見たいなものもありますが、要件定義自体がないお客さんなんかもたまに居るので章立てにいれています。
要件定義があれば、要件定義参照として終わりです。
章立ては以下を開いてください。
基本設計の章立て
- システムの目的
- 業務フロー
- システムの対象領域の定義
- システムの全体概要
- 他のシステムとの連携など含め
- システム全体のUIルール
- システム全体の共通ルール
- 機能一覧
- 機能遷移図
- 各機能単位の設計
- 画面設計
- 帳票設計
- バッチ設計
- その他
- データ設計
- データ定義(論理/物理)
- ドメイン定義
- ERD(Entity Relationship Diagram)
- DFD(Data Flow Diagram)
- コード設計
- シーケンス設計
- 他システム等とのインターフェース設計
- メッセージ設計
- 方式設計(インフラ等)
- 運用設計
- バッチなどスケジューリングされた運用
- 定期運用されるべき物
- 運用フロー
一件多く感じるでしょうが、これがそろわないと私の経験では設計として成り立ちません。
そして、開発チームは全て読破する必要がありますが、お客さんに全てレビューする訳ではありません。
何をどこまで誰に説明するかは、確章立ての説明で記載します。
だれに向けて書くか
基本設計はお客さんと、開発チーム双方が見る設計書であることは最初に伝えまっした。
しかし、お客さんといっても実際にシステムを使う「エンドユーザ」、システムを運用する情報システム部（ない場合は運用を請け負うこともある）など、役割によってレビューする範囲は変わってくる。
今後の説明では以下の図を基に説明していきます。
役割については、こちらも参考にしてください。
さいごに
今回はここまでにします。
以降は、各章の記載内容と、レビューのポイント、開発者の何に役立つのかを記載していきます。
コメント