注目のセミナー

申込受付中!

【開催間近】
手戻りなしの
要件定義テクニック

要件定義の基礎から
現場で役立つノウハウ
まで徹底解説!
★ミニ演習つき★

開発プロセス

プロジェクト・マネージャの「やってはいけない」

日経SYSTEMS

[品格編]メンバーの責任にしてはいけない

2012/02/09
上田 志雄=ティージー情報ネットワーク

 システム開発プロジェクトがQCD(品質・コスト・納期)を満たせずに失敗に終わることは少なくない。日本情報システム・ユーザー協会(JUAS)が実施した企業IT動向調査2011によると、500人月以上のプロジェクトで納期遅延が42%、コスト超過が40%、品質に不満が31%となっている。

 これらの失敗には、プロジェクト遂行過程において必ず何らかの兆候がある。その代表的なものが現場で日々起こる「小さなミスや失敗」だ。小さなミスや失敗が現場で起こったとき、「担当したメンバーの起こした失敗だ」と片付けるPM(プロジェクトマネジャー)がいるが、それではいけない。小さなミスや失敗がプロジェクト全体の失敗に直結することが少なくないからだ。

メンバーの提案を尊重するPMのSさん

 SさんはSIベンダーに入社して10年の中堅エンジニア。数年前からいくつかの小さなプロジェクトのPMを経験してきた。今回、これまでの実績を買われて大規模なシステム再構築プロジェクトのPMを任されることになった。

 プロジェクト開始当初からSさんは、メンバーに対して細かな指示は一切出さなかった。いつも気難しそうな顔をしてはいたものの、「君がそう思うんだったらいいんじゃないか」といった具合に、メンバーの提案を尊重していた。メンバーもそんなSさんに対して「思ったようにやらせてもらえているぞ! Sさんのためにも頑張ろう」と意気に感じていた。プロジェクト内の雰囲気も非常に良かった。

 そんな雰囲気の中、新システムの一部の機能で利用するパッケージソフトを選定することになった。既存システムで利用しているX社製のパッケージか、それともY社製のものか、どちらを採用すべきかを決める必要があった。

 早速Sさんは、この機能を担当しているメンバーのA君に調査・検討を指示。その結果「パッケージの機能はほぼ同じなので、コストが安いY社製にしたい」と、A君から提案を受けた。Sさんは「安定性で選ぶなら既存システムで使っているX社製だろうけど、担当の君の結論ならば、まあいいだろう。機能が同じならば安い方がいいかもな。早速次の定例会議でY社製を使うことを提案するよ」とA君に伝えた。

 A君は大喜びですぐにY社のパッケージソフトの導入に向けて詳細な検討作業に取り掛かった。ユーザー企業の利用部門との定例会議でも、Sさんからの提案でY社製パッケージの導入がすんなりと決定。その後の設計フェーズと実装フェーズは順調に進んでいった。

>>製品の相性問題が発生
次ページ以降はITpro会員(無料)の方のみお読みいただけます。
会員の方は、 ログインしてご覧ください。
まだ会員でない方は、ぜひ登録(無料)していただき、ITproの豊富なコンテンツをご覧ください。

この記事に対するfacebookコメント

nikkeibpITpro

読みましたか? 〜 未読記事をご紹介