基本設計とは？開発での位置づけや書き方の注意点を解説！
基本設計とは、ソフトウェア開発のうち、上流工程と呼ばれる過程で実施する作業です。要件定義と詳細設計の間に位置する作業で、ソフトウェア開発の基盤になる部分を決定します。機能などの概要を決めていく部分であり、その結果がソフトウェアの方向性を決定すると考えてよいでしょう。
今回は、ソフトウェア開発で非常に重要な工程となる基本設計とはどのような作業であり、ドキュメントには何を記載すれば良いのか、またどのように書けば良いのかなどを解説します。
基本設計とは
基本設計とはどのような活動であるか、概要やシステム開発全体における位置づけについて解説します。
基本設計の概要
基本設計は外部設計とも呼ばれる作業で、システム開発において要件定義の内容を具体化する工程です。要件定義ではシステムに求められる内容が大まかに定められているだけであり、このままでは開発ができません。そのため、基本設計において仕様を具体化していきます。具体化すべき内容は多岐にわたり、例えば以下の項目を具体化しておかなければなりません。
- 画面設計
- データ設計
- 業務フロー設計
- 外部連携設計
- 非機能要件
この段階では、システムの全体構成や機能、データの流れなどを明確にします。これにより開発やテストの指針、そして成果物などが明確となるのです。そして、以下の見出しで解説するようないくつもの成果物を作成し、ドキュメントに沿って設計や開発を進められるようにします。
また、単純な機能的な設計だけではなく、性能などについても基本設計で定めることが一般的です。例えば、処理速度が極端に遅いとシステムが使い物にならないという状況に陥りかねません。これを回避すべく、処理速度の目標を定めておくなどします。他にもセキュリティ面を事前に設計しておくなど、基本設計でやるべきことは多岐にわたるのです。
システム開発全体における基本設計の位置づけ
システム開発における基本設計は要件定義と詳細設計の中間に位置するものです。上記でも触れたように、システムの全体像を具体化する工程だと捉えましょう。要件定義で定めた内容だけでは、システムを開発することが難しく、基本設計で必ず具体化・詳細化しなければなりません。
なお、開発工程は基本設計の内容を軸に進められます。そのため、ここでの成果物が開発全体の品質や効率に大きく影響するため注意が必要です。また、ドキュメントを作成し、関係者と合意を取っておくこともポイントと言えます。基本設計で認識のずれがあると、後続の工程で大きなトラブルが発生しかねません。
基本設計における一般的な成果物
基本設計の成果物は、プロジェクトによって変化します。明確に決められているわけではありませんが、一般的には以下のドキュメントを作成しなければなりません。
基本設計書
基本設計書は基本設計フェーズの中核となる成果物です。必ず作成すると表現しても過言ではないでしょう。こちらの資料を軸として、以下で解説する別の資料を参照する流れが基本です。
基本設計書にはシステム全体の設計方針を記載します。システムの目的や概要、システム化の対象となる業務やその範囲などを明記しましょう。ここに記載された内容が後続の工程の基盤となるため、丁寧に検討して記載しなければなりません。
また、システム構成図やデータフロー図なども含めておくと良いでしょう。例えば、Webサーバーとデータサーバーを構築するならば、それぞれの台数や関連性について、基本設計書の中で述べておきます。また、スペックなどもここで記載しておくと、後続の工程で作業しやすくなるでしょう。
他にも、非性能要件がある場合は、基本設計書に記載しておきます。パフォーマンスやセキュリティ、スケーラビリティなど 設計において重要となる要素は明記しなければなりません。
画面設計書
画面設計書は、ユーザーインターフェースの詳細を記載した資料であり、 操作性を確定させるためのベースとなるものです。
記載内容は状況によりますが、主に各画面のレイアウトが記載されます。粒度はプロジェクトによって変化し、ワイヤーフレームやプロトタイプが記載されると考えましょう。場合によっては詳細なものが記載されるものの、基本設計の段階では概要がわかれば差し支えありません。
また、入力項目や出力項目を定義し、ユーザーの操作性を確定させなければなりません。例えば、ユーザーIDとパスワードを入力することを基本設計で定義しておきます。また、検索ボタンを押した際に、どのような内容が出力されるのかを定義しなければなりません。
帳票設計書
システムが帳票を生成する場合は、帳票設計書が必要です。帳票に限らず、何かしらアウトプットする際は、こちらにまとめておくと良いでしょう。
基本的には、帳票の設計書であるため帳票のレイアウトを記載しなければなりません。また、それぞれの項目の詳細事項も記載します。例えば、データベースのどの項目を出力するのか、どの項目をどのように計算して出力するのかなどです。また、条件分岐が必要な場合は、それらについても記載しなければなりません。
他にも帳票を出力する条件などを示しておきましょう。例えば、出力日から1週間以内のデータを出力する、入力された ID に関連するものだけを出力するなどです。他にも帳票がエクセルファイルなのか、Wordファイルなのか、PDFファイルなのかなど 出力形式 についても定義します。
データ設計書
データ設計書はデータの構造や仕様を定義したものです。主にデータベースの設計に向けた基盤となる資料と考えましょう。場合によってはデータベースの定義を含みますが、ここではデータベース設計の段階となる資料とします。
データベースの設計に必要なものであるため、データ項目を定義しなければなりません。データ名や、それらのデータ型、制約条件などを洗い出しておきましょう。もし使用するデータベースエンジンが決まっているならば、その点も考慮して作成しておくと後続の工程でトラブルが生じにくくなります。
また、データ間の紐づけを示すために、論理データモデルも含めておくことが望ましいでしょう。 ER図 などを作成しておけば、後続の工程で直感的にデータの関連性を把握できます。データの整合性も意識することが重要であるため、それらも踏まえて作成していきます。
業務フロー図
システム化対象の業務プロセスを可視化するために、業務フロー図を作成することがあります。これにより、システムの動作と業務プロセスの関係性を明確にできるのです。
作成にあたっては、業務フローを洗い出して、それをフローに落とし込んでおきましょう。事前に業務が明確になっていなければ、システムを開発することは不可能です。フロー図を作成し、その中のどの部分がシステム化の対象であるか明記するようにしましょう。
運用設計書
運用設計書は、システムの開発終了後に稼働する際の運用や保守に関する設計書です。システムは開発して終わりではなく、むしろ開発が完了したときがスタートと言えます。その後の運用や保守についても、基本設計の段階である程度は考慮しておかなければなりません。例えば、システムをどのようにバックアップするかを検討し、定義しておきます。1日に1回バックアップを取るか、週末にバックアップを取るかなど、システムの重要性を踏まえて検討するのです。また、フルバックアップを取るか、差分バックアップを取るかなども検討しておかなければなりません。
他にも、障害が発生した際の対応フローを検討しておきましょう。どのように障害を検知して、誰がどこにエスカレーション するのかを定めておきます。システムによってはサービスデスクなどが準備されているため、それらの役割がどのように働くのかの定義も必要です。
基本設計を進める際の注意点
基本設計を進める際には、いくつもの注意点があります。
要件定義書との一致
最初に、要件定義の内容と一致しているかどうかを確認しなければなりません。基本設計の前提は、要件定義で決まった内容であるため、ここに差異があると大きな問題が生じてしまいます。要件定義の内容を細かく確認し、基本設計と合致しているかどうかを確認しましょう。また、記載されている内容に抜け漏れがないかどうかの突合せも重要です。
もし要件定義の内容と矛盾が生じた場合は、主に基本設計を見直さなければなりません。多くの場合、要件定義が終了した段階で内容が確定されているため、要件を修正することは望ましくないでしょう。既に決まっている内容に即した基本設計に変更すべきです。
他にも、要件定義では洗い出されていない部分が基本設計に含まれるかもしれません。これらの取り扱いは状況によりけりですが、基本的に含めておいてよいでしょう。ただ、どの要件に紐づく内容であるのかは説明できるようにしておくことが望ましいです。
実現可能性の評価
基本設計の段階で実現可能性についても評価しておくことがポイントです。具体的には、現実的に実装可能な設計であるのか評価しなければなりません。
例えば、画面の表示速度が1秒以内と記載されていたとします。現在のリソースなどを踏まえて、このような設計が実現可能であるかどうか評価すべきです。基本設計では1秒以内とされているものの、現実的に3秒ほどかかるならば、設計内容を見直さなければなりません。また、そもそも基本設計の段階で明らかに無理な部分があるならば、要件定義に立ち返ることも考えるべきです。
なお、この段階で実現可能性を評価しておかなければ、詳細設計の段階で手戻りが生じてしまいます。工程が後になればなるほどインパクトが大きくなってしまうため、基本設計の段階で可能な限り評価しておきましょう。もし、机上での評価が難しい内容であれば、実際にデモ機を作成するなどして、確認しなければなりません。
エンドユーザ視点での確認
基本設計書の内容はエンドユーザーがレビューすることも多くあります。そのため、エンジニア目線ではなく、エンドユーザー目線で記載することも心がけましょう。どうしてもテクニカルな内容はやむを得ませんが、可能な限り配慮すべきです。
例えば、画面設計書はエンドユーザーが実際に確認する機会が多い資料です。どのようにボタンが配置され、どのボタンをクリックして画面遷移するのかどうかなどを評価するでしょう。このような資料は誰が見ても直感的にわかりやすく記載することが望ましいのです。
とはいえ、各種資料のフォーマットは事前に定められている場合があります。この場合は、エンドユーザー向けの配慮に限界があるため、可能な限りという点を押さえておきましょう。
まとめ
システム開発における基本設計の概要や、具体的な成果物などを解説しました。要件定義に次ぐ重要な作業であり、システム開発の品質を大きく左右する部分です。適切な基本設計がなされていないと、システム全体の品質が下がったり、大きな手戻りが発生したりすることになりかねません。
基本設計の品質を担保するためには、紹介したような成果物を作成することが重要です。これらの成果物について関係者がレビューや承認を実施し、合意形成するようにしましょう。ドキュメントを残しておかなければ、認識差が生じた際に水掛け論になってしまいます。
