Findy Engineer Lab

エンジニアの"ちょい先"を考えるメディア

ITエンジニアから研究者へ。社会人博士として大学院にも再挑戦し、自分の「代表的プロダクト」を追求するわけ

高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017

こんにちは、坪内佑樹です。Web上では、ゆううき@yuuk1tと呼ばれています。

僕は現在、さくらインターネット研究所で研究員を務めています。専門領域は、ITエンジニアが情報システムに対して常に変化をもたらしながら、同時に情報システムの信頼性を高めていくための技術である、Site Reliability Engineering(SRE)です。

これまで、大学院を中途退学したのち、Webサービス企業でWebオペレーションエンジニアおよびSREを5年間務めました。そして昨年(2019年)の2月から現職で研究開発に取り組んでおり、今年はさらに情報系の大学院の博士課程に社会人博士として進学します。

本記事では、昨今注目を浴びているSRE分野において「代表的プロダクト」を作ることに憧れ、それを目標の軸に据えて、なぜエンジニアから研究者になる「選択」をしたのかをご紹介します。

大学で研究するより、代表的プロダクトを作りたい

僕は2012年まで、情報系の大学院で修士課程に在籍していました。学部から修士にかけて取り組んだ研究は、平たく言うとストレージやネットワーク処理における一部のアルゴリズムを、CPUやGPUの機能を駆使して高速化することでした。

コンピュータやOSの仕組みを理解してその上で動作するソフトウェアを高速化する技術は、得られる結果が「速いか遅いか」に支配される世界であり、目立たないけれど硬派でかっこいい技術でした。文章を書くことはそれなりに好きだったため、学位の取得要件である論文もそれほど苦になりません。したがって、研究そのものはそれほど嫌いでなかったと言えます。

とはいえ、大学院修了後に博士課程に進学したり企業の研究所に就職して、研究を続ける考えは全くありませんでした。ましてや就職したのち、博士課程に戻ってくるなどとは、夢にも思いませんでした。

結果的には、修了どころか、残り半年で修士課程を辞めるという最初の転機が訪れます。

インターンをきっかけとしてWebオペレーションエンジニアに

当時、実社会における情報システムの課題がよく分かっていなかったこともあり、取り組んでいる研究が本当に問題の解決につながるのか分からないままでした。イメージできない研究より、プログラミングやシステムのオペレーションなど、エンジニアとしての技能を身に付けたい気持ちが強くありました。

また、研究室の指導方法に不満があったことも影響しています。所属していた研究室だけでなく聞き及んだ限りは他も似たようなもので、大学で研究すること自体に嫌気がさしていました。

そんなわけで一足先に、新卒として内定をもらっていた株式会社はてなに入社することになりました。前年に同社のサマーインターンに参加したことをきっかけに、Webサービス企業に就職してエンジニアをやりたいと考えていました。既にアルバイトスタッフとして働いていましたし、後に長く関わることになるサーバ監視サービスMackerelの立ち上げに早く取り組みたい欲求もありました。

入社後の職種は、Webオペレーションエンジニアです。Webサービスで利用するWebサーバ、データベースサーバなどの各種ミドルウェア、OS、ネットワーク、ハードウェアなどの基盤技術を組み合わせたシステムについて、いかに構成するかを設計したり、稼働中のシステムを操作したりします。

Webサービスのバックエンドは、それぞれ役割をもった多数のサーバが、互いにネットワーク通信する分散システムとして構成されます。多数の構成要素が協調して一つの系をなすものが昔から好きだった僕は、すっかりWebオペレーションの世界にのめり込んでいきました。

アウトプットを続けるうち「顔が見える」成果物への思いが強くなる

このように情報技術に取り組みはじめた時期、Webコミュニティを通して、多くのエンジニアが自らの成果物をOSSやブログといった形でアウトプットしていることを知りました。しかも、同世代ですごいことをしている人がたくさんいました。

自分も少しずつ取り組みをアウトプットするようになり、既存のアウトプットのすごさがますます分かるようになりました。中には、その人なりのアウトプットを突き詰めた先に、名刺代わりになるような成果物を持っている方も見受けられました。自分もいつか顔が見える成果物を作ってみたいという思いが、ふつふつと沸いてきました。

このような成果物のことを、僕は代表的プロダクトと呼んでいます。代表的プロダクトという言葉はそれほど一般的ではなく、あまり馴染みがないかもしれません。この用語は、あんちぽ@kentaroさんがブログで書いている1ように、「○○さんといえば□□で有名」という形でITエンジニアに広く知られる成果として定義されています。

この記事では、代表的プロダクトと呼ばれるための条件が4つ挙げられています。

  1. それなりの規模のもの
  2. 広く使われるもの
  3. 技術的新規性のあるもの
  4. 作者個人を強く想起させるもの

Webサービス企業でエンジニアをしていれば、大学とは違って大規模な現場の課題にたくさんぶち当たるはずです。その課題を解決するソフトウェアを開発していけば、いつか代表的プロダクトにたどり着くと当時は信じていました。

しかし実際のところ、こういった条件を満たす代表的プロダクトを作ることは、7年経過した今もまだ続く目標です。

大規模なWebシステムを開発・運用する経験

はてなに在籍した5年の間に、サーバ監視サービスMackerelを中心として、社内のほぼ全てのサービス、ないし基盤システムに何らかの形で携わりました。そこには大きくて複雑な生き物のようなシステムがあり、会社から離れた個人の環境ではとても再現できません。

それだけの規模を持つサービスに障害が発生したときには、真夜中にアラート通知を受けて一人で復旧にあたる経験が何度もありました。担当したことのない初見のシステムやミドルウェアも含まれるため、ドキュメントや各種監視ツールが示す情報を手繰りながら、自分で考えて復旧プロセスを組み立てる必要がありました。

自分がやらなければ、誰も直すことはできない状況を、まさに最後の砦となって、サービスを守っていました。そういったWebオペレーションの仕事は、のちにSREという新しい分野に発展しました。

天職だと思えたSRE

SREは、サービスの信頼性を100%にすることを目指すのではなく、信頼性の目標値を短期的にあえて下げることにより、システムの変更速度(開発速度、リリース速度、アジリティ、プロダクティブティとも呼ばれる)を向上させるための技術です。2

つまり、信頼性という守りだけでなく、変更速度という攻めに転じることもできます。自由にシステムを変更して試行錯誤できることは、子どもの頃に好きだったサッカーのシミュレーションゲームを思い起こさせます。複雑なシステムを自分の制御下に置ける全能感は、他に代えがたい感覚です。

そういう意味で、SREは僕にとってまさに天職でした。現場では毎日やることが大量にあり、エンジニアとしての経験を浴びるように積んでいきました。例えば、代表的プロダクトとは呼べないものの、自分が開発したOSSもいくつかプロダクション環境に導入できました。

Drootlstfgokcgrabenifireworq(fireworqでは厳密には分散システムとしての設計部分を担当)といった、主にオペレーション自動化ツールやミドルウェアに分類されるソフトウェアたちです。中には現職でも使われているものがあります。

エンジニアリングにおける知の全体像と現場の知見

こうした経験を積むことで、自分が持つ知識や技能も増えていきました。しかし、知識がいくら増えても、その知識や技能がエンジニアリングにおける知の全体像のどこにあるのか、他の知とどういうつながりがあるのかを理解しないと、自分は満足できなかったのです。

古典的な話題であれば、情報科学の教科書を読めばよいのですが、現在の現場の知見に近い話題では、いくらググっても体系化された情報にはたどり着けないことがありました。3

そこで、自分が持っている知や、ブログ記事やカンファレンスのスライドに散らばった知を集め、抽象化し、他のシステムにも応用可能な形で体系化し、文章として自分のブログ4で表現することに熱中しました。一時期は、そうした記事を月に1本は書く制約を課して投稿を続けたのです。

その後も折に触れ更新していると、広く読まれ、自分でも面白く思えるブログに育ち、やがて代表的プロダクトとも呼べるものになってきました。ソフトウェアだけで表現できない技術は自然言語で表現するしかなく、文章も立派なエンジニアの成果物であると考えるようになってきました。

クラウドが発展する中で抱えた問題意識

ここ5年ほど、クラウドコンピューティングの発展には目覚ましいものがあります。コンテナオーケストレーション、マイクロサービス、サーバーレス、カオスエンジニアリング、分散トレーシング、サービスメッシュなど、新しいアーキテクチャが提案され、普及しつつあります。

さらに、AWS、GCP、Azureといったメガクラウドが提供する多数のマネージドサービスが登場したことにより、サーバ上に自分でシステムを構築・運用する機会は徐々に減っていきました。このような技術の発展により、他人が考えたり作ったりした技術を単に使うだけで、ほとんどの問題が解決できてしまうように錯覚してしまうほどです。

自分は何を生み出すことができるのか?

こうした技術を利用して問題を解決できるのなら、それはもちろん素晴らしいことです。しかし、あらゆる局面や観点で他の全てより有用な、万能な技術はないと考えています。自分で考えたり作ったりして解決できる問題が、発見できていないだけで、まだまだ残されているはずです。

個人の欲求としても、既存の技術を利用するだけで、自分は何か生み出せるんだろうか? と思うことがあります。自分自身の目標が「代表的プロダクト」を作ることなので、このままではまずいわけです。自分が作る側で居続けるには、どうすればよいかを考えました。

事業に直接貢献できる成果を、半年や1年程度の短期間で確実に上げようとすると、どうしても自分のアイデアを実現するより、既製の技術を流用する方がよいことになってしまいます。事業の課題をいちエンジニアの立場でコントロールすることは難しいものですし、逆にコントロールできるポジションは一般的にマネージャー職なので、やりたいことだけではなく多くの仕事を引き受けなければいけません。

こういった問題意識から、2〜3年程度のスパンで自己の取り組みを育てることができ、自分がやりたいことをコントロール下における仕事をしたいと考えるようになりました。

エンジニアではなく研究者としての道が急浮上

モヤモヤしたものを抱えた状況で、師匠であるところのまつもとりー@matsumotoryさんがさくらインターネットに転職され、研究所で仕事をされるという報5を読みました。

この報をきっかけに、それまで具体的に考えたことがなかった「転職する」という道が、急に自分の前に浮かんできました。同時に、もし研究職に転向すれば、自分のやりたいことに集中できるのではないか、という期待を持ちはじめました。

そして、さくらインターネットはクラウドやデータセンターを主体としたITインフラ企業なので、 自分の好きなSREを含むITインフラ技術に集中してコミットできると考えました。いったん期待を持つと早く話を進めたくなり、その後すぐに、さくらインターネット研究所で研究員として働くことに決めました。

クラウド企業の研究所でSREを研究する

さくらインターネット研究所での取り組みは、自分が参画する以前に想像した以上に、各メンバーの裁量に任されています。会社の事業への直接的な貢献も、明には求められていません。成果の発信とその利用を通じて、社会と会社の発展に寄与することがミッションです6

取り組む内容は、メンバーがやりたいと思うもの、かつ「さくららしさ」があれば何でもよいとされています。研究テーマが与えられるわけではないため、自分が最も得意なSREを軸にした研究テーマを設定しています。

なぜSREを研究対象に選んだのか?

ITインフラの運用技術の分野で、国内ではインターネットを対象とした研究が盛んであり、クラウドやWebシステムを対象とする研究は残念ながらあまり見かけません。特に、SREという用語をテーマに含めた研究は、自分が知る限り、国内ではまだ例がないようです。

僕が具体的に取り組んでいる内容を、次のスライド7にまとめています。

見てもらうと分かるのですが、僕がやっている研究は実務寄りで、「もっと研究らしいことをやったらいいのでは」と言われることもあります。ここでいう「研究らしい」とは、例えば新しいネットワークプロトコルやOS、データベースそのものの基礎技術の開発のように、実務になかなか取り入れづらいため大学で研究されているようなものを指します。

それはそれで、やってみれば面白いと思いますし、今後取り組む可能性がないわけではありません。しかし、僕は研究らしい研究がやりたいのではなく、自分の顔がみえるような代表的プロダクトを作りたいわけです。そうすると、これまで一番長い間取り組んできて得意なことをやるのが、自分らしいビジョンを描きやすいと考えています。

学術研究のシステムを活用して技術的な新規性を示す

研究職を選んだ理由は、単にやりたいことを自由にやれるためだけではありません。代表的プロダクトを作る上で、OSSやテックカンファレンスのようなエンジニアの世界だけでなく、学術研究の世界のシステムを活用することが効果的なのではないかと期待しました。

前述した代表的プロダクトの3つ目の要件に、「技術的新規性のあるもの」があります。しかし、あるアイデアや成果物に新規性があるかどうかは、自明ではありません。

情報科学の分野では、ソフトウェアや論文のような成果物が数多く発表されるため、似たような成果物に出会うことがよくあります。したがって自分で思いついたり作ったりしたものだと、大したことないからとか、既存の〇〇と似ているから新しくないよね、と最初から諦めてしまう様子も見かけます。

そこで、いかに新規性があるかを示したり、そもそも新規性とは何かを突き詰める手段として、学術論文のアプローチ8が歴史的に確立されているため、これを利用しない手はありません。

オープンで客観的な基準となる学術論文のアプローチ

学術論文では、「新規性」「有効性」「信頼性」「了解性」の4点を記述することが要求されます9。特にシステム開発論文の場合、個別の要素が既知であっても、組み合せが新しく工夫があり、さらに他のシステムに応用可能であり、先行手法と比較して優れていることが主張できていればよいとされます。

もともと要素技術の新しさがなければ、学術論文にならないと思いこんでいました。しかし、既知と既知の組み合せでも、その組み合せが自明でなければ新規性として認められることは、新しい発見でした。それでも、類似のシステムがたくさんある中で新規性を見出すには、徹底したサーベイと、既知の部分ではなく自分が考えた組み合せがよいのだと言えなければなりません。

このような学術論文の各要件が満たされているかを確認するには、論文を客観的に評価する仕組みが必要です。国際会議や論文誌といった論文を発表する場では、同じ分野の研究者に論文を評価してもらう査読の制度があります。さらに、国際会議や論文誌にもレベルがあるため、今自分がどのレベルにいるかを確認しやすくなっています。

このように学術の世界には、ソフトウェアエンジニアの世界では資格試験以外であまりみかけない、オープンかつ客観的な基準が存在します。この客観的基準をクリアすることによって、自分の研究に有用性を持ちつつ、新規性があるかどうかを確認できます。

こうした学術研究の成果として、2019年7月に開催された国際会議IEEE COMPSAC 2019へ投稿した論文がメインカンファレンスで採択されました。

続いて、2019年12月に開催されたIOTS2019(第12回インターネットと運用技術シンポジウム)で発表した論文が、優秀論文賞とシー・オー・コンヴ賞をダブル受賞することができました。

このように学術の世界でも徐々に成果を発信することができるようになってきました。しかしながら、これらの研究で示した新規性はまだまだ満足できるほどではありません。特に代表的プロダクトの4つ目の要件である「作者個人を強く想起させるもの」には満たないと考えています。

自分らしい新規性を育てるため再び大学院へ

それでは、この「作者個人を強く想起させるもの」をどうすれば満たせるのでしょうか。作者個人を強く想起させるかどうかは人の主観に依るため、狙って満たせるものではないと思っていました。

しかし、情報処理学会が主催するIPSJ-ONE2017での登壇10をきっかけに、「作者個人」とは何か、つまり自分らしさが何かを発見し、ビジョンと呼ばれる形で言葉にすることが、まず必要ではないかと気付きました。

ビジョンと言うからには、単一の成果物で表現できることはなかなかないでしょう。一つ一つの成果物の貢献は小さくても、一つのストーリーをもって複数の成果物をつなげ、大きな新規性として見せていく必要があります。

そのような技能をどのように身に付けるか? 一つの大きな研究計画に基づいて、複数の研究を博士論文としてまとめあげる大学院の博士課程に、以前から着目していました。

博士課程では、入学試験で研究計画を審査され、入学後の中間審査、予備審査、公聴会といった審査プロセスが用意されています。このプロセスに挑戦することで、「作者個人を強く想起させるもの」を作るための技能を身に付けることができると期待しました。

会社のサポートも受けて博士課程へ進学

博士過程への進学には、授業料などの経済的な負担、仕事との両立などの時間的な負担、周囲の理解といったハードルが一般にあります。

幸いなことに、さくらインターネットに入社するとき、研究所所長の鷲北@ken_washikitaさんから、博士課程進学に興味があるか、興味があれば会社のサポートを受けて進学することが可能なので、ぜひ挑戦してみてほしいと言ってもらいました。

大学院で所属予定の研究室の先生と事前に相談したときにも、博士課程で取り組む研究内容はさくらインターネットでやっている研究そのままでかまわないと伝えてもらいました。したがって、一般に言われる博士課程への進学のハードルは、ほとんどなくなりました。

最後に残ったハードルは、修士課程を一度中退していることから、また同じように辞めてしまうのではないかという不安でした。しかし、この1年で大学や研究機関のさまざまな方にお会いする機会があり、研究会の運営委員にも携わる中で、アカデミアの世界に対する負の印象が徐々に薄まってきました。

何より進学先の研究室が、まつもとりーさんの出身研究室であったことや、研究室内の進捗報告会にお邪魔することもあったり、はてなで一緒に働いていたアルバイトの学生が在籍していることも安心材料でした。気が付くと進学しない理由がなくなったので、昨年の秋ごろ、進学を決めました。

入試のプロセスも順調に進み、2020年4月から、社会人博士として京都大学大学院情報学研究科の博士後期課程へ入学しています。代表的プロダクトを作るという目標に向かって紆余曲折を重ねた結果、もう関わることはないと思っていた大学の世界に、7年ぶりに戻ってきたことになります。

むすび ── 道を作る

ここまで書いてきた内容を踏まえると、僕が技術者から研究者になる「選択」をしたり、大学を辞めてまた戻ってくる「選択」をしたように読めます。

しかし実際は、しつこく述べてきたように、代表的プロダクトを作ることが一貫した目標であり、その目標を達成するため、状況に合わせて環境を変化させてきたと言った方が、自分ではしっくりきます。

とはいえ、最初から明確に目標を意識できていたわけではありません。頭の中に言葉になっていない状態でふんわりと漂っていたり、ときどき忘れたり、明後日の方向に向かってしまうことも多々ありました。過去を振り返ってみると、これまでのキャリアの節々で直感的に感じていた高揚感や違和感は、代表的プロダクトを作りたい気持ちがあったゆえに生まれていたことに気付き、それを軸に結果的に整理できただけです。むしろ、今回、こうして文章をしたためる機会をいただいたことで、はじめて明確に目標として認識できました。

代表的プロダクトの表現媒体が何かは、ここでは規定はしていません。昔はOSSであったり、サービスのような形を思い描いていましたが、今では、ブログや書籍、論文などの文章も立派なプロダクトを表す媒体であると考えています。ソフトウェアエンジニアの観点だと、「コードを書く」ことにこだわってしまうかもしれませんが、表現媒体は、人それぞれでよいと考えています。これは、まつもとりーさんの受け売りですが、「プロダクト」と呼ぶよりは、「作品」と呼んだ方が適切かもしれません。

また、代表的プロダクトを何か一つ作って、それで満足してしまうことはありません。一つ作れば、また別のものを作りたくなるでしょう。したがって、代表的プロダクトを作り続ける道が続いているような心象風景を自分の内に持っています。研究という言葉と区別するために、こうした活動全体を「探究」と呼んでいます。

人生において分岐点のいずれかを選択したり、長期的な人生の計画を立てるよりは、自分が歩む「道を作る」11こと。先の見えない時代だからこそ、自分の直感からくる必然性を捉えて、その直感の由来を思索し、自分らしい道を作っていくことが大事であると僕は信じています。

参考文献

編集:はてな編集部