はじめに
こんにちは、くりメガネです。株式会社センシンロボティクスでロボット運用支援ツールの開発とスクラムマスターを担当しているソフトウェアエンジニアです。
この記事は、Claude CodeのようなAIコーディング支援を日々使っている、あるいはこれから開発の進め方に組み込んでいきたいエンジニアに向けて書いています。
前回の記事「Claudeに『過去』を与える」の続編です。今回のテーマは 「時間」 で、記事を2本に分けました。この 計画編 では、スプリントから今この瞬間まで、粒度を変えながら計画を立てて転がす部分を扱います。立てた計画を実際に実行へ移す部分——起動時にモデルを選ぶ、承認のない計画では実装させない、夜間に無人で進める——は、続く 実行編 にまとめます。
Claudeは「時間」を知らない
前回、Claudeにプロジェクトの「過去」を与える話を書きました。ですが、過去を与えても、Claudeはもう1つ大事な感覚を持っていません。時間です。
Claude Codeは、目の前のタスクには全力で取り組みます。ですが「このスプリントの締切はいつか」「今日の残り時間であと何が終わるか」「このペースで間に合うのか」を知りません。放っておくと、1つのタスクにコンテキスト（AIの作業メモリ）とトークンを際限なく注ぎ込み、気づけば締切当日に「まだ終わっていない」ということが起きます。
これは人間にも起きることです。だからこそ私たちは、スプリントプランニングをして、1週間の計画を立てます。そして今日やることを決め、時計を見ながら進めます。この記事で紹介するのは、その 時間の感覚をClaudeに与える計画の仕組み です。
何が変わったか：時間を与えると、計画が動き出す
仕組みの前に、時間を与えると計画の立て方・守り方が具体的にどう変わるかを並べます。
-
締切に間に合うかを、時計を見ながら進められる。「退勤の目標時刻まであと何時間、残りタスクはこれだけ」というラインが常に見えて、遅れていれば落とす・繰り越す候補が出ます。時計で強制終了するのではなく、判断の材料が出ます
-
今日やる順番が決まり、気まぐれで崩れない。 朝に確定した順番をその日は守り、途中で思いついた別の改善は列に積むだけにします。割り込みを減らすのが狙いです
-
レビュー待ちを見込んで、前倒しできる。 レビューに出せる時間帯や往復にかかる日数を計画に織り込み、レビューが要るタスクを週の序盤へ寄せます。自分の作業を終えたのにレビュー待ちで詰まる、という事態を防ぎます
-
見積もりが、実績で自動的に補正される。 どのタスクに実際どれだけかかったかが自動でたまり、スプリントごとに見積もりとのズレを測って精度を上げます。手で工数を付ける必要はありません
-
人間の出番が、計画の承認と成果物のレビューに寄っていく。 一手ずつの実装を見張る代わりに、入口で「この計画で進めていいか」を、出口で「できたものが要件を満たすか」を判断します。この分担を仕組みで守る部分は、続く実行編で扱います
全体像：スプリント → 週 → 日 → 瞬間
時間の感覚は、粒度の違う4つの階層に分けて与えます。そして、その全部に共通の「見積もりの土台」を供給します。
- 見積もりの土台：過去の実績から「これはこれくらいかかる」を出す。下の全階層に同じ土台を供給する
- スプリント：チームで合意する。ゴール、着手するチケット、SP（ストーリーポイント。作業量の見積もり単位）、完了の定義（DoD。Doneとみなす条件）
- 週：自分の担当分を、レビューに出せる最小の塊まで分解し、稼働可能な時間に積み上げて容量を確認する
- 日：今日やる順番を確定し、締切リスクを洗い出す
- 瞬間：確定した順に着手し、時計と突き合わせてペースを確認する
大事な考え方が2つあります。1つは、下の階層ほど頻繁に計画し直すこと。先のことは変わるので、直前になるほど細かく調整します。もう1つは、完全な自動運転は最終手段に置くこと。人間の判断を計画の承認と成果物のレビューという要所に効かせながら回します（その効かせ方は実行編で書きます）。
以下、土台から順に見ていきます。それぞれ専用のスキル（Claudeに手順を教えておく設定）にしていて、同じ考え方を粒度だけ変えて適用しています。
見積もりの土台：実績を「自動で」ためる
計画の精度は、見積もりの精度で決まります。ここで使うのは勘ではなく、自分の実績の記録です。大事なのは、記録を手作業に頼らず、セッションの流れに埋め込んで自動でためることです。手で工数を付けるのは続かないので、仕組みにしています。
打刻はセッションに紐づいて自動で入ります。
-
着手したときに、そのタスクの見出しへ開始時刻
[HH:MM〜]が入ります - ひと区切りついたら終了時刻が埋まって
[HH:MM〜HH:MM]に閉じ、やったことが1行で追記されます（要約は軽いモデルが作ります） - 同じタスクに日内で何度も着手すれば、時間帯が並びます
記録先は日付ごとのディレクトリに固定していて、タスクリスト/YYYY/YYMM/MMDD/report.md の形です。中身はこうなります。
# YYYY年MM月DD日 作業記録
<!-- 始業: 10:00 | 退勤: 19:00 -->
## Done
### 対象チケット [10:00〜11:30] [14:00〜14:20]
- やったこと（セッション終了時に自動で要約されて入る）
### チケット外 [13:00〜13:10]
- チケットに紐付かない作業
この打刻を、別のスキルがタスク別の作業時間へ按分集計します。時間帯が重なった作業は分単位で均等に割り振り、チケット別の実働時間の表を同じファイルへ書き戻します。
| チケット | 按分時間(h) |
| --- | --- |
| 対象チケット | 1.8 |
| チケット外 | 0.2 |
こうして「どのタスクに、実際どれだけかかったか」が、意識しなくてもたまっていきます。この実績が、次からの見積もりの土台になります。
この記録は、労務管理ではありません
念のため、この自動記録の目的をはっきりさせておきます。
- 目的は、見積もり精度の向上だけです。「この種の作業は1SPあたり実際どれくらいか」をつかみます。次の計画を現実的にするための材料です
- データはローカル（自分のPC）で管理し、外部に送信しません。 生の作業ログをどこかのサービスへ集約したり、他人と共有したりはしません
- 勤怠監視や労務管理が目的ではありません。 記録される始業・退勤の時刻も、「今日はあと何時間使えるか」という稼働可能時間を出すためだけに使います。むしろ、締切に対して自分が無理をしていないかを、自分で見るための道具です
「実績を自動でためる」という言葉は、監視のように受け取られがちです。ですが、ここでの実績は自分の計画を自分で守るための材料であって、誰かに提出するための記録ではありません。
スプリントの計画と見積もりの補正
この土台の上に、まずスプリント単位でチームの合意を作ります。ここも専用のスキルにしていて、スプリントのゴール・着手するチケット・SP・完了の定義（DoD）のたたき台を、実績ベースの見積もりに載せて1枚に整理します。
そしてスプリントが終わるたびに、見積もりの合計と実績の作業時間を突き合わせ、「1SPあたり実際は何時間だったか」を測って記録します（これも補正用のスキルにしています）。ポイントは、1つのタスク単位ではなく スプリント合計で見ることです。個々のタスクは当たり外れが大きくても、合計で見ると1SPあたりの実時間は安定しやすいからです。
補正した値は、ローカルの小さなデータとしてカテゴリー別に残します。たとえばこんなイメージです。
{ "category": "実装", "sp_to_hours_median": 3.2, "samples": 18 }
この数字がたまるほど、次のスプリントで「このゴールは入りきるか」の判断が正確になります。見積もり → 実績 → 補正 → 次の見積もり、と回すわけです。極端に外れたタスク（想定外の調査が続いたものなど）は代表値から除き、外れ値の影響を抑えています。
週の計画：レビューに出せる塊まで割る
次は週単位です。ここも専用のスキルにしていて、スプリントで合意した自分の担当分を、レビューに出せる最小の塊まで分解します。分解すると数が増えるので、会議を除いた稼働可能な時間に積み上げて、入りきるかを確認します。超えていれば、その時点で締切リスクとして見えるようにします。
ここで効くのが レビュー待ちの織り込みです。完了とみなす条件を「実装が終わった」ではなく「レビューを通ってマージされ、動作を確認できた」に置いているので、レビューにかかる時間も計画に含める必要があります。
そして、レビューをしてもらえる時間帯は相手によって異なります。レビュー可能な時間帯が限られているメンバーもいますし、休暇や会議で割けない日もあります。レビューが夜の枠に寄る相手だと、指摘を受けても修正の反映は翌営業日が最速になり、1往復におよそ1営業日かかります。
そこで、レビューが必要なタスクは「何往復 × 1往復あたり何営業日」ぶんを差し引いて、実装完了の目標を前倒しします。この前提は設定に寄せていて、実績で少しずつ調整します。
reviewers:
# レビュー枠が限られる相手ほど、往復に営業日がかかる
limited_window_reviewer:
days_per_round: 1 # 1往復に約1営業日（枠が限られるため）
rounds_estimate: 2 # 平均の往復回数。実績で調整する
たとえば期限まで3営業日で、2往復のレビューを見込むなら、実質は残り1営業日扱いで前倒しします。自分の作業を週の序盤に終えてレビューに渡し、レビュー待ちの間に別のタスクを進める、という並べ方です。
日と瞬間：順番を決めて、崩さない
ここが計画を「今この瞬間」まで落とす部分です。朝に順番を確定し、日中はその順番を崩さずに、時計と突き合わせながら進めます。担当を2つのスキルに分けています。朝、順番を確定するスキルと、その順番を実行するスキルです。
朝：今日やる順番を確定する
順番を確定するスキルは、次を材料にして「今日やること」を並べます。
-
前営業日までの
report.md（実績。何にどれだけ使ってきたか） - 各プロジェクトの、自分担当の未完 Jira チケット
- 自分の open なプルリクエスト（継続中の作業を見落とさない）
- 当日のカレンダー（会議と退勤の目標時刻から、稼働可能時間を出す）
- 各タスクの締切
- 週の計画の結果と、Slackに流れた「今日のタスク」（あれば補助に使う）
これらを突き合わせて、今日の確定順を タスクリスト/YYYY/YYMM/MMDD/plan.md に書き出します。この plan.md が当日の正本で、以降はこの順番を崩しません。
順番は、簡単なスコアで決める
順番は、締切の近さ・関わる人との距離・作業量を重みづけした簡単なスコアで決めます。
優先度スコア ＝ w1 × 締切の近さ ＋ w2 × 関わる人との距離 ＋ w3 × 作業量
重みと配点は設定に持たせています。締切を最も重く見て、その次に「誰に渡すか」を見ます。
# 優先度 = w1×締切の近さ + w2×関わる人との距離 + w3×作業量
priority:
weights: { w1: 0.50, w2: 0.30, w3: 0.20 }
deadline_buckets: # 締切までの営業日 → 締切の近さ(0〜100)
overdue: 100 # 期限超過
due_today: 90
in_1d: 75
in_2_3d: 55
in_4_5d: 35
in_6d_plus: 20
no_due: 30 # 期限なし
carryover_bonus: 15 # 前日から open のまま繰り越したタスクに加点
tier_must_do_min: 60 # これ以上なら「今日やる」
tier_consider_min: 40 # これ以上なら「できれば」、未満は繰越
3つの項の意味は、それぞれこうです。
-
w1 締切の近さ：期限が近いほど高くします。ここに前の節のレビュー待ちが効きます。レビューが要るタスクは、往復日数ぶん締切を前倒しした状態で近さを計算します。たとえば期限まで3営業日でも、2往復のレビューを見込むなら「残り1営業日」の配点で扱い、朝側へ寄せます
-
w2 関わる人との距離：「成果を確認してもらう相手の遠さ」と「往復の遅さ」です。顧客や外部の調整が要る作業、レビュー枠が限られる相手に渡す作業ほど、距離を大きく見ます。距離が大きいほど早く着手して渡さないと、待ち時間で締切に間に合わなくなるからです。不明なときは保守的に「やや遠い」に置いて前倒しします
-
w3 作業量：大きいタスクほど不確実性が高いので、朝側に寄せます。夕方に大物を始めて中途半端に終わる、という失敗を避けるためです。大きすぎるものは「要分割」として、着手前にさらに割ります
スコアがしきい値を超えたものが「今日やる」、その下が「できれば」、さらに下は「今日はやらない（繰越）」になります。稼働可能時間に積み上げて収まらなければ、その場で ⚠ 締切リスク を付けて、自動で残業前提にはしません。無理なら無理と朝の時点で出すのが狙いです。
日中：順番を崩さない（気まぐれを止める）
順番を実行するスキルの一番の役目は、順番を崩さず、割り込みを減らすことです。
- 一度
plan.mdで確定したら、その日の途中で気分によって別の改善作業に飛びません - 思いついたことは、その場でやらずに列（別メモ）に積むだけにします。翌日以降の計画で拾います
- 順番を変えたくなったら、その場で変えず、理由をメモして翌朝の計画に戻します
これは「気まぐれ」を止めるための仕組みです。思いつきの割り込みは、体感で一番大きな遅延要因でした。良いアイデアを捨てるのではなく、判断のタイミングを朝に集約するという考え方です。
並列でセッションを開くこともあるので、着手したタスクは共有ファイルに記録して、別のセッションと同じタスクを二重で進めないようにしています。
瞬間：ペースを確認する（時計で強制終了はしない）
作業中は、カレンダーの残り時間と、残りタスクの見積もりを定期的に突き合わせます。
- 「退勤の目標時刻まであと何時間」に対して、「残りタスクの見積もり合計」を比べます
- 遅れていれば、「この時間までにここまで終わっていないと間に合わない」というラインを出し、落とす・繰り越す候補を提示します
- ただし、時計で強制終了はしません。 あくまで判断の材料を出す役です。締切に間に合わせるうえで何を諦めるかは、人間が決めます
もう1つの番人：未レビューの本数
ペースと並ぶもう1つの番人が、未レビューのプルリクエスト（PR。変更をレビューに出す単位）の本数です。上限を決めていて、自分のopenなPRがそこに達したら、新しく着手するのを止めて、レビュー待ちの解消を優先するよう促します。
execution:
wip_review_cap: 3 # 未レビューの自分の PR がこの本数に達したら新規着手を止める
作るスピードだけを上げても、レビューが詰まれば全体は進みません。むしろ手戻りのコンテキストが増えて、あとで自分が苦しくなります。上限を3本にしているのは、「作る」と「通す」のバランスを崩さないためです。
実行編へ、そして前回の「過去」とつながる
ここまでは、計画を 立てて、転がす話でした。スプリントで合意し、週でレビューに出せる塊まで割り、朝に順番を確定し、瞬間ではペースを見る。共通の見積もりの土台に載せ、下の階層ほど頻繁に計画し直す。これが計画編の骨格です。
立てた計画を 実行に移す部分は、続く実行編にまとめます。起動時に難易度とトークン残量でモデルを選ぶこと、承認済みの計画が無いまま実装を始めさせないこと、人手なしで安全に進められる作業を夜間に無人で一区切りずつ進めること。「人間の出番を計画の承認と成果物のレビューに集約する」を、仕組みとして守る話です。
そして、この計画の仕組みは、前回の「過去」を与える仕組みと組み合わさると力を増します。過去のインシデントやレビュー指摘、チームのコーディング作法がAIから参照できるからこそ、任せた実装が チームの作法を守り、意図や背景を汲んだものになります。時間の仕組みが「いつ・どれだけやるか」を決め、過去の仕組みが「どう作るのが正しいか」を支える。 この2つがそろって、人間が計画の承認と成果物のレビューに集中する分担が現実になります。
スプリントから週、日、そして今この瞬間へ。粒度を変えながら、同じ見積もりの土台の上で計画を転がす。働き方の数字は、それを守った結果としてついてきます。 次回、実行編でお会いしましょう。