ITエンジニア 新卒1年目の振り返り：初めての見積で大失敗

概要

新卒エンジニアとして、1年目の最後に経験した見積について書きます。

1年目の終わりに、新人ながら運よく案件の見積に携わることができました。その際、過小な見積してしまい失敗した話です。

※開発自体は2年目の最初でした。その苦労話は別で書く予定です。

目的

見積に関わった経験を振り返りつつ、次に機会があればここを気を付ける という視点で記事を書いていきます。

初めて見積に関わる方などの参考になれば幸いです。

見積の振り返り

前提

時期としては、新卒1年目の2-3月でした。
初配属から約半年間、同じお客様のシステム開発を担当をしていました。

案件はアジャイル開発で、私は2回の開発～リリースを経験していて、見積は3回目の開発に向けてのものでした。

また、規模感としては、2-3人×3か月程度の開発です。

見積はPM+私の2人体制で臨みました。

実際の見積作業

実際に取り組んでいた仕事内容としては、以下でした。

• 週1の定例でお客様の要件ヒアリング
• 定例に向けた事前準備
• 開発工数の見積

なお、お金が絡む部分はPMの方が担当でした。
※お金が絡む部分：開発工数を基に見積金額を出し、お客様と金額交渉をし、契約をしていく等

やってきた内容をもう少し詳しく話していきます。

週1の定例でお客様の要件ヒアリング

既存のお客様ということもあり、週次で定例を実施、主にお客様から要件を話してもらう進め方でした。

案件次第だと思いますが、こちらからがっつり提案するという感じではありませんでした。
どちらかと言うと、要件定義に近いイメージだと思います。

要件概要を聞き、必要に応じてやりたいことの目的や具体を掘り下げ、実現方法をいくつか提示していきました。

定例に向けた事前準備

当然ですが、事前準備を行います。
主には、こちらから提案する内容の資料準備です。

前節で書いた通り、顧客からの要望に対する実現案の説明が主でした。

特に、工数（金額）に影響の大きい部分は数パターン用意して、顧客に選択してもらうという進め方をしていました。

開発工数の見積

次に、開発工数の見積に着手しました。

開発イメージが固まってきたのと、スケジュール的に"そろそろ"というタイミングで概算見積を出します。

スケジュール的に"そろそろ"なのは、大まかなリリース希望日があり、「見積提示→顧客の稟議→発注→開発→リリース」の期間から逆算して、そろそろ見積を出さないといけないという感じです。

※顧客次第ですが、稟議や発注はそこそこ時間がかかります。
　私の案件では、1ヶ月近くかかるので早めに動く必要がありました。

工数の見積は、顧客の要望に対する機能・成果物のイメージを固め、これまでの開発経験から算出していきました。

私の案件では、Salesforceのフロー（ローコード開発）を使っての開発でしたので、例えば、以下のような見積でした：

• 〇〇機能にはフロー3本必要で、一つのフローに4日で、合計12日
  同様にフェーズ毎・機能毎に考えて、合計60日の工数が必要

最終的にPMに提出してレビュー&修正して、顧客に提出しました。

※その後、金額交渉とかもあったよう

見積ではここを気を付けるべし

冒頭で書いた通り、私が作成した見積は過小評価しすぎで、実際の開発に必要な期間としては短かったです。
※結果として、色々と開発でバタバタがありました。

ここでは、具体的に「見積でどんな失敗をしたか？」を基に、見積で気をつけたほうが良いと思うことを書いていきます。

タスクの洗い出しができていない

当たり前ですが、タスクが洗い出されていなければ、その分小さく見積をしてしまいます。
見積時には、タスクの洗い出しをしてから、工数の見積をするべきです。

例えば、開発に対するレビュー工数、テストに対するテスト仕様書作成など、見落としがあったと感じています。

「テスト仕様書の作成」について、もう少し具体的に書きます。

このタスクを見落としてしまった要因は、メンバの入れ替わりにより新規メンバ中心の開発であったことだと感じています。

これまでは、一人のメンバが一つの機能を担当して、開発からテストまで一貫でやっていました。また、テストで他メンバがヘルプに入る場合にも、既存メンバのため内容をよく理解したメンバでした。

そのため、極端な話、テスト仕様書を雑に書いても問題はありませんでした。

一方で、今回の開発では、新規メンバ中心の開発でした。開発とテストが別々のメンバであることが増え、仕様をよく理解していない場合が多かったです。

そのため、テスト仕様書をより正確に詳しく書く必要があり、そこに想定より多くの工数が取られました。

各タスクに対するリスク分析をしていなかった

ここは前節のテスト仕様書の話にも通じますが、リスク分析は大切です。

システム開発において、全く同じ開発をすることはなく、多くのリスクが潜んでいます。

例えば、

• メンバの入れ替わり
  • 案件や技術に対するキャッチアップに工数がかかってしまう
• 新しい技術
  • 実現可能性に対する調査やキャッチアップに工数がかかってしまう
  • ※ここはローコード開発であっても、十分に考慮が必要です。
    　むしろローコードの方が制約が多い場合もあり、実現可能性には注意が必要です。
• 新しい顧客(もしくは新しい担当者)
  • コミュニケーションルールに認識齟齬があると、そこがネックで開発が遅れてしまう
  • 例えば、レスポンスの速さは意外と重要で、質疑に対する返信が遅かったり決定事項を先送りされる場合は要注意だと思います。

これらのリスク分析をしたうえで、対策を取ったり、リスク込みの見積を出す必要があります。

要件をミニマムでとらえてしまった

要件は膨らむものです。

見積のときに聞いていた要望よりも多くの要件が発生して、結果として工数をひっ迫してしまいました。

正確には、見積時には要望は抽象的で、開発が進むにつれて具体的な要件になります。その過程で、想定よりも多くの機能が必要になってしまうのです。

見積時に要望が抽象的なのは仕方がないことです。そのため、抽象的な要望に対して、どんな機能が必要になりそうか？を自分の中で具体化することが必要だと思います。

そのうえで、リスク込みで見積工数に反映することが求められます。

もしくは、提案や見積時に"見積前提"を明確にしておくことも大事です。

"全ての機能"を想定すると膨大な工数と金額になるので、"ここまでを開発する想定です"を顧客とすり合わせておくことで、要件が膨らむことを予防できます（要件が膨らんだ場合は追加発注としてもらいやすい）

要件定義を甘く見てはいけない

要望が膨らむと、それを決めるための時間も多くかかります。

加えて、要件定義は、こちらが一方的にがんばれば良いものではなく、顧客との密な認識合わせが必要です。

工数だけでなく、何回の会議が必要であるかを考えておく必要があります。

例えば、要件定義を10日の見積だとします。定例が週1回の場合は2回しか会議ができず、それではとても要件定義は完了しません。

また、工数の使い方も注意が必要です。
例えば、

• 1人のPMが0.5人月(他プロジェクトとの兼任等)で入るなら、「見積工数は10人日」=「実際の期間は20日」です。
• 一方で、2人のPM/メンバが1人月ずつで入るなら、「見積工数は10人日」=「実際の期間は5日」です。

当たり前ですが、後者の場合は大変なことになりそうです。
そして実際、私の見積は後者のような状況でした。

※会議は何回必要で、各回で何を決めるか？をできるだけイメージして見積をすることも必要だと思います。

発注が分割された

やや特殊ですが、顧客都合で発注(リリース)が分割されました。
※発注金額が大きいと稟議に時間がかかってしまうため

いくつかの機能を3ヶ月でリリースする予定だったのですが、分割されて1.5ヶ月ずつでリリースすることになりました。

当初は工数が変わらないので軽視していましたが、ここに大きなリスクが潜んでいました。

というのも、期間が長ければ、タスクを前後させることで、ある程度融通が効くようになります。

例えば、前節の要件定義の期間が短くても、決まった機能から先行で開発を進めることで、全体のスケジュールを守る方法も取れます。

ところが、今回はリリースが分割されたために、タスクの融通が効かず、結果的に苦労したのです。

まとめ

ここまで、見積の経験を振り返って、気を付けることを書いていきました。

• タスクの洗い出しができていない
• 各タスクに対するリスク分析をしていなかった
• 要件をミニマムでとらえてしまった
• 要件定義を甘く見てはいけない
• 発注が分割された

次はこの教訓を活かしつつ、精度の高い見積を出せるようになりたいです。
（と言っても、見積は難しいので、きっと失敗するだろうなと思っています）