process-mapper

process-mapper

社内業務のリーダー向けに、BPMN 形式の業務プロセス文書化、ボトルネックの検出、サイクルタイム分析を行います。

目的

社内業務では、次のような問題が繰り返し発生します。

1. プロセスが暗黙知になっている — 手順が属人的な知識としてしか存在しないため、引き継ぎが滞り、オンボーディングに何週間もかかります。
2. 待ち時間が見えない — 業務プロセスの経過時間の大半は、実作業ではなくキュー／待機／承認に費やされます。そのため、チームは誤った工程を最適化してしまいます。
3. 局所最適化 — ゴールドラットの制約理論が無視され、制約ではない工程にリソースが追加されても、何の効果も得られません。

このスキルは、文書化されたプロセスマップを作成し、業務がどこで滞留しているかを特定し、LLM の直感ではなく決定論的なロジックに基づいて制約を具体的に示します。

使用する場面

• 新しい業務プロセスを文書化するとき（調達受付、ベンダーのオンボーディング、従業員のオンボーディング、インシデントの引き継ぎ、経費精算、顧客のオンボーディング、保険金請求の査定など）。
• 既存のプロセスが「遅すぎる」ものの、誰もボトルネックを特定できないとき。
• サイクルタイムは測定しているが、付加価値比率を測定していないため、プロセスが健全か、無駄が多いかをチームが判断できないとき。
• 部門横断の引き継ぎで作業が滞り、根本原因が不明なとき。

ワークフロー

5 段階の決定論的なフローです。

1. 受付。 各工程を 1 件ずつ記述する JSON ファイルとしてプロセスを取り込みます。各項目には name、owner、type（value-add | wait | rework）、duration_minutes_p50、duration_minutes_p90 を指定します。assets/process_template.md とその JSON のひな形を使用します。
2. 工程のマッピング。 process_documenter.py を実行し、ASCII スイムレーン図と正規化された JSON アーティファクトを生成します。スイムレーンは担当者ごとに分かれているため、部門横断の引き継ぎが見えるようになります。
3. サイクルタイムの測定。 cycle_time_analyzer.py を実行し、合計 P50、合計 P90、付加価値比率（VA%）、リトルの法則に基づくスループットの推定値を算出します。判定基準：VA% > 25% = HEALTHY、10–25% = TYPICAL、< 10% = WASTE-HEAVY。
4. ボトルネックの検出。 適切な --profile（saas / services / manufacturing / healthcare）を指定して bottleneck_detector.py を実行します。出力は、重大度（CRITICAL / HIGH / MEDIUM）、根本原因の仮説、および検出結果ごとに推奨アクションを 1 つ示す、優先順位付きリストです。
5. 推奨。 ボトルネックの一覧とサイクルタイムの判定を組み合わせ、ゴールドラットの「すべてを制約に従属させる」というルールに基づき、制約に焦点を当てた介入策を 1 つ推奨します。制約ではない工程の最適化は推奨しないでください。

スクリプト

scripts/process_documenter.py — プロセス JSON を読み込み、検証したうえで、テキストベースの BPMN 形式スイムレーン図を Markdown で出力します（担当者ごとにレーンを分け、工程には種類と所要時間を注記します）。後続のツール向けに正規化された JSON アーティファクトも出力します。標準ライブラリのみを使用します。--sample を指定すると、調達受付の 6 工程のサンプルが表示されます。

scripts/bottleneck_detector.py — 3 つの決定論的な検出ルールを適用します。（a）工程の P50 が付加価値工程の平均の 2 倍を超える、（b）待機状態がサイクル全体の 40% を超える、（c）手戻りが 15% を超える。SaaS、サービス、製造、医療では「通常」の待機比率が異なるため、しきい値は --profile に応じて調整されます。出力は、重大度、仮説、アクションを示す優先順位付きリストです。

scripts/cycle_time_analyzer.py — 合計 P50 および P90 のサイクルタイム、付加価値比率（VA%）、待機率、手戻り率、リトルの法則に基づくスループットの推定値（WIP / サイクルタイム）を算出します。リーンの原則に基づく判定基準は、VA% > 25% = HEALTHY、10–25% = TYPICAL（製造業以外のプロセスの大半がこの範囲に入ります）、< 10% = WASTE-HEAVY です。

簡単な例

# Renders a BPMN-style swim-lane diagram + normalized JSON for the built-in 6-stage procurement-intake example
cd business-operations/skills/process-mapper && python3 scripts/process_documenter.py --sample

参考資料

• references/lean_six_sigma_canon.md — TIMWOOD のムダ、バリューストリームマッピング、制約理論、カンバンの WIP、リトルの法則。Womack & Jones、Rother & Shook、Goldratt、Ohno、Liker、Pyzdek、Anderson を引用しています。
• references/bpmn_essentials.md — プール、レーン、ゲートウェイ、イベント、メッセージフロー、よくある表記上の誤り。OMG BPMN 2.0 仕様、Silver、Allweyer、Freund/Rücker、OASIS、ISO/IEC 19510:2013 を引用しています。
• references/bottleneck_anti_patterns.md — Goldratt、Kim et al.、Spear、DORA、Deming、およびプロセスマイニング研究に基づく、7つの具体的なアンチパターン。

前提条件

1. ユーザーはステージ単位のサイクルタイムデータ（概算の P50 / P90 推定値でも可）を提供できます。提供できない場合、最初に行うべきなのはプロセスの計測であり、マッピングではありません。
2. ここでの「プロセス」とは、個別のステージを持つ、繰り返し実行可能なビジネスワークフローを指し、単発のプロジェクトではありません。
3. ユーザーはボトルネックに対処する権限がある（または、調査結果を対処できる人に伝えられる）ものとします。それがなければ、出力は学術的なものにとどまります。
4. ステージの type は実態を反映している必要があります。ユーザーが「付加価値」として分類したステージは、顧客の視点から実際に成果物を変化させている必要があります。待ち時間を付加価値として誤分類することは、最もよくあるデータ品質上の失敗です。

アンチパターン

• すべてのプロセスを一度にマッピングする。 1つ選んでください。Goldratt によれば、制約は1か所です。
• 制約以外を最適化する。 ステージ4がボトルネックの場合、ステージ2を高速化しても、ステージ4の前に仕掛品が積み上がるだけです。すべてを制約に従属させてください。
• 総サイクルタイムを処理時間と取り違える。 この2つが同じであることはほとんどありません。VA% によってその差が明らかになります。
• 待ち時間が支配的なプロセスに人員を追加する。 待ち時間は人員を増やしても解消されません。引き継ぎやバッチ処理をなくすことで解消します。
• 手戻りを別の問題として扱う。 手戻りのループはプロセスマップに含める必要があります。隠すと実際のサイクルタイムが過小評価されます。

以下とは異なります

• business-growth スキル — 外部向けの営業活動、リードファネルのコンバージョン、カスタマーサクセスによる顧客維持を扱います。Process-mapper が扱うのは、社内のオペレーションです。
• engineering/slo-architect — システム信頼性の SLO、エラーバジェット、バーンレートアラートを扱います。Process-mapper が扱うのは、システムの稼働時間ではなく、ビジネスプロセスのサイクルタイムです。
• c-level-advisor (COO / CEO) — 改善対象とするプロセスの戦略的な優先順位付けを扱います。Process-mapper は、その優先順位決定後に使う戦術的なツールです。
• プロジェクト管理スキル — Jira / Confluence のチケットワークフローツールを扱います。Process-mapper が扱うのはプロセスの設計であり、チケットの追跡ではありません。

質問を深掘りするためのライブラリ（Matt Pocock のグリル・ディシプリン）

ツールを呼び出す前に、オーケストレーター（または /cs-grill-bizops）は、推奨回答と典拠の引用を添えて、以下の質問を1つずつユーザーに尋ねます。まとめて尋ねてはいけません。

1. 「最も時間のかかる上位3つの工程について、実測したサイクルタイムはありますか。それとも推定値のみですか？」 推奨：実測データを求めます。 典拠：Goldratt 1984（The Goal）—推定したボトルネックを最適化しても、誤った制約に確実に取り組むことになります。

2. 「マッピングするのは現在のプロセス（現状）ですか。それとも意図するプロセス（将来像）ですか？」 推奨：まず現状をマッピングします。ボトルネックの特定後に将来像をマッピングします。 典拠：Rother & Shook 1999（Learning to See）—バリューストリームマッピングは、必ず現状から始めます。

3. 「チーム間の引き継ぎはどこで発生し、それぞれの引き継ぎでどれくらい待ちますか？」 推奨：すべての引き継ぎを記録し、待ち時間の中央値を記録します。 典拠：Reinertsen 2009（Principles of Product Development Flow）—引き継ぎ時の待ち時間は、最も大きな見えないコストです。

4. 「各工程でのバッチサイズはいくつですか？」 推奨：可能な限り、バッチサイズを1に近づけます。 典拠：Anderson 2010（Kanban）—バッチサイズはサイクルタイムのばらつきと1対1で相関します。

5. 「工程ごとの手戻り率はどれくらいですか？」 推奨：明示し、手戻りのループをマップに含めます。 典拠：Pyzdek（Six Sigma Handbook）—隠れた手戻りが、サービスプロセスの総サイクルタイムの30-50%を占めます。

深さ優先で進めます。1～3に回答する前に質問4へ進んではいけません。5つすべての回答が確定したら、process_documenter.py → bottleneck_detector.py → cycle_time_analyzer.py の順に呼び出します。