工数の見積もりこそ「ざっくり力」が重要？見積をこなすSEがコツを伝授

みなさんこんにちは。文系女子SEのほりごたつ(@horigotatsuSE)です。

みなさんは見積、と聞くとどのようなイメージでしょうか？

経理とかお金を扱う部署で詳細まできっちり細かーくつくる感じ？

 

経理かどうかはさておき、

きっちり細かく、というイメージの方も多いですよね。

ですが、SEが案件契約前に作成する見積に関しては

むしろざっくり力が必要なんです。

今回は、見積作成もこなしている現役SEの私が

見積作成にあたってのコツをお伝えします！

見積はどのタイミングで作るもの？

まずは、

見積と一口に言ってもどのタイミングで作る見積のことを指すのか

という前提のお話しをします。

私の現在の仕事のうち、案件初動を抜粋しました。

見積作成のタイミング

①契約の受注・調整

→お客さまとの案件キックオフに参加します。
→見積を作成して契約を受注、社内プロジェクトの立ち上げなどの事務手続きを行います。

②要員の計画・アサイン

→内容や難易度、スケジュールやチームメンバのスキルマップなどから「誰に主担当(窓口)をお願いするか」「メンバは誰をつけるか」などを考えます。

③案件の推進

→今度はチームメンバ向けにキックオフを行います。

このように、

メンバに案件着手してもらう前に作成するのが一般的。

見積作成のタイミング

案件が立ち上がったのでキックオフします！

とお客様から連絡をもらい、キックオフに参加。

この時点ではその案件を誰にアサインするか決めてないので、

私と上司などのリーダー層が行ったりすることが多いです。

こんな内容の案件になるので、対応調査と概算見積をお願いします。

と概算見積を依頼される流れとなります。

概算見積作成時点では設計も固まってないんだよね。。

 

そう、見積作成時点では

「大雑把な」対応内容までは調査して回答しますが

所詮設計書も未完成な状態。「詳細」な内容までは分かりません。

それでも概算見積作らないと契約ができない。。

 

お客様も案件に対して「予算」を組みます。

そのため、「だいたいこれくらいですよ」のお金を提示できないと

そもそも案件として契約ができないんですね。。

そのため、

「詳細」な内容までは分からないまま概算見積は作らなければいけないのです。

工数を見積りするためのコツ

このように、詳細が分からないままに作らなければいけない概算見積。

それにあたってのコツをお伝えしますね。

大事なのはこの３点。

工数見積もりのコツ

①ざっくりイメージを膨らませる

→まずはコレが超大事！これがないまま細かく考えようとすると失敗する。

②前提を置く

→イメージを膨らませる中で「これは分からない」というものは前提を置く。

③正直ベースを意識

→標準的な生産性を意識するのはもちろんだけど、まずは「自分だったらどれくらいか」を考える。

それぞれについて説明していきますね。

ざっくりイメージを膨らませる

これが本当に重要なことで、

まずはイメージを膨らませます。

イメージ？

 

たとえば、とあるオンラインを新設する案件だったとしましょう。

まずは以下のように、画面とデータのやりとりを大まかにイメージするのです。

このざっくりイメージができると、

• どんなプログラムが必要か
• 何本くらいのプログラムが必要か
• それぞれ何stepくらいの大きさになるか

がざっくり見えてきます。

イメージできたらあとはそれぞれどれくらいかを考えればいいんだね

 

最初に詳細に細かくやろうとすると、

全体像を見失いがち。

しまった、お客様宛通知作成するなら社員向け明細も必要だった。。

など横ならびのアウトプットを見落としたり、

あれ、この項目ってそもそもデータベースに持ってない？

と見積前提から崩れてしまったりします。

それを防ぐためにも、

全体像をざっくりイメージしたあと、ちょっとずつ細分化して見積。

これがポイントです。

前提を置く

全体をイメージしてちょっとずつ細分化していくと、

ここってどう構築すべきなんだろう？

と「これから固めなければいけない」内容も発掘されます。

もちろん課題やQAのやりとり、

顧客とのコミュニケーションで固めていかなければいけない内容ですが、

見積の場合はそこまでしっかり固めきれません。

だからこそ前提が大事なんだね

 

たとえば先ほどのイメージの中で

プログラムAにおいて取得される内容があやふやだったとします。

このとき、

• 何が入力されているなら何stepくらいになるか
• その情報が入力されなかったら何stepくらいになるか
• 入力内容で開発規模にどれくらい差がでるか

などいろんな方面から前提を置いて考えてみます。

前提によってあまり規模が変わらないならそれでいいし

 

もし規模が変わるようであれば、

「今回はこういう前提です」ということを伝えて見積結果を提示する。

これが２つ目のポイントです。

正直ベース

規模が見積もれたらいよいよ工数ですが、

ここでポイントとなるのが生産性ですね。

でもこれ、人によって変わるよね。。

 

そう、

ベテランの人がやったら生産性は上がって工数は少なくなり

新人がやったら生産性が下がって工数が多くなる。

これは当たり前のことです。

だからこそ、標準的な工数が求められますが・・・

私は一旦、正直ベースでいいと思うの

 

まずは「自分だったらどれくらいかかるんだろう？」をイメージすること。

これが分からなければ元も子もありません。

一旦正直に「自分だったらどれくらいかかるか」を考え、

自分が平均と比べてどうかを考えてみる。

これが一番初心者にはいい方法かなと思います。

きっと現場によっては

現場ごとのベースラインが確立されていたり、

現場ごとに見積時の生産性が定まっていたりすることもあるでしょう。

私の現場にもあるしね！

 

ですが、見積は

などなど様々な環境変数で変化するもの。

だからこそ、

ぶっちゃけ今回はこれくらいかかりそうだなぁ

 

という肌感覚を大事にして

それとベースラインがかけ離れているならリスクとして管理するなり

見積を修正してみるなり

という工夫が必要なのかな、と思っています。

まとめ：まずは正直ベースで見積もってみよう

ここまで「ざっくりイメージ」「前提を置く」「正直ベース」という

３つのポイントをお伝えしました。

が、

「まずはとにかく見積ってみる」

ということが一番大事です。

私が初めて見積したときはかなり苦戦したなぁ。。

 

上司に見積のポイントを聞いてみても

まあとりあえずは「えいっ」とやってみてよ

とテキトーなことを言われ。笑

正直相当悩みました。

今思うと、

「とりあえずやってみる」ことで見積の感覚を身につけさせてくれたんだなと。

規模感とかって実際やってみないと身につかないしね

 

まずはとりあえず正直ベースで見積もってみる。

それを上司に「多すぎ」「少なすぎ」などと指摘されたら直す。

それを繰り返すことで、自分の中にベースラインが出来上がりますよね。

それが見積の第一歩です。

ためになった！と思ったらはてなブックマークやSNSでのシェアよろしくね！

仕事で悩んだらコチラの記事もオススメ！

仕事ができない人の特徴は考え方にあった！「入社１年目から差がついていた！頭がいい人の仕事は何が違うのか？（中尾ゆうすけ）」
失敗から学ぶために読むべき本！「ミスしても評価が高い人は何をしているのか？（飯野謙次）」
仕事を抱え込むタイプは読みたい本！「最速で１０倍の結果を出す他力思考（小林正弥）」
仕事がうまくいかない時に読みたい本「多分そいつ、今ごろパフェとか食ってるよ。（Ｊａｍ）」
ビジネスにおける重要な思考法が詰まった本！「Think Smart（ロルフ・ドベリー）」

仕事がうまくいかないのは○○のせい？入社5年でサブリーダーになった女の仕事術
SE向いてないと悩んでいる方へ。「ざっくり力」をつけよう！【文系女子ＳＥの実体験】
SE(システムエンジニア)の失敗は許されない？現場SEの失敗談【文系女子ＳＥの実体験】
仕事がうまくいかないのは国語力のせい？！ビジネス国語の重要性

基本情報技術者試験午後問題の対策はアルゴリズムが要！試験合格までにやったこと