見積のブレは、多くの場合「発注側の情報の曖昧さ」に起因する
「開発会社に見積を依頼したら、A 社は 300 万円、B 社は 900 万円と 3 倍も差が出た」——こうした見積のブレは、多くのケースで発注側から渡した情報の曖昧さに起因します。特に非エンジニアの担当者が口頭やメール本文だけで要件を伝えると、開発会社は不確実性を織り込むためにバッファを厚めに積むしかありません。
この不確実性を減らす武器が、業務フロー図と画面遷移案です。どちらも図解ツールを使えば非エンジニアでも作成でき、見積の精度を大きく引き上げます。この記事では、発注担当者が見積依頼前に用意すべき業務フロー図・画面遷移案の作り方を、勤怠システムの具体例を交えて整理します。
1. なぜ業務フロー図・画面遷移案が見積精度を上げるのか
開発会社が見積を作るときに社内で行うのは、「必要な機能と工数の洗い出し」です。要件が曖昧だと、次のような判断を開発会社側で埋めるしかなくなります。
- ユーザーは何人いて、どんな役割の人が使うのか
- 業務は月に何回発生し、繁忙期はいつか
- 例外処理 (差し戻し・代理承認・修正など) はどこで起きるか
- 画面は何枚必要で、どこから遷移するのか
これらを開発会社が「想像で埋めた見積」は、あとで前提が違うと分かった瞬間に追加費用が発生します。逆に業務フロー図と画面遷移案が事前に提示されていれば、開発会社は「その図に描かれている範囲」だけを見積もればよく、リスクバッファは小さく済みます。
同じ機能要件でも、業務フローと画面遷移が揃っているだけで見積レンジが 2〜3 割絞られるケースは珍しくありません。加えて、複数社に相見積を取るときも「全社が同じ図を前提に見積もる」ため、金額比較がフェアになります。
2. 業務フロー図の作り方
業務フロー図は「誰が・いつ・何をして・次にどうなるか」を 1 枚で表す図です。難しく考えず、まずは現状 (As-Is) を素直に描くことから始めます。
As-Is フローを先に描く
As-Is は「今の業務のやり方」です。まずはシステム化する対象業務について、次を書き出します。
- 登場人物 (申請者・承認者・管理者・経理など)
- 業務のトリガー (月初・申請発生・締め日など)
- 使っている資料や道具 (Excel・紙・メール・既存システム)
- 発生する例外 (差し戻し・代理承認・修正申請・緊急対応)
As-Is を描くと、「今どこに手間や漏れが発生しているか」が可視化されます。開発会社にとっても、既存業務の理解は初手の情報として最も価値があります。
To-Be フローで理想像を描く
続いて、システム導入後の「あるべき業務フロー」を描きます。ここで大事なのは「何を自動化し、何を人が判断するか」を線引きすることです。すべてを自動化しようとすると要件が膨らみ、逆に自動化ポイントを絞れば工数を抑えられます。
To-Be は As-Is を横に並べて描くと、「どの手順が消え、どの手順が新設されるか」が明確になり、開発会社との認識合わせが速くなります。
記号は 3 つだけ覚えれば十分
BPMN などの正式な記法もありますが、非エンジニアの発注担当者は次の 3 記号だけ押さえれば実務に耐えます。
| 記号 | 意味 | 使いどころ |
|---|---|---|
| 四角 (□) | 処理・作業 | 「申請する」「承認する」など |
| ひし形 (◇) | 分岐 | 「承認 OK？」「金額 10 万円以上？」 |
| 矢印 (→) | 流れの方向 | 処理から処理へつなぐ |
登場人物ごとに横方向のレーン (スイムレーン) を分けて描くと、責任範囲が一目で分かります。
粒度は「1 画面 = 1〜3 ステップ」を目安に
細かく描きすぎるとメンテナンス不能な図になり、粗すぎると見積の役に立ちません。目安として、システム上の 1 画面での操作が 1〜3 ステップに収まる粒度がちょうど良いラインです。「申請画面を開く → 内容を入力する → 送信する」で 1 つのブロックに集約する、といった形です。
3. 画面遷移案の作り方
業務フロー図で「どんな業務があるか」が固まったら、次は「どんな画面が必要で、どうつながるか」を描きます。
まず画面リストを作る
いきなり図を描かず、まずは Excel やスプレッドシートで画面リストを作ります。列は次のような構成が実務的です。
| 画面 ID | 画面名 | 主な操作 | 利用者 | 備考 |
|---|---|---|---|---|
| S001 | ログイン | メール・パスワード入力 | 全員 | SSO 対応要否 |
| S002 | 申請一覧 | 一覧表示・絞り込み | 申請者 | ページング要 |
| S003 | 申請作成 | 入力・下書き保存・送信 | 申請者 | 添付ファイル対応 |
このリストが「必要な画面数」を客観的に示すため、開発会社は工数を算出しやすくなります。20 画面と 50 画面では見積が大きく変わるため、この数字が事前に確定しているだけで精度は跳ね上がります。
遷移図で画面のつながりを描く
画面リストができたら、矢印でつなげて遷移図にします。「ログイン → 一覧 → 詳細 → 編集 → 保存」といったハッピーパスを 1 本描いたあと、「エラー時」「差し戻し時」「キャンセル時」の分岐も描き足します。
デザインの作り込みは不要で、四角に画面名を書いて矢印でつなぐだけで十分です。開発会社は「画面数 × 平均工数」で見積を組み立てるため、遷移図の見た目より画面数と分岐の網羅性が重要です。
作成ツールの選び方
作成ツールは、社内でメンテナンスしやすいものを選ぶのが正解です。
- Miro / FigJam は付箋感覚で描けて複数人で編集しやすく、業務フロー・遷移図の初期案に向きます
- Figma は画面遷移だけでなく簡易ワイヤーフレームも描けるため、デザインまで進めたい場合に有利です
- Excel / PowerPoint / Google スライドは社内共有が容易で、IT 統制の関係で外部ツールが使えない企業でも扱いやすい選択肢です
「かっこいい図」を作る必要はありません。開発会社が読めて、社内でも更新できるフォーマットであることが最優先です。
FIXITえっ、業務フロー図って自分たちで描かなきゃダメなの？開発会社にやってもらえないの？
Shioriお願いはできます。ただ有償のヒアリング工数になって、数十万円の追加になることが多いです。
FIXITShioriはい。既存業務は発注側のほうが速く正確に書けるので、そこは社内で握るのが結果的に安上がりです。
FIXITShiori分かれ目は見た目ではなく、登場人物・処理・分岐が読み取れるかどうかだけです。
4. どこまで詰めれば十分か
業務フロー図・画面遷移案を作り込みすぎると、要件定義工程を発注側で丸ごと巻き取ることになり、時間もコストもかかります。見積依頼段階では「開発会社が工数を積めるだけの情報」があれば十分です。
最低限のラインと過剰品質の境界
見積依頼段階に必要なのは、次のレベルです。
- 業務フローは主要フロー 1〜3 本と主要な例外分岐
- 画面リストは主要画面がすべて洗い出されている (20 画面規模なら 20 画面全部)
- 画面遷移図はハッピーパスと主要な戻り動線
- 各画面の詳細 UI (ボタン配置・色・余白) は不要
一方で、次まで詰めるのは過剰品質です。
- 全項目の入力チェック仕様 (文字数・必須有無)
- DB 設計・API 仕様・エラーメッセージ文言
- 権限マトリクスの全パターン
こうした詳細は要件定義フェーズで開発会社と一緒に詰める領域です。発注段階で完璧に作ろうとすると、社内リソースを浪費します。
過不足を避ける発注前チェック
見積依頼前の準備の全体像は 発注前に整理すべきこと にチェックリスト形式でまとめています。RFP (提案依頼書) まで作る場合の項目は RFP の書き方 を参照してください。
5. 勤怠システムを例にしたサンプル
抽象論だけでは分かりにくいので、勤怠システムを例に業務フロー図と画面遷移案の最小構成を示します。
勤怠システムの As-Is 例
- 従業員は毎日、紙のタイムカードで打刻する
- 月末に管理者がタイムカードを集めて Excel に転記する
- 残業時間は管理者が手計算し、承認者にメールで送る
- 承認後、経理システムに手入力する
問題点は「転記工数」「手計算のミス」「承認の遅延」です。
勤怠システムの To-Be 例
- 従業員はスマホから打刻する
- 月次でシステムが自動集計する
- 承認者はシステム上で承認する
- 経理システムへは CSV 連携する
画面リスト (抜粋)
| 画面 ID | 画面名 | 主な操作 | 利用者 |
|---|---|---|---|
| S001 | ログイン | 認証 | 全員 |
| S002 | 打刻 | 出勤・退勤・休憩 | 従業員 |
| S003 | 勤怠一覧 | 自分の勤怠を月表示 | 従業員 |
| S004 | 勤怠修正申請 | 打刻漏れの修正申請 | 従業員 |
| S005 | 承認一覧 | 部下の申請を一覧 | 承認者 |
| S006 | 承認詳細 | 承認・差し戻し | 承認者 |
| S007 | 月次集計 | 部署別・個人別集計 | 管理者 |
| S008 | CSV 出力 | 経理システム連携 | 管理者 |
遷移の主要パス
打刻フローは「ログイン → 打刻」で完結し、修正フローは「ログイン → 勤怠一覧 → 勤怠修正申請 → (承認者側で) 承認一覧 → 承認詳細 → 承認」となります。
この程度の粒度でも、開発会社は「画面 8 本 + 承認ワークフロー + CSV 出力 + 認証」といった構造を捉えられ、工数の見積が組み立てられます。業務システム全般の見積構造は 業務システムの見積相場 で解説しています。
6. 資料が揃った状態で見積依頼するとどう変わるか
資料が揃っているか否かで、見積は次の 3 点で変わります。
見積の精度が上がる
要件が可視化されると、開発会社は「見えているものだけ」を見積もれます。バッファの積み方が薄くなり、複数社間のブレも小さくなります。相見積を取ったときに「A 社と B 社の差はどこか」を発注側が自力で読み解けるようになります。
見積期間が短くなる
資料が揃っていない場合、開発会社は追加ヒアリングを重ねて要件を埋めます。この期間だけで 2〜4 週間伸びることがあります。業務フロー図と画面リストがあれば、ヒアリングは 1〜2 回で済み、見積提示までの期間は 1〜2 週間に短縮されるのが一般的です。
金額差が縮まる
同じ案件でも、要件が曖昧なときの A 社と B 社の見積差は 3 倍を超えることがありますが、資料が揃うと 1.3〜1.5 倍程度まで縮まる傾向があります。差の原因も「単価水準」「テスト工程の厚み」「体制構成」といった説明可能な差に整理され、比較検討がしやすくなります。
コツ
発注段階で目指すのは「開発会社が工数を積める最小限」であって、要件定義の完成形ではありません。主要フロー 1〜3 本と全画面のリストが揃っていれば、そこから先の詳細は要件定義フェーズで開発会社と一緒に詰めるほうが、社内リソースの使い方として効率的です。
まとめ
業務フロー図と画面遷移案は、開発会社が見積のリスクバッファを削るための最重要資料です。業務フロー図は As-Is → To-Be の順で、四角・ひし形・矢印の 3 記号で描けば十分。画面遷移案はまず画面リストを作り、遷移図はハッピーパスと主要な戻り動線だけを押さえます。詳細 UI・DB 設計・入力チェック仕様まで詰めるのは過剰品質で、要件定義フェーズに任せるのが現実的です。資料が揃うと、見積の精度・期間・金額差の 3 つが同時に改善し、複数社比較がフェアになります。
AI 駆動開発のクリエイティブスタジオである FIXIT では、発注担当者と一緒に業務フローと画面遷移を整理しながら、見積依頼に耐える資料までまとめるかたちで相談を受けています。「自社で作った資料が見積依頼に十分かレビューしてほしい」といった段階からのご相談も歓迎です。無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。