発注側と受注側が混在するスクラムチームで、違和感をどう乗り越えるか？

実践者の問い（pq-17）。取り込み済みの文献のうち 7 本から拾った 15 件の事例と知見にもとづく。ここに無い打ち手が存在しないという意味ではない。

結論（TL;DR）

発注側と受注側が 1 つのスクラムチームに混ざったときの違和感を、進め方を変えて乗り越えた結果を比べた文献は、今回読んだ範囲では見つかっていません。拾えたのは、大規模な開発プログラムや行政・自動車・通信機器の事例、質問紙調査などで、いずれも混成チームの運営のしかたを変えて結果を追ったものではありません。

最も具体的なのは、ノルウェーの年金基金が約 4 年かけて進めた大規模な刷新プログラム（約 175 人、うち 100 人が 5 社の外部のコンサルタント）の事例です。発注側と外部の会社 2 社のチームで、要件を事前にどこまで詳しく書くかの好みが違い、一方は詳細な事前の仕様を好み、もう一方は緩い仕様と作りながらの協働を好んだと語られています。誰にでも聞ける状態で働くうちに、発注側の業務担当者と構築側の境界が曖昧になり、受注側が発注側の要件に疑問を出す場面が生まれました。ある技術アーキテクトは、一緒に解決策を見つけられると述べています。ただし、受け入れ基準をどの段階で決めるかについて回答者の意見が揃わない、記述が曖昧で差し戻されるといった代償も記されています。発注側の担当者 30 人をフルタイムで構築チームと同じ階に置いた工夫もありました。契約の形に触れた記述もあり、難しい作業や変更の多い作業は、しばしば契約の縛りが少ない発注側のチームに回され、試作の資源が確保されなかったことが終盤の作り直しにつながったと参加者は見ていました（原因を支払いの仕組みとするのは参加者の説明です）。聞き取りは管理職に偏り、成果を評価する質問は避けられています。

通信機器会社の事例では、外部のコンサルティング会社の拠点の専門家（1 チーム約 10 人）と自社の経験の深い人を混ぜた拠点をまたぐチームが、大きな問題の 1 つに挙げられました。会議の設備が合わず音声だけで参加する人が多く、結束づくりのワークショップにも出向かなかったため、期待したほどは役立ちませんでした。コーチやマネージャーは、そのチームが実のあるチームになっていないと見ていました（拠点の側の人への聞き取りは 1 人だけです）。組織は、5 つの大きな混成チームを、4 つの小さなチームと、必要に応じて割り当てる専門家のプールに組み直しましたが、その結果は書かれていません。

行政の事例では、ドイツの行政で、多くの組織がフリーランスや短期契約の開発者に頼ると語られ、1 つの組織は外部の開発者を常勤と同じに扱いつつスクラムマスターだけは内部の職員にしていました（結果は書かれておらず、短期契約は知識の引き継ぎを妨げうると論文は述べています）。局面で従来型と使い分ける組織もあり、例として調達の段階では従来型が適すると見なされていました。政府のフェローシップでは、民間から来たフェローと公務員の組で、フェローが即座の変化を期待する一方、公務員は本来の業務を離れる自由が無く、日々の運営がずれたと報告されています。自動車の供給元 2 社と完成車メーカーの共同開発では、誰が進めるのか、責任がどこにあるのかが曖昧になり、意思決定が遅くなりました。

質問紙調査（ポーランドの ICT 案件、回答 288 件、受注側が 85%）では、「契約交渉より顧客との協働」の平均がアジャイルの 9 つの要素で最も低く、この項目は 8 つの成功の指標のすべてと正の相関がありました。ただし自己申告の相関で、因果は示されていません。受注側の事業部門の診断では、契約の形のために修正が無償になりやすく、品質の問題を悪くしうると見られましたが、根拠は聞き取りだけです。

どれも、発注側と受注側が 1 つのスクラムチームに混ざる場面で、違和感を乗り越える進め方を比べた記録ではありません。契約の種類ごとの違いを分けて追ったものも、見つかっていません。

打ち手と事例

車載ソフトウェアで、2 社の供給元と完成車メーカーが共同で開発するプロジェクトでは、誰が進めるのかと責任の所在が曖昧になり、意思決定と変化への対応が遅くなった ［The interrelationship between the agile approach and project…（2026）］

• 状況: 自動車業界の製品開発プロジェクト（事例 B）。小さな供給元（約 100 人）と大きな多国籍の供給元（10 万人超）の 2 社が、中間のソフトウェアを共同で開発し、完成車メーカー（OEM）が作る画面などと統合する。 2 社とも、チームの単位ではアジャイルを使い、バックログとプロダクトオーナーを置いている。小さな供給元は、大きな供給元と顧客である OEM に自分のやり方を合わせている。関わる人は、このプロジェクト専任ではない。
• やったこと: PI 計画などのアジャイルの手法で、組織間の足並みをそろえる労力を増やしていた。小さな供給元は、大きな供給元と OEM に自分のプロセスを合わせ、その足並みは日々の調整と、一緒に働いた経歴に支えられていた。
• 起きたこと: 複数の組織が同じコードを同時に触るため、やり取りの形が複雑になり、関わる人や管理者が増え、不具合の対応を誰がするのかを見分けにくくなった。この複雑さが意思決定を遅くし、変化への反応が鈍くなったと報告されている。インタビューを受けた人は、以前は自社と OEM の 2 者だけで簡単だったが、いまは 3 つの組織の複数のチームがいて、誰が進めるのか、誰の責任かが分かりにくく、他へ回しやすくなったと語った。この曖昧さを解く対策と、その結果は書かれていない（結果の記述なし）。
• 注意点: 受注側どうしと発注側（OEM）の組織間の調整の話で、1 つのスクラムチームの中の混在とは違う。インタビューにもとづく 1 事例で、遅れや責任の曖昧さの程度は測られていない。論文は、この複雑さがアジャイルの適用を妨げる面があるとも述べている。
• 根拠: 事例研究／複数チーム。文献: The interrelationship between the agile approach and project complexity in product development（2026）。文献の種類: 論文・研究者。位置: 6.6 The agile approach and interorganizational complexity。確認の根拠: 原典
• 原文: “This complexity slowed down decision-making and, thus, the responsiveness to change”

政府のイノベーションフェローシップで、民間から来たフェローと公務員が組になって働くと、フェローが即座の変化を期待し、公務員は本来の業務を離れる自由が無く、日々の運営がずれた ［Resolving Agile Ambidexterity（2026）］

• 状況: ヨーロッパのある国の連邦政府が行った、6 か月のイノベーションフェローシップ（民間の新興企業・非営利組織・独立したコンサルティング会社の人が、官庁の案件に加わる）。フェローと公務員が組（タンデム）になり、フェローが持ち込んだアジャイルの手法を官庁の仕事に使った。調査は、公務員・フェロー・事業の責任者・外部の関係者など計 168 人へのインタビューにもとづく（内訳の数字は原文の本文と表で食い違う）。
• やったこと: フェローと公務員の組は、アジャイルの手法を官庁の日常に取り入れようとした。 1 組の例では、毎朝の短い会議（デイリー）を設けたが、議会からの即時の回答の依頼が入って妨げられた。フェローは、誰でも出られる金曜のワークショップも開いた。
• 起きたこと: チームの規範（受け入れられる振る舞いの基準）が大きくずれた。論文は、その背景を、フェローの即時の変化への期待と、公務員が本来の業務（ライン業務）を離れる自由を与えられていないことだと書いている。ずれが解けなかった組は、アジャイルを「本来の業務に上乗せされた仕事」と受け取り、上位の支援と管理職の認識が足りないことが、拒否につながったらしいと、公務員自身が述べている。一方、解けた組もあり、そこでは公務員にもともと変化への動機があり、上司の支持も強かったと書かれている。
• 注意点: フェローは民間から来た人で、契約の形（請負か、派遣か、その他か）は、この記述からは分からない。発注側と受注側が 1 つのチームに混在する場面と同じとは言えない。論文は 1 つの国の連邦政府のフェローシップ 1 件で、著者自身が特殊な事例だと書いている。ずれを解いた組が何をしたかは、本来の業務との効率の違いを示した、上位に進捗を発表したなど、抽象的にしか書かれていない。
• 根拠: 事例研究／複数チーム。文献: Resolving Agile Ambidexterity: Between Ambivalence, Adaptation, and Accommodation（2026）。文献の種類: 論文・研究者。位置: 4.2 Pathway 1: Ambivalence and/or Rejection Based on Continued Tension Between Agile and Administrative Routines。確認の根拠: 原典
• 原文: “which had to do with both the expectations of the fellows for immediate change and the lack of freedom given to the civil servants to abandon their line tasks”

ドイツの行政でアジャイルを方法論として使う組織の多くはフリーランスや短期契約に頼る。事例 R は、外部の開発者を常勤と同じに扱いつつ、スクラムマスターだけは内部の職員にしていた ［Adopting agile in government（2024）］

• 状況: ドイツの公的機関 19 か所の比較事例研究のうち、アジャイルを方法論として使う型（7 か所）。民間企業のほうが給与が高く、アジャイルの技能を持つ人を採用しにくい。行政は採用の過程を自分で決められないことがあり、人事部門がアジャイルの価値を理解しにくいことも挙がった。その結果、この型の多くの組織が、フリーランスや短期契約に頼っている。
• やったこと: インタビューを受けた 1 人（事例 R）は、中規模の会社と「コンサルティングの日数」の契約を結ぶやり方を「ボディリース」と呼んだ。来る人は実際にはソフトウェア開発者で、常勤の職員と同じ扱いにしている。ただしチームを率いるスクラムマスターは、内部の職員にしなければならないと話した。
• 起きたこと: この運用の結果（チームの成果や摩擦）は、論文には書かれていない（結果の記述なし）。論文は一般論として、短期契約は組織の文化や手続きになじみの少ないフリーランスを入れるため、プロジェクトの中での知識の引き継ぎを妨げうると述べている。
• 注意点: 運用の説明は、導入を進める立場の 1 人の証言である。論文自身が、インタビューを受けたのは導入に深く関わった人で、見方が理想化されている可能性を限界に挙げている。知識の引き継ぎが妨げられるという点は、論文の見立てで、この事例で測ったものではない。対象はドイツの公的機関で、公務員法や調達の規則の強い環境である。
• 根拠: 事例研究／大規模な組織。文献: Adopting agile in government: a comparative case study（2024）。文献の種類: 論文・研究者。位置: Results — Addressing the challenges。確認の根拠: 原典
• 原文: “However, the Scrum master, who leads the team, has to be an internal employee.”

ドイツの行政で、スクラムを使う 2 つの組織は、プロジェクトの局面で従来型と使い分けた。局面の例として、調達の段階では従来型が適すると見なされた ［Adopting agile in government（2024）］

• 状況: ドイツの公的機関 19 か所の比較事例研究のうち、アジャイルを方法論として使う型（7 か所）の 2 組織。プロジェクトの進み方の中に、調達の段階があった。
• やったこと: プロジェクトの局面によって、従来型のプロジェクト管理とアジャイルなプロジェクト管理（Scrum）を切り替えた。局面の例として、調達の段階では従来型のほうが合うと見なされた（誰の判断かは書かれていない）。
• 起きたこと: 2 つの組織で、アジャイルの程度が局面によって上下した。調達の段階で従来型を使うことの効果や、切り替えの難しさは、論文には書かれていない（結果の記述なし）。
• 注意点: 調達の段階が従来型に向くという記述は「例えば」を添えた 1 文で、2 組織の両方がそうしたかは断定できない。調達の仕組み（契約の種類、事業者の選び方）や、事業者が決まったあとの運営は書かれていない。導入を進める立場の人の証言にもとづく。対象はドイツの公的機関で、調達の法令が強く働く環境である。
• 根拠: 事例研究／大規模な組織。文献: Adopting agile in government: a comparative case study（2024）。文献の種類: 論文・研究者。位置: Results — Agile as methodology。確認の根拠: 原典
• 原文: “During the procurement phase, for instance, traditional project management was deemed more suitable than agile project management.”

外部のコンサルティング会社の専門家を混ぜた大きなチームを、少人数のチームと、必要に応じて割り当てる専門家の「プール」に組み直した ［Large-scale agile transformation at Ericsson（2018）］

• 状況: 大手通信機器会社（Ericsson）の開発組織。第三者のコンポーネントの専門家を出す外部のコンサルティング会社（拠点 E）の人を、自社の経験の深い人と混ぜて、国をまたぐ 5 つの大きなチームを作った（拠点 E から 1 チーム約 10 人）。
• やったこと: 機能によって必要なコンポーネントの知識が違うため、5 つの大きなチームを、7〜9 人の中核メンバーによる 4 つの小さなチームに組み直した。残りの拠点 E の人は専門家の「プール」にし、次の機能に必要な知識に合わせて、チームへ割り当てた。コンサルタントは専門分野が狭く、離職率が高いため、他のコンポーネントへ知識を広げさせるのは費用に合わないと組織は判断した。
• 起きたこと: 5 つの大きなチームが、4 つの小さなチーム（中核は 7〜9 人）と専門家のプールに組み直された。プールの運用の結果（待ち時間や知識の分断など）は、論文には書かれていない（結果の記述なし）。
• 注意点: 組織の判断の記述で、組み直しの効果は測られていない。拠点 E の側の事情や受け止めは、この記述からは分からない。外部の会社の専門家を「必要なときに割り当てる資源」として扱うことが、チームの一体感に与える影響は、論文の別の節（4.3.6・4.3.7）で挙がっている問題と合わせて読む必要がある。
• 根拠: 事例研究／大規模な組織。文献: Large-scale agile transformation at Ericsson: a case study（2018）。文献の種類: 論文・研究者。位置: 4.2.2 Phase 1: Introducing Agile (Competence Pool)。確認の根拠: 原典
• 原文: “consultants had quite narrow focus areas, and the case organization did not see having them broaden their knowledge on other components as cost-efficient due to high attrition rate at the consultant company”

外部のコンサルティング会社の拠点の人と自社の人が混ざった拠点をまたぐチームは、ワークショップに出向かなかったため、結束づくりに十分役立たなかった。会議の設備も互換が無かった ［Large-scale agile transformation at Ericsson（2018）］

• 状況: 大手通信機器会社（Ericsson）の、5 つの拠点・3 か国に分かれた開発組織（買収した製品の開発を引き継いだもの）。拠点 E は外部のコンサルティング会社（子会社ではない委託先）で、第三者のコンポーネントの専門家を出していた。拠点 C・D の経験の深いアーキテクトや技術コーチと、拠点 E の人（1 チーム約 10 人）が混ざった拠点をまたぐチームが作られた。
• やったこと: 拠点 E から、現場の様子を伝える「訪問エンジニア」が拠点 A・D のチームに常駐した。信頼を高め、顔を合わせて連絡のしきいを下げるために、価値ワークショップを開いた。自社の拠点には高品質のビデオ会議設備があったが、拠点 E は互換のある設備が無く、音声のみで参加することが多かった。拠点 E の人は、現地で働いていた一部の人を除き、ワークショップに出向かなかった。
• 起きたこと: 論文は、結びつきの強くなかった組織の人がいる拠点をまたぐチームを、この事例の大きな問題の 1 つに挙げ、多くの回答者が言及したと書いている。ワークショップは、拠点 E の人が出なかったため、チームの結束づくりに期待したほどは役立たなかった。回答者の多くは、拠点をまたぐチーム全般について、もっと出張や交換訪問をして一緒に働くべきだと述べた。
• 注意点: 拠点 E の人へのインタビューは 1 人（拠点 D に一時的にいた代表者）だけで、拠点 E の見方は、ほかの拠点の人の説明から得ている。拠点 E は外部の拠点で、改革の対象に入れられておらず、近く外す計画もあった。距離・時差・文化の違いと、委託先であることの影響は、この記述では分けられていない。ビデオ会議設備の違いは、自社の拠点どうしと拠点 E のあいだの比較であり、効果は測られていない。
• 根拠: 事例研究／大規模な組織。文献: Large-scale agile transformation at Ericsson: a case study（2018）。文献の種類: 論文・研究者。位置: 4.3.6 Cross-Site Teams。確認の根拠: 原典
• 原文: “The use of cross-site teams with members from organizations that had not been tightly integrated before arose as one of the major problems in the case project.”

外部のコンサルティング会社の拠点にまたがるチームは、経験の深い人が班長役になり、残りは個別の作業をする形で、実のあるアジャイルのチームになっていないと見られた ［Large-scale agile transformation at Ericsson（2018）］

• 状況: 大手通信機器会社（Ericsson）の、5 つの拠点に分かれた開発組織。欧州の拠点 C・D の経験の深い人（サブシステムの責任者、アーキテクト、技術コーチ）と、アジアの外部のコンサルティング会社の拠点 E の残りの人でできたチームがあった。研究の時点では、技術コーチがチームリーダーの役割を担い、ほかのメンバーは個別の作業をしていた。
• やったこと: 拠点 E のチーム固有の対策は、論文には書かれていない（拠点をまたぐチーム全般には、ペアリングや拠点間の交換の取り組みがある）。
• 起きたこと: コーチやラインマネージャーは、そのチームが「実のあるチーム」になっていないと見ていた。論文の観察では、実のあるアジャイルのチームになるまでに長い道のりがありそうだった。拠点間の文化の違いも大きかったと書かれている。この問題は、拠点 E と働くコーチとラインマネージャーが特に挙げたものである。論文は、組織が拠点 E を外してもプロジェクトを成功させる方法を実際に計画していたことを、この問題の大きさの証拠として挙げている。
• 注意点: 拠点 E のチームメンバーには聞いておらず（代表者 1 人のみ）、問題の見立ては欧州側のコーチやマネージャーのもの。論文自身がそう書いている。「実のあるチームでない」程度は測られていない。委託契約の形や、拠点 E の側の事情は、この記述からは分からない。
• 根拠: 事例研究／大規模な組織。文献: Large-scale agile transformation at Ericsson: a case study（2018）。文献の種類: 論文・研究者。位置: 4.3.7 Working as “A Real Team”。確認の根拠: 原典
• 原文: “These teams seemed to have a long way to go before turning into real agile teams.”

いつでも誰にでも聞ける状態で働いた結果、発注側の業務担当者と受注側の構築チームの境界が曖昧になり、受注側が発注側の要件に疑問を出す場面が生まれた。ある技術アーキテクトは、一緒に解決策を見つけられると述べた ［Exploring software development at the very large-scale（2017）］

• 状況: ノルウェーの公的機関（年金基金）の大規模な基幹システム刷新プログラム（Perform）。発注側の業務担当者が高いレベルの要件を作り、受注側を含む構築チームが解決策を詳しくして作る、という段階の分け方だった。
• やったこと: 発注側の担当者は、確かめたいことがあれば構築チームに話しかけることができた。構築チームの側も、「答えを知っていそうな人には誰にでも聞ける」状態だった。その結果、高いレベルの要件・解決策の記述・構築の境界が次第に曖昧になった。
• 起きたこと: 著者は、この曖昧さが協働をより効率的にしたと書いている。ある技術アーキテクトは、受注側が文脈を理解するほど発注側の本当の課題が見え、一緒に解決策を見つけられる、と語った。解決策の記述にあたる人が、上流の要件のアウトプットに疑問を出せるようにもなり、「こうしたらどうか、なぜこうするのか」と受注側が発注側に問い返す場面があった。関わった人は、この進め方が創造性を刺激したと感じていた。一方で、受け入れ基準を決める段階が、解決策の記述の段階なのか構築中なのかで、回答者の意見が一致しなかった。解決策の記述が曖昧すぎて構築に使えず、差し戻されたこともあった。
• 注意点: 著者の記述と参加者の発言にもとづき、協働が効率的になった程度は測られていない。管理側の役職の人に偏ったインタビューである。境界の曖昧さには、受け入れ基準の持ち主が決まらない、記述が曖昧で差し戻される、という代償も記されている。契約の形（時間と材料、目標価格）ごとに様子が違ったかは分けて書かれていない。
• 根拠: 事例研究／大規模な組織。文献: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation（2017）。文献の種類: 論文・研究者。位置: 4.2.3 Blurred Boundaries between Phases。確認の根拠: 原典
• 原文: “As the contractor starts to understand more about the context, the customer’s real problem is more visible, and this means we can find a solution together.”

発注側の担当者 30 人をフルタイムで構築チームと同じ事務所の階に置くことで、必要なときに話せる状態を保った ［Exploring software development at the very large-scale（2017）］

• 状況: ノルウェーの公的機関（年金基金）の大規模な基幹システム刷新プログラム（Perform）。約 175 人のうち 100 人が 5 社の外部のコンサルタントだった。大規模なので、発注側の担当者を多数そろえ、全チームが相談できる状態にする必要があった。
• やったこと: 発注側（年金基金）から、ピーク期にプロダクトオーナーや業務担当者 30 人をフルタイムで参加させ、「業務」プロジェクトとして要件とユーザーストーリーの優先順位付けを担わせた。この担当者を、構築チームと同じ事務所の同じ階に置いた。 2009 年からは、全チームとプロジェクト管理も 1 つの開放的なフロアに集めた。
• 起きたこと: 著者は、同じ事務所に置いたことで発注側の担当者がいつでも相談できる状態になったと述べている。発注側の担当者どうしの足並みと、発注側と構築側の足並みは、複数の場、連続的な解決策の記述、境界の曖昧さの 3 つに支えられたと整理している。開放的なフロアは、調整と知識の共有を効率的にしたと多くの人が語った。一方で、大きな声の議論を避けるためにイヤホンを使い始めた人もいた。足並みがどれだけ揃ったかは、測定されていない。
• 注意点: 参加者の受け止めと著者の考察で、足並みや待ち時間の測定値は無い。発注側 30 人は、ピーク期（2009〜2011 年）の人数で、最終予算が約 1.4 億ユーロの巨大なプログラムの話である。常駐できた理由は書かれておらず、小さなチームにそのまま持ち込める規模ではない。常駐した担当者と受注側のあいだの摩擦は、この記述からは分からない。
• 根拠: 事例研究／大規模な組織。文献: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation（2017）。文献の種類: 論文・研究者。位置: 5.1 Customer Involvement。確認の根拠: 原典
• 原文: “Locating them in the same office space as the construction teams ensured their availability.”

難しい作業や変更の多い作業は、しばしば、契約の縛りが少なく業務知識も多い発注側のチームに回された ［Exploring software development at the very large-scale（2017）］

• 状況: ノルウェーの公的機関（年金基金）の大規模な基幹システム刷新プログラム（Perform）。構築チームは、発注側の年金基金が率いるチームと、外部のコンサルティング会社 2 社が率いるチームに分かれていた。外部の会社には、時間と材料の契約や目標価格の契約が使われていた。
• やったこと: どのチームにどの作業を渡すかを、実際的に決めていた。変更が多い作業、複雑なモジュール、設計の見通しが立たない作業は、しばしば発注側のチームに渡された。
• 起きたこと: 機能アーキテクトは、発注側のチームが予算や契約の制約を（外部の会社ほど）受けず、より柔軟だったと語った。発注側のチームには業務知識も多かった。この割り振りが全体の成果にどう響いたかは書かれていない（結果の記述なし）。
• 注意点: 著者の記述と、機能アーキテクトの発言に基づく。割り振りの基準が文書化されていたかは、この記述からは分からない。外部の会社のチームが、難しい作業を渡されないことの影響（学習の機会など）は、この記述からは分からない。対象は大規模なプログラムで、契約の仕組みは国や案件によって違う。
• 根拠: 事例研究／大規模な組織。文献: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation（2017）。文献の種類: 論文・研究者。位置: 4.2.3 Blurred Boundaries between Phases。確認の根拠: 原典
• 原文: “the most challenging tasks were given to the Pension Fund feature teams because they had more domain knowledge and a more flexible contract model”

支払いの仕組みの都合で、捨てるかもしれない試作の資源が確保されず、新しい技術の見極めが遅れて、終盤に作り直しが出たと、参加者は見ていた ［Exploring software development at the very large-scale（2017）］

• 状況: ノルウェーの公的機関（年金基金）の大規模な基幹システム刷新プログラム（Perform）。画面の層に Flex という技術を使ったが、十分に理解されないまま使われ、効果的なアプリケーション構造の指針を作れなかった。外部の会社には、時間と材料の契約や目標価格の契約が使われていた。
• やったこと: 新しい技術を採る前の試作（proof of concept）を増やしたいという声があった。試作の資源は確保されなかった。終盤には、画面の層の性能を直すために多くの作業をし、永続化の層も大きく直した。この直しは、非機能要件のユーザーストーリーとしてまとめた。
• 起きたこと: サブプロジェクトマネージャーは、試作が無かったのは支払いの仕組みとプログラムの進め方のためだと述べた。捨てるかもしれない試作や、複数の案を作る試行のための資源が割り当てられなかった、という説明である。終盤には、画面の層の性能を直す作業が大きくなり、アーキテクチャ側の作り直しも生じた。契約の形を変えたら試作ができたかは、書かれていない。
• 注意点: 試作が無かった原因を支払いの仕組みとするのは、回答者の説明（フィードバックの場でのサブプロジェクトマネージャーの発言で、「一部は」と限定されている）で、論文が検証したものではない。スケジュールの厳しさや、機能を優先する圧力も同じ論文の別の箇所で挙がっており、原因は 1 つに絞れない。契約が発注側と受注側のどちらの制約だったか、詳しくは書かれていない。
• 根拠: 事例研究／大規模な組織。文献: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation（2017）。文献の種類: 論文・研究者。位置: 4.3.1 Up-Front Architecture。確認の根拠: 原典
• 原文: “the lack of proof of concepts was due to the contract model”

発注側の組織と外部のコンサルティング会社 2 社が同じプログラムで開発したところ、要件をどこまで事前に詳しく書くかの好みが会社ごとに違った ［Exploring software development at the very large-scale（2017）］

• 状況: ノルウェーの公的機関（年金基金）が 2008 年から約 4 年かけて進めた大規模な事務自動化システムの刷新プログラム（Perform）。開発は 3 つのサブプロジェクトに分かれ、発注側の年金基金が自分の人員と 5 社のコンサルティング会社の人員でチームを率い、残りの 2 つは外部のコンサルティング会社 2 社（Accenture と Steria）がそれぞれチームを率いた。各チームは Scrum で 3 週間のイテレーションを回した。発注側の業務担当者が作る要件と、構築チームが書く「解決策の記述」（画面・エラー処理・データモデルなどの詳細）の受け渡しが、リリースごとに連続して行われていた。
• やったこと: 解決策の記述は、構築に加わる人と発注側の業務に詳しい人が一緒にチームを作って書いた。会社ごとの好みの違いをそろえるために行った対策は、論文には書かれていない。
• 起きたこと: 解決策の記述を、1〜3 イテレーション分だけ先に用意して次の構築チームへ流し続ける中で、緊張が生じたと報告されている。その中で、事前の計画への好みの違いが会社ごとに目立った。 Accenture はより詳細な事前の仕様を好み、手戻りを減らしたい意図があった。機能アーキテクトは、Accenture の側として、発注側を「ある程度しつけ」て、引き受ける作業に入れる前に何がほしいかをはっきりさせてもらう必要があった、と語っている。 Steria はもっと緩い仕様と、作りながらの継続的な協働で細部を詰めることに慣れていた。発注側の年金基金は、その中間だった。この違いをどう解いたか、その後の結果は書かれていない（結果の記述なし）。
• 注意点: プログラムの終了後に、プロジェクト管理・アーキテクト・Scrum マスターなどの人へ行ったグループインタビューと文書に基づく記述で、管理職の人に偏る可能性（elite bias）を著者が挙げている。 Accenture の参加者は他の 2 組より少なく、意見の幅が狭い可能性も著者が挙げている。著者は、プログラムの成果を評価する質問はあえて避けたと書いている。好みの違いが成果にどう響いたかは分からない。対象は 175 人が関わった巨大なプログラムで、1 つのスクラムチームの中の発注側と受注側の混在とは規模が違う。
• 根拠: 事例研究／大規模な組織。文献: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation（2017）。文献の種類: 論文・研究者。位置: 4.2.2 A Continuous and Iterative Process。確認の根拠: 原典
• 原文: “There were noticeable differences between the three suppliers Accenture, Steria, and the Pension Fund in terms of preferences for up-front planning.”

B2B のソフトウェア事業部門で、契約の形のために修正が無償になりやすく、品質の問題を悪くしうると見られた。ただし根拠は聞き取りだけである ［Quality culture boosts agile transformation—Action research…（2022）］

• 状況: 金融向けのソフトウェアを作る B2B の事業部門。保守契約、ライセンス契約、時間単価の契約（上限付きのものもある）、SaaS が並行して使われ、顧客に特定の人を「容量」として提供する契約もあった。聞き取りで、プロセスと製品の品質の両方が問題だと挙がった。
• やったこと: 診断の段階で、契約の形が品質の問題にどう響くかを考えた。契約の形そのものを変える対策は、この記述には出てこない。
• 起きたこと: 結果の記述なし。 契約の形のために修正が無償になることが多く、品質の問題を悪くしうる、と診断で書かれた。一貫したプロジェクトの報告データが無く、この点を数えて確かめることはできなかった。根拠は聞き取りだけである。
• 注意点: 著者が診断で述べた見立てで、検証されていない。論文自身が、簡単には数量化できず、証拠は聞き取りだけだと書いている。時間単価や容量の契約が、品質や受注側の動き方にどう響くかは、この記述からは分からない。発注側と受注側がチームに混在する場面ではなく、受注側の事業部門の内部の診断である。
• 根拠: アクションリサーチ／大規模な組織。文献: Quality culture boosts agile transformation—Action research in a business-to-business software business（2022）。文献の種類: 論文・研究者。位置: 3.7 Diagnosis (Intervention 2)。確認の根拠: 原典
• 原文: “The contract structure (ref. revenue stream analysis in case description) can worsen the situation with quality problems, as the fixes are often free.”

前提に反する事例

今回読んだ範囲では、見つかっていない。

調査から分かっていること

同じ調査で、「契約交渉より顧客との協働」は、納期・予算・機能・顧客満足など 8 つの成功の指標のすべてと、正の相関があった。因果は示されていない ［The Impact of Identified Agility Components on Project…（2023）］

• 状況: ポーランドに拠点を置く ICT 業界を中心にした企業の、プロジェクトの管理者などへの質問紙調査（有効な回答 288 件、受注側 85%・発注側 15%）。アジャイルの要素の当てはまり具合と、プロジェクトの成功の指標（納期・予算・機能・顧客満足・チームの満足・利用者への便益・会社への便益・戦略目標）の自己評価を、同じ回答者から集めた。
• やったこと: 介入ではなく、アジャイルの要素と成功の指標のあいだの相関（Spearman の順位相関）を調べた。
• 起きたこと: 「契約交渉より顧客との協働」と、8 つの成功の指標とのあいだの相関係数は 0.548〜0.655 だった（すべて p < 0.001）。最も高かったのは予算（0.655）、最も低かったのは戦略目標の達成（0.548）である。著者は、人と対話・顧客との協働・反復的な納品・関係者との良好な関係の 4 つが、成功の指標のすべてと強い相関（0.5 超）を示したとまとめている。
• 注意点: 相関であり、顧客との協働が成功の原因だとは示されていない。著者自身が、変数どうしが互いに影響しうること、プロジェクトの後からの観察であること（成功を予想して管理の仕方を変えた可能性）を限界に挙げている。成功の指標も自己評価である。著者が 0.5 超とした要素の列挙は、表の値（ほかの要素にも 0.5 超がある）と一致しない。受注側の回答が 85% を占め、発注側と受注側を分けた結果は示されていない。 ICT 業界とポーランドに限られる。
• 根拠: 調査（アンケート）／大規模な組織。文献: The Impact of Identified Agility Components on Project Success—ICT Industry Perspective（2023）。文献の種類: 論文・研究者。位置: Discussion of results (Table 7)。確認の根拠: 原典
• 原文: “collaboration with the client prevailing over contract negotiations”

ポーランドの ICT 案件の質問紙調査で、「契約交渉より顧客との協働」は、アジャイルの 9 つの要素のなかで最も平均が低かった ［The Impact of Identified Agility Components on Project…（2023）］

• 状況: ポーランドに拠点を置く ICT 業界を中心にした企業の、プロジェクトの管理者などへの質問紙調査（回収した有効な回答 288 件）。回答者の立場は、受注側（請負・供給側）が 85%、発注側（投資側）が 15% だった。 9 つのアジャイルの要素（人と対話・動くソフトウェア・顧客との協働・変化への対応など）が、実際のプロジェクトでどれだけ当てはまるかを、5 段階で答えてもらった。
• やったこと: 介入ではなく、実態の調査である。
• 起きたこと: 「契約交渉より顧客との協働」の平均は 2.88 で、9 つの要素のなかで最も低かった（ほかの 8 要素は 3.07〜3.30）。著者は、これを信頼の不足と、アジャイルなプロジェクト管理への十分な開放性の不足を裏づけると解釈している。
• 注意点: 自己申告のアンケートで、受注側の回答が 85% を占める。発注側と受注側を分けた集計は示されていない。平均が低いことが、顧客との協働が少ないことなのか、契約を優先する慣行なのかは、この調査からは分からない。「信頼の不足を裏づける」という言い方は、平均値だけから言えることより強い著者の解釈である。サンプルは目的に合わせて選ばれた（purposive sampling）もので、ICT 業界とポーランドに限られる。スクラムチームの中の発注側と受注側の混在を直接調べたものではない。
• 根拠: 調査（アンケート）／大規模な組織。文献: The Impact of Identified Agility Components on Project Success—ICT Industry Perspective（2023）。文献の種類: 論文・研究者。位置: The influence of agility factors on project success — Findings: Analysis of the extent of involvement of individual agile components。確認の根拠: 原典
• 原文: “which confirms the lack of trust and lack of full openness to an agile project management approach”

出典一覧

文献	年	ライセンス	記録の数
Adopting agile in government: a comparative case study	2024	CC BY 4.0	2
The interrelationship between the agile approach and project complexity in product development	2026	CC BY 4.0	1
Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation	2017	CC BY 4.0	5
The Impact of Identified Agility Components on Project Success—ICT Industry Perspective	2023	CC BY 4.0	2
Large-scale agile transformation at Ericsson: a case study	2018	CC BY 4.0	3
Quality culture boosts agile transformation—Action research in a business-to-business software business	2022	CC BY 4.0	1
Resolving Agile Ambidexterity: Between Ambivalence, Adaptation, and Accommodation	2026	CC BY 4.0	1

---

🔍 妥当性検証レポート（クリックして展開）

• 総合判定: ⚠️ 警告あり (スコア: 100/100)
• 評価の前提: 結論（TL;DR）を、このページに載せた事例と知見だけに照らして評価した
• 形式論理検証: FAIL
• LLM批判的評価（agy: gemini-3.8-flash-high）: Faithfulness 5.0/5, Relevance 5.0/5

評価コメント:

• 形式論理警告: 自己管理チームの原則（DevelopersSelfManagement）に反し、外部によるタスク割り当てを認めています
• Faithfulness（5/5）: 前提コンテキストに記載された各事例（ノルウェー年金基金、Ericsson、ドイツ行政、政府フェローシップ、車載ソフトウェア、ポーランドの質問紙調査など）の事実関係のみならず、それぞれの「注意点」に挙げられている調査の限界、エリートバイアス、測定値の欠如、因果関係が示されていない点、結果の記述がない点に至るまで、極めて厳密かつ忠実に要約・反映されています。コンテキスト外の勝手な推測や俗説・捏造は一切含まれていません。 - Relevance（5/5）: 「発注側と受注側が混在するスクラムチームで違和感をどう乗り越えるか」という問いに対し、前提コンテキスト内に直接的な検証結果や解決策が存在しないこと（前提事例の多くが1つのスクラムチーム内の混在ではないこと、あるいは結果が未記載であること）を冒頭と結びで明快に答えています。その上で、コンテキストから読み取れる部分的な試みや代償、関連する示唆を過不足なく提示しており、与えられた前提の下で最も論理的かつ誠実な回答となっています。

---

関連する用語

• スクラムチーム
• プロダクトオーナー
• ステークホルダー
• 顧客