チームの約束を書いて残す

ここまで、意図・仕様・計画の書類の連鎖、作る段の3層、確かめる段の2つの仕組み、出す段と保つ段の権限設計を見てきました。最後のレッスンでは、これらを「チームの約束」としてどう書き残すかを扱います。書き残さなければ、次に人が増えたときや、担当が変わったときに、また同じ議論をやり直すことになります。

約束を2種類に分ける

チームの約束は、性質によって置き場所が変わります。ここまでのレッスンで見た「助言」と「強制」の区別が、そのまま効いてきます。

この2つを混同すると、たいてい同じ失敗が起きます。「絶対に破られたくない約束」をCLAUDE.mdだけに書いて安心してしまい、忙しいときに誰か(あるいはClaude自身)がうっかり踏み越えてしまうパターンです。逆に、「守ってほしいだけの約束」までフックで縛ってしまうと、細かい例外のたびにフックを止める作業が発生し、かえって運用が重くなります。

レビューの基準は、前者の代表例です。何を重大な指摘とし、何を軽微な指摘として流すかを1つの文書にまとめておくと、Claudeがレビューするときも人間がレビューするときも、同じ物差しで判断できます。GitHub Actionsのレビューワークフローも、リポジトリのCLAUDE.mdに書いたコードスタイルやレビュー基準に従ってプルリクエストを作る、と公式ドキュメントが説明しているとおり、この書類がそのままレビューの一貫性を支えます。

一人で作っていたものを、人に使わせるとき

ここまでのレッスンは、チームのリーダーだけでなく、一人で道具を作っている人にも当てはまる形で書いてきました。ただし、一人で使っていたものを他の人にも使わせる段階に進むときは、見直すべき点が増えます。

この境目をどう扱うかは、「自分だけ使う」と「人に使わせる」の責任でも扱っています。あわせて読むと、技術的な約束の書き方だけでなく、責任の広がり方まで見通せます。

見直しのタイミングを、先に決めておく

チームの約束は、書いたら終わりではありません。運用しているうちに、CLAUDE.mdが古い前提のまま残ったり、フックが今のルールと合わなくなったりします。見直しのタイミングを先に決めておくと、放置を防げます。

見直しを先送りにしがちな理由は、たいてい「いまはうまく回っているから」です。しかし、うまく回っているのは、いまのメンバーといまのやり方が、たまたま噛み合っているからにすぎません。人が入れ替わる、扱う情報が変わる、Claude Codeの機能が更新される。そのどれか1つが起きるだけで、約束は静かに古びていきます。

やってみよう

演習1：約束の棚卸し表を作る

いまチームや自分が守っている約束を5つ挙げ、それぞれ「守ってほしいだけ」か「絶対に破られたくない」かを分類してください。後者なのにフックになっていないものがあれば、次に着手する候補です。

演習2：このコースを1枚にまとめる

このコースの6レッスン(ボトルネックの診断、意図・仕様・計画、作る段、確かめる段、出す段と保つ段、チームの約束)を、自分のチームまたは自分の開発の流れに当てはめて、1枚の簡単な流れ図にしてみましょう。

今日のまとめ

3行で振り返ります。

• チームの約束は「守ってほしいだけ」の約束と「絶対に破られたくない」約束に分け、前者はCLAUDE.mdやスキル、後者はフックに置く
• 一人で使っていたものを人に使わせる段階では、約束と判断の記録を、自分以外にも読める形にする必要がある
• 見直しのタイミングを先に決めておかないと、約束は書いた時点のまま古びていく

このコースで見てきた意図・仕様・計画の連鎖、作る・確かめる・出す・保つの各段は、どれもチームの人数や規模に関係なく使える考え方です。まずは自分の手元にある1つの作業で、意図の書類を1枚書くところから試してみてください。