クラスメソッドに数多くある採用応募職種から、どの部門に申し込もうか迷われている方も多いかもしれません。そこで2019年現在、AWS環境のセキュリティ監査サービス「insightwatch」の機能に関するサービス開発 / 運用支援をする伊藤祥がどのような職歴を経てクラスメソッドへ応募したのか、その際どのような意図で転職応募先を選んだのかをご紹介します。

“自分で手を動かしてつくる” ソフトウェアエンジニアとして働きつづけたい

私は小学生の時にMSXというパソコンでBASICに触れてからプログラミングに興味を持ち、中学生のときにはソフトウェアをつくる仕事をしたいと思っていました。情報系の高校に行きたかったのですが通える範囲に無く、機械いじりも好きだったため、機械科のある高校に入学しました。

高校時代はC++（当時のBorland C++ Builder）やインターネット、FreeBSDに触れる機会を得て、さらにソフトウェアをつくる仕事をしたい気持ちを高めていったのを覚えています。

大学、大学院は念願叶って情報系に進学することができました。大学院卒業後は、自分で手を動かしてサービスをつくるのが好きなこともあり、ずっと自社サービスやサービス基盤開発のソフトウェアエンジニアをつづけてきました。

私がクラスメソッドのことを知ったのは、今から10年以上前にさかのぼります。当時は福井に住んでいたのですが、やはり都市部と比べるとエンジニアの数も少ないですし、なかなか技術者が集まるようなコミュニティや勉強会がないような状態でした。

そこで、当時興味があったAdobe Flexの開発者が集う場をつくりたい、という思いから、クラスメソッドの社長 横田聡が立ち上げた「Flex User Group(FxUG)」というグループの北陸活動を、石川、富山、福井の3県が共同して始めました。

その活動のなかで横田とは知り合いになりましたし、その活動に関わっていた一部の社員とは交流がありました。Adobe主催のイベントに出席すると顔を合わせることも多かったですね。

クラスメソッドの自由な雰囲気は当時から感じていて、社長の自由な動き方ももちろんですが、元エンジニアがトップの会社で、エンジニアフレンドリーな社風が魅力的に見えていました。もちろん「DevelopersIO」のブログもよく目にしていたので、クラスメソッドへの親近感は持っていました。

転職タイミングで自分の課題や目的意識を確認することが、マッチングにつながる

私はこれまで5社ほどに勤めてきましたが、自社プロダクトか、自社プロダクトを支えるサービス基盤の開発をしてきて、受託というのをやってきませんでした。

そんなこともあって、転職先を探す時は自社プロダクトの開発をしている部署を探すようにしています。社内で「こういうものをつくろう」と決めて、それを一緒につくっていく、という流れが好きなんだと思います。

一方で最近は、オンプレからパブリッククラウドへとスキルシフトしたいという気持ちが強くなっていました。前々職ではオンプレが100%、前職ではオンプレ（プライベートクラウド含む）とパブリッククラウド（AWS/GCP）とが半々くらいだったので、今回の転職を機にパブリッククラウド100%で自社プロダクトの開発をしたいと思っていました。

また、コンサルティングやマネジメントだけでなく、サービス改善のためにKPIモニタリングをして、仮説を立て、自分で開発・運用をしたい希望もありました。

そんななかで、今回の転職先を探しているときにクラスメソッドの募集を目にしました。クラスメソッドという会社そのものは受託開発が多いのですが、自社サービスがあることは知っていましたので、「それを開発しているのはどこだろう？」と、募集職種から内容を探していき、「ここだろうな」と思ったAWS事業本部プロダクトグループへ応募したという流れになります。

私が転職にあたって重視していることは、実はタイミングによって違います。エンジニアフレンドリーな会社への転職時には「技術的におもしろそう」「Web系のサービスをやりたい」「大量のトラフィックを扱える」というようなモチベーションで移りましたし、「妻や子どもが将来使うであろう一般向けサービスに関わりたい」という動機で転職先を決めたこともあります。

今回のタイミングでは子どもの存在が大きかったです。これまでの仕事では子どもが眠ってから帰るような生活で、関わりの薄い父親だったので、もっと子どもと接する時間を増やしたいという思いがありました。そこで、リモートワークや「ふるさと勤務」の制度が充実しているクラスメソッドは魅力的に見えましたね。

ふるさと勤務・リモートワークが“当たり前”の職場環境におどろいた入社当初

クラスメソッドに入って最もおどろいたのは、リモートワークが想像以上に“当たり前”になっていて、決して特別な働き方ではないことです。会議室にはオンライン会議をするための機材がすべて揃えられていますし、ミーティングを招集するときも必ずオンラインでのミーティングURLが送られてきます。

このシステムがあるため、「当日はオンラインで参加します」という連絡も必要ありません。それぞれの予定に合わせて会議に参加すればいいので、実際に当日、会議室に行ってみなければ誰がいるのかわからないくらいです（笑）。

さらに、私のチームは社内でも突出して「ふるさと勤務」の割合が多く、今は6名のうち4名が常時リモートでの勤務で、東京、静岡、福島（郡山）、福島（会津）、富山というように5ロケーションにわかれています。

現時点で社内の「ふるさと勤務」は10人程度とのことなので、約半数が私のチームにいることになります。私自身、こういうリモート前提の勤務環境は初めてだったので、入社当初はメンバーの抱えている課題をどう探っていけばいいのか、戸惑いがありました。

でも、社内環境に慣れてくると、オンラインミーティングの仕組みは整っていますし、今はSlackやChatworkなどのコミュニケーションツールがありますので、大した問題ではないことに気付きました。

不便なことといえば、その場でラフスケッチしたものを共有しにくいことくらいでしょうか。今は自分も週の半分くらいはリモート勤務していて、そのおかげで子どもを保育園に迎えに行けるようになりました。

今は東京にいますが、夫婦共に実家が東京ではありませんので、いずれは私も「ふるさと勤務」をするかもしれないな、と思うことがあります。

子どもの進学タイミングに合わせて検討したいと思っていますが、「ふるさと勤務」を実現するためのインフラがすでに整っていて、実際に活用されていることは、クラスメソッドに入社して魅力に感じられるところのひとつです。

「こんなことできませんか？」にスピード感をもって応えることが喜び

今ちょうどクラスメソッドは成長の時期で、どんどん社員が増えてきています。私が所属する「insightwatch（インサイトウォッチ）」のセキュリティチェック機能のチーム、ジョブ機能のチームも、入社当初はそれぞれPM1人と、各オフショアチーム、それらを横断して私が支援する形でした。

しかし、今年に入ってから両チームに1名ずつメンバーが加わり、開発速度が加速してきました。そんななか、私は今、グループ全体を見回して課題を洗い出し、自動化されていないところをしたり、開発の改善提案をしたり、ツールを考えて設計して実装して運用するところまでやらせてもらう立場です。

これまでAWS Amplify Consoleを導入して、構築・デプロイフローの簡素化をしたり、Nuxt.jsを利用したシングルページアプリケーションとしての実装、サーバレスマイクロフレームワークAWS Chaliceを利用したAPI開発を進めてたりしてきました。

技術的なトライアルへの裁量があることで「こんなことできます？」と問われた2～3時間後には「こんな感じでどうですか？」とスピーディーに実装・リリースでき、メンバーから感謝のフィードバックをもらえることにやりがいを感じています。

私はコードを書くことが好きなので、クラスメソッドのメンバーが困っていることや不便なことがあると、解決策となるツールを試行錯誤して提供するということを部署を横断して行っています。

クラスメソッドは技術ブログの「DevelopersIO」が有名なんですが、自分はあまりブログをたくさん書く方ではないかもしれません。その分、コードを書いて貢献していくことができればなと考えています。

これまで仕事以外でも、趣味と実益を兼ねて、ElasticsearchやJava、Webフロントエンド周りなどのエンジニアのコミュニティに登壇してきました。またハッカソンには積極的に参加し、運営に携わったこともあります。

東京に来てからもさまざまな勉強会に参加していますし、これからも引きつづき社内外問わず、技術コミュニケーションへの貢献をしていきたいと思っています。