この記事について
この記事はHamee Advent Calendar 2017の12月21日分の記事になります。
25歳のペーペーが社内のチーム再編成時に「ヤバそうなプロジェクトに即座に入って対応する人が欲しい」という要望から生まれたチーム…いわゆる"火消し"の栄えある1人目として配属されて、色々なプロジェクトに参加して思った事を書きます。
はじめに
僕が行っている"火消し"は通常のプロジェクトの枠組みからは外れています。
普通のプロジェクトだと「XXXができるプロダクトをYYYまでにZZZで作って欲しい」と明確な納期や目標が存在するのが普通だと思いますが、そういったものはありません。
「普段は管理系業務に重点を置きながら、火の手が上がったら有無を言わずに飛び込んでいく。」というスタイルといえば通じるのでしょうか？
当然ながら日常的にどこかが炎上しているわけではないため管理・マネジメント・ディレクション業務が主になってきます。
普段の作業比率で言うと開発業務が2、管理系が6、雑務2といった割合です。
エンジニアとして開発も行いますし、進捗管理の為のマネジメントもしますし、いきなりよく分からん会議に参加して意見を出しに行くこともあります。
そんな日々を過ごしてもうすぐ半年が経過しようとしているので、思ったことをつらづらと書きます。
本編
炎上した。しそうだったプロジェクトってどんなことしてた？
日々の進捗報告やKPT等の振り返りで「プロジェクトのゴール」を強く意識していなかった
日々の進捗報告をダラダラと続けているPJは炎上度合いが高いです。
例として「今日（今週）は何を作りました」。「これだけ進みました」という目下の作業の事"しか"口にしなくなると黄色信号です。
開発作業に当たる人らを管轄すべきリーダークラスの人がコレを言い出したらそろそろ火事になりそうな雰囲気になってきます。
これはプロジェクトのゴールのことを忘れている傾向の一つとして捉えています。
僕が思う対策
このパターンにハマるプロジェクトというのはゴールが不明瞭、大雑把なままスタートしているのではと思っております。
一言で言うとプロジェクトリーダーが本来の業務を行えていない状態です。
「別に良くない？作業に集中しているってことでしょ。いいことじゃん？」と思っている人もいるかもしれませんが、全体から見たら小さい物事の作業に集中してしまった結果、貴重な作業リソースを消費して作業全体の遅れを招く傾向が非常に高いように思えます。
プロジェクトリーダーというのは強い権限を持っているので、その権限を存分に使ってプロジェクトリーダー本来の業務を行えるようにすると上手く行く傾向があるように感じております。
スコープが異様に広がっていき、その広がり方に際限が無く、見直す時間を取らなかった
そこそこ大きな案件を進めていく際に、要所要所で現時点で完成している成果物を関係者に見せる場があると思います。
そのときに追加の要望があった際にうっかり良い顔をしたくなるのか、そのプロダクトで目標としている事以外の内容をそのまま受け入れてしまうと大変な事になります。
一度受け入れたものを「やっぱり無理です」と小さくすることは、その提案を最初から拒否する事以上に困難です。
また、その開発作業を行っている開発者に対するインパクトも大きいです。
作業をするにあたり十分な時間が確保されていたとしても、「作業が増えた」事実が突きつけられます。このインパクトはやる気を削ぐには十分です。
多かれ少なかれ時間が立てば立つほど現場は疲弊していく為、当初のパフォーマンスを保てなくなり作業が遅れ始める切っ掛けとなります。
僕が思う対策
これは事前に相手方に「何か要望を新しく入れる際はリスクがある」ということを伝えておかないといけません。
その上で最初の要件定義に全力を尽くすべきで、「やってみないと分からない」という作業は必要最低限に留めたいです。
もし、大きく変わり過ぎてしていて目標としている事そのものが変わってしまっているのであれば、一度作業の手を全て止めて全員でプロダクトのことを考え直す時間を確保したほうが有意義だと考えています。
目標が変わってしまっているのであれば、今作っているプロダクトは最悪の場合不要となってしまうことがあるからです。
エンジニア・プロダクトリーダー業務・ディレクションを一人でやっている人がいる
俗に言うプレイングマネージャーというやつです。
当然ながらその一人で行っている人の作業がどれか1つでも遅れた時点で全てが遅れ始めます。
殆どの場合、遅れてしまったスケジュールに間に合わせようとするために各関係者との調整、時々の方針決め、コーディングetc...全てが半端になった結果そこに関わった全員が遅れ始めるという悪循環が始まります。
この場合、不思議と開発業務に重点を置くようになっていきます。
自分だけ作業が完結する事が多いので気が楽なのかもしれません。
僕が思う対策
なんだかんだ言って、エンジニアの仕事って楽しいです。新しい何かを手を動かして作る仕事はとてもクリエイティブです。
対してディレクションの業務は調整や管理ばかりで面倒なことが多いです。つまらないと感じる方が殆どだと思います。
人間、楽をしたい生き物なので作業がどんどんエンジニア寄りになっていきます。
日を追う事に進捗管理が疎かになってしまい、気がついたときには手遅れということになりやすいです。
エンジニアとしては優秀なんだけど、リーダーとしては…。と思われてしまう人はこの傾向が強く出ていると感じております。
僕自身プレイングマネージャーは超優秀な人しか無理だと思っていて、普通の人が兼任可能な作業はせいぜい2つまで（しかも、一方には半分も入れていない。）だと考えています。
一人プロジェクトをやっているのでなければ、なるべく他の人に作業を分担するようにして全てが破綻しないように心がけたいと思う次第です。
進捗管理が大雑把だった
よほど小規模な案件でないと明確なゴールが見えない事が殆どだと思いますが、設計段階で決めたゴールに突っ走っていくのは炎上の第一歩です。
ゴールだと思って一気に行っても途中でバテてしまう事も多いですし、ゴールが動いてしまったりするのが現実には起こります。
全部できあがってから最後に大きなチェックを行うと出戻りがあった際の被害が甚大で、やる気もごっそり持って行かれてしまいます。
僕が思う対策
作業全体を細かく区切ってその区切り毎に細かく切っていくのが良いと考えております。
大きな括りでも1週間や2週間程度の単位でチェックポイントを設けて、都度確認と修正を繰り返していくほうが進捗を目で追いやすく、進み具合からまだ大丈夫なのかピンチなのかを判定出来ます。
また、チェックポイントが多くなるので、仕様変更といった意図しない作業に関しても耐性を持てます。
チェックポイント毎での確認になるため出戻りは殆どなくなって、何かあっても単なる追加になるため作業難易度も精神的な負荷も楽になります。
最後に
僕が何かのプロジェクトに入る時は殆どの場合、担当者が炎上しきっていて消し炭になっている状況が多いのですが、本来は消し炭になる前や出火する前になんとかしたいものです。
炎上しないで無事に終わるプロジェクトというのは
- スケジュールの管理
- リソースの管理
- 要件の管理
この3つを徹底して管理しているのが共通点です。出来ることと出来ないことが切り分けをするためにも、この3つの管理は必要不可欠だと思っています。
炎上しないように事前に防ぐという意識を持ちつつ常に業務に当たろうと思う次第です。