要件定義とは？進め方とポイントを解説

システム開発プロジェクトにおいて要件定義は最も重要な工程といっても過言ではないでしょう。なぜなら、要件定義工程の失敗を取り戻すのは非常に難しいためです。ある調査※では要件定義工程の作業ミスをリリース時点で修正するためには、要件定義にかかった労力の200倍を要するという結果もあります。

要件定義はシステム開発プロジェクトの初期工程でありながら、システムの完成形を見据えて実施する必要があります。

この記事では、要件定義工程について、その重要性や具体的な進め方、必要なスキルなどをご紹介します。この記事を読むことで以下のことがわかります。ぜひご覧ください。

• 新規事業における要件定義の重要性
• 要件定義の具体的な進め方
• 要件定義において必要となるスキルや進め方のポイント

※参考：アラン M. デービス著、松原友夫訳「ソフトウェア開発201の鉄則」

要件定義とは？

要件定義とは、システム開発を始める前にシステムに対する要件を整理し、ドキュメント化する作業のことです。

要件定義では、システムに求める要素を要件定義書等のドキュメントとしてまとめ、今後のシステム開発のスタート地点とします。

要件定義はウォーターフォール型のシステム開発における工程の一つですが、アジャイル型でシステム開発を行う場合でも実施すべき工程です。

アジャイル開発では柔軟な方針の転換が可能ですが、事前に方針を決めずにプロジェクトに着手するのは危険です。要件定義を通して事前に構築すべきシステムの方向性を整理することで、プロジェクトの迷走を防ぐことができます。

アジャイル開発における要件定義につきましては、弊社スパイスファクトリーを取材していただいた「ROUTE 06 / 要件定義の最前線：アジャイル開発成功の秘訣」にも掲載されています。本記事と合わせて、読んでいただけたら幸いです。

参考記事：要件定義の最前線：アジャイル開発成功の秘訣

新規事業開発における要件定義の重要性

昨今では、他社との競争優位性確保や細かな市場ニーズへの適応のため、デジタル技術を利用して新規事業開発を進めるケースも増えています。

新規事業開発においてシステムを活用する場合、要件定義のプロセスは非常に重要となります。

要件定義では「どのようなシステムを開発するか」を細かく決めていきます。具体例を挙げると以下のとおりです。

• システムにどのような画面を用意するか
• システムはどのようなデータを持つか
• システムの想定利用者数はどの程度か
• システムにどのようなセキュリティ対策を行うか

新規事業の成功のためにはシステムの品質確保が重要です。たとえば、ユーザーニーズを満足できるだけの機能が無ければ、ユーザーの心は離れてしまいます。

また、せっかくビジネスが軌道に乗ったとしても、システムの想定利用者数を超えてしまえばアクセス集中によりシステムはダウンし、機会損失を生みユーザーの満足度も低下します。

サイバー攻撃により個人情報などが漏えいするリスクも考慮しなければなりません。

新規事業開発における要件定義は、ビジネスの成功という観点で具体的に開発するシステムの内容を決めていく、非常に重要な工程といえるでしょう。

なお、新規事業開発におけるデジタル活用の重要性は以下の記事でも解説しておりますので、併せてご覧ください。

※関連記事：DXを新規事業に取り入れるには？事例に学ぶコストをおさえて小さくはじめる方法

要件定義と要求定義の違い

要件定義とよく似た言葉に、要求定義というものがあります。両者は似ている言葉ですが、明確に異なるものです。

大まかに、発注者が行う「要求定義」と、開発会社が行う「要件定義」と理解するとよいでしょう。

要求定義とは、どのようなシステムを開発したいのかを、依頼側の立場としてまとめることです。自社にエンジニアがいない場合、システムを開発するためには外部の開発会社へ発注を行うことになります。

開発会社に開発したいシステムの内容を伝えるためには、誤解のないようにドキュメントで開発内容を明示してあげる必要があります。そこで、開発したいシステムの内容を要求定義としてドキュメント化します。

一方で、一般的に要件定義は開発会社側が主体となり行います。このとき、要求定義をインプットとして要件定義を行うこととなります。

なお、要件定義の主体は開発会社ですが、発注者側も無関係でよいというわけではありません。自社の希望するシステムを明確に開発会社に伝え、認識齟齬無くシステム開発を進める必要があります。

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

ウォーターフォール型開発において、要件定義の次工程となるのが基本設計です。基本設計では要件定義で定めた内容をブレイクダウンし、より細かくシステムの開発内容を定めていきます。

具体的には、以下のような項目を決めていくこととなります。

• 各画面にどのようなボタンや入力フォームを設けるか
• システムのデータベースをどのように設計するか
• 他のシステムとどのように連携を行うか
• どのようなスペックを持ったサーバーやクラウド環境を用意するか

要件定義の進め方

以下では、当社スパイスファクトリーの知見やノウハウも含めながら、要件定義の進め方についてご紹介します。

ステークホルダーの特定

要件定義としてシステムの姿を定めるにあたり、まずは意見を聞くべきステークホルダーを特定します。

最も重要となるステークホルダーは、システムの想定利用者です。利用者の意見を最大限取り入れることで、満足度の高いシステムを作り上げることができます。

それ以外にも、データを連携するシステムの担当者や、システムの結果を間接的に利用する方など、システムに関連する方をもれなく洗い出していきます。

現行システムや業務フローの把握

現行システムが存在する場合、いわゆるAs-Isの整理として、そのシステムが持っている機能や画面、またそのシステムを利用した業務フローの整理を行います。

多くの場合、現行システムが備えている機能は新システムでも必要となるものですので、現行システムの分析は効率的な要件定義のアプローチとなります。

現行システムの資料が不足しており、十分な分析を行えないというケースもあります。この場合、システムを管理する有識者や業務の担当者へのヒアリングを通して、現行システムの姿を把握していきます。

システム像の具現化

要件定義を進める中で、「作りたいシステムが本当に実現できるのか分からない」という懸念を持つケースはよくあります。要件定義ではどうしても文字を中心としてシステム像をまとめますので、特にシステム開発に不慣れな場合はイメージが湧きにくいのも現実です。

当社では、要件定義の成果をできるだけ分かりやすいものとするべく、プロセスの最初からUXデザイナーが伴走します。これにより、イメージしづらいシステム要件を可視化しながら要件定義を進めることができます。

具体的には、UXデザイナーと共に以下のような成果物を作りながら、システム像を具現化していきます。

 

要素	概要
インセプションデッキ	・プロジェクトの目標、範囲、ステークホルダー、リスク、スケジュールなどの主要な要素を示す文書。 ・プロジェクトチームとステークホルダーが共通の理解を持つために使用される。
ユーザーリサーチ	・ターゲットユーザーのニーズ、行動、動機、ペインポイントを理解するための調査活動。 ・インタビュー、アンケート、観察、ユーザビリティテストなどの手法を使用する。
ユーザーストーリーマップ	ユーザーがシステムをどのように利用するかを視覚的に表現する手法。 ・単なる機能の羅列ではなく、具体的なシナリオと目的をセットにして要件を書き出すことで、ユーザーにとって価値のある体験を設計しやすくなる。
ワイヤーフレーム	・システムの主要な画面やインターフェースのレイアウトを示す図。 ・デザインや機能の具体的なイメージを共有しやすくし、初期段階でのフィードバックを得やすくするために使用する。 ・当社では「オブジェクト指向UI（OOUI：Object-Oriented User Interface）」の概念を用いて、インターフェースを直感的かつ効率的に設計する。
Figmaプロトタイプ	・ワイヤーフレームを基に、Figmaなどのツールを使用して作成されるインタラクティブなプロトタイプ。 ・ユーザーや利害関係者が実際に操作しながらフィードバックを提供できる。

要件定義書の作成

これまで整理した要件は、最終的に要件定義書として取りまとめます。要件定義書にはシステムに持たせる機能だけでなく、セキュリティやIT基盤などの専門的な要素も含まれます。

当社では、エンジニア・デザイナー・PMが連携し要件定義に臨み、プロジェクトの方向性や具体的な要件を見える化した上で文書化します。

要件定義に必要な項目

ここでは、要件定義で主に定める項目として、「スコープ」「機能要件」「非機能要件」の3つをご紹介します。

スコープ

スコープとは、プロジェクトが対象とする範囲や目標のことです。スコープを明確に定義することで、プロジェクトの方向性を明確にし、関係者間の認識齟齬を減らします。

スコープは可能な限り図を活用して示すとよいでしょう。対象とする業務やシステムを赤枠などで囲い、対象に含まれない業務やシステムを赤枠から除外することで、誰が見てもプロジェクトの範囲が分かりやすくなります。

その他、スコープに関連して以下のような要素を定めることも重要です。

項目	内容
プロジェクト目標	現在存在する課題や、課題に対してプロジェクトが達成すべき具体的な目標を整理する。
成果物	プロジェクトの完了時に提供する具体的な成果物（ソースコードやドキュメントなど）を整理する。
制約条件	予算、スケジュール、リソースなどの制約条件を明確にする。
前提条件	スケジュールの都合や順守すべき法令など、プロジェクトの実行に影響を与える前提条件を確認する。

機能要件

機能要件では、システム化の対象となる業務と、業務で利用するためのシステム機能を整理していきます。

業務フロー

システム導入前後の業務の流れを図示し、各プロセスを具体的に記述します。これにより、システムがどの業務をどのようにサポートするかが明確になります。

フローで業務を表すことで、関係者間の認識を統一しやすくなり、業務の改善点も明確になります。

機能一覧

システムに用意すべき機能を全て洗い出し、各機能の用途や必要性、処理内容をまとめます。重要度や優先順位も併記すると、より効果的な整理が可能です。

機能一覧にまとめた内容がそのまま実現されるシステムとなりますので、要件定義書の中でも重要度の高い項目といえます。

画面一覧

システム内で使用される全ての画面をリストアップし、それぞれの画面の目的や操作方法を詳述します。併せて、画面遷移図としてそれぞれの画面の遷移の流れを図示するとよいでしょう。

画面はユーザーが実際に操作するものであり、ユーザー体験を向上させるためにも重要です。UXの観点を意識して必要な画面を精査するべきです。

帳票一覧

システムから出力される帳票を全て記載し、各帳票の内容や使用される場面を整理します。併せて、帳票のフォーマットや項目も明示します。

特に法令対応が必要なシステムでは、出力する帳票は法令が求める要素を網羅しているか、フォーマットは問題ないかなども意識します。

データ項目

システムで使用されるデータ項目を全てリストアップし、各項目の名称、データ型、制約条件を明記します。

データを洗い出すことで、システム開発中や運用時にデータの一貫性を保ちやすくなります。

また、併せてシステム内のデータベース構造を視覚的に表現したER図を作成します。ER図は、データベース設計の基礎となり、効率的にデータを扱うために必須の資料です。

システム間インターフェース

開発するシステムが他のシステムと連携する場合、その連携する方法を記述します。具体的には、データの送受信方法や形式、頻度を整理します。

インターフェース仕様は、異なるシステム間で協調して処理を行うための文書です。必ず双方のシステム担当者間で打ち合わせを行い、認識齟齬が無いように整理します。

非機能要件

システムを作る上では、機能以外にもセキュリティ対策内容や用意するIT基盤なども定めなければなりません。これらは非機能要件として定義します。

操作環境

ユーザーがシステムを使用するためのハードウェアやソフトウェアの仕様を定義します。具体的には、対応するオペレーティングシステムやブラウザ、画面サイズ、デバイスなどを定める必要があります。

性能要件

システムが処理を実行する際の応答時間や処理能力を明確にします。

たとえば、平均応答時間として画面操作後のレスポンスタイムを定めるほか、最大負荷時の応答時間、スループット、同時接続ユーザー数を定義します。

性能はユーザーの満足度に直結するため、ピーク時でも安定した動作が保証される必要があります。一方で、過剰なスペックを持ったシステムは費用対効果の面で課題となりますので、適切な規模感での設定がポイントです。

可用性要件

可用性とは、システムが利用可能である時間の割合を指します。一般的に、可用性は稼働率として表現されます。

たとえば「99.9%の稼働率」であれば、一年の間に約9時間程度システムが停止することを許容することとなります。

99.99%、99.999%と高い可用性を設定すればそのぶんシステムが停止する時間帯は減りますが、高い可用性を実現するためには重厚なITインフラが必要です。

性能と同様に、業務要件を踏まえた適切な水準での設定がポイントとなります。

運用保守要件

運用保守要件として、システムの日々の運用や保守管理において必要となる要素を定めます。

具体的には、システムの監視方法やログ管理、障害対応、ソフトウェアの更新、パッチ適用などが含まれます。

運用保守を容易にするために、管理者がシステムを簡単に操作できる管理ツールやドキュメントの整備も重要です。

セキュリティ要件

セキュリティ要件では、データの機密性や完全性を守り、システムを安定的に稼働させるために必要となる対策を定義します。

ユーザー認証やデータの暗号化、侵入検知と防止方法、セキュリティパッチの適用、定期的なセキュリティ監査などが一般的に定められる要件です。

昨今のサイバー攻撃動向を踏まえると、セキュリティの確保は非常に重要です。見落としがちですが、要件定義においてしっかりと議論すべきポイントでしょう。

要件定義に必要な要素・スキル

要件定義には様々なスキルが必要となります。ここでは、特に重要なスキルについてご紹介します。

コミュニケーション能力

要件定義においては、発注者側・開発会社側問わず、的確なコミュニケーションを行うことが重要となります。

システム開発は専門的なスキルが求められる一方で、発注者側の方は必ずしもシステムを専門にされていない方も多いのが現実です。双方が異なるスキルや認識を持っている中で、認識齟齬なくシステムの開発内容を定めなければなりません。

コミュニケーションにおいては、可能な限り認識齟齬をなくすべく、ドキュメントベースでの確認を基本とします。

ITや業界に関する知識と経験

システム開発においては、ITに関する知識はもちろん、業務や業界に関する知識も重要な要素となります。

業務や業界に関しては、一般的に発注者側の方が詳しく知っています。開発会社側も、発注者側の持っている知識や経験をできるだけ吸収し、認識齟齬なく要件定義を進める必要があります。

実現可能なシステム設計

特に開発会社側では、要件定義を通してコスト的・技術的に実現可能なシステムとなるように調整しなければなりません。

通常、発注者側ではシステムにかけられる予算や期間は決まっているものです。あまりにも過大な要件や、技術的に実現できない要件については、適宜その理由を説明しつつ、コントロールする必要があります。

これには前述したコミュニケーション能力の他、発注者側のニーズをどのようにシステムで実現するか、変換するスキルが求められます。

要件定義を進める上でのポイントを解説

以下では、要件定義を進める上でのポイントをご紹介します。

RFPの作成

特に発注者側として重要となるのが、RFPを作成して開発内容を明確にしたうえで、開発会社を選定し、要件定義に着手するプロセスです。

RFPとはRequest for Proposalの略であり、日本語では提案依頼書となります。RFPは発注者側が作成し、開発会社に対して構築したいシステムの内容を伝え、開発内容の提案や費用の見積もりを依頼するものです。

システム開発を行う際には、開発会社を公平かつ適切に評価・選定するために、RFPを作成し、コンペティションを実施することをおすすめします。

RFPには前述した要求定義で整理した内容を記載します。RFPという形で明確に開発会社にシステムのイメージを伝えることで、要件定義へとスムーズに移行することができます。

※関連記事：【サンプル付】RFPとは？テンプレートと書き方ガイドで完全解説

適切なスコープ定義

よくあるのが、要件定義段階で壮大な絵を書いてしまい、実現のために多額のコストと期間がかかってしまうという失敗です。過大な要件を求めず、自社のビジネスにおいて重要であり優先度の高い要素を盛り込んでいくことを心がけます。

このためには、スコープ定義として今回のシステム開発で何を実現し、また何を実現しないかの仕分け作業が必要です。優先度が低い機能については、2次開発に回すなどの調整を行います。

なお、特に重要度の高い機能を先行して構築したい場合、PoC開発やMVP開発といったアプローチが有効です。

それぞれ、PoC開発はビジネスアイディアなどの仮説検証を行うことを目的とし、MVP開発はプロダクトが市場にフィットするかを確認することを目的とします。

PoC開発とMVP開発については以下の記事で解説しておりますので、ご興味のある方はぜひご覧ください。

※関連記事：MVP開発とは？アジャイル開発との違い、実施プロセスや注意点を解説
※関連記事：PoCとは。ビジネスにおけるPoC活用メリットや進め方を徹底解説

役割分担の明確化

要件定義を開発会社に丸投げしてしまうのは、非常に危険です。最終的に想定していたシステムが開発されず、プロジェクトが失敗する原因となります。

一方で、発注者側のみで要件定義を進めすぎるのも危険です。要件定義にはシステムに求める可用性や信頼性、セキュリティといった専門的なスキルが求められる要素も含まれます。

よって、発注者側、開発会社側の双方がうまく役割を分担し、それぞれのスキルや知識を合わせて進めていくことがポイントです。双方の役割分担については、要件定義のキックオフ時点で星取表を用いて明確化しておくことをおすすめします。

明確なドキュメントの作成

要件定義において作成する要件定義書は、システム開発におけるバイブルとして、以降の工程において参照され続けます。一般的に、システム開発においては後工程になればなるほど参加人数が増えていきます。

新たに参加した方が要件定義書を読んだときに、その内容が伝わらなければなりません。

要件定義書はできるだけ分かりやすく、第三者に伝わる内容にしなければなりません。

要件定義に成功した事例紹介

株式会社エクスメディオ | 医師向けコミュニティ「ヒポクラ 血液内科 Pro」のデザインリニューアル

AIを活用した医師同士のコミュニケーション・プラットフォームを運営する株式会社エクスメディオ様では「ヒポクラ 血液内科 Pro」として血液内科領域の医師専用の会員制コミュニティサービスを提供されています。当社では、同サービスの利用ユーザーの増加を目的としたデザインのリニューアルを支援させていただきました。

本プロジェクトでは、アクティブユーザーを増やすべく、医師が気軽に質問・回答でき、かつそれを習慣化してもらうことを重視した改善を実施。ユーザーへのインタビューを通して要件を整理し、仕様書として整理しました。

ユーザーである医師の心理的安全性が高まり、結果としてリニューアル前より気軽な内容の投稿が増え、質問の回答も増加させることができました。

※事例ページ：株式会社エクスメディオ | 医師向けコミュニティ「ヒポクラ 血液内科 Pro」のデザインリニューアル

株式会社トムス・エンタテインメント | アニメーションの制作管理システム「ProGrace」の開発

当社では、アニメーション制作を営む株式会社トムス・エンタテインメント様が主に社内で活用するアニメーションの制作管理システム「ProGrace」の新規開発を担当いたしました。

開発にあたっては、実際にシステムを利用する制作進行担当の方にデモやレビュー、ミーティングに参加していただき、現場目線の意見を取り入れた要件の整理を行いました。整理にあたってはワイヤーフレームなども活用し、システムの開発につなげていきました。

※事例ページ：株式会社トムス・エンタテインメント | アニメーションの制作管理システム「ProGrace」の開発

帝人株式会社 / 在宅医療支援機構株式会社 | 訪問看護専門総合転職支援サービス「NsPace Career」の開発

在宅医療が重要視される社会環境も踏まえ、帝人株式会社様および在宅医療支援機構株式会社様では、訪問看護を専門とする看護師向け総合転職支援サービス「NsPace Career」を提供しています。

本プロジェクトにおいて、当社はUXデザインや機能実装、運用保守まで包括的な支援を実施しました。

要件の整理にあたっては、実際に看護師へヒアリングを実施し、必要な機能を検討いたしました。また、デザイナーとエンジニアによる「ペアデザイン」により、デザイン作成段階でエンジニアによる社内レビューを行い、技術的に実現性の高いデザインカンプを作成する取り組みも実施しました。

※事例ページ：帝人株式会社 / 在宅医療支援機構株式会社 | 訪問看護専門総合転職支援サービス「NsPace Career」の開発

まとめ

今回は、要件定義の重要性や進め方など、要件定義に関して詳しく解説しました。ご紹介した通り、特に新規事業開発において要件定義は非常に重要となります。

また、要件定義を進める上では、ITのみならず、UI/UXデザインのスキルも持った開発会社の選定もポイントです。

当社、スパイスファクトリーは、システム開発に精通した多数の人材を抱え、プロジェクトマネージャーやエンジニア、デザイナーなどオールインワンで皆様のシステム開発をサポートします。要件定義工程から開発、リリース後の運用まで対応が可能です。

新規事業開発やシステム開発をご検討されている方は、ぜひお声がけください。