医療DX入門5 People and Program management、人材・計画管理

KOBAYASHI, Shinji

0. これまでについて

　これまでGAPSフレームワーク[1]にそって、医療DXについて解説してきました。ガバナンス(G)はDXの目的を示し、アーキテクチャ(A)では目的までの工程表を作成しました。人材・計画管理(P)では目的に向かって、工程を進めていきます。


1．はじめに

　GAPSフレームワークではPeople and Program management（人材管理、計画管理）としてPRINCE 2フレームワーク[2]を利用しています。
　ITプロジェクトのマネジメントについては、1980年代から研究が進められPMBOK[3]やISO 9000シリーズ[3]などのガイドラインやフレームワークが活用されてきました。最近では心理的安全性(psychological safety）[3]やサイト信頼性エンジニアリング(SRE; Site Reliability Engineering)[4]など話題となり定着しつつあります。こうしたマネジメント手法はITやDXに限らず一般的なプロジェクト管理に応用可能で医療分野でも取り入れていくべきものです。
　本稿ではPRINCE2をベースとして、DXマネジメントについて概説します。既に病院全体としてISO 9000シリーズのようなマネジメントシステムを利用されているのでしたら、それを応用しても構いません。PRINCE2については研修や資格試験もありますので、深く学びたいかたはそちらをご覧ください。


2. 7つの原則と7つのプロセス

　PRINCE2ではマネジメントについて以下の7原則を重視しています。これらの原則は医療DXでも有用です。以下に概要を示しますが

2.1. 7つの原則

  1. ビジネス正当性の継続の確保

    • ガバナンスで決定された目的にそって、プロジェクトが進行しているかを継続的に検証し、正当性がなくなったときはプロジェクトを中止する。

  2. 経験からの学習

    • プロジェクトの開始から終了まで、他のプロジェクトの経験を含め起きたことを共有し、教訓を特定して学ぶことでプロジェクトの改善につなげます。

  3. 役割、責任、関係の定義

    • プロジェクトにおいて誰がどのような役割と責任を持つのかを明確に定義しておきます。

  4. ステージによるマネジメント

    • プロジェクトを複数のステージに分けて管理することで、起こりうるリスクや不確定要素を減らします。

  5. 例外によるマネジメント

    • プロジェクトでスケジュールや成果物の品質などで許容される範囲を設定します。

    • 許容度の範囲内でプロジェクトの進行が許されますが、許容度を超えた場合にはガバナンス層に報告して、プロジェクトの進め方について決定を求めるようにします。

  6. 成果物重視

    • 最終的な成果物を明確に定義しておきましょう。情報システム導入に関連するすべてのものをリストアップして、それらが完成することを目指しましょう。

  7. プロジェクトに合わせたテーラリング

    • 医療機関の規模や果たすべき役割などにあわせて、マネジメント手法もアレンジしていきましょう。

    • ただし、行き当たりばったりに変えるのではなく、最初にどのようにアレンジした方法でマネジメントしていくかを決めておいた方がいいです。

2.2 7つのプロセス

  1. プロジェクトの開始前（Starting up a Project, SU）

    • プロジェクトの基本的な妥当性と実現可能性を確認。

  2. プロジェクトの指示（Directing a Project, DP）

    • プロジェクトの全体指示を提供し、進捗を監督。

  3. プロジェクトの立ち上げ（Initiating a Project, IP）

    • 詳細な計画を作成し、リソースを確保。

  4. 段階管理（Controlling a Stage, CS）

    • 各プロジェクトフェーズを管理し、成果物を納品。

  5. 製品提供管理（Managing Product Delivery, MP）

    • プロジェクト成果物を計画通りに納品。

  6. ステージ境界の管理（Managing a Stage Boundary, SB）

    • 各フェーズの終わりで次の段階への準備を確認。。

  7. プロジェクトの終了（Closing a Project, CP）

    • プロジェクトを公式に終了し、学びを次に生かす。

3. 運用と管理について

　PRINCE2を医療機関で応用するポイントとしては以下のことが挙げられると思います。それぞれについて解説します。

  • 成果物の定義

  • 役割の明確化

  • 段階的なアプローチ

  • リスク管理

  • 透明性の確保

3.1. 成果物の定義

　ガバナンスで設定したDXの目的や評価指標、アーキテクチャで設定した要件を達成するために必要となる成果物をまずリストアップします。DXは情報システムが導入されれば終わりというものではありません。職員が日々の業務で情報システムを運用していくためには、マニュアル類の整備も必要ですし、患者さんにも業務の変更を伝えなければいけません。マニュアルや講習会の実施、患者さんへの周知のためのパンフレットやWebでの案内なども含めて成果物として定義します。プロジェクトを推進するための活動を記録した日報も必要であればそれも成果物に含めます。
　それらの成果物をいつまでに誰がどのように作成していくのかということを記述した計画書は何よりも重要で、ガバナンス層に提示して内容について了解を得ておく必要があります。
　すべての成果物が完了した場合には経営陣に報告し、プロジェクトの終了を宣言します。

3.2. 役割の明確化

　成果物を定義したら、その成果物を誰が担当するのか役割を決めていきます。ガバナンスで決定されたプロジェクトチームとそのリーダーが何を担当するのかを決めていきます。
　一つの例として、RACIチャートの分類を示します[5]。

  • 実行責任(Responsible)：タスクを実行する1人以上の人物

  • 説明責任(Accountable)：タスクを所有する1人の人物

  • 協議先(Conslted)：タスクに必要なインプットをする人

  • 情報先(Informed)：タスクの進捗または完了について通知を受ける人

3.3. 段階的なアプローチ

　PRINCE2ではプロジェクトを2.2で示したようなステージに分割して管理することを推奨しています。DXプロジェクトは長いものであれば5年、10年単位で行われるものです。5年、10年先まで見越した計画も必要ですが、予測のできない外部要因でプロジェクトの方針を変更せざるを得ないこともよくあります。プロジェクトが短期間で小規模のものであれば、そうしたリスクに対応しやすくなります。1年のプロジェクトを3ヶ月ごとにわけてステージを設定したり、外来業務の変更を診療科ごとに日時を変えて行うなどは検討すべきです。
　もちろん、分割したそれぞれのサブプロジェクトやステージごとに成果物を設定して、ステージが完了して次に移行するときはガバナンス層の了承を得るようにします。

3.4. リスク管理

　リスクとはプロジェクトの進行を妨げる要因のことです。あらかじめリスクとなり得る脅威を評価し、重要度や発生頻度により優先順位をつけてリスク管理を行いましょう。
　プロジェクトの進行に伴い、スケジュールの遅延や予算の追加を伴うような変更が発生する場合があります。そのような例外的な事項についてもあらかじめ予想できれば、どの程度までプロジェクトチームの裁量に任せるのかを例外計画書にまとめておきましょう。例外をどこまで許容するかはプロジェクトによっても異なります。あらかじめガバナンス層とステージごとに決めておくべきです。
　例外計画書にも記載されていないようなイベントが発生したり、設定した範囲を超える例外が発生した場合は、ステージあるいはプロジェクトの中止を含めてガバナンス層と協議します。

3.5. 透明性の確保

　計画書を共有してその進捗について定期的に、あるいは重要なイベントが発生したときに報告することはプロジェクトの透明性を高めます。透明性の高いプロジェクトは共感や協力を得やすくなります。

4. まとめ

　PRINCE2の概要を示して、その勘所を説明しました。2023年度の日本情報システムユーザー会の調査でもITプロジェクトの実に85%は予定通りに完了しないと報告されています[6]。ITプロジェクトは失敗の歴史でもあり、失敗を乗り越えようと、これまでさまざまな研究がなされてきました。今回取り上げたPRINCE2もその一つです。
　電子カルテを始めとした病院情報システムの開発や導入もまた失敗の連続ですし、今でも導入や更新時のトラブルは絶えません。ともすればマネジメントもシステムベンダーやコンサルタント任せになりがちですが、マネジメントが破綻して被害を受けるのは病院であり、患者さんです。医療機関側として何をどのように管理していくのかそれらのステークホルダーと協議した上で、経営陣にも関与してもらう必要があります。
　これまで、ガバナンス、アーキテクチャ、そしてマネジメントについて解説してきました。医療DXに対するアプローチは異なりますが、それぞれDXを成功に導くためのものです。まず、ガバナンスとして目的を定めないとプロジェクトは始まりませんが、アーキテクチャやマネジメントは平行しながら行う作業ですし、それぞれの作業を経た上でガバナンス方針も変わっていくものです。アプローチごとにつながりを持ちながらDXを成功させるのがGAPSフレームワークです。
　GAPSフレームワークの解説は次回の「標準と相互運用性(Standard and interoperability)」で一通り終了です。

参考文献

  1. Asia eHealth Information Network, Mind the GAPS, https://www.asiaehealthinformationnetwork.org/mind_the_gaps/

  2. The Stationery Office. Managing Successful Projects with PRINCE2. ISBN 0-11-330891-4, https://shop.itstrategy.jp/items/83793597

  3. Google re:Work, 心理的安全性を高める、https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness#foster-effective-team-behaviors

  4. Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔　監訳、Sky株式会社 玉川 竜司　訳、SRE サイトリライアビリティエンジニアリング、O'Reilly Japan, 2017, ISBN:978-4-87311-791-1

  5. 鈴木道代、RAM、http://pmstyle.jp/honpo/pmbok_method/tool1.htm

  6. 一般社団法人 日本情報システムユーザー会、企業IT動向調査報告書 2023、https://juas.or.jp/cms/media/2023/07/JUAS_IT2023.pdf