ステークホルダーと、どう関係をつくり、話すのが良いか？ 価値観の合わない相手とは、どう話すか？

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

結論（TL;DR）

ステークホルダーとの関係づくりの打ち手を、条件をそろえて比べ、効果を確かめた文献は、今回読んだ範囲では見つかっていません。読めたのは、公的機関と事業者の実務者が自分たちの経験を書いたブログ 4 本で、いずれも筆者の自己評価です。価値観の合わない相手との関係を、正面から扱った事例はありませんでした。

スプリントレビューへの関与が薄れたときの打ち手が、1 件あります。英国法務省のチームは、完了したストーリーのデモを、予告なしにステークホルダー自身にしてもらいました。付箋を配り、印のある人がデモをすると告げる形で、最も関与していた人と最も薄かった人が当たるように仕組んでいます。筆者は、告げられた時点で出席者がすぐに注意深くなり、関与の薄かった二人とも活発になったと書いています。1 チームの 1 回の試行で、その後のレビューで続いたかは書かれていません。

相手の言葉で話す打ち手もあります。英国教育省の責任者は、デジタルを「分かっていない」と評判の上級のステークホルダーに、「アジャイルである」と言う代わりに、間違いから学んで数週間で直せることの大切さを話しました。筆者は、信頼が増して密に協力でき、サービスの提供の障害が取り除かれたと書いています。相手側の見方は無く、会議の前の一回の工夫の話です。

方向を変える提案は、先に整理してから相談する形が見られました。英国の見習い制度サービスのチームは、当初の前提と違う提案を、関係者へ持ち込む前に、問題と代替案を整理しました。政策側とも連携し、短い資料と試作品で相談しています。筆者は、全員が賛成したと書いています。節約は見込みで、反対や調整の経緯は書かれていません。

顧客との間では、都合の悪い事情も共有する例があります。欧州のマネージドサービス事業者の運用チームは、顧客の開発チームと毎日同期し、人手不足や他の顧客の作業のような、普通は伝えない事情まで話しました。そのうえで、遅れを取り戻すまでの代替案や優先順位を、顧客と一緒に話し合っています。筆者は、チームと経営層にとって一番怖かったのは透明性の水準だったと書いています。顧客の評価は、仕掛かりの制限などを同時に入れた結果への言葉で、同期だけの効果は切り分けられません。

4 件とも、相手は組織の内部の関係者か、取引先の顧客です。意見や価値観が大きく食い違う相手への対応は、この範囲では確かめられていません。メンバー同士の摩擦は別の問い、経営陣への効果の説明は別の問い、スプリントレビューを実りあるものにする進め方は別の問いで扱っています。

打ち手と事例

英国の見習い制度サービスのチームは、関係者の前提と違う提案を、課題と代替案を先に整理した資料で相談し、合意を得たと書いている ［Design trust（2021）］

• 状況: 英国の教育技能資金庁（ESFA）の見習い制度サービスで、雇用主が見習い訓練を探すサービスを担当するスクラムチームの話である。筆者はデザイナーに呼びかける立場の書き手で、チームと関係者は、修了審査の機関をこのサービスに残し、見せ方を分かりやすくする前提で進めていた。当初の構想は、雇用主が訓練機関と審査機関を一つの流れで選ぶことだった。ところが発見のフェーズで、雇用主が審査機関を決めるには早すぎることが分かった。審査機関の選択は、適切な見習い制度と訓練機関の選択の邪魔にもなっていた。このサービスはその決定の場として適切ではないことが明らかになったと、筆者は書いている。
• やったこと: チームは、関係者に相談する前に、問題と代替案、それぞれの利点を探った。解決策を持たずに関係者へ近づくと、道を誤る恐れがあると考えたからである。相談先は、プロジェクトチーム、サービスデザイナー、リーダーシップチーム、審査機関の政策チームだった。政策側とは連携して、必要を理解し、足並みをそろえようとした。議論のために短いスライド資料を作った。内容は、プロジェクトの目的、問題の説明、利用者がその機能を必要とする理由、分離による改善点、試作品、次の手順である。試作品は GOV.UK の試作キットで作り、画面から構成の図も作った。提案は、審査機関を探す作業を独立した別のサービスに切り出すことだった。
• 起きたこと: 筆者は、全員がこの方向に賛成したと書いている。チームは、二つの別のサービスに分けた状態で調査を続けた。筆者は、探すサービスが複雑になるのを防げたと書き、将来に核の部分を直す手間を省ける見込みがあるとも書いている。見込みの部分は、実際に節約できたかを確かめた記述ではない。
• 注意点: 一つのチームの一回の事例である。記事は、Apprenticeship Service に関わるデザイナーである筆者が書いた。冒頭は三人称、後段は一人称で、筆者がそのチームの一員かは明記されていない。成功や節約という評価は筆者の自己評価で、第三者の確認は無い。政策側が反対したかどうか、どんな反論や調整があったかは書かれていない。関係者が価値観の違う相手だったという記述は無い。関係者は、同じ組織の内部の関係者である。外部の相手との関係の事例ではない。記事は、デザイナーが関係者に働きかける姿勢を勧める文脈で書かれている。その勧めの部分は規範で、記録にしない。記事の冒頭の家の改装のたとえと、デザイナー向けの一般的な心構えの節は、拾っていない。
• 根拠: 経験報告／単一チーム。文献: Design trust - why it’s important to influence stakeholders in the right direction（2021）。文献の種類: ブログ・実践者。位置: Case study - where there’s a will there’s a way（The assumptions / The challenge / Where to begin / What we did / The outcome の各節）。保存版: https://web.archive.org/web/20260512192547/https://sfadigital.blog.gov.uk/2021/03/30/design-trust-why-its-important-to-influence-stakeholders-in-the-right-direction/。確認の根拠: 原典

運用チームが顧客の開発チームとの毎日の同期を始め、人手不足や他の顧客の作業のような、普通は伝えない事情まで共有した ［How becoming open and agile led to customer success（2017）］

• 状況: 欧州のマネージドサービス事業者 Basefarm の運用チームは、インフラとマネージドサービスで複数の顧客を支援していた。スウェーデンの大手民放 TV4 には、四人が月の作業時間の一部を充てる契約で、TV4 の変更をステージングや本番へ反映する流れが詰まっていた。顧客の開発チームは、依頼のチケットを出しても何も起きないと感じ、運用チームを自分たちの配信の詰まりと見ていた。運用側のチームは、障害対応と他の顧客の割り込みに追われ、何も終わらないと感じてストレスを抱えていた。筆者はこのチームのサービスマネージャーだった。
• やったこと: チームは顧客の開発チームと毎日の同期を始めた。昨日終えたこと、今日の重点、行く手を阻むものを話した。作業が別の部署で止まっていることを、顧客に正直に伝えた。病気や休暇で人手が足りないことや、しばらく他の顧客の作業に取られることも伝えた。これらは普通は顧客に直接は言わないことで、チームと経営層にとって一番怖かったのは透明性の水準だったと、筆者は書いている。伝えたうえで、遅れを取り戻すまでの代替案や優先順位を、顧客と一緒に話し合った。
• 起きたこと: 筆者は、いつも意見が一致したわけではないが、たいていの場面は扱えて、いちばん大事な作業に集中できたと書いている。新しいやり方を始めた翌週に、顧客のリード開発者の一人から、顧客になってから最高の週だったと電話で伝えられたとも書く（最初の週の稼働は、合意した時間の半分にとどまった）。ただし、この評価は毎日の同期だけでなく、仕事の見える化や仕掛かりの制限など、いくつかの変更を同時に入れた結果への言葉である。毎日の同期だけの効果は切り分けられていない。
• 注意点: 運用側の当事者が自分で書いた自己申告の記事で、顧客の側の見方は筆者を通した伝聞しかない。記事は Opensource.com の Open Organization Workbook の一部として、オープンでアジャイルな進め方を紹介する文脈で書かれた成功談である。顧客の評価は 1 回の電話の伝聞で、測定した結果ではない。毎日の同期は、同じ記事で説明された仕掛かりの制限や割り込みの窓口当番などと並行して行われた（導入の順序や時期は書かれていない）。関係が良くなった理由を同期だけには帰せない。価値観の合わない相手との関係づくりとして書かれた記事ではなく、顧客と運用側の見方のずれが主題である。一つの顧客と一つのチームの話である。記事は、やり方が社内の他チームにも広がったと書くが、その中身や結果は書かれていない。他の顧客や組織に当てはまるかも書かれていない。
• 根拠: 経験報告／単一チーム。文献: How becoming open and agile led to customer success（2017）。文献の種類: ブログ・実践者。位置: 節 Holding daily sync meetings（The scariest part… の段落と、続く These were things you typically never tell customers… の段落）、節 So how did it go?。保存版: https://web.archive.org/web/20260605221033/https://opensource.com/open-organization/17/11/transparency-collaboration-basefarm。確認の根拠: 原典
• 原文: “But by starting to be open about it, we could discuss alternatives or prioritize differently until we could catch up.”

英国法務省のチームは、関心が薄れた関係者に、スプリントレビューでストーリーのデモを自分でやってもらう試みをして、チームは成功と受け止めた ［Getting stakeholders more involved in sprint reviews（2014）］

• 状況: 英国法務省（Ministry of Justice）のデジタル部門で、内部の利用者向けの Web ツールを作るチームの話である。筆者は、このチームと働き始めて間もない立場で書いている。開発は進んでいて、アルファ版の終わりが近づいていた。ふりかえりで、スプリントレビューへの関係者の関与が薄れていることが話題になった。とくに関係者のうち二人は、デモに関心を示さなかったと筆者は書いている。ほかの関係者も質問から内容を追えていないように見え、ツールの利用状況や感想もほとんど返ってこなかった。
• やったこと: 筆者を含む少人数で案を出し合い、まず関係者を責めることはやめて、自分たちに何ができるかを考えることにした。選んだのは、関係者自身にデモをしてもらう案である。完成済みのストーリーのうち、関係者が自分で実演できる簡単なものを選び、事前には知らせなかった。レビューの冒頭で、筆者はレビューをする目的を改めて説明し、付箋を配った。一部の付箋には印があり、印のある人がデモをすると告げた。実際には、最も関与していた関係者と最も関与の薄かった関係者が当たるよう、配り方を仕組んでいた。前半はチームが分析や監視の仕事を見せ、その後に、関与していた関係者から順にデモをしてもらった。
• 起きたこと: 筆者は、付箋が配られて誰かがデモをすると告げられた時点で、出席していた関係者がすぐに注意深くなったと書いている。チームが見せた部分でも、質問や提案が絶えなかったという。関与の高かった関係者は問題なくデモを進め、ほかの関係者から多くの質問を引き出した。関与の薄かった関係者はデモに手間取った。画面に慣れていないことが明らかだったと筆者は書いている。二つ目のデモはチームが手順を案内した。その後、関与の薄かった二人とも（デモをした人を含む）目に見えて活発になり、自分の仕事の進め方や、システムが助けになりそうな点について、よい発言をしたと筆者は書いている。筆者とチームはこの結果を成功と受け止めた。ただし、次のスプリントレビューをどう進めるかへの含意は、まだ分からないと筆者は書いている。
• 注意点: 一つのチームの一回の試行の報告で、効果をレビューの前後で測ったものではない。成功という評価は筆者とチームの自己評価である。関与が戻ったかどうかは、同じレビューの場での様子の観察にとどまり、その後のレビューで続いたかは書かれていない。付箋の配り方を仕組んだ（無作為に見せかけた）のは筆者で、事前に知らせない判断はチームのものである。相手が戸惑う可能性があり、どの関係者にも向く方法とは限らない。筆者自身が、この結果の意味をまだ決めかねていると書いている。コメント欄には、事前に知らせておくとよかったという別の読者の経験もあるが、記録の根拠には使わない。関係者は、同じ組織の内部の利用者という立場である。外部の顧客や、価値観の大きく違う相手との関係の事例ではない。
• 根拠: 経験報告／単一チーム。文献: Getting stakeholders more involved in sprint reviews（2014）。文献の種類: ブログ・実践者。位置: 本文全体（The idea / The execution / The result / So what next? の各節）。保存版: https://web.archive.org/web/20260410162725/https://mojdigital.blog.gov.uk/2014/07/28/getting-stakeholders-more-involved-in-sprint-reviews/。確認の根拠: 原典

英国教育省の教員サービスの責任者は、デジタルを「分かっていない」と評判の上級の関係者に、相手の言葉で話してみて、信頼を得られたと書いている ［What I learnt leading empowered teams at scale in Teacher…（2023）］

• 状況: 英国教育省（DfE）の教員サービスは、省で最大級のデジタルのポートフォリオで、長く続くサービスチームを持つ。筆者はその責任者で、退任にあたり、学んだことを振り返って書いている。筆者は、省の中でチームを守るほど、省の他の部署から切り離され、意思疎通が難しくなり、誤解も増えたと書いている。信頼が足りない場面では、前向きな変化ではなく摩擦と苛立ちが生まれたとも書いている。ある上級の関係者は、デジタルを「分かっていない」という評判があった。よそのユーザーリサーチャーを「いかさま師」と呼んだという噂まであった。
• やったこと: 重要な会議の前に、同僚が筆者に、その関係者の言葉で話してみるよう促した。筆者はそれを受け、「アジャイルである」と言う代わりに、間違いから学んで数週間で直せることの大切さを話した。「ユーザーリサーチが大事だ」と言う代わりに、人々がどう反応するか分からないことのリスクを話した。
• 起きたこと: 筆者は、相手のように話したことで、密に協力でき、相手からの信頼も増したと書いている。それが、サービスの提供の障害を取り除くことにつながったとも書いている。信頼が増したことや障害が取り除かれたことの具体的な中身は、書かれていない。
• 注意点: 筆者一人の振り返りの記述で、第三者による確認や、相手側の見方は無い。成功という評価は筆者の自己評価である。相手の評判は噂として書かれていて、実際の考えかどうかは確かめられていない。会議の前の一回の工夫の話で、その後も関係が続いたかは書かれていない。この節は大きな振り返りの記事の一部で、筆者の「信頼の速さで変化は進む」という総括の中の一例である。スクラムの一チームの話ではなく、複数のサービスチームを束ねる責任者の話である。そのため scope は最も近い multi_team としたが、個人の立場での対話の工夫であり、チーム水準の事例としては読めない。同じ記事の他の節（戦略、依存関係、提供の維持）は、この悩みの事例としては拾っていない。
• 根拠: 経験報告／複数チーム。文献: What I learnt leading empowered teams at scale in Teacher Services（2023）。文献の種類: ブログ・実践者。位置: 3. Change happens at the speed of trust（上級の関係者の段落）。保存版: https://web.archive.org/web/20260514200112/https://dfedigital.blog.gov.uk/2023/08/30/what-i-learnt-leading-empowered-teams-at-scale-in-teacher-services/。確認の根拠: 原典

前提に反する事例

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

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

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

探した範囲の文献には見つからなかったこと

次のことは、この問いのために探した範囲の文献には見つかりませんでした。「研究が無い」という意味ではありません。

• 意見や価値観が大きく食い違うステークホルダーとの関係を、時間をかけて追い、対立が収まった、または収まらなかった結果まで書いた事例。（探した範囲: 収集ラウンド 1 回・読んだ文献 33 本）
• ステークホルダーへの働きかけの効果を、導入の前後やほかのやり方と比べて確かめた報告。働きかけには、相手の言葉で話すことや、デモをしてもらうことがある。（探した範囲: 収集ラウンド 1 回・読んだ文献 33 本）
• スクラムのイベント（スプリントプランニング、スプリントレビュー）に、関与の薄いステークホルダーを巻き込んだ結果が、その後のレビューで続いたかを追った事例。（探した範囲: 収集ラウンド 1 回・読んだ文献 33 本）

出典一覧

文献	年	ライセンス	記録の数
What I learnt leading empowered teams at scale in Teacher Services	2023	Open Government Licence v3.0	1
Design trust - why it’s important to influence stakeholders in the right direction	2021	Open Government Licence v3.0	1
Getting stakeholders more involved in sprint reviews	2014	Open Government Licence v3.0	1
How becoming open and agile led to customer success	2017	CC BY-SA 4.0	1

Contains public sector information licensed under the Open Government Licence v3.0.

---

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

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

評価コメント:

• 前提コンテキストの記述に対して極めて誠実であり、安易な一般化や俗説の混入を避けて論理的な限界を明示している点は高く評価できます。一方で、厳格な監査の観点から以下の課題と評価理由を指摘します。 1. Faithfulness（忠実性: 4点）: - 優れている点: 各事例の具体策だけでなく、「注意点」に記載された制約（筆者の自己評価にとどまること、1回限りの試行であること、他施策との効果の切り分けができないことなど）を正確に反映しています。「価値観の合わない相手」に対する事例が存在しないことも、コンテキストの注意点に基づいて正しく述べています。 - 減点理由: 末尾の「メンバー同士の摩擦は別の問い、経営陣への効果の説明は別の問い、スプリントレビューを実りあるものにする進め方は別の問いで扱っています」という一文は、提供された前提コンテキストのどこにも記載がありません。外部のFAQ構造や別設問の存在を前提としたメタ記述が混入しており、「前提コンテキストのみに基づく」という基準から逸脱しています。 2. Relevance（適合性: 4点）: - 優れている点: 「価値観の合わない相手とはどう話すか」という問いに対して、前提コンテキストの限界を明確にした上で「正面から扱った事例はない」と断定を避けて回答している点は論理的に的確です。また、関係づくりや対話のアプローチとして4つの事例（事前の課題・代替案の整理、不都合な事情の透明な共有、実演による巻き込み、相手の言葉遣いへの適応）を提示できています。 - 改善点: 質問「どう関係をつくり、話すのが良いか？」に対して、各事例の要約と注意点の列挙にとどまっており、「効果が実証された確立した手法はないものの、事例からは透明性の確保・事前の構造化・相手の語彙の採用といった共通の示唆が得られる」といった統合的な結論や要約が不足しています。また、末尾の別設問への言及は質問者への回答としては不要なノイズとなっています。

---

関連する用語

• ステークホルダー
• ステークホルダーの参加
• スプリントレビュー
• プロダクトオーナー