トピック3.5 — デリバリーライフサイクル

一文で言うと： デリバリーライフサイクルとは、ディスカバリー、アルファ、ベータ、ライブ、そして最終的な廃止という、デジタルサービスが通過するフェーズと意思決定の関門の連なりであり、臨床安全、情報ガバナンス、アシュアランスが、最後に付け足されるのではなく、あらゆるフェーズに織り込まれています。

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

ライフサイクルは、組織がアイデアを安全な稼働中のサービスに変え、最終的に責任をもって廃止する方法です。医療・ケアでは、あらゆる移行が、法定および臨床上の重みを持ちます。臨床安全のケースなしに、患者のケアに関わるシステムを導入することはできず、適法な根拠と完了したデータ保護影響評価（DPIA）なしに、機密の患者データを処理することはできません。これらをプロジェクト終盤の書類仕事として扱うライフサイクルは、遅れるか、安全でないか、あるいはその両方のサービスを生みます。

利害は非対称です。バグを出荷する消費者向けアプリは、ユーザーを苛立たせますが、バグを出荷する共有ケア記録は、臨床家に誤った患者のアレルギーを見せかねません。NHSが、GOV.UKのフェーズモデルと、臨床リスクマネジメント標準のDCB0129とDCB0160を、同じライフサイクルに組み込んでいるのは、そのためです。ライフサイクルを正しく整えることは、ガバナンスの気配りではなく、安全、公平性、公費の価値が、単に約束されるのではなく、実際に届けられる仕組みです。

リーダーは、ライフサイクルが進捗を読み取れるものにするからこそ、それを必要とします。名前の付いたフェーズと関門によって、取締役会は、サービスがどこにあり、どんなエビデンスがあり、どんな決定が期日を迎えるかを見られます。「ほぼ終わりです」という霧を、説明可能で段階的な公費のコミットメントに置き換えます。

中核概念#

フェーズモデル：ディスカバリー→アルファ→ベータ→ライブ。 NHSとGOV.UKのサービス標準は、4つのフェーズを定めています。ディスカバリー（トピック3.4 — ディスカバリーフェーズ参照）は、問題を理解します。アルファは、解決策が機能する可能性があるかをテストし、最もリスクの高い想定を潰すために、使い捨てのプロトタイプを作ります。ベータは、本番のインフラ上に、本物の、非公開からのちに公開されるサービスを構築し、規模を拡大しながら実際のユーザーと反復します。ライブは、サービスが廃止されるまで、なお反復を続けながら、継続的な運用でサービスを走らせます。フェーズはリスク低減の傾斜路です。それぞれが、より多くのお金をコミットし、より多くのユーザーを晒し、前のフェーズのエビデンスによって正当化されます。

ベルトコンベアではなく、継続的な反復。 フェーズは一方向のウォーターフォールではありません。ベータにあるサービスが、難しい機能のためにアルファに戻ることもあり、稼働中のサービスは継続的に反復します。このモデルの価値は、仕事が一方向に流れるという約束ではなく、その関門にあります。

アジャイル、ウォーターフォール、ハイブリッド。 *ウォーターフォールは、範囲を最初に固定し、順番に進めます。要件が本当に安定していて、把握できる場合（データセンターの移行、義務づけられた規制変更）にのみ適しています。アジャイル*は、小さな増分で提供し、点検し適応します。ユーザー向けサービスの不確実性に適しています。ハイブリッドは、大規模な医療プログラムの大半の、誠実な現実です。組織とその規制当局が求める、マイルストーンと資金の包みの中で動く、アジャイルのプロダクトチーム。手法は、流行ではなく、不確実性に合わせてください。

サービス評価と標準の関門。 フェーズ間の移行、特にアルファからベータへ、そして公開ローンチの前には、NHSとGOV.UKのサービスはサービス評価に直面します。Service Standardの項目（ユーザーのニーズ、アクセシビリティ、セキュリティ、信頼性、チーム、技術の選択）に照らして仕事をテストする、独立した審査員団です。合格は、より多く支出し、より多くのユーザーを晒すための関門です。評価は、エビデンスに基づくピアレビューであり、形式的な承認ではありません。

ライフサイクルの糸としての臨床安全と情報ガバナンス。 DCB0129（製造者/供給者向け）とDCB0160（導入する医療・ケア組織向け）は、臨床リスクマネジメントのシステム、ハザードログ、名前のある、訓練された臨床安全責任者（CSO）によって承認される臨床安全性ケース報告書を求めます。情報ガバナンスは、適法な根拠、DPIA、Caldicott原則の遵守を求めます。どちらも、ディスカバリー、アルファ、ベータ、ライブを貫く糸であり、最後の関門ではありません。

廃止。 ライフサイクルには終わりがあります。サービスを安全に廃止すること、つまり保存に関する法律の下でのデータの移行またはアーカイブ、ユーザーの振り向け、臨床家への通知、記録の保全は、それ自体がフェーズであり、最も見過ごされがちなものの一つです。

ベストプラクティス#

1. フェーズを、カレンダー上のマイルストーンではなく、リスク低減の関門として使う。 各フェーズの決定を、「次のお金とユーザーをコミットすることを正当化するだけのエビデンスがあるか」とします。エビデンスが揃ったからではなく、日付が来たから終わるフェーズは、関門の意義を飛ばしています。

2. 臨床安全を、ライブの前ではなく、アルファから織り込む。 解決策の形が現れたらすぐに、臨床安全責任者を任命し、ハザードログを開きます。アルファで特定されたハザードは設計で取り除くのが安く、稼働時に見つかったハザードは、ローンチを止める危機です。安全性ケースはサービスとともに成熟するため、DCB0129/0160の承認は、すでに行われた仕事の要約であり、駆け込みではありません。

3. DPIAとIGの作業をディスカバリーで始め、生きたものに保つ。 データの流れ、適法な根拠、Caldicottの考慮事項はアーキテクチャを形づくるため、アーキテクチャがまだ柔らかいうちにそれらを表に出します。構築後に書かれたDPIAは文書作成の演習であり、設計と並行して書かれたものは、実際にリスクを減らし、手戻りを防ぎます。

4. CI/CDとDevOpsで、本番への道を自動化する。 継続的インテグレーションと継続的デリバリー、つまり自動化されたビルド、テスト、デプロイのパイプラインによって、チームは、小さく元に戻せる変更を、安全に頻繁に出荷できます。安全性が重要な領域では、数分で修正を導入し、きれいに巻き戻せる能力は、それ自体が安全の統制です。これを、監視、アラート、Infrastructure as Codeと組み合わせ、稼働中のサービスが観測可能で、再現可能になるようにします。

5. 手法を不確実性に合わせる。 ユーザーのニーズが不確実で、ディスカバリーがまだ物事を教えてくれているところではアジャイルを使い、ウォーターフォール的な順序づけは、要件が本当に固定され、変更のリスクが低い場合にのみ受け入れます。一つの手法がすべてを統べているふりをするのではなく、ハイブリッド、つまりプログラムの包みの中のアジャイルのチームを運営していることを明示してください。ふりは、誰も欺けず、全員を苛立たせます。

6. サービス評価を、試験ではなく、デザインの道具として扱う。 アシュアランス、臨床安全、セキュリティ、アクセシビリティのレビュー担当者を、早期から頻繁に巻き込み、正式な評価が、すでに標準に合わせて作られたサービスを確認するだけになるようにします。評価の一週間前に初めて標準に出会うチームは、ゆっくりと高くつく形で失敗し、標準を内面化したチームは、その副産物として合格します。

7. ライブでも反復を続け、それに資源を割り当てる。 サービスは、稼働してもチームを必要としなくなるわけではありません。ライブは、実際の利用が、最後の不公平、まれだが深刻な臨床のエッジケース、アクセシビリティのギャップを露呈する場です。サービスの運用寿命にわたって、常設のプロダクトチームに資金を出します（トピック5.0 — プロダクト主導の仕事参照）。チームのない稼働中のサービスは、臨床リスクを蓄積する技術的負債です。

8. 必要になる前に、廃止を計画する。 構築している間に、サービスが最終的にどう廃止されるかを決めます。記録管理の法律の下でのデータの保存と移行、ユーザーの振り向け、臨床家への通知、臨床安全性ケースと監査証跡のアーカイブ。計画されていない廃止は、データとユーザーを取り残し、計画された廃止は、管理され、監査可能なフェーズです。

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

1. 私たちのフェーズの関門は、本当にエビデンスに統治されているのか。それとも、いつの間にか計画上の日付になっていないか。 ディスカバリー、アルファ、ベータ、ライブのモデルの価値のすべては、前のフェーズのエビデンスがそれを正当化するときにのみ、各移行がより多くのお金をコミットし、より多くのユーザーを晒すことにあります。エビデンスが揃ったからではなく、四半期が終わったから関門が開く瞬間、傾斜路はリスクの低減をやめ、「アジャイルの衣装をまとったウォーターフォール」になります。この問いは、チームに、直近の数回の移行を正直に振り返り、もしエビデンスが「まだです」と言っていたら何が起きたかを問うよう求めます。保留する余地があったか、難しい機能のためにベータをアルファに戻せたか、それとも稼働日は政治的に動かせなかったか。議論すべき緊張は、組織の、読み取れて取締役会が予定するマイルストーンへの必要性と、安全なサービスはエビデンスのペースで動くという現実の間にあり、ハイブリッドのデリバリーは、まさにその摩擦の中にあります。具体的な視点には、次の関門で期日を迎える具体的な決定とエビデンスを名指しすること、「スプリント」が実際に範囲を変えるのか、固定された計画を追っているだけなのかを確認すること、キャリアのリスクなしに、関門を遅らせる権限を与えられているのは誰かを問うことが含まれます。良い答えは、エビデンスが計画を変えた実例を示し、何のエビデンスが、次の公費とユーザーのコミットメントを正当化する、あるいは妨げるかを明確に述べられます。

2. 臨床安全と情報ガバナンスは、あらゆるフェーズを貫く生きた糸か。それとも、ライブの前に終えるつもりの書類仕事か。 医療・ケアでは、DPIAとDCB0129/0160の臨床リスクの作業は、プロジェクト終盤の承認ではなく、アルファ以降、アーキテクチャと設計を形づくらなければならない糸です。早期に設計で取り除かれたハザードは安く、稼働時に発見されたハザードは、ローンチを止める危機、あるいはさらに悪いことに、安全性ケースを通してしまうよう迫るプレッシャーだからです。この問いは、解決策の形が現れたらすぐに、名前のある訓練された臨床安全責任者と開かれたハザードログが存在するか、そして、データの流れがまだ変更できるほど柔らかいうちに、ディスカバリーでDPIAと適法な根拠の分析が始まったかを浮かび上がらせます。議論する価値のあるトレードオフは、これを継続的に行うことで感じる負担と、後付けの、はるかに大きなコストと臨床リスクの間にあります。特に、まだ規制当局が見ていなくても、DCB0129の義務が、会社の規模にかかわらず製造者に課される、小規模なチームやスタートアップにとってはそうです。具体的なエビデンスを考えてください。ハザードログは、アルファで見つかり軽減されたハザードを示しているか、安全性ケースは、すでに行われた仕事の要約として読めるか、DPIAは実際の設計上の判断にたどれるか。誠実な答えは、サービスとともに安全性ケースを成熟させるチームと、ローンチの前月の書類の駆け込みに向かうチームを区別します。

3. このサービスはライブでどう運用され、最終的にどう廃止されるのか。そして、それを行うために資金が付いているのは誰か。 ライフサイクルには、組織が日常的に資金不足にする長い尾があります。ライブは、実際の利用が、最後の不公平、まれだが深刻な臨床のエッジケース、アクセシビリティのギャップを露呈する場であり、稼働時に解散して、サービスを腐らせ臨床リスクを静かに蓄積させるチームではなく、常設のプロダクトチーム、監視、速く元に戻せるデプロイを必要とします。同じように見過ごされるのが廃止です。記録の保存に関する法律の下でサービスを廃止し、データを移行またはアーカイブし、ユーザーを振り向け、臨床家に通知し、ハザードログと監査証跡を保全することは、国のシステムにとっては、後継が届いたときの後付けではなく、それ自体が大きなプログラムです。議論すべき緊張は、年次の資金サイクルと、ローンチ時にプロジェクトを「完了」と宣言する圧力、対、安全なサービスが実際に必要とする、ライフサイクル全体にわたる所有です。有用な視点には、監視と素早いロールバックを備えたCI/CDのパイプラインが、稼働中の安全の統制として扱われているか、オンコールと反復の予算が、稼働の祝賀を生き延びるか、出口の計画が、パニックの中で即興されるのではなく、構築している間に書かれたかが含まれます。良い答えは、運用寿命にわたってサービスを所有する人を挙げ、誰かがあとで対処してくれるという希望ではなく、管理され、監査可能な廃止を説明します。

4. プロトタイプの失敗が、最後に私たちを止めたのはいつか。そして、私たちはまだ、捨てるためのものを作っているか。 アルファは、最もリスクの高い想定を安く潰すために存在し、失敗する使い捨てのプロトタイプは、その仕事を果たしたことを意味します。本番のお金と本物の患者がコミットされる前に、高くつく教訓を買ったのです。この問いは、チームが本当にアルファを使い捨ての学習として扱っているのか、コードを捨てることが無駄に感じられるために、最初のプロトタイプを磨き上げて最終的なプロダクトにしてしまう方向へ、静かに滑っていないかを探ります。これは、リスク低減のフェーズを、目隠しで行う高価なコミットメントに変える、埋没費用の罠です。浮かび上がらせる価値のある緊張は、「見せるものを用意する」圧力と、書いたすべての行を再利用したいという思いと、本番のインフラで本物を作る前に、解決策が機能する可能性があることを証明するという規律の間にあります。具体的な視点には、直近のアルファが実際にどの想定をテストしたか、どれかのプロトタイプがエビデンスに基づいて放棄されたことがあるか、非公開ベータの構築が、本番の標準で書き直すべきだった使い捨てのコードを再利用しなかったかを問うことが含まれます。誠実な答えは、プロトタイプが潰した、あるいは確認した具体的な想定を挙げ、チームが捨てる意思のあった学習の成果物と、いまライブで走らせている保証されたコードを区別できます。

5. 私たちは一つの誠実なハイブリッドを運営しているのか。それとも、互いに静かに矛盾する、偽装された複数の手法か。 大規模な医療プログラムの大半は、本当にハイブリッドです。組織とその規制当局が求める、マイルストーンと資金の包みの中で動く、アジャイルのプロダクトチーム。失敗はハイブリッドそのものではなく、それが純粋なアジャイルか純粋なウォーターフォールであるふりをすることで、二つの論理が、あらゆる関門で管理されないまま衝突することです。この問いは、チームに、固定された順序づけのコミットメント（資金の段階、規制上のマイルストーン、連携の凍結）が実際にどこにあり、本物の反復がどこで起きるかを名指しするよう求めます。「アジャイル」と「計画」が、それぞれプログラム全体を主張して全員を苛立たせるのを許さないためです。議論すべきトレードオフは、組織の、予測可能なマイルストーンと監査可能な支出への正当な必要性と、エビデンスに基づいて範囲を変えるというデリバリーチームの必要性の間にあり、誠実な手は、継ぎ目を明示して、両方を見越して計画できるようにすることです。有用な視点には、バックログの再優先順位づけが、プログラム計画との接触を生き延びることがあるか、サプライヤーが、反復的に働くよう求められながら、固定の範囲で契約されていないか、取締役会が見る報告が、仕事の実際の進め方と一致しているかが含まれます。良い答えは、名前のある固定点と名前のある柔軟な空間を備えた、意図的に設計されたハイブリッドを説明し、体裁のために手法が主張される混乱ではありません。

6. 稼働中のサービスがいま、ユーザーに実際に何をしているのかを、どれだけよく知っているか。そして、彼らが報告する前に、害に気づけるか。 稼働中の医療サービスは、その観測可能性と同じだけ安全です。監視、アラート、指標をハザードに変える臨床安全の勘は、古いデータの欠陥を数分で捉えるか、数週間後にインシデント報告で知るかの違いを生みます。この問いは、チームが本番のサービスを見られるか、つまりエラー率、連携の失敗、アクセシビリティでの離脱、実際の利用だけが明らかにする公平性のギャップを見られるか、そして誰かが、インフラの稼働時間だけでなく、臨床リスクを念頭にダッシュボードを見張っているかを検討します。緊張は、適切な観測可能性とオンコールのコストと規律と、サービスが稼働したら「便りがないのは良い便り」という静かな想定の間にあり、安全性が重要な領域では、それが静かな害が蓄積する仕方です。具体的な視点には、ハザードログが稼働中のインシデントから更新されているか、アラートがサーバーの健全性だけでなく臨床的な影響に対応しているか、悪いリリースが、多くの患者に届く前に検知されてロールバックできるかが含まれます。誠実な答えは、チームが見る具体的なシグナル、監視が捉えた（あるいは見逃した）実際のインシデント、そして稼働中のエビデンスが次の反復にどうフィードバックされるかを説明します。

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

あるコミュニティNHSトラストが、地域看護師の訪問スケジュールのための、レガシーな紙とスプレッドシートのシステムを置き換えようとしています。ディスカバリー（トピック3.4）を経て、チームはアルファに入り、最もリスクの高い想定、つまり看護師が患者の自宅で電話を使うこと、そしてスケジュールが電子患者記録と連携できることをテストするために、二つの使い捨てのプロトタイプを作ります。臨床安全責任者はアルファの初日に任命されてハザードログを開きます。同僚がすでに完了した訪問を、古いスケジュールが表示するという初期のハザードが、リアルタイムの同期状況を示すという設計上の判断を促します。ディスカバリーで始められたDPIAは、単独で働く職員の位置情報には、定義された適法な根拠と保存期限が必要であることを指摘します。

アルファからベータへのサービス評価で、独立した審査員団が、アクセシビリティ（視覚障害のある看護師）、セキュリティ、チームの推論を探ります。サービスは、是正項目付きで合格します。非公開ベータでは、10人の看護師が本番のインフラ上で本物のシステムを使い、CI/CDのパイプラインによって、チームは毎日出荷し、悪いリリースを10分以内にロールバックできます。利用が公平性の問題、つまりトラストの端末を持たない派遣職員を明らかにし、ブラウザベースの代替手段につながります。公開ベータは、3つの地域に拡大し、臨床安全性ケース報告書は、より広い展開の前に、DCB0160の下で完成し、承認されます。

サービスは、常設のプロダクトチーム、監視ダッシュボード、オンコールの当番表を備えてライブになります。18か月後、トラストが地域のプラットフォームを採用したとき、スケジュールは計画どおり廃止されます。保存スケジュールの下でデータが移行され、看護師が再訓練されて振り向けられ、ハザードログと安全性ケースが監査のためにアーカイブされます。すべての移行は、ガントチャート上の日付ではなく、エビデンスに裏づけられた決定でした。

セクター別の視点#

スタートアップ#

スタートアップのライフサイクルは圧縮され、大部分が自己統治です。独立したサービス評価の審査員団はないため、アルファ、ベータ、ライブの関門の規律は自ら課さなければ、「継続的に出荷して祈る」へ崩壊します。利点は、小さなチームが初日から本物のCI/CDを動かし、どんな大きな組織よりも速く反復できることです。危険は、まだ規制当局が見ていないために、臨床安全とDPIAの糸を静かに落とすことで、医療では致命的な誤りです。DCB0129の義務は会社の規模にかかわらず製造者に課され、一つの管理されていないハザードが、プロダクトと会社の両方を終わらせうるからです。スタートアップは、儀式がなくても、フェーズモデルの意図、つまり晒す前にエビデンスを、採用すべきです。解決策の形が現れたらすぐに、（多くは兼務の）臨床安全責任者を任命してください。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、通常、ライフサイクルに、構築者ではなく導入者として出会います。サプライヤーのシステムを調達または設定しているため、社内のデジタルチームがなくても、DCB0160の導入承認と地域のDPIAが自分たちに降りかかります。フェーズは依然として適用されますが、圧縮され外部委託されます。「アルファ」は、少数の実際の患者での監督付きパイロットであり、「ベータ」は診療所全体への段階的な展開で、ライブは、サプライヤーの更新が継続的に、そして診療所の制御の大半の外で届く日常業務です。組織は、臨床安全責任者（多くは日々の仕事に加えてその役割を担う臨床パートナー）を指名し、システムが地域でどう使われるかについてのハザードログを保たなければなりません。製造者のDCB0129の作業は、導入に特有のリスクをカバーしないからです。資金が乏しく、専任のITもないため、現実的な規律は、サプライヤーのアシュアランスに頼りながら、地域の知識だけが下せる少数の決定、つまり誰が訓練されるか、システムが停止したときの代替手段は何か、この特定の環境でのデータの流れはどうかを、自ら所有することです。

大企業#

NHSトラストや大手サプライヤーは、ライフサイクルを、最も完全で最も保証された形で運営します。正式なサービス評価、名前のある臨床安全責任者、DCB0160の導入承認、変更諮問委員会、そしてアジャイルの仕事が収まらなければならない年次の資金サイクル。特徴的な課題はハイブリッドです。組織と監査人が求める、プログラムとマイルストーンの包みの中で動くアジャイルのデリバリーチームであり、典型的な失敗は「アジャイルの衣装をまとったウォーターフォール」で、関門が静かにカレンダー上の日付になります。大企業には、CI/CD、観測可能性、常設のプロダクトチームを適切に行う資源がありますが、組織の惰性とレガシーな連携が、デプロイをのろのろにしてしまうことがしばしばあります。説明責任は広く、影響範囲は大きいため、非公開ベータからライブへの段階的な傾斜路は、任意の慎重さではなく、不可欠なリスクの統制です。

政府#

国の機関は、完全なService Standard、公表されるサービス評価、支出管理、議会の精査の下で提供するため、あらゆるフェーズの関門は、公的な説明責任の地点でもあります。ここでのライフサイクルは長く、影響範囲は広大です。NHS全体のライブサービスは、何百万人に触れうるため、段階的な傾斜路、臨床安全のアシュアランス、置き換えられるレガシーシステムの廃止の利害が高まります。調達のルールと複数年の資金の取り決めが、実際には「アジャイル」が何を意味しうるかを形づくり、国のシステムの廃止（数十年分の記録と法定の保存義務を伴う）は、それ自体が大きなプログラムです。トレードオフは、アシュアランス対速さです。政府のデリバリーは強く関門が設けられており、安全と公費を守りますが、チームが、大きな設計を最初に行う方式に戻るのではなく、反復し続けるよう、意図的な努力が必要です。

よくある失敗パターン#

• アジャイルの衣装をまとったウォーターフォール。 チームが「スプリント」を回すが、範囲、日付、設計はすべて最初に固定されており、反復は芝居。対策：各関門でのエビデンスが、計画を本当に変えられるようにする。
• 最後に付け足される安全とIG。 臨床安全性ケースとDPIAが稼働の前月に書かれ、ローンチを止めるか、さらに悪いことにプレッシャーの下で通される。対策：アルファでハザードログとDPIAを開き、継続的に成熟させる。
• ビッグバンのローンチ。 サービスが非公開/公開ベータを飛ばして完全展開に直行し、すべてのユーザーを未検証のソフトウェアに晒す。対策：段階的な傾斜路を使い、エビデンスとともに露出を拡大する。
• 放棄されたライブのサービス。 デリバリーチームが稼働時に解散し、サービスが腐り、臨床リスクが静かに蓄積される。対策：運用寿命にわたって、常設のプロダクトチームに資金を出す。
• 評価直前の詰め込み。 評価が迫るまで標準が無視され、その後、表面的に満たされる。対策：アシュアランスと臨床のレビュー担当者を継続的に巻き込む。
• 出口の計画がない。 後継が届いたときにパニックでサービスが廃止され、データとユーザーが取り残される。対策：廃止を第一級のフェーズとして計画する。

成熟度モデル#

チェックリスト#

• サービスに明示的な現在のフェーズ（ディスカバリー/アルファ/ベータ/ライブ）と、名前のある次の決定がある。
• フェーズの移行が、日付ではなくエビデンスに基づいて関門にかけられている。
• 臨床安全責任者が任命され、アルファ以降、ハザードログが開かれている（DCB0129/0160）。
• DPIAと適法な根拠の評価（Caldicott、UK GDPR）がディスカバリーで始まり、最新に保たれている。
• デリバリーの手法が不確実性の水準に合わせられ、あらゆるハイブリッドの取り決めが明示されている。
• サービス評価が計画され、アシュアランス/セキュリティ/アクセシビリティのレビュー担当者が早期に巻き込まれている。
• 公開ベータの前に、監視と素早いロールバックを備えたCI/CDのパイプラインが整っている。
• サービスが、ビッグバンではなく、段階的な傾斜路（非公開ベータ→公開ベータ→ライブ）でユーザーに晒されている。
• サービスの運用寿命にわたって、常設のプロダクトチームに資金が付いている（トピック5.0参照）。
• 廃止の計画が、データの保存/移行、ユーザーの振り向け、安全と監査の記録のアーカイブを網羅している。

主要な情報源#

• GOV.UK Service Manual — アジャイルプロジェクトのフェーズ（ディスカバリー、アルファ、ベータ、ライブ）とGovernment Service Standard。
• NHS England — NHS Service StandardとNHS Digital Service Manual、NHSのサービス評価。
• NHS England Digital — DCB0129（Clinical Risk Management: its Application in the Manufacture of Health IT Systems）とDCB0160（its Application in the Deployment and Use of Health IT Systems）。
• NHS England — デジタルの臨床安全アシュアランス、臨床安全責任者の役割、ハザードログ、臨床安全性ケース報告書。
• NHS England — Digital Technology Assessment Criteria (DTAC)。
• 英国のCaldicott原則、2018年データ保護法/UK GDPRとデータ保護影響評価。
• NICE — Evidence Standards Framework for Digital Health Technologies。
• DevOpsと継続的デリバリーの実践（例：DORAのケイパビリティ：継続的インテグレーション、デプロイの自動化、監視）、継続的デリバリーとサービスの運用に関するGOV.UK Service Manualのガイダンス。

参考文献#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health