プロジェクトが暗礁に乗り上げて進め方がわからなくなったとき、よくある対応について整理しました。
失敗がちらついたときこそ、プロジェクトマネージャーが力を発揮するときです。
数多くのプロマネが対応してきた基本のリカバリーパターンになります。
プロジェクトがうまくいかない時の対応方法
プロジェクトは、納期、品質、コストのバランスを保ちながら推進します。
すべてが完全に当初計画通りにうまくいくのであれば100点なのですが、なかなかそうはならないのが現実です。
いかに合格点でおさめてリリースするのかが、プロジェクトマネージャーやプロジェクトリーダーの腕の見せ所、です。
さて、プロジェクトがうまくいかないときですが、マネージャーとしてはやはり、プロジェクトを進める基本的観点を考慮して対策をうちます。
・納期
・品質
・コスト
今回は、それぞれの対応がどう行われるか見ていきます。
納期
納期への対応にしても、いくつかの方法があり、局面ごとにかわります。
基本的な考え方は２つです。
プロジェクトとして全体の計画をのばすか、段階的なリカバリーをかけるため一部を遅らせるかです。
要件検討、設計、製造等まだ後ろに工程が残っている場合は、一部のタスクだけ未完了のまま次工程に伸ばすということは、よくつかわれます。対策を打たずにやみくもに後ろに伸ばしてもプロジェクトとしてはスケジュール遅れが後ろに順番におくられるだけなので、実際には予定タスクをこなすために増員するなどの対策を打つ必要があります。
立上げ直前、ユーザテストなどの局面でリリースが厳しい場合には、後ろの工程でリカバリーをするわけにはいかないため、完全に立上げ時期をずらす以外にも、一部の機能の立上げを延期する、取りやめるなどの手段を取ります。
いわゆる、段階的立上げ、部分立上げです。
政治的にどうしても立ち上げないといけないプロジェクトなどは、段階的な立上げはよく耳にします。
プロジェクトが遅延してどうしようもない時の一つの手段として、ステークフォルダーと調整する価値があると思います。
品質
品質面では、４つの側面での品質があります。
・要件品質
・機能品質
・性能品質
・運用品質
要件品質とは、要件書や仕様書等、お客様（ユーザ）と合意している内容でシステムとして実運用に耐えられるかどうかということです。
この側面での品質の悪さは、ウォーターフォールがたのプロジェクトの場合は、プロジェクトの最終局面で発生することがあり、リカバリーが困難になるケースが多々あります。
ただし、要件書や仕様書そのものが運用にあわないということですので、ユーザ側ならユーザ側と責任の所在をはっきりさせてプロジェクトをどうするか、調整することになります。
このようなケースに備えて、要件書やユーザの操作等を定義した外部仕様書は、ユーザ承認をもらっておくことが重要です。
機能品質で問題があるとは、いわゆるユーザに使ってもらう機能そのものに欠陥があるということです。
バグがのこっていて、システムの出力結果に誤りがあるケース、特定の操作をするとシステム的に不安定でシステムエラーを起こしてしまうケースがあります。
いずれにしても品質そのものは直す必要がありますが、 プロジェクトの立上げ自体は品質に対して優先順位をつけて、致命的な欠陥がない場合には立ち上げるという選択肢もあります。
性能品質面については、いわゆるオンライン画面の場合には、レスポンスが遅いということですが、頻繁に使用しない機能の場合には優先順位を下げて対応を後回しにするということは検討すべき方法になります。
また性能の場合にはバッチ処理についても考慮すべき必要があります。
朝までかかっても終了しないというケースの場合には、実運用が耐えられないときは最優先で対応が必要ですが、昼間の処理と同時並行で流せるという場合には、改善は後回しにしてリリース後の改善という形で対応することも可能です。
最後に運用品質です。
これは実際にユーザーが運用する時の機能が不足しているとか、障害検知や通知などの運用の仕組みがまだ織り込まれていないなどの問題です。
当初から運用については考えられていなかったというケースも想定されますし、プロジェクトとしては状況を踏まえて対応していく必要があります。
運用面の機能に関しては実際にどのタイミングで必要なのかということを明確にして、必要なタイミングまでの開発スケジュールで調整することで、リソースを他にまわして対応することも可能になります。
いずれにしても、品質に問題がある場合には特に、品質の状態を明らかにして、プロジェクトを立ち上げるか延期するかの立上げ判定会を実施して、ステークフォルダー間での認識をあわせておく必要があります。
コスト
コスト面の対応としては大きく二つ、増員で対応するか、設備を増強するかです。
機能面での品質や納期遅延に対しては、増員をするケースが多くなりますが、性能面での問題がある場合には増員をするよりもハードウェア設備を増強することにより劇的に性能が向上する場合があります。
増員対応にしても、設備増強にしても気をつけるべき点があります。
増員対応で気をつけること
増員のタイミングと要員スキルは注意が必要です。通常優秀なメンバーの追加は時間がかかるものです。
タイミングがあわない場合は、既存のプロジェクトメンバーの実施タスクの中で、習得時間がかからないタスクの担当を別タスクにまわして新規メンバーとたまつきするなどの対策が必要になります。
また、望ましいやりかたではありませんが、増員がそこまで必要でない場合には、既存メンバーの残業や休日出勤での対応もよくある対応になります。
また、納期が厳しい場合の増員については、並行で実行できるタスクを考慮し、多重度をあげるなどの検討が必要です。
実際の増員については、個々のメンバーを採用する以外にも、必要なスキルを所有している会社や組織に応援を依頼するという手段があります。
技術的な課題でプロジェクトが停滞している場合には、そのスキルをもつメンバーを外部組織に頼った方がプロジェクトの立て直しに有効な場合があります。
性能向上のための設備増強で気をつけること
性能のボトルネックになるリソースを調査して、ボトルネック部分に対して増強する必要があります。
処理性能が遅いために性能がでないのか、メモリが少なくてディスクアクセスが発生し遅いのか、ディスク性能が遅くて性能がでないのか、やみくもに設備投資をしてもボトルネックになっている部分が増強されないと性能改善にはつながりません。
設備増強の場合は、技術者によるボトルネック調査と検証を事前に実施することがポイントになります。
プロジェクトで困った時
これまでの自分の経験やノウハウをもとに、プロジェクトのコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。
もしプロジェクトでお困りの時は下のリンクより、ご相談ください。
