カイポケリニューアルプロジェクトってどうなの！？入社・参画から半年経ったエンジニアに聞いてみた！

はじめまして。@kimukei です。

2022年9月1日からソフトウェアエンジニアとして株式会社エス・エム・エスで働いています。

この記事では、「カイポケリニューアルプロジェクト」（以下「リニューアル」）とこの会社について、最近ジョインした私の目線から実際どんな感じなのかを掘り下げていきます。興味を持っていただけている方にチームの雰囲気や文化などが伝われば幸いです。

リニューアルについては以下のサイトもぜひご覧ください。

careers.bm-sms.co.jp

これを書いている人

2018年に新卒で株式会社LIFULLに入社してからずっとWebの領域でフルスタックに色々エンジニアリングしてきました。正社員エンジニアとして働きながら副業エンジニアとしても複数の会社でプロダクトを手がけていたりと精力的に活動してきました。前職のBASE株式会社では主に顧客管理システムのローンチや新機能の開発のリードをしてたりしていました。

詳しくはここにまとめていますので興味があれば覗いてみてください。

https://kimuchanman.github.io/self-introduction/

では早速本題に移ります。

そもそもなんでエス・エム・エスに入社したの？

まず、エス・エム・エスをどうやって知ったかですが、一番最初は転職ドラフトの指名です。私の場合、指名いただいた企業様の指名理由やテックブログなどに目を通してからお返事していました。

エス・エム・エスはテックブログやドキュメントから、アーキテクトを定義しアーキテクトへのキャリアパス*1 *2があることが伺えて興味を持ちました。組織によってアーキテクトの役割が異なりフワッとしがち、なんならアーキテクトという役割は設けていなかったりする中、自組織におけるアーキテクトの役割や考え方を明確に語っている組織は多くないと思います。

選考の前に、カジュアル面談を通して介護領域の複雑さと、2025年問題や2040年問題などの近い将来に迫った問題について説明していただきました。

日本が高齢化先進国になるということは、それを支えるシステムは高齢化社会の世界的なモデルとして模倣されるようになるはずです。そのため介護業界は近い将来、日本が世界をリードする領域になり得ることに関心を持ちました。

エス・エム・エスとはカジュアル面談を3回行なったのですが、リニューアルの指揮を執っている三浦さん*3とのカジュアル面談では、プロジェクト概要や開発プロセスを説明してもらいました。

開発プロセスについては Domain-Driven Design Starter Modelling Process に沿った本格的な DDD のプロセスを導入しており、実際に介護現場での経験が長い方がドメインエキスパートとしてプロジェクトにジョインしているということを知りました。ここまでしっかりした DDD のプロセスを組織全体で実行するのは相当な体力がないとできないことだと思い興味が深まりました。

また、介護ドメインは複雑ながらも、入社前から介護制度に明るいエンジニアはごく少数であることやみんな入社してから学べていること*4から、未経験の介護ドメインに飛び込む勇気が湧きました。

そういった経緯で、このプロジェクトは学びが多そうで面白そうだと思い入社に至りました。

実際に入ってみて

概ね入社前に聞いていた情報と大きな乖離はありませんでした。

リニューアルでは、多くのシニアメンバーがプレイヤーとして実際に手を動かしてサービス開発をしています。みんな経験豊富で、日々多様な視点や解決法が見られプレイヤーとしてはなんとも代え難い福利厚生を享受していると感じます。

また、実際に学んでみると介護制度の複雑さがわかってきました。というのも、そもそも介護まわりの法制度が既存のものに継ぎ足しで今があるような構造なのです。ソフトウェアエンジニアの方には、機能の追加を重ねていく中で複雑度が上がってきてしまったソフトウェアをイメージしてもらうと伝わりやすいかと思います。

更に、エス・エム・エス社内の中で紹介されている推薦図書に『最新図解スッキリわかる! 介護保険第2版基本としくみ、制度の今とこれから』があり、これを読むとなおさら介護制度の複雑さが理解できました。

たとえば、単位数の計算がサービス種類や加算の種類の多さによって複雑になっていることや、サービス種類によって関わる人の役割や職種が変わってくることが挙げられます。そして、法改正の際にはこれらに変更が生じることもあります。リニューアルプロジェクトにおいても、このような複雑さをどのように取り扱うかは大きな焦点の一つとなっています。

その過程でドメインエキスパートと一緒にドメインモデリングができたり、ドメインエキスパートに気軽に相談できたり、定期的に施行される法改正についてドメインエキスパートによる説明会が行われることは非常に安心感があります。

しかし、入社前の想像と実際に入ってみてのギャップを感じる点もありました。入社時点（2022年9月）に感じたギャップとしては、ADR（Architecture Decision Records）などのドキュメント類が完全に整備されている訳ではなかったことが挙げられます。詳しくは後述します。

ドキュメンテーションについて

入社時点では、ドキュメントはそこまで整備されている方ではなかったです。

これは、当時はプロジェクトメンバーが少数で MTG やモブプロなど同期的な場で解決されることが多かったことが理由としてはあると思います。

しかし、プロジェクトメンバーの規模が拡大していく中でこのやり方に課題を感じ、組織としても、GitLab Handbook を参考にしたコミュニケーションガイドラインを策定し、なるべく非同期で仕事を進められるようにドキュメンテーションをより意識的に取り組んでいます。また、フロー情報とストック情報を意識し、決定事項をストック情報としてロックして共有する方法を取るようになりました。

プルリクエストについても、GitHubのテンプレートの機能も活用して、変更の背景や設計方針や今回の変更のスコープ外の点などを明記するようにしており、プロジェクトとしても少しずつそういった「なぜ」や「どうやって」を明文化する意識が根付いてきたように感じます。

どういった人におすすめできるか

エス・エム・エスはプロダクトごとに組織の色は違っていて、私がジョインしたリニューアルを手がける組織では、大きく二つの特徴があると思います。

一つ目は、個人に与えられる裁量が大きいということです。組織構造として縦のレイヤーが少なく、かなりフラットな体制を取っています。そのためきっちり分割されたタスクという単位では仕事が降ってくることは稀です。自発的にプロジェクト全体を成功に導くために必要なことは領域を問わず発揮することを期待されます。

自発的にタスクを定義し調和を取りつつ進めるような動きを取るため、ルーズボールが発生しやすい仕組みになっているとも言えます。そのため、ルーズボールを積極的に拾って行けたり、そもそもそういった問題を未然に防げたり、幅広く動ける人が現況だとより活躍しやすそうです。ファシリテーション力や巻き込み力も重要です。

よく「鳥の目、虫の目、魚の目」と称されるような、視点の使い分けをしながらのエンジニアリングスキルがあると非常に活躍できると思います。

とはいえ、この組織体制のままではなかなかスケールしません。現状についてはプロダクトがローンチ前であることに起因していそうで、開発初期はファジーで動的な要素が多いためであり、この構造はプロダクトの輪郭が出来上がるにつれて解決されていきそうです。

二つ目は、更なる成長を目指している大規模で複雑なシステムの構築に初期段階から携われる点にあります。

勝負する介護業界は前述の通り複雑性が高く、構築するシステムも簡単なものではありません。つくるものも多岐に渡りますが、その分得られる知識や体験は大きいです。

会社としてもスキルの習得には最大限補助をしてくれます*5し、学ぼう、成長しようと思えばどんどん成長していける環境にあると思います。また、まわりのメンバーのアウトプットから刺激をもらうことも多いと思います。

これらの点に魅力を感じてくださる方には是非ともジョインしていただきたい、成長に飢えていたり刺激が欲しい人にはもってこいの環境です！