デジタルクエスト社のアドベントカレンダー１３日目担当の綿引です。
エンジニアの方々は避けて通れない「見積もり」という工程。
「見積もり」が楽しい！って思える方は少ないですよね。
工数を短くすれば自分の首が締まるし、長くすれば「こんなかかるの？」とお叱りを頂くし。
私なりのスマートに片付けて先に進めるためのポイントをまとめました。
ポイント① 見積もりやすい粒度
要件・やりたいことなんかを洗い出していると、大きすぎるものや小さすぎるものが混じってきます。
大きすぎるものは、工数のブレ幅が大きくなりやすいですし、小さすぎるものは見積もり内に含まれないことが多く発生します。
見積もり時の最小単位をどこに設定するかでも変わってきますが、0.5人日程度までに留めておくことが無難です。
0.1や0.25程度で片付くタスクは、１つにまとめて見積もることをオススメします。
ポイント② 不確定要件
初期の見積もり時には、決まりきっていないことが紛れ込んできます。
これはある程度仕方のないことなので、不確定を是として見積もりを提出するのが良いでしょう。
例えば、○○という仕様なら○人日、△△という仕様なら△人日、といった提案を付加するとなお良いと思います。
ポイント③ 誰がやる基準に併せるか
エンジニアのスキルやレベルは当然ながら人それぞれ異なっています。
見積もりを行う際には、「誰がやるか」を念頭に置くのがベストですが、勝手に見積もられて押し付けられるメンバーからすると堪ったものではありません。
担当が決まっているのであれば、担当者に見積もりをしてもらいましょう。
ポイント④ 見積もりの精度
③と似ていますが、人が行うことなので、機械的にやろうとしても余計なものが混ざり込んできます。
そこで、見積もり時にはできるだけ2人以上で相見積もりを行うのが良いです。
その分のコストがかかってはきてしまいますが、担当者間の認識をあわせる場や実装方針などの議論にも発展して、最終的に見積もりの精度が上がります。
コードレビューならぬ見積もりレビューとして弊社でも活用しています。
ポイント⑤ お客様あっての見積もり
見積もりをしていると、「何のために」「誰のために」という観点が置いてきぼりになりがちです。
プロダクトだけに目を向けるのではなく、その背景までを含めて理解することでこちらから提案することも可能に。
スクラム開発でのトレードオフスライダーのように、優先度を整理することで要件もスッキリすると思います。
ポイント⑥ 過去の経験を活かす
見積もりをする際は、過去の類似事例を思い出してください。
自分自身でなくとも技術は多少変わっていても経験した開発での工数感覚というのは大きくブレることはないでしょう。
潜んでいるリスクの検知にも役立つはずです。
ポイント⑦ お金と工数は分けて考える
この業界、当然のように”人月”という単位でやりとりがなされますが、エンジニアは極力この人月単価には触れない方がよいでしょう。
自分の尺度と会社都合での値付けは常に乖離しています。
エンジニアの価値換算を自身で行ってしまうと、そこがモチベーションの起点にもなりますので、任せられる環境に身を置いたほうが冷静な判断が下せるハズです。
ポイント⑧ バッファ
開発が終わってみると、見積もった工数よりも多かった・少なかったという話は当たり前のように出てきます。
少なかった場合は、さほど問題にはなりませんが、多かった場合は関係各位に迷惑をかけてしまいます。
期間に猶予が持てるようであれば、見積もり時点でスケジュールとお金のバッファを相談しておくと良いでしょう。
それが許されない状況であれば、優先度の低いタスクをスコープ外にすることをバッファとして相談しておくのをオススメします。
いずれにしても、エンジニア自身がバッファを各タスクに内包してしまうのは誰のためにもならない行為だと思いますので、事前相談推奨です。
ポイント⑨ 説明責任
各タスクに予定工数を割り振っていったものは、すべてお金に換算される数字ですので、説明できなければなりません。
経験則で見積もった場合に、説明し難いケースが出てくることもありますが、いずれも①での適切な粒度が維持できていれば問題にはならないでしょう。
④での複数人での見積もりを行っておくと、全員の理解も深まり、誰でもタスクに割り振った工数の説明ができる状態になると思います。
ポイント⑩ 契約形態
例えばお客様が「できたところを毎週確認したい」とアジャイル開発を希望された場合に一括請負契約は危険です。
プロダクトオーナーとしてお客様にも参加して頂くことを前提に、一部を準委任契約にしてもらう等の交渉をすることが無難です。
その他、”瑕疵”の考え方であったり、納品基準についてもトラブルの基となりますので、あらかじめ説明の上、理解してもらうことに努めましょう。
ポイント⑪ テスト
品質担保で重要なテスト工程ですが、低予算の場合には優先度が低くなりがちです。
各タスク消化時に単体テストを内包、テスト期間にて結合テスト実施というケースが多いですが、テスト期間にも不足機能の開発を行っていては本末転倒です。
システムの規模 (画面数や機能数) を基におおよそのテスト期間とその間の人員を想定した工数割り出しをしましょう。
中規模以上のプロダクトであれば、外部のテスト請負をされている企業様にお手伝いいただくのがベストです。
ポイント⑫ どうやって作るか
例えば、iOSアプリを作るといっても、多種多様な開発アプローチがあると思います。
お客様の都合 × 自社の都合 (経験とスキルセット) で最適な開発方針を定めるのが良いでしょう。
例にとったiOSアプリですと、Swift3,2,Objective-C,PhoneGapなど複数の方針があがりますが、エンジニアのエゴで決めることなく、作った後のことも考えて選定してください。
ポイント⑬ 見積もり法の活用
代表的な見積もり手法して、以下のような見積もり法があります。
- トップダウン見積もり法
- ボトムアップ見積もり法
- ファンクションポイント法
- 係数モデル見積もり法
状況に応じた使い分けができれば有効な手法です。
④で挙げた複数人で別々の手法でアプローチするのも良いかと思います。
ふりかえり
「見積もり」での当たり前を挙げてみました。
２０１６年は見積もることの多い年となりましたが、形となったモノの数を振り返ってみると、至らぬ点も多かったと自省しつつ、来年もまた、「見積もり」たいと思います。