基幹システムプロジェクトの成功要因を「3つ」に絞ってみた（前編：トップダウン編）

その素朴な質問に、私は即答できなかった

「基幹システムプロジェクトの成功のためには、何が必要ですか？」

ある現場で、情シスメンバーから聞かれました。

私は、答えに詰まってしまいます。

とても素朴な質問です。だからこそ、難しい。説明したいことが次々と湧き上がり、喉元で大渋滞を起こしてしまったからです。

これまで、さまざまなプロジェクトを経験してきました。業界、会社規模、現行システムの状況、組織の成熟度。背景が変われば、プロジェクトの目的も変わります。目的が変われば、当然、成功要因も変わってきます。

ポイントを挙げれば、それこそ無数にあります。

しかし、全部を列挙してしまうと、どれが本当に大事なのか分からなくなります。網羅しようとすればするほど制約が増え、プロジェクトは窮屈になっていきます。個別性の高い要因を並べたところで、他社の参考にはなりません。

そこで、絶対に外せないポイントを、あえて「3つ」に絞って整理してみました。

① トップダウン
② ベンダー選定
③ 情シスPMO

100を超えるプロジェクトの実体験（失敗も挫折も数え切れません⋯）を踏まえて、今だからこそ辿り着いた結論です。

まずは、1つ目の「トップダウン」から考察していきたいと思います。

トップダウンは当たり前？

「何だ、トップダウンか」と思われたかもしれません。

プロジェクトはトップダウンが重要。

これは誰でも知っています。否定する人など、まずいません。実際にプロジェクト体制図を見れば、たいてい最上位に経営トップの名前が書かれています。

つまり、ほとんどのプロジェクトは、建て付け上は「トップダウン」なのです。

しかし、あえて問いかけます。

本当にトップダウンで実行できているプロジェクトは、どれだけあるのでしょうか？

問題は、委任した「後」の距離感

経営トップは「プロジェクト責任者」として、経営判断に関わる重要な報告だけを受ける立場です。

日々の運営や推進は、プロジェクトマネージャーが仕切ります。現場の細かい論点は、プロジェクトメンバーが詰めていきます。

そのため、トップからは「細かい話は任せた」「後はよろしく」と委任されます。

これ自体は、何ら問題ありません。むしろ健全な役割分担です。

問題は、その後です。

プロジェクトと経営トップの「距離感」が、静かに広がっていくのです。

なぜ現場は「大丈夫です」と答えてしまうのか

典型的なのは、トップに「遠慮しすぎる」ことです。

何か問題が発生しても、まずは自分たちで解決しようという意識が働きます。

気軽に相談するべきではない。今はまだ小さな問題だから、自分たちで何とかする。瑣末な話でわざわざお時間をいただくのは忍びない。頼りないと思われたくない・・・等々。

ここだけを切り取れば、どれも正しい姿勢です。

そのため、経営トップが気になって「状況はどうだ？」と聞いても、現場は反射的に「大丈夫です」と答えてしまいます。

あるいは、メンバーがトップに相談しようとしても、その上司である「中間管理職」が止めてしまうケースも少なくありません。

しかも厄介なことに、こうした上司はわりと高確率で登場します。

保身にまみれた上司がひとりいるだけで、プロジェクトは一気に破滅へと引きずられていきます。

さまざまな配慮と忖度が交錯し、トップへの相談は封印されていきます。

その結果、問題はどんどん膨らんでいきます。気づいたときには、大幅な遅延、巨額の追加費用、ベンダーとの信頼関係の崩壊。深刻な状況に陥っています。

そして臨界点に達し、ようやく相談しようとしたときには、トップの予定はびっしり埋まっています。連日の出張で、会うことすらできません。

トップは情報が入らないのですから、介入のしようがありません。

知らない間に、状況だけが悪化していきます。事件化してから報告しても、もう後の祭りです。

外様のトップが招く、もうひとつの結末

経営トップの資質や背景によって、自動的に疎遠になる場合もあります。

特に注意が必要なのが、親会社や関係組織から転籍してきた、いわゆる「外様」のトップです。

現場を知らないため、現場の会話についていけません。課題の中身も理解できません。

その結果、プロジェクトに介入したがらなくなります。

そして、こんな指示が出ます。

「現場の意見をきちんと聞いて、しっかりと合意形成をとるように」

もっともらしい指示です。トップからの指示は、たしかに出ています。

しかし、その中身は「ボトムアップでやれ」という矛盾。

トップは一切介入せず、現場がそれぞれの立場で考え、動くことを要求されます。

ここには、別の深刻な問題が発生します。

ほぼ確実に「現行踏襲」になるのです。

なぜなら、現場は業務プロセスを大きく変える「権限」を持っていないからです。現場に決めさせるということは、実質的に「今の業務フローのままで行け」と指示しているのと変わりません。

その結果、せっかくの一大プロジェクトでありながら、大きな改革は行われず、小さな改善だけに留まります。

現行を変えないのですから、業務に関しては大きな問題は起きません。表面上は、平穏に進みます。

しかし、大金を投じたのに、何の変革も残らない。

もっと合理的で、圧倒的な成果を出せるチャンスがあったとしても、検討の俎上にすら上がらず、闇に葬られていきます。

トップが「自然と介入する」仕組みをつくる

では、真のトップダウンプロジェクトにするには、どうすればよいのでしょうか？

トップの介入が適切に行われるには、「適切な報告」を、「適切な距離感」で届ける必要があります。

配慮しすぎる組織風土や、トップの資質に左右されない「仕組み」をつくること。それも、最初に手を打っておくことです。

その仕組みが、これです。
 

「ステアリングコミッティ」（以降、ステコミと略します）

 

経営トップおよび経営幹部に出席していただき、プロジェクトマネージャーから状況を報告する場を、定期的に持つこと。

重要なのは、このステコミにおける報告の「質」です。

経営判断と介入を行うために必要な情報を、こちらから提供しなければなりません。

そのため、ステコミのアジェンダは、経営トップが聞くべき情報で構成する必要があります。

・プロジェクトサマリ
・進捗状況
・課題・リスク
・相談・承認事項
・今後の予定

トップが介入するための情報を、常に提供し続けることです。

もしトップが外様であるならば、そのトップが理解できる表現で報告することです。専門用語に逃げてはいけません。

ある意味、トップを強制的に巻き込む仕組みともいえます。

この報告内容の質によって、経営判断の質が決まるのです。

起点は、報告する側にあります。

トップが介入してくれないと嘆くのではなく、トップが自然と介入する仕組みがあること。

それが、トップダウンプロジェクトの前提です。

トップダウンとは、責任を引き取ってもらうこと

誤解のないよう、補足しておきます。

詳しく報告すればよい、というものではありません。トップが細部まで介入するべきでもありません。

トップが要件定義にまで口を出すのか。それは、明確に違います。

「マイクロマネジメント」は、お互いに負担が大きく、双方が不幸になります。そもそも、トップにそんな時間はありません。

トップが決めることと、現場に任せることは、明確に分かれます。

また「トップがシステムに詳しくないとトップダウンできない」というものでもありません。

そして、現場が無能だから決められないわけでもありません。

営業部門は、営業部門として合理的に考えます。
経理部門は、経理部門として合理的に考えます。
物流部門は、物流部門として合理的に考えます。

それぞれ、正しいのです。

だからこそ、合意形成だけで決めようとすると「現行踏襲」に帰結します。

トップダウンが必要なのは、現場では引き受けられない意思決定があるからです。

部門をまたぐ全体最適を選べば、必ずどこかの部門に痛みが生じます。誰かの便利を捨てなければ、全社としての合理化ができないこともあります。

その痛みを、現場同士の話し合いだけで決めさせるのは酷です。

だから、最後は経営が決める。

トップダウンとは、現場では背負えない責任を、トップに引き取ってもらうことでもあるのです。

そのために必要な情報だけを選び、報告する。それがステコミの役割です。

報告資料が「無難」に書き換えられる瞬間

ここでありがちなのが、ステコミ報告資料を作った後です。

上司である中間管理職のレビューで、問題を伏せるよう圧力がかかることがあります（わりと高確率で）。

この圧力に、屈してはいけません。

そこで折れてしまえば、ステコミは形骸化し、開催の意義そのものが失われます。

とはいえ、会社員は組織で仕事をしています。上司の指示に逆らうのは、簡単ではありません。上司の頭ごなしに、経営トップへ直訴するわけにもいきません（状況が深刻であれば、それも選択肢にはなりますが）。

でも、ここは戦ってほしいのです。

ここが、プロジェクトの分水嶺だからです。

言われたとおりに無難な報告へ修正して、その後プロジェクトが炎上したとしても、その上司は責任を取らないでしょう。

それどころか、手のひらを返して「もっと早く報告すべきだった」と言い放つはずです。

私は、実際に言われたことがあります。

だからこそ、ここでは最大の労力を割いて、上司に報告内容を認めてもらうよう調整してください。

私は何度も戦いました。その結果、場は大きく動きました。崖から転落せずに、踏みとどまることができました。

あなたにも、戦ってほしいのです。

ただし、フォローしておくと、このような中間管理職が生まれるのは、経営トップにも責任があります。

過去に失敗を責められたり、犯人探しをされたり、怒鳴られたり。そんな経緯があったのかもしれません。

現在の組織の雰囲気や文化をつくっているのは、経営トップです。

「悪い情報ほど早く上げるように」というルールを、トップ自身が示してこなかったからこそ、今があるのかもしれません。

それでも、報告が遅れれば、余計に責められ、怒鳴られるだけでしょう。

だからこそ、プロジェクト体制を組んでいるのです。

その文化を超え、組織の壁を越えていくところに、プロジェクトの醍醐味があります。

ぜひメンバーで協力し、困難を乗り越えて、ヒーローになっていただきたいと思います。

プロジェクトが苦しい時の悪魔のささやき

ステコミは、定例化することが非常に重要です。

基本は「月次開催」です。

よく「フェーズの節目で開催すればよい」という話が出てきます。数ヶ月に1度、というやり方です。

しかし、それでは不定期になってしまいます。フェーズが遅れれば、ステコミも後ろにずれていきます。

それではダメなのです。

毎月開催するからこそ、経営トップが状況を定期的に把握できます。

ここで最も大事なのが「ステコミをスキップしない」ことです。

プロジェクトの状況が良くなかったり、作業が立て込んだりすると、必ずこの話が出てきます。

「今月はスキップしましょう」

悪魔のささやきです。

遅れを報告したくない。ひどい状況を詰められたくない。怒られたくない。失望されたくない。

しかし、プロジェクトは、状況が良くないときこそ報告すべきなのです。

順調なときの報告は軽くて構いません。悪いときこそ、丁寧に、詳細に情報を入れるべきです。

毎月開催するから、悪い状況であっても、強制的に報告の場が訪れます。

そのステコミに向けて、良い報告ができるよう、関係者はみんな踏ん張り、進捗を出していきます。

ステコミが、締め切りとなり、ペースメーカーとなるのです。

この緊張感を持続させる仕組みこそが、ステコミの存在意義です。

だから、何があっても毎月開催してください。繁忙期だろうが、お盆や年末年始の大型連休があろうが、関係ありません。スキップ癖がつく方が、はるかに問題です。

そのためには、向こう半年ほどのステコミ日程を、先に押さえてしまいましょう。

経営トップの会議予定は、ぎっしり詰まっています。だからこそ、先に枠を確保するのです。

直前に設定しようとするから、予定が埋まっていて、延期に次ぐ延期となり、ずるずる先送りになってしまいます。

プロジェクトの覚悟を示すためにも、ステコミ日程は最初に固定し、逃げないことが重要です。

さらにいえば、月次ステコミとは別に「緊急エスカレーション」もありうることを、最初に宣言しておきたいところです。

プロジェクトには、常に重大な問題が発生する可能性があります。

・稼働時期に重大な影響が出る
・予算超過が許容範囲を超える
・ベンダーとの契約問題に発展した

このような状況に陥った場合は、次回のステコミを待たずに「臨時ステコミ」を開催できる。そう定義しておくとよいでしょう。

社外ステコミという、大きな次元のリスク対策

なお、ステコミには「社内ステコミ」と、ベンダーを交えた「社外ステコミ」があります。

企画、プロジェクト計画、ベンダー選定といった最上流では、まだベンダーがいません。当然、社内ステコミのみとなります。

ベンダーが決まった後、要件定義以降は、社内ステコミと社外ステコミを使い分けていくことになります。

社外ステコミのメリットは何でしょうか？

自社の経営トップや経営幹部が出席すれば、ベンダー側も相応の幹部が出席せざるをえなくなります。

その結果、ベンダー報告の質が勝手に高まり、課題対応のスピードも上がります。

ベンダー幹部が関与することで、ベンダー側に自浄作用が働くからです。

極論すれば、経営トップは出席するだけで、ベンダーの緊張感は高まり、対応品質は格段に上がるのです。

停滞していた課題があっても、お互いの経営幹部の介入で、スピード決着します。

ベンダーとは、週次定例会や分科会なども多く実施しているはずです。ですが、社外ステコミは、それとはまったく次元の異なるリスク対策といえます。

トップダウンを「環境変数」にしてはいけない

基幹システムは、企業の「心臓」です。

今後のDX戦略の基盤であり、前提でもあります。

心臓なのですから、経営トップが関わるのは当然です。

基幹システム刷新とは、ITプロジェクトの顔をした経営改革だからです。

だからこそ、トップダウンになるかどうかを「環境変数」にしてはいけません。

保身まみれの上司がいようが、現場から距離を置きたい外様のトップであろうが、関係ありません。

プロジェクト計画書にステコミを定義し、最初に仕組み化してしまうこと。

これによって、プロジェクトと経営トップの「ホットライン」が保全されます。

これは、本当に大事なことです。

トップダウンを仕組み化する

プロジェクトメンバーの権限など、たかが知れています。経営トップでなければ判断できないことが、無数にあるからです。

・大幅な追加費用の承認
・こじれたベンダーとのトップ交渉
・部門間が対立した際の介入
・組織再編が不可欠な業務フロー変革
・無駄な業務の切り捨て
・全社を俯瞰した経営判断
・傷口が広がる前のストップ判断

これらの経営判断がなければ、目を覆いたくなるような大惨事となってしまいます。経営との距離が遠すぎれば、現場の優先度も下がり、全社プロジェクトは単なる「ミニプロジェクト」へ格下げとなります。

大きな変革と成果を出すためにも、トップダウンは絶対に外せない要素なのです。

つまり、プロジェクト成功の1つ目の条件は「トップダウン」です。

そのためには、ステコミを適切にデザインすること。プロジェクト計画書にステコミの開催要領を事前に明記し、関係者と合意しておくことです。

1つ目だけで、ずいぶん長くなってしまいましたので、今回はここまでとします。来週は、2つ目以降を整理していきます。

貴社の基幹システム刷新は、トップダウンプロジェクトでしょうか？