最初のタスクをどう選ぶか

最初のタスクは、新人が「このチームで自分は動ける」と思えるかどうかを決めます。 技術的な難易度以上に、設計の巧拙が結果を左右する部分です。

ここで失敗すると、本人の能力とは無関係に、最初の2週間が沈黙で埋まります。 この章では、渡すタスクを難易度で並べる方法と、任せきるか巻き取るかの判断基準を扱います。

良い最初のタスクの5条件

最初のタスクは、次の5つをすべて満たしていることが望ましいです。 1つ欠けるごとに、新人が詰まる確率が跳ね上がります。

条件	満たさないと何が起きるか
影響範囲が閉じている	どこまで調べればいいか分からず、探索が終わらない
正解の判定が明確	「これで合っているか」を自分で判断できず、常に聞きに来る
似た既存実装が参照できる	ゼロから設計させることになり、レビューで全部書き直しになる
1〜3日で終わる	完了体験が遠く、進捗が見えないまま不安だけが溜まる
実際に価値がある	捨てられる練習問題だと分かると、真剣に取り組めない

最後の条件は特に効きます。 「練習用に作った、マージされないタスク」は、本人にもすぐ分かります。 分かった瞬間、そのタスクは評価される仕事ではなく、時間つぶしに変わります。

小さくてもいいので、本番に入るものを渡してください。 バリデーションのエラーメッセージが1つ親切になるだけでも、 それは誰かの役に立つ変更であり、レビューもマージも通ります。

難易度の階段

タスクは「簡単／難しい」の2段階ではなく、階段として並べてください。 各段には、そこでしか学べないものがあります。

段	タスク例	ここで学ぶこと	目安
1	画面の文言修正、エラーメッセージの修正	開発フロー全体。ブランチ・PR・レビュー・デプロイの一周	半日
2	既存関数へのバリデーション追加	既存コードの読み方、テストの書き方、境界値の考え方	1日
3	新しいエンドポイントを1本追加	レイヤー構成、既存パターンの模倣、エラーハンドリングの作法	2〜3日
4	既存機能の改修	影響範囲の調査、後方互換、既存仕様の読み解き	3〜5日
5	設計判断を含む機能開発	選択肢の比較、トレードオフの説明、他人との合意形成	1〜2週間

大事なのは、1段目を飛ばさないことです。

1段目は技術的にはほぼ何もしていません。 しかし新人にとっては「このチームで変更を本番に届ける経路」を一周する体験であり、 ここが通っていないと、以降のすべての段で「デプロイってどうやるんだろう」が付きまといます。

一方で、各段に何日いるかは人によって大きく変わります。 経験者なら、1段目を1時間で終えて2段目・3段目を同じ週に渡して構いません。 逆にプログラミング自体が初めてなら、2段目に2週間かけてもおかしくありません。

固定すべきなのは順番であって、滞在時間ではありません。 上の表の「目安」は、達成すべきノルマではなく、 詰まりを検知するための基準線として使ってください。 目安の2倍を超えたら、様子を見に行く合図です。

段が上がった時に何を変えるか

難易度を上げる時、変えるのはタスクの大きさだけではありません。

• 1〜2段: 完了条件をこちらが全部書く。参照すべきファイルも指定する
• 3段: 完了条件は書くが、どのファイルを触るかは本人に調べさせる
• 4段: 「何を作るか」だけ伝え、影響範囲の調査から任せる。調査結果をレビューする
• 5段: 課題だけ伝える。設計案を2つ以上出してもらい、選んだ理由を説明してもらう

支援を減らす順序は、手順 → 調査 → 設計です。 いきなり設計から任せると、たいてい戻ってきません。

Good First Issue は「貯める」もの

最初のタスクが用意できない最大の理由は、新人が来てから探し始めるからです。 忙しい時期に、条件を5つ満たす都合のいいタスクが転がっている確率は高くありません。

やるべきなのは、日頃からの積み立てです。

1. 開発中に「これ直したいけど今じゃない」と思ったら、その場で issue を立てる
2. good first issue のようなラベルを付けておく
3. 気づいた時点の文脈を、その場で書き足しておく
4. 受け入れが決まったら、貯まった中から難易度順に3〜5個選ぶ

3 が肝心です。「あとで書く」は書かれません。 気づいた瞬間なら、関連ファイルも参考実装も頭に入っています。 数ヶ月後の自分は、それを一から思い出し直すことになります。

issue に書いておく項目

新人からの質問は、書いてある情報の量に反比例します。 最低限、次の4つを書いてください。

項目	例
背景	なぜ直すのか。今どう困っているか
関連ファイル	「入口はこのハンドラ。バリデーションはこのファイルにまとまっている」
参考になる既存実装	「同じことを別の項目でやっている箇所がある。そこを真似ればよい」
完了条件	動作で書いた受け入れ基準。テストの有無

このうち 「参考になる既存実装」の効果が突出して大きいです。 新人が最初に詰まるのは書き方ではなく、 「このチームではどう書くのが普通なのか」が分からないことだからです。

やってはいけない最初のタスク

次の4つは、状況を問わず失敗します。

1. ドキュメント修正だけで2週間

親切のつもりで渡されることが多いパターンです。 しかし本人は「コードを触らせてもらえていない」と受け取ります。 そして2週間、開発フローを一度も通らないまま過ぎます。

ドキュメント修正自体は良い課題です。ただし初日の半日で終わる量にしてください。

2. 誰も仕様を知らないレガシーの改修

「ちょうど誰も手を付けていない領域があるから」という理由で渡されがちです。 これは新人にとって最悪の組み合わせになります。

• 既存仕様を聞ける人がいない
• 正解かどうかを判定できる人もいない
• 詰まっても、それが本人の実力の問題か、そもそも難しいのか切り分けられない

チームの誰も答えを持っていない問題は、新人向けではありません。

3. 本番障害対応

「実地で学べる」は本当ですが、最初の1ヶ月には向きません。 時間的なプレッシャーがある状況では、本人は質問を我慢し、 周囲も説明する余裕がありません。学習効率が最も落ちる環境です。

障害対応は、まず横で見せるところから始めてください。

4. 「なんでもいいから触ってみて」

自由度が高いタスクは、ドメイン知識がある人にとってだけ自由です。 何も知らない人にとっては、選択肢が無限にあるだけの迷路になります。

言われた側は、たいてい何も選べないまま数日を過ごし、 「何をしていいか分からなかった」と言えないまま時間が過ぎます。

ストレッチと過負荷の境界

伸びるのは、今の実力より少しだけ上のタスクです。 簡単すぎれば学びがなく、難しすぎれば手が止まります。

問題は、この境界が外から見えにくいことです。 「大丈夫です」という返事は、どちらの状態でも返ってきます。

観察すべきは、言葉ではなく行動の変化です。

兆候	ストレッチ（伸びている）	過負荷（沈んでいる）
手が止まる時間	30分〜1時間で何かしら動き出す	半日以上、進捗が変わらない
質問の質	「AとBで迷っている。理由はこう」	「動きません」「よく分かりません」
成果物	不完全でも何か出てくる	数日、何も出てこない
説明	自分の言葉で経緯を説明できる	説明が曖昧になる、断片的になる
態度	詰まった箇所を具体的に言える	「もう少しで終わります」が繰り返される

特に注意すべきは 質問の質が落ちた時です。 最初は具体的に聞けていた人が「よく分かりません」と言い始めたら、 理解の土台が崩れていて、何が分からないかも分からなくなっています。

この状態でさらに時間を与えても回復しません。 一度タスクを止め、前の段に戻って土台を確認するのが最短です。

見積もりは当てるためにさせるのではない

新人にも見積もりをさせてください。ただし目的を取り違えないことが重要です。

目的は、当てることではありません。ズレを検知して相談する練習です。

新人の見積もりは外れます。それは前提です。 価値があるのは、次のサイクルが回ることです。

1. 「2日くらいだと思います」と言う
2. 1日目の終わりに「思ったより進んでいない」と気づく
3. 2日目の朝に相談する

3 ができるようになることが、この練習の成果です。 見積もりがなければ、そもそも 2 の「思ったより」が存在しません。 基準がない人は、遅れていること自体に気づけません。

実務上は、次のように運用するとうまくいきます。

• 見積もりは本人に言ってもらう（こちらから「2日ね」と言わない）
• 大きく外れていても、その場では修正しない（外れる体験自体が学習になる）
• ただし 「1.5倍を超えたら必ず相談」 という約束だけは先にしておく
• 終わったら、見積もりと実績のズレを一緒に振り返る。責めるためではなく、次の精度のため

外れた理由を分類する

振り返りでは、ズレの原因を分けると学習が早くなります。

• 作業量を読み違えた（触るファイルが想定より多かった）
• 未知の技術に時間を取られた
• 環境やツールで詰まった
• 手戻りが発生した（設計を相談せずに書き始めた）

上の3つは、経験を積む以外に短期の改善策がありません。 一方で最後の1つだけは、着手前に方針を5分相談するだけで防げるタイプのズレです。 改善を促すなら、そこに絞ってください。

手放す判断と巻き取る判断

締め切りがあるタスクで新人が詰まった時、任せ続けるか、こちらが引き取るか。 この判断は感覚でやると必ず遅れます。基準を先に決めておいてください。

巻き取りを判断する基準

観点	任せきる	巻き取る
残り時間	見積もりの2倍以内で収まりそう	締め切りまでに間に合わない見込みが立った
詰まりの種類	調べれば分かる範囲	チームの暗黙知や設計判断が必要
学習効果	この経験が次に効く	時間だけ溶けて学びが薄い
本人の状態	手が動いている	数日、成果物が出ていない
障害の性質	タスクの本質部分	環境やツールなど本質でない部分

原則として、環境・ツールの詰まりは早めに巻き取り、 設計や実装の詰まりは粘らせるのが良い配分です。 前者は学びが薄く、後者は本人の成長そのものだからです。

巻き取る時の伝え方

巻き取ること自体より、伝え方で結果が変わります。 これを本人の失敗として扱わないことが絶対条件です。

悪い例:

「時間ないんで、こっちでやりますね」

良い例:

「このタスク、締め切りの都合で残りは自分がやります。 詰まっているのはチーム側の事情を知らないと分からない部分で、 渡し方の問題です。 やった内容は後で一緒に見ましょう。そこまで進めてくれた分は使わせてもらいます」

含めるべき要素は3つです。

1. 巻き取る理由が締め切りであること（能力の話にしない）
2. 難しかった原因の所在（渡し方・情報の不足など、こちら側の要因を明示する）
3. 成果を捨てないこと（途中まででも使う、あるいは後で一緒に見る）

3 が抜けると、本人には「数日の作業が無駄になった」という記憶だけが残ります。

逆に、任せきるべき場面

時間がかかっても手を出さない方がいい場面もあります。

• 締め切りに余裕がある。1日多くかかっても誰も困らないなら、待つ価値があります
• 本人が手を動かし続けている。試行錯誤の途中で取り上げると、成長の機会そのものを奪います
• 詰まりの正体が分かっている。あと1歩なら、ヒントだけ出して待ちます
• その領域を今後任せたい。一度自力で通した人は、次から相談相手になります

「自分がやった方が速い」は、ほぼ常に事実です。 それでも任せるのは、3ヶ月後に自分がやらなくて済むようにするためです。 短期の効率で判断すると、いつまでも自分がやり続けることになります。

ケーススタディ: 5日目に何も出てこないインターン

あるインターン生に、新しいエンドポイントを1本追加するタスク（階段の3段目、目安3日）を渡しました。 5日目になっても PR が出てきません。デイリーでは毎日「もう少しで終わります」と言っていました。

確認して分かったことは次のとおりです。

• 2日目にローカルで認証周りの設定に詰まり、そこで丸2日使っていた
• 設定手順は誰も文書化しておらず、チーム内では口伝だった
• 本人は「環境の問題で止まっているとは言い出しにくい」と感じていた
• 実装そのものは、詰まりが解けた後は半日で終わった

失敗の所在は明確です。

• 渡す前に環境が通っているか確認していなかった（1段目・2段目を飛ばしていた）
• 進捗を「終わりそう？」でしか聞いていなかったので、事実が見えなかった
• 環境の詰まりという巻き取るべきタイプの詰まりを5日放置した

このケースでは、3日目の朝に「今、画面に何が出ている？」と一度聞くだけで、 2日分が回収できていました。

この章のまとめ

• 良い最初のタスクは、影響範囲が閉じ、正解が判定でき、参考実装があり、1〜3日で終わり、実際に価値がある
• タスクは階段として並べる。1段目（文言修正）を飛ばさず、開発フローを一周させる
• 支援を減らす順序は 手順 → 調査 → 設計。いきなり設計から任せない
• Good First Issue は来てから探すのではなく、日頃から気づいた時点で文脈ごと貯める
• 「参考になる既存実装」を issue に書いておくと、質問が最も減る
• ドキュメント修正だけで2週間、仕様不明のレガシー、本番障害、「なんでもいいから」は失敗する
• 過負荷の兆候は手が止まる時間・質問の質・成果物の有無で見る。「大丈夫です」は情報ではない
• 見積もりは当てさせるためではなく、ズレを検知して相談する練習としてさせる
• 環境・ツールの詰まりは早めに巻き取り、設計・実装の詰まりは粘らせる
• 巻き取る時は、理由を締め切りに置き、原因の所在をこちら側に置き、成果を捨てない。黙って巻き取らない