「発注側だから、ちゃんと管理しなきゃ」が落とし穴
システム開発を発注すると、責任感の強い経営者・担当者ほど、こう考えがちです。
- 「自分でWBSを引いて、スケジュールを管理しなきゃ」
- 「フロー図を最新に保って、仕様を可視化しなきゃ」
真面目で立派な姿勢ですが、実はこの2つは発注側がやらなくていい作業です。
やればやるほど、現場との認識がズレ、意思決定が遅れ、プロジェクトはむしろ難航します。
本当に発注側が握るべきは、もっと別のところにあります。
やらなくていいこと①：WBS（作業分解構成図）の作成
なぜやらなくていいのか
発注側が引いたWBSは、ほぼ例外なく**「自分が思う理想のスケジュール」**になります。
- 「設計に2週間、実装に4週間、テストに2週間あれば足りるはず」
- 「来月リリースするには、今週中に実装が始まっていないとおかしい」
しかし、システム開発の難所は外からは見えません。
データの調査、外部APIの仕様確認、過去システムとの整合性チェックなど、実装そのものより準備に時間がかかる作業が大量にあります。
これらは現場のエンジニアにしか見積もれません。
発注側が引いたWBSは、現場のリアルとズレた「願望スケジュール」になり、
- 「なんで遅れてるの？」と詰める材料にしかならない
- 結果として「順調です」と虚偽報告される温床になる
という悪循環を生みます。
代わりに発注側がやるべきこと
タスク分解と工程設計は開発側に任せ、発注側は 「スコープ管理」と「意思決定」 に集中します。
- スコープ管理：何を作って、何を作らないか
- 意思決定：迷っている仕様を即決して、ボールを返す
スケジュールの粒度ではなく、**「機能の取捨選択」と「決断のスピード」**で貢献するのが、発注側の正しい仕事です。
やらなくていいこと②：フロードキュメントの「維持」
一度は作る、でも維持はしない
業務フロー図やシーケンス図は、要件定義フェーズで一度は作る価値があります。
全体像を発注側と開発側で揃えるための、合意形成のツールとして有効だからです。
問題はその後です。
仕様変更や追加要望が出るたびに、フロー図を律儀に更新し続ける——これはやらなくていい作業です。
- 仕様変更のスピードに追いつけず、書いた瞬間から陳腐化する
- 「正しいフロー図」を維持するコストが、得られる情報量に見合わない
- 結局、誰もメンテされていないフロー図を信じなくなる
維持されないドキュメントは、害になります。
古い情報が「正」として残り、新しい情報との矛盾を生むからです。
代わりに死守すべき「ストック情報」
フロー図の代わりに、発注側がストック情報として死守すべきものがあります。
それが ユーザーストーリーとシナリオ です。
- ユーザーストーリー：「誰が、何をしたくて、何が嬉しいのか」を1行で表現したもの
- シナリオ：そのストーリーが実現する具体的な流れ
ユーザーストーリーは、フロー図と違って陳腐化しにくい性質があります。
画面の構造やデータの持ち方が変わっても、「ユーザーが何をしたいか」という本質はあまり変わらないからです。
そして、このストーリーを元にデモを作り、毎週の週次デモで「実物」を確認する。
ストーリーが正、デモがその時点のスナップショット——この役割分担が、発注側にとっての最小コスト最大効果のドキュメント運用です。
まとめ：発注側の仕事は「絞る」「決める」「守る」
発注側がやらなくていいことを整理すると、こうなります。
やらなくていいこと | 代わりにやること |
|---|---|
WBSを自分で引く | スコープ管理（何を作る/作らない）と意思決定 |
フロー図を維持し続ける | ユーザーストーリーとシナリオを死守する |
WBSもフロー図も、発注側が頑張れば頑張るほどズレていく性質のものです。
それよりも、「絞る・決める・守る」——スコープを絞り、迷いを即決し、ユーザーストーリーを守り抜く。
この3つに集中するだけで、プロジェクトの成功確率は大きく変わります。
Beekleの進め方
Beekleでは、要件定義時にユーザーストーリーとシナリオを丁寧に作り、
それ以降は動くプロトタイプと週次デモで進捗と認識を揃えていきます。
分厚いドキュメントを維持する代わりに、ストック情報（ストーリー）を守り、フロー情報（実物）を毎週更新する設計です。
「自分でWBSを引いて消耗している」「フロー図のメンテで疲弊している」という方は、ぜひ一度ご相談ください。