要件が決まらないまま開発を始めると、何が起きるのか
機能を考える前に決めておきたい、課題と優先順位
プロジェクトが迷走するのは、要件定義書が短いからではありません。解決すべき課題、優先順位、そして何をもって完了とするのかについて、関係者の合意がないまま開発を始めてしまうからです。要件とは、単なる機能一覧ではありません。プロジェクトの方向が揺れたときに、何度でも立ち戻って確認するための判断基準です。
1. 「まずは開発を始めよう」と決めた瞬間
多くのプロジェクトは、次のように始まります。
依頼する側は、できるだけ早く成果物を見たいと考えます。会議を重ねるより、実際の画面を見ながら話したほうが早そうに思えるからです。
要件を整理する側は、細かな内容は作りながら決めればよいと考えます。すべてを先に決めようとすると、着手が2週間遅れてしまうからです。
開発する側は、曖昧な部分を自分なりに解釈して実装します。質問することはできますが、そのたびに回答を一日待たなければならないこともあります。
そして3週間後、中間成果物が完成します。その確認の場で初めて、関係者がそれぞれ違う完成形を想像していたことが明らかになります。
ここから修正が始まります。最初は一つの機能を直すだけだったはずが、やがて「では、これはなぜこのようになっているのですか」という根本的な質問に戻ります。スケジュールは遅れ、同じ内容の会議を3回繰り返すことになります。
この状況で、誰かが仕事を怠っていたわけではありません。依頼した人も、要件を整理した人も、開発した人も、それぞれの立場で合理的に判断していました。ただし、判断基準がそれぞれ異なり、その違いを確認する機会がなかったのです。
2. 要件がないことと、資料がないことは同じではない
要件定義を「資料を作成する仕事」だと考えると、資料が厚くなるほど安全だと思いがちです。しかし、実際はそうではありません。
- 資料が30ページあっても、なぜ作るのかが書かれていないことがあります。
- すべての画面設計が完成していても、その画面によってどのような問題を解決するのかが説明されていないことがあります。
- 機能一覧が長くなるほど、何を優先すべきかが見えにくくなることもあります。
要件の本質は、資料の量ではありません。チーム全員が、同じ課題と同じ成功基準を共有している状態をつくることです。そのため、依頼された言葉をそのまま書き写すのではなく、一度その背景を問い直す必要があります。
| 依頼された機能 | 実際に確認すべきこと |
|---|---|
| 検索機能を追加してください | 利用者は今、何を見つけられずに困っているのか。見つけられないことで、どのような問題が起きているのか |
| 管理者ページが必要です | 誰が、どの業務を、一日に何回処理するのか |
| 通知を送る必要があります | どのような状況で、誰に、どのような行動を促す必要があるのか |
左側に書かれているのは「解決方法」であり、右側に書かれているのが「要件」です。この二つを区別しないまま開発すると、検索欄は完成したものの、利用者は相変わらず必要な情報を見つけられないという結果になります。機能は完成しているのに、課題は解決されていない状態です。
3. 合意せずに始めると繰り返される5つの問題
① 人によって異なる成果物を想像する
「顧客管理画面」という同じ言葉を聞いても、ある人は顧客一覧と検索機能を、別の人は対応履歴の管理や集計機能まで想像します。実際の画面を見るまでは、お互いに同じ内容について話していると思っています。
② 優先順位がなければ、すべての機能が必須になる
何から作るのかを決めていなければ、スケジュールが足りなくなったときに、どの機能を外すべきか判断できません。その結果、すべての機能が少しずつ未完成のまま、納期を迎えることになります。
③ 開発中の意思決定が増え、手戻りが発生する
実装中に判断が必要になると、開発担当者が一時的に判断するか、回答が来るまで待つことになります。一時的な判断は後から覆され、回答を待つ時間はそのままスケジュールの遅れにつながります。
④ 完了基準がなければ、検収が終わらない
「どのような状態になれば完了なのか」を決めていなければ、検収の場が新しい意見を出す場になってしまいます。すべて作り終えたはずなのに承認されないプロジェクトの多くは、完了基準が定められていません。
⑤ 遅延の原因が個人の責任にされる
判断基準がなければ、何が遅延を引き起こしたのかを説明することもできません。その結果、遅延の原因が担当者個人の問題として処理されがちです。実際には、意思決定の仕組みや情報不足に原因があった場合でも同じです。
4. 機能より先に決めるべきこと
開発を始める前に合意すべきなのは、機能一覧ではありません。次の7つの問いに対する答えです。
- 私たちが解決したい課題は何か
- その課題を最も強く感じている利用者は誰か
- どのような変化が起きれば、課題を解決できたと判断するのか
- 今回、必ず含める範囲は何か
- 今回は作らないものは何か
- スケジュール、予算、技術、社内ルール上の制約は何か
- 意見が分かれたとき、最終決定を行う人は誰か
ここで「それでは、すべてを決めてから開発を始めなければならないのか」と思われるかもしれません。そうではありません。
最低限の合意事項は、課題、利用者、目標、優先順位、完了基準です。これらは開発を始める前に決めます。
詳細設計は、画面構成、表示する文章、例外処理、細かなルールなどです。これらは、作りながら決めても構いません。
両者を区別する基準は簡単です。後から変更するとプロジェクトの方向まで変わるものは先に決め、後から変更しても方向が変わらないものは後で決めます。目標が変われば、それまでに作ったものの大部分が影響を受けます。一方、ボタンの文言を変更しても、変わるのはその文言だけです。
5. 開発前に整理しておきたい7つの最低要件
新しいプロジェクトを始めるときは、A4用紙1枚で十分です。次の7項目を埋めることを目標にしてください。
| 項目 | 記入する内容 |
|---|---|
| 1. 課題 | 現在、どのような不便や損失が発生しているか |
| 2. 利用者 | 誰が困っているのか。何人がその問題を経験しているか |
| 3. 目標 | 何が、どのように変わる必要があるか |
| 4. 対象範囲 | 今回の開発に含めるものは何か |
| 5. 対象外 | 今回は作らないものは何か |
| 6. 優先順位 | 絶対に必要なものと、後から追加してもよいものは何か |
| 7. 完了基準 | どのような状態になれば、完了として承認するか |
担当者、意思決定者、スケジュール、技術上の制約、連携する既存システムについては、この表の横に別途記載します。7項目の中で、特に空欄になりやすいのが、5番の「対象外」と7番の「完了基準」です。そして、プロジェクトが長期化する原因も、多くの場合この二つにあります。
6. 同じ依頼内容を書き直してみる
実際のプロジェクトでよく見られる依頼内容をもとにした例です。
整理後の文章には、次の5つの情報が含まれています。
- 課題 — 顧客を見つけるまでに時間がかかる
- 利用者 — カスタマーサポート担当者
- 目標 — 1分以内に見つけられる
- 対象範囲と対象外 — 検索と履歴確認は作り、Excelへの書き出しと顧客分類は作らない
- 完了基準 — 5人の担当者が20件の顧客事例を見つけられれば完了
最初の文章だけで開発を始めると、担当者によって異なる機能を作る可能性があります。整理後の文章から始めれば、異なる解釈が生まれる余地はほとんどありません。文章の長さは3倍になりましたが、必要な会議は半分になります。
7. 要件を変更するときに守りたい原則
要件は変わるものです。実際に使って初めて分かることもあれば、市場環境が変化することもあります。変更すること自体は失敗ではありません。変更が与える影響を確認しないまま進めることが問題です。
- 変更する理由を一文で記録する — 3か月後には、誰も理由を覚えていない可能性があります。
- 変更する機能だけを見ない — スケジュール、費用、品質にどのような影響があるのかも確認します。
- 追加するものがあれば、今回外すものも決める — 機能を追加するだけでは、スケジュールは必ず遅れます。
- 誰が、いつ承認したのかを記録する
- 変更内容を、関係者全員へ同じ文章で共有する — 一人でも認識していない人がいれば、その部分から再びずれが生じます。
この5つを守れば、要件変更は事故ではなく、根拠のある意思決定になります。
8. 開発着手前の10分チェックリスト
着手会議の最後の10分間に、次の10項目を関係者全員で確認してください。一つでも空欄があれば、その項目が今回のプロジェクトで最初に問題になる可能性があります。
- 解決する課題を一文で説明できる
- 主な利用者が誰なのか明確になっている
- 期待する成果が定義されている
- 必須機能と任意機能が区別されている
- 今回は対応しない範囲が記載されている
- 完了したかどうかを判断する基準がある
- 技術、スケジュール、社内ルール上の制約を確認している
- 最終的な意思決定者が決まっている
- 変更依頼を記録する場所が決まっている
- 参加者全員が同じ内容を確認している
ご参考 · あたたかいデジタルでは、この作業を診断段階で行います
私たちは、依頼された機能をそのまま見積もることはしません。まず、60分の無料相談で現在のお悩みを伺います。その後の診断段階で、上記の10項目をお客さまと一緒に整理し、課題診断レポート、画面設計、機能の優先順位、3つの問題解決方法をご提供します。その後の検証段階では、最も重要な機能を一つだけ実際に作り、現場で使用していただきます。
診断結果の資料は、お客さまの資産です。診断だけで終了しても構いませんし、その資料を別の開発会社へ持ち込んでいただくこともできます。各段階の終了時に、次へ進むかどうかをご判断いただきます。途中で終了しても、追加料金は発生しません。
会社によって見積金額に大きな差が生まれる理由も、最終的にはこの要件の整理に関係しています。詳しくは開発の見積もりが会社によって2〜3倍も違う理由でご紹介しています。
まとめ
要件を決めることは、これから起きるすべての変化を事前に予測することではありません。今解決すべき課題と優先順位、そして何をもって完了とするのかを、チーム全員で決めることです。
この合意に時間を使うことで、開発着手が数日遅れることはあります。それでも、多くの場合は先に合意したほうが早く完成します。後から減らせる手戻りや会議の時間が、最初に使った数日間を上回るからです。
次回のプロジェクト着手会議では、まず画面にこの10項目のチェックリストを表示し、関係者全員で読み合わせることから始めてみてください。
何を作るか決める前に、
何を作らないか決めることが大切です。
チェックリストの空欄を埋められない場合、解決すべき課題がまだ一文で整理されていない可能性があります。
あたたかいデジタルでは、開発をおすすめする前に、今回作らないものからお客さまと一緒に決めていきます。
ご相談は60分無料で、何度でもご利用いただけます。事前にご用意いただく資料もありません。
まだ考えが整理されていない状態のまま、お越しいただいて構いません。
あたたかいデジタル · 迅速開発
人のための、あたたかいデジタル体験を。あたたかいデジタルがつくります。
※ 第6章の顧客管理の事例は、複数のプロジェクトでよく見られる内容をもとに構成した例です。特定のお客さまやプロジェクトを紹介したものではありません。
※ この記事の判断基準は、あたたかいデジタルにおけるプロジェクト経験に基づくものです。業界の統計や調査結果ではありません。手戻り率など、検証可能な出典のない数値は使用していません。