初めての要件定義で学んだ『不確実性』の潰し方

1. はじめに

私は、現在参画しているプロジェクトで初めて要件定義を経験しました。今まで基本設計以降の工程にしか携わったことがなかったので、実際に経験する中でPM/PLの進め方を間近で見て、多くの学びがありました。本記事では、これから要件定義を初めて経験する同じような境遇の方に向けて、要件定義の中で私が実践して手応えを感じたことや、逆に苦労した反省点を「不確実性をどう潰すか」という切り口で共有します。

2. プロジェクト概要

本プロジェクトの内容は、新規開発ではなく既存Webアプリに対する機能追加です。体制としては、PMの配下に「アプリチーム」と「インフラチーム」が編成されており、私はアプリチームのSEを担当していました。

3. 要件定義の中で意識したこと

要件定義を振り返り、要件定義の目的は、プロジェクトの成功に向けて、プロジェクトの初期段階で不確実性を減らすことだと感じました。
私が今まで経験してきた設計工程以降では、要件はある程度決まっており、「具体的にどのように実現するか」という部分にフォーカスしていました。しかし要件定義では、そもそも何を実現すべきか、という部分から議論する必要があり、お客様の要求や期待が曖昧なことが多いです。また不確実性と一言で言っても、技術的な不確実性、要件の不確実性、スケジュール的な不確実性など様々な側面があります。要件定義をスムーズに進行させるためには、こういった不確実性を早期に減らすことがプロジェクトの成否を左右しました。
本記事では、私が意識したポイントを技術（外部連携や既存制約）、要件（スコープや優先順位）、スケジュール（依存関係と意思決定）の3つに分けて整理します。

技術的な不確実性を減らす

プロジェクトによって明らかにするべき不確実性は変わると思いますが、本プロジェクトでは以下の2つについては特に不確実性が高い、かつ先に確定させておかなければ後工程に大きな影響を及ぼす、極めて重要な要素でした。

• 外部連携方式を確定し、技術検証を実施する
• 既存システムを理解し、制約を把握する

外部連携方式を確定し、技術検証を実施する

内部のシステムであれば、設計次第でどうにかなることも多いですが、外部連携の場合は、相手先のシステムやサービスの仕様に依存するため、要件定義の段階で外部連携方式を確定し、技術検証まで済ませておくことが後工程への影響を大きく左右します。

外部連携には、大きく分けて以下の2種類があります。

• 外部サービス（クラウドサービスやSaaSなど）
• 外部システム（他社が開発・運用しているシステム）

要件定義で押さえる観点も、この2つで少し異なります。外部サービスは「そのサービスで要件を満たせるか」が中心で、外部システムは「インターフェースと責任分界、異常系を含めた運用をどうするか」が中心になります。

外部サービス（クラウドサービスやSaaSなど）の場合

候補が複数ある場合は、各サービスの機能比較や簡易検証を早めに行い、判断材料としてお客様に提示することで意思決定を進めやすくなりました。また、候補が1つに絞れた後も、設計に入る前に技術検証を行い、要件を満たせることを確認しておくことで手戻りを防げました。
具体的には外部の認証サービスを利用する際、APIのエラーコードごとの挙動やタイムアウト時の扱いなどを先に確認し、ベンダーへの仕様確認とお客様への共有を行うことで、後工程もスムーズに進められました。

外部システム（他社が開発・運用しているシステム）の場合

外部システムは別ベンダーが開発していることが多く、連携方式だけでなく、責任分界や調整プロセスまで含めて整理しておく必要がありました。要件定義の段階で確認しておきたい主な観点は以下です。

• インターフェースの仕様の確認
  • どのようなAPIが提供されているのか
  • どのようなデータが送受信されるのか
  • どのような認証方式が必要なのか
  • どのように通信するのか
• 異常系の挙動の確認
  • リトライ実行するか
  • 外部システムダウン時の対応
  • エラーコードごとにどのような挙動になるのか

外部連携を検討する際は、正常系だけでなく異常系についても早い段階で方向性を揃えておくことが重要でした。例えば「外部サービス／外部システム側が停止した場合でも業務を継続したい」といった要望がある場合、代替案や運用でのカバーを含めて検討が必要になります。私は当初、これらは設計フェーズで詰める内容だと思っていましたが、実現可否やスコープに直結するため、要件定義の段階で論点として扱い、合意しておく必要があると学びました。

本プロジェクトでは、外部ベンダーと複数回ミーティングを設け、スケジュールや連携方式について認識を合わせ、技術検証まで実施することで、設計工程以降も問題なく進められました。
特に苦労したのは、セキュリティ要件とシステムの制約の板挟みです。既存システムとの連携方式で暗号化トークン方式を採用した際、『既存システムのバックエンドが改修不可』という制約がありました。通常ならバックエンドで暗号化を完結させたいところを、フロント側で公開鍵を保持する構成の安全性を検討するなど、「教科書通りにいかない現場の制約の中でどう最適解を出すか」という議論が要件定義の醍醐味であり、この議論をスムーズに進めることができるかが、プロジェクトの成功を左右すると感じました。

既存システムを理解し、制約を把握する

既存システムの理解と制約の把握は、要件定義段階で欠かせない作業でした。

アプリケーション

アプリケーションにおいては、既存システムの技術スタックやアーキテクチャを把握し、要件定義段階で使用できる技術やライブラリ、フレームワークを明確にしておくことが、後のライブラリ選定や設計判断の前提になります。本プロジェクトにおいては、使用されている技術スタックが古いため、「使用したいライブラリが対応しているか」を確認する必要がありました。また既存機能改修の場合には、デグレのリスクがあるため、既存機能の挙動や制約を把握し、要件定義段階で新しい要件が既存機能に与える影響を調査し、リグレッションテストの範囲を明確にしておくことで、テスト工程の見積もり精度が上がります。

インフラ

インフラにおいても、既存システムのインフラ構成や運用体制を把握し、初期段階で利用できるクラウドサービスや運用方法の前提を整理しておく必要がありました。 特に、既存のクラウドサービスの利用状況を確認したうえで、追加で必要になりそうなサービスは早い段階で洗い出し、お客様と認識を合わせておくと後工程が進めやすくなります。理由としては、インフラ構成はコストに直結し、設計に入ってから大きな変更が発生すると、予算の見直しや代替案検討が必要になりやすいからです。例えば今回のプロジェクトでは、外部APIに対して一時的にリクエストが集中し得る要件がありました。そこで、クラウドのキューイングサービスやサーバーレス関数を用いて処理を非同期化・分散し、レート制限を回避しつつUXを維持する方針を早期に決めました。もしこの方針を後から追加する形になると、コスト面の調整や構成見直しに時間がかかり、場合によっては機能自体のスコープ調整も発生し得ます。今回は初期段階でインフラ構成の方向性を大まかに固め、予算感やシステムイメージとの乖離が出ないように揃えていったことで、以降の検討をスムーズに進められました。

要件の不確実性を減らす

要件の不確実性を減らすために以下のことを実施しました。

お客様と認識を密に合わせる

要件定義では、お客様の要求や期待が曖昧なことが多いため、お客様との認識合わせを密に行うことが、後半の手戻りを防ぐ鍵でした。プロジェクトの初期段階では、ミーティングの機会を多めに設け、既存システムの理解を深め、認識齟齬を早期に潰すことを意識しました。

要件に優先順位を付け、スコープを明確化する

要件定義の初期段階では、お客様から多くの要望が挙げられましたが、すべてを実現することは難しいため、要件の優先順位付けを行うことが重要でした。今回対応を実施しない要件についても、次のフェーズで対応する可能性があることを伝え、将来的に対応する可能性があることを明確にしておくことで、お客様の期待値をコントロールすることも重要でした。
ただ、今回は要件の優先順位付けは行いましたが、スコープの明確化と変更管理のプロセスが十分に整備されていなかったため、要件定義の後半の段階で、スコープに関する認識のズレが発生しました。特に外部システムとの連携がある場合、担当範囲の変更が発生しやすく、また、境界についても曖昧なことが多いです。要件定義の後半で、既存サーバからデータがバッチで同期されてくるという要件がありましたが、自分たちの担当であることを認識しておらず、要件定義の後半になってから初めて認識のズレに気づきました。ミーティング内で要件の読み合わせを実施したり、全体構成図を作成したりして各社のスコープの境界を明確にし、スコープに対する認識合わせをより積極的に行うべきでした。

プロトタイプやポンチ絵を活用し、認識齟齬をなくす

要件定義の過程でお客様の要求や期待が曖昧な場合には、例えば、画面イメージや操作フローを簡単なプロトタイプとして作成してお客様に提示することで、具体的なイメージを共有し、要件の確認を行いました。これにより、お客様の要求や期待を明確にし、要件定義の精度を高めることができました。また、内部で議論する場合も同様に、論点を整理したスプレッドシートや、ポンチ絵、シーケンス図などを用いて認識合わせを行うことで、議論をスムーズに進行できました。

成果物の認識を合わせる

要件定義で作成する成果物についても、お客様との認識合わせを密に行うことが重要でした。例えば、要件定義書や仕様書のフォーマットを連携いただいたり、ドラフトを作成した後、早期にお客様に確認いただくことで、誤解や認識のズレを早期に発見・修正できました。これにより、最終的な成果物の品質を高められましたし、最終提出時の手戻りも減らせました。

スケジュールの不確実性を減らす

スケジュールの不確実性は、上述した技術的な不確実性・要件の不確実性に加えて、お客様や外部ベンダーの要望からも影響を受けるため、最も除去することが難しく感じました。

ただ、以下のようなことを意識することで、スケジュールの不確実性を減らすことができました。

リリーススケジュールを明確化する

どんなプロジェクトでもリリーススケジュールは存在すると思いますが、その中でも要件に優先順位付けを行い、

• マストで対応しないといけない要件はどれか
• 段階的なリリースは検討できないか
• リリースの判断はどのように行うのか

などを要件定義段階で明確にすることが重要でした。

要件定義を進める中で、当初の想定よりも要件が増えることはよくあります。そのため、上記の論点については、こちらが主体となって議論をリードし、判断の進め方まで整理していくことが重要だと感じました。具体的には、要件の優先度を整理したうえで、追加分を次リリースへ回す選択肢も含めて提示し、判断に必要な情報を揃えた状態で意思決定できるようにすることで、炎上リスクを抑えやすくなります。

外部ベンダーとのスケジュールを調整する

本プロジェクトでは、外部システムとの連携がありました。多くの場合、外部システム側も同時に開発・改修を行っていることがあるため、ベンダーのスケジュールを把握しておく必要があります。外部システムとの連携はお互いがスケジュールを把握しておかないと、「片方の設計が遅れている影響で、もう片方の設計も進められない」や、「機能を追加したいが、ベンダー側がすでにテスト工程に入っているため対応不可」ということが起こり得ます。そうなるとプロジェクトが炎上するリスクが高まるため、要件定義段階で外部ベンダーと密にコミュニケーションを取り、スケジュールを把握しておくことが重要でした。

プロジェクトをリードする

お客様のタイプやスタンス、状況によっては難しい場合もあると思いますが、スケジュールを守るために一番大事なのは、こちらが主体となってプロジェクトをリードしていくことだと感じました。

本プロジェクトでは、要件定義の初期段階で、こちらが主体となって議題や論点を整理して、意思決定を促進する仕組みを作ることができませんでした。お客様もシステム部門の方で「やりたいこと」が明確にあり、内部的にも色々検討していただいていたことに甘え、あまりこちらから提案するというよりもお客様の意見を聞いて進める、という形になっていました。
結果、こちらの想定とは全く違う案になったり、議論が平行線になったりして、要件定義の進行が遅れてしまいました。また、これにより追加要件なども発生しやすくなり、スケジュールの不確実性が高まってしまいました。

要件定義の段階では、プロジェクトの成功に向けてこちらが主体となって議題や論点を整理し、意思決定を促進する動きがスケジュールの乱れを未然に防ぐと実感しました。そうすることで、スムーズに要件定義を進行できるだけでなく、お客様の要望も反映しつつ、スケジュールの不確実性も減らすことができると感じました。

4.まとめ

今回初めて要件定義を経験し、3つの観点から不確実性を潰すことの重要性を実感しました。
技術面では外部連携と既存制約を早期に確定することがその後の設計の土台になり、 要件面ではスコープと変更管理のプロセスを整備しないと後半に認識のズレが起きること、 スケジュール面ではこちらが主体的に議論をリードしなければ判断が止まり続けることを学びました。
本プロジェクトは既存システムへの機能追加でしたが、新規開発プロジェクトの場合はこれ以上に考慮することが多いと思います。

私は初めて要件定義を経験することで、システム作りの最初の工程で議論されていること、考えないといけないことが自分の中で明確になりました。また、当記事執筆時点では開発・テストフェーズに入っていますが、「当時は意識していなかったけど、今振り返れば要件定義でお客様と確認しておいてよかった」と思うことも多々ありました。今後要件定義にチャレンジするときは、これらを意識して取り組みたいと思います。また、要件定義をこれから経験する方は、ぜひ不確実性を減らすことを意識し、プロジェクトの成功に向けて頑張っていただければと思います。