開発工程の中の基本設計の説明です。
１．要件定義との違い
基本設計のINPUTは要件定義書です。要件定義書がユーザーの言葉で記載されているのに対して、基本設計書はシステムの言葉で記載されています。
要件定義との大きな違いは、ユーザー部門のレビューを受けるかどうかです。
基本設計は基本的にユーザー部門は関わりません。事業会社のシステム部門やシステム子会社がレビュアーになります。
ところがベンダーの考える開発工程は、以下のように定義しているケースが多いです。
要件定義：業務フローや機能一覧、主要画面の入出力項目を決定
基本設計：画面や帳票レイアウトを決定
つまり基本設計もユーザー部門の参画を前提としています。
たいていのベンダーはこの進め方でプロジェクトをはじめようとしますが、私は毎回それを却下しています。この進め方で上手くいくこともあるのかもしれませんが、ある程度の規模の会社では、この進め方では以下のような理由で炎上します。
①ユーザーは業務フローなど理解できない
「業務フロー」と呼んでいますが、あくまでもシステムのドキュメントです。ユーザーは普段、業務フローなんて作らないので、このドキュメントを見ても自分たちの業務をイメージできません。
ユーザーが自分ごととして見れるのは、画面や帳票レイアウトです。画面があってはじめて自分たちの業務がイメージでき、具体的な要望がでてきます。これを基本設計でやると手戻りが多くなり、ユーザーの要望も叶えられないケースも出てきたりして、関係が悪くなります。
要件定義で最初にやるべきことは、画面や帳票のレイアウトなのです。
②ユーザーは忙しい
ITエンジニアの都合で要件定義と基本設計の両工程に参加を依頼しても、ユーザーはシステム開発が本来業務でないので、長期間、打合せに参加することを嫌がります。しかも最初にやるのが業務フローとか機能一覧といった自分たちに馴染みの無いドキュメントばかりだと、肝心の基本設計に入る頃にはモチベーションが相当落ちています。
③ユーザーは要件定義と基本設計の違いなんて分からない
工程を分けると、ユーザーはどこで何を決めればいいのか迷います。要件定義でいろいろ要望を出しても、「それは基本設計で決めます」と言われてしまうと、どのタイミングで要望を出せばいいのか分からなくなってしまい、基本設計に入る頃には言おうと思っていた要望を忘れてしまい、基本設計が終わってから、最悪のケースでは受入テストになって思い出すといった事態になります。
要件定義：ユーザー部門と決めること
基本設計：システム部門と決めること
という定義にすることで、早期に仕様をFIXすることができ、ユーザーにとって分かりやすいプロジェクトになります。
プロジェクトの一番の目的はQCDではなく、顧客満足です。ユーザーが、あの人たちに頼んで良かったと思えるようなプロジェクトの進め方をすることが重要です。
２．基本設計でやること
要件定義は、ユーザー部門を相手にするので
・画面レイアウト
・画面遷移図
・帳票レイアウト
・ビジネスルール
といったユーザーの目に見える部分を決めるドキュメントを作ります。これらを総称して要件定義書と呼びます。
それに対して基本設計は、システムのプロだけで進める工程なので
・テーブルの論理設計
・ER図やCRUD
・画面や帳票の入出力設計
・機能分割
・ビジネスルールのシステムロジックへの置き換え
といったシステムの作りの概要をまとめるドキュメントを作ります。
画面や帳票、ビジネスルールといった情報を元に、必要な機能を定義して、テーブルを設計します。画面で入力した情報をどんなテーブルに格納して、格納した情報をどんなタイミングで更新したり画面に出したりするのか、またテーブルに入出力する際に適用するビジネスルールをシステムのロジックで表現し直したりします。
規模の大きいシステムの場合、全体設計で機能の定義やテーブルの設計を行い、その後、個々の機能ごとに個別の基本設計を進めます。
３．基本設計の例
紙で回付している稟議書のワークフロー化の要件をもとに基本設計を考えてみます。
要件
「社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能」
「機密は、稟議を回付した人だけが参照、ダウンロード、印刷が可能」
「厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可」
要件定義で階層構造化した組織のテーブル、ユーザーのテーブル、権限のテーブル等を設計します。
また稟議の機密区分の違いによる権限の違いをどのようにコントロールするかを考えます。
ユーザーが稟議を検索した際、
・ユーザーが回付ルートに含まれる稟議
・ユーザーと同じ部署のユーザーが起案して、かつ、機密区分が社外秘の稟議
この２つのロジックで検索をすれば、参照の要件を過不足無く満たすことができます。
では、この２つのロジックをどのように実現すれば良いでしょうか？稟議のテーブルにユーザー情報や組織情報、機密区分を持たせることで、対象の稟議を過不足無く抽出することができます。
ここでもう一歩、考えなければいけないことは、稟議のテーブルに本当に組織情報を持たせて良いかどうかです。社員マスターにはユーザーが所属する組織情報があるので、稟議のテーブルに組織を持たせなくても、テーブル同士を結合することで、要件を実現することはできます。これがテーブルの正規化の考えで、一般論としては正規化することが望ましいと言われています。
稟議のテーブルに組織情報を持たせるかどうかは、異動時の扱いで決めることができます。
例えば総務部で起案した稟議は、他の部署のユーザーからは参照することはできません。もし稟議のテーブルにユーザーの組織情報を持たせず、社員マスターから組織情報を参照する設計とした場合、どうなるでしょう。
極端な話し、総務部で起案した稟議に携わった人たちが全員人事部に異動してしまった場合、それらの稟議は後から総務部に異動してきた人たちから参照することができなくなってしまいます。
これが稟議のテーブルにユーザーの組織情報を持たせていれば、起案時点の組織情報を持つことになるので、異動による影響を受けなくてすみます。
基本設計は、このような感じで、自分の頭の中でシステムを動かしながら設計をしていきます。
【振り返り】
今回は基本設計の説明でした。次回は詳細設計の説明をしていきたいと思います。
