プロセス提案シミュレーター(プロトタイプ)
7つの質問に答えると、ピットイン方式参照モデルをあなたのチーム向けに調整した提案を、根拠つきで表示します。入力内容がブラウザの外へ送信されることはありません(要件定義)。
Q1. 開発に関わる人数は?(プロダクトの開発・レビュー・承認に日常的に関わる人数(専任・兼任を問わない))
Q2. プロダクトはいまどの段階?
Q3. 品質への要求は?
Q4. 最悪の場合、何が起きる?(想定できる最悪の故障が起きたときの帰結。品質要求(可用性・監査)とは別に、危害の深刻度で選ぶ)
Q5. 開発の形態は?
Q6. 作成を指示した本人以外に、確認できる人はいる?(2名体制の相手、他チーム・別部門・社外コミュニティなど、コードや仕様を見てもらえる相手。AI の確認は数えない。回答は初期化の時点の見込みとして記録する。確認者を置けるかどうかは、人の名簿と席の記入から判定する(第4章 G-6))
Q7. 社内に既存の承認ゲートはある?(品質管理部門の判定、CTOレビュー、リリース判定会議など)
Q8. AI利用の制約は?
すべての質問に答えると、ここに提案が表示されます。
あなたのチームへの提案
ゲートの調整
ロール・運用の調整
調整の根拠
すべての調整は知識ベースの規則に由来します。上書きされた調整(取り消し線)も、判断の過程として残しています。
チームでの修正と採択
提案は出発点です。ゲート表の「あなたの修正」列で各ゲートの扱いを上書きできます。提案より弱める方向の修正は逸脱として提案書に記録されます。修正を含めた状態はこのページの URL に保存されるので、リンクを渡せばチームの他メンバーが同じ内容を確認できます。
- A(結果責任)を2人以上に割り当てない(理由: 責任の分散は「全員の責任=誰の責任でもない」状態を生み、承認の滞留と形骸化の温床になる(フェーズ1の日本ガバナンス分析))
- AIをA(結果責任)に割り当てない。AIはどこまでもR(実行)(理由: AIは結果への説明責任を負えない。人が承認し責任を持つ構造がピットイン方式の成立条件)
- 差し戻し基準(チェックリスト)のないゲートを作らない(理由: 基準のないゲートは判定者の属人判断になり、滞留と素通し(rubber stamp)の両方を招く)
- 安全重要度CL3の安全関連部で、AI自律レベルをL1より上げない(理由: 生成物を未検証の入力として扱い、決定論的な後段検証で捕捉しきる構成が、機能安全の枠組みで成立する唯一の経路)
- 安全重要度CL2以上で、安全リスクアセスメント(テンプレ9)と安全適合性の検証記録を省略しない(理由: 人員・期日の制約は、危害の深刻度を下げない。省略するなら安全重要度の判定自体を見直す)
- 標準から外した項目を、理由と承認者とともに提案書へ記載せずに運用しない(理由: 規格の世界でも、テーラリングは適合の放棄ではなく「差分の宣言」を条件に認められる。宣言のない省略は追跡できない)
- リスク区分に依存する条項を、案件単位で適用外にしない(理由: リスク区分は変更ごとに判定する。案件の安全重要度から、変更ごとの判定の適用外は導けない(ADR-0039))
- 担い手の運用形態(人確定・協働・委任)の上限を、案件単位で引き上げない(理由: 上限は変更ごとのリスク区分で決まる。席ごとの宣言は上限であり、R1を協働や委任へ、R2を委任へ引き上げる経路はない(ADR-0054))
- 適合性確認が失効した担い手の確認を、検出の層に数えない(理由: 担い手の識別(モデルの版・指示資産の版・権限の組)が変わった時点で確認は失効する。測り直すまで、その担い手の確認を検出能力の根拠にできない(ADR-0056))
ベースの全体像はピットイン方式参照モデル、実装方法はフェーズ5の実装リファレンスを参照してください。採択したら、提案書を自組織のリポジトリへ持ち帰って版管理を始めてください。
このシミュレーターはユーザーテスト中です。提案への違和感・質問の分かりにくさなど、気づいたことをフィードバック Issueでお寄せください(提案内容への指摘は共有URLを添えてもらえると助かります)。検証の記録はユーザーテストを参照してください。