【徹底解説】システム開発において要件定義とは？やり方を5ステップで解説！

「システム開発の要件定義って何？」
「要件定義では具体的に何をする？」
「要件定義の重要なポイントを知りたい」

本記事では、要件定義の全体像を知ってもらうために、要件定義のやり方を5ステップで解説しています。

システム設計やプログラミングを行う前の、第一段階である要件定義は、システムを作るうえでの基盤となり、今後の開発を左右します。

そのためシステム開発において、要件定義は重要なフェーズなのです。

本記事を読んで、要件定義の外観を掴むとともに、重要なポイントについても押さえておきましょう。

またこの記事では、要件定義書の書き方や要件定義の難しさ、要件定義において必須のスキルについても解説しています。

▼『システム開発』の詳細についてより詳しく知りたい方は、こちらの記事が参考になります。
①【初心者必読】システム開発系の会社の種類とそのメリット・デメリットについて解説！
②Webアプリとは？ 仕組みと作り方を解説！

システム開発の要件定義とは？

要件定義とは、クライアントや開発関係者と密にコミュニケーションを取ることで、「どのようなシステムを開発するのか」「どのような計画で開発を行うのか」を決定することです。

ちなみに要件と似た言葉で「要求」がありますが、この2つには決定的な違いがあります。

要求と要件の違い

要件定義の話をするうえで、要求と要件の違いは明確にする必要があります。

まず、要求というのは「～したい」という思いになります。

例えば「システムで業務を効率化したい」「集客を見込めるアプリを開発したい」などです。

それに対して要件とは「要求を実現する手段」に当たります。

つまり要件定義とは「要求を要件に落とし込んでいく作業」といえます。

また、クライアントとのヒアリングの際に、クライアント自身も自覚していない要求もあるので、そのような要求も要件に落とし込むことが重要です。

システム開発における要件定義の重要性

システム開発は要件定義の質で決まると言っても、過言ではありません。

要件定義が重要だと言われている理由は、要件定義で決定した事項をもとに、システム開発が行われるからです。

システム開発は、「要件定義→システム設計→開発→テスト→保守・運用」の流れで進むため、要件定義の完成度は後工程に大きな影響を与えます。

要件定義の段階で、クライアントの要望をもとに、システムに組み込む機能や実行計画が決められるため、そのあたりの設定が曖昧だとプロジェクトの進行が遅れて、結果的にミスにつながります。

例えば要件定義の時点で、クライアントの要求を全く要件に落とし込めてなかったら、いざ実際にシステムを動かしてみた時に、追加の要望や出戻りが多発するでしょう。

このように、要件定義がしっかりとできていないと、システム完成の時期が遅れてしまい、開発費の増大やシステムの質の低下を招くので、要件定義の重要性は知っておくべきです。

システム開発における要件定義の流れ

ここでは要件定義のやり方を、5つのステップで解説します。

要件定義では、「業務要件を検討→システム要件を検討→機能要件を検討→非機能要件を検討→実行計画を決定」の流れで進みます。

要件定義の流れを順番に解説します。

業務要件を決める

業務要件とは、業務の現状を分析して問題点を洗い出し、システムで何を実現するのかを決める工程です。

まず最初に、ヒアリングを通してクライアントの要望を抽出します。

ちなみにこの段階では、システムに何を組み込むのかなど、技術的な部分は意識しません。

なぜなら業務要件の時点で意識することは、あくまでも「業務について」だからです。

システム要件を決める

システム要件とは、業務要件で決めた業務フローを、どうのようにシステム化するのかを決定する工程です。

ここで、システム要件と業務要件との違いを区別する必要があります。

まず業務要件が「システムで実現させたいこと」だとしたら、システム要件はそのを実現するための「手段」に当たります。

ここで両者の違いをイメージしやすくするために、簡単な例を挙げます。

業務要件が「1日の運動量を知りたい」だとしたら、これを実現するシステム要件は、「スマートウォッチで心拍数を測れるようにする」「GPSから移動距離を割り出す」「心拍数や移動距離などの情報から、運動量を計算する」などが挙げられます。

機能要件を決める

機能要件とは、業務を実現するために必要な機能を決める工程で、この次に説明する非機能要件とセットで、システム設計の重要なファクターとなります。

ちなみに機能要件で決める機能とは、システムにおいて最低限必要な機能のことを指します。

非機能要件を決める

非機能要件とは、機能要件以外の要件、つまり必ずしも必要というわけではない機能を決める工程です。

この工程では「別に必要というわけでもないけど、あればいいな」くらいの要望を満たすための要件をまとめます。

また非機能要件には、セキュリティ面や可用性、レスポンスなどの観点で、システムが動作するための前提条件をまとめたものがあります。

実行計画を決める

業務要件やシステム要件などを決めたら、システム構築にかかるコストや時間の見積もり、開発の計画を立てます。

実行計画を決めたら、その計画にそって開発が行われます。

システム開発の要件定義書の書き方

要件定義書とは、要件定義で決めた事項を記載した書類のことです。

この要件定義書が、要件定義における成果物になるので、書き方を知ってもらうために、書類に記載するべき項目について説明します。

業務要件の書き方

業務要件では、システムの使われ方について記載します。

業務要件を書く目的は、システム開発の際に、クライアントのニーズを意識させるためです。

具体的に業務要件で書くことは、主に「システムの概要」と「ユースケース」です。

システムの概要とは「これから開発するシステムのざっくりとした内容」になります。

また、ユースケースとは「このシステムの使われ方」を定義したものです。

機能要件の書き方

機能要件で書くことは、主に「アプリの種類」「機能一覧」「外部システム連携」で、このシステムにはどのような機能があるのか、または不要な機能を記載します。

まず、アプリの種類では「システムがWebアプリケーションで機能するのか」もしくは「スマホ向けアプリでも機能するのか」などを記載します。

次に、機能一覧で書くことは、ログイン機能やメール送信機能など「全ての機能」です。

この際、実装方法や詳細設定などについても書きます。

最後に、外部システム連携の欄で書くことは、クレジットカード決済APIなどの「外部のシステムとどのように繋がっているのか」です。

非機能要件の書き方

非機能要件で書くことは、主に「インフラ構成」「キャパシティプランニング」「性能要件」「可用性」「死活監視」「セキュリティ要件」「バックアップ計画」などです。

まず、インフラ構成では、システムを稼働させるためのネットワークやソフトウェアなどの「ITインフラの構成」を記載します。

次に、キャパシティプランニングでは「システムを利用するユーザー数」や「システムが利用される程度」を記載します。

これはシステムにかかる負荷を見積もるために、必要な項目です。

次に、性能要件では、画像表示の速度や応答率といった「システムの性能」を記載します。

また、可用性の欄で書くことは「サーバーダウンのしずらさ」です。

次に、死活監視では「システムが正常に稼働しているかを、どのように監視するのか」を記載します。

次に、セキュリティ要件の欄で書くことは「情報システムの安全性」です。

最後に、バックアップ計画では「バックアップの頻度」や「バックアップの時期」などを記載します。

システム開発の要件定義が難しい2つの理由

工期遅延理由のおよそ55%が要件定義の問題と言われています。

遅延の具体的な要因は、要求仕様の決定漏れや開発規模の増大などです。

なぜこのような問題が起きるのかを、ここでは解説します。

要件定義の難しさを知ることで、要件定義を行う際に、注意点を意識して行うことができ、要件定義のミスを未然に防ぐことが可能になります。

そのため、ぜひこの点を押さえておきましょう。

クライアントのニーズを捉えるのが難しいから

クライアントのニーズは、本人も気づいてなく、変わりやすいものです。

そもそもシステム開発というのは、長期間にわたって行われるもので、数年に及ぶプロジェクトも、珍しくはありません。

そうした間に、会社の方針の変更などで、クライアントのニーズが変化することもあるのです。

また、ユーザーテストで実際に触ってみて、ニーズに気づくこともあり、クライアントのニーズを捉えることは難しいのです。

クライアントのニーズを捉えられないと、要件に落とし込むことが困難になります。

開発の各担当者間で連携が図りづらいから

担当者が異なれば、目的意識も異なります。

例えば、経営者であれば「売上増加」などが目的で、システム部門の担当者であれば「要件通りの設計」などが目的になります。

また、ビジネス部門の担当者は業務に詳しいですが、システム部門の担当者はITに詳しいです。

そうすると、ビジネス部門とシステム部門の間で知識の壁が生じてしまいます。

「目的意識の違い」や「知識の壁」があることで、コミュニケーションが難しくなるという問題が発生します。

そうなると、担当者間で連携がとりずらい環境になり、アイデアも出にくい状況になってしまいます。

システム開発における要件定義のコツ

ここでは、要件定義を上手く行うためのコツとして「ヒアリングのコツ」と「関係者との連携方法」を解説します。

それでは見ていきましょう。

5W1Hを意識してヒアリングを行う

クライアントとのヒアリングの際に、「いつ」「どこで」「誰が」「何を」「なぜ」「どのように」を意識しましょう。

例えば「なぜシステム化が必要なのか？（Why）」「解決したい課題は何なのか？（What）」「システムの具体的な利用シーンはどのようなものなのか？（How）」などが挙げられます。

5W1Hという視点を持っておくことで、仮説を持ってヒアリングを行うことができるようになり、より相手の要望を引き出すことが可能になるのです。

また、5W1Hの中で特に重要なのは「なぜ」を意識することです。

疑問を深掘りすることで、よりクライアント要件の解像度が上がります。

関係者と円滑なコミュニケーションを図る

各担当者との円滑なコミュニケーションは、プロジェクトの成功を左右します。

円滑なコミュニケーションのために、重要になってくるのは「1次情報の利用」です。

1次情報とは「直接仕入れた情報」という意味で、「直接見たり聞いたりして得た情報」になります。

ここで意識してほしいのは「担当者に直接聞く」ということです。

不明点がある際は、又聞きよりも直接聞いたほうが確実ですよね。

そのため、関係者と円滑なコミュニケーションを図るには、「直接聞く」「直接会って話す」などの一次情報の利用が重要なのです。

ただ、ビジネス部門にはITに苦手意識のある人が多いので、なるべく専門用語を避けて簡単な言葉で、図表などを駆使して伝えるようにしましょう。

システム開発の要件定義で求められる4つのスキル

ここでは、システム開発の要件定義に必要な能力を4つご紹介します。

要件定義の進め方に関する知識

要件定義の進め方の知識とは、体制や成果物、プロジェクトマネジメントなど、要件定義を成功させるための知識のことです。

この知識があると、よりスムーズな要件定義を行えるようになります。

この知識を得るには、ある程度の経験を積む必要があります。

システム開発に関する知識

システム開発に関する知識とは、システム化対象業務やシステム開発の専門知識のことです。

この知識が無いと、クライアントに具体的な提案をすることができなくなります。

また、要件定義においても、システム開発の知識は必須です。

目的思考とデザイン思考の能力

目的思考とは、目的に対して要望・要件を照らし合わせて、有効性の有無を評価し、有効性が低い場合は、その要望・要件を却下する思考法です。

例えば目的が「業務報告を効率化したい」で、要望・要件が「営業の可視化」「レポーティング」「入力の効率化」「IEの利用」だとします。

目的思考では、これらの要望・要件の必要性を吟味することが重要です。

デザイン思考とは、要望・要件に対して目的を照らし合わせて、網羅性を評価し、網羅性が不足している場合は、要件を追加する思考法です。

ヒアリング時のコミュニケーション能力

ヒアリングの際は、コミュニケーションを通じて、クライアントのニーズを引き出す必要があります。

そのためにも、「ヒアリング」「プレゼン」「ミーティング」「ファシリテーション」などのスキルなどが求められます。

システム開発における要件定義とは？やり方を5ステップで徹底解説！ まとめ

今回は要件定義について、詳しく解説しました。

要件定義のやり方や要件定義書の書き方などの実践的な知識は、実際に要件定義を行う上で必須の知識です。

また、それらを理解するうえでも、要件定義についての基礎的な知識は欠かせません。

今回の記事は、絶対に押さえておくべき内容が詰まってるので、本記事を読んで今後のシステム開発に、役に立てていただければ幸いです。