AIをサプライチェーンで鍛えれば、不測の事態に強いモデルができる

• Xでシェア
• Facebookでシェア
• LINEでシェア
• LinkedInでシェア
• 記事をクリップ
• 記事を印刷

全プロジェクトの情報をオープンにし、イノベーションを起こす

森 ハードの技術者とソフトの技術者では、使う言語や文化も違うでしょうね。

榊原 以前はハードウェア開発が中心でしたが、当社はメカだけではないAIやソフトウェアの機能を十二分に盛り込んだソリューションプロバイダーに変革することを目指しています。ですから、ハードウェア技術者には、AIやクラウドといったソフトウェアの技術、無駄なくスピーディに開発・展開するDevOps(デブオプス)などの手法を身につけてもらっています。それがCTOに就任してからの大きなチャレンジの一つでした。

森 「Think Big, Act First, and Fail Fast」というポリシーで、R&D(研究開発)部門のカルチャー改革を進めてこられたそうですが、手応えはどうですか。

榊原 ハードウェアは誤作動や故障が許されませんから、「とにかく失敗してはいけない」という文化がR&D部門にも染み込んでいました。そこで、もっと発想を大胆にして(Think Big)、とにかく手を動かし(Act First)、早く失敗して(Fail Fast)ほしいというメッセージを出しました。お客様の課題を解決するソリューション開発は、失敗を恐れずにどんどんチャレンジして、失敗から学ぶのが成功への早道だからです。

カルチャー改革の仕掛けの一つとして、「リスクテイカーアワード」という制度をつくりました。リスクを取ってチャレンジし、失敗した人を表彰する制度です。「私、こんな失敗しました」「俺もこんなことやらかした」という面白いエピソードがいっぱい出てきました。R&Dプロセスにおける失敗をネガティブにとらえないという意味で、この制度は結構響いたと思います。

これからは、R&Dプロジェクトの計画を説明する時に「プレゼン資料はいらない」というルールにしようかと思っています。その代わり、「時間をあげるから、実際に動くものをつくって持ってきなさい」と。頭でっかちな計画は、実用化に結びつきにくいので、とにかく手を動かしてほしいのです。

森 ハードからソフト、そして買収した海外の企業まで、多彩かつ多様な技術者の集団を率いられていますが、「こういう組織にしたい」という具体的なイメージはありますか。

榊原 専門領域の外にも目を向け、異なるテクノロジーをかけ合わせてどんどんイノベーションを起こしてほしいので、そのためには表面的に階層をなくすといったことよりも、情報格差のない真の意味でフラットな組織にする必要があると思っています。

イメージとしては、『Joy, Inc.』(邦題『ジョイ・インク 役職も部署もない全員主役のマネジメント』翔泳社、2016年)に書かれているような組織です。誰が何をやっているかをみんながわかっていて、どうやったら仲間の役に立てるかを考えている。そういう組織をつくるには、フラットに情報を共有できる環境がまず必要です。

技術研究開発本部では数百のR&Dプロジェクトが動いていますが、それらのテーマ、メンバー、進捗状況、開発費などの情報を全部デジタルデータ化して、誰でもリアルタイムで確認できるようにしました。ソフトウェア開発については、全員がGitHub(ギットハブ:ソフトウェアの開発プラットフォーム)を使うようにしました。いま1500くらいのリポジトリー(ファイルやディレクトリーの記録・保管場所)があって、ソースコードやプロジェクトの成果を共有できるようになっています。

森 フラットな情報共有が進めば、誰に相談すればいいのかすぐにわかりますし、アジャイルな開発も進めやすい。心理的な安全性が高まって、アイデアも出しやすくなりますね。

実用化を視野に入れると、事業サイドとの課題やデータの共有も重要です。現場の課題を共有し、データを提供してもらいながら開発を進めれば、R&Dへの理解が深まって、事業化しやすくなります。

榊原 事業化という出口戦略を視野に入れることは、すごく大事です。そこで、R&Dプロジェクトのポートフォリオを整理しました(図表参照)。「課題の明確性」と「期間」という2軸で4象限に分類し、課題が明確で短期間で成果を求められる「Issue-driven」(イシュードリブン)と、課題は明確ではないけれども時間をかければ将来的に事業として大化けしそうな「Blue sky」(ブルースカイ)の2つに該当するプロジェクトにリソースを集中させる方針です。

森 イシュードリブンとブルースカイに該当する典型的なプロジェクトは、どんなものですか。