# 仕様は書けた。今週、何を完成させますか？

Canonical: https://specscore.md/ja/articles/weekly-delivery/

仕様書が完成していても、プロジェクトが進むとは限りません。要件は明確で、エージェントには計画があり、未完了のタスクだけが増えていく。足りないのは、もっと小さな判断かもしれません。今週どんな役立つ成果を完成させ、そのために何をやめるのか。このレビューは、同僚やメンターと一緒に、またはノートだけでも実践できます。

## タスクの山ではなく、利用者の成果を選ぶ

受け入れ基準を一つ選び、短い実演に変えましょう。CSVインポートなら「パーサーを実装する」は作業の説明です。「利用者が正しいファイルを読み込み、レコードを確認でき、不正な行には役立つエラーが出る」なら検証できます。エラー処理も約束に含めてください。期限に合わせて省くと、約束の内容が変わります。

SpecScoreは、チームとエージェントが読めるファイルに要件と受け入れ基準を整理します。週次のメモからその基準を参照しましょう。正しい動作の定義は仕様書に残し、メモでは実現可能な部分を選びます。仕様書の複製や、新しいプロジェクト管理システムは必要ありません。

## 実際の予定に合わせて時間を見積もる

レビューと統合作業も含め、集中して使える時間帯を書き出してください。二晩は五営業日ではありません。利用者の一連の操作を試す時間と、予期しない問題を一つ解く時間を確保します。収まらないなら、着手前に小さくても一通り使える流れを選び直しましょう。

自分では制御できない依存関係も挙げます。「本番環境のアクセス待ち」には担当者と判断時刻が必要です。水曜日になってもアクセスできなければ、ローカルでの実演に意味があるかを判断します。その結果は正確に呼びましょう。ローカルのデモは本番で使える証拠にはなりません。金曜日に成功の定義をこっそり変えないことです。

## エージェントの作業を区切り、判断は引き受ける

どの問題が重要かをあなたが考えている間にも、エージェントは複数の実装を生成できます。そのため、完了した小タスクが増えても元の目的が進まないことがあります。各タスクに具体的な基準、許される範囲、提出する証拠を指定してください。利用者の流れ全体を受け入れる責任は、一人の人間が持ちます。

新しいアイデアが出たら、自動的に着手せず記録します。それは今のどの約束と入れ替わるのでしょうか。自分の最終レビューを待つ成果を一つだけにする方法も試せます。これは集中のための実験で、普遍的な生産性ルールではありません。役立つ作業を遅らせるなら調整してください。

## 説明を聞く前に証拠を見る

レビューでは、まず実物を開きます。動くインポート、不正な入力のテスト、公開済みの文書などです。利用者と同じ順序で操作し、選んだ基準と結果を比べてください。コミット数、作業時間、自信に満ちたエージェントの報告は背景情報であり、受け入れの証拠ではありません。

実装済み、テスト済み、目的の環境で利用可能という状態を区別します。レビューする人には、失敗する方法を一つ探してもらいましょう。共有する情報は必要な範囲だけにします。架空のサンプルや機密情報を除いた実演で十分なことも多く、約束を振り返るために顧客データ、秘密情報、非公開リポジトリを見せる必要はありません。

## 守れなかった約束には、新しい判断が必要

実演が失敗したら、役立つ最小限の説明を残します。未知の依存関係、広すぎる範囲、作業時間の中断、誤った前提などです。見積もりの失敗を人格の評価にしないでください。次の範囲を小さくする、依存関係を解く、方法を変える、意図してプロジェクトを止めるなど、具体的に対応します。

習慣で同じ約束をそのまま翌週に送らないでください。次に観察できる成果とレビュー日を決めます。数回繰り返したら、見積もりと実際に完成したものを比較しましょう。記録の価値は判断を改善することにあり、連続達成を守ることではありません。

## そのまま使える五行の週次レビュー

- 成果：レビュー日までに利用者は何ができるか。
- 証拠：どの基準と実演で確かめるか。
- 時間：いつ実装し、テストし、レビューするか。
- 制約：何を延期し、どの依存関係について判断するか。
- レビュー：誰がいつ結果を見て、その後何を決めるか。

## 自分の判断に、人の視点を加える

何が起きたかを尋ね、次の選択を一緒に検討してくれる人と、このメモを使ってみてください。CommittedMeは人によるメンタリングと約束の振り返りを中心にしています。開発者・創業者向けのページで、その考え方を紹介しています。仕様書はリポジトリに置いたまま、機密の仕事を明かさずに話せる目標を持ち寄りましょう。

[CommittedMeについて読む（英語）](https://committedme.com/en/for/builders/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_footer)

YouTube、TikTok、Instagram、ブログなどで、すでに開発者に教えていますか。判断の理由やテストを誰かに説明すると、自分の前提に気づくことがあります。相手が前進する一方、その質問が自分の学びを続けるきっかけにもなります。そんな対話に関心があれば、メンターの役割についてお読みください。

[メンターの役割を読む（英語）](https://committedme.com/en/become-a-mentor/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_mentor)

CommittedMeは私たちのエコシステムの別の製品です。この記事はレビューの実践方法を説明するもので、SpecScoreとの技術的な連携を示すものではありません。

## 成果を検証できる形にする

[検証可能な受け入れ基準の書き方](https://specscore.md/ja/articles/acceptance-criteria/)