社内プロジェクトマネージャーで、数々のプロジェクトを率いてきた経験を持つ佐藤誠氏が語る、三回にわたって掲載する「プロジェクト管理の極意シリーズ」の最終回です。
プロジェクト管理と一言で言っても、やるべきことは多くありますが、今回のシリーズでは受託開発のプロジェクトに焦点を当てて、それぞれのタスクごとにポイントをご紹介していきます。
最終回では、プロジェクト終盤やプロジェクト終了時にやるべきことや、プロジェクトがトラブル・炎上に陥った場合の対策についてのインタビュー記事を掲載します。
とりわけ、プロジェクト炎上時はマネージャーとして手腕を発揮するべきポイントですので、マネージャーとしての資質が問われるでしょう。
目次
プロジェクト終盤 品質問題
プロジェクトも終盤戦に差し掛かると、品質の問題が気になってくることがあります。 時として、「機能的には問題ないけど、品質がいまいちだよね」などといった会話が、メンバー間で交わされることもあります。
そういった場合は、迷うことなく品質重視の対策を講じます。
多少の利益を削ってでも、体制を強化したり、より多くの工数を掛けたりするなどの対策をとります。
また、急な仕様変更や想定外作業が入ってくる可能性がないとも言い切れないので、常にメンバーの増員ができるような体制をとっておくことが重要です。
品質を重視することは、該当プロジェクトだけでなく、お客様と継続的な取引をさせて頂くためにも必須と言えます。
次回以降も当社にお願いしようとお客様に思って頂けなければ、継続して取引を行うことはできませんので、短期的な利益を優先するのではなく、長期的な信頼関係の構築を優先します。
次のプロジェクトに向けてメンバーとの会話が重要
プロジェクトも終盤に差し掛かり、ゴールが見えてきた頃には、次のプロジェクトのメンバー構成を決めておかなければなりません。
突然、「3日後から、次のプロジェクトに入って下さい」ということや、「明日から違うプロジェクトでお願いします」などということは、メンバーのストレスにもつながりますので、避けなければなりません。
ある程度のゆとりを持って、前もってプロジェクト変更や移籍の可能性の話だけでもしておく必要があります。
プロジェクトによっては夜勤があるものや、休日出勤があるものもありますので、前もって伝えておくことは必須と言えます。
その際はマネージャーによる上からの押しつけだけで決めるのではなく、メンバーの意見も聞きながら、できるだけ双方が納得のいく形での合意形成を図ります。
また、いつ頃からどういったスキルの人間が何人必要かといったことは、日頃からリーダークラスの部下と対話をするようにしています。
急に言われてもなかなか対応できない面もあるので、日頃の会話を通して準備を進めておきます。
基本的に、メンバー構成はリーダーに任せて、リーダーから依頼されたスキルセットを持つ人間を集めることが、マネージャーとしての役割となります。
＜コミュニケーションの重要性について語る佐藤氏＞
プロジェクト炎上前・炎上時の対応方法
まず、プロジェクト開始前の見積の段階で、このプロジェクトは炎上するかもしれないと気づくことがあります。
それは、短期スケジュールのプロジェクトにおいて、お客様担当部分の作業が遅延するリスクが高いと感じる場合です。
例えば、4月から弊社メンバーが開発を開始するというスケジュールになっている場合に、それが5月、6月と開始時期が遅れていくことがあります。
そういった場合には、お客様側と交渉を行い、双方の妥結点を見出すことになります。
金額面やスケジュール面で調整を図りますが、往々にしてプロジェクトが炎上してしまうことがあります。
その他の炎上パターンとしては、基本的に後工程になることが多く、製造中に炎上するかもしれないと気づくことがあります。
基本設計や詳細設計等の設計フェーズでも、上手くいっていないと感じることはありますが、この段階では炎上というより、単なるトラブルという認識が強くなります。
炎上の定義・考え方
炎上の定義としては、以下の3点が挙げられます。
- 高稼働
- スケジュールの破綻
- 想定見積を大きく超えて工数がかかっている
一点目の高稼働はそのままですが、月単位の長期にわたって昼夜や休日を問わず、働かなければならない状態を指します。
二点目のスケジュールの破綻については、作成していた想定スケジュールが全く無い状態になることです。 立て直そうにも立て直しすら効かず、先のことを予想することもできない状態を指します。
遅延が発生しているにも関わらず、リリース日はずらさないということになると、炎上状態になります。
リリース日を後ろにずらすことができれば、トラブルで済むでしょう。
三点目の想定見積を大きく超えて工数がかかるというのは、よりマネージャー側のミスである場合が多く、見積が甘かったと言わざるを得ないでしょう。
例えば、10人月と想定していたプロジェクトが13～14人月程度になるくらいなら、トラブルという扱いで済みますが、15人月を超えて20人月程度かかってしまうようだと完全に炎上ということになります。
工数が見積もりの倍近くかかれば、当然利益は上げられず、プロジェクトとしては赤字になります。
プロジェクト炎上時の具体策
まずプロジェクトの炎上以前に、トラブルに気づいた段階で早めのアプローチをすることが大切です。
人員補強を行うことも対策の一つとして挙げられますが、人員補強にはタイミングでの限界がありますので、早め早めにトラブルの芽をつぶしておくことが重要なポイントと言えます。
その上でプロジェクトが炎上してしまった場合の対応方法として、まずは上述の通り、人員補強を行うことが挙げられます。
プロジェクトが炎上しているので、助けて下さいという形でお願いをすることになります。
しかし、新規メンバーを追加した場合でも、すぐにプロジェクトに対応できるというのは夢物語であり、既存メンバーにキャッチアップするのに最低でも１～2週間はかかるので、ここは辛抱が必要です。
あとは月並みですが、プロジェクト関係メンバーで何とかやり切ることです。
この時は、マネージャーとしての腕の見せ所となります。
つまり、マネージャーが先陣を切って一番働くことで、メンバーに背中を見せることが重要です。
この時は、まさに上からピラミッド順で稼働を上げていきます。
また、メンバーに対してはアメとムチを上手く使い分け、なんとかやり切る方向にチームをまとめ上げることがポイントです。
メンバーに対してお詫びするところはきちんとお詫びをする、やってもらうことはやってもらうというメリハリをつけることも必要です。
例えば、マラソンを走る場合でも、ただただつらいと思って走るのと、いわゆる”ランナーズハイ”と呼ばれるような快感を味わいながら走るのとでは、同じ距離を走るにしても、メンタル的に大きく変わってくるでしょう。
チーム全員で困難に立ち向かうことを楽しむぐらいのメンタルと結束力を持って、プロジェクトを推進していくことが鍵となります。
プロジェクトが無事に終了したら、メンバーには振替休日をとってもらうなど、労いの気持ちを行動で示すことが大事です。
メンバーの中にはプロジェクト終了後も一緒に働く人もいますので、良好な関係性を保っておくためにも、終了後の対応は真摯にしておくべきでしょう。
プロジェクトが終了したら反省・改善を忘れずに
プロジェクトが一段落したら、プロジェクト報告書を作成します。
金額面での予算と実績や作業工数の予算と実績を洗い出し、分析を行います。
その上で、メンバー体制とスケジュールは問題なかったのかについて反省点を洗い出します。
また、プロジェクト推進や評価の考え方として、PMBOKと呼ばれるプロジェクトマネジメントの知識体系を指標として用います。
反省点や問題点を洗い出したら、その点について「いつ、なぜ、どのようにリカバリーしたのか」といった指標で分析を行い、次のプロジェクトへの改善につなげます。
案件によっては作成したプロジェクト報告書をもとに、役員からの評価を受け、良かった部分・改善点等などのアドバイスを頂きます。
プロジェクトが終了したらそのままにせず、きちんと分析を行い、それを可視化することで、次のプロジェクトへとつなげていくことが大切です。
まとめ
プロジェクト管理の極意シリーズの最終回はいかがでしたでしょうか。
プロジェクト中盤から終盤にかけては、プロジェクト全体を通しても山場となることが多いので、より注意を払って管理を行っていく必要があります。
プロジェクトは想定スケジュール通りに順調に進むことよりも、紆余曲折がありながら、なんとか前進していくことの方が多いでしょう。
そういった想定外のケースにも冷静な判断で対策を練り、実行していく断行力が求められます。
また、プロジェクトが苦境に陥っている時ほど、マネージャーが先陣を切って苦境に立ち向かうことで、チーム全体を引き締めることができます。
本来はプロジェクトが順調に進むことが一番良いですが、そうではない場合に、臨機応変な対応ができることがマネージャーとして重要な資質となります。
3回にわたってプロジェクト管理の極意についてのインタビュー記事を掲載してきましたが、今回で本シリーズは終了です。
