タクシーアプリ「GO」の iOS アプリを開発している今入庸介です。
本記事では、見積もりと実績の乖離を可視化し、見積もりの精度を高めるための取り組みについて紹介します。
タクシーアプリ「GO」の開発では、数週間程度で終えられる小規模なプロジェクトから、半年以上かけて開発する大規模なプロジェクトもあります。
開発を進める中で、定義された仕様を元に、エンジニアが開発工数を見積もる工程があります。それを元に立てられたスケジュールにしたがって開発を進めるのですが、プロジェクトの規模が大きくなればなるほど計画通りに進められないといった事象が続いていました。
この課題を改善するための一つの施策として、見積もりと実績を可視化し、プロジェクトが完了したあとに振り返られる仕組みを構築しました。
本記事では、その仕組みについて紹介し、どのようにして習慣化をしたのか、見積もりと実績の乖離から得られた気づきについて紹介します。
冒頭でもお話したとおり、チーム開発をする上で計画通りに進められないという悩みがありました。
計画通りに進められないことで、以下のような課題が生まれます。
複数のプロジェクトが同時並行で進められている状況下で、開発の遅延は様々な悪影響を及ぼします。
ユーザに対して新機能の提供が遅れたり、一部妥協した価値の提供になってしまうこともあるので、可能な限りこういった状況は防がなくてはいけません。
こういった状況が生まれる原因はどこにあるのでしょうか。いくつか思い当たるものを挙げます。
どれもチーム開発をしていると起き得る課題で、完璧に対処することはできないでしょう。
特に、見積もりやスケジューリングについては、最適な解を求めることが非常に難しいです。
工数を低く見積もりすぎると、日々の開発に高い負荷がかかってしまいますし、余裕がありすぎるスケジュールを立てると、それはそれで良い状況とは言えません。
しかし、より精度の高い見積もりやスケジューリングを目指すことは可能だと思います。
昨年までのタクシーアプリ「GO」の開発では、見積もりに対して実際の稼働がどうだったかといった情報がなく、見積もりと実績に対する乖離を知ることができない状態でした。
見積もりの精度をあげるため、そして最適なスケジューリングを行うために、見積もりと実績を可視化する取り組みを今年から実施しました。
その仕組みとそこから得られた効果や気付きについて次に紹介します。
年始から8ヶ月に及ぶ大規模なプロジェクトがあり、その中で見積もりと実績の記録を毎日行うことにしました。
タクシーアプリ「GO」では、タスク管理に Asana を利用しています。Asana のカスタムフィールドを利用して「見積もり」と「実績」の欄を各タスクごとに用意しました。
「見積もり」は、見積もり工程の段階でチームメンバ内で合意がとれた見積もり時間が記入されています。
見積もり作業は Google スプレッドシート上で行われ、開発開始前に CSV としてダウンロードして Asana にインポートすることで、タスク内容および見積もり時間を自動作成できるようにしました。
「実績」は、各タスクごとに費やした実際の開発作業時間を指します。
開発作業時間には、実装はもちろんのこと、そのタスクをやる上で調査した時間や、Pull Request 作成時間、コードレビューの指摘事項の修正時間などが含まれます。
実績値の入力は各エンジニアが毎日作業を終えた段階もしくは終業前などに手動で入力しました。
タスクに対して見積もりと実績が入力されることで、プロジェクト内における「残タスクの見積もり時間の合計」と「開発に費やした作業時間の合計」を求めることができます。
それらの最新状態を日々記録していくことで、現状の進捗をバーンダウンチャートとして可視化できるようになりました。
Asana でのタスクの管理の仕方として、タスクの状態を以下の 3 つに分類しています。
上記の状態に対する見積もり合計時間と、各メンバごとの実績の合計時間を割り出すことでバーンダウンチャートとして可視化できます。これらの情報は Asana の「ダッシュボード」を使って確認できるようにしました。
各項目をスプレッドシートに毎日転記すればバーンダウンチャートが作られていきます。
タクシーアプリ「GO」の開発では、毎週バックログリファインメント MTG を開催しており、その場でプロジェクトの進捗具合を確認していました。
バーンダウンチャートの導入により、数値を使って明確に現状を伝えることができ、プロジェクトの現状の把握が行いやすくなりました。
残タスクの消化具合が鈍化してきていることがグラフから読み取れるようになったので、今までより早い段階で手を打てるようになったと思います。
日々バーンダウンチャートを作成するために、見積もりと実績の時間を手作業で転記していたのですが、以下の課題が生まれました。
上記を解消すべく、Asana API と Google Apps Script を利用して、自動的に毎日のバーンダウンチャートを作成する仕組みを構築しました。
自動的に取得した情報は、バーンダウンチャートのシートとは別で管理し、バーンダウンチャートのシートから参照する形で情報を反映させています。
バーンダウンチャートの作成を自動化したことで、属人化も防げ、長期的に低コストで運用することが可能になりました。
Asana API を使ってバーンダウンチャートを作成する仕組みについては以下の記事が参考になります。
AsanaとGoogleスプレッドシートを連携して、バーンダウンチャートを自動生成する
見積もりと実績の入力について、プロジェクトにかかわるエンジニア全員に日々の記録をお願いしました。
毎日漏れなく記録しないと、バーンダウンチャートによる進捗管理が正確に行えません。また、見積もりと実績の乖離をあとから振り返る際にも正しい情報が得られなくなります。
実績の入力を習慣化するために、いくつか取り組んだことがあるので以下に紹介します。
なぜやっているのか納得していない状態で習慣化させることは難しいでしょう。
面倒な作業をお願いすることになるので、きちんとその背景や現状の課題感、得られるであろう効果の説明をチームメンバ全員に対して行いました。
また、プロジェクトの途中から新しく参加するメンバに向けて、都度説明をすることになるだろうと予測し、上記についてはドキュメント化していつでも参照できる形にしておきました。
本記事で紹介した取り組みの中で、エンジニアが各自のタスクに対して何時間費やしたかを記録していく作業が生まれました。これは毎日行わなければならない作業です。
この作業自体に時間がかかるようでしたら長続きはしません。なるべく手間がかからない仕組みになるよう心がけました。
結果として、各エンジニアが日々行うべき作業は、『Asana の「実績」というフィールドに費やした時間を入力する』これだけで完結する仕組みとなっています。
実績に入力する時間は 0.5 刻みでよいものとし、より詳細に記録したい人は細かく入力するといった自由度を持たせました。(自然とそうなっていました。)
完璧を追求しすぎると負荷がかかってしまい、継続的に行うことが困難になるでしょう。
また、入力内容の正確さは問わないように心がけました。毎日バーンダウンチャートを眺めていると、一部のメンバーの昨日の実績が思ったより少ないなと感じることがあります。
「MTG もあまり入っていないし、ハドルで聞いた内容だとかなり時間をかけたような気がするけど……」と思うこともありましたが、厳しく監視しすぎると逆効果になりかねないと思い、入力された実績の正確さについては問いませんでした。
入力された実績の正確さを求めることは次の課題とし、まずは実績を入力しているかどうかについてフォーカスし、毎日記録することの習慣づけを大事にしました。そのため、実績が未入力(昨日と比較して実績の合計値の差分が 0 )のときは、個別に連絡して入力の依頼を徹底しました。
この取り組みを実施した当初は、(自分も含め)入力漏れがかなりありましたが、1ヶ月ほどで入力漏れはほとんどなくなり、習慣化できるようになったと感じました。
無事に8ヶ月に及ぶ大規模プロジェクトは完了し、すべてのタスクに見積もりと実績の時間が入力された状態が生まれました。これで見積もりと実績について詳しく振り返ることができます。
以下に、どのように振り返ってどういった気付きが得られたのかを紹介します。
Asana にはプロジェクトごとにタスクとその詳細情報を CSV として出力させる機能があります。
これを利用し、各メンバーごとに取り組んだタスクの一覧を割り出しました。その後、見積もりと実績の乖離がどれくらいあるかを散布図で表現しました。
赤い線が見積もりと実績が一致するラインとなり、これに近づけば近づくほど見積もりの精度が高かったといえます。逆に、このラインから離れているものは見積もりが甘すぎた or 厳しすぎたといえるでしょう。
上記を元に、エンジニア内で振り返り会を実施し所感を集めました。
また、見積もりの工程で各自どのような作業をしているのか気になっていたので、お互い共有してみました。
以下の質問をベースに議論をしました。
そして、計画通りに開発を進めるためのアイデア出しやその種となる意見を募りました。
エンジニア内で行った上記の振り返りの内容は、今後開発チーム全体として改善していけるよう、PdM や PjM、デザイナーなど非エンジニアの方にも共有しています。
上記の振り返りから得られた気づきや課題を一部紹介します。
見積もり工程では、そのタスクの実装にどれくらい時間がかかるのかを検討します。 しかし、そのタスクをこなすためには実装以外にも以下のような作業が発生します。
複数人で大規模なアプリを開発していると、他にも様々な作業が発生すると思います。 こういったことがあるため、見積もり段階でバッファを積むようにしています。
今までは一律でバッファを積んでいましたが(見積もりの合計時間に一定倍率をかける)、タスクごとにそのバッファの量は変わるだろうという意見がありました。
より精度を高く見積もるために、バッファの扱い方を工夫することは、一つのアイデアとしてよさそうだと思います。
要件定義や UI、API の仕様などが明確でないときちんとした見積もりを行うことは難しいです。
どうしてもざっくりとした見積もりになってしまい、その精度は低くなる可能性が高いです。
しかし、仕様を完璧に定義してから見積もることは現実的ではありません。一部の仕様やデザインの検討は、開発作業と並行して行われることもあります。
前述のバッファの話と繋がってくるところもありますが、こうした不確定要素に対してどのようにアクションすればよいのか、今後議論していけたらなと思います。
本記事ではタクシーアプリ「GO」の開発における見積もりと実績の管理手法について紹介しました。
新しい取り組みの習慣化や低コストでの運用など、本記事で紹介した仕組みが参考になれば幸いです。
見積もりと実績の管理を行うことで、今まで見えていなかった気づきや課題を発見することができました。
今後も継続して行うことで、開発フローのブラッシュアップやチーム開発におけるパフォーマンスの向上を目指していきたいです。
興味のある方は 採用ページ も見ていただけると嬉しいです。
Twitter @mot_techtalk のフォローもよろしくお願いします!