基本設計の意味と課題の解決方法を紹介！仕様書と要件定義の違いとは？
基本設計はシステム開発に欠かせない
この記事では、SIerでのシステム開発において欠かせない「基本設計」をメインに見ていきます。
開発プロジェクトに携わるエンジニアは、要件定義・設計・実装など各フェーズで何が行われるのかを正確に理解する必要があります。
設計をメインとするエンジニアもそうでないエンジニアも、幅広い知識を身に付けておくようにしましょう。
情報システム開発の流れをおさらい
開発フローを押さえておくことは基本設計・要件定義などの言葉が理解する上で大切です。
各フェーズについて、改めてチェックしていきましょう。
要件定義
要件定義のフェーズでは、発注元であるクライアントの希望をまとめていきます。
「どういう機能を持った新システムを求めているのか」をヒアリングするため、コミュニケーション能力が大事になってくるのが特徴です。
＜関連記事＞
要件定義の意味と必要性を徹底解説！必要な基礎知識とスキルとは？スムーズな進め方と確認すべき重要なポイント3点も紹介。
基本設計
要件定義で決まった内容を振り返りつつ、開発するシステムの全体像・概要についてまとめていくフェーズです。
顧客の目で見える部分の工程を設定していくことから、「外部設計」とも呼ばれます。
「プログラムをどのように配置するかを検討する段階」と捉えても良いでしょう。
詳細設計
基本設計ではシステムの大枠を決めたのに対し、この詳細設計フェーズでは細部を詰めていきます。
顧客の目に見えない部分を設定していくため、「内部設計」と呼ばれることもあります。
詳細設計書は開発エンジニア向けに作るので、専門用語などが多くなっているのが特徴です。
＜関連記事＞
詳細設計とは？詳細設計書の書き方を徹底解説！成果物の作成方法や記載すべき項目は？内部設計や仕様書との違い・サンプルも紹介
プログラム実装・単体テスト
基本設計・詳細設計で生まれた設計書（ドキュメント）をもとに、エンジニアがプログラム作成を行なっていきます。
上の設計フェーズで生産された設計書通りに実装されていくため、設計書の質はとても重要です。
全ての完成を待ってからのテストだと細かい修正に対応できないため、実装と並行して「単体テスト」も適宜行われます。
結合テスト
単体テストがクリアできたら、設計書通りにプログラムが組まれているかを検証します。
不備のあった箇所は適宜修正していくことになります。
結合テストの後に「受入テスト」を行い、問題点がなければクライアントに納品して完了です。
要件定義のポイント
システム開発プロジェクトの冒頭で行われる要件定義について、重要なポイントを押さえておきましょう。
機能要件を掴む
クライアントが「こういった機能が欲しい」と要求している機能が、機能要件にあたります。
要件定義を行う際は、まず機能要件を明確に掴まなければなりません。
コミュニケーション力が欠かせない
クライアント側の担当者は、必ずしもITに詳しいとは限りません。
「どういった機能があれば良いのか」をうまく言語化するためのコミュニケーション力が必要になってきます。
ITエンジニアと聞くと「ITの技術力・専門知識の量」ばかりクローズアップされがちですが、SIerエンジニアはコミュニケーション力も欠かせない要素です。
SIerの就職活動においても、他の業界と同じくコミュニケーション力が重視される傾向にあります。
非機能要件
要件定義で決められるのは、”機能”だけではありません。
運用性やセキュリティ面など、機能に依らない部分の事柄を「非機能要件」と呼びます。
これも要件定義で定められていきます。
要件定義で失敗してはならない
要件定義はいわば「プロジェクト全体の道標」であり、ここで方向性を誤ってしまうと最終的な成果物も希望からずれた物になってしまいます。
後の工程で軌道修正を測ろうとすると該当フェーズのエンジニアの負担が重くなり、成果物の質も悪くなるでしょう。
要件定義があいまいな結果になることだけは避け、綿密な意思疎通をクライアントと図っていくべきです。
仕様書と要件定義の違い
仕様書とは？
仕様書は「何のシステムを作るのか」を明らかにした書類のことで、「要件定義書」ともいえます。
要件定義のヒアリングだけではシステムの内容として曖昧なままなので、仕様書に起こして明確化します。
要件定義の結果として仕様書が生まれる
このことから、仕様書は「要件定義を踏まえて作られる書類」であると分かります。
両者は確かに別物ではありますが、全く関係性のないモノ同士というわけでもありません。
要件定義書に何を書けば良いか
ここで「仕様書=要件定義書」に焦点を当て、書類作成の際に盛り込むべき内容について見ていきます。
システムの大まかな概要
「これから開発しようとするシステムは一体何なのか」を大まかに記述します。
ここはある意味で、書類を作成するにあたっての定型表現のようなものでもあり、細かく書いていく必要はありません。
新システム導入の目的・理由
クライアント側は「◯◯という問題の解決」のために、SIerへ新システムの開発を依頼しています。
問題解決という点に主眼を置き、新システムを導入することでどんな効果があるのかを明確にしていくことが肝要です。
「従来のシステムでどういった問題点があるのか」「この新システムにより、◯◯を解決できる」のように書いていくと良いでしょう。
業務フローがどう変わるのか
今日、情報システムを業務に活用していない企業は殆どありません。
新システムを導入すれば、企業が日常的に行なうであろう業務フローも変化していくことになります。
多少の変化は仕方ないとはいえ、「業務がどのように変わっていくのか」をクライアントに前もって説明しておくことは大切です。
機能要件の解説
上述した通り、クライアントが望む機能が「機能要件」にあたります。
非機能要件の解説
クライアントが希望する要件のうち、業務に直結する機能として含まれないものは「非機能要件」に該当します。
仕様書と設計書の違い
ここで、仕様書と設計書（基本設計書・詳細設計書）の違いについて押さえておきましょう。
仕様書は「何を作るのか」をまとめる
仕様書では、「そもそもどんなシステムを作るのか」を定義していきます。
要件定義を踏まえた上で、開発する対象のシステムの理想像を具体化させる必要があります。
設計書は「どのように作るのか」をまとめる
そして設計書は、完成形となるシステムを「どのように作るのか」の工程について定めたものです。
そのため「仕様書→設計書」という順序が正しいと言えます。基本設計書もそのうちの1つと言えるでしょう。
基本設計の大まかな流れ
システム開発全体のフローを振り返ったところで、ここからは「基本設計の流れ」について見ていきましょう。
基本設計には大きく分けて3つの作業が存在します。
要件内容のチェック
要件定義でクライアントとまとめた決定事項を改めて確認します。
基本設計を数名のエンジニアで行なう場合は、各メンバーの認識をきちんと共有しておくことが大切です。
設計する
要件の確認が済んだところで、実際に設計へと移ります。
基本設計に必要な視点・ポイントについては、後の段落で触れていきます。
レビュー
「この設計書で問題ないか」のレビューを行います。
基本設計書としての役割をしっかり満たしているか・読む人によって誤解が生じないかなどの点を注意深く確認することが肝要です。
基本設計に必要な視点とは？
要件定義を経て、基本設計フェーズに入っていきます。ここではどういった視点を持つべきなのでしょうか。
要件定義との整合性
基本設計で決めた事柄は、その後の全フェーズに絡んできます。
完成品が要件定義の内容とかけ離れていては本末転倒となってしまうでしょう。
詳細設計に入る前の基本設計で、「要件定義の項目を満たしているか」を注意深くチェックする必要があります。
実現可能なシステムとなっているか
要件定義でヒアリングした内容を設計書に落とし込んでいくのが基本設計フェーズです。
クライアントにとっての「理想」を明確にできても、実際のシステム開発でそれを「現実」にできなくては意味がありません。
クライアントの希望はできる限り盛り込むべきですが、システムとして実現できるかどうかの線引きはしっかりと行うべきでしょう。
仕様書を作成する段階から、この点について意識しておくことが大切です。
クライアントにとって分かりやすくなっているか
基本設計はシステム開発の根幹を固めていく作業であるため、クライアント側も気になるところです。
開発工程がかなり進んだ後で「自分たちの希望とかけ離れている」と指摘した場合、修正にはかなりの手間が掛かってしまいます。
開発側だけでなく、顧客側にも大きな損害が出てしまうことでしょう。
基本設計フェーズの段階でも、クライアントと綿密な意思疎通を図っていくことが大切です。
担当エンジニアは渉外役として上手く立ち回る必要があります。
基本設計書の作り方
業務フローの明確化
クライアント（ユーザー）が実際に行う業務内容を想定し、その流れを図で表現していきます。
縦軸に管轄部署・横軸に時間を設け、1つずつ流れに沿って記述していきます。
例えば商品発注システムのフローを説明する場合、「申込情報を取得」→「得た情報を入力」→「内容の確認」→「発注」といった具合です。
業務フローはシンプル・明確であることが望ましいとされています。
複雑化しすぎるとクライアントが理解しにくいだけでなく、システムとしての実現も難易度は高くなってしまいます。
システム構成図を作る
システムにおける、ハードウェア・ソフトウェア・ネットワークなどの構成図をそれぞれ作成する必要があります。
ソフトウェア構成では使用OSやミドルウェアの詳細等、ハードウェア構成ではルータやスイッチ等を明確に記述していきます。
機能一覧表の作成
ここでいう機能とは、「システム開発の対象となっている機能」のことです。
満たすべき機能要件を一覧化することで、開発担当のエンジニアが作業内容を把握しやすくなります。
非機能要件もまとめる
クライアントの業務内容に直接は影響しない非機能要件についても、基本設計書でまとめていきます。
そのシステムを継続的に使用することになる側にとっては、セキュリティ面・スピード面なども大切な要素です。
基本設計の更なるポイント
ドキュメントは作りすぎない
基本設計によって「基本設計書」が作られることになりますが、ドキュメントを過剰に生産してしまうことにも注意が必要です。
全ての書類がしっかりとメンテナンスされているなら問題ありませんが、誤った情報が含まれていると開発フローに支障を来します。
重要なのは「質の高い書類」を生産することであり、とにかく大量に作成すれば良いというものではありません。
とはいえドキュメントを一切用意しないのも困るので、どの程度生産するかはクライアントとの折衝で判断していくべきでしょう。
図表や数式表現をうまく使う
基本設計書は、顧客・エンジニア問わず多くの関係者が目にすることになる書類です。
文章ばかりの表現だと理解に苦労するほか、誤解が生じてしまうことも考えられます。
開発を担うエンジニアにとっては、テキストよりも数式表現を使ったほうが作業する上でも負担が減るでしょう。
設計する側にも技術力は求められる
基本設計書は、後工程のエンジニアが実装を行なう際に欠かせない書類です。
なので、技術者がそれを利用するという前提で書類作成していくことになります。
上流工程のエンジニアが必ずしもプログラミングをするとは限りませんが、設計側にもある程度の技術力は必要です。
上流工程を担うのは主にSE（システムエンジニア）ですが、SEも社内研修でIT技術の習得を行なう場合が殆どです。
要件定義をメインに行うエンジニアはある意味「コンサル 」といえるものの、エンジニア要素もやはり関係してくることになります。
基本設計書のサンプルサイト
下記のサイトに、基本設計書のサンプルとしてお勧めのものが記載されています。
基本設計を学んでエンジニアのスキルアップを
基本設計や詳細設計だけでなく、各ドキュメントについての解説も交えて紹介してきました。
フリーランスエンジニアとして活躍していくには、システム開発についての幅広い知識を持っておくことが大切です。
開発フロー全体の知識を習得し、自身のキャリアへ役立てていきましょう。自分のスキルが増えるほど、対応可能なプロジェクトも増えていきます。
