AI導入プロジェクトの責任者と役割分担

架空の12人企業で起きた役割の空白

以下は役割設計を考えるための架空例です。従業員12人の卸売会社が、営業担当の面談メモからお礼メールの下書きを作る小規模実験を始めます。実在企業の導入事例や成果ではありません。

社長は「営業主任に任せた」と考え、営業主任は外部支援者が安全性まで保証すると考え、外部支援者は入力文の作成だけが担当だと考えていました。この状態では、顧客情報を入力してよいか、下書きの事実を誰が照合するか、誤送信の疑いで誰が止めるかが決まりません。

そこで仕事を肩書ではなく、成果物と判断に分けます。対象は、承認済みの架空面談メモを使った下書き実験。顧客への送信は対象外とし、二週間後に継続、修正、中止を決める設定です。

五つの欄で責任を分ける

「担当」だけでは、作る人と最終判断する人が混ざります。各成果物に次の五つを置きます。

• オーナー：期限、目的、停止を含む成果全体に責任を持つ
• 実行者：手順に沿って作業し、記録を残す
• 検証者：原資料、基準、禁止事項と照合する
• 承認者：利用や公開に進めてよいか最終判断する
• 代行者：不在時にどの役割をどこまで引き受けるか決めておく

外部支援者へ作業を委ねても、社内の業務判断まで自動的に移るわけではありません。契約範囲、成果物、受入条件、情報の取扱い、事故時の連絡先を明記します。

記入済み役割表

次は架空会社が実験開始時に完成させた表です。氏名ではなく役職で示していますが、実際には連絡可能な個人名と期限も記入します。

「承認は延期」は空欄ではありません。権限を持つ代行者がいないため、本人不在なら実施しないという運用です。停止だけは被害拡大を避けるため、営業主任が暫定的に行えるようにしています。

一人が複数役を持つときの境界

小規模企業では兼務を避けられません。営業主任がオーナーと実行者を兼ねることはできますが、顧客への送信、個人情報の利用、費用発生、利用停止後の再開など影響の大きい出力を自分で検証し、自分で承認する形にはしません。別の権限者が原資料と基準を確認します。

人を増やせない場合は、影響を下げます。実データを使わず架空データだけにする、外部送信をしない、金額や契約判断を対象外にする方法です。それでも独立した承認が必要な仕事は、承認者が戻るまで止めます。「少人数だから自己承認」は例外ルールにしません。

外部支援者が実行者と技術面の検証者を兼ねる場合も、業務上の正しさと利用可否は社内の別担当が確認します。何を検証したかを分けて記録すれば、同じ「確認済み」という言葉の混同を防げます。

会議では空欄と衝突を探す

開始会議では表を読み上げ、「連絡がつかない場合」「基準にない出力が出た場合」「入力後に禁止情報へ気づいた場合」を一つずつ模擬します。代行者が元の役割と同じ権限を持つか、停止と再開の権限が分かれているかも確認します。

変更時は日付、変更理由、承認者を残します。担当者の退職や休暇、外部契約の終了があれば、表を更新するまで新しい実験を始めません。成果が良くても役割の空白が見つかれば、まず運用条件を直します。

引継ぎでは、最新版の手順、未解決事項、直近の停止記録、連絡先を代行者と読み合わせます。代行者が一度も作業を試していなければ、架空データで模擬し、権限外の判断を求められたときに保留できるかも確認します。表の名前を変えるだけでは引継ぎ完了としません。

最初の一枚は成果物から埋める

役職一覧から始めず、「何を作るか」「誰が使ってよいと決めるか」を先に書くと、責任の重なりが見えます。次に検証者と代行者を置き、高影響の自己承認が残っていないか確認してください。

自社の人数で五つの欄を埋め切れない場合は、30分相談でご相談ください。対象範囲を小さくする案も含め、責任と権限が食い違わない進め方を一緒に作ります。