EM/EngOpsとして30案件を回すskills群を作ったら、PM向け管理基盤になった話

前回、10人の開発組織で30案件以上を回す中で、MondayもNotionもしっくりこなかった話を書きました。2026年初春、EngOpsとして組織全体を把握できてきたタイミングと、Claude Codeが実用段階に入ったタイミングが重なり、ようやく「ツールを自分たちに合わせに行く」選択肢が見えてきた、というところで終わっていました。

今回は、その続きです。GitHubリポジトリ「project-portfolio」と、10個のClaude Code skillsを使ったエンジニアリングマネジメント運用基盤を、約1週間で一気に作った話を書きます。

なお、この記事は、過去に書いた以下の記事のうち、「project-portfolio」にフォーカスして深掘りしたものです。
全体像を掴みたい方はこちらも参照ください。

出発点：組織からの要請

作り始めた直接のきっかけは、明確な指示ではなく、組織から受けていた2つの抽象的な要請でした。

• 開発状況と予測を掌握せよ

• 人数をなるべく増やさずにAIと調和した組織づくりをせよ

Notion運用では1つ目の要請に応えきれていませんでした。30案件以上のカンバンを眺めても、期限の迫っている案件、進捗が止まっている案件、依存関係で詰まりそうな案件を横断的に把握することはできない。各カードを一つずつ開くしかなく、現実的には誰もやらない。

2つ目の要請は、単なる業務効率化ではありません。人間だけで回す前提を崩し、AIを運用の一部として組み込むことを意味します。そのためには、AIが参照できる形で情報が構造化されている必要がある。

この2つを同時に満たす形として編み出したのが、GitHub上のSSOTと、Claude Code skillsの組み合わせでした。

リポジトリの構成

まず、project-portfolioリポジトリの中身はざっくりこうなっています。

project-portfolio/
├── CLAUDE.md              ← AIへの指示書
├── README.md              ← 案件一覧（台帳本体）
├── projects/
│   ├── 1.md 〜 XX.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
    └── ...（計10スキル）

案件IDの中には階層化されているものがあります。9.md、9.1.md、9.2.mdみたいな形で。階層化しているのは、親子関係のある案件を扱うためです。例えば「顧客A向けの全体プロジェクト」が9番で、その中のサブ案件が9.1、9.2と分岐する。この粒度で管理できると、大きな案件の中の個別タスクも、独立した小案件も、同じ構造で扱えます。

resources/が独立しているのは意図的です。案件と人的リソースは別の軸で管理する方が、横断的な調整がしやすい。人的リソースとAIリソースを同じディレクトリに置いているのも、両方が「使えるリソース」として同質だと考えているからです。

10個のskillsを4つのカテゴリに分けた

skillsは以下の4カテゴリ、合計10個です。

• 案件管理（3つ）

  • /update-project ：担当者のコメントをもとに案件シートとREADMEを更新

  • /new-project ：新規案件シートを作成

  • /weekly-review ：週次レビュー

• 監査・検出（3つ）

  • /deadline-alert ：期限が迫っている案件を洗い出す

  • /dependency-check ：連動案件間の矛盾を検出

  • /project-health ：全案件シートの未記入項目や鮮度を監査

• リソース（2つ）

  • /resource-review ：稼働とアサインの整合性をチェック

  • /resource-forecast ：マイルストーンから需給を予測

• レポート（2つ）

  • /weekly-report ：全社定例向けの週次報告を生成

  • /stakeholder-summary ：宛先別のサマリを生成

このうち、最初に作ったのは「案件管理」の3つでした。

Phase 1：個別案件のCRUDから始めた

最初に/update-projectと/new-projectを作ったのは、自然な流れでした。まず案件が存在する、それを更新する、というのが運用の基本動作だからです。Claude Codeと対話しながら、約半日で基本形ができました。

/weekly-reviewはその直後に追加しました。これは案件管理の中でも一番使うskillで、週1回、全案件を横断的にチェックして、担当者と対話しながら情報を更新し、READMEの「今週の重点案件」を更新していくものです。
このskillで1つ意識的な判断をしています。AIに案件シートをいきなり書き換えさせないようにしたことです。手順の中に「ユーザーへの確認」というステップを明示的に入れ、ステータスの変更や新情報の反映は必ず担当者に確認してから行うようにしています。

理由は3つあります。まず、案件シートを軽く保ちたいこと。AIが自動で情報を埋めると、すぐにシートが肥大化してノイズが増えます。次に、週次報告の観点と案件管理の観点では、情報の粒度や切り口が違うこと。画一的に埋めると、どちらの用途にも中途半端な情報になる。最後に、HITL（Human-in-the-Loop）の観点です。判断に関わる情報の更新は、人間が責任を持つ方が安全です。

対話しながら更新する設計は、完全自動化より面倒です。でも、この3つの理由を考えると、面倒でもそれが最適だと判断しました。

Phase 2：その日のうちに監査・検出を追加した

案件管理skillsができた時点で、別の問題が見えました。個別のCRUDだけでは全体の健康状態が見えないのです。
Notion時代と同じ問題が戻ってきた、と言ってもいいかもしれません。各案件を個別に更新できるようになっても、「今、一番ヤバい案件はどれか」「案件間で矛盾が生じていないか」「鮮度が落ちている案件はどれか」を俯瞰する手段がない。

そこで、その日のうちに監査・検出の3つを追加しました。

• /deadline-alert ：期限が迫る案件の警告

• /dependency-check ：連動案件間の矛盾検出

• /project-health ：全案件シートの鮮度や未記入項目チェック

個別操作のskillは案件担当者の視点、監査・検出のskillはEngOpsの視点、と言い換えることもできます。個別の入力ゆらぎは許容しつつ、横断監査で整合性を取り戻す設計です。

Phase 3：他者の視点で見えたニーズ

案件管理と監査・検出の6つができた時点で、幹部陣に見せました。返ってきた反応は、自分では気づけなかったものでした。

「リソース管理のスキルはないの？」

確かに、組織から受けていた要請の中に「人数をなるべく増やさずに」という条件が含まれていました。その前提で案件を回すなら、人的リソースの稼働状況を掌握し、必要なら採用・外注のタイミングを判断できる必要があります。でも最初の6つのskillsには、その視点が入っていなかった。入れていなかったというのが正しい表現です。
そもそも案件管理の仕組みで大外しをしていたら、リソース管理の仕組みを先に作っても手戻りになるだろうと思っていましたので。外からのフィードバックで、自分のやってきた方向性が外れていなかったことがわかりました。

ということで、すぐに/resource-reviewと/resource-forecastを追加しました。稼働の偏りを検知し、マイルストーンから今後の需給を予測する。resources/ディレクトリを新設したのもこのタイミングです。

Phase 4：レポート生成と、作ったが使われないskill

最後に追加したのがレポート生成の2つです。

/weekly-reportは、週次の全社定例向けに今週の結果3点と次アクション3点を生成するskillです。これはすぐに定着しました。週次定例のたびに使うので、運用が自然と習慣化します。

一方、/stakeholder-summaryは、経営層・営業・メンバー・顧客といった宛先別にサマリを出し分けるskillとして作りましたが、一度も使われていません。

理由は明快で、現時点でレポートの宛先が社内だけだからです。経営層も一般社員も、同じ/weekly-reportの出力で事足りる。宛先別のパーソナライズは、宛先が分かれて初めて必要になる機能でした。

実は、もう1つ使われていないskillがあります。/deadline-alertです。Phase 2で作った監査skillの1つですが、個人のタスク管理用には類似のskillを使っているものの、project-portfolio上では使っていません。理由は単純で、GitHubのブラウザ画面で各案件シートの最終更新日を見れば、期限の近い案件は直感的にわかるからです。わざわざskillを呼び出してアラートを出す意味がなかった。

2つの「使われないskill」には共通パターンがあります。別の手段で代替可能だったということです。/stakeholder-summaryは/weekly-reportで代替可能、/deadline-alertはブラウザの画面で代替可能。

この経験から得た教訓は、便利そうだから作るのではなく、必要性が具体化してから作ることです。想像で作ったskillは使われない。観察して、実際に困ってから作ったskillは使われる。

skillは作るだけでは使われない

もう1つ、運用の工夫があります。週次・月次のルーティンフローをskillsのREADMEに明記したことです。

週次は4ステップ： /dependency-check → /weekly-review → コミット＆プッシュ → /weekly-report。
月次も4ステップ：/project-health → /resource-review → /resource-forecast →コミット＆プッシュ

このルーティンがないと、作ったskillも存在を忘れられます。「こういう場面ではこのskillを呼ぶ」という流れが決まっているから、運用が回る。

1週間で作って、即運用

ここまでの10個のskillsは、2026年3月頭から、約1週間で一気に作りました。それから1ヶ月ちょっと運用しています。

正直、これほど速く立ち上がると自分でも思っていませんでした。理由は、Phase 1〜4の試行錯誤の大部分を、Claude Codeと対話しながら進められたからです。skillの中身を自分で書くのではなく、「こういう運用をしたい」と相談して、提案された定義を調整する。この方法だと、skill群が数時間〜半日でできます。

次回、この仕組みには前提条件があり、すべての組織で真似できるわけではない話を書きます。また、LinearやBacklogといった既存PMツールもAI機能を強化している現状を踏まえて、なぜそれでも自作を選んでいるのかも整理します。