To-Be（理想の業務）の描き方｜As-Isとのギャップから課題を出す方法

現状の業務を洗い出した。ムダも見つかった。

——では、次は何をすればいいのでしょうか。

ここで多くの会社が、いきなりシステムの比較検討に進んでしまいます。資料請求をして、デモを見て、見積もりを取る。

しかし、その前にもう一つ決めておかなければならないことがあります。「どういう状態になれば成功なのか」という到達点です。

これをTo-Be（トゥービー）、日本語では「あるべき姿」や「理想の業務」と呼びます。

この記事では、To-Beの描き方と、現状（As-Is）との差から課題を導く方法を解説します。現状分析のやり方については、業務の見える化の進め方｜現状分析（As-Is）で見るべき5つの手順をご覧ください。

To-Beを決めずにシステムを選ぶと何が起きるか

到達点が決まっていない状態でシステムを選ぶと、判断の基準が「機能の多さ」か「価格の安さ」しかなくなります。

その結果、次のようなことが起こります。

起きること	なぜ起きるか
機能が多いものを選んでしまう	何が必要か決まっていないので、多いほうが安心に見える
デモの印象で決めてしまう	比較軸がないため、画面のきれいさで判断してしまう
営業担当の提案に流される	「御社の場合はこれが必要です」に反論する材料がない
導入後に成功したか分からない	成功の定義がないので、評価のしようがない
途中で要望が増え続ける	どこまでやれば終わりなのかが決まっていない

特に最後の「要望が増え続ける」は深刻です。

ゴールが決まっていないプロジェクトは、終わる条件がないので、予算と期間が尽きるまで続きます。

To-Beとは「未来の業務の姿」であって、システムの仕様ではない

ここが最も誤解されやすい点です。

To-Beを書いてくださいとお願いすると、多くの場合「こういう画面が欲しい」「こんな機能が必要」という答えが返ってきます。

それは手段であって、到達点ではありません。

これはTo-Beではない	To-Beとして書き直すと
受注管理システムを導入する	受注内容を1回入力すれば、請求書まで自動で作られる
スマホから在庫が見られるようにする	倉庫に行かなくても、その場で在庫を答えられる
ダッシュボードを作る	月次の数字を、翌営業日には経営会議で見られる
ワークフロー機能をつける	承認待ちが1日以内に収まる

右側の書き方には、システムという言葉が出てきません。

これが重要です。到達点を手段から切り離しておくと、後で「もっと安い実現方法」が見つかったときに乗り換えられるからです。

To-Beを描く4つのステップ

ステップ1｜業務の目的に立ち返る

まず、その業務が「何のためにあるのか」を確認します。

受注処理の目的は、受注管理表を埋めることではありません。顧客が注文したものを、正しく、約束した期日までに届けることです。

目的に立ち返ると、「そもそもこの工程は目的に貢献しているのか」という問いが立てられるようになります。

ステップ2｜理想の状態を「動作」で書く

次に、うまくいっている状態を文章にします。

コツは、誰が何をしている状態かを、動作として書くことです。

• △ 受注業務が効率化されている
• ○ 営業担当が外出先から受注を登録すると、倉庫の担当者が即座にその内容を見られる

下のように書けていれば、関係者が同じ絵を思い浮かべられます。

「効率化」「見える化」「最適化」といった言葉が出てきたら、それは具体的に書けていないサインだと思ってください。

ステップ3｜数字を入れる

動作で書けたら、そこに数字を入れます。

項目	現状（As-Is）	理想（To-Be）
受注1件の処理時間	30分	10分以内
請求書発行にかかる時間	月20時間	月5時間以内
在庫の問い合わせ対応	週10件・1件5分	週2件以内
受注から出荷までの日数	平均5日	3日以内
請求の誤り	月1〜2件	原則ゼロ
担当できる人数	1名のみ	3名が対応可能

数字を入れる目的は2つあります。

一つは、どこまでやるかを決めるためです。「10分以内」と決めれば、9分にする工夫は不要になります。

もう一つは、導入後に成否を判定するためです。この数字が、そのまま効果測定の指標になります。

ステップ4｜いつまでに、どこまでを決める

最後に、期限と範囲を区切ります。

理想をすべて一度に実現しようとすると、たいてい破綻します。「1年後にここまで」「3年後にここまで」と段階に分けてください。

時期	到達点	対象範囲
6か月後	受注情報の二重入力がなくなる	営業部・経理部
1年後	在庫状況が全員リアルタイムで見られる	＋倉庫
2〜3年後	受注から入金まで一つの流れでつながる	＋外部の会計担当

段階に分けておくと、最初の投資額を抑えられます。小さく始める考え方については、後の回で詳しく扱います。

As-IsとTo-Beの差が「課題」になる

ここまで来ると、課題は自動的に出てきます。

現状と理想の差、それがそのまま課題です。

この差を埋める作業を、ギャップ分析と呼びます。難しく考える必要はありません。表にすれば見えます。

現状（As-Is）	理想（To-Be）	ギャップ＝課題	考えられる打ち手
受注内容を2か所に入力している	1回の入力で請求書まで作られる	入力が二重になっている	データを1か所に集約する
在庫は倉庫の台帳にしかない	その場で在庫を答えられる	在庫情報が共有されていない	在庫の記録場所を共有化する
承認待ちが平均1日	承認待ちが1日以内	ほぼ達成できている	今回は対象外にする
値引き判断はベテランのみ	3名が対応可能	判断基準が言語化されていない	ルールを文書化する

この表の価値は、3行目のような「実はギャップが小さい項目」が見えることにもあります。

やらなくていいことを見つけるのも、ギャップ分析の役割です。

打ち手の欄に「システム」と書かない

上の表の右端を見てください。「システムを導入する」とは書いていません。

4行目の「ルールを文書化する」は、システムがなくてもできることです。実際、ギャップの何割かは運用の見直しだけで埋まります。

この段階で手段を絞り込まないでください。手段の選び方は、課題が出そろってからで十分間に合います。

現実的なTo-Beと、非現実的なTo-Be

理想を描くとき、どこまで高く設定するかは悩ましいところです。判断の目安を挙げます。

観点	現実的なTo-Be	危険なTo-Be
人員	今の人数でできる	専任担当がいる前提になっている
スキル	現場が今の知識で使える	全員がITに慣れる前提
投資額	削減効果の範囲に収まる	効果より投資が大きい
期間	1年以内に最初の成果が出る	3年後に全部完成させる
取引先	相手のやり方を変えなくてよい	取引先全社の協力が前提

特に注意したいのが、いちばん下の取引先です。

「取引先にも専用画面から発注してもらう」という理想は、自社だけでは実現できません。相手に手間が増えるなら、まず使ってもらえないと考えたほうが安全です。

自社の努力だけで到達できる範囲に理想を置く。これが、実現するTo-Beの条件です。

To-Beを描くときによくある失敗

現場に「理想を書いてください」と丸投げする

現場に聞くと、たいてい「今の作業が少し楽になる案」が出てきます。

それは悪いことではありませんが、今の仕事の枠組みは疑われません。「この業務自体をなくす」という発想は、担当している人からは出にくいものです。

現場からは事実と困りごとを集め、理想は経営の視点で描く。この役割分担が現実的です。

他社の事例をそのまま理想にしてしまう

同業他社の成功事例は参考になりますが、そのまま持ち込むと合いません。

取引先の構成、社員数、扱う商品、地域性が違えば、最適な業務の形も変わります。

参考にすべきは結果ではなく、どうやってその結論に至ったかの考え方のほうです。

理想が壮大になりすぎる

「全社のデータが統合され、経営判断がリアルタイムで行える状態」。

間違ってはいませんが、この粒度では次に何をすればいいのか誰にも分かりません。

大きな理想を掲げるのは構いませんが、必ず「最初の6か月で到達する状態」まで分解してください。

現状の不満の裏返しで終わる

「Excelが重い」→「重くないシステムにする」。これでは、業務の形は何も変わりません。

不満の解消は出発点にすぎません。そこから一段進んで、「そもそもこの作業が要らない状態」は作れないかを考えてみてください。

明日からできる3つのこと

1. 対象業務の「目的」を一文で書く
   受注処理なら「注文を正しく期日までに届けること」。ここが出発点です。
2. 理想の状態を、動作で3つ書く
   「誰が」「何をしている」の形にします。効率化という言葉は禁止です。
3. 現状・理想・ギャップの3列表を作る
   行は5つで十分です。埋まらない行があれば、現状分析が足りていないサインです。

よくある質問

To-Beは誰が決めるべきですか？

最終的には経営者、または対象業務の責任者です。

投資の判断を伴うため、決裁権のある人が決める必要があります。ただし、現場の実態を無視した理想は実現しないため、素案づくりには現場を巻き込んでください。

数値目標はどうやって決めればいいですか？

現状の半分、を最初の目安にしてみてください。

月20時間かかっているなら10時間。1割の改善なら運用の工夫で済むことが多く、システム投資に見合いません。逆に9割減は、業務そのものをなくす発想が必要になります。

To-Beを決めたのに、後から変わってしまいました

問題ありません。むしろ自然なことです。

検討を進めるうちに、より良い形が見えてくることはよくあります。大事なのは変えないことではなく、変えたときに関係者へ共有し、合意し直すことです。

暗黙のうちに目標が変わっていく状態が、最も危険です。

まとめ｜ゴールを決めてから、手段を選ぶ

To-Beを描く作業は、システム導入のための準備ではありません。

自社の業務をどう変えたいのかを、会社として決める作業です。

• To-Beは「未来の業務の姿」であって、システムの仕様ではない
• 「効率化」ではなく、誰が何をしている状態かを動作で書く
• 数字を入れる。どこまでやるかと、成否の判定基準になる
• As-IsとTo-Beの差が、そのまま課題になる
• 自社の努力だけで到達できる範囲に理想を置く

ここまでで、課題が10個も20個も出てきたはずです。

次はそれをどの順番で解決するかを決める番です。中小企業のDXが失敗する原因の一つは、すべてを同時に解決しようとすることにあります。

整理した内容を社内で共有する文書にまとめる方法は、【中小企業向け】システム化構想の立案テンプレート｜立案書の作り方で解説しています。

みんなシステムズでは、理想の業務像を描く段階からご相談を承っています。「現状は分かったが、どこを目指すべきか判断できない」という場合も、お気軽にお問い合わせください。