トピック5.0 — プロダクト主導の仕事
一文で言うと: プロダクト主導の仕事は、機能の固定リストを届けることではなく、測定可能な成果に責任を負わせながら、権限を与えられた継続的なチームに、サービスをその全生涯にわたって所有させるために資金を出すことです。
医療・ケアにおいてなぜ重要か#
デジタルヘルス・ケアの組織が運用しているもののほとんどは、一回限りの納品ではなく、生きたサービスです。NHS App、電子患者記録、共有ケア記録、電子紹介のパスウェイ、社会的ケアのケース管理システム。これらのどれも「完成」していません。臨床ガイダンスが変わり、安全インシデントが表面化し、需要が移り、周囲の環境が進化するにつれて、継続的に改善されなければなりません。
生きたサービスを、ばらばらのプロジェクトの連続として管理すると、予測可能な失敗が起きます。サプライヤーが仕様に合わせて構築し、資金が尽き、チームが解散し、サービスは、次の資本の入札まで、放置されて朽ちていきます。臨床家はギャップを回避して働き、患者安全のリスクが蓄積し、ぎこちないサービスに最も耐えられない人々こそが最もニーズが大きいため、公平性が損なわれます。プロダクト主導の仕事は、その循環を断ち切るために存在します。安定したチームを、利用者と成果の近くに置き続けることで、サービスが、資金調達のラウンドの間に劣化するのではなく、時とともに、より安全で、より使いやすく、より公平になるようにします。
賭け金は、財務的かつ法定のものでもあります。誰かが利益を得たかどうかにかかわらず、成功を「期限と予算どおりに納品された」で測るプロジェクトよりも、サービスが実際にケアを改善するかを継続的に検証するチームのほうが、公金をよりよく守ります。本トピックは、トピック5.1 — プロジェクト主導の仕事とトピック5.2 — プログラム主導の仕事と並びます。この三つは、競合するものではなく補完し合う道具であり、それらをどうまとめるかは、トピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント(EPPM)で説明します。
中核概念#
継続的なプロダクトチーム。 プロダクトやサービスを、そのライフサイクル全体にわたって所有する、機能横断で長期にわたるチームです。チームは存続し、仕事がそこへ流れてきます。これは、Marty CaganとSilicon Valley Product Group(SVPG)が述べるプロダクトオペレーティングモデルの、原子的な単位です。プロダクトマネージャー、プロダクトデザイナー、エンジニアからなる安定したグループで、医療の文脈では、臨床とデータの専門性に支えられます。
権限を与えられたチーム。 Caganは、作るべきもののロードマップを渡される「フィーチャーチーム」と、解決すべき問題と達成すべき成果を渡され、最善の解決策を見つけることを信頼される「権限を与えられたチーム」の間に、鋭い線を引きます。権限の付与は、何でも行ってよいという許可ではありません。明確な戦略の枠組みの中での、結果への説明責任です。
アウトプットよりアウトカム。 アウトプットとは、出荷するもの、つまり機能、リリース、画面です。アウトカムとは、その結果として世界に起きる変化です。より少ない予約の無断キャンセル、より速い退院、より少ない投薬の誤り、より公平な利用。プロダクト主導の仕事は、チームを成果で測ります。誰も使わない、あるいは誰の安全にも寄与しない機能を出荷することは、進歩の装いをした無駄だからです。
プロダクトマネージャー。 プロダクトの価値と実現可能性に責任を負うプロダクトマネジメントのリードです。これは作る価値があるか、人々は使うか、組織の戦略、規制、財務に適合するか。医療・ケアでは、この役割は、臨床安全と情報ガバナンスのリードの上に座るのではなく、彼らと緊密に連携しなければなりません。
プロダクトオペレーティングモデル。 SVPGは、これがモデルであって、方法論でも硬直した枠組みでもないことを明確にしています。導入する規定のプロセスではなく、企業が技術に支えられたプロダクトをどう構築し運営するかについての、一連の原則、つまり権限を与えられたチーム、成果への説明責任、継続的なディスカバリー、プロダクト戦略です。
プロダクトライフサイクル。 ディスカバリー(解決する価値のある本物の問題はあるか)、デリバリー(安全に、うまく作る)、成長と最適化(採用と成果の改善)、そして最終的にはサンセット(優雅な廃止または置き換え)。プロダクト主導のチームはそのすべてを所有するため、プロジェクトのチームにはできない、生涯全体にわたる賢明なトレードオフを行えます。
ベストプラクティス#
プロジェクトではなく、チームに資金を出す。 Mik KerstenがProject to Productで論じるように、期限付きのプロジェクトの予算から、バリューストリームに結びついた継続的なプロダクトの予算へ、資金を移します。継続的なチームに、連続する計画サイクルを通じて成果を追求するための資金を出し、何年も前に合意したマイルストーンの計画ではなく、実証された結果に基づいて、資金を再承認します。
チームに、機能のリストではなく、問題と成果を与える。 使命を、「外来の予約の無断キャンセル率を減らす」や「臨床家が結果を探すのに費やす時間を削減する」として枠づけ、あとは権限を与えられたチームに、最善の解決策を見つけさせます。上から与えられる、約束された機能のロードマップは、Caganが警告する、フィーチャーチームというアンチパターンを再現します。
成果の指標を、明示的で臨床的に意味のあるものにする。 少数の成果指標を最初に合意し、できれば目標と主要な成果(OKR — トピック7.3参照)として設定します。あらゆる効率の指標を、安全と公平性の指標と組み合わせ、チームが、害や不平等の拡大を代償にした速さで報われることが決してないようにします。
チームを、実際の利用者の近くに置く。 継続的なディスカバリーを組み込みます。臨床家、介護職員、事務職員、患者との定期的な接触です。NHS Service ManualとGOV.UK Service Manualはどちらも、ユーザーリサーチを、一度限りのフェーズではなく、常設の規律としています。継続的なチームなら、関係が続くため、これを現実的な負担で行えます。
臨床安全をチームの中に置いた、多職種のチームを築く。 デジタルヘルスのプロダクトチームには、プロダクト/デザイン/エンジニアリングに加えて、臨床安全責任者(DCB0129/DCB0160)、情報ガバナンス、データの専門性が必要です。安全とガバナンスは、最後に取り付けられる関門ではなく、チームの中で所有される設計上の入力です。
プロダクトを計装し、データに基づいて行動する。 継続的なチームは、テレメトリーに投資できるため、意思決定が、意見ではなく、実際の利用と実際の成果に根ざします。デジタル排除を早期に捉えるため、コホート別に採用を見ます。
サンセットを含め、ライフサイクル全体を所有する。 権限を与えられたチームは、ローンチだけでなく、優雅な廃止と移行も計画します。構築を続けないと決め、戦略的なプラットフォームに統合することは、正当で価値あるプロダクトの判断です。
マイクロマネジメントではなく、戦略を通じてチームを整合させる。 整合のない自律は、局所最適と混乱を生みます。明確なプロダクトのビジョンと戦略、そして規模においては、ポートフォリオとプログラムの枠組み(トピック5.2とトピック5.3)が、チームに安全に権限を与えられるようにするものです。
チームで話し合うための問い#
現在運用しているサービスのうち、継続的で資金を与えられたプロダクトチームに値する、本物の生きたサービスはどれか。そして、そう見せかけているだけの有限の仕事はどれか。 これは根本的な仕分けの問いであり、どちらの方向に誤っても高くつきます。デジタルヘルス・ケアの組織では、環境は混在しています。共有ケア記録や患者向けのアプリは生きたサービスですが、一回限りのデータセンターからの撤退やハードウェアの更新は、本当に有限です。そして誠実な答えは、あらゆる場所に一つの資金モデルを適用するのではなく、重要なシステムのそれぞれを名指しして、その主張を論じることを求めます。緊張は、財務とガバナンスの機構が、通常、あらゆるものを、期限付きの資本の入札へ向かわせることにあります。そのため、何かを「プロダクト」と呼ぶことは、特別扱いの懇願のように感じられ、生きたサービスを「プロジェクト」と呼ぶことは、本トピックの初めに述べた、作って放置する劣化を、静かに保証します。生涯全体のコスト、サービスを取り巻く臨床ガイダンスと需要の変化の速さ、そして継続的な改善を誰も所有しないとき、患者安全のリスクが蓄積するかを考えます。良い答えは、継続的なチームが明確に正当化される二つか三つのサービスを挙げ、境界線上のものについて率直で、一律の方針を擁護するのではなく、有限の仕事を、明示的にトピック5.1に回します。
チームの資金を賭けるなら、実際に用いる二つか三つの成果指標は何か。そして、害を代償にした速さで報われることが決してないよう、それぞれをどう安全と公平性の指標と組み合わせるか。 アウトカムがアウトプットに勝る、と言うのは簡単ですが、運用に移すのは難しいものです。指標がお金を動かした瞬間に、行動を歪め始めるからです。「無断キャンセル率を減らす」よう言われたデジタルヘルスのチームは、最もデジタルに自信のある患者を促すことで、その数字を達成できる一方、高齢の、あるいはより困窮したコホートのギャップを、静かに広げかねません。したがって、議論では、各チームが過剰に最適化しうる効率の単一の指標は何か、そして組み合わされた安全と公平性のガードレールが実際に何を測るかを表に出す必要があります。具体的な候補(投薬の誤りの減少、より速い退院、地域やデジタルアクセスの代理指標別の利用)を持ち寄り、それらが臨床的に意味があるのか、単に計装しやすいだけなのかを、ストレステストします。各指標を誰が所有し、ベースラインは何で、どのくらいの頻度でレビューされるかを考えます。所有者のいない、あるいはベースラインのない成果は飾りだからです。誠実な答えは、気にかけている成果の中に、遅く、あるいは測りにくいものがあることを受け入れ、見栄えのする採用の数字への引力に抵抗し、トレードオフが見えるままになるよう、公平性の指標を効率の指標と並べて公表することにコミットします。
権限を与えられたチームに、方向を変える本物の権限をどこまで与える用意があるか。そして、その自律が局所最適へ断片化しないようにする、どんな戦略の枠組みがあるか。 権限の付与は、プロダクトオペレーティングモデルの要であり、最も一般的な偽物でもあります。組織は、固定されたロードマップを渡し、デリバリーを測りながら、チームを「プロダクトチーム」と改称するからです。本物の問いは、境界がどこにあるかです。ディスカバリーが、別の解決策のほうが成果をよりよく実現すると示したとき、チームは、取締役会が後援する機能から、その別の解決策へ方向を変えられるのか、それとも臨床ガバナンス、情報ガバナンス、既存のサプライヤー契約が、実際にはそれを拒否するのか。緊張は、整合のない自律は、ICS全体で重複と漂流を生み、マイクロマネジメントとして徹底される整合は、フィーチャーファクトリーを再現することです。そのため、答えは、命令せずに制約する、明示的なプロダクトのビジョンと戦略、そして規模においてはポートフォリオの枠組みにあります。チームが方針を変えたがった最近の判断を考え、システムがそれを許したかを正直に問います。良い答えは、チームが単独で下してよい判断と、エスカレーションが必要な判断を定義し、枠組みを与える戦略文書を挙げ、組織が現在、統制と整合を混同しているところについて率直です。
年次の予算サイクルを通じて、継続的なチームにどう資金を出し、擁護するか。そして、財務が、固定の終了日のない「プロダクト」の正当化を求めたとき、実際に何をするか。 プロダクト主導の仕事は、お金にかかっており、NHSと公共部門の財務の機構は、バリューストリームに結びついた継続的な収益の資金ではなく、期限付きの資本の入札のために作られています。そのため、この問いは、「プロジェクトではなくチームに資金を出す」の背後にある、居心地の悪い運用上の詳細を迫ります。緊張は、継続的なチームが、乏しい臨床、プロダクト、エンジニアリングの人材を引き留めるために、複数年の安定を必要とする一方、それが依存する予算の決着が、きれいな開始と終了を示す資本のスキームに対して、毎年争い直されることです。実際の数字を持ち寄ってください。チームの継続的なコストは何か、どのバリューストリームに対応するか、そして何年も前に合意されたマイルストーンの計画ではなく、再承認を正当化する、実証された成果のエビデンスは何か。資本と収益の会計ルール、調達のサイクル、サプライヤーの契約が、あなたの組織でこのモデルをどう助け、あるいは妨げるかを考えます。誠実な答えは、継続的な予算を誰が承認するか、厳しい予算の年にチームがどうなるか、そして組織が、本物のサービスをプロダクトのラインに転換する用意があるのか、静かにプロジェクトの入札に逆戻りさせるのかを挙げます。
プロダクト主導の仕事が、臨床安全と情報ガバナンスの義務に出会うとき、安全とガバナンスは、本当に設計上の入力としてチームの中にあるのか。それとも、チームが駆け寄り、交渉して回避する関門のままか。 継続的に出荷する、権限を与えられた継続的なチームは、リスクの像を変えます。あらゆるイテレーションが、プロジェクトの終わりでの一度の承認ではなく、臨床安全とデータ保護の潜在的な事象になるためです。したがって、DCB0129/DCB0160のハザードの作業とDPIAは、リリースの関門に取り付けられるのではなく、チームのリズムの中に存在しなければなりません。緊張は本物です。すべてのプロダクトチームに、臨床安全責任者と情報ガバナンスのリードを組み込むことは高価で、それらの技能は乏しいため、組織は、それらを薄く共有したり、保証を、チームが遅くに求める承認として扱ったりしたくなります。その誘惑こそが、安全について、作って放置する失敗を再現します。デリバリーの圧力の下で成果指標を最適化するチームは、内部に安全の声がなければ、害が患者に届いたあとで初めて、それを発見するからです。多くの小さなリリースにわたって、安全ケースをどう生きたままに保つか、ハザードログを誰が所有するか、そしてガバナンスの同僚が、ディスカバリーと優先順位づけへの本物の影響力を持つのか、最後の拒否権だけを持つのかを考えます。良い答えは、安全が現在、設計上の入力ではなく関門であるところについて率直で、継続的な保証を現実的な負担にする、人員とリズムにコミットします。
継続的なチームを、十分にサービスを受けていない利用者の近くに、本当に保つには、どうするか。そうして、継続的な改善がデジタル排除を縮めるようにし、広げないようにするには。 プロダクト主導の仕事は、公平性を第一級の成果として約束しますが、自分のプロダクトを計装する安定したチームは、すでに関与している利用者、つまりデジタルに自信があり、つながっていて、テレメトリーに現れる人々から、当然、最も大きな声を聞きます。そのため、利用者への近さが、静かに、容易な利用者への近さになりえます。緊張は、排除のリスクが最も高いコホート(高齢の患者、困窮した地域の人々、デジタルアクセスが乏しい、あるいは言語の壁がある人々)が、継続的なディスカバリーを通じて届くのが最も難しく高価であるにもかかわらず、まさに公衆衛生サービスが奉仕するために存在する人々だということです。具体的な実践を持ち寄ってください。どのコホートが研究に意図的に募集されているか、採用が地域とデジタルアクセスの代理指標別にどう見られているか、そしてデジタルの道が誰かを取り残すとき、どんなデジタル以外のフォールバックがあるか。チームの公平性の指標が、実際に判断を変えるのか、単に報告されるだけかを考えます。誠実な答えは、現在の研究の対象が、届きやすい人々に偏っているところを認め、まだ声を聞いていない、十分にサービスを受けていないグループを挙げ、改善が優位を複利で積み上げないようにする、具体的な投資、つまりアウトリーチ、支援付きのデジタル、電話でのフォールバックを説明します。
実践例:医療・ケアの事例#
ある統合ケアシステム(ICS)は、複数のトラストにまたがって使われる、患者向けの予約管理アプリを運用しています。歴史的に、改善はそれぞれ別のプロジェクトでした。サプライヤーが「SMSのリマインダーを追加する」ために契約され、それを納品して去りました。6か月後、リマインダーは誤作動し、誰も修正を所有せず、契約を再開するために資本の入札が必要でした。
ICSは、プロダクト主導のモデルへ移行します。プロダクトマネージャー、デザイナー、4人のエンジニア、臨床安全責任者、情報ガバナンスのリードからなる、継続的なプロダクトチームを立ち上げ、継続的に資金を出し、機能のリストではなく成果を使命とします。無断キャンセル(DNA)率を減らし、人口全体でのアクセスの公平性を改善する。
チームは、患者と外来のスケジューラーとともに、継続的なディスカバリーを行います。リマインダーは役立つものの、ある困窮した地域でDNAのより大きな原因は、患者が簡単に予約を取り直せず、単にその枠を逃してしまうことだと学びます。チームは、仕様ではなく成果を所有しているため、投資を、華やかな通知機能から、簡単な自己での再予約のフローへと方向転換し、地域別とデジタルアクセスの代理指標別に利用を計装します。
三つの計画サイクルを通じて、DNA率は下がります。そして決定的に、チームは公平性の指標を監視し、高齢の患者で利用が遅れていることを見つけて、デジタルの道が不平等を広げないよう、電話でのフォールバックの経路を促します。成果が実証できるため、資金は続きます。「承認されて放置」された機能は一つもなく、サービスは単に改善し続けます。のちに、国のプラットフォームが同じ機能を提供したとき、同じチームが移行を運営し、自らのコンポーネントをサンセットします。プロジェクトのチームには決して下せなかった、生涯全体の判断です。
セクター別の視点#
スタートアップ#
小さなデジタルヘルス企業では、プロダクト主導の仕事が既定であり、しばしば唯一の様式です。単一の権限を与えられたチーム、ときに会社全体が、プロダクトを端から端まで所有します。資金が制約となります。投資家の滑走路や助成金が、次のラウンドを正当化するのに十分な速さで、チームが成果の手応え(採用、継続率、初期の臨床的な兆し)を示さなければならないことを意味するため、継続的なディスカバリーと計装は、贅沢ではなく、生き残りの道具です。リスク選好は高く、説明責任は、取締役会や国民ではなく、創業者と投資家に向かうため、チームは数日で方向転換できます。罠は、臨床安全と情報ガバナンス(DCB0129、DPIA)を、先送りすべき企業の間接費として扱うことです。医療では、その規律はシード段階でも譲れず、NHSの購入者は、患者データに近づけさせる前に、DTACのエビデンスを求めます。
小規模事業者#
確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設や訪問介護事業所、単独拠点のクリニック、あるいはスタートアップの段階を過ぎた小規模なヘルステックのサプライヤーにとって、プロダクト主導の仕事が、専任の機能横断チームを立ち上げることを意味することはまれです。資金を出せる、余分なプロダクトマネージャー、デザイナー、エンジニアがいないからです。ここでの「継続的なチーム」は、多くの場合、診療所のマネージャーや登録管理者と、信頼できるサプライヤーであり、重要な規律は、システムを設定し保守する者に、一度限りの導入ではなく、成果、つまり、より少ない予約の無断キャンセル、より安全な薬剤の照合、最も虚弱な入居者へのより良いアクセスに対して責任を負わせることです。現金は、滑走路に限られるのではなく、継続的に逼迫しているため、賢明な動きは、誰も保守しない特注の構築を委託するのではなく、他者が生かし続けるプロダクト(よく運営されるサプライヤーのロードマップ、共有ケア記録、ICSのプラットフォーム)に乗ることです。臨床安全と情報ガバナンスは、全面的に適用されます。大きなトラストと同じDCB0160の導入の義務とDPIAの義務ですが、社内の能力はまったくないため、自らの安全ケースを所有するサプライヤーを選ぶことは、本物のプロダクトの判断です。公平性の側面は身近です。小規模な提供者は、まさにデジタル排除に最もさらされる、高齢の、あるいはより困窮した患者にサービスを提供していることが多いため、デジタル以外のフォールバックを保つことは、任意ではありません。
大企業#
大規模なNHSトラスト、統合ケアシステム(ICS)、ヘルステック企業では、継続的なチームのモデルは、年次の資本予算と、プロジェクトの形をした財務の機構と衝突します。中心的な仕事は、継続的なサービス、つまりEPR最適化のチームや共有ケア記録のチームを、停止と再開を繰り返すプロジェクトから、バリューストリームに結びついた継続的な予算を持つ、資金を与えられたプロダクトチームへ転換することで、それは組織図の変更であると同時に、財務とガバナンスの変更です。説明責任は、臨床ガバナンス、情報ガバナンス、取締役会の保証、サプライヤー契約に重層的に及ぶため、権限の付与は、数十の自律したチームが局所的に最適化するのを防ぐため、明示的なプロダクト戦略とポートフォリオの整合(トピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント参照)と組み合わされなければなりません。規模は、利用者への近さの敵であるため、組み込まれたリサーチへの意図的な投資が、大きな組織のチームを誠実に保ちます。
政府#
国の規模、つまりNHS England、DHSC、UKHSAでは、プロダクト主導の仕事は、長寿命のプラットフォーム(NHS App、NHS login、国の相互運用性のAPI)を、プログラムではなくプロダクトとして資金を出し、GDSとNHSのService Standardとそのサービスアセスメントに従います。資金はSpending Reviewの決着とビジネスケースを通じて流れるため、難しいのは、周囲の機構が期限付きのプロジェクトのために作られているときに、会計年度と政治のサイクルをまたいで、安定したチームを維持することです。説明責任は、大臣、議会、そして国民に対して、National Audit Officeを通じて負い、公平性の責務は法定であるため、成果の指標は、公表された人口レベルの公平性の尺度と組み合わされなければなりません。賞は到達範囲です。一つのプロダクトの改善が、同時に何千万人もの利用者に触れうるため、誤ったときの便益とコストの両方が高まります。
よくある失敗パターン#
- 名ばかりのプロダクト主導(「フィーチャーファクトリー」)。 組織が、プロジェクトのチームを「プロダクトチーム」と改称しながら、なお固定のロードマップを渡し、デリバリーで測る。対策:肩書きだけでなく、使命と指標を変える。
- 安全や公平性のガードレールのない成果。 単一の効率の指標を最適化すると、害を隠したり、排除を広げたりしうる。対策:あらゆる成果の指標を、安全と公平性の指標と組み合わせる。
- 戦略のない「権限の付与」。 自分で方向を発明するよう放置されたチームは、漂流し重複する。対策:強いプロダクトのビジョンと戦略、そしてポートフォリオレベルの整合(トピック5.3)。
- 本当に有限の仕事にプロダクト主導を適用する。 一回限りのデータセンターの移行やハードウェアの展開は、永続的なチームを必要としない。対策:範囲が本当に固定されているところには、プロジェクト主導の仕事(トピック5.1)を使う。
- 年次のプロジェクトの入札に戻る資金。 停止と再開を繰り返す予算の上の継続的なチームは、計画も人の引き留めもできない。対策:バリューストリームに対する、継続的で成果をレビューする資金。
- チケットを書く人としてのプロダクトマネージャー。 役割をバックログの管理に矮小化するのは無駄である。対策:プロダクトマネージャーに、価値、実現可能性、成果への説明責任を持たせる。
成熟度モデル#
| 観点 | 着手 | 発展 | 標準化 | 管理 | 統合 |
|---|---|---|---|---|---|
| チームの安定性 | プロジェクトごとにチームが編成され、その後解散する | 主力のサービスのために、一部の継続的なチームがある | 継続的なチームが、名前のあるプロダクトをライフサイクル全体で所有する | 定着と離職が目標に対して追跡され、キャパシティと代替が積極的に管理される | 安定したチームが、自分たちに仕事を流し、離職が少なく、深い領域の知識がある |
| 使命 | 機能のリストが与えられる | 機能と目標が混在する | チームが、解決すべき問題と成果を与えられる | 成果の所有が正式化され、使命が合意された目標に対してレビュー・舵取りされる | チームが戦略を形づくり、成果の所有を信頼される |
| 測定 | 成功=期限と予算どおりに納品 | 一部の利用指標が追跡される | 成果の指標(安全と公平性を含む)が合意・レビューされる | 成果のKPIがダッシュボードで追跡され、安全と公平性の統制が目標に対して保証される | 成果が、資金と舵取りの判断を継続的に動かす |
| 資金 | 年次/資本のプロジェクトの入札 | プロジェクトと部分的な継続的資金の混合 | バリューストリームに結びついた継続的なプロダクトの資金 | 継続的な資金が、合意された目標に対する定量的な成果レビューを通じて統治される | 成果に基づく再承認で、資金が実証された価値に従う |
| ディスカバリー | 要件が最初に一度だけ集められる | 時折のユーザーリサーチ | 利用者と臨床家との継続的なディスカバリー | ディスカバリーのリズムとコホートのカバーが、質について測定・管理される | 計装されたプロダクトで、エビデンスに基づく判断が既定 |
チェックリスト#
- これは、継続的なチームに適した、本当に継続的なサービス(有限の仕事ではなく)か。
- 安定した機能横断のチームが、ライフサイクル全体にわたってプロダクトを所有しているか。
- チームが、固定の機能リストではなく、問題と成果を使命としているか。
- 成果の指標が合意され、それぞれが安全と公平性の指標と組み合わされているか。
- 臨床安全(DCB0129/DCB0160)と情報ガバナンスが、チームの中にあるか。
- チームが継続的に資金を与えられ、実証された成果に基づいて再承認されているか。
- 継続的なユーザーリサーチとディスカバリーが、常設の実践になっているか。
- プロダクトが計装され、排除を捉えるために、コホート別に採用が見られているか。
- 自律を組織の目標に整合させる、明確なプロダクト戦略があるか。
- 優雅なサンセット/移行が、明示的なライフサイクルの段階として計画されているか。
主要な情報源#
- Silicon Valley Product Group (SVPG)、Marty Cagan — The Product Operating Model: An IntroductionとEmpowered Product Teams(svpg.com)、著書Inspired、Empowered、Transformed。
- Mik Kersten — Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework(IT Revolution、2018年)。
- NHS England — NHS Service ManualとNHS Digital Service Standard。
- GOV.UK — Government Digital Service (GDS) Service ManualとService Standard。
- NHS Digital — 医療ITシステムの臨床安全標準DCB0129(製造)とDCB0160(導入)。
- John Doerr — Measure What Matters(OKR)、成果に基づく目標設定のために。
参考文献#
- Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
- Product lifecycle — Wikipedia — https://en.wikipedia.org/wiki/Product_lifecycle
- Cross-functional team — Wikipedia — https://en.wikipedia.org/wiki/Cross-functional_team
- Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
- Objectives and key results (OKR) — Wikipedia — https://en.wikipedia.org/wiki/OKR
- Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
- NHS App — Wikipedia — https://en.wikipedia.org/wiki/NHS_App
- Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
- The Product Operating Model / Inspired, Empowered, Transformed — Marty Cagan, Silicon Valley Product Group — https://www.svpg.com/
- Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/
- NHS service manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/
- GOV.UK Service Manual and Service Standard — Government Digital Service — https://www.gov.uk/service-manual
- Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
- Measure What Matters — John Doerr — https://www.whatmatters.com/