TOBE業務フローとは、課題が解消されたあとの業務の流れを、誰が・何を・どうするかの粒度で描いたものです。「DXで効率化する」はTOBEではなく、「担当者が毎朝FAXを手入力しなくなり、受注データが自動で取り込まれる」のように業務の変化として書けて初めてTOBEになります。この記事では、理想状態の定義から解決策の比較、スコープの線引き、受け渡し部分のリスク評価までを順に説明します。
TOBEを描く前に揃えておくもの
TOBEは単独で描くものではありません。前提として次の2つが手元にある状態で着手します。
- ASIS業務フロー：現状の業務を、ロール（担当者・部署・システム）ごとのレーンと時系列で描いたもの
- 課題の構造：ASISのどこで何が起きているか、その根本原因は何かを整理したもの（イシューツリーなど）
ASISが曖昧なままTOBEを描くと、「今と何が違うのか」を誰も説明できません。課題の構造がないまま描くと、根本原因に効かない改善案が並びます。ASISの描き方はASIS業務フローの記事、課題の分解はイシューツリーの記事にまとめています。
TOBEの3つの条件
良いTOBEには共通する条件があります。
| 条件 | 悪い例 | 良い例 |
|---|---|---|
| 具体的 | 受注業務を改善する | 注文書が届いたら受注データが自動で下書き登録される |
| 測定可能 | 入力ミスを減らす | 受注の手入力件数が1日40件から0件になる |
| 現場視点 | システムが自動化する | 担当者は下書きを確認して確定ボタンを押すだけになる |
「〜をゼロにする」「〜が自動で〜になる」「〜は確認ボタン1回で終わる」という形で書くと、業務フローの変化として読める文になります。逆に「効率化」「最適化」「強化」が残っていたら、まだ具体化が足りていません。
TOBEを描く3ステップ
Step 1：理想状態を業務フローとして定義する
ASISと同じ書式（ロールのレーン×時系列）でTOBEを描きます。書式を揃えるのは、差分を一目で見せるためです。変わるステップには次のようなマークを付けておくと、現場・経営層・開発側が同じ図を見て議論できます。
| マーク | 意味 | 例 |
|---|---|---|
| [新規] | ASISになかったステップ | システムが注文書PDFを読み取って下書きを作る |
| [変更] | やることは同じで手段が変わる | Excel転記 → 画面上で確認・確定 |
| [廃止] | ASISにあって消えるステップ | 営業への電話での在庫確認を廃止 |
| [統合] | 複数ステップを1つにまとめる | 目視チェック3回 → 自動チェック1回 |
描いたら、文章でも1段落に要約しておきます。図だけだと「結局何が変わるのか」を説明する場面で困るからです。
Step 2：解決策の候補を複数出して比較する
TOBEに到達する手段は1つではありません。解決策は次の3層で考えると、システムだけで解こうとする失敗を避けやすくなります。
- ルール変更：業務ルールそのものを変える（例：注文書フォーマットを取引先と統一する）
- オペレーション変更：手順や役割分担を組み替える（例：入力担当と確認担当を分ける）
- システム化：1と2で残った定型作業をシステムに任せる
候補が出たら、効果・コスト・実現可能性の3軸で並べます。
| 案 | 内容 | 効果 | コスト | 実現可能性 |
|---|---|---|---|---|
| A | 主要取引先とフォーマット統一＋Excelマクロ | 中 | 低 | 高 |
| B | 注文書の読み取り＋受注システムへの自動登録 | 高 | 中 | 中 |
| C | 基幹システムの全面刷新 | 最高 | 非常に高 | 低 |
ここで大事なのは、「最も効果が高い案」が「推奨する案」とは限らないことです。実現可能性には技術面だけでなく、現場が受け入れられるか、予算が確保できるかという組織面も含まれます。上の例なら「Aを短期で入れ、その実績をもとにBへ進む。Cは今回扱わない」という順序の提案が現実的です。
Step 3：スコープをIN/OUTで確定する
TOBEを描くと、あれもこれも入れたくなります。プロジェクトの失敗の多くはスコープの膨張から起きるため、「やること」と同じ重さで「やらないこと」を書きます。
Phase 1 スコープ（期間：3ヶ月）
IN（やること）
- 主要5社の注文書読み取りと受注下書きの自動作成
- 担当者による確認・確定画面
OUT（やらないこと）と理由
- 残り30社の取引先対応 → Phase 2（件数が少なく効果が小さい）
- 在庫引当の自動化 → Phase 2（在庫データの精度確認が先）
- 請求業務の見直し → 別プロジェクト（担当部署が異なる）
OUTは「永遠にやらない」ではなく「今回はやらない」です。理由とあわせて書いておくと、要件定義の段階で「これもお願い」と言われたときに同じ議論を繰り返さずに済みます。Phase 1は3ヶ月以内に収めると、早めに成果を見せて次のフェーズの合意を取りやすくなります。
ロール境界のリスクを4つの問いで確認する
業務はリレーのように担当者から担当者へ受け渡されて進みます。TOBEで見落としやすいのが、この受け渡しの瞬間です。業務フロー図でいえば、矢印が別のレーンへまたがる箇所にあたります。
改良案がロール境界に関わるときは、次の4つに答えます。
- 新たにどんなリスクが発生するか
- 現場や取引先に、新たに何を強いるか（運用ルール、教育、ツール導入など）
- それが失敗したらどうなるか
- 失敗したとき、代わりの流れはどう動くか
たとえば「注文書をメールで受けて読み取る」案なら、メールの見落とし、読み取り誤り、取引先へのフォーマット変更依頼といった論点が出ます。正常系だけを描いたTOBEは、現場で必ず詰まります。影響が最も大きい境界については、検知（誰がどう気づくか）、行動（誰が何分以内に動くか）、代替手段（手入力に戻す等）、切り替えの判断基準まで決めておきます。4つに答えられない案は、まだTOBEとして完成していません。
実例：受注入力業務のASISとTOBE
部品商社の受注業務を例に、対比表を作ってみます。
| 業務ステップ | ASIS（現状） | TOBE（あるべき姿） |
|---|---|---|
| きっかけ | 取引先からFAXで注文書が届く | 注文書がメールのPDFで届く［変更］ |
| データ作成 | 担当者が受注システムへ手入力（1件5分） | システムが読み取り、受注の下書きを作る［新規］ |
| 在庫確認 | 営業に電話で確認 | 下書き画面に在庫数が表示される［変更］ |
| 確認 | 上長が紙の注文書と画面を見比べる | 担当者が差異のハイライトだけ確認する［統合］ |
| 確定 | 入力後に上長が承認 | 担当者が確定ボタンを押す（上長承認は10万円以上のみ）［変更］ |
| 例外対応 | 都度、電話で取引先に確認 | 読み取りに失敗した注文だけ一覧に残り、手入力する［新規］ |
最後の行のように、例外時の流れを描いておくのがポイントです。読み取りがうまくいかない注文書は必ず出ます。その注文がどこに溜まり、誰がいつ処理するかが書かれていて初めて、現場は「これなら回る」と判断できます。
TOBEの伝え方：合意は順序で決まる
TOBEは描いて終わりではなく、相手とすり合わせて合意する必要があります。いきなり「これがTOBEです」と出すと、「今と何が違うんですか」で時間切れになりがちです。次の順序を踏みます。
- ASISの認識を揃える：「今はこうなっていますよね」を最初に確認する
- スコープの認識を揃える：「今回は受注入力だけで、在庫管理は触らない」と境界を示す
- TOBEを出す：1と2が揃っているので、差分だけで議論できる
現状のヒアリングと、TOBEの壁打ちは別の作業です。1回の打ち合わせで両方やろうとすると、どちらも中途半端になります。別のセッションとして設計してください。
もう1つ、フロー図だけでは伝わらない相手がいます。経営層や企画部門はフロー図から画面まで頭の中で補えることが多い一方、現場担当者は「で、自分の画面はどうなるの？」が最後まで残りやすいです。その場合は、フローの各ステップに対応する画面のワイヤーフレームを横に並べて見せます。Excelで枠を引く程度のラフで十分です。色や余白を作り込む段階ではありません。
よくある失敗
- TOBEが抽象的なまま：「業務効率化」と書いたまま開発に入り、何を作るか誰も説明できず手戻りが出る
- 解決策を1案しか検討しない：比較がないので、その案が妥当かを判断する材料がない
- 実現可能性を確認しない：「システムがあればできるはず」で進め、現場が使いこなせない、社内規程に引っかかる、予算が出ない
- OUTを書かない：「せっかくだから」で範囲が膨らみ、納期に間に合わなくなる
- 経営層のTOBEだけで決める：現場の例外処理や手順が反映されず、稼働後に裏でExcel運用が復活する
- 現場に確認せずに描く：現場担当者の業務負担が逆に増えていることに、リリース後まで誰も気づかない
この記事のまとめ
- TOBEは「誰が・何を・どうする」の粒度で、業務フローの変化として具体的に書く
- ASISと同じ書式で描き、[新規][変更][廃止][統合]で差分を示す
- 解決策はルール変更・オペレーション変更・システム化の3層で考え、効果・コスト・実現可能性で比較する
- スコープはINとOUTを両方書き、OUTには理由と対応時期を添える
- ロール境界は4つの問いで評価し、失敗時の代替フローまで設計する
- 合意はASIS→スコープ→TOBEの順で取り、伝わらない相手にはラフな画面を添える
TOBE設計は、ロードマップのStep 4「あるべき姿を描く」にあたるスキルです。描いたTOBEは、次に打ち合わせ資料で合意を取り、要件定義へ引き継ぎます。手順と演習をもっと詳しく学びたい方は、FDEガイドのTOBE業務フロー設計を参照してください。スライド・演習問題・テストはlecture.iplot.jpで取り組めます。