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

PMプロフェッショナルへの歩みー8

向後　忠明　[プロフィール]　：7月号
　これまでプラントビジネスを通して経験してきたプロジェクトの多くは業務範囲も広く、技術も多種・多様でした。しかし、先月号で説明したJICAの案件はこれまでとは業務の内容も範囲も異なり、また組織体制や環境もPMの在り方についても全く異なるものでした。

　ここで少し話は変わりますが「プロ」の意味について考えてみましょう。
　マッキンゼーコンサルタント会社の社長であった大前研一の著書における「ザ・プロフェッショナル」から一部引用するとプロフェショナルとは以下のように定義しています。

  1. ① 社内のみならず社外においても第一線で通用する専門知識や実務能力を備えている人
  2. ② 顧客満足を約束事として自ら宣言することのできる人

　しかし、筆者はこの意見に若干異論があります。①の定義は問題ないが、①は納得できません。自分が勝手に宣言しても結果がまずければプロフェッショナルとは言えません。よって、②は以下のように修正します。
　「具体的結果責任を示すような目に見える物的成果物を目的通り達成し、顧客満足を得ることのできる人」
　なお、この物的成果物の定義ですが、マスタープランや企画書も含みます。
　プロフェッショナルと言えば身近なところで医師、弁護士、公認会計士、建築士等々がいますが、必ずしもこの人達全部がプロフェッショナルとは言えません。
　この人達は国家試験に合格し、専門知識も実務能力もあると証明された各分野で活躍している社会的に優秀と言われ実務能力もあるその分野の専門職です。この人達は国家資格といったそれぞれの分野の印籠を持っていることで組織から離れて個人的に活動することも可能です。PMプロフェショナルとは異なり、彼らは個人または団体として顧客との契約または約束事で仕事をする人達であるが、実務においては結果責任を成果物として明確にする必要もなく、場合によっては顧客満足を与えることまでの義務を果たさないケースもあります。
　このことは契約的側面から見ても明確であり、契約には請負、委任そして準委任といった種類があります。

　上記の大前研一のプロフェショナルの顧客との約束は準委任にあたり業務委託契約の一種で、「特定の業務を行うことを定めた契約のことであり、その業務の遂行自体が目的となり、その結果や成果物の完成については責任を求めないようになっています」
　それに対して、PMプロフェショナルの場合は顧客との約束はほとんど請負や委託契約といった種類のもので与えられた目標通りの結果を達成し、物的成果物も示す責任持っています。
　すなわち、大前研一の言っているプロフェショナルはビジネスにおいての事業戦略や企画の検討などを主業務とするコンサル役務に相当するもので一般的に「与えられた依頼要件を基本構想からプロファイルによりそこにある問題を発見、そしてその解決策を整理し、企画書またはマスタープランに落としこむといった仕事」までが多いです。いわゆるコンサルタントという職種に近いものと思います。
　よって、前月号で説明のJICAの調査案件も準委任契約によるものでありコンサルタント役務に相当し、PMプロフェショナルに求められる範疇のものではありません。
　ここまで大前研一の言っているプロフェショナルとPMプロフェショナルの役割や役務範囲の違いについて話をしてきましたが、ここから前月号で約束のシステム開発案件について説明いたします。

　JICA案件が終了し、ほっとして、後半年で古巣の会社に戻れると思っていた矢先に、システム開発分野の仕事が舞い込んできました。このプロジェクトも全く経験をしたことがなく、筆者にとっては前回のJICA案件と同じような状況下での依頼でした。その内容は

　「ある国（T国）のトップとN社のトップでの会談で国の中央銀行の決済を各市中銀行双方とネットワークで結合したシステムの構築」

　といったシステム開発プロジェクトでした。

　N社にとっても海外のシステム開発は初めてであり、最初はN社の関係するシステム開発を専門とする子会社（ND社）等々にも声がけしたが、結局海外案件ということでNI社にこの話が来ました。筆者にとってはこの種の案件は初めてであり、この案件もJICA案件の場合と同じにC．H．ケプナ博士によって開発されたラショナル思考プロセス（EM：Effective Management法）の問題解決のための思考スキルの活用を再度利用し、本プロジェクト実行面での課題の抽出と解決策の評価を行いました。

　この過程でわかったことはシステム開発の問題点の多くは顧客の要件がプラントビジネスとは異なり顧客要件が明確でなく、その上開発途中での設計仕様に関する顧客要求変更が多くあり以下のような問題が多いとのことでした。すなわち、

　情報通信関係の情報誌などによるとその成功率は開発規模にもよるが過去数十年間のデータを見ても、完全に成功と評価されるプロジェクトの割合は、概ね15%から30%程度で推移していることが多いようです。一方で、失敗（中止されたり、導入されても利用されなかったりするプロジェクト）や、課題を抱えたプロジェクト（納期遅延、予算超過、機能不足など）の割合が依然として高いと報告されています。

　このプロジェクトの依頼が来たのは1987年頃であり、この頃は日本におけるシステム開発プロジェクトの開発は今ほど習熟していない頃であり、また、顧客が海外であり成功率に示す数値もさらに上記より低いことが予想されました。

　しかし、このような状況にもかかわらず断ることもできず、本システム開発プロジェクトに関与することになりました。そのためNI社においてこのプロジェクトへの関与の条件として、プロジェクトに必要な人材の選定に下記のような条件を付けました。すなわち、少なくとも技術面のリーダとして本プロジェクトと類似したシステム開発実績のあるSE（N社の子会社であるDE社からの派遣）と英語（会話及び英文資料作成）に習熟した人材の要求を求めました。

　その後求める人材の選出後、簡単な筆問事項をまとめ、筆者とNI社役員を含め4人でT国へ出張することになりました。

　この当時は羽田、アンカレッジの北極回り、そしてドイツ経由のアンカラといったかなり時間のかかる旅行となりました。そして飛行場から車で都心に向かいましたが途中の景色は黄色い台地が続きなんとなくうら淋しい感じのところでしたが、このような国にシステム開発？と思いながら中央銀行に着きました。中央銀行はかなり荘厳な建物でびっくりしましたが、中央銀行のスタッフに案内され、宮殿のような廊下を通って立派な会議室に通されました。すでに相手方のプロジェクトスタッフらしき人達が待っていて、早速話し合いに入りました。

　相手方の対応は真剣であり、途中で副総裁まで我々との会議に参加してきました。そして、中央銀行側のプロジェクトメンバーの紹介の後に顧客の求めるシステム概要の把握のため、中央銀行側とシステムの現状と顧客要求内容の確認などを行いました。この時の現地調査でも銀行側の協力姿勢はかなり真剣であり、我々に対する期待度の大きさを肌で感じました。このような状況の中、最後に副総裁より本プロジェクトをすぐにでも初めてほしいとの話がありました。すなわち、入札ではなく随契での発注であるとのことがわかり、顧客の我々に対する期待度の高さも明確となりました。早速日本に帰り調査結果を検討し、その前提で提案書を作成することを約束し、帰国しました。

　システム開発の案件は前記したようにその成功率は非常に低く、顧客要件が明確でないケースが多いため、一般的には随意・コストプラス契約ベースと考えます。システム開発の一般的なフレームワークは顧客と膝附合わせの打ち合わせによる相互理解によるシステムの方向性、システム化計画そして要件定義の固定までが第一歩と考えました。なぜなら、ここまでは十分な時間をとって途中で大きな誤りや変更がないかを確認しながら、随契でのコストプラス契約で進めなければこの種のプロジェクトはリスクが多いと分析の結果でも感じていました。現在ではこれをアジャイル方式と言っていますが、この当時はこのような考え方は皆無でした。そして、ND社の紹介で日本銀行や全銀協会の協力を得ることもできT国の求めるシステムの概要と契約方法を含めた仕事の進め方をまとめた提案書をもって再度NI社の責任役員と同伴でT国に出かけました。

　この後は来月号とします。
ページトップに戻る