不信には役割がある；それがあなたのやっている仕事でないだけだ
本稿は、AIに対する不信は欠陥ではなく、信頼性工学の一部であると主張する。元マイクロマネージャーは「検証アーキテクト」となり、AIタスクがA3フレームワークのアシスト、オートメート、アボイドのどのモードに属するかを決定し、検証ループを設計できる。マイクロマネジメントの動機として、権威維持と蓄積された経験の2つを区別し、後者がAIの文脈で有用であることを示す。
アジャイルコーチングの20年以上の努力は、すべてのドラフト、会議、決定に介入するマイクロマネージャーを変えることができなかった。しかし、本稿は、彼らの不信は欠陥ではなく、単に間違った対象に向けられていると指摘する。AIの採用が進むにつれて、この懐疑的な姿勢は実際には資産となり、「検証アーキテクト」という新しい役割を生み出す可能性がある。
検証アーキテクトとは何か？検証アーキテクトは、どのAIタスクがA3フレームワークのアシスト、オートメート、アボイドのいずれのモードに属するかを決定し、各モードでのレビューの具体的な意味を定義し、AIの失敗をより鋭いプロンプト、評価、または受け入れ基準に変換する検証ループを実行する責任者である。この役割はコンプライアンス監査人ではない。コンプライアンスはルールが守られたかどうかを問うが、検証はシステムが動作条件下で主張された結果を生み出すかどうかを問う。小規模組織では、この仕事はしばしばプロダクトマネージャー、スクラムマスター、QAリーダー、またはテクニカルリーダーが肩書きを持たずに担う。
マイクロマネージャーには2つの異なる動機があり、同じ行動を生み出すが、異なる介入が必要である。1つ目は権威維持：不信は出力の改善ではなく、管理者の手に決定権を留めることに関する。この管理者に「何がこの出力を信頼できるものにするか？」と尋ねると、答えは「まず私が見る必要がある」という運用上のナンセンスである。検証はパフォーマンス的であり、リスクではなくコンプライアンスが検査される。AIツールはこのタイプの人を助けない。なぜなら彼らはより良い証拠を本当に望んでいないからだ。
2つ目は蓄積された経験：不信は具体的な過去の失敗に基づいている。この管理者は、何がうまくいかなかったか、何が約束されて実現されなかったか、どの検証ステップが失敗前にスキップされたかを詳細に説明できる。人間の同僚に対しては、これはマイクロマネジメントとして現れる。なぜなら人間の判断を検証することは社会的なコストが高いからだ。しかしAIの場合、検証は構造化されていて安価である。確率的システムを対象とすることで、同じ傾向が有用な仕事を生み出す。
この2つを区別する小さな診断：「この出力を信頼できるものにするには？」に対する答えが、権威維持では「まず私が見る必要がある」、蓄積された経験では「これら3つのチェックに合格する必要がある」である。前者は人のコンプライアンスを検査し、後者は作業成果物のリスクを検査する。前者のレビュー後は決定権が管理者に戻るが、後者ではシステムに鋭いチェック、ルール、プロンプト、または受け入れ基準が追加される。
A3フレームワーク（アシスト、オートメート、アボイド）は、どのパターンに当てはまるかをテストする方法の1つである。権威維持はA3を正直に使えず、答えは曖昧で可逆的である。蓄積された経験パターンは、タスクを数秒で分類できる。なぜなら、疑念が特定の過去の失敗に基づいており、リスクプロファイルにマッピングできるからだ。
最終的に、AIはアジャイルムーブメントが名前を付けることを学ばなかった役割を生み出す。検証アーキテクトである。彼らは「AIはこれができるか？」とは問わない。代わりに「AIが私たちの文脈で安全に、反復可能に、測定可能にこれを行うためには、何が真実でなければならないか？」と問う。彼らの作業単位はプロンプトではなく、ループであり、数ヶ月にわたって蓄積される日々の作業である。