コンサルティング

野村證券と日本IBMの訴訟にみる属人性排除の難しさ

  • このエントリーをはてなブックマークに追加

日経コンピュータの名シリーズ「動かないコンピュータ」に、日本IBMと野村證券の訴訟問題が掲載されていました。この訴訟については、IT専門誌にかぎらず、日経新聞や一般のビジネス雑誌にも取り上げられるほどの大規模なIT訴訟のようです。

 

以下、日経コンピュータからの引用です。

<引用開始>
野村ホールディングス(野村HD)と野村証券が日本IBMに対し、開発費用など計33億円の損害賠償を求めるIT訴訟の詳細が判明した。海外製パッケージソフトを利用したシステム導入の失敗が裁判へと発展した。
<引用終了>

日経コンピュータの記事によると、日本IBMの受注規模は約18億円。これだけの巨大なプロジェクト、かつ超がつく有名企業同士のプロジェクトであっても、プロジェクト崩壊の原因はキーパーソンの離脱。つまり属人性が排除しきれなかったことにあるようです。

 

実は個人的にも同様の経験・・・

つまりキーパーソンのプロジェクト離脱によるプロジェクトの崩壊を経験していることもあり、改めてITプロジェクトから「属人性」を排除することは困難であるとの認識を強くしました。

訴訟の概要

以下、全て日経コンピュータの記事をもとに書きます。

 

野村證券は2008年ごろから、老朽化した基幹系システムを2013年までに全面刷新する計画を進めており、その際に「SaaSやパッケージソフトを活用してIT費用を抑える方針を打ち出した」とのことです。この要求に対して日本IBMは、海外パッケージソフトのカスタマイズ導入を提案・受注しました。このパッケージソフトは金融系ソフト大手であるスイスのテメノスが開発したものであり、テメノスはIBMとパートナー関係にあるということです。

 

そして、今回のプロジェクトでは、たった3人のキーパーソンがプロジェクトを離脱したことでプロジェクトが崩壊したとのことです。

プロジェクト崩壊の原因はキーパーソンの相次ぐ離脱

まずひとり目は、日本IBM側でプロジェクトリーダーの立場にあったA氏。このA氏は社内の人事異動によりプロジェクトを離脱したとのことですが、野村證券側の主張によると、交代要員に対して十分な引き継ぎがなされず、以降のプロジェクト進行に大きな支障をきたしたとのことです。

 

次にパッケージソフトの開発元であるテメノス日本法人のB氏が退職によりプロジェクトを離脱。そしてトドメの一撃(?)が、パッケージソフトのカスタマイズを担当していたテメノス本社C氏が退職したことだったとのことです。

 

野村證券はC氏をカスタマイズのキーパーソンと認識しており、退職後もPJ終了まではC氏には該当プロウジェクトに対して、50%の労働時間を割くことで日本IBMと合意していたらしいのですが、実際C氏は退職してからプロジェクトに関与していないということです。

 

野村證券は、これらPJを離脱した要員の復帰を含めた23項目の改善要求を日本IBMに通達しました。だが日本IBMから十分な回答が得られなかったとして同年11月、プロジェクトの中止を日本IBMに伝えたということです。

 

数十億円規模のプロジェクトもたった3人のキーパーソン離脱で崩壊するのがITプロジェクト

これだけの予算規模、更には委託側・受託側ともに、恐らく知らない人はいないというぐらいの超有名企業。普通に考えれば、様々なリスクを事前に想定し、幾つものリスクヘッジ策・セーフティーネットを用意してのプロジェクト運営を行っていると思います。

 

しかし実際には、たった3人のキーパーソンがプロジェクトを離脱しただけで、これだけの規模のプロジェクトが崩壊してしまうのです。

 

特にC氏に対するリスクヘッジはあまりにお粗末なように感じます。一応「退職後もPJ終了まではC氏には該当プロジェクトに対して、50%の労働時間を割くこと」とありますが、C氏が事故や病気により、その業務に携われなくなることは十分に考えられます。

 

また、「この50%との労働時間を割くこと」というのが、誰と誰の契約だったのかも気になります。日本IBMとC氏の直接契約ならまだしも、野村證券と日本IBMの契約であれば、これはただの気休めというレベルだと思います。

キーパーソンの離脱リスクに対するコスト

キーパーソンの離脱リスクに対する対策はかなり難しいと思います。

 

一番簡単な対策は、キーパーソンの属人性を排除するために、複数人をプロジェクトにアサインするという方法はあります。しかしその増分だけ、プロジェクト費用は高価になってしまいます。案件がコンペとなれば、提案側・受託側はぎりぎりまで見積り金額を削ります。その中で利益を出そうとすると、当然アサインする人間を削る事になるでしょう。

 

一方、顧客はそんな裏側の事情はどうでもよく、単に安い提案に発注する傾向があります。よって、適正にリスクコストを積んでいるプロジェクトは受注しづらい状況になります。結果、リスク想定の甘いベンダーにプロジェクトが流れてしまい、お約束のように「デスマ」という結果を招きます。

 

また、もしリスクを見越して、複数人をアサインしたとしても、本当にキーパーソンとなるような優秀な人間の仕事を、その他大勢のアサインされた人間でこなせるかも疑問です。ITの世界、特にプログラマやSEに関しては、能力のある人とない人では、その仕事の生産性に軽く20〜30倍の開きがあります。でも給与にはそれだけの開きは絶対にありません。これでは優秀な人間はやってられないということで、独立したりより良い条件で他社に引きぬかれたりでプロジェクトから離脱するわけです。

 

さらに、外資では「転職はチームで動く」という文化もあります。私も外資系で過去3回ほど転職を経験していますが、全て「チームでの転職」でした。なので、リスクヘッジを見越して複数人のメンバーをあてがっても、全員が手を繋いでプロジェクトを離脱するというリスクだって十分にあるのです。

 

こう考えると、キーパーソンの離脱リスクに対する完全なヘッジは極めて困難です。それどころか、有能なキーパーソンが離脱せずに最後まで走ることのできたプロジェクトは、ある意味「ラッキー」だったという見かたさえできます。

キーパーソンを「人として大切にする」ことが一番のリスクヘッジ

私はこれまでいろんな技術者さんと仕事をしてきました。その経験の中で、多くの技術者は純粋で、単にお金の条件のみで動く人はそれほどいなかったように思います。もちろん守銭奴のようなエンジニアさんもいます。しかし、それはそれでその人の強烈な個性ですよね。私は嫌いじゃないです(笑)。

 

エンジニアにとって重要なのは「やりがい」を感じられる仕事です。この「やりがい」は、時に金銭的な報酬以上に大切です。これは個人的にも経験があるのですが、金銭的にかなりの高待遇で雇用されたとしても、1年も経過すればそれは「当たり前」になってしまいます。

 

「やりがい」とはなにかを定義するのは極めて困難です。

また「やりがい」は、人それぞれだの感性に依存します。

 

私自身は、「自分がつくったソリューションがユーザに喜ばれ、『ありがとう』の言葉を直接ユーザからかけていただけた」瞬間が、エンジニアとして最高の幸せの瞬間のひとつであり、やりがいを感じる瞬間です。

 

また、直接ユーザから声をかけていただける機会が得られにくいポジションであったとしても、直接の雇用主である社長や上司、プロジェクトチームのメンバーから「ありがとう」「君のおかげで助かっている」「今後も一緒に仕事をしたい」という言葉を頻繁にかけてもらっている場合とそうでない場合とでは、そのキーパーソンの退職リスクは全く異なるのではないかと思います。

 

人間だれしも「ありがとう」と言われて嫌な思いをする人はいません。
ありがとうと言われる瞬間は、誰にとっても大なり小なり「幸せ」を感じる瞬間だと思うのです。

 

精神論的な話になるかもしれませんが、職場とそのキーパーソンとの間に「良い雰囲気」が醸成されていることは、プロジェクトの重要成功要因のひとつだと思います。そしてプロジェクトを発注する側としても、単に契約書の内容と見積金額だけではなく、その辺りを敏感に感じるセンスが必要かもしれませんね。

 

ちなみに私は仕事を発注する・しないを判断する場合、ある程度のお金と時間を使ってでも、そのプロジェクトに携わる予定の技術者さんと食事をご一緒して、ざっくばらんな交流会を持つようにしています。この交流会で、おおよそその会社の雰囲気を感じる事ができます。

 

また、「逆もまた真なり」で、自分が仕事を請け負う側の場合、必ずお客さん先の、特にエンドユーザの仕事環境は必ず詳細に確認します。そしてそういった場では、必ず現場の方とざっくばらんなお話しをして、その職場の雰囲気を「感じる」ようにしています。

 

感覚的なものではありますが、この「感じることのできるセンス」って、ITエンジニアにとっては想像以上に重要な事だと思っています。

 

そして最も大事なこと。
それは「感謝」を忘れない。
そしてそれを言葉に出すということですね。

  • このエントリーをはてなブックマークに追加