AI技術者と非技術者がうまくコミュニケーションを取るためのからくり(Advent Calendar Day 1)

I.序論

(1)はじめに

何もかもが変ってゆく時代なのだから、今度は僕たちが変らなければならぬ順序かもしれない。 『マルテの手記』 (著：リルケ、訳：大山定一、新潮文庫 1953年 P.165)

D2C データソリューション部のYです。本稿は、AI技術者と非AI技術者お互いがどのようなアクションをとればベストなコミュニケーションが取れそうなのか、筆者の各サイドでの実体験を元に考察したものです。(「アドベントカレンダー1日目からポエム?」は禁句)
特に、分析プロジェクトでコンサルタントとデータサイエンティストがタッグを組んだり、機械学習を用いたプロダクトをBizDev・AIエンジニア共同で改善したりといった現場担当者レベルのケースを想定して執筆しました。

以下の登場人物が出てきます。

• 技術者：ビジネスに対して機械学習関連技術の実装側面からコミットする人間
• 非技術者・ビジネスパーソン：ビジネスに対して事業開発的な側面からコミットする人間(技術を使っていない人間は本質的にいませんし技術者も当然ビジネスパーソンですが、技術者と比較できるように便宜的にこの呼称を用いています)

また、文中の例示は前職・現職の実体験をもとにしたものです。

(2)問題意識

分析プロジェクトで以下のような経験はありませんか？私はあります(N敗)。

• 特定のイシューについて議論をしたくて質問をしたところ、求めていない視点での内容が返ってくる
• 自身の技術/ビジネスへの理解が浅いせいでプロジェクトに対する解像度も低く、何が分からないのかが分からない
• 技術調査した結果について伝えようとしても大事な内容をうまく分かってもらえない

自分の悪かった点を振り返ると、これらは一定のパターンに沿って生じているような気がしてなりませんでした。それらを言語化して対応策を考えることで誰かの助けになるのではないだろうかと思い立ったのが本稿です。

II.本論

(1)うまくいかないパターン

心理学で有名なジョハリの窓を使い、コミュニケーションがうまくいかないパターンを整理してみましょう。

①技術者が持っているナレッジ・問題意識をうまくビジネスパーソンに伝えられず、必要な議論ができないパターン
=> いかに技術的なテーマを議論可能な形にわかりやすく落とし込むか(後述II-(2)に対応)

②ビジネスパーソンが持っているナレッジ・問題意識を技術者に伝えられず、必要な議論ができないパターン
=> いかにビジネステーマを議論可能な形にわかりやすく落とし込むか(後述II-(3)に対応)

③技術者・ビジネスパーソンともに状況が理解できておらず必要な議論ができていないパターン
=>　両者それぞれがそれぞれの得意領域に引っ張っていきいかに解像度を高めるか(まずは①・②の状態をつくる)

技術者・非技術者の違いは当人に与えられているジョブの違いであり、それすなわち普段無意識に好んでいる視点の持ち方や当人にいつもかかっている慣性力の違いでもあります。
その慣性に気づき対策を取っておければ、図表右上の領域の理想状態に限りなく近づけられるのではないでしょうか。
よって、ここからは技術者の視点とビジネスパーソンの視点それぞれに要素分解し、必要なアクションを考えてみましょう。

(2)技術者がうまくビジネスパーソンと話すためのススメ

技術をかみくだくこと、そしてビジネスの言語で喋ることの2点を推したいです。
自身が技術者の立場で他の方に説明を行う時、容易に起こりうるエラーは「自分の持っている・調査した技術的な内容が相手に伝わらないこと」や「ビジネスにとって重要な視点で語れていないこと」などかと思われます。
これらを防ぐためのアクションをみていきましょう。

(a)技術をかみくだく

1.比喩を活用する

比喩とは既知の事柄で未知の事柄をなぞらえ説明することです。
専門性の高いテーマを取り扱う場合、相手にとって馴染みやすい話に置き換えて話すことで議論の促進が期待できます。

例：コンサルタントから相関関係と因果関係の統計学的な違いの説明を求められた場面。「『風が吹いた時に桶屋が儲かっていることだけが分かっている状態』が相関関係、『風が吹いたことによって桶屋が儲かる、と明確に事柄に矢印が引ける状態』が因果関係だ」と回答し、テクニカルな定議論を回避しつつ必要なディスカッションを行うことができた。

例：RecallとPrecisionの説明を求められた際、それぞれを射的における「撃ち漏らしがないかどうか」と「どれだけ正確に射撃できたか」に喩えた。(自分の記事を紹介していくスタイル)

2.社内啓発にコミットする

技術を理解してもらう方法として、その場でわかりやすく伝えるだけでなく、そもそも技術(者)に関心をもってもらうためのカルチャーづくりにコミットするというのも有用な手段です。

当社データソリューション部では技術勉強会が毎週開催されていますが、その内容を社内広報でも周知したところ多くの反響がありました。

(b)ビジネス言語を話す

1.インパクトを狙いインパクトで語る

ビジネス上のインパクトベースで技術を語れる技術者の方はたいていものすごく重宝されます。
技術そのものではなく技術実装でどういう事業成果を生み出せるかがビジネスパーソンの(もとい誰でも本来あるべき)関心事ですから、それを意識した会話からは有用な議論を行うことができるでしょう。

例：施策分析を目的として機械学習モデルを構築しサービスの購入者分析を行った際、AUC(test)=0.70のモデルができた。期日内でこのAUCをもっと向上させてから解釈するべきなのか、現版を元に分析を行うべきかをクイックに議論するため、AUCが0.70/0.80/0.90だった場合の影響度合いを定量・定性両面から整理した。

2.頻出語を覚える

コミットするビジネスドメインでよく用いられる語彙を頭に入れ、技術的な事柄がどう紐づくのか仮説を持っておくことはプロジェクトアサイン直後などのタイミングで有用です。
例えば当社は広告を扱う事業を行っているので媒体やmROI(マーケティング上の費用対効果)に関連する指標は日々飛び交います。
「CVR予測モデルの精度評価指標が現状XxだからこれをYyに伸ばしたい」というテックに閉じた論調よりも、「CVR予測モデルの精度評価指標が現状XxでCVをYy件創出できているから、これを今後Zzにしていきたい」という話し方ができたほうが本質的な議論ができるでしょう。

(3)ビジネスパーソンが技術者とうまく話すためのススメ

技術者を巻き込むデザインの設計と、技術に対してキャッチアップをする方法を推したいです。
技術者と協働する場合、非技術者の方がPM的な立ち位置でプロジェクトをリードすることが多いのではないかと思います。その際、技術者の方に技術を技術単体でなくビジネスを推進させるツールとして考えてもらうこと、そのためのビジネスサイドの発信を行うこと、及び技術に対して議論に必要な程度の見識を持っておくことが必然的に求められます。

(a)巻き込みをデザインする

1.ストーリーで語る

ストーリーを語ることは技術的な実装とビジネスの推進をsyncさせる重要なツールです。
ビジネス上の目標をどのように達成したいかをストーリーA、技術実装(分析、ダッシュボード、モデルなど)の過程をBとした時、BはAの中でどのような位置づけか、AB双方が乖離するリスクはどこにありそうか、などを意識した会話ができると技術者をうまく巻き込むことができます。

例：コンサルタントとしてデータサイエンティストとともに分析プロジェクトの手法検討を行った。クライアントの課題と分析によってそれをどう解決するのかのイメージを先に描き、そのストーリー実現に有用な手法を調査してもらうことで、短期間でのアプローチ選定を行うことができた。

例：クライアント向けにダッシュボードを構築した際、ある図表がクライアントにとってどのようなメリットがあり、そこから得られる示唆によってどのような分析提案が可能になるかを議論しきってから実装した。結果、実装者とコンサルタントとの間に認識齟齬がなく納品を行うことができ、クライアントからも好評をいただくことができた。

(b)技術を理解する

1.インデックスを狙いインデックスで語る

これは、インデックス(目次)すなわち技術がどのような要素から構成されていて、それぞれの要素が全体の構造のどこに位置づけられるのかに絞って学習を図る方法で、いわゆるパラシュート勉強法を少しアレンジしたものです。
数式やソースコードレベルの話をいきなり理解しようとすると難しいことが多いと思われますが、まずインデックスの理解に努めると必要以上に深入りする必要なく、スピーディな知識習得が可能です。

例：因果推論を扱う分析PJにアサインされ、アプローチ選定のため1からのキャッチアップを要求された。概ねどの手法も(1)TG(処置群)とCG(対照群)の比較と処置効果の算出というモチベーションがあり (2)時系列的なデータとしてみるか静的なデータとしてみるかで大きくアプローチが分岐しそうで(3)他の機械学習モデルと同じような精度評価の仕方ができることをキャッチアップし、アプローチ比較のための論点をそれらにあてがって整理することができた。

2.勉強会を開く・開いてもらう

そんなことかよ！というツッコミが飛んできそうですが、実際問題としてビジネスサイドから技術サイドに対してアラートを上げ、解像度を高めたいテーマを伝えてまとまった時間で技術的な内容を教えてもらうというのは有用なアプローチです。
特に、プロジェクトのメンバーが多くリテラシーに差が生じている場合、社内のハイレイヤーを巻き込んでいるプロジェクトで週次MTG内では技術観点での発信をできていない場合などで効果が大きいように見受けられます。

III.おわりに

LLMの台頭に我々の業務はどう適応していくべきか、一技術者としてヒヤヒヤしつつワクワクしつつですが、
周りの人をどう巻き込み技術とビジネスとをどうsyncさせるかといったソフトスキルはまだまだこれからも人間の持ち物にしていけるのではと感じております。
拙稿がささやかながら誰かの一助になればと思います。

当社はアドベントカレンダーの真っ最中であり、新しい記事が続々投稿される予定ですので、
ぜひD2C m-techアカウントのフォローを宜しくお願い致します！

また、D2Cグループではデータサイエンティスト、エンジニアの方々を募集しています。
ブログを読んでD2Cで働いてみたいと思った方、D2Cの業務に興味をもってくださった方がいらっしゃいましたら是非ご応募ください！
▼ D2Cグループ採用サイトはこちら
https://recruit.d2c.co.jp/

▼ D2C問い合わせフォームはこちら
https://www.d2c.co.jp/inquiryform/

引用・参考文献

• マルテの手記(著：リルケ、訳：大山定一、新潮文庫 1953年 P.165)
• 三行で撃つ(著：近藤康太郎、CCCメディアハウス 2020年)
• 「超」勉強法(著：野口悠紀雄、講談社 1995年)
• アナロジー思考(著：細谷功、東洋経済新報社 2011年)
• ロジカル・シンキング(著：照屋華子・岡田恵子、東洋経済新報社、2001年)
• ストーリーテリングのリーダーシップ(著：ステファン・デニング、監訳：高橋正泰・高井俊次、白桃書房 2012年)