はじめに

この記事はLITALICO Engineers Advent Calendar 2024 シリーズ2の12日目の記事です

LITALICOでエンジニアをしている@takmonです。
今回は、2024年度の障害福祉法改正に伴い、システム改修のヘルプを行った経験についてお話しします。
まずは、私の直近の経歴を簡単にご紹介します。

直近の簡単な経歴

年月	所属	内容
〜2018年6月	某介護福祉業界のメガベンチャー	介護事業所にて利用者に提供したサービスをもとに国保連（国）へ給付費を請求するSaaSの開発・保守を担当。法改正を2度経験。
2018年7月〜2022年3月	LITALICO	障害児福祉教室にて、利用者に提供したサービスをもとに国保連（国）へ給付費を請求するSaaSの新規開発および保守運用を担当。法改正を1度経験。
2022年4月〜	LITALICO	障害福祉・児童福祉業界で働く人向けの求人サイトの開発・保守・運用を担当

介護業界と障害福祉業界の違いはありますが、これまでに法改正を合計3回（2015年、2018年、2021年）経験しました。

法改正ヘルプで担当したSaaSについて

弊社は2020年12月に福祉ソフト株式会社をグループ会社化しました。
福祉ソフトが扱っていたSaaSは、現在もLITALICOで「かんたん請求ソフト」として提供しています。
このソフトを簡単に説明すると、指定のExcelフォーマットに入力されたデータをアップロードするだけで、国保連に請求するためのCSVファイルを作成できるものです。

そもそも法改正って何？

法改正は主に3年に1度のサイクルで行われます。
内容はその時々によって異なりますが、職員の報酬アップや新しいサービスの追加などが挙げられます。

法改正対応は具体的に何するの？

SaaSの役割は、国保連に請求するためのCSVを作成することです。
国保連側で定義されているCSVのインターフェース仕様は、法改正によって変更されることがあり、それに対応するためのシステム改修が必要になります。
（例：2024年度法改正時のインターフェース仕様書）
また、施設や事業所が利用者に提供したサービスごとに点数（単位数と呼びます）が定められています。
一般の方に馴染みのあるもので例えるなら、病院で診察を受けた際に受け取る診療報酬明細書に「初診〇〇点」といったものを見たことあるのではないでしょうか？
それと同じように、介護・福祉業界でも、例えば「初回サービス提供時は〇〇単位」といった形で単位数が決まっています。
法改正により、この単位数が変更されることがあり（ほぼ毎回変更があります）、その際にはマスターデータの更新が必要です。
なお、3年ごとの法改正以外でも、消費税増税などが発生した場合にはデータの変更が必要になる場合もあります。
（例：2024年度法改正時のサービスコード表（サービスの内容と単位数の一覧）の一部）

白羽の矢が立った背景

私の直近の経歴にも記載していますが、現在は求人サイトの開発部署に所属しており、通常は法改正対応には関与していません。
そのため、法改正に関する情報のインプットは全くしていない状況でした。

法改正の内容も踏まえ、社内体制の見直しが発生した結果「かんたん請求ソフトの法改正」へ急な戦力強化が必要となりました
法改正対応にはドメイン知識が不可欠であり、業務委託の方を採用して対応するには時間が不足していました。
そのため、社内でドメイン知識のある人材を探した結果、これまで法改正を3度経験した私が指名されることになりました。

開発チーム体制

開発チームは以下の3名で構成されました。

私
業務委託エンジニア 2名（うち1名は私より先にプロジェクトに参画）

何をしたのか

かんたん請求ソフトは約30種類のサービスに対応していますが、それらすべてを改修するのは非常に大変です。
弊社には、一部のサービス種類に関する請求計算のみを行う別のシステムがあり、そちらも法改正対応を行うため、それと連携することで対応すべきサービス種類を減らす方針になりました。
ので、実際の法改正対応に先んじてそちらのシステムと連携する改修を行い、それが終わってから連携していないサービス種類に対して法改正対応を行いました。

どうやったのか

私: ドメイン知識はあるが、かんたん請求ソフトのシステムについては未経験。
業務委託A: システムを把握しているが、ドメイン知識が乏しい。
業務委託B: 参画タイミングが私とほぼ同じで、システム知識もドメイン知識も未習得。

といった状況だったので、それぞれ何かしらのインプットが足りていない状態でした。
なので、モブプログラミングを行いそれぞれの知識を共有しつつ進める方針にしました。
なお、私はこれまでもモブプログラミングで業務を行ってきたことがあるのでノウハウは持ってました。

結果は？

モブプログラミングを導入することでレビューのリードタイムがほぼゼロになったので、結果的に開発スピードは上がったと思います。
モブプログラミングはメンバー全員で同時に作業するため並列作業に比べ工数がかかる一方、レビューフィードバックや手戻りを減らせる利点があります。
今回のようにインプットすべき内容が多く、難易度が高い場合には非常に有効な手法でした。

ただし、すべての場面で有効というわけではないため、状況に応じて開発手法を柔軟に選択することが重要だと感じました。

おわりに

今回の対応を通じて、ドメイン知識を持つエンジニアの重要性を再認識しました。
現在、弊社では絶賛エンジニア募集中です。
もしこの記事を読んだ方で障害福祉に知見がある方がいらっしゃれば、ぜひLITALICOで一緒に仕事しませんか？

明日は @k_orita さんの記事になります。
お楽しみに！