ERP知識シリーズ The・MoSCoW 第五部：MoSCoWケーススタディ①ワーストシナリオ
RFPが届いた。RFP本編以外には、別紙として、現行業務フロー、機能要求一覧表、非機能要求一覧表、現行システムの画面／帳票集、用語集が付いている。プロジェクト方針は「ERPの標準機能を活用する（Fit to Standard ）」とのこと。そして、ERP導入の目的にはこんなことが書かれていた。「老朽化（保守サポート切れ）対策」、「生産性向上」、「意思決定の迅速化」。さらに５つの改革テーマが挙げられており、その中には、脱Excel、紙による仕事をなくす「ペーパーレス化」とある。
機能要求一覧はどうだろう。「んっ？」。「Excelにエクスポート／インポートできること」…。RFP本編と矛盾しているではないか。「品目マスタに〇〇区分を設けて、△△の場合はXX倉庫に引当できること」？ これは現行システムの機能そのものですよね。「受注入力できること」とあるが、それはどんなERPでもできる。こんなことまで書いていて、一体、機能要求は何件あるのか。なんと、1,400件もの要求があるではないか。
それに「生産性向上」との目的に対して、具体的なKPIが何も書かれていない。例えば、FAXからの受注入力は1日何件あり、1件何分かかっているのか。ペーパーレス化なら、現状で紙がどれくらい使われているのか（枚数）が必要なのだが……。
もし、この様なRFPを受領したら、この要求を全てMoSCoWに記載してはいけません。それは、ERPベンダーの機能設計を焼き直しするような労力がかかるだけで、プロジェクトの目的には何一つ価値を与えないからです。
しかし、今回は「ワーストシナリオ」です。ここから先は、プロジェクトがどのような道を辿って、まるで「不毛地帯」のように出口の見えない消耗戦へ沈んでいくのかを見ていきます。
1,400件をすべて「機能検証」として管理してしまう
最初の判断は、驚くほど単純です。機能要求一覧の1,400件を、そのまま「機能検証の対象」として管理してしまいます。
ここでの“管理”は、要求の意図をほどいて目的に接続し直すことではありません。要求同士の関係を整理して、受入基準（何を満たせば導入判断できるか）を追記することでもありません。表に番号を振り、担当と期限を付け、ステータスを加えて、見える化することです。
MoSCoWも当然使われます。しかし、使い方が変質します。Must／Should／Could／Won’t が「優先順位」ではなく「ラベル」になり、貼り付けることが目的になります。Mustは「絶対に必要」、Shouldは「対応したい」に、Couldは「できれば」に変わっていきます。Won’tは最初から置かれません。やらないなら書かないのです。
こうしてMoSCoWは、要求を選び抜く枠組みではなく、要求を抱え込むための箱になっていきます。全部入っている安心感は増えますが、その分だけ目的からは遠ざかります。
ヒアリングの対象が「現行業務」と「現行システム」に
次に実施されるのはヒアリングです。別紙として現行業務フローと画面／帳票集も付いていますから、会話は自然と「今の業務」「今の画面」「今の帳票」に寄っていきます。
この時点で本来必要なのは、プロジェクト目的の言葉に照らして問い直すことです。生産性向上とは何をどれだけ減らすことなのか、意思決定の迅速化とはどの判断をどれだけ短縮することなのか、といった話に進まなければなりません。しかし会話の中心は現行の再現に固定されます。
Fit to Standard という方針が書かれていても、その場で起きているのは「現行業務を標準に合わせて再設計する議論」ではなく、「現行業務をできないと“困る”といった議論」です。その結果は大きく変わります。
ユーザーは「仕事の仕方は変わらない」と思っている
ユーザー側は、日々の業務を止められません。繁忙期もあり、属人性もあり、引継ぎも不安です。そのため、次のような前提で話が始まります。
「今の仕事の仕方は変えられない」
「システムだけが新しくなる」
「現行と同じことができれば大丈夫」
目的が抽象的なままだったことが、ここで影響してきます。生産性向上が何を指すのか、意思決定がどの判断を対象にしているのか、それを測るKPIは何か。これが定義されていないと、変えない前提が強くなり、要求は「“今の”再現」に向かって積み上がっていきます。
いきなり「画面」「見た目」「項目名」の要求が並び始める
ヒアリングが進むほど、要求は具体化します。ただし具体化の方向が、業務価値ではなく画面になります。
「一覧は今と同じ並びで」
「項目名は現場が慣れているので変えないで」
「ボタンの位置はこの方がいい」
「入力順が違うとミスが増える」
現場の切実さは理解できます。しかしこれらが“機能要求”として増殖すると、要求の粒度が揃いません。結果として、「受注入力できること」と「品目マスタに区分を設けること」と「Excel入出力できること」が同じ棚に並び、同じ優先度に見えてしまいます。同じ優先度に見えると、同じ密度で検証しようとし、検証計画は膨張していきます。
そしてこの局面で「業務やシステムをAs-IsからTo-Beへ移行するための重要な役割を担うMoSCoW」はなんのブレーキにもなりません。画面要求は「使いずらいと生産性が下がる」という理由でMust化しやすく、Mustが増えるほど、Mustの価値が薄まります。薄まったMustを守ろうとして、さらに“超Must”が追加される、ということがおきます。
ユーザー定義フィールドは、あっという間に使い切られる
現行システムの画面とERPの画面を並べて、項目を照らし合わせます。ユーザー定義フィールド膨張の始まりです。さらに、現行帳票にあった項目、Excelにあった列、紙の回覧に書いていたコメント欄など、あらゆる“現行の痕跡”を新システムに持ち込まれていきます。新しいプロセスなど関係ありません。今ある項目がなくなると不安になるからです。
ユーザー定義フィールドは便利です。便利だから増えます。増えると足りなくなります。足りなくなったところで「もう少し項目を足せませんか」という話になり、境界線が消えていきます。
こうして、ユーザー定義フィールドが尽きるころには、アドオン項目追加が“普通”になります。Fit to Standard は言葉として残っていても、実態は「標準の上に現行を積み上げる」状態になっていきます。
使いづらい機能はERPの外で補う、やがて中枢領域へ足を踏み入れていく
標準機能はすべての会社にとって“ちょうど良い形”にはなっていません。そのため不満が出るのは自然です。しかし、不満の扱いが「ERPの外で補う」に寄っていくと、話は変わります。
最初は小さな補完のつもりでも、補完はインターフェース開発を招き、インターフェース開発はマスタ同期を招き、同期は例外処理を招き、例外処理は運用ルールを招きます。運用ルールが増えるほどトレーニング時間は長くなり、問い合わせも増え、ERPと他システム間の整合を保つことが難しくなっていきます。
やがて「このままでは連携が管理できない」という声が出始めます。そこで登場するのが、システム構成図の真ん中に置かれる「データハブ」なるものです。統合のための“箱”として描かれますが、実態は、増え続ける連携をとにかく受け止めるための受け皿です。結果として、構成図の線はその箱へ集中し、「とにかく何でもデータハブにつなぐ」という状態になっていきます。
そして気づけば、想定していなかった領域まで手が伸びます。原価管理のような、会社の中枢を担う領域です。ここまで来ると、全体像を語れる人が減り、判断は遅れ、遅れた判断は追加コストを呼ぶ、という連鎖が進みます。
経営陣の「効果は？」に誰も答えられない
ある日、経営陣から問われます。
「で、効果は？ 生産性は上がるのか。」
答えられません。努力が足りないからではありません。最初から測る準備をしていなかったからです。
FAX受注は一日何件で、1件あたり何分かかっているのか。紙は月に何枚使われているのか。在庫照会は誰が何回しているのか。締め処理に何日かかっているのか。意思決定が遅れるボトルネックはどこなのか。こうした数字がないまま進んでいると、改善を証明できません。「測らないものは改善できない」とはまさにこのことです。
リスケと追加コストを繰り返し、ようやく本稼働
スケジュールは延びます。検証対象が1,400件あるので当然です。しかも内訳は、業務価値の確認ではなく、画面の一致、項目名の一致、現行ロジックの再現、外部パッケージ連携、アドオン項目追加です。
「ここまで来たら、やり切りましょう」という言葉が出ます。ここでの“やり切る”は、「目的を達成する」ではなく「動くようにする」です。現行と同じように見えるようにする、現行と同じように回るようにする、という意味での“完成”です。
何度かのリスケと追加コストの積み上げの末、本稼働の日が来ます。安堵もあります。しかし、ここからが本質的な話しです。
本稼働したのに、仕事の仕方は何も変わらない
現場はいつも通り忙しい朝を迎えます。新システムを開きます。しかし同時にExcelも開かれます。紙も印刷されます。メールで仕事のやり取りをしています。
「念のため」「今までのやり方が安心」「新しい画面に慣れていない」。理由はどれももっともらしく、すぐには否定できません。そして気づきます。仕事の仕方は、導入前とほとんど変わっていないことに。
脱Excelは達成されず、ペーパーレス化も達成されません。生産性向上は説明できず、意思決定の迅速化も体感として語れません。
ワーストシナリオの結末は、派手な失敗ではありません。静かな失敗です。「動いている」ので失敗に見えず、「稼働している」ので失敗を認めにくく、「要求は全部やった」ので反省点が見えにくいのです。要求を全部やることと、目的を達成することは別物です。しかし、この違いが最後まで共有されません。
ワーストシナリオのまとめ
このワーストシナリオでは、間違いがいくつも連鎖的に起きています。その始まりはRFPです。As-Is要求が大半を占めていたこと、KPIが定義されていないこと。要求を部門横断で見直していないこと。そしてプロジェクトが始まると、プロセス設計より先に項目マッピングが進んでしまうこと。さらに、プロジェクトの目的が議論から消えていくこと。経営陣の関与がほとんどないこと。そして何より、チェンジマネジメントが最初から最後まで存在しないことです。
RFPには現行の業務やシステムの機能をすべて書き上げ、「これで抜け漏れはない」と安心していたはずです。では、その安心はどこへ行ってしまったのでしょうか。
このワーストシナリオは、決して希少な出来事ではありません。今この瞬間も、どこかで同じような連鎖が現実のものとなり、関係者が辛い日々を過ごしているはずです。
次回は気分を一転し、「ベストシナリオ」を扱います。これまで19回にわたって続けてきた「The・MoSCoW」シリーズの総まとめとして、同じ題材を別の結末へ導く筋道を描きます。
