Evidence——判断の記録

守秘義務に基づき、企業名・個人名・特定につながる詳細は伏せるか一般化しています。ただし、論点の構造と、下した判断の中身は事実のままです。 ここに並んでいるのは実績のリストではありません。どの局面で、何を決め、何を決めさせなかったか——判断の記録です。

4つの経営テーマ

テーマA|AIガバナンスをどう設計するか

AIを、誰がどこまで決めてよいことにするか。

生成AIの導入を現場の判断に任せてよいのか、それとも全社で統制すべきか——多くの経営者が今、この二択の間で止まっています。しかし本当の論点は「使う・使わない」ではなく、「どの判断を、誰の承認マターにするか」という統治設計です。技術評価より先に、決定権の設計を誤ると、AIは経費申請の陰で既成事実化していきます。

Case 02|通信キャリア——AIモデル評価の独立監査 良い数字ほど、先に疑う。

AIへの投資を、技術の精緻さだけで評価してよいのか。論点になっていたのは解約予兆AIモデルの評価——だが、その問いの前に確認すべきことがある。過学習リスク、季節性の分離、データ鮮度。この3点を優先して質し、施策効果と連動しない単純な的中率評価を退けて、検証方法をその場で即興提示した。

もう一つの論点は「新料金プラン移行者の解約リスクスコアが低い」という良い数字の解釈だ。母集団が直近の新規移行者に限られる以上、この数字は統計的に当然である可能性がある。移行したばかりの顧客は、解約しない。

だから拙速な成果認定を保留させた。AIの出す数字を疑う役は、AIには任せられない。

個別ページで開く →
Case 06|メディア企業——AI導入の統治ゲート設計 経費申請は、同意ではない。

新たな生成AIコーディングツールの導入が、経費申請ベースで既成事実化されつつあった。誰も明示的に承認していないのに、使われ始めている——これはAI時代に最も起きやすい統治の穴だ。新規ツールを機密データに触れさせる前に、立ち止まらせた。

実コード・実リポジトリのレビューは既存の公認AIボットに寄せ、新規ツールは機密を含まない執筆補助に限定する。この役割分担を設計した上で、経費申請による導入を「同意」とみなすやり方を明確に拒否した。

データ範囲・セキュリティ・契約条項——3つのゲートを書面で通してからでなければ、実データには触れさせない。AIが決めていいことと、人間が決め続けるべきこと。その境界線は、まさにこういう場面で引かれる。

個別ページで開く →

テーマB|DX組織をどう機能させるか

DXに投資した。なぜ成果が出ないのか。

DX部門を作り、人を採り、予算を付けた——それでも動きが鈍いとき、経営者の手元に届く説明はたいてい「人が足りない」です。しかし増員の前に切り分けるべき問いがあります。それは人員の問題なのか、意思決定構造の問題なのか。診断を誤った投資は、組織の疲弊を早めるだけです。

Case 03|DX開発部門——「忙しさ」の誤診断を退ける DX組織が機能しない原因は、人手不足ではなかった。

DX組織の生産性低下は、人員の問題なのか、意思決定構造の問題なのか——大手企業のDX開発部門で、この切り分けが論点になった。現場の空気は「人が足りない」。実際、タスク管理チケットは短期間で1割以上急増し、期限超過も多数に達していた。だがデータを分解すると、実態は違った。方針は決定済みなのに仕訳されていないチケットが滞留する——人手不足ではなく、衛生問題だ。

増員や督促による対応を却下し、死蔵チケットの一括クローズと仕分けを最優先課題に設定した。そして、仕分けが完了するまで増員判断は保留する、というキルコンディションを明示した。

忙しさを増員で解くのは、診断の放棄だ。まず問題を正しく名指しすること。

個別ページで開く →
Case 05|データ分析専門組織——採用戦略の再定義 頭数を足しても、勝ち筋は増えない。

データ分析専門組織で、人材の離職が相次いだ。目先の案件を回すだけなら、ビジネス経験者とAI活用でカバーできる。だがエンジニアリング力を軽視すれば、分析力ともども、外部依存の構造から抜けられない。短期的な人繰りと、中長期のケイパビリティ防衛。この二つを明確に切り分けた上で、採用ターゲットの再定義を主導した。

喫緊で採るべきは「アナリスト」ではない。目的を言語化し、勝ち筋を作れる「プランナー」だ。

そして競争の土俵を、勝てない年収競争ではなく差別化軸に置き直し、優先順位を確定させた。採用とは頭数の補充ではなく、組織が何で戦うかの意思表示である。

個別ページで開く →

テーマC|データを経営判断につなげるか

データ活用の本当のリスクは、数字の中身ではなく、決め方にある。

ダッシュボードも指標も揃った。次に経営が問うべきは「その指標の変更を、誰が決めてよいのか」です。現場の改善提案に見える運用変更が、実は収益に直結していることがある。データ経営の成否は、分析の精度よりも、承認階層の設計で決まります。

Case 04|小売・EC——KPI変更承認の階層設計 収益に影響する判断を、現場だけに任せない。

現場の改善提案として進めば、収益に直結するリスクを見落としかねない判断だった——会員制度を軸に据えた小売事業者でのことだ。論点は、会員ランクの更新頻度を年度単位から月次・四半期に短縮すべきか。購買頻度を刺激するというメリットの裏に、見過ごせないリスクがある——販促の割引と会員特典の割引が同じ売上に重なり、営業利益に直接跳ねる。

メリットとリスクを切り分けた上で下した判断は、KPI設計の中身そのものではなかった。財務インパクトが出る可能性が高い論点である以上、経営企画部門への相談を必須条件に格上げする。つまり「どの意思決定を、誰の承認マターにするか」の線引きだ。

KPIは間違えても直せる。承認階層を間違えると、間違いに気づく仕組みごと失う。

個別ページで開く →

テーマD|複数部門をまたぐ変革をどう進めるか

部門をまたぐプロジェクトは、誰が「次へ進む」を決めるのか。

単一部門なら部門長が決められる。しかし複数の組織が並走する変革では、フェーズを進める判断基準が誰のものでもないまま、プロジェクトだけが前に進んでいきます。経営が最初に据えるべきは、スケジュールではなく「止まる条件と進む条件」の合意です。

Case 01|流通・小売——承認ゲートの段階設計 全部決めようとすると、何も決まらない。

複数の事業会社が並走する、顧客基盤の連携プロジェクト。フェーズ移行の承認基準が存在しないまま、要件定義がクローズに向かっていた。ここで全体設計を一気に固めにいくのは悪手だ。スコープを「今すぐ決めるべき最小の一点」に絞り込み、3段階の承認フレームワークを自己起案した。確認者は現場・PM・経営の3層に分け、全件を経営に上げる非効率を断った。

リリース判定も、単発の可否判断から「リリース→初期監視→初回月次締め確認→安定稼働宣言」の4段階構造に再設計。各段階の承認者は、関与組織の実質的なリスク所在に応じて、あえて非対称に配置した。

承認とは形式ではない。リスクが在る場所に、判断を置くことだ。

個別ページで開く →

6つのケースに共通するもの

業種も論点も異なる6件だが、判断の型は同じところに帰着する。

  1. 目先の解決策に飛びつく前に、問題を再定義する。 増員の前に診断を。成果認定の前に検証を。

  2. 意思決定の重さに応じて、承認の階層を変える。 全件を経営に上げるのも、何も上げないのも、同じ設計放棄である。

  3. 自動化・拡大の前に、小さく検証する。 最小の一点を決め、ゲートを通し、それから広げる。

AIが決めていいこと、人間が決め続けるべきこと——境界線の設計とは、この3つの動作の反復に他ならない。

登壇・コミュニティ運営

判断の型は、密室で作られたものではありません。データ活用のコミュニティを運営する側で、磨かれてきたものです。

  • Treasure Data User Group 会長(2015–2018)
  • Tableau User Group 副会長(2014–2017)
  • データサイエンティスト協会 企画委員 副委員長(2014–2015)

Qorum Method——判断のやり方を、公開しています

山崎事務所が自らの運用で実践している意思決定ガバナンスの方法論を、OSSとして公開しています。リスクに応じた承認ゲート、レビュアーの役割分離——このEvidenceページで示した判断の型の、再現可能なかたちです。GitHub: shiyamaz/qorum-method

手の内は、すべて公開しています。それでも「御社の場合、境界線をどこに引くか」は、個別の仕事です。その線を、一緒に引きましょう。

Thinkingを読む →

お問い合わせ