先進的なとりくみを続ける現場に訪問し、
今回はPreferred Infrastructureからスピンアウトし、
【インタビューされた人】
久保田展行（くぼたのぶゆき）
（株）久保田展行
Twitter：@nobu_
開発者よりも研究者の多い組織体制
- ──Preferred Networks
（以下PFN） さんは現在、 何名いらっしゃるんでしょうか。 久保田：全部で50名います。そのうち研究者が30名で、
エンジニアが10名、 そのほかはバックオフィスや経営陣などです。 - ──研究者の方の割合がかなり高いですね。
久保田：研究者といっても、
純粋な研究者というよりは自分でものを作りたいタイプの人が多いので、 研究者とエンジニアの境界がはっきりあるわけではないです。ただ、 それでもタイプとしては違っていて、 そういった研究者気質の人が30人くらいいるという感じです。研究者だからといって理論を作って終わりではなく、 コードも書くし実験もする。お客さんのところに行って一緒に話すこともありますね。 - ──なるほど。研究寄りの方が30名いらしゃるということですが、
その人たちのチーム構成はどう分かれているんでしょうか。 久保田：割り方にはいくつかあって、
お客さんごとの区切りと、 得意分野ごとの区切りがあります。たとえば研究者だと、 ディープラーニングをコアでやっている人たちのチームや、 異常検知のような特定のアルゴリズムに詳しい人たちのチームなど、 それぞれ得意分野を持っています。縦軸としてお客さんごとのチームで分かれつつ、 専門分野のつながりという横軸でも情報共有ができるような、 マトリックス型に近い体制にしています。
CTOとCROの両輪でマネジメントする
- ──日常的な仕事としてはお客さん単位でプロジェクトが立ち上がり、
それをチームとして実行していくということですね。Webサービスとは違い研究開発は長期的なプロジェクトになるイメージがあるのですが、 1プロジェクトにどの程度の期間がかかるものなんでしょうか。 久保田：流れとしては
「お客さんがすでに何かしら問題を抱えた状態で来てくださり、 それに対して研究を行い解決策を提供する」 というものなので、 立ち上がりは早いです。研究自体はおよそ3ヵ月くらいのスパンでスピーディに終わるのですが、 そのあと研究成果が製品になるまでには品質保証や検証などさまざまな作業が入ってくるため時間がかかります。この開発の部分をどうするのかが現在の課題です。 - ──その3ヵ月間で研究者とエンジニアとが協力してプロジェクトを進めていくイメージですか？ どのようなチーム構成でプロジェクトを進められるんでしょう か。
久保田：プロジェクトによって違いますが、
1チームはだいたい7人から10人くらいですね。タスクによって、 研究者だけでやるときもあれば、 最初から製品化を見越してエンジニアを交えて開発を進めていくこともあります。 - ──研究から、
実際に製品として動くところまでを見るのは大変そうですね。 久保田：実は研究から製品化というのは道のりがすごく長いので、
1人ではなく2人で分けて見ています。私はCTO （Chief Technology Officer、 最高技術責任者） として製品寄りの立場からプロジェクトを見ている一方で、 比戸将平さんという方がCRO （Chief Research Officer、 最高研究責任者） というポジションを別に構えているという体制です。私は研究の動きに応じて人を付けたり、 研究開発が終わったものを製品化するための道筋を立てたりといった仕事を、 比戸さんは研究の方面で何を優先するか、 どうプロジェクトを進めていくかといった仕事を……という感じでマネジメントを分担し、 2人で全体をカバーするイメージですね。 - ──求められるものが違うわけですね。次に個別のプロジェクトについて聞きたいのですが、
あるプロジェクトに対してどういうチームを組むかとか、 プロジェクトマネジメントや進行管理などはどうされているんでしょうか。たとえばWebサービスだと最近プロダクトマネージャーという職種が確立されつつあって、 スタートアップの開発チーム構成としてプロダクトマネージャーがプロダクト全体に責任を持って、 プラスエンジニアとデザイナーでチームを組むというのがよくある構成なんですが、 PFNさんでは研究開発におけるプロダクトマネージャーのような立場の人はいらっしゃるんでしょうか。 久保田：はい、
副社長の岡野原大輔さんがやっています。お客さんにとって良いアルゴリズムや成果物のインタフェースがどういうものかを考えたり、 そもそもどういう解き方をすればよいかという全体のデザインや方向性を決めています。 - ──領域を広く理解していないとできないことですね。
研究と開発の良さを相互に取り入れる
- ──それにしても、
CTOとCROという体制はおもしろいですね。 久保田：PFNは研究の会社であるという認識があって、
いろいろと研究ありきでことが進んでいるんです。何をやるにしても研究が起点になるんですが、 最終的に製品化までもっていかないとビジネスとしてはスケールしません。CTOの自分は製品化までをどう最短化するかという部分の面倒を見ています。たとえば研究者とエンジニアはけっこうインセンティブが違っていて、 研究者は目先の問題をいかに速く解決するかという能力に特化されています。そのためCI （Continuous Integration、 継続的インテグレーション） だったりコードのきれいさだったりも大 事ですが、 最優先事項じゃないんですよ。 - ──インセンティブの違い、
おもしろいですね。 久保田：うちはそういう人は少ないですが、
人によってはGitも触ったことがないということもあります。こうした研究者とエンジニアとのギャップを埋めて、 研究でできあがったものをうまく製品に落とし込めるようになることが最終的なゴールだと思っているんです。ただ一方でエンジニアのやり方を研究者に押し付けても効率が悪いと言われるだけなので、 「じゃあ、 どういうふうにすれば気持ちよく研究してもらいながら、 できあがったものをすぐに製品として形にできるか？」 というのが僕のテーマですね。 - ──その2つの領域をどうつなぐのかは難しそうですね。そういう意味では、
エンジニア的な考えやツールで、 研究にも取り入れたら良いものや、 実際に取り入れて効果があったものって何かありますか？ 久保田：まずバージョン管理の徹底は基本ですね。コードは全部GitHubで管理しているので、
何かあったときに皆がコードを見られて、 周りが支援に入りやすい態勢になっています。研究ってどうしても属人性が高いタスクになるんですが、 それでも冗長化をしておかないとお客さんに迷惑がかかってしまう。 「この人がいなくなったら突然何もことが進まなくなる」 というのは商売として駄目だと思っているので、 そこはうまくWebから発展した技術を活かしています。Dockerもすごく活躍しています。 - ──研究でDockerを使うんですか。おもしろいですね。
久保田：研究の過程で、
すばやく作業を進めるために自分用のツールをたくさん作っちゃうんですが、 逆にそのツールを使えないと速度が出ない。そして、 そのツールをほかの人が使えるようにするのは難しい。そんなときにDockerを使えば、 1回どこかで動けばほかの人の環境でも再現できて、 実験の再現性を持たせられるんですよ。環境の再構築を支援する、 みたいな。 - ──たしかにまったく同じ環境を立ち上げられるっていうことですよね。逆に研究者の仕事の進め方でエンジニアも取り入れるとよいようなことはあるでしょうか。
久保田：どれだけコードを書く量を減らすか、
持っている道具を組み合わせて最短で課題を解決するという姿勢はとても参考になりますね。たとえば何かを自動化するときに、 エンジニア的発想だと新しいツールを作ろうとするところで、 研究者は普段使い慣れているものをちょっと変えたり組み合わせるだけで解決してしまう。プログラミングコンテストのようなマインドに近いですね。課題を最短時間で解くことに命をかける。 - ──問題解決をいかに短くやるか、
速くやるかというところでいろいろ工夫されるんですね。
知見を共有し、基礎体力を付ける
- ──僕の印象なのですが、
研究というと1人で進めて成果を出すというイメージがあるので、 研究のチームというのは意外な感じがします。 久保田：もちろん個人プロジェクトもありますが、
まず前提として失敗するかもしれない課題に挑戦しているので、 プロジェクトメンバーの心理的負担は大きいんですね。もし失敗したときに、 個人プロジェクトだとその人に責任が集中してしまいます。そうなると自由に活動しづらくなるので、 少なくとも方法論や進め方に関してアドバイスができる人が必要だと思うんですよ。先輩の研究者の中には過去に似たような問題を解いた人もいるので、 そうしたメンターみたいな人と一緒にアルゴリズムに対しても議論できるようにしながら、 過去の知見をうまく共有できる体制を必ず持つようにしています。だいたいのプロジェクトについて、 フルで関わらないまでも、 少なくとも3人はサポートする人がいるようになっていますね。 - ──メインでプロジェクトを進める人に加えて、
サポートする人が必ず入る。 久保田：そうですね。たとえば、
とあるプロジェクトについて、 メインで携わっている人がお客さんに説明する予定だったのが、 突然直前になって別の人が代わりに行くことになってとても困っていたということがありました。でも、 このような体制のおかげでその代わりの人がきちんと発表できた。この体制はうまく回っていると思います。 - ──チーム内での知見の共有のためのしくみとしては、
サポートで入ること以外にはどうされているんでしょうか。属人性と専門性は近いものだと思うんですが、 チームでやる場合には、 あまりに属人的になると知見の共有が問題になると考えていて、 そこをどう解消されているのかなと。 久保田：できる限り属人性をなくすためには、
研究の基礎体力を継続的に付けていくしかないのかなと思いますね。研究の分野は一個一個がものすごく深くて、 全体を深くカバーしている人はいないんですよ。ただ、 基礎体力が強くて別分野のキャッチアップが速い人というのはいます。たとえばうちの会社は数学畑から来ている人も何人かいるんですが、 そういう人って理論を追うのがものすごく速いんです。分野が変わってもすぐに追い付ける。うちではおもしろい論文を発表する会を定期的に開いていて、 自分の分野だけではなくほかの人がやっている研究内容もきちんと理解していけるようにしています。これがプロジェクトの切り替えとか人の再配置が起きたときもスムーズにできることにつながっているのだと考えています。 - ──全員が同じ専門知識を持つのではなく、
別分野についてもいかに速くキャッチアップできるようにするかということですね。 久保田：属人性をなくす話としてはほかにも、
チームとして似たようなタスクが出てきたときにほかの人がいかにそれをうまく行なえるかということで、 できる限り共通のフレームワークを使って作業するようにしています。たとえばディープラーニングは全部Chainerというフレームワークを使って書いているんですが、 そうすることによって共通化されていない部分が最小になるんですよね。そのおかげでほかの人のコードについて自分の知らない部分だけを読めば何やっているかを把握できます。 「まずコードを書いて研究する」 というのが前提にあるので、 そのコードの部分にできるだけ共通化されたものを使う。また、 みんながSlackなどのチャットベースで頻繁に、 継続的にコミュニケーションを取り続けているため、 逆にあらためて共有したり明文化したりしないと共有できないことは減っている気がしますね。
普段はアメリカでお仕事をされている久保田さん。今回は帰国のタイミングに合わせ、
良いチームとは
- ──最後になりますが、
久保田さんが考えられる良いチームとは？ 久保田：良いチームというのは、
「自分たちがチームであるとは認識していないが、 にもかかわらずうまく連携できる人の集まり」 だと思っています。結果としてチームワークがうまくいっている、 というか。1つの目標に向かってみんなでとてもうまく動けるが、 それをチームとしては強く意識していない。そういう考えが常識になりすぎて自分たちがチームであることを忘れるくらい同じ方向を目指している塊ができると強いのかなと思います。 - ──いいですね。チームであることを忘れる状態。
久保田：あとは、
複数のチームがあったときにチームごとに責任が分かれるのはいいんですが、 「これは自分のチームとは関係ないから手を出さなくていいや」 とか 「向こうのチームが困っているけど別にいいや」 といった感じにならないこと。チームを超えて、 さらにお互いをカバーでき合えるようなチームのチームというような組織ができると理想だと思いますね。 - ──理想的ですね。
久保田：けっこう昔から感じているところではあって、
チームと言ってしまうとそこで責任だけでなく関心までなくなってしまうことがあるんですよ。僕はそこがあまり好きではなくて、 チームとしては分かれつつ、 ほかの人がやっていることにも当事者意識が持てるような組織にしたいなと思っています。 - ──いい形ですよね。そのためには先ほどおっしゃっていた論文発表会のような、
チームを超えてゆるくつながる取り組みが大事なんですね。本日はありがとうございました。
本誌最新号をチェック！
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判／
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！ - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT