この記事は、Lancers（ランサーズ） Advent Calendar 2024 の8日目の記事です。

はじめに

こんにちは！ランサーズの若林です。
今年は社内開発と社外の顧客に向けた提案や実務など幅広い方とエンジニアリングのお話をしてきました。
その中で多くの見積もり業務に直面し、その難しさを改めて実感しました。この記事では、実践してきた見積もりと、見積もりを通したコミュニケーションについて、共有したいと思います！

見積もりとは

見積もりは単なる時間やコストの予測業務ではありません。目的地に到達するための道のりを予測し、潜在的なリスクや変数を考慮するプロセスです。見積もりを共有することで、タスクの難易度やリスクを第三者と共有できます。

例えば、料理のレシピを友人に説明するとき。「30分で完成」と言うだけじゃなく、「初心者には少し難しいレシピで、慣れないと1時間くらいかかるかも。事前準備と同時調理が必要だよ」と伝えます。これが、見積もりのコミュニケーションです。単なる時間ではなく、作業の複雑さや必要な準備を相手に伝えられます。

見積もりは、顧客や社内関係者との期待値を適切に調整するコミュニケーションツールです。

非エンジニアに見積もりを通じて伝えることができること：
* 潜在的なリスクを事前に共有する
* 顧客と開発チーム間の認識のギャップを埋める
* 現実的なスケジュール設定を促す

見積もり実践

プロジェクト内機能開発の見積もり

社内機能開発では、フィボナッチ数列を用いた見積もりを行っています。

フィボナッチ数列とは

フィボナッチ数列は、0と1から始まり、直前の2つの数を足して次の数を作る数列のことです。
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...

1ポイント：約1時間の軽微なタスク
2ポイント：半日程度の簡単な実装
3ポイント：1日程度の中規模タスク
5ポイント：2-3日の複雑なタスク
8ポイント：1週間程度の大規模機能
13ポイント：2週間程度の複雑なシステム開発

なぜフィボナッチ数列なのか？

この数列は、数字間の比率が徐々に拡大するため、タスクの相対的な大きさを直感的に理解しやすくなります。
ポイントで議論することで、チーム内でのコミュニケーション言語が統一されます。
「このイシューは8ポイントかかるのであれば実施の検討をした方が良いかも」「1ポイントでできるなら今週のリリースに乗せられそう」、というような会話ができます。
同じ開発資産を共有しているメンバー内では複雑さの表現が容易なフィボナッチ数列を用いた見積もりは、イシューのサイズやスケジュールに対する期待値を調整することができ、効果的に活用できています。

顧客向け工数見積もり

顧客向け工数見積もりでは、ファンクションポイント法を活用しました。
これは、ソフトウェアの機能的な規模を客観的に測定する手法です。要件が明確な場合、機能の数や複雑さを分析することで、かなり精度の高い見積もりができます。

要件が明確な場合、機能の数や複雑さを分析することで、かなり精度の高い見積もりが可能になります。
「この機能は処理数が3で外部連携もあるのでこのポイントになります」というような客観的にわかりやすい指標になるため、顧客に対して見積もり説明をする際にも大きなずれが生じることなくコミュニケーションを取ることができました。
また、顧客の想定している工数とのギャップがあった場合には、こちらが想定している連携処理が不足していたりとリスクやタスクがあるなど認識もれの発見にもつながりました。

実際に、この手法を用いた見積もりシートの雛形を作成することができたため今後の顧客向けの見積もりでも利用できる状態になりました。

ファンクションポイントを用いた見積もりまで精度を高めるには要件の詳細化、タスクの細分化が不可欠です。
顧客への提案初期の概算見積もりの段階では今回作成した見積もりシートの粒度まで精緻化されていないことが多いので、今後概算見積もりの精度や概算見積もりにおける期待値調整をどこまでできるかというのが課題になっていきそうです。

期待値調整について

非エンジニアにわかりやすく丁寧に説明し、プロジェクトの本質的な課題を共有するのは、エンジニア側の責任です。このプロセスを省くと、事業部や顧客とスケジュールの認識がずれたり、運用コストが想定以上にかかったりしかねません。
実際に、今年着手していたプロジェクトでも難易度やその工程の大切さがうまく連携できていなかったことによりスケジュールやスコープが固まらないということがありました。これは大きな改善ポイントです。

追加作業や要件の変更が発生したら、その都度コミュニケーションを取ることが大切です。
変更によって別のタスクに影響が出てスケジュールを見直すことによるリスクがちゃんと握れていたのか、など振り返ると反省をすべきポイントはたくさんあります。変更影響をエンジニアが楽観的に見積もってしまっていた可能性もあります。

見積もって終わりではなく、リスクや課題を含めてプロジェクトの関係者全員が同じ認識を持てるような、定期的なコミュニケーションの場の重要性も改めて感じました。

おわりに

常にプロジェクトや状況は変化するため、完璧な見積もりを作ることは不可能ですが、見積もりの数値に現れるプロジェクトの複雑さや規模を元に関係者とコミュニケーションをとることが大事だと改めて感じました。
プロジェクトのゴールに向けて、見積もり数値からゴールの再定義やリソースの再構築などステークホルダーと一緒に同じ方向をむいて検討できたら良いなと思っています。