SaaS ERPをFTSで導入するためのチェンジマネジメント 総論賛成から各論反対／意識改革の分岐点 その3：変わるべきは自分たち
前回の「その2：経営者インタビュー」に続き、今回は「変わるべきは自分たちかもしれない」と気付く契機となるTo-Beヒアリングにについて解説します。
第三ステップ：内省〜改善点を探る〜
ERPの導入が決定すると、誰もが前向きに取り組み始めます。しかし、それが本当に自分自身の意思によるものとは限りません。導入されるパッケージが、自分がかねてから推奨していたものではなかったり、長年かけて必要な機能を補ってきた現行システムには、たとえ古いテクノロジーであってもそれなりの愛着があるものです。
こうした背景から、表向きには賛成しているように見えても、内心では消極的な抵抗感を抱いている。そんな状況が少なからず存在しているかもしれません。
そして、抵抗を放置すると、些細な出来事をきっかけに「このシステムでは仕事が回らない」と抵抗が表面化します。その多くは「業務の属人化」や「現状のやり方に対するこだわり」が残っているためで、本当に変える必要があるのか？という内なる抵抗があるのです。
この抵抗は根強く、たとえ初期段階のスタートアッププログラムで変革の必要性を理解し、経営者インタビューで共感が芽生えたとしても、自分の仕事の領域になるとやはり抵抗が起きます。自分の仕事を他人から「こう変えましょう」と言われてもそう簡単には受け入れられないでしょう。
人は「自ら考えたこと」に主体的に動く
そこで実践するのが「To-Beヒアリング」です。単に現状の業務を確認するだけではなく、なぜこの仕事の仕方をしているのか？、もしこういうことができたらどうするか？、というように現状の仕事の仕方やシステムの問題点をあぶり出し、その上で新しいやり方に気づいてもらうのです。ここで一番大事なことは、「答えは言わない」ということです。ここでいう答えとは、ユーザーが新しくやることを指します。これをやらせる側から言ってしまうとユーザーはやらされ感を持ってしまい、どんなに正しいことでも自発的に行動しない恐れが残ります。故に、現状の業務や考え方を振り返り、改善の余地に「変わるべきは自分たちかもしれない」と自ら気づいてもらうのです。
業務から発想するTo-Beの描き方
以前のTo-Beヒアリング解説記事でも述べたとおり、重要なのは機能ではなく業務に焦点を当てることです。「新しいシステムではどういったことができるのか？」の問いに答えてしまうと、どうしても現行システムでできることに捉われてTo-Beに向かわなくなります。目的は、関係者との対話を通じて、あるべき業務を描くことです。そのため、FTSアプローチにおいて重要なのは、「ERPパッケージに備わっている“機能”を、ユーザー自身の気づきにつながる問いかけの中にさりげなく組み込むことです」。それを“機能”として直接説明してしまってはいけません。「機能の話を機能として話さない」というのは少し奇妙に思えるかもしれませんので、具体例でご説明します。
業務の中に隠された改善機会に気づくには
たとえば、受注時に納期確認を行う業務を例に挙げてみましょう。
現行システムでは、受注入力後すぐに在庫照会画面が自動で立ち上がり、受注品番の在庫状況を確認する運用が定着しています。さらに、手持ち在庫だけでなく将来の供給（入荷・生産予定）も含めた情報が参照できるため、担当者は在庫を手動で予約し、納期回答の確実性を担保しています。
このような運用に対して、新システムではATP（Available to Promise）機能を活用する想定です。とはいえ、To-Beヒアリングの場で「ATPという機能があります」と直接説明するのではなく、次のような問いかけを通じて業務の本質に対する気づきを促すことが重要です。
たとえば、
「先納期の注文でも在庫予約を行いますか？」 「その結果、急ぎの注文が欠品することはありませんか？」
といった問いを投げかけることで、在庫の使い方そのものが納期回答の質に直結するという認識を、担当者自身に持ってもらいます。
ここで重要なのは、機能の説明をするのではなく、その機能が解決しようとしている課題の本質＝在庫の有効活用という観点から会話を進めることです。
こうした問いにより、担当者は「今のやり方で本当に最適なのか？」と自ら考え始め、機能ではなく業務としての改善点に目を向けるようになります。これこそが、To-Beヒアリングの最大の価値です。
「なぜそうしているのか」を問い直す
もう一つの例として、頻繁な生産計画の変更を取り上げてみましょう。
現状業務のヒアリングを表面的に行うだけでは、「需要が頻繁に変動するから、生産計画も柔軟に変えられるようにしたい」という要望で終わってしまうかもしれません。しかし、ここに本質的な問いを加えることで、業務の構造そのものに気づきを促すことができます。
たとえば、次のような質問を投げかけます：
需要変動の要因は何ですか？
この問いは、生産管理担当者だけでは答えきれないため、営業や需給部門など、他部門との連携を引き出すきっかけになります。
安全在庫の持ち方はどのようにしていますか？
これは、生産計画が需要変動の影響をどの程度受けるのか、その“緩衝材”として機能しているかを確認する問いです。
これらの問いを通じて、単なる「変更しやすい仕組みがほしい」という要望の裏にある、予測の精度や前提の曖昧さ、そして業務のつながりの不在が浮かび上がってきます。
“当てる”予測ではなく、“見直せる”予測へ
ここで注意したいのは、「需要予測の精度を上げる」とは、不確実な未来を完璧に予測することではありません。重要なのは、以下の2点です：
需要予測の見直しを短いサイクルで回すこと 予測が外れたときの要因を明確にすること
これにより、生産計画を人手で調整せずとも、自動的に構築できる基盤が整っていきます。
安全在庫は“根拠ある設計”になっているか？
一方、安全在庫のあり方にも課題が潜んでいます。
実態としては、生産管理部門は需要予測を鵜呑みにはできず、「実需ベースで生産する」傾向が強く、安全在庫の量に明確な算出根拠がなく、見直しもされていないというケースがほとんどです。
しかし、こうした状況に対して、「安全在庫機能があります」といった機能起点のアプローチをしてしまうと、本来見直すべきはずの需要予測や生産計画の在り方が後回しになってしまいます。
目的は、業務のあるべき姿に近づくこと
だからこそ、To-Beヒアリングでは、業務の背後にある前提や設計に対して「なぜそうしているのか？」と問い直すことが重要です。
機能の話にすり替えるのではなく、あくまでも業務プロセスの改善機会を探る視点で対話を進めることで、関係者自身が「このやり方を変えるべきかもしれない」と気づくことができるようになるでしょう。
単に機能を学ぶことではないということ
ここまで見てきたように、業務を変えるためには、担当者自身が「なぜそうしているのか？」を問い直し、納得の上で新しいやり方を受け入れる必要があります。
この点を踏まえると、FTSアプローチにおいて重要なのは、ERPパッケージに実装されている標準機能を“覚えて使ってもらう”ことではないということが見えてきます。
もちろん、新規事業や海外拠点の立ち上げといった、業務の前提がまだ定まっていない場面では、機能の習得を起点とした導入が有効に機能するケースもあります。しかし、既存業務が長年にわたって定着し、そこに担当者という“役割”が根を張っている場合、単なる機能教育では変革は起こりません。
むしろそのような場面では、既存業務の目的や構造をゼロベースで見直すBPR（Business Process Reengineering）型のアプローチのほうが、本質的な変化に向き合えるのです。役割や判断のあり方ごと見直すことが求められる以上、“割り切って考える”姿勢が必要であり、FTSアプローチはそのための強力な枠組みでもあります。
担当者だけに任せない：BPOの役割
ここまでのステップでは、主に業務担当者個人に焦点を当ててきました。現状のやり方を見直し、「変わるべきは自分かもしれない」と気づいてもらうための対話と内省。これは、変革を始めるために必要不可欠な第一歩です。
しかし、変革は決してひとりで完結するものではありません。むしろ、ここから先が本当の始まりです。
業務プロセスの再設計（BPR）や、ERPの標準機能をどのように活用するかといった判断は、チームとして意思決定し、組織として進めていくプロセスです。つまり、個人の気づきはあくまで変革の入口にすぎず、本質的な改革を実現するためには、チーム全体の納得感と合意形成が不可欠なのです。
そして、このタイミングで特に強調しておきたいのが、業務担当者にすべてを任せきりにしてはいけないということです。たとえ担当者が「変わる必要がある」と頭では理解していたとしても、これほど大きな業務変更を自分ひとりの判断で進めるのは、心理的にも非常に大きな負担になります。
だからこそ、プロジェクト体制の中には、担当者を支える存在としてビジネスプロセスオーナー（BPO）を必ず配置すべきです。BPOが業務変更の背景や目的に深く理解を示し、その変革を共に背負う“後ろ盾”となることで、初めて担当者は安心して改善に取り組むことができます。
この「支えがある」という実感こそが、変革をチームで進めるという意識の出発点なのです。
まとめ：気づきは、変革の準備ではなく変革そのものである
今回取り上げたのは、「総論賛成・各論反対」の最も重要な分岐点となる、「気づき」のフェーズです。単に現状の業務を聞き取るのではなく、「なぜそうしているのか？」を問い直し、自らの中にある改善余地に気づく、これこそが、真の意味での変革の始まりです。
ただし、どれだけ納得感があっても、担当者ひとりで業務変更を背負うのは無理があります。だからこそ、プロジェクト体制には、業務の背景を理解し、変革の後ろ盾となるビジネスプロセスオーナー（BPO）の存在が必要です。担当者の気づきを、チームとしての意思へと引き上げること。それが、変革を現実のものにするための土台となります。
To-Beヒアリングは、ここで完結するものではありません。このステップで得られた気づきや認識をもとに、次はCRP（Conference Room Pilot）という検証の場に移っていきます。そしてCRP中にも、To-Beヒアリングの視点は引き続き重要になります。ただし、ここまでのヒアリングで「なぜ」「どうあるべきか」という思考の土台がしっかりできていれば、以降の議論は単なる機能確認に留まらず、業務設計と意思決定に直結する対話へと進化していくのです。
次回は、第四ステップ「習得：新たな知識を学ぶ」です。いよいよ、これまであえて封印してきた“機能の話”が登場します。ただし、ここまでの3ステップを経ているからこそ、もう「現行システムとどっちが便利か」といった機能の良し悪し論に陥ることはありません。議論は、常に業務改革に根ざしたものになるはずです。
