【目的】 システムに致命的なエラー（毒矢）が発生している際、解決に直結しない「非生産的な情報収集」や「形而上学的な議論（無記）」を強制終了し、最優先タスク（毒矢の抜去）へリソースを全集中させる。
Step 1：毒矢の検知（クリティカル・イシューの特定）
現在、組織やプロジェクトにおいて流血（リソースの流出・士気の低下）を引き起こしている「真の問題」を直視する。
- [ ] 今、我々のシステム（組織・プロジェクト・自分自身）に突き刺さっている「毒矢」は、具体的に何か？（例：売上の急減、キーマンの離脱、深刻なシステム障害）
- [ ] その問題は、今すぐ止血（対処）しなければ、システム全体をクラッシュ（命終）させる危険性を持っているか？
Step 2：無効クエリ（Abyakata）の検知と強制終了
思考や会議の時間が、解決に寄与しない「矢の分析」に浪費されていないかを監査する。
- [ ] 以下の「無効なクエリ」にCPU（時間・思考）を奪われていないか？
- 犯人探し： 「誰がこの矢を射たのか？（誰の責任か？）」
- 過剰な原因分析： 「なぜこんなことが起きたのか？（過去への執着）」
- コントロール不能な外部要因： 「市場環境が…」「競合他社が…（矢の材質や出所の分析）」
- 完璧主義のバグ： 「すべてのデータが揃うまで動けない（全容解明の要求）」
- 【実行コマンド】 これらが「現在の止血（課題解決）」に直結しないと判断した場合、これらのクエリを「Abyakata（処理対象外フォルダ）」へ移動し、議論を即座に強制終了（タスクキル）する。
Step 3：共通エラーの認識（前提の再確認）
「条件が整わないから動けない」という思考のデッドロックを解除する。
- [ ] 「原因がAであろうとBであろうと（誰の責任であろうと）」、今我々が血を流し、苦しんでいる（Dukkhaが存在している）という事実に変わりはない、とチームで認識を共有できているか？
- [ ] 「真理（全容）を知ること」よりも、「生き残ること（エラーの修復）」が最優先であると合意できているか？
Step 4：Byakata（最優先タスク）の即時実行
リソースを100%、以下の「検証可能かつ解決可能な4つのプロセス（四諦）」のみに再配分する。
- [ ] Dukkha（課題の特定）： 止めるべき流血（損害・苦痛）は何か？
- [ ] Samudaya（直接原因の特定）： 今すぐ取り除ける「直接的なバグ（矢そのもの）」は何か？
- [ ] Nirodha（目標の定義）： 「矢が抜け、止血が完了した状態（滅）」の定義は明確か？
- [ ] Paṭipadā（実行プロセスの適用）： 目標達成のための「今すぐ実行できる最短のアクション（道）」は何か？
【システム・ステータス】 上記を完了し、「無関係な議論」を切り捨てて「行動」へ移行した時、システムはデッドロックから解放され、修復プロセス（最適化）が開始される。
ビジネスユースケース（適用例）
【シーン】 新規サービスのローンチ直後に重大なシステム障害が発生し、ユーザーからクレームが殺到している。
- バグの発生（マールキャ状態）： 緊急会議の場で、「なぜテスト段階で気づかなかったのか（責任の所在）」「他社の類似サービスはどうなっているか（外部要因）」「完全な原因報告書が出るまで動けない（完璧主義）」という議論に終始し、復旧作業が止まっている。
- パッチの適用（タスクキル実行）： リーダーがStep 2を発動。「誰の責任か、なぜ起きたか（無記）の議論は今すぐ強制終了する。原因報告は後回しだ。現在、ユーザーが不利益を被っている事実（苦）だけを見ろ。リソースの100%を『サービスを一時停止し、暫定復旧させること（毒矢を抜くこと）』に集中させよ」とコマンドを下す。
コメント