発注・外注の進め方
小規模開発の要件定義はどこまで必要？外注先と進めるちょうどいい決め方
「要件定義」という言葉には、分厚い設計書や長い打ち合わせのイメージがあるかもしれません。大規模なシステム開発ではそうした工程が必要ですが、小規模な業務用Webアプリや社内ツールでは、同じやり方をする必要はありません。一方で、何も決めずに始めると、完成後に「思っていたものと違う」が起こります。小規模開発に「ちょうどいい」要件の決め方とは、どの程度なのでしょうか。
小規模開発の要件定義のゴール
要件定義の目的は、文書を作ることではなく、発注者と開発会社が同じものを思い浮かべられる状態にすることです。そのために必要な分だけ決め、残しておけば十分です。
| 大規模開発 | 小規模開発 | |
|---|---|---|
| 主な成果物 | 詳細な要件定義書、設計書 | 画面一覧、機能一覧、業務の流れのメモ |
| 決め方 | 文書で網羅的に決めてから作る | 大枠を文書で決め、細部は動く画面を見て決める |
| 関わる人 | 多くの部署と担当者 | 窓口、最終判断者、現場の担当者が中心 |
残しておきたい6つの要件
1. 目的
何を解決するための仕組みか、どうなれば成功かを一文で書きます。迷ったときの判断の基準になります。
2. 画面一覧
必要な画面の名前と、それぞれの画面で何ができるかを一覧にします。「案件一覧：担当者とステータスで絞り込める」のように、一行ずつで構いません。
3. 機能一覧
登録、検索、通知、出力、承認、権限など、画面をまたいで必要になる機能を書き出します。優先度（最初の版に必要か、後回しか）もあわせて記録します。
4. データの項目
扱うデータごとに、記録する項目を書き出します。今使っているExcelや帳票があれば、それをもとにするのが確実です。必須項目、選択肢、入力の形式もここで決めます。
5. 業務の流れ
誰が、どの順番で、何をするのか。ステータスがどう変わるのか。承認がある場合は、誰が承認し、却下されたらどうなるのかを書きます。書き方はシステム化の前に業務フローを整理する方法で紹介しています。
6. やらないこと
今回の範囲に含めないことを明記します。後から「これも入っていると思っていた」というずれを防ぐ、効果的な一行です。
発注者が決めること、開発会社と決めること
| 発注者が決めること | 開発会社と一緒に決めること | 開発会社に任せてよいこと |
|---|---|---|
| 目的、業務のルール、やらないこと | 画面の構成、機能の優先順位、権限の設計 | 技術の選定、データベースの設計 |
業務のルール（ステータスの意味、承認の条件、計算方法など）は、開発会社には決められない部分です。逆に、技術的な選択まで発注者が決める必要はありません。社内で決めておくべきことの詳細は社内ツール開発を外注する前に決めておくべき7つのことにまとめています。
文章で決めきれない部分は「動く画面」で決める
画面の使い勝手や、入力の順番、一覧に出したい項目などは、文章でいくら議論しても決めきれないことがあります。こうした部分は、早い段階で実際に動く画面を作り、触ってみて決めるほうが確実です。
- 大枠を文書で合意する：目的、画面一覧、機能一覧、やらないこと
- 最初の版を作る：合意した範囲で、実際に操作できる状態にする
- 触って確認する：現場の担当者も含めて、使い勝手を確認する
- 合意した範囲内で調整する：文言、配置、操作の流れなどを直す
この進め方なら、要件定義に長い時間をかけずに、認識のずれに早く気づけます。
要件定義でよくあるつまずき
- 例外を網羅しようとして終わらない：頻度の低い例外は「当面は手作業で対応」と決めて先に進む
- 現場の担当者が関わらない：業務の流れは、実際に作業している人に確認する
- 言葉の意味がずれる：「対応中」「承認」などの言葉は、条件を一文で定義する
- 決めた内容が残っていない：打ち合わせで決めたことは、簡単でもよいので文書にして共有する
相談の前に用意しておくと早いもの
要件定義の出発点として、次のようなものがあると話が早く進みます。完璧である必要はありません。まとめ方はWebアプリ開発を依頼する前に準備するもの｜要件メモの書き方とテンプレートで紹介しています。
- 目的と、困っていることを書いたメモ
- 今使っているExcelや帳票（見本データ）
- 業務の流れを箇条書きにしたもの
- 参考にしたいサービスや、手書きの画面イメージ
要件を記録しておく形式
小規模な開発では、要件を残す形式に決まりはありません。大切なのは、関係者がいつでも参照でき、変更があれば更新されることです。
- 共有の文書：画面一覧、機能一覧、業務の流れを一つの文書にまとめ、関係者で共有する
- 表計算のシート：機能一覧や項目の一覧は、表にすると漏れや重複に気づきやすい
- 画面のイメージ：手書きの図や簡単な画面のイメージを添える
形式よりも、「どれが最新か」が分かることが重要です。打ち合わせで決まったことを反映せずに古い文書が残っていると、かえって混乱の原因になります。
要件が変わったときの扱い
開発を進めるうちに、要件を変えたくなることは珍しくありません。そのとき、次の点を確認すると、範囲や費用の話がこじれにくくなります。
- 合意した範囲の中の調整か、範囲を超える追加かを確認する：文言や配置の調整なのか、新しい機能なのか
- 目的に照らして必要かを考える：今の版に入れなければ目的を達成できないか
- 影響を確認する：費用と期間、すでに作った部分への影響を開発会社に確認する
- 決めたことを記録する：変更の内容と、範囲・費用への影響を文書に残す
最初に「やらないこと」を決めておくと、この判断がしやすくなります。
要件の整理にかける時間の目安
小規模な開発では、要件の整理に長い時間をかけるより、大枠を決めたら早めに動く画面で確認するほうが、結果として早く正確に進みます。決めきれない部分は、初回納品で確認する項目として残しておきましょう。
大枠の整理は、初回のご相談から
Tailboneでは、完璧な仕様書がない状態からのご相談にも対応しています。今決まっていることを伺い、画面一覧と機能一覧、やらないことを一緒に整理したうえで制作範囲を合意し、早い段階で実際に触れる初回納品をお渡しします。文章で決めきれない部分は、その画面を見ながら決めていきます。
よくあるご質問
要件定義は有料ですか？
依頼先や規模によって扱いが異なります。初期の相談の中で大枠を整理する場合もあれば、要件定義を一つの工程として見積もる場合もあります。どこまでが相談の範囲で、どこからが作業として費用がかかるのかは、事前に確認しておきましょう。
要件定義の資料は、誰が作るのですか？
小規模な開発では、発注者が業務の情報（目的、流れ、項目など）を出し、開発会社がそれを画面一覧や機能一覧の形にまとめる、という分担が一般的です。発注者がすべてを文書にする必要はありません。
要件が途中で変わったらどうなりますか？
合意した範囲内の調整であれば、修正の中で対応できることが多くあります。範囲を超える大きな変更は、内容と費用を改めて相談するのが一般的です。だからこそ、最初に範囲と「やらないこと」を文書に残しておくことが大切です。