BtoB SaaS における業務ルールの大規模な変更にビジネスサイドと共に立ち向かう

はじめまして。高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている菅井俊介です。2019年7月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発・運用を担当しています。

カイポケでは、エンジニアとビジネスサイド*1が積極的に協力して開発やサービス運営を行っています。今回、カイポケにとって大きなイベントである2021年4月の介護報酬改定を乗り越えた話を紹介しようと思います。

まず、介護報酬改定の概要とその重要性について簡単にお伝えします。

介護報酬改定とは

2000年から施行されている介護保険制度は、3年毎に第N期としてテーマを置いて大きな見直しが行われています。今回の2021年4月からは第8期となり、「感染症や災害への対応力強化」や「介護人材の確保・介護現場の革新」などのテーマが設定されています。

参考:厚生労働省から通知された2021年4月介護報酬改定の概要

この見直しのことを介護報酬改定と呼んでおり、そこでは、サービスの金額が調整される程度のシステム対応が軽微で済むものから、既存の計算の概念や仕組みを覆すようなインパクトのあるようなものまで、様々な改正が行われます。

介護報酬改定対応の重要性

介護報酬改定はカイポケにとって、重要なイベントです。 カイポケのコア機能の1つとして、介護事業所が行う請求業務を実現する機能があります。 この請求業務は介護事業者が収入を得るために必要な業務です。 通常、介護事業者は提供したサービスに対して、その報酬の9割を国に請求、1割を利用者に請求することとなっています*2。これは普段私たちが病院に行った際に3割しか負担していないものとほぼ同じ仕組みですので、それを想像していただけるとわかりやすいと思います。

さらに国に請求する9割と利用者に請求する1割を計算する仕組みはかなり複雑です。もし自身で制度を読み解いて請求しようとする場合、自立する程の厚さがある本の3冊分の内容から、関係する内容を理解する必要があり、普段の業務を行いながら実施するのはなかなか無理がある作業となってしまいます。

そのため、介護事業者はカイポケのように請求機能をもつサービスを利用するのです。カイポケとしては、以上のように介護事業者の収入に直結する役割を担っているわけですから、介護報酬改定の内容を正しくシステムに反映することは極めて重要となります。

介護報酬改定を対応していく上での課題

以上のように、カイポケにとって重要なプロジェクトである介護報酬改定への対応ですが、この介護報酬改定対応を行っていく上で乗り越えないといけない課題がいくつかあります。

  1. 開発チームから密に情報共有を行うコストの高さ
  2. 開発期間の短さによる成果物への認識合わせの難しさ
  3. 全ての変更をシステム対応することの難しさ

これらの課題とその解決に向けた取り組みについて、以下で具体的に見ていきます。

開発チームから密に情報共有を行うコストの高さ

介護報酬改定の内容を気にするのは社内のエンジニアだけではありません。カイポケを使っている介護事業者も、業務を行うためには介護報酬改定の内容を知る必要があります。 そこで、弊社としても、介護報酬改定の内容やシステムでどのように対応するかをユーザーの方々に画面上にポップアップ表示できる業務支援ツールを用いて案内したり、後述の特設サイトでまとめるなど、わかりやすく伝える取り組みを実施しています。

このような顧客コミュニケーションを円滑に行うためには、開発チームから社内の顧客接点となる部門に情報を提供する必要があります。開発チームはシステム改修の内容については当然ですが、改修するために介護報酬改定の内容も正確かつ網羅的に把握しているためです。

しかし、開発チームが情報共有にリソースを割いてしまうと、肝心の開発作業に集中出来なくなってしまいます。 そこで、開発チームのスループットを最大化するための取り組みとして、法解釈分析班や法改正窓口を設けて情報の整理を行いました。これらの役割は以下の通りです。

  • 法解釈分析班:開発チームの中でもドメインに詳しいメンバーで構成され、法解釈とカイポケへの影響を把握し、開発チーム内や法改正窓口に連携する。
  • 法改正窓口:ビジネスサイドの介護やシステム開発に詳しいメンバーで構成され、社内で取りまとめた質問を一手に回答する役割。ここで回答出来ないもののみが法解釈分析班に渡される。

こういった役割を事前に明確にして臨んだことによって、ビジネスサイドを通して介護事業者にも正しく情報伝達し、開発チームは実装に集中できました。

f:id:bm-sms-product-dev-saiyo-pr:20211013180349p:plain

開発期間の短さによる成果物への認識合わせの難しさ

介護報酬改定は確定された内容の公開が施行の直前であるため、確定を待ってしまうと開発可能な期間が短くなってしまうという問題があります。

今回の介護報酬改定でも2021年4月1日から施行される内容の確定版が通知されたのは2021年3月31日でした。

介護保険事務処理システム変更に係る参考資料(確定版)(令和3年3月31日事務連絡)

後述するように、機能によってそれがユーザーに必要になるタイミングは異なるのですが、例えば請求を行う計算機能であれば、4月に提供したサービスの請求は5月1日〜5月10日で実施するため、4月末までには機能改修が完了している必要があります。 必要になる改修の規模は介護報酬改定の度に異なりますが、内容が確定してからの1ヶ月で開発が間に合うものではないことが恒例です。 そのため、前年10月ごろから少しずつ公開される大まかな方針や、未確定の情報から内容を把握し、対応内容の検討や実際の開発に着手する必要があります。

ここで問題になるのが、「正しいものを作れるか」という点です。ソフトウェア開発では、開発チームが実装した成果物が、顧客あるいはプロダクトオーナーが欲しいと思っていたものとは違うということがしばしば起きます。求める成果物についての認識を合わせることに失敗し、それに気づかないまま実装してしまうわけです。

介護報酬改定の場合は、元来の制度が複雑・大規模であることに加えて、不確定な情報から仕様を考えていくこともあり、特に上記のような問題が発生しやすくなります。 このような問題を避けるために、早期から介護報酬改定内容をキャッチアップし、関係者の間で認識を合わせていく会を実施しました。

会の概要

  • 介護報酬改定について、内容の整理と共有、見立てをつける
  • 法解釈分析班として3名を選定
  • 法解釈分析班が事前に資料を読み込み
  • 最大50人程参加(開発、運用、QA、カスタマーサクセス)
  • 参加者は自由に発言

これを大まかな改正の方向性が出始めた10月頃から、ある程度内容が出揃う1月までの4ヶ月間、週に1度のペースで続けました。 参加者の中には元介護事業所の職員で制度に詳しい事業部のメンバーも多く、介護のシステムにまだあまり詳しくないエンジニアでも、改正される内容の概要だけでなく背景や目的について共通の理解を持って実装を進めることができました。

全ての変更をシステム対応することの難しさ

介護報酬改定は対応範囲が非常に広いため、全て期間内に対応する事は難しいという問題があります。

介護保険の対象となるサービス種類(訪問介護、通所介護など)の数は非常に多く、請求に関するルールはそれぞれに異なる部分があります。介護報酬改定では、全てのサービス種類に共通の変更もあれば、個々のサービス種類に特有の変更もあり、変更内容は多岐にわたります。したがって、すでに述べたような短い開発期間の中ですべてに対応することは困難です。

そのため、「全部を納期までにやり切らないといけない」という発想ではなく、「どうすれば限られた時間とリソースで顧客への価値提供を最大化できるか」という考え方で開発を進めていきました。

価値提供を最大化するために、システムでの対応の必要性や機能改修が顧客に必要となるタイミングの観点で、開発を行う優先順位をつけていきました。

介護報酬改定の内容の中には、請求のための計算方法が変わるなど、システムでの対応が不可欠なものもあれば、申請書のフォーマットの変更など、システムでの対応までは必要でないものもあります。こういった違いを見極め、必要性の高いものから対応を行うことで、エンジニアのリソースを集中して開発できました。

また、機能改修が顧客に必要となるタイミングという観点も重要です。

以下の図に示す通り、介護事業者は1ヶ月の中でも時期によって行う業務が異なります。 ある月に提供するサービスの計画は前月の下旬に立てるため、介護報酬改定の影響を受けたサービスの登録をはじめて行うタイミングは3月下旬になります。一方で、ある月に提供したサービスに関する請求業務は、翌月の1日~10日に行うため、介護報酬改定での変更内容を反映した形で請求を行うのは、5月1日~10日になります。

つまり、同じ4月施行の介護報酬改定への対応でも、計画を立てる機能に対して、請求のための計算機能は、顧客に必要になるタイミングが1ヵ月ほど遅いわけです。したがって開発する上での優先順位をつけることができます。

例:4月にサービス提供する場合の業務の流れ f:id:bm-sms-product-dev-saiyo-pr:20211013180343p:plain

以上のような優先順位付けを行うには、介護事業者の業務を深く知っている必要があります。業務を深く知る存在というと、「ドメインエキスパート」という概念がありますが、そのような社内のエンジニアに魔法のように介護業務の知識をもたらしてくれる存在は最初からいるものではありません。もちろん、元々詳しい人も社内にはいるわけですが、全てを知っているわけではないため、日頃の開発の活動や、介護報酬改定での取り組みを通じて、業務についての知識(ドメイン知識)を組織として身に付けていくことが必要です。法改正を通して身につけていくための活動を積極的に実施しています。

このような取り組みの一環として、先述した介護報酬改定の内容をキャッチアップしていく会や、新規機能開発の際のユーザーストーリーマッピングなどを、介護事業者の業務に詳しいビジネスサイドのメンバーの協力を得ながら実施し、エンジニアの中にもドメイン知識を蓄積していくことができています。

優先順位をつける際には、顧客が手動で対応できるものについてはその方法を案内するなど、システムで対応する以外の選択肢も持って判断することも必要になります。

この際、システム対応するものはその変更点や使い方を、システム対応の優先順位を落としたものはリリース予定時期や手動での対応方法について、顧客がわかりやすいように詳しくまとめた特設サイトをビジネスサイドに作ってもらいました。

f:id:bm-sms-product-dev-saiyo-pr:20211013180354p:plain

このように、顧客にとって不可欠なものを必要な時期までに届けることに開発チームのリソースを集中投下しつつ、それ以外の部分についても顧客の業務に滞りが出ないようにしたことで、顧客へ提供する価値を最大化できました。

まとめ

介護報酬改定は、介護事業者の方々にとっても、カイポケを運営している私たちにとっても、大きなイベントです。このイベントを乗り越えるためには、技術的なスキルだけでなく、様々な工夫が必要になります。今回紹介した3つの取り組みには、ビジネスサイドの理解や協力が必要不可欠です。エス・エム・エスでは、このようなコラボレーションを実現するための基礎となる、エンジニア組織とビジネスサイドとの関係作りに、日頃から取り組んでいます。

こちらの記事でも紹介している通り、希望していただければ現場のメンバーからも話を聞くことも出来ますので、興味を持っていただけたら是非カジュアル面談からでも聞きにきていただけたらと思います。

tech.bm-sms.co.jp

*1:ビジネスサイド:本稿ではカスタマーサクセス、セールス、マーケティング、コールセンターなど、顧客とのコミュニケーションを行う部署などの総括として記載しています。

*2:年齢と所得に応じて、国負担額は7~9割、残りの1~3割が利用者負担額が異なります。