変革の本質は、今の仕事を写すことではなく、次の型を決めることです
企業変革の現場では、よく「まずAs-Isを正確に把握しましょう」と言われます。
現状を理解しないまま未来は描けない。これは一面では正しいです。
実際、現場で何が起きているのか、どこに例外があるのか、どの部門が何をしているのかを知らずに進める改革は、たいてい机上の空論になります。
ただし、ここに大きな落とし穴があります。
それは、As-Isを丁寧に描きすぎると、現行業務を守ること自体がプロジェクトの目的にすり替わることです。
このすり替わりは、非常によく起こります。
現場にヒアリングする。
例外を拾う。
顧客ごとの事情を確認する。
部門固有の運用を文書化する。
一見すると、まじめで丁寧な進め方です。
ですが、それを積み上げていくと、次第に「この例外も必要」「このやり方にも事情がある」「ここは現場が困るから残すべきだ」という論点が増えていきます。
その結果、To-Beは未来の業務ではなく、現在の複雑さをより美しく整理しただけのものになりやすいです。
これは、多くのDXプロジェクトが陥ってきた罠でもあります。
現行を理解することと、現行を保存することは違います。
ですが実際のプロジェクトでは、この二つがすぐに混ざります。
特に、現場への配慮や社内合意を重視する文化が強い会社ほど、現行運用をできるだけ残す方向へ引っ張られます。
結果として、標準化するはずのシステムに例外が増え、SaaSを導入しても人の手間は減らず、部門間の断絶も残り続けます。
そして最後には、「結局また増えただけだった」という疲労感だけが残ります。
だから、SaaSと生成AIを前提にした変革では、発想の順番を変える必要があります。
もちろん現状は見ます。ですが、その目的は現行業務を精密に再現することではありません。
目的は、何が価値で、何が惰性で、何が例外で、何がただの“つなぎ”なのかを見抜くことです。
つまり、As-Is分析は写経ではなく選別のために行います。
これが従来の業務改善との大きな違いです。
ここで鍵になるのが、SaaSをどう捉えるかです。
多くの企業では、SaaSは「今の業務を効率化するためのツール」として見られがちです。
ですが本来、SaaSはもっと強い意味を持ちます。
SaaSは単なる道具ではなく、**会社を標準業務へ寄せる“型”**でもあります。
この考え方に立つと、問いは変わります。
「現行業務をどうSaaSに乗せるか」ではありません。
「どこまで現行を手放して、SaaS標準の型に会社を寄せられるか」です。
この違いは大きいです。
前者では、現行の複雑さが前提になります。
後者では、複雑さのうち何を切るかが前提になります。
つまり、SaaS導入はシステム選定の話ではなく、経営判断としての標準化の話になるのです。
ただし、ここでSaaSだけを見ていても不十分です。
部門ごとにSaaSを導入するだけでは、断絶は消えません。
営業には営業のSaaS、経理には経理のSaaS、現場には現場のSaaSがあり、それらをまた人がつないでしまえば、会社の負荷構造は大きくは変わらないからです。
そこで重要になるのが、APIやiPaaSといった連携層です。
この連携層は、見た目には地味です。
派手な画面もありません。
ユーザーが直接触れる場面も少ないです。
ですが、ここでデータ同期、イベント連携、ワークフロー接続、ログ管理ができるようになると、これまで人が担っていた“受け渡し”が一気に薄くなります。
つまり、API連携層は、SaaSの価値を支える裏方であると同時に、ホワイトカラーのつなぎ仕事を溶かす中核でもあります。
さらに、BI・分析層が入ると意味が変わります。
今まで多くの会社では、数字を見ること自体が仕事になっていました。
集計して、貼り付けて、比較して、説明用に整える。
ですがBIや分析基盤が本当に機能し始めると、見るための仕事は減ります。
代わりに、「見えた数字をどう判断し、どう動くか」が仕事になります。
ここでようやく、営業採算、管理工数、未請求、例外件数、支店別収益、荷主別条件といったものが、報告資料ではなく意思決定の道具になります。
生成AIは、この構造にさらに別の力を加えます。
SaaSが業務機能を持ち、APIが流れをつなぎ、BIが数字を見せる。
その上で生成AIは、検索、要約、文書ドラフト、分析支援、問い合わせ一次対応、異常値の説明補助、Text-to-SQLのような横断的な知的作業を担います。
つまり生成AIは、単体の部門機能ではなく、会社全体の知的な中間処理を薄くするレイヤーです。
ここで重要なのは、AIを部門別に積み増すことではありません。
重要なのは、会社の横断レイヤーとして置くことです。
営業のAI、経理のAI、総務のAIと分けて考えるより、会社全体の問い合わせ、検索、要約、説明、分析をどう支えるかで考える方が、本質に近づきます。
この構造が見えてくると、第6章で出てきた「半分で足りる」という感覚の正体も分かってきます。
人数が先に減るのではありません。
まず、現行業務の中に埋もれていた“つなぎ”や“重複”や“説明のための作業”が減ります。
その結果、従来のホワイトカラー業務量は大きく変わります。
つまり、ホワイトカラー半減の出発点は、人を切る設計ではなく、現行再現を捨て、標準化された新しい型へ会社を乗り換える決断にあります。
当然、ここには強い抵抗が生まれます。
営業は「うちは特殊だ」と言います。
現場は「現場事情を分かっていない」と言います。
管理部門は「例外があるから簡単には標準化できない」と言います。
どれも一理あります。
ですが、その一理を全部残していくと、結局また人が配線になります。
マスタは統一されず、例外は温存され、データはつながらず、SaaSは増え、人は減らないまま疲弊します。
だからこそ、変革において重要なのは“丁寧に全部を救うこと”ではなく、どこまで救わないかを決める勇気です。
このとき大切なのは、粗暴になることではありません。
現行を全部切り捨てることでもありません。
本当に必要なのは、価値のある例外と、惰性で残っている例外を区別することです。
残すべきものは残す。
ただし、条件なく残し続けない。
その見極めが、設計図の質を決めます。
変革の成否は、導入段階で決まると思われがちです。
ですが実際には、その前の設計段階でほとんど決まっています。
現行を守る設計をすれば、導入後も人の仕事は減りません。
標準へ寄せる設計をすれば、導入後に痛みは出ますが、流れは変わり始めます。
つまり、設計図とはITの図面ではなく、会社がこれから何を仕事と呼ぶのかを決める文書でもあります。
次の章では、その設計図がいよいよ現実にぶつかります。
マスタの汚さ、例外処理、教育不足、現場の反発。
理想がきれいに進まないのは当然です。
ですが、本当に重要なのは、そこで設計思想を捨てないことです。
現行再現へ戻るか、標準の型へ進むか。
その分岐点に、次の章の面白さがあります。