皆さま、はじめまして。松本亮介と申します。Twitter上では、まつもとりー（＠matsumotory）と呼ばれています。
10数年前のことですが、意識の高い大学生だったわたしは、大学2年生の頃、自分が研究したいインターネットと運用技術を専門としている研究室に早々と連絡をとり、これからの研究生活を想像しては「おれはやるぞ……何かを！」と意気込んでいました。
しかし、大学3年生の情報工学実験というコンパイラを作る授業の合否結果が出た瞬間、留年が決定しました。そのときの記憶は今も忘れることができません。自分が夢見ていた研究生活もすべて崩れていきました。誰よりも速くコンパイラの実装を終わらせ、周りの友人に意気揚々と解説をしたり実装を手伝ったりしていたのですが、それは決して良心だけではなく、自分はすごいだろ！ 見てくれ！ という気持ちが強かったように思います。
そういったおごりや挫折を経て、自分が研究開発を行っていくなかでどういうキャリアがあり得るのか、あらためて真面目に考えるようになりました。その過程で、大学の中でずっと研究することに不安を覚え、修士には進学せず企業のエンジニアを3年間経験し、その後、修士を飛ばして京都大学大学院情報学研究科の岡部研究室にて博士課程から研究を再開し、京都大学博士（情報学）の学位を取得しました。
そして、現在ではペパボ研究所で、エンジニアリングと学術研究という両輪からのアプローチによって、最高のプロダクトを作るための研究開発を行っています。研究開発した技術はきちんと論文にしてアカデミア（学術研究のコミュニティ）で発表すると同時に、RubyやWebサービスに関わる技術カンファレンスでも発表するなど、エンジニアリングと学術研究を両立しています。
2016年に情報処理学会（IPSJ）において、時流に乗る日本の若手トップ研究者19名に選ばれ、IPSJ-ONE 2016に登壇
なぜ、わたしはこのような働き方をしているのでしょうか？ 本記事では、Webサービスに関わるエンジニアや研究者の今後のあり方を踏まえながら、企業でエンジニアリングと学術研究を両立する意味について、これまでのWebサービス業界の背景と、その変遷を紐解きながらお話をしていきたいと思います。
エンジニアリングを科学する時代の到来
わたしは大学卒業後、企業でインフラエンジニアとして働きはじめました。
2008年当時のインフラエンジニアの仕事では、システムのサービスレベルを維持するさまざまな処理が自動化されはじめていましたが、まだまだ多くがエンジニアの手による職人技に頼っており、会社の新しいプロダクトを開発するどころか、そもそもコードを書く時間もあまりなく、仕事を定量的に評価する基準やデータもほとんどありませんでした。
その後、Infrastructure as Codeの考え方や、SRE（Site Reliability Engineering）、監視やモニタリングの重要性が広まり、基盤技術のフレームワーク化や、HashiCorpによって開発された基盤ツールなども充実してきたことに伴い、インフラをコード化して開発プロセスを活用したり、各種状態を表すデータを精緻に取得したりできるようになりました。その結果、多くの作業が自動化され、インフラやプロダクトの状態を定量的に評価できる時代がきています。
この意味するところは、単に仕事が効率化され、もっと新しいプロダクトを開発したり、コードを書いたりできるようになる、というだけではありません。実は、システムの定量的な評価が可能になることによって、人類が伝統的に醸成してきた叡智（えいち）といっても過言ではない「科学的アプローチ」によるシステムの計測と評価、および体系化が可能となり、さらなる改善や新技術の提案がしやすくなる。これこそが重要だと、わたしは考えています。
科学的アプローチについては、多くの人が中学から高校を経て大学・大学院まで、その基礎をコツコツと学びます。しかし、実際に企業が提供するプロダクトの現場では使うことができず、忘れ去られていました。これからは、学習した科学的アプローチが大いに活用され、役立つ時代になってきているのです。
それでは、研究開発の基礎的なスキルは企業においてどう活用されるのでしょうか。
技術を使う技術と技術を作る技術
現在のWebサービス業界において、研究開発がプロダクトの収益に与える影響はまだまだ少ないといえるでしょう。なぜなら、既存の技術を素早く適切に組み合わせる「技術を使う技術」だけでも、十分に収益を上げるプロダクトを作ることができるためです。
というのも、必要なソフトウェアはOSSとして公開され、設計やノウハウも、ブログやセミナーでの発表などを通じて業界で広く共有されています。これをわたしは「技術の透明化」と呼んでいるのですが、この流れは今後ますます加速していくことでしょう。
技術の透明化が加速するとどうなるでしょうか。既存の技術を組み合わせて業界である程度戦えるプロダクトを作れたとしても、その技術はすべての会社に平等に与えられているわけです。そうなると平等な技術による均衡を打ち破るべく、常に一歩先へと進められるようにしたいと考える会社が出てくるでしょう。
このとき「技術を高度に幅広く使う技術」だけではなく、「技術を作る技術」こそがプロダクトの差別化につながると考えています。つまり、技術の透明化が加速することにより、社内で技術を自ら作ることができる状態、すなわち「技術を作る技術」を社内で醸成することが重要になります。
前節で述べたように、これまで難しいとされていた領域の定量化が促進され、それに伴って科学的アプローチを取り入れやすくなっていることからも、これは想像に難くないでしょう。
なぜなら科学的アプローチでは、一見バラバラに見える技術に対して共通項を見いだして、整理し、体系化します。その上で、新規性・信頼性・有効性を示すような技術を生み出す方法論なのですから、「技術を作る技術」に強く作用してくることは間違いありません。
科学的アプローチによって技術を作る
技術を作る、ということは簡単ではありません。現時点で存在するたくさんの関連手法を理解した上で、自分たちが実現したいプロダクトや社会に対して足りていない技術、つまり新しい技術を自ら思い描く必要があります。
そのためには、人間の発想として技術をトップダウンに捉える構想力が必要であり、それを具体化しながら膨大な関連技術をサーベイ（調査）して比較し、新しい技術の優位性を明らかにしていかなければなりません。サーベイし、整理した情報は、頭の中があふれてしまわないよう、まとめて定期的にアウトプットすることになります。言い換えると、これこそがアカデミアで取り組まれている学術研究であり、科学的アプローチと言えるわけです。
読者の皆さんも、「これは面白い技術だ」と思って実装に明け暮れた経験が少なからずあるかと思います。しかし、出来上がってしまうとその情熱が消えてしまい、その気持ちを再度新たにするきっかけがなく、そのソフトウェアも放置されてしまうといった経験もあるでしょう。
科学的アプローチを活用すると、そういう「技術的に何が面白くて、自分は何に情熱ややりがいを感じているのか？」について、サーベイした関連技術と対象の技術を比較しながら「面白さ」を論理的に整理でき、その答えを自ら認識できます。さらに可能なら、その内容を言語化し、他人にも理解できるレベルまで推敲することにより、そういった情熱を持った取り組みをより深く認識でき、自覚的かつ計画的に行えるようになります。
自覚的に情熱を持って継続的に取り組めるならば、コツコツと成果を積み重ねることを楽しむこともでき、最終的には妥協することなく大きな成果を作り上げることができます。人は大きな絵に基づいて、科学的アプローチのように、煩雑な状態を整理して問題をひとつずつ認識し解決していくアプローチを得意としているのです。
この科学的アプローチによって技術を作りながらも、最終的には所属している会社において最高のプロダクトを作るという、実効性をもった研究開発にする必要があります。実効性は、現時点でアカデミアの研究に欠けている、あるいはさほど重要視されていない性質だと考えています。アカデミアと企業が、それぞれのコミュニティにおいて欠けている点を互いに補いながら、新規性・信頼性・有効性・実効性を持ち、事業を差別化できる技術を醸成することが、今後のWebサービス業界で求められる研究開発になっていくでしょう。
技術によって事業を差別化し自分をも差別化する
わたしが所属するGMOペパボでは、取締役CTOの栗林（@kentaro）により、「事業を差別化する技術の醸成」が技術面のコンセプトとして掲げられています。
事業を差別化するには、人間の発想とそれを実現する技術が必要であり、現時点では、人間の柔軟な発想を支える技術がまだまだ足りていないとわたしは考えています。そのため、どうしても自分たちが今知っている技術の範囲内でどういうサービスが実現できるか、といったボトムアップの思考に陥りがちです。
しかし、本来は人間のサービスに対する発想にルールや制限を課すことなく、まずは実現したいことに基づいて、トップダウンの思考でサービスや技術を作り上げる状態にすべきです。
トップダウンのアプローチでサービスを開発するには、やりたいことを実現する技術を、仮にまだ世の中になかったとしても、自分たちで作り上げる技術と自信が必要になります。その技術こそが「事業を差別化する技術」です。
わたしは、そういった「事業を差別化する技術」までも世の中に公開して、フィードバックをもらうようにしています。なぜなら、社外でも議論を行うなかで、自分たちだけでは見落としがちな論点を得ることができ、新しい技術の品質をさらに高めることができるからです。
また、社内の限られたリソースだけで技術を開発するよりも、優れた技術を公開することによって技術の透明化の流れをうまく活用する方が、これからの技術開発を効率的に行えると考えているためです。すなわち、優れた技術を公開することは、社外と自分たちとの問題意識を一致させ、社外との共同開発を促し、自然と相互扶助の関係を作ることにつながります。
そのため、エンジニアに対しては積極的なアウトプットを推奨しています。それが結果的に、Webサービス業界で自分自身のスキルを差別化することにもなり、この競争力の高い業界で生き抜くことができるよう、成長を促す効果もあります。
それらが巡り巡って、また事業を差別化することにつながると信じています。
エンジニアが技術を作るために重要なこと
エンジニアが、いざ事業を差別化するような新しい技術を作ろうとする上で、科学的アプローチにおいても非常に重要な要素のひとつは、とにかく関連技術をサーベイすることです。
関連技術のサーベイをたくさん行うことにより、雑多な技術の集合から共通項を見いだし、現状解決できていない課題や領域を明らかにすることが重要です。それが、課題を解決する手法を提案することにつながります。
これまでWebサービスにおいて定量的な評価が難しいとされてきた時代においては、会社のリソースが限られていたり、そもそもプロダクトが職人の手作業によって支えられてきた背景もあり、問題のあった箇所を局所最適によって場当たり的に改善することが多かったように思いますし、プロダクトを維持する上で、それが重要度の高いタスクにならざるを得ませんでした。
しかし、Googleをはじめとする多数の博士号持ちエンジニアを擁するインターネットの大企業が、科学的アプローチによりWeb技術を見直し、整理してきました。今後、システムの定量評価や多くの自動化がより進むことで、綿密な関連技術のサーベイに基づいて、システムを俯瞰したアーキテクチャやコンポーネント間の関連性や課題をきちんと体系化してアウトプットし、システム全体のアーキテクチャを改善あるいは提案することが求められるでしょう。
そのため、本来解決したい問題意識に基づき、計測によって定量的な評価を行い、どのコンポーネントを適切に改善するか、それらが相互にどういう影響を与えているかを考察して整理していく必要があります。まさにこのアプローチこそが、論文を執筆する意味にもつながってくるわけです。
論文を書く意味
技術の透明化が加速するなかで、「技術を使う技術」と同様に「技術を作る技術」の重要性が増すと述べました。また、その技術はまさに「事業を差別化する技術」であり、最高のプロダクトを生み出す重要なポイントになることも説明しました。その技術を生み出すためのヒントが、論文執筆に隠されているのです。
実は、わたし自身、論文を書くための研究をしているわけではない、と思っていた時期がありました。言葉のごとく、論文を書いて実績を残すことが目的ではなく、良い研究になるのであれば論文にならなくてもよい。それはそれでひとつの側面です。
一方で、エンジニアリングと研究を両立させるなかで、良い論文としてまとめられること自体が良い研究になることもあるのではないか、と思いはじめました。
ここでいう「良い論文」とは、論理構成が適切で、新規性・信頼性・有効性が高く、それぞれの要素できちんと議論がなされており、関連研究も十分にサーベイされている状態を指します。そこに実効性があれば、本記事での文脈においては、より良い論文といえるでしょう。
そうした良い論文を書くには、十分にサーベイを行った上で、自分たちの研究の前提条件や基礎概念を体系的に整理し、関連研究の課題を明確化した上で、それを解決する手法を提案し、その実装まで行う必要があります。さらに、適切な実験環境を用意して、意味のある評価を行い、それによって有効性や信頼性を主張しつつ、読者がちゃんと再現できるように書くことも求められます。
そこに実効性を加えるとなると、作った技術を実際のプロダクション環境に導入して、実運用上の評価をし、今後の課題まで評価しなければなりません。これらはすべて、前節までに述べてきた、技術を作る技術に必要な方法論です。
同時に、この論文をアカデミアと共有することで、長いあいだ新しい技術を生み出してきたより多くの研究者たちと議論できる、まさに知のサイクルが用意されているのです。これをわたしは「論文システム」と呼んでいます。
今後、技術の透明化に従って事業を差別化することが必要となってくる時代において、その重要性を理解していれば、論文を読み、執筆することに投資するという選択は、企業としても重要であるといえるでしょう。アカデミアと連携することによって事業を差別化する技術を効率よく生み出し、論文システムに乗ることで科学的アプローチが緻密に実践可能となり、ひいては最高のプロダクトを作り上げていく流れを起こすことができます。
Webサービスのシステムに対する定量的な評価においても、科学的アプローチにおける評価の方法論は非常に参考になります。それによって、さらなる課題が見えてきますし、課題を適切に認識することで新しいアイデアも生まれやすくなるでしょう。
企業とアカデミアの境界がなくなる世界
これまで述べてきたことは、少なくともWebサービス業界、もっというとインターネット業界において、技術への取り組み方の方向性がどうなっていくかに関するわたしの予想でもありました。もしこの方向に進むのならば、その先には企業とアカデミアの境界がなくなる世界が来るだろうと思っています。
企業が限られたリソースや歴史的経緯から実効性を重視して取り組んできたことに、アカデミアが関心を持つこと。そして、科学的アプローチを生業としてきたアカデミアに対して、論文システムをはじめとする方法論に企業が関心を持つこと、その両面が重要であると思います。
企業のエンジニアが当たり前に論文を書いてWebに関する技術を科学するようになり、またアカデミアの研究者が実効性の高い実装をして、プロダクトでも使えるようなソフトウェアを作り上げるようにもなるでしょう。
少なくとも、そのように相互に関心を持たないことには、技術の透明化が加速する時代において、プロダクト開発も学術研究もともに効率が悪くなってしまいます。まずはお互いに、それぞれの取り組みの良い文化やプロセスを取り入れてみることから始めてみるのがよいのではないでしょうか。
Webサービス企業における研究開発の役割
技術の透明化が加速して「技術を作る技術」の重要性が増し、企業とアカデミアの境界がなくなる世界までを想像してみました。この世界で、読者の皆さんは「どう生きていけばよいか？」ということを考えるだろうと思います。
例えば、大学は社会人向けにも広く研究室の学生を募集していますので、博士課程を目指してみるのもよいでしょう。そのために、会社が社会人学生という選択肢をサポートする制度を検討するのもよいと思います。
また、アカデミアの研究者は、企業のサービス開発に参加してエンジニアリングの実効性や開発プロセスを経験するというのもよいでしょう。実際にそういう人材の流れも最近よくみられます。わたしが所属するペパボ研究所のように、社内に研究開発組織を作るという選択肢もあり得るでしょう。
気をつけないといけないことは、科学的アプローチによって「事業を差別化する技術」を生み出すために研究開発をするのであって、単にこれまで触ったことのない技術を使うために研究開発をするわけではないということです。
例えば、機械学習を取り入れたいからといって、機械学習そのものを研究することなく、単に使うだけの研究開発組織を作ってもあまり意味がないでしょう。それが目的であれば、技術を使ってシステムを作ることに長けたエンジニアが機械学習を技術のひとつとして使いはじめれば、すぐにプロダクトに応用できるようになるでしょう。それぐらい今のエンジニアはレベルが高いです。
企業の研究開発はあくまで、科学的アプローチによってサービスを検証し、改善しながら、論文を書き、事業を差別化する新しい技術を生み出して、その技術をプロダクトに適用することに注力すべきだと思います。
そのためには細かなルールを設定せず、十分に試行錯誤する時間を与えることによって、発想を抑圧しないことも大切でしょう。
アウトプットの重要性
今後、エンジニアリングと研究開発に取り組んでいくなかで共通している大事なことは、アウトプットすることです。とにかく、技術を使う技術も技術を作る技術も、それらを社内外に継続的にアウトプットすることによって、自分の立ち位置を知ることができます。
それによって、思い込みがあったり、不必要な前提条件を知らず知らずのうちに作っていたりしないかを認識できます。さらには、自分を差別化するなかでスキルや行動を適切に知ってもらうことが、社内外の評価につながっていくでしょう。むしろ、アウトプットなしには評価が困難な時代になっていくのではないでしょうか。
そういったアウトプットは、一時的なものでは効果がありません。一回のアウトプットではなく、とにかく継続的にアウトプットを積み重ねていくことが大切です。
そのためには、まず自分の取り組みを言語化すべく、技術についてどんな些細なことでもよいので、細かく切り出して数をこなすようにしましょう。そうすることで、思考と文章が一致しはじめ、自分の思考をより適切に素早く、大量に表現できるようになります。最初から内容を選んでいると長続きせず、その基本的なスキルすら身につきません。
例えば、これは面白いぞ！ と思ってブログ化しても、意外と誰も読んでくれなかったり、読まれてもあまり感想が得られなかったりという経験はないでしょうか？ それは多くの場合、自分の思考が適切に他人に伝わる形で言語化できていないからです。
あるいは、言語化が不十分であることに起因して、思い込みからくる暗黙の前提や議論の不十分な箇所に気付くことができず、技術的に曖昧な内容を書いてしまっているからです。
文章によるコミュニケーションの上達、良い文章の執筆や図による適切なイメージ表現は次のステップであって、まずは、自分の思考や行動から意識的に細かく複数の主張を切り出して、それぞれを言語化すること。それを継続的に取り組みましょう。
それによってアウトプットが上手になってくれば、自分自身の思い込みや曖昧な議論に気付くことができ、自分の取り組みの価値を論理的かつ説得力を持って言語化できるようになり、読み手を意識したテキストでの技術的なコミュニケーションも上達します。そういった点でも、エンジニアにとってアウトプットは重要です。
思考をきちんと整理し、素早く外部に言語化しておくスキルは、限られた脳のリソースの中でさらなる深い思考を効率化するためにも非常に重要です。思考とコードの関係も同じですよね。最初のうちは思っていることすらコードに表現できませんが、書いているうちに思考とコードが一致してきて、慣れてくるとだいたいのコードが頭の中で描ける状態になってきます。
そして、思考をコードや文章としてどんどんアウトプットし、形にするうちに、整理されたことに気付いた脳がさらなるアイデアや実装を生み出してくれる、といった体験をすることになるでしょう。
結果的に、アウトプットが皆さんの技術力や思考力を醸成し、それによって技術選択や技術開発を改善していくサイクルを回し続けられるようになります。そして、技術を作る上で最高のドキュメントでありアウトプットといえるものが、論文です。ぜひ論文の執筆にも挑戦していただけたらと思います。
おわりに
本記事では、「企業におけるエンジニアリングと研究開発」というテーマで自分の考えをまとめてみました。本記事が、皆さんの今後のキャリアを考える上での議論の材料になると幸いです。
わたしが企業において、エンジニアリングと学術研究を両立する意味がわかっていただけたでしょうか。もし読者の中に学生がいらっしゃれば、ぜひ今大学で学んでいる科学的アプローチの基礎や研究活動にしっかり取り組み、実績をアウトプットしていくことが、これからの時代を生き抜く近道になると思います。
また、現在エンジニアである皆さんには、技術を一から作り上げること、プロダクトをトップダウンに構想することを恐れないでください。そのため論文システムに上手に乗ることによって、アカデミアと共に研究開発を行い、エンジニアあるいは研究者としてのキャリアの幅を広げ、エンジニアと研究者が交わる世界、「技術の透明化」が加速し続ける世界、まさに空前の技術的戦国時代を「技術を作る技術」によって生き抜いていただけると幸いです。
執筆者プロフィール
松本 亮介（まつもと・りょうすけ） / まつもとりー 
matsumotory
京都大学博士（情報学）。現場の技術を知るため修士に行かずにホスティング系企業に就職したのち、異例の修士飛ばしで京都大学大学院の博士課程に入学。インターネット基盤技術の研究に取り組み、mod_mrubyやngx_mrubyなどのOSSをはじめとした多数のOSSへの貢献や学術的成果を修める。2015年よりGMOペパボ株式会社にて、サーバのセキュリティ・リソース管理・運用技術改善などを中心に、OSやミドルウェアなどに関する研究開発を行っている。第9回OSS奨励賞の受賞や情報処理学会IPSJ-ONEにおいて時流に乗る日本の若手トップ研究者19名に選出される。
