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