サムネイル:見積もりの時に意識していること

はじめに

この記事は DMMグループ Advent Calendar 2024 の16日目の記事です。

こんにちは。プラットフォーム開発本部第2開発部決済グループ購入チームのチームリーダーの市原です。

決済グループは、DMMグループ Advent Calendar 2024 5日目の記事の決済基盤の技術的負債に向き合うにあるように全社的な影響があるプロジェクトをはじめとして様々な要求を受けるグループです。要求に対しては工数や工期の見積もりを都度出しており、出した見積もりは要求実現の判断材料として利用されたり、要求に対する対応を実施する場合の計画のベースになったりします。

こうした見積もりに対する関わり方としては私自身で「見積もり作成」と、チーム内へ「見積もりのレビュー」があります。今回は、そういった見積もり時に意識していることを記載します。

見積もりの時に意識していること

見積もりに対して期待されている精度と成果物を確認する

見積もりと一口に言っても、期待されている精度は時と場合により変わります。例えば新規のプロジェクトを実施するかどうかを判断するために工数の見積もりが必要という場合は、大雑把な数字でもいいので素早く見積もりを出す必要のあることが多いです。一方で、プレスリリースを伴うようなプロジェクトのリリース日を決定する材料として工数の見積もりが必要な場合、見積もり結果の誤差が小さくなっている必要があります。そのため、必要な精度の見積もりを適切な時間で見積もれるようにするために、見積もり提出の期日と合わせて、期待されている精度が超概算・概算・詳細のうちどれに該当するかをまず確認しています。

また、工数見積もりだけが必要なのか、工期も合わせて見積もり結果が必要なのかというのは場合によって変わるので、都度確認をしています。これは、工期を見積もる場合は工数を踏まえたうえでそのプロジェクトへのアサインをどうするか、という観点での検討が必要になり、他のプロジェクトの状況を踏まえた検討が必要になってくるためです。

見積もりに対する前提条件・実現想定を記載する

下記の観点で情報をまとめ、また他のメンバーの見積もりをレビューする際にも確認しています。こうした形で見積もりの前提条件や実現想定を記載することで、見積もりを以降のプロセスで詳細化して見積もり結果が変わった場合にも、その変わった理由が説明しやすいようにできると考えています。

(1)見積もり時点での要件はどういったものか
- 要件をまとめた資料があればその資料への URL を記載します。
- また、内容が大きな場合はその概要を記載します。これは要件の内容自体が大きい場合、 URL 先の資料から内容を把握すること自体に時間がかかりがちであるためです。
(2)要件に対してどのような実現方法を想定しているか
- 特に超概算や概算の時点では詳細な設計まではできないこともあり、決済システム全体としてどのような形で要件を実現するかといった情報を簡単な図や文章で記載します。
(3)見積もり時点での不明点を明確にする
- 特に超概算や概算の時点では要件としてまだ決まっていない点もあるため、そういった部分を見積もりに対するリスクとして記載をします。

(2)について補足すると、例えば下記のような形でシーケンスを書くなどしています。

図1:要件に対する実現方法の想定の例