システムやアプリの開発を依頼する際、要件定義はどのように進めるべきか理解することも必要です。本記事では実務の流れに焦点を当てて解説します。
要件定義は、依頼側と開発会社が一緒に作り上げていくプロセスです。専門的な技術判断は開発会社が担いますが、業務の実態や解決したい課題については、依頼側からの情報提供が欠かせません。この記事を通じて、各ステップで何が行われ、どのような準備や確認が必要なのかを把握していただければと思います。
要件定義についての解説記事は以下でご覧ください。
要件定義の全体像（7つのステップ）
要件定義は、一般的に以下の7つのステップで進められます。
- 要求のヒアリングと整理
- 課題と目標の明確化
- システム全体構造の明確化
- 機能要件の決定
- 非機能要件の決定
- 工数見積もりとスケジュール設定
- 要件定義書の作成と合意
これらのステップは順番に進むこともあれば、行ったり来たりしながら内容を詰めていくこともあります。開発会社がリードしながら進めてくれますので、依頼側は各段階で必要な情報提供や確認を行っていく形になります。
それでは、各ステップについて詳しく見ていきましょう。
ステップ1｜要求のヒアリングと整理
このステップで行うこと
プロジェクトの最初の段階では、依頼側の要望を開発会社と共有します。「システムで何を実現したいのか」「現在どのような業務を行っているのか」「どんなことに困っているのか」といった情報を、開発会社に伝えていきます。
開発会社は、お話を伺いながら、実現可能性や技術的な選択肢を検討し、依頼側の要望を整理していきます。この段階では、まだ細かい仕様まで決める必要はありません。
依頼側が準備しておくとスムーズに進むこと
事前に以下のような情報を整理しておくと、やり取りがスムーズに進みます。ただし、完璧に整理されている必要はなく、大まかな内容で構いません。
- 現在の業務フロー：どのような流れで業務が行われているか、サービス開発の場合はユーザーや運営側、システムも含めたフローについて整理する
- 困っていることや改善したいこと：現状の課題や不便に感じている点
- システム化で実現したいこと：最終的にどうなっていたいか
例えば、「予約受付を電話やメールで行っているが、手作業が多くてミスが起きやすい」「在庫管理が複数のExcelファイルで行われており、リアルタイムで把握できない」といった具体的な困りごとを伝えると、開発会社も提案しやすくなります。
開発会社とのやり取りで意識しておくと良いこと
ヒアリングの際、「こういう機能が欲しい」という手段だけでなく、「なぜそれが必要なのか」という目的も併せて伝えると、開発会社からより良い提案を受けられる可能性があります。
例えば、「会員登録機能が欲しい」という要望の背景に「リピーターを増やしたい」という目的があるなら、その目的も共有することで、会員登録以外の選択肢や、より効果的な機能の組み合わせが提案されるかもしれません。
また、すべての要望を同じ優先度で伝えると、予算やスケジュールの調整が難しくなることがあります。この段階では詳細に決める必要はありませんが、「これは絶対に必要」「できれば欲しい」といった温度感を持っておくと、後の判断がしやすくなります。
ステップ2｜課題と目標の明確化
このステップで決まること
ヒアリングで得た情報をもとに、開発会社と一緒に「解決したい業務課題」と「システム化の目標」を明確にしていきます。ここでは、現状の業務を詳しく分析し（As-Is分析）、システムでどこまで改善できるかを検討します。
例えば、「予約管理の効率化」という漠然とした目標を、「予約受付から確認メール送信までを自動化し、担当者の作業時間を50%削減する」というように具体化していきます。
依頼側が関わる部分
開発会社から、現在の業務について詳しく質問されることがあります。これは、システムで解決すべき本質的な課題を見極めるためです。
- 現場で実際に困っていることを具体的に伝える
- 経営層が考える課題と、現場が感じている課題の両方を共有する
- 開発会社からの質問に答えながら、一緒に内容を整理していく
この段階で、経営層と現場担当者の認識にズレがある場合は、社内で調整しておくことをおすすめします。例えば、経営層は「データ分析機能が欲しい」と考えているが、現場は「日々の入力作業を減らしたい」と思っている、といったケースです。
どちらも大切な視点ですので、開発会社に両方の声を伝え、優先順位や実現方法を一緒に検討していくと良いでしょう。
ステップ3｜システム全体構造の明確化
このステップで決まること
課題と目標が整理できたら、次はシステム全体の構成を決めていきます。開発会社が、業務フローやシステム構成図を作成し、「どの部分をシステム化するか」「どのような流れで処理が行われるか」を可視化してくれます。
ここでは、ビジネスプロセス図や業務フロー図といった図表が用いられることが多く、視覚的に全体像を把握できるようになります。
依頼側が確認する部分
開発会社が作成した業務フロー図や構成図を見ながら、以下の点を確認します。
- 実態と合っているか：図に描かれている業務の流れが、実際の業務と一致しているか
- 例外的なケースへの対応：通常の流れだけでなく、イレギュラーな対応（キャンセル、変更、エラー処理など）も考慮されているか
- システム化する範囲：どこまでをシステムで処理し、どこは人が対応するのか
例えば、ECサイトであれば、「注文→決済→発送」という通常の流れだけでなく、「返品・交換」「決済エラー時の対応」「在庫切れ時の処理」といった例外ケースも、この段階で洗い出しておくことが大切です。
図を見て分かりにくい部分や、「実際にはこういうケースもある」と気づいた点があれば、遠慮なく開発会社に伝えましょう。この段階で認識を合わせておくことが、後の手戻りを防ぐことに繋がります。
ステップ4｜機能要件の決定
機能要件とは
機能要件とは、システムが持つ具体的な機能のことを指します。例えば、ECサイトであれば「商品検索機能」「カート機能」「決済機能」「注文履歴機能」といったものです。
業務を改善するための「道具」の部分と考えると分かりやすいかもしれません。システムで「何ができるようになるか」を定義するのが、機能要件です。
依頼側が判断する部分
機能要件の決定では、「どの機能が必要か」「優先順位はどうか」を判断していきます。すべての要望を最初から実装しようとすると、予算やスケジュールが大幅に膨らんでしまうことがあります。
そこで、機能に優先順位をつけることが重要になります。一般的には、以下のような分類が用いられます。
- Must（必須）：これがないとシステムとして成り立たない機能
- Should（重要）：できれば最初から実装したい機能
- Could（任意）：あると便利だが、予算や期間に余裕があれば検討する機能
例えば、予約システムであれば、「予約受付機能」「予約確認機能」はMust、「キャンセル待ち機能」はShould、「顧客分析ダッシュボード」はCouldといった具合です。
開発会社から「この機能は実装が難しいが、こういう方法なら実現できる」といった代替案が提示されることもあります。その際は、目的を達成できるかどうかという観点で、柔軟に検討すると良いでしょう。
ステップ5｜非機能要件の決定
非機能要件とは
非機能要件とは、機能以外の「品質」や「性能」に関する要件のことです。システムがどれだけ快適に、安全に、安定して動作するかを定義します。
具体的には、以下のような項目が含まれます。
- 性能：処理速度、表示速度、同時に何人が使えるか
- セキュリティ：データの暗号化、アクセス制限、個人情報保護
- ユーザビリティ：操作のしやすさ、画面の見やすさ
- 拡張性：将来的な機能追加やユーザー数増加への対応
- 保守性：運用後のメンテナンスのしやすさ
機能要件に比べて見落とされがちですが、非機能要件はユーザーの満足度やシステムの安定性に大きく影響します。
依頼側が決める項目
非機能要件を決める際、「速い」「使いやすい」といった抽象的な表現では、開発会社と認識がズレる可能性があります。できるだけ具体的な数値や条件で合意することが大切です。
例えば、以下のように具体化します。
- 「速い」→「検索結果が3秒以内に表示される」
- 「たくさんの人が使える」→「同時に100人がアクセスしても問題なく動作する」
- 「安全」→「クレジットカード情報は保存せず、決済代行サービスを利用する」
特にセキュリティについては、業界や取り扱うデータの種類によって求められる水準が異なります。個人情報を扱う場合や、法規制への対応が必要な場合は、開発会社と相談しながら適切な対策を定義しましょう。
また、将来的にユーザー数が増えたり、機能を追加したりする可能性がある場合は、拡張性についても検討しておくことをおすすめします。
開発会社と一緒に決めていく部分
非機能要件は技術的な知識が必要な領域も多く、すべてを依頼側だけで決めることは難しい場合があります。「このくらいの性能が欲しい」という希望を伝えると、開発会社が技術的な実現方法やコストとのバランスを提案してくれます。
例えば、「同時接続数1000人に対応したい」という要望に対して、「初期は100人対応で構築し、必要に応じてサーバーを増強する方がコストを抑えられる」といった代替案が出ることもあります。
ステップ6｜工数見積もりとスケジュール設定
このステップで決まること
機能要件と非機能要件が固まったら、開発会社が開発にかかる工数と期間を算出します。ここで、プロジェクト全体のスケジュールと予算が明確になります。
見積もりには、要件定義の内容が大きく影響します。機能が多ければ多いほど、また非機能要件の水準が高いほど、工数と費用は増加します。
依頼側が確認しておくこと
見積もりとスケジュールを確認する際、以下の点を開発会社と共有しておくと良いでしょう。
- 希望する稼働開始時期：「〇月までにリリースしたい」といった期限がある場合
- 予算の制約：予算に上限がある場合は、その範囲で実現できる内容を相談する
- 社内のリソース：レビューや確認作業に割ける時間や人員
もし見積もりが予算を超えてしまった場合は、機能の優先順位を見直したり、段階的なリリース（最初は基本機能のみで、後から追加開発）を検討したりすることもできます。
また、スケジュールには、依頼側の確認やレビューにかかる期間も含まれます。社内の意思決定に時間がかかる場合や、繁忙期で確認作業に時間を割けない時期がある場合は、事前に伝えておくとスケジュール調整がしやすくなります。
ステップ7｜要件定義書の作成と合意
要件定義書の役割
ここまでのステップで決めてきた内容を、開発会社が「要件定義書」という文書にまとめます。要件定義書には、一般的に以下のような項目が記載されます。
- システム開発の目的
- 現状の課題
- システムの全体像
- 機能要件
- 非機能要件
- 工数・見積もり
- スケジュール
- 開発体制・連絡体制
- セキュリティ対策
要件定義書は、依頼側と開発会社の間で「何を作るか」の認識を揃えるための重要な資料です。以降の設計・開発・テストすべての工程で、この文書が基準となります。
依頼側が確認するポイント
要件定義書が完成したら、内容をしっかりと確認しましょう。確認する際のポイントは以下の通りです。
- 記載内容が自分たちの意図と合っているか：特に、機能要件や業務フローが実態と一致しているかを確認
- 分かりにくい部分はないか：専門用語や技術的な説明で理解できない箇所があれば、遠慮なく質問する
- 抜け漏れはないか：話し合いで決めた内容が、きちんと文書に反映されているか
要件定義書は、後からの変更も可能ですが、開発が進むほど変更コストが大きくなります。この段階で、できるだけ認識のズレを解消しておくことが大切です。
変更が必要になった場合のルール
プロジェクトが進む中で、「やはりこの機能も追加したい」「仕様を変更したい」といった要望が出てくることもあります。その際の変更管理のルール（どのように変更を依頼するか、追加費用やスケジュール調整はどうなるか）を、この段階で確認しておくと安心です。
要件定義書の内容に納得し、責任者が承認したら、いよいよ次の設計・開発フェーズに進みます。
認識を合わせるための工夫
要件定義をスムーズに進めるために、文書だけでなく視覚的な資料を活用することも有効です。
ワイヤーフレームやプロトタイプの活用
ワイヤーフレームとは、画面の配置や構成を簡単な線画で表したものです。デザインは施さず、白黒の表示になっています。「どこにボタンがあるか」「どのような情報が表示されるか」を視覚的に確認できます。
プロトタイプは、実際に動かせる試作版です。ボタンをクリックすると次の画面に遷移するなど、操作感を体験できます。
文書だけでは「こんなはずじゃなかった」となりがちな部分も、ワイヤーフレームやプロトタイプを見ながら確認することで、認識のズレを防ぐことができます。
特に、画面の使いやすさや操作の流れが重要なシステム（ECサイト、予約システム、社内業務システムなど）では、早めにワイヤーフレームを作成してもらい、関係者で確認することをおすすめします。
定期的なコミュニケーション
要件定義は、一度決めたら終わりではなく、段階を追って内容を詰めていくプロセスです。途中で疑問に思ったことや、気になることがあれば、早めに開発会社に相談しましょう。
「こんなことを聞いていいのかな」と遠慮する必要はありません。むしろ、小さな疑問を放置しておくと、後で大きな認識のズレに繋がることもあります。
定期的なミーティングを設定し、進捗を確認しながら進めていくと、安心してプロジェクトを進められます。
社内の確認体制
要件定義では、さまざまな判断が必要になります。そのため、「誰が最終的な判断をするのか」を事前に決めておくことが大切です。
また、現場担当者と経営層の意見が分かれた場合、どのように調整するかも考えておくと良いでしょう。開発会社とのやり取りがスムーズになりますし、プロジェクト全体の意思決定も早くなります。
まとめ
要件定義は、システム開発プロジェクトの土台を作る重要な工程です。7つのステップを通じて、依頼側と開発会社が一緒に「何を作るか」を明確にしていきます。
各ステップで、依頼側には情報提供や確認、判断といった役割がありますが、技術的な専門知識は開発会社がサポートしてくれます。分からないことや不安なことがあれば、遠慮なく質問し、納得しながら進めることが、プロジェクト成功の鍵となります。
オプスインでは、これまで多くの企業様のシステム・アプリ開発をサポートしてきました。要件定義の段階から丁寧にヒアリングし、お客様と一緒に最適なシステムを作り上げていきます。システム開発、アプリ開発をご検討の際は、お気軽にご相談ください。
