これいつまでにできる？
えっと…１週間くらいでしょうか？
エンジニアとして働いていると良く見かける場面です。
ですが、まだ仕事に不慣れな新人エンジニア・プログラマーの場合、どう答えたらいいか困ってしまいますよね。
そもそも見積ってどうやってするの？
予定通りにできないとどうしよう…
と考えてしまって返答できない方もいるかもしれません。
結論から言うと、「なにも答えられない」という状態は良くありません。
なぜなら、なにも答えがないと上司としてはこの先の予定を決めたり、どの部分に不安を感じていてどんなフォローをすると作業が円滑に進むのかが分からないからです。
筆者は、この記事を書いている時点で６年目のエンジニアとして働いています。
新人のころ、いや今でも見積って難しいなと感じる今日この頃。
聞かれたら、なにか答えないといけない。
そんな思いをたくさんしてきました。
この記事では、
- 見積はなぜ必要か
- 見積をするときの３つのポイント
- 「これいつまでにできる？」の答え方
について紹介しています。
「これいつまでにできる？」に悩んでいるあなたに読んで欲しい記事となっています。
そもそも見積ってなんのためにするの？
そもそも見積はなんのためにするのか。
一番大きなところでいうと、予算を立てるためです。
あくまで大雑把にですが、ある開発プロジェクトが１人でプログラムを完成させるまでに必要な期間が１カ月とします。
そうすると、開発者の１時間あたりの金額が3000円だとして、1日８時間で土日を省いた１カ月の日数が２０日間、
3000（円） × ８（時間） × 20（日） ＝ 480,000 円 （１カ月あたり）
と予算を見積もることができるのです。
※フリーランスや新しい考え方で開発を行う企業では、上記のような時給的な考え方はしていないこともありますが、今でも多くの企業では時給を元に予算を見積ることが多いと思います。
とはいえ、新人エンジニアやプログラマーが予算のことを考えて動くことはありません。
新人エンジニア・プログラマーにとって、見積が必要な理由は
受け持つ仕事がどの程度で完成するのかを上司、あるいはプロジェクトリーダーに報告しなければならないからです。
上司としては、次の仕事を割り振ったり、見積日数が長いのであればフォローしたりしてプロジェクトを円滑に進めなければなりません。
その為、見積は仕事を回していくうえで必要なものとなります。
他にも見積を行うことで、作業の全体を把握できたり、どこの部分で時間がかかるかを予想することで、事前に必要な情報を集めたりできます。
新人プログラマー・エンジニアが見積をするときのポイント３つ
見積をするときのポイントを３つ紹介します。
- タスクの切り分けと時間の把握
- 懸念点の洗い出し
- 正確な見積はできなくていい
これら３つを意識することで、見積に対する苦手意識が軽くなります。
タスクの切り分けと時間の把握
まずは見積の基本となる「自分のすべき事柄をタスク分け」しましょう。
例えば、「ある画面にある条件で固定のメッセージを表示する」といった内容の修正案件があるとします。
※新人から新規でプログラムを作成することは稀です。例え新規でも、テンプレートや似たり寄ったりのプログラムが既に作成されている場合がほとんど。
こういった案件の場合このようにタスクを切り分けることができます。
| No. | 作業内容 | かかる時間 |
|---|---|---|
| １ | 要望の実現方法の調査（特定の画面の処理やメッセージを出す処理を入れ込む部分の調査） | ３時間 |
| ２ | プログラミング（メッセージを出す処理を追加する） | ３時間 |
| ３ | 動作確認（条件にヒットすればメッセージが表示される） | ２時間 |
| ４ | テスト仕様書の作成（テストパターンの洗い出し） | ３時間 |
| ５ | テストの実施 | ５時間 |
| ６ | 上司（もしくは第3者）のレビューを受け、指摘があれば修正 | ２時間 |
| ７ | 成果物提出時に必要な文書や社内のルールに基づいた提出方法の提出作業 | １時間 |
もっと簡略化したタスクでもいいです。
自分なりにタスク化してください。そして、それぞれにだいたい何時間かかるか予想をたてます。
この例では、19時間で作成できるので2日と少しで完成できると言えます。
残業をするなら、２日、残業をしないなら３日と答えていいでしょう。
このようにタスクに切り分けて、それぞれの時間を積み上げることで見積を立てることが出来ます。
タスク分けをすることで、どこに何時間かかるか把握できます。
上司としては、タスクごとに分けたその配分が間違っていると予想できたらこの時点で訂正することもできます。
プログラミングだけなら何日でできる？ テストだけだと何日かかる？
といった質問をすることもあるので、自分の中でしっかり時間を把握しておいてください。
懸念点の洗い出し
プログラム・システムの作成は、予想もしていないことが起きたり、思っていたよりも複雑なことをしなければならなかったりと想定していないことが起こることは日常茶飯事です。
また、やってみないと分からないことも多々あります。
そういった場合は、あらかじめ懸念点を洗い出しておきましょう。
そして、懸念点が悪い方向、つまり時間がかかる作業が発生すると予測される場合は見積に含める必要があります。
要は、バッファー（余裕をもった時間）を持った見積にしなければなりません。
このバッファーの取り方には注意が必要です。
なぜなら、バッファーを取りすぎると見積にならないからです。
その為、多少のバッファーをとる必要はありますが、最初の見積時点で大きくバッファーをとる必要はありません。
その分、懸念点については、上司に伝えられるようにしておきましょう。
懸念点を最初に聞いていると、既知の問題であればその場で解決できるかもしれません。
また、上司の方も最初から懸念点を頭においた上で計画を進めることができるので、フォローできる準備をすることもできます。
正確な見積はできなくてもいい
まず最初に言いたいことは、新人が正確な見積をすることはできません。
また、新人でなくても完璧な見積をすることはできません。
できることと言えば、あくまで見積と実際かけた時間の差を縮めることです。
そして、正確な見積ができないことくらい上司であれば百も承知です。
これを前提にしておいて問題ありません。
なので、できるだけ正確な見積を目指すことはいいことですが、実際の作業時間が見積からずれたからといって酷く落ち込む必要はありませんし、
見積からずれることを恐れてやたらとバッファをとった見積にする必要はありません。
実際の作業が見積もった時間よりも大きくずれる場合、もしくはずれることが予想される場合は、上司に報告しましょう。
現状を知ることが出来れば、上司もフォローしたりアドバイスを与えることができます。
次の作業を他に振ることもできるので、報告が大事ですよ。
新人プログラマー・エンジニアが見積を聞かれた時の答え方
「これ何日でできる？」と言われた場合の答え方は、状況によって使い分けることが大事です。
なぜなら、あまりに適当な答えをすると、後々困った状況になることもあります。
なんとなく予想できますよね。
「あの時こう言ったでしょ」と言って、見積から実際かかった時間に差がおきた時に怒られちゃいます。
３つの状況に合わせた答え方を習得しましょう。
- これまでに似たようなことを経験したことがある場合の答え方
- 初めて経験することばかりの場合の答え方
- 懸念事項が多い時の答え方
それでは解説していきます。
これまでに似たようなことを経験したことがある場合の答え方
これまでに似たようなことを経験していれば、「新人プログラマー・エンジニアが見積をするときのポイント３つ」に気を付けながら見積をした結果を伝えるだけでOKです。
これいつまでにできる？
（これは前にも同じようなことをしたからそれを踏まえて….）
だいたい３日でできます。
ただ懸念点が１点あって、………ですがここが〇〇となっていた場合は更に２日ほど伸びる可能性があります。
このように、まずはおおよその見積日数を伝え、その上で懸念点がある場合は、それを説明し何日伸びるかあらかじめ伝えておきましょう。
正直何日伸びるかは、やってみないと分からない部分があるのでそれは追々全容が見えてきたときに伝えればよいです。
初めて経験することばかりの場合の答え方
正直、やったことがない作業を見積もることが一番難しいです。
なので、初めて経験することが多い場合は、そのことをまず伝える必要があります。
そして、全体の作業をざっくりでも見積もれるだけの情報収集・調査の時間を最初にとる必要があります。
これいつまでにできる？
ほとんど経験がない作業となるので、実際のところどの程度かかるかは今の段階では見積もれません。
作業手順・作業量の確認を最初にさせてください。
こういえば、まぁ分からないよねって上司も納得しやすくなります。
誰に尋ねるといいか、自分の時はこうだった、など上司にアドバイスを貰えるように今の現状を素直に伝えましょう。
懸念事項が多い時の答え方
これいつまでにできる？
なにも問題が起きなければ、３日ですが、懸念点が多く伸びる可能性があります。
問題があった場合には、ご相談させてください。
経験があっても、いや経験があるからこそ懸念事項が多い場合があります。
そういった場合は、大まかな見積をすることはもちろんですが、作業の節々で今の状況を上司に伝えることが重要になります。
上司にとって、最も懸念していることは予定していた通りの時間に、成果物があがってこないことです。
なぜなら、仕事には必ずお客様がいて、プログラムが完成することを待っているのです。
納期まで余裕がある場合はいいですが、そうでない場合は予定通りに進まないとお客様との契約問題に発展する恐れもあります。
ですが、作業の途中でここで行き詰っている、この作業で時間がかかっている、今ここまで進んでいるが予定より何日遅れる
といった報告を行うことで、上司は作業の進み具合が把握でき、困っているならアドバイスを行い、作業量的に問題があるのであればもう一人フォローに入れるなど手を打つことができるのです。
ここの部分で困っています。あと〇日かかります。
分かったわ。その部分は、フォローがあったほうがいいですね。
〇〇さんと一緒に作業を進めてください。
見積方法を知っておこう
ざっくりとした見積方法だけでは、「見積できない！」 という方もいるかと思うので、見積方法について紹介します。
取り入れられる場合は取り入れてください。
作業時間の記録を残して、実績から見積もる
各タスクごとに実際にかかった時間を毎日記録しておきます。
そこから平均的に何に何時間かかっているかを見積もる方法です。
この方法だと、実際にかかった時間をもとに次の仕事の見積を行うので、
実績をもとに見積作業を行えます。
タスクを更に細分化して、見積もる
プログラミング、テストみたいな大まかな作業のタスクを更に細分化します。
例としてテストを上げるなら、このようになります。
| パターン概要 | １ケースにかかる時間 | ケース数 | 合計時間 |
|---|---|---|---|
| A項目を確認するためのテストパターン | 15分 | 10ケース | 2.5時間 |
| B項目を確認するためのテストパターン | 30分 | ３ケース | 1.5時間 |
| C項目を確認するためのテストパターン | 5分 | ６ケース | 30分 |
合計でテストには、4時間半かかると見積もることができます。
このように、出来る限りタスクを細分化することで、より明確な見積を行うことができます。
これをもっと細かくするとパターン①は～とかになりますが、流石にそこまでやると見積するだけでめちゃくちゃ時間がかかってしまうので、ある程度のところで止めておきましょう。
新人エンジニアが見積を聞かれた時は、とりあえず大雑把にでも見積もること
新人エンジニア・プログラマーにとって、作業時間の見積は簡単ではありません。
ですが、見積を大まかにでも行うことで、作業全体の把握ができ、プロジェクトを円滑に進めることができます。
上司からも自分が何をすべきか分かっている、と評価してもらえます。
また、見積から差分が生じた場合は上司に報告しましょう。
出来る限り自分だけが納期に間に合わないことを知っている、という状況を脱却しておくこが大事です。
なので、大雑把でもいいので、
「これいつまでにできる？」
に答えられるようになりましょう。
コメント