はじめに
本記事では、フリーランスエンジニアとしてどう開発していくと消耗しないかを書いています。
また、ついやらかしてしまう見積りの甘さについて簡単に解説します。
交渉が全て
戦いは見積りを出す時から始まっています。見積りには大きく分けて以下の2パターンあります。
- 要件定義を全て満たす機能を開発するための見積もり
- ある金額で実装できる機能のみを実装するための見積り
要件定義を全て満たす機能を開発するための見積りでは、自分が不利にならず利益も出る金額で見積りを出します。
ここで遠慮して安い金額で短期間の見積りを出すのは自分だけではなくクライアントさえも不幸にします。 なぜなら、納期は開発する前に完全にわかる物ではありません。もしも途中で納期を伸ばす場合はその分、サービス残業をしていることになります。良かれと思って出した見積りが自分も損して納期も守れないとなるとお互いに嫌な気分で開発が進みます。
次にある金額で実装できる機能のみを実装するための見積りでは、遠慮せずこの金額ではここまでしか実装できませんと言うようにしましょう。金額が安いのに全部実装できますと言うのは破滅への始まりでしかありません。
完璧な見積もりはない
(図はソフトウェア見積り 人月の暗黙知を解き明かすから引用)
この図は見積の不確実性を表しています。見積りを出した初期は工数が多過ぎたり、少な過ぎたりしてプロジェクトが進んでいくに従って不確実性がなくなっていくということを表しています。
経験によってこの不確実性がわかったり、プロジェクトを進めてからじゃないとわからない不確実性もあります。なので、最初の見積りを適宜変えてもらうみたいな開発をしていく必要があります。
クラウドソーシングでは、そもそも開発について見積りは変わるという認識がないクライアントがほとんどなので気をつけないといけません。
実際に駆け出しの時は見積りを甘くしてしまうのはしょうがないと思います。そのプロジェクトの実績値をデータとして蓄積し、過去のプロジェクトと似ている場合はその実績データから規模感を算出して見積りを出すという方法もあります。これがタスクリストよりも正確に見積りを出す方法の一つです。
見積りはプロジェクトの成功の大部分を占めていると個人的には思います。ぜひ、良い見積りを出すようにしましょう。
参考文献
ソフトウェア見積り 人月の暗黙知を解き明かす スティーブ マコネル
https://www.amazon.co.jp/dp/B00KR96M6K/ref=cm_sw_r_tw_dp_3YNSBY0F0TMVF59JSGHE