作業工数ってなんだろう？工数を算出するまでの流れを考えてみた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部＠札幌の佐藤です。
普段仕事していて、工数の算出ってどうしたらいいんですかという質問を受けるときがたまにあります。
私も今まで自分の中にあるルールを具体化できていなかったため、このタイミングで工数の算出について明文化することにしました。
あくまで私の経験によるものとなりますので、本来のあるべきからそれている可能性、プロジェクトによってはあてはまらないケースあると思いますが、ご了承いただければと思います。
また、こちらはプロジェクトマネージャー向けというよりは作業者向けとなっておりますので、その点もご了承いただければと思います。
そもそも作業とは何か
プロジェクトにはゴールがあります。
開発であれば、ある期間の中でシステムを構築・設計するなどがあると思います。
保守運用も作られたサービスに対してお客様のご要望に実現するという点において、開発よりも小さいですがゴールが存在します。
プロダクトを作る・設計を行う、資源の改修を行うなど、ゴールの種類は様々あり、様々な粒度が存在します。
ですが最終的にはドキュメントや開発をします。それが納品するしないにかかわらず、何かを作ることになります。
つまり作業とはゴール（求められているもの）に向けて、何かしらを作るということになります。
上で書いた通り、作業というのは様々な粒度が存在します。
WBSでのセオリーは最小粒度でタスクを分解することですが、うまく分割されていないケースや、さらに細かく分割しなければならないというケースが存在します。
今回は主に後者の「さらに細かく分割しなければならない」という点にフォーカスしていきたいと思います。
私たちは何を求められているのか
一般的に「作業をする」というよりは「作業が割り振られている」という言葉のほうがしっくりくるのではないかと思います。
「作業が割り振られている」＝「その作業には何らかのゴールがあってその完成を依頼されている」ということになります。
ただ、ここでいう「完成」とはなんでしょうか？
単純にものを言われたように作ることでしょうか？
求められていることの背景を知るということを最初にイメージする、というのが物事のスタートになると思います。
そもそもカレーを作る必要がないのであれば、別にカレーじゃなくてもよくないですか？という話です。
背景を理解できると、結局こういうことをやらなきゃいけないんだな？という推測が生まれます。
つまりここはWHYにあたるところです。
背景を理解するには
開発で考えてる場合、それがVモデルであれば、上流まで追いかけていくのが分かりやすいと思います。
そもそも作成する機能は何者で、どうしてほしいのかはそこに書いてあります。
書いてなければ上長に確認したほうが良いです。
上流に行けば行くほど「そもそも」が書いています。そもそもを追うというのが必要です。
追いかけない場合、自分が今何をやっているのか分からず、とりあえず目の前の作業だけを行います。
全体感を失っていますので、そもそもやらなくていいことをやったり、真にそれが必要なのかという視野を失います。（N敗）
運用で考えるのであれば、お客様からの依頼がなぜ依頼されているのかというのを考えるべきです。
昔、運用担当時にお客様から設計書を提供をお願いされたことがありました。
そのときは、ほーん、設計書なんてすぐ渡しますよーって感じで渡しました。作業としては単純ですよね。
ただ上司からは、何故渡したのか。その背景を考えた？といわれました。
ここの背景を妄想すると、「お客様が何かをやろうとしている」「うちの会社ではない別の会社に渡そうとしている」などが浮かび上がります。
そこが理解できていない＝真に何を求められているのかを理解しないで行動した。
（このケースにおいては最終的に引き渡すことになりますが、背景を理解することでお客様側の背景を理解することになります）
それが適切であったのかどうかはちゃんと考えるべきです。
背景を理解すると
ここで初めてゴールに向けて何かを作るということになります。
ただし、ここでは上司のイメージとのすり合わせはほとんどできていません。
（多分こんな感じなんだろうなーという推測レベルで落ちています）
ここから私は何をすべきかという観点で考えていく必要があります。
私たちは何をすべきか
じゃあ早速何か作りましょうとなったときにすべきことは以下3点です。
- 最終到達地点（何を作るのか）の確認
- 品質（どのくらいのものを作るのか）の確認
- スケジュール（いつまでにできるのか）の確認
この3つはお互いにそれぞれ関連しています。
次はこのそれぞれの確認ついてみていきます。
最終到達地点（何を作るのか）の確認
ここはWHATにあたります。
カレーでいえば「カレーライスですか？ナンですか？」「ライスは白米ですか？」「チキンカレーですか？」になります。
開発であれば、その作業の成果物はソースコードだけなのか、単体テストドキュメントを用意するのかという観点です。
もう少し細かくいうのであれば、ソースコードの何を作らないといけないのかです。
何を作らなければいけないのかというのは、脳死的に考えれば指定された資源や資料を作成すればよいです。
それが適当であるのか（そもそもやる意味あるのか？）は前段の背景を理解しなければ議論することができません。
1回しかやらない作業のドキュメントを求められている場合、1回しかやらないことを知らなければ単純にそれを作ればよいという考えになります。
背景を理解している場合、ここにそもそもやらなくてもいいんじゃないか？という観点が追加されます。
そのうえでドキュメントを作成するということになれば、その完成が最終到達地点となります。
当然ですが最終到達地点を誤ると、単純に手戻ります。
推測でいいので、これを作る予定ですということを上長、あるいは開発のリードと認識合わせしておくのが良いでしょう。
プロジェクトにアサインしたばかりの場合、ここでソースコードなどの資源の全量について聞くことになると思います。
（カレーを作るのに必要な材料はここで説明されるイメージです）
品質（どのくらいのものを作るのか）の確認
これはWHATの中でのMUCHになるところだと思っています。
カレーをルーから作るのか、スパイスから作るのか、スパイスの原料を育てるところから行うのかという点です。
品質はこだわればこだわるほどある一定までは向上します。
ですが、そもそもそれをやることってできるのでしょうか。
物事には大体制限時間が存在しています。
プロフェッショナルでいる限り、制限時間の中である一定のものを完成させる必要があります。
ただ、そのある一定のものとはなんでしょうか。
テスト証跡を細かくとろうとすればどこまでも細かくとれます。
ドキュメントも細かく書こうと思ったらどこまでも細かく書けます。
そのレベルは開発という大きなスケジュールの中でどこまでやれるのかというところによります。
（ドキュメントについては、保守運用での維持管理可否という側面も追加されます）
ここで理解しておくべき背景は、全体スケジュールです。
保守運用であれば、その作業のエンドです。
too muchにならないように、どの程度のイメージであるのかを上長とすり合わせておくのがベターです。
最終到達地点は認識通りなのに、ここを誤ってしまうと、自分の負荷が無意味に上がっていくことになります。
スケジュール（いつまでにできるのか）の確認
上でも書いた通り、物事には制限時間が存在します。
そしてWBS上に表現されている各タスクの制限時間は、必ずしも自分のスキルレベルにあっていないケースがあります。
また、調査していく中であり得ないほど難しかったというケースもあります。
ですが、WBS上に表現されている制限時間の超過は、ある一定の状況において許されなくなります。
ある一定の状況というのは、例えていうのであれば予定完了日の寸前に言うことです。
信頼を失う行為なので、自分の評価を考えるのであれば認識したほうが良いです。
「ある一定の状況において許されなくなります」ということは、許されるタイミングもあるということになります。
それは作業の開始時点から近ければ近いほどです。
これは何を指すのかというと、リソース調整ができるという点です。
（私がカードゲーマーなのでそういう例えをしますが）最初（タスクを割り振られたとき）に手札に持っているカードは基本的にはこの6枚かなと思います。
- 「スコープの引き直し」
- 「スケジュールの引き直し」
- 「担当者変更」
- 「担当者の分担」
- 「残業」
- 「休日出勤」
このカードは好きなタイミングで好きなカードを場に出すことができますが、時間経過で1枚ずつ手札から捨てます。
捨てられるカードは担当者の負荷が低いもの（数値の小さいもの）から捨てられます。
手札が空になる前までに完了した場合はゲームに勝利、手札が空になった場合ゲームに敗北します。
自分の理想的なカードを出したいのであれば、常に手札に今何があるのかを意識すべきです。
作業というゲームに勝つためのセオリーです。
ただし、自分の理想的な手札を切るためには相手に納得してもらう必要があります。
ここは後ほど、工数の算出であらためて記載します
私たちはどこまでやらなければならないのか
ここも作業をするにあたって重要な要素となります。
ここでいうどこまでは「カレーを何故作るのか」ということではなく、「カレーをどこまで私が作るのか」です。
「カレーを作る人とご飯を炊く人は別なのではないか」という話です。
ここは非常に抽象化されやすいところです。
基本的に作業は最終到達地点（あるいは変更された到達地点）に到達するまで
開発であれば、作業をしていくうちに設計の不備などでその担当者とコミュニケーションをとることがあります。
また、開発も保守運用も、お客様へ確認するということもあります。
その場合、どこまでが自分の担当なのでしょうか。
上記状況は、自分の手から離れてしまっている状態となるからです。
結論から言うと、最終到達地点（何か作らなければいけないものを作る）までは、誰の手に渡っていても自分のタスクです。
ソースソードの実装であればその実装が終わって単体テストが完了するまでというのが最終到達地点であれば、そこに到達するまでは責任もって遂行する必要があります。
作業が誰かの手に渡っているということは、誰がか自分の制限時間を奪っていることになります。
上でも書いた通り、手札にあるカードを無駄に捨てたくなければ、ここを自分でコントロールする必要があります
具体的なコントロールというのは、「いつまでにできそうですか？」という質問になります。
自分の手札から自分にとって都合のいいカードをを出したいのであれば、より具体的な日時を確認すべきです。
来週までかかるのであれば、「スケジュールの引き直し」「担当者の変更」のカードを出します。
そうすることによって、最終到達地点が変更されることになります。
逆にいつまでかかるのかわからないという回答をされた場合、出すべき札が判断できなくなります。
その場合どういう結果になるのかは、考えなくても分かるはずです。
また、自分が得するカードを出したいのにその判断を与えてくれない人に対し、どういう感情になるのかも、分かるはずです。
最終到達地点までの道のり
ここまで最終到達地点という名前で話していました、この最終到達地点ですが、ゴールがあればそこまでの道のりがあるはずです。
工数を見積もるためには、どんなプロセスで最終到達地点に到達するのかを認識合わせする必要があります。
マラソン中継で勝手にショートカットする人は見ないですよね？
道のりを誤っていると、やらなければならないことをやっていないことになりますので、大きく手戻りが発生します。
最終到達地点までで考えられるものとしては、主に以下3つです。
- 最終到達地点に到達する前提の整理
- 作業をして最終到達地点へのゴール条件をそろえる
- 到達する条件が適当なのか判断
「最終到達地点に到達する前提の整理」については、「私たちは何をすべきか」にて書いたものになります。
「作業をして最終到達地点へのゴール条件をそろえる」は、前提の通り作成しなければならないものを必要な品質で作り上げることです。
「到達する条件が適当なのか判断」は、「作成しなければならないもの」が「必要な品質であるのか」をチェックするものです。いわゆるレビューになります。
レビューについて
※ここではどのようなレビュー方法が適切なのかについては言及しません。
何故レビューをするのかは、上で書いている通り「必要な品質であるのか」を確認するものです。
ここまでさまざまな確認をしてきたと思います。
ただ、それが100％認識があっているってどうして言えるのでしょうか？
自分があっているのか不安になりませんか？
ここでは第三者がその判断が適切であったかのジャッジをすることになります。
第三者の冷静な意見によって、気づかなかった観点に気付くことになります。
そしてその観点を整理し、保守運用でチェックポイントとして昇華することで俗人化の呪縛から離れることができます。
ここでいう第三者というのは誰でしょうか？
それは、レビューのルールによるというのが回答になります。
レビューは「自社の人間」ある場合、「自社とお客様」である場合両方あり得るためです。
そのため、誰にレビューするのかは確認すべきです。
もうひとつこのレビューのポイントして、ここで責任範囲が「個人から集団」に切り替わることです。
簡単に言うとすると、お前らがいいって言ったんだからミスっても私だけのせいではないというものです。
レビューを行うことで担当者の心理的な負荷が軽減されることになります。
最終到達地点までのスケジュール（工数）を決める
ここまで来て初めて「スケジュール（いつまでにできるのか）の確認」をするための武器が揃います。
ここまでの話を表として整理します。
ここまでの説明は、画像1枚目のフローの話になります。
ここの領域のうちひとつでも分からない場合は、私って何をすればいいんでしたっけ？になります。
ここで不明点がある状況はアサインされたすぐの状況が主に該当します。
プロジェクト自体の理解度が進んでくると意図しなくても自然と知っている状況となり、特に考えなくなるところもあります。
（開発内容やレビュー方針等）
ここまで整理されてくると、最終到達地点までに何を作って、どのようなフローを行うと完了できるのかが見えてきます。
ただし、ここまでではどんな感じに作成・改修すればいいのか具体的なものははっきりとはしていません。
WBSで用意されている日程が適当であるのかどうかが、分からない状態となります。
ここからは今まで手に入れた情報から、自分ならこの日程で完了できるだろうという観点で考えていくことになります。
今まで理解した内容から、作業をリストアップする
ここまでわかってきた「道のり」や「作業品質から」から何をどのくらいのレベルで作らなければいけないか、完了までの作業を考えます。
ひとまず新規開発を例に進めます。
今まで聞いてきた感じだと、多分開発して、テストして、それをレビューしてもらって、資源をPUSHするんだなーというのがなんとなくわかっているはずです。
それが一番粒度が粗い概念となります。
そこからもうひと段階、細かい粒度にしていきます。
ここが最初に話した後者の「さらに細かく分割しなければならない」という状況です。
何故細かくするのかというのは、非常に単純でこのレベルでは作業の網羅性（何を作ればいいんだっけ？）が見えないためです。
作業を最小作業粒度まで落とし込んでおけば、ゲームのデイリーミッションをクリアするように上からなぞっていけばいいだけです。
次に何をしなければいけないのかということを無駄なカロリーを消費しません。
もうひと段落細かくしてみました。
ここからもうひと段落細かくして、最小作業粒度まで落としましょう。
内容によってはこの段落で作業が最小粒度になっているものもあると思います。
ここまでできると最終到達地点まで向かうため道しるべが完成します。
道しるべそれぞれの作業工数を考える
例えば友達と旅行に行く計画を立てるときに何を考えるでしょうか。
最初に考えるのは、どこに行くかだと思います。
1日しか休みがないのにハワイに行きたいということは言わないはずです。
それはなぜかというと、飛行機での移動時間がどう考えても休みの24時間にはまらないからです。
上で最終到達地点まで向かうため道しるべを作りましたが、これも同じです。
WBSで用意されている工数では、どう考えても難しいという状況があります。
これは今までなんとなく道しるべを作っていく過程で肌感覚で思っているはずです。そしてその第六感は大体あっています。
その場合は手札にあるカードのうち、「スケジュールの引き直し」を出したいと思うはずです。
このカードを出すことで自分が残業しなくて済むからです。
プロフェッショナルであるためには、このカードを出すための根拠が必要となります。
普段生活していてもそうだと思いますが、根拠のない発言に対しての回答は常に「ソースは？」です。
「ソースは？」といわれないように根拠を作っていきましょう。
ここで絶対に守らなければならいルールがあります。
このルールは絶対に守ってください。
- 頑張ったらこのくらいでいけるという時間を書く（バッファは入れない）
- 0.5時間単位で書く
それぞれの理由については別セクションで記載しています。
工数の算出法は「パラメトリック」や「類推」、「トップダウン」など様々なものが存在しています。
私の経験ではトップダウン（今まで設した背景から何を作るのかという流れ）で工数を算出していたため、今回はそのような形での工数の算出としています。
工数を算出する際に考えられることは大きく4点あります。
- （できる）ほかの機能をコピペすればいい
- （できる）ちょっと重たいけどやれる
- （できる？）調べなければわからない
- （できない）何を直せばいいかわからない
「できる」に該当するものについては、設計書やアーキテクチャなどをみた結果からの判断になります。
既存機能の模倣で行ける場合は、工数は少なくて済みます。
ちょっと重たそうというのは、定量的な指標が出しにくい（担当者のレベルによるため）ですし、どのくらい積めばいいのかわからないです。
ここは今までのカンにどうしても頼ることになります。
それだと何か起きたときのリカバリができなくなりますので、バッファで調整するのが良いと思います。
調べなければ分からない場合は、工数を出す前にエスカレーションすべきです。
この場合、新規開発作業の前に、機能調査を先にスケジュールすべきだからです。
その場合は調査にどのくらいかかるのかを明示する必要があります。
何を直せばいいかわからないという場合は、有識者を見つけなければ工数を積むことができませんので、工数を積む前に認識合わせをしてください。
勝ち見込みのない工数見積もりは何の意味もないです。
自分の中でこれならいけるというイメージを付けてから臨みましょう。
ただし、その間にも作業の制限時間は近づいていますので、急ぐ必要があります。
ここまでのルールを守って書いてみると大体このような感じになります。
※一番小さい工数は人日と時間があるので、ちゃんと明記しましょう。
頑張ったらこのくらいでいけるという時間を書く（バッファは入れない）
バッファを入れない理由は、バッファも根拠がなければならないためです。
なんとなくヤバそう、でもここは大丈夫そうで入れると、結局どのくらいの余剰を用意したのが、第三者が理解できないですし、自分も説明できないので、その工数の妥当性が誰にもわからなくなります。
また余剰の最終的なジャッジは上長が実施するのが妥当です。
明らかにかけすぎなバッファはWBSに合わせて調整されますし、複数人で実施するカードを出してくれる可能性があります。
また、頑張った場合と余裕がある場合の2点で工数を出すことで、作業結果から次の作業の指針になります。
0.5時間単位で書く
ここはシンプルに30分未満にすると、トイレ行った時点で遅延になるためです。
人であることを辞めたくなければ、基本的には守ったほうが良いと思います。
ただし、テーブルへの複数データ登録を1クエリできるなど、複数の最小単位作業を1回でクリアできるという状況であれば、この限りではありません。
作業工数を伝える
ここは「最終到達地点までのスケジュール（工数）を決める」ですので、スケジュールを決定する必要があります。
ここまで考えてきたことを上長とすり合わせて、了承してもらうことがゴールです。
上で作った資料をそのまま持っていけばOKであるという考えもありますが、私個人としてはこの資料は未完成です。
以下3つがないからです。
- この資料は誰に見せるものなのかを考えていない
- バッファなどの算出前提条件がない
- 報告軸がおかしい
ここまでの内容を反映するとこのような感じになります。
これでようやく、上長に工数について討議をすることができます。
この資料は誰に見せるものなのかを考えていない
ここは最初の背景で言うところの体制図を見ているのかどうかの話となります。
上の人たちは、どういった情報が欲しいのかと考えたときに、粒度が細かいことが必ずしも正義であるとは限りません。
ここでのゴールは、スケジュールを決定することで作業内容を報告することではありません。
PMOクラスの人は作業内容の情報を必要だと思っているのかと考えたときにそうではないということは分かりますよね。
工数を見せる人にその工数感が伝わらなければ意味はありません。
例えば修正資源が100機能分ある場合、工数が妥当なのかどうやって判断するのでしょうか。
また、それをどうやって説明するのでしょうか。ひとつひとつ話していたら1日かかってしまいます。
もう少しサマリーで見たいと思うはずですし、説明もそっちのほうが楽なはずです。
ということなので、粒度をもう少し粗くしましょう。
作業単位でもちょっと説明しにくそうですね。
テストコンディションの作成とテストクラスの作成のそれぞれの工数を上長に説明する必要があるのでしょうか。
もう少し大きいレベルにサマリーします。
おそらくここの粒度で説明するのが良いと思います。
ただし、サマリしすぎて詳細が分からなくなっているので、そこは備考で根拠を補記するのが良いと思います。
修正資源が100機能分ある場合は、難易度で松竹梅つけて「難易度A：5h×20本、難易度B～」という感じで概算レベルで根拠づけするのが良いと思います。
当然ですが、粒度をどこまでにするのかというのは「見せる人が誰なのか」によります。
開発リードのレベルであれば、最小粒度のままでもよいでしょう。
バッファなどの算出前提条件がない
上で書いたように、今の状態は頑張った場合になります。
何か問題が起きた場合この工数での完了が難しい可能性があります。
そのため、作業にバッファをつけていきましょう。
どのくらいつけるのが良いのかというのは、正直人に寄りますが私は基本は1.2掛け、リスクが多い場合は1.5掛けします。
そしてこのバッファを付けた根拠も示すことが重要です。
上でも書きましたが何を根拠にバッファを用意しているのかが分からないと、それが適当なのかが分からないためです。
ここは素直に自分が思っているリスクを書いておくのがベターです。
リスクが実は難しいものではない可能性があります。
議論の中でそれが分かれば、自分の中で腹落ちできれば1.2掛けでよいということになるためです。
また、バッファの計算を最小作業にそれぞれに掛けていくか、それとも合計に対してかけるかという問題もあります。
ここは、人それぞれの考え方になるのでそれぞれ良い方法でやればよいと思います。
私は合計に対してかけることが多いです。
理由は最終的に作業した場合に、中途半端な作業時間になった場合に一体何分で終わるのかが見えにくくなるからという点、
最後に工数を人日単位にする際に、工数を分かりやすく丸めますが、増減した時間をどの作業から調整するのかを考えるのが面倒だからです。
報告軸がおかしい
お客様と会話するときに「時間」で話すことは基本ないと思います。
「時間」という言葉の中には、1日の時間と、営業時間のふたつの意味があるからです。
この資料では時間でものを語っていますので、これを営業時間（人日）に変換する必要があります。
必要に応じて人月も用意する必要があります。
作業を着手しよう（おわりに）
ここまできてようやく作業がスタートできます。
難しく書いているところもありますが、基本的には以下をひとつひとつ確認していこうということです。
- なぜこれが最終到達地点（作るもの）なのか（背景）
- 最終到達地点はなにか（成果物）
- どのくらいのレベルを作るのか（品質）
- 最終到達地点まで何をしなければならないのか（フロー）
- いつくらいにできる予定なのか（スケジュール）
ここから作業を進めていきますが、作業中もいろいろな問題が発生します。
常に自分の手札に何が存在していて、具体的にどのくらいで終われるのかということを考えながら進めていただければと思います。
