ビジネス側に技術を身近に感じてもらうには？ 〜技術とビジネスの共創のOK/NG例〜

こちらはABEJA Advent Calendarの２４日目の記事です。

はじめに

こんにちは。ABEJAで事業部のディレクターを務めています@ryusakumaです。

• 「技術進歩はコロナで大変な中でも、変わらず進むなあ」
• 「でも、肝心の、お金を握る意思決定者の技術への関心・理解はまだまだだなあ」

と思っていたりする方向けに、機械学習/深層学習（以下、ML/DL）の活用現場の生々しい体験をもとに、何かヒントとなる情報をお届けしようと筆をとりました。

こんな方が想定読者

• ビジネス側が今よりも技術を理解すれば技術の社会実装は進むのに、とお考えのエンジニアの方
• そう言われても、情報は世の中に溢れすぎていてどこから理解すればいいかわからない。誰か教えて、というビジネス側の方
• とにかくゆたかな世界を実装したい方々

こんな話です

お題に対し、小難しく考えず、単純に、ビジネスの人がもっと技術を「面白い」と思えれば良いのでは？

と仮説を立てました。
なぜなら、現に、今記事を書いている私の目の前では

• リサーチャーがプロジェクトマネジャーと一緒に最強の営業をしている
• コンサルタントのPythonコーディングを、エンジニアがペアプロしながら高速化している
• BQのCLIでの操作方法を人事部の人が人事データの解析したいからと学んでいる
• **機械学習エンジニア兼弁護士（敢えてぼかして、この記事の人とかこの記事の人）**がド文系（注：私）にE資格の勉強法を教えている

エンジニアとノンエンジニアが互いにリスペクトしながら、まさに技術とビジネスの境目などなく普通に仕事をしているのです。（4つ目だけ仕事じゃないけれど）

一朝一夕でこの環境ができた訳ではない。少々手前味噌ですが、リアルな体験から何か皆様のヒントになる（と良いな）と思うことをNGな例、OKな例、最高な例でお伝えします。

書いている人

• レガシーなシステム構築経験あり（ERPパッケージ導入屋さん。ただしアプリ側）
• 戦略コンサルタントでもあった。無駄に社会人歴は長い
• ML/DLには2年前まで直接触れたことはなかった
• Qiita初投稿（ドキドキ）

OK/NG例

1. ある程度分かっていそうなビジネス側

ビジネス側にも色々いるので、一概に言えないのですが議論の単純化のため図にしました。

• 縦軸のWHY：なぜその技術を使う必要があるのか？：わかる
• 横軸のWHAT：どのような技術があるのか？：わからない
  という方をまずは対象と想定して話します（何を隠そうML/DL領域における私がそれでした）。

1-1. NG例：Not readyな人への勿体無いアドバイス

そんな私が入社して3ヶ月くらいのある日のことです。我が社が誇るスーパーPOであるKくんが夜、いつもの通り一人で大きなディスプレイに向かって黙々と作業をしていました。

売上予測の作成に疲れた私は休憩がてら、話しかけても大丈夫ムードな彼に近づきました。

私「Machine LearningやDeep Learningの中身をもっと理解するには何をしたらいいの？」

Kくん「UbuntuやDjangoあたりでいいんじゃないですか」

私「？？？」（とりあえずググるか・・・）

深い考えなしに聞いたことではありましたが、エンジニア経験皆無すぎて、初めての単語にリアクションしきれずその場は終わりました。一回ググって、「うん、よく分からない」、となって、その後しばらくこの単語たちに会うこともありませんでした

今思い返すと、環境構築したかった訳でもMLのWebアプリを作りたかった訳でもないんだよ、初心者ながらちょっと触りを知りたかっただけなんだよ、Kくぅん、と言えるのですが・・・

彼の立場を想像すると、私が上の四象限のうちどこの人かも知らず（夜遅い時にご飯食べる仲ではありましたが、直接仕事をしてはいなかった）、少し技術の分かる奴なのだろうと思い親切心で教えてくれたのではないか、と想像します。

だから、「私はPythonの基本文法はわかるけれど、ゼロつく片手にJupyter notebookでDLのお手本コードを書くくらいしかできない。XXのタスクを解くためにYYなモデルをそれっぽく作ってみたいんだけれど、どうすればいい？」、と自分が何が分かっててどこまでできるのか、そしてこれから何を実現したいのか、を的確に話せる状態だったら役に立つはずのアドバイスでした。当時は全然無理でしたけれど。

つまり、エンジニアが親切心を発揮してくれても、ビジネス側の状態がReadyでなければ完全に豚に真珠ということです。（しつこいんですが、Kくんが悪い訳じゃないですよ、私が何も考えずに聞いたせいです、ごめんなさい）

1-2. OKな例：ビジネスと技術の交流機会

上記と同じくらいの頃に会社の有志のイベントでハッカソンが実施されたことがありました。

事前にビジネスと技術のミックスになるよう班わけがされていて、

「ウチも社員が増えてきた。人が多くなってコミュニケーション不足が生じることもある。というか、人の名前と顔が一致しない！どのように解決するか？」

のようなお題に対し、各チームが創意工夫をしてソリューションを発表せよというものでした。

結構前の話なので詳細は割愛しますが、（ご興味ある方はこちら）

• 人と人を敢えてランダムにマッチングさせてご飯食べに行くところを推進するアプリ
• 覚えられない新入社員の名前をリマインドしてくれるアプリ

などデモもありの本物っぽいLTもありのバラエティに富んだ発表で、普通に楽しめました。
テクノプレナーなOさんを始めとする主催側の様々な努力も素晴らしかったですね。特に以下：

ハッカソン初心者へのガイド

これも思い返すと、

• 高速でコーディングし、すぐ動くものが作れちゃう方
• ロゴデザインを含めブランディングを本気で考える方
• 本物っぽいデモを製作できちゃう方

など普段の仕事の延長では見えにくい、お互いのスキルの生々しい凄さを凝縮した形で感じることができました。

遊び心（会社の代表的なスライドをコラージュしちゃう）

カジュアルさも手伝って、ビジネス側から見れば、技術に対して距離が縮まるような取り組みだったと思います。
誰某さんはどんな凄いことができる、いわゆるKnow-Whoを理解できることは、その後のディスカッション機会にも繋がり素晴らしいことなのですが、さらに共創を促進するためもう一歩進めないでしょうか。

何か、こう、ビジネス側が自分から技術を触ったり使ってみたくなるような施策もあるのでは？

1-3. 最高な例：自分にも真似できるのでは？と思わせる

断っておくと、この成果は仕掛けを作った方、弊社が誇るリサーチャーのFさんのものであって、私は単にその恩恵を受けた人です。

題材："ABEJA Platform Models"を使ったML/DL

よく使われるML/DLタスクをビジネス側がデモや簡易的なデータのアセスメントができるようにしたツール群です。（デプロイメントにはABEJA Platformを使います）

手前味噌で恐縮ですが、これを改めて社内で紹介してもらって、「私もやってみよう〜！」となった話をします。

タイルからタスクを選ぶ：Pose Estimationにしよう

以下簡単な流れです。細かいところはサクサク飛ばしていただいて結構です。

• 学習済みパラメータを備えた標準モデル達が並んでいます。
• ただし、自分でモデルをスタートし、デプロイしてあげる必要があります。
• 私は自分のポーズ推定がしたかったので、 Pose Estimationを選択しました。（画面には全部映ってませんが、現時点で１６種類）

デプロイ

Organizationという、自プロジェクトを動かすところへ新しくデプロイメントを立てます。

その後、ABEJA Platformに入りまして、デプロイメントができていることを確認。

ここからHTTPサービスを作ります。
(実はここで詰まっていて、そもそもデプロイがよく分かっていなかった。FさんにSlackで質問の嵐）

モデルを動かす

HTTPサービスが使用可能になったので、エンドポイントに記載のURLを呼び出せばモデルが動きます！
（ここでもまた詰まり、動作させるためのコード内でURLやユーザーIDやパーソナルアクセストークンを記載するあたりをFさんに教えてもらう体たらく）

*以下JupyterのスクショからはユーザーID、パーソナルアクセストークンの部分は除外してます

当時はPythonの文法も全然分かっていなくて、ただインプットするJPGの場所、結果を吐き出す場所だけ書き換えれば大丈夫なコードを用意いただきました。

インプット (IMG_6084.JPG)

アウトプット (Output7.jpg)

うん、見事にポーズ推定できてます。（全然仕事に関係ないんですが）

自己満足してる場合じゃないですね、失礼しました。ポーズ推定ができたこと自体は本質ではなくて、このようにビジネス側の人間に何か手を動かして、ほぼ期待通りの推論が自分でできた（実際は私はほとんど何もしてないのですが）、と思わせたところにミソがあったな、と思います。

動線としては、

• 一見簡単そう！→解く問題がシンプル（ABEJA Platform Modelsはタイルでできることを明示）
• 少し教えてもらいながらならできるはず！ →いつでも聞ける雰囲気（FさんはSlackでいつでも聞いてね！と寛容）
• きっと仕事に役にたつ！ →ただのデモではなく、自分の画像で、自分のタイミングで動かせる（ようにFさんはサンプルコードを用意）

これを皮切りに、どうなっているんだろう？と興味が溢れていくという構図です。さすがですFさん。

• 今回はたまたま弊社の製品・ツールを題材にさせてもらいましたが、「自分ゴト」化してもらうようにするのがポイントですね。
• 個人的な肝は、広く一般公開するようなハンズオンで作り出しにくいのが、他でも使える！持ち帰ってあとで色々試せる！のところですね（上記例は自社サービスなのでいつでも触れるというチート・・・）

2. あんまり分かっていないビジネス側

次の対象者です。ここでは

• 縦軸のWHY：わからない　（とにかくDXしなくては！AI活用だ！）
• 横軸のWHAT：わからない

という方が対象になります。今度は私自身の話ではなく、プロジェクトや事業の最終意思決定を行うような方々、失礼ながら冒頭に述べた「カネを持っている方」の中で、いまだに旧態依然とした意思決定ラインにいらっしゃる方が対象になります。
つまり、私が過去相対していた方々の話。

2-1. NG例：効果だけを根拠にとにかく模倣する（させる）

• 昔話になってしまうのですがERPパッケージの導入での失敗です。

• 本来ERPパッケージは言葉の通りEnterprise Resourse Planningを実現するツールなので、企業の資源を最適に配分するために、自社内のヒト・モノ・カネ（敢えてここでは古い言い方を踏襲します）に関わるデータを可視化することが目的です。

• ベストプラクティスと言われる業務機能を備えたパッケージを持ってきて、企業内のどの拠点でも、事業部でも、部門でも同じような形で経営層に情報が届くように業務を標準化することが第一優先です。

• 導入にあたっては、今の業務に対して、ERPパッケージの機能のカバー範囲を重ね合わせることになります。
  
  　　　　　　　　　　　　　　　　 ↓
  

• すると、企業にとって競争優位性のある部分、固有な業務機能がどうしても出るので、そうしたところはやむなくカスタマイズ（追加開発）し、一方でパッケージに合わせられるところは極力合わせることで業務の改革を実現するものです。（太線が導入後の業務）
  

• ところが、一部の間違った考えの企業経営者はこのように考えました。

  • 「ERPパッケージで米国企業はベストプラクティスを用いて業務改革が進んでいるらしい！」
  • 「すごい！では我々も導入だ！」
  • 「導入の仕方は現場に任せる！」

• 結果、下図のようになります。
  

  • 今のシステムの利便性を享受している現場部門がそれを捨てたくないあまりカスタムメイド開発、業務は一切改革されない
  • 標準機能をフル活用してデータの共通化をはかり経営の意思決定に役立てるどころか
  • データのありかも分からず、活用方法も分からない
  • （→あとで気づき、本来の目的に立ち戻って標準化・共通化プロジェクトを必死に実施する）

• という憂き目に会いました。（もちろん例外の企業もいらっしゃると思いますがここでは敢えて誇張しています）

• 日本企業におけるERP導入の大きな教訓として、盲目的に技術導入することはせず、そのコンセプトを理解した上で適切に投資せよ、技術側としては、盲目にさせないような説明が重要、ということになります。

2-2. OKな例：アナロジーを活用しコンセプトを伝える

では、表面的な効果だけを伝えてしまうことや、いたずらに模倣をすることを避けるにはどうするのか？

非常に根が深い問題です。

振り返りますと、入り口部分では結構アナロジーが効いていたなと思います。

アナロジーの例

• ML/DLを子供に喩える

  • いわゆるAIは子供みたいなものなので、生まれてすぐに賢くはなりません。（時間軸）
  • 教え込む経験（データ）により判断できることや程度が変わリます。（不確実性）
  • その教え込む期間はとても時間がかかりますし、そこで大半の時間を使います。（前処理の大変さ）
  • 大人がいないと日常生活は危ないのと同様、人が介在しなくてはリアルな業務で使えないことがほとんどです。（運用移行への困難さ）
    

• 現実に、某小売業のお客様でPoCを実施する前に役員の方含めて講演を設けさせていただきました。

  • こうしたことを切々と説いた結果、モデルの精度自体の問題に拘泥せず、**「どのようにしたら運用に持っていけるか、一緒に考えましょう」**というスタンスになってくださいました！

• 時間軸や不確実性、前処理の大変さや運用移行の話も、アナロジーを通すことでしやすくなります。

アナロジーにはマイナス面も

• 一方で、細谷功氏のアナロジー思考にもあるように、表面的類似と構造的類似がある中で、本当のアナロジーは構造的にも似ている必要があるので、思いつきで安易に喩えを出さないように注意が必要です。
  • 「AIと子供が似ているってことは、非行に走ったり（暴走したり）するんですか？」のような問答はしたことはないですが（笑）
  • あくまで、「技術のこういう利点や限界を伝えたい」という範囲で使うのが吉だと思います。
• 入り口がクリアできたな、と思われる方には引き続き相違点も含めた詳細なフォローが必要です。
  • 「AIと子供が似てると言いましたが、（うまく学習できれば）大人以上の精度になることもあります」
  • 「人間の子供はある程度ライフプランを考えて長期の投資など考えられます、AIはどちらかというとベンチャー投資的な発想です。撤退もありえます」

リアルオプション的な発想

意思決定する方が、「なんか分かった気になる」ことがここでも重要なのです。人間、分からないものは不安です、誰かに任せたくなります。

自分が分かるものは興味を持って介入します。そうすれば、現場に丸投げすることを少しでも防ぐことができるのではないでしょうか。

ただ、これだけでは不十分です。最後は、やはり地道な対応が求められます。

2-3. 最高な例：人別に対策を取る（丁寧に説明する）

• 当たり前の話ですみません。
• 時間と手前をかけて情報収集をし、その方の背景や興味、人となりに合わせてもっともハマる文脈で話しましょう。
• 私が数百社と相対してきた経験も踏まえポイントを列挙します。（コンサルタントとしてのセールス術になってしまうのでポイントのみです。エピソード系は別の媒体や機会に譲りますmm）

事前情報収集

• 企業情報は言わずもがな（有価証券報告書、企業Website、業界情報を提供するニュースソース）
  • ベンチャーとの提携を最近始めたとか
  • 新しめな事業やサービスのプレスリリースがあったかとか
  • 特許情報でその企業の特許探す（結構眺めてるだけで面白くて終わるので注意ですね）
• お客様自身の背景情報を徹底収集（その方の外部発信、SNS、株主の方や役員など経営者人脈などから）
  • 著名な方なら、対談とか取材記事があるとベスト
  • 偉い方なら、有価証券報告書の後半にも載っているキャリアパスとかも
  • （聞ける関係なら）アポイント前に課題、気になっていることを聞いちゃう

伝え方・話し方：タイプ別対応

• ここはめちゃくちゃ主観です。プロファイリングを学んできた訳でもないので、面白半分で読んでください。

  • 技術懐疑派

    • ML/DLの例だと、「AIはコストばかり食う割に精度でないのでしょう？」と言われることも
    • そういうケースもありましたが実はすでに我々の生活の中ですでに使われているんですよ、をマイルドに伝える
      • ご存知ECサイトでのレコメンデーション
      • クレジットカードの不正検知
      • スマートスピーカー
      • 小売店での属性分析

  • 興味あるが今更イチから学ぶのは無理

    • ML/DLの例だと、「AIの仕組みも分からないしプログラミングなんてとんでもない」

      • いや、必要ないです。プログラミング自体ができることと意思決定の質は比例しません
      • 大事なのは、日進月歩の技術にちょっとでもアンテナを貼ること
      • AI ScholarとかAI NOWとか眺めていただくだけでも
      • 「どの技術で何をする」のが技術難易度が高いのかを知っておいていただきたい。　R&Dとしてカネをめちゃくちゃかければできることなのか、ビジネス実装することのできるコストに収まりそうなものか
        

      技術的難易度を大雑把に書くと
      

  • もう私はよく知ってるんで

    • ML/DLの例だと、「情報システム部門経験長いので、わかります。ウチの会社はデータがたくさんある」
      • システム開発とDXの違いから説明する
      • 企業の基幹システムとML/DLで必要なデータの幅や傾向を説明する

などなど、パーソナライズを考えるとキリがないですね。これくらいにしておきます。

まとめにかえて

最後までお読みいただいた方、誠にありがとうございます！ビジネス側の私の視点からだと、結局技術を身近に感じる（感じさせる）には、**「相手のいる象限に応じて対応を変えるべき」**という単純な結論なのですが、如何でしたでしょうか。

ここでの対処法はあくまで浅薄な私の知識と経験に基づいた一例ですし、当然万能ではありません。

私自身は、自分自身もそうだったし、これから出会う新しい技術に対しては常にこうした問題が起りうるものだと意識してはいながらも、現実には自分や相手がどの象限にいるのかがすぐには分からず、結構苦労することもいまだにあります。

よろしければ、相手の技術理解をどんな風に見極めて、どんな風に促進しているのか、ご意見をお寄せいただけたら幸いです。

また、技術とビジネスが良い感じに交わり、日々共創に励んでいる現場は良いな〜と思った方はこちら（採用ページ）へお越しください！