= INDEX =

1. アナログが残る「介護の現場」

2. 膨れ上がる介護マーケット

3. 介護業務からアナログをなくす「カイポケ」

4. カイポケの機能

5. カイポケのフルリニューアルの背景とは？

6. カイポケのシステム

7. カイポケの技術課題

8. 技術課題が生まれるカイポケの複雑性とは

9. カイポケの開発ロードマップ

10. カイポケを支えるプロダクトチーム

11. 開発プロセス・環境

12. メンバーボイス

13. ポジション

14. 働き方・福利厚生

高齢者人口の増加に伴い介護ニーズも増加し、介護の現場は慢性的な人材不足の状態です。そのような状態に重ねて介護の現場では「介護のケア業務」以外の仕事もあり現場に大きな負担がかかっています。

（弊社IR資料より）

いまだに多くの介護事業所では、手書きでの書類作成やホワイトボードを使った情報共有が行われています。

現場に負担が残る一方で、日本の高齢化が進むなかで介護業界は拡大を続けており、将来的には日本の主要な産業に位置づけられると見込まれています。

しかしながら課題が多く存在するのも事実であり、業界の拡大とともに介護の課題は日本全体が向き合う課題となりつつあります。

アナログなプロセスが残る介護業務をテクノロジーの力で効率化することによって介護サービスのコスト削減とクオリティ向上を実現することが「カイポケ」のプロダクトビジョンです。

非効率な事務作業のペーパーレス化を進め、業務時間を短縮し、より本質的な「介護ケア業務」に時間を当てることで「コスト削減」と「クオリティ向上」の両立を追求しています。

多くのユーザーから支持を受け、カイポケの売り上げも年平均20%という高い成長率で継続的に伸長しています。

カイポケのプロダクトの中の主要機能として、①介護サービスの「記録」、②実施したサービスに基づいた「請求」、③介護業務の個人負担分の「集金」業務があり、これらを効率化するための機能を提供しています。

カイポケの請求情報に基づき、請求・入金管理業務も行うことができます。自動引き落としによって効率的に利用料を集金することで現場業務の負担を削減しています。

継続的な事業成長を目的としてサービスの安定性やプロダクトの優位性を高めることを目的とした「新カイポケ」の開発プロジェクトを2021年に始動しました。

アーキテクチャから見直し、「拡張性」・「スケーラビリティ」・「開発並列性」をキーワードにした「新アーキテクチャ」を設計し、開発を進めています。

サービスローンチから17年が経過し、システムとしての安定性や開発効率の観点でもシステム的なテコ入れが必要な状況となっておりました。また介護業界からのニーズは高まっており、会員獲得が進むことを見越しても、今後の更なる成長のために、システムの見直しが急務で求められています。

現在のカイポケは、UIは1000ページ超、データベースのテーブルが1000超の大規模なアプリケーションであることから複数の開発チームで並行開発を行うため、モノリスからマイクロサービスへ移行することを決めました。

障害の影響範囲や法改正対応の修正範囲の局所化と新業態への参入のための拡張性の担保、移行への生産性向上のための並列性確保を目的にマイクロサービスアーキテクチャへ移行

（図出典：日経クロステック 「塩漬けレガシーとマイクロサービスの意外な相性」）

2021年9月から新カイポケの開発チームを社内異動や中途採用によって組成し、2022年10月時点で8つの開発チームを有する規模に急拡大しました。

「業務理解」では顧客の利用者管理業務、予実管理業務、給付管理業務、国保連や利用者への請求業務、残債管理業務といった広範な業務分析のために、ユーザーストーリーマッピングやイベントストーミングをチーム全員で行いました。

「基本設計」においてはドメイン駆動設計や情報設計を通じて、主にフロントエンド(UI)やバックエンドの分割をどうするのか、開発チーム横断の取り組みとして設計を進め分割が決まりました。さらに設計だけでなくプロトタイピングを進め、アーキテクチャや技術スタックの検証を進めました。

カイポケでは、前述の通り今後の並行開発体制を見据えてマイクロサービスアーキテクチャを採用しています。

バックエンドは当面の間は小さく細かい単位でのマイクロサービス化はしない方針で、一定のまとまりの範囲でマイクロサービス化していく設計になっています。一方、フロントエンドは将来的にはプロダクトは5個になる計画がありますが、初期は一つのサーバーにまとめておく設計になっています。

図のように各マイクロサービスをAWS上に配置し、認証にはIDaaSのAuth0を採用しています。 またFrontend - Backend間通信、Backend - Backend間通信はGraphQLを採用しています。 特にFrontend - Backend間通信ではGraphQL Federationを採用していて、 各マイクロサービスのGraphQL Schemaをまとめて一つのGraphQL Schemaに合成することで Frontend側からBackendの個々のマイクロサービスを意識しないでアクセスできるようにしています。

またGraphQL Schemaの共有はApollo Studioを利用していて、CIによって合成GraphQL Schemaが壊れていないかの自動チェックも行なっています。

カイポケではマイクロサービスアーキテクチャを採用しているので本来は個々のバックエンドの採用技術はバラバラでも良いです。しかし、開発初期はあえて揃えていた方が技術共有の観点で有利だと判断して大枠では揃えています。 バックエンドの言語は Kotlin で、Web Framework は Spring Boot と DGS、 ORM は jOOQ、テストは JUnit と MockK を採用しています。

フロントエンドは複数のアプリで統一したユーザー体験を提供するため、共通コンポーネントとページ固有のコンポーネントの分割を行なっています。

またTypeScript と GraphQL を採用して型を活かしたフロントエンド開発ができるようにしています。

フロントエンドの言語はTypeScriptで、Next.js + Reactを採用していて、UI Framework は Chakra UI、その他React Hook Form 、ZodやJest、Storybookなどを採用しています。

インフラストラクチャーはエス・エム・エスのこれまでの開発、運用実績からAWSを採用しています。その中でECS/Fargateによるアプリケーションと、他のAWSサーバーレスサービスを組み合わせることで、ビジネスロジックの開発に集中できるようにしています。

さらに、それを効率的に開発していくためには、アプリケーション開発者がAWSリソースを裁量を持って利用できることが必要なため、CDK を用いて、アプリケーション開発者が関連するAWSリソースを管理しています。

AWSリソースの共通部分については、SREチームが管理するように分担しており、SREチームにとって使い勝手の良いTerraformを採用しています。

カイポケが現在向き合っている技術課題は大きく3つあります。

3年ごとに見直される介護保険制度に応じて、短期間でシステム修正が求められる難易度の高い開発。そして、カイポケの長年の機能追加や部分改修により複雑化されたデータモデリング・フロントエンド設計への課題がメインとなります。

介護費用請求にまつわるロジックはカイポケのコアとなる部分です。しかし、介護費用の算定ロジックは極めて難解な上に、3年ごとの法改正に合わせた素早い改修と請求金額の正確な計算が求められます。「新カイポケ」では、算定ロジックを一から見直し、法改正による制度変更に素早く対応するための新たな算定ロジックの実装にチャレンジしています。

現在のカイポケは扱う業務範囲が広く、また長年の機能追加によりデータベースも肥大化しており、今後開発を進めるためには、担当する開発範囲を適切に分割する必要がありました。そのため、DDDを採用し業務分析を実施、その結果をもとに新たに開発チームを組織し直しました。現在もDDDを継続しており、最適なチーム体制で適切な業務範囲を担当していけるよう進めています。

現在のカイポケは、長年の機能追加により改修の影響範囲が見えにくくなり、そのため部分的な改修が続きました。その結果、全体的に統一感のないUI や少しずつ機能の異なる似通ったページが増えていきました。「新カイポケ」では、実際のユースケースを元にフロントエンドを分解し、それぞれのユースケースに適切な UX を目指すとともに、デザインシステムを用いて統一感のある UI の開発を進めています。

　　　▼ 現在のカイポケのサイトマップ（ユーザー階層の複雑さ）

この領域のソフトウェアは、そのサービスに関わるユーザーだけではなく、その周辺にいる企業や社会から強い影響を受けています。

カイポケは要介護認定者の増加や、介護サービス・事業形態・ユーザーの多様化（例：在宅介護、老人ホーム、大小様々な事業所、多様な職種の人など）など社会的背景から影響を受けるだけではなく、3年ごとに見直される介護保険制度の改正の頻度という観点からも大きな影響を受けています。

これらがカイポケのプロダクトとしての複雑性の根本の要因となります。

近年、社会では介護制度の予測を上回るペースで要介護認定者が増加し、それに伴い介護サービスの種類も多様化し、法人が保有する介護事業の業態の組み合わせも増加しました。

出典：厚生労働省 老健局「公的介護保険制度の現状と今後の役割」（当該ページURL）

介護事業者の業態やサービスの種類の多様化に加え、ユーザーの職位や職種によっても求めるニーズが異なるため、ユーザーの組み合わせの多様化も複雑性に大きな影響を及ぼしています。

しかし、そのような中でも、私たちは「広いターゲットに対して、低いコストでサービス提供をしていく『コストリーダーシップ戦略』を事業上大切にしており、今後もその方針で開発をサービス提供を進めます。そのため、より多様なユーザーにとって使いやすいサービスを作っていくことが求められ、システムの複雑性が増しています。

介護、障害福祉、医療ドメインを対象とするカイポケは介護保険法などの様々な国内法令と向き合う必要があります。またこれらの法律は2~3年に一度大きな法改正があるため、カイポケは外部起因により要件が変わり大規模な法改正対応を行う必要があります。

カイポケの情報設計としてはサービス種類別の事業所起点でUIを構成し、サービス種別を追加するためには同じような機能を線形に増やさなければならないモノリスアーキテクチャを採用してきました。さらに、10年以上に及び大規模なリアーキテクチャをすることなく現在まで開発を行なってきました。

しかし、近年の介護業界の複雑化を背景に、拡張性を担保しながらさまざまな業態とその組み合わせを見据えたシステム設計と実装が求められています。

カイポケの開発ロードマップとして、まずは様々な業態を広くサポートする土台となる Web アプリ4つの開発を予定しています。そして、その後、介護サービス提供に近い業務をサポートするネイティブアプリ5つの開発を予定しています。

カイポケが提供する介護市場は高成長のマーケットであることを背景に、並行して複数のアプリを開発する必要があります。また、それぞれのアプリが相互に連携し合い、最終的なカイポケのプロダクトビジョンを達成するため、開発体制や開発プロセスも疎結合にする必要があります。

新規開発予定のアプリは9つあり、それらは大きく包括型アプリ・特化型アプリの2種類に分かれます。包括型とはサービス種別横断的なアプリで、特化型とは各サービス体系固有のサービスを提供するアプリです。

当面は、包括型Webアプリ4つをフェーズ1として開発を進め、その後、特化型アプリ5つをフェーズ2として開発をしていく計画です。

開発チームは、プロダクト・ドメインごとに分かれ、最適な形でプロダクトに向き合えるよう組織されています。

複数の機能・チームが同時並行で開発を進める上で、疎結合な状態をつくるために、エス・エム・エスではチームトポロジーの概念を適用しています。

新カイポケのプロダクトチームは、開発するものの分割基準が一致しないため、まずは大きくバックエンド開発とフロントエンド開発に分かれています。その中で、バックエンド開発はドメインごと、フロントエンド開発は機能ごとにチームが分かれています。

エス・エム・エスでは、よりエンジニアの方が働きやすい環境で業務に集中できるよう、様々な制度・環境が整っています。

👇 エンジニア向け採用情報も併せてご覧ください。