基幹システムの刷新が止まったと経営が気づくのは、たいてい追加費用の稟議が回ってきたときです。
しかしそのプロジェクトは、その半年以上前から、課題管理表の数字の上では止まっていました。
止まっているのに止まって見えないのは、経営に報告されている数字が「総件数」と「残件数」だからです。この2つは、プロジェクトが前進しているか停滞しているかを構造的に区別できません。残件が減っていても悪化していることがあり、横ばいでも前進していることがある。
一方、経営会議に上がってくる説明はたいてい2つに割れます。「現場が協力的でない」か、「ベンダーの力量不足」か。この2つは対立しているように見えて、実はどちらも検証されないまま並存するのが常です。検証する道具がないからです。
私はパッケージ導入プロジェクトのPMOとして、要件定義フェーズの課題管理を担当してきました。そこで分かったのは、この2説はどちらも課題管理表の数字で切り分けられるということ、そして止まるプロジェクトでは、そのどちらでもない第三の場所に滞留が起きているということです。
この記事では、3つの診断を挙げます。いずれも自社のプロジェクトで今週中に数えられるものにしました。
1.「カスタマイズが多い」は印象論。深さで割ると経営判断になる
パッケージ導入で必ず起きるのが、カスタマイズをめぐる議論です。
「標準機能に業務を合わせるべきだ」「いや現場の運用は変えられない」。この対立は、たいてい印象論のまま長期化します。カスタマイズが「多い」のか「少ない」のか、誰も同じ尺度を持っていないからです。
ここは技術論に見えて、実は分類の設計で解ける経営課題です。
カスタマイズを深さで5段階に分けます。
自社の製品に当てはめるときは、呼び方ではなく「アップグレードで壊れるか」で切ってください。
読み替えはこうなります。
- 壊れない→ Lv1〜2
- 壊れる可能性があり、検証工数が要る→ Lv3
- 確実に上書きされる→ Lv4
- ベンダー保守の外に出る→ Lv5
ERPなら「標準のカスタマイズ機能の範囲内か／アドオン開発か／標準プログラムの改変か」がそのまま対応します。
この表を持つと、議論の性質が変わります。
Lv3以上が付いた要件だけを抜き出し、経営判断の対象にする。
Lv1〜2はプロジェクト内で処理してよい案件で、経営会議に上げる必要がありません。
多くのプロジェクトでは、この選別がされていないために、経営層の前に大量のカスタマイズ要求が未分類のまま並びます。1件ずつ説明され、判断できる粒度になっていないので判断されず、時間切れで「持ち帰り」になる。この光景を、私は繰り返し見ています。
Lv3以上を経営判断にかけるときは、必ず「標準機能で対応した場合に業務側が受け入れる運用負担」を併記します。
カスタムするかどうかは、開発コストの大小では決まりません。開発コストと運用負担の比較でしか決まらないからです。
この一行がないと、経営層は金額だけを見て却下し、現場は納得しないまま運用が破綻します。
Lv4・Lv5が出てきた場合は、見積を取る前にやることがあります。要件そのものを見直せないか、外部システムとの連携で代替できないかを先に検討する。
この2つはパッケージ保守の枠外に出る選択です。コストの問題ではなく、将来のアップグレードを放棄するかどうかという経営判断にあたります。
なお、情報システム部門が5〜15名規模の会社では、この選別を誰がやるかが問題になります。ベンダーに任せると、ベンダーにとって都合のよい線引きになる。
発注側の誰か1人が、Lv3の線を引く責任を持つ。この役割を明示的に置いているかどうかが、実務では分かれ目です。
2.残件数は健康状態を語らない。「決まっていない件数」を数える
課題管理表を月次で経営に報告するのは、たいていの基幹刷新プロジェクトで定番です。ただ、報告されるのは「総件数」と「残件数」です。
課題にはライフサイクルがあります。5段階に分解します。
①起票 → ②分析 → ③方針検討中 → ④決定済 → ⑤実行中 → クローズ
このうち①〜③が「方針未決」、④〜⑤が「決定後の実行」
残件をこの2つに割ります。ここまでは教科書的な話です。実務で効くのは、割り方を主観に委ねないことのほうです。
というのも、この判定は利害そのものだからです。ベンダー側は「決定済（④）」と主張し、発注側の現場は「まだ検討中（③）」と言う。
その対立こそが、プロジェクトが止まっている症状そのものです。ここを当事者の申告に任せると、計器の目盛りが政治になります。
そこで、判定基準を1つだけ機械的に決めます。
④「決定済」とは、決めた人の名前・決めた日・決定文書のリンクの3つが埋まっている状態を指す。1つでも欠けていれば、すべて③に倒す。
この定義なら、誰が数えても同じ数字になります。そして多くのプロジェクトでは、この基準を当てた瞬間に「決定済」が大きく減ります。
減った分が、決まったつもりで決まっていなかった案件です。設計フェーズで再燃するのは、ちょうどこの層です。
そのうえで比率を見ます。目安は5割。 方針未決が残件の半分を超えているプロジェクトは、実行力ではなく意思決定がボトルネックになっています。
ただし絶対値より変化のほうが信頼できます。要件確定の直前など、方針未決が一時的に跳ね上がる局面は正常です。
問題は戻るかどうかで、3ヶ月連続で方針未決の比率が上がっているなら、総残件数が減っていても止まっています。ここで冒頭の2説に戻ります。この内訳は、社内の見立てをそのまま切り分けます。
止まるプロジェクトの大半は1行目です。だから体制を厚くしても効きません。決まらない案件を並行して抱える会議が増えるだけで、方針未決はむしろ増えます。
「③方針検討中」に突出している場合は、意味が少し違います。議論の場はあり、参加者もいて、毎回議論している。それでも決まらない。
ここで必要なのは追加の会議ではなく、1枚の比較表です。選択肢を2〜3案に絞り、各案の費用・期間・業務側の運用負担・見送った場合のリスクを1枚に並べる。
判断材料が足りないから決まらないのであって、議論の量が足りないのではありません。
ベンダーのツール上の課題管理表を改造できなくても構いません。 自社側で月1回、残件一覧をエクスポートして2区分に振り直すだけで足ります。作業は30分程度で、専任は要りません。
3.エスカレーション基準を、時間から回数へ切り替える
会議体の設計には、たいていエスカレーション基準が書かれています。よく見るのは時間基準です。「2営業日以内に解決できない課題は上位会議へ上げる」。
この基準には穴があります。毎回少しずつ進んでいるように見える議論を、検知できないのです。
検討が堂々巡りになっているとき、会議は空転していません。毎回何かしらの論点が出て、宿題が設定されます。
参加者の実感としては「進んでいる」。だから時間基準に引っかからないまま、同じ論点が形を変えて、3ヶ月間往復します。
ここに足すべきは、時間ではなく回数の基準です。何日経ったかではなく、同じ論点が同じ会議に何回戻ってきたかを数える。
ただし「2回連続で停滞したら上げる」とだけ書くと、機能しません。「停滞」を誰が判定するのかが残るからです。議事録を書くのはたいていベンダー側で、「進捗あり」と書けば永遠に停滞しません。判定者が、上げられて困る当事者になっている。
そこで、ここも主観を排します。
同じ論点が同じ会議の議題に2回載ったら、進捗の有無にかかわらず自動で上げる。
議題名で数えるので、誰の裁量も入りません。運用としては、課題管理表に「審議回数」の列を1つ足すだけです。
会議で議題に上がるたびに+1する。月次で「審議回数2以上」をフィルタすれば、エスカレーション候補が機械的に出ます。
エスカレーション基準は、時間・回数・影響範囲の3種で数値化します。それぞれの上げ先の会議体まで書き切って、はじめて運用に耐えます。
数値のない基準は、実運用では必ず「なんとなく上げる／上げない」に退化します。
影響範囲についても一言。他部門への影響・スケジュールへの影響・データ連携への影響のどれかに該当する課題は、横断課題として扱います。
ただし中堅規模の案件では、この条件に当てはまる課題が大半になるはずです。全件を上位会議に上げると会議が破裂します。
そこで「横断課題に倒す」の意味を限定してください。上位会議へ上程するのではなく、横断タグを付けて関係部門の閲覧対象にするところまでに留めます。
上げるかどうかは、そのうえで審議回数で決めます。
なぜ「2年」なのか
3つとも要件定義フェーズの話です。プロジェクト全体から見れば序盤にあたります。
にもかかわらずここを取り上げるのは、基幹刷新の成否が実質的にこのフェーズで決まるからです。
要件定義で方針未決を積み残したまま設計に進むと、その未決は消えません。設計の途中で「そういえばこれは決まっていない」として再浮上します。
既に動き出した設計を止めるコストが乗るぶん、判断はさらに難しくなる。だから先送りされ、開発フェーズで手戻りとして三度目の請求書が来ます。
ここまで来ると経営の議題は「システムをどう作るか」ではなく「このプロジェクトを続けるかどうか」に変わります。
2〜3年計画の基幹刷新では、要件定義に半年、設計に半年、開発に1年を見るのが標準的な配分です。
未決が持ち越されるたびに1フェーズ分——半年から1年——判断が先送りされ、3回目にあたる開発フェーズで採算が合わなくなる。 計画開始から数えて、だいたい2年目です。
頓挫は事故ではなく、構造的な帰結です。だからこそ、要件定義フェーズの課題管理表の内訳が、最も早い警告になります。
社長がプロジェクト責任者に聞くべき4つの質問
自社のプロジェクトに当てはめてみてください。いずれも既存の資料で答えられる内容です。答えられない場合、その事実自体が診断結果になります。
- 経営判断にかけているカスタマイズ要求は、深さで選別されているか。 そして各件に「標準対応した場合の運用負担」が併記されているか
- 課題の残件は「方針未決」と「決定済・実行中」に分けて報告されているか。 そして「決定済」の判定は、決めた人・決めた日・決定文書が揃っていることを条件にしているか
- 方針未決の比率は、直近3ヶ月で上がっているか下がっているか
- エスカレーション基準に、時間だけでなく回数の基準があるか
4つとも「はい」なら、そのプロジェクトは少なくとも自分の状態を見る手段を持っています。
4つとも「いいえ」だった場合は、1から着手してください。
カスタマイズの選別は最も短期で効果が出るうえ、経営会議の時間が直接減り、残る3つの前提にもなります。
体制を厚くするのは、そのあとで構いません。順序が逆になっているプロジェクトを、私は繰り返し見ています。
■ 個別相談（30分課題診断）のご案内
30分で、次の3つをお持ち帰りいただけます。
- いま自社のプロジェクトのボトルネックが、意思決定にあるのか実行にあるのかの判定
- 方針未決のうち、先に潰すべき課題の絞り込み
- 上記4つの問いへの自社の答えを書き出した1枚
資料の準備は不要です。
お手元に課題管理表があれば画面共有で拝見しますが、なくても現状をうかがえば判定はできます。
刷新の検討がまだ構想段階でも構いません。
もっと詳細な情報が知りたいという方はこちらお問合せください。
