全2633文字
PR

 リーダーシップやマネジメント能力を重視する従来型のプロジェクトマネジメント手法だけでは、プロジェクト運営がうまくいかなくなっている。プロジェクトマネジャーには新たに、「ファシリテーション」の能力が求められる。

 中堅製造業の生産管理システム構築プロジェクトを担当する若手プロマネ原川の視点から、ファシリテーションについて解説していく。もうすぐテストという段階で、ユーザーが「この機能がないと業務が回らないから追加開発してほしい」と言い出し、メンバーがつい受けてしまった。ところがスケジュール上、とても対応している余裕はない。この状況を原川はどう乗り切るのか。


〈イラスト:串田 千麻〉
〈イラスト:串田 千麻〉

 プロジェクトの進捗会議。開発フェーズも終盤を迎えているにもかかわらず、インフラリーダーの八木がユーザーから追加要望を受け入れて帰ってきた。

八木:お客さまからこんなリクエストを受けました。対応必須になりそうです。

メンバー:ええっ。

開発リーダー高野:ちょっと八木さん。その要望を受けると他の機能の改修も必要になります。ここまでプロジェクトが進んでいると、追加開発はいまさら無理です。

移行リーダー大山:運用観点だと手順書を大幅に増やすことになります。八木さん、どうしていつも受け入れてしまうのですか。

八木:状況はわかっていますが、この機能がないと業務が回らなくなるとお客さまが言っているのです。

全員:…。


 プロジェクトを進めていくうえで、ユーザーの無理な要求に遭遇する場面は必ずある。開発フェーズがほぼ終わりに差し掛かり、テストと移行作業の準備を進めている。そのような段階で、ユーザーから仕様変更の要求があり、それをユーザー対応を任されたメンバーが受けてしまった。しかもユーザーは、変更を要求した機能がないとシステムを利用して業務ができないと訴えている。プロジェクトメンバーは「何とか対応しないとまずい」と考えてしまう。

 特に技術に強いメンバーの場合、「何とかすれば対応できるかも」と考えがちだ。ユーザーとの折衝の場で技術的に対応可能かどうか判断できるため、ユーザーから「この機能がないと業務が回らない」と言われると、技術的な観点からのみ検討し、可能であれば仕様変更を受け入れてしまうケースがある。

思考停止の言葉に気を付ける

 プロジェクトメンバーは皆、「ユーザーの業務を良くしよう」「ユーザーに満足してもらおう」と思ってシステム開発に取り組んでいる。そうした中、後から「この機能がないと業務が回らない」と聞くと、「ユーザーがシステムを利用して業務を遂行するために、とにかく何とかしなければ」と思い込んでしまうのだ。

 マネジメント重視のプロジェクトマネジャーの場合、ユーザーがどうしても必要な機能を実装するために、仕様変更にかかる期間はどの程度か、再見積もりが必要になるか、リソースは確保できるか、スケジュールの調整は大丈夫か、など様々なシミュレーションを行う。

 経験の浅いプロジェクトマネジャーであれば、慌てて影響範囲を調査したり、見積もりを作成したり、再スケジューリングなどを検討するだろう。

 ベテランで技術力が高いITエンジニアのリーダーであれば、時間のかかる費用交渉や社内承認を経るよりも「開発したほうが早い」と、作業に着手してしまう可能性もある。