business-operations-skills

事業運営 — ドメインオーケストレーター

BizOps の領域は社内向けです。会社が実際にどのように運営されているかを扱います。このオーケストレーターは会話コンテキストを分岐し、問い合わせを6つのサブスキルのいずれかに振り分けたうえで、要点を絞った概要を親スレッドに返します。大量の情報取り込み（ベンダーカタログ、業務プロセスへのヒアリング、複数文書にわたる SOP の取り込み）は、分岐したコンテキスト内で行います。

呼び出すタイミング

症状	振り分け先のサブスキル
「業務のどこで待ち時間が最も長くなっていますか？」	process-mapper
「このベンダーは SLA を満たしていますか？」	vendor-management
「Q3 にリリースするだけの人員は足りていますか？」	capacity-planner
「組織再編について社内向けの説明資料を作りたい」	internal-comms
「インシデント対応プロセスのランブックを書いてください」	knowledge-ops
「ソフトウェア支出が前年比で40％増加したのはなぜですか？」	procurement-optimizer

振り分けロジック（決定論的）

オーケストレーターは、プロンプト内で検出されたシグナルに基づいて問い合わせを分類します。確信を持って振り分けるには2つのシグナルが必要です。シグナルが1つの場合は、確認の質問をします。

シグナルテーブル

シグナルクラス	キーワード	サブスキル
PROCESS	ボトルネック、サイクルタイム、待ち時間、引き継ぎ、BPMN、プロセスマップ、ワークフロー	process-mapper
VENDOR	ベンダー、サプライヤー、SLA、契約、サードパーティ、MSA、SaaS サブスクリプション、更新	vendor-management
CAPACITY	人員数、キャパシティ、稼働率、計画、採用順序、FTE	capacity-planner
COMMS	全社ミーティング、社内ニュースレター、発表、チェンジマネジメント、FAQ、タウンホール	internal-comms
KNOWLEDGE	SOP、ランブック、ナレッジベース、Wiki、プレイブック、ドキュメント、オンボーディング文書	knowledge-ops
PROCUREMENT	支出、調達、購入、サプライヤーの集約、ソフトウェア監査、SaaS の乱立	procurement-optimizer

シグナルが混在している場合（例：「ベンダーの SLA ＋ 支出監査」）、まず確信度が最も高いサブスキルを実行し、その後の分岐ターンで2つ目のサブスキルにつなぎます。

フォールバック

該当するシグナルクラスのスコアがどれも2以上にならない場合は、候補として可能性が最も高い2つを示し、確認の質問を1つだけします。黙って推測してはいけません。

ワークフロー（Matt Pocock のグリル手法）

Matt Pocock の grill-with-docs パターンに基づきます。先に調査してから質問し、推奨する回答とともに1ターンにつき質問を1つだけ行い、意思決定ツリーを深さ優先でたどり、依存関係を追跡し、すべての問いかけの根拠を文書化された標準（references/）に置きます。

ステップ1 — 質問する前に調査する

確認の質問をする前に、次の点を確認してください。

• ユーザーの作業ディレクトリに、grep 可能なプロセスマップ、ベンダーカタログ、SOP、組織図がすでにあるか
• 問い合わせから対象領域がすでに特定できるか（例：「ベンダーの SLA レビュー」なら vendor-management なので、質問は不要です）
• 言及されたファイル名から対象領域を明確に特定できるか（procurement-Q3.csv → 調達）

コードベースから対象領域を特定できる場合は、黙って振り分けます。質問しないでください。

ステップ2 — まだ曖昧な場合は、推奨回答を添えて絞り込む質問を1つだけする

Matt のルール：質問をまとめてはいけません。「どう思いますか？」を安易に使ってはいけません。必ず推奨案を提示してください。

パターン：

Q1/1: [precise question naming the two candidate lanes]
Recommended: [Lane X, because <one-sentence rationale from the signal table>]

(Confirm, or override?)

ユーザーの回答を待ちます。その後で振り分けます。質問をしたターンの後に、黙って推測してはいけません。

ステップ3 — 分岐する意思決定ツリーをたどる（問い合わせが複数の領域にまたがる場合のみ）

ユーザーの問い合わせが正当に2つの領域にまたがる場合（例：「ベンダーの SLA ＋ 支出監査」＝ VENDOR ＋ PROCUREMENT）、ツリーを深さ優先でたどります。

1. 確信度が高い領域を先に確定する → 分岐したコンテキストでそのサブスキルを実行する → 概要を返す
2. 「次に［2つ目の領域］も実行しますか？推奨案は、はいです。理由は［依存関係］です。」
3. ユーザーが明示的に確認した後に限り、2つ目のサブスキルを実行する

黙って連鎖させてはいけません。分岐のたびに、ユーザーの明示的な確認を得てください。

Step 4 — フォークしたコンテキストでサブスキルを呼び出す

各サブスキルは、元のプロンプトと構造化された入力（ファイルパス、JSON 入力）の要約を使って呼び出します。フォーク先では、大量の取り込み処理（ベンダーカタログ、プロセスの記録、SOP のソースドキュメント）を親コンテキストの外に保ちます。

Step 5 — 根拠となる典拠を引用した問いかけを添えて要約を返す

サブスキルの完了後、親スレッドに200 語以内の要約を返します。

• 分析した内容
• 主な調査結果トップ 3（それぞれ参考文献の引用を付記。例：「Goldratt の制約理論：制約のない工程ではなく、ボトルネックを最適化する」）
• 次のアクションのトップ 3（可能であれば担当者を明記）
• 作成した成果物のパス
• ユーザーへの問いかけを 1 つ、出典を引用して提示：「付加価値比率は 12% です。リーンの典拠（Womack & Jones 1996）では、15% 未満はムダの多い状態とされています。プロセス再設計を妨げているのは、政治的な要因、技術的な要因、予算のどれですか？」

その後、親エージェントは追加の質問をすることができます（質問ごとに新しいフォーク呼び出しが発生します）。

問いかけの質問集（ドキュメントを根拠に問いかけるパターン）

ユーザーから特定の領域に進むのに十分な情報が得られたら、オーケストレーターはサブスキルを呼び出す前に、その領域内の意思決定について問いかけることができます。各ターンで質問は 1 つずつ提示し、推奨される回答と典拠の引用を添えます。例：

• PROCESS レーン：「マッピングを始める前に、各段階のサイクルタイムを実測していますか。それとも推定値のみですか？ 推奨：所要時間が最も長い上位 3 段階について実測データを求めてください。アンチパターン（Goldratt 1984）：推定値でマッピングすると、誤った制約を最適化してしまいます。」
• VENDOR レーン：「評価を始める前に、ティア 1 の重要度のしきい値をどう定めますか。年間支出額（$X/year）で定めますか。それとも業務上の依存度（ベンダーの障害が売上を阻害するか）で定めますか？ 推奨：業務上の依存度です。アンチパターン（Gartner TPRM）：支出額だけで階層化すると、Target の情報漏えい事件における HVAC ベンダーのような、支出額は少なくても重要なベンダーを見落とします。」
• CAPACITY レーン：「モデル化を始める前に、稼働率とスループットのどちらを計画していますか？ 推奨：スループットです（Little の法則）。アンチパターン（DORA）：稼働率を 80% 超で計画すると、待ち行列が発生してスループットが低下します。」

レーンを定義する意思決定が確定するまで、サブスキルを実行しないでください。

前提

1. ユーザーは従業員 10 人以上の組織を代表して行動しています（それより小規模な組織にはこの機能は不要です）。
2. ユーザーはサブスキルに必要なデータ（プロセス文書、ベンダーリスト、支出データのエクスポートなど）にアクセスできます。または、スキルに用意されたダミーデータを使うことに同意しています。
3. ユーザーは、LLM 風の文章よりも決定的で再現可能な分析を求めています。各サブスキルには、標準ライブラリのみを使用する Python ツールが含まれています。

対象外

• ERP、ベンダー管理プラットフォーム（Vendr、Tropic）、またはキャパシティプランニング SaaS（Float、Runn）の代替ではありません。
• セッションをまたいで状態を保存しません。呼び出しごとに独立して動作します。
• Python ツールから外部 API を呼び出しません（設計上、標準ライブラリのみを使用します）。

以下との違い

• business-growth/* — 外部向けの営業活動（CSM、セールスエンジニアリング、RevOps）を対象とします。BizOps は社内向けです。
• c-level-advisor/coo-advisor — 戦略的な COO の判断（「組織を再編すべきか？」）を対象とします。BizOps は戦術的な業務（「ボトルネックを示したプロセスマップはこちらです」）を対象とします。
• engineering/slo-architect — SLO／SLI／エラーバジェットを用いたシステムの信頼性を対象とします。process-mapper が扱うのは業務プロセスの信頼性であり、システムの信頼性ではありません。
• engineering/llm-wiki — Karpathy のパターンに基づく個人用PKM です。knowledge-ops は全社向けの SOP 作成を対象とします。

出力成果物

各サブスキルは、少なくとも 1 つの成果物（Markdown、CSV、または JSON）を作成し、ユーザーの作業ディレクトリに保存します。オーケストレーターは、要約にファイルパスを記載します。

アンチパターン（禁止事項）

• ❌ 「念のため」と 6 つすべてのサブスキルを実行する — シグナルに基づいて 1 つを選び、要約を返して、次のスキルの呼び出しはユーザーに委ねます
• ❌ ベンダーやプロセスの変更を自動承認する — 調査結果を提示し、判断は人間に委ねます
• ❌ 確認を求めずに本番環境のプロセス文書を編集する — 新しいファイルに書き込み、差分を提案します
• ❌ 要約の手順を省略する — 親コンテキストに必要なのはサブスキルの出力全体ではなく、200 語以内の要約です

参考資料

• 戦略的な COO の位置付けについては、c-level-advisor/coo-advisor を参照してください
• Path-B の構築パターン：documentation/implementation/bizops-commercial-expansion-plan.md