ハトネコエ Web がくしゅうちょう

プログラミングやサーバー・Web制作、チームマネジメントなど得た技術のまとめ

期日(完了予定日)の作り方

0. 最初はわからなかった

働き始めた頃は、「いつ頃終わりそうですか? 完了予定日を設定してください」と言われると「うーん、全然わからない」と困ってしまっていたのですが、
しだいに慣れてきた気がするので、自分の中での期日設定の方法(工数の概算)についてまとめてみます。

期日を考える能力を身につけるのって、
逆に相手側から期日を押し付けられるときにも有効で、
「それならこの機能を入れるのはやめる」とか「その機能は完璧じゃない状態で妥協する」などを
思考したり相手に提案することができて良いです。

1. なんのタスクが発生するか考える

すごく当たり前のことなんですが、大事だし、これが出来ていない人は多く見られます。
ここをミスると、予定していた期日より数週間単位で遅れます

例えば「カレーライスを作る」という大きなタスクがあったときに、
「材料をスーパーで買って」、「鍋にカレー粉を入れる」くらいのタスクしか想像できていない場合に失敗します。

1-1. タスクの粒度を細かくする

先ほどの「カレーライスを作る」タスクですが、まだまだ分解できます。

「買い出しに行くお店を決める」「野菜の皮をむく」「野菜の皮を切る」「肉を炒める」「鍋に水を入れる」「野菜を煮る」
キリがないほどあります。
「野菜の皮をむく」はさらに「にんじんの皮をむく」「じゃがいもの皮をむく」などに分類できます。

ただ、カレーを作ったことがなければそれは想像が難しいかもしれません。

自分だけでは全体が想像しにくいと思ったら、経験者に相談するといいかと思います。
経験者がいない場合でも、誰かと相談しながらタスクを洗い出してみると、自分一人では気付かなかったことが出てくるかと思います。

小さいタスクで分けると「これは数時間」「これは2日は欲しいな」が見積もりつきやすいのでとてもオススメです。

タスクの粒度を細かくするのは、すごく一般的に言われているけれど、
出来ていない人が多いことのように感じます。
プロマネやチームの人に、タスク分解について相談してみるのはオススメです。

1-2. 周囲の足りていないものがないか確認する

1-1 と似た内容です。

自分では「これとこれやれば終わるだろう」と思っていたら、大事なこと(しかも時間のかかること)が抜けていた場合です。

例えば、そもそも家に鍋がなかったとか、カレーが出来てからご飯を炊いてないことに気付くとかw

実際の開発で言うと、Webアプリの改修だけでなく、インフラ側に関してインフラチームとの調整も必要だったのに、
それを全く考慮に入れていなかったとかが起こりがちです。

この意味でも、タスク分解について人と相談するのはオススメです。
複数人で話していると気付くこともあります。

ただまあ、このケースは考慮漏れで起きることもやはりあるので、
そのときはすぐに現状報告をして、期日の再設定をお願いするのがいいと思います。
前述の相談をおこなっていたのなら、プロマネ等も気付かなかったことなので周囲も受け入れてくれるでしょう。

1-3. どこまで行けば終わりかを考える

何が終わればゴールかの認識を合わせておくのはとても大切です。

カレーを作り終えればゴールだと自分は思っていたけれど、
相手は「え、食器洗いとか後片付けまで終わらせてこそでしょ?」と思っているかもしれません。

また、現状からあと何と何をやれば終わりかを常に考えるのも大切です。
つまりは、完了するまで 1-1, 1-2 を常におこなって、残りのタスク状況をアップデートします。
周囲にも、「私はあと〇〇と〇〇をやれば終わりだと思ってるけど、合ってるよね?」と確認しておきます。

期日がだんだんと迫ってきたときに、本当に終わりそうかの判定で特に役立つ手法です。

2. 不確定な要素を探す

タスクを出してみたとき、完了が自分に委ねられていない不確定な要素があるのなら、そのタスクの完了見込みは大きめに取ります。
1-2 で書いた「インフラ側に関してインフラチームとの調整」なんかもその例ですね。

この不確定なタスクを複数残しているのに「あさってには終わりそうです」とか言ってしまうのはアンチパターンです。
だいたい終わりません。

プルリクのレビューなんかもそうです。
あらかじめプルリクに対して「この大きさの修正だとマージまで5日はかかるかもなー」などと大きめに概算しておくといいです。
(プルリクのレビューに対する見積もりは忘れがち)

そして、このタスクが完了するまでが単なる待ち時間とならないよう、
あらかじめ並行してできるタスクを考えておきましょう。

そのスケジューリングをおこなうために、
先に不確定な要素を探しておくことが大事なのです。

3. 70〜80%の力で完了させられる期日を設定する

よくあるのが、各タスクを自分の持つ100%の力でおこなえたときの期日として設定するパターンです。
そんな人間、常に全力出せません。
割り込みタスク(会議だったり経費精算だったり)が発生したり、風邪をひくかもしれません。

自分自身が不確定要素です。
ふだんを考えて、1週間に自分がどれだけ動けるか考えてみてください。

あんまり大きく見積もりすぎるのも問題ですが、100%の力で終わる時間の 1.5〜2倍くらいを見積もっておくと、
仮に 1-2 のような考慮漏れがあったとしても、ギリギリ間に合わすことができるかもしれません。

「目標」は自分の出来るギリギリよりちょっと上を設定することが多いですが、
「期日」はそれと違い、そこまでに終わっていなければいけない日です。
ギリギリを設定せずに、「5分前行動」のような、ちょっとだけ余裕を持って間に合わせられる期日を設定しましょう。

4. 終わらなそうなら早めに期日を変更する

これも苦手な人が多い項目です。
なんか嫌な予感がしたらすぐに報告します。

タスクにとりかかって調査していたら、全然自分のタスク見積もりが甘く、あれこれとやらないといけないことに気付いたり、
急に別件からの差し込みタスクが増えたり、いろいろな予期していなかったことは起こります。

それによって自分の想像していた進捗スピードを出せていないのなら、
すぐに連絡して、事情を説明し、完了予定日がずれこみそうなことを報告します

何も報告をしなければ、相手はあなたの言い出した期日に仕事を終わらせてくるものだと思っています。
待ち合わせと同じですね。集合1時間前に「ごめん、1時間遅れる」と言ってくれるのと、待ち合わせ時間を過ぎてから「ごめん、1時間遅れる」と言い出されるのでは全然心象が違うのと一緒ですね……

(と偉そうに書いてますが、私は待ち合わせ時刻の直前に遅刻の連絡をする人です……ごめんなさい……)

社外向けの告知を出さないような機能実装はこの意識が希薄になってしまいがちですが、
何も言わず期日に間に合わなかった人の評価は「大事な仕事を任せられないな」とそっと下がっています。大事です。

5. まとめ

以上の 4 つが、私が期日と向き合うときに気を付けていることです。
総じて言えるのは、 人と相談すること大事 ってことと 余裕を持って設計しよう ってことですね。

自分の中で「○日までに終わらせたいな〜」と思ったとしても、
期日は「約束の日」なので、それを頭に入れた上でしっかり検討すると、
苦しむ人のいないスケジュールが組めると思います。