トピック7.0 — チーム構造、役割、責任

一文で言うと： デジタルヘルスの納品は、チームの間にどう境界を引くか、そして誰が何をするかをどれだけ明確に名指しするかで、成否が決まります。したがって、価値の速く安全な流れのためにチームを構造化し、多職種で人員を配置し、責任を明示してください。

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

チームの組織の仕方は、サービスの振る舞い方になります。コンウェイの法則、つまり、システムの設計は、それを構築した組織のコミュニケーション構造を映す、という法則は、医療・ケアでは、好奇心の対象ではなく、患者安全のリスクです。断片化したチームは、断片化したケア記録、脆い連携、臨床リスクが潜む引き継ぎを生みます。

NHSと社会的ケアでは、公金を使い、法定の義務も負っています。DCB0129/DCB0160に基づく臨床安全、UK GDPRと守秘義務のコモン・ローに基づく情報ガバナンス、そしてアクセシビリティの義務。これらの義務は、最後に取り付けることができません。それらを果たす権限と時間を持つ、名前のある人々によって、チームの内側で代表されなければなりません。

構造を正しくすれば、多職種のチームは、臨床家が信頼し、患者が使える、動くソフトウェアを出荷します。誤れば、忙しい専門家が自分のサイロを最適化する一方、サービス全体が停滞します。遅れ、予算超過し、静かに放棄されるデジタルプログラムの背後にある、古典的なパターンです。

中核概念#

多職種チーム（MDT）。 デジタル納品のチームは、絶え間ない外部への依存なしに、サービスを設計し、構築し、運用するために必要なあらゆる専門分野、つまりプロダクト、デリバリー、デザイン、リサーチ、エンジニアリング、データ、そして臨床とガバナンスの視点を含むべきです。これは、職員がすでに知っている臨床のMDTの概念、つまり混合された専門性と、成果への共有された説明責任を映しています。

チームトポロジー。 効果的なチーム設計を、すべて価値の速い流れに資する、四つの基本的な種類と三つの相互作用のモードに絞る、モデル（Skelton & Pais）です。

• ストリームアラインドチーム — 価値ある単一の仕事の流れ（サービス、ユーザージャーニー、プロダクト）を軸に組織され、それを端から端まで所有します。これが既定のチームの種類で、ほとんどの人は、これに属すべきです。
• プラットフォームチーム — ストリームアラインドチームが作り直さずに速く進めるよう、内部のセルフサービスの能力（共有インフラ、連携エンジン、ログインサービス、共有ケア記録のAPI）を提供します。
• イネーブリングチーム — 他者が能力を高められるよう指導し、そして退く、期限付きの専門家のチーム（例：臨床安全、アクセシビリティ、テスト自動化）です。
• 複雑なサブシステムのチーム — 汎用的なチームに過負荷をかける、深い専門知識が必要な部分（リスクスコアリングのアルゴリズム、NHS Spineのインターフェース）を所有します。

三つの相互作用のモードは、あらゆる二つのチームがどう関わるかを統べます。協働（定義された期間、緊密に働く。高い帯域で、発見のために多少の非効率を許容する）、X-as-a-service（一方のチームが、他方の能力を最小限の手間で利用する。規模での、摩擦の低い既定）、ファシリテーション（一方のチームが、他方の学びを助ける）。モードを名指しすることで、遅れと責任のなすり合いを生む曖昧さを防げます。

認知負荷。 チームは、頭の中に保持できる量に限りがあります。チームトポロジーは、各チームが所有する領域を、それが安全に推論できる範囲に限定すべきだと論じます。領域が臨床的なとき、決定的な原則です。

コンウェイの法則と逆コンウェイ戦略。 アーキテクチャは組織の構造に従うため、つまり、チームと技術を一つの設計として扱う社会技術システムの見方から、望むアーキテクチャを生むよう、意図してチームを形づくります。モジュール式で相互運用可能なケア記録が欲しいなら、単一のモノリシックなチームで構築してはなりません。

ベストプラクティス#

1. 各サービスの周りに、完全な多職種チームを配置する。 最低限、プロダクトマネージャー、デリバリーマネージャー、ユーザーリサーチャー、サービス／インタラクションデザイナー、エンジニア、データ／アナリティクスの能力に加え、名前のある臨床安全と情報ガバナンスの関与を含めます。専門分野を欠くチームは、他者を待つか、その仕事を飛ばすかのどちらかで、医療で飛ばされる仕事は、通常、安全、アクセシビリティ、ガバナンスです。

2. ほとんどのチームをストリームアラインドにし、端から端までの所有を与える。 技術の層（例：「データベースチーム」）ではなく、利用者のジャーニー（例：「外来の紹介」）を軸に組織します。端から端までの所有は、フィードバックのループを短くし、臨床リスクが蓄積する引き継ぎのギャップを止めます。

3. プラットフォームをプロダクトとして構築し、サービスとして利用させる。 連携エンジン、IDサービス、共有ケア記録のAPIを、独自のチーム、ロードマップ、利用者を持つ内部プロダクトとして扱います。チケットを上げて待つのではなく、ストリームアラインドチームがセルフサービスできるよう、「as-a-service」として公開します。

4. イネーブリングチームを、乏しい専門性を抱え込むためではなく、広めるために使う。 臨床安全責任者、アクセシビリティの専門家、セキュリティエンジニアは、まれです。彼らを、あらゆるチームが並ぶ恒久的なボトルネックにするのではなく、納品チームをより高い水準へ指導するために配置し、そして次へ移します。

5. すべての役割とその意思決定権を明示的に名指しする。 重要な判断、つまり臨床安全の承認、稼働、情報ガバナンスの承認、支出について、責任のモデル、つまりRACI（実行責任者、説明責任者、相談先、報告先）や、より単純な「決定者／助言者」の分担を使います。ここでの曖昧さが、説明責任が蒸発する場所です。

6. 臨床安全責任者に、本物の権限と本物の時間を与える。 DCB0129/0160は、リリースを止められる、名前のある、適切に訓練された臨床安全責任者を求めます。その役割をチームの中で明示し、時間を守り、ノーと言えるようにしてください。名ばかりのCSOは、インシデントによって見つかるのを待つガバナンスの失敗です。

7. 領域に境界を設けて、認知負荷を管理する。 チームが、あまりに多くのサービス、あるいはあまりに複雑な臨床領域を所有するなら、分割します。シグナルに注意してください。自分自身の変更の安全上の含意を、もう自信をもって説明できないチームは、過負荷です。

8. 逆コンウェイ戦略を意図して適用する。 望むアーキテクチャと相互運用性に合うよう、チームの境界を引きます。モジュール式で標準に基づく（例：HL7 FHIR）システムには、モジュール式のチームを。偶然の組織図に、あなたのケア記録を設計させてはなりません。

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

1. 現在の組織図が、すでに私たちのアーキテクチャを設計しているのは、どこか。そして、それは私たちが実際に望むアーキテクチャか。 コンウェイの法則は任意ではありません。チームの形がどうであれ、システムはそれを映すようになるため、誠実な最初の動きは、すでに持っているケア記録、連携、引き継ぎを見て、どのチームの境界が、それぞれの継ぎ目を生んだかを問うことです。医療・ケアの現場では、それらの継ぎ目は臨床リスクが潜む場所、つまり断片化した記録、脆いSpineのインターフェース、単一のチームが所有しない安全ケースです。したがって、これは美学ではなく、患者安全の会話です。議論すべき緊張は、望むアーキテクチャを得るためにチームの境界を引き直すこと（逆コンウェイ戦略）が、混乱を招き、確立された縄張りを脅かし、完全には制御できない、資金とライン管理の構造を横切ることです。最も苦痛な二つか三つの連携を、それぞれの端を所有するチームまでたどり、ストリームアラインドの境界が、引き継ぎを完全に取り除いたかを問うことを検討します。良い答えは、動かす具体的な境界を少なくとも一つ挙げ、誰がなぜ抵抗するかについて誠実で、混乱に値する変更と、as-a-serviceのインターフェースが、より安価に摩擦を直す変更を区別します。

2. 私たちの乏しい専門家、つまり臨床安全、情報ガバナンス、アクセシビリティは、本物の権限を持ってチームの中にいるか。それとも、全員が並ぶ外部の関門か。 この種のあらゆるサービスは、最後に取り付けられない法定の義務（DCB0129/0160の臨床安全、UK GDPRと守秘義務のコモン・ロー、アクセシビリティの法律）を負いますが、これらの能力はまれで高価なため、組織を中央での抱え込みへと引き寄せます。トレードオフは本物です。あらゆるチームに臨床安全責任者を組み込めば、薄まるまで乏しい専門性を薄く広げ、中央に集中させれば、一人がすべてについて相談を受け、あらゆるリリースが待つ、英雄的なボトルネックを作ります。イネーブリングチームのパターン、つまり期限付きの専門家が、チームに自前のハザードのワークショップを運営するよう指導して退くという方法は、提案された解決策ですが、リーダーシップが、専門家に、自ら行うのではなく教える時間を守って初めて機能します。自分自身のリリースの履歴を誠実に見てください。単一の名前のある人を待って、稼働が何度遅れたか、そしてその人は、安全にノーと言える権限と確保された時間を持っていたか。強い答えは、希少性に正面から向き合い、各義務について、組み込むか、可能にするかを意図して選び、キャパシティをどう広げても、決して薄めてはならない具体的な権限、つまりリリースを止める力を名指しします。

3. チームが、安全に担える以上の認知負荷を引き受けたことを、どうやって知るか。そして、それについて実際に何をするか。 認知負荷は、安全な納品の静かな調整役です。チームは、自分自身の変更の安全上の含意への自信が損なわれ始める前に、推論できる臨床領域とサービスの量に限りがあり、医療では、その損耗は、インシデントがそれを露わにするまで見えません。難しいのは、過負荷がめったに自らを告げないことです。それは、わずかに遅い納品、より多くの欠陥、より多くの「誰かに確認させて」として現れ、圧力の下にあるチームは、特にチームの分割が政治的に高くつくか、人員が凍結されているとき、それをフラグ付けするより吸収しがちです。早期警戒のシグナルが何か（自分自身のリリースの安全ケースを、もう自信をもって説明できないチームは、強いシグナルです）、そして納品が目に見えて止まる前に、過負荷を表面化する仕組みが今日あるかを議論します。反対の圧力も考えます。チームの分割は、新たな境界と引き継ぎを生むため、治療が、第1問の断片化のリスクを再び持ち込みえます。誠実な答えは、漠然とした「感じ取れる」ではなく、具体的で観察可能なシグナルに合意し、誰がチームの領域を限定し、あるいは分割する権限を持つかを挙げ、負荷の軽減と境界の増殖の間のトレードオフを認めます。

4. 私たちの共有の能力のうち、サービスとして利用されるプラットフォームとして運営すべきものはどれか。そして、実際にそのように資源を与えているか。それとも、チケットの待ち行列に名前を付け替えただけか。 プラットフォームチームの約束は、ストリームアラインドチームが、チケットを上げて待つことなしに、連携エンジン、IDサービス、共有ケア記録のAPIをセルフサービスできるため、システム全体が速くなることです。失敗は、何かを「プラットフォーム」と呼びながら、それが、全員がなお並ぶ、人員不足の中央の機能のままであることです。トレードオフは本物です。能力を本物の内部プロダクトとして構築することは、それに独自のチーム、ロードマップ、ドキュメント、利用者を与えることを意味し、それは、利用者に面する機能の出荷と競合する重大な投資であり、現金の限られたNHSの現場では、その投資は無期限に先送りしやすいのです。医療・ケアでは、賭け金はより鋭くなります。共有の能力は、しばしば安全上重要なもの、つまり個人照合の索引、FHIRのインターフェース、監査証跡であり、薄いプラットフォームチームが、その上にあるあらゆるサービスの単一障害点になるからです。複数のチームがすでに依存している能力を見て、それぞれについて、その相互作用が本当に摩擦の低いX-as-a-serviceなのか、隠れた待ちを伴う、偽装された協働なのかを問います。誠実な答えは、どの能力が今プラットフォームへの投資に値し、どれがあとかを挙げ、誰が資金を出し人員を配置するかを明確にし、プロダクトオーナーも、ロードマップも、セルフサービスの経路もない何かを、プラットフォームと宣言する誘惑に抵抗します。

5. 契約したサプライヤーや借りた職員に頼っているのはどこか。そして、空洞化した発注者ではなく賢い発注者であり続けるために、どの役割を社内に保たなければならないか。 医療・ケアのデジタル納品の多くは外注されており、サプライヤーは、キャパシティと専門性を素早くもたらせますが、プロダクトの所有、技術的な保証、臨床安全の承認のすべてが契約とともに建物を出ていくなら、組織は、売られているものを判断し、必要なものを仕様に定め、結果を安全に所有する能力を失います。緊張は、速さと能力の間にあります。人員の補強や一式の構築は、何かを素早く稼働させますが、サプライヤーに説明責任を問える社内の筋力を静かに損ない、成果を所有するストリームアラインドのチームではなく、構成要素の形をした、引き継ぎの多い構造を届けることが多いのです。この領域で、譲れない保持される役割は、委任できない説明責任の周りに集まります。上級責任者、稼働を承認する臨床安全責任者、優先順位を決めるプロダクトオーナー、そしてサプライヤーが構築するものを検査するのに十分な技術的な保証。現在の納品を調べ、明日サプライヤーが去ったら、どの能力を再構築できないかを問います。良い答えは、契約して本当に構わない仕事と、社内に残さなければならない賢い発注者の中核を区別し、契約されたチームに、人材派遣ではなく成果の所有を求めることを主張し、安全とガバナンスの判断が、常に自分自身の説明責任のある人々に残らなければならないことを名指しします。

6. 私たちのチーム構造が、実際に、価値の速く安全な流れを生んでいることを、どうやって知るか。そして、何がそれを引き直すきっかけになるか。 チームの設計は目的ではなく手段です。ストリームアラインドのチーム、プラットフォーム、名指しされた相互作用のモードの要点は、価値のより速く安全な納品ですが、組織は、構造がそれを届けているかをめったに計装しないため、組織再編は、エビデンスではなく、政治と直感で行われます。難しいのは、ゲーム化せずに、流れと安全を反映するシグナルを選ぶことです。生の速度やストーリーポイントのスループットは、誤った行動を招く一方、流れの指標（アイデアから稼働までのリードタイム、デプロイの頻度、変更あたりの引き継ぎの数）と安全の指標（ハザードがどれだけ速く閉じられるか、チームが自前の安全ケースを所有しているか）は、境界が助けているのか妨げているのかについて、より多くを教えてくれます。安定性との本物の緊張があります。絶え間ない組織再編は、納品を安全にする、チームの継続性と共有された認知の空間を壊すため、境界を引き直す前に、高いハードルと明確なきっかけが必要です。境界が誤っていることを示すエビデンスは何か、つまり持続するチーム間の待ち、単一のチームが所有しない安全ケース、誰もセルフサービスしないプラットフォームと、誰がそれに行動する権限を持つかを話し合います。誠実な答えは、実際に見守る少数の流れと安全のシグナルにコミットし、チームの安定性を守る意図した閾値を設定し、将来のあらゆる再形成の、きっかけの条件と意思決定者を挙げます。

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

ある統合ケアシステム（ICS）は、急性期、コミュニティ、精神保健、プライマリケア、社会的ケアにまたがる共有ケア記録を展開しています。

本能は、一つの大きな「共有ケア記録チーム」を作ることです。代わりに、ICSはチームトポロジーを適用します。プラットフォームチームが、共有記録の中核、つまり個人照合の索引、FHIRのAPI、連携エンジンを所有し、セルフサービスの能力として公開します。複数のストリームアラインドチームが、その上の本物のユーザージャーニー、つまり「救急部門で患者の記録を見る」「ソーシャルワーカーのセーフガーディングのビュー」「GPの薬剤の照合」をそれぞれ所有し、プラットフォームをas-a-serviceとして利用します。複雑なサブシステムのチームが、偽の一致が本物の安全インシデントとなる、確率的な患者照合のアルゴリズムを所有します。臨床安全とアクセシビリティの専門家のイネーブリングチームが、ストリームアラインドのチームを順に回り、彼らに代わって行うのではなく、自前のDCB0160のハザードのワークショップを運営するよう指導します。

各チームには、名前のあるプロダクトマネージャー、デリバリーマネージャー、臨床安全責任者がおり、RACIは、稼働が上級責任者に説明責任を負うが、CSOとIGの承認なしには進めないことを明確にします。救急部門のチームが新しいデータ項目を必要とするとき、相互作用のモードは明示的です。6週間の協働ではなく、プラットフォームチームから、文書化されたAPIの要求を通じたX-as-a-serviceです。納品はより速くなり、決定的に、各ジャーニーの安全ケースは、それを出荷するチームによって所有されます。

セクター別の視点#

スタートアップ#

10人のデジタルヘルスのスタートアップは、四つの異なるチームの種類を配置できません。それは通常、一人が複数の帽子をかぶる、単一のストリームアラインドチームそのもの（ユーザーリサーチも運営するエンジニア、事実上の臨床安全責任者である臨床家の創業者）です。優先事項は、判断が速くなるよう、チーム全体を一つの共有された認知の空間に保つことです。全員が同じ部屋にいるとき、正式なRACIは過剰です。本当のリスクは、創業者のボトルネックです。臨床安全と情報ガバナンスが、一人の忙しい人に懸かり、DCB0129/0160の義務は先送りしやすいのです。会社が最初のNHSの契約を勝ち取るとき、最初の専門職の採用は、その関門のリスクを下げる人々、つまり名前のあるCSOとIGのリードであるべきで、それはエンジニアリングの人員を拡大する前です。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、実際の患者と継続的な運営を抱えていますが、専任のデジタルやITのチームを持つことはまれで、設計すべき「チームトポロジー」はありません。診療所のマネージャーや臨床リードが、日常業務と並んで、事実上、納品の能力全体です。現実的な動きは、プラットフォームやイネーブリングのチームを築くことではなく、すでにいる人々に責任を明示的に名指しすることです。導入するシステムの臨床安全責任者は誰か、情報ガバナンスは誰が所有するか、変更を誰が承認するか。たとえそれが、少数の職員の非常勤の帽子であっても。大きなトラストと同じ法定の義務（DCB0129/0160、UK GDPR、アクセシビリティ）が適用されるため、実務上のパターンは、それらを作り直すのではなく、サプライヤーとICSの共有プラットフォームとイネーブリングの支援に頼りつつ、サプライヤーに説明責任を問えるだけの賢い発注者の能力を、ちょうど十分に保持することです。単独で最大のリスクは、一人のボトルネックです。臨床システムを理解する唯一の人が去れば、安全と継続性がともに去るため、ここでは、正式なチームモデルよりも、RACIを書き留めることと、第二の人を相互研修することが重要です。

大企業#

大規模なNHSトラストやヘルステック企業は、反対の問題を抱えています。レガシーの構成要素と部門の線に沿って引かれた、あまりに多くのチームと、あらゆる場所にある引き継ぎです。ここは、意図したチーム設計のモデルが真価を発揮するところです。構成要素のチームを、ストリームアラインドのものへ作り変え、共有ケア記録と連携の能力のためにプラットフォームチームを立ち上げ、イネーブリングチームを使って、乏しい臨床安全とアクセシビリティの専門性を広めます。関係者の数があまりに多く、非公式な調整を不可能にするため、RACIと明示的な意思決定権は不可欠になります。逆コンウェイ戦略は、ここでは生きた梃子です。数十年ものの組織図が、すでにアーキテクチャを形づくっているため、リーダーは、構造に彼らのケア記録を設計させるのではなく、意図してチームの境界を引き直さなければなりません。

政府#

国の機関（NHS England、DHSC）や地方自治体は、他者が人員を配置する基準、つまりGovernment Digital and Dataの能力の枠組み、Service Standard、DCB0129/0160を定め、お金がチームのキャパシティをどう買うかについて、議会と国民に説明責任を負います。ここでの構造は、調達と資金のルールによって形づくられます。納品の多くがサプライヤーに外注されるため、社内に保つべき重要な役割は、能力が空洞化するのを防ぐ、賢い発注者の役割（プロダクトの所有、技術的な保証、臨床安全の承認）です。説明責任は正式で監査可能です。名前のある上級責任者、公表された支出統制、透明性の義務。したがって、責任のモデルは、任意の衛生ではなく、公的な記録の問題です。典型的なリスクは、構造が、流れを絞る恒久的なプログラムボードと関門へと硬直化することです。対抗策は、サプライヤーに、人材派遣的な人員補強ではなく、ストリームアラインドで、成果を所有するチームを求めることです。

よくある失敗パターン#

• 構成要素チームの罠。 技術の層（「フロントエンドチーム」「データベースチーム」）で分けられたチームは、あらゆる機能で引き継ぎを生み、成果を所有しない。価値の流れを軸に再編する。
• カーゴカルトのSpotify。 「スクワッド、トライブ、チャプター、ギルド」を、その下にある自律、整合、プラットフォームへの投資なしに、ラベルとして真似る。Spotifyのモデルは、ある時点の一つの会社のスナップショットで、Spotify自身もそこから進んだ。組織図ではなく、原則を借りる。
• 英雄的なボトルネック。 一人のCSO、一人のアーキテクト、一人のIGのリードが、あらゆることについての相談先となり、あらゆるチームが待つ。彼らを、全員の能力を高める、イネーブリングの能力に変える。
• 後回しのガバナンス。 臨床安全とIGが、組み込まれたチームメンバーではなく、外部の関門として代表され、彼らの懸念が、安価に行動するには遅すぎる時点で届く。
• 境界のないチーム。 誰も全体を理解しなくなるまで、サービスを吸収し続けるチーム。認知の過負荷は、遅くなる納品と損なわれる安全への自信として現れる。
• 恒久的な協働。 二つのチームが無期限に「協働」しているのは、通常、欠けた境界である。協働に期限を設け、きれいなas-a-serviceのインターフェースへ移る。

成熟度モデル#

チェックリスト#

• あらゆるサービスに、それを端から端まで所有する、ストリームアラインドのチームがある。
• 各チームが、プロダクト、デリバリー、リサーチ、デザイン、エンジニアリング、データ、臨床安全、情報ガバナンスを含むか、名前のあるアクセスを持つ。
• チームごとの、名前のある、訓練された臨床安全責任者が、確保された時間と、リリースを止める権限を持つ。
• 共有の能力（連携、ID、ケア記録のAPI）が、サービスとして利用される内部プラットフォームとして運営されている。
• 乏しい専門家が、恒久的なボトルネックではなく、期限付きのイネーブリングチームを通じて働いている。
• 臨床の承認、稼働、IGの承認、支出のためのRACI（または同等のもの）が存在し、実際に使われている。
• チームをまたぐ各依存に、名前のある相互作用のモード（協働／X-as-a-service／ファシリテーション）がある。
• チームの領域が、管理可能な認知負荷に限定され、過負荷のチームが分割されている。
• チームの境界が、望むアーキテクチャと相互運用性を生むよう、意図して選ばれている。

主要な情報源#

• Team Topologies — Matthew Skelton & Manuel Pais（四つのチームの種類、三つの相互作用のモード、認知負荷）：teamtopologies.com
• NHS Digital Service StandardとNHS Service Manual — 多職種チームの役割と働き方
• GOV.UK Service Manual (GDS) — 「Set up a service team」とアジャイルな納品のガイダンス
• Government Digital and Data（旧DDaT）Profession Capability Framework — 役割の定義：ddat-capability-framework.service.gov.uk
• 臨床リスクマネジメント標準DCB0129（製造）とDCB0160（導入）、NHS Digital — 臨床安全責任者の役割
• コンウェイの法則 — Melvin Conway, "How Do Committees Invent?"（1968年）
• Spotifyのエンジニアリング文化（Henrik Kniberg） — スクワッド／トライブ／チャプター／ギルド。ある時点のモデルとして、批判的に読む

参考文献#

1. Conway's law — Wikipedia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

トピック7.2 — 労働力計画、トピック7.3 — 労働力戦略、トピック7.5 — 人材・組織開発、トピック8.1 — チェンジマネジメントも参照。