チーム開発経験の浅い新入社員に見積りをマスターしてもらう方法A
この記事はクラスター Advent Calendar 2022 (シリーズ 1) 23日目の記事です。
はじめに
こんにちは。クラスター株式会社 ソフトウェアエンジニアのanoriqqです。
アドベントカレンダーもいよいよ終盤ですね！
昨日は、amanatsu-knitさんの 個人的に好きなクラスター社のslackカルチャー4選でした。私も日々SlackのTwitter化に貢献すべく活動しています。先月は1,400ツイートほどしていました。
さて、この記事では、私が『ソフトウェア見積り 人月の暗黙知を解き明かす』を読んで学んだことをもとに、チーム開発経験の浅い新入社員に見積りをマスターしてもらう道のりを考えてみた話をしたいと思います。
本書は、見積りとはなにかや、良い見積りを得るための技法を学ぶことができる本です。見積り嫌いな私が、これらを改めて捉え直したことで、むしろ自分の武器にできるような気さえしました。少なくとも、本気で見積りをしたくないと思っていた頃の気持ちは完全に消失しました。
もっと早く知りたかったと心底悔しくなったので、次の世代の若手には最速で見積りをマスターしてもらいたいと思い立ち、この記事を書くきっかけとなりました。
本記事は次のような構成になっています。
- 対象読者と前提
- 見積りプラクティス集
紹介する見積りプラクティスは特定の環境・条件を前提としています。また、私の想定できる非常に狭い範囲の前提で考えた見積りプラクティスになりますのでご了承ください。見積りプラクティスをそのまま適用してもうまくいかない場合は、カスタマイズが必要になるかもしれません。カスタマイズする際はぜひ、種本をあたってみてください。
対象読者と前提
対象読者は、クラスター社に入社したばかりだった3年前の私(サーバー領域担当/チーム開発歴<1年)です。本記事は、当時の自分を思い出してメンタリングするつもりで書いています。
前提は、クラスター社の開発環境・開発フローです。ここは、見積りプラクティスをより理解できるように補足がありますので、必要であればご参照ください。
見積りプラクティス集
ここからは、具体的にどのように見積りをマスターしていくのかについてのお話になります。
といっても、一度に見積りのすべてをマスターするのは難易度が高いです。少なくとも私が見積りを大きく外すことがなくなるまでには3年近くかかりました。新入社員にとっては、新しい環境に慣れるので精一杯な状況ですから、実務と並行して、ひとつずつ理解していくのが無理のない方法だと思います。
そこで、チケットをひとつこなす度に新しい見積りプラクティスを取り入れるスタイルを考えました。チケットをこなすほど、実務の経験値も上がっていきますが、それに合わせて、見積り技術もステップアップしていけると思います。
ここでは、順番に見積りプラクティスを並べているので、上から取り入れていくと良いと思います。しかし、実践するタスクと見積りプラクティスとの相性もあると思われるので、適宜入れ替えてもよさそうです。
1.記録する
まずは、チケットを実際に遂行して、やったことと、消費した工数を記録します。見積りの練度に関わらず記録することはできますし、この記録が将来の見積りに役立ちます。
以下は、スプレッドシートに記録する例です。
やったことは、もう少し詳細に書いても良いと思います。チケットを分割して考えたときに、それぞれの部分で工数の比率がどうなっているのかが分かると、その知識が見積りに利用できます。テストコードを書く時間が一番大きかったとか、バグ調査でログの見方が分からずに時間かかった、などです。
さらにカスタマイズして、変更したコード行数などを記録してもよさそうです。
自分の組織の過去のデータを使用する最も大きな理由は何だろうか。それは、過去のデータを使用すると、より正確な見積りを作成できることだ。過去のデータ、すなわち「文書化された事実」の使用と、コストやスケジュールの超過には、負の相関がある。つまり、過去のデータを使用して見積もられたプロジェクトは、コストやスケジュールの超過が少ない（ Lederer and Prasad 1992）。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 161). 日経BP社. Kindle Edition.
2.チケットを知る
有用な見積りを出すためには、見積もる対象のことをよく知る必要があることに同意してもらえると思います。1.記録するではチケットの作業の中でも終盤の振り返り部分に焦点を当てていますが、2.チケットを知るでは、チケットの作業の中で序盤の準備部分に焦点を当てます。
チケットは、具体的な作業内容が書かれたものと、目的が書かれたものに大別されます。前者はチケットの内容を実施するのが完了条件で、例えば「fugaテーブルにpiyoカラムを追加する」「Hoge feature flagを有効化する」などがあります。後者は、目的を達成するための手法を検討し、次のアクションを決めるのが完了条件で、例えば「hogera APIのレスポンスに要素の合計数を追加したい」「hogehogeの処理に時間がかかりすぎている」などがあります。
個々のチケットには完了条件があり、その条件を達成するためにやるべきことが具体的に分かるまで準備することが、見積りの重要なポイントですし、チケットをスムーズに進行することにも繋がってきます。ただし、これは小規模なチケットに適用できることであり、規模が大きなチケットにもアサインされるようになったら、コスパの良い準備をすることも考えると良いです。
集めた情報は、チケットの説明欄にまとめておくと良いでしょう。以下はJiraを使った例です。
作業内容に書いたことは、1.記録するのやったことと重複するので、記録のスプレッドシートにはチケットへのリンクを乗せるだけに変更しても良いともいます。
新しい家を建てるにはいくらかかるだろう？それはどんな家かによる。Webサイトを作るにはいくらかかるだろう？それはどんなWebサイトかによる。それぞれの具体的な機能が詳細に理解できるまでは、ソフトウェアプロジェクトのコストを正確に見積もることは困難だ。「何か」が定義されていないのに、その何かを構築するために必要な作業量を見積もることはできない。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 80). 日経BP社. Kindle Edition.
3.見積り、ターゲット、コミットメントを理解する
さて、ここでやっと見積りの話に入っていきます。まずは見積りとはなにかを捉えることが重要です。なぜなら、見積りの近接概念である、ターゲット、コミットメントという重要な要素を意識する機会が少ないため、これらを見積りと混同しがちだからです。これらを分けて考えることで、良い見積りのためにすべきことが分かりやすくなります。
見積り、ターゲット、コミットメントそれぞれについては、こちらの記事に書かれていて分かりやすくまとまっています。
辞書にある「見積り」の定義は、厳密な意味では正しい。見積りとは、プロジェクトにかかる期間やコストを予測することだと言ってよい。だが、ソフトウェアプロジェクトの見積りとは、ビジネスのターゲットと、コミットメントと、コントロールとの間の相互作用である。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 30). 日経BP社. Kindle Edition.
4.チケットが完了するまでは不確実な要素が常にある
すごく当たり前のことですが、未来のことはどうなるか分かりません。2.チケットを知ると、1.記録するの間には実際の作業が行われますが、計画した通りに進むこともあれば、そうでないこともあると思います。そういった、進行段階ごとにどのくらいの不確実性があるかを図示したものが以下の「不確実性のコーン（円錐）」です。
図4-2
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 85). 日経BP社. Kindle Edition.
この図によると、初期コンセプトの時点の見積りは、実際の0.25倍も小さな見積りになっている可能性もありますし、実際の4倍も大きな見積りになっている可能性もあります。そして、プロジェクトがおよそ30%進捗した、ユーザーインターフェース設計完了の時点の見積りは、コーンはだいぶ狭くなり、実際の0.8倍程度小さな見積りの可能性、実際の1.25倍大きな見積りの可能性がある状態になります。これはチケットにも当てはめることができます。
状況が変わるたびに見積りを見直すことが大切であり、チケットの進行状況によってコスパの良い見積りが違うことが読み取れます。例えば、初期コンセプトの時点では、時間単位の高精度な見積りにはあまり意味がなく、月単位の大まかな見積りで十分ですが、詳細設計の完了時点では、時間や日単位で見積りを出すことができるし、そのほうがターゲット・コミットメントの決定に役立ちます。
5.一点見積りより二点見積り
ようやく実際に見積りをします。
一点見積りは、3時間や2日など、範囲のない見積りのことです。そして、二点見積りは、2~4時間、1~3日など、範囲のある見積りのことです。ここでは、両方の見積りを試してみましょう。
1.記録するで集めたデータを参照し、見積もる対象のチケットに近いチケットをいくつか選択します。それらチケットの実工数を参考に、見積もる対象のチケットがどのくらいの工数になるかを想像します。より正確性を高めるための手法は、次の見積りプラクティス以降で紹介しますが、ひとまず想像で数字を出して大丈夫です。(メンター向けの補足としては、ここまでにアサインするタスクを、できるだけ同系統のものに揃えると良いでしょう)
見積もった工数を見積りとして使うのが、一点見積りです。ここでは、例として10時間と見積もったとします。
もう少し進化させて、さきほど見積もった工数を最有力ケースとして扱い、4.チケットが完了するまでは不確実な要素が常にあるで紹介した不確実性のコーンを取り入れます。最有力ケースにばらつきを反映させて少ない側の見積りと多い側の見積りを計算します。例えば、アサインされるチケットの多くは要求が確定しているでしょうから、要求の完了時点の最有力ケースが10時間の場合は、少ない見積りは
この2つの見積りの範囲である、6.7~15時間を見積りとして使うのが、二点見積りです。
さて、ふたつの見積りを行いましたが、一点見積りの10時間と、二点見積りの6.7~15時間は後者のほうが優秀なので、積極的に二点見積りを使っていきましょうという話をします。
まず、4.チケットが完了するまでは不確実な要素が常にあるで説明したとおり、チケットは特定のこの瞬間に完了すると言えるものではありません。一般的に次の図のような分布になっています。
図1-3
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 37). 日経BP社. Kindle Edition.
図の分布をより表現しているのは、10時間という見積りより、6.7~15時間という見積りです。前者は10時間の時点で完了する確率を表せていませんが、後者は、10時間の時点で完了する確率が50%以下であることを表せています。
これは振り返りの際にも役に立つ情報です。このチケットが実際には10時間で完了したとき、一点見積りと比べると、見積り通り完了したことしか分かりませんが、二点見積りと比べると、もっと時間がかかる確率のほうが高かったが、それより早く完了したことが分かります。
さて、今回は初めて見積りを行いました。1.記録するのスプレッドシートをカスタマイズして、進行段階ごとの二点見積りや最有力ケースの見積りなどを記録する列をつくると良いでしょう。
6.数える>計算する>>>判断する
5.一点見積りより二点見積りで見積りを作成する際、似ているチケットの記録を参考にそれっぽい見積りを出しました。これは類推見積りという手法を簡素にしたものです。この手法より正確性の高い手法に、数えること、計算することがあります。
数えること、はそのまま、チケットの見積りに影響する要素を数える手法です。ただ、数えたらそれがそのまま見積りになることはほとんど無いので、数えた結果を何らかの計算によって加工して見積りとするのが、計算することです。
数えるものは様々あり、数える難易度や見積りへの影響度合いも多様です。例えば、何らかのAPIを作成するチケットを見積もる場合、次のような数えられるものがありそうです。このうち、見積もるチケットと関連性の高いものを数えると良いです。
- 参照するDBのテーブル数
- 依存する外部サービス数
- APIサーバー以外に依存するコンポーネント数(Lambda・S3など)
- 影響プラットフォーム数(Android・iOS・Windows・macOS・Quest2など)
- エンジニアリング要求の数
- ファンクションポイント
- ユースケース数
- 用意するドキュメント数
- テストケース数
これらを、1.記録するで集めた記録を集計した過去のデータ(DBテーブル1つあたりの平均工数や、ファンクションポイント1つあたりの開発・テスト・文書化に要する平均工数など)を用いて加工します。自分が初めて担当する領域のチケットなど、過去のデータが足りない場合は、有識者に提供してもらうと良いです。
計算した結果が出たこの段階で、多くの場合は有用な見積りになっているはずです。ですから、ここからさらに判断による加工をするのはおすすめしません。主観は見積りを短くしようとする力学が働いており、正確性に欠けることになります。また、主観が混ざると、その判断は記憶や記録に残りにくいので、振り返りが困難になります。
いわゆる専門家の判断というものは、最も正確さに欠ける見積り手段だ。見積りは、具体的な指標に結び付けることができた場合に、最も正確になる。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (p. 157). 日経BP社. Kindle Edition.
突然見積りを答えないといけないとき
最初のうちは無いと思いますが、EMやPMに即興で見積もることを要求される場合があります。即興の場合、手元にデータが十分にない場合が多いですから、判断に頼るしかないと思うかもしれません。が、できる限り判断を使わないように粘ってください。
最低限20秒だけ考える時間をもらいましょう。20秒くらいなら黙っていてもそんなに気まずくならないと思います。その時間で、機能の数や画面の数やテーブルの数など、数えられるものを数えましょう。数えた数を過去のデータ(スプレッドシートなどパッと開ける場所にまとめておくと良さそう)をもとに計算しましょう。計算結果が中規模以上であることが分かったら、より難しい要求である可能性があるので勘で割増しましょう。見積もった数字の精度は低いほうがよいです。
また、見積り結果を伝えるときは、正確性を著しく欠いた見積りであること、より正確性の高い見積りのためにはもっと時間が必要であることを前置きしましょう。
さいごに
私が感じている良い見積りのメリットとして、高い正確性の見積りを出せるようになると、想定していた未来ばかりが起こるようになるということがあります。これは精神衛生に非常に良いです。ですので、見積りをマスターするのはとてもおすすめです。
私もまだ道半ばですが、一緒に見積りをマスターしていきましょう。
また、なにか考えがある方には、チーム開発経験の浅い新入社員に見積りをマスターしてもらう方法B、C、、、の公開をお待ちしています。
え、クリスマスはもう半年も過ぎてる？そんな......
盛大に見積りを間違えました。
明日は、こんぱいるさんのcluster2022年の加速です！
補足
クラスター社の開発環境・開発フローのうち、見積りに関係する部分を補足します。
我々は、様々な粒度のTaskとBugをチケット管理しています。また、それらをひとまとめにしたEpicと呼ばれる開発単位も存在します。毎週のリリースフローに、Task・Bug・Epicが乗り、QAを経て公開されます。
見積りの対象は、Task・Bug・Epicのチケットです。
見積もる要素は、主に工数です。工数をもとに必要な人員やリリーススケジュールを検討します。
基本的には自分が担当するチケットは自分で見積もることになっています。ですので、メンターや上長からアサインされたチケットは、自分ならこのくらいの工数が必要だな、ということを見積もる形になります。
Task・Bug・Epicの規模はおおよそ次のとおりです。
- 期間
- Epicは2週間~数ヶ月、Task・Bugは0時間~数週間
- 関係者(以下から必要な職能のみ参加)
- プロダクトマネージャー
- デザイナー
- エンジニアリングマネージャー
- ソフトウェアエンジニア
- QA
- 関係者数
- Epicは3~10人、Task・Bugは1~2人
なお、若手新入社員に割り当てられるチケットは、期間が2週間程度で関係者数3~5人規模のEpicや、期間が数日で関係者数が1~2人規模のTask・Bagが多いです。成長に合わせて、徐々に担当するチケットの規模が大きくなります。
また、サーバー開発に限った要素ですが、主に使用するプログラミング言語はGoです。
開発フローについてより詳しく知りたい場合は、こちらのブログをおすすめします。
Discussion