はじめに
LITALICOの事業について
LITALICOは「障害のない社会をつくる」というビジョンを掲げ、事業展開している会社です。現在は教育・障害福祉などの領域で、情報メディア、HRサービス、SaaS型業務支援システム、学校向けの支援サポートのソフトウェアなど複数のビジネスモデル・サービスモデルをtoB/toC向けに展開しています。
主に障害福祉の領域に色々なプロダクトやサービスを展開していますが、障害福祉と一括で説明していますが、実際の支援内容で法律が分かれていたり、多岐に及びます。
-
主に障害者総合支援法
-
主に児童福祉法
LITALICOの店舗事業で行っている、就労支援サービス及び障害児通所サービスは障害福祉サービスの一部となり、全てをカバー出来ているわけではありません。
ビジネス変化に伴いプロダクトを進化させる
昨年のAdvent Calendarで以下の記事を書きました。
こちらは障害児支援事業所さま向けの運営支援サービスでした。
2020, 2022年とLITALICOグループに新しい2つの会社がJoinしてビジネス変化が生まれました。
福祉事業所向けの業務支援SaaSプロダクトも2つ増え、LITALICO全体でカバーする障害福祉の領域が広がりました。
またシステム的に対応する福祉サービスで重複する部分も出てきました。
前回の記事でも触れましたたが、法改正の対応の難しさは各プロダクトでも同様にあります。
システムが対応する福祉サービスは種類が違っても全て法律に則って行う必要があり、システム開発時の制約や課題は近いものになります。
特にコア業務となるレセプト業務の法改正時の対応のリスクが集中しやすく懸念がありました。
今回の記事は、ビジネス変化に伴い
- プロダクトを進化させる判断に至った理由
- 目指すゴールと大きな方針決定
- 採用する開発プロセス
- 開発プロセスを支えるツールや取り組み
を2回に渡ってまとめたいと思います。
本記事は、前半の課題認識から方針決定までの流れを中心にお話したいと思います。
既存レセプトアプリケーションの課題
レセプト業務の主な内容は、障害福祉の事業所が支援を行った対価を給付費という形で市区町村等に請求を行う業務になります。
支援サービス毎に報酬内容が異なりますが、最終的に市区町村等に請求を行う手順やデータ形式は決まっており、厚生労働省が公開する インターフェース仕様書 に記載されている伝送データを作成する必要があります。
レセプト業務の流れは以下のようになります。
- 各種支援を行った各種実績（体制状況やサービス利用等）を収集
- 各種実績を報酬条件を表した報酬算定構造 [2] というものに当てはめて報酬金額のベースとなる単位数を求める
- 利用者負担額の調整業務
- 最終的な給付費額を算出し各種帳票（請求書等）と伝送データを出力
- 給付費の代理受領及び利用者負担額請求
既存アプリケーションでは以下の様な課題がありました。
- 実績データと算定構造が蜜結合に近い状態になっている
- 算定構造の各種条件をマスターデータとして管理しておりメンテナンスの難易度が高く、網羅的にテストを行うのが難しい
- 算定構造の条件判定の手続き処理が多く、算定構造の実態と乖離してしまっている
- 対応する福祉サービス毎にテーブルの追加が必要で、実装するクラス数が多い
- 市区町村等へ請求するという関心事以外も責務として持っている
その為、法改正時の開発で
- システム全体の仕様が確定しないとレセプトアプリの開発着手ができない
- データフロー的に実績データが登録されないとテストができず、レセプトアプリのテストが後回しになってしまう
- マスターデータとロジックの整合性の検証が必須だが、時間的な制約から主要な請求パターンのみの検証しかできない
- マスターデータの拡張やメンテナンスが職人技過ぎて対応できる人材が限られる
- 伝送データの仕様が変わった場合に、修正箇所の特定が難しく修正範囲も広い
- 実績管理や請求データを利用する後続の業務 [3] の理解も必要で、ドメイン知識の習得に時間がかかりすぎる
という問題がありました。
特に上の2つの問題は、開発期間の圧迫や、品質の低下に直結していました。
レセプトアプリは運営支援システムの中で、
- バグ発生時の深刻度が高い
- テストケースの作成には深いドメイン知識が必要
- テストケースの組わせが膨大
という特性があり、テストの重要度が上位になります。
ただ構造上どうしてもテスト開始タイミングが遅くなり十分なテスト期間の確保が難しいです。
レセプトのテストには数多くのマスターデータ及び実績データの登録が必要且つデータの精度がテストの品質に直結するので、致し方ない側面があります。
コア機能を見定める
昨年に法改正に対応した支援サービスは3つだけでしたが、ビジネスの変化に伴い、34サービスをカバーしていくことになりました。
また、今後の法改正でさらにサービス数が増える可能性があります。
今までの課題を無視して進めるにはリスクが非常に高いです。
これらのサービスをカバーするためには、レセプトアプリの開発者を増やすことも考えられますが、ドメインの知識が複雑すぎるため、一気に増やすことは現実的ではありません。
このため、根本的にやり方を変える必要があると考えました。
次の法改正に対応するために、レセプトのコア機能を見直し、BaaS（Backend as a Service）化してリアーキテクティング（再構築）を行うことを決めました。
最初に行ったのは、各プロダクトの業務プロセスを整理し、レセプト業務で共通となるコア機能の抽出です。
データフローから大まかな業務をまとめて機能単位にグルーピングしました。
各プロダクトでは、伝送データの出力する機能は同様にありますが、結構差がありました。解決しようとしている課題とその扱う領域の範囲が異なり、関連するデータの保持の仕方も異なりました。
各プロダクトの差について一つ一つの論点を整理・検討して、最終的に以下の機能に絞り込みを行いました。
- 報酬算定
- 利用者負担の金額調整＆給付費計算
- 給付費請求書出力＆伝送データ出力
上述のレセプト業務の流れの2〜4までとなります。
実績データの収集と、給付費や利用料の請求の責務をなくすことで、関心事を報酬算定と伝送データにだけに向けることができます。そして各プロダクトの実績データや個別の業務要件にを気にかけることなく請求プラットフォームとして独立した開発を行える様になります。
目指すゴール
独立化させた請求プラットフォームを通じて、目指すべきゴールを以下の様に定義しました。
- 請求の関心事を明確にし、平行開発を可能にしてプロダクト全体のアジリティを上げる【主目的】
請求プラットフォームも含めたプロダクト全体の法改正対応の着手タイミングを前倒しする - 確保した時間で十分な検証を行えるようにして品質を担保する【超重要！リスク低減】
独立化したサービスとして各プロダクトとの結合前に検証できる仕組みも構築する - 請求業務のロジックを集約してシステム開発の効率化を図る【副次効果】
BaaS化の目的は、共通化に伴うシステム開発のコスト削減ではなく、法改正を高品質かつ迅速に対応するために行うものになります。
請求プラットフォームをどのように設計していったか？
業務プロセスを大まかに整理し、ユースケースとしてまとめ、それらをもとにインタフェースを定義しました。
こちらのインターフェースで設計で重要かつ難易度が高かった箇所は、請求データの元となる各種データをどのようにAPIのパラメータに渡すかという点です。
幸いなことにLITALICOグループ内には、請求データを効率的に作成するためのデータ構造に関するノウハウと実績がありました。それらをベースに各プラットフォームのニーズに合わせてAPIとして実装しました。APIはドメイン知識を集約して表現するものとなるので、Design Docsなどを通じて設計方針をまとめ、1つ1つのAPIでブレが生じないよう慎重に設計しました。
採用した開発プロセス
請求プラットフォームとなるBaaSの開発にあたり、スキーマ駆動開発を採用することにしました。請求プラットフォームの実装が完了してから各プロダクトの連携部分を実装していたら法改正に間に合わないため、請求データの元となる各種データのスキーマを最初に設計し、インタフェースを公開して並行開発を行うフローとしました。
スキーマ駆動開発で作成するAPI仕様書は、OpenAPI V3フォーマットを採用しました。
OpenAPI V3を採用した理由として、
があり、記述力が必要でスキーマを再利用して記述する為です。
ここまでのおさらい
これまで、レセプト機能をBaaS化し、リアーキテクティング（再構築）を行う判断をした背景とゴール設定から大きな方針決定まで流れをお話しました。
コアドメインの選択をするという雰囲気を少しでも伝えられていたら嬉しく思います。
今回のプロジェクトはエンジニアリング主導で行われていますが、技術的な興味ではなくビジネスの観点でドメインの重要な部分を選ぶという判断をおこなっています。
コアドメインを集中して開発できるようにすることでプロダクト全体のアジリティをあげることを狙っています。
次からのお話は開発の流れに入っていきますが、記事が長くなってしまったため、投稿を分割することとします。
続きは明日投稿しますのでどうぞお楽しみに！
追記：
後編を投稿しました
Discussion