AWSからエス・エム・エスへ転職したエンジニアの判断軸 - 事業が伸びているから開発環境に投資できる

2020年11月にエス・エム・エスに入社した福嶋です。これまでに国内大手ソフトウェア企業でのシステム開発や、約200万人のユーザーが利用するWebサービスの開発などを経験してきました。

今回は、私がエス・エム・エスに転職を決めた経緯や、現在の仕事内容、今後目指したいことについてお伝えしてみたいと思います。

ユーザーと共にサービス開発に従事する楽しさ

「長いエンジニア人生をどのように過ごすか」

これはエンジニアであれば誰もが考えることではないでしょうか。定年を60才と考えると、エンジニア人生の半分を過ぎたとき、私はどう残りのエンジニア人生を過ごすかを考え、転職を決断しました。この決断に至るまでの流れを少し振り返ってみます。

私のエンジニアとしてのキャリアは、大学卒業後に国内ソフトウェア開発会社に入社し、パッケージ製品の設計・開発に携わることから始まりました。その後、転職してグループウェアサービスの開発チームに所属して、技術責任者を担当しました。ユーザーがいない状態から始まり、最終的に約200万人が利用するサービスまで育てるという経験ができました。

様々な開発を経験しましたが、印象に残っているのはチャット機能の実装です。プレスリリースを出したら、Twitterで「待ってた!」「使ってみたい!」という反応がありました。ユーザーの声に耳を傾けながら開発していたので、実装した機能にユーザーから直接フィードバックがあるのはとても面白かった。

機能の実装によって、サービスの使われ方が変化したのも印象に残っている理由のひとつです。チャット機能が実装される前は、掲示板がディスカッションの場所でした。チャット機能が実装されてからはちょっとした会話や議論がチャット上で起こるように変わっていった。チャットで決まったことが掲示板などにストック情報として記載されるようになり、グループウェアの使われ方が変わりました。

機能実装以外で印象に残っているのは、開発したサービスが社会に対して貢献できているという実感できたエピソードです。ユーザーに在宅医療をしているお医者さんがいらっしゃって、その方がグループウェアを使って患者さん1人につき1つのグループを作り、お医者さんと看護師さんと在宅ヘルパーさんも入ってコミュニケーションしている事例がありました。

その事例ではグループウェア上で、患者さんごとにグループを作り、患者名をグループ名に設定。そのグループに病院の職員のみなさんと、訪問看護ステーションの看護師やケアマネジャーなど、関係するスタッフが参加し、患者さんやご家族が抱えている様々な問題の共有や治療方針、ケアの方針の確認、伝達などに利用されていました。患者さんの状況について共有した情報が他の在宅ヘルパーにも伝わる状態が生まれ、患者さんも何度も同じ説明する必要がなくなった。患者さんはちゃんと見てもらえているという実感が得られ、満足できたそうです。自分が手掛けたプロダクトが社会に貢献できているなと感じられたエピソードです。

事業の強さは健全な開発環境につながる

その会社では8年ほど働いていたのですが、「AWSに来ないか」と声をかけてもらったことがきっかけで転職。AWSでは、まずサポートエンジニアとして、AWSサービス単位のお客様の困りごとを解決する仕事をしました。

サポートエンジニアを2年9ヶ月ほど経験し、仕事の目標を達成したことを機会に、ソリューションアーキテクトへ職種変更しました。ソリューションアーキテクトの仕事では、クライアントの要望や要件を伺いながら、最適なAWSサービスの組み合わせやアーキテクチャをサポートします。私は、ソリューションアーキテクトの中でも、お客様のプロトタイピング開発を支援する仕事をしていました。

ソリューションアーキテクトである私自身はお客様のコードを書いてはいけないという決まりがあったのですが、クライアントと一緒にサービス開発を経験できたことはとても楽しく、サービス開発にやりがいを感じていたグループウェアサービス時代を思い出しました。

AWSでのお客様のサービス開発をサポートする経験を経て、「もう一度サービス開発をしたい」と考えるようになりました。そんなとき、登録していた転職サイトからスカウトメールが届き、これが自分のエンジニア人生としての残り時間の使い方を考えるきっかけとなりました。

「AWSでお客様の開発を支える仕事を続けるか、サービス開発の現場に戻るべきか?」

そう自分に問いかけたときに、開発者として働く方が幸せだと考えました。サポートと開発、両方の仕事を経験したからこそ、この結論に至ったと思います。また、サービス開発の現場に戻るべく、どの業界、どの企業でサービス開発をするかを考えました。

自分のなかでは「市場が伸びている」「事業が伸びている」などの点は重視しました。事業が伸びなければ、給与は上がらず、人の流出が激しくなります。そうすると、開発環境をモダンにするためにリソースを割くのは難しくなってしまう。開発環境が改善されていくために、財務的に健全な企業であることは重要だと考えていました。

その観点を持ちつつ、業界は絞らずに転職活動をしていました。お声がけいただいた企業の中から、エス・エム・エスを選んだのは、複数の観点から検討し、総合的に判断した結果です。先述の事業が伸びているかどうかに加え、モダンな開発環境があるかどうか、自分がサービス開発に従事できるかどうかなどが判断のポイントでした。

エス・エム・エスの市場におけるポジショニングも判断のポイントになりました。手掛けているサービスは、市場においてナンバーワンのシェアではない成長中のものも多くあり、それがよかった。すでに業界一位であれば挑戦する余地が少ないですし、ゼロから事業を立ち上げるのはやりがいはありますが、ハードルが高い。

エス・エム・エスは業界トップになるための挑戦権がある。かつエンジニアレベルやモダンな開発環境を備えているため、近い将来にトップを取れそうだと考えました。そんなエス・エム・エスに自分の経験を加えれば、事業成長をさらに加速できると思いました。

AWSを駆使したアーキテクチャへの移行をリード

他に内定をいただいた会社では、まずはSREとして仕事をして、将来的に開発に関わることはありえるという内容でした。自分は開発の仕事がしたくて転職を検討していたので、入社前に開発を約束してもらえていたのも決め手でした。

入社してからわかったことですが、前職がAWSだったのでエス・エム・エスのエンジニアの方々から「SREをやってもらったほうがいいんじゃないか」という意見も出たそうです。そのとき、エンジニアリングマネージャー(EM)の田辺さんが開発と押し切ってくれたと聞きました。おかげで現在、私は前職の経験を活かして介護事業者向け経営支援サービス「カイポケ」のチームでAWSアーキテクトと開発エンジニアを兼務しています。

入社して経験した大きな仕事は、AWSを駆使したアーキテクチャの移行です。エス・エム・エスは数年前にAWSに移行をしていたのですが、まだまだ使いこなせているとは言い難い状態でした。

カイポケの利用者が増加していくなかで、サービス運用を継続しながら改善や新規機能の開発に耐えうる設計にしていかなければなりません。以前の開発環境は、一部のコードを変更すると別の場所に不具合が出てしまい、新機能開発にも時間がかかってしまうこともありました。

この状況を解消するために、アプリケーション側で実施していた処理の一部をAWSのフルマネージドなサービスに移しています。これによって、アプリケーションがシンプルになり、機能の変更や追加の際に、不具合を発生させにくくなります。これらの開発をうまく進めるというのは、AWSアーキテクトとしての腕の見せどころです。

カイポケでは、新機能の開発に加えて、技術負債の解消、さらには2〜3年に一度の介護業界の法改正に対応する必要があります。まだ入社してから時間があまり経過していませんが、自分の経験を活かしてサービスの改善のために取り組んでいるところです。

もちろん、導入して終わりではなく、いかに運用していけるかが、今後の開発の精度の鍵を握るといっても過言ではありません。AWSアーキテクトとして、継続してシステムの運用に伴走していきたいと考えています。

また、カイポケには色々なチームがあり、どのチームもどのようにAWSを活用するとなおいいのか把握できていない状況。まず、私たちのチームがアーキテクチャを実際に構築することで活用事例を作り、他のチームにもノウハウを提供できるようにしたいと思っています。

変化に対応し、学習を重ねる開発組織

エス・エム・エスに入社して感じるのは、エス・エム・エスの事業領域である介護領域についての新しい知識を学ぶ重要性です。介護領域では、制度改正や改正に伴う現場対応など、目まぐるしい変化が起こり続けています。こういった変化に、どう技術を適用させるかは非常にチャレンジングで魅力です。

また、開発現場もこうした変化に対応できるように日々研鑽を重ねています。会社によっては、納期に追われるエンジニアが大きなプレッシャーを感じることも少なくありません。エス・エム・エスでは、試行錯誤を重ねることを良しとし、開発内容によっては時間がかかることも考慮してもらえています。そのため、事業のために必要な開発に集中できます。

また、他のエンジニアが書いたコードを見てレビューを行うなど、誰か一人に全責任が課されるのではなく、助け合う文化があります。うまくいかない時は原因を一緒に考えるなど、開発組織みんなで課題に取り組むような雰囲気です。

エンジニアのなかには自分一人で開発をしたい方もいるかもしれませんが、こうした開発組織のあり方は学びも起こりやすく、エンジニアとしての成長も加速できるのではと感じます。