チームにアジャイル開発を導入し、開発スケジュールの見積もり精度を上げるためにやっていること
こんにちは、鉄棒です。ナビタイムジャパンで『auナビウォーク』の運用を担当しています。
今回お話する内容と対象読者
KDDI株式会社とナビタイムジャパンで運営する『auナビウォーク』アプリをリニューアルするというプロジェクトにおいて、アジャイル開発を導入しました。開発期間を正確に見積もるためにストーリーポイントを活用したので、その話をしたいと思います。
本記事は、多少アジャイル開発の基礎知識があり、これから導入したいと考えている方を対象にしています。
漠然と感じていた課題
以前から開発プロジェクトを進めるにあたり、事前の見積もりよりも多くの開発期間がかかることがあり、見積もりの精度を上げたいと感じていました。
開発の見積もりと言うと「人日」での見積もりをイメージされる方も多いかと思います。一人が一日働いた場合に発生する作業量を「一人日」として定義し、開発タスクそれぞれの人日を算出することで、開発にかかる全体期間を求めることができます。
私もこのやり方を行っていましたが、開発メンバーの能力により一日でこなせる作業量が異なるため、実際に進めてみると計画通りに進まないということがありました。
そこで、この課題をアジャイル開発で解決できないかと考えました。
アジャイル開発の導入
チームの開発スタイルをアジャイルに切り替えようと思った際「導入が形骸化しないだろうか」「チームメンバーがちゃんと納得して進められるだろうか」など、不安に思うこともあるかもしれません。
しかし私のチームでは「みんなで同じアジャイル研修を受けて、認識を揃える」という手段で解決することができました。
ナビタイムジャパンでは、社内でアジャイル開発のための研修が行われています。チームにアジャイル開発を導入しようと思いたった際、この研修が使えると思いました。
当初は、一人、二人のメンバーを選出して、代表して研修を受けてもらい、これをチームに持ち帰って啓蒙してもらうという進め方も考えましたが、全員で研修を受けることにしました。
研修は座学、グループワークを２日間にわたって受講しました。グループワークは同じ開発チームのメンバーと受講できたことで、自分達の開発プロジェクトの仕事をイメージしながら臨むことができました。
メンバーに起きた化学反応
研修を終えて執務室に戻ってくると、受講したメンバーはみんな目の色が変わっていました。
「忘れないうちに、総括しません？」「うちのプロジェクトにどう反映できるか話しましょう！」など、興奮気味に話をしたのを覚えています。
同じ研修を同じ目的で受けることでビジョンを共有でき、研修で習った内容を共通言語として使えるようになったことで、アジャイル開発を進めやすくなりました。
これは全員が同じ研修を受けた効果だと思います。
それからは「いかにチームにアジャイルを導入するか」などは一切考えなくて良いくらい、メンバーから「研修で習ったふりかえりのふりかえりやってみましょうよ！」など、自ら提案してくれるようになり、放っておいても自然とアジャイル開発導入が進むようになりました。
スプリントごとの開発と、その見積もり
チームではスプリントという細かい開発期間ごとに、計画から開発、ふりかえりまでを実施しています。当初は４週間周期で開発していましたが、今は２週間で行っています。
この２週間のスプリント内で行う作業は、「人日」ではなく「ストーリーポイント」という単位で見積もっています。人日が作業にかかる人員数、期間を表すのに対して、ストーリーポイントはその大きさ、煩雑さを表す単位です。
見積もりの例
ストーリーポイントで見積もる場合も、一番最初は１ストーリーポイントがどのくらいかを定義しておくことが必要になります。私たちは、チームの熟練エンジニアAさんが１日にこなせる量を「２」としました。これを元にタスクを見積もって行きます。
見積もりは優先度順に並んだタスクの一覧から、２週間のスプリントで実施できるものを取っていきます。
各開発タスクがそれぞれ何ポイントなのかは、開発メンバーの合議により決定されます。一人が数値を決めるのではなく、全員で決めることで精度を向上させています。
そして、２週間でどのくらいのタスクを割り振るかは勤務日数と個人のスキルを元に計画しています。
（例）
熟練エンジニアAさん
スプリント内における勤務日数：9日
１日でこなせると思われるストーリーポイント数：2
開発を受け持つストーリーポイント数：18 （9日 x 2）
半熟エンジニアBさん
スプリント内における勤務日数：10日
１日でこなせると思われるストーリーポイント数：1
開発を受け持つストーリーポイント数：10 （10日 x 1）
実績と記録の例
２週間の開発を終えたあと、実際にどのくらいのストーリーポイントを消化できたか記録を残します。
(例)
熟練エンジニアAさん
実際の勤務日数：8日
スプリント内で完了できたストーリーポイント数：20
１日でこなせたストーリーポイント数：2.5
半熟エンジニアBさん
実際の勤務日数：10日
スプリント内で完了できたストーリーポイント数：7
１日でこなせたストーリーポイント数：0.7
これが１スプリントにおける実績です。例えば上の例だと、１スプリントでチームとして27ストーリーポイントをこなせたことになります。
このチーム全体のパフォーマンス、個人のパフォーマンスを各スプリントごとに細かく記録として残しました。
ストーリーポイントの履歴
各スプリントごとのストーリーポイント（以下、SPと記載する場合があります）の履歴からは何がわかるでしょうか。
例えば「実績SP」の推移をみることで、チームが１スプリントあたりどのくらいのタスクをこなせるかが、ざっくりとわかります。「実績SP / 見積もりSP」は見積もり通りに進んでいるか達成率の推移がわかります。
このように、記録をつけるだけで、見える化されるものがあります。
ふりかえり
チームでは２週間のスプリントの最後でふりかえりを実施し、次の２週間のスプリントがより良い形で進められるよう、定期的な改善活動を行なっております。
当初はストーリーポイント管理表の内容だけで進めていましたが、ふりかえりの場でメンバーから「割り込みが多いので、計画通り進まないことが多い」「見積もり漏れが出てきて、本当に期日通り終わるのか不安」などの声が上がり、こちらの内容だけでは見積もり精度に不安が残ることが露見されました。
確かに今の管理表の内容だけでは、「優先度の高い割り込みタスク」や「見積もり漏れ」には対応できてなさそうです。そこで次のスプリントからは以下のような情報も記録として残すようにしました。
見積もりにおけるズレを修正するための４つのデータ
開発のプロジェクトでは、あらかじめ見積もったスケジュールから計画外に遅延してしまう要素がいくつかあります。
例えば「人日」での見積もりを行った場合は、人ごとの能力の違いにより進捗に誤差が出ることがあります。また、突然に緊急の仕事が割り込んでくることで、本来の作業時間が取れなくなることもあります。
このような見積もりのズレに対応するために、４つのデータを計測することにしました。
※単位は全てストーリーポイントです。
※データは数値だけでなく、その理由をコメントとして文章で残すようにしています
見積もり漏れSP：当初の見積もりに対して「これも対応しなければいけなかった！」という見積もり段階で漏れていたタスク。この履歴を残すことで、漏れの傾向が見える化され、次のスプリントの計画を立てる際に参考にしながら進めることができます。
割り込みSP：予定外のタスクとして、急遽やらなければいけなくなったタスク。（例：お客様からの問い合わせ対応、公開中のアプリで突如見つかった不具合への対応、など）こちらも、データを残すことで、大体どのくらいの割り込みが起こりうるかの参考数値となります。
消費SP/日：各個人がスプリントごとに１日平均でどのくらいのSPをこなしたかの数値。実績SPを、その人の勤務日数で割ることで算出しています。人ごとのパフォーマンスが明確な数値として出るので、プロジェクトの残りタスクに対してどのくらい期間がかかるかという計算を正確に出すことができます。
溢れたSP：計画していた内容に対して、そのスプリントで実行できなかったSP。この数値の分だけスケジュール外のタスクが溜まっていることを示すもので、遅れが見える化されたものです。逆に予定より多く消化できた場合はマイナスで値を入力します。この値が高くなってしまった（遅れが多い）場合は、遅れを取り戻すために先ほどの「消費SP/日」を参考に人員を補充したり、優先度の見直しを行います。
以上のような追加データを取ることで、見積もり精度の向上ができました。
終わりに
今回は私のチームで行って効果があったストーリーポイントを用いた見積もりについて記載してみました。ご覧になった方のお役に少しでも立てたなら幸いです。