AS-IS／TO-BEとは何か｜形骸化を防ぎ、利益につなげるための再設計

4月が近づくと、多くの企業で目標設定や中期計画の議論が本格化します。売上目標、利益率、投資計画、人員配置。経営会議では「まずは現状を整理しよう」「あるべき姿を明確にしよう」という言葉が自然に使われます。

AS-IS（現状）とTO-BE（あるべき姿）。
合理的で、説明しやすく、誰もが理解できる思考法です。

現状を把握し、目指す姿を描き、その差分を課題として特定する。論理的であり、再現性もある。業務改善、IT導入、組織改革、経営戦略立案など、ほぼあらゆる領域で使われています。

にもかかわらず、多くの企業で次のような現象が起きています。

毎年AS-IS／TO-BEを実施しているが、本質的な構造は変わらない
計画は精緻だが、実行が弱い
分析は深いが、利益への接続が薄い
翌年また同じ議論を繰り返している

AS-IS／TO-BEは間違っているのでしょうか。
それとも、使い方に問題があるのでしょうか。

まずは、このフレームワークの一般的な定義と射程を正確に整理します。

AS-IS／TO-BEの意味と定義
AS-IS／TO-BEフレームワークの基本手順
AS-IS／TO-BEは合理的であるにもかかわらず、なぜ機能しないのか
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は、それらを一枚の設計図として統合する工程です。

As-Isの精度が低いままTo-Beを描けば、議論は願望に流れます。
As-Isは、思考の土台を揃えるための工程です。

To-Be（あるべき姿）の定義

To-Beは「将来到達したい状態」を明確にすることです。

売上を伸ばす、顧客満足度を高める、業務効率を改善する。これらは方向性にすぎません。To-Beは、それを数値や構造として具体化します。

どの市場で、どの顧客層に対し、どの水準まで売上を伸ばすのか。
どのプロセスを、どの程度短縮するのか。
どの組織体制に再編するのか。

To-Beは理念ではなく設計目標です。実行可能性と資源制約を前提に描かれなければなりません。

経営レイヤーにおいてTo-Beは、「何に資源を配分するか」を決める基準になります。やれることではなく、やるべきことを選別するための軸です。

AS-ISとTO-BEの関係

AS-ISとTO-BEは、現在と未来という時間軸で説明されます。

AS-ISは現在の設計図
TO-BEは未来の設計図

両者を比較し、その差分を特定します。この差分が「ギャップ」です。

そして、そのギャップを埋めるための施策を設計する。
ここまでが、一般的に整理されるAS-IS／TO-BEフレームワークです。

重要なのは、ギャップを単なる数値差として扱わないことです。売上が10億円不足しているという事実だけでは不十分です。なぜ不足しているのか。どのプロセスが滞っているのか。どの資源配分が最適でないのか。ギャップは因果の入口です。

AS-IS／TO-BEフレームワークの基本手順

一般的な進め方は次の通りです。

テーマを定める
To-Beを定義する
As-Isを整理する
ギャップを特定する
ギャップを埋める施策を設計する

この構造は合理的です。
議論の順序が明確で、説明責任を果たしやすく、再現性も高い。

特に経営レイヤーでは、To-Beを先に定義することで、現状分析の焦点が定まります。目指す姿が曖昧なまま現状を整理すると、情報が拡散します。逆に、To-Beが具体であれば、As-Isの整理も戦略的になります。

そして、ギャップを特定し、施策を設計する。ここまでがフレームワークの範囲です。

AS-IS／TO-BEは合理的であるにもかかわらず、なぜ機能しないのか

ここまでを見る限り、AS-IS／TO-BEは合理的であり、欠陥は見当たりません。構造も明確で、進め方も整理されている。

それでも現実には、

分析は行われるが、実行力が伴わない
施策は立案されるが、利益に結びつかない
翌年また同じギャップが残っている

という現象が繰り返されます。

フレームワークは施策設計まで含んでいる。
それでも成果に差が出るのはなぜか。

問題は手順ではないのか。
それとも、手順の「使い方」にあるのか。

AS-IS／TO-BEが形骸化するとき、何が起きているのか。

この問いから、再設計の議論が始まります。

AS-IS／TO-BEがうまくいかない理由｜形骸化・失敗・陥りがちな罠

AS-IS／TO-BEは合理的なフレームワークです。
にもかかわらず、なぜ「うまくいかない」「形骸化する」「毎年同じ議論になる」という現象が起きるのでしょうか。

ここでは、AS-IS／TO-BEが失敗するときに起きている典型的な構造を整理します。手順そのものではなく、思考の深度と運用の質に焦点を当てます。

AS-ISが“状態の報告”で終わる問題

AS-ISがうまくいかない最初の理由は、現状整理が「状態の報告」で止まることです。

売上が前年比マイナス3％
受注率が低下している
新規顧客数が減少している

これらは事実です。しかし、事実の列挙は構造理解ではありません。

売上が落ちている。
なぜか。

市場が悪い。
競合が強い。
価格競争が激しい。

このレベルで止まると、AS-ISは報告資料になります。

AS-ISの本来の役割は、構造を描くことです。

なぜ特定市場への依存度が高いのか
なぜ価格競争に巻き込まれやすい設計になっているのか
なぜ新規顧客が定着しない構造なのか

状態を構造にまで分解しなければ、TO-BEは単なる目標設定になります。

ギャップを“数値差”として扱う失敗

AS-IS／TO-BEの失敗例として多いのが、ギャップを単なる数値差として扱うことです。

売上目標との差：10億円
粗利率目標との差：3％

差は明確です。しかし、その差を埋める施策が

営業人員を増やす
広告費を増やす
キャンペーンを強化する

といった「投入量の増加」に偏ると、設計は変わりません。

ギャップは不足量ではなく、設計のズレです。

なぜ現在の営業プロセスでは目標に届かないのか
なぜ顧客単価が伸びない構造なのか
なぜLTVが低い設計なのか

数値差の背後にある因果を見なければ、AS-IS／TO-BEは数値管理の延長になります。

外部環境帰属という罠

AS-IS／TO-BEが形骸化するとき、議論は外部要因に収束しやすくなります。

市場環境の悪化
顧客ニーズの変化
競争激化

これらは重要な要素です。しかし、すべてを外部環境に帰属させると、内部設計の議論が止まります。

市場が悪いから売上が落ちた。
競合が強いから価格が下がった。

それは一部事実でしょう。しかし、

なぜ価格競争に耐えられない構造なのか
なぜ差別化できない設計なのか
なぜ顧客接点が分断されているのか

この問いを避けると、AS-ISは環境分析で終わります。

経営レイヤーで起きる“構造回避”

経営層ほど、AS-IS／TO-BEは抽象化されやすい傾向があります。

ビジョンを掲げ、数値目標を設定し、部門に展開する。
ここまでは明確です。

しかし、次の領域に踏み込むと議論は鈍ります。

評価制度
権限設計
意思決定階層
情報流通
役割定義

これらはギャップの原因になりやすい領域です。同時に、摩擦を生みやすい領域でもあります。

その結果、

「段階的に見直そう」
「まずは現場改善から」
「タイミングを見て検討する」

といった結論に収束しやすい。

穏当であること自体は問題ではありません。しかし、構造に触れない限り、ギャップは再生産されます。

「分析した気になる」ことの危険

AS-IS／TO-BEは資料として整理しやすいフレームワークです。

現状整理
あるべき姿
ギャップ図
施策一覧

整然と並びます。

整っている資料は、思考も整ったように感じさせます。しかし、

因果が曖昧なまま
優先順位が慣習的なまま
投資配分が過去踏襲のまま

であれば、それは設計ではありません。

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／TO-BE分析が浅くなるのは、
因果の連鎖を途中で止めてしまうからです。

ギャップを“設計のズレ”として定義する

ギャップを数値差ではなく設計差として捉え直します。

売上10億円不足。
ではなく、

現在の営業設計では月間受注件数が上限に達している
マーケティング設計が新規顧客獲得に偏り、既存顧客育成が弱い
情報が部門間で分断されている

このように、設計レベルでのズレを定義します。

ギャップを設計差として捉えると、
施策も自然に構造レベルに上がります。

人員増加ではなく、
プロセス再設計。

広告費増額ではなく、
顧客データ活用設計。

AS-IS／TO-BEは、ここまで踏み込んで初めて経営フレームワークになります。

痛みを最小化する議論設計

構造に踏み込むと摩擦が生まれます。
評価制度、権限設計、意思決定階層。これらは人と直結しています。

そのため、いきなり制度や組織の問題に踏み込むと、防衛反応が生じやすい。

ここで有効なのが、資源視点から入る設計です。

自社の強みは何か
どの資源が競争優位を生んでいるか
どの資源が十分に活用されていないか

強みの再確認から始めると、議論は攻撃的になりにくい。

そのうえで、

なぜこの強みが再現されないのか
なぜ拡張できないのか

という問いに進むことで、自然に構造議論へ移行できます。

これはAS-IS／TO-BEの手順を変えるのではなく、
議論の順序を設計するという発想です。

経営レイヤーでのAS-IS／TO-BE再設計

経営層がAS-IS／TO-BEを実施する際、最も重要なのは「資源配分」との接続です。

AS-ISで構造を描き、
TO-BEで目標を定義し、
ギャップを特定する。

ここで止まると、分析になります。

そこから一段進めて、

どの資源を再配分するのか
どの事業を縮小するのか
どの投資を止めるのか

この決断まで接続できて初めて、AS-IS／TO-BEは経営装置になります。

構造に触れるとは、
最終的に資源配分に触れることです。

ここを避けると、分析は戦略資料に留まります。

AS-IS／TO-BEを“思考装置”にする

AS-IS／TO-BEはテンプレートではありません。
思考装置です。

現状をどこまで深く描けるか
目標をどこまで具体化できるか
因果をどこまで接続できるか

この三つの深度が、成果の差を生みます。

形だけ整えても、
思考が浅ければ、結果は変わりません。

AS-IS／TO-BEを機能させるとは、
構造を描き、因果を接続し、資源配分にまで落とし込むことです。

ここまで到達して初めて、
AS-IS／TO-BEは利益に接続します。

AS-IS／TO-BEを利益に接続する｜因果設計と資源配分の具体化

AS-IS／TO-BEが機能するかどうかは、「因果をどこまで設計できるか」にかかっています。

ギャップを確認することと、ギャップを再現性を持って埋めることは別です。
その間にあるのが因果設計です。

因果設計とは、「なぜそうすれば目標に到達するのか」を言語化することです。

売上を伸ばす。
ではなく、

顧客単価を上げる
購買頻度を上げる
新規顧客獲得効率を上げる

そのどれを選ぶのか。
さらに、その指標を動かすレバーは何か。

AS-IS／TO-BEが浅い場合、この因果が曖昧です。

因果を分解する

売上を構成するのは、

売上＝顧客数 × 客単価 × 購買頻度

この式自体は単純です。
しかし、どこを動かすのかによって、必要な構造は変わります。

例えば「顧客単価を上げる」場合。

商品構成の見直し
クロスセル設計
アップセル提案プロセス
営業インセンティブ設計

これらが関わります。

ここで重要なのは、「単価を上げる」という目標を掲げることではありません。
単価を上げる構造を再設計することです。

AS-IS／TO-BEが失敗する企業は、
単価向上というTo-Beを掲げても、営業評価制度は変えません。
商品設計も変えません。
情報共有プロセスも変えません。

つまり、因果が途中で切れています。

CRMを例にした因果設計

「売上を上げるためにCRMを強化する」というテーマは、多くの企業で見られます。

しかし、このテーマ自体が曖昧です。

CRM強化とは何を意味するのか。

顧客データを統合することか
MAツールを導入することか
セグメント配信を強化することか
カスタマーサクセス体制を作ることか

CRMは手段です。
目的ではありません。

AS-ISを構造で捉えると、

顧客情報が部門ごとに分断されている
過去購買履歴が営業に共有されていない
既存顧客フォローが属人的になっている

という構造が見えてきます。

To-Beを具体化すると、

顧客単価を15％向上させる
既存顧客の年間購買頻度を1.4倍にする

といった目標になります。

ここで初めて、因果を設計します。

顧客情報統合 → セグメント精緻化 → パーソナライズ提案 → 客単価向上
カスタマーサクセス体制構築 → フォロー接触増加 → 購買頻度向上

この因果が明確であれば、
CRM導入は単なるIT投資ではなく、構造再設計になります。

しかし、

ツール導入だけ
データ蓄積だけ
システム刷新だけ

で止まると、因果はつながりません。

AS-IS／TO-BEを利益に接続するとは、
ツールではなく構造を動かすことです。

資源配分まで落とす

因果が明確になったら、次は資源配分です。

どの部門に何人配置するのか
どの予算を削り、どこに再投資するのか
どのプロジェクトを止めるのか

ここに踏み込まなければ、因果は実行に移りません。

AS-IS／TO-BEが分析で終わる企業は、
この資源配分に触れません。

既存の事業を守りながら、新規施策も追加する。
結果として、どれも中途半端になる。

構造を変えるとは、
資源の流れを変えることです。

ここまで到達して初めて、
AS-IS／TO-BEは経営の意思決定装置になります。

プロジェクトと縦組織の両方に効く

この因果設計の考え方は、プロジェクト単位でも、縦組織でも有効です。

プロジェクトであれば、

成果指標
プロセス設計
役割定義
意思決定フロー

縦組織であれば、

評価制度
権限設計
情報流通
資源配分

いずれも因果の接続で設計されます。

AS-IS／TO-BEは、単なる業務改善フレームワークではありません。
資源と構造を再設計するための思考装置です。

まとめ｜AS-IS／TO-BEを“使っている”から“使えている”へ

AS-IS／TO-BEは合理的です。
だからこそ、多くの企業が使っています。