アジャイル開発における工数見積もりの手順と具体的な方法

アジャイル開発

アジャイル開発とはソフトウェアの開発手法の一つです。開発工程を細かく区切り、実装・運用・テストを繰り返し行う手法で、開発期間を短縮することができるのがメリットです。

開発を進める際には工数を見積る必要がありますが、「アジャイル開発の見積もり方が分からない」「専門用語などで説明されている記事が多くてよく分からない」とお悩みの方も多いのではないでしょうか。

本記事では専門用語を噛み砕き、アジャイル開発の工数の見積もりの手順や具体的な手法について解説しています。

【開発実績2200件超から厳選】課題解決までのストーリーがわかるDX事例集


※本記事は株式会社モンスター・ラボ提供によるスポンサード・コンテンツです。


アジャイル開発で見積もりをすべき理由

ウォーターフォールに比べて、アジャイル開発は見積もりが軽視されがちですが、大まかなスケジュール感の把握は必要です。

依頼元が必ずしも知見に優れていて、妥当な要求をしてくれるわけではありません。時には無謀に思える要求をされることもあります。このときに、会社やプロジェクトがどれくらいの要求になら応えられるのか見積もっておかなければ、トラブルに発展する可能性が高くなります。

例えば、クライアントに「このアプリを1ヵ月で作っていただきたい」と要求されたとします。

何も考えずに承諾して、蓋を開けてみれば「全ての機能を実装するのに3ヵ月かかる」要求だった場合、クライアントの要求に応えられずに信用を落としてしまう可能性があります。

1ヵ月でリリース可能な状態にするには、どれくらいの人数で開発を行い、どの機能を取捨選択すれば良いかを確認しましょう。

参考:アジャイル開発時におけるプロジェクトの進め方(その1)


アジャイル開発の見積もりでおさえておくべき3つのポイント

アジャイル開発の見積もりをする際は、かならず抑えておくべきポイントが3つあります。

  • 理想と現実を分けて考えること
  • 過去の工数を参考にして見積もりをすること
  • ウォーターフォールと混同しないこと

このポイントさえおさえておけば、何故その工数が必要なのか根拠を持てるため、より正確な見積もることが可能になります。

1.理想と現実は分けて考える

アジャイル開発の見積もりも限ったことではありませんが、当初の予定を変更せざるを得ない自体が起きることもあります。

例えば最近では、コロナショックで多くのプロジェクトがテレワークに変わり、工数を見直さなければならなくなりました。

これはかなり極端な例ですが、インフルエンザによって長期間キーマン不在で予定が崩れることもあり得ます。必ずしも理想通りに事が運ぶとは限りません。

そういった不測の自体に備えて、タスクの属人化を防ぐようにしたり、スケジュールにバッファを持たせるなどの工夫が必要です。

2.過去にかけた工数を参考にする

アジャイル開発の見積もりで、過去の資料は大きな財産です。

過去に同じような開発をしたり、似たようなタスクをしたのであれば、実際にかかった工数、どんな問題がおき、どれくらいスケジュールに誤差が生じたのかを参考にできるはずです。

ここで大事なのは、なぜその問題がおき、今後どのような対策を練れば、見積もりを外さないで済むのか考えることです。

見積もりを正確に行うためには、過去の資料を基にPDCAサイクルを回すことが不可欠になります。

3.アジャイルとウォーターフォールの違いをおさえる

開発手法が違えば、見積もりに対する考え方も変わってきます。ウォーターフォールなどと同じような考え方で見積もるのは避けましょう。

アジャイル開発は、1つの開発期間(スプリント)の中で、リリース可能な範囲をざっくりと決め、2週間~1ヵ月期間で何度も開発とリリースを繰り返します。

アジャイルでの見積もりは、「1スプリントでどれだけの開発が行えるのか」という視点で決まります。

限られた時間で、ユーザーニーズを最大化するためにどうすべきかに重きを置き、必要なものは追加し、優先度の低いものは削除します。

そのため、見積もりはリリースした後のユーザーの反応や、クライアントの要求次第で変わることもあります。

一方、ウォーターフォールの場合は、見積もりを外すことは許されません。それほどに絶対的なものですから、全ての機能をいつまでに実装できるか、細かく工数を設定します。

さらに巨大なWBSを引いて、タスクを細分化し、ひとつひとつに納期を定めてスケジュールを管理します。

まとめると、スケジュールが可変であるかどうかが、ウォーターフォールとアジャイルの見積もりの考え方の違いと言えるでしょう。

参考:アジャイル開発とウォーターフォール開発の違いは何?アジャイル開発の手法や意味も要チェック


アジャイル開発の見積もりのフロー

アジャイル開発の見積もりは、以下の手順で行われることが多いです。

  1. ベロシティの割り出し
  2. タスクにかかる工数の見積もり
  3. 会議や雑務にかかる時間の見積もり

参考:ストーリーポイントで見積もる現実的な方法

1.ベロシティの割り出し

アジャイル開発では、まず「ベロシティ」というものを割り出します。

ベロシティとは、1スプリントでどれだけ作業を進めることができるのかという指標のことです。スプリントとは、開発の周期のようなものと考えてください。

1スプリントあたりの日数はプロジェクトによって変わり、1週間の場合もありますし、1ヵ月の場合もあります。

1スプリントが1ヵ月とすると、その1ヵ月の間で設計からテストまでの工程を行い、リリースまで完了させます。この場合、ベロシティの割り出しとは、1ヵ月でどれだけの機能を実装可能か見積もることを指します。

まずは、決められた期間でできる全量を見積もるイメージです。

参考:ベロシティとは

2.タスクにかかる工数の見積もり

ベロシティを割り出したら、タスク積みを行います。

ログイン画面にかかる工数はどれくらいか、検索機能を作るのにどれくらい時間がかかるか、設計からテストまでの工程がそれぞれどのくらいの期間を要するのかなどを見積もります。

その見積もりを元に、WBSを引きメンバーに割り当てていきます。

一般的には、バックログやレッドマインというツールで、メンバー各位のタスクと進捗率を見える化している現場が多いです。

ベロシティの割り出しでざっくりと全量は見積もったので、次はタスクごとに細分化して見積もります。

3.会議や雑務などにかかる時間の見積もり

会議や雑務の時間は、バッファとしてざっくり見積もられることが多いので、工数に入ることは稀です。

毎日朝会や夕会などの会議がある場合や、進捗報告会を開く習慣がある現場以外では、見積もられないことの方が多いです。

毎日メンバー全員が参加する会議が行われるプロジェクトは、ウォーターフォールでも少ないです。

仮に一回の会議の時間を30分とすると、毎月約10時間、会議で時間が潰れることになります。毎月、10時間会議をするとなれば、その時間も工数に見積もる必要があるでしょう。

会議や雑務の時間を見積もりに入れるかどうかは、プロジェクトの方針に依存します。


アジャイル開発の見積もりは「プランニングポーカー」が主流

アジャイル開発の見積もりの手法では、「プランニングポーカー」が主流です。

プランニングポーカーとは、フィボナッチ数列を使い、顧客の要求(アジャイル開発では「ユーザーストーリー」や「ストーリー」と呼ばれることが多い)に答えられる規模感を見積もる手段です。

ポイントは絶対的な工数を見積もるのではなく、ストーリーに対してどれくらいの工数が必要か、「相対的」な数字を出すことです。

プランニングポーカーの3つの手順

プランニングポーカーは以下の手順で行うと良いでしょう。

  1. 要件の確認
  2. 自分の見積もりを数値で表す
  3. 議論をし、見積もりを決定する

一般的に行われている手順をまとめたので、アジャイル開発を見積もる際に活用してください。

参考:見積もりのためだけじゃなかった! プランニングポーカーが開発チームとプロダクトにもたらす8の恩恵

手順1:要件の確認

まずクライアントからどんな機能を製造する依頼が来ているのか説明します。全員が理解しているか確認してから、次の手順に進みましょう。

手順2:自分の見積もりを数値で表す

要件を理解したら、どれくらいの見積もりが適切か、自分なりの案を出します。

プランニングポーカーでは、フィボナッチ数列(1、2、3、5、8、13……)が書かれたカードを切って行きます。

このカードの点数が、クライアントの要求に答える規模感を表していると思ってください。
参加者が切った数値に対して、各々がなぜその数値を選んだのか意見を発表していきます。

手順3:議論をし、見積もりを決定する

各々が出した案に対し深堀をしていき、最終的に妥当なポイントは何か結論付けます。

例えば、更新機能の改修の工数を見積もるとします。根本原因は、「DB側のバグで検索が上手くできないこと」です。

1人は「まずはテーブル定義などから見直す必要があり、他機能への影響を考慮し横展開するとなるとかなり工数がかかりそう」という理由で「13」を選択しました。

もう1人は「結合条件やレコード絞込み条件を調査すれば、どのテーブルに問題があるかあたりを付けることはできると指摘します。そうすれば問題のテーブルの定義ないし、結合、レコード絞り込み条件を見直すだけで良いのではないか」という理由で「5」を選択。

3人目が「確かに、結合条件やレコード絞込み条件を足掛かりに調査をすれば効率的ですが、調査とテストに手間がかかるように思えます」という理由で「8」を選択。

議論を重ねた結果、「8」が妥当という結論に至ります。

このように、全員で意見を出し合いながら、各機能にかかる工数をざっくりと見積もっていきます。

アジャイルの見積もりでプランニングポーカーが採用される3つの理由

アジャイル開発の見積もりで、プランニングポーカーが多く採用される理由は3つあります。

  • 全員が意見を言える
  • ゲーム感覚で脳がリラックスした状態で取り組める
  • メンバーの得手不得手が事前に把握しやすい

プランニングポーカーは、議論の活性化だけでなく、実際にプロジェクトが始まったときのタスク積みにも応用できます。

参考:フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法

全員が意見を言える

プランニングポーカーでは、全員がカードを切って、自分がなぜその点数を選択をしたのか意見を言うことができます。

つまり、開発に取り掛かる前に、メンバー全員の意見を取り込める点がメリットです。

ゲーム感覚で脳がリラックスした状態で取り組める

プランニングポーカー自体が、トランプなどのカードゲームのような感覚で楽しめる要素があります。

堅苦しい雰囲気だとなかなか意見が言えないメンバーたちも、リラックスして意見を言うことができます。

メンバーの得手不得手が事前に把握しやすい

カードに点数を付ける際に、「この機能の製造経験がないため、私は少し皆さんよりも工数が必要になるかと思います」などと発表すれば、メンバーの得手不得手をリーダーが把握することにつながります。

すると、ベテランのフォローの下でタスクを進めたり、他に実装経験のあるタスクを優先して回したりすることができます。

采配ミスを事前に防ぎやすくなるのも、プランニングポーカーのメリットの1つです。

プランニングポーカーの注意点

アジャイル開発を見積もる上で、多くのメリットを持つプランニングポーカーですが「時間をかけすぎない」「遊び感覚で物事を決めない」という2点に気を付けましょう。

場合によっては生産性が失われるなど、本末転倒の結果になりますので、対策も含めて解説します。

議論に時間を使い過ぎない

ポーカーで意見を言い合っている最中に、議論が白熱してしまい、ついつい予定していた時間をオーバーしてしまうことが多いです。

時間内に意見をまとめられるように、会議のファシリテーターが時間を図るなどして対策をしておきましょう。

遊び感覚で意思決定しない

プランニングポーカーはゲーム感覚で楽しく見積もりを決められる点がメリットではありますが、同時に遊び感覚が先行し、好き勝手な意見やその場のノリで意思決定してしまうこともあります。

特に、初心者や若手のみでやると、このような事態に陥りがちです。そうなるときちんとした意思決定もできず、多くの時間を浪費してしまいます。

そうならないために、きちんと目的を明確にした上で会議を進めるようにしましょう。


アジャイル開発の見積もりで注意すべき3つのポイント

アジャイル開発の見積もりで注意すべきポイントは以下の3点です。

  • 見積もりに時間をかけ過ぎない
  • タスクの漏れがないか確認する
  • 見積もりを超えた場合はなぜ超えたか振り返る

参考:スクラムでの見積もり(ストーリーポイント)

アジャイル開発の見積もりに時間をかけ過ぎない

見積もりを決める際に、メンバー間の意見の擦り合わせが上手くいかず、時間をかけ過ぎるケースが非常に多いです。

どんな場合の会議でもそうですが、目的とゴールが曖昧だと、議題もブレがちです。

今日は、どのストーリーの見積もりを決め、ポイント出しに何分、意見の出し合いに何分、意見をまとめるのに何分かけるか事前に決めて、論点がブレない工夫をしましょう。

タスクの漏れがないか確認する

見積もりを決める際に、考慮に入れるべき作業に漏れがないか確認すべきです。

例えば、リリース作業、DB定義などに掛かる工数が漏れてしまうことがあります。

毎日会議があるプロジェクトは、会議の時間を工数に入れ忘れる場合もあるので注意してください。

見積もりを超えた場合はなぜ超えたか振り返る

見積もりは正確に出さないと意味がありません。そのために、もし前のスプリントで見積もりが外れたなら、外れた理由を明確にする必要があります。

同じことを繰り返さないためにはどうすべきか対策を練る必要があります。そうして、見積もりの正確性を上げていかなければいけません。

「バッファを持たせて対応する」という意見もありますが、プランニングポーカーの場合、数字でざっくり工数を決めていくので、意識しなくてもバッファが含まれます。

そのため、意識的にバッファを入れるのはあまり得策ではありません。

【開発実績2200件超から厳選】課題解決までのストーリーがわかるDX事例集


まとめ

今回はアジャイル開発の工数見積もりに焦点を当てて解説してきました。

アジャイル開発での見積もりはウォーターフォールで行うよりも軽視されがちですが、余計なトラブルなどの種になりかねませんので、かならず見積もりを行いましょう。

アジャイル開発はプランニングポーカーと呼ばれる手法で進めていくのが一般的です。ゲーム感覚で進められ、プロジェクトメンバー全員から意見を吸い上げることができます。ただし、ゲーム感覚の延長のまま意思決定をしたり、時間を浪費するのはNGです。

アジャイル開発では、時間をかけすぎないように注意することが大切です。ただし、実数が見積もりをオーバーしてしまった場合、必ず振り返りを実施しましょう。

アジャイル開発の案件ご相談受付中(PR)

アジャイル開発は今や定番の開発手法ですが、自社の手がけるプロジェクトにマッチしているかどうか、しっかりと判断してから導入するように心がけましょう。

具体的な企画がある場合は、一度開発会社へご相談されることをおすすめ致します。

アジャイルでのプロダクト開発実績多数!具体的な見積もりのご相談はこちら

※本記事は株式会社モンスター・ラボ提供によるスポンサード・コンテンツです。

コメント