「要件定義と基本設計の2つの言葉はよく目にするけど、詳しい違いが分からない」、「それぞれの作業で、どんなことを意識すればいいのだろう」など、要件定義と基本設計について不明瞭な点があるという方も多くいらっしゃるのではないでしょうか。この2つの言葉は明確に区別されており、それぞれで意識するポイントも違ってきます。
この記事では、要件定義と基本設計の違いから、設計の流れ、要件定義、基本設計の作成時の重要ポイントまでを解説していきます。
また、設計を効率的に進めるためのサービスの紹介も最後にしています。
ぜひ、最後までご一読ください。
「要件定義」と「基本設計」とは？
要件定義と基本設計は、どちらもシステム開発の業務フローの一部です。
要件定義は、クライアントからの要求をもとに実装する機能を決める作業のことです。要件定義でクライアントへのヒアリングを通じ、要求機能一覧や業務フローなどを作成していきます。
また、基本設計は要件定義で決まった機能を具体化するための設計作業です。要件定義では必要な機能を言葉で表現しているのに対し、基本設計では具体的な画面イメージとして設計し、開発する内容に認識のズレがないかを確認します。以下では、要件定義と基本設計について、もう少し詳しく見ていきます。
要件定義について
要件定義で決めることとは、どのようなことなのでしょうか？ここでは、要件定義で具体的に決めることをご紹介していきます。
要件定義で決めるべきこと
要件定義で決めるべきことには、次のような項目があります。
- システム化の目的
- システムの概要、構成
- 実装する機能（機能要件）
- 求める性能やセキュリティ（非機能要件）
- 導入・移行計画
- スケジュール
- 人員の体制
他にもクライアントの要望にもよりますが、システムのバグ修正などの品質管理に関することや、使用するフレームワーク、サーバー構成に関する取り決めなどもここで話し合っておくとよいでしょう。
クライアントが抱えている課題やシステム開発に至る背景などをまとめておき、作業者が開発業務に集中できるように要件定義を決めることが大事になってきます。スケジュールや人員の体制なども要件定義の段階で決めておくことになるでしょう。
基本設計について
続いて、基本設計で決めることをご紹介していきます。要件定義との違いに気をつけながら見ていきましょう。
基本設計で決めるべきこと
基本設計では、次のような項目を決定していきます。（一例）
- 画面レイアウト
- 画面遷移図
- 帳票レイアウト
- コード一覧
- ER図
- CRUD図
- システムインターフェース
基本設計では、要件定義の内容をもとに機能ごとにどういう開発を行うかを決めていきます。基本設計を作成することで、システム全体の機能のリスト化とそれぞれの関連性がつかめるようになります。
要件定義と基本設計の違い
要件定義と基本設計の明確な違いとは、何なのでしょうか？
簡潔にいうと、要件定義がクライアントの要件・要望をまとめた成果物であるのに対し、基本設計は、その要件定義を元にシステムの外部仕様を決めることです。
要件定義～基本設計の流れ
ここでは、要件定義の作成から基本設計の作成、テストにいたるまでを、いくつかの手順に沿って解説していきます。
ヒアリング
はじめに、要件定義の作成にあたって、クライアントからの要求のヒアリングを行います。
ゼロからのヒアリングでは双方時間がかかるため、クライアントに現状の業務や求める要求を予めまとめておいてもらいましょう。その資料をもとに確認ができるとスムーズに進みます。もしそういったものが何もない状態であれば、細かい機能要件を詰める前に大きな方針を再度決めるプレ要件定義を行うとよいでしょう。プレ要件定義で明らかになった大まかな要望に対して、再度要件定義で詳しくヒアリングしていくという流れです。
またヒアリング、打ち合わせには欲しい機能を決定する権限を持つ方に参加してもらいましょう。その場で決定ができず、毎回持ち帰って確認になってしまうと時間がかかりすぎてしまうためです。ですので、ヒアリングの際はプロジェクト全体の意思決定を行える方と、実際のその業務の担当者に参加いただけるよう、事前に調整しましょう。
ヒアリング内容を細分化
クライアントが抱えている問題や要求をヒアリングによって明確化したら、要求に優先順位を付けていきます。
優先順位を付けたら、「必須要件」と「希望要件」の2つの要件に分類してください。必須要件は、必ず組み込む必要のある要件で、希望要件はできれば組み込む要件のことです。希望要件に比べ必須要件の優先順位のほうが高くなります。
要件定義ではどうしても「あれも欲しいこれも欲しい」と要求は膨らみがちです。ですが、実際には予算も期間も限られているので、その中で対応できるものに絞らないとなりません。また費用対効果のあるかどうかも考えなければなりません。最終的に対応する範囲を決める際に、どれが必須でどれが希望の機能かが分かる状態になっていないと、なかなか決定することができません。機能の多さに応じて、希望の段階を分けて管理するのも良いでしょう。
要件定義書の作成
細分化した要件を元に、要件定義書を作成していきましょう。この要件定義書は後の開発フローでも重要になってくるので、ドキュメントにしっかり残しておくことが必要です。
要件定義書には、次の3項目を少なくとも入れるようにしましょう。
- システムの概要や構想
- システムを導入する目的
- システム導入後のフロー
- 要求機能一覧
- 非機能要件
要件定義書は開発側だけでなく、クライアントも確認することになるため、ここでは開発に関してあまり知識がない人でも理解できるような作成を意識する必要があります。
しっかりと要件定義書を作成することで、開発側とクライアント側との認識の不一致を防ぐことができるでしょう。
基本設計に落とし込む
要件定義でクライアントの要求と作成するシステムの概要が定まったら、次に基本設計のフローに進んでいきましょう。基本設計では、設計とクライアントによるレビュー、承認を繰り返しながら進めていきます。
基本設計は、クライアントがレビューするので、クライアントにわかるように作成することが前提になります。開発者が内容を理解するためにも使われますが、クライアントとの認識齟齬がないように基本設計は行われます。仮に基本設計が不十分で、クライアントの認識の齟齬や誤りがあるとその後の工程での変更を余儀なくされ、納期遅延や追加費用の発生につながる可能性があります。
クライアントは設計に時間を割くより、実際に動くものを作る作業を期待しますが、設計が甘いと結果としてプロジェクト失敗のリスクを高めることになってしまいます。基本設計のレビューは大変ではあるものの必要な作業であることをクライアントに十分理解していただき、協力いただけるように調整しましょう。
詳細設計に落とし込む
詳細設計とは、基本設計を元にシステムの機能ごとにより詳細な設計をしていく作業のことです。クライアントには直接目に触れない部分の設定も行っていくため、「内部設計」と呼ばれることもあります。
詳細設計の作成時には、開発者が目を通すものということもあり、専門用語が多くなるでしょう。
プログラムの作成
設計書を元にプログラムの作成を行います。設計の通りに作成が進むため、ヒアリングから始まる設計フローがとても大事なことがわかるかと思います。
テスト
最終的なシステムのテストを行う前に各機能ごとに設計と外れていないかテストを行っていきます。また、各機能ごと完成のタイミングが異なることもあるため、個別のテストを行っていきます。各機能ごと問題がなければ、機能を統合し、全体のテストを行っていきましょう。
問題がなければ、クライアントに納品して完了となります。
要件定義と基本設計のポイント
ここでは、要件定義・基本設計を進める上でのポイントについて解説していきます。同じシステム開発のフローですが、注意するポイントが違うのでそれぞれの違いについて注意して見ていきましょう。
要件定義のポイント
はじめに要件定義の作成時のポイントについて2つ解説していきます。
・要求を引き出す
先述した通り、クライアントの要求をしっかり引き出す必要があります。
クライアントが抱える問題が明確でないと、「どのような機能を作ればいいか」がぼやけてしまうため、要求を引き出すことは非常に重要になるでしょう。
また、クライアント側がITに精通していない場合もあるため、専門用語をわかりやすい表現にして話すコミュニケーションスキルも必要になってきます。逆にクライアント側の独自の言い回しも存在します。一般的な使われ方であれば問題ありませんが、社内システムを略称で呼んでいたり、見ただけではなんのことかわかりづらい社内用語がある場合もあります。そうしたものが多いようであれば、最初に「用語集」を作成しておくとその後コミュニケーションにおいても認識齟齬が起きづらくなるので、クライアントにリクエストするのもよいでしょう。
また要件定義の流れでもご紹介しましたが、要求を確認するにあたり、元になる資料がまるでない状態だと、なかなか要求を引き出すこともできません。ヒアリングの元になるものを用意しておいていただくようにしましょう。
・要求が実現可能か判断する
クライアントの要求を引き出して、システムに反映していくことが重要であることはもうおわかりいただけたかと思いますが、要求が実現できるかどうかも判断していかなければなりません。技術的に不可能、というものはどうしようもないとして、予算と期間などの制約上不可能というものもあります。クライアントに良い印象を与えようとするあまり、そうした実現不可能な要求を受け入れてしまうと結果としてプロジェクトがうまくいかないリスクとなります。制約条件を無視した開発は結局失敗し、お互い不幸になってしまうので、クライアントの要求が実現不可能な場合は代替案を提示するなどのして、クライアントの納得させるスキルも必要になってきます。
基本設計のポイント
次に、基本設計での重要なポイントについても見ていきましょう。
改めて要件のズレや抜け漏れがないかを確認する
基本設計は要件定義の内容に基づいて進めますが、結果として要件定義で決めたことと異なる内容になることは少なくありません。要件定義段階のコミュニケーションでは実現できると考えていたものが、いざ基本設計で画面に起こし、内容を確認したら認識に齟齬があり、実現が難しいことがわかった、なんてこともあります。こうしたことがないかを発見することも基本設計工程の役割です。
またに基本設計段階で、画面イメージが起こせると追加で必要な機能が見えたり、逆に不要な機能を発見することもできます。
・ユーザの視点を持つ
要件定義で決めた機能が網羅されていても、使いづらかったり運用に問題がある画面ではクライアントは満足しません。要件を満たしつつ、使いやすさも意識して画面を設計する必要があります。
そのためには実際のユーザの運用を想定して設計を進めることや使いやすいデザインを意識することが重要です。実際デザイナーがシステムのUIデザインを基本設計で行うケースは多くはありませんが、デザイナーのような考え方を持ちながら設計ができると、最終的に納品するシステムの満足度向上につながります。
クライアントは優れたUI/UXのウェブサービスやスマホアプリに慣れ親しんでいます。優れたデザインに囲まれて生活していると、そうでないシステムにどうしても不満を抱いてしまいます。おしゃれである必要はないかもしれませんが、使いやすい画面にするように心がけましょう。
まとめ
要件定義と基本設計の違いについて理解いただけたでしょうか？また、要件定義から基本設計にいたるまでのポイントや要件定義、基本設計ごとのおさえるポイントについても解説してきました。
要件定義と基本設計は、意識していないとそれぞれの目的があやふやになってしまいがちです。プロジェクトの成功のためには、それぞれの設計フローを的確に行い、不備の無い設計を行うことが重要です。
また専門的な知識だけでなく、クライアントからの要求を引き出すスキルだったり、開発するシステムを様々な視点から見るスキルなども必要になってきます。また、設計を効率的にするツールの導入などもシステムのクオリティを上げるために重要です。ポイントをおさえた設計を行って、クライアントに満足してもらえるシステム開発を行っていきましょう。
