要件定義のハマりどころ
生成AIで「雛型」は作れるけれど
最近では生成AIの活用が広がり、プロジェクトで揃えるべき「雛形」を作成することは以前よりも容易になりました。
GEAR.indigoなどを使えば自然言語からプロジェクトの全体設計を出力することができますが、とはいえそれを実際に「実装して世に出す」までには要件定義時点で押さえておかなければならないことが複数あります。（一応補足しておきますがこれはGEAR.indigoがダメということではなく、素晴らしいプロダクトです）
当たり前ですが「抜け漏れがある要件定義で進めよう」とする人はいません。
ただ、「考慮漏れ」というのは「漏れていることを認識できない」から発生するもの。
このあたりを網羅的に設計できるかが「経験」によるところが大きかったのですが、今回はそれを少しでも言語化できたらなと。
この記事を読むべき人
- いわゆる「上流工程」を初めて任されたエンジニア
- 自社サービスを通じて顧客に価値提供をしたいプロダクトオーナー
要件定義についてのおさらい
要件定義は、ユーザーの業務やビジネス目標を理解し、それをシステムの仕様に落とし込むプロセスです。これには、プロジェクトの全体像を明確にし、関係者全員の合意を得ることが求められます。
システム開発において、要件定義はプロジェクトの成否を左右する重要なフェーズです。しかし、多くのプロジェクトで要件定義が「ハマりどころ」となり、スケジュールの遅延や仕様漏れの原因となることが少なくありません。
以下、要件定義プロセスの主要ステップとその「ハマりどころ」を解説します。
プロジェクト概要
目的：
プロジェクト（サービス）の背景、目標、範囲、制約条件を明確化すること。
ハマりどころ：
-
目的不明：クライアントの指示が曖昧な場合、システムの方向性が定まらず迷走するリスクがあります。
- 対策: プロジェクト憲章やコンセプト資料を作成し、関係者の合意を早期に形成する。
- ステークホルダー間で微妙にゴールがズレているケースがあるので公式の場だけでなく非公式の場で本音ベースでの「プロジェクトの理由」みたいなのを拾えているとGood
「とりあえず予算消化でなんか作ってみて」みたいなパターンも（残念ながら）ある
-
範囲の膨張：「ついでにこれも」という要求が増え、スコープが拡大する問題。
- 対策: スコープの明確化と、範囲外の要求に対する対応ルールを設ける。
- 夢ばかり大きいが具体的なことは何も決まってないケースも多い。創業者はそれで良いかもしれないが実際に推進していく立場としてはきちんと具体化してやれるべき「現実」に一つ一つ落とし込んでいくことが重要。
現行業務フロー
目的：
現在の業務プロセスを正確に把握し、改善点を抽出する。
ハマりどころ：
-
現場ヒアリング不足：現場担当者へのヒアリングが不十分だと、重要な業務や課題を見逃すリスクがあります。
- 対策: ヒアリングガイドを用意し、現場担当者を巻き込んだ詳細な業務分析を行う。
- 「なんとなくMTG設定してみました」みたいな巻き込み方だと現場側の時間ばかり食って有益な知見が得られないことがあるのでヒアリングする項目は「仮説を持って」臨むこと。
- 仮説は間違っていても良いが、間違っている仮説でもあるとそこを起点に話が進みやすい
- とくに「今までシステムでやっていなかったところ」が抜けやすい。システム化プロジェクトだと「PCでやっていた業務」という枠にとらわれがちなので注意
- 自社サービス（特にtoC）とかだと「ユーザーが正確に課題を言語化できている」とは限らないので、例えばアンケート項目設計などの手法を学んである程度「形にはまった意見の吸い上げ方」をすることが重要
-
非公式プロセスの見落とし：現場で実施されているが、正式には記録されていないプロセスが抜け落ちる。
- 対策: インタビューだけでなく、実際の業務観察や文書レビューを実施。
- 「例外処理の手動プロセス」と称する手動運用が抜け落ちるパターンが多い。（例外処理こそ頻度の高い主導フローとなっているケースもある...）
業務要件一覧
目的：
業務のニーズや課題を洗い出し、要件として整理する。
ハマりどころ：
-
要件の曖昧さ：「効率化したい」「顧客満足度を向上させたい」といった抽象的な要件が多い。
- 対策: SMART（具体的・測定可能・達成可能・関連性・時間軸）の基準に従い要件を具体化。
- 定量目標や計測可能な指標がないと成果物の品質をめぐって水掛け論になりやすい
- 特にデータサイエンス系で揉めるケースが多い。
- 「見える化されたのはわかったんだけどさ、結局うちにしか持ってないような魔法の指標がないことがわかっただけじゃん」
- 特にデータサイエンス系で揉めるケースが多い。
-
優先順位付けの欠如：すべての要件を平等に扱い、重要度が不明瞭になる。
- 対策: must-have と nice-to-have は分ける
- 最初の方のnice-to-haveは思い切って落としてしまった方が良い
- 契約の巻き方によるが継続開発でイテレーティブにnice-to-haveも実現しますよ、みたいな見せ方がベスト
システム化業務フロー
目的：
業務要件をもとに、システムで実現するプロセスを設計する。
ハマりどころ：
-
業務とシステムの乖離：現場の業務が理解されず、実際の運用に適さない設計になる。
- 対策: 業務フローを具体的にモデリングし、ユーザーとの確認を繰り返す。
-
手作業のブラックボックス化：一部の業務がシステム化されず、手作業が温存される。
- 対策: 手作業のプロセスも見直し対象とし、可能な限り自動化を検討。
- CSVを手元でちょちょっと担当者が加工して既存システムに入れてる、みたいなところは漏れやすい
-
外部連携の考慮不足: 後ろで実は外部システムと連携していたのにヒアリングできておらず考慮が漏れる
- 対策: 既存システムがある場合は外部連携を行っているかどうかをヒアリングする。
- 「このデータフォーマットだとうちの管理会計パッケージに入らないんだけど？」
- 担当者がCSVちょっといじるパターンとコンボで発生することがある
- 外部連携ではRDBのトランザクションを使えないケースが多いので、リトライやロギング、フォールバックの考慮をする
- HTTP通信はよく失敗する
機能要件一覧
目的：
システムで実現する機能を具体的に定義する。
ハマりどころ：
-
過剰な機能設計：実際に使われない機能を多く盛り込み、コストや開発工数が膨らむ。
- 対策: ユーザーストーリーやペルソナを活用して、必要な機能にフォーカス。
- 予算が限られるケースでは「業務時間の削減」への影響度が低い一部のフローは手動で残すなどの判断が必要
- 全自動化が本当に必要なケースは多くない
-
ユーザー視点の欠如：ユーザーの使い勝手を軽視
- 対策: プロトタイプを活用し、ユーザーから早期にフィードバックを得る。
- 今だとプロトタイピングをAIでできるので積極的に使っていくと良さそう
非機能要件一覧
目的：
性能、可用性、セキュリティなど、システム全体の品質を定義する。
ハマりどころ：
-
性能要件の過小評価：アクセス数やデータ量の増加を見越さない設計。
- 対策: 将来の拡張性を考慮したシステム設計を行い、性能テストを実施。
-
とはいえ、全てのケースで無限のスケーラビリティが必要ではない。 社内システムで「1000万アクセスに耐えうるアーキテクチャ」は必要ではない（場合が多い）
- 「どのくらいのユーザーが使う想定か？」みたいな問いを当ててみると良い
- 機能によっても必要とされる性能要件は異なる
- e.g. ECサイトで商品ページを表示するのに3秒かかるのと、月次の給与計算バッチが5時間かかるのでは前者は受け入れられないが後者は受け入れられる可能性は高い
-
曖昧なセキュリティ要件：「セキュリティを強化」といった抽象的な表現に留まりがち。
- 対策: 実装すべきセキュリティ基準を明確化し、具体的な対策を設計に盛り込む。
- 全てのケースでガチガチなセキュリティが求められるわけではない。業務影響度と工数のバランスをとった設計をする。
- e.g.BtoBの管理者権限だと多要素認証が必要だけど、ToCで絶対に必要ではない、等
まとめ
要件定義は、システム開発の土台を築く極めて重要なフェーズです。そのため、「目的の不明確さ」「現場理解の不足」「曖昧な要件」などの典型的なハマりどころを回避するための対策が不可欠です。この記事で紹介したポイントを参考に、堅実かつ効率的な要件定義を実現してください。
株式会社CodeKnightsは
「生成AI時代の、変化の激しい環境を勝ち残るためのWebサービス開発」
を専門として活動しています。
お仕事のお問い合わせはこちらから↓
参考リンク
- GEAR.indigo https://gearindigo.app/
参考書籍
システムを作らせる技術 エンジニアではないあなたへ
ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた
その他の人気記事
SNSアカウント
X(Twitter)
note
Discussion