10.13

View in English

10.13 組織間協働

概要と動機

組織間協働とは、共通の所有者、予算、指揮系統を持たない、二つ以上の独立した組織によるソフトウェアと技術についての共同作業です。それは、社内のチームワーク(1.2章)とは異なります。一つの会社の中では、リーダーは最終的に人々を指揮し、紛争を調停し、資源を再配分できます。組織の境界をまたぐと、誰にもできません。各当事者は自分の法的な同一性、インセンティブ、離脱の権利を保つので、協働は命じられるのではなく、ガバナンス、契約、信頼を通じて勝ち取られ、維持されなければなりません。この章がマネジメントの部にあるのは、組織間の仕事が、根本的に戦略、ガバナンス、関係の問題であり、技術的な帰結を伴うのであって、その逆ではないからです。

動機は、築く価値のあるすべてを単一の組織が築いて制御することはできないことです。オペレーティングシステム、暗号ライブラリ、ウェブのプロトコル、クラウドのツールのような基盤的なソフトウェアは、今や協働で築かれます。それを重複させるコストが莫大で、共有された相互運用可能な基盤の価値が、それを抱え込むことのどんな私的な優位性よりも大きいからです。コーペティション(協力と競争の混合。ライバルが共有の基盤で協力しながら、その上の製品で競争し続けること)が当たり前になりました。競合する企業が同じオープンソースのランタイムを共同開発し、それから上に築くサービスで差別化します。規模とネットワーク効果のために、誰もが使える共有の標準は、自分だけが使える独自のものに勝ります。

企業と政府にとって、賭け金は直接的で具体的です。企業は、依存するプラットフォームを形づくり、単一ベンダーへのロックインを避けるために、コンソーシアム(共有の目的のために作られた、会員が資金を出すグループ)やオープンソースの財団に加わります(10.3章、10.11章)。政府は絶えずこの問題に直面します。市民が一つのやりとりとして体験するサービスを届けるために、機関はデータを共有しなければなりません。法域は国境を越えて相互運用しなければなりません。公共部門は、共有プラットフォームをますます築きます。アイデンティティ、決済、通知のような共通のサービスを、一度築いて多くの機関が再利用する。繁栄するガブテックのエコシステム(政府のための技術を築くスタートアップ、ベンダー、公的機関のネットワーク)は、法的に別々の組織が実際に協働することに依存します。

主要原則

  • 誰も責任者ではない。 境界をまたぐと、あるのは権限ではなく影響力です。命令ではなく同意のために設計します。
  • 中立性が参加を可能にする。 中立の拠点は、ライバルが競合に優位性を渡さずに貢献できるようにします。
  • アーキテクチャの前にインセンティブを揃える。 協働は、技術的な非互換性よりはるかに頻繁に、ずれた利害で失敗します。
  • 相互運用性が技術的な基盤である。 オープン標準とインターフェース(3.8章)が、独立したシステムを実際につなげます。
  • 貢献とIPを明示的にする。 誰が何を所有し、誰が使えるかは、仕事が始まった後ではなく、始まる前に書き出されなければなりません。
  • 信頼は小さく検証可能なステップで築かれる。 狭く始めて届け、実績が積み上がるにつれて範囲を広げます。
  • 出口のために設計する。 どの当事者も去りえます。協働は、崩壊や乗っ取りなしに離脱を生き延びなければなりません。

推奨事項

目標に合う協働の形を選ぶ

唯一のモデルはないので、意図して選びます。業界の同盟とコンソーシアムは、領域の方向を設定し、資金をプールします。オープンソースの財団(共有のコードを保持し統治する、Linux FoundationやApache Software Foundationのような中立の非営利団体)は、多くの組織が築いて依存するソフトウェアをホストします。標準化団体(合意された技術仕様を公表するISO、IETF、W3Cのような組織)は、誰もが準拠してコードを書く相互運用性のルールを生みます。合弁事業は、共有の商業的な目的のために、新しい共同所有の事業体を作ります。官民パートナーシップ(PPP)、つまり政府と民間企業が公共サービスのデリバリー、資金調達、リスクを分かち合う長期の取り決めは、公的な権限と民間の能力を組み合わせます。機関間と政府横断の協働は、公的機関を直接つなぎます。共有プラットフォームと共有サービス、データ共有の取り決め、コーペティションが道具箱を仕上げます。形を目標に合わせます。軽い整合なら同盟、共有のコードなら財団、持続的な商業的な手段なら合弁事業。

境界をまたぐ中立のガバナンスを確立する

どの参加者も他を命令できないので、ガバナンスは明示的で、理想的には中立でなければなりません。共有の資産(コード、商標、ロードマップ)を、どの一人のメンバーにでもなく中立の財団に帰属させ、どの参加者も一方的に奪ったり操ったりできないようにします。決定権を明確に定義します。誰が技術的な方向を決めるか(しばしば技術運営委員会)、誰が予算を制御するか、紛争がどう解決されるか。参加者が共通の方向に対して計画できるよう、共有のロードマップを公表します。最も声が大きい、あるいは大きい者からではなく、合意されたルールから権限が流れるよう、書かれたガバナンスのモデルを採用します。Apacheの「実力主義」(貢献を通じて得られる影響力)と財団の理事会の構造は、実証された雛形です。

貢献と知的財産の条件を前もって明示する

知的財産(IP、コード、特許、商標のような法的に保護される創作物)は、善意の協働が最も頻繁に壊れる所です。コードを書く前に決着させます。明確なオープンソースライセンス(10.3章)を使い、全員が使用と再配布の権利を知るようにします。共有の資産に清潔な出所を与えるため、貢献者が自分のコードを貢献する権利を持つことを確認し、必要なライセンスを許諾する仕組みである貢献者ライセンス契約(CLA)またはDeveloper Certificate of Origin(DCO)を要求します。貢献者がのちに共有の成果物の利用者を訴えられないよう、特許を明示的に扱います。しばしば非主張あるいは特許の誓約の条項を通じて。書かれたIPの条件は、漠然とした善意を、持続的で強制力のある明確さに変えます。

データ、プライバシー、独占禁止について慎重に契約する

独立した組織間の協働は、社内の仕事にはない法的リスクを負います。データ共有の合意は、目的、許される使用、セキュリティの統制、保持、責任を規定しなければならず、個人データを共有する適法な根拠と、必要な所ではデータ処理の合意を含め、プライバシーとデータ保護法(4.5章)を尊重しなければなりません。独占禁止(市場を不当に制限する合意を禁じる競争法)は、競合が協働するたびに、生きた制約です。協力を競争前の基盤に保ちます。価格設定のような商業的に機微な情報の交換を避けます。目的が共謀ではなく、相互運用性と共有のインフラストラクチャであることを文書化します。法務を早期に巻き込んでください。データや独占禁止の失態は、協働を台無しにし、メンバーを罰則にさらしえます。

相互運用性とオープン標準の上に築く

相互運用性、つまり独立したシステムが情報を交換して使う能力(3.8章)は、他のすべてを可能にする技術的な基盤です。当事者が一つのベンダーの独自の内部に依存せずにつなげるよう、オープン標準(誰でも許可や料金なしに実装できる公開の仕様)と、安定して文書化されたインターフェース(API、アプリケーションプログラミングインターフェース)を好みます。政府では、共通のデータ標準と共有のAPIが、機関が境界をまたいでサービスを構成できるようにします(7.1章)。相互運用性がなければ、協働は、共有の価値を可能にするのではなく依存を根づかせる、脆い一対一の統合へと退化します。

インセンティブと信頼を意図して培う

参加は任意なので、各組織は継続的な利益を見なければならず、各組織は投資するのに十分に他を信頼しなければなりません。共有の価値を可視にして貢献におおよそ比例させ、どの主要な貢献者も搾取されていると感じず、どのフリーライダーも支配しないようにします。狭く、賭け金の低い範囲から始め、本物の何かを届け、実績が育つにつれてのみ広げます。これは、イノベーションパートナーシップ(10.9章)とInnerSource(1.2章)と同じ信頼構築の論理を、会社の境界をまたいで拡張したものです。透明性(オープンな決定、オープンなロードマップ、オープンな指標)は、権限が及ばない所で信頼を維持するものです。

トレードオフ: 長所と短所

アプローチ長所短所
オープンソースの財団中立の拠点。共有のコスト。広い採用。単一の所有者なし決定が遅い。資金と人員を出す必要。ガバナンスのオーバーヘッド
コンソーシアム/業界の同盟方向を形づくる。資金をプール。業界の重み政治で停滞しうる。大きなメンバーによる乗っ取りのリスク
標準化団体持続的な相互運用性。広い正統性非常に遅い。仕様が実践に遅れうる。重いプロセス
合弁事業明確な所有と商業的な手段。コミットされた資源組成も解消も複雑。出口とIPの紛争
官民パートナーシップ公的な権限と民間の能力を組み合わせる説明責任とロックインのリスク。長く硬直した契約
コーペティション共有の基盤、その上での競争的な差別化独占禁止の露出。共有と競争の境界が繊細

決定的な緊張は共有の価値対個別の制御です。当事者が中立の共有地にプールするほど、集合的な利益は大きくなり、結果を一方的に制御できる度合いは小さくなります。解決は、線を意図して引くことです。全員が共通の基盤から利益を得る、競争前の基盤で協働します。本物の競争上あるいは主権上の優位性が住む所では制御を保ちます(10.11章、3.8章)。

チームで議論すべき問い

  1. 共有の資産は中立の拠点に帰属していますか。それとも、のちにフォーク、再ライセンス、撤回ができる一つの参加者が握っていますか。 組織の境界をまたぐと誰も責任者ではないので、コード、商標、ロードマップを握る者が、いずれそれらを操る、あるいは奪えます。中立の財団は、ライバルが競合に優位性を渡さずに貢献できるようにし、それこそLinux FoundationとApache Software Foundationのモデルが存在する理由です。単一のメンバーが共有地を所有するなら、他のすべてのメンバーは一度の再ライセンスの決定から乗っ取られる位置にいます。貢献している共有の資産のそれぞれを持ち込み、それが法的にどこに住み、誰がその方向を制御するかを尋ねてください。答えが「最大のパートナー」なら、さらにエンジニアリングの労力を投資する前に直すべき、乗っ取りのリスクがあります。

  2. 協働の形を、目標に合わせて意図して選びましたか。それとも、なじみのあるものを既定にしましたか。 軽い整合には同盟、共有のコードには財団、持続的な相互運用性のルールには標準化団体、コミットされた商業的な手段には合弁事業、公共サービスには官民パートナーシップが必要です。それぞれが異なる速度、コスト、出口の帰結を持ち、間違ったものを選ぶことが、協働が政治で停滞する、あるいは硬直した長期の契約に化石化する方法です。形を実際に必要なものに合わせ、それを達成する最も軽い構造を好みます。特定の協働から望む具体的な成果を持ち込み、選択肢に照らしてテストしてください。共有のリポジトリと書かれたガバナンスの覚え書きで扱えることをするために、重いコンソーシアムに加わろうとしているなら、縮小してください。

  3. フリーライドをどう防ぎ、貢献を利益におおよそ比例させ続けますか。 共有地は、当事者が共有の成果を消費するが決して貢献しないと朽ち、主要な貢献者がフリーライダーに搾取されていると感じると分裂します。共有の価値を可視にし、貢献を利益におおよそ比例させ、共有する範囲を広げる前に信頼と実績が積み上がるよう、狭く賭け金の低い範囲から始めてください。透明性(オープンな決定、ロードマップ、指標)は、誰にも強制する権限のない所で協力を維持するものです。組織が各共有プロジェクトから受け取るものと、そこに戻すものの誠実な説明を持ち込んでください。依存するものの純粋な受益者であるなら、単一ベンダーのロックインからあなたを守るものを静かに弱めています。

  4. 協力するものと競争するものの境界はどこにあり、誰がそれを取り締まる資格がありますか。 コーペティションは、協働が競争前の基盤で止まることに全員が合意する場合にだけ機能します。競合が価格、市場戦略を明かすロードマップ、顧客データを交換した瞬間、協力は共謀になり、すべてのメンバーを競争法の罰則にさらすからです。大きなチームでは、危険は、共有のリポジトリの奥深くにいるエンジニアが、線が一度も引かれなかったために、法務が決して認めないであろうものの共有へずれていくことです。協働がカバーするものと明示的に除外するものの書かれた記述に加え、法務が確認した独占禁止のガードレールを持ち込み、新しいワーキンググループが形成される前にレビューする人を名指ししてください。規制当局が合弁事業とコンソーシアムを綿密に精査する企業と政府の設定では、文書化され法務が承認した境界を、調査が始まった後に埋め合わせる書類ではなく、参加の前提条件として扱ってください。

  5. この協働が乗っ取られる、停滞する、あるいは崩壊する場合の出口の計画は何で、ガバナンスは実際に私たちを守りますか。 どの当事者も去りえ、支配的なメンバーが共有地を自分の目的に向けて操りえ、コンソーシアムは何も出荷せずに何年も会合しえます。したがって、どう立ち去り、何を持ち出すかを事前に知っておかなければなりません。相反する考慮は、出口のための設計(可搬なデータ、オープンなライセンスのもとでフォーク可能なコード、単一ベンダーへの依存なし)が、関係が健全な間は無駄に感じられる労力を要することです。ライセンスの条件、商標とロードマップが法的にどこにあるか、主要なパートナーが撤退した週に組織が何をするかの具体的な答えを持ち込んでください。市民への複数年の義務を負う公的機関にとって、一つのメンバーが握るフォークできないプラットフォームは、人々が依存するサービスの継続性のリスクなので、オンボーディングの前に、中立の保管と出口の権利を書面で要求してください。

  6. この協働が実際に価値を届けているかをどう測り、何の証拠があれば離れますか。 組織間の仕事はゾンビのメンバーシップを蓄積します。離れることが政治的な表明のように感じられ、誰も見返りを追跡しないために、利益が薄れたずっと後も資金と人員を出し続けるコンソーシアム。成功がどう見えるか(私的な構築に対する回避されたコスト、共有の基盤の上で出荷された機能、減ったロックイン)に最初に合意し、参加のレビューを引き起こす閾値を設定します。席の年間コスト、貢献する職員の時間、過去1年に受け取ったものについての率直な見方を持ち込んでください。メンバーシップが部門にわたって増え、めったに取り消されない企業と政府のポートフォリオでは、各関係の所有者を名指しし、固定の周期でレビューし、撤退する権限を持たせてください。レビューする説明責任を誰も負わない協働は、誰も決して出ない協働だからです。

セクター別の視点

スタートアップ。 最も乏しい資源はエンジニアリングの注意なので、コモディティの依存関係を再発明するのをやめるためにだけ協働し、標準化委員会での威信を追うためには決して協働しないでください。単独では所有できない一つの共有ライブラリを共同で保守し、軽量なガバナンスの覚え書きとDeveloper Certificate of Originで出所をきれいに保ち、立ち去ってもフォーク以外に何もコストがかからないほど範囲を狭く保ちます。席に座ることよりも速度が重要です。共有の基盤があなたの生存を直接脅かすまでは、重いコンソーシアムは飛ばします。

小規模事業者。 社内に法務や標準の専門家はいないので、組織間の仕事を築くものではなく加わるものとして扱い、自分で起草するのではなく、中立の財団の既存のライセンスと貢献の条件に頼ってください。データ共有の取り決めに署名する前に、共有データで何ができ、責任がどこに着地するかについて、平易な言葉の答えを得ます。プライバシーや独占禁止の失態は、協働の価値より高くつきうるからです。交渉して取り締まらなければならないオーダーメイドの二者間の取引より、そのまま採用できる確立されたオープンソースの財団と公表された標準を好みます。

大企業。 協働を、多くのチームにわたるポートフォリオとして管理してください。属するすべてのコンソーシアム、財団、合弁事業の登録簿と、それぞれが消費するコストと職員の時間、返す価値。共有の資産の中立の保管、法務が確認した独占禁止の境界、支配的なパートナーが依存するプラットフォームを乗っ取れないよう、書かれたガバナンスのモデルを主張します。参加と貢献の労力に明示的に予算を付け、私的な投資は本物の競争上の優位性のために取っておき、全員が共有するコモディティの基盤にはコストをプールします。

政府。 調達規則、透明性の義務、公的な説明責任があらゆる取り決めを形づくるので、単一のベンダーが乗っ取れないオープン標準と中立のガバナンスを好み、すべての契約にデータの可搬性と出口の権利を求めてください。市民と監督機関がサービスの運営方法を見られるよう、共有プラットフォームのガバナンス、ロードマップ、データ共有の条件を公表し、機関間のデータ共有を明示的な適法な根拠とプライバシーの保護に根づかせます。モデルを証明するために、機微でないサービスを先にオンボードし、重大な決定への説明責任を、コンソーシアムに拡散させるのではなく、名指しされた公的な職員に保ちます。

事例

スタートアップ。 三つの初期段階のスタートアップが、それぞれ同じオープンソースのデータ解析ライブラリに依存しており、それは一人の疲れたボランティアが保守していて、その燃え尽きが全員を脅かします。それぞれが静かにフォークする代わりに、中立の共有リポジトリで、軽量な書かれたガバナンスの覚え書きと、貢献の出所をきれいにするDeveloper Certificate of Originとともに、共同で保守することに合意します。コモディティのパーサーでだけ協働し、自分たちのプロダクトは固く分けたままにし、共有するものを広げる前に信頼を築くため、狭い範囲(セキュリティパッチだけ)から始めます。

大企業。 競合するクラウドとソフトウェアのベンダー数社が、同じコンテナオーケストレーションのプラットフォームに依存しています。それぞれが私的なフォークを保守する代わりに、技術運営委員会、書かれたガバナンスのモデル、貢献者ライセンス契約を備えた中立の財団にそれを寄贈します。各社は、プラットフォームの上に築くマネージドサービスで引き続き激しく競争し(コーペティション)、共通の中核のコストと方向を分かち合います。これは単一ベンダーのロックインを避け、全員が頼る基盤を健全に保ちます。独占禁止の法務は、協力が市場や価格ではなく共有のインフラストラクチャに限定されていることを確認します。

政府。 国の政府は、市民が一度サインインして多くの機関のサービスに届くよう、共有のアイデンティティプラットフォームを立ち上げます。プラットフォームは、公表されたロードマップと明確な決定権を持つ中立の中央機関に統治され、各機関は独立のままで、オープンなAPIと共通のデータ標準(3.8章、7.1章)を通じて統合します。機関間のデータ共有の合意は、何を、何の目的で、どんなプライバシーの保護のもとで共有できるか(4.5章)を正確に規定するので、市民のデータは法律と同意が許す通りにだけ流れます。機微でない機関が先にオンボードし、より賭け金の高いサービスが加わる前に、信頼を築きモデルを証明します。

ビジネスケース: 動機、ROI、TCO

組織間協働の経済は、共有のコストとネットワーク効果にかかっています。中核の動機は、基盤的な技術が築いて保守するには高価だが、共有されるとはるかに価値が高いことです。共通のプラットフォームや標準への投資をプールすることで、総所有コスト(TCO)が多くの組織に広がるので、それぞれが私的な構築のコストのわずかな分を払い、他のすべてと相互運用する基盤を得ます。投資利益率(ROI)は、避けられた重複、すぐに使える基盤の上での市場投入の高速化、減ったロックインとベンダーに対するより強い交渉上の立場、そして一つの組織の壁を越えた人材とアイデアへのアクセス(10.9章)から来ます。

コストは本物で、しばしば過小評価されます。ガバナンスと法務のオーバーヘッド、意味ある形で参加する職員の時間、共有地への貢献の還元、単一の所有者ができるより遅い決定。政府にとっては、ビジネスケースは公共の価値を加えます。共有プラットフォームは断片化を減らし、機関全体の総支出を削り、市民の体験を改善しますが、説明責任と集団的な惰性のリスクと量らなければなりません。どちらの側の罠も、調整の誤りです。本物の競争上あるいは主権上の優位性であるものについて協働することは、差別化を無駄にします。コモディティの基盤について協働することを拒むことは、業界全体がすでに築いたものを、単独で満額払って築くことを意味します。最も強いケースは、共有の基盤にコストをプールし、制御が本当に重要な所のために私的な投資を取っておきます。

アンチパターンと落とし穴

  • フリーライド: 当事者が共有の成果を消費するが決して貢献せず、共有地が朽ちるまで飢えさせること(オストロムが研究した古典的な集合行為問題)。
  • ガバナンスの乗っ取り: 一つの大きな、あるいは資源の豊富なメンバーが、静かに協働を自分の私的な優位性に向けて操り、中立性を空洞化すること。
  • ずれたインセンティブ: 当事者が両立しない目標で加わり、それがコミットメントの後に初めて表面化して、取り組みを停滞させること。
  • 中立の拠点がない: 共有の資産が一つの参加者に握られ、のちにフォーク、再ライセンス、撤回されうること。
  • 曖昧なIPの条件: 所有、ライセンス、特許の権利が決着する前に築き始め、のちの紛争を保証すること。
  • 独占禁止への盲目: 「協働」の名のもとに、競合が商業的に機微な情報を共有すること。
  • 協働の劇場: 会合して公表するが決して出荷せず、予算と善意を消費するコンソーシアム。
  • 境界の混乱: 組織間の仕事を社内の仕事のように扱い、存在しない指揮の権限を想定すること。

成熟度モデル

  • レベル1、開始。 協働は機会主義的で人柄に駆動され、握手で統治され、書かれたIP、データ、ガバナンスの条件がありません。ライバルは共有の依存関係で、非公式な善意だけで協力します。重要な人が去る、あるいは紛争が起こるまでは機能し、それから崩壊します。
  • レベル2、発展。 一部の協働が、定義された範囲と決定権を伴う明示的な合意(ライセンス、CLAあるいはDCO、データ共有の合意)に裏づけられますが、実践はチーム間で一貫していません。あるグループは共有の資産を中立の拠点に帰属させ、別のグループはなお握手に頼り、ガバナンスは、あるとしても二者間で重いものです。
  • レベル3、標準化。 協働の仕方を統べる文書化された組織全体のモデルがあります。共有の資産は、公表されたガバナンス、ロードマップ、実力に基づく決定権を伴う中立の拠点(財団あるいは中央機関)に置かれ、ライセンス、IP、データ共有、独占禁止の条件の標準のチェックリストが、共同作業が始まる前に要求され、相互運用性はオープン標準(3.8章)に拠ります。ルールは、各チームの裁量に任されるのではなく、一貫して徹底されます。
  • レベル4、管理。 協働のポートフォリオが、ベースラインに対して測定され制御されます。各メンバーシップのコストと職員の時間、すべての共有プロジェクトの貢献対利益、私的な構築に対して回避されたコスト、減ったロックインを追跡し、一つのメンバーのコミットの割合、理事会の席、メンテナーの役割のようなガバナンスの乗っ取りの先行指標を見張ります。打ち切りや更新の閾値が事前に設定されるので、停滞したコンソーシアムや純粋な受益者の関係は、感傷で擁護されるのではなく、証拠で捉えられます。
  • レベル5、オーケストレーション。 協働は、組織全体に統合された、継続的に改善される戦略的能力です。標準や財団を消費するだけでなく形づくり、健全な共有地を維持し、市場とリスクの状況が移るにつれてコーペティションと出口を再均衡させ、追跡する指標に応じてガバナンスを適応させます。組織間の仕事は中核的な能力です。切り離されたプロジェクトの集まりではなく、繁栄するガブテックあるいは業界のエコシステム。

議論のためのアイデア

  • あなたの技術のうち、どの部分が本物の競争上あるいは主権上の優位性で、どの部分が構築のコストを分かち合うべきコモディティの基盤ですか。
  • 支配的なメンバーが静かに協働を自分の目的に向けて操る前に、ガバナンスの乗っ取りをどう早期に検知しますか。
  • 共同プロジェクトにエンジニアリングの労力を貢献する前に、最低限どんな書面の合意(IP、データ、決定権)を要求しますか。
  • 機関横断のデータ共有の取り組みで、停滞させずに、デリバリーの目標とプライバシーおよびデータ保護法(4.5章)の両方をどう満たしますか。
  • 主要な貢献者が共有プラットフォームを去ると脅したとき、ガバナンスは協働が崩壊したり乗っ取られたりせずに生き延びるようにするには、どうしますか。
  • 健全なコーペティションと独占禁止のリスクの線はどこにあり、組織の中でそれを判断する資格があるのは誰ですか。

要点

  • 組織間協働は、共有の権限を持たない独立した組織による共同作業で、ガバナンス、契約、信頼を通じて勝ち取られ、命じられるものではありません。
  • コンソーシアム、財団、標準化団体、合弁事業、PPP、共有プラットフォーム、データ共有の取り決め、コーペティションのうち、形を目標に合わせて意図して選びます。
  • 中立のガバナンス、明確な決定権、明示的な貢献とIPの条件が、競合を含む独立した当事者が安全に協働できるようにするものです。
  • 相互運用性とオープン標準(3.8章)が技術的な基盤です。それがなければ、協働は脆くロックインを招きやすい統合へと朽ちます。
  • 特に競合が協力するときは、データ共有、プライバシー(4.5章)、独占禁止について慎重に契約します。
  • 失敗の様式(フリーライド、ガバナンスの乗っ取り、ずれたインセンティブ)に注意し、それらに耐えるガバナンスと出口の権利を設計します。
  • 企業と政府のどちらも、共通の基盤でコストを分かち合い、優位性と主権が本当に住む所のために制御を取っておきます(10.11章)。

参考文献とさらなる読み物

  • Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action (1990): the foundational study of how shared resources are sustained without central authority.
  • Henry Chesbrough, Open Innovation: The New Imperative for Creating and Profiting from Technology (2003): collaboration across organizational boundaries as a source of innovation.
  • The Apache Software Foundation: governance model, “The Apache Way,” and meritocratic decision-making (apache.org).
  • The Linux Foundation: neutral hosting and governance for large-scale open-source collaboration (linuxfoundation.org).
  • Karim Lakhani and others, writing on open-source and community-based innovation; and Adam Brandenburger and Barry Nalebuff, Co-opetition (1996): the strategy of cooperating and competing at once.
  • OpenSSF (Open Source Security Foundation) and the OpenChain standard (ISO/IEC 5230): cross-organisation approaches to supply-chain and licence compliance.
  • Government digital service and GovTech literature on shared platforms and inter-agency data sharing (for example, national digital-service and open-standards guidance).