問題解決プロセスについて書かれた書籍が出版される一方で、身の回りの未解決問題は年々増えていると感じます。私は AWS の Developer Relations として機械学習に関わる仕事をしており、 80% に登る機械学習プロジェクトの失敗確率はまだ解決されない問題です。生成 AI をはじめとした先進的技術も登場しているにもかかわらず、それらが軽やかに問題解決する場面を目にしたことがまだありません。なぜなのか ? を本記事で考察します。

数冊の書籍と自分自身の経験から、問題解決プロセスが機能しない理由について仮説を立てました。問題解決プロセスをソフトウェアと見立て、ソフトウェアを実行するのランタイムの問題が根本原因と考えています。つまり、私たちは「どんなプロセスでやるか」と同じくらい、あるいはそれ以上に「どんなチームでやるか」を議論する必要があるということです。

本記事はドラフトであり、まだデータポイントは十分でありません。私自身の体験のバイアスが入る箇所もあるでしょう。ただ、アジャイルやデザイン思考など様々なプロセスが会社内で広まってはいまいち効果が出ない、さらに生成 AI といった新しい技術がなかなか会社で浸透しないという方にとって解決策のヒントになれば幸いです。

問題解決プロセスはなぜ問題を解決しないか ? 

問題解決に取り組む担当者の影響力が無限という前提を置いているから、と考えています。例えば経理の担当者が誤りがある経理精算の訂正に時間がかかり頭を悩ませているとします。「完全無欠の問題解決プロセス」によれば問題解決のプロセスは次のように定義されています。

1. 意思決定者のニーズを満たすため、問題を的確に定義する

2. 問題を分解し、検討すべき仮説を立てる

3. やるべきこと、やるべきでないことの優先順位をつける

4. 作業計画を策定する

5. 認知バイアスを避けながら事実収集と分析を進める

6. 洞察を引き出す調査結果を統合する

7. 意思決定者に説得力ある形で伝える

このプロセスは暗黙的に「意思決定者への提案」を想定しています。意思決定者は誰でしょう ? 経理部の部長なのか、経理システムの開発をした IT 部門なのか、はたまた入力をミスしている業務部門の部長なのか。これらを見定めるにはデータ分析が欠かせませんが、明細データへのアクセス権限や業務部門へのヒアリングには何らかの承認が必要でしょう。そうした承認を得る、意思決定者に提案するのが一担当者に可能でしょうか。

他の書籍のアプローチも、問題を定義しロジックツリーで分解し優先度をつけて仕留めていくのが基本的なアプローチと思います。これらには組織横断のデータアクセスや連携権限が不可欠であり、それが許容されないと根本原因の特定と解決は困難です。

つまり、汎用的な問題解決プロセスは暗黙に 1) 意思決定者に提案するための組織横断的なイニシアティブの作成がいつでも許容される 2) 1 からの提案を受ける・実施するプロセスが整備されている 3) 1 に対し組織横断的なデータアクセスや実験を行う権限が付与される、の 3 点を前提にしています。この前提が満たされないチームや組織では問題は解決されないでしょう。

問題解決に重要なのはプロセスかチームか。この比較として興味深いケースを挙げます。上述の「完全無欠の問題解決プロセス」では第 6 章でスペースシャトルのチャレンジャー号が爆発した事故を題材に、ベイズ統計を用いれば原因となった O シリング不具合による打ち上げ失敗リスクを予測できた = 事故を防止できたと説いています。

一方で「チームが機能するとはどういうことか」では類似したコロンビア号の事故が取り上げられています。断熱材の問題に気づいたエンジニアが報告の上申をあきらめてしまったことで着陸時に事故が起き宇宙飛行士 7 名全員が命を落とした事故です。原因として、チームの心理的安全性が意思決定に与えた影響を論じています。

ここで、打ち上げ失敗リスクを予測できたとするチャレンジャー号の事故では原因になった O シリングに欠陥があること、打ち上げ当日の低温下では事故のリスクがあることをエンジニアチームは知っていた事実があります。真の原因はどちらにあるでしょうか。

機械学習プロジェクトの 80% が失敗すると冒頭で紹介しましたがこの原因はビジネス目標が不明瞭であることやチームの連携が不十分であることです。 さらに、デザイン思考を世界に広めたデザイン会社 IDEO がレイオフを発表したのは、 (IDEO の意図は別として ) プロセス偏重のアプローチに限界があることを示唆していると感じます。

私は問題解決プロセスを開始する前にチームの組成が必要不可欠であり、そのためにワークショップが有効であると感じています。次のセクションでその理由を述べます。

境界を越えたチームの組成がなぜ必要なのか ?

シンプルに問題を解決するためです。先ほどの経費精算の入力ミスを減らす単純な問題一つとっても、システムを開発する IT 部門、入力を行う業務部門が関わります。企業が価値を創出するまでのプロセスをバリューチェーンと呼び、各活動のつながりを見ると発生した問題の影響が後続プロセスに影響することは明らかです。

エンジニアやデータサイエンティストとして注目すべき点は、「技術開発」が全社横断の活動として定義されていることです。あらゆる部署がシステムを使用しデータウェアハウスに活動履歴が蓄積する中でデータとシステムが問題解決に果たす役割は大きく、様々な部署との連携が必然となります。
ユーザーストーリーマッピングや Event Storming といった手法がストーリーを基軸にした「共通理解」を重視しているのは、問題を解決するために境界を越えたステークホルダー間での共通理解が不可欠だからと推察します。

注意すべき点は、境界を超えるのは難しいという点、超え続けるのも難しい点です。「チームが機能するとはどういうことか」では知識の境界が組織・職業・またその組み合わせによって発生するとしています。組織内あるいは職業の専門知識に基づく文化やプロセス、暗黙知がコミュニケーションを難しくするということです。さらに、仕事を円滑に進めるためには介入が少ない方が良いので、私たちは関係するステークホルダーの数を一定以上にしない傾向があるのではないかと考えています (Event Storming の書籍ではこの閉じられた関係 / 御むプロセスをサイロと呼んでいます ) 。先のコロンビア号の事件では「エンジニア仲間内では」断熱材の問題が共有されていたことがわかっています。

ワークショップの有効性と課題は何か ?

境界を超えるきっかけとして有効である反面、形骸化と持続性に課題があります。特定の目的に関係したメンバーを集めたワークショップは、自己組織化を促しメンバー間での目標・情報の共有、ワークを通じて仕事の仕方 = ルールを確認できる点で有効です。先に挙げた Event Storming などの手法は、特定の問題をうまく解決することを目標に、関係者を一つの部屋 / ホワイトボードの前に集め、情報共有しながらルールに沿いソフトウェアを設計していく手法です。

自己組織化・目的・情報の共有・ルールは境界の内に閉じたがる特性へ介入するのに有効なアプローチです。これらは「世界はシステムで動く」で述べられているシステムの中で介入すべきレバレッジポイントの一部です。

この書籍は↑の書影にある通り、問題の背景にある多様なシステムを理解し介入するのに有効なシステム思考という考えを解説している書籍です ( システム思考の詳細は割愛します。関心ある方は読んでみてください ) 。

「チームが機能するとはどういうことか」においても、境界を越えたチームを組成するために「上位の共通目標を設定する」「関心を持つ」「プロセスの指針を示す」を挙げており概ね共通した指針を提示しています。さらに、自己組織化・目標・情報の共有・ルールという 4 つのポイントのうち 3 つは冒頭挙げた問題解決プロセスが機能する 3 つの前提に対応します。  1) 自己組織化 : 意思決定者に提案するための関係部署数名から成る組織横断的なイニシアティブの作成をいつでも許容する 2) ルール : 1 からの提案を受ける・実施するプロセスが整備されている 3) 情報の流れ : 1 に対し組織横断的なデータアクセスや実験を行う権限を付与する、です。目標は少なくとも関係する複数のステークホルダーが共有できるスコープで定められている必要があります。

一方で、ワークショップは単発のため持続性に課題があります。学校や会社で行ったワークショップで知り合った人にそのあと連絡を取ったことがある方はいるでしょうか ? 個人的にワークショップで使った模造紙が処分される確率は 90% を超えると見ています。

また、ワークショップ自体がプロセスでもあるため形骸化しやすい難点があります。学校や会社で実施したワークショップを適当に流してしまったことがある方は結構多いのではないかと思います。特に時間内のアウトプットを求められた場合その傾向は顕著になります ( 特定テーマについてまとめた意見を発表するなど ) 。「ワークショップデザイン論」では「創るための構成」と「学ぶための構成」の 2 つを提案しており、問題解決の前提となるチームを組成するには境界を超えるメリットと方法を「学ぶ」ことを重視する必要があります。

持続性と形骸化をワークショップあるいは他の手法で解決できれば問題解決がより進むと言えます。

問題解決プロセスを機能させるために

日常的にワークショップを活用することが持続性と形骸化の解決に役立つと考えています。普段の業務の一部となってしまえば形骸化せず自然と持続するためです。私が読んだ書籍ではワークショップをアトラクションのように 1 回でいかに成功させるかが主軸にされていましたが、そうした形態だけでなく 1on1 のように頻度高くかつ気軽に境界を超える場を誰でも作れることがチームの組成に不可欠ではないかと考えています。

例えば、 AWS の ML Enablement Workshop は全三回で計 10 時間ほどかかります。 Kick-off として実施するのは良いですが、何回もという感じで使うのは難しいです。最初の理解編を切り出した 2 時間程度のコミュニティ版は、何回か勉強会形式で開催しており満足度 5 段階中 4.6 、他の人にお勧めしたい度合は 4.3 と高評価を頂き vol1 、vol2 に続き第三回を先日開催しました。

参加者から「自分の会社でも開催してみたい」という声も得られ、テーマを絞り軽量・簡略化することは自己組織化を促進し日常化するために必要と考えています。全 3 パートがそれぞれ独立し短時間で実施できれば、状況に合わせて適切なワークショップが実施できます。フルコース料理から単品料理にして平日のランチでも食べれるようにするイメージです。

この解決策はまだ仮説の段階ですが、 ML Enablement Workshop はこの方向で改良を検討していこうと思います。

コミュニティでの開催も、単発ではなく実際にチームを組成し最終的な課題解決 = プロダクトでの機能リリースにつなげるような活動ができないか検討中です。勉強会というとエンジニアはエンジニア、デザイナーはデザイナーにそれぞれ一人で参加というイメージですが、それでは境界を超える経験を得ることはできないと思います。チームメンバー丸ごと参加の勉強会や、継続的に参加 / 知見をえられる場を作ることが本質的な問題解決につながるのではないかと考えています。

問題解決プロセス自体は生成 AI に聞けばサラッと教えてくれる時代です。ただそれを機能させるチームの組成はまだまだ人間の仕事と感じています。チームの組成さえうまくいけばあとはプロセスのレールに乗せられるとしたら、非常にレバレッジの利くアプローチでありポテンシャルは高いと思います。 AWS としてはもちろん、コミュニティでの活動は直近イベントを共催した PM DAO と AWS Startup Community 、そして溶け込むラジオメンバーとあれこれ検討していますので関心ある方はお好きなコミュニティから連絡いただければと思います！