自己紹介
では早速、本日ご登壇いただく石垣さんに自己紹介をお願いできればと思います。お願いします。
石垣氏：
改めまして、石垣と申します。現在は『DMM .com』でプラットフォーム事業本部 部長という役職についています。
工数とエンジニアのリソースの観点から見て、見積もりは必ず必要になってくると考えています。今回は主に、以下の3つの点についてお話できればと思います。
- 見積もりの目的と効果
- 3つの見積もり領域
- 見積もりが要らない状態
「見積もりの目的と効果」
まずは、「見積もりの目的と効果」についてお話しします。
マーティンファウラーの言葉に以下のようなものがあります。
「見積もりをする = 何を獲得するのか、何を失うのかを問い続ける。何も得るものがなければ 見積もりはいらない」
見積もりをする目的は、見積もりが上手くなることではありません。見積もりによって何を獲得するか、または見積もりによって何を失うのかという問いを続けることが非常に重要だと言えます。
仮に何も見積もりによって得るものがなければ、見積もりは必要ないという結論になります。ここで重要なのは、見積もりによって何を獲得するかです。
以下に、見積もりの効果と目的の一例をまとめてみました。
まずは、意思決定するために見積もりを行います。
「見積もる」という行為は、1番初めは要求も抽象的でブラックボックス化しています。そこで、見積もりの過程でタスクの細分化や規模感、相互関係などを明らかにし、ブラックボックスを可視化し、解きほぐし、可視化します。
さらに、アイテム同士の前後関係に基づいて優先度の判定ができます。
優先順位や規模感を見た上で、施策を実施するべきかの判定に使えるとともに、チームの中でのフロー効率やリソース効率など、開発するためのプロセスの制限にもなります。
以上のように、何をを意思決定したいのかを原点に立ち返って考えるために、見積もりという行為が必要だと考えています。
また、「信頼の積み上げ」という項目に関しても、チーム内におけるベロシティや生産性についてチーム内外で共有し信頼を積み上げていくために見積もりをします。
そして、見積もったものはその通りリリースしているという実績の積み重ねを学習することが重要だと思っています。
逆に失うものが何かと考えると、基本的には「時間」です。スクラムでの運用であれば、「人数×見積もる時間」のような形で、例えば10人チームでプランニングが1時間、スプリントで月4回繰り返すと仮定すると、約40時間毎月かかります。1日8時間働くとしたら、5人日ぐらいの価値があるので、ここはきちんと意識するべきところです。
スクラムやアジャイルの手法で進めていくと、プランニングというイベントが必須となります。それに対し、失うものは何なのかを基本に立ち返って確認する必要があります。
また、見積もりを行うことで信頼を失う可能性もあります。
開発の初段階では不確実性が高いため、見積もりの精度が低いのは当然です。これはどう考えても解決が難しい問題です。
例えば「この機能を作るのが30時間でできます」と報告すれば、その報告には必ず責任が伴います。
PMやPDM、そしてチーム外の経営陣は、その報告の不可欠性が高かった としても、そこの報告に準じた予算を組みます。
特にDMMはエンジニアが1000名ほどいて、チームが数百ありますので、見積もりにおける不確実性も高まります。そのため、プロダクトチーム、PM・PdM、経営陣という各レイヤーごとに正確性を見失い、信頼を失ってしまう懸念点は少なからず存在します。
このポイントは重要なので、もう少し深掘りしていきましょう。
この画像のプロダクトチームは、スクラムチームと 置き換えてもいいです。
この矢印の下に書いてある内容が、それぞれの視点と得たい観点です。各レイヤーごとに視点や観点が違うのがわかります。
- プロダクトチームであれば「ポイント」
- PM・PdMは「工数」
- 経営層は「金額」
この、それぞれのレイヤーが持っている視点を、他のレイヤーに変換するコストについて、見積もりでは考えなければなりません。
「工数→金額」に関してはそれほど難しくありません。1人月が75万円だとした場合、ある機能を1人月で作れば75万円、2人月なら150万円で作れるという金額が明らかになります。
しかし、「ポイント」が少し厄介になります。なぜなら、ポイントは架空の単位だからです。架空の単位を、実態のある工数に変換するのは簡単ではありません。
プロダクトチームからポイント数で見積もりがあがってきた際に、それをきちんと工数と金額に変換しなければならない作業が発生します。
「3つの見積もり領域」
見積もりの方法について考えると、世の中には様々な手法が存在します。
上の図のように、縦軸には「相対的」「絶対的」という実数値的な観点を、横軸には「個」と「チーム」という要素を置いて見ていきましょう。
スクラムチームではストーリーポイント式の見積もりを使うことが多いです。ストーリーポイントはチームの経験と学習に基づくもので、アウトプットの量を測るための指標となりますし、他のサンプルとの比較が主に行われるため、相対的な見積もりの手法となります。
一方で「時間見積もり」は絶対的な指標として扱われます。「個」か「チーム」かは対象によりますが、図ではいったん左下に置いています。
「時間見積もり」は、三点見積もり、係数見積もり、ボトムアップの見積もりなど、多岐にわたる手法が存在します。それ以外には、「No-Estimates」と呼ばれる方法もあります。
見積もりの方法は「ストーリーポイント見積もり」「時間見積もり」「No-Estimates」の3つに分類することができます。それぞれの方法について、簡単に説明していきます。
「ストーリーポイント見積もり」
「ストーリーポイント見積もり」は、アジャイルの基本を理解していれば大丈夫だと思います。
基本的にこれは相対比較であり、作業量ではなく規模で見積もります。フィボナッチ数列1が1時間、5が5時間といった具体的な時間に置き換えてはいけません。規模の比較が大事で、個ではなく、チームのスキル単位で考える必要があるのです。
この見積もりは難しい点も多いです。例えば「このチームのテックリードは3時間で終わるが、今日入ってきた新人であれば10時間かかる」といったケースは起こり得ます。
そうなると、作業時間は作業者によって変わるため、やはり個ではなくチーム単位で経験学習して見積もることが大事になってきます。
「時間見積もり」
次に、時間見積もりについてです。
これは実際に工数や人月で見積もるという点が重要です。基本的にはチーム単位ではなく、個が中心になりますが、どちらを基準に決めても問題はありません。
この図で言うと、ABCという3つの作業があります。それぞれの人月を足していくと、合計で約20人月、つまり1ヶ月となります。このように、作業を分解し、それを足していくことで算出するのが「ボトムアップ」という方法になります。
この見積もり以外の方法もあります。
類推見積りは過去のプロジェクトを参考にしています。過去のプロジェクトでかかった工数と見積もり対象のプロジェクトを比較して、見積もりを算出する手法です。
係数見積もりは、不変の係数を設けて、例えば今回のプロジェクトは重いので3を掛ける、といった特定の係数による重み付けを行う方法です。
3点見積もりも一般的な方法です。悲観値と楽観値、そして最可能値の3点で、見積もりを算出します。
プロジェクトマネージャーの領域では、このような時間見積もり方法が多く使われています。
「No-Estimates」
「No-Estimates」について解説します。
これは先ほど言った ストーリー ポイントの考え方と近く、数年前から海外を中心に採用されている方法 になります。
図の左のように、「タスクに見積もりをつける」というのが一般的な考え方だと思います。 しかし、「No-Estimates」の場合は「見積もりの単位にタスクを切る 粒度を合わせる」という考え方になります。
ストーリー ポイントの場合、例えば 「会員登録機能を作る」というようなユーザー ストーリーがあって、 そのために必要なタスクを分解して、タスクごとに見積もりを付けていくというような考え方になります。
しかし、「No-Estimates」の場合はそうではなく、例えば チームの経験的に3という粒度のタスクがあり、その共通認識が持てている状態があるとします。あるタスクについて、チームに所属する全員が、このタスクは「3」だという認識を持っている状態を作り、これに対し「3」という規模感でタスクを切っていくという方法です。
ただし方法を使うには、 チーム全員がタスクの粒度に関して共通認識を持てている状態を作らなければなりません。ある程度チームが成熟していることが条件です。チームを作りたての初期のフェーズなどではなかなか難しいでしょう。
「見積もりがいらない状態」
最後に「見積もりがいらない状態」です。
さきほど説明した見積もりの方法や、見積もりが意思決定の手段としてあること、経営層から見た時の意義やPdMから見た際の考え方など、見積もりには多岐にわたる要素があると思いますが、結局のところ見積もりの考え方は、結局自分のチームのフェーズにかなり比例します。
今回は、見積もりをしないという話になると思いますが、それは全チーム共通の義務ではありません。見積もり方法は、チームの自己組織化に比例します。自己組織化が進んでいれば、見積もりの方法はそこまで重要ではなくなることが多いです。
加えて信頼と実績があれば、詳細な見積もりはそれほど必要ないという方向にまとまることもあります。自己組織化とは、暗黙知が共有されており、お互いの考えが分かる状態です。加えてプランニングもストーリーポイント形式で進めていても、チームの意見が基本的に合う、ずれることが少ないという状態です。
見積もりの早さで言えば、「類推モデル」や「No-Estimates」が効率的で早いことが多いです。私の経験上、プランニングには1.5時間ほど毎回かかっていましたが、「No-Estimates」を使えば15分ほどで済むこともあります。PDIやSDIを事前に準備していれば、プランニングが一瞬で済むようになります。
ただし、ストーリーポイント形式から「No-Estimates」に移行する際は、ベロシティの安定やタスクの粒度に共通認識が持てているどうかなどの確認が必要です。
その一方で、少数精鋭で進めているスタートアップでは、社長が積極的にプロダクトを作っていく場合、見積もりをしないところも多いです。見積もりせずともプロダクトは前に進み、成長しているケースがあります。そのようなケースもあるので、全ての環境で見積もりが必ずしも必要だとは思いません。
とはいえ大きな組織では、チームの外に出た時に工数や成果物を証明しなければなりません。そのため、実数値や工数見積もりが必要なケースも出てきます。とはいえ、類推モデルなどでサンプル数を蓄積していけば、この問題は改善されるかもしれません。
例として、タックマンモデルを挙げてみましょう。
- 形成期：チームが最初に組成される段階では、メンバー間の相互理解が不足しており、スキルや役割が明確でないため、自己組織化していない状態になります。
- 混乱期: 役割が徐々に形成されると、メンバーが違う方向を向き出し、仲が悪くなるような状況が生じることがあります。例えば、テックリードを希望する人が複数出てきたり、前のチームとの役割の違いや、自分が描くキャリアの方向性に違いがあったりすることです。
- 統一期〜機能期: これらの問題を乗り越え、半年から1年でチームが統一されると、チームが完全に自己組織化され、メンバーがお互いの思考を理解し、長い期間一緒に働いているかのような状態になります。
このタッグマンモデルに照らし合わせると、チーム組成の初期段階では、ストーリーポイントや時間見積もりなどを選択します。この際、お互いの価値観やスキル感は見積もりに出てくるので、そこを確かめる手段が必要だと思います。
そのうち お互いの実力が分かってくるので、そのフェーズになると「No-Estimates」などが可能になります。しかし、チーム組成の初期段階で、「No-Estimates」がうまくいくチームはあまり見たことがありません。
その理由は、お互いの人物や実力、役割、考え方などが分からないためです。これは一例ではありますが、参考になれば幸いです。
私の発表は以上になります。ご清聴ありがとうございました。
佐藤氏：はい、石垣さん、ありがとうございました。
様々な見積もりの方法について、目的や視点、変換コストなどの観点から整理してご紹介いただいたので、視聴者の皆さんも何かしらの前提状況を揃えられたのかなと思っております。
この後はパネルディスカッションです。石垣様よろしくお願いいたします。
さらに本日は、皆さんがどれぐらいスクラムしているのか、そういうところを実際に深掘りする前にご質問させていただきます。
現在のスクラムの運用状況、どれぐらいスクラムされているか、また運用上何か課題に感じることがあれば、最後の方の質疑応答に回っていくテーマになってくるかもしれません。
皆様ぜひお答えいただければと思います。
ちなみに、さっきのお話では、見積もりをしないということではありましたが、本来見積もりによって獲得したい意思決定や信頼を最小で得るために「見積もらないという見積もりをしている」という印象を受けました。見積もりから完全に離れていないような感じですね。
石垣氏：
見積もりをなくすというのは、スモールな会社やチーム内で閉じていれば可能だと思います。ただし、規模が大きい場合や他のチームとのバランスを取らなければいけない場合など、見積もりの時間を減らすなどのアプローチが必要だと感じます。
佐藤氏：
本当に見積もらないような力強い進行と比べると、比較的理性的な開発を目指しているところもあると思いました。
ありがとうございました。ここからは、ディスカッションに移っていきたいと思います。
ディスカッション
ディスカッションテーマ①「見積もりを行う場合に、気を付けるべきことは？」
佐藤氏：
今までの解説と多少被るところもあるでしょうが石垣さん、いかがでしょうか？
石垣氏：
気を付けるべきは、トレードオフが何なのかという点です。長い時間をかけた上で、ちゃんとリターンをチームで感じられるのであれば見積もるべきです。ざっくり見積もってもチームがうまく回っているなら問題ないと思います。時間に対するトレードオフは、見積もりする段階で大事になってくるでしょう。
佐藤氏：
実際に見積もりをしているメンバーや関わっているメンバーが何かしら違和感を覚えたタイミングなどが、見積もりの方法を見直すべきタイミングなのかもしれませんね。
石垣氏：
一例ですが、優秀なチームほど週のタスク量が多くなり、見積もりにかかる時間が長くなるという傾向があると思います。
優秀なチームほど見積もりに長く時間をかけているという現状が、原体験としてはちょっと違和感の発端でしたね。
佐藤氏：
それは、良いチームほど見積もりに時間をかけているが、そのチームの生産性を支える上で見積もりがそれほど寄与していないという部分が感じられることがあるんですね。
石垣氏：
そうですね。細かな見積もりの差に重要性はないので、「そこに時間をかけるのであればコードを書いてた方がユーザーに価値が届くよね」「見積もりってそんなに時間が必要なものなのか？」という問いかけが、転換期であったと思います。
佐藤氏：
ありがとうございます。では、次のテーマに進んでみましょうか。
ディスカッションテーマ②「どの段階になれば 見積もらない方法に移行できるのか？歩み方などあれば教えてください」
佐藤氏：
どの段階になれば見積もらない方向に移行できるのか。歩み方、道のりとしてどういう過程を描くことを意識していくのがいいのかということですが、いかがでしょうか？
石垣氏：
先ほども話した通り、自分たちのチームが信頼できるようになることが重要です。チームを組成した段階で見積もらないというのは難しいと思います。
まず、ストーリーポイントや時間見積もりなどを行い、自分たちのチームを信頼できる状態を作り上げるのが大切です。
その状態を作り上げられたら、まずは「No-Estimates」を行ってみて、その状態で以前と変わらずにチームが機能できている。 一方で 見積もりにかかる時間が下がっているという状態を作り上げられれば、メリットしかありません。
いきなり見積もらない方法を実行するのではなく、そこに至るまでのフェイズを踏むことが大事だと思っております。
佐藤氏：
「自分たちはこれをやらなくても大丈夫」という自信を獲得できる状態になっていることが重要ということですね。
石垣氏：
そうですね。加えて、タスクに関する粒度に関して、チーム内で共通認識が持てることも重要だと思います。
例えばチームを組成したばかりの頃は、同じタスクに対してにも、1~8まで、粒度の認識にズレがありました。
そのズレをディスカッションして統一し、次第にスプリントが進むと粒度のズレが少なくなり、最終的にはこの認識のズレがなくなり、粒度が統一されました。この状態であれば、そもそもプランニングにかける時間が無駄だという結論になり、自然にチーム内で見積もらない方法に移行していきました。
佐藤氏：
チーム組成初期は、ストーリーポイントなどのタスク規模を抽象的に見積もることで、タスクにどのぐらい時間がかかるのか、メンバー1人ひとりで認識の差が生まれやすい状況であると思います。そういった違いがだんだんと無くなってくるということでしょうか。
石垣氏：
そうですね。加えて、チーム組成当初は、メンバー同士でスキルの差があります。しかし、例えばプロジェクトが進むにつれてスキル的な差が統一されれば、メンバー間のスキルの差がなくなっていきます。そうすれば、個々人のスキル差による見積もりの差は生まれにくくなるでしょう。これが大きな要因かもしれないですね。
佐藤氏：
見積もりそのものの運用以外にも、チームとして成熟するためのいろいろな工夫が必要なのかもしれませんね。ありがとうございました。
ちなみにこれは、私の個人的な質問になってしまうのですが、「No-Estimates」のご説明の中で、「3」という数字を 便宜上 スライドの中で使われていたと思うのですが、この3という数字が細かく タスクを砕いていくとこの数字になるのか、それともたまたまその大きさに収束していった結果なのかというと、いかがでしょうか。
石垣氏：
たまたまその形に落ち着きました形ですね。先ほど挙げたチームの例で説明しますと、最終的に、チームメンバーが3のタスクしか作らなくなるという共通意識が形成されました。数字が3であること自体が特別なわけではなく、チームによっては5でタスクを切るチームもあれば、細かく1でやっているチームもあったりします。
チームの文化やパターンランゲージなどが、その規模感を作っていくと言えるでしょう。
佐藤氏：
自然と3や5でしかタスクを切らなくなってくるチームは、その粒度が心地よく感じられている状態になっているんでしょうね。
石垣氏：
そうですね。チームによっては、8という粒度のタスクが大きすぎるので分解するという文化もあれば、5が大きすぎるので分解するという文化もあります。チームごとの文化の違いだと思います。
佐藤氏：
そもそも、適切な粒度がどれぐらいの大きさなのかもチームによって違うでしょうし、チームの性質によって、そもそもタスクの原型的な大きさも違いますもんね。
石垣氏：
たとえば、チームの再編が起きた場合の対応について考えると、そこでもチームの性質が大きく影響します。半分以上のメンバーが変わると、文化も大きく変わる可能性があるので、やり直しになることが多いです。逆に1人程度の新卒が加わるなどの変化は問題ないことも多いでしょう。
ディスカッションテーマ③「チーム編成などが起きた場合 どう対応するのか？」
佐藤氏：
「チーム編成などが起きた場合 どう対応するのか？」 というテーマですが、こちらはいかがでしょうか。
石垣氏：
イメージ的には、タック万モデルで言うところの形成期まで一気に戻るような感じがします。チームの過半数が変わってしまった場合、文化が変わってしまうのはよくあることだと思います。新卒で1人 入ってくるレベル であれば問題ありませんが、チームの過半数が新しい人になる、チームが解散し バラバラになってしまうような状態になれば、最初の状態からやり直しになります。
スクラムはチームの資産や価値を大事にする考え方ですが、チームを壊してしまうと生産性が振り出しに戻ることもあります。
佐藤氏：
石垣さんは事業部のマネージャーとして、チームの生産性を維持するために気を使っていることなどはありますか？
石垣氏：
基本的には人を入れ替えないようにしています。 DMM自体が、プロジェクトごとに人を集めるのではなく、プロダクトチームの集合体として運営しています。プロダクトごとにチームを持ち、チームの資産を大事にしているため、基本的にチームの再編は避けています。
ディスカッションテーマ④「運用してみてのPros/Consを教えてください」
佐藤氏：
「No-Estimates」を運用してみての経験から、そのメリットとデメリットはどのようなところがあるのか、教えていただければと思います。
石垣氏：
まず、Prosに関して言うと、時間が短くなるというのが大きなメリットです。先ほど解説したトレードオフの話だと、費用対効果はいいです。
しかし、Consについては、新しい人が来たときにその人のオンボーディングをする中で、チームの文化の言語化や解釈は時間がかかるものだと思っています。オンボーディングに関しては時間がかかるし、わかりにくいですね。
時間の見積もりや「あなたが見積もるならどのくらいかかる」という会話でもいいですが、ストーリーポイントのように共通認識が具体化していないと、伝えるのが難しいです。
また、チーム外の人に対し、後ぷっとする際に弊害が起こります。見積もりを工数や金額で欲しいと言われた時に、「No-Estimates」でやっていると、ストーリーポイントを工数や金額に変換するのに一手間かかります。
基本的に「No-Estimates」はタスク量ですね「このスプリントは10個のタスクを消費しよう」という考え方になりますので、その10個にどのぐらいの価値や時間がかかるのかを変換するコストがかかるというのがデメリットかなと思います。
佐藤氏：
実際、先ほども便宜上3という数字もありましたが、最終的に「No-Estimates」に至ると、タスクの個数のような数え方になるんですね。ストーリーポイントを時間や工数に変換するのは大変というお話でしたが、どのような考え方で変換作業を行っているのでしょうか。
石垣氏：
たとえばチームが10個のタスクを1スプリントで終わらせるとするとします。その10個という数はいったん考えずに、スプリント単位で変換します。
具体的には「この機能は1スプリントで終わります。これは約5人日になります。この作業を5人でやるので、1人日で終わります」といったように時系列にあわせて計画します。
細かく分解せず、スプリント単位で処理できるかどうかを見積もります。
ディスカッションテーマ⑤「今後の課題があれば」
佐藤氏：
時間が迫ってきたので、Pros/Consについての具体的な質問はQ&Aで取り上げるかもしれません。石垣さんの今後の課題についてざっくりとお話いただけるとありがたいです。
石垣氏：
一番の課題は、見積もりをしないと言いつつも、チーム外に出た時の変換コストです。工数見積もりにかなりの時間がかかることは変わらないので、スクラムチームの外に出た時にどうすべきかを考えたいと思っています。
佐藤氏：
ありがとうございます。
質疑応答
【質問】①
「全体のWBS見積もりはどのタイミングで行っていますか？また途中の 見積もり修正はどのような方法で行ってい ますか？」
石垣氏：
スクラムチーム内だけで完結する場合、WBSなどは特に引かないというのが私の例です。引いたとしても「No-Estimates」で管理しています。
しかし、複数のプロダクトチームが関わるプロジェクトでは工数見積もりが必要ですね。それはスクラムチームの外でPMチームなどが並列的に対応しています。
途中の修正はリファメントなどで逐次行い、見積もりの修正もその都度しています。スクラムチームに関しては週1で行います。月曜日にプランニングの切れ目があれば、水曜日や木曜日などに30分程度の時間をとってズレがないか確認しています。
佐藤氏：
ありがとうございます。スクラムチームの中では、外部から工数やスケジュールなどが発生することがあると思います。その部分は適宜スクラムチームに共有するということですね。変換コストがかかるかもしれませんが、適宜共有してシンクしているというイメージでしょうか。
【質問】②
「No-Estimates」において他部門や経営層から説明を求められた際、どのような指標で説明されていますか？
石垣氏：
先ほどのスライドにもあった通り、経営陣に対しては金額で出しています。例えば、「この機能を作るためには500万円ぐらいかかります」といった話です。工数なども書いていますが、大体は人月と工数で変換して出しています。
佐藤氏：
金額の計算の根拠として人月があるということは、提供する情報にはありつつも、石垣さんから経営者の方に「いくらです」と具体的に説明しているイメージですかね。
石垣氏：
そうですね。もう少し詳細に言うと、例えば友達紹介キャンペーンなどの企画が立ち上がった時、その企画を通すために工数が必要だと思います。友達紹介キャンペーンが1000万かかるとなると「やらない」という判断も出てくると思うので、まず概算の見積もりを出してくださいという依頼が開発陣に来ます。
その際、スクラムチームやエンジニアリングマネージャーなど誰でも良いのですが、ここでは3点見積もりを人月で出すことになります。企画を通すための見積もりですね。
企画が通り、実際に企画を実行するとなった時には、スクラムチームに持って行って、詳細見積もりなどを行います。このように、見積もりに関しては概算見積もりや詳細な見積もりなどの段階を踏んでいます。
佐藤氏：
なるほど、「No-Estimates」とは別のテクニックもあるかもしれませんが、最初に概算の見積もりを出すわけですね。
石垣氏：
そうですね。概算見積もりは精度60%ぐらいで大丈夫という認識で、経営陣と共有しています。要件が決まっていない段階で、ブレない詳細な見積もりは無理だということは経営陣も理解しています。
ざっくりとした人月と金額を出せれば、その情報を元に企画をやるべきかどうかの判断ができると思いますので、そういった合意をもとに進んでいる形ですね。
佐藤氏：
ありがとうございます。次の質問に行ってみたいと思います。
【質問】③
見積もりに対するリターンについて、どういった場面で実感することが多いでしょうか？
石垣氏：
獲得するものと失うもののリターンの違いがありますが、失うものに関しては時間です。これは現場でよく見かけることで、「長い」というのが一番のストレスになったりしています。
予実をあまり管理していなかったりすると、時間を失うことが大きな問題だと感じています。
メリットのところは、獲得できるものを意思決定の材料として使える点もあるのですが、やはりこれも時間です。エンジニアにとって時間の価値は高く、「見積もっている時間があればこのタスクが終わった」というような状況によく遭遇することがあるのではないでしょうか。効率的に使える時間が価値を生むというメリットは大きいと思います。
【質問】④
「ストーリーポイントが安定するまで見積もりに使いづらい、新しいチームやプロジェクトの序盤で見通しを立てづらい」ということですがいかがでしょうか？
石垣氏：
そうですね。ストーリーポイントの概念はチームによって掴みづらいことがあると思います。最初は時間をフィボナッチ数列に置き換えて考えるといいと思います。時間は全員が共有する単位なので、お互いの価値観やスキル感がそこでわかってきます。そこからストーリーポイントへの移行がおすすめかもしれません。
佐藤氏：
なるほど。教科書通りにやると、ストーリーポイントは時間ではないと言われることもありますよね。
石垣氏：
それが結構難しいと感じることがありますね。現場でストーリーポイントを時間に置き換えているチームも多いと思うので、そこから相対見積もりに移るのがいいかなと思っています。
佐藤氏：
実際に外から説明を求められる時にも時間に置き換えられることが多いですよね。
そういうところで、あえて時間見積もりから始めるといいんじゃないかというのは、割と勇気が出る回答だったかなと思います。
【質問】⑤
「チーム内のコミュニケーションがうまくいかず、人員の入れ替えなどが発生しています。新規に採用したメンバーと既存メンバーとのズレが生じ、なかなか見積もりをやらないという判断ができない状態です」とのご意見でした。これは、見積もるよりも以前の話のようですね。
石垣氏： 心情的な問題なのか、スキル差によるものなのかなど、ズレが発生する原因を深掘りする必要がありますが、スクラムには仲良くなるイベントも多く、振り返りから変える方法もあると思います。
振り返りには色々な方法もあるので、まずは振り返りでチームの統一感を高めてみてはいかがでしょうか。
【質問】⑥
見積もりがずれた時にその原因の共有がされずらく、また共有されたとしても改善が困難な場合、どうすればいいでしょうか？
石垣氏：
チームの組成当初については、見積もりは基本的にずれるものだと考え、それを改善していく過程が重要だと思います。チームメンバー同士の価値観がわかってくれば、時間が解決することもあるでしょう。
【質問】⑦
「非エンジニアへの見積もりの説明に苦労しています」とのことですが、いかがでしょうか？
石垣氏：
要求を出してくる側が非エンジニアである場合、見積もりがずれる理由がわからないことも多いです。
先ほど例に出した「友だちキャンペーン」の企画で、要求が3行しか書かれていない、ということもあり得ます。この場合に10人月で見積もりを出し、実際には20人月かかるようなこともあるでしょう。
非エンジニアの場合、見積もりと工数の関係についてあまり理解されていないことも珍しくありません。
このようなケースでは、要求を出す側にもう少し詳しい情報を出してもらえるように求めます。さすがに3行だとズレが大きくなります、そのため、どのレベルまで深掘りしてもらえれば、見積もりのずれは減りますというような説明をするようにしています。
【質問】⑧
「形式的にはスクラムの形で開発をしているが、毎週こなすだけになってしまったり、あまりメリットを享受できていないと感じている」ということですがいかがでしょう？
石垣氏：
これはよくある問題ですね。
スクラムというのはただの型なので、ただ型を入れているだけだと、それに従って動くロボットみたいになってしまうことがあります。
型を入れた時に、そのチームに合っているかどうかの差分を見つけ出すことが大事です。
例えば、スプリントレビューがいらないチームもありますし、POがちゃんとレビューに入っていると省けることもあります。チームによってその辺りが変わってくるので、カスタマイズ性は大事になってくると思います。
スクラムやXPなどのフレームワークは型なので、自分たちのチームに合わせて型を変えていくことが重要です。
スクラムの中で型を変えてはいけないという決まりはないので、いろいろカスタマイズしていいと思います。
佐藤氏：
カスタマイズする方向性やモチベーションをチームとして持つというのが意識として必要そうですね。
石垣氏：
そうですね。スクラムをただなぞるようなやり方は避けなければなりません。
【質問】⑨
「見積もりにかかる時間が長いタスクの流動化をメンバー間で揃える会話が不毛に感じる」ということですが、いかがでしょう。
石垣氏：
チーム組成初期は不毛感を感じることもあるでしょうが、一度整えれば後は勝ちのようなところがあります。
初めのうちは我慢するか、いったんは時間の見積もりでやってみるなど、工夫が必要かもしれません。今回紹介したような「No-Estimates」などのゴールを設定すれば、モチベーションを維持したまま取り組めるかも知れません。
佐藤氏：
はい、ありがとうございました。これで最後のご質問コメント等でした。石垣さん、たくさんお答えいただきありがとうございました。
▼ エンジニアの求人状況
https://dmm-corp.com/recruit/engineer/
▼ 開発組織の行動指針
