ドメイン知識の習得は、個人のタスクじゃない――開発チーム全体で取り組むオンボーディングとその知見:ドメイン知識と開発(2)
ITエンジニアは「ドメイン知識」の習得を求められることがあるが、技術知識の取得と比べると優先度は低くなりがちだ。制度改正の多い介護・医療分野のドメイン知識習得に取り組むエス・エム・エスの事例から、ドメイン知識習得の重要性とそれを開発に生かすためのポイントを解説する。第2回は、開発チームがドメイン知識習得のために実施した取り組みと、それによって得られた知見について。
前回は、開発チーム(開発者)がドメイン知識(業務知識)を習得することの重要性を説明しました。今回はドメイン知識を習得するためにそれぞれの開発チームで行っている取り組みとそれによって得られた知見について、クラウド型の介護事業者向け経営支援サービス「カイポケ」の開発チームを例に説明します。
開発チームにおける取り組みと得られた知見
キャッチアップを個人のタスクにしない
既存のシステムを運用・開発しているチームでは、新規に参画するメンバーと比べると知識量に差があります。新規に参画する開発者の多くは介護・医療の報酬制度に詳しくありません。コードレビューや普段の会話などでも、知識量に差があると会話が成立しないこともあります。素早く開発に入ってもらうために、ドメイン知識のキャッチアップを個人のタスクとするのではなくチームとして取り組んでいます。
新規に参画するメンバー向けのオンボーディング
未経験の領域についての知識を習得するのは大きな労力が必要です。新規メンバーが参画した際には、ドメイン知識を習得するための足掛かりとなることを目的として、開発者が主体的に勉強会を実施しています。講師役は最近参画したメンバーが中心に行うことで、理解が曖昧な箇所の発見にもつながります。
オンボーディングにおいては、できる限りの時間を共有して説明などに充てることが望ましいですが、既存メンバーはそれぞれのタスクもあるため全ての時間を共有することは容易ではありません。ドキュメントなどを用いて各自で知識を習得する時間も重要です。システムの「教科書」として機能や運用面などを網羅的にドキュメント化して残す取り組みや開発時に得られた知見のドキュメント化など、これらを使って知識の習得に役立てています。
ほとんどのドキュメントはツールを統一して作成しています。また、新しい記事が作成、更新されるとチャットツールに通知されるようにしています。必要な情報を取得するには検索が最も有効な手段ですが、検索をする場合は適切なキーワードを知っておく必要があります。チャットツールの通知情報などからキーワードや他のチームが取り組んでいる内容を把握できるため、後になって情報収集に役に立つこともあります。
なお、最近はオンラインホワイトボードのようなツールの利用も増えています。オンラインホワイトボードは会議の際のコミュニケーションに非常に役に立ちますが、ドキュメントツールから独立して存在していると、上記のような利点が損なわれてしまいます。概要はドキュメントツールに記述し、オンラインホワイトボードを埋め込んだり、リンクを貼ったりすることでドキュメントツールの検索に引っ掛かりやすくなるよう工夫しています。
新機能開発・報酬改定
新しい機能を開発する際はユーザーストーリーマッピングを活用することが増えています。法改正や標準仕様への対応は、限られた時間の中で行う必要があります。ユーザーストーリーマッピングを行うことで、その要求が整理され、開発の優先度付けにも役立ちます。
モブプログラミング・コードレビューの実施
メンバー間のコンテキストをそろえるためにモブプログラミングや、コードレビューを同期的に実施しました。例えば変数名や関数名の付け方などをとっても、ドメイン知識や技術的知見に差がある場合、テキストベースでやりとりすると想定以上に時間がかかってしまうことがあります。会話しながら進める時間を用意することでお互いの知識の差を埋め、コンテキストをそろえることに役立ちます。コンテキストがそろえばテキストベースでもレビューを行うコストが下がります。
マイクロサービス化チームにおける取り組みと得られた知見
弊社では、機能をマイクロサービスとして切り出すチャレンジを行っています。取り組みに注力するための独立したチームを置いています。ドメイン知識が未熟な開発メンバーで発足したため、チーム全体でドメイン知識の習得に取り組みました。
ドメイン知識の乏しいチームのキャッチアップ
マイクロサービス化チームの開発メンバーは当初、介護業界について習熟しているメンバーがいない状態で、チームとしてドメイン知識のキャッチアップに取り組みました。マイクロサービスとして機能を切り出すとスコープが小さくなるので開発や運用、保守が容易になることが期待できますが、マイクロサービス間のトランザクションを制御することが難しくなり、システム全体の整合性維持が課題になります。業務のトランザクションの境界で機能として提供する必要があり、モノリシックなシステムのどの部分を切り出すかを検討するためにはドメイン知識が必須です。
トランザクションの境界を見つける
検討の結果、システムとして非常に重要で毎回の報酬改定での影響も受ける「請求業務」の部分に見当を付け、開発を始めました。請求業務は、提供した介護サービスの内容に加え、介護サービス利用者や事業所の状態などが複雑に絡み合います。そこで、複雑な計算パターンを最初から網羅するのではなく、請求に関わる一連の業務の流れ(一本道)を見つけるというアプローチをとりました。この「一本道」は連続的な業務、つまりマイクロサービスとして整合性を保っておいた方が良いトランザクションの境界を示しています。
そのために実際に請求業務を手で行い(ロールプレイ)、ユーザーストーリーマッピングを行いました。実際の業務を手で行うと、その業務におけるドメインオブジェクト(エンティティ)と属性が明らかになってきます。そして、ユーザーストーリーマッピングを行うことで必要な振る舞いが見えてきます。また、新規にアプリケーションを開発する際に、テストはそのシステムの最初のユーザーになります。テストを積極的に書いて、振る舞いを整理することにも活用していました。
ドメインの理解が進むと、コンテキストの違いが違和感として現れることがありました。請求業務は「保険者(健康保険組合)に対する請求」と「利用者に対する請求」があります。当初の理解ではどちらも「金額計算のロジック」があるという程度の理解でしたが、それぞれ請求する対象が異なるので、関心事も異なります。きっかけはメンバーの違和感でしたが、一度立ち止まってコンテキストの境界を再度引き直し、アプリケーションとしてのスコープも小さくしました。スコープを小さくしておくことは、開発する上でも重要です。
ドメイン知識を計算式に落とし込む
モノリシックなシステムの改修においては、言語やライブラリを新しく導入することは容易ではありません。無作為にライブラリを増やすと、保守性が低下してしまいます。アプリケーションとして独立させて開発するアプローチは、技術選定を行う機会となります。言語として既存のシステムを踏襲せず、表現力の高い「Kotlin」を選択しました。前回の冒頭で介護報酬額は以下のような式で計算されることを紹介しました。
報酬額=単位数(点数)×単価
class 単位数(val value: Int) { operator fun times(tanka: 単価): 報酬額 = 報酬額((this.value * tanka.value).toInt()) } class 単価(val value: Double) class 報酬額(val value: Int) { override fun toString(): String = "報酬額は${value}円です" } fun main() { val amount: 報酬額 = 単位数(200) * 単価(10.9) println(amount) // 報酬額は2180円です }
単位数と報酬額をどちらもint型で定義してしまうと、改修を繰り返すうちに思わぬところで変数が使い回されてしまうことがあります。単位数と報酬額をクラスとして分けておくことで、報酬額に単価をかけるといった存在しない計算をコンパイルレベルで防ぐことができます。
実際に今動いているシステムへの接点
既存システムの運用・開発経験から得られる知見はとても重要です。介護報酬の計算には非常に多くの変数が絡んでおり、そのパターンの網羅性を最初から担保することは容易ではありません。そこで、早い段階で本番の環境に構築し、稼働している既存システムへのリクエストをトリガーとして、マイクロサービスでも計算を行い計算結果の差分を取得するというアプローチを行いました。これによって、計算におけるエッジケースの早期発見や、実際のデータの流量によりパフォーマンス上の課題点なども見えてきます。
開発者がドメイン知識を習得することのメリット
ドメイン知識習得のための取り組みや、それによって得られた知見を紹介しました。変化が早く複雑化する要求の中でシステムを開発するためには、システムとして絶対に外せない部分や、柔軟性が必要な部分などを明確にする必要があります。開発者が習得したドメイン知識をシステムで表現することにより、変化に強いシステムの開発に一歩近づくことが可能となります。
著者紹介
株式会社エス・エム・エス
介護事業者向け経営支援サービス「カイポケ」を開発。
同社テックブログの[SMS TECH BLOG]にて、「複雑なドメインにベイビーステップで立ち向かう」などの記事を公開中。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- なぜドメイン知識(業務知識)の習得が重要なのか? 変化する知識に対応し続けるために
ITエンジニアは「ドメイン知識」の習得を求められることがあるが、技術知識の取得と比べると優先度は低くなりがちだ。制度改正の多い介護・医療分野のドメイン知識習得に取り組むエス・エム・エスの事例から、ドメイン知識習得の重要性とそれを開発に生かすためのポイントを解説する。第1回は、開発者のドメイン知識取得の重要性と体制づくりについて。 - 「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”
2021年6月21〜22日にガートナーが開催した「アプリケーション・イノベーション&ビジネス・ソリューション サミット」で、ガートナー ジャパンの桂島 航氏が「コンテナとKubernetesをITリーダーはどのように活用すべきか」と題して講演した。その内容をレポートする。 - 課題は「知見やノウハウ不足」 トライトグループが「保育施設におけるDX実態調査」の結果を発表
トライトグループは、「保育施設におけるDX実態調査」の結果を発表した。保育活動に活用できるツールの導入は進んでいるものの、DXを推進するための「知見やノウハウの不足」が課題になっていることが分かった。