Laravel開発を外注したのに仕上がりが想定外だった、という経験はありませんか？認識齟齬が生まれる原因と、要件定義を正確に伝えるための実践的な手法を解説します。
「完成したけど、使えない」という悲劇をなくしたい
こんな経験はありませんか？
「半年かけて開発してもらったのに、実際に使ってみたら全然違った」 「追加費用を請求されたけど、最初からそのつもりで話していたのに…」 「どこまでが仕様で、どこからが追加なのかわからない」
実はこれ、Laravelに限らずWeb開発の現場で頻繁に起きている問題です。Fivenineでも過去に、他社で開発されたシステムを引き継いだ際、要件定義書が存在しないどころかメールのやり取りだけで開発が進んでいたケースに何度も遭遇しました。
発注側は「あれだけ説明したのに」と思い、受注側は「そういう要件では聞いていない」と感じる。この認識の乖離こそが、Web開発プロジェクト失敗の最大の要因です。
この記事では、LaravelでのWebシステム開発を外注する際に、「思っていたものと違う」をゼロに近づけるための要件定義の伝え方を、実案件の経験をもとに具体的にご紹介します。
なぜ認識のズレが生まれるのか
「なんとなく伝わるだろう」という甘い期待
要件定義のトラブルが起きる背景には、大きく3つの原因があります。
①「動詞」で止まっている要件
「ユーザーが登録できるようにしたい」という要件だけでは、開発者にとって解釈の余地が広すぎます。メール認証は必要か、SNSログインは対応するか、承認フローはあるか、登録後のメール通知は誰に送るか。これらがすべて未定義のまま開発がスタートすると、完成品がクライアントの想定とズレるのは必然です。
②「なにが普通か」の常識が違う
クライアントは過去に使ったことのあるシステムを無意識に参照します。「こういう感じで」と既存サービスのスクリーンショットを渡すことはよくありますが、それがデザインの参考なのか、機能の参考なのか、UXの参考なのかが曖昧なままだと、開発者は独自の解釈で実装を進めます。
③変更履歴が残らないコミュニケーション
「電話で追加仕様を伝えた」「打ち合わせで決まったはずだった」という口頭・口約束のみのコミュニケーションは、後のトラブルの温床になります。プロジェクトが長期化するほど、記憶は曖昧になり、認識は発散していきます。
実践：要件定義を正確に伝える5つの手法
1. 「誰が・何を・どうする」のActor-Action形式で書く
要件を書くときは、主語（Actor）と動作（Action）と目的を必ずセットにしましょう。
曖昧な書き方（NG例）
- 商品管理機能を作る
- 管理者がログインできる
- 在庫を管理したい
明確な書き方（OK例）
- 管理者が、管理画面から商品名・価格・在庫数・公開フラグを登録・編集・削除できる
- 管理者はメールアドレスとパスワードでログインし、セッションは24時間有効とする
- 在庫数が10個を下回ったタイミングで、登録済みメールアドレスに通知メールを送信する
これだけで、Laravelのモデル設計・バリデーション・通知機能の実装粒度が開発者に明確に伝わります。
2. 画面遷移図とワイヤーフレームを必ず用意する
FigmaやMiroなどの無料ツールを使って、画面の流れを図示してください。開発者が最も必要としている情報は「どのページからどのページへ、どんな操作で遷移するか」です。
あるクライアントでは、予約システムの開発依頼時に手書きの画面遷移図をExcelで再現したものを提供していただきました。それが非常に明確だったため、初回の見積もり精度が上がり、追加費用ゼロで納品まで進んだ事例があります。
flowchart TD
A[トップページ] --> B[サービス一覧]
B --> C[サービス詳細]
C --> D{ログイン済み?}
D -->|Yes| E[予約フォーム]
D -->|No| F[ログイン画面]
F --> G[会員登録]
F --> E
E --> H[確認画面]
H --> I[予約完了]
I --> J[確認メール送信]このような図を事前に用意することで、開発者が「おそらくこういう動きだろう」と推測する必要がなくなります。
3. 非機能要件を明示する
「〇〇ができる」という機能要件と同じくらい重要なのが、**「どの程度」「どのくらい速く」「どれだけ安全に」**という非機能要件です。これが抜けていると、動くけど使えないシステムが出来上がります。
## 非機能要件
### パフォーマンス
- ページの初期表示: 3秒以内
- API レスポンス: 1秒以内（通常処理）
- 同時接続想定ユーザー数: 最大100人
### セキュリティ
- 認証: Laravel Sanctum によるトークン認証
- XSS/CSRF対策: Laravelデフォルト機能を使用
- 入力値バリデーション: サーバーサイドで必須実施
### 可用性
- 稼働率: 99.5%以上
- メンテナンス通知: 24時間前までに告知
4. Laravelの「モデル定義」をドキュメントに含める
技術的な要件定義として非常に有効なのが、扱うデータの項目と型を明示することです。開発者に渡す資料に以下のようなテーブル定義を含めることで、データベース設計の認識ズレを防げます。
// 要件定義書に含めるデータ項目の例（擬似コード）
/**
* [予約テーブル] reservations
*
* id - 予約ID（自動採番）
* user_id - 会員ID（usersテーブルと紐付け）
* service_id - サービスID
* reserved_at - 予約日時（日本時間）
* status - ステータス（pending/confirmed/cancelled）
* note - 備考（任意・最大500文字）
* created_at - 登録日時
* updated_at - 更新日時
*
* ビジネスルール:
* - 同一ユーザーの同一時間帯への重複予約は不可
* - キャンセルは予約日の前日17時まで可能
* - confirmed後の変更は管理者のみ可能
*/
これは完璧なコードである必要はありません。「このシステムで扱うデータが何で、どんなルールがあるか」を言語化することが目的です。
5. 「スコープ外」を明記する
見落とされがちですが、「やらないこと」を書くことは「やること」を書くのと同じくらい重要です。
## スコープ外（今回の開発には含まない）
- 多言語対応（日本語のみ）
- スマホアプリ版の開発
- 決済機能（第2フェーズで検討）
- 外部CRMとのAPI連携
- CSVインポート機能
これを明記することで、開発者が「これはどうしますか？」と確認する手間が減り、スコープクリープ（仕様の際限ない拡大）も防止できます。
よくある失敗パターンと対処法
失敗①：参考サイトを「そのまま作って」と渡す
「このサービスみたいなものを作りたい」と大手サービスのURLを渡すケースは非常に多いです。しかし、参考にしたい点が「デザインの雰囲気」なのか「機能の一部」なのかを明確にしないと、見積もりが天文学的な金額になったり、逆に全く別方向に解釈されたりします。
対処法： 参考サイトを渡す際は「このサイトのAという機能（ページのURL指定）のUXを参考にしたい。ただしデザインは別物でよい」のように、参照する観点を必ずセットにする。
失敗②：口頭確認で仕様変更を重ねる
開発途中で「やっぱりここはこうして」と電話やSlackで追加変更を重ねるパターン。一つ一つは小さな変更でも、積み重なると当初の仕様書と全く違う成果物になります。
対処法： 仕様変更はすべて「変更依頼書」として書面化し、工数・費用への影響を都度確認する運用ルールを最初に決めておく。
失敗③：「あとで決める」が増えすぎる
キックオフ時点で未決定事項があること自体は問題ありません。しかし「あとで決める」事項が5つ以上になると、プロジェクトは高確率で迷走します。
対処法： 未決定事項には必ず「いつまでに決定するか」のデッドラインを設定し、それを超えた場合は開発がストップするというルールを合意しておく。
この技術、御社の業務にも活かせます
業務システム開発
Laravelを使った業務システムの構築・改修を20年以上の経験でサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
「思っていたものと違う」は、技術力の問題ではなくコミュニケーション設計の問題です。どれほど優秀なエンジニアでも、曖昧な要件からは曖昧な成果物しか生まれません。
逆に言えば、要件定義さえ丁寧に行えば、初回の見積もり精度が上がり、手戻りが減り、最終的なコストも品質も大幅に向上します。 あるクライアントでは、要件定義に2週間追加でかけた結果、開発フェーズの手戻りがほぼゼロになり、当初見込みより3週間早く本番リリースできた事例もあります。
最初の一歩として、まずは「自分たちのシステムに登場する人物（Actor）を全員書き出す」ところから始めてみてください。管理者、一般ユーザー、配送業者、加盟店オーナー——それぞれが「何をしたいか」を列挙するだけで、要件の全体像が驚くほどクリアになります。
Fivenineでは、Laravel開発の要件定義支援から設計・開発・運用まで一貫してサポートしています。「どこから手をつければいいかわからない」という段階からでも、ぜひお気軽にご相談ください。
