こんにちは！WAmazingで人事を担当している小島です。

今回、社員インタビューVol.3として取り上げるのは、Scalaをメインに扱うサーバーサイドエンジニアとして、開発を行いながら社内教育にも積極的に取り組んでいる「ひらっちさん」（社内での愛称）です！

ひらっちさんは、最初の社員として、創業初期にWAmazingへジョインし、技術力の高さから社内でも一目置かれる存在です！

今回もCTO舘野がインタビュアーとして様々な角度から切り込み、WAmazingの開発環境が深く知れる内容となっております。
ぜひ、最後までご覧ください！！

（注記）本人意向により、今回はインタビュー時の写真はございません。

状況に応じてより良い言語を選択する。

舘野：まずは簡単に、現在担当している業務について教えてください。

ひらっち：今は宿事業（WAmazingサービスでは国内約1万軒の宿のオンライン予約が可能）におけるバックエンド機能をScalaで実装しております。

舘野：メインはScalaで書いてるということですが、Scala以外のプログラミング言語を使うことはありますか？

ひらっち：宿サーバー以外のところ、例えばWAmazing本体(サービスリリース時に作られた最初のRailsアプリケーション)はRailsで書かれているので、それを触る時は当然Rubyを使いますので、普段使うとすればScalaとRubyの2つですかね。

舘野：なるほど。ところで、WAmazingに入社する前はどんな仕事をしていましたか？

ひらっち：前職は、某エンタメコンテンツ系会社で、PHPで書かれていた既存のシステムをScalaでリプレイスする仕事などをやっていました。

舘野：Scalaという話が出ましたが、WAmazingにジョイン以降、社内におけるScala活用の旗振り役としてもひらっちは活躍してくれていますが、元々Scalaに愛着というか、「Scala愛」みたいなものがあるのですか？

ひらっち：うーん、言語に対しては特にこだわりがあるわけではないですね。こだわりではなくて、僕としては状況に応じて、より良い言語を選択して使っていきたいという考えがあって、それで今はScalaが良いと思っているので使っているという感じですね。

舘野：なるほど。今の職場でも前職でも、Scalaがベストだと考えて選択しているということですか？

ひらっち：“僕の知る限り”ではありますが、多くのケースにおいてはScalaは良い選択肢なのではないかと思います。

ビジョンへの共感、そして一からサービス作りに関われる絶好のチャンスがWAmazingにはあった。

舘野：ところで、前職からの転職を考えた際に、最終的になぜWAmazingに決めたのですか？

ひらっち：冒頭に話したとおり、前職ではPHPで書かれていた既存のシステムをScalaでリプレイスする仕事をやっていたわけですが、既存のシステムが非常に大規模だったこともあり一気にリプレイスすることが難しかったため、Scalaに置き換える仕事をずっとやっていました。新機能を全く入れないということもできないので、既存のPHPのシステムの方にもどんどん機能が追加されていって、既存システムと後発で出来始めてきたScalaのシステムを平行運用するということになったんですね。結局、より複雑なことになってしまっていました。。

舘野：平行運用は非常に難易度が高いですよね。

ひらっち：そうですね、難易度は高いです。元々PHPの大きなモノリシックなアプリケーションがあって、それが非常に複雑で、手を入れるのが大変だったこともありリプレイスしようという話でした。それが、平行運用でより複雑になり、かつ、Scalaリプレイスプロジェクトも2年、3年と経っていく中で、結構ぐちゃっとなってきてしまったんですよね。そうして、Scalaのシステム自体のリファクタリングや改善みたいな業務もやっていたわけですが、もはやキリがないというか、やってもやってもなかなか終わりが見えない仕事なので。また、直接的にユーザーへの価値を生み出せるものではないので、もっとユーザーに新しい価値を提供していけるようなサービスを作っていきたいなという気持ちが強くなり、転職活動を始めていました。そういうタイミングでちょうど、WAmazingが新しくサービスを作り始めるところで、ちょうどいいなーと思って。

舘野：たまたまタイミングも良かったわけですね。

ひらっち：そうですね。あと、個人的にトライしてみたかったことが、結局システムが大規模になってしまうと、どうしても複雑になりメンテナンスが困難になるというのは、一般的にはそうだとは思うものの、でも本当に必ずそうなるのかな？というのは疑問に思っていて、初期段階からちゃんと作っていけば、そうしたことも回避できるのではと思っていました。

舘野：そもそも作り方の問題もあるのではないかということですね。

ひらっち：そうなんです。僕がWAmazingと出会った頃は、ちょうどこれからサービスを作り始める段階だったので、先ほど話したような、自分がトライしたかったことに取り組めるチャンスがあるんじゃないかと思いました。

舘野：なるほど。ひらっちはWAmazing一号社員であり、最初のエンジニアだったわけですが、何もない段階から自分が関わっていけるかどうかということが、転職における要件の一つだったわけですね。

ひらっち：そうですね。WAmazingはタイミングも良かったです。

舘野：まだ何にもないところだったから面白いと感じた？

ひらっち：それが一つの理由でもありますが、他の理由として、「日本中を楽しみ尽くす、Amazingな人生に」というWAmazingのビジョンに惹かれたということもあります。僕自身、趣味で昔、日本全国をバイクでツーリングしたことがありますが、その時に、訪日外国人旅行客に知られていない面白い場所がまだまだたくさんあるなと感じました。WAmazingは、そうした日本の観光コンテンツを訪日外国人旅行客に広め、地域活性にも貢献できるという点で、今後期待できるサービスだと思いました。

長期視点で考えた時に最適な言語がScalaだった。

舘野：ひらっちはWAmazingに初期からジョインして、今2年ぐらい経ったと思いますが、実際一からシステムを作ってみてどうですか？

ひらっち：僕がWAmazingに入社を決めた時点では、まだそもそも何も出来てなくて、どう作っていくかも決まっていませんでした。僕が実際に入社したタイミングではRailsで作っていこうという話になっていて、一番最初のサービスリリースの時はRailsアプリケーションで作りました。その後しばらくはRailsアプリケーションを使っていましたが、その後、SIMシステムをリプレイスする時に初めてScalaでサーバーを書いて、元々のRailsアプリケーションから一つの独立したサービスとして切り出すという対応をプロジェクトとしてやりました。

舘野：今振り返ると、最初はエンジニアリソースが限られていたことに加え、当時いたメンバーのスキルセットの理由により、とりあえずRailsで全部作ってしまおうという所からスタートして、SIMシステムをリプレイスする時に、リプレイスするのであれば、WAmazing本体のモノリシックなサービスを現状のまま成長させるのではなく、別のシステムに分離したほうが良いであろうという判断で作った形ですね。その時に、もしWAmazingにひらっちがいなかったら、SIMシステムをRailsで作っていた気がするんですよね。新しいScalaで作られたSIMシステムはすごくいい物ができたなと思っていて、これこそ、ひらっち視点で、Scalaを導入してここでシステムを分離した方がいいと積極的に提案して動いてくれたお陰だと思っています。Railsを選択するよりScalaを選択してシステムを分離した方ががいいという判断は、技術的な観点でどういう点が決め手になった感じですか？

ひらっち：そうですね、前職での経験から、モノリシックなアプリケーションでやっていくとどうしても実装が密結合になって、ぐちゃぐちゃっとしちゃうんですよね。それよりは、SIMは他と関係のない独立した機能ではあるので、一つの塊として捉えて絶対切り出した方がいいだろうとは思っていました。その上で、Scalaは静的型付き言語なので、間違った変更をしてしまったとしてもある程度コンパイラが見つけてくれるため、非常に変更がしやすく、先々のメンテナンスのことも考えるとScalaを導入した方いいだろうと考えました。

舘野：なるほど、SIMシステムにおいては既存とのコンテキストとの関わり合いがすごい薄いので分離した方がいいだろうとまず考え、分離するのであれば今話してくれたようなメリットを生かせるScalaがいいだろうと判断したわけですね。

ひらっち：はい、そうですね。

舘野：別の観点になりますが、個人的には、SIMを新たなシステムに移行してから問題が少ないというのもポイントかなと思っています。SIMシステムは通信の管理を責務として持っているので、しっかりと安定したシステム構築をしないといけない中で、Scalaという静的型付き言語で書かれたシステムで非常に問題が少ないまま運用出来ているということは、リリース後の運用・開発含めた総合的な開発速度を考えると最適な選択なのかなと思っています。私自身、Railsは今でも好きですが、スピーディーに作るには適しているものの、その後のメンテナンスなどを考えると、ちゃんとテストを書かないといけなかったりします。長く運用し続ける時に、適した運用方法とそうでない運用方法があるのかなと思っていて、今回のような通信部分のシステムは、しっかりしたシステムを問題ない形でリリースし、その後機能をどんどん追加していく上では、Scalaの型システムを生かしたものの方がやはり非常に効率が良いと思いました。スピード優先で、短期視点で考えると、PHPやRailsのが早く作れるので適しているかもしれないですが、長期視点で考えると、非常にScalaは安定していて、問題なく動き、かつ、効率が良い開発ができるんだろうなと。今回それをひらっちが、WAmazingで実証してくれたんじゃないかと思っています。

ひらっち：そうですね。Railsは確かに初速は速いですよね。ただ、長期的にメンテナンスしていくとなると、結構難しいのではないかと思います。

Scalaの学習コストは高いわけではない。大事なことは学べる環境があるかどうか。

舘野：ところで、Scalaは、非常に言語自体も良く出来てるし型システムも良く出来ているのですごくいいプログラミング言語である一方で、社内で書ける人材が少ないという問題があるかなと思います。やはり、広く使われてるようなJava、PHP、Ruby、JavaScriptみたいな言語だと使える人材は一定数いるかと思いますが、Scalaを使える人材となると、エンジニア全体の中では限られてくるんじゃないかと。そうした中で、ひらっちがWAmazingでScalaを広めるために行なっている取り組みとかってあったりしますか？

ひらっち：最近は週一回、社内でScalaの勉強会を開催しています。

舘野：率直に聞いてみたいことがありますが、エンジニアがScalaを学習するコストは高いのかそうではないのか、ひらっちの視点でどう思いますか？

ひらっち：確かに、Scalaの学習コストついてはよく言われる話ではありますが、僕自身はそれほど難しいことだとは思っていません。そもそも、新しい言語を学ぶとなると多少のコストはかかりますよね。Scalaに限らず、それはどの言語もそうだと思うんですよ。その中で、Scalaが特別難しいということではないと僕は思っています。
Scalaの言語機能には色々ありますが、それらを最初から全部使える必要はなく、最初に使えるところだけ使っていけばいいと思うんですよね。Scalaというのは、（あくまで実装の一つではありますが）JVM(Javaが動いているバーチャルマシン)上で動いている言語で、Javaから発展したような側面があるので、Javaと似ている部分もあると思います。そのため、Javaが書けるエンジニアであれば、Javaにもあるような機能のみを使って、Scalaのコードを問題なく書けると思います。Javaが書けるエンジニアは割と多いですよね。もちろんScalaの方が高機能な部分はたくさんありますが、別にそういう機能は使わなくとも、ベターJavaとして使うことはできるわけですよね。
例えば最近、Scala未経験の若手エンジニアにScalaのコードを書いてもらっていますが、普通に書けています。Scalaだとvar（再代入可能な変数）とかミュータブルなオブジェクトはあまり使わないのですが、そういうコードを書いていた人が、Scalaになったらいきなりそれをやめないといけないのかというと、そういうことではなくて、Scalaでもvarやミュータブルなオブジェクトを書くことはできます。つまり、最初からScalaっぽいコードを書くとか、色んな機能を使うとかは必要ないと思いますね。

舘野：Haskell等を最初から学ぶと、いきなりハードルが高くなったり、純粋関数型言語ですべてイミュターブルで表記しないといけないとかになると、その言語独特のものをちゃんと覚えなければ使えないということがありますが、その点Scalaは、使いたければ使うことができて、再代入しながら書くこともできるし徐々に言語を覚えてきて、イミュータブルの良さを活かしていくようなタイミングで、Scalaっぽい書き方にスイッチしていくことも可能なので、そういう点ではそれほど難しいわけではなく、とりわけ学習コストが高いわけではないということですね。

ひらっち：その通りです。

舘野：実際、ScalaをやったことがないメンバーにScalaを教えながらWAmazingで取り入れていると思うのですが、今のところ順調ですか？

ひらっち：いい感じだと思いますよ。若手エンジニアも積極的に書いてくれていますし、ScalaでリプレイスしたSIMサーバーについていえば、作った当初はコミットしていたのは僕だけでしたが、その後、別のエンジニアもコミットしてくれています。

舘野：Scalaを触ったことがないエンジニアが、勉強会だけではなく業務でも実際に触る機会があるというのはいいですね。これは個人的な考えですが、エンジニアが学習する時に、分かっている人が隣にいるとすごく心強いですよね。やはり、特に仕事を通じてだと、プルリクエストあげてレビューを行なってというプロセスがある中で、そもそもこれはおかしいと指摘をしてくれる人がいると、言語に対する理解がより深まっていくのかなと思っています。そうした指導を社内でひらっちが率先してやってくれているので、みんなScalaを学びやすい環境があるのかなと思いますね。

ひらっち：ありがとうございます。あとは、Slack上に「Scalaチャンネル」というのがあって、そこでScalaに関する共有を行なったり、あとは疑問点があればそこで聞いてもらうということもやっています。

舘野：誰も詳しい人がいない中で手探りでやるというのは結構大変ですが、Scalaにおいてはひらっちが率先して導入してくれて、かつ、指導やフォローする環境をひらっちが主体となって整えてくれているので、WAmazingは「Scalaをやってみたい！」という人でも覚えやすい環境なのではないかと思いますね。

ひらっち：自画自賛っぽくなってしまいますが、そう思います。Scalaの本も会社の本棚に入っていますしね（笑）

舘野：色々、技術的側面におけるWAmazingの魅力を語ってくれましたが、それ以外にWAmazingの魅力みたいなところがあれば教えてください。

ひらっち：やっぱりそれは、成長に期待できるという点ではないでしょうか。テレビを見ていても、インバウンド関連ニュースが取り上げられることは多いですし、盛り上がってきてますからね。

舘野：そうですね、訪日外国人旅行者が年々増えている中で、WAmazingはインバウンドプラットフォームの雄になれる可能性は十分ありますよね。

（社内の本棚にはScala本を含め技術書が並ぶ　※写真は一部）

リモートワーク成功の秘訣は「コミュニケーション」

舘野：少し話が変わりますが、ひらっちがWAmazingで切り開いてくれたことの一つに「リモートワーク」があるかなと思っていますが、当初、WAmazingにおいては全面的にリモートワークが許容されていたわけではなかったですが、ひらっちがジョインした後に、リモートワークの方がむしろ生産的にコードが書けるので、トータルのアウトプットを考えるとそちらの方がいいと思いますと提案してくれましたよね。全面的に許容されていたわけではなかった中で、実現可能かどうか、ひらっち自身がまず最初に週1リモートを試してみようとなり、今では週2リモートでやっていますが、リモートワークはちゃんとアウトプットが出ているかどうかが重要な中で、ひらっちはリモートでも成果をあげてくれていると思っています。そこで聞いてみたいのが、ひらっちがリモートでも成果を出す上で心がけていることってあったりしますか？

ひらっち：リモートワークの時はだいたい自宅で作業していますが、自宅で作業する時は結構集中できるんですよね。オフィスだと、どうしても周りの音が気になったりしますが、自宅だとそういうのがありませんから。自宅にも作業できる環境を整えているので、集中しやすいですし、設計など集中しなければいけない作業はだいたい自宅でやっています。リモートワークをする上で特に気をつけていることは「コミュニケーション」ですね。オフィスにいないので、どうやってコミュニケーションをとるかが重要になりますが、僕の場合にはわりとSlackを活用するようにしていて、リモートワーク時にSlackをもらった場合にはできる限り素早く反応するようにしたり、Slackは頻繁に見るように心がけています。あとは、Slackの電話機能を活用することも多いですね。今はたくさんツールもあるので、リモートで仕事する上では、工夫次第でそんなに支障はないのではと思っています。

舘野：一般的にリモートワークのデメリットとして「コミュニケーションが取り辛くなる」ということが言われますが、ひらっちの場合には、リモートであっても積極的に情報や状況をキャッチアップしてくれているかなと思います。リモートで出社していないからコミュニケーションが取れず困るというよりかは、Slackで話せば基本的にすぐ返事がくるし、急遽会議を開いて話そうとなった時でも、音声会議などをうまく活用してくれたりだとか、会議に臨む上での準備でいえば、ゼロベースで臨むのではなくて、リモートだからこそ「こういう情報が書かれていると非常に分かりやすく会議に臨めるから書いていきましょう」とか、リモートワークに必要な生産的なやりとりをを行えるようにするための仕組み作りをちゃんと考えてくれていることは、すごくいいなと思っています。ひらっちが率先してこうした取り組みを進めてくれると、WAmazingの他のエンジニアもリモートをやろうと思った時に、それをお手本にできますよね。

ひらっち：ありがとうございます。引き続き、心がけていきたいと思います。

（プロダクト開発メンバーによる社内MTGの一コマ）

会社の成長に従って向き合う課題も変化していく、そこにベンチャーならではの成長機会がある

舘野：最後になりますが、ひらっちが今後エンジニアとしてどうなっていきたいか、どういうことにチャレンジしていきたいかについてぜひ教えてください。

ひらっち：そうですね、僕としては今後も、今のような形で開発を続けていければと思っています。今と同じにといっても、当然ながら、今後成長を目指さないということではありません。今と同じようにこの会社で開発を続けていけば、どんどんサービスは成長していくわけですし、それに従って、会社も成長していくわけですよね。そうすると、その時その時で違った課題が出てくると思うんですよ。僕が入社した時は何もない状態で、ゼロからイチを作り上げるフェーズだったわけですが、そこからいえば今は大きく変わっています。今後もサービスも会社も成長していく過程で、その時その時で違った課題に取り組めると思うので、この会社で仕事を続けていけば、会社の成長と共に自ずと自分の仕事内容も変化していき、成長していけるのではと、そう思っています。

舘野：なるほど、具体的に今後チャレンジしてみたいことは何ですか？

ひらっち：そうですね、さきほども話していたSIMサーバーを切り出して、今では、いくつかサーバーができていますが、モノリシックなアーキテクチャではなくて、マイクロサービス的な、いくつかのサービスを別々のサーバーで作っていくといったそうした設計にしたわけですが、それが今後成長していき、よりサービス規模が大きくなってきた時に、当時の設計で大丈夫だったかどうか、答え合わせのような形で振り返ることができると面白いかなと思っています。答え合わせをした結果、ダメだったとならないように、今後も状況を見ながら、適切なタイミングで軌道修正していくといった、そういう仕事ができていったら面白いなと思っています。

舘野：会社の規模が大きくなると、よりシステムも変容していく中で、技術者としてさらに腕を磨いていきつつ、「歴史を間近で見る」というか、一からできたものがどう変わっていき結果どうだったのか、あの時はこう判断したけど結果それが良かったのかとか、どういうアーキテクチャで組み立てていくと成功に近づけるのかというのは、確かにその通りだなと思いました。理想的なのは、WAmazingがどんどん成長して、それに対してさらなる技術力で解決に臨んでいくということですよね。私自身はWAmazing全体の成長に最大限コミットしたいと思っていますし、ひらっちもそれを技術でどんどんより良くしていくという所にコミットしながら、これからも一緒にやっていけたらなと思っています。

ひらっち：はい、そうですね。引き続き頑張ります。