今回は、「バッファー込みで作業をさせてはいけない」「報告を待ってはいけない」など、「作業指示」と「進ちょく管理」という2つの場面における、7種類の禁じ手を解説しよう。

作業指示:バッファー込みで作業をさせてはいけない

 PMはスケジュールを見積もるとき、問題が起こった場合などに備えて、作業や工程ごとに遅延を見込んだ「バッファー」を確保しておく。そしてそのスケジュールをユーザーと合意した上で、プロジェクトを進めていくことになる。

 このときPMがやりがちなのは、バッファー込みのスケジュールを、バッファーが含まれていることを伝えないままチームリーダーやメンバーに示して、作業指示をしてしまうことだ。みずほ情報総研の百井氏は「PMが忙しいときは特に、ユーザーに見せたスケジュール表を、そのまま示しがちだ」という。

 しかし、バッファー込みのスケジュールで、リーダーやメンバーに作業をさせてはいけない。「作業の手戻りが起こったときには、備えのためのバッファーが既に使い込まれてしまっているという状況になり、リカバリーできなくなってしまう」(百井氏)からだ。

 作業を進めるとバッファーがなくなっていく、という状況を回避するには、リーダーやメンバーに作業指示を出すときに、注意しておく必要がある。百井氏は、バッファーを隠したスケジュールを作成し、それに基づいてリーダーやメンバーに作業してもらうようにしている。

 例えば、5日間を割り当てている作業のうち、バッファーが1日分含まれている場合、リーダーやメンバーには、4日間でその作業をこなしてもらう。隠したバッファーは、PMである百井氏が別途管理する。管理しているバッファーは、スケジュールが遅延しそうなときに、使えるようにする(図1左)。

 バッファーの使い込みを防ぐ策はほかにもある。作業ごとのバッファーを集め、リーダーやメンバーに公開するのだ(図1右)。

図1●バッファーの使い込みを防ぐための取り組み例
図1●バッファーの使い込みを防ぐための取り組み例

 みずほ情報総研の笠井究宣氏(法人ソリューション第4部 第1チーム第2課 課長)は、集めたバッファーの総量を公開して、バッファーを極力減らさないことをプロジェクトを進める上での目標に掲げている。バッファーを共有することで、メンバーは自分の作業の遅延が、全体に影響することを意識せざるを得ない。「バッファーを使わずに作業が進められるようになると、メンバーのモチベーションも高まってくる」と笠井氏は効果を語る。

 バッファーの量をどれくらいにするのかも、メンバーの納期順守の意識に影響するので注意しておきたい。TGIフィナンシャル・ソリューションズの坂下氏は「あまりバッファーを多く取りすぎると、PMやリーダーを含めたメンバーの気が緩み、プロジェクトが遅れがちになる」と説明する。

 実際、坂下氏が以前経験したあるプロジェクトでは、全工程の3割程度のバッファーを確保したのにもかかわらず、納期ぎりぎりで終結した。本来固める必要があったインタフェースの仕様が、広い範囲で抜けていたためだ。「余裕があることでかえって気が緩んでいた。バッファーは全工程の1~2割程度にとどめておくと、緊張感が保たれる」と、坂下氏は話す。

作業指示:メンバーの見解に納得してはいけない

 あるプロジェクトでシステム仕様が固まりかけたころ、PMだった富士通の北岡良一氏(特定社会システム監視本部 本部長代理)は、顧客情報を管理する顧客管理サブシステムの担当リーダーから次のような報告を受けた。「ユーザーから業務時間中に顧客情報を変更できるようにしたいという追加の要望を受けました。機能追加は技術的には問題ないので、すぐに実現できます」。

 ユーザーの要望をできるだけくみ取ろうとするリーダーの姿勢は評価できる。そのメンバーの技術的な知識もスキルも信用している。しかし北岡氏は納得しなかった。「その機能を加えることで、それまで固めてきた仕様をかなり見直す必要がある」(北岡氏)と判断したからだ。

 プロジェクトの中で機能の実現しやすさを判断できるのは、通常はPMではなく、顧客管理サブシステムを担当するメンバーである。そのためPMは、メンバーが専門とする技術に関する見解や意見は、素直に受け入れてしまいがちだ。

 しかし、メンバーの見解に、すぐに納得してはいけない。すぐに実現できるというメンバーの判断が妥当でも、PMにとっての判断材料はそれだけではないからだ。PMは、技術面での情報はもちろん、プロジェクト全体を見て、さまざまな情報を基に、適切に判断しなければならない。「ユーザーと交渉するよりも技術的に解決するほうが早い、と考えがちにもなるので、注意が必要だ」(北岡氏)。

 冒頭の例では、顧客管理サブシステムだけを見れば確かに、機能を追加しても問題はなかった。ところがそのプロジェクトでは、業務時間中の取引情報を管理する取引管理サブシステムも併せて開発していた。取引管理サブシステムは、顧客管理サブシステム上の顧客情報を使って、取引を処理する。顧客管理サブシステムで、業務時間中に顧客情報を変更できるようにしてしまうと、取引データへの影響を調べる機能や、取引データを変更する機能などを新たに追加する必要が出てくるのだ。

 北岡氏は「メンバーの見解をうのみにせず、信頼性や品質、これまで固めてきた仕様などに影響がないかどうかを踏まえて、PMは判断する必要がある」と話す。

 また、ITエンジニアは基本的に、得意な技術にこだわりのある人が多い。例えばシステムの開発中に性能問題が起こったときにも、「技術や方式ありきで、解決策を見つけようと主張しがちだ」(丸紅情報システムズの岡安氏)だ。しかしPMは、メンバーのこうした技術へのこだわりに対しても、適切な対応を採る必要がある。「メンバーが広い視野で解決策を出せるように誘導するのもPMの役目」(岡安氏)なのだ。