はじめに
Rehab for JAPAN（Rehabと略）でレセプトチームのプロジェクト管理およびチームマネジメントをしている @makikub です。
Rehabのレセプトチームが開発しているレセプトとはデイサービスで利用する請求ソフトのことであり、事業所が利用者一人ひとりの介護サービスやお弁当代などを記録し、自治体や利用者へ支払ってもらう金額を算出し、請求することができるようにするのがプロダクトとしての役割です。
レセプトの開発プロジェクトでは、プロダクト部が作り上げる要件定義と実装者が行う詳細設計の間に基本設計のフェーズを設けており、この基本設計ができる人材の確保が課題となっています。
ただ、基本設計という言葉を少し調べれば分かるのですが、基本設計という言葉が意味する部分は組織によって様々であり、「基本設計はこれをすべき！」といった正解がありません。
そこで、レセプト開発で行なっている基本設計を5W1H形式で紹介することで、社内外への認知を高める狙いで本記事を執筆します。
本記事を読めば、Rehabのレセプト開発で行っている基本設計がどんな狙いで実施され、何をアウトプットとし、どのように役立っているのかをざっくり知ることができます。
ターゲット
- Rehabのレセプト開発で行っている基本設計に興味がある方
- なぜこの基本設計フェーズが必要かの背景を知りたい方
この記事で伝えたいこと
- レセプト開発における基本設計は、難しい介護ドメインの用語で記載された要件定義を開発者に理解してもらうためにも必要
- 基本設計の成果物は暫定で決めてはいるが、ケースバイケースで追加することも多い
What：レセプトTでの基本設計とは何か。
本記事を執筆するにあたり、一般的な基本設計について調べてみました。
基本設計の目的と内容
- 要件定義で決められた機能要件を実現するための具体的な設計を行う。
- システムを構成する機能やコンポーネントを特定し、それらの関係性を明確化する。
- システムの外部仕様(画面設計、帳票設計、データ設計など)を決定する。
- システムの内部構造(アーキテクチャ、データベース設計など)の基本的な方針を決める。
概ねこんな感じですが、これら以外にもレセプトの基本設計が担う大事な役割が2点あります。
PdMと一緒にあるべき仕様とQCDの検討
QCDとは、いわゆる品質（Quality）、コスト（Cost）、納期（Delivery）です。PdMが求めるやりたいことに対して、実現可否とスケジュールに合わせて「実現するならこういうことならできる」といった仕様の落とし所を一緒に模索します。そのため、技術のことだけではなく、現場のユーザーの使いやすさを常に意識する必要があります。
実装者へ噛み砕いて仕様を分かりやすく伝える
本記事を執筆時点では、レセプトの開発者はRehab内の別プロダウトと比べると比較的多いため、状況にもよりますが基本設計者自ら作るシーンは少ないです。しかしながら、開発者が多いと仕様の伝達齟齬も起こりやすく、基本設計者の役割には、開発者へ基本設計の内容を伝達し開発者からの質問に回答することで、開発者が品質の高いソースコードを生産するお手伝いを継続的に実施することも含まれます。
Why：なぜレセプトTでは基本設計が必要か
理由は大きく二つ挙げられます。
- プロダクトの性質上、間違えることが許されない
- そもそも請求ソフトを理解するうえでの介護ドメインの用語が難解
前者について、レセプトを利用することで正しく金額を計算し、事業所から請求する必要があるため、レセプトの不具合などで金額自体を間違えてしまうと経営上のリスクにも繋がります。
後者については、レセプトの要件を理解するための介護保険に関する前提知識が幅広く、今後の介護報酬改定の動向を踏まえた拡張性のある設計に落とし込むという意味でも、基本設計の役割が重要となっています。
Who：誰が基本設計を実施するのか。
本記事執筆時点では、主にレセプト開発のリーダー２名で実施しており、一部をメンバーに協力いただいている状況です。
基本設計は開発プロセスの一つであるため、本来は業務の差し込みが多いリーダーレベルが実施することはプロジェクトの遅延リスクとなるので避けたいのですが、Whatで述べた内容に対応できる人材が不足しており、リーダー業と兼務で基本設計を行なっているのが実情です。
基本設計者として求める要件は以下の通りです。
- システム開発の経験
- 基本設計の経験
- 実装・テストの経験
- PdMや開発者とのコミュニケーション
- 介護ドメインに関する知識
上記の通り求めるものが多く、特に開発経験はまだしも、併せて介護ドメインに関する知識を有した人材はなかなか市場には存在しないため、本記事執筆時点では介護ドメインに関する知識以外の開発経験を有している方を募集中です。
When & Where：いつどのフェーズで基本設計を実施するのか。
WhereとWhenは区別をつけることが難しかったため、同じ章題で解説します。
基本設計は、PdMによる要件定義と開発者による詳細設計の間のフェーズで実施します。また、開発者へ説明するためにも、PdMから要件を受けて設計を具体化する際に基本設計のドキュメントを作成します。
ただし、ドキュメント自体は基本設計フェーズが完了したらお役御免ではなく、詳細設計以降も間違いや不整合があれば修正します。
要件定義から詳細設計まで一貫して、ドキュメントのメンテナンス負荷を下げるためにも、基本設計以降のフェーズでは同じことを意味する資料はできるだけ作らないようにしています。そのため、基本設計の成果物についても、実装・テスト以降も立ち返って確認し、メンテナンスを実施するようにしています。
How：どのように基本設計を作成・実施するのか。
作成するべき基本設計の成果物はひとまず以下と決めており、PdMが考えるやりたいことに合わせて取捨選択します。
- データベースのスキーマの追加が必要な場合
- テーブル設計書、ER図
- ファイルの入出力がある場合
- ファイルの項目定義
- 帳票が必要な場合
- 帳票の項目定義書
- 画面の追加がある場合
- 画面項目の制御（非表示、表示、活性、非活性）
- 難解なロジックが追加となる場合
- 処理フロー図
- テストケース作成が関連項目が多く複雑となる場合
- テストシナリオ
ただし上記はあくまで参考程度で、必要とあれば別途追加します。
上記をまとめたレセプトの開発フローと対応する成果物の関係は以下の通りです。
またドキュメントは作って終わりではなく、開発者へのインプット会も実施します。その際は、資料の内容だけに留まらず、なぜこのような設計にしたのかという背景を意識して説明するようにしています。
まとめ
レセプト開発で行っている基本設計を5W1Hで紹介してみました。いかがでしたでしょうか？
やはりレセプトという特性上、一般的にスタートアップでイメージしやすいアジャイル開発というよりは、SIerのようなある意味ウォーターフォールのような開発フローを取ることで、品質面の担保を優先しています。とはいえ、Rehabはまだまだスタートアップのため、事業を前のめりで推進できるようにするためにも、開発スピードも要求されます。
レセプト開発での基本設計は、その開発フローの中でもPdMと開発者の間を繋ぐ重要な役割を果たし、システムの品質と開発効率を向上させるために欠かせない要素となっています。今後も、基本設計を含めた開発プロセスを改善し続けることで、レセプトを現場で使いやすいプロダクトにどんどん育てていきたいと考えています。
Discussion