株式会社エス・エム・エスと「カイポケ」について

鄧：株式会社エス・エム・エスは、「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」ことをミッションとしています。2003年設立、東証プライム市場上場、従業員数は連結で4,528人という規模の会社で、医療・介護/障害福祉・ヘルスケア・シニアライフ領域で40以上のサービスを展開しています。

開発生産性という言葉は極めてコンテキスト依存だと思っています。当社の開発責任者である田辺さんも昨年ファインディ主催の開発生産性をテーマにしたオンラインイベントで、「開発生産性という単語は時と場合による」とおっしゃっていました。今日お話しする内容は、グローバルに展開できる唯一の基準ではなく、あくまでエス・エム・エスという一企業の中の、「カイポケ」というプロダクトでの一開発推進チームの活動だと捉えていただければと思います。



カイポケは介護・看護・障害福祉事業者向けの経営支援サービスで、バーティカル（業界特化型）BtoB SaaSです。2025年7月1日時点で56,900事業所で導入されています。

特徴は、介護の事務作業をクラウド上で完結できるようにすることです。現在の制度設計は紙ベースで考えられていて、毎月大きな紙束ができあがり、FAXでやり取りしたり、ホワイトボードでシフト調整したりと、やることがいっぱいあります。それをクラウド上で完結させて、本来のコア業務である利用者様のサポートにフォーカスできるよう提案しているのが我々です。

カイポケは、現在対応している居宅介護支援、通所介護、訪問介護、訪問看護などに加え、より幅広い介護事業種別や障害福祉分野へと対象を広げ、同じ事業所の中でもいろんな業務を徐々にサポートすることによって、パイを広げていくことを目指しています。

「開発推進」が必要になった背景

このような成長戦略を取る中で、開発推進がなぜ必要になったのか、その背景についてご紹介します。



カイポケが直面している複雑度は多岐にわたります。最上位には高齢化社会という大きな社会問題があり、その中で国や各自治体が提供する制度自体が複雑な構造を持っています。

さらに、定期的に法改正が発生します。これをエンジニア的な用語で表現すると、「コントロールできない外部要因による強制的な仕様変更」となります。この仕様変更が定期的に発生することも、複雑度を高める要因の一つです。

また、顧客である事業所は多様な業務ドメインを抱えており、これも複雑度を増す要因となっています。加えて、我々自身の組織にも開発組織的な制約や技術的制約が存在します。

このように多数の複雑度が存在する中で、今日特に焦点を当てたいのは2つの側面です。制度自体の複雑度にどのように対応するか、そして顧客業務ドメインの複雑度にどう対処するかということです。



カイポケの開発戦略は、複雑度を一気に解決するのではなく、分割統治（Divide and Conquer）のアプローチを採用することです。複雑度を分割し、それぞれを個別に攻略する戦略を取っています。

例えば、複数の制度が存在し、それらのコンテキストがBounded Contextとして明確に分離できる場合、制度ごとにチームを分けて並行開発を行います。これにより、相対的なアウトプットを増加させることができます。

同様に、顧客の業務についても、業務ドメインの分割が可能な領域については分割を行い、それぞれを並行で開発を進める体制を構築しています。

戦略は明確でしたが、実際に運用してみると一度失敗し、問題を抱えることになりました。その後再構築を行ったため、その失敗事例をお話しします。

失敗からの学びと、チームの再定義

ドメイン分割によるBounded Contextに基づいた並列開発では、ビズアプリ、ケアアプリといった各アプリケーションチーム、開発推進チームの前身であるプラットフォームチーム、SREチームなど、複数のチームに分けて開発を進めました。



しかし、チーム間を跨ぐ共通課題が必然的に発生します。こうした課題を解決するため、「技術戦略」という会議体を設置し、週次で関係者が集まって議論を行う体制を構築しました。

この体制の最大の問題は「兼務」でした。各チームメンバーが本業と並行して技術戦略に参加する形態は、様々な問題を引き起こしました。この問題を解決するため、兼務体制をやめて専任チームとして再構築することにしました。Before/Afterという形で、各チームの本業と兼務だったものを、専任で明確なテーマ・ゴール設定を持った開発推進チームに変更したのです。

主な失敗点は3つあります。



第一に、兼務そのものの限界です。各チームには顧客に機能を提供するという本業があり、スプリント・スクラムによるタイトな開発サイクルを回しています。そのタイトなマイルストーンを達成しようとする中で、サイドクエストとしての技術戦略活動にどの程度コミットできるかという根本的な問題がありました。実際には十分なコミットができず、推進力不足という結果に終わりました。

第二に、オーナーシップの不明確化（その1）です。本来、各アプリケーションチームはインフラから顧客体験まで全責任を持つべきですが、いつの間にかSREが実質的なインフラ専門部隊として位置づけられてしまいました。

第三に、オーナーシップの不明確化（その2）、これはスコープの無限拡大です。メール送信のためのサードパーティアカウント管理やパフォーマンスモニタリングなど、どのチームにも明確に所属しないタスクが暗黙的にプラットフォームチームの責任範囲とみなされるようになりました。結果的にプラットフォームチームのスコープが無限に拡大し、何も達成できない状況に陥りました。

この反省を踏まえ、より効率的にプロダクト開発を推進できる体制について検討を開始しました。

失敗を踏まえて新しいチームを構築するにあたり、まずプロダクト主導型の開発チームとして次のような問いを立てました。「より早くプロダクトの価値を実感できるようなプロダクトを作るには、どうしたらいいだろう？」この問いから出発して、我々が考えている課題設定と価値仮説を明確にしました。



開発推進のアイデンティティを確立するため、何を解決してどういう価値をもたらすかを明確に定義しました。まず課題設定として、開発者のスキルギャップと認知負荷が迅速なプロダクト価値提供を阻害していると考えました。これがすべての問題ではありませんが、手っ取り早く改善できる領域として焦点を当てることにしました。

開発チームには様々なスキルセットを持つメンバーがいます。例えば、インフラに詳しい人と詳しくない人がいる中で、素早く開発を進めるためには、その複雑性を一部抽象化して、ある意味社内のPaaSのようなものを作ろうという考えに至りました。

価値仮説としては、抽象化・標準化されたPaaSと開発支援により、開発効率と開発者体験を最大化し、事業成長を加速するということを設定しました。我々の目標として、開発効率と開発者体験をNSM（ノーススターメトリック）として、これを目指すチームを作りました。

限られたリソースの中で何をどう達成するかという戦略についても明確にしました。戦略として、元のオーナーシップを損なわず、開発者が本来のコア業務であるプロダクト価値創造に集中できる環境を整備することで、ビジネスの成長スピードを加速させることを目指します。

戦術としては、各種SaaS、インフラ、監視、各種ツールなどを連携させ、抽象化・共通化・自動化されたプラットフォームとして提供することで、各開発チームの負担を軽減し、属人化を防ぎ、開発全体の生産性を向上させます。

我々が考える価値提供のアプローチとして、各チームに対してAWSアカウントを提供して個別に対応してもらうという選択肢もありますが、それでは先ほど説明したスキルギャップの問題に対して十分な解決策となりません。そのため開発推進チームがこれらの複雑性を一手に引き受けることで、複雑度自体は減少しませんが、一度構築したものを再利用できる仕組みを作ることで、全体的な効率性向上を実現できると考えています。

この考え方の例として、責任共有モデルがあります。AWSも同様のモデルを採用しており、インフラのサーバーラックなどの物理的な複雑性を抽象化することで、利用者はクラウド上で簡単にリソースを利用できるようになっています。同じ「良いサービスを作る」という目標を共有しながらも、それぞれに明確な役割分担があり、どのように責任を分担するかの境界線を定めているのが責任共有モデルです。我々も類似のアプローチを採用しています。



AWSを例として説明すると、目標は「いいサービスを作ろう」という共通のものですが、同じ目標を共有していても、具体的なタスクをどう分担するかの境界線を明確にする必要があります。

我々も似たような責任共有モデルを採用しています。AWS、GitHub、Datadogなど様々なツールがありますが、それらのツールを抽象化して、扱いやすい粒度でSDKなどを作って、それを提供しようとしています。これにより、各開発チームは最終的に自分が慣れたフレームワークの中で開発すれば良い感じの機能が作れるということを目指しています。

新しい開発推進チームの活動内容

空中：ここからは、開発推進チームの実際の活動内容について説明します。

開発推進チームは「開発しやすすぎて感動してほしい」というビジョンを掲げています。カイポケ開発部の開発者全員にこのような体験を提供することを目標としています。

まず、開発者が構築しているシステムの概要について説明します。システム全体は、バックエンドに複数のサーバーで構成されています。これらのサーバーは、billing（介護請求）、hcs（居宅支援）、service-fee（報酬算定）、platformといったサービスを提供し、それぞれがGraphQLを公開する形で設計されています。



バックエンドとは別に、伝送システムという外部システムが存在します。これは介護請求を行う際の国の保険者とのデータ連携システムです。我々が開発しているリニューアルプロジェクトと既存のカイポケシステムが共通でこの伝送システムを利用するため、適切な連携機能を提供しています。

また、システム全体では契約関連データの取得にSalesforceを利用し、認証認可にはAuth0、オブザーバビリティにはDatadogを活用しています。フロントエンドはNext.jsで構築され、バックエンドの複数のGraphQLサーバーとはゲートウェイを通じて統合された単一のGraphQLインターフェースで接続されています。

カイポケの戦略として、複数のサービスを並行開発していく方針を取っているため、バックエンドサービスは今後も継続的に増加していく予定です。サービス数が増加しても開発効率を損なわないようにするため、各チームにはドメインの課題解決に集中してもらう体制を構築しています。

そのため、開発推進チームでは様々な基盤ソフトウェアの開発と提供を行っています。具体的には、認証/認可ライブラリ、ロギングシステムとライブラリ、オブザーバビリティ用ライブラリを開発しています。全サーバーでGraphQLを使用しているため、GraphQL共通設定ライブラリも提供しています。

さらに、先述したゲートウェイサーバーの開発、Salesforceとのデータ連携を担うSalesforce Ambassador、UIコンポーネント、ビジュアルリグレッションテスト（以下、VRTテスト）の基盤なども開発しています。

インフラ運用基盤の整備も重要な活動領域です。Datadogによる監視機能の提供、AWSリソースの管理、Terraformによる構成管理を行っています。また、リリースフローの構築と提供、Feature Toggleを使った機能のON/OFF制御機能、バッチ実行基盤の構築も担当しています。

ストリームアラインドチームへのサービス提供も行っています。platformサービスの一部として、ACLサーバー（認証/認可サーバー）を提供し、各サーバーからの認可問い合わせに対応しています。サーバー間のデータ同期基盤の構築、インフラ利用ガバナンスの策定、Integration Test等のテスト基盤の提供も実施しています。

開発体験改善の取り組みとして、VoD（Voice of Developers）という仕組みを運用しています。これはGitHubのIssueを活用した仕組みで、開発者が誰でも使いにくさや改善要望を投稿できるようにしています。

その他の活動として、脆弱性診断の実施とその結果の共有、デザインシステムのMCP化にも取り組んでいます。

開発推進チームの活動は技術領域別に整理すると、以下のようになります。



バックエンド領域では、認証認可ライブラリ、Logging、Observability、GraphQL共通設定、Gatewayサーバー、Salesforce Ambassador、ACLサーバーといった基盤コンポーネントを開発・提供しています。

フロントエンド領域では、UIコンポーネントの開発、VRT基盤の構築、デザインシステムのMCP化に取り組んでいます。

PaaS領域では、Datadogによる監視、AWSリソース管理、Terraformによる構成管理、Release Flow、Feature Toggle、Batch実行基盤、脆弱性診断、データ同期、インフラ利用ガバナンス、テスト基盤といった、幅広い基盤サービスを提供しています。

活動の成果

開発推進チームの活動成果として、特に重要な2つの事例を紹介します。

まず、VRTテスト基盤の内製化について説明します。VRTテストとは、フロントエンドのコードからスクリーンショットを取得し、変更後のコードと画像比較してテストを行う手法です。これにより意図しない画面変更を見た目で確認できます。



既存のVRT基盤として、SaaS提供のChromaticを利用したシステムがCIで動作していました。しかし、プロダクトとチームの成長に伴ってスナップショット数が急激に増大し、毎月13万件が追加され、すでに70万件に達していました。Chromaticは従量課金制のため、コスト負担が大きな課題となり、内製化の議論が開始されました。

この時点で、サイドクエストの問題が顕在化しました。アプリケーションチームでは内製化による費用削減効果を認識していましたが、誰が実際に担当するかという課題がありました。各チームは本業に集中する必要があり、大規模な内製化プロジェクトに割くリソースがない状況でした。

そこで、開発推進チームがVRT基盤の内製化を引き受けました。技術選択肢の調査と比較検討を実施し、インフラを含めた基盤を構築しました。現在ではCIで動作するレベルまで完成し、毎日継続的に稼働しています。この内製化により、コスト削減と組織成長に対応できるスケーラブルな基盤を実現できました。詳細は弊社テックブログで前編・後編として全面公開しています。

次に、デザインシステムのMCP化について説明します。



従来は、Figmaにデザインシステムが定義されており、フロントエンド実装時にはFigmaのページデザインとデザインシステムを参照しながらReactコードを作成していました。この機械的な作業をLLMで効率化したいと考えました。

しかし、単純にLLMに画面作成を依頼すると、デザインシステムを無視した出力になってしまいます。カラー定義はRGB値の固定値で出力され、マージンもピクセル単位での直接指定となり、定義済みのsm、md、lgといったサイズ指定が使われませんでした。

この課題を解決するため、デザインシステムのMCP化を実施しました。デザインシステムのコンポーネントをLLMに学習させることで、出力コードが適切にデザインシステムを反映するようにしました。

相当な試行錯誤を経て、最終的に適切なデザインシステム準拠のコード生成を実現しました。現在では、適切なカラー定義が使用され、ボタンやステップなどの独自コンポーネントが正しく活用され、汎用的なボックスやdivではなく、デザインシステムで定義された専用コンポーネントが選択されるようになっています。

この成果についても、詳細な記事とスライドを公開し、実装方法から技術的アプローチまで全プロセスを共有しています。

最後に、仲間集めのお知らせとして、採用情報についてご紹介したいと思います。

エス・エム・エスでは、エンジニアの採用を積極的に行っています。採用情報については、https://careers.bm-sms.co.jp/engineer でご確認いただけます。また、我々の技術的な取り組みや開発文化については、テックブログで継続的に情報発信を行っています。

プラットフォームエンジニアリングに興味がある方、開発者体験の向上に情熱を持っている方、社会に意味のある価値を提供したいと考えている方とお会いできることを楽しみにしています。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です