難解で複雑な技術的課題に向き合える
日本最大級の業界特化型SaaS「カイポケ」のフルリニューアル始動
= INDEX =
1. アナログが残る「介護の現場」
高齢者人口の増加に伴い介護ニーズも増加し、介護の現場は慢性的な人材不足の状態です。そのような状態に重ねて介護の現場では「介護のケア業務」以外の仕事もあり現場に大きな負担がかかっています。
（弊社IR資料より）
⚡手書き資料、ホワイトボードなどのアナログが残る現場
いまだに多くの介護事業所では、手書きでの書類作成やホワイトボードを使った情報共有が行われています。
現場負担例①：3つの書類に手書きで転記する必要
利用者ごとのバイタルデータなどの情報や、どのようなサービスを提供したかなどを、介護記録・連絡帳・業務日誌という3つの書類に書く必要があります。
医療と同様に、介護サービス料金のほとんどは介護保険で賄われており、介護事業者は毎月介護報酬の請求を行なっています。 介護報酬を請求するために「紙」に書かれた介護記録をもとにPCの請求ソフトに1枚1枚その記録を入力する必要があります。
2. 膨れ上がる介護マーケット
現場に負担が残る一方で、日本の高齢化が進むなかで介護業界は拡大を続けており、将来的には日本の主要な産業に位置づけられると見込まれています。
しかしながら課題が多く存在するのも事実であり、業界の拡大とともに介護の課題は日本全体が向き合う課題となりつつあります。
3. 介護業務からアナログをなくす「カイポケ」
アナログなプロセスが残る介護業務をテクノロジーの力で効率化することによって介護サービスのコスト削減とクオリティ向上を実現することが「カイポケ」のプロダクトビジョンです。
⚡ 現場の負担をなくすプロダクト
非効率な事務作業のペーパーレス化を進め、業務時間を短縮し、より本質的な「介護ケア業務」に時間を当てることで「コスト削減」と「クオリティ向上」の両立を追求しています。
⚡ 平均20%の高い成長率
多くのユーザーから支持を受け、カイポケの売り上げも年平均20%という高い成長率で継続的に伸長しています。
4. カイポケの機能（一部）
カイポケのプロダクトの中の主要機能として、①介護サービスの「記録」、②実施したサービスに基づいた「請求」、③介護業務の個人負担分の「集金」業務があり、これらを効率化するための機能を提供しています。
⚡ ①記録の一元化・短縮化
複数の書類に記入が必要だった介護記録について、クラウド上での一元管理を実現しています。また定型文挿入や音声入力、自動転記機能などにより、隙間時間での作業も可能となり、作業時間も短縮することができます。
⚡ ②正確な請求業務
カイポケでは記録業務と請求業務が連動しています。また医療と同様に介護業務毎に「点数」が設けられていますが、その複雑な点数計算も介護記録をもとに処理することで、正しい請求も可能にし、時間短縮と正確性を担保しています。
⚡ ③集金業務の自動化
カイポケの請求情報に基づき、請求・入金管理業務も行うことができます。自動引き落としによって効率的に利用料を集金することで現場業務の負担を削減しています。
5. カイポケのフルリニューアルの背景とは？
継続的な事業成長を目的としてサービスの安定性やプロダクトの優位性を高めることを目的とした「新カイポケ」の開発プロジェクトを2021年に始動しました。
アーキテクチャから見直し、「拡張性」・「スケーラビリティ」・「開発並列性」をキーワードにした「新アーキテクチャ」を設計し、開発を進めています。
⚡ローンチから17年経過し抜本的な見直しへ
サービスローンチから17年が経過し、システムとしての安定性や開発効率の観点でもシステム的なテコ入れが必要な状況となっておりました。また介護業界からのニーズは高まっており、会員獲得が進むことを見越しても、今後の更なる成長のために、システムの見直しが急務で求められています。
⚡ 高い拡張性 x スケーラビリティ x 開発並列性を支えるアーキテクチャが必要
現在のカイポケは、UIは1000ページ超、データベースのテーブルが1000超の大規模なアプリケーションであることから複数の開発チームで並行開発を行うため、今回のリニューアルでは現在のモノリシックなシステムの構造から脱却していくことを決めました。
障害の影響範囲や法改正対応の修正範囲の局所化と新業態への参入のための拡張性の担保、生産性向上のための並列性の確保を目的に、ドメイン毎にサービスを分割したアーキテクチャへ移行しています。
（図出典：日経クロステック 「塩漬けレガシーとマイクロサービスの意外な相性」）
⚡ 新カイポケの開発チームを発足
2021年9月から新カイポケの開発チームを社内異動や中途採用によって組成し、2022年10月時点で8つの開発チームを有する規模に急拡大しました。
「業務理解」では顧客の利用者管理業務、予実管理業務、給付管理業務、国保連や利用者への請求業務、残債管理業務といった広範な業務分析のために、ユーザーストーリーマッピングやイベントストーミングをチーム全員で行いました。
「基本設計」においてはドメイン駆動設計や情報設計を通じて、主にフロントエンド(UI)やバックエンドの分割をどうするのか、開発チーム横断の取り組みとして設計を進め分割が決まりました。さらに設計だけでなくプロトタイピングを進め、アーキテクチャや技術スタックの検証を進めました。
6. カイポケのシステム
カイポケでは、前述の通り今後の並行開発体制を見据えて、ドメイン毎のサービスがサービス間で連携するアーキテクチャを採用しています。
バックエンドは当面の間は小さく細かい単位でのマイクロサービス化はしない方針で、一定のまとまりの範囲でサービス分割をしていく設計になっています。一方、フロントエンドは将来的にはプロダクトは5個になる計画がありますが、初期は一つのサーバーにまとめておく設計になっています。
⚡ カイポケのアーキテクチャ設計
図のようにドメイン毎に分割した各サービスをAWS上に配置し、認証にはIDaaSのAuth0を採用しています。 またFrontend - Backend間通信、Backend - Backend間通信はGraphQLを採用しています。 特にFrontend - Backend間通信ではGraphQL Federationを採用していて、 各サービスのGraphQL Schemaをまとめて一つのGraphQL Schemaに合成することで Frontend側からBackendの個々のサービスを意識しないでアクセスできるようにしています。
⚡ カイポケの技術スタック
カイポケでは複数のサービスが自律的に開発を進めることができるアーキテクチャを採用しているので本来は個々のバックエンドの採用技術はバラバラでも良いです。しかし、開発初期はあえて揃えていた方が技術共有の観点で有利だと判断して大枠では揃えています。
バックエンドの言語は 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を採用しています。
Category | Technology Stack |
Programming Language/Library | - Web Frontend
HTML, CSS, JavaScript, TypeScript, React, Next.js, Apollo, Chakra UI, React Hook Form, Zod, Storybook, Jest
- Backend
Kotlin, Spring Boot, DGS, jOOQ, JUnit, MockK
- Other
GraphQL, GitHub |
Infrastructure | - AWS
ECS/Fargate, ALB,EventBridge, SQS, Route 53, S3, CloudFront, Aurora
- IaC
CDK (アプリケーション部分)
*開発チームがインフラにも裁量を持っています
Terraform (インフラ共通部分) |
Middleware | (Pub/Sub) |
Database | PostgreSQL |
Monitoring | Datadog |
7. カイポケの技術課題
カイポケが現在向き合っている技術課題は大きく3つあります。
3年ごとに見直される介護保険制度に応じて、短期間でシステム修正が求められる難易度の高い開発。そして、カイポケの長年の機能追加や部分改修により複雑化されたデータモデリング・フロントエンド設計への課題がメインとなります。
⚡ 技術課題① 極めて複雑な介護費用請求金額のモデリング
介護費用請求にまつわるロジックはカイポケのコアとなる部分です。しかし、介護費用の算定ロジックは極めて難解な上に、3年ごとの法改正に合わせた素早い改修と請求金額の正確な計算が求められます。「新カイポケ」では、算定ロジックを一から見直し、法改正による制度変更に素早く対応するための新たな算定ロジックの実装にチャレンジしています。
- 介護保険制度は3年ごとに見直され、新しい制度や今までの制度の更新が行われるため、そのたびに介護給付費計算のロジックの修正が必要になってきます。しかし、この制度の決定は、制度開始のギリギリまで正式決定されないため、短期での開発が必要になってきます。
- お金に関わる計算なので、正しく実装していかないといけないところですが、現状では実装ロジックの複雑度が高く、短期間でさらに正確に実装していくのが非常に難しい状態にあります。
- また、介護給付費に必要な介護サービスごとの単位数などのデータの作成も必要なのですが、構造化されていない PDF からデータを作成しているため、完全に自動化できておらず、ここにもコストが掛かっている状態です。
- 介護保険制度の理解には時間がかかり、認知負荷が高いため、DDD によるドメイン分析によって変更の影響範囲を極小に抑えるチーム分割を行いました。
- 介護給付費の計算に必要な介護サービスごとの単位数のデータ作成のコストを極力減らすため、国民健康保険中央会が提供する「介護給付費単位数表標準マスタ」の利用を検討して、開発コストの軽減に取り組んでいます。
- また、正確で短期での実装を可能にするべく、「介護給付費単位数表標準マスタ」を利用することで動的に計算ロジックを導き出す計算エンジンの開発にも取り組んでいます。
- 介護保険制度、特に介護給付費の計算にまつわる知識を獲得するのは難易度が高いですが、その難しさをどうやってシンプルで理解しやすい実装に落とし込むかという面白さもあると思います。
⚡ 技術課題② 1000超のテーブルと向き合うデータモデリング
現在のカイポケは扱う業務範囲が広く、また長年の機能追加によりデータベースも肥大化しており、今後開発を進めるためには、担当する開発範囲を適切に分割する必要がありました。そのため、DDDを採用し業務分析を実施、その結果をもとに新たに開発チームを組織し直しました。現在もDDDを継続しており、最適なチーム体制で適切な業務範囲を担当していけるよう進めています。
- カイポケの業務範囲の広さ
- 現在のカイポケが扱う業務は、利用者管理やサービス提供予実管理、請求業務など広範囲に及びます。新たに開発をスタートするには、開発者の認知負荷軽減のため、担当する開発範囲を適切に分割する必要がありました。
- 肥大化したデータベース
- 長年の機能追加によって、データベースも肥大化していきました。やがて、全体を把握するのが困難になってきました。
- 現在のカイポケの適切な切り取り線を見つけるため、DDD を採用して業務分析を行ってきました。
- DDD を進めるにあたっては Domain-Driven Design Starter Modelling Process を Step1 から順番に実行することで業務分析を進めました。
- この DDD の結果を元に、カイポケの業務範囲を分割し、それぞれを担当する開発チームを組織しました。
- 引き続き、各開発チームで担当業務の DDD を継続し、分析したモデルに基づいた開発を行っています。
- 一度分割をしましたが、さらに深堀りすることで分割した境界が動く可能性もあり、本当にそれが正しいのか引き続き検討する必要があります。
- エンジニアだけでなく、ドメインエキスパートなど様々な役割のメンバーと DDD を進めているため、業務の分析だけでなく、新たな発見や知識を得ることができる面白さはあります。
⚡ 技術課題③ 1000超のページと向き合うフロントエンドの設計
現在のカイポケは、長年の機能追加により改修の影響範囲が見えにくくなり、そのため部分的な改修が続きました。その結果、全体的に統一感のないUI や少しずつ機能の異なる似通ったページが増えていきました。「新カイポケ」では、実際のユースケースを元にフロントエンドを分解し、それぞれのユースケースに適切な UX を目指すとともに、デザインシステムを用いて統一感のある UI の開発を進めています。
- 介護事業所はその規模が様々あり、経営者・管理者・事務員・ケアマネジャー・介護職員など多様な職種のユーザーが存在します。そのため、利用者の職種別に使用機能を合わせると、システムの階層が深くなってしまうという課題があります。
▼ 現在のカイポケのサイトマップ（ユーザー階層の複雑さ）
- 長年に渡って、改修や機能追加を繰り返してきたことで、デザインやUIが微妙に異なる機能が発生し、その結果としてユーザー体験の低下をもたらしています。
- 近年では同じ運営者が異なる事業所を展開しているケースも多くあるものの、現在のカイポケでは事業所起点で情報登録が必要なため、ユーザーにとって管理が煩雑になってしまうなどの課題があります。
- 全体情報（IA）設計について
- 前述の課題を解決するために、カイポケのサイト全体の情報設計を行いました。
- デザインシステムの刷新
- ユースケースごとにアプリのフロントエンドを分割することになったため、アプリが変わったとしても統一的なユーザー体験を提供するためにデザイシステムの構築を始めています。
- カイポケのフロントエンドでは、開発スピードをあげる・コンポーネントの再実装を避けるなどの理由からChakra UI という UI フレームワークを採用し、開発を進めています。
- ２アプリ並行して作るところの難しさ
- デザインシステムの構築でも触れましたが、複数のアプリで統一したユーザー体験を提供するために UI の一貫性を保つところが、難しさでもありチャレンジングなところだと思います
- コンポーネント数も多くなるので、共通コンポーネントとページ固有のコンポーネントの分割などコンポーネントの設計が重要になってきます
- TypeScript / GraphQL で型を活かした大規模なフロントエンド開発ができる
- ページ数・コンポーネント数が多い大規模なフロントエンド開発になるので、TypeScript を採用して静的型な型チェックでコンパイル時にエラーに気づけるようにしています
- Apollo Client と GraphQL Code Generator を利用して、GraphQL のスキーマやクエリから TypeScript の型を自動生成することで、バックエンドとの通信部分も型付けしています
8. 技術課題が生まれるカイポケの複雑性とは
この領域のソフトウェアは、そのサービスに関わるユーザーだけではなく、その周辺にいる企業や社会から強い影響を受けています。
カイポケは要介護認定者の増加や、介護サービス・事業形態・ユーザーの多様化（例：在宅介護、老人ホーム、大小様々な事業所、多様な職種の人など）など社会的背景から影響を受けるだけではなく、3年ごとに見直される介護保険制度の改正の頻度という観点からも大きな影響を受けています。
これらがカイポケのプロダクトとしての複雑性の根本の要因となります。
⚡ 膨れ上がる介護マーケット
近年、社会では介護制度の予測を上回るペースで要介護認定者が増加し、それに伴い介護サービスの種類も多様化し、法人が保有する介護事業の業態の組み合わせも増加しました。
出典：厚生労働省 老健局「公的介護保険制度の現状と今後の役割」（当該ページURL）
⚡ 多様化するユーザーによる組合せの増加
介護事業者の業態やサービスの種類の多様化に加え、ユーザーの職位や職種によっても求めるニーズが異なるため、ユーザーの組み合わせの多様化も複雑性に大きな影響を及ぼしています。
しかし、そのような中でも、私たちは「広いターゲットに対して、低いコストでサービス提供をしていく『コストリーダーシップ戦略』を事業上大切にしており、今後もその方針で開発をサービス提供を進めます。そのため、より多様なユーザーにとって使いやすいサービスを作っていくことが求められ、システムの複雑性が増しています。
⚡ 法改正への対応
介護、障害福祉、医療ドメインを対象とするカイポケは介護保険法などの様々な国内法令と向き合う必要があります。またこれらの法律は2~3年に一度大きな法改正があるため、カイポケは外部起因により要件が変わり大規模な法改正対応を行う必要があります。
⚡ モノリスなシステム
カイポケの情報設計としてはサービス種類別の事業所起点でUIを構成し、サービス種別を追加するためには同じような機能を線形に増やさなければならないモノリスアーキテクチャを採用してきました。さらに、10年以上に及び大規模なリアーキテクチャをすることなく現在まで開発を行なってきました。
しかし、近年の介護業界の複雑化を背景に、拡張性を担保しながらさまざまな業態とその組み合わせを見据えたシステム設計と実装が求められています。
9. カイポケの開発ロードマップ
⚡ まずは土台となるWebアプリ4つを開発予定
カイポケの開発ロードマップとして、まずは様々な業態を広くサポートする土台となる Web アプリ4つの開発を予定しています。そして、その後、介護サービス提供に近い業務をサポートするネイティブアプリ5つの開発を予定しています。
⚡ ロードマップと目指すもの
カイポケが提供する介護市場は高成長のマーケットであることを背景に、並行して複数のアプリを開発する必要があります。また、それぞれのアプリが相互に連携し合い、最終的なカイポケのプロダクトビジョンを達成するため、開発体制や開発プロセスも疎結合にする必要があります。
新規開発予定のアプリは9つあり、それらは大きく包括型アプリ・特化型アプリの2種類に分かれます。包括型とはサービス種別横断的なアプリで、特化型とは各サービス体系固有のサービスを提供するアプリです。
当面は、包括型Webアプリ4つをフェーズ1として開発を進め、その後、特化型アプリ5つをフェーズ2として開発をしていく計画です。
⚡ 新規プロダクト開発
ERPとは介護事業に関わる経営者や管理者を対象に「介護事業の経営・管理業務」を支援するプロダクトです。
介護過程とは介護事業の管理者や生活相談員を対象に「介護過程の安定的な提供」を支援するプロダクトです。
CRMとは介護職員や管理者、看護師、ヘルパーなどに介護業務者に対し「介護に関わる業務の効率化」をサポートするプロダクトです。
ケアマネジメントとは居宅介護支援事業の管理者や職員を対象に「ケアマネジメントに関わる業務」を支援するプロダクトです。
FCMとはFCの各加盟法人を対象に「介護事業の運営・管理業務」を支援するプロダクトです。
10. カイポケを支えるプロダクトチーム
⚡ プロダクト単位での役割と人数構成
開発チームは、プロダクト・ドメインごとに分かれ、最適な形でプロダクトに向き合えるよう組織されています。
⚡ チームトポロジーを適用したエンジニア組織
複数の機能・チームが同時並行で開発を進める上で、疎結合な状態をつくるために、エス・エム・エスではチームトポロジーの概念を適用しています。
新カイポケのプロダクトチームは、開発するものの分割基準が一致しないため、まずは大きくバックエンド開発とフロントエンド開発に分かれています。その中で、バックエンド開発はドメインごと、フロントエンド開発は機能ごとにチームが分かれています。
- 居宅支援チーム
- 事業所管理ドメイン、ケアマネジメントドメイン、サービス提供管理ドメインのバックエンド開発
- 介護請求チーム
- 売上請求管理ドメイン、報酬算定管理ドメインのバックエンド開発
- ERP チーム
- ERP 機能のフロントエンド開発
- ケアマネジメントチーム
- ケアマネジメント機能のフロントエンド開発
- プラットフォームチーム
- カイポケ全体にわたる機能(アカウント(認証/認可)、コミュニケーション、販売管理)のバックエンド開発
- SRE チーム
- AWS の共通インフラ部分の開発や、カイポケ全体の SRE 業務
- アーキテクトチーム
- カイポケ全体のアーキテクチャや技術的課題を検討、意思決定する
- 技術別イネイブリングチーム(将来)
- AWS、frontend、Database などの有識者で構成され、必要に応じて他チームをヘルプする
- 伝送チーム
- 国保連への伝送処理が複雑なため、この部分を専任で開発
⚡メンバー
11. 開発プロセス・環境
エス・エム・エスでは、よりエンジニアの方が働きやすい環境で業務に集中できるよう、様々な制度・環境が整っています。
⚡ 特徴的制度・環境
エンジニア向けの技術書が自宅に無償で届く制度があります。Slack内のチャンネルにAmazon URLを書いて購買担当者にメンションをするだけで、即日注文され、自宅に技術書が届きます。
技術出版社の O'Reillyが運営しているサブスクサービス「O'Reilly Online Learning」（通常年間499ドル）を無料で利用することができます。技術書や講義動画、オーディオブックなどが読み放題・見放題になります。
プロジェクトには、これまで介護業界で実際に働いてきた経験のあるメンバーがいます。
このため、DDDを進める上でドメインエキスパートを外部から招く必要がなく、効率的な分析が行えています。
また、ちょっとした疑問でも気軽に質問できてとてもスムーズです。
例えばチームでレイヤードアーキテクチャを採用すると決めていても、実はそこには濃淡があって、個人個人で微妙に異なる実装になることがあります。 モブプロでチーム全員で話し合いながらコーディングを進めることで、個人間の差異や迷うところについて、その場で相談・決定しながらコーディングを進めることが可能です。またリモート環境でもみんなでワイワイ話しながらコーディングできるのも良い点です。
早期に動くものを開発し、より早いフィードバックを得ることで、改善サイクルを効率的に回すため、Agile開発を採用しています。また、Agile開発に親和性の高いScrum開発を採用しています。Agile開発、Scrum開発については、エス・エム・エスに有識者がおり、必要に応じてアドバイスがもらえる環境です。
⚡ その他制度一覧
- カンファレンス参加の奨励（参加費支援）
- 自然発生する様々な勉強会
- テックトーク
- キーボード・マウス購入制度
- 27インチ4Kディスプレイ支給
- 昇降デスク
- モブプロ用43インチディスプレイ
12. メンバーボイス
⚡このチーム・仕事の好きなところ、楽しいところ
Kiyotaka Soranaka
⚡このチーム・仕事の癖のあるところ
Kiyotaka Soranaka
Yasumasa Miyasaka
Shigetaka Shirouchi
13. ポジション
- フロントエンドエンジニア(JavaScript/TypeScript)
- ソフトウェアエンジニア-バックエンド(Rubyエンジニア)
- ソフトウェアエンジニア-バックエンド(Java/サーバーサイドKotlin)
- ソフトウェアエンジニア-テックリード/アーキテクト
- エンジニアリングマネージャー
- SRE
- QAリーダー（候補含む）
14. 働き方・福利厚生
⚡ 勤務環境
- フレックス（コアタイム 12:00~16:00）
- リモート中心の開発
- 高い有給消化率
⚡ 評価制度
- 成果評価ではなく能力評価
- 3つの能力軸で評価が決定
- 問題解決力
- チーム開発のファシリテーション力
- 技術力
- 期初に能力の見立てを行い、定期面談でギャップをすり合わせ
- テーマを決め、通年で挑戦しこまめにフィードバック
- 年に1回評価
👇 エンジニア向け採用情報も併せてご覧ください。
