アルゴリズム人材が関われば、“魔法”は製品に変えられる　事例ベース・技術ベース・魔法ベースで見つける社内の課題

社内で課題を見つける方法1　事例ベースで考える

高橋直大氏：では、社内で課題を見つけるにはどうしたらいいのか。考え方には3つあります。「事例ベース」「技術をわかってもらう作戦」「諦めて魔法でもいいから挙げてもらう作戦」です。

仕事にかかわる人間自体が課題を見つけないと、どういう仕事をやっているのかがわからないし、いちいち聞いて回るのが大変なので、わかってもらわないといけない。だから、「どうやってエンジニアじゃない人からおもしろい課題を抽出するか」です。

一番簡単なのは、事例ベースです。協業他社がやっていることを、あの会社がやっているからうちもやろう、他社のやっていることは自社もできるからやろうという方法です。できることがわかっている分、確実性が高いし、需要があることもわかっているのでやりやすい。

しかしデメリットもたくさんあって、他社がやっているので今さらだし、最初にやったところは特許が取れるんですね。アルゴリズム自体に特許はないんですが、それを使ったサービスのやり方については特許が取れるので、そういうところはつらいです。

社内で課題を見つける方法2　技術ベースで考える

次は技術ベース。こういう関係のものはできるということを知ってもらって、「あなたの業務にこういう業務はありますか？」と考えてもらう作戦です。僕はこれに人工知能学会が提供している「AIマップ」を使用しています。着想となる技術をまんべんなく知ることができて、それがきれいにまとまっているんですよ。ライセンスされているので、きちんとライセンスが載っているように書かないといけませんが、部分的に貼りつけたものがあります。（スライドを指して）星と丸はまだ出てきませんが、項目ごとにカードになっています。

拡大します。例えば「予測・制御系」。左下の「数値予測」のほか、「確率予測」「運転・制御」「運転計画」「予測候補提示」というキーワードが書いてあります。

この場合、「なにか運転の計画をしているところはありますか？」と課題の人に聞くと、たぶん漠然とAIができることを考えるよりもはるかに出てきやすい。「確率を予測するものはありますか？」「運転や制御をやっているものはありますか？」「数値予測をしないといけないものはありますか？」「数値予測ができたらうれしいものはありますか？」と聞いていくわけです。

AIマップはいろいろなところにあります。ほかには「状態・推定系」。「これがどういう状態であるかを判定するものはありますか？」。状態が変わった、正常だったのに異常になった。異常検知は別ですね。「異常になったかどうかを検知しなければいけないものはありますか？　それはうまくいっていますか？」

「センサデータ認識」。「センサでこうなったと認識できたらうれしいものはありますか？」と、一つひとつ聞いていく感じです。ほかにも「認証」「指標化」「メディア認識」を聞いていくと出てきやすい。できればこれをいろいろな現場の人に聞いてもらって案を出してもらって課題を見つけていきたいですね。

さらに技術ベースに「分析・要約系」や「設計・デザイン系」があります。「数値データ分析」「言語データ分析」など、SNSからなにかする、要約をする。「配置・設計」「コーディネート」「スケジューリング」は、アルゴリズムの人たちがメチャクチャ得意な分野です。星はアルゴリズム人材がメチャクチャ得意で、丸はまあまあ得意なことを示しています。

（スライドを指して）この場合でも、「調停・参謀」「順番付け・選択」「パーソナライズ」について「なにかありますか？　なにかできるとうれしいものありますか？」と1つずつ聞いていく。ある程度あたりをつけるといいですが、ジャンルごとに分けて聞いてあげることで、「アルゴリズムが役立つものはありますか？」と意見を聞くよりはるかに集まります。

ただ、これはプログラミングコンテストの人すべてに適性があるわけではありません。機械学習はデータサイエンティストの人が得意だし、適切な人をアサインする必要があります。それだけを請けるという組織以外は、データサイエンティストや組み込み開発の人に、そういう感じでやってあげるといいのではないかと思っています。

社内で課題を見つける方法3　魔法ベースで語ってもらう

最後に、魔法ベース。これは「未来を語ってもらう」です。先ほどの虚空から肉まんを取り出す案は、言うと恥ずかしいと思いますが、多少恥ずかしくてもいいから未来にどうあるべきかを語る。50年後だとやり過ぎだから、10年後、20年後にどうなっていてほしいかを語ってもらうと、実はその中に今でもできるものがあるかもしれないし、「できるかできないかわかんないならやってみよう」ということができる。新しいものが出てくる。

こういう組織や仕組みをがんばって作っている企業はけっこうあると思うんですが、コンピューターでできそうなものを挙げてもらうのは当然として、今はできなそうだけど将来コンピューターでできるようになったらうれしいことを挙げてもらうといいと思います。今でもできるものがけっこう出てくるんです。

課題が見つかったあとは現場と技術者の歩み寄りが大事になる

では、課題が見つかったらどうするのか。課題の実態や技術で可能な範囲を擦り合わせて、案件として確定させていきます。現場と技術者の距離が遠いと案件が本当に進みません。IT分野から遠ければ遠いほど、双方が歩み寄らないとぜんぜん進まないんです。

歩み寄った結果、そもそもデジタルデータになくてデータを取るところからやらないといけなかったり、そもそも全体像や問題となるものを知っている人がいなかったりするので、それを聞くところから。「当初これを達成したいと言われていたけど、それが目的じゃなくね？」など、いろいろあるんです。

ただ、そういうものを少しずつ解消して課題にすることによって、おもしろい仕事ができるのではないかと思います。

アルゴリズム人材によって“魔法”が“製品”に変わる可能性がある

アルゴリズム人材の話に戻ります。（スライドを指して）これらができることです。「基礎的なアルゴリズムがわかっている」。30年前くらいというのはかなり怪しい表記ですが、これができたというレベルのものは、できるできないについてある程度の精度の回答ができます。

「最新のものまで全部詳しいわけではない」。アルゴリズムの中にも専門があるので、詳しい領域と詳しくない領域が存在しますが、正直30年前にできたかできないかを判定できるだけでもすごく価値があります。それだけ選別ができるので。

こういう人たちがうまくビジネス開発にかかわることで、魔法だと思っていたものが製品に変わる可能性がある。魔法だと思っていたものってたくさんありますよね。将棋AIだって、しばらくはコンピューターが（人を）超えることなんてないと思っていたのに超えちゃったわけですから。どんどん人間を超えるようになっています。

アルゴリズム人材が行うべき業務

（スライドを指して）アルゴリズム人材が行うべき業務は、このようなものだと思っています。顧客に対してヒアリングを行って、解決すべき課題を明確にする。これはITコンサル的な話で、最適化専門部署であればそういう案件にあたりましょう。

そして、要件を取捨選択して問題を整理します。アルゴリズムが活きなかったらほかの部署に託したり受けなかったりすることもあると思うし、扱いきれないものであれば、業務への影響が少ない範囲で要件を絞る。本当はここまで考えないと最適にならないけれど、考えなくてもそれなりにいいものができるというところまで絞る、取捨選択することはアリだと思います。部分的にアルゴリズムを導入し、部分的に人を残すこともあると思います。

その上で問題を整理したら、アルゴリズムを実装して課題を解きますが、解いたら終わりではありません。実際動かしてみたら、「ここが違う」とか「これでいいと思っていたけど実はダメだった」ということが出てくるので、「この評価を加えないとダメだ」「問題を解こう」を繰り返して、実際に動かしてよくなるまでアルゴリズムを書き換えて、現場で活用できるアルゴリズムにしていきます。

なぜ課題の見つけ方の話をしているのか。僕のようなアルゴリズム狂の考え方は基本的に、当然コンピューターでできることをやってもそんなに楽しくないんですよ。レベルが高ければ高いほど、難しくて奥深いものであればあるほど、課題として解くのがおもしろいと考えるのが上位の競技プログラマー、アルゴリズム人材だと思っています。

課題発見とアルゴリズム部門は会社によって異なる

課題が見つかるだけではダメで、案件としてきちんと整備しないといけない。ではどう組織を置くべきか、課題発見とアルゴリズム部門の接続について。これは会社によって違うので、みなさんがよいかたちを見つけてください。

「AtCoderJobs」というサイトをスクショしたものを貼って、実例をいくつか見せます。フューチャーはITコンサル企業ですが、AtCoderの人や競技プログラマーの人をたくさん雇っていて、いろいろな課題を解決しています。

ITコンサルとして、コンサルを受けるところから課題を自分で実装するところまで、上から下までやっている企業です。そういう企業でも外の会社に話を聞きに行って仕事を取ってAIで解決している。逆の観点から言えば、外注してもうまくいくところはうまくいきます。

よくあるのが、子会社モデルです。（スライドを指して）MC Digitalという企業です。三菱商事で出てきた課題や新規事業に対して、アルゴリズム案件を請けていて、子会社が親会社の問題を解決するケースもあります。

（「受注＋子会社モデル」のスライドを指して）正確かはわかりませんが、合わさったかたちとして、ALGO ARTISは上にDeNAがいます。たぶんDeNAが仕事を請けて、DeNAの中でアルゴリズム系の案件を集中して解くALGO ARTISという企業があります。スライドの下にすごいことが書いてあるんです。「ALGO ARTISはすべてのプロジェクトで焼きなましやビームサーチといったヒューリスティック最適化の技術を使用しています」。すべてのプロジェクトでアルゴリズムをやっているという異常事態です。DeNAが請けた仕事を適切に流しているから、こんな異常なことが起こっているのかなと思います。（「自社開発モデル」のスライドを指して）リクルートのように自社でやっているところもあります。