「あまり独立志向のようなものはなくて。所属している組織の中で、自分に任された開発を淡々とやってきた感じです」
自身のキャリアについてこう振り返るのは、プロダクト本部 プロダクト開発ユニット プロダクト開発二部 サーバーサイドエンジニアの高橋。そんな彼がChatworkにジョインした理由、サーバーサイドエンジニアとしてのやりがい、そして今後のキャリア展望について聞いてみました。
■プロフィール
髙橋 治
プロダクト本部 プロダクト開発ユニット プロダクト開発二部
大学卒業後、スマートフォン向けアプリやゲーム、映像コンテンツの製作等を行うフリュー株式会社に新卒入社。Webサービスやスマートフォン向けアプリ開発、バックエンドチームのテクニカルリードを経験。2022年4月にChatworkへ入社し、サーバーサイドエンジニアとしてサービスのバックエンド開発を担っている。
昔から、初めて見るものにはついつい触れてみたくなる性格だった
──これまでのキャリアについてお伺いしたいのですが、まずはエンジニアを志したきっかけについて教えていただけますか？
特にこれといったきっかけがあったわけではないんですが、強いて言えば、小さい頃からゲームやコンピューター（PC）には興味があったように思います。ただ、そこまで熱中して何かをやっていたというより、触れたことのないものに触れてみたい、それまで自分が知らなかったことを知ってみたい…という単純な好奇心ですね。猫の目の前に毛糸の玉を置くと、猫が勝手に遊び始めてしまうような感じです。
──好奇心からついつい触れてしまった…という、何か具体的な例はありますか？
たとえば、中学生のときに塾の先生から「Linuxというものがある」ということを教えてもらって、なんとなく興味を持ったんです。当時はまだプログラミングという言葉すら知らなかったですし、PCについても特に何の知識もありませんでした。「Linux」が一体何なのかもわからないのに、興味本位で家のPCに勝手にインストールしてしまい、PCを壊してしまったことがあります。
──まさに好奇心が高橋さんを動かしていますね（笑）。その後、コンピューターに興味を持って、大学でプログラミングを学ばれたということなんでしょうか？
いえ、大学は情報学科でコンピューターサイエンスを学んでいましたが、コンピューターに関する基礎的な理論が中心で、授業の中でプログラミングに触れる機会はほとんどありませんでした。授業で扱われる際も、プログラミングは目的ではなく手段の一つとして扱われることが多かったですね。
──なるほど。ではそもそも、プログラミングを学びたいということで学部学科を選ばれたというわけではなかったんですね。
はい、ちょっと乱暴な言い方をすると、高校のときにたまたま理系科目が得意だったから理系に進んだというだけで。その中から「勉強するならコンピューターなのかな」となんとなく感覚的に学びたいことを決めましたし、当時はまったく将来のこととかキャリアについては考えていませんでしたね。
Twitter（X）に触れたことをきっかけに、Webサービス開発に惹かれていった
──では、そこから一社目のキャリアにはどのようにつながっていくんでしょうか？
僕がインターネットに触れたのは大学生になってからなんですが、HTMLとかCSSを使ったWebサイトのつくり方なんかを調べていく中で、次第にWebサービスに興味を持つようになりました。当時、Twitter（現：X）が使われ始めたタイミングでしたが、Webサービスとしてのつくりもそうなんですが、僕はAPIというものをここで初めて知ったこともあり、ネット上でサービス同士をつなぐAPIに漠然と興味を持ちました。
そのため、就職活動時もWebサービス開発やシステム開発を行う企業を中心に応募し、スマートフォン向けアプリ等の開発を行うフリュー株式会社に入社しました。
「知らない→わかる→使える→できあがる」というサイクルがたのしかった
──本格的にプログラミングを学ばれたのは入社後だと思いますが、実際にWebサービスの開発に携わってみていかがでしたか？
まず、僕はとても運が良かったと思います。というのも、この点はChatworkもそうなんですが、フリューでは新卒入社の社員に対する教育が非常に手厚い環境でした。同じ部署に同期入社が3名いたんですが、それぞれに指導役の社員がついてくれて、仕事についてもそれ以外のことについても気軽にいつでも相談できました。また基礎的な研修の他に、TwitterのようなWebサービスを半年くらいかけてつくってみて、それをまわりがサポートしてくれて、できあがったらフィードバックを受けられるといった内容の研修もあり、スキル獲得の機会となりました。
──新人研修や入社後のフォローアップで開発に関する基礎を学ぶことができたんですね。
さらに、これは当時のビジネスにおけるタイミングもありますが、実際の業務においては比較的規模の小さなサービスを短期間のうちに複数つくるということをやっていまして。僕が所属するチームだけでも常に4～5つくらいの開発や運用を並行して進めていて、それも基礎となるパターンはだいたい同じだったため、ここでエンジニアとしての基礎がつくられたように思います。最初は知らなかったことを学んで、理解して、使えるようになって、サービスができあがる…という経験を重ねていくうちにスキルも身につきましたし、なによりも「サービス開発ってたのしい！」という実感を持つことができました。
──新入社員教育に対して職場全体が積極的であったことと、小さな開発サイクルを何度も経験できたことが、「運が良かった」ということなんですね。
そうですね。実際に経験してみないとなんとも言えませんが、もし最初から大規模なサービス開発を担当することになっていたら、新入社員としては開発の一部分にしか携われなかったかもしれませんし、全体像を把握するまでにもっと時間がかかっていたように思います。僕の場合は小規模なサービスばかりだったため、技術同士の接続も理解しながらサービス開発の全体像をつかむことができました。
キャリアのターニングポイントは、バックエンドのテクニカルリード経験
──4年目以降、主にバックエンドチームのテクニカルリードを担当することになるんですね。
タイミング的にはちょっと想定外というか、いろいろな事情があってやむを得ず僕が担当することになったんですが、振り返るとキャリアの一番大きなターニングポイントになっているかと思います。
──ご自身的にはちょっと想定外のキャリアだったんですね？
このときのチームでテクニカルリードを担当していたエンジニアの方が抜けてしまったんですよ。開発が軌道に乗るまでは少人数で進めようという話をしていたためリソースも限られていて…事実上、バックエンド専属の開発者が僕一人になってしまいました。
全体設計や、フロントエンド側とアプリゲーム側とのやり取りを一人で切り盛りすることになってしまいまして。今でこそ「これが良い経験になった」と振り返ることはできていますが、当時は本当にたいへんでした。
──どういったところに最も苦労されたんでしょうか？
当時はわりと新しい技術スタックを使っていこうという話がチーム内でも出ていて、そういった新しいことにチャレンジしようという機運が高まっていたんです。そうした考えについては僕も同意していたんですが、何でもかんでも新しいことに挑戦すれば良いのかというとそうではないと思っていて。できるかどうかわからない挑戦の部分を何割くらい採り入れるかというバランスというか、挑戦していく部分の見極めが大事なんじゃないかと感じました。
──なるほど。サービス全体を俯瞰してバックエンドを担うエンジニアとして、そういったバランス感覚が養われたのがこのときだったんですね。ちなみに、そうした見極めはどういった観点で行うものなんでしょうか？
やっぱり一番重視するのはユーザーの体験です。新しい技術スタックを使ってみても、ユーザー体験として特に大きな差がないのであれば、敢えてリスクを増やすことなく、確実な方法を採るべきです。私もエンジニアとして、新しいことに挑戦したいという思いはもちろん持っているんですが、ここのバランス感覚は自分の役割としてブレずに持っておこうと考えていました。
──フリューさんでの後半のキャリアでもバックエンドのテクニカルリードを担当されていますね。ここでもやはりバランス感覚を大事にされていたんでしょうか？
ここではどちらかというと、新しいことへのチャンレンジに寄ったバランス感覚ですね。後半に担当していたのは、僕がジョインした時点ですでに10年以上継続しているようなアプリケーションだったのですが、運用していくうえでいわゆる技術的負債と呼ばれるものが生じてきます。増改築を繰り返すうちに整合性がきっちり取れない部分です。家に例えるなら、渡り廊下部分が若干斜めになっているとか建付けが悪くなっているとかそういうイメージでしょうか。もちろん渡ることはできるんですが、小さな段差につまずいて転んでしまう危険性もあります。そうした部分を解消していこうという動きはあっても、さまざまな事情から手がつけられずに放置されてしまうことが多いのですが、そこを放置せずに最後まで進めることが僕の役割でした。
──ここでは、どのような経験や学びが得られたんでしょうか？
起こっている事象、部分だけに注目するのではなく、現状を把握したうえで、どうすれば理想の状態に近づけるのかというベストな方法を選択することです。自分がメインで全体の絵を描くわけではなくても、サービスの全体像と現状を把握したうえでどのように切り盛りしていくのかというところは、現在Chatworkで担っている部分にも生かされていると感じています。
「大規模分散システムに携わってみたい」という純粋な好奇心から、転職を決意
──ではいよいよChatworkでのキャリアについても伺っていきたいのですが、まず転職のきっかけについて教えてください。
当時、「Scala関西Summit」という勉強会がありまして、もともとイチ参加者として勉強会には参加していたんですが、途中からスタッフ側でもお手伝いするようになりました。スタッフにはChatworkのエンジニアも多く、そこで知り合って声をかけていただいたものの、そのときはまだ転職の意志はなく、お断りしていました。ただ、しばらく経ってからまた、転職サイトに置いてあった自分のポートフォリオを見ていただいて再度お誘いをいただきまして。そこからカジュアル面談をさせていただいた、という経緯です。
──エンジニアとしてのキャリアという面では、Chatworkのどのような部分に魅力を感じていましたか？
前職の仕事にもやりがいは感じていたのですが、扱っているものはいわゆるクラシカルなWebサービスが中心でした。サービスの規模は大きくても、スケールしたクラシカルなWebサービスという感じです。その点、「Chatwork」はシステム自体がいわゆる大規模分散システムと呼ばれるもので、おそらく前職のままだと自分は一生触れることのない領域なんです。「このままここにいると、この先絶対に経験できないことに触れてみたい」というのが転職のモチベーションになっていたと思います。
安定稼働を維持しながら新たなユーザー獲得、そして機能拡張をめざしたい
──あらためて、Chatworkでの現在の仕事内容を教えていただけますか？
「Chatwork」は2011年にサービスを開始して、もう10年以上続いているサービスなんですが、まさに技術的な負債に立ち向かっている状況です。そうした中で僕は、将来的なサービス拡大や機能追加に向けてバックエンド部分のリライトを行っています。
──前職との違いを感じる部分はありますか？
担当している領域としては前職と変わりませんが、やはりまずシステムとしての規模感が違います。また同じリライト作業であっても、機能追加やキャンペーンのようなものに対してエンジニア発信で行っていくのではなく、Chatworkの場合は経営陣も含めて課題感を持って取り組んでいるという点は大きな違いかもしれません。
ただそれ以外の部分では、良い意味で大きな変化はあまり感じていなくて。きっと、エンジニアにとって良い環境から、良い環境へと移って来られたんだと思います。
──Chatworkとしての「良い環境」は、どんなときに感じられますか？
これもまた前職とも共通している部分ではあるんですが、エンジニアとして純粋な気持ちを持っている方が多い印象です。仕事だから仕方なく、お金のためだけにやっている…ということではなくて、問題解決にフォーカスできるというか。ビジネスとしての問題解決に対して、何か別のことを心配したり気兼ねしたりすることなく、エンジニアリングの力で真正面から向き合うことができる環境だと思います。
──では最後に、Chatworkでこれから挑戦してみたいことがあれば教えてください。
これはシステムとして当たり前のことかもしれませんが、「Chatwork」がネガティブな意味で話題にならないようにしたいと思っています。多くのユーザーに利用いただいているからこそ、「Chatwork」が使えなくなってしまうと、SNSやニュースサイトでも話題になってしまうんです。ユーザーが今後増え続けても、そういうことが起こらないような安定的なシステムの根幹を担いたいですね。
そうした安定稼働を維持したうえで、将来的にはもっとユーザー自身がカスタマイズできるような機能があるとおもしろいんじゃないかと個人的には考えています。社内でも「Chatwork」は使われていて、「さらにこういうことができると良いよね」「もっとこんな機能があったら良いんじゃないか」といったアイデアは、エンジニア同士でも日々会話しています。そうしたプラスアルファの部分、「Chatwork」のさらなる進化にも携わる開発ができると良いですね。
撮影場所：東京オフィス（WeWork 日比谷FORT TOWER）
