【前編】ベンダーを萎縮させたら成功は遠のく、悪い情報を引き出すのはCIOの役目

ベンダーに「問題ない」と言われるプロジェクトほど怖いものはない---。民営・分社化対応プロジェクトを率いた日本郵政公社の間瀬朝久理事常務執行役員は、こう言い切る。約40年のIT部門での経験から、「プロジェクトにおける問題の多くは、意思疎通に原因がある」と分析。「ベンダーが萎縮せず意見を言えるようにするのはCIOの役目だ」と話す

郵政民営化のシステム対応は、開発が間に合うかが国会で議論されるなど、社会の注目を集めました。システム責任者として、どう感じましたか。

 適切な表現ではないかもしれませんが、民営・分社化はIT部門に日を当てたところがあります。それまではIT部門なんて内部で全く目立ちませんでした。突然、表舞台に立たされたわけですから、正直戸惑いました。

 正常に動いている限り、経営者や業務部門がシステムの存在を意識することはありません。注目が集まるのはトラブルが起きたときです。何かあった際に、何でこんなことができてないんだ、考えも及ばなかったのか、と言われるわけです。

 システム開発の目的やリスクを社内外に伝えていくのは、IT部門あるいはCIOにとって、とても大切なことだと思います。システムは、開発が終われば完成ということではありません。不具合などのリスクが潜んでいる可能性はあるし、事務リスクもある。

 2007年10月に向けた暫定対応プロジェクトでは、社内外にこのような状況を説明することの重要性を改めて実感しました。あまり上手にできたとは思っていませんが…。

全社にまたがるPMOを初めて設置

郵政公社には約100のシステムがあり、暫定対応では63システムを改修したそうですね。プロジェクト全体の整合性はどう確保しましたか。

 これだけのプロジェクトを並行で進めるのは初めてでした。それまでは、大規模なプロジェクトが重ならないようにしていたのです。

 そもそも、郵政公社のIT部門は、貯金、保険、郵便などの事業単位で縦割りになっていました。社内に横串を刺してシステム開発プロジェクトを一元管理する組織はなかったのです。

 そこで、暫定対応プロジェクトでは、「CPMO(本誌注:民営化プロジェクト推進室)」を設けました。毎週金曜日に関係者50人程度を集めて、進捗や課題について情報共有する手法です。CPMOには、IT部門だけでなく業務部門も参加しています。プロジェクトを走らせながら、業務とシステム双方の問題を洗い出し、解決策を考えました。

 CPMOのなかで、貯金、保険、郵便、局会社、共通と5つの大きなチームを作り、それぞれのチームが配下のシステムに責任を持ってもらうことにしました。全体の状況はCPMOで集約します。開発に参加しているITベンダーやコンサルタントなどもCPMOに入ってもらいました。

 このような全社にまたがるプロジェクト管理組織を作ったのも、過去には例がありません。

CPMOでは、どのように進捗を管理しましたか。

 毎週の会議に加えて、各システムとも3カ月単位で「カットオーバー・クライテリア(本番移行の判定基準)」を設けました。切り替え準備ができているかどうかを「見える化」するのが狙いです。

 最大のヤマ場は2007年1月末でした。この段階で、開発途中のシステムも含め、10月までに完成できるかどうかを判断しなければならなかった。10月に間に合わない場合は、3月1日までに民営・分社化の延期を申請することが、郵政民営化法の附則第三条で決まっていたのです。

写真●間瀬 朝久(ませ・ともひさ)氏
撮影:中島 正之

個別のプロジェクトを振り返って成否の分かれ目はどこにありましたか。

 全体的な傾向として、貯金の勘定系システムのように歴史のあるシステムはうまくいきました。開発体制やプロジェク トの推進ルールが固まっていましたから。

 一方で、新しいシステムほど遅延しました。人事、財務、あるいは再構築に臨んだ郵便システムなどです。システム化の歴史が浅いので、プロジェクト管理ルールから作らなければならなかった。

人事や保険など、貯金システム出身の間瀬さんにとって未経験のプロジェクトを管理する際に、特に留意したことは何ですか。

 IT部員とベンダーの会議にできる限り参加しました。開発現場に入るのが私のやり方でしたので、初めてのプロジェクトでも、そのスタイルを貫きました。私自身が現場育ちですから、現場に入らないと進捗状況などをつかみにくいのです。

 悪いことが起きると、問題の核心に関する情報は上がってこない。最前線にいなければ、プロジェクトが火を噴くまで気付かないものです。特にメンバーの顔色を見れば問題があるかどうか、すぐ分かります。

 ベンダーやパッケージ製品、開発手法は違っても、システム開発でやるべきことは一緒です。システムを企画して開発して、運用まで持っていくということです。この基本を忠実に守りました。

部下とベンダー双方の言い分を聞く

とはいえ、これだけ大規模なプロジェクトだと、局所的に火を噴いたところがありまんでしたか。

 もちろんありました。そういう場合は、そのプロジェクトのメンバーに何が問題なのかを直接聞きます。原因の多くは、IT部員とITベンダー双方の意思疎通にある。私は両者の間に入って、双方の言い分をしっかり聞くように心がけました。

 特にITベンダーが萎縮しないように配慮しました。課題はITベンダーから上がってくるものなのです。ですが、問題が起きてITベンダーが萎縮すると重要な意見が上がってこなくなります。ITベンダーに「何も問題ありません」と言われるプロジェクトほど、怖いものはありません。

>>後編 

日本郵政公社 理事常務執行役員
間瀬 朝久(ませ・ともひさ)氏
岐阜県立益田高校卒業後、1965年郵政省入省。木曽福島郵便局長を経て貯金局電子計算計画課に異動。以後、約40年にわたり、システム関連の業務に従事する。主任システム計画官などを経て2003年4月、日本郵政公社郵便貯金事業本部システム企画部長。2004年7月、執行役員金融総本部情報システム本部長。2005年4月から現職。1946年4月生まれの61歳

(聞き手は,桔梗原 富夫=日経コンピュータ編集長,取材日:2007年8月22日)

出典:日経コンピュータ 2007年9月17日号 56ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。