概要
新卒でエンジニアとして働き始めて、苦労したことのひとつに「見積もり」があります。
インターンのときから「まずはちゃんと見積もれるエンジニアになろう」という目標はCTOとの1on1でも言われていたのですが、なかなかその理由までは理解できていませんでした。
しかし、実際に業務がはじまって少し長めの開発を任されるようになったときにその重要性を身を持って感じました。
単発のタスクではなく長期のタスクになると、開始前にスケジュールを引いてその進め方や進捗を都度開発チームやPMとすり合わせながら日々のタスク進行を行う必要があります。
見積もりをスケジューリングを行わず遅延させた新卒1年目のプロジェクト
僕が新卒で入社したマイベストにて任された最初の大きなプロジェクトが「商品のバリエーション掲出」というものになります。
プロジェクトの詳細は下記の記事でも書いたのですが、このときは既存の商品情報を送るエンドポイントの追加に加えて、新規に2つのエンドポイントを作成し。フロントエンド側で処理をしてデータを表示する必要がありました。
メンバーとしては僕と、フロントエンドエンジニア、そしてPMの3名で進行させたのですが、ざっくりそれぞれのタスクと初期のストーリーポイント見積もりは行ったものの、タスクの進行の進捗管理やスケジューリングは行っていませんでした。
その結果として、いくつもの問題が起きてしまいました。
- フロントエンド側でAPIの開発待ちが発生した
- 現在どのタスクが進行中で、どの単位でリリースできるのかという認識が持ちづらくなった
- いつ終わるのか、どのくらい遅延しているのか伝えづらくなった
- リリース間際でコンフリクトが起きて予期していなかった工数が発生した
結果として機能のリリースを1ヶ月程度遅延させてしまうことになりました。
悔しかった僕は、この失敗をふりかえり、見積もりと計画づくりについて改めて勉強し直してまとめました。
現在こちらの記事を書いているのはそれから1年ちょっと後ですが、改めて復習の意味でもこちらの内容を都度補いながら書いていきたいと思います。
見積もりとは
見積もりとは、ざっくりとの検討をつけることです。
何か製品をつくるときにはその原価や日数、経費などを前もって計算することです。
上記のプロジェクトの例では、一体作業にどれくらいの工数がかかるのか。それは何人で行えるのか、リリースはいつになりそうかなどを手を動かし始める前に検討をつけておくことを意味します。
しかし、見積もりを正しく行うはとても難しく、『Clean Coder プロフェッショナルプログラマへの道』p.141にも下記のような記述があります。
見積もりとは、ソフトウェアのプロが直面する活動のなかで、最もシンプルだが最も恐ろしいものである。ビジネス価値の多くは見積もりにかかっている。我々の評判の多くは見積もりにかかっている。不安や失敗の多くは見積もりが原因である。ビジネスと開発者を分断してきたのは見積もりだ。両者の関係が不信感に満ちている原因も見積もりだ。
見積もりがなぜ大事なのか
そんなに大変な見積もりなのに、なぜ行う必要があるのか？おおきく4つの役割があります
リスクの低減
見積もりを行い、事前にこれから行われる作業内容や工程を一度頭の中でシミュレーションすることで、起こりそうな問題を発見できます。
結果として起こりそうなリスクに対して適切に事前に対策を行ったり、場合によってはそもそものプロジェクトを取りやめるなどもできます。
意思決定を支援できる
リスクの話と関連して、事前に調査や見積もりを行うことで得られた情報が、その後のプロジェクトの進行に対しての実施や順番ぎめの判断材料とすることができます。
不確実性を減らせる
また、結果としてこれからチームが進むべき方向や取り組んだ先にある成果物がイメージしやすくなるため、それを足がかかりとして不確実性をへらすことができます。
信頼を確立する
進捗として成果物が出せない場合でも、事前に取り決めた計画の進捗として開発の成果を供給していることを伝えれれば、開発チーム外に対しての信頼を担保できます。
「見積もり」という言葉の曖昧性
コミュニケーションのなかで無意識的に「見積もり」という言葉を使うことも多いですが、実は見積もりという言葉は人によって解釈が異なることがあります。
下記の記事にも詳しくありますが、見積もりの信頼精度を意識して、それが「コミットメント」なのか単なる「見立て」でよいのかなどを「見積もりをお願いします」というお願いをされた段階で認識を合わせておくことが大事です。
見積もりがずれる原因
未来が遠すぎる
また、見積もりとは未来のことを事前に考える行為なので、当然ならが不確実性が多くあります。
遠い未来のことほど想像しづらく、近い未来は想像しやすいです。
見積もりの話をするときに有名な「不確実性コーン」というものがありますが、だいたいプロジェクトの初期には60〜160%のズレが生じますが、ステップ数が進んでいくほど見積もりの精度は上がっていきます。
最初に見積もったタスクについても、改めてプロジェクトが進行するにあたって「再見積もり」を行うことでその後のプロジェクトのスケジュールを正しく引くことに繋がります。
要件定義
また、開発を勧めていくにつれて、要件が変わることもあります。当然見積もりは事前に決めた要件をもとに算出されているため、要件が変わるとそのみつもりは変わります。
要件そのものが変わることはなくても、決めていた要件に考慮できていないケースがあったり、表現があいまいで固まっていないケースなどがあると、その結果として思ったよりも複雑な実装になり工数が増えるということもあります。
イレギュラーが発生する
スケジュールを見積もっても、だいたいの場合には正しくいきません。
- 障害が起きて対応しないといけない
- 外部サービスが落ちてしまい、予定通りの開発が行えなかった
- 開発者が体調を崩した
などなど、予期しないイレギュラー発生によって伸びてしまう（工数は変わらないけど工期が延びる）ようなケースもあります。
認知バイアス
また、人はだれしもバイアスを持っています。
想像よりも自分やチームの実力を過大評価してしまい、実際にかかる工数よりも小さく見積もってしまうということもあります。
見積もりを正しく行うためには
僕が新卒で入社したときには振られたタスクについて全くの検討がつなかったことが多かったのですが、だんだんと精度を上げることができました。
それは、自分の中で開発経験がたまり、その根拠をもとに新しいタスクの見積もりが行えるようになったことがあると思います。
しかし、そこで正しい見積もりができるためには、自分の中の開発経験の実際にかかった工数と作業内容がただしく記憶されていることが大事です。
最初の例では、新規で2つAPIを建てる必要があったときに、1つめで2日かかってのであれば、2つめのAPIを建てるときも2日程度かかることは予想できます。
タスクが終わったときに、そのタスクに対しての見積もりと実際にかかった工数を記録していき、その差分と原因を自分の中で修正していくことがよかったと思っています。
分割する
そのうえで、作業を細かくするのは振り返りの際に役立ちます。
「APIを建てる」というタスクを、Modelの実装、スキーマの実装、GraphQLの実装、などのように分割できるところまで文化値して、それぞれのタスクに対しての見積もりを出して、それぞれの作業に対しての見積もりを行うようにします。
結果として、次に振られるタスクがModelの修正だけで済むのであれば今回のAPIの実装の経験を生かして正しく見積もることができます。
さらには、小さいタスクのほうが見積もりがしやすいので結果的に正しくなりやすいという副次的な効果もあります。
小さく分割したタスクのうち、やったことがないものやよくわからないものから着手して、なるべく不確実なものをなくしていくのも大事です。
調査の時間をつくる
「どのくらいかかりますか？」という質問に対してすぐに答えたくなりますが、上でも書いたように「コミットメント」を求められている可能性もあります。
そのようなときには、ちゃんと調査する時間をもらって正しく見積もることも大事です。
- 技術調査する
- 詳しそうな人に見積もってもらい参考にする
- 作ってみる（プロトタイピング）
これらの手法は一例ですが、それぞれ有効なので、この見積もりの時間を見積もって、要求してもらうという手があります。
実装してから見積もりの差分に気づくことの手戻りよりも、事前に不確実なことを発見するときの計画の作り直しのほうが失うものが少ないです。
単一の視点で見積もりをしない
他の人と一緒に見積もりをしたり、「楽観的」「悲観的」などの視点を加えてその見積もり結果をもとに見積もりをすることも見積もり精度を上げることに繋がります。
このあたりは参考書籍にもあるので、興味がある方はぜひ読んでみてください。
まとめ
2年目になっても、見積もりやスケジューリングは難しいなと思う一方で、対外的にスケジュールを公表したり、無理のない持続可能な働き方をする上でも見積もりやスケジューリングを大事だと感じる比重の多さをとても感じています。
「守れる約束をして、それを果たす」という当たり前のことですが、当たり前がちゃんとできるように意識していきたいと思います。
参考になれば幸いです
参考