Claude Code + GitHub で「人間とAIが協働する組織」を設計した全記録 — EngOpsの実践

この記事は「AI × EngOps 実践記」シリーズの第5回です。
第1回: EngOps、はじめました / 第2回: AIが速くしたのは"実行"だけだった / 第3回: 意思決定を『AIと人間両方のために残す』仕組みを作る / 第4回: 社内の情報を構造化したところ、うまい具合に人とAIの接点になった話

はじめに

40人規模のスタートアップでEngineering Operations（EngOps）を担当しています。

EngOpsとは何か。 Engineering Manager（EM）がピープルマネジメントと技術判断を担うのに対し、EngOpsは「エンジニアリング組織が回る仕組み」の設計・運用を担います。DevOpsがCI/CDやインフラの自動化に焦点を当てるのに対し、EngOpsはもう少し広く、案件管理・リソース配分・プロセス標準化・ツール整備といった「開発業務そのものの運営基盤」を扱います。評価や1on1ではなく、プロセスと仕組みが主戦場です。（詳しくは第1回で書きました。）

前回の記事で、「社内の案件情報を構造化したらAIとの接点になった」という話を書きました。今回はその続き — 構造化した情報の上に、Claude CodeとGitHubを使って「人間とAIが協働する業務基盤」を丸ごと設計・実装した話です。

やったことを一言で言うと:

「AIを業務に使う」ではなく「AIと人間が協働する前提で業務を設計する」がテーマです。

この記事で書くこと・書かないこと

書くこと:

• なぜMarkdown + GitHubなのか（思想）

• エンジニアリングチーム向けのポートフォリオ管理基盤の設計

• コーポレートチーム向けのオペレーション管理基盤の設計（エンジニアとは違う構造にした理由）

• CLAUDE.mdとスキルシステムで「AIの振る舞いをコードとして定義する」実践

• 定量的な成果

書かないこと:

• Claude Codeの基本的な使い方（公式ドキュメントを参照してください）

• プロンプトエンジニアリングのTips

背景: なぜ「AIと協働する組織設計」が必要だったのか

会社全体の方針

当社には「社員数をなるべく増やさずに事業拡大していく」「人とAIの調和を図っていく」という経営方針があります。つまり、どのチームも気軽に人を増やさない。しかし事業は伸びており、業務はどんどん増えていく。人を増やさずに業務を回すには、AIと人間が協働する基盤が不可欠です。

当社にはエンジニアリング、コーポレート、営業、研究など複数のチームがあります。今回はそのうち、私が直接関わるエンジニアリングチームと、タイミングよく業務可視化の機会が生まれたコーポレートチームの2つに取り組みました。

エンジニアリングチームの課題:

• 30以上の案件が並走。顧客案件、自社開発、基礎技術、補助金申請が混在

• CTOに案件統括が集中し、ボトルネック化

• 「いま何がどうなっているか」が横断的に見えない

コーポレートチームの課題:

• 週次・月次の定期業務が44件以上

• 少人数で回しているため属人化が進んでいる

• Head of Corporateが育休に入るタイミングで、ナイスタイミングで業務棚卸しをしてくれた。これを活かさない手はない

どちらも「情報が散在していて、全体像が見えない」という本質は同じ。しかし、仕事の構造が違う。

• エンジニアリング: プロジェクト制（始まりと終わりがある）

• コーポレート: 定期オペレーション制（毎週・毎月回り続ける）＋ 一部プロジェクト

同じツール、同じ構造で管理しようとすると破綻します。ここが設計の面白いところでした。

設計思想: 3つの原則

原則1: AIが読み書きできる構造で情報を管理する

Notionでもスプレッドシートでもなく、Markdown + GitHubを選びました。理由を端的に書くと以下3点です：

• LLM（Claude Code）がそのまま読み書きできる

• Git履歴で変更の経緯が追える

• 特定のSaaSに依存しすぎない（LLMポータビリティ）

Notionを検討しなかったわけではありません。しかし、Notionは漫然と更新できてしまうのが良くもあり悪くもあるポイント。チームの状態管理を行うにあたっては、Githubのようにリポジトリの方が分があると考えました。また、Notionのデータベースに情報を入れると、そのデータはNotion内に閉じてしまいます。LLMから読み出したり書き込んだりできなくはないですが、変換コストが高いように思えました。スプレッドシートも同様で、LLMが直接読み書きするには変換コストが高くなります。

Markdown + GitHubなら、どのLLMでもファイルを開いて読み書きできる。情報の構造が、そのままAIの作業指示書になる設計です。
取り扱う情報はテキストファイルが中心になってしまうのがちょっとした欠点ではありますが、そこは今後の技術進歩に期待したいところです。

原則2: 「仕事の構造」に合わせて基盤を分ける

エンジニアリングとコーポレートで、管理の構造を変えました:

コーポレートの定期業務を無理にプロジェクト化すると「毎週同じシートを更新するだけ」の作業になって形骸化します。**「正常のときは何も書かなくていい」**という設計が、運用コストを最小化する鍵でした。

原則3: AIの振る舞いを「コード」として定義する

Claude Codeには、CLAUDE.md（プロジェクトレベルの指示書）とスキル（スラッシュコマンド）という仕組みがあります。これを活用して:

• CLAUDE.md: 「このリポジトリの構造」「更新ルール」「やってはいけないこと」を定義

• スキル: 「/weekly-review」「/deadline-alert」等、繰り返す業務を手順化

AIに「よしなにやって」と頼むのではなく、業務手順をコードとして定義し、AIがその手順に従って動く設計です。人間がルールを決め、AIがルールに従って実行する。この明確な分担が「人間とAIの協働」の本質だと考えています。

実践1: エンジニアリングチームのポートフォリオ管理

リポジトリ構造

project-portfolio/
├── CLAUDE.md              ← AIへの指示書
├── README.md              ← 案件一覧（台帳本体）
├── projects/
│   ├── 1.md 〜 16.md      ← 各案件の個別シート
│   └── project_template.md
├── resources/
│   ├── human-capacity.md  ← 誰が何を担当しているか
│   ├── forecast.md        ← リソース需給予測
│   └── ai-usage.md        ← AI活用方針
└── .claude/skills/
    ├── update-project.md   ← /update-project
    ├── weekly-review.md    ← /weekly-review
    ├── deadline-alert.md   ← /deadline-alert
    └── ...（計9スキル）

CLAUDE.mdに書いていること

AIが守るべきルールの例:

## 更新ルール

### 整合性の維持（最重要）

案件シートを更新したら、必ず以下も同期する:
1. README.mdの案件一覧テーブル
2. エグゼクティブサマリ / 重点案件
3. 見直しメモ
4. 連動案件のシート（例: 顧客Aの案件 ↔ 標準プロダクトの機能No.2）

### やってはいけないこと
- 担当者の確認なしに評価スコアを変更しない
- 担当者の確認なしに優先度を変更しない
- 情報が曖昧な場合に推測で埋めない — 質問する

これにより、AIが案件シートを更新すると、自動的に関連する全ファイルを同期する動きになります。「この案件を更新したけどREADMEの反映を忘れた」がなくなる。

スキルの設計: 9つのスラッシュコマンド

スキルは「手順書」です。 例えば `/weekly-review` には「まず営業日カレンダーを読んで今週のイベントを確認する → 全案件の状態を確認 → 重点案件を選定基準に照らして見直す → READMEを更新」という手順が書いてある。AIはその手順に従って動く。

定量的な成果

• 30件以上の案件を1人（＋AI）で横断管理できる状態を構築

• 担当者フィードバックの反映（案件シート更新＋README同期＋連動案件更新）が1回の対話で完結

• 社内レビューで指摘を受けた4案件の修正を、連動する6ファイルを漏れなく同期しながら実施

• コーポレートチームの44業務の構造化（7分野×5頻度への分類、台帳化、属人化リスク整理）を約2時間で完了（業務棚卸しExcelの受領から台帳完成まで。棚卸しExcel自体はHead of Corporateが事前に作成）

実践2: コーポレートチームのオペレーション管理

エンジニアリングとは構造が違う

コーポレートチームのHead of Corporateが育休に入るタイミングで、業務棚卸しのExcelを受け取りました。中身を見て「これはプロジェクト管理じゃない」と気づきました。

経理の月次決算、法務の契約レビュー、知財の定例MTG — これらは終わりがない。毎月回り続ける。これをプロジェクトシートで管理すると形骸化する。

2層構造の設計

corporate-portfolio/
├── CLAUDE.md
├── README.md              ← 全体サマリ
├── operations/
│   ├── weekly.md          ← 週次の定期タスク
│   ├── monthly.md         ← 月次の定期タスク + 都度発生業務
│   ├── quarterly.md       ← 四半期・年次タスク
│   └── calendar_2026.md   ← 営業日カレンダー（365日分）
├── projects/              ← 改善・チャレンジ案件（エンジ版に近い）
└── .claude/skills/
    ├── ops-check.md       ← /ops-check
    └── ...（計6スキル）

第1層: オペレーション — 定期タスクの「健康状態」を追う。正常/遅延/要注意/改善中の4状態。正常のときは備考を書かなくてよい。

第2層: 改善プロジェクト — 期限と完了条件がある案件だけ、エンジニアリング版と同様に管理。

営業日カレンダー

Head of Corporateとのヒアリングで、月次タスクの期限が「毎月10日の3営業日前」「税理士定例の2営業日前」のように営業日ベースで決まることが分かりました。

私もHead of Corporateも大手製造業出身で、大企業では「年間カレンダー」が全社員に配布されていました。それに倣い、2026年の365日分の営業日カレンダーをMarkdownで生成し、祝日・会社休日を反映したうえで、各月次タスクのイベントを実際の日付にマッピングしました。

これにより `/deadline-alert` が「今週の経理イベント: 3/25に経費精算支払集計期限（10日の3営業日前）」のように具体的な日付でアラートを出せるようになりました。大企業では当たり前にあったものが、スタートアップにはなかった。AIに仕事をさせるためにも、こういう基礎的な情報の整備が意外と効きます。

業務棚卸しExcelからの構造化

Head of Corporateから受け取ったExcelの業務一覧（約50行）を、7分野（経理・財務IR・法務・知財・総務・人事労務・情シス）×5頻度（週次・月次定期・月次都度・四半期・年次）に分類し、44件のオペレーション + 改善案件として台帳化しました。

同時に、育休中の引継ぎ状況（誰に引き継いだか/休止中か/本人続投か）と属人化リスクも構造化。これが後の「各メンバーの業務自動化に向けて」の道筋になっています。

CLAUDE.mdの設計パターン

2つのリポジトリでCLAUDE.mdを書いて気づいたパターンを共有します。

パターン1: 構造の説明を最初に書く

AIに「このリポジトリで何をしているか」を最初に伝える。人間のREADMEと似ているが、AIが業務判断に使う情報を優先する。

## リポジトリ構造
README.md              … 案件一覧（台帳本体）
projects/{ID}.md       … 各案件の個別シート
resources/             … リソース管理

パターン2: 「やってはいけないこと」を明示する

AIは指示がなければ「よかれと思って」勝手にやる。特に以下を明示することが重要:

### やってはいけないこと
- 担当者の確認なしに評価スコアを変更しない
- 情報が曖昧な場合に推測で埋めない — 質問する

パターン3: 連動ルールを書く

「Aを変えたらBも変える」というルールがないと、情報の不整合が蓄積する:

### 連動案件の主な組み合わせ
- 3.md（顧客Aの案件） ↔ 9.2.md（標準プロダクトの機能No.2）
- 9.md（標準プロダクト） → 9.1.md 〜 9.8.md（標準プロダクトの各コンポーネント）

結果: 何が変わったか

変わったこと

1. 「あの案件どうなってる？」に即答できる。 AIがリポジトリを読んで最新状況を返す。

2. 更新の漏れがなくなった。 CLAUDE.mdの連動ルールに従ってAIが全ファイルを同期する。

3. コーポレートチームの業務が初めて一覧化された。 育休前の業務棚卸しExcelを構造化し、7分野44件のオペレーションとして台帳化。属人化リスクや引継ぎ状況も可視化した。これから実際に運用を回していく段階。

4. 新規案件の立ち上げが高速化。 `/new-project` で情報を伝えるだけで、テンプレートから案件シート作成 → README追加 → リソース台帳反映まで完了。

5. 「次に何をすべきか」が分かる。 `/deadline-alert` で今週やるべきことが出てくる。

まだ変わっていないこと（今後の課題）

• 情報のインプットはまだ人間依存。 現状は「この案件のステータスが変わった」という事実は人間が伝える必要がある。ただし、これは改善の道筋が見えている。議事録をMarkdown整形して各リポジトリに自動分配し、それをポートフォリオ側から収集してサマリーを生成、PRとして提出 → 案件担当者が承認、というフローの構築を進めている。

• 意思決定は人間がやる。 AIは「この案件の期限が迫っています」と言えるが、「だから何を優先するか」は人間が決める。ここはAIに委ねるべきではない領域。

• 現場を知るのは人間。 コーポレートの業務棚卸しは、Head of Corporateへのヒアリングなしにはできなかった。構造化はAIが得意だが、情報の源泉は現場にある。

これからやること

1. 「1看板1リポジトリ」への展開。 各案件に対応するGitHubリポジトリを作り、案件シートを「各リポジトリのサマリー圧縮係」として機能させる。担当者がPRでサマリーを更新し、EngOpsはレビューするだけの運用に移行する。

2. 非エンジニアへのLLM活用展開。 コーポレートチームのメンバーがClaude Codeのスキルで自分の業務を自動化できる状態を目指す。パイロットとしてHead of Corporateから着手予定。

3. ミーティングログの自動分配。 ミーティングの議事録をMarkdown整形し、関連するリポジトリに自動分配する仕組み。

まとめ

「AIを業務に使う」と「AIと人間が協働する前提で業務を設計する」は、似ているようで全然違います。

前者は既存の業務にAIを後付けする。ChatGPTに文章を書いてもらう、Copilotにコードを補完してもらう。これはこれで便利ですが、業務の構造自体は変わらない。

後者は、業務の構造をAIが参加できる形に再設計する。 情報をAIが読み書きできる形式で管理し、更新ルールをコードとして定義し、繰り返し業務をスラッシュコマンドにする。すると、AIは「便利なツール」ではなく「チームメンバー」になる。

EngOpsの仕事は「エンジニアリング組織が回る仕組みを作ること」ですが、2026年のEngOpsは「人間とAIが協働する組織の仕組みを作ること」だと実感しています。

実装の詳細（付録）

付録A: CLAUDE.mdのサンプル

# CLAUDE.md — [プロジェクト名]

## このリポジトリについて
[チーム名]の案件ポートフォリオ管理台帳。

## リポジトリ構造
（省略 — 記事本文と同等の内容）

## 更新ルール
### 整合性の維持（最重要）
案件シートを更新したら、必ず以下も同期する:
1. README.mdの案件一覧テーブル
2. エグゼクティブサマリ / 重点案件
3. 見直しメモ
4. 連動案件のシート

### やってはいけないこと
- 担当者の確認なしに評価スコア・優先度・オーナーを変更しない
- 情報が曖昧な場合に推測で埋めない — 質問する

## コミット規約
- メッセージは日本語で書く
- 対象案件IDを明記する

付録B: スキルファイルのサンプル（/weekly-review）

---
name: weekly-review
description: 週次ポートフォリオレビューを実施する
user_invocable: true
---

# 週次ポートフォリオレビュー

## 手順
1. **データ読み込み**:
   - operations/calendar_2026.md を読み、今週の営業日・イベントを把握
   - operations/weekly.md、monthly.md を読む
2. **オペレーションチェック**:
   - カレンダーのイベントを参照し、今週期日があるタスクをハイライト
   - ユーザーに各オペレーションの状態を確認
3. **改善案件の進捗確認**:
   - README.mdの改善案件テーブルを読む
   - 期限が近い案件をハイライト
4. **README.mdの全体更新**
5. **サマリ報告**

## 注意事項
- 状態やステータスの変更は必ずユーザーに確認してから反映する

付録C: 2層構造の設計判断（コーポレート版）

エンジニアリング版をそのまま持ち込まなかった理由と、2層構造に至った設計判断の詳細。

最終的に「定期オペレーション（operations/）＋ 改善プロジェクト（projects/）」の2層構造に。定期業務は「正常のときは何も書かない」設計にすることで、更新コストを最小化した。

今後は「1案件1リポジトリ」とポートフォリオ管理の連携の実践と、非エンジニアへのLLM展開について書く予定です。