こんにちは、株式会社カケハシでおくすり連絡帳 Pocket Musubiの開発を担当している渡辺です。
プランニングポーカーをご存知でしょうか？ アジャイル開発における規模の見積もり手法の1つです。やり方は、それぞれメンバーが数字のカードを持ち、対象のタスク（もしくはユーザーストーリー）に対して、自分が考えた規模の数字カードを出し合います。一致すればその数字、一致しない場合は、なぜその差分が生じたのかを議論します。
弊社では、見積もりするタスクのゴールを定義し、知見のある人や担当する予定の人にHowの部分を説明いただきます。そこで議論をした後、自分が思うタスクのポイントを出します。ポイントはフィボナッチ数列を用いています。 弊チームでは、タスクの分割もエンジニアが行なっています。担当するエンジニアがタスク分割してから見積もりに臨みます。エンジニアがタスク分割することでリスクを下げています。 ポイントに関しては、基準のタスクを用意し、それを3として見積もっていきます。
このときに大事なのは、そのタスクを行うときに、私たちは何を行い、どのように実装するのかの認識合わせをしておくことです。いわば、設計の一部を行うわけです。
どのように実装するか認識を合わせ、それだったら時間がかからないとか、いや時間がかかるとかを議論し、議論が出尽くしたら数字を出します。そこで数字が一致しない場合はどこかに認識齟齬があるため、もう一度議論をして認識を合わせます。
氷山モデルというのをご存知でしょうか？
氷山は見えている一角が1割で、残りの9割は海底に隠れていることを表しています。
この隠れた9割は要件からは見えません。非機能要件はもちろん、実装上の構造の都合があったりします。思っていたよりも工数が大きいということがありますが、この隠れた部分を認識していないと実装を開始したときに「思ったのと違う」となってしまいます。
たとえば、私たちがTODOカードを実装しているとしましょう。
上記のようにカードの見積もりの数字を実装するタスクがあります。
ここで用件だけ見ると数字を入力して表示する+合計して表示するとして「1Sprintぐらいで終わるかな」というように言われたとします。
さて見積もりをしてみたらどうでしょう。カードの間に依存関係がないので、合計値の計算は難しい、UIが数字を入れることを想定していなかったため大幅にデザインを変えなくてはいけない等、議論しているうちにわかりました。 弊チームでは、個々のエンジニアはフロントエンドもバックエンドも両方実装します。そのため、個々人の意見はいろんな視点で見られ、意義深いものになる傾向があります。
そうしたら、プランニングポーカーの結果「8」となったします。Velocityが1Sprintで3ポイントずつ消費するチームの場合、2Sprintでも納まらないため、3Sprintかかるという結果になってしまいました。
このように、実際のソースコードを理解するエンジニアが議論してはじめてわかることが多いのです。
見積もりの値を出した後は、それを素直にPOやステークホルダーに提示し、理解をしてもらいましょう。ここでHRT/Humility（謙虚）、Respect（尊敬）、Trust（信頼）が大事です。エンジニアを尊敬する文化があれば、「そんなにかからないでしょ」のような短納期で頑張ることもなく調整できます。文化づくりは大切です。
