介護事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの宗です。２０１８年に入社し、早いものでこの春には７年目に入ります。（自分としてはまだ４年経ったくらいの気分なので、数えてみては毎回驚いてます） 今回は、エス・エム・エスに中途で入社して以降、自分がどんなことをやってきたかを振り返りつつ、一部を具体的にご紹介してみようと思います。今と状況が変わっているところもありますが、エス・エム・エスでの仕事ってどのような雰囲気だろうと気になっている方の参考になれば嬉しいです。
これまでやってきたこと
私は入社当初から、カイポケのレセプト機能周辺をメインとして担当してきました。最初の数年は現在稼働しているカイポケについて改修や改善、機能追加を行い、その後カイポケのリニューアルプロジェクトに異動して今に至ります。異動後は介護における請求業務周りの整理やモデリングを経て、それらの結果を元に日々開発を進めています。
ここで言う「レセプト機能」とは、介護施設や事業所が、提供したサービスに応じた報酬を国に請求するための機能群です。詳しい内容は割愛しますが、簡単に言うと、利用者の方々の状態を元に毎月どのようなサービスを提供するかのスケジュールを立て、実際にサービスを提供し、その結果を元に請求する、というサイクルを楽に行えるようにするものです。
さて、この６年の間、継続的に介護保険制度の請求にまつわる部分に関わってきたのですが、その中でも印象的だったものを挙げるとすれば、制度変更に対応するためにカイポケで新しいサービスを扱えるようにしたことと、リニューアルプロジェクトにおいて、イベントストーミングを用いて請求業務のドメインを捉え直したことでしょうか。後半はこの２つについて、少し掘り下げようと思います。
法改正によるサービス追加の対応
介護報酬の文脈での「サービス」とは、事業所が介護報酬を国へ請求する際に「利用者さんへどういったケアを提供したか」「事業所の体制を健全なものとするためにどういった取り組みをしているか」といったことを表すための統一されたメニューのようなものです。基本的には「どのサービスを、いつ、誰に提供したか」という情報を元に請求が行われます。
現行のカイポケの開発を担当していた頃、法改正により新たなサービスが導入されるということがありました。法改正において、サービスの追加自体は珍しいことではないのですが、その時新たに定義されたサービスはこれまで扱われてきたものと少し異なる報酬計算が必要なものでした。そのため、既存のコードに手を加え、新しい計算方法に対応したロジックを入れることとなりました。 （介護報酬の計算については、こちらの記事を読んでいただくとイメージがつきやすいかと思います） tech.bm-sms.co.jp
一連の対応は、他のメンバーとペアになって行いました。当時の私は、介護報酬の計算についてはまだまだ初心者だったので、新たな計算方法とそこへつながる前提知識をペアの方に教えていただきつつ、既存コードで関連のありそうな場所の見当をつけていきました。請求金額を計算する箇所もそうですが、UIからユーザーが当該のサービスに関する設定を編集できるようにする必要もあったため、そういった画面やコードについてもユーザーストーリーマッピングで洗い出し、調査していきました。調査を終えて修正内容の方針を決めた後は、既存コードのリファクタをしたり可能な範囲でテストコードを書いて、見通しを良くした上で実際のロジック追加を行う……というように進めました。
また、制度が施行されるタイミングまでは、この新しいサービスは存在しないものとして扱わなければなりません。新サービスの設定周りのデータによって制度施行の前後で不具合が起きないよう、特定のタイミングでデータパッチを当てるといった対応も行いました。
思い返してみると、これがはじめて報酬計算の複雑さにしっかり向き合ったタイミングだった気がします。加えて、既存の機能に手を入れるためにはシステム、制度それぞれについての理解が不可欠であるものの、実際にはそれで十分ではなく、ユーザーがカイポケの中で計算へ至るまでの道もちゃんと把握・整備してはじめて「対応できた」と言えるんだということを実感しました。
イベントストーミングによる請求業務の整理
前節のサービス追加対応を終えてから数年後、現在も所属しているリニューアルプロジェクトへ異動しました。当時やるべきこととしては（ユーザーが事業所を運営していく中で特に重要な）請求業務のドメインの再整理がありましたが、元々複雑な領域のため、ドメイン駆動設計（domain-driven design、以下ではDDDと書きます）を使って進めていくことになりました。
とはいえ、DDDの考え方に則ってドメインを整理していくという作業は初めてのことだったので、プロジェクトの有識者に助言や並走をしてもらいながらDomain-Driven Design Starter Modelling Process に挙げられている８つのステップに沿って、チームで少しずつ取り組んでいきました。ここに挙げられているワークの一部は、当時実施するには時期尚早であまり具体的に分析できないといったものもありましたが、特に２つめのステップで推奨されていたイベントストーミングは得るものが多く、自分にとっても刺激的なものだったと記憶しています。
イベントストーミングでは、大まかに言うとユーザーの行動やそれに付随して発生する判断の内容、その際に参照される情報などを付箋に書き出し、タイムラインに沿って並べていきます。その過程でドメインへの理解を深め、DDDで言うところの集約や境界づけられたコンテキストを探っていくのですが、最終的に１枚の大きな、ドメインの地図とも言えるようなものができあがった時、それまでカイポケの開発を通して自分の中に作られてきた断片的な知識が補完され、繋がりを持って可視化されたような感覚を持ちました。また、その結果をベースとして障碍や医療分野での請求業務についてもある程度整理したところ、介護分野との差分やそれぞれに特有の困りごとがあることがわかり、その性質の違いも興味深いものでした。
イベントストーミングを実施した後には、その結果を元にしてDomain-Driven Design Starter Modelling Processの後続のワークを進めたり、ユビキタス言語の検討などを行っていきました。またプロジェクト単位でも、マイクロサービスの分け方やチーム編成を考える際に活用するということもありました。これまでの開発で作られてきたものは、イベントストーミングを通じて得られたドメイン理解が土台となって積み上げられたものだと感じています。
おわりに
今回の記事を書くにあたって、過去の業務内容を全体的に振り返るということをしたのですが、これがなかなか大変な作業でした。しかし振り返っていくにつれて、介護保険制度の、特に請求にまつわる部分にいろいろな角度から触れてきたのだなという実感も沸いてきました。請求業務や報酬計算への理解が深まるほどにその複雑さも身に染みて感じられるようになり、それが「この分野（特に報酬計算）をどうにかきれいにモデリングして、自然な形のコードに落とし込みたい」という今のモチベーションに繋がっていったように思います。嬉しいことに、現在リニューアルプロジェクトでそれを叶えられる立場にあるので、目指したところに少しでも近付けていけるよう、今後も頑張っていきたいと思います。
ここまで書いてきたことが、どなたかの参考になれば幸いです。もし記事の内容について「このあたりの話をもっと詳しく聞いてみたい」など興味を持たれた方がいましたら、カジュアル面談も実施中ですのでお気軽にお声がけください！
