想定読者
- 業務のムダや手戻りが多いのに、どこから見直すべきか決めきれない方
- チーム内の認識違いや引き継ぎ漏れを減らしたいマネージャーやリーダー
- 現場の声を反映しながら、実行まで進む業務改善を進めたい方
結論
As Is / To Be分析の価値は、今の業務を図にすることだけではありません。 現状の流れ、理想の流れ、その差分 をチームで共有し、改善の優先順位まで決められる点にあります。
業務改善が止まりやすい理由は、課題が曖昧なまま話が進むからです。誰かは忙しいと言い、誰かは手順が多いと言い、別の誰かは確認不足だと言う。これでは議論が散らかります。
そこで役立つのが、As Is / To Be分析です。今どう動いているのか、これからどう変えたいのかを並べて見ることで、議論が感覚論から抜け出します。改善案を出す場面でも、思いつきではなく、根拠のある判断につながります。
As Is / To Be分析が必要になる場面
As Is / To Be分析は、業務改善のための定番フレームワークです。 As Isは現状、To Beは理想の状態を指します。名前だけ見ると難しそうですが、やることはシンプルです。
- 今の業務フローを書き出す
- 理想の流れを書き出す
- 差が出ている箇所を見つける
- 何を変えるか決める
この流れを踏むだけで、改善の議論がかなり進めやすくなります。
特に、次のような場面では効果が出やすいです。
| 状況 | 起きている問題 |
|---|---|
| 担当者ごとにやり方が違う | 品質にばらつきが出る |
| 確認作業が多い | 時間がかかる、待ちが増える |
| 引き継ぎがうまくいかない | 抜け漏れや再確認が増える |
| 改善案が出ても進まない | 誰が何を変えるか決まらない |
業務の不満を並べるだけでは、改善は前に進みません。 現状と理想を同じ土台で比べること が、最初の一歩です。
As Isを描くときに外せない視点
As Isでは、今の業務をありのままに書き出します。 ここで大事なのは、正しい手順ではなく、実際に現場で行われている流れ を出すことです。
理想の手順やマニュアル上の流れを書いてしまうと、後で差分が見えなくなります。現場で起きている遠回りや例外対応こそ、改善のヒントになります。
誰が、何を、どの順番で進めているかを見る
まずは業務の流れを分解します。 担当者、作業内容、受け渡しの順番が見えるだけでも、かなり状況がつかめます。
たとえば、次のような形で洗い出すと把握しやすくなります。
- 問い合わせを受ける
- 内容を確認する
- 担当者に振り分ける
- 対応内容を作成する
- 上長確認を行う
- 顧客へ返信する
- 対応履歴を記録する
このとき、実際には途中で差し戻しがある、口頭確認が入る、別ツールに転記している、といった細かな動きも拾ってください。そこにムダや詰まりが潜んでいます。
ボトルネックは時間・手間・認識違いから探す
As Isを描く目的は、現状を眺めることではありません。 改善すべき箇所を見つけることです。
チェックしたい観点は次の3つです。
- 時間がかかっている工程
承認待ち、確認待ち、返信待ちなど
- 手間が多い工程
二重入力、転記、同じ説明の繰り返しなど
- 認識違いが起きる工程
担当範囲が曖昧、判断基準が人によって違うなど
会議では、各工程に対して次のようなメモを付けると議論が深まります。
- ここで毎回止まる
- この確認は本当に必要か
- 人によってやり方が違う
- この情報は前工程で取れないか
こうしたコメントが集まると、改善の優先順位も見えやすくなります。
To Beを描くときは理想と実行案を分けて考える
To Beでは、こうなっていたら良いという理想の業務フローを描きます。 ただし、最初から現実的な案だけに絞る必要はありません。
理想を小さくまとめすぎると、今の延長線上の改善しか出てこなくなります。まずは広く発想し、その後で実行案に落とし込む流れが大切です。
制約をいったん外して理想の流れを出す
To Beを考える場では、次のような問いが役立ちます。
- この確認、本当に毎回必要か？
- そもそも入力項目を減らせないか？
- 担当の受け渡し回数を減らせないか？
- ツール連携で自動化できないか？
- 顧客への回答をテンプレート化できないか？
ここでは、予算や体制の話をいったん脇に置いて構いません。 理想像を先に出すことで、改善の方向性がはっきりします。
たとえば、現状が次のような流れだとします。
- 問い合わせ受信
- 担当者が内容確認
- 別シートへ転記
- 上長へ口頭共有
- メール作成
- 再確認
- 送信
- 履歴入力
これに対してTo Beでは、次のような形が考えられます。
- 問い合わせ内容をフォームで統一
- 自動で担当振り分け
- テンプレートで一次回答
- 必要案件のみ承認
- 送信履歴を自動保存
この差分が、そのまま改善テーマになります。
ギャップを埋める施策は小さく切って進める
To Beを描いた後は、As Isとのギャップを埋める施策を決めます。 ここで大切なのは、全部を一気に変えようとしないことです。
おすすめは、施策を3段階に分けるやり方です。
| 優先度 | 施策の例 | 進め方 |
|---|---|---|
| 高 | テンプレート作成、確認ルール統一 | すぐ着手する |
| 中 | フォーム改善、担当分担の見直し | 1〜2か月で試す |
| 低 | システム連携、自動化開発 | 要件を固めて検討する |
このように分けると、会議で終わらず、実行に移しやすくなります。
さらに、各施策には次の3点を必ず付けてください。
- 誰が担当するか
- いつまでにやるか
- 何をもって完了とするか
ここが曖昧だと、せっかくの分析も止まります。
チームで進めるときに失敗しないコツ
As Is / To Be分析は、フレームワーク自体よりも、進め方で差が出ます。 特に、現場メンバーが本音を出せるかどうかで結果が変わります。
よくある失敗は、リーダーだけで作って現場に共有する形です。これでは納得感が生まれず、運用も変わりません。
進めるときは、次のポイントを意識してください。
- 現場担当者を必ず入れる
- 問題の犯人探しをしない
- 発言量が偏らないようにする
- 完璧な図を目指しすぎない
- 最後にアクションまで決める
会議の場では、誰が悪いか ではなく、どこで詰まるか に焦点を当てることが重要です。責任論に寄ると、情報が出なくなります。
また、最初から全業務を対象にしないのもコツです。 まずは1つの業務、1つの部門、1つの申請フローなど、範囲を絞って始めると進めやすくなります。
よくある質問
Q: As Is / To Be分析はどんな業務でも使えますか？
A: はい。営業、採用、経理、カスタマーサポート、制作進行など、流れがある業務なら幅広く使えます。特に、担当の受け渡しが多い業務や、確認作業が増えがちな業務と相性が良いです。
Q: フローチャートのような図にしないと意味がありませんか？
A: いいえ。最初は箇条書きでも十分です。大切なのは、現状と理想を同じ粒度で並べて比べることです。図にするのは、その後でも問題ありません。
Q: To Beが理想論だけで終わりそうで不安です。
A: その不安は自然です。だからこそ、理想を出す時間と、実行案に落とす時間を分けるのが有効です。最初は広く案を出し、その後で優先順位、担当、期限を決めると前に進みます。
Q: 会議で意見が出にくい場合はどうすればいいですか？
A: いきなり全員発言にすると止まりやすいため、まずは付箋やテキストで個別に書き出してから共有すると意見が出やすくなります。匿名で集める方法も有効です。
Q: 分析した後、何を成果として見ればよいですか？
A: 代表的なのは、処理時間の短縮、差し戻し件数の減少、確認回数の削減、引き継ぎ漏れの減少です。改善前後で比べられる指標を1つでも決めておくと、効果を判断しやすくなります。
筆者について
記事を読んでくださりありがとうございました！ 私は スプレッドシートでホームページを作成できるサービス、SpreadSite を開発・運営しています！ 時間もお金もかけられない、だけど魅力は伝えたい！ という方にぴったりなツールですので、ホームページでお困りの方がいたら、ぜひご検討ください！ https://spread-site.com
