ITエンジニアは「ドメイン知識」の習得を求められることがあるが、技術知識の取得と比べると優先度は低くなりがちだ。制度改正の多い介護・医療分野のドメイン知識習得に取り組むエス・エム・エスの事例から、ドメイン知識習得の重要性とそれを開発に生かすためのポイントを解説する。第1回は、開発者のドメイン知識取得の重要性と体制づくりについて。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
デジタルトランスフォーメーション(DX)がうたわれて久しい昨今、システムの内製化に舵を切る企業は着実に増えているように見えます。その背景には、世界的に猛威を振るっている新型コロナウイルス感染症(COVID-19)による影響も少なからずあります。直接会うということがリスクとなり、リモート会議や、文書も紙からデジタルへと、業務の変化が余儀なくされています。
しかし、業務の変化は社会情勢などの外的要因によるものだけではありません。むしろ事業拡大や転換などの内的要因によることの方がほとんどでしょう。システムはデジタル化した業務を体現しています。
介護事業所の事務システムを例に挙げます。介護報酬は、診療報酬と同様に利用者に提供したサービスごとに定められた点数(単位数)に、単位数単価を掛けることで計算できます。
報酬額=単位数(点数)×単位数単価
この計算式をシステムに落とし込む際、どう考えるべきでしょうか。一見すると報酬額、単位数および単価はただの数値(Number型)のように見えます。しかし、介護報酬の計算において報酬額に単位数を掛けたり、単位数と単位数単価を足したりすることはありません。介護報酬の仕組み、つまり「ドメイン」を理解すると、それらを別の型として意識できるようになります。
上述の計算は介護事業所の事務システムではさまざまな場所に現れます。これらが全てシステム内で同じ数値(Number型)として記述されていると、計算式に関わる変更の影響範囲が測りにくくなったり、システムの改修を繰り返すにつれてNumber型の変数が思わぬ使われ方をしてバグを作り込んでしまったりする危険もあります。柔軟過ぎるコードでは、逆に業務の変化に対応できなくなってしまうのです。
以上は一例ですが、開発者の業務への理解は大変重要です。業務の変化に対応できないシステムを構築してしまうと、システムが業務の変化の足かせとなる可能性があります。
エス・エム・エスでは、介護事業者向けの経営支援サービスとしてSaaS型のクラウドサービス「カイポケ」を提供しています。高齢社会においてなくてはならない介護・医療サービスは、それぞれ法制度の下に事業者が高齢者に対して提供します。法制度はそのときの社会情勢などにより見直され、医療報酬は2年、介護報酬は3年ごとにそれぞれ改定(報酬改定)が行われます。2021年度の介護報酬改定においても、COVID-19の影響を受けて報酬が上乗せされたり、ICT活用による規制緩和などが含まれたりしています。介護・医療に関わるこのサービスを開発・運用するためには、法改正によって生じた変更点に追従し続ける必要があります。
変化に素早く対応するには、システムを小さく区切ることが重要です。例えば、上述の報酬改定の影響を大きく受ける「介護報酬の計算」と「(介護サービスの)利用料の回収」はどちらも金額に関わります。「利用料の回収」は多様化する決済方法への対応や回収状況の可視化などにも関係します。一方で「介護報酬の計算」は制度の影響を強く受けます。このように事柄によって関心事が異なります。
これら2つの関心事をシステムとして切り離しておくことでお互いの影響を小さくすることができ、それぞれの要求の変化に対して素早く対応できるようになります。システムを小さく区切る境界線を見つけるためにはドメイン知識が欠かせません。システムを開発する開発者自身がドメイン知識を身に付けておくことが重要です。
システムを改修して報酬改定に対応する場合は、介護保険制度というドメインについて知っておく必要があります。報酬改定ではこの単位数や計算式が見直されますが、改定内容の提示から施行まで3カ月程度しかありません。また、初回に提示された内容が更新されることもあります。そのため、改定内容を素早くキャッチアップしシステムを改修する必要があります。
介護保険制度をはじめとした福祉制度は非常に複雑で、医療保険制度や障害福祉制度など複数の制度が関わり合っています。介護サービスを提供している事業者は単一もしくは複数の制度に基づいて事業を行っています。開発者が幅広い事業者にリーチするには介護保険制度だけでなく、他の制度にも対応する必要があります。
しかし、個々の開発者がそれらの制度を理解しつつ、システムを開発するのは至難の業です。医療報酬や介護報酬は制度ごとに改定のサイクルが異なります。そこで当社では制度をコンテキストの境界として捉え、開発チームもおおよそ制度ごと(介護、訪問看護《医療》、障害者・障害児)に編成しています。それぞれのチーム単体か、チーム間で協力し合いドメイン知識の習得にチャレンジしています。
報酬改定の対応は時間との戦いです。施行日はあらかじめ決まっていますが、改定内容は時間をかけて議論がなされていきます。対応内容を元に現行のシステムに習熟しているメンバーを中心としたサブチームを編成し、開発の並列度を上げる方法をとっています。
また、既存システムの開発・運用に加えてシステムを安定して提供し続けるために、機能をマイクロサービスに切り出す取り組みも実施しています。ただ、既存システムの開発や運用に携わるメンバーが新規アプリケーションの開発を兼務すると、新規アプリケーションの開発が進まなくなるという問題があります。当社はシステムの持続可能性を維持するためにマイクロサービスへの切り出しは必須であると捉えており、専任メンバーのチームを編成してこの取り組みを進めています。
制度などが改定される際はその対応範囲でチームを分け、チームごとにスコープを小さくしてドメインの習得およびシステムの開発・運用に当たっています。しかし、それでも開発者だけでは制度の解釈が難しく、ドメインを完全に理解できているわけではありません。制度や顧客業務に精通しているドメインエキスパートの存在はとても重要です。
ドメインエキスパートは、報酬改定といった制度に強く依存している部分についてその足掛かりを担うことが多いです。繰り返しになりますが、報酬改定は幾度も議論が行われて徐々に固まっていきます。最終的に改定内容が確定してからシステムの対応範囲を考えていると、リリースが間に合いません。
議論は議事録が公開されているので、ドメインエキスパートがその内容を追いかけて報酬改定における方針や概要をまとめ、それを元に開発者がシステムへの影響範囲などを検討します。また、開発チームは制度やスコープを絞っていますが、介護と医療の連携や介護保険と障害福祉を一体に提供する共生型サービスなど、制度間での関わりも無視できません。特定の領域に絞らず知識があるドメインエキスパートが開発のキーとなります。
当社では開発チームごとに裁量があり、ドメイン知識の習得についてもさまざまな取り組みを行っています。既存システムを運用・開発しているチームと、マイクロサービスとして機能を切り出すチームとではそのメンバーの習熟度合いや開発フェーズが異なるため、その取り組みも少し異なる部分もあります。下図に取り組み事例を紹介します。
これらの取り組みでドメイン知識をキャッチアップし、システムに落としこんでいます。次回以降はそれぞれの取り組みを具体的に紹介していきます。
介護事業者向け経営支援サービス「カイポケ」を開発。
同社テックブログの[SMS TECH BLOG]にて、「複雑なドメインにベイビーステップで立ち向かう」などの記事を公開中。
Copyright © ITmedia, Inc. All Rights Reserved.