開発計画を立てるときの工数見積もりについて
ストーリーポイント
アジャイル開発において次に着手するタスクをスクラムイベントなどでエンジニアが決定し、タスクの難易度をフィボナッチ数列の数値で決定します。この難易度をストーリーポイントと呼んでいます。ストーリーポイントは本来工数を見積もるための道具ではないですが、過去の実績から難易度から工数を算出することができます。
ただし、エンジニアにタスクの難易度を見てもらわないといけないためPMだけでは工数見積もりできないのが欠点です。
安全係数の決定方法
どういった手法を取るにしても、工数の見積もりを行っても実際には多くの工数を要することもあります。だからと言って、安全係数を多く取ってしまうと過剰な投資を行ってしまいエンジニアの手が空いてしまいますし、ビジネスに負の影響を与えてしまいます。
安全係数は決まった数値は無く、チームメンバーの状況やPMから見たタスクの難易度などから決定することになります。従って、PMの経験に大きく依存してしまいます。一般的に概ね見積工数の1.1倍〜1.5倍ほどで設定します。ただし、工数が極端に少ない場合は単純な係数ではなく1人日ほど追加するなどします。
当たり前かもしれないですがビジネスの状況に時間的もしくは金銭的余裕がある場合は高めの安全係数を設定するようにしています。一方でチームメンバーの力量も見通せず、ビジネスに余裕が無い場合は安全係数は低めにせざるを得ないです。この場合、間に合わなかった場合の最悪のケースを想定して実装予定の機能の中で削れそうなものやPJ中盤でも変更できそうな箇所を予め見繕って置くことが大切です。つまりリスク管理しましょうということです。
エンジニアに工数算出の協力を求めるか
工数見積や計画段階でエンジニアに協力してもらうとエンジニアの手が止まってしまうので、協力を求めるか非常に悩ましいと思います。
しかし、個人的にはチーム立ち上げ時であれば積極的に工数見積もりに協力してもらったほうが良いと考えています。一般的にチーム立ち上げ時＝PJ開始時点となるので、実績も無く見積もりに必要な情報が少ないことが理由です。同じチームである程度開発実績が蓄積できれば過去の開発状況を考慮してPMだけで開発計画を立てることができます。
もちろんPM自身がエンジニアでありコーディングできるならエンジニアの協力無しに開発計画を立てることができます。ただし、自身のスキルとエンジニアのスキルに乖離があることは忘れないようにしましょう。
ALTURA Xの開発チームで採用している方法
弊社は協力会社から参画頂いている人数が多くチームメンバーの入れ替わりが頻繁に発生します。当初はストーリーポイントで工数算出することを目指していましたが、チームメンバーが入れ替わってしまうと難易度評価がぶれてしまい安定しないため諦めています。
弊社では係数法を用いて、開発する機能が関わる画面の数とAPIエンドポイントの数から工数を算出しています。また、安全係数については機能の複雑さや関連する機能の数をもとに1.1〜1.3程度にしています。また、工期全体に対しても安全係数を1.1程度かけて若干余裕をもった開発スケジュールにしています。ただ、精度はそれほど良くないため今後も弊社の開発スタイルにあった工数見積方法を模索し続けることになると思います。
終わりに
簡単に工数の見積方法について説明させていただき、安全係数の決定方法や工数算出にエンジニアの協力を求めるかについて述べさせていただきました。
工数見積を諦めるPMもいますし、工数見積に意味は無いという話もあります。一方で開発開始時にビジネス側からは必要な人数とリリース予定日を確認されるので工数見積は必然的に必要になってしまいます。一つの目安として工数見積はできたほうが良いので個人的には工数見積を諦めるのではなく、リスクを加味して算出しつつ、精度が良くないことはステークホルダーに説明する努力をし続けることが大切だと考えています。