見積りという作業について感じたこと

先日、チームのメンバーにとある機能の開発を進めてもらうにあたり、見積りをしてもらいました。そのときに感じたことをメモしておこうと思います。

アジャイルな見積りと計画づくり（原題: Agile Estimating and Planning (以下、AEP））には、見積りについて、以下のように書かれています。

(p.29-30)
見積りや計画づくりがそんなにも難しくて、プロジェクトの終わりになるまでは正確に見積もれないのであれば、そもそも見積りや計画づくりをするのはなぜだろうか？
わかりやすい理由として、働いている組織から見積りの提出を求めることが挙げられる。
（略）いずれの場合にも計画や見積りが欠かせない。見積もるのが難しいので計画やスケジュールは作成しない、という言い訳は通用しない。
しかも、見積りや計画づくりという大変な仕事に取り組むべき理由は、こうした消極的なものだけではない。もっと根源的な動機があるのだ。

「もっと根源的な理由」については後述しますが、 今回のことは、まさに上述のことが現れているなと思った出来事でした。

起こったこと

とある機能の開発をAさんに依頼し、大枠の画面設計やアーキテクチャの設計を進めてもらいました。
それらの設計は決めることができ、大きく分けてフロントエンド、バックエンド、バッチ処理の開発が必要そうだということが明らかになりました。
後続作業としてタスク分解や工数見積りを行い、開発のスケジュールを立てようということになりました。^[1]
ただ、Aさんはこれまでは各々の要素を個別のタスクで触ったことはあるものの、ここまで本格的にすべてを統合した開発を行った経験はありません。
そのため、より開発経験が豊富なBさんにサポートしてもらい、見積りをしてもらうことにしました。

これを受けて、AさんとBさんが見積りの相談をしたのですが、ここでの議論が非常に有意義だったなと感じました。 単純に見積り工数を算出することだけではなく、

• 実装上の注意点
• 仕様上、問題になりそうなポイント
• タスクの切り方
  • 例: フロントエンド、バックエンド、バッチという切り方で作業をしてしまうと結合が遅くなってしまうので、例えば、検索などは主たる要素ではないので、後回しにして、メイン導線だけでも通して動くようにした方がよい

など、様々な観点で議論が行われました。

AEPでは、よい計画づくりには以下のような特徴があり、これらが見積りを行う「根源的な理由」であると書かれています。

• リスクを軽減する
• 不確実性を減らす
• 意思決定を支援する
• 信頼を確立する
• 情報を伝達する

AさんはBさんの視点での問題になりそうなポイントや気づいていなかった設計上の課題点を得ることができ、見積り実施前よりも、確実によりよい開発を行えるようになったと思いますし、
今回の話は、まさにこれらが現れていたかと思っています。
また、BさんもAさんのタスクの概要を知ることができたので、やろうと思えば、今回のAさんのタスクの一部をBさんに手伝ってもらうといったこともやりやすくなったはずで、この点も大きなメリットだったと思っています。

まとめ

今回のように、ある程度の規模の開発においては、なるべく初期の段階で、チーム内でディスカッションを行い、
お互いの知識やスキルを補完し合い、計画を立てていくことで大きなメリットがあるということを（いまさらではありますが）学びました。
AEPも改めて読み返したいと思いましたし、今後もこのことは意識していきたいと思います。

脚注

1. アジャイルな開発では、ストーリーポイントなどによる見積りを行い、予定開始日、終了日といった具体的な日付を決める見積りを行わないことも多いとは思いますが、いまのチームでは、おおまかにではありますが、日付をベースにした予定を立てています