PMプロの知恵コーナー
先号   次号

ゼネラルなプロ (42)

向後 忠明 [プロフィール] :4月号

 今月号は失敗したプロジェクトを実例に基づき話をし、そして、このプロジェクトを失敗せずに終わらせるには「ゼネラルなプロ」だったらどのような工夫をして成功につなげたかを来月号で話をしてみたいと思います。
 この物語は、今回対象とする失敗プロジェクトの直前に成功裡に終了したTU国の中央銀行のプロジェクトとその規模及び内容も同じようなプロジェクトであり、顧客はTH国の中央銀行であり、その銀行の電子決済に関するシステムの開発でした。
 TU国でのプロジェクトをリードしてきたPMはTU国の総裁そして自社グループのトップからも称賛の言葉をもらい、長いTU国駐在からも帰国し、日本で休息の日々を過ごしていました。
 ある日、営業からの連絡で「TH国の中央銀行よりTU国中央銀行のシステムがうまく稼働しているとの話を聞いて、ぜひTH国の中央銀行のシステムの開発をやってもらいたい」との話が来ているとのことでした。
 内容を聞いてみると、TH国の中央銀行のシステムは中央銀行とその支店及び各銀行間の大口送金とその決済システムと電子手形処理システムの2つのシステム構成とのことでした。
 それに比べ、TU国において実施したシステムは中央銀行本店と支店そして各市中銀行間の大口/小口の資金決済及び送金とその決済システムであり、手形電子処理システムは含んでいませんでした。なお、ハードウエアーの調達についてはどちらも中央銀行の所掌となっていました。
 我々はTU国での中央銀行及びその視点間の大口送金や決済についてはすでに開発した実績を持つので内容的にはTH国のシステムとは大差は無いと思いました。

 しかし、電子手形処理システムについては初めてでした。
 そのため、まずはこのシステムの内容について理解する必要がありと判断し、日本の全銀協やメーカに接触しその処理プロセスやシステムの構成について教えてもらいました。
 そのシステムは手形を各銀行からのMTによるデータをセンターで機械処理し、その結果を電子決済システムに投入するものであるとの話でした。
 このことからTU国で経験したシステムとあまり変わりはなく、そして小切手システムは機械的処理と判断し、詳細はメーカとの協調でやれば問題ないと判断し、提案書を提出しました。
 しかし、提案時に気になったのは、TU国で開発したOSとアプリの間を取り持つSMSと言うシステムをそのまま使用できるかどうかという事です。
 本件については、TU国のプロジェクトを担当したチームメンバーとの検討会ではTU国のものとそれほど大きな違いはないと判断されました。
 提案書は顧客の要求から一括請負で提出し、提案コストについてはSMSのことが心配だったので条件を付けて出しました。
 その理由は、本プロジェクトは当初顧客から随意契約との話であった。また、詳細な要件が決まってない状況での開発にはリスクもあるのでTU国と同じように基本設計は実費精算方式と考えていました。
 ところが急に顧客はシンガポールの会社がパッケージで提案してきているので競争入札・一括方式で本プロジェクトは実施するとのことを言ってきました。
 そのため、なるべく低コストでの提案する必要があるという事でTU国で最も時間を要したSMSを使用し一括方式で提案することになりました。
 しかし、この時のPMは“この種のシステムは先進諸国が独自でそれぞれの国で開発しているので、パッケージ化されたものはないはずだが?”との疑問は持っていましたが、受注優先という事で上記に示したような一括請負契約という事になりました。
 その結果、それから何日かして我々の提案が一番良い内容という事で提案書の内容についての説明を求めてきました。

 いよいよ、顧客との交渉という事でプロジェクトの中心メンバーをそろえてTH国に出かけていきました。
 しかし、その着いた日にTH国はデモの真最中であり、大きな暴動に発展しつつある状況であり、これまでのタイ訪問では経験のない状態が発生し、夕刻になってホテル近くの不夜街の明かりや名物の屋台が一斉に消えてなくなるような状態となりました。
 明後日には顧客との会議が入っていましたが、次の日はホテルに静かにしていて、顧客との会議の前打ち合わせをしながらこの暴動が治まるのを待ちました。

 その夜になって、軍のトップと政府側のトップらしい人がTH国の王様の前で王様からの苦言?を聞いているように見えるテレビ放送がありました。
 この後、暴動は治まったようですが、まだ一部では政府庁舎の方ではデモが行われているとのことでした。
 明日は“いよいよ顧客との会議”と準備ができていたが、この中央銀行も政府庁舎の側であったので、翌日のことを心配しながら、朝になり何はともあれ出かけることにしました。
 タクシーを拾って、「中央銀行へ」とお願いしたら、タクシーの運転手は料金上乗せを危険手当として要求してきました。
 これを聞きなんとなく不安になりましたが何はともあれ中央銀行に向かいました。
 道の途中には、暴動の後の残骸や焼けた車等がまだそのままになっていて、中央銀行が近づくにつれデモ隊の騒ぐ声が聞こえてきました。
 それでも何とか中央銀行に到着し、会議室に入り会議を開始することができました。
 初日の会議は提案書の技術的説明であり、契約内容についての確認などを行い、この日に出された質問については検討後、翌日という事で無事終わりました。
 次の日、デモは相変わらず中央銀行の側でやっていました。
 会議は引き続き行われ、最後のプロジェクトコストの交渉に入りました。
 この頃には問題のSMSがの提案と顧客要望との間に大きな食い違いが発生して来ていることが明確になり、提案書に示した条件も含め、その打ち合わせに入ることになりました。  関連の話し合いが始まってから少したってから会議場所の近傍で大きな爆発音と煙が立ち上がり、それが数度も発生し、会議どころでなくなってしまいました。
 顧客も我々も浮き足立ち、その交渉も中途半端になり、なんとなく若干のコスト追加を認めてもらい、PMとしてもこの状況でのこれ以上の交渉は無理と思い交渉を打ち切りました。
 交渉団は日本にそのまま帰りました。この時、PMは変更交渉を中途半端でTH国での交渉を途中で打ち切って帰国したことに公開していましたが、だれにも言えずにその結果を待っていました。
 そして、数日たたってから、TH国中央銀行から正式に契約したいとの連絡が入り、再度TH国に行き、契約調印を行い、そのまま基本設計に入りました。

 このころから、これまで一度も顔を出さなかった顧客側の業務運用チームが会議に出てきました。そして、彼らから多くの難題が課せられました。
 例えば、
本システムは世界一のものにするため、アメリカFRBやイギリス中央銀行のシステムの調査をやってください
小切手システムの20年先を見据えたシステムの将来像も描いてください
本システムの最適性を検証してください
等々の要求が出てきました。

 我々としては寝耳に水であり、これまで提案してきたシステムの見直しなどにも影響し、懸案のSMSの問題も中途半端なものとなっていることからコスト負担も大きくなることから即座に断りました。
 しかし、顧客もかなり強くこれらの検討を要求してきたので、顧客との関係も大事と思い以下のように③を除いて、いくつかの件は妥協してもらいました。

は全く知己もなく難しいので、現在実際に稼働している日本銀行のシステムと照らし合わせるため、基本設計終了後にその内容について日本銀行からの意見を聞きます。そして、最大限に基本仕様に反映するとのことの約束をして納得してもらいました
については誰もが将来像はわからないし、現状のコストにも影響しないので、想像たくましくその将来像を何とか作成し、まとめました。中央銀行側も本システム完了後、TH国の金融業界の動向を見て決めていきたいと考えているとのことで本件は終息しました。
についてのシステムの最適性とは何を意味するのか日本のシステムを開発した兄弟会社の助力を得て、いろいろなシステム構成と使用メーンフレームの型式について説明しました。しかし、納得してもらえませんでした。

 このことがネックとなり、思い悩み基本設計も時間ばかりが過ぎ、顧客との関係もぎくしゃくしだしました。
 約1か月遅延となり中央銀行側も業を煮やし「我々の求めていることは本システム導入に当たっての経済的最適性とそのメリットデメリットを示してもらう事です」とのことでした。
 「しかし、これは顧客側が当然このシステムを導入するためにやらねばならぬことではないのですか?」と反論しましたが受け入れられず、ここで業務はストップという事になってしまい時間ばかりがたってしまいました。
 なぜなら、我々は最適経済性検討などは本システム導入前に顧客が当然やっておくべきものとの考えを持っていたので全く眼中いない検討項目でした。
 また、もしこれを受け入れていたら、時間やプロジェクトコストも大幅に増加するので簡単には受け入れられる状態ではありませんでした。
 しかし、最終的には顧客も本システム導入を決めた手前もあり、顧客内部での検討で「本システムの完成が最も優先すべきであるので、基本設計はそのまま続け、経済最適検討は基本設計終了後、システムの全体コストと運用コストが明らかになったところで顧客自身が行うことで決着がつきました。
 我々としては基本設計やその結果のハードウエアー仕様も決まらないのに正確な経済最適計算などできるはずがないと思っていました。しかし、我々にも最適性の意味を確認せずに意味を取り違えて技術的側面での最適性のみを追いかけていたことを大いに反省しなければいけないと思いました。

 このようにいろいろ曲折があったが、その後は問題なく詳細設計、プログラミング、各種検査、運用試験と進み、終結を迎えることになりました。
 しかし、プロジェクトスケジュールは大幅に遅れ、そしてプロジェクトコストもかなり予算よりオーバーとなり、プロジェクトとしては失敗でした。

 このプロジェクトはPMのTU国での成功実績での自信過剰等がプロジェクトの進め方や顧客との対応などに影響しているような感じです。
 さて、このような失敗事例を読者諸君だったらどうしたら問題なく進めることができたかを考えてみてください。

 来月号では、「ゼネラルなプロ」だったら“このようにしただろう”そしてこのためには“このようなPMコンピテンシーを発揮しただろう”という事を書いてみたいと思います。

ページトップに戻る