三人集まって見積もりの話をする
用事の後、甘いものを補給しようと同行していた方達とカフェに入る。お二人とも30代と見受けるエンジニアの方である。三人それぞれ所属する組織も違うし、業種セクターも違うのだと話しているうちにわかった。
顔見知りであるし、ソーシャルネットワークで繋がっているのでなんとなく興味を持っていることを垣間見ている。それぞれの趣味の話をしたり、IT業界的な話に移ったり、雑多なことについて会話する。
そうした話の中で、見積もりをどうしているかを尋ねてみた。一人は30代と言えどもまだ若い。ただ、エンジニアの経験は所属する組織に依存するから年齢に関係なく知見を持っていることもままある。うっかり思い込みで決めつけると痛い目に合う。訪ねるときは謙虚でなければならない。
前置きはそのくらいで尋ねてみると、想定していた『過去実績』で工数を見積もっているようだ。言葉に自信なさげな感じを覚えたのでも、しかすると見積もりはプロジェクトで担当する範囲や配下のメンバの作業工数くらいなのかもしれない。
もうお一人は、キレッキレの方である。そういう方はご自身も謙虚な物腰で話される。見積もりについてお話を伺うと、製品導入とコンサルティングなので見積もりはあてにならないのだという。強いて言うなら『類推見積もり』かもしれない、とおっしゃる。
話の流れ的に過日の見積もり本についていくつかの問題提起をしてみる。
- 結局、見積もりは各種手法があるが、使えるのは過去実績による類推見積もりではないか
- 類推見積もり自体も、過去実績の収集自体の精度が低く信頼性を伴っていないため他の見積もり手法に比べましな方程度ではないか
- 類推見積もりから、インタフェース数、プロセス数の基準を設けて閾値を設けなければならないのではないか
甘いものを口にしつつ、概ね同意を得る。
この問題提起に至る前に、いくつかの前提を踏まえている。
見積もり手法は、対象となるシステムの構築形態により適合できない手法がある。例えば、パッケージをカスタマイズ、アドオン開発するようなソリューションビジネスの場合にFP法を適用するのはパッケージというブラックボックスの扱いに困るのではないか、などである。
また、PoCの要素が強い製品開発それも試作的なものは見積もりようがなく、スプリントゼロのようなプロセスを踏まなければ当てずっぽうでしかない、などのコメントがあった。
類推見積もり自体も、その実績値の収集の方法はバケツで掬っているようなものだから、間接工数を多く含めており正味での精度は低い、という意見について同意のコメントもあった。
導入自体は微々たる工数であるが、その後の運用での調整とそれから得られるアウトプットから、運用で蓄積するデータのゴミを捨てる補正の工数はギャンブルのようだ、などコメントがつけられている。
類推見積もりでは、単に外部インタフェース数だけではなく、内部プロセス数を設け、閾値として仮置きし、そうした設定値の調整を継続して行う必要があるのではないかとう意見もあった。若干、こうした工夫についてはFP法のノウハウがあるのかもしれない。
こうしたことや過日の見積もり本を踏まえ、一旦整理すると、
- 誰の立場で見積もるのか
- 見積もるのは工数か、システム全体か
- 見積もる対象と見積もり手法の適合性を見極めているか
- 参考となる過去データはあるか
- 過去データの精度は把握できているか
- 見積もりを実行する際のチームのモデルを持っているか
- 適用技術の習得度合いを把握しているか
- システム開発手法は確立しているか
- リスク識別のプロセスで調整を行うか
あたりを踏まえて見積もりの何を話すかを確認しながらでないと噛み合わないような気がする。
ただ、エンジニアにフォーカスされるのは、タスクの工数見積もりであってシステム化にかかる全体の見積もりではないことが多い。
まあ、ケーキを焼くときに材料を計量する工数の話をするのか、調達から焼き上がりまでの総見積もりまでかというようなものなのだが。
