プロジェクトメンバを不幸のどん底に陥れる、「炎上」を招かないためには、技術的観点だけではなく、マネジメントとしてメンバを管理することも重要です。
炎上とは
多角的要因によって、プロジェクトがままならない状況に陥ることを指します。その結果、プロジェクトメンバが揃って死への行進を繰り広げる「デスマーチ」が起こることもあります。
なぜ炎上するのか
先にも述べたように、炎上要因は非常に多岐にわたります。例を挙げてみましょう。
- プロジェクトマネジメントの失敗
- 度重なる仕様変更
- 設計の不足
- プロジェクトメンバの失踪
- 不慮の事故
- 天災
これらを防ぐために必要なことについて考えてみます。
炎上防止のために
マイルストーンの策定
適切なマイルストーンを敷いてください。
「何をいつまでにどこまでやればいいのか」というゴールが見えていないと、プロジェクトメンバは精神的に疲弊し、結果的に大幅なパフォーマンス悪化を招きます。
主目的は、「締切の可視化」です。メンバに明確なゴールを提示することにより、程よい緊張感をメンバに抱かせることができます。
ボトムアップ型の工数算定
トップダウンのスケジューリングは、管理者から見れば余裕を持った至極素晴らしいスケジュールに見えたとしても、実際の作業ではかなりの乖離を招くことがあります。
メンバひとりひとりにタスクを与え、計画してもらいます。
「自分で言ったのだから期日は厳守しないと」と、責任感を持たせることもできます。これは、プロジェクトにとって有益に働くでしょう。
コミュニケーション方式の策定
どのような方式でも構いませんが、コミュニケーションは重要です。
最低限、チーム間で相談できるような仕組みを考えましょう。たとえば、Slackや、軽い定期MTGを行うのもよいでしょう。
スケジュールの遅延を招かないためには、メンバが発する早期のアラートが何よりも大切です。
仕様変更のコストを見積もる
仕様変更を飲むことは容易ですが、それには大変なコストが伴うことをクライアントに説明します。
また、リスケジュールを検討します。急な仕様変更には、メンバのモチベーションを保つための工夫が必要です。
交渉が可能かどうかにもよりますが、もし交渉が不可能であったとしても、何かしらのインセンティブを用意しておけば、モチベーションの持続が期待できます。
属人化を避ける
担当範囲の属人化は、不慮の事故があった際に、確実にプロジェクトに不幸な結果をもたらします。
これは、一朝一夕では回復することのできないものです。情報共有は必ず行いましょう。
また、その日やったタスクは、必ずその日のうちにSCMにpushするよう、ルールを取り決めます。これは、翌日に何らかの理由で当人が現場に来られなくなった際に、他の人が無駄なく引き継げるようにするためです。
まとめ
今回は、技術面、管理面ではなく、チームのモチベーション維持のために必要なことをまとめてみました。
システム開発は、楽しくやりたいものです。特段、日本のシステム開発の現場は長時間労働となりがちですが、そういった職場環境にしないため、プロジェクトを成功に導くために、的確なプロジェクトマネジメントを行う必要があります。
もちろん、これだけでプロジェクト炎上を防げるわけではありません。そういった意味でも、プロジェクトマネジメントは非常に難度の高いものです。PMBOKなどの様々なマネジメント手法はありますが、最終的に作業を行うのは人間です。様々な面からの細かいフォローアップを忘れなければ、多少無理なスケジュールであれ、ついてきてくれる人は少なくないはずです。