エンジニアとしての経験が積まれてくると、参画したプロジェクトがデスマーチと化すか否かをかぎ分ける能力が付き、ある程度「鼻が利く」ようになってしまうことがあります。それでもプロである以上、いい加減なところでプロジェクトを抜けるわけにはいかず、溜息とともに腹を括った経験はありませんか？高確率で失敗するとわかっていても、仕事を続けなければいけないのは非常に苦痛ですよね。
そこで今回は、デスマーチ化を予感したときにメンバーとしてできる対応をまとめてみます。
むやみに人員を投入しない
これはチームメンバーと言うよりは、チームリーダー以上のポジションに当てはまります。
予期せぬ事態、不具合、仕様漏れなどが発生したときに、むやみに人員を投入して精神の安定を図るというタイプではありませんか？
確かに工数管理表やWBSのようなドキュメント上では、つじつまを合わせることができます。
しかし実際にはプロジェクトの途中から予定していない人員を投入することは、数字以上のコストを伴うのです。
投入された人員が、参画してすぐにプロジェクトの流れをつかめるとは限りません。
席の確保、ツールのインストール、入館の手続きなどの雑務に加え、現場ルールの周知や引継ぎ、実際に担当するシステムについての知識などを一から覚えてもらう必要があります。
これらをほぼ単一でこなせるのであればまだ良いのですが、多くの場合、専任でサポートする人員が必要となるでしょう。
ただでさえ不足しがちな人員が一層不足し、なおかつチーム内に混乱を招くことにもなりかねません。
不足の事態に対応するためには、まずタスクの選別や人員の再配置によって穴を埋めることができないかを検討し、最終手段として人員の補充を考えるようにしたいところです。
「瞬発力」よりも「持続力」を意識した対策を
「なんとか今週を乗り切れば」「単体テストさえ終わってしまえば」などと、目前の「ヤマ場」だけを意識した対策は控えるようにしましょう。
何故ならばそのヤマ場の次には高確率で「より困難なヤマ場」が待ち構えているからです。
一旦崩れだしたプロジェクトは、一朝一夕に立ち直ることはなく、長い時間をかけて傾きを矯正していくほかありません。
どんな手法を用い美辞麗句を並べても、かならず複数回の修羅場が訪れるもの。
あらかじめヤマ場は何度か来ることを意識し、瞬発力よりも持続力を意識した対策を心がけてみてください。
例えば、目前のタスクは無理に成功させず、
対応時間を稼ぎながら次のフェーズに備えるという立ち回りも有効になるでしょう。
PM・PLにしっかりと「無理」を伝える
「やります」「できます」は上に立つものにとって非常に嬉しい言葉です。
メンバーもできることならお世話になっている上役を喜ばせたいと感じているもの。
しかし時にははっきりと「無理」を伝えて、自分の身とプロジェクトを守ることも大切なのです。
自分自身もプロジェクトを支えている貴重な戦力であることを理解し、自分の身を守ることがプロジェクトを守ることにもつながるという意識を持ってみてください。
そのためには、心身の健康を保ちつつ走り続けられるラインを見極め、しっかりと上司に報告しておくべきです。
信頼関係もコストのうち！周囲との関係を密にする
デスマーチ化するプロジェクトの多くが「コミュニケーションのコスト」を考慮していません。
コミュニケーションのコストとは即ち、信頼関係を築くために投入したコストです。
これが崩壊してしまうようでは、再度信頼関係を築くためのコストは投入できず、プロジェクトはジリ貧になってしまいます。
メンバー間、担当者間の信頼関係があってこそ、効率の良いコミュニケーションがうまれ、システムを構築する原動力となるのです。
デスマーチ化を予感したときこそ、メンバーとの協力体制をもう一度見直して、不測の事態に備えるようにしてはいかがでしょうか。
