四半期かかっていたであろうものを、週末だけで作り上げたことはありますか？
提携教会には優先事項のリストがありました。そのリストのどこかに、「エグゼクティブ・ダッシュボード」という項目がありました。大人と子どもの出席者数、イベント、ボランティアの参加状況などが一目で確認できるものです。しかし、他にも3つの優先事項がある状況では、どんな優先事項もそうであるように、この項目はリストの中でどんどん下位に追いやられていきました。そこで、私たちが目の前の課題に取り組んでいる間も、彼らは待たずに、自分たちでダッシュボードを「バイブ・コーディング」したのです。
それを開けてみると、問題なかった。彼らは数値を確認し、ロック社が実際に保管していた記録と照合した結果、問題なく機能した。
しかし、そのダッシュボードには「アクティブな小グループのメンバー数」というKPIが掲載されており、まさにその点が私たちを不安にさせたのです。
「Active」が定義されていません
ここでいう「アクティブ」とはどういう意味ですか？ステータスが「アクティブ」なグループメンバーのことですか？それとも、過去8週間のうち4週間出席した人のことですか？
後者の例を見てみましょう。ある参加者が、過去8週間のうち4週間に参加していましたが、リーダーがその参加者を別のグループに移動させたため、その参加記録は昨夜アーカイブされました。しかし、ダッシュボードでは依然としてその参加者が「アクティブ」とカウントされています。数値は正確です。記録も本物です。ただ、この記録を作成した担当者は、ここで「アクティブ」が何を意味するのかを尋ねる必要もなければ、Rockにそのような経路が存在することを知る必要もなかったのです。
「確認済み」と「理解済み」は同じ意味ではありません。
おそらく、これと似たようなものをすでに目にしたことがあるでしょう。ダッシュボードそのものではなくとも、誰かが皆の時間を節約するために手早く作成したレポートやワークフローといったものかもしれません。
これはすでに起きていたことだが、AIの仕業ではなかった
データビューの問題
Rockは、誰かがAIに何かを作成するよう依頼する何年も前から、すでにこの機能の独自バージョンを開発していました。おそらく皆さんはすでに「データビュー」という機能に出会ったことがあるでしょう。これは、設定した条件に一致する人や記録のリストを保存するためのRockの機能です。提携教会の一つでは、すべてのミニストリースタッフに、60日間の出席状況から特定の基金への献金まで、その日の業務に必要な情報を自由に作成できる機能を提供していました。 その意図は良きものでした。セルフサービスの機会を増やし、処理待ちの依頼を減らすことでした。
数ヶ月も経たないうちに、誰もが自分なりの「エンゲージメント」の定義や、「貢献」の定義を持つようになった。それぞれの報告書は、技術的には正しいものの、互いに静かに食い違っていた。経営陣は、ロック社から出される数字を信用しなくなった。問題はロック社そのものではなく、一貫性のあるデータ戦略の欠如にあった。
これは「真実の源」に関する問題であり、チームがAIをどのように活用するかという点においても同様の問題が生じます。また、この問題はデータビューだけに留まるものでもありません。
教会のテクノロジー分野以外でも、こうしたことは起こり得る
Airbnbも、一元化された指標プラットフォームを構築する前は、同じような問題に直面していました。「先週、最も予約が多かった都市はどこか」という単純な質問に対しても、データサイエンス部門と財務部門は、定義や参照するテーブルがわずかに異なるため、それぞれ異なる数値を提示していました。その結果、データへの信頼性が低下し、意思決定者からの信頼も失われてしまいました。この問題を解決したのは、より高性能なツールではありませんでした。解決策は、全員が合意して参照する「一つの場所」を設けることだったのです。
AIに同じ仕事をさせると、その差がより早く明らかになる
『Rock Cast』の第207回エピソードでは、AIが生成したSQLがどこで機能しなくなるかを示す典型的な例として、次のようなものが挙げられました。「誰かが『与えた』とされるすべてのアカウントを返してください。つまり、『どのアカウントのことなのか？ どのアカウントが『与えた』とみなされるのか？』というわけです。」
これはロック氏に限った話ではありません。2023年、2人の弁護士が、偽の判例引用で埋め尽くされた法廷意見書を提出しました。これらはChatGPTが作り出したもので、本物の裁判所の判決文のように見えました。裁判所が実際の判例を提示するよう求めた際、どちらの弁護士も、すべての弁護士がすでに所有し、書類を提出する前に使用するように訓練されている実際の法律データベースから判例を引き出すことはしませんでした。そのうちの1人は裁判官に対し、「そんなものがでっち上げられるとは思いもしなかった」と語った。判例引用は完成されたもののように見えたため、彼はそれを発見できたはずの手順を省いてしまったのだ。
ツールの処理速度が向上するにつれ、その出力結果への信頼は、誰かがそれを確認できる能力をはるかに上回ってしまう。経験豊富なRock管理者は、その不備がどこにあるかを正確に把握するために何年もかけて学んできたため、その不備を見抜くことができる。一方、そのような熟練度もなく、疑う理由もないまま、自分一人で手早く作業を進めているスタッフは、おそらく質問することすら思い浮かばないだろう。
あなたに代償を強いるリスク
その最初のダッシュボード――週末に作成されたもの――を、同じことを行っているすべてのチームや善意あるスタッフ一人ひとりに当てはめてみてください。それぞれが独自の定義を持ち、それを管理・統括する者が誰もいないのです。
ダッシュボードごとにデータモデルが異なる。作成者が異動すると、それを修正する人がいなくなってしまう。省庁間で、一見すると矛盾していないように見える定義が、実は密かに食い違っている。
それはもはや、単に数人の人間が素早く動いているように見えるだけではありません。誰も信用しないレポートやツール――数字が合わず、ダッシュボード同士の表示が食い違う――のように見えてくるのです。もしあなたが、そうした数字の責任を負わなければならない経営幹部であるなら、その代償はあなたに降りかかることになります。
これは建設に反対する議論ではない
私たちが何を言おうとしているのではないのか、その点を明確にしておきたいと思います。
「ペースを落とせ」と言っているわけではありません。「チームの開発を止めろ」と言っているわけでもありません。四半期も待たずに、週末のうちにダッシュボードをリリースし、数値を確認しながら、その過程で自信を深めていくこと――それこそが成功なのです。誰かのその取り組みを思いとどまらせようなどとは、決して思っていません。
その根底にある定義を誰も所有していない状態でシステムを構築することが、被害を招く原因なのです。AIがそのリスクを生み出したわけではありません。AIは、かつて誰かがまず疑問を投げかけることを余儀なくされていた、その最後の「摩擦」を取り除いただけなのです。
「The Fix」
- 適切な人材を一堂に集め、その言葉を「真実の源」に変えましょう。「アクティブなメンバー」とは何か？「関与している」とは何か？「献金」とは何か？各ミニストリーごとに異なる定義ではなく、一つの定義に合意し、誰もが確認できる場所にそれを明記しましょう。 これを「ミニストリー辞書」と呼びましょう。ダッシュボード、レポート、あるいはAIが構築したデータセットのすべてが準拠しなければならない、用語と定義をまとめた共通のリストです。そして、それを支える基礎的なデータビューとデータセットを構築し、Rock、スタッフ、AIのいずれを活用して構築を行う場合でも、誰もが正確な情報に基づいて作業できるようにします。
- トレーニングは、その重要度に見合った内容にしましょう。チーム全員がRockのマスタークラスを受講する必要はありませんが、数人は受講すべきです。なぜなら、チームが実際には存在しないギャップを前提に開発を進めてしまう前に、Rockで実際に何が可能かを把握しておく必要があるからです。 実際の課題は、Rockの知識ではなく、AIの習熟度にある場合もあります。Triumphが「AI Agentic Workflows Cohort」を運営しているのは、まさにそのためのものです。少人数のグループが、指導やレビューを受けながら、実際のワークフローを一つ一緒にこなしていくプログラムです。
- 単なる検証ではなく、理解をテストすること。 ジェフリー・リットはこの違いを明確に指摘している。検証とは「それが機能するか」を問うものであり、理解とは「その人がそれを説明でき、応用でき、次に誤りが生じた際にそれを察知できるか」を問うものである。正しく動作するものであっても、それを作成した人がその中に組み込まれた判断基準を説明できないのであれば、それを土台として構築するのは依然として安全とは言えない。
この手順を省略してしまうと、結局のところ、人々に混乱した状況を乗り切る方法を教え込むことになったり、誰も使い方がわからない基盤を彼らに手渡すことになってしまいます。
チームやエージェントにさらなるスピードを求める前に
まず一つ質問をしてみてください。「それを作った人は、単に動作したかどうかだけでなく、その仕組みについても説明できるでしょうか？」
ビルドは技術的に正確であっても、間違っている場合があります。なぜなら、「間違っている」とは必ずしも数値が不適切であることを意味するわけではないからです。時には、誰も合意していないだけで、実際には適切な数値である場合もあります。
建物作りはだんだん楽になってきた。そうなるのは当然だった。
自分が何の上に構築しているのかを理解することは、決して任意のことではありませんでした。ただ、それを無視するのが以前より簡単になってしまっただけです。