なぜ、仕事が大きくなると手が止まるのか

こんにちは。ウォンテッドリーの Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。

現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は小室さんによる「【入社エントリー】なぜSIer出身者がウォンテッドリーへ転職したのか」でした。今回は私が日頃から仕事で大事にしている段取りの話をします。

はじめに

この機能をまるっと任せたい / この課題をなんとかしてほしい

エンジニアとして経験を積んでいくと、ある時から「この機能をまるっと任せたい」「この課題をなんとかしてほしい」といった、粒度の大きな仕事を任される機会が多くなります。実装方針やタスクの切り方、スケジュールの立て方まで自分で考える必要があり、責任と裁量の両方を担うことになります。しかしその自由度ゆえに「どう手をつければいいのか分からない」と悩んだ経験がある方も多いのではないかと思います。

粒度の大きな仕事が進まない原因は段取り不足

粒度の大きな仕事には「このAPIを実装してください」や「このバグを直してください」と言った明確な仕事とは異なり、問題そのものをどう捉えるかや、どう解きほぐして実現まで導くかを自分の力で考えることが求められます。しかし、それを従来の感覚のまま「まず手を動かす」ことから始めてしまうと、気づいたときには何をしているのか分からなくなってしまうことがあります。

今回はそうした「粒度の大きな仕事」で私が実践している「段取り」の進め方を言語化していきます。日々の開発に忙しい皆さんが前に進むためのヒントを提供できればうれしく思います。

段取りとは

単に納期から逆算してスケジュールを引くことではない

ここで言う「段取り」とは、単に納期から逆算してスケジュールを引くことではありません。むしろ、仕事を始める前に「どうやってその問題を解いていくか」を自分の頭で整理するプロセス全体を指しています。

私が考える段取りの目的は、大きく2つあります。1つは問題を見通せるサイズにまで小さく分けること、もう1つは自分やチームが「この順番で進めればうまくいきそう」と納得感を持てる状態を作り出すことです。

数時間で終わる実装タスクと違って、粒度が大きい仕事では「何から手をつければいいかわからない」「このまま進めて本当に終わるのか不安」といった感覚に陥りがちです。そうした状態で進めてしまうと、いつまで経っても仕事が終わらなかったり、スコープが膨らんで手に負えなくなったりすることもあります。

だからこそ、作業に入る前に「自分はこういう順番で進めるつもりだ」と明文化しておくことが重要です。この段階で見えていなかったリスクや、曖昧だった部分があぶり出されることも多く、結果として後のコミュニケーションや見積もり精度も上がっていきます。

どう段取りをとるか

段取りの重要性を理解していても、いざ目の前に大きな仕事があると「とりあえずやってみよう」「報告用にはとりあえずガントチャートを作っておこう」と考えてしまうことがあります。納期から逆算してガントチャートを引き、見積もりを埋めるようにして予定を組むアプローチは一見して理にかなっているように見えますが、実際にはうまくいかないことが多いです。

最初に完成系を描かず、徐々に輪郭をはっきりさせていく

こうした進め方の問題は、全体像が見えないまま手を動かしてしまうことにあります。特に、粒度の大きな問題では、前提が曖昧なままスケジュールを作ってしまい、途中で見積もりが破綻したり、タスクの抜け漏れに気付いたり、進め方の実態とズレてしまったりして大きな手戻りにつながることがあります。仕事の計画とは本来、最初に完成系を描くものではなく、徐々に輪郭をはっきりさせていくものです。

具体例で考えてみる

4つのステップ

例えば、"プロジェクト" の段取りにおいて私が実践している進め方は、次の4ステップを順番に踏んでいくというものです。段取りを丁寧に進めることで、自分やチームが納得感を持って仕事を進められるようになり、スケジュールの精度や実行可能性も自然と高まっていきます。

大きな問題（数週間〜数ヶ月）を小さな問題（数日〜1週間）に分解する
小さな問題を解くステップを考える
ステップごとの工数をざっくり見積もる
スケジュールに落とし込む

1. 大きな問題（数週間〜数ヶ月）を小さな問題（数日〜1週間）に分解する

たとえばブログサービスに、「いいね機能を追加する」という1つの大きな問題も「ユーザーが投稿にいいねを押せるようにする」「ユーザーがいいねを取り消せるようにする」「投稿ごとのいいね数を表示できるようにする」といった複数の小さな問題に分けることができます。ここでの目的は扱いやすいサイズに砕くことです。

分解した問題の解決イメージが不明確な場合は、さらに問題を分解します。目安として、表記に人ごとの解釈ブレが発生しうるリスクがあったり、自分自身どうやって問題解決すればいいのか不安な場合は分解不足です。

2. 小さな問題を解くステップを考える

問題分解だけで終わらせてしまうと、いざ手を動かすときに「で、どうやってやるんだっけ？」と手が止まってしまいます。小さな問題ごとに、どんな手順で解いていくかをあらかじめ考えておくことで、作業に迷いがなくなります。

たとえば、いいね機能の例でいうと、「いいね」を押せるようにしないと取り消せすことが出来ないので問題に依存関係があります。

また、よりミクロなレベルでは「ユーザーが投稿にいいねを押せるようにする」の実現ステップにも依存関係があります。この例でいうとUIとAPIが存在しないとその繋ぎこみは出来ません。

最後に、問題同士の依存関係を制約として全体の問題解決ステップを考えます。今回の例だと以下のようなステップになることが分かりました。なお、この段階まで可視化できると実装者以外の人との認識合わせにも役立ちます。

3. ステップごとの工数をざっくり見積もる

次に、それぞれのステップに対して「だいたいどれくらいの時間がかかりそうか」をざっくり見積もります。ここで大事なのは、精密さではなく、タスク間の重さやリスクの見積り感を揃えることです。

私自身が使っている考え方としては、最悪・平均・最良のケースをざっとイメージして、そのレンジ内で「まあこのへんだろう」という幅をもたせた工数を置くようにしています。例えば先ほどの例であれば、以下のように見積もりを出すことで、どのタスクが重そうか、先に確認すべき不確実性がどこにあるのかがはっきりします。

このとき重要なのは、「リスクがあるかないか」「あるとすればどう段取りに反映されているか？」を明確にしておくことです。上の例だとオレンジで「不明（既存のテーブル構造次第）」と書いてあるステップです。リスクによる工数の増減は、その中の一部でしかありません。リスクの存在そのものが共有・理解されていない状態では、どんな見積もりも空中戦になってしまいます。

補足：リスクはどう段取りに反映させるべきか？（後述）

4. スケジュールに落とし込む

最後に、各ステップの実施順と工数を踏まえてスケジュールを組み立てます。ここまでの手順に沿って行なっていれば、タスクの依存関係や優先順位も見えているので、現実的で納得感のあるスケジュールが引けるはずです。

また、ウォンテッドリーではタスクチケットの管理に GitHub Issue を採用しているため、私はスケジュール項目の粒度に合わせてIssueを作成しています。この方法の利点は、仕事の進行に合わせてIssueを順番にクローズしていけるため、どこにマイルストーンがあるか？がPM以外のエンジニアにとって分かりやすくなることです。

いいね機能を追加する (root issue)
- ユーザーが投稿にいいねを押せるようにする (sub issue)
- ユーザーがいいねを取り消せるようにする (sub issue)
- 投稿ごとのいいね数を表示できるようにする (sub isue)

上記より細かい粒度の問題をさらに sub issue に切るべきかは悩ましいですが、私は今回の例であれば sub issue の Issue Description にチェックリストを配置して管理します。

補足：リスクはどう段取りに反映させるべきか

たとえば、あるタスクに「テーブル構造が未確認」「仕様があいまい」などの不確実性があるときは、PoC（実現可能性検証）の作業を1日として工数に含めてしまう、というのもよくやる手です。これは「リスクを潰してから実装する」という考え方です。

逆に、潰しきれないリスクに対しては、次のような工夫で緩和しています。

実装者のスキルに不安がある場合 → 経験のあるメンバーとペアにする
関係者とのやりとりが多く発生しそうな場合 → 工数にバッファを乗せる
影響範囲が広そうな変更 → 早めに着手してスケジュール後半に余裕を持たせる

リスクマネジメントがうまい人ほど、「自分が何を知らないか」をちゃんと把握していて、人に聞きに行ける力があります。自分ひとりで判断がつかないときは、迷わず他のメンバーに相談することも計画フェーズでは大切なスキルの1つです。最近では、ChatGPTなどのAIに一旦相談してみるというアプローチも選択肢になり得ます。