SESで工数見積もりを任されたら｜根拠の出し方と、ズレそうなときの報告の型

「この改修、工数いくらか出してもらえますか」と窓口のリーダーに聞かれて、手が止まった。SESで経験を積むと、実装やテストだけでなく、数字を出す役が回ってくる場面があります。

私はSESエンジニアとして5年ほど、4社の現場を経験しました。初めて見積りを任されたのは3社目の保守改善で、1人日と答えた依頼に、実際は約2.6人日かかっています。

今回は、SESで工数見積もりを任されたときの根拠の出し方と伝え方、ズレそうなときの報告の型を、失敗を交えてお伝えします。

目次

1. SESで工数見積もりを任されたとき、最初に確認すること
2. 準委任と請負では、見積りの意味が違う
3. 見積りを頼まれたら、先に聞いておく4点
4. エンジニアは工数を低く見積もりがち
5. 初めて任された見積りが、1人日から2.6人日になった日
6. 依頼の中身と、私が出した1人日
7. どこが抜けていたのか｜実績の内訳
8. ズレた原因は、能力ではなく見積りの作り方だった
9. 保守改修の見積りに影響範囲調査を含めるか｜切り出して見積もる
10. 調査を本体に混ぜると、見積りが外れやすい
11. 2段階で答えるやり方
12. 切り出せない場合は、調査の時間を数字に入れる
13. 見積もりの根拠の出し方｜分解・実績・前提条件
14. 作業を分解して、漏れなく並べる
15. 自分の実績を貯めて、時間を置く
16. 前提条件を、数字とセットで書く
17. 厚労省が挙げる「リスクの洗い出し」を、前提に落とす
18. 幅で伝える言い方と、前提条件の添え方｜会話例
19. 点で答えたときと、幅で答えたとき
20. 点の見積りと幅の見積りを並べる
21. 幅の使い方で気をつけること
22. ズレそうな時点で出す報告の型｜原因・見込み・選択肢
23. ズレそうだと気づく目安
24. 報告の型｜原因・見込み・選択肢
25. 型にすると何が変わるか
26. 期日が先に決まっている場合の見積りと報告
27. 初めてなら、1人で数字を出さずにレビューを頼む
28. 誰にレビューを頼むか
29. レビューを頼む手順
30. レビューを頼むのは、遠慮することではない
31. 4社目で見積りを受ける側になって見えたこと
32. 内訳のない「3人日」に聞く3つのこと
33. 管理職の見積りは、自分の残業に直結する
34. 後輩に見積りを任せる順番
35. 見積りが約束として扱われそうなときの考え方
36. 目安の数字が、約束にすり替わる場面
37. 断定できないこと
38. まとめ

SESで工数見積もりを任されたとき、最初に確認すること

結論見積りを頼まれたら、数字を考える前に「この数字が何に使われるか」を確認します。準委任の現場では、見積りは完成を約束するものではなく、稼働の目安だからです。

最初に確認すべきなのは、技術的な見積もり方ではなく、数字の位置づけです。ここでは、契約の種類によって見積りの重さがどう変わるかと、頼まれたときに聞いておく点を順に見ていきます。

準委任と請負では、見積りの意味が違う

SESの多くは準委任契約で、約束するのは「成果物の完成」ではなく「一定の期間、一定の作業に従事すること」です。契約の違いは、準委任と請負の記事で整理しました。

関連記事SESの準委任契約とは｜請負・派遣との違いと指揮命令・偽装請負の境目SESの準委任契約とは何か。請負・労働者派遣との違い、指揮命令と偽装請負の境目、履行割合型と成果完成型の違いを、契約書を見られな…

請負なら、見積り金額は完成の約束に近づきます。準委任では、見積りは「この作業にこれだけの稼働がかかりそうだ」という目安として、客先が予定を組むために使います。

ただ、目安だから雑でいいという話にはなりません。窓口のリーダーは、私の数字をそのまま週の予定に載せるからです。数字は目安でも、予定は数字のとおりに組まれる。この食い違いが、後で書く私の失敗の原因でした。

見積りを頼まれたら、先に聞いておく4点

3社目の保守改善で、私は見積りを頼まれるたびに次の4点を確認するようになりました。聞くのは、依頼を受けたその場でかまいません。

3つ目は軽く見られがちですが、換算がずれると全体がずれます。IPA（情報処理推進機構）のソフトウェア開発データ白書のFAQには、特に指定がなければ1人月を160人時（1日8時間×月20日）として扱う、という回答があります。別の質問では1人月を120時間とした比較の例も出てくるように、換算の前提は何を基準にするかで変わります。出典: IPA ソフトウェア開発データ白書 FAQ

月の換算ですら複数あるので、日の換算も現場で揃えるのが確実です。私の現場は1人日を8時間で数えていて、この記事の数字もすべて8時間換算です。

エンジニアは工数を低く見積もりがち

厚生労働省の「IT業界の働き方・休み方の推進」には、エンジニアは作業工数を低く見積もりがちだという指摘があります。見積り精度を上げる手立てとして、社内でのレビューやリスクの洗い出しにも触れています。出典: 厚生労働省「IT業界の働き方・休み方の推進｜問題解決の勘所5」

この指摘は、私の初見積りにそのまま当てはまりました。次のセクションで、何がどう抜けていたのかを数字で見ていきます。

初めて任された見積りが、1人日から2.6人日になった日

保守改善に入って8か月ほど経った頃、窓口のリーダーから初めて「この依頼、工数を出してもらえますか」と言われました。それまでは、決まった工数を渡される側だったので、数字を自分で出すのは初めてです。

依頼の中身と、私が出した1人日

依頼は、申し込み画面の選択肢に新しい区分を1つ足すというものでした。画面の選択肢を増やすだけに見えたので、私は修正とテストと証跡で足し上げ、「1人日でできます」と答えています。

内訳は、コード修正が0.25人日、テストが0.5人日、証跡と申請資料が0.25人日でした。誰にも見せず、自分の頭の中で組み立てた数字です。

同じ依頼の見積りと実績です。1人日＝8時間で数えています。

窓口のリーダーは「1日」で週の予定を組んでいたので、予定を組み直してもらうことになりました。叱責はありませんでしたが、並行していた別の依頼の期日にも響きました。

どこが抜けていたのか｜実績の内訳

終わってから、作業ごとの実績を書き出しました。見積りに入れていなかった項目が、実績の半分近くを占めています。

コードを書く時間は、見積りより0.5時間増えただけでした。ズレの大半は、自分の頭の中で「作業」と認識していなかった項目から来ています。

実装は全体の約12%で、残りの大半は調べる、確かめる、残す、直すの時間です。保守改修の工数は、コードを書く量に比例しません。影響範囲調査が1件あたり半日〜1日かかるという現場の事情は、リリースが重い理由の記事に詳しく書きました。

現場のリーダーが回答するときは、この調査を最初から工数に含めていました。ところが、自分で数字を出す立場になって初めて、その項目を自分で数えなければならないと気づきました。

関連記事SESの保守改修でリリースが重い理由｜影響範囲調査は半日〜1日かかった現場SESの保守改修でリリースが重くなる理由を、保守改善約1年半の実体験で整理します。影響範囲調査のやり方、証跡とドキュメントの多さ…

ズレた原因は、能力ではなく見積りの作り方だった

あとから振り返ると、原因は3つに整理できます。

見積りがズレる原因の多くは、技術力ではなく、数える項目の漏れです。この見方に変えてから、見積りの作業は「予想する」ことから「漏れなく並べる」ことに変わりました。

保守改修の見積りに影響範囲調査を含めるか｜切り出して見積もる

結論影響範囲調査は、本体の作業とは別に切り出して見積もります。調査が終わるまでは、本体の工数が決まらないからです。

保守改修では、直す量より先に「どこまで広がるか」が分からないと数字が出せません。この章では、調査を見積りに含めるか切り出すかの考え方と、私が使った2段階の出し方を書きます。

調査を本体に混ぜると、見積りが外れやすい

影響範囲調査は、半日で終わる依頼もあれば、1日以上かかる依頼もあります。調査前に本体の工数まで答えようとすると、「広がらなかった場合」の数字を置くしかありません。

先ほどの失敗は、まさにこれでした。調査を入れず、広がらない前提の数字を出して、実際は6時間の調査と、その結果として増えたテスト範囲が乗っています。

調査は、結果によって本体の工数が変わる、いわば「条件を決める工程」です。だから、調査と本体を同じ1本の数字に混ぜない、というのが私の結論でした。

2段階で答えるやり方

保守改善の後半から、私は見積りを頼まれたら、次の流れで答えるようにしました。

1. 調査だけ先に見積もる半日〜1日の枠で回答
2. 調査を実施する影響範囲を表にまとめる
3. 本体の工数を出す調査結果を根拠に幅で回答

窓口のリーダーに最初に伝えるのは、「まず調査に半日〜1日をください。その結果で本体の工数をお伝えします」という一言です。急ぎで概算が要るときは、後で書く幅の出し方で、前提つきの概算を先に返します。

この2段階にすると、調査の結果が本体の見積りの根拠になります。「どの画面とAPIが影響するか」の表を添えれば、数字の説明が1枚で済みます。

切り出せない場合は、調査の時間を数字に入れる

客先の都合で、調査前に確定の数字が要ることもあります。その場合は、調査を黙って本体に混ぜず、内訳に「影響範囲の調査（半日〜1日）」と別の行で入れます。

内訳に別の行で入れておけば、あとで調査が長引いても「どの行がズレたか」を説明できます。内訳のない1本の数字だと、ズレたときに全体が責められます。

内訳を書いておくことは、自分を守る手段でもあります。私の場合、調査が膨らんだときに、調査の行だけを根拠にして再見積りを出せました。

見積もりの根拠の出し方｜分解・実績・前提条件

見積りの根拠というと難しく聞こえますが、分解、実績、前提条件の3つで足りました。特別な計算式はいりません。分解、実績、前提条件の順に、実際にやったことを書きます。

作業を分解して、漏れなく並べる

最初にやるのは、依頼を作業の単位に分けることです。保守改修で私が使っていた並びは、次のとおりです。

1. 依頼内容の確認・要件の整理窓口への確認事項を含みます。回答待ちは作業時間ではなく経過時間なので、別に扱います。
2. 影響範囲の調査前の章のとおり、切り出して扱います。
3. 設計（設計書の更新を含む）改修の設計と、変更した設計書の直しです。
4. 実装コードを書く時間です。多くの場合、全体の1割から2割でした。
5. 単体・結合テストテストの観点出しと実施、不具合の修正を含みます。
6. 証跡・申請資料の作成テスト結果の画面キャプチャや、リリース申請の書類です。
7. レビューと指摘対応レビューを受ける待ち時間は別として、指摘を直す時間を置きます。

前回の失敗は、このうち2・3・7を数えていなかったことでした。逆に言えば、この7行を毎回なぞるだけで、同じ漏れは起きなくなります。

作業の分解は、WBS（作業分解構成図）の考え方そのものですが、難しい図は要りません。メモ帳に7行書けば十分です。

自分の実績を貯めて、時間を置く

分解したら、各行に時間を置きます。ここで根拠になるのが、自分の過去の実績です。

初見積りの後、私は自分用に実績メモを作りました。依頼が終わるたびに、種類と、調査から証跡までを含めた合計の時間を1行足すだけのメモです。保守改善の後半で、18件ぶんが貯まりました。

同じ種類の依頼でも、実績には幅が出ます。ですから見積りも、1つの点ではなく幅で出すのが自然です。次の章で、その伝え方を書きます。

実績メモの効果は、数字の精度だけではありません。「前に似た依頼が2人日と3人日だった」と言えると、根拠の説明が一言で済みます。窓口のリーダーも、理由が見える数字には口を挟みにくくなります。

前提条件を、数字とセットで書く

もう一つの根拠が、前提条件です。見積りの数字は、「こうなら、この工数」という条件つきの約束だと考えます。

たとえば私は、数字の横に次のような前提を書き添えました。

前提が崩れたら、数字を見直す。この取り決めを先に言葉にしておくと、後で「見積りと違う」と言われたときに、「前提のこの点が崩れました」と具体的に返せます。

厚労省が挙げる「リスクの洗い出し」を、前提に落とす

先に触れた厚生労働省の資料では、見積りの精度を上げる手立てとして、リスクの洗い出しに触れていました。私はこれを、前提条件の書き方に転用しています。

リスクを洗い出すといっても、大げさなことはしません。「この依頼で、時間が膨らむとしたらどこか」を3つ書き出し、その裏返しを前提にするだけです。「設定ファイルの呼び出しが多かったら」というリスクは、「設定ファイルの呼び出しが想定内なら」という前提になります。

3つ書き出す作業に、5分はかかりません。その5分で、あとの再見積りの回数が減りました。

幅で伝える言い方と、前提条件の添え方｜会話例

根拠が揃っても、伝え方を間違えると意味が薄れます。数字は「2〜3人日」のように幅で伝え、前提条件を添えるのが私の型です。窓口のリーダーとの実際のやり取りに近い形で、悪い例と良い例を見ていきます。

点で答えたときと、幅で答えたとき

初見積りのときのやり取りは、ほぼ次のとおりでした。リーダーに「どのくらいかかりますか」と聞かれて、私は「1人日でできます」とだけ答えています。リーダーは「では今週の水曜に、確認用に出してください」と返し、その場で予定が決まりました。

私の「1人日」は、「前提が全部うまくいけば」という言葉を省いた答えでした。リーダーの側には、約束として届いています。

3か月後、同じ種類の依頼を頼まれたときは、こう答えました。

この会話で、数字、根拠、前提、見直しの時期の4つが一度に伝わっています。リーダーが上限の3日で予定を押さえてくれたので、下限で終われば余裕ができ、上限までなら予定の範囲内に収まる状態になっています。

点の見積りと幅の見積りを並べる

2つの答え方の違いを、並べて整理します。

点で答えた場合

• 「1人日です」だけを伝える
• 根拠も前提も伝わらない
• 予定が数字のとおりに固定される
• ズレると「約束と違う」になる

幅と前提で答えた場合

• 「2〜3人日」と幅で伝える
• 過去の実績を根拠に添える
• 前提が崩れたら見直すと先に言う
• ズレても「前提が崩れた」と説明できる

幅で答えるのは、逃げ道を作るためではありません。実際に、工数は幅を持ってしか分からないので、それをそのまま渡しているだけです。

幅の使い方で気をつけること

幅で答えるときに、私が守っていた点が3つあります。

ズレそうな時点で出す報告の型｜原因・見込み・選択肢

結論ズレに気づいたら、終わってからではなく、ズレそうな時点で「原因・見込み・選択肢」の3つを揃えて報告します。報告の中身がそろっていれば、相手はその場で判断できます。

見積りは、出した後の動き方で信頼が決まります。ここでは、ズレそうな時点を見分ける自分のルールと、報告の型を、実際にあった例で書きます。

ズレそうだと気づく目安

見積りを出して数か月後、幅で「2〜3人日」と答えた依頼がありました。前提は、設定ファイル側の呼び出しが想定内であることでした。

ところが、2日目の終わりになっても、調査が終わっていませんでした。半日で終わると見ていた調査が1.5日かかり、本体の作業に入れていない状態です。

このとき、見積りの下限である2人日は、すでに消化していました。私はこの経験から、次の目安を自分のルールにしました。

1つでも当てはまったら、その日のうちに報告の準備をします。「もう少し頑張れば間に合うかも」と考えて黙る時間が、一番ズレを大きくするからです。

報告の型｜原因・見込み・選択肢

3日目の朝、私は窓口のリーダーに次のように伝えました。

この報告は、1分で終わりました。リーダーが選んだのは、設定ファイル側を別の依頼に分ける案で、当初の期日は守れています。

型にすると何が変わるか

報告が下手に聞こえる原因の多くは、「困っています」で止まることです。型にすると、相手が決めることだけが残ります。

選択肢を持っていくのが、肝になります。客先から見れば、「遅れます」だけの報告は問題の持ち込みで、選択肢つきの報告は判断材料の提供です。

報告は、ズレが小さいうちに、決める材料をそろえて持っていく。これだけで、同じズレでも受け止められ方が変わります。

障害のような緊急時の報告の順番や、第一報に入れる項目は、別の記事に書きました。

関連記事SESで障害を起こしたら？報告の順番と障害報告書の書き方SESで障害を起こしたら、誰にどの順で報告するか。自社と客先の二重の報告先、第一報・続報・最終報の分け方、障害報告書の書き方と再…

期日が先に決まっている場合の見積りと報告

見積りを出す前から、期日が決まっていることもあります。期日が先に決まる構造は、納期が一方的に決まる理由の記事で扱いました。

期日が固定のときも、私はまず工数の幅を出し、その幅が期日に収まるかを示します。収まらないなら、範囲を削る案を同時に出します。期日の都合で数字を縮めて出すと、結局どこかで同じズレが表に出ます。

初めてなら、1人で数字を出さずにレビューを頼む

初めて見積りを任された人が、いちばん安全にできる対策は、一人で完成させないことです。私の初見積りの失敗も、誰にも見せなかったことが一因でした。この章では、レビューを頼む相手と手順、頼み方の文面を書きます。

誰にレビューを頼むか

3社目の私が頼んだのは、同じ現場に5年以上いる、40代くらいの協力会社の方でした。保守の依頼を何百件も見てきた人で、「このシステムで広がりやすい場所」を知っています。

頼む相手の条件は、2つです。同じシステムの過去の依頼を知っていること、そして数字に責任を持たない立場で意見を言えることです。自社のリーダーでも、現場の先輩でもかまいません。

自社の上司や営業は、現場のコードの事情までは分からないことが多いので、数字の中身ではなく、客先への出し方の相談に向いています。

レビューを頼む手順

私が実際に踏んでいた手順は、次の順です。

1. 依頼を一文にして、作業を7行に分解する前の章の7行に、自分の時間を置きます。ここまでを1人でやります。
2. 幅と前提を仮置きして、レビューを頼む仮の数字であることを伝えて、15分だけもらいます。
3. 抜けている工程と、危ない前提を聞く「何か足りない作業はないか」「この前提は怪しくないか」の2点に絞ります。
4. 指摘を反映して、窓口に回答するレビューを受けた旨と、根拠を添えて答えます。
5. 実績が出たら、メモに足す見積りと実績の差を1行書きます。次のレビューの材料になります。

頼むときの文面は、短くてかまいません。私は、次のようにチャットで送っていました。

何をどこまで見てほしいかが具体的だと、相手も短時間で答えられます。「見積りを見てください」だけでは、頼まれた側が何を見ればよいか迷ってしまいます。

レビューを頼むのは、遠慮することではない

初めての頃は、「簡単な見積りで人の時間をもらうのは申し訳ない」と思いがちです。私も最初はそうでしたが、協力会社の方は「数字を出す前に見せてもらったほうが、あとで手戻りが減って助かる」と言ってくれました。

コードレビューと同じで、見積りも出す前に見てもらうほうが全体のコストは下がります。コードレビューを受ける側の心構えは、SESでコードレビューを受けるときにまとめています。見積りのレビューは、成果物ではなく仮の数字を見てもらうだけなので、コードのレビューよりも頼みやすい部類だと感じています。

4社目で見積りを受ける側になって見えたこと

現在の4社目では、管理職として3〜5名を見ています。手を動かしつつ、メンバーから見積りを受けて、客先に出す前にレビューする側です。立場が変わると、見積りの見え方も変わりました。

内訳のない「3人日」に聞く3つのこと

経験2年目のメンバーが、「この改修は3人日です」と、内訳なしで出してきたことがありました。数字は妥当にも見えます。ただ、私が見るのは数字そのものより、何が入っているかです。

私が聞いたのは、次の3点でした。

答えは、調査が入っていないというものでした。調査を足して見直した結果、4人日になりました。メンバーが悪いのではなく、私の初見積りと同じ項目が漏れていたのです。

自分が失敗した場所は、他人の見積りでも同じ場所に穴が空きます。レビューする側が最も役に立つのは、数字の良し悪しではなく、抜けやすい項目を先に知っていることでした。

管理職の見積りは、自分の残業に直結する

管理職になって、見積りの重みが変わった点があります。私の残業には、残業代が付きません。見積りが甘ければ、ズレた分は自分の残業で吸収することになります。

管理職の残業代のしくみは、別の記事に整理しました。

関連記事SESで管理職になると残業代は出ない？管理監督者との違いと確認することSESで管理職になると残業代は出ないのか。入場数か月後に管理職となり残業代がなくなった私の経験から、労基法の管理監督者との違い、…

そのため、メンバーの見積りを客先に出すときは、合計に自分のレビューの時間も加えます。1件あたり30〜60分ほどで、こまごまとした時間ですが、数が重なると無視できません。自分が手を動かす分と、見る分を分けて数えないと、私自身がパンクします。

後輩に見積りを任せる順番

メンバーに初めて見積りを任せるときは、いきなり一人で出させず、次の順に段階を踏みます。

この進め方は、後輩を指導する立場で学んだことでもあります。育て方の全体像は、SESで後輩を指導するときに書きました。

見積りが約束として扱われそうなときの考え方

ここまで、準委任では見積りは目安だと書いてきました。ただ現場によっては、目安のはずの数字が、契約外の作業の根拠や、責任追及の材料として使われそうになることがあります。

目安の数字が、約束にすり替わる場面

典型的なのは、「前に1人日と言ったのだから、1人日で終わるはず」と、前提の話が抜けて数字だけが残る場面です。幅と前提を書面に残していれば、こうした場面で効いてきます。

私の現場では、幅と前提をチャットか課題表に残していたので、前提の崩れを根拠に見直しを依頼できました。口頭だけだったら、初見積りのときのように、「1日」という数字だけが一人歩きしていたと思います。

契約外の作業を頼まれる場面の考え方は、SESで契約外の作業を頼まれたときに書きました。

断定できないこと

見積りの扱いは、契約書の書き方や、客先との取り決めで変わります。準委任でも、契約に成果物の納品を含む形のものがあり、一律には言えません。

迷ったら、契約書と、自社の営業・上長に確認してください。現場の窓口だけに確認しても、契約上の位置づけまでは分かりません。見積りの数字を客先に出す前に、自社の営業にも一度見せておくと、契約と食い違うことを避けられます。

まとめ

SESで工数見積もりを任されたら、最初にやるのは計算ではなく確認です。数字の使い道、換算の単位、含める作業を聞いてから、分解して、実績で時間を置き、幅と前提で伝えます。

私の初見積りは、1人日と答えて約2.6人日でした。技術力が足りなかったわけではなく、調査や設計書の更新といった作業を数えていなかっただけです。漏れなく並べる、幅で伝える、早く報告する。この3つで、同じ失敗はほぼ起きなくなりました。

これから見積りを任される方は、まず今抱えている依頼を1件選び、7行に分解してみてください。すでに見積りを出している方は、実績が出た依頼から、見積りとの差を1行ずつメモに足し始めると、半年後には自分だけの根拠になります。