伝えるを形に。それが基本設計

システム開発の工程は
要件定義⇒基本設計⇒詳細設計⇒製造⇒単体テスト⇒結合テスト⇒ユーザーテスト⇒リリース
という順序を辿ることが一般的です。
基本設計についてお話ししましょう。

基本設計とは

基本設計とは要件をもりもりに盛り込んだ動作を形にした、「これを作りますけど良いですか」とお客さまと認識を合わせるための取り扱い説明書であり、詳細設計へ書くべき必要な処理を洗い出した指示書でもあります。

要件定義からいきなり詳細設計を書くには全体の流れを整理した事前の資料が必要です。
システムの全体を俯瞰し、処理の流れを整理し、お客さまと意識を合わせるようなクッション的な工程がこの基本設計です。
例えば野球でいえば試合前のルールやサインの確認、ポジションや打順の決定などの試合を臨むうえで全体の意志を共有するようなものです。

基本設計は取り扱い説明書

基本設計はシステムを利用するユーザが見て触る部分の表示や動作を具体化します。

どこで何が表示するのか、入力はどうチェックされるのか、ボタンを押すと何が起きるのか。お客さまの要件をこの様に満たしましたよ。という部分をフィクションではなく、論理的なノンフィクションで書くことによって、要件定義での頭の中のイメージが、目に見えて手に入れられる具体的なシステムのイメージとなるのです。

基本設計のヒヤリングでこれが欲しかったんだよ。と言ってもらえるようにするには、機能性が高いことはもちろんですが、お客さまに伝わらなければならないのです。
表現を平易にする。設計者の独りよがりにならないように書くことが大切です。

全体から詳細へ

書き方で注意すべき点がもう一つあります。学生で色々な文書の書き方を学ばれた方には改めてお伝えするほどではありませんが、設計書の描き方としてシステム全体を俯瞰する表現から、徐々に細かい部分へと書いていきます。

基本設計で作成する資料は様々にありますが、基本的な資料の参照する順番として、
システム構成⇒業務フロー⇒画面一覧と画面遷移図⇒画面設計書⇒項目定義
と書いておくと、情報が取り出しやすいし、お客さんへも分りやすく説明できます。

そして情報の流れが可視化されて、詳細設計で有用な資料となるのです。

基本設計は詳細設計の指示書

基本設計は要件定義で決めた要件をこのように盛り込みましたよとお客さまに提示するための資料と同時に、後ろの工程、詳細設計書につなげるための資料でもあります。

どのボタンがどの処理をするのか。バッチは何が必要か。
処理の一つ一つを洗い出して、どういう処理かを文書にします。
この処理一つ一つに対して詳細設計書は実装に近い処理にかみ砕いていくことになります

処理の描き方の粒度に注意

あまり細かく書きすぎて詳細設計書で表すところを書いてしまうことがあります。これまでの経験で一番多いのが、データベースへの読み取り情報SQLを作りこんでしまうのです。

基本設計は文章でSQLの内容を表現すると、基本設計は文章で、詳細設計はコードでと二重管理となってしまい、それを嫌って、基本設計でコード化したSQLを書くことがあります。

新規作成時には問題ないですが、後々改修で別の人がこのSQLは何をやっているのかをコードから読み取ることになり、工数の増加の一因になります。

システムの規模にもよりますし、新規作成の工数が増えることになりますが、処理を説明する手間を惜しんではいけないと思います。

基本設計とはプレゼンの資料作り

基本設計は二方面、要件定義と詳細設計の両方に理解を求めるプレゼンの資料を作る様なものです。
お客さまが理解して、かつ詳細設計も進められるものです。

他の工程に比べて特に伝わりやすさを常に求め続けられるのがこの基本設計になります。

システム開発プロジェクトに携わる人にとって幸いとなりますように。