SIG
先号　　　次号

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

PS研究会MM4リーダー：富士通株式会社　松田　浩一　[プロフィール]　：5月号
1．ふりかえり
　前回のオンラインジャーナルで、過去の失敗経験からプロジェクトマネージメント力の強化や社内ルール、仕組みを強化しているにもかかわらず、なかなか思うように失敗が減らないことを報告しました。失敗プロジェクトとは、単に納期遅れや、コストが予定以上、バグが多かった、などというものではありません。ここで言う失敗とは、SIシステム開発を断念してしまうか、サービスを開始してもほとんど機能しないような大きな品質問題を抱えるものです。失敗原因については、要求事項がいつまでも確定しなかった、見積り精度が低くて予定の稼動では無理があった、スキル者が不足しており技術面で力が及ばなかった、などと聞きます。しかし、このようなプロジェクトでは、問題に気づいた時は既に手遅れであったということです。前回、プロジェクトマネージャを含むプロジェクトメンバーひとりひとりをプロジェクト実態ととらえたときには、「作業を実際に行う人の責任感の総量が一定の濃度に達しなかった」ことが根本原因だと報告しました。今回はこの責任感の濃度についてお話したいと思います。

2．ESとPSについて
　プロジェクトに参加したメンバーひとりひとりの「やる気」のようなものをPS(Partner Satisfaction)として、これまで研究してきました。ESによって社員のやる気を引き出し、CSを向上することが企業存続の重要な観点と言われます。現在のSIシステム開発をなりわいとする企業では、ほとんどの作業実態がプロジェクト型となり、プロジェクトは複数の会社に所属するメンバーで構成されています。プロジェクト型の職場ではESではなく、現場の作業者の満足度、すなわちPS向上が重要になります。
　近年、コンプライアンスの問題やセキュリティの問題、個人情報流失などを気にするあまり、報告やチェックを無意味に増加させるようなことが起こり、所属企業からのプロジェクトにおけるメンバーの働き方を締めつける傾向にあります。さらに大型開発が減少し、SI不況になっていることを背景に、売上げや利益目標など、企業の危機感が数値として末端のメンバーにまで浸透しているのかもしれません。もともと給与支払い者である会社の命令がプロジェクトの命令より強いところへ、このような背景からプロジェクトに必要な作業を考えず、盲目的に会社からの指令にしたがって作業をこなすようなメンバーも出ています。PSの観点からみた場合、メンバーひとりひとりのやる気は、「プロジェクトを成功させる」ことより「所属企業が得をする」ことを目指すようになっています。

3．プロジェクト目標と企業目標の乖離
　ひと昔前、汎用機全盛のSIシステム開発では「初めての技術適用」「初めての開発言語」「初めてのプロジェクトでの作業」が多く、失敗もたくさんしました。しかし初めてづくしなので問題があるのが当たり前、多くのメンバーが解決に向けて協力していました。さらに時代を経て、新たに出てきた言語、便利なフレームワークなども普及し、開発技術としては大変進化したことが実感されます。ところが、こういう進化に反して後退していると感じるのが前述した「プロジェクトを成功させる」という、ひとりひとりの思いです。自社のコストダウンのためにはリスク回避という観点が必要になってきます。リスク回避のために会社独自の作業計画が厳密になり、自社の責任範囲を限定する傾向が強まってきます。また、作業の割り当てが明確になった結果、各個人は自分の範囲をスケジュール通り終わらせれば良いという表面的な合理主義がはびこってしまいました。新しいプロジェクトマネージャは、SIシステムとは「進化したツールを使い」「計画を厳密に作る」ことで、積み木を組み立てたら完成するような簡単なものと勘違いするようになったのかも知れません。作業する人が、プロジェクトを進めるなかで新たに出てきた懸案事項や小さな問題を認識したとしても「計画外」であることを理由に「対応すると自社利益の喪失」と考えて放置することが常識になります。さらに深刻なのは、自社の問題に直結する計画外の懸案は「下請け企業の責任範囲」として押し付けるという態度が出てくるということです。プロジェクトの実態を把握できない顧客や元受企業の責任者にはこのような態度がしばしば見受けられます。予算オーバーになることを恐れるあまり「計画外のことは出入りの業者の責任だ」という態度で接することが得だと勘違いしています。多段階の契約で結ばれているさまざまな企業がこれと同じことを主張すると最終的に末端の作業者へのしわ寄せとなり、本来解決すべき組織的な対応がまったく出来なくなります。作業しているメンバーひとりひとりから見ると「なんて無責任な」と思いつつも「自社のためには仕方が無い」と思う人もいますし、「なんとかしたい」と気づきながら「忙しすぎて手が出ない」と思っている人もいます。プロジェクトを成功させるために、このような問題を解決すべき組織があれば良いのですが、せいぜい「共通グループ」と言ってみたり「クオータヘッド」と言ったりして少人数で、ものすごく忙しくて手が回らない組織に対応させているのが実態です。結果として実際に作業する人達は「言っても仕方が無い」「言ったら自分に跳ね返ってくる」ということで問題が表面化されなくなります。

4．プロジェクトが失敗して企業が成功することは無い
　誰でも同じような成果が出るためのツールや仕組みが発達してきました。個々の作業の範囲では合理的で計画が厳密であればあるほど成功の確率はあがるはずが、プロジェクト全体で見ると柔軟性を喪失し、放置される懸案事項が増えてしまうという、なんだか良いのか悪いのか分からないことが起こっています。
　昔から末端の作業者はリーダーに向かって「これは大変な問題です」と報告すると、リーダーは課長に向かって「問題はありますが何とかなりそうです」と言い、課長は部長に「問題がありましたが解決目処が立ちました」と言い、部長は事業部長に「何の問題もありません」と言っていました。今回の「続・なくならない失敗プロジェクト」で主張しました多段階契約企業の利益優先のために問題が解決されないこと以外にも伝統的な問題はいつの世にもあります。いつでも成功の決め手となるのは、プロジェクトメンバーが自分で気になることを発信し、他のメンバーから発信された問題にも敏感に反応し、有機的な組織としてのその都度、その問題を解決することです。数値目標を言う企業が悪いのか、我欲に取り付かれた発注元が悪いのか、そもそも問題を発見しても放置する担当者が悪いのか、立場によっても違うと思います。少なくともプロジェクトマネージャは意識してこのような事態にならないように目配りする必要がありますが、重要なのはメンバー全員がそうならないように気づくことです。所属企業側でもプロジェクト側の思いを理解し、これを支援することの必要性に気づかない限り、完璧なリスク回避を続けても「わが社はいつも失敗するプロジェクトに従事しているなあ？」というマイナスの結果しかありません。

5．まとめ
　今回は「責任感の濃度」についてお話することにしました。責任というとリーダーや管理者、経営者を思い浮かべるのですが、今回述べたのは「作業者の責任」です。その濃度とは、プロジェクトに対して良かれと思って自分が出来る具体的な動き、その頻度のことです。気になっているのに「知らん顔」をすること、隣の人が困っているのに「放置」することが積み重なって「責任感の濃度」は希薄になります。
　今回のお話は続編なので、前回の結論と同じです。これから益々「自分がやらなきゃ誰がやる！自分が言わなきゃ誰が言う！」という積極果敢なメンバー育成をし、増やすことが私達PS研究会の新しいテーマのひとつとなりそうです。

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