[架け橋 by CIO Lounge]

2024年2月28日(水)CIO Lounge

　プロジェクトは生き物で、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の支援もあって、短期間でマーケティング部門が望む形をつくることができました。危うく説明力のなさを猛省し、ステークホルダーにご迷惑をかけるところでした。

●Next：プロジェクトの成功と失敗から得られた4つの教訓