プロジェクトの遅れを取り戻す心構え10選
ZDNet Japanに『プロジェクトの遅れを取り戻す方法10選』という記事が掲載されていました。
これを書かれたのは外国の方のようで、少し日本的でないように感じるものもありましたが、とても参考になります。自分もこれらの10の方策をベースとして、各点で心構えをしておいたほうが良いと思うことをまとめました。特に断りのない場合、項目は本家の記事と連動しています。
＃1：残業する
残業は小規模なプロジェクトや短期間のプロジェクトを乗り切るのに非常に効果的です。要員追加を行なった場合は新しく来た人が戦力になるまでのオーバーヘッドが小さくありません。残業ならばその心配なく戦力を増大させることができます。
ただし1人が1日に働ける時間は限度がありますし、1か月に残業できる時間にも限度があります。（法的にも体力的にも精神的にも）そういうわけで残業で乗り切る前に早めの段階で要員追加を検討すると良いでしょう。
また、1日8時間労働というのは民主的に決めて法律になった社会のルールです。それを超えない範囲での体調不良は個人の責任によるところが大きいですが、それを超えて働いてもらった場合の体調不良はPM側に責任が発生してくるものだと考えています。（もちろん偶発的な病気は抜きとして、ですが。）残業が絡んできた場合は要員の体調管理に努め、連日終電ギリギリまで仕事をしている人がいたら敢えてもう15分残業してもらってタクシー券を渡すくらいの配慮ができたらいいなと思います（もちろん自分の権限を逸脱したり社内ルールに反したりしない限りで）
＃2：リソースの再割り当てを行う
リソースの割り当てがまずい場合、メンバーの手空きが発生する事があります。クリティカルパス上の作業が遅延なく進んでいれば大きな手空きは発生しませんので、まずは計画段階でクリティカルパスに優先的にリソースを割り当てておく事が基本となります。
不幸にも『ドライバできてないのでテストできませーん。暇でーす。』という事態に陥ってしまった場合、手が空いた人を前工程に投入していく必要が出てきます。しかし現実の世界では後工程に大きな影響を与えるような工程は厚い人員配置にすることが多いです。よって、それでも遅れる何かがあるのだから多少の人員投下でどうこうできることは少ないと見るのも一理あるでしょう。時間が解決してくれるのを待つか、後工程の人員にまったく別工程に参画して時間をつぶしてもらうなどの対処が考えられます。
また、後工程の人は自分の作業を増やさないために手空きであることをひた隠す可能性も否定できません。そちらは勘と経験で見抜いていきましょう。
＃3：すべての依存関係を入念に確認する
事前にすべての依存関係を把握できて、その通りにスケジュールを作成できるというのは考えづらい事です。日次や週次での進捗確認でなかなか進捗率が変動しない工程があれば注意していきます。
そのためには「とりあえず着手しました」で進捗率10%くらいのタスクが5本ほど並行で走っている、というような状況だと管理しづらくなります。せめてプライムなタスクがどれかわかるように見える化してもらい、プライムなタスクだけは進捗率の変動率が0%になっていないことを定期的に点検できるようにします。プライムなタスクの変動率が0%だった場合はその理由を調べ、その人の作業で技術的に困難な場面に遭遇しているとか、前工程の成果物を待っているとか、メンタル的にやばくなっているということを判明させていきます。
＃4：一定の時間を必要とする作業を把握しておく
一定の時間を必要とする最たる作業はプロジェクト管理上必要な報告系の会議であると言えます。1weekを8h×5dayと計算して利用できる体力を見積もっておくのは危険です。30minute/1dayとか2hour/1weekという時間を固定的に会議用に参入することをプロジェクトメンバー間でルール化しているのであれば、その分を差し引いて体力計算を行なわない限り「会議の分だけ残業が発生する」ことになります。会議の時間が長かったり回数が多かったりする雰囲気の職場では気をつけたほうがよいでしょう。
＃5：リソースを入れ替える
外から招き入れたメンバーの能力不足に行き当たった場合、一期一会のリソースなら迷わず切るとよいでしょう。その際、次回の調達時までに人材をコーディネートした担当者間で意思疎通に不備がなかったか等を確認しておく必要があります。もし、先方が悪意を以って出してきた場合（経歴詐称など）は2度と取引をしないことを伝えて自社内でその情報を共有するなどの対応が考えられます。
また、入れ替えといってもプロジェクトから追い出すことだけがすべてでなく、プロジェクト内での人間関係の組みなおしで済む場合もあります。例えば面倒見の良い先輩のフリをして後輩に仕事を押し付けたり、新人さんが「右も左も分かりませーん」というフリをして先輩に仕事を逆流させたり、と色々な人間関係があるでしょう。もちろん男女関係が発生してしまう事もあるでしょう。そういった場合は当事者が接触しないような配置にしていきます。
また、不幸にもプロジェクトからはずれてもらうメンバーが発生した場合には、新旧メンバーが引継ぎを行なうケースが多いでしょう。その一環として、一時的に新旧メンバーが一緒に仕事をしてもらうこともありますが、「この人は外されるのか」という思いと「この人が来るから自分は追い出されるんだな」という思いが交錯してスパークしないよう配慮しなくてはならない場合があります。特に出ていく人の性格には注意が必要です。
＃6：スケジュールを圧縮する
メンバーは急に調達できませんし、不要になったからといってある日突然に解放することも難しいです。また、メンバー投入の日から、そのメンバーが実力を発揮するまでにはプロジェクト目的の共有から顧客属性の理解やらで多大な労力が必要となります。そのためスケジュール圧縮に伴い人員の調達計画を変更すると無駄が生じ、多くの場合でコストの増大が伴います。
もしスケジュールを圧縮する場合は、クリティカルパスの遅れに対して一時的に『プロジェクト内特命プロジェクト』を生成して一気呵成に挽回を図り、全体への影響（手空きメンバーの発生など）を小さくする、という方法がコストパフォーマンスが良いです。ちまちまやっていると傷口が深くなりやすいように思います。
また、そもそもなぜ実現できないスケジュールを作成したのか、というところから分析すれば往々にして、お客様の圧力が強かった、自分（PM）の能力を会社に認めて欲しかった、スケジュール作成者の能力不足、など根本的な原因が見つかってくるでしょう。
そのような原因まで分析すると、その後工程のスケジュールがどれくらい危険であるかを評価できます。それにより、以後の工程が円滑に進まなさそうなことが判明した場合は先手を打って軌道を回復していかなくてはなりません。
＃7：ピッチを上げる
手戻りが少ないような場合に有効となります。どうも手戻りが出てしまいそうなプロジェクトでは、過去のプロジェクトを参考にして『手戻り率』を前もって組み入れておくことで予想外の遅延というリスクを低減することができます。手戻りがなかった場合にリソースが余分になってしまいますが、手戻り時が発生した場合にはリスケジュールなどに大きな体力が発生しますので、どちらが得になりそうかを判断して採用を検討します。
また、手戻りがメンバーに与える影響として、自分のコードが日の目を浴びずに「廃棄」になることにショックを受ける人は少なくありません。特に新入社員が担当する部分はできるだけお蔵入りにならないようなところを選んであげるのが良いでしょう。
＃8：スコープの変更を阻止する
PM以外のメンバーがスコープ変更を行なえないようルール化する、という話はよく聞きますが、効果抜群だったということはあまり聞きません。多くの場合、メンバーは「今これをやっておけば後から自分（または他人）の作業が減るのではないか、」という善意から作業を増やすからではないかと考えています。誰も自分の仕事を増やしたいとは思いません。後で言われるより今言われたほうがまし、とトータルで見てスコープ変更に応じるケースは多いのではないでしょうか。となるとルールがあっても水面下でスコープ変更が起きてしまうことがあります。
後から言われそうなエラーチェックを追加したり、ユーザインタフェースを基本設計から逸脱しない限りで改善したりと、ある程度の「カイゼン」はバッファとして想定しておくことが望ましいでしょう。メンバーが「こういう風にやったほうがよいのではないか」という相談をしてきたら、そのやる気を買って修正を認めるのが親分的存在としての務めではないでしょうか。もし大きな影響が出そうであればもちろんやめてもらうことも必要になりますが、良かれと思って言ったのに納得感が得られないような断り方をされると気持ちが落ち込んでしまうでしょう。「こっちが言ったこと以外はやるな」という姿勢では連帯感が生まれません。沈没寸前の泥舟をこぎ続けなければならない場合はともかく、できるだけこういった殺伐とした雰囲気を作りたくないものです。
＃9：プロセスを改善する
まずは内部的なプロセスについて。プロジェクトを進めながらプロセスを改善できるなどという話を聞いたことがありません。できたらすごいと思います。
走り始めたプロジェクトでプロセスを改善することはできないと考えたほうがいいです。複数プロジェクトマネージャを束ねるプロジェクトオーナー的な立場の人、（部長あたりの人）が危険を察知して、PMサポ的な人を投入し、新鮮な頭で問題点を探し出すなどしなくては改善を望めません。
「今のこのやり方はこうしたら楽になるんじゃないかな」と思いついたのに口に出さず、実行もしない人はいません。恐怖政治が敷かれていて「お前の権限じゃない。」というセリフが横行していれば別ですが、そういった環境は少ないはずです。なのに改善が難しいのは、その集団でのやり方が確定してしまったら、ついそれが良い方法なのだと思い込んでしまうからではないでしょうか。そうなってしまった場合は、外からの人間に指摘してもらうのが最も早くそこから脱出する方法であると思います。
外部的なプロセスについて。例えば全社的な品質管理活動により、指定様式で資料を作成するなどの作業があり、それが高負荷になる場合があります。それはそれで全社として見れば大きなメリットを産むものでしょうから、「体力をやりくりできないので免除してください」なんていうお願いはしないほうがよいと思います。ただし負担が大きい場合は「負担です」という現場からの実感を伝えておくべきだと思います。
こういった作業は突発で沸き起こる事は少ないため、プロジェクト開始時におおよその所要体力を想像して見積もっておく事ができそうです。（情報セキュリティ関連については強化の一途を辿っているので予測しづらいかもしれません）
＃10：作業のスコープを縮小する
遅れがどうにもならない場合、ともすると「このままじゃリリースできない」などとリリースを人質にお客様に泣きを入れる以外に選択肢がないような状況もあるでしょう。まったくお客様の過失なくそんな事態になることは少なく、だいたいはリリース前倒しか、仕様変更か、機能追加か、今月中には上司の決裁降りる降りる詐欺か、担当者が異動してしまうあたりが真の原因になっており、そうなるとお客様もしぶしぶ承諾してくれるということになります。
こういった場合一方的な要求だけでは通らなくて、バーターを求められることもあります。例えば本来のリリース日を延期し、一部ユーザを対象に限定機能によるパイロット運用期間を設け、その運用を見極めて残機能の開発に着手すれば本当に必要な機能、そうでない機能の整理がつき、トータルとしてよいものを作れるかもしれません。そのようなポジティブな交換条件を出してお客様の満足度を少しでも落とさないようにします。
以上、10の心構えでした。