はじめに
年明けから従事しているプロジェクトで、初めて開発チームのマネージャー的な役割を少しだけ担うこととなりました。
社の方々に多大なサポートをいただきながら、自分なりに考えてなんとかやってはいるものの、マネージャー的役割が初めての経験ということもあり色々と失敗しました。
この失敗を次に生かすために、失敗したこととそこから学んだことをまとめたいと思います。
ちなみに、以下のような意味合いで言葉を使っています。
マネージャー的役割
プロダクトオーナーから開発しているアプリの方向性を聞き、それをチームが取り組めるタスクに細分化して、それを見積もる。
他のチームとの窓口的な役割を担い、開発チームが開発を進めていけるようにする役割のことを指しています。
見積もり
細分化されたタスクがどれくらいの大きさなのかを考えて可視化する。そして、それを元にスケジュールを引くまでを、今回は見積もりとしています。
見積もり関連で最近失敗したこと
1. 設計タスクを見積もりに含めていなかった
今回、新機能開発を行っていますが、その仕様や設計(DB設計など)を決めるということをタスクを洗い出した時に含めていませんでした。
そこまで大きな機能ではなかったため、そこまで設計に重きを置いていなかったというのが見積もりをした時の考えでした。
しかし、実際には思いの他設計タスクに時間がかかってしまい、コーディングに着手するのが遅れたという失敗でした。
2. 自分がマネージャー的な役割を担っているにも関わらずに、普通に手を動かす時間がある前提でスケジュールを引いてしまった
上記の「マネージャー的役割」に記述したようなことをやっていたのですが、それにも関わらずに普通に手を動かせるという前提でスケジュールを引いてしまいました。
具体的に説明しますと...
自分が「マネージャー的役割」を担っていない状態で1日に1ポイントを消化できるとした時、今回はそうでないため1日に0.5ポイントくらいしか消化できないと考えるべきでした。
しかし、マネージャー的役割を担うことの負担を全く勘定に入れず、「このタスクは3ポイントだから3日くらいで終わるなぁ」という感じでスケジュールを引いてしまいました。
その結果、私が担当するタスクの完了が想定よりも大分遅れてしまいました。
3. スケジュールを引いた時の想定から大きくずれ込んでいることを早めに相談することができなかった
今回の失敗として、これが1番大きい失敗だと思います。上記の1・2のようなことがあり、当初引いたスケジュールよりも遅れてしまっている状態でした。
これには薄々気づいていたのですが、「自分が頑張ればなんとか巻き返せるのではないか」と考えてしまい、早めに相談するということができませんでした。
その後、当初引いたスケジュールとのギャップが大きくなった状態で、ようやく相談してプロダクトオーナーに色々と調整していただくという運びになってしまいました。
4. プロダクトオーナーにとって分かりやすい見積もり表を作ることができなかった
プロダクトオーナーとスケジュールについて話し合う際に、自分が作成した見積もり表は洗い出したタスクが細かくなりすぎていて、中期的なマイルストーンが伝わりづらくなってしまいました。
以下の例のような感じです。 ただ、以下はちょっと細かすぎて実際のタスク表とは少し異なりますが、ニュアンスが伝わればと思います（実際のタスク表を一般化して書くのが難しかった...）。
例1
| タスク | ポイント |
|---|---|
| 新機能の開発に必要な gem 〇〇を入れて設定する | 0.5 |
| 〇〇 model を追加 | 0.5 |
| 〇〇 Controller と View を追加 | 1 |
| CSS を当てる | 2 |
| .... |
例1のような見積もり表では、同じチームメンバー間ではやるべきことが共有できるのですが、プロダクトオーナー目線ではここまでタスクが細かいと中長期的なマイルストーンは把握できないということでした。
このように、プロダクトオーナーや開発チーム以外の人に分かってもらいやすい見積もり表を作ることができませんでした。
失敗から学んだこと
仕様や設計が固まっていない場合は、それを決めるタスクを切って、しっかり時間をとる
今回の仕様決めや設計は、諸事情あり開発チームだけで完結できるものではありませんでした。そのため、仕様設計に関わる人が多ければ多いほど、しっかりとそれらを決める時間を確保するということが必要だと学びました。
また、開発チームで仕様や設計の草案を練ってAさんにレビューしていただき、それを直したものをBさんにレビューしてもらい...というような形で仕様・設計決めをやってしまったことも改善すべき点でした。 仕様・設計に関わる人を一気に集めて、その場で議論して、固めてしまうというやり方が時間短縮のためには必要でした。
マネージャー的な業務をする場合は、自分のコーディングにおける生産性は半分以下だと考えてスケジュールを引くこと
マネージャー的な業務をしていると、思った以上にコーディングに時間が取れなかったり、コーディングしていたとしても集中して取り組むことができませんでした。
そのため、マネージャー的な業務をする場合は、通常時の半分以下の生産性になってしまうと考えてスケジュールを引くことを学びました。
当初のスケジュールの想定通りにいかないと少しでも感じた時点で相談すること
今回の私のように、スケジュールとのギャップが大きくなってしまった段階で、相談するとプロダクトオーナーや他の人も打てる手が限られてしまうということを体感しました。
今回の場合は、社のエンジニアの人にサポートに入っていただいて、なんとかギャップを小さくできました。しかし、早めに相談することで、スコープや納期を調整してもらうという手段も取れたかもしれません。
そのように、時間と共に打てる選択肢少なくなってくるため、少しでも想定通りにいかないと予感した時点で相談するということが大事なのだと学びました。
誰に説明するかを考えて見積もり表を作る
4のように、細かすぎるタスクを切ってしまうと開発チーム以外の人には一気に伝わりづらくなると感じました。 そのため、見積もり表を作る場合は、「誰に見せるもの」「なんのために見せるもの」なのかということを考えて見積もり表を作る必要があると考えました。
具体的には、今回の場合は「プロダクトオーナー」に対して「作るもののスコープや納期を調整するための議論をするため」に見積もり表を見せるという状況でした。
そのため、例1のような細かすぎるタスクの切り方だとマイルストーンが把握しづらく、あまり議論できないということが問題でした。
よって、中項目を作成するなどして、その中項目がどれくらいで終わりそうかということが伝わるようにする必要がありました。
例2
| 中項目 | タスク | ポイント |
|---|---|---|
| 新機能開発のための準備（0.5 pt） | 開発に必要な gem 〇〇を入れて設定する | 0.5 |
| 新機能 A の開発（3.5 pt） | A model を追加 | 0.5 |
| A Controller と A view を追加 | 1 | |
| A 機能に CSS を当てる | 2 | |
| 新機能 B の開発 | ... | ... |
上記のように中項目を設定して、「その中項目がどのくらいで終わりそうか」「その機能はいつまでにできている必要があるか」「だから、スコープ・納期・人員を調整しよう」というような話ができるような見積もり表を作っておくべきでした。
まとめ
今回初めてマネージャー的役割を務めさせていただいて、以下のような失敗をして、学びを得ました。
- 設計タスクを見積もりに含めていなかった => 設計タスクを見積もりに含めること
- 自分がマネージャー的役割でも、普通にコーディングを進められると思ってスケジュールを引いた => マネージャー的役割をやるのなら、自分の生産性は半分以下であると考えてスケジュールを引くこと
- スケジュールから大きく遅れていることが分かった段階で初めて相談した => 遅れることを予感した段階で相談すること
- 細かすぎる見積もり表を出してしまった => 誰に見せる見積もり表なのかを考えて、見積もり表を作成する
同じ失敗は2度しないように、今回学んだことを次の機会には生かしていきたいです。