スタートアップ出身者のエス・エム・エスでの課題との向き合い方

2021年12月 に入社した丸井です。

エス・エム・エスに入社する前は、大企業向けのソフトウェアを開発している会社や、スタートアップで主にバックエンドの開発をしてきました。

スタートアップは 2 社経験しており、1社目では社長・技術責任者に続く 3 人目の社員として、当時ベータローンチを迎えたばかりだった Web システムの開発をしたり、システムを提供していたパートナー企業の現場に足を運んで課題ヒアリング、時には現場の作業のヘルプに入ったり...と、色々やってました。

2 社目のスタートアップ(前職) にも創業間もないタイミングで加わり、1 社目とは打って変わってユーザーからやや遠い領域のシステムの開発や、技術検証などをやっていました。

そして、現在エス・エム・エスでは、介護事業者向け経営支援サービス「カイポケ」の開発チームに所属しています。

エス・エム・エスを知った経緯

前職のスタートアップでサービスの立ち上げを経て、継続的な開発・運用フェーズを経験するなかで、個人的にプロダクトに向き合えていないと感じる場面が増えてきていました。

なぜそう感じるのか?を掘り下げてみると、プロダクトが提供する価値を理解し、そしてその価値を高めることに貢献できるイメージを持てていない、ということが主な理由だと気づきました。

「プロダクトが提供する価値」というとかなり固い表現ですが、要はそのプロダクトが「誰をどう幸せにするのか」という点についてあまり咀嚼できていない状態でした。そしてそんな状態だったので、今後何をしていけばよいかについても迷子になっていました。

立ち上げフェーズでは作ること自体に没頭し、そして「作ってみないと分からない」ことを理由に疑問の解消を先延ばしにしていたように思います。

自分なりに貢献できることを模索するため創業メンバーと話し合いを重ねながらも、他の道も探ってみたいと感じていたタイミングで、偶然エージェントからエス・エム・エスを紹介してもらいました。

エス・エム・エス入社の決め手

カジュアル面談やその後の選考を通して、高齢社会の課題にアプローチするプロダクトの価値や今後の可能性を感じるとともに、エンジニアチームと事業チームが互いを尊重しつつプロダクトを作り上げている点について、とても良い印象を受けました。

「互いを尊重しつつ」と一言で書きましたが、これは単に仲良くやってるという話ではなく、時には侃々諤々(かんかんがくがく)なやり取りをしながらも誠実に対話を重ねているという意味合いです。

面談でお会いした現場のエンジニアから経営層の方まで、チームの関係性についての話に一貫性があったのも好印象でした。

ちなみに、ちょうど選考を受けているタイミングの前後で、上記のような関係性に至った過去の経緯についても触れられている記事が投稿され、個人的に納得感が増しました。

tech.bm-sms.co.jp

価値あるプロダクト、そして関係者が一丸となってプロダクトを作り上げることができる可能性を感じ、そこに自分も加わってみたいと思う気持ちが芽生えたことが決め手となり、入社を決意しました。

入ってみてどうだったか

前述の内容については、ほぼ期待通りだと感じています。 特に互いを尊重し合う姿勢については想像以上で、一人一人の意見を引き出すことを非常に大切にしています。

反面、意外だったこともありました。

例を挙げると、私は直近スタートアップで過ごしていたため、エス・エム・エスのように成熟したプロダクトを持つ組織では、開発を進めるにあたって窮屈に感じるような場面に出くわすことも覚悟していました。

ところが、これまでそのような場面にはあまり遭遇していません。もちろん全く無いわけではありませんが、前職のスタートアップと比較してみても遜色なく、むしろ自由度が高いように感じる点も多くあります。

このあたりは立ち上げられたばかりのチームに配属されたということとともに、「フェアプロセス」を意識して開発組織が運用されていることも関係しているように思います。

tech.bm-sms.co.jp

蓄積したドメイン知識を掘り下げるおもしろさ

入社してからは、主にカイポケのアーキテクチャ改善に向けたドメインモデリングやプロトタイピングに取り組んでいます。

エス・エム・エスでは、これまで15年以上にわたって上記のプロダクトを提供しており、人・プロダクト・運用オペレーションに豊富なドメイン知識が蓄積されています。

これらドメイン知識をドメインエキスパートと力を合わせて掘り下げることで、これまでに積み重ねてきた価値を再発見できることは醍醐味です。

例えば、一見冗長な作りに思えるところに現場でありがちなミスを防ぐための工夫が盛り込まれていたり、無駄に思える運用オペレーションにユーザーの満足度を上げるポイントが含められていたり。

同時に今では不要になった機能や形骸化したオペレーションも蓄積しているので、それらを解きほぐすことができるのも、ある意味醍醐味と言えます。

エス・エム・エスでの課題との向き合い方

エス・エム・エスの開発チームの特徴として、個人の裁量の大きさが挙げられます。 課題解決方法を自由に選択できるというだけでなく、そもそもどんな課題に取り組むかも自主的に決めることができるため、入社当初は多少戸惑うほどでした。

そのような環境で個人的に意識しているのは、まず自分がやりたいことを考えた上で、周りを巻き込んだ時に良い影響がありそうであれば巻き込んでみる、というものです。

例えば、現在所属しているチームではドメインモデリングと並行して技術選定や開発運用の感覚をつかむための「実装トライアル」を実施していますが、これも元々は個人的にコーディングする機会を確保したいと感じたことをきっかけに、チームメンバーに呼びかけて始めたものです。

呼びかけた当初は、Kotlin や GraphQL のキャッチアップ、そして最近あまり使っていなかった AWS に少しでも触れる機会が作れると良いな、というくらいに考えていました。 ところがトライアルを始めてみるとメンバーから次々にやりたいことが出てきて、結果、GraphQL のフェデレーションを試したり、将来的に必要になりそうなアクセス制御のパターンを実装してみたり、AWS の CDK Pipelines や AppMesh が整備されていったりと、自分一人では考えつかなかった様々な取り組みにつながっています。

このあたりは同じチームの空中さん @soranakk の入社エントリでも触れられている内容です。

tech.bm-sms.co.jp

社内の他のチームにおいても読書会や勉強会が盛んに行われているので、周囲を巻き込んだり、面白そうな企画に参加してみるということが、エス・エム・エスの開発チームの文化として浸透しているようです。 (ちなみに、私が今社内で参加している会は『モノリスからマイクロサービスへ*1』読書会、『Node.js Best Practices*2』勉強会、『Production Ready GraphQL*3』読書会などです)

前述したとおり、入社当初は個人の裁量の大きさに戸惑うこともありました。しかし、今では個人の裁量に委ねられているからこそ、自分に合った課題との向き合い方やプロダクトへの貢献の仕方を模索できる環境になっていると実感しています。