こんにちは。
セラク・みどりクラウド事業部のエキスパートエンジニア・スクラムマスターの原田です。

みどりクラウド事業部では、毎週1回・朝30分を使ってミニ勉強会を開催しています。
勉強会を開催する理由や、勉強会テーマであるアジャイル・スクラム勉強会の選定理由については第1回のストーリーで紹介していますので、よろしければこちらも併せて御覧ください

第5回の勉強会では、アジャイルな見積・規模による相対見積について講義形式で実施しました。

講師は引き続き、Scrum Alliance認定のスクラムマスター(Certified ScrumMaster)である私・原田が担当させていただいています。

勉強会で使用したスライド

まずは、勉強会で使用したアジャイルな見積・規模による相対見積のスライドについてご紹介します。

アジャイルな開発を始めるにあたって、見積をどうするればよいかはどのプロジェクトでも悩むポイントかと思います。各種アジャイルのTipsを適用したりスクラムでスプリントを用いた開発であっても、見積はリーダーが纏めて行っていたり、人日などの工数で見積を算出しているチームは多いのではないでしょうか？

しかし、見積がアジャイルではないのに、プロジェクトはアジャイルなんてことはあるのでしょうか？
このフレーズはアジャイルな見積と計画づくりという本から引用しましたが、実際その通りでプロジェクトを変化に柔軟でフィードバックを反映しながら改善していく体制にしたいのなら、見積も変化に柔軟でフィードバックを反映しながら改善していかなくてはいけません。

そのため、みどりクラウド事業部で私が担当したいくつかの案件でも、PBL（Product Back Log）は工数の積み上げによる見積ではなく、他の機能と比べてみたときにどれくらいの規模感になりそうかという相対見積を行っています。
その後、スプリントプランニングではSBL（Sprint Back Log）を用いてより詳細なタスクの洗い出しを行うのですが、そのときは開発チームでタスクの理想時間を見積ります。
ポイントは、PBLは規模による相対見積で、SBLは理想時間による見積という点です。

相対見積の手法としては、ポイントやTシャツサイズといった抽象的な表現を用いたり、フィボナッチ数列を活用してみたりというTipsがあるのですが、開発チームが相対見積を使いこなしたり、顧客が相対見積を受け入れるのにはそれなりに時間と慣れが必要であることを考慮しておく必要があります。
いきなり相対見積を採用するのが難しい場合、これまでの工数見積を使いながらも段々と変化させるなど、工夫が必要です。

雑談Timeで参加者から出たコメント

最後に、雑談Timeと称して勉強会参加者でディスカッションを行っています。
そのディスカッションで出たコメントを一部ご紹介します。

• 日数ではなく相対規模で見積るのは、これまでの見積の考え方から大きく思考を変える必要があるので、エンジニア・顧客の双方にとって慣れが必要になると思う。また、顧客は日数などの期間で見積を提示されることに慣れているので、顧客を巻き込めるかがポイントになりそう。
• PBLの総ポイント数からプロジェクトの着地点を予測する方法は、直近の実績を用いて予測するので精度が高そうな気がする。もう少し詳しく知りたい。

このように、セラク・みどりクラウド事業部では定期的な勉強会の時間を確保し、開発メンバーの知識や技術の底上げを行っています。

面白そうだなと興味を持っていただけたら、勉強会では他にどのようなテーマを扱っているのかもご紹介できますので是非お話をしましょう。お待ちしています。