生成AIが使われない本当の理由は「社長の決定渋滞」だった

番組冒頭で松田さんは、今回はニュースではなく自社の話をすると切り出します。テーマは「AIシステムは作った後に壁がある」という、実際に取り組むなかで感じた気づきです。

AIが進化してから、社内から「こういうAIシステムができたので見てください」という連絡がチャットワークで届くようになったといいます。担当者が自発的に報告してくれること自体は、ありがたい状況です。

ところが報告を受けた後、松田さん自身がどうしているか。正直なところ、チャットワークで届いたものを既読のまま数日置いてしまうことが実際にあったと打ち明けます。

見ないわけではない。ただ、AIシステムを評価するには実際に触って使い、直してほしい点を開発者に伝える必要があります。まとまった時間が取れないと、そこまで到達できないのです。

結果として、気づけば2、3個の「決定待ちのAIシステム」が溜まっていたと松田さんは振り返ります。

松田さんはまず前提を整理します。AIシステムを「作る」壁は、ここ数年、さらにここ数ヶ月でグッと下がったといいます。

たとえばGoogle系のツールやClaude CodeClaude Code ── Anthropic社のAI「Claude」を使い、自然言語での指示からプログラム開発を進められる開発支援ツール。のようなものを使えば、プログラムが書けなくてもシステムのようなものを作れると説明します。

ただし成果が出るシステムでなければ意味がないため、作る部分はコンサルに伴走してもらったり、自社でできるところをやって一部を外部に頼んだりするのがよいと松田さんは話します。実際に自社でもそうしているそうです。

問題はその先の「浸透」です。プリマベーラでは10個近いAIシステムを動かしていますが、しっかり使われて浸透していくものと、だんだん使われなくなって形だけ残るものに分かれてきたといいます。

同じ人が同じ道具で作っても、使われるものと使われないものが出てくる。松田さんは最初、システムの出来の差かと考えました。

しかしよく考えると、差はもっとシンプルだったと気づきます。その差は「決定」だというのが、たどり着いた答えでした。

いつもこの番組で伝えているとおり、うまくいかない原因を人のやる気に求めても何も解決しません。やる気に頼る前に仕組みを疑うのが基本の考え方だと松田さんは言います。

AIが浸透しないとき、多くの社長は「現場が使ってくれない」「うちの社員はAIやITが苦手だから」と考えがちです。しかし松田さんは、その前に疑うべきは社長自身の決定だと自らの経験から語ります。

AIが使われない状態は、一見すると「導入の問題」に見えます。だから使い方の説明会をしよう、マニュアルを配ろうという話になりがちです。

しかし仕組み化の視点で見ると、原因はこの番組で何度も伝えてきた「決定サイクル」が止まっていることにある、と松田さんは指摘します。

この決定サイクルをAIシステムに当てはめると、流れがわかりやすくなります。

プリマベーラの場合、実施と報告まではまだ質に課題はあるものの、回り始めているといいます。問題はその次、社長の番である「決定」でした。

実際に触って「これで行こう」「ここを直して」「これは使わなさそうだからやめよう」と判断するのが決定です。自社ではここで止まっていた箇所が多かったと松田さんは認めます。

決定が止まると担当者は次に進めません。直していいかも、現場に広げていいかもわからない。仕方なく別のシステムを作り、また「できました、見てください」と社長に届きます。

こうして社長のもとに決定待ちのシステムが並んでいく。松田さんはこれを「決定渋滞」と呼びます。

渋滞したシステムは、担当者の熱も冷め、社長自身もチェックしなくなり、形だけが残って終わっていきます。だからAIは、意思決定者がきちんと決定するところまでセットでやらないと止まるのだと松田さんは強調します。

決定すべき層は仕組みの階層によって変わります。経営の仕組みなら社長、事業の仕組みなら部長、業務の仕組みなら店長。その層の決定が止まれば、浸透もブラッシュアップもされません。

ではなぜ決定が止まったのか。松田さんが自ら振り返って挙げた大きな要因は、テキストで進めようとしていたからでした。

いまプリマベーラの社内のやりとりは、ほとんどがテキストです。チャットワークを使ったテキストコミュニケーションが主流で、これは多くの会社でも同じでしょう。それ自体は正しいと松田さんは言います。

ただ、ことAIシステムのチューニングに関しては、テキストが罠になっていたといいます。落とし穴は大きく3つあります。

1つ目は、AIシステムは作った時点で100点ではないという前提です。作れるのは50点や60点で、そこから自社に合わせてチューニングする作業が必ず発生します。

たとえばブログ記事を作るシステムなら、社内の用語や言葉遣い、言い回しを自社に合わせて調整する必要があります。担当者が「できました」と言った時点では、まだ半分しか完成していないのです。

2つ目は、テキストの報告は「見てください」で終わってしまうことです。報告としては成立していても、社長が意思決定するための情報としては足りません。

結局、社長が自分でリンクを開いて触り、どこが自社に合っていないかを見つけ、言語化してフィードバックする。この一連が社長側のタスクになるため、忙しい社長ほどここで止まります。松田さん自身、実際に何個も止まっていました。

その解決策として松田さんは、担当者側が同じ視点を持つことを挙げます。AIシステムには必ず解決したい目的があるので、追加した機能がその目的と整合しているかを確認する。そう報告してもらえれば、社長が決定すべき塊が小さくなり、決定しやすくなるといいます。

3つ目は、修正指示をテキストで書くと長くなり、解釈がずれることです。項目の順番、店舗ごとの分け方、言い回し。こうした指摘をテキストで書けば、当然長くなります。

たとえば5個フィードバックして2個は改善されても3個は直らない、ということが繰り返されます。50点が70点になっても残り3つが残り、使ってみて「なんか違う」と気づき、「あれ、これ前に指示したはずなのに」とまた思い出す。ここで時間が溶けていくのです。

この3つの落とし穴こそ、プリマベーラで起きた決定渋滞の正体だったと松田さんはまとめます。

対策として松田さんが出した答えはシンプルでした。週1回、あるいは2週に1回でもいいので、20分ほどリアルタイムでミーティングをし、テキストではなく口頭でやると決めたのです。

テキストでやっていた報告と決定を、リアルタイムに置き換える。オンラインで問題なく、自社ではGoogle Meetでやろうとしていると話します。

この設計のポイントは4つあります。

1つ目のカレンダー化について松田さんは、報告を待つのではなく取りに行く、決定を待つのではなくしに行く、と表現します。時間がある時に見ようと思ってもなかなか見られないからです。

4つ目のテキスト化は重要な補足です。口頭だけだと空中戦になってログが残らず本末転倒なので、意思決定した内容や話の流れはAIの文字起こしで必ず残し、タスクにして改善につなげます。

松田さんは、これはAIシステムの導入時にも同じことが言えると付け加えます。テキストやマニュアルで現場に伝えてもわからない部分は残るので、最初の数十分だけでも使い方をリアルタイムで伝えるのが効果的だといいます。

そのうえで松田さんは、効率化と非効率化の使い分けが大切だと語ります。通常の意思決定や報告の場は効率化すべきですが、こと今回のAIのブラッシュアップに関しては、あえて非効率な会議をやったほうが前に進むという考えです。

非効率化することで決定渋滞がなくなり、ブラッシュアップが早くなり、全従業員がAIを使いこなせるようになる。会社としてはそちらのほうが期待成果が大きい、というのが松田さんの結論です。

松田さんは、多くの中小企業がいま「AIによる成果向上」と「それを浸透させること」という大きく2つの壁に直面しているのではないかと見ています。

とくに浸透の部分は、いかに仕組みとして設計してやっていくかが大切だと繰り返します。今回の決定渋滞の話は、その一例でした。

最後に松田さんは、プリマベーラではAIシステムの開発と、それをどう浸透させるかをセットにした「成果の出るAI顧問」も行っていると紹介します。システムは作れるが浸透しない場合や、どんなシステムを作れば成果が出るかという相談に役立てるといいます。

まとめ

AIシステムが使われない原因を現場のやる気やITリテラシーに求める前に、松田さんは社長自身の「決定」が止まっていないかを疑うべきだと説きます。作る壁が下がった今、勝負は作った後の浸透にあり、その要は意思決定者の決定サイクルを止めないことでした。

• 使われるシステムと形だけ残るシステムの差は、出来の良し悪しではなく「決定」されているかどうか
• 決定が止まると担当者は別システムを作り続け、社長のもとに決定待ちが並ぶ「決定渋滞」が起きる
• テキストでの報告と修正指示は、50点前提・情報不足・解釈ずれの3つの落とし穴で決定を止める
• 週20分のリアルタイム会議で報告と決定を置き換え、画面共有と口頭フィードバック、AI文字起こしでのログ化を組み合わせる
• 意思決定や報告は効率化すべきだが、成果に直結するAIのブラッシュアップ会議はあえて非効率化する