c. チームと顧客/ユーザー
#LeSS本
チームが顧客のために素晴らしいプロダクトを作ることに関心をもつためには、共感（そして直接のつながり）が必要
間接的や散乱した情報ではなく、"顧客やユーザーから" 機能に関するコンテキストと詳細な知識を得ることが必要
理想的には、チームは顧客と直接会い、顧客の（表面的ではなく）本質的な目標と問題を把握して、ソリューションを共同で作成する
チームとユーザーの直接対話を避ける古い習慣（↓ 例）によって、多くの受け渡し問題が発生する
ユーザーと明確化作業をするアナリスト
UI/UX デザイナーがつくる偽の「プロダクトオーナーチーム」
チームとユーザーの直接対話を避ける古い習慣が残ってしまう理由の例
単一スキルの専門家が
自分の領域を守りたいから
フィーチャーチームに参加するのが不安であると考えるから
これまでのサイロ気質やスキル不足のため、チームが顧客との明確化作業に居心地の悪さを感じる場合があるから
「1 人で仕様書を書くほうが効率的だ」と信じてしまっているから（部分最適化してしまっている）
チームとユーザーの間のオープンな議論によって、スコープクリープ（プロジェクトが当初の目標や境界を越えて膨張し始めたときに起こる現象）を恐れているから
プロダクトオーナーは仕様書作成の経験があり、仕様書作成を以上することに慣れてないから
両者の関係性をより良くするためのヒント
コネクターになる
プロダクトオーナーとして、顧客やユーザーがチームと直接関わるように働きかけをし、手配する
提供する機会の例
プロダクトバックログリファインメント
スプリントレビュー（新機能を使用したり、教育したりする）
ユーザビリティスタディ
現場での「フィールドスタディ」
ユーザーの職場でともに時間を過ごし仕事を手伝うこと
インストールのために訪問
トレーニングをする
ビジネス活動を共有する
ビジネス開発訪問、ビジネス分析、マーケティングなどに開発者を招待する
顧客と話す方法を教える
「顧客とのコミュニケーション入門」のようなミニコースを提供するか、依頼する
開発者は顧客と話すことに慣れておらず失敗する可能性があるが、修正できる問題であると考える
顧客関係管理グループと組む
「顧客関係を管理する」ことが自分たちの権限であると信じてるグループと組むこと、顧客と話す方法を教えることは、チームと顧客を結びつけるためには良い方法である
組織図が追いつくのを待ってはいけない。これまでの境界を無視して、プロダクトオーナーとしてチームと顧客を繋げてください
中間の人たちを統合する
従来型のビジネス部門が使っていたサブグループは、フィーチャーチームのメンバーとして価値ある役割を担うことができる（↓ 例）
ビジネスアナリスト
UX
変更管理
要件を収集し要件定義を書くグループ
スクラムマスターやサポートマネージャーとともに、それらの部門を廃止し、機能を分解し、よりシンプルな組織を作成することで LeSS の組織設計が本当のフィーチャーチームになるよう務めることがプロダクトオーナーとしての仕事である