Findy Engineer Lab

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

技術を楽しめているか? Scalaエンジニアが研究・開発・教育それぞれで試行錯誤した10年のキャリア

読者の皆さん、はじめまして。株式会社オプト所属のエンジニアでかつJapan Scala Association(JSA)理事を務めている水島宏太@kmizuと申します。

この記事では、私の経歴を大学院の修士課程から現在に至るまで振り返って、どのような試行錯誤をしてきたかを「教育」「研究」「開発」という3つの軸を中心にお話ししたいと思います。この軸は今の自分を規定しているものでもあり、これまで試行錯誤してきたものでもありました。

私のキャリアは割と行き当たりばったりな部分がありまして、皆さんの参考になるかどうか分かりませんが、「こういうキャリアもあるんだ」「こういう生き方もありなんだ」程度にでも受け止めてもらえればうれしいです。

「研究する力」と「技術の感性」を磨いた大学院時代

大学院も博士後期課程にもなると、学部(学類生)と違って、研究テーマ決めや論文投稿、発表といった活動について、教員に頼らず自分で決めないといけません。論文誌や国際会議に論文を投稿して成果を出すことも求められます。

私の専門は、解析表現文法(Parsing Expression Grammar、PEG)と呼ばれる技術です。解析表現文法は2004年に発表されたかなり新しい分野で、研究を始めたばかりの頃(2006年頃)は論文も数えるほどしかなく、解析表現文法についての数少ない関連論文を読みつつ、自分で試行錯誤したものでした。このような中で「問題について深く考える」力が身に付いてきました。

結果、なんとか博士号(工学)を取得することができたわけですが「自分で1つの研究をやり遂げた」ことと、得られた「研究する力」は自分を支える根っ子でもあり、学会活動に関わるきっかけにもなっています。大学院、特に博士後期課程を通じて学んだことや得たことは何か? と問われれば、大きなものはやはり「(本当の意味で)研究したこと」と「研究する力」だと言えます。

プログラミング言語でわいわいする楽しさ

大学院生時代のもう1つの活動の軸は「技術」です。当時、既に草の根で技術イベントに参加したり主催することは当たり前になっていましたが、私はプログラミング言語に関する技術イベントに参加したり、主催したりしていました。私をご存じの方にとっては意外かもしれませんが、Scalaという1つの言語に特別な興味を持っていたわけではなく、いろいろなプログラミング言語を触る中でScalaに惹かれ、次第にのめり込んでいったのです。

その中には、実用的には全く役に立たないように見えることも数多くありました。例えば、型システムを使ってプログラミングをする「型レベルプログラミング」は今でも「役に立つ」かは怪しいものですが、とにかく楽しかったですし、プログラミング言語についてわいわいと雑談することも、やっぱり役に立つかは不明ですが、単純に「楽しい」と感じたのを今でも覚えています。

また、技術イベントを主催したことは技術に関する感性を磨く役に立ちましたし、特にScalaについての技術イベントを積極的に主催したことは、後の日本におけるScalaコミュニティ活動の広がりにもつながりました。

人生の転機となったScalaコミュニティ活動

Scalaのコミュニティ活動は、私にとって大きな変化の1つです。博士後期課程1年のときは単に趣味で楽しんでいただけでしたが、Scalaに興味を持つ人が増えるにつれて「日本でScalaを普及させられないか?」ということを考えるようになりました。

そこから、Scalaに目をつけていた方(豆蔵の羽生田さんら)とともに日本のScalaコミュニティ「Scala-be」を結成したり、名古屋で100人規模のScalaイベント「Scala座」を開催したりと、Scalaコミュニティ活動に傾倒するようになりました。

時期を同じくして「Scalaの本を出しませんか」という企画が動き出し、社会人1年目に共著で『オープンソース徹底活用 Scala実践プログラミング』を出版しました。コミュニティ活動が外から評価された実例と言えるでしょうか。

Scala Days 2010
▲ Scalaが誕生したEPFL(スイス連邦工科大学ローザンヌ校)にあるらせん階段は、Scalaロゴのモチーフとして知られる/筆者がScala Days 2010に発表者として参加した際に撮影

ScalaMatsuriへと続く道

私が就職した2011年以降、Scalaは国内外で注目を集めることが増えていました。私自身、Scalaを楽しみつつ普及活動に携わっていました。その頃、実のところそれほど深い思いはなく、私が好きな言語であるScalaがより広まるとうれしいという程度でした。ただ、素朴に「広まるとうれしい」と言っても、Scalaに興味がない企業がScalaを採用するには実績が必要です。

そして、ある時を境に「Scalaを国内で普及させるには大規模イベントの開催が必要だ」と考えるに至りました。そのようなイベントを開催することで、Scalaの実用事例が集まって、企業も「Scalaは使える」と思ってくれるのではないかと考えたのです。しかし、そのような大規模技術イベントはお金もかかりますから1人で実施するには無理があります。

というわけで、現在のScalaMatsuriの前身となる「Scala Conference in Japan 2013」キックオフミーティングを行い、スタッフになりたいと考える人たちを募集することにしました。幸いにして、このときに多くの方がスタッフとして集まってくださり、そこから、「Scala Conference in Japan 2013」の企画が始動し、紆余曲折あれど、無事、開催に至ったのでした。

Scala Conference in Japan 2013 〜座長の軌跡〜 - kmizuの日記

この「日本のScalaコミュニティへの貢献」が、巡り巡って転職時に評価されたりしたので、今にして思えばキャリアにおいても重要な活動でした。

研究に未練を残しつつ就職し技術教育に出会う

話は前後しますが、私のもう1つの大きな変化は就職でした。博士後期課程3年になると、企業に就職するか大学に残るかの決断を迫られます。

研究が好きな私は未練があったものの、会社組織でプログラムを書いてみることも重要ではないかということで、就職活動をすることにしました。結果として、私が一番興味を持っているプログラミング言語に近いことができそうな企業を選ぶことにしたのでした。

会社組織の一員として開発をしていると学術研究との違い、特に大規模なコードベースを扱うことの難しさや、バージョンの管理の重要性など、多くのことに気づきます。こうした学びができたことで、就職したのは正解だったと思っています。

Scalaエヴァンジェリストと技術教育への興味

2014年に株式会社ドワンゴに転職。私のミッションの1つは、Scalaの普及活動とScala教育でした。

当時、新卒エンジニアの教育科目としてScala研修を取り入れようという動きがあったのですが、まとまったテキストがありませんでした。私は当時の同僚数名と協力して、研修テキストを書き上げました。このテキストは「Scala研修テキスト」としてドワンゴからJSAに委譲され、今でもメンテナンスがされています。

また、このテキストを使ったScala研修を私が担当することになり、会社の新卒に対して「Scalaをいちから教える」という作業に初めて直面しました。それまでScalaの普及活動について考えたことはあっても「教育」が重要であることをよく理解していませんでした。

しかし、実際に講師としてScalaを教えることで「初心者がScalaを学ぶ体制」が必要だという気づきを得ました。ひいては技術教育というものの重要性を初めてはっきりと実感したのです。

教育的な技術イベントやハンズオン

技術を広めるためには教育が重要だという観点に至った私は、次のようにさまざまな教育的技術イベントを多々開催しました。

特にハンズオンには労力がかかりましたが、こういう活動は見てくれている人は見てくれているもので、地道に活動を続けることが重要です。

今の私が取り組んでいる3つの軸の話

2019年7月に現職のオプトに転職しました。ここで「教育」「研究」「開発」という3つの軸に対して現在の私がどのように取り組んでいるかを紹介します。

教育:エンジニア新卒教育

私のミッションの1つは「新卒エンジニア研修」です。ドワンゴに在職中も「Scala研修」については担当していましたが、「新卒エンジニア」全体への研修を担当するのはこれが初めてでした。そのとき、初めて「新卒エンジニア(プログラミングに不慣れなことが多い)に対して必要な研修とは?」という問題と真正面から向き合うことになりました。

さらに皆さんご存じの通り、2020年2月頃から新型コロナウイルスが猛威を振るいはじめました。会社全体がリモートを推奨し、週2日以内の出社体制にシフトする中で、対面が前提だった新卒エンジニア研修も急遽リモートで行われることになりました。つまり、初めての新卒エンジニア研修と、初めてのリモート研修という難題を同時に解決する必要に迫られたのです。

特に、リモートでの研修は難題でした。対面であったなら、講義についてどれくらい新卒が理解しているのか、全体を見合わたすとある程度は直感的に分かるのですが、リモートでWebカメラ越しとなると(途中からは、講師以外のWebカメラはオフの場合が多かったのでなおさら)、理解度把握にもかなり苦労しました。

その中で、slackのリアクションを利用して理解度を確認するというアイデアを思いついたり、演習でコーディングをやってもらっている最中に、問題が発生したときにはVisual Studio CodeのLive Share(直接ネットワークの向こうにある相手のエディタを操作できる機能)を使って、画面越しに相手のトラブルを解決するやり方も模索していきました。

教育の本質的な難しさと喜び

この経験を通じて、「教育」の本質的な難しさにも直面しました。例えば、いかに正しい説明でも、新卒にうまく伝わらなければ意味がありませんが、それまでの私は「技術的に正しい説明」に固執しているきらいがありました。もちろん「技術的な正しさ」は大切だと今でも考えていますが、相手によっては多少正確さを落としてでも、理解しやすい説明をすることも重要だと初めて実感しました。

さらに、「教える相手は一人一人違った人間である」といった一見当然であることも、よく分かっていなかったように思います。例えば、研修を設計するときに「このカリキュラムを終えれば全員が内容を理解している」という前提を置いていたような節がありましたが、そもそも1科目にもっと時間をかけられる大学教育でも、学生によっては理解していると限らないといった事例を考えると、このような仮定はナイーヴ過ぎたと感じています。

ほかにも、時間が足らなければ問題であるし、かといって時間が余り過ぎると退屈させてしまうのも問題であるとか、本質的な難しさがいろいろあります。こういうことは、突き詰めれば「教育を受ける側は一人一人違う人間であり、技術レベルや知識レベルもまちまちである」ということにつながるのだと考えています。

このように「教育」はとても大変なことだと思う一方で、その結果、相手が何かを得てくれたと感じたときの喜びもまた格別のことなのも事実です。大変ではあっても、それだけやりがいはあるといったところでしょうか。ともあれ、今に至るまで「教育」は私にとって大きな軸であり続けています。

開発:自分の適性を見つめ直す

ドワンゴに転職する前は、開発が主な仕事でした。そのときの悩みは「自分がプロダクト開発そのものに熱意を向けられない」ことでした。ドワンゴに在職中は、求められる役割もあって、あまり開発業務を行っていませんでした。

そして、現職に転職して、開発に関係する業務をいろいろな形で行うようになりました。今の私は、特定のチームには属さないやや特殊なポジションにおり、テクノロジーエヴァンジェリストというちょっと変わった肩書で勤務しています。この立場でどうすれば組織に貢献できるかと考えた結果、チームを横断して、その組織が抱えている課題を解決することがミッションになりました。

例えば、昨年までにやった作業としては、社内のいくつかのチームで使われているScalaのWebアプリケーションフレームワークであるPlay Frameworkのバージョンアップ作業があります。特に、バージョンアップ前はPlay 2.5または2.4だったのですが、それをPlay 2.6にアップデートする作業が大きなものでした。

こういった作業は担当する人によって工数が変わるものですが、私が引き受けた方が工数を少なく済ませられることと、比較的技術的難易度が高い作業だったことから、私がアップデート作業のコードを書くことがありました。

また別の例としては、Scalaの並行処理ライブラリであるFutureを使ったアプリケーションでOOME(JVMのヒープメモリが足らなくなること、OutOfMemoryErrorの略)が発生する問題を解決したり、Webアプリケーションの起動時に5秒かかるのを1秒まで縮める(SQLに関するチューニング)作業も行いました。

こうした「困り事を解決する」ことを繰り返すうちに、私はアプリケーション開発よりもトラブルシューティングやパフォーマンス・チューニング、周辺環境の整備といった作業の方に適性があることに気が付くことになりました。

社会人になったばかりの頃、自分が何について得意か、あるいは何が得意ではないか、また何について熱意があり、何について熱意がないのかを、はっきり自覚できていませんでした。今になって振り返ると、自分の得意や不得意だけでなく、何に熱意を持つことができ、何に熱意を持てないかを自覚することが重要だったのだと思います。

研究:学術コミュニティでの活動と未練

今の私にとってもう1つの軸は「研究」です。2011年3月に博士号(工学)を取得して以降、私は研究者コミュニティの一員として、アカデミアに「恩返し」をしたいとずっと考えていました。とはいえ、博士号取得して以来、査読付き論文を提出していない私が「研究者」を名乗るのはおこがましいので、「コミュニティの一員」という表現になってしまうのですが。

そんな中、私の専門分野については国内でも査読を引き受けられる人が少なかったようで、私に査読の依頼が来ることもしばしばありました。地道な作業が認められたのか、あるいはその他の要因かは不明ですが、学会の運営委員や、学会誌の編集委員を務めることになりました。

幸いなことに前職でも現職でも、社員として学会参加することを条件として、研究活動に一定の時間を割くことを認めてもらっているので、研究コミュニティに関わり続けることができています。

ただ、私自身が「研究」をできていないという焦りは正直なところあります。また、直接業務に関係しない研究をどうやって会社への貢献につなげられるかは、今でも迷います。今から研究職に就くことも無理ではないものの、同時に私は「開発をしていたい」という情熱も持っています。現状は、研究のための時間を十分取ることができておらず、この点についてどう折り合いをつけるかは未だに課題です。

若いエンジニアに伝えたい3つのこと

以下に、とっても偉そうな感じに聞こえることを3つ書きましたが、どうすればうまくいくのかは人によって違うもので、誰にとってもうまくいく万能なやり方はないと断言します。ただ、いくつかの点はキャリアにとって、あるいは人生にとって重要なことなので、あえて書いてみることにします。

1. 健康を大事に

特に20代のうちは、健康を崩すことが少ないため無理しがちです。しかし、無理をするのは、「健康の前借り」です。無理を続けると、精神的なダメージが蓄積した結果、長期療養に至ることは決して少なくありません。

特に精神的な健康を一度崩すと回復には長い時間を要しますから「無理は禁物」「きちんと休息を取る」というのは心に留めておいてほしいです。組織から無理を要求されたとしても、自分のキャパシティーを超える場合に「無理です」と勇気を出して言うことや、強引にでも休息を取ることは重要です。特に責任感の強い人は無理をしがちなので気をつけてください。

2. 低リスクなチャンスには積極的に挑もう

無理は禁物の反対のようですが、ある程度のチャレンジはしておいた方がいいです。1つ言えるのは、比較的リスクが低いチャレンジは積極的にしておいても損はないということです。

例えば、勉強会で発表をするといったことは、仮に失敗してもリスクが低いですが、いろいろな人に顔を覚えてもらえるチャンスにもなりますし、自分の知識を整理することにもつながります。躊躇している方は「とりあえず」やってみてはどうでしょうか。

3. 人間関係を広げよう

言うまでもなく人間関係は大切です。しかし、私が言いたいのはそういうことではなく、できるだけいろいろな層の人と関係を持っておくと良い、ということです。同じコミュニティで活動を続けることも重要ですが、似た意見の人が集まる傾向があるので、どうしても視野が狭くなりがちです。

ときには自分の得意でない技術のコミュニティに顔を出してみたり、未知のコミュニティに顔を出してみてはどうでしょうか。例えば、フロントエンドが得意な人はバックエンド技術に関するコミュニティに、バックエンドが得意な人はフロントエンド技術に関するコミュニティに顔を出してみることはいい経験になります。

おわりに ─ 技術を楽しもう

私のキャリアとこれまで考えてきたことについてつらつらと書いてきました。いかがでしたか? つまみ食いでも、役に立つことがあればうれしいです。

1日8時間労働だとして、定年までの数十年間、人生の1/3近くは仕事になるわけですから、どうせなら楽しく仕事をしたいものです。そのためには、技術を「勉強する」だけでなく、技術で「遊ぶ」観点があると良いでしょう。もし、技術で遊べるなら、仕事でも楽しみの量は全く違うものになります。「遊ぶ」を忘れないことは重要です。

怠惰に生きることも重要です。怠惰というのは単に何もせず怠けているという意味ではなく、しんどいなあと感じる問題があったときに「仕方ない」と同じことを繰り返すのではなく、折に触れて「こうすれば楽になるのでは?」と考えて生きるということです。組織が使えるリソースは常に限られていますから、限られたリソースの中で必要以上に特定の人が「頑張る」とその人が疲弊する結果になります。自分が疲弊しないようにしつつ、皆が楽になる方策を考え続けることは常に重要なことだと感じます。

何はともあれ若いエンジニアの皆さんには、とにかくいろいろなことを見聞きし、そして技術を楽しんでほしいと思います。

kmizu's working table 2021
▲ 現在は筆者も自宅でリモート勤務/執筆を終えた仕事机を撮影

編集:はてな編集部