要件定義とは？基本設計との違いから進め方、仕様書作成まで解説

要件定義は、システム設計やサイト制作、企画実行に際して、肝となる作業です。

本記事では、タイトルよろしく要件定義とは何かを伝えるべく、基本設計との違いから、進め方、仕様書作成まで幅広く解説していきます。
今まで苦労されてきた方、これから必要とされる方、ぜひ、コツを掴んでもらえると幸いです。
どうぞ、ご一読ください。

要件定義とは？基本設計との違いやメリット

あるプロジェクトの構想を練る際、その目的やコンセプト、実現のために必要な工程などを整理する必要があります。まさしくその作業こそ要件定義です。
現代社会においてはITシステムに携わる業界での専門用語という印象が強いとはいえ、本来、あらゆる仕事の現場で求められてもおかしくありません。

要件定義を端的に説明

要件定義の設計は、主にデザイナーやディレクター、エンジニアなどタスクを指揮する人間が中心となり、プロジェクトの進行に必要な項目を列挙するところからはじまります。その内容を“要件定義書”と呼ばれる仕様書に落とし込み、適宜、関係者へ周知。過不足ないものへと調整を図ったうえで、ひとまず完了です。

要件定義と基本設計の違い

基本設計は要件定義の一連の流れに組み込まれているケースも多く、混同しやすいとはいえ、一般的には、明瞭化のフェーズに該当するものとして区別されています。
具体的には、業務フロー、機能一覧、画面レイアウト、画面遷移、インターフェース一覧など実際にシステムを動かす部分の仕様決めです。
視覚的に共有できる役割という意味では、仕様書のそれ、つまり要件定義の強化と位置づけていいかもしれません。
セキュリティ面の管理や運用規定といった重要項目も、大抵、この時点で決定されます。

要件定義の目的、メリット

要件定義は、上流工程（クライアントの要求を聞き出してから詳細を設計するまでの工程）のスムーズ化に寄与します。
仕様書によってワークフローが体系化されるため、制作部隊にとっては役割が明確です。加えて、クライアントの要求をどの部署も共有しやすく、協力体制は強固なものと化します。

逆に、要件定義を疎かにしてしまうと、それぞれの判断で作業が行われ、間違った方向へと舵を切ってしまう恐れが出てくるでしょう。
ゴールは、単に完成させることではありません。クライアントの要望に応えた、満足度の高い製品を納めることです。
だからこそ、現場を一つにすべく、要件定義は不可欠なものだといえます。

なお、要件定義と似た言葉に「要求定義」というものがあります。後者はあくまでクライアントの要望をまとめるまでです。それらをプログラミングやデザインへ置き換える、要件定義とは異なります。

要件定義の進め方

先に要件定義は項目列挙からはじまるとお伝えしましたが、その前段階として、ヒアリングなどクライアントとのやりとりは必須といっていいでしょう。スタート地点にまで用意する材料、すなわち現状の問題点を洗い出していきます。
このとき、重要なポイントはギャップを見つけ出すことです。
そして、それらを克服するための機能、デザインをまとめます。
そのうえで、納期や予算、実現性といった現実的な要素と照らし合わせていきましょう。これらのプロセスを経て、ようやく開発者が要件定義を仕上げられるだけの情報が出揃います。
その後は仕様書を作成。クライアントに了承を得られれば、いざ制作、開発へと移行可能です。

おさえるべきポイントはこれだ！

要件定義でおさえるべきポイントは案件によっても変わってくるとはいえ、「クライアントの要望」「解決手段」「明確なタスク」の3点は必須といっても過言ではありません。
要望はゴールの共有。解決手段はミッションに対する施策。タスクの明瞭化は生産性の向上。それぞれが適切に機能されることで、プロジェクトの最適化を図ることができます。

要件定義書（仕様書）の重要性

繰り返しますが、クライアントや現場は要件定義を仕様書によって把握します。つまり、優れた要件定義も、仕様書が雑に作られていては無意味なのです。
そのことをきちんと理解し、細かい点にまで意識を向ける必要があります。
まず把握すべきこととして、仕様書の種類。大別すると「業務」と「システム」です。
前者は、プロジェクト概要や目的、納期、指標が主な項目に該当します。補足事項としては、クライアントの現状、進捗まで随時伝えられるといいでしょう。
後者は、機能面と非機能面それぞれに言及します。
開発チームが手がける管理画面やインターフェース、データなどは機能面。
一方、非機能は、主にユーザビリティや満足度をはじめ、クライアントのITリテラシーや契約内容、引継ぎ情報……等々、多岐に渡ります。現状のOSやバックアップ体制、今後の保守やメンテナンスについてもしっかり記載しておきましょう。

プロジェクトの全体像を現場に把握してもらうべく、仕様書が持つ役割は非常に重要です。
同じゴールを目指す仲間からの信頼にもつながります。
デザイン、構成への配慮や見せ方にも工夫を凝らすなど、極力注力するようにしてください。

システムに関する記載

前項でも触れましたが、システムに関して確実に記載すべき項目は、概要、導入目的、業務フローです。
概要では、どのような特長を備えたシステムなのかについて説明します。このとき端的に業務要件、システム要件を挙げるならば、前者は顧客、後者は開発側の視点を持ちましょう。」難しい話ではありません。典型的な例を述べると、サイト内に商品購入のカートを実装して欲しいとの要望があった場合、業務要件は「商品購入」でOKです。一方でシステム要件は購入のための手段が該当します。すなわち「カートに商品を入れる」です。

導入目的も、顧客目線からスタートさせましょう。然らばおそらく要望が浮かび上がってくるはずです。そこに前述の概要を掛け合わせます。つまり、このシステム概要によってどういった要望が実現できるかを説明するのです。

そして、業務フローはシステム導入前後の変化を伝えるとわかりやすいでしょう。
結果的にそのシステムが必然であることのロジックが成り立ちます。

機能要件に関する記載

機能要件とはクライアントが求めているものです。ダイレクトにプロジェクトのゴールを指すといってもいいでしょう。
仕様書には、システム実装でできることはもちろん、（システム自体の）タイプや構造、データについても漏れなく記載しましょう。また、予算オーバーにも気を付けてください。

機能要件は、初期段階で共有する要件とはいえ、クライアントの完成形へのイメージを後押しする役割を持つため、思いのほか重視されます。極力具体的に、鮮明に描けることが大事です。

非機能要件に関する記載

非機能要件とは、文字通り機能面以外の要件を指します。
クライアントの要望はあるにせよイメージは漠然とされているケースがほとんどでしょう。
そのなかで具体的にゴールを設定しなければなりません。
機能要件が決まり次第取り掛かります。扱う項目はシステムの性能や効率性、セキュリティや保守・運用サービスなどです。これらを記載し、プロジェクトの解像度をさらに高めていきます。いわばそのための要件定義書（仕様書）です。

失敗しない要件定義のコツ

経験の浅い担当者が作った仕様書では、詳細設計の部分が曖昧になりがちです。しかし、現場がもっとも確認したがっているのは、まさにそこの部分といえます。
情報不足はもちろん、作業内容のニュアンスを的確に伝えなければ、プロジェクトの進行に綻びが生じやすくなるでしょう。意思決定も容易に行えないかもしれません。
そうならないための大事なコツ。以下、いくつかご紹介します。

図表を効果的に用いる！

たとえば、タスクを無造作に並べるだけでは、各々の判断に委ねられ、齟齬が生まれる可能性が高くなると考えます。そこで、大切なのは共有できるイメージです。つまり、視覚化が必要とされます。
たとえば、クラス図やシーケンス図で各タスクのつながりを表現するだけで、作業内容の解像度はぐっと上がります。なぜなら、お互い、担当する役割の相関関係が理解できるからです。もちろん、プログラミングもデザインも、高い品質、精度が期待できます。

修正、変更連絡は丁寧かつタイムリーに行う！

修正や変更の反映をこまめに行う場面も多いでしょう。どれほど入念に考えられた要件定義であっても、制作・開発途中で問題が見つかるケースは珍しくありません。あるいは、予算や技術的な理由で、変更を余儀なくされる可能性も出てきます。そのような場合であっても、当初の進め方にこだわっていてはプロジェクトが大きく揺らいでしまいます。必要に応じて柔軟に要件を修正していきましょう。もちろん、関係者を戸惑わせないよう伝え方には慎重さが求められます。なおかつタイムリーに周知できなければ、一気に信用はガタ落ちです。
丁寧に、そしてスピーディーに！
常に意識しておきたいところです。

理由、期限、対象、場所、人、方法、予算

キャリアを積まれている方々の共通点として、仕様書内に「5W2H」がはっきり記載されていることが挙げられます。
どのような理由で（WHY）、いつまでに（WHEN）、何を（WHAT）、どの部門で、誰が（WHO）、どのような方法によって（HOW）、いくらの予算で（HOW MUCH）行うのか。
これらをすぐに確認できるようにしておくことは当たり前のように思われがちですが、初心者だとどうしてもそこまで気が回らない方も少なくありません。
現場が混乱しないためのコツであり、確実に伝えておきたい要素です。

要件定義は仕様書作成までしっかり取り組もう！

要件定義は、システム開発やサイト制作などあらゆるプロジェクトの進行において、根幹をなす部分といっても過言ではありません。ここを軸とするため、ローンチや納品までの一連の流れ、進め方も当然変わってきます。各部署のパフォーマンスにも影響を及ぼすため、どうしたって慎重に取り組まなければならないでしょう。
そして、それは基本設計から仕様書作成に至るまで気が抜けません。

ゴールに向けて、最善のスタートダッシュを切るための起爆剤。あるいは途中、困難やトラブルに対峙した際、再度原点に立ち返ることのできる明確な指針。さらには、そのプロジェクトに携わる方なら誰もが理解できる共通言語。
各シチュエーションで要件定義は作用します。
拙稿にてお伝えしてきたその有用性と持つべき意識。流れを理解することはもちろん大切ですが、もっとも心がけたいのは、クライアントの要望を満たしたうえで、関わる人たちが気持ちよく仕事できることだと考えます。そこから逆算して、導き出されたものが、おそらく最適解と呼べるものでしょう。