オンラインジャーナル/PMプロの知恵コーナー

先号　　　次号

海外でのITプロジェクト実践　(2)
「立ち上げ」

向後　忠明：5月号

　本プロジェクトはT国における銀行間資金の移動と決済及びそれに付随する各種情報処理をコンピュータ化し、オンラインにて電子的に処理することを目的として、T国中央銀行が企画したものでした。
　このプロジェクトの特徴を簡単に下記に示します。

① 海外現地企業又は組織へのソフト開発を含むシステムの日本からの輸出第一号である。

② 外国語(英語)による仕様への対応そしてフォルトトレラント(Fault Tolerant )コンピュータでのソフト開発の双方を満足する開発企業及び人材の確保がMustである。

③ 中央銀行と言う特殊業務を扱うことの出来る業務知識が必要である。

　すなわち、日本でも良く知られている「全国銀行データ通信システム」通称全銀システム)のT国版です。
　現在では多くの日本のIT関連企業が海外のベンダーを利用し、各種のプロジェクトを実行していますが、それでも純粋な海外顧客を対象としたシステム開発・構築を行なっているところは少ないようです。
　本プロジェクトは海外の顧客の業務システムの開発･構築であり、設備建設とは異なり、アルゴリズムを中心とした仕事が中心であり文書及びプログラム作成が主な成果物でありました。
　そのため、関係者間の意志の伝達、すなわち、言語の違いによるミスコミュニケーションの防止、異文化(今回のプロジェクトはイスラム圏)から来る誤解の発生の防止、現地の人達との調和、そして正確にT国中央銀行及び関係者の要求を引き出すための密なビジネス上のコミュニケーションが重要と考えました。
　現在においても、この種の国内のプロジェクトにおいても的確な顧客要求の理解、不十分な顧客要求そして思い違いからプロジェクトが失敗しているケースが多いと良く耳にします。
　システム開発・構築のプロジェクトにおける現在の日本の現状から察しても、私が引き受けたT国の本プロジェクトはどのような運命をたどるか、読者諸氏も容易にに想像できると思います。

　一方、私がプロジェクトマネジャとして任命された時でも本プロジェクトの大前提となる契約に関する書類作成、交渉、ましてや調印もしていない状態でした。のため、この作業も早急に進めなければならない状況になっていました。
　しかし、肝心要のプロジェクトマネジャが「全銀システムとは？？？」の状態でした。
　その上、、顧客であるT国の顧客も、「日本の全銀システムは為替業務を正確かつ迅速に処理することのできるシステム」と言う程度の理解であり、その内容も十分に分かっていない状態でした。ますます、この時点で本プロジェクトを安易に引き受けた事を悔やんでも悔やみきれない思いとなって、夜も寝られない状態が続きました。

　前月号で「度胸と挑戦」と言っていながら、「節操なく案件を引き受けると事故の基になる」と言いましたが、まさにこのことが現実となっていました。
　しかし、ここで引き下がる事はプロジェクトマネジメント能力の稚拙さを露呈することにもなるし、「度胸と挑戦」と言った手前もあり“やるしかない”と思い先に進むことにしました。

　何はともあれ最も優先度の高い事は本プロジェクトを担当するプロジェクトマネジャ及びプロジェクトスタッフ全員が、「全銀システムとは？」を理解する事でした。
　そこで、NI社の社長にこのシステムの開発実績を持つN社グループのND社から全銀システムの開発・構築に経験のある人材をチームに入れてもらうことをお願いしました。そして、技術面、特に全銀システムの業務内容とそのプロセスなどの指導をしてもらうことになりました。
　チーム全員がその人の下で全銀システムの内容、開発経緯、開発内容そして開発にあったてのノウハウを教授してもらい、また現場で稼動中のシステムの見学、そして運用に関するヒアリングを通してシステムの全容を理解していきました。
　この頃になるとなんとなくシステムの全容が分かってきて、「これなら何とかいけるかも知れない」と言った淡いがそれなりの自信も沸いてきました。

　次なる心配は契約です。
　本案件はトップ間での話し合いで決まったプロジェクトであるが、実際の業務を進める基準となる契約がすでに話したようにまだ何も進んでいない状況でした。そこで早速顧客提出用の契約書及び関連書類の作成に入ることになるのですが、ここで一番困ったことはこのプロジェクトに要するコスト及びプロジェクトの期間でした。
　システムの概要が理解できたとは言え、実際に全銀システムを開発・構築したこともなく、ましてや日本の全銀システムとも規模も内容も異なることから、日本のケースを参考することもできませんでした。
　そこで考えたのが仕様の凍結が見られるまで単金ベースの実費精算とするコストプラス方式の契約でした。
　この契約形態は顧客要件が明確でなく、そのためプロジェクト全体コストの積算も難しい案件に適用されます。
本プロジェクトで取った方法は以下の通りでした。

①基本要件の確認及び基本設計の完了までコストプラス契約

②各レベルの担当者の職種と単金設定

③基本設計完了前までにプロジェクトコスト及び全体スケジュールを提出し双方確認の後に一括契約

　日本の契約は殆どの場合、一括契約であり、それも顧客要求条件が曖昧でその上、激しい受注競争がなされているのが現状です。
　この辺の事は読者諸氏も良くご存知なので説明は割愛します。
　いずれにしても、プロジェクトマネジャになる人は案件の要求事項やプロジェクトのおかれている環境条件を良く見てそれに見合った契約形態をオファーできる知識を持っている必要がある。
　もちろん、契約形態は顧客側が決めることが多いですが、案件によっては請負企業側からプロポーズしていくことができるような環境作りをしていくことが肝要かと思います。
　このように、現在ではIT関連プロジェクトにおいても契約の重要さは以前と比較しプロジェクトマネジャの必須知識として求められるようになってきているようです。

　いろいろな問題がありましたが、なんとか契約を調印し、仕事のスタートを切ることができましたが、この契約において顧客側が特に要求してきたことは「コミュニケーション」でした。
　そのため、プロジェクトの節目節目において両チームが重要な期間はそれぞれの国に一同に介して業面対にて務を行うことの義務付けがなされました。
　コミュニケーションは海外のプロジェクトに関わらず、ITシステム開発・構築には非常に重要な要素となっています。ましてや言語、習慣、考え方などの異なる国の顧客とプロジェクトを進めるとなると日本のそれとは比べられないほど大変なことになります。

　来月号では「コミュニケーションと海外プロジェクト遂行の心得」などについて話をしてみたいと思います。