SIG
先号　　　次号

「なくならない失敗プロジェクト」

MM4リーダー：富士通株式会社　松田　浩一　[プロフィール]　：4月号
　はじめに、このたびの東日本大震災震災で亡くなった方々にお悔やみを申し上げます。また、被害を受けた方々には心からのお見舞いを申し上げます。

1．これまでの経緯
　弊社ではITシステム開発における、過去の失敗プロジェクトを教訓にして、全社的にプロジェクトマネージメント力の強化、体験的な育成カリキュラムの増強、組織内の手続きの改善、実際の契約時における法務的なチェック機構の追加をしています。これらの対策に先駆けて、ISOに則った証拠主義的な作業による現場責任の明確化や、作業計画の詳細化、型決め、なども実施しています。このような対策は様々な企業でも同じように進めていることと思います。

2．最近の失敗プロジェクトの傾向
　過去の経験に基づいた企業としての対策や、プロジェクト内部でのチェック事項の累積など、様々な対策によって失敗プロジェクトは減ってきていると感じます。しかし、近年発生している失敗は、過去のものとは異質ではないかと感じます。典型的な特徴として、「突然、納期遅延となるか、動かないことが発覚する」「問題が発生したプロジェクトでは、混乱が長引く」というようなものです。
　これまで経験してきた過去の失敗は、上流工程の問題が徐々に、作業を進めるに従って明らかになってくるというものが多かったように思います。もちろん過去に突然問題が明らかになる失敗がなかったわけではありませんが、多くのプロジェクトで発生するようなものではありませんし、特に大規模なシステムでは起こっていなかったように思います。
　自分自身が直接担当していないシステム開発の問題を知った場合に、突然問題が明らかになるというように感じることもあります。つまり、間接的にでも、自分自身がどれだけのプロジェクトを知る立場なのか、という事によっても誤った印象を抱くということです。このような対象物と観察者の立場をわきまえたうえでも、最初に述べた印象は変わらないと思います。

3．失敗の直接原因
　失敗の直接原因を細かく分析すると、沢山のミスが指摘されますが、まとめて言うと「作業を実際に行う人の責任感の総量が一定の濃度に達しなかった」事です。責任感の濃度を左右するのは、どちらかというと管理する立場の方の責任感よりも、システム構築に直接関わる人の責任感であると思っています。急に問題が明らかになるのは「予兆を事前に公にしない」というリーダー層の責任感の欠如と言うこともできます。しかし、事前に明らかになった問題を担当レベルで「これは問題だ」と騒ぐと、プロジェクト全体の共通認識になり、顕在化してきます。そういう末端の担当者の危機意識、問題意識のほうが重要だと考えています。
　混乱が長引くのは「プロジェクト全体を機能的に把握せず、今後の運営計画を時系列にも見ていない」という意志力の薄さを感じます。リーダー層の意志が強い場合は作業チームへの圧力が増し、自由な発言を許さない方向に行く場合が多いため、担当者の自由な発言を許さない方向に進む場合もあります。失敗防止の決め手は実作業を通じて業務的な意味や実際の運用を想像できる担当作業者の意識のほうが重要となってきます。失敗の原因は予兆を最初に感じる作業者レベルの無気力とリーダー層のリスクや問題を感じられる感受性の問題があるといえます。本気で怒りながら、問題を訴えるような情熱が現場に薄れてしまっているのかもしれません。

4．失敗の背景にあるもの
　これまで、さまざまなITシステムの開発手法やマネージメント技法を先鋭化し、作業者の実施すべき作業項目と時間を管理できるようなしくみも整備してきました。しかし、ツールとマネージメント技術があり、詳細な計画ができたら失敗しないというのは、机上の数学で全ての事象を説明できるという前提で仕事を進めるようなものです。例えば1の仕事をAさんが実施し、2の仕事をBさんが、3はCさん、というふうに100までの仕事を計画したら100の仕事は論理的に仕上がってくるというものです。1と2の間には1.5もありますし、√2とか4/3とか、説明しつくせない事柄はその担当する方やレビューする人が考えて作業しなければ実現できないことが現場には沢山あります。
　組織内の正式な会議では、説明しやすいストーリーをもって論理を積み上げ、膨大な作業計画を策定したと言うと承認されやすくなります。あまりにも行き過ぎた管理ルールや上位者によるリスク詳細を危惧する態度が、説明しやすい論理や計画を招きます。現場で起こった問題が自分の責任ではないことを正当化するために上位者へエスカレーションするルールができた結果、逆に上位者は実行前にリスクを認めない態度となる、という責任回避の循環が形成されます。現場の力を引き出し、プロジェクトの成功を願うといった、強い思いを組織として打ち消しているのかもしれないと感じられるのです。

5．気になること(蛇足)
　最近コンプライアンスの問題、セキュリティの問題などがクローズアップされてきた結果システム開発の現場では色々な困難が生じています。従来のシステム開発では機能試験や移行試験を行う場合には実際のデータを利用した確認が行われていましたが、最近は本物のデータは利用許可がでない方向にあります。悪意のある場合に備えていることは理解できますが、品質リスクが増すことは考慮されていません。コンプライアンスやセキュリティなどに関連してシステム開発に関わる手続きやチェック機構が増加している反面、費用は減っていることが失敗の危険性をさらに増しています。

6．まとめ
　最近は失敗をおそれるあまり、自分の作業目標が「ルールによって動く」ことに変わってしまったか、計画した通りチェックしたこと以外に目を向けない人が増えてきた可能性があります。「ルールを守れば自分の責任ではない」と言う思いが蔓延する病気があるのかもしれません。計画通り、ルール通り実行することも重要ですが、柔軟に計画を変更して作業の重要度を検証しながら作業内容に工夫を加えるということも重要であり、このバランスが崩れているのかもしれません。私達のリーダーであった団塊の世代の方は、かなり迷惑ではありましたが、「俺が責任取る。一番良いと思う対策を考えてくれ。一緒に徹夜しよう。」と言える親分ばかりでした。業務や方式の仕組みが体に染み込んでいる親分が定年し、どんどん少なくなっています。「自分がやらなきゃ誰がやる！自分が言わなきゃ誰が言う！」という積極果敢なメンバー育成をし、将来の親分を増やすことが私達の新しいテーマかもしれません。
以上

　 IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。
SIG推進部会は こちら
ITベンチマーキングSIGホームページは こちら
ページトップに戻る