皆さんの大規模プロジェクトは順調ですか？

　プロジェクトは生き物で、1つとして同じものはありません。ゆえに私たちは大きな失敗を起こさないようにプロジェクトマネジメントを勉強し実践経験を積みます。しかし、それでも失敗するのはなぜでしょうか。

　私は1989年松下電器産業（現パナソニック）に入社して以来約35年間、社内情報システム部門に所属し、数々の大規模なプロジェクトに参画してきました。プログラマー、システムエンジニア、プロジェクトリーダー、プロジェクトマネジャーと立場はその時々で変わりましたが、一貫してシステム開発・導入プロジェクトに携わってきました。楽だったと思えるプロジェクトは記憶になく、常に全力で突っ走っていたように思います。

　そんな経験から、プロジェクトの成否に直接影響することが2つあると考えます。1つはやはり「プロジェクトの成否は人次第」であることです。プロジェクトには計画を立てても達成できない、業務知識が乏しく要件定義に穴がある、テストの網羅性が不足、結果としてコストの抑えが効かない、など人に起因するリスクがたくさんあります。

　そのため、人数合わせのような体制だと、どんな高レベルのプロジェクトマネジメントも機能しません。社運をかけた全社プロジェクトともなれば、その会社で一番優秀な人をアサインしなければなりません。また、ご支援いただくITベンダーには該当案件に長けたエース級をお願いしたいところです。アサインする経営陣がそのことを認識していなければ、キックオフの時点ですでにマイナスからスタートしていることになります。

　もう1つが「組織風土」です。厳しさの中にもチームワークがあり、役割分担はするが壁は作らず、三遊間のゴロを積極的に拾いに行く、お互い声を掛け合い気遣う──といった風土はプロジェクトには必要なことです。うまくいっていないプロジェクトは、これらが欠落していることが多いのではないでしょうか。修羅場をくぐった経験豊富なメンバーであればこれらは自然にできます。

　そうは言っても、常にこれらが成立するとはかぎりません。たとえ脆弱な体制であってもプロジェクトを進行しなければならない状況は必ずあります。その場合、だれしも経験があると思いますが、コストと納期に融通性（バッファ）をもたせつつ、覚悟をして取り組むことなります。いったんプロジェクトが走り出すと、炎上でもしないかぎり、そう簡単にメンバーの交代・補強はできず後手に回るのが常ですので、プロジェクトマネジャーは先手先手でアラートを上げ、経営幹部はそれを直視しなければなりません。

私の失敗経験─どうにもならない初モノプロジェクト

　プロジェクト成否に占める「人」の割合が大ではあるものの、そう単純ではありません。要注意なのが“初モノ”のプロジェクトです。どういうことか、私自身の失敗例をいくつか紹介しましょう。

B2C ECシステムのスクラッチ開発プロジェクト（2008年前後）

　社内に経験者がおらず、要件定義から大手ITベンダーにも大きく依存しました。後から痛感することになるのですが、ECには社内業務システムにはない勘所が多く、特に商品をショッピングカートに入れてから決済までのプロセスは複雑です。品質担保に苦労し、本番稼働後もトラブルが多発しました。加えて本番前に「返品」の仕組みが要件定義から漏れていることが発覚したり、クレジットカードの与信ロジックに見落としがあったりと、本番前後は戦場と化しました。

　当時はまだECサイト構築用のパッケージが少なく、検討の結果、スクラッチ開発することになったのですが、知見のない初モノに取り組むことの難易度の高さは想像以上でした。今なら思いつく、ECサイトに精通した専門ITベンダーやエンジニアに参画してもらう手立てにも、考えが及びませんでした。当時は、次々に露呈する問題に1つ1つ取り組む以外にありませんでした。

海外B2B顧客向けホームページ構築プロジェクト（2013年前後）

　そもそも情報システム部門に社外向けWebサイト構築の経験がないのに、開発を担当してしまったプロジェクトです。ITベンダーの話を聞いたり書籍などで必死に勉強したりしましたが、CMS（Contents Management System）の選定を誤り、購入したパッケージを半年後に捨て、イチからやり直すという損失を出しました。目利きができなかった／ベンダーの謳い文句が本当にそうなのかを突き詰められなかった、という大きな反省と教訓となりました。

だれが取り組むかで結果はいくらでも変わる

　もちろん初モノでも成功したプロジェクトもあります。これについても紹介します。

AWSクラウドの活用（2017年前後）

　今なら想像できませんが、当時、クラウドは脆弱でリスクが大きいという風潮があり、大企業の情シスほど採用に二の足を踏んでいました。私は論理的に説明がつかないこの風潮を突破したいと考え、オンプレミスで稼働していた「一般消費者向け大規模会員サイト」のAWSクラウドへの移行を進言しました。

　情シスの上層部は「重要システムのクラウド化は時期尚早」といった感覚でしたので、簡単にはゴーサインが出ません。約2カ月にわたり毎週、幹部に説明して了承にこぎつけました。社内ではチャレンジングな取り組みと言われましたが、無事成功。後続のクラウドプロジェクトはやり易くなったと思います。

顧客接点強化のためのCDP構築プロジェクト（2018年前後）

　一般コンシューマーを対象としたCDP（Customer Data Platform）構築プロジェクトのケースです。私は途中参加でしたので、パッケージ選定は当初横目で見ていました。しかし手段先行の違和感があり、過去の反省（前述のCMS選定ミス）を踏まえて候補の各パッケージのベンダーを1人で訪問行脚し、パッケージ特性を深く調査しました。要件と照らし合わせた結果、選定とは別のSaaSパッケージを採用するべきと提案しました。

　そのパッケージはスタートアップで、付き合ったこともないベンダーのものだったため、情シス内では賛同されませんでしたが、ギリギリのところで食い下がり粘り勝ちしました。非常に優秀なベンダーSEの支援もあって、短期間でマーケティング部門が望む形をつくることができました。危うく説明力のなさを猛省し、ステークホルダーにご迷惑をかけるところでした。

人に恵まれるプロジェクトのほうが稀かもしれない

　会社の規模によって大きく異なるのは人財の豊富さです。情シスが100人いる企業と20人の企業では、プロジェクト運営に大きな差が生じます。加えて組織風土の差まであると相当苦労することになります。私は2020年秋、情シスだけで1000人いる企業から20人の企業に転職しました。その後、2022年前後に携わったのが、大規模な基幹システム全面刷新プロジェクトです。

　すでにプロジェクトが開始されていましたが、広範囲かつ45年ぶりの全面刷新で移行難易度も高く、またITベンダーとしっかり組む経験のないメンバーで構成するのだから相当難航すると思いました。それでも、この全社プロジェクトの失敗はあってはならないものです。私も途中参加ながら全力を尽くし最後まであがく覚悟で推進したものの、懸念は現実になり、当初計画から1年延期した2023年5月に本稼働することとなりました。

　私もメンバーも疲弊する中、経営陣が全面バックアップし続けてくれたことが大きな救いでしたし、また今回の参画でプロジェクトメンバーの成長は著しく、苦杯をなめることでさらに頼もしくなったのは大きな成果でした。30年以上この仕事をしてきていても、合格点をとれないことに歯ぎしりをしながら、次の事業場横展開に取り組んでいる最中です。

　冒頭でも述べましたが、システム開発・導入プロジェクトは、人と人との共同作業の集合体であり、メンバーである「人」が最も重要な要素です。ちょっとしたことに気づく人、アクションをとってくれる人がいるかどうかで、結果は大きく変わります。100点はとれなくともコンスタントに合格点をとれるよう組織風土の醸成も含め取り組んでまいりたいと思います。ここ数年、内製化に舵を切る企業が増えているのはアジリティの確保だけでなく、内製化による経験や知識習得が組織力・プロジェクト遂行力を向上させることに直結しているからだと思います。

　最後に教訓を4つ挙げておきます。

①体制図に名前が入ったら体制構築完了したと安心しないこと
②鳥瞰図やグランドデザインの書き物がないプロジェクトは危険
③成果を示す数値目標がないプロジェクトも危険
④QCDの納期を疎かにする人は信用できない