ERP知識シリーズ The・MoSCoW 第五部：MoSCoWのケーススタディ【後編】ベストケースシナリオ
経営陣から「基幹システムを刷新せよ」との指令が下った。
理由は一つではなかったが、経営としては先を見越した判断だ。システムの老朽化、保守切れ、日々高まるセキュリティリスク。今は何とか回っていても、この先も同じやり方で通用する保証はない。「まだ大丈夫」ではなく、「手遅れになる前に」。そんな判断だった。
その指令を受け取った実行側として、まず感じたのは不安だった。これまでの基幹システムは業務ごとに分断され、ITベンダーに丸投げしている領域も多い。正直なところ、自分たち主導で何から手を付ければいいのか、すぐに答えが出る話ではない。最初の一歩目を誤ったことで、後々まで影響が残った事例も嫌というほど見聞きしてきた。
“真”のFTS
だから、まずは勉強することにした。早速、ベンダーが主催するセミナー「SaaSタイプのERPをFit to Standard（FTS）アプローチで成功する方法」に参加した。そこで知ったのは、自分が思っていたFTSとはまったく違う考え方だった。
FTSとは、「業務をシステムに合わせる」ことだとばかり思っていた。しかし、そこで語られていたのは、BPRの実現に向けて業務を標準化すること。その結果として、システムに自然と合い、さらに将来にわたってビジネス環境の変化に追随し、ITの進化を享受できるという考え方だった。そして何より重要なのは、この変革が必要だと理解し、組織そのものが変わること。その大前提があってこそのFTSなのだと。これは腑に落ちた。
これを自社に当てはめて考えてみると、簡単な話ではないこともすぐに分かった。できるかどうか以前に、やる必要があるのか。そして、もしやらなければどうなるのか。そう考えると、答えは明確だった。このままでは、変化に対応できない。だからこそ、やるしかない。
プロジェクトの意義
とはいえ、勢いだけで進めてうまくいく話ではない。まず考えたのは、なぜ今やらなければならないのか、という点だった。システムが古いから、というのはきっかけ（トリガー）でしかない。現場が大変だから、でも足りない。このままだと何が起きるのか、そして何が失われるのかを、「やらないリスク」として整理する必要があった。
会社として何を成し遂げたいのか（経営課題：Needs）。次に、それをプロジェクトとして何を実現するのか（プロジェクトの目的：Goals）。そして、To-Beの姿と今のやり方を並べたとき、どこを変えなければならないのか（ビジネスモデル変革：Change）。この三層で考えてみると、はっきり見えてきた。足りないのは機能ではない。限界に来ているのは、我々のやり方のほうだ。今の延長線に新しいERPを置いたところで、同じことを少し速く、少し楽にやるだけで終わってしまう。
「このままではいけない。」覚悟を決めて、次の議論に進めた。
稼働後にどうなっていたいのか。その姿を、現実の行動につなげるために明確にした。業務効率やリードタイム、判断スピードなど、いくつかのKPIを定めたのは、そのためだ。KPIは、単に数字を追うためのものではなく、何を改善すべきか、どこまで改善できているかを具体的に測り、行動を導く基準になる。改善の方向が見えるからこそ、チームは迷わずに動くことができる。
このように、変わった先の姿を具体化し、改善の基準を共有すること自体が、チェンジマネジメントの本質だと理解した。ここから先は、システム導入ではなく、変化を起こすための行動そのものの設計であり、変わることを前提にしなければ、どんなに立派な計画も途中でAs-Isに引き戻されてしまう。
プロジェクトメンバー選出と支援体制
さて、そのためには、誰と進めるのかが決定的に重要になる。まずはプロジェクトメンバーの選出から始めた。業務やITスキルなどの専門知識だけでなく、変化を前向きに受け入れられるか、やり切る覚悟があるかを重視した結果、若手中心のメンバー構成になった。各業務領域の熟練者には直接の参画は難しかったが、熟練者がプロジェクトを全面的に支援することを部門長から約束してもらえた。それに、新しいことに取り組むのだから、むしろ若手の方が固定観念にとらわれず、新システムの吸収も早いだろう。会社からプロジェクトルームも用意してもらい、いよいよプロジェクトらしくなってきた。
要求管理の本質
要求が具体化し始めると、最初に学んだFTSの考え方が、ここで生きてきた。意見や要望をそのまま並べるのではなく、To-Beヒアリングで導いた目指す姿と、現行業務から外せない制約条件を、あらかじめ整理していく。その上で、それぞれの要求を、目的や制約条件との関係で見ていった。本稼働に影響するものは何か、取引先との関係で外せないものは何か、社内で完結するものは何か。こうした切り分けを、最初に決めた考え方に沿って行っていくことで、MoSCoWが本来の役割を果たし始めた。
CRPでは、その違いがさらに明確になった。CRPはデモを見る場ではなく、意思決定の場だった。To-Beに近づくのか、それともAs-Isを再生産するのか。その判断が積み重なり、As-Is踏襲の要求は自然と姿を消していった。
伴走から自走へ、ILUOで習熟度評価
CRPを意思決定の場として機能させるためには、もう一つ欠かせない前提があった。ユーザーがERPを使いながら検証できる状態にあることだ。操作に慣れていなければ、画面を追うだけになり、結局は「今の仕事と比べてどうか」という議論に戻ってしまう。そこで、ユーザー習熟度を放置せず、ILUOで可視化して管理することにした。
I（指導を受けながら作業できる）、L（一人で作業できるが指導が必要なことがある）、U（一人で作業できる）、O（熟知し、他者に教えられる）。この4段階で、誰がどの業務領域を、いつまでにどのレベルまで到達するのかを明確にした。遅れが出た場合は、習熟度の高いメンバーがフォローに回る。こうして、CRPで本質的な検証ができる状態を整えていった。
プロジェクト終盤には、Oに達するメンバーも現れ、ベンダーの支援がなくてもエンドユーザ向けの説明やトレーニングを回せるようになっていた。人に説明することで理解が深まり、結果としてマニュアル整備やノウハウの蓄積も進んだ。本稼働後を見据え、自分たちで運用し続けられる状態が、この段階で見え始めていた。
本稼働判定を定量化する
本稼働判定にあたっては、定量的に判断することを前提に進めた。これからの業務を安定して運用し続けられるかを見極めるための判断である。そのため、評価の観点と基準を先に定めた。業務やデータが一通り揃っているかという網羅性、日々の業務を想定して実機で検証できたとする稼働性、To-Beとして目指した姿に合っているかという適合性、そして稼働後も自分たちで運用し続けられるかという継続性。これらの評価軸に沿って、業務・データ・システム・人・移行・運用といった領域を確認していった。評価は、あらかじめ定めた評価項目と指標に基づいて行い、結果を評点とコメントで整理した。点数そのものではなく、どこが満たされ、どこに課題が残っているのかを明確にすることが目的だった。
ついに新システムが本稼働した。稼働後、変化ははっきりと現れた。ビジネス環境の変化への対応は早くなり、現場で判断できることが増えた。内製で継続的に改善を回せるようになり、生産性も向上した。KPIはリアルタイムで可視化され、議論は事実に基づいて行われるようになった。何より大きかったのは、意思決定の質が変わったことだ。
ベストケースシナリオのまとめ
以上がベストケースシナリオです。今回はユーザー視点で描きました。ワーストケースシナリオとベストケースシナリオを分けた分岐点は、ERPが優れていたことやユーザー企業の業務にシステムが合っていたことだけではありません。最初に考え方を学び、なぜ変わるのかを理解し、その学びを守りながら実践を積み重ねられたかどうか、その違いです。
そして、その中心にあったのがMoSCoWです。MoSCoWは、業務やシステムをAs-IsからTo-Beへ移行するための重要な役割を担います。本シリーズの第1回で示したこの考え方は、理論として語られただけでなく、本ケーススタディを通じて、実務の中でどのように機能するのかが具体的な形として示されました。
8月から始まった「The・MoSCoW」シリーズは、今回で全20回となります。ここまでお読みいただき、ありがとうございました。
