LoginSignup
3
5

More than 3 years have passed since last update.

さらっと「これどれくらいでできる」って聞かれたときの対処法

Posted at

「そっすねー3ヶ月くらいじゃないすかー?」

根拠のない予測は地獄の始まりです。

「こんなはずじゃなかった」の連発でもともと想定していた期間の
2倍、3倍の時間がかかってしまったなんて事にもなりかねません。

どれくらいの時間で終わるか考えることを「工数見積り」とか「工数予測」などといったりします。
私が最初にエンジニアとして働いた環境では工数見積りの方法について
誰も知見を持っていなかったのでなんどか痛い目にあいました。

書籍を読んだり、外部のエンジニアに話を聞いたりしながら工数見積り術を学んで
小規模なプロジェクトであれば大体ちゃんと予想できるようになってきたので
ざっくりとした工数見積りのコツを昔の自分のような人にお伝えできればと思います。

目次

  • なぜ工数見積りは難しいのか。
  • 最速最小のプロトタイプを作る。
  • 影響範囲を考える。

なぜ工数見積りは難しいのか。

1. 依頼者が何を欲しいのか最初の段階では依頼者も知らない。

嘘みたいなホントのよくある話です。
相手がソフトウェアの専門家でない場合、完成品の要件はおろか、画面イメージまで定まっていません。
この段階で完璧な要件定義をしようとすると依頼者はその場ではOKを出すものの
完成品をみてから根底をひっくり返して来ることがあります。
ソフトウェアは一回作ったら最利用できるため、
新規の開発はほぼ必ず何か今までにない事が含まれています。

2. 人間は未来を正確に予測できない。

基本的にソフトウェア開発は今まで作った事がないものを作る事になります。
やった事がないことがどのくらいかかるかという予測はとても難しいです。
過去に似たようなことをやった事がある場合でも完全に再利用可能なものでなければ
思わぬ落とし穴がある事があります。
以前使ったライブラリの思わぬところにバグがあったり、
今回使う事になったライブラリとのバージョン不整合があったりします。
また、データを受け取ったら中身が言われていた物と違ったり、
開発環境のデータと本番環境のデータが違うといったこともあり得ます。

3. 性格と経験によってバラツキが生じる

慎重な性格の人や、過去に見積りで失敗して痛い目にあった人は余裕を持った予測をする傾向があります。
余裕を持って予測することは非常に大事ですが度が過ぎるとその人の評価が下がったり
プロジェクトがなくなってしまい、ビジネスが出来なくなってしまいます。
チームで作業する場合、人の予測を理解しないまま鵜呑みにしないほうがいいでしょう。

最速最小のプロトタイプを作る。

1. 不確実性の一番大きいところを潰す。

プロジェクトを始める前が最も見積りが難しく予測した工数が実際の工数と前後してしまう可能性が高いです。
より細かい要件定義や、設計、実装を進めていく中で徐々に正確な予測ができるようになります。

予測が難しい事、不確実性が時間とともに減少していく様を不確実性コーンと呼ぶ事があります。
工数見積りの精度がプロジェクトの始めで依頼者に理解して貰う際に役に立つことがあります。
image.png

プロトタイプを作ることはこの不確実性コーンの一番大きい左側から右側に進めていく作業です。
環境の構築、技術的に最も難しい所の検証までこの段階でできると後の予測が楽になってきます。

2. 作っているものが正しいか確認できる。

プロトタイプを作ることで依頼者との認識のすり合わせがしやすくなります。
全体の画面イメージとあわせて期待するアウトプットの認識をすり合わせましょう。
正確な要望、要件の理解が正確な見積りの最低条件です。

影響範囲を考える。

1. システムの影響範囲

ソフトウェアの多くはフロントエンド(UI)、バックエンド(API, データベース)を持っていて
工数を予測する作業はどの範囲に変更が必要なのかを見極めましょう。
この方法はプロジェクトの全貌が見えていないのに予測しなければならない際に有用です。
UIのみ変えればいい場合とUIに加えてビジネスロジックに変更がある場合は
UIのみの場合と比べて2~4倍時間が必要などというと納得してもらいやすく、
作業を依頼する側も概算を立てれます。

また多くの開発されるソフトウェアは外部のシステムと連携しています。
既存のデータベースに変更を加えたり、他システムで使っているAPIを利用したりすることがあります。
これにより必要な工数が長くなることもあれば短くなることもあります。
どちらにせよ外部システムとの連携は工数に大きく影響してくるので
必ずできるだけ細かく仕様を確認するようにしましょう。

2. 人の影響範囲

プロジェクトによっては自分のチームのみで完結しない仕事もあります。
そもそもの責任者が営業サイドであったり、必要なデータは多部署が持っていたり、
あったこともない人が要望を出してくることがあります。

依頼者がいってきたことをただ聞いてやっていると思わぬところで今までやってきた作業が
全く意味がないものになってしまうことも世の中では珍しくないことなので
依頼者の後ろに誰がいるのか、依頼者とコミュニケーションを取りながら予期せぬどんでん返しを
極力無くしていきましょう。

また、データの連携は送るだけと思っていても意外と時間がかかる事があるので
期間を長めに見積もりつつ最優先で対応することをおすすめします。


以上、いかがでしたでしょうか。
今回は正確に工数を予測することを主眼として書きましたが、
そもそも必要のないものを作らず、利用者に対して価値のあるものを作るために
要件定義をしっかりする事も重要です。

これを読まれた方が私のように自分の過去の気楽な予想に苦しめられることの無いように、
また価値ある製品を作っていくために少しでも役に立てば嬉しいです。

3
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
5