とあるプロジェクトにヘルプで入ったときのふりかえり - 理由はそのうち考える

とあるプロジェクトがトラブルに巻き込まれ、マネジメントの役割でヘルプに入ることになった。そのためここ２ヶ月ほどはバタバタしていたが、漸く終わった(落ち着いた)のでゆるくふりかえっていく。

基本情報

ヘルプメンバー含めて10人ちょっと(半数以上がヘルプメンバー)
作業場所はバラバラ
不具合改修メイン
期日が決まっている

準備など

まずはじめにRedmineで専用のプロジェクトを作り、急造(期間としては2日くらい)で開発プロセス・導入手順・進捗管理方法などをまとめた。テンプレートは社内にあったので内容を埋めるプラスアルファで済んだのは良かった。イチから考えていると結構時間がかかるので、こういうテンプレートがあると立ち上がりが段違いに感じた。また並行してヘルプメンバーの選定と調整、キックオフのための段取りをした。幸いだったのはヘルプに入ってもらえる人全員に快諾をもらえたこと。断られると次の手に困る状況だったので助かった。それから専用のチャットグループを作ってコミュニケーション手段やルートを確立した。

ヘルプメンバーがなるべく速やかに立ち上がれるように、開発用の環境も事前に可能なところまでは構築してVMで配布できるようにしたり、wikiにドメイン系のナレッジを書き込んだりしておいた。

感じたことなど

良かった点

色々なプロジェクトからヘルプに入ってもらったので、面識はあるが普段あまり接点のない人たちとの間で交流することができた。イメージ通りの人や意外な一面を見せる人など、作業を通じて色々な面を知ることができたのは良かった。他にも普段のプロジェクトとは異なる作業内容から刺激を受けた人もいたのではないかと思う。当初はどうなるのかと不安があったが、なんとかやりきったという達成感が大きい。
進捗状況の見える化には消化チケット数によるバーンダウンチャートを使用した。先の予測を立てたり状況を報告したりするのが行いやすかった。実績に基づいていると大体これくらいで進捗しそうだなというのが感覚としてわかる。開始直後や度々ペースが悪い時期があったが、早い段階で気づくことができリカバリーもできた。

気にしていたこと

開始序盤はコミュニケーション周りには注意を払っていた。チームとしても急造だったので、やりとりにはなるべく入るようにしてコミュニケーションが止まらないようにしていた。

改善点など

チームビルディングが不十分だった。チームとして未熟な状態なので、テキストメインのコミュニケーションだと認識を合わせるのが難しいときもあった。もっと積極的にZoomを使うなどしてもよかったかもしれない。また期間中は負荷が高い状態が続いた。計画時点では考慮していたものの、やはり実際に動き出すと目標を達成するために負荷をかけざるを得なかった。そのため工数的にも実績が予定をかなりオーバーすることになった。QCDでいうところのQとDを優先していたのでいたしかたない点ではあるのだが、できることならもう少し楽にやりたかった。それでもなんとかやりとげることができたのでメンバーには感謝しかない。

あと作業中に別件でチケットが増えたり客先レビューのフィードバック対応など、いくつか予測できなかった点があった。事前に知ることができていればもう少しやりようがあったかもしれない。

事前の察知が重要

今回の件についてはヘルプに入る時点でこうなることがある程度予想できたので、対応内容の改善というよりもどうやったら初めから負け戦状態に陥らないか、もっと早い段階で気づくことはできなかったのかを考える必要がある。個人的には普段から状況を把握できるような仕組みづくりが重要だと考えている。一応社内に定型的な報告の仕組みはあるがあまり活用できていない。そういうのも大事だが、もっとゆるい感じで、雑談でもそういった話ができるような雰囲気にしていければと思っている。