まず日程を設定しているか

　製品を受託開発するプロジェクト進行中に顧客から仕様変更の検討依頼がありました。ある仕様の変更は可能かということと、それに要する費用はどれくらいかというリクエストです。依頼を受けた担当者は社内で関係者と検討を始めましたが、仕様の変更は社外から購入しているパッケージに依存することから、パッケージの提供元と折衝を行うことになりました。何度かやりとりした結果、パッケージ側の仕様は変えられないということで、顧客から依頼のあった仕様変更には対応できないという結論に至りました。顧客から検討依頼を受けてからここまで2週間を要したところで、いざ顧客に結論を回答したところ、担当者は”音沙汰が無かったので仕様変更に対応してもらえるものと思っていた。いまさらできないと言われても困る”と言われてしまいました。

　もう一つの事例です。プロジェクトのマイルストーンとして、開発する製品の基本設計レビューを社内関係者と共に実施することになっていました。担当者は、基本設計を完了しその成果物について上司の承認を得たのち、基本設計レビューを開催するべく関係者の日程を調整しようとしました。しかし、なかなか関係者の日程が合わず、どうしても参加してほしい人を優先し、それ以外の人は個別に成果物を見てもらうことにしても、開催日が10日後になってしまいました。基本設計結果を受けた後続の作業が控えているなか、10日間のラグが生じることになったのです。

　上記2つの事例に見られる問題は、いずれもまず日程を設定していないことによるものです。

　前者は、顧客から仕様変更の検討依頼を受けた時点で、担当者がいつまでに検討結果をお知らせするということを回答するべきでした。そのうえで、約束した期限に遅れそうな場合は、それが分かった時点で検討状況と新たな日程を顧客に連絡する必要があります。検討の予想結果が顧客の望まないものになりそうな場合は、特に早めに状況を連絡しておくべきでしょう。

　後者は、可能ならプロジェクトの計画時点で、それが難しい場合は基本設計が完了する予定の(このケースの場合は)10日以上前に関係者の日程を調整しておくべきでした。もしプロジェクトの計画時点で日程を設定できるなら、だいぶ先のことになるので調整作業は不要にでき、この日に実施するので参加してください、という案内を事前に発信しておけばよいでしょう。

　前者については異論がないところだろうと推測しますが、後者についてはそうは言っても基本設計が計画通りに進まないかも知れないし、実際には難しいという意見があるかも知れません。しかしプロジェクトであるなら、いつまでに顧客に製品を納入しなければならないなど、全体の期限があるはずです。最終的な期限は約束し守らなければならないのであるから、途中の期限を守れないことはないのです。途中の期限に対する意識が低いことが、最終的な納期遅延を招くこと、あるいはプロジェクトの終盤に混乱を引き起こすことにつながると考えられないでしょうか。

　期限を定めることは自らにプレッシャーを掛けることになりますが、有期的制限を持つプロジェクトにおいてはそこから逃げてはいけないのです。プロジェクトは一人でやっているわけではないので、自分自身の精神的負担は発生しますが、関係者と状況を共有し適切に巻き込んでいく進め方は、結果的には自分を楽にします。プロジェクトに限らず、まず目標日程を定め、場合によっては周囲に宣言したうえで物事に取り組み始めるというのが、成果を出すための効果的な手段となることは実感できるところではないでしょうか。

　最新の提言を、メールマガジン(無料)で配信しています。是非ご登録ください。