トピック1.1 — 運用モデル

一文で言うと： ターゲット運用モデル（TOM）とは、組織の戦略が、バリューストリーム、ケイパビリティ、チーム、ガバナンス、技術、データ、サプライヤーを通じて流れ、デジタルヘルス・ケアの成果を生み出す仕組みを意図的に設計したものであり、その形を正しく整えられるかどうかが、下流のすべてが速く安全になるか、遅く脆くなるかを左右します。

医療・ケアにおいてなぜ重要か#

デジタルヘルス組織の多くは、才能や技術の不足で失敗するのではありません。運用モデルが自分たちと戦っているから失敗するのです。資金は期間限定のプロジェクトに結びつき、意思決定権は曖昧で、どのチームも同じログイン、統合、監査の基盤を作り直します。その結果、公費で二重のコストが生じ、臨床安全は一貫せず、サービスは統合ケアシステム（ICS）をまたいでデータを共有できません。

この領域の運用モデルが特徴的なのは、相反する善を両立させなければならないからです。主権を持つ組織、つまりトラスト、地方自治体、一般診療所の自律性を尊重できるほど連合的でありながら、患者にそれらをまたぐ一つの安全な体験を提供できるほど一貫していなければなりません。ダウンタイムがケアに影響しうる中で、運用（run）（臨床システムを安全に利用可能に保つこと）と変更（change）（それらを改善すること）のバランスをとらなければなりません。そして支出は比例的でなければなりません。公的な説明責任と臨床安全に足るほど重く、反復を窒息させない程度に軽いアシュアランスです。TOMは、こうしたトレードオフを偶然に任せず、明示的にする場です。

中核概念#

運用モデルの層。 有用なTOMは積み重ねであり、各層が上の層を支えます。

• 戦略と成果 — 改善するために存在する、測定可能な集団とサービスの成果（しばしばOKRとして表現されます。トピック1.3 — エビデンスに基づく意思決定参照）。
• バリューストリーム — 利用者に価値を届けるエンドツーエンドの流れ。たとえば「患者を紹介し、トリアージし、治療する」。組織図ではなく、市民の旅路を軸に組織されます。
• ケイパビリティ — できなければならないこと（ID管理、予約、臨床記録、分析）。ソリューションが変わっても、ケイパビリティは安定しています。
• チーム — ケイパビリティとバリューストリームを提供するために組織された人々（後述のTeam Topologiesを参照）。
• ガバナンスと意思決定権 — 誰が何を決め、どのようにアシュアランスが適用されるか。
• 技術とデータ — チームが構築の土台にするプラットフォーム、標準、データアーキテクチャ。
• サプライヤー — 調達する市場と、その管理の仕方。

トップダウン（戦略→バリューストリーム→ケイパビリティ）で設計すると、チームと技術が、レガシーな構造ではなく成果に整合し続けます。

集中型、連合型、プラットフォーム型のモデル。 集中型は、デリバリーを一つのチームや独立行政法人に集約します。一貫していて標準化のコストは低い反面、ボトルネックになりやすく、地域のニーズから遠くなりがちです。連合型は、デリバリーをトラストや地域に委譲します。対応が早く、地域が主体になれる反面、重複と乖離が生じやすくなります。プラットフォーム型は、両者を調停するパターンです。中央のチームが、共有され再利用可能なケイパビリティ（ID、相互運用性、ホスティング、デザインシステム）をプラットフォームとして提供し、連合したチームがその上で高速に構築します。成熟した医療システムの多くは、「プラットフォームと連合の組み合わせ」に収束します。

Team Topologies。 このフレームワークは、4種類のチーム、つまりストリームアラインド（バリューストリームを所有）、プラットフォーム（セルフサービスのケイパビリティを提供）、イネーブリング（他者のケイパビリティ習得を支援）、複雑なサブシステム（アルゴリズムなどの深い専門作業）を挙げ、それらの間の低摩擦な相互作用を重視します。プラットフォームモデルにきれいに対応します。プラットフォームチームは、ストリームアラインドなチームの認知負荷を減らし、ユーザーと臨床の価値に集中できるようにします。

運用（run）と変更（change）。 運用は、稼働中のサービスを安全で利用可能に保つこと、変更はそれらを改善または構築することです。サービスを構築も運用もするプロダクトチーム（「作った者が運用する」）は、フィードバックのループを閉じ、安全性を高めますが、そのバランスには正直に資金を付けなければなりません。変更の資金を出すために運用を飢えさせることは、臨床システムを劣化させる典型的な道です。

実用最小限のプラットフォーム（TVP）。 Team Topologiesに由来します。プラットフォームは、ストリームチームの摩擦を本当に減らす共有サービスの最小の集合であるべきで、それ以上ではありません。作り込みすぎたプラットフォームは、それ自体がボトルネックとなり、それ自体がレガシーになります。すべてのチームが本当に必要とする少数のケイパビリティ（認証、相互運用性レイヤー、ホスティング、デザインシステム）から始め、実証された需要があるときだけ拡張します。

ベストプラクティス#

1. 組織図から積み上げるのではなく、成果から下に向けてモデルを設計する。 動かさなければならない集団とサービスの成果から始め、それを届けるバリューストリームを導き、そのあとでチームと技術を設計します。既存の階層に錨を下ろしたTOMは、現在のサイロを自動化するだけです。

2. プラットフォームと連合の形を採用する。 共有ケイパビリティをセルフサービスのプラットフォームとして中央から提供し、トラストや地域のストリームアラインドなチームにその上で構築させます。これにより、安全性と相互運用性における全国的な一貫性と、地域の速さと主体性が両立します。この領域が求める調停です。

3. プロジェクトではなくプロダクトに資金を付ける。 期間限定のプロジェクトから、バリューストリームに沿った継続的に資金の付くプロダクトチームへと資金を移します。プロジェクト資金は、チームが領域を学び終えたまさにその時点での解散を強います。プロダクト資金は、医療サービスが必要とする安全知識と反復を維持します（トピック5.0 — プロダクト主導の仕事参照）。

4. 支出管理を比例的かつ段階的にする。 エビデンスに結びつけた段階的な資金を用います。プログラム全体を最初に承認するのではなく、ディスカバリー、アルファ、ベータ、ライブの各ゲートで資金を解放します。GDS型の支出管理とNHSのアシュアランス経路は、検証されていないアイデアへの大きな埋没費用を防ぐために存在します。全面的な官僚主義としてではなく、リスクと価値に応じた閾値として適用してください。

5. RACIまたはRAPIDのマップで意思決定権を明示する。 権限の曖昧さは、デリバリーが停滞する最も一般的な原因です。重要な意思決定の種類ごとに、誰が実行責任・説明責任・協議・報告を負うか（RACI）、あるいは誰が提案し、同意し、実行し、助言し、決定するか（RAPID）を明記します。それを公開し、チームが、自分たちに権限のある決定をエスカレーションしなくて済むようにします。

6. プラットフォームを薄く、需要主導に保つ。 二つ以上のチームが同じものを必要とすることが示されたときだけ、共有ケイパビリティを構築し、プラットフォームを、社内のチームという独自のユーザーを持つプロダクトとして扱います。壮大なプラットフォームを先に作りたい衝動に抵抗してください。実用最小限のプラットフォームは、採用を通じて、その範囲を勝ち取ります。

7. サプライヤーを、モデルの外ではなく一部として管理する。 どのケイパビリティが戦略的（構築・所有）で、どれがコモディティ（購入）かを意図的に決め、中核となる臨床データについて単一サプライヤーへのロックインを避け、契約にオープン標準と撤退の権利を求めます。サプライヤーは運用モデルの一つの層であり、その仕事の進め方は、あなたのものと両立しなければなりません。

8. 意思決定権を明示する。 運用モデルは、誰が何を決めるか、つまり、どの選択がプロダクトチームに、どれが臨床安全の権限者に、どれが取締役会に届かなければならないかを、人々が知っているときにのみ機能します。意思決定権をマッピングし、各決定を、それを安全に担える最も低いレベルに移して、デリバリーが不要なエスカレーションで妨げられないようにします。権限の曖昧さは、遅く防御的なデリバリーの最も一般的な原因の一つです。

9. 運用モデルを、進化させるプロダクトとして扱う。 ターゲット運用モデルは、一度決めて壁に額装するものではありません。需要、技術、パートナーシップが変わるのに合わせて点検し、エビデンスに基づいて適応させます。いくつかのシグナル、つまり仕事の流れ、意思決定までの時間、手戻り、チームの健全性を観察し、組織改編の流行に応じてではなく、構造が明らかに妨げになっているときに変えます。

チームで話し合うための問い#

1. 私たちの運用モデルは、成果とバリューストリームから下に向けて設計されているのか、それとも単に既存の組織図とそのサイロを自動化しただけなのか。 この問いは、現在の階層に錨を下ろしたTOMは既存のサイロを固定化するだけだという、本トピックの中心的な警告に迫るものです。組織改編の前に、テーブルに載せる価値があります。医療・ケアの場でこれが重要なのは、バリューストリームが、主権を持つ組織をまたぐ市民の旅路（紹介し、トリアージし、治療する）に沿うのに対し、組織図は制度上の境界に沿うためであり、後者に基づくモデルは、公費で、分断され相互運用できないサービスを生み続けるからです。正直に議論すべき緊張は、成果から上から下へ設計することは本当に混乱を招くということです。上級者がキャリアをかけて築いた部門の所有、予算、報告ラインを横断するので、きちんと行うには現実の政治的コストがかかります。上位3つの成果を挙げ、実際のチームの境界と資金のラインが、そのバリューストリームに沿っているのか、部門に沿っているのかをたどって、自分たちを具体的に試してください。チームが部門にきれいに対応しているなら、それが答えです。良い誠実な答えは、モデルが組織図の形をしている箇所を認め、サイロにまたがって分断され、害を生んでいるバリューストリームを少なくとも一つ特定し、組織がどの構造上の境界を引き直す意思があるかについて現実的です。

2. 私たちの実用最小限のプラットフォームには何が属するのか。また、それが作り込まれてボトルネックになること、あるいは作り込みが足りずにすべてのチームが同じ基盤を作り直すことを、どう防ぐのか。 プラットフォームと連合の形は、プラットフォームが薄く、需要主導に保たれる場合にのみ機能します。この問いは、本トピックが挙げる二つの失敗モード、つまり自らのレガシーなボトルネックとなる壮大なプラットフォームと、すべてのチームにログイン、統合、監査の作り直しを強いる不在に、チームを向き合わせます。ICSでは、プラットフォームは実質的に共有インフラ（ID、FHIR相互運用性レイヤー、安全性のベースライン付きホスティング、デザインシステム）であり、その範囲を誤ると、すべてのストリームチームにわたってコストか摩擦が増幅されるため、これが重要です。議論すべきトレードオフは、タイミングとエビデンスです。早く作りすぎれば推測を外してボトルネックを生み、遅すぎれば重複がすでに固まっています。したがって「二つ以上のチームが同じものを必要とすることが示された」というテストが要であり、チームは、それを実際に適用しているのか、明らかに中心的に思えるものを作っているだけなのかを、ストレステストすべきです。いまプラットフォームとして扱っているものと、チームが作り直しているものを見て、プラットフォームが社内ユーザーとSLAを持つプロダクトとして運営されているのか、全員が並んで待つ待ち行列なのかを問います。誠実な答えは、現時点で二チームのテストを通過する具体的なケイパビリティを挙げ、残りを先回りして作る誘惑に抵抗し、プラットフォームチームの社内ユーザーを、本物のサービスレベルを持つ本物の顧客として扱うことを約束します。

3. 意思決定権が本当に曖昧なのはどこで、チームがいまエスカレーションしていることのうち、自分たちで決める権限を与えられるべきものは何か。 権限の曖昧さは、デリバリーが停滞する最も一般的な原因として挙げられており、この問いは、公開されたRACIやRAPIDのマップが取り除くはずの、日常的な摩擦を浮き彫りにします。地域チーム、ICSのデジタル委員会、臨床安全、情報ガバナンスのすべてが決定に正当な主張を持つ連合型の医療システムでは、これは切実です。境界が不明確だと、すべてがエスカレーションされるか、さらに悪いことに、うまくいかなくなるまで誰もその判断を所有しません。探るべき緊張は、意思決定の委譲には、ガードレールの中でチームを信頼することが必要ですが、上級リーダーや取締役会は、臨床安全や公費が関わる場面でまさにそれに抵抗しがちだということです。しかし、その信頼を与えないことこそが、エスカレーションによる渋滞を生む元凶です。直近でエスカレーションされた5件の決定を列挙し、それぞれについて、誰が決めるべきで、どのガードレールがあればそれを可能にしたかを問うことで、具体的にします。パターンは通常、繰り返し現れる少数の曖昧な決定の種類を明らかにします。良い答えは、誰が何を決めるかについて、プラットフォーム標準、サービス設計、臨床安全の承認を区別した、具体的で公開可能な記述をつくり、組織が本当に委譲する意思のある決定と、中央に残す決定、その理由について正直です。

4. 私たちは運用と変更に正直に資金を付けているのか、それとも新機能の資金を出すために、稼働中のサービスの運用を静かに飢えさせているのか。 本トピックは、変更の資金を出すために運用を飢えさせることが臨床システムを劣化させる道だと率直に述べており、この問いは、停止や安全インシデントがそれを決めてしまう前に、そのバランスを表に出させます。医療・ケアでは、「運用」はバックオフィスの間接費ではなく、臨床家がケアの現場で頼るシステムの可用性なので、運用予算の劣化は、不便を被るユーザーだけでなく、患者に影響しうるダウンタイムとして現れます。トレードオフは居心地の悪いものです。変更は目に見えて称賛されますが、運用は失敗するまで見えないため、取締役会とロードマップは自然に新しいものへ偏ります。「作った者が運用する」モデルは、フィードバックのループを閉じておくことで助けになりますが、それはチームの運用の時間が、名目上割り当てられたあとで食いつぶされるのではなく、本当に守られている場合に限られます。昨四半期、各プロダクトチームのキャパシティのうち、計画に対して、サービスを安全で利用可能に保つために実際に使われた割合を見て、運用の仕事が追跡され評価されているか、割り込みとして扱われているかを確かめます。誠実な答えは、いま運用が資金不足になっている箇所を挙げ、現実的な運用の割り当てを、残りものではなく最優先の費用として守り、どの稼働中のサービスが運用リスクを蓄積しているかについて率直です。

5. どのケイパビリティを意図的に構築・所有し、どれを購入すると選んでいるのか。そして、意図せず中核となる臨床データのロックインを受け入れていないか。 ここでのベストプラクティスは、構築か購入かを意図的に決め、中核となる臨床データについて単一サプライヤーのロックインを避け、サプライヤーを外にあるものではなく運用モデルの一つの層として扱うことです。この問いは、それらの選択が実際になされているのか、なりゆきに任されているのかを試します。デジタルヘルスで最も重大なロックインは、臨床記録とそのデータを巡るものです。現実的な撤退手段のない独自のデータストアは、システム全体を10年間縛り、下流のあらゆるサービスができることを決めてしまいうるからです。緊張は、速さと選択肢の保持です。購入は今日は速く、しばしば安く、特に逼迫したチームにはそうです。しかし、オープン標準や撤退の権利を伴わない便利な購入は一つひとつ、明日の選択肢を静かに狭め、そのコストは、離れようとして初めて見えるようになります。中核ケイパビリティを列挙し、それぞれを戦略的（構築・所有）かコモディティ（購入）かに分類し、コモディティの契約が、実際にオープン標準（HL7 FHIR、SNOMED CT）と実効性のある撤退の権利を求めているかを確かめて、具体的にします。良い答えは、本当に戦略的な少数のケイパビリティと、安全に購入できる多数とを区別し、すでに臨床データでロックインされている箇所について正直で、最も重要な契約にオープン標準と撤退の権利を盛り込むことを約束します。

6. 運用モデルを変える必要があるとき、どうやって知るのか。流行や新しいリーダーの着任で組織改編するのではなく、どんなシグナルがそれを教えてくれるのか。 本トピックは、運用モデルを、壁に額装した図ではなく、エビデンスに基づいて進化させるプロダクトとして位置づけます。この問いは、どんなエビデンスがあればそれを作り替えることが正当化されるのかを、あらかじめ定義するようチームに求めます。医療・ケアでは、組織改編は混乱を招き、費用もかかります。苦労して得た領域知識と臨床安全の知識を解散させるからです。それでもこのセクターは、現在のモデルが実際に妨げになっているかどうかではなく、政策サイクルや新たな任命に駆られた構造の入れ替えに陥りがちです。緊張は、安定と適応の間にあります。モデルを安易に変えれば、チームが落ち着いて安全の専門性を蓄積することが決してできず、変えなさすぎれば、固まった構造が、もう仕事に合わなくなってからも長く流れを妨げます。仕事の流れ、意思決定までの時間、手戻り、チームの健全性といった、観察する少数のシグナルを選び、それらがどう動けば意図的な再設計を引き起こし、どの程度ならより小さな調整にとどめるかに合意して、具体的にします。誠実な答えは、少数の先行指標にコミットし、エビデンスに基づく変更と組織改編のための芝居を区別し、モデルを点検し、シグナルがデリバリーを妨げていると示したときに行動する責任者を明確にします。

実践例：医療・ケアの事例#

5つの地域をカバーするICSでは、各トラストがそれぞれ患者向けの予約ツールを作っています。コストは重複し、体験は食い違い、どれもきれいにデータを共有していません。ICSは運用モデルを再設計します。

3つの成果（受診しなかった予約の削減、避けられる入院の削減、アクセスの公平性の向上）と、その背後にあるバリューストリームを定義します。そして、実用最小限の4つのケイパビリティを所有する小さなプラットフォームチームを立ち上げます。共有のID・ログイン、FHIRベースの相互運用性レイヤー、セキュリティと臨床安全のベースライン付きの共通ホスティング、デザインシステムです。各地域はストリームアラインドなチームを維持しますが、いまはゼロからではなく、プラットフォームの上に構築します。

資金は、年次のプロジェクト入札から、各ストリームの常設のプロダクト予算へと移り、ディスカバリー、アルファ、ベータのゲートを通じて解放されます。公開されたRAPIDマップにより、地域チームはプラットフォームと臨床安全のガードレールの範囲内で自らのサービス設計を決定し、ICSのデジタル委員会がプラットフォームの標準を決定することが明確になります。1年以内に、3つの地域が一つの予約ケイパビリティを共有し、デザインと安全のベースラインが一貫し、かつてはプロジェクトの一サイクルを要した新機能が数週間で出荷されるようになります。プラットフォームが、差別化にならない重労働を吸収したからです。

セクター別の視点#

運用モデルは、それが仕える組織の規模に合わせて設計されます。同じ層、つまりバリューストリーム、ケイパビリティ、チーム、ガバナンス、プラットフォーム、サプライヤーが、スタートアップ、大企業、政府機関では、まったく異なる姿に描かれます。

スタートアップ#

小さなデジタルヘルス企業では、運用モデルはほとんど暗黙のものであり、それで構いません。一つか二つのストリームアラインドなチーム、意思決定権の大半を握る創業者、そしてプラットフォーム化するものがまだないのでプラットフォームチームはありません。規律とは、少数の本当の決定を早期に明示することです。臨床データストアを構築するか購入するか、どのオープン標準にコミットするかを決めて、今日の近道が明日のロックインにならないようにします。運用と変更は同じ人の手にあるため、初期の顧客のために稼働を維持することがロードマップを飢えさせるリスクがあります。エンジニアリング時間のシンプルで誠実な配分が、保護された運用予算の軽量版に当たります。サプライヤーは速さで選ばれますが、スタートアップも中核となる臨床データのロックインは拒むべきです。将来のNHSの購入者は撤退の権利を求めるからです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設や訪問介護事業所、単独拠点のクリニック、収益前の段階を過ぎた小規模なヘルステックのサプライヤーには、実際の患者と日々の運営がありますが、プラットフォームチームも、専任のデジタルやITの能力もなく、資金や人員の余裕もほとんどありません。ここでの運用モデルは、購入したケイパビリティをつなぎ合わせたものが大半であり、決定的な選択はサプライヤーに関するものになります。調達する臨床システムにオープン標準と撤退の権利を求めることです。大きなトラストの購買力や社内の専門性がないにもかかわらず、同じ相互運用性と臨床安全の義務を負っているからです。運用と変更は、ケアも提供する同じ少数の人々に集約されるため、誠実な規律とは、火消しだけでなく、システムを安全で最新に保つための少しの時間を守ることです。意思決定権は単純で、通常はパートナーか経営者が決めますが、そのため、デジタルに関する決定を無期限に先送りしやすくなります。したがって価値は、重要な少数の決定（どの臨床記録か、どの地域共有プラットフォームに参加するか）に名前を付け、意図的に行うことにあります。ICSや国の機関が共有のID、相互運用性、デザインのプラットフォームを提供しているなら、小規模事業者にとって最善の手は、作り直さずにその上に構築し、自前では人員を確保できないケイパビリティを借りることであるのが普通です。

大企業#

NHSトラストやICSは、プラットフォームと連合の形が真価を発揮する場です。患者にとって一つのサービスのように感じられなければならない、主権を持つ組織の集まりだからです。難しい問題は、技術と同じくらい政治的です。期間限定のプロジェクト入札から常設のプロダクト予算へ資金を移すこと、地域チームが自分たちの所有する決定をエスカレーションしなくて済むよう、RACI/RAPIDのマップを公開することです。大規模なヘルステックや製薬の企業には、プラットフォームエンジニアリングの力がありますが、自らがボトルネックとなる壮大な社内プラットフォームを作り込みすぎるリスクがあります。二つ以上のチームが同じものを必要とすることが示されるという、実用最小限のプラットフォームのテストが、そのブレーキです。この規模では、意思決定権と資金の流れが運用モデルそのものであり、通常、技術は制約になりません。

政府#

国または地方の公的機関は、他の組織が身を置かなければならない運用モデルを設計するため、標準とプラットフォームについての選択は、実質的に国のインフラです。NHS EnglandやDHSCが共有のID層、相互運用性の背骨、デザインシステムを提供することは、国民規模に適用されたプラットフォームのパターンであり、その支出管理と段階的なアシュアランスのゲートが、公費を説明責任の下に置く手段です。失敗モードは、遠く離れたボトルネックとなる集中型のモデルで、あらゆる地域の文脈に一つの解決策を義務づけることです。是正策は、本当に共通のケイパビリティをプラットフォーム化し、残りをトラストと地方自治体に連合させることです。議会への説明責任はまた、構築か購入かとサプライヤー管理が公的記録の対象であることを意味するため、オープン標準と撤退の権利は、単に慎重であるだけでなく、期待されるものです。

よくある失敗パターン#

• 組織図の自動化。 バリューストリームではなく既存の部門を軸にチームを設計し、TOMがサイロを固定化する。対策：成果とバリューストリームから下に向けて設計する。
• ボトルネックになるプラットフォーム。 すべての依頼がその後ろに並ばなければならない、過大な範囲の中央プラットフォームチーム。対策：実用最小限のプラットフォームを、SLA付きのプロダクトとして扱う。
• プロダクトの仕事にプロジェクト資金。 失効する資金は、解散と再編のやり直しを強いる。対策：段階的ゲート付きの継続的なプロダクト資金。
• 変更を養うために飢えさせた運用。 臨床システムが劣化するまで、稼働中サービスの運用に資金を出さない。対策：運用と変更に明示的に資金を付け、運用予算を守る。
• 所有者のいない決定。 誰が決めるのか誰も知らず、すべてがエスカレーションされる。対策：公開されたRACI/RAPID。
• なりゆきのロックイン。 中核となる臨床データが、撤退手段のない独自のサプライヤーシステムに閉じ込められる。対策：あらゆる戦略的契約に、オープン標準と撤退の権利を盛り込む。

成熟度モデル#

チェックリスト#

• 運用モデルは、既存の階層ではなく、成果とバリューストリームから設計されている。
• 共有ケイパビリティは実用最小限のプラットフォームとして提供され、ストリームチームがその上に構築している。
• プロダクトチームには継続的に資金が付き、バリューストリームに整合している。
• 支出管理は段階的（ディスカバリー/アルファ/ベータ/ライブのゲート）で、リスクと価値に比例している。
• 意思決定権は文書化（RACIまたはRAPID）され、公開されている。
• 運用と変更には明示的に資金が付き、運用予算は守られている。
• チームタイプ（ストリームアラインド、プラットフォーム、イネーブリング、複雑なサブシステム）が理解され、使われている。
• 構築か購入かは、ケイパビリティごとの意図的な選択であり、中核となる臨床データはロックインを避けている。
• 契約がオープン標準（例：HL7 FHIR、SNOMED CT）と撤退の権利を求めている。

主要な情報源#

• Matthew Skelton & Manuel Pais — Team Topologies（ストリームアラインド、プラットフォーム、イネーブリング、複雑なサブシステムのチーム、実用最小限のプラットフォーム）。
• GOV.UK Service Manual — spend controlsと段階的アシュアランス（ディスカバリー/アルファ/ベータ/ライブ）、Government Digital Service。
• NHS digital service manual — NHS service standard（service-manual.nhs.uk）。
• AXELOS — ポートフォリオ・プログラムのガバナンスのためのManagement of Portfolios (MoP)とManaging Successful Programmes (MSP)。
• Bain & Company — 意思決定権のRAPIDフレームワーク、およびRACIの責任割当モデル。
• John Doerr — 成果を定義するためのMeasure What Matters（OKR）。

参考文献#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book