はじめまして、エス・エム・エスでSREとして介護事業者向け経営支援サービス「カイポケ」の開発・運用に携わっている小笠原です。
2022年10月に入社してしばらく働くなかで組織やプロダクト開発の状況がある程度見えてきたので、入社エントリを兼ねて自身の所属するチームや仕事について紹介します。
内容は現在のスナップショットにはなりますが、中で働いている人や組織の雰囲気、向き合っている課題について今後入社を検討される方の参考になると嬉しいです。
入社までにやってきたこと
先に自身の経歴について紹介しますと、情報系の大学院を出て2017年からIT業界で働き始めて今年で6年目です。ポジション的にはいわゆる中堅どころのエンジニアです。新卒でSIerに入社してSEとして顧客の比較的規模の大きなWeb基盤の開発・運用を1年ほど行い、そこからWebベンチャーに転職して4年半ほど中規模なWebシステムの開発・運用に幅広く携わりました。
前職ではReact/Railsを用いたアプリの機能開発を経験し、その後は基盤開発に軸足を置いて基盤の構築・運用やアプリと基盤の間に落ちるような諸々の課題解決に取り組んでいました。
個人的に興味のあった課題（フロントエンド/バックエンドの機能開発、アプリのパフォーマンス改善、基盤の刷新、CI/CD構築、セキュリティ強化、モニタリングの導入・運用、コンテナオーケストレーションツールを用いたアプリ開発など）を一通り経験でき満足したことと、コンフォートゾーンに入っていたこともあり一度環境を変えようと考えたのが転職のきっかけです。
Web開発に関して一通りの経験は積めたものの技術的にはまだまだ未熟と感じていたため、これまでの経験を活かしつつさらに経験を深められる会社を探していました。
エス・エム・エスを知ったきっかけ
そんな中、LinkedInでEMの古萱からメッセージをもらったのがエス・エム・エスを知るきっかけでした。それまではエス・エム・エスについては会社の名前も知らなかったのですが、メッセージに添えられていた技術責任者田辺のブログを読んで興味を持ちました。この記事では「継続性アーキテクト」という概念で技術を深める方向のキャリアを説明しており、技術志向のエンジニアに寄り添った考え方に感銘を受けました。そのような考え方を持った人が運営する組織であるなら一度話を聞いてみたいと考えました。 そして、実際に転職活動を行う中で採用要件や向き合っている課題について話を聞く中で私がこれまで行ってきた経験が多く活かせそうだと気づき応募するに至りました。
入社の決め手
複数社を受けて総合的に判断した結果入社を決めたので「これで決めた！」というものはないのですが、エス・エム・エスが他と比べて良いと思ったのは以下の点です。
- ビジネスモデルが強い
- 医療介護業界は今後も需要が伸びるためそこをターゲットとしているエス・エム・エスは継続的に事業が発展する可能性が高く、エンジニアとして長期でコミットできそうと考えました。
- 事業に興味を持てた
- 私は自分が携わったシステムやサービスが最終的にどんな価値を社会に提供できているかが仕事のモチベーションになっています。エス・エム・エスが取り組んでいる医療・介護領域の事業はその点提供価値がわかりやすいため取り組みがいがあると考えました。
- 課題が多くて挑戦の余地がある
- サービスおよび機能の数が多く歴史もあるため、課題が多く取り組む仕事の範囲も広くて飽きないと考えました。よい設計で整理が進んだプロダクトの場合、かえって面白い仕事がない場合もあるので課題が多いことは自分は肯定的に受け取りました。
- 個人の裁量や動きやすさがありそうに見えた
- 大企業ではあるものの開発組織は人数的にも体制的にもまだまだ発展段階にあり、開発者個人の裁量が大きく動きやすさがあると考えました。また、組織の技術責任者やリードする立場の方がいわゆるWeb系の企業出身者が多く、エンジニア個人の動きやすさに配慮している印象を受けていました。
実際に入社してからは「カイポケ」というプロダクト（後述）およびそのリニューアルプロジェクトにSREメンバーとして関わって働いています。２つのチームで色はそれぞれ異なるのですが、自分が入社前に抱いていた組織やチームへの印象は入社後も大きく変わることはなかったように感じています。
関わっているサービス「カイポケ」について
「カイポケ」は介護事業者向けのSaaSです。
介護事業者が国の保険制度を利用する際の請求業務を行ったり、事業所職員がタブレットから記録業務を行ったり、それ以外にも介護事業に関わる様々な業務をこのサービス上で行うことができます。
カイポケの現行システムは開発開始から10年以上が経過しており、当初は主に外部のリソースを利用して開発していたところ、その後内製化に舵を切って取り組んできた歴史があります。現在４万を超える事業所で導入されており、40個以上の機能を備えています。
機能・ドメインごとにサーバが分割されているためサーバ台数は多いものの、主となるシステムの基盤構成はシンプルでALB、EC2、RDSをベースとした一般的なWebアプリを想像してもらえると良いかと思います。アプリケーションサーバのレベルでは分割されているものの、DBなどのリソースのアプリケーション間で共有されているため、システム全体としてはモノリシックな側面も残っています。
ところで、先日以下の記事でもご紹介したように、現在、この現行のシステムをリニューアルするプロジェクトが進んでいます。
リニューアルをすることにした理由はいくつかあるのですが、先述のようにモノリシックな部分があるがゆえに変更の影響範囲が広くなりやすいこと、また、共有されているリソースの存在が組織全体の開発スピード向上のボトルネックになりうること、などがSREチームに関わる部分として挙げられます。
そのような背景のなかで私は現行「カイポケ」（以下、現カイポケ）のSREとリニューアルプロジェクトのSRE、２つのチームにメンバーとして関わっています。それぞれ向き合っている課題と求められる仕事に違いがあるため、雰囲気がわかるよう簡単に紹介していければと思います。
現カイポケのSREについて
まず現カイポケのSREの責務ですが、開発・運用含め基盤関連の仕事全般と言うような形でふわっと与えられています。開発チームからの依頼対応や各種基盤リソースの障害対応、各種コンポーネントのバージョン更新、脆弱性対応などインフラエンジニアという括りで担当が分かれるような運用寄りの仕事もあれば、リリース改善やトイルの削減、プラットフォームのモダン化と言った一般的にSREが担当するような仕事まで様々です。
その中で何を優先してどこまで手を出すかはチームの体制・余力に応じてチーム内で調整するようになっており、チームの裁量は大きいです。チームが少数体制だったときには現状維持を主な目的とした「守り」の施策に集中していたときもありましたが、現在では人員が増えたこともありチームの業務範囲を拡大して現状改善を主な目的とした「攻め」の施策の割合を増やしているところです。
例えば直近で進んでいる施策には「バッチ実行基盤のマネージドサービスへの移行」、「デプロイ自動化」、「オブザーバビリティ改善」などがあり運用負荷削減や開発効率化、システム安定性向上といった現状からの改善を図っています。
現カイポケはシステムが少し古い構成で動いていることもあり、仕事の傾向としては現代的な構成や運用に持っていくことで価値が出ることが多いです。アプリは介護ドメインの複雑さを反映してビジネスロジックは複雑である反面、非機能要件はシビアではないため基盤側は世の中的によく使われているWebアプリケーション運用のベスト・プラクティスを正しく導入できれば着実に改善を進めることができるように見えています。
ただ、プロダクトの主たる部分がモノリシックな作りということもあり変更の影響範囲が広くなる傾向があります。新しい技術スタックの導入を試みると、検証中に思わぬ箇所で導入を妨げるような課題にぶつかります。課題にはいろいろな種類があるのですが、経緯を紐解いて地道に解決の道筋を作る必要が出ることが多く、歴史の長いプロダクト特有の難しさを感じます。
個人的にはそのような課題がある中でうまく差し込めるような解決策を考えるのがパズルゲームのようで面白いと考えています。技術責任者やEM、アーキテクトの方々も「過去のしがらみは気にせずどんどん改善を進めてくれたら良いよ」と肩を押してくれるので、今後もSRE主導での改善活動に積極的に取り組んでいきたいと考えています。
リニューアルプロジェクトのSREについて
一方でリニューアルプロジェクトのSREの責務はプロダクトが初期構築のフェーズということで柔軟性を持って動くことを期待されており、明確な定義はありません。ただしチームの大きな目標としては「システムが安定して動いている状態」と「システムを早く世の中にリリースできる状態」を維持することを目指して動いています。
SREの立ち位置がわかりやすくなるので先に開発体制について説明しておくと、リニューアルプロジェクトではアジリティの高い開発体制を目指しており、これを実現するため開発チームには基盤リソースのアクセス権限が与えられています。開発チームがオーナーシップを持つサブシステムごとの基盤リソースについては開発チームが管理するため、SREチームはシステムの全体設計や共通コンポーネントの管理を始めとするシステム横断の技術課題の解決に集中できるようになっています。
例えば直近の仕事で言うと以下の記事で紹介しているように「OpenTelemetryの検証」や「本運用を見据えた監視体制の整備」などに取り組んでいます。
リニューアルプロジェクトではシステムを０ベースに近い形で設計しているため、制約が少ない中で技術選定や開発が行える環境です。もちろん技術の導入には妥当な選定理由は必要ですが、検証で該当技術の成熟度を測って導入判断を行ったり新しいバージョンのライブラリの使い勝手を試したりを気軽にできるのは新規構築ならではの楽しい部分だと考えています。
現在リニューアルプロジェクトでは初期バージョンのリリースに向けて動いており、運用基盤もそれに合わせて整備を進めていく段階です。SREチームでも開発状況に合わせて様々な施策を担っていくことになるので、自分でもどんどん手を動かしてプロジェクトの成功に貢献していきたいと考えています。
まとめ
個人的な転職の経緯から、現在関わっているチームや仕事について簡単に紹介させていただきました。これを読んで「カイポケ」のSREチームの雰囲気や普段どのような課題と向き合って仕事をしているかについて理解が深まると嬉しいです。
どちらのSREチームも開発状況が日々少しずつ更新されているため、本文では敢えて具体的に利用している技術の話やシステム構成の話、組織内の詳細な体制の話などは省略しました。より具体的な話や今後の見通しなどが気になった方はぜひ一度カジュアル面談にいらしてください。
