この記事はnoteに投稿した『「AIの民主化」時代のキャリア形成、「AIブームの終焉」以降の企業内研究開』を加筆修正した内容になります。

問題設定:「AIの民主化」時代以降は、どのような人材が求められるのか

AIの民主化」は、「AIブームの終焉」と共に語られる終着点の一種でした。「AIの民主化」の時代を特徴付けているのは、何よりも、「誰もが一定程度はAIを扱える」という大衆化された状態です。「AIの民主化」以降、もはや「AI」についての専門知識には、希少価値が伴わなくなります。

尤も、これは必ずしも悲観的な状況ではありません。「AIの民主化」の時代がその専門知識の希少価値を否定していくという事態は、言うなればAIの「オーラ(aura)」が喪われたことを意味します。

例えば「最前線」を語る大手IT企業が大学の権威と提携したというプレスリリースも、「AI」関係のスタートアップ企業が多額の資金調達を実現したといった報道も、「AI」を活用した新サービスを大々的に取り上げているオウンドメディアの宣伝も、もはや注視して仰ぎ見る必要が無くなったということです。「AIブームの終焉」後の時代を生きる我々は、「AI」という概念を冷徹に分析する機会を獲得しました。

「AIの民主化」に対する批判的な意識は必要ありません。冷静に、よく周りを見渡してみましょう。スマートフォン、SNS、IoT、家電、監視システム、自動運転、そして金融・証券市場におけるアルゴリズム取引や株価のボラティリティ推論など、様々なテクノロジーや分析ツールが、「AI」のアルゴリズムと結合し始めています。

今や「AI」は、何処か独得な雰囲気を有した特別な存在でもなければ、手の届かない場所にある憧れの対象でもありません。「AI」は、我々の生活する世界に踏み込んで来ています。この事態は、「AIブームの終焉」が、逆に「AI」に習熟せざるを得ない状況を形成していることを意味しています

実際、プログラマ、エンジニア、そしてアーキテクトと呼ばれている人々は、既にこの状況に直面しています。AutoMLや種々の機械学習ライブラリは、「深層学習(Deep Learning)」という呼び名で慣れ親しまれてきた「ニューラルネットワーク(Neural Networks)」のアルゴリズムをブラックボックス化することで、その機能的な再利用を可能にしています。数学や統計学に詳しくなくても、これらのツールを利用すれば、その内部のアルゴリズムに対する理解度を問わずに、「AI」を実装することができるようになります。

「AIの民主化」時代以降、誰でも一定程度は「AI開発」を実践できるようになりました。TensorFlow、PyTorch、MxNetなどのような機械学習ライブラリを利用すれば、既存の学術論文で提唱されている主要なモデルは直ぐに開発できるようになっています。

しかしながら、その副作用として、「AIの民主化」はこの国に三つの問題をもたらしました

第一に、誰でも一定程度は「AI開発」を実践できるようになった今、原理的にはより多くのプレイヤーが市場に参入できるようになりました。そのため、新規参入者は人材としての競争力を高めていかなければなりません。その際、とりわけ外国人労働者がライバルとなる可能性は高いでしょう。

とはいえ、第二に、人材として発揮できるアウトプットが既存の機械学習ライブラリに強く制約されている「データサイエンティスト」や「機械学習エンジニア」が量産されたというのも事実です。こうした人材は、GitHubで配布されているバッチプログラムを実行し、その結果に一喜一憂することに終始してしまいます。決して、数学や統計力学を用いた誤差関数の設計ができる訳でもなければ、行列や線形代数、多様体仮説に準拠した新しいニューラルネットワークの構造を提案できる訳でもありません。

一方で第三に、学術論文を読み込み、新しいモデルを提唱することに精一杯で、ビジネスドメインへの適用や収益化の検討を度外視する「リサーチャー」が台頭してもいます。企業の経営者たちはこうした「リサーチャー」の費用対効果を気にします。企業を経営する以上、維持費の計算は不可避です。

「競争力」、「人材」、そして「費用対効果」といった概念は、非常にドライな現実を反映した概念です。「AIの民主化」という文字通り「民主主義的な」動向の行き着く先にあるのは、「資本主義的な」競争という冷徹な現実であるためです。

企業内研究開発に限定していえば、GitHubのソースコードの「コピペ」程度しかできないようでは、まず人材として通用しません。一方で、「研究のための研究」に没入し過ぎることも問題です。研究開発とはR and Dです。Rだけでも成り立ちませんし、Dだけでも成り立ちません。概念実証のプロトタイピングを介して、商用化のためのDevelopmentを検討しなければならない時というのは必ず訪れます。その際、「それはビジネスだから関係無い」、「それは自分の専門分野とは関係無い」と言った具合に仕事を放棄してしまう「リサーチャー」は、もはや経営者から観れば、人材として絶望的なコストパフォーマンスを発揮していることになります。

「AIの民主化」によって派生した上記の三つの問題は、いずれも人材に関連した問題で、皆さんのキャリア形成とも関わる問題です。もしかすればこの新しい状況では、「AIの民主化」以前の時代で求められた人材とは別種のタイプの人材が求められるのかもしれません。少なからず上記の三つの問題で言及されるような「機械学習エンジニア」、「データサイエンティスト」、「リサーチャー」ではない、別種のタイプの人材です。

以下では、この「AIの民主化」の時代以降に求められる人材の概観や形態について素描していくことにします。ただし、個別具体的に人材の事例を取り上げたところで、人の数だけ答えが得られるだけで、結論は出ません。ここでは、事柄に即した抽象的な観点から、Researchに特化した「R人材」とDevelopmentに特化した「D人材」の区別を導入するところから、考察を始めてみましょう。

問題解決策:「R人材」・「D人材」から「R and D人材」へ

窮屈なスケジュールと限られたリソースの中で企業内研究開発を実践していくためには、役割分担や分業は不可欠です。しかし、「Rしかできない人材」と「Dしかできない人材」で役割を分担した場合と、R and Dの人材同士で役割を分担した場合とでは、生産性は大きく異なります。日本の場合、RとDの双方に明るい人材が一人もいないプロジェクトでは、どちらか片方を外注する方向で展開される場合が散見されます。しかしその場合も、ユーザー側とベンダー側の開発折衝が派生問題となります。

プロジェクトマネジメントの観点から観れば、「Rしかできない人材」と「Dしかできない人材」がチームを組む場合、双方の間には緊密な相互依存関係が生じます。「Rしかできない人材」は、Developmentを実践できるメンバーに依存しなければ、例えばプロトタイピングすら儘ならない状況が続いてしまいます。一方で「Dしかできない人材」は、例えばResearch内容を詳解してくれるメンバーに依存しなければ、モデルのパラメタチューニングに躓いてしまうでしょう。

これに対して、「R and Dの人材」同士でチームを組む場合、このような緊密な相互依存関係を回避することが可能になります。Rを専門としていながら、Dもある程度はわかっている人材や、逆にDを専門としていながら、Rもある程度はわかっている人材が集まれば、上述した緊密な相互依存関係は回避できるようになります。各メンバーは独立して動ける領分が広いために、双方の依存関係は「疎結合」で済ませることができるのです。

「Dに特化している人材」と「Rに特化している人材」の差異

一般的には、「Dに特化している人材」や「Rに特化している人材」は大多数です。ここでいう「Dに特化している人材」とは、無論ソフトウェア・エンジニアのことです。近年の日本では、プログラミングスクールを介した未経験者の転職により、「Dに特化している人材」は増えつつあります。実際に転職できているかどうかや、現場で通用しているかどうかはともかくとしても、少なからずその候補は増えています。

一方、「Rに特化している人材」は、日本においては特に、相対的に増加し難い状況にあります。例えば学費を支払わない場合は、大学や大学院で基礎的な専門知識を習得する機会は中々得られないでしょう。私個人は奨学金と自分で稼いだお金で大学に通っていたため、親に学費を支払って貰うという選択肢を縛り要素として意図的に排除していました。そのため、学費を払って貰えないことで苦悩している学生の気持ちはよくわかりませんが、少なからず聞くところによると、「Rに特化している人材」になるための学習のハードルは比較的高い模様です。

「Rに特化している人材」よりも「Dに特化している人材」の方が、母集団は多いように見受けられます。これに加えて現代では、大学や研究所よりもIT企業の方が、研究開発に必要となる多種多様なデータを蓄積している場合が散見されます。そのためなのか、「Rに特化している人材」が社内にいない状況であっても、そのIT企業に元々務めているソフトウェア・エンジニアの方々が、企業内研究開発のメンバーとしてアサインされる場合は往々にしてあり得るのです

以上の状況を前提とすれば、「Dに特化している人材」として位置付けられるソフトウェア・エンジニアは、DのみならずRもカバーしなくてはならなくなるケースが今後も増えてくるでしょう。AI(Artificial Intelligence)という狭い範囲に限らずとも、RPA(Robotic Process Automation)、IPA(Intelligent Process Automation)、AI(Augmented Intelligence)、5G通信、自律走行・自動運転車両、IoT事業など、新しいテクノロジーが普及するたびに、ソフトウェア・エンジニアが企業内研究開発にアサインされる可能性は高まります

そうなると、今「Dに特化している人材」としてのソフトウェア・エンジニアがRの領域にも手を伸ばそうとすることは、意味の無いことではありません。一定のニーズは常にあるので、休日に技術書を読む片手間で、「R and Dの人材」としての学習も進めていくことができれば、キャリア形成上一定の付加価値を生み出すと考えられます。

また、本人に強い動機付けが無かったとしても、いずれにしても仕事上巻き込まれる可能性は大いにあり得ます。「AIの民主化」は「AIブームの終焉」と共に進展しましたが、冒頭で述べた通り、AIは我々の生活に浸透してきます。ただそれが、AIとして意識されなくなるだけのことです。アルゴリズムなきアーキテクチャはあり得ません。機能的であれ、疎結合的であれ、ソフトウェア・エンジニアがAIとの接点を持つ可能性はむしろ今後も一層高まっていくと考えられます。

問題解決策:スキルセットを汎化する

「Dに特化している人材」が「Rの人材」としての学習を継続的に進めていくのは、一般的には負担の大きい試行錯誤となるでしょう。確かに、それまでの経歴(学歴)やキャリア(職歴等)と接点の無い新しい領域に踏み込む場合であれば、それは難易度の高い挑戦になるはずです。

しかし、「Dの人材」としてのスキルセットを拡張すれば、「R and Dの人材」としてのスキルセットとして応用することができます。例えばオブジェクト指向設計は数学や論理学の集合論と密接な関わりがあります。そもそもプログラムの「関数(function)」や「機能(function)」は、数学の概念です。

AIのアルゴリズムに関連した専門領域とソフトウェア・エンジニアリングの専門領域との間には、差異はありますが、共通点もあります。それが、ソフトウェア・エンジニアの皆さんが日常的に使用している数学や論理学であるということです。

「文系エンジニア」と「理系エンジニア」の差異

ちなみに「文系エンジニア」と「理系エンジニア」の区別は、この主題を考える上では、何の役にも立ちません。文系出身であろうと、ソフトウェア・エンジニアとしてプログラムを設計・実装しているのなら、皆自覚の有無を問わず、数学や論理学を学びつつ利用しています。

そもそも論理学というのは、文系科目と言える「哲学」でも頻繁に活用されます。例えばイマニュエル・カントは論理学の体系化に貢献した哲学者の一人として知られていますが、若い頃の彼は、1756年に「物理的モナド論(monadologiam physicam)」という論文を発表し、「空間」という概念の性質を物理学的に検討していました。一人の哲学者の記述を追うだけでも、文系科目でもある論理学が理系科目と接点を持つケースは多聞に及ぶことでしょう。

「特化」と「汎化」の差異

数学や論理学を前提にすれば、「Dに特化している人材」のスキルセットを「R and Dの人材」のスキルセットへと「汎化(generalization)」することが可能になります。「汎化」というのは、UMLのクラス図を設計する際に参照される概念です。この概念は、様々な異なる流動的諸要素の中から共通部分を抽出することを意味します。対義語は「特化(specialization)」と呼ばれています。

この「汎化(generalization)」という概念は、実は機械学習のとりわけニューラルネットワーク最適化問題にも登場する主要な概念です。機械学習における「汎化(generalization)」とは、過去に観測しなかったデータに対しても巧く機能する能力を意味します。機械学習の中心的な問題設定の一つは、モデルの学習に利用した訓練(学習)データのみならず、学習時に観測しなかった未知の新たなデータに対しても、アルゴリズムがより良い性能を発揮しなければならないということにあります。

モデルは通常、事前に訓練データを学習することで、本番のデータに対して推論の処理を実行します。例えば画像分類問題であれば、モデルは事前に大量の画像データを学習します。昔からある喩え話がよく言い表しているように、猫の画像を学習するにしても、この世界に存在するあらゆる猫画像を集める訳にはいきません。それは非現実的な取り組みです。だからモデルは、限られた訓練データの中から、猫の特徴を洗い出し、その形態(Gestalt)を学習しておかなければなりません。例えば猫耳が付いているならば概ね猫である、といった具合にです。

ところが、猫と類似した特徴を持つ動物は他にも存在します。トラやライオンにも、見方によっては、猫とよく似た耳を持っています。しかし、猫の訓練データに「特化」してしまったモデルは、これら動物を全て猫と判定してしまいます。これを特に「過剰適合(overfitting)」と呼びます。

訓練データに「特化」し過ぎないためには、二つの意味で「汎化」が必要になります。一つは、猫の画像だけではなく、トラやライオンの画像も訓練データに含めることで、猫ばかりの訓練に肩入れし過ぎないようにするという意味での「汎化」です。もう一つは、訓練データそのものにばかり「特化」するのではなく、実際の現実でのアプリケーション上で観測される画像にも適応できるようにするという意味での「汎化」です。そうすることで、猫とトラとライオンの差異をモデルに教え、尚且つ、猫と虎とライオン以外にも動物が存在している可能性に対して柔軟に対応して貰う必要があります。

このように、「汎化」という概念は、ソフトウェア・エンジニアリングと機械学習の双方で言及される共通の概念です。勿論、専門分野が違えば文脈も異なり、その概念の意味も異なるでしょう。しかし、「特化」を抑えるという点では、双方の専門領域での「汎化」は、同様の機能を有した概念であると考えられます。しかも、「汎化」と「特化」の区別は、やはり論理学で使用される概念でもあります。

「スペシャリスト」と「ジェネラリスト」の差異

「特化(specialization)」と「汎化(generalization)」の区別を人材の分析に当てはめるなら、「スペシャリスト(Specialist)」と「ジェネラリスト(Generalist)」の区別を導入することが可能になります。と言うのも、一つかごく少数の専門分野に特化している人材が「スペシャリスト」として位置付けられる一方で、複数の専門分野を広く跨る人材が「ジェネラリスト」として位置付けられるためです。

一見すると、「R and Dの人材」は「ジェネラリスト」のように見えるかもしれません。しかし、それは全くの間違いです

クラス図の「汎化」を思い描いてください。「汎化」によって、クラスの概念構造を可視化できるようになります。サブクラスにはサブクラスのサブクラスがあるように、親クラスには親クラスの親クラスがあり得ます。つまり、「汎化」した先にあるクラスは、更なる「汎化」の余地があるということです。

「汎化」に終わりはありません。「Dの人材」がそのスキルセットを「汎化」することで「R and Dの人材」になり得たとしても、更にその先にはビジネスパーソンとして「汎化」できる余地が残っています。また、一流のビジネスパーソンになり得たとしても、その先には更に広く「社会」一般での貢献が問われるようになります。

尤も、この終わりなき「汎化」を反復することには、それなりの利点があります。自身のスキルセットを「汎化」し続けていけば、既知の専門知識や専門技術を機能的に再利用することで、未知の専門領域を探索できます。その探索から得た発見は、既知の専門領域の拡張を可能にすると共に、更なる「汎化」のキッカケを与えてくれることでしょう。既知の専門領域が拡張される分、未知の専門領域との共通点を発見する余地が拡大されるためです。

それならば、「汎化」と「特化」の区別を再帰的に導入することで、「汎化」のスペシャリストになってみるというのも一興だと考えられます。むしろこれこそが、「Dに特化している人材」から「R and Dの人材」へと展開していく人材の基礎的な形態であると考えられます。

逆に、「ジェネラリスト」を自称するというのは、もうそれ以上自分の実力には「汎化」の余地が無いと主張しているようなものです。それは成長の停止であり、キャリア形成上ネガティブです。

問題再設定:「汎化」のスペシャリストとしての「R and D人材」

「AIの民主化」時代以降に求められる人材とは、「Rに特化した人材」でもなければ「Dに特化した人材」でもありません。それは「R and D人材」であって、「汎化」のスペシャリストを意味します。それは知識や技術力の終わりなき「汎化」に取り組む人材であって、「ジェネラリスト」を自称する人材とは全く異なる存在です。

勿論、「汎化」ばかりではなく、時には「特化」することも重要です。例えばPoCが終わり、もはや目の前にある課題は実装のみであるのならば、「D」に「特化」すればよい訳です。「汎化」と「特化」のどちらが重要なのかは、専ら皆さんが直面している問題に依存して規定されることでしょう。とはいえ、「汎化」と「特化」の区別を導入し続けることはキャリア形成上は意味のあることであり続けるはずです。

参考文献