基本設計は大切だ、という話です。また、高いスキルを必要とする工程です。基本設計をきちんと出来れば、エンジニアとして一人前と言っても過言ではありません。重要かつ難易度の高い基本設計の品質が、プロジェクト成功の鍵を握っています。
基本設計の目的は何でしょう？私は2つあると考えています。
① 詳細設計のインプット
基本設計は詳細設計の前工程ですから、当たり前の話ですね。しかし、この当たり前が意識出来ていないことが意外と多いのです。詳細設計で遅延など問題が発生することがあります。原因は何でしょう？よく、詳細設計担当者のスキル不足で片付けられることがあります。果たして本当でしょうか？そのようなケースでは私の経験上、基本設計の品質が悪いことの方が多いです。例えば、基本設計にAとBを区別すると書いてあるのですが、区別の方法が書いていなかったりするのです。方法が書かれていなければ詳細設計は出来ません。詳細設計は、基本設計ほどの高スキル者でなくとも実施可能であるべきだと思います。その前提で、十分なインプット情報を充実させる必要があります。
② ユーザーと仕様を握る
ユーザーは要件を出します。その要件が、システムに確実に実装されていることをユーザーに確認してもらい、承認を得る必要があります。つまり、システムに詳しくないユーザーが理解できる表現になっていることが肝心です。そして、要件定義書と整合性が取れていること。基本設計をやる中で、要件を100%実現するのが難しいと気づき、ユーザーと要件変更の調整をし合意したとします。そんな時は、要件定義書も修正してもらう必要があります。
基本設計の品質が悪く①の目的が達成出来ていないケースですと、次工程の詳細設計で苦戦することになりますが、早い段階での問題判明であり、まだマシですね。辛いのは②の目的が達成出来ていないケースです。ユーザーとの認識相違は、テスト工程にならないと判明しません。ユーザーがテスト結果を見て、何か違うぞ、と気づくのです。
テスト工程はシステム開発の後半戦。サービスインまで、わずかな時間しか残っていません。このタイミングでの認識相違。ユーザーは修正してほしいと言い、開発側は修正していたら間に合いませんと言います。以前お話した変更管理のスキームで上手く収まれば良いのですが、サービスイン直前での問題判明。感情論で、言った言わないで揉めることも想定されます。
基本設計は本当に大切な工程です。十分な期間を確保し、きっちり対応すること。開発側だけで完結させず、ユーザーに確認してもらう期間も確保することが肝心です。
途中で出てきた変更管理については、この記事で説明しています。参考になればと思います。
