案件ごとに業務ヒアリングから始めたり、評価設計から始めたり、とりあえずプロトタイプを作ったりする。

そのため、AIプロジェクトには「決まった進め方がなく、毎回オリジナルで設計しなければならない」ように見える。

ただ、実際には少し違いプロジェクトごとに、最初に抱えているリスクが違うからであり、それは序盤で見極めてパターン化することができる。

前提知識

プロマネの基本として、進め方とは、プロジェクトに存在するリスクによって決まるもの

• プロジェクトでは、企画書、要件定義、設計書、プロトタイプ、評価、ユーザーテストなど、さまざまな活動を行う。

• ただし、それらを実施すること自体に価値があるわけではない。

• それをやらずに進んだ場合に、

  • 間違ったものを作る

  • 作ったものを間違って評価する

  • 現場で使えないものを実用化する

  • 顧客と認識がずれる

  • 重大な事故や損失につながる

    といった可能性があるから実施している。

• 企画書や設計書も、突き詰めれば何らかのリスクに対する対応策である。

つまり、あるべき進め方 = そのプロジェクトで起こりうる失敗を、必要な順番で潰していく方法と考える方が近い。

「進め方がわからない」ときに、本当にわかっていないのは手順ではない。

• このまま進むと何を間違える可能性があるのか
• その失敗がどれくらい重大なのか
• そのリスクを判断するために、何がまだわかっていないのか

がわかっていない。

進め方がわからないのではなく、リスクがわからない。

これがまず出発点になる。

AIプロジェクトの3変数

仕事の複雑性・組織の業務リテラシー・推進するチームのAIリテラシーの3変数によって潜んでいるリスクが大きく変わる

AIプロジェクトの難易度と進め方を大きく左右するものは、主に3つある。

1. 仕事そのものの複雑性
2. 組織の業務リテラシー
3. AIリテラシー

同じ「営業AI」「図面AI」「問い合わせ対応AI」という名前でも、この3つが違えば実質的には別のプロジェクトになる。

業務の品質や価値条件が細かい言語化されていない組織であれば、機械化以前のその業務の成立条件が明らかになるかどうかが怪しい。

• 仕事自体が暗黙知だらけ
• なぜその業務をしているのか組織内でもわからない
• AIをどう評価すればいいかもわからない

のであれば、実装より前に大量の探索が必要になる。

だから毎回オリジナルなのは、必ずしもプロセスそのものではない。

どこにリスクがあり、何をどの深さまで探索する必要があるかが毎回違う。

仕事の複雑性

同じ名前の仕事でも、機械（暗黙知を知らない未経験者）から見ればまったく違う仕事である

AIプロジェクトでは、「営業をAI化したい」「審査を自動化したい」「図面作成を自動化したい」といった言葉から始まることが多い。

ここで「ああ、営業ね」と理解したつもりになるのがかなり危ない。

例えば「営業」と呼ばれている仕事でも、

• 顧客に商品を説明する
• 顧客の課題を整理する
• 提案書を作る
• 契約条件を調整する
• 契約処理まで行う
• 他部署へバックオフィス業務を投げる

など、会社によって実体がまったく違う。

人間はこれらをまとめて「営業」と呼べる。

しかし、機械から見れば別の処理である。

仕事によって、AI化の難しさは大きく違う

同じような処理に見えても、仕事の性質が違えば進め方も変わる。

例えば、

• 必要なデータが最初からすべて存在する
• データへのアクセスも可能
• 人間は解釈と判断だけをしている

のであれば、比較的早くAI化できる。

一方で、

• 必要な情報を自分から取りに行く
• 顧客へ質問する
• 回答によって次の行動を変える
• 類似事例を探しながら推測する
• 表情や雰囲気など非デジタル情報も利用する

となれば、自律的な仕事そのものを再現する必要が出てくる。

また、

• 多少間違っても問題ない仕事
• 一度の誤りで大きな顧客損失が発生する仕事
• 手術や自動運転のように極端な精度が必要な仕事

でも必要な設計は変わる。

つまり「AIでできるか」以前に、対象としている仕事が、そもそもどのような性質の仕事なのかを見極めなければならない。

組織の業務リテラシー

AI化の難易度は、その組織が自分たちの仕事をどれだけ言語的に構造的に理解しているかで変わる

同じ仕事であっても、組織によってAI化の難易度はかなり違う。

業務遂行や業務設計の能力が高い組織では、

• 業務フロー
• 入出力
• 判断基準
• 品質基準
• 例外条件
• リスク
• なぜその作業が必要なのか

まで、すでに明文化されていることがある。

この場合、DXやAI化はかなり進めやすい。

一方で、

• 昔からこのやり方だから
• 詳しい人なら見ればわかる
• マニュアルにはこう書いてある
• なぜ必要なのかは誰も知らない

という仕事も多い。

特に長く続いている大企業の業務では、

「この業務が始まったときに設計した人はもういない」

ということすらある。

その場合、構造から逆算して、

「これはこの事故を防ぐために存在しているのではないか」

と、仕事の意味そのものを再発見しなければならない。

暗黙知とは、単にマニュアルがないことではない

現場では、

• たくさん経験しているからなんとなくわかる
• このケースは危ない気がする
• これはやらなくていい
• こういうときだけ確認する

といった知識が大量に存在する。

本人に「判断基準は何ですか」と聞いても出てこないことがある。

しかし、

• こういうケースはどうですか
• これは省略できませんか
• この確認をしないと何が起こりますか

と具体的に聞くと、

「昔こういう事故があった」

という話が出てきたりする。

つまり、AI化ではマニュアルを読むだけでは足りない。

その仕事が現在の品質を成立させている理由まで取りに行く必要がある。

管理者と現場で「良い仕事」の基準やNG条件が違うこともある

さらに難しいのが、組織の中で評価基準が一致していないケースである。

例えば、

• 経営側は「クレーマーには最低限対応すればよい」と考えている
• 現場側は「問い合わせに誠実に答えることが自分たちの仕事だ」と考えている

ということがある。

現場の品質基準に合わせると、

• AIへの要求が極端に高くなる
• いつまでも実用化できない

こともある。

逆に経営だけを見れば、

• 現場で守られていた重要な品質を落とす

可能性もある。

したがって、

• 絶対に守る条件
• より高いほど価値がある条件
• 実用上の合格ライン

を、組織として明らかにする必要がある。

これはAIの評価設計であると同時に、仕事そのものの再定義でもある。

AIリテラシー

AIそのものへの理解度、具体的な実用化やリプレイスの成功経験によっても、必要な進め方が変わる

仕事が明確でも、AIを利用する側がAIプロジェクトに慣れているとは限らない。

例えば、

• AIにどこまで任せられるのか
• 何を作れば可能性を判断できるのか
• どの程度の精度を期待すべきか
• どのように評価すればいいのか
• AIと人間をどう組み合わせるのか
• どこまで作れば実用化と呼べるのか

がわからなければ、それ自体がプロジェクトリスクになる。

AI活用に慣れている組織なら、

• 小さく作る
• 実データで評価する
• 原因を分解する
• 改善する

というサイクルへすぐ入れる。

一方、慣れていない場合は、

• AIに何ができるか
• AIはどのように失敗するか
• 100%正解しないものをどう運用するか
• 人間と比較してどの水準なら導入するか

といった前提から共有する必要がある。

AIでは「作れない」より「作ったものを見誤る」リスクが防げるチームしか主幹業務での実用には至れない

以前は、「そもそもAIにこの知能があるのか」が大きな問題だった。

しかし現在は、多くの一般的な業務について、

• 一定の処理能力を持つAIを作ること
• プロトタイプを作ること

そのものはかなり簡単になっている。

その結果、相対的に重要になっているのが、作ったAIを正しく評価できるかという問題である。

例えば、

• 本当の業務品質と関係ない指標を評価する
• 現場では致命的な失敗を平均値に埋める
• 人間より高い精度を不必要に要求する
• 現在の運用との比較をせず絶対評価だけを行う

といったことが起こる。

AIが微妙なアウトプットを返したとき、「AIの性能が低い」と考えがちだが、実際には、

• そもそも仕事の定義が違った
• 必要なデータが存在していなかった
• AIが解くべき問題設定が間違っていた
• 評価方法自体が間違っていた

ということも多い。

AIプロジェクトでは、作る能力以上に、何を作るべきかを定義し、何が良い状態なのかを評価できる能力が重要になる。

結論

進め方の間違いは組織/仕事/AIへの誤解から生まれる。

AIプロジェクトが他の領域より進め方を間違えやすい最大の理由は、仕事を理解していない状態でも、仕事を理解したつもりで作り始められてしまうことにある。

その案件固有の構造やリスクを見落とし、必要名整備・必要な探索、評価も、構築もも個別最適性を満たせなくなる。

「良い進め方がわからない」ときは、進め方自体ではなく、リスクが見えなていないという姿勢で探す。

• 仕事がわかっていないなら、仕事を探索する。
• 評価基準がわかっていないなら、評価条件を探索する。
• AIで実現可能かわからないなら、小さく作って試す。
• 失敗原因がわからないなら、評価を分解して原因を探索する。

プロジェクトを前に進めるとは、決められた工程を順番に消化することではない。

今ある未知とリスクを見つけ、それを「わかっている状態」に変えていくこと。

AIプロジェクトの進め方が案件ごとに違って見えるのは、そのためである。

毎回ゼロから進め方を発明しているわけではない。

仕事の複雑性、組織の業務リテラシー、AIリテラシーという3つの条件を見ながら、どのリスクを、どの順番で、どこまで解消する必要があるかを設計している。