INSIGHT
社長の自作に、誰も反対しなかった。それを採用の根拠にするな
自分で作れて現場から反対も出ないという事実を、業務の要求と品質を満たした証拠にしてよいか。
社長が自ら作った業務アプリを会議で動かす。いつも手で転記していた内容が、数分で一覧になった。参加者は感心し、質問は出ても、導入への反対は出ない。「現場も納得している」と、その場で採用を決めたくなる。
しかし、反対がなかった理由は一つではない。使えそうだと思ったのかもしれない。例外をその場で思い出せなかったのかもしれない。作成者であり決裁者でもある相手に、会議中は言いにくかったのかもしれない。沈黙だけでは区別できない。
作成者への反対が出ない関係のまま、沈黙を同意に数えて実業務への採用を決めてはいけない。
問題は「社長が作ったこと」ではなく、評価の関係にある
経営者や部門長が自分で試作品を作ることには価値がある。課題を短い距離で形にでき、現場も具体物を見ながら話せる。問うべきなのは作成者の肩書きや技術力ではなく、同じ人が説明、評価への応答、採否を握る場で、使えない条件まで意思決定者へ届くかである。
会議で「率直な意見を」と頼んでも、それだけで関係は変わらない。発言した内容を誰が評価するか、導入方針に逆らったと受け取られないか、後で修正されたか分かるかが不明なら、参加者は発言の影響を判断できない。これは実際に全員が萎縮していたという断定ではない。沈黙から同意を証明できない、という判断の限界である。
デモの場では価値と操作を確認する。採否の場では、使える条件、使えない条件、未確認を記録する。二つを分けるだけでも、画面への感想と業務への評価を混同しにくくなる。
会議の沈黙を、個別に書ける条件へほどく
「賛成ですか、反対ですか」と聞くと、評価は人や方針への投票になる。代わりに、業務の場面ごとに答えられる欄を用意する。
- 自分の担当業務のうち、どの範囲なら使えるか
- いつもの手順と違う案件は何か
- 誰の確認や承認を残したいか
- 誤った結果が出たとき、どこへ戻したいか
- まだ判断できない条件は何か
回答は、デモ会議の前後に個別でも提出できるようにする。提出先、期限、採否資料へ載せる方法を先に示す。匿名であることだけに頼らず、記録された条件が誰に渡り、どう処理されたかを追えるようにする。
「使えない」と書く場合も、全面反対を求めない。「締切後の申請では使えない」「代理承認の扱いは未確認」のように条件として残す。作成者にとっても、人格や成果への反論ではなく、修正または利用制限へ変えられる材料になる。
「反対なし」を数える代わりに、使える・使えない・まだ分からないを条件付きで集める。
反論より先に、一日の例外を記録する
評価では、通常の一件だけでなく、現場の一日をたどる。担当者が休んだときの代理、入力が欠けた申請、締切後の訂正、取り消した後の連絡、忙しい時間の中断。そこで画面外の確認や手書きのメモが出てきたら、まず事実として記録する。
作成者は、その場で「その機能はあります」「運用で対応できます」と答え切らなくてよい。すぐ説明を始めると、利用者の報告が機能への批評として扱われ、次の例外が出にくくなる。集めた後で、すでに対応している、修正する、手作業を正式な手順にする、利用範囲から外す、追加確認する、のいずれかを付ける。
NISTのSecure Software Development Framework は、設計、レビュー、実行コードの検証、公開後の脆弱性対応などを扱う。上位職の自作や発言のしやすさを研究した資料ではなく、AI生成コードの品質を保証するものでもない。ここでは、作成だけで完了とせず、別の確認と公開後の対応を残す一般的な枠組みとして参照する。
評価を成立させるのは、反対できる人より反映される記録
「社長にも反対できる人」を一人置いても、その人の勇気に評価を預けることになる。意見を集めた後の会議で、「締切後の訂正は当面、旧手順で受け付ける」と利用条件が変わる。提出者が、自分の指摘がどう扱われたかを読める。そこまで届いて初めて、意見を求めた意味が生まれる。
作成者は目的、現在の機能、既知の制約を説明する。利用者は実際の条件と例外を出す。業務確認者は、条件を試せる形に整える。採否を決める人は、使える・使えない・未確認のすべてを読んで、範囲と残作業を決める。同じ人が複数を兼ねる場合でも、それぞれの欄へ判断を残す。
NIST AI 600-1 は、生成AIのリスク管理で人とAI、第三者依存、役割、継続評価、停止・廃止などを整理している。これは日本企業への個別の法的義務でも、権限差が必ず欠陥を生むという実証でもない。役割と継続的な見直しを採否の後にも残すための参照資料である。
評価票には少数意見の件数だけでなく、条件、業務への影響、扱い、再確認する人と期限を書く。採用後も、提出した人が「その条件はどうなったか」を確かめられるようにする。
採用決裁は、四つの記録が届いてから再開する
実業務への採用を再び決めるには、少なくとも次の四つが必要になる。
- 対象となる利用者、業務、情報、確定操作が書かれている。
- 作成者以外の利用者が、使えない・未確認を条件として提出できる。
- 通常時と主要な例外を試し、結果と残作業が記録されている。
- 採用、限定利用、修正後に再評価、見送りの判断理由が残る。
そろわない間は、承認、外部送信、データ更新など実業務を確定する利用を始めない。画面の確認、サンプルデータでの試用、例外収集は続けられる。既存の手順へ戻れる範囲であれば、限定利用を評価の一部にしてもよい。
再開条件は全員の賛成ではない。「使えない」「未確認」を含む記録が決裁者へ届き、利用範囲を変えられることである。
賛成の数ではなく、言いにくい条件も採否の資料へ届く仕組みを作る
社長の自作は、改善の会話を始める力になる。だからこそ、周囲の沈黙まで成果の証拠にしない。作成者への賛否と、業務で使える条件の評価を分ければ、反対は対立ではなく改善材料になる。
次の会議では、賛成者の数を数える前に、個別に書ける条件欄と、その回答を採否へ渡す人を決めたい。評価の質は、誰かが勇気を出したかではなく、言いにくい条件も同じ決裁資料へ届いたかで確かめられる。