吉羽龍太郎さんに聞く、ステークホルダーとの信頼を築く方法

「実物があるから、関係が作られる」──吉羽龍太郎さんに聞く、ステークホルダーとの信頼を築く方法

アジャイルを実践する中で、開発チームの中はうまく回っていても、その外側にいる他部門や経営層、営業との関係で足踏みしてしまうケースは少なくありません。開発チームの境界を越えて関係者の目的を揃えるには、何が必要なのでしょうか。

今回お話を伺ったのは、株式会社アトラクタ取締役CTOでアジャイルコーチの吉羽龍太郎（@ryuzee）さんです。2026年3月には、ステークホルダーとの関係性の築き方を扱った訳書『Aligned』を刊行しています。

営業からの急な割り込み、ステークホルダーとの難しいコミュニケーション……そうした問題に対して、吉羽さんが語ったのは、コミュニケーションのテクニックだけではありませんでした。

あくまで「実物」を土台にして、その上で誰とどう向き合うか。実物を見せ、成果を共有しながら関係を築いていくという、アジャイル開発の根底にある考え方まで掘り下げました。

プロダクトがうまくいくと、全ての問題は拭い去られる
エンジニアが開発しかしない、ということ自体が間違い
誰と向き合うのか──「予算を承認したのは誰か」から始める
1on1で集めるのは判断ではなく「生データ」
「時間を取ってもらえない」をどう突破するか
信頼は透明性と結果で積み上がる
アジャイルチームが明日からできること
【関連記事】ステークホルダーを巻き込み、プロダクトを育てる

プロダクトがうまくいくと、全ての問題は拭い去られる

── 数多くの開発チームを支援されている中で、チーム内部の課題以上に、チームの外との関係性に悩む声を聞くことが多いと伺いました。関係者の間で目的や認識を揃える難しさを現場ではどう感じていらっしゃいますか。

吉羽龍太郎さん（以下、吉羽）　よくあるのは、いろいろなことを言われる中で、全部やろうとしてどっちつかずになるというシナリオですね。

営業からは「この機能がないと契約が取れない」、経営層からは「もっと売り上げを増やしてほしい」、上の立場の人からは「約束した期間で成果を出してほしい」と、それぞれ別のことを言われるわけです。会社の組織構造として開発チームは大体下の方にあるので、やっぱり「No」と言いにくいんですよ。何か言われると、まずはなんとかする方法を考えてしまう。

でも「全部入り」は大体ろくなことになりません。やることばかり増えるのに、フォーカスもできていないので目に見える成果が出てこない。だからまたいろいろ言われる、という状態です。

少し補足しておくと、これは突き詰めると単純な話でもあるんです。ステークホルダーがいろいろ言ってくる状況って、基本的にプロダクトがうまくいっていないんですよ。

── 前提として、うまくいっていない。

吉羽　儲かっていれば、みんながゴールを達成できているので、細かいことは言われません。だから身も蓋もない言い方をすると、プロダクトがうまくいくと、全ての問題は拭い去られます。

逆に言えば、ステークホルダーマネジメントに悩むという時点で、プロダクトがうまくいっていない可能性があるぞと認識しなきゃいけない。ステークホルダーがいろいろ言ってくるというのは目に見えるので問題視しやすいんですが、それが一番の問題とは限りません。というのは口を酸っぱくして言っています。その前に、プロダクトが今どういう状態なのかを見極める必要があります。

エンジニアが開発しかしない、ということ自体が間違い

── プロダクトを成功させることが大前提であり、まずは今の状態を見極める必要があるのですね。その上で、プロダクトをうまくいかせるためには、開発チームの中だけで完結するのではなく、外側のステークホルダーとも協力していく必要があります。現場ではさまざまな立場の人がいますが、実際にはどのようなケースをご覧になりますか。

吉羽　よく見るのは、営業から割り込みが入るパターンですね。

営業の人はお客さんから「これがないから契約できない」と言われる。それを短絡的に裏返して、「じゃあこの機能があれば契約してくれるんだな」と期待して、チームに持ってくるわけです。でも、別のお客さんに行くとまた違うことを言われる。そうすると、チームが立てていた計画に、割り込みや追加、変更が次々と重なっていきます。

変化が起こること自体は悪くないんです。問題は、その意見が本当に対応すべき合理的な意見なのかが検証されていないことです。とにかく数字が欲しいので「作れ」という話になってしまう。本当は、「じゃあ何カ月以内に作るので、今契約書にサインしてください」というところまで持っていくべきで、エンドのお客さんの本気度をちゃんと探って選別しないといけません。

── とはいえ、力関係としては営業の方が強く、開発からは言いづらいようにも思います。

吉羽　一つは、営業にエンジニアが付いていく、というのを僕はよく言っています。特に取りたい大口のお客さんの場合は、エンジニアだからこそ言える話がいっぱいあるんです。

お客さんが「この機能がない」と言ったときに、「こういうやり方ならすぐ対応できますよ」と、その場でオプションを提示できるからです。買う側からすると、「持ち帰って検討します」と言われると温度感が下がってしまうんですよね。その場で「こういう手もあります」と出せれば、「それなら、とりあえずやってみましょうか」となりやすい。

つまり、開発の人が開発しかしないということ自体が、そもそもの間違いなんですよね。「成功させるために必要なことは全部やる」と考え方を変えると、状況は結構変わります。そのためにはチームの外と合意を取るのも開発の仕事だ、という認識を持たなきゃいけない。

── 逆に、エンジニアが自分のフィールドに営業を連れ出すような方法も有効でしょうか。例えば、カンファレンスに同行してもらうとか。

吉羽　逆も全然アリだと思います。営業の人に開発の現場を見てもらう機会があると、関係性は変わりますよね。似た例で言うと、プロダクトマネージャーやプロダクトオーナーが実際に自分でデプロイしてみる、というチームもあります。相手が何をやっているかを知るのは、どの職種でもとても重要です。

誰と向き合うのか──「予算を承認したのは誰か」から始める

── チームの外側には営業以外にもさまざまなステークホルダーがいますが、相手を知るためには、まず誰から、どのような観点で関係性を整理しておくとよいのでしょうか。

吉羽　プロダクト開発でいうと、「誰が予算を承認しましたか」「誰がこのプロダクトをいつまでに作ると決めて約束していますか」というところですね。ツリー構造の組織だと、開発チームから見て1個か2個上くらいだと思います。人・物・金を供給してくれた人が、まずは最大のステークホルダーです。

ただ、それだけでは足りません。組織構造に関係ない動きをして、しかも影響力を持っている人が結構いるんですよ。『Aligned』の作中では、スパークスという人が全部のミーティングに登場して、やたらと自分の言う通りにしろと主張している。本来プロダクトマネジメントの組織とは関係ないはずなのに、主導権を握っている。役職や肩書きと影響力は必ずしも一致しないんです。

だから“観察”がすごく重要ですね。誰が実際に影響力を持っているかは、会議での議事内容やパワポの資料だけでは分からないので、登場している人の振る舞いや会話のトーンを含めて、全体のパワーバランスを見ていく必要があります。

── リモートワークの環境でも、そうした観察は可能なのでしょうか。

吉羽　チームの中であれば比較的やりようがあります。例えば僕が支援しているチームの一つは、リモートの日は朝から全員が同じZoomに入って、そのあと終日つなぎっぱなしにしているんです。頻繁に喋りながら「ちょっとこれ見て」と言ったり、雑談したりしている。これなら、ほかのメンバーがどういう状況で仕事をしているかを観察できます。

問題はステークホルダーの振る舞いです。会議の様子を見ることである程度は分かりますが、会社によってはカメラオフがデフォルトだったりして厄介です。特に強めの発言やネガティブな発言のときに、どんな顔をして言っているのかが分からないと判断材料が少なくなりますね。

1on1で集めるのは判断ではなく「生データ」

── 書籍では、相手の意思決定スタイルを理解することが効果的なコミュニケーションにつながると紹介されています。実際にはどう見極めていらっしゃいますか。

吉羽　特別なことはしていません。大事なのは、ここでもまずは観察することですね。スクラム自体が経験主義、つまり「知識は経験から生まれ、意思決定は観察に基づく」という考え方ですから、何か手を打つ前にじっくり見る。これはステークホルダーに対しても同じです。

ただ見ているだけでは分からないので、1on1を定期的にやって情報を集めます。初回に聞くことが多いのは、その人自身のゴールや目標ですね。「今、どんなミッションを持っているんですか」と。チーム外も含めていろいろな人に聞くと、それぞれ違います。そこで「ほかの方がどんな目標を持っているか、ご存じですか」と投げかけてみたりもします。

── 聞いた内容は、「この人はこういうタイプだ」と整理して残しておくのでしょうか。

吉羽　いえ、「この人は指示型だ」「民主型だ」というようなラベル付けは基本的にせず、もう少し生データに近いメモを残すことが多いですね。「こういう話をしていた」と。ラベルは自分の判断になってしまって、それだけ書いていてもあまり役に立たないんです。

近いやり方が、僕がAmazonで働いていたときの360度評価です。シチュエーショナルフィードバックといって、「Aさんがこういう状況のときにこういう振る舞いをしていた」と、必ず具体的な事実をセットにします。いいとか悪いとかはその後の話で、まずはこう振る舞っていた、という事実が重要なんです。

だから1on1のコツとしては、下手にサマリーにし過ぎないことですね。生データのままにしておいた方が、あとから使えます。

── その生データをもとに、相手によってこちらの出方を変えていく。

吉羽　そうなりますね。意思決定するときにデータをすごく重視する人であれば、やっぱり事実を集めて話をします。「合意した」という事実が大事な人もいて、その場合は持っている情報をテーブルに乗せて、お互いに懸念点を話した上で、最後に「合意したよね」と確認する。直感で決める人であれば、直感で決められてしまう前に必要な情報をインプットしておく。相手によって出方は変わります。

あとは、1回で合意しようと思うからできない、という話でもあります。相手を観察しながら、手を変え品を変え、コミュニケーションの仕方を工夫して、合意に向けたやり取りを繰り返す。そうしていると「この人には先にこれを出しておくと話が進みやすい」というのが分かってきて、圧倒的に早くなります。

「時間を取ってもらえない」をどう突破するか

── 現場では「話したいけれど時間を取ってもらえない」という悩みもあります。

吉羽　『Aligned』では会議という形式にこだわらず、雑談や偶然の接点を使って話をしてしまう「アンミーティング」という言い方で紹介しています。同書の主人公・アイリーは朝早くいいコーヒーを用意して、コーヒー好きのスパークスをその匂いでおびき寄せていました。

そこまで凝ったことをしなくても、現実の職場でできることはいくらでもあります。同席している会議がちょっと早く終わったなというときに「ちょっと参考に聞いていいですか」と声をかける。それだけでも十分です。

やろうと思えばいくらでもできるので、「時間を取ってもらえない」という言い方自体が、本気で取ってもらおうとしていないのではないか、という気はします。作中のスパークスは会議の招待すら承認してくれませんが、あそこは物語として誇張して描いているのであって、日本の会社でそこまでの人がどれだけいるかというと、そんなに多くありません。少し立場が上の人であれば、別の上位の人から紹介してもらうなど、やりようはいくらでもあります。

── オンラインの場合も、会議の終わり際に時間をもらうといったことはできるものでしょうか。

吉羽　その場で話すのではなく、「この後ちょっとだけ時間が欲しいんですけど、詳しくはSlackでDMするので」と頭出しをする、というテクニックが使えると思います。

── そもそも「話しづらい」と感じる相手との関係を変えるために、まず何から始めればよいでしょうか。

吉羽　まず話すしかないんですよ。ある日突然、話が通じる関係性ができるわけではありません。そこには、「あなたに関心があって、もっとうまくいかせるために協力してほしいんです」という前向きな姿勢が欠かせません。

その上で、相手の関心事や目標を聞いていきます。それから、恐怖ですね。何をそんなに恐れているのかを知るのは、結構有効です。例えば「数字が出なかったら首が飛ぶ」と実は上から言われているとか。プロダクトのチームは知らないけれど、そういう恐怖を抱えていることはあります。

「話しづらい」というのは、人格的に問題があるケースは少なくて、ほとんどの場合、相手のコンテキストが分からないことに起因するんですよ。質問して相手のことが分かるようになると、話しやすくなりますね。

── 話を聞くときに気をつけていることはありますか。

吉羽　とりあえず、反論しないで聞く方がいい。反論すると「面倒なやつだな」と思われて、何も進みません。聞いているこちら側も、いちいち腹を立てていては、関係性を作ろうとして来た意味がなくなってしまいます。

本書でも、相手が何か言ったら「これってこういうことですか？」と言い換えて質問する方法が紹介されています。これは結構重要で、それが合っていれば相手からすると「この人、分かってくれてるんだ」という安心感につながります。まずは聞くというところに軸足を置いておくのは、とても大事です。

Aligned―プロダクト開発におけるステークホルダーとの関係性の築き方

著: Bruce McCarthy、Melissa Appel
訳: 吉羽龍太郎、原田騎郎、永瀬美穂
発行: 2026年3月

オライリー・ジャパン

信頼は透明性と結果で積み上がる

── 関係づくり自体が目的ではなく、あくまで「プロダクトを成功させる」ためのコミュニケーションだというポイントが見えてきました。一方で、こちらから自分を出さないと、向こうからの信頼は得られないようにも思います。

吉羽　それはそうですね。自分の側の情報を出さないと、やっぱり隠し事がある状態に見えて、信用されないんですよね。だから僕は、聞かれたことには大体答えます。NDAで守るべき情報は別として、それ以外は基本的に隠しません。「この人はここには興味がないだろう」とこちらで切り分けず、デフォルトでは、オープンにしておいた方が圧倒的に楽です。

どうしても言ってはいけない情報以外は、誰の口からどこに伝わっても困らない、という扱いにしておく。迷うなら、話す前にメンバーに「どこまで伝えるといいかな」と相談すればいいだけの話です。

── オープンにする以外に、信頼につながることはありますか。

吉羽　これも突き詰めれば当たり前の話ですが、結局、結果を出しているかどうかが非常に重要なんです。「話しやすいけれど結果は何も出さない人」と「話しにくいけれど成果は出す人」を比べたら、やっぱり後者なんですよ。目に見える結果を出せば自分のチームが信頼されるので、外からマイクロマネジメントされることもなく、「うまくいっているなら邪魔しない方がいい」と思ってもらえます。

だから、まず実物や結果を見せることが土台にあって、その上でステークホルダーとの関係を築いていくことが大事なんです。

そのための代表的な場が、スクラムでいうスプリントレビューです。1週間か2週間に1回、実物を披露してフィードバックを集めるイベントで、これは本来、ステークホルダーに参加してもらうことを前提としたイベントです。関心のある人に来てもらえば、状況はもう透明になります。

それでも来られない人がいます。もしその人がとてつもなく重要なら、こちらから出張して見せに行くことも必要です。現物があること自体がいろいろなところに効き目がある、というのがアジャイル開発のコアの思想です。

── 資料ではなく、現物を軸にする。

吉羽　スライド資料を送っても、みんななかなか見ないんですよ。それならばと、Figmaでデザインのモックを作って送っても、やはり真剣には見てもらえない。それなのに、実物ができたとたんに「ここはどうなっているんだ」と言い出すのが世の常です。実物至上主義というのが、信頼を勝ち取る上でとても重要だと思います。

── 逆に、「これは信頼を失いやすい」という振る舞いがあれば教えてください。

吉羽　できないことを「できる」と言ってしまって、結局できないというのが一番良くないですね。いい顔をしたくなりますし、「一つだったらなんとかなりそう」と思ってしまう。でも「分かりました、やります」を繰り返していると、プロダクトはろくなことになりません。

あとは、良くない情報を隠して結局後でバレることですね。良くないニュースは、早ければ早い方がいい。良いチームなら、スプリントレビューで悪い話を出せます。

ステークホルダーによって態度や伝え方が違う、というのも良くないですよね。自信がないときは持ち帰った方がいいですよ。「これは今、判断できないし確約もできないので、一回チームで検討してからちゃんと答えます」と。その場で嘘を言うよりは、言わない方がマシです。

アジャイルチームが明日からできること

── チーム外との関係づくりで、まず明日から始められることがあれば教えてください。

吉羽　いちばん強調したいのは、とにかく実物を頻繁に見せるということです。関係づくりは小手先のテクニックでやる話ではなくて、実物があるから関係が作られるんです。名前は何でもいいんですけど、実物を披露する場にステークホルダーを呼ぶ、というのを繰り返し続ける。話はそれからだと思います。

それができているなら、次はステークホルダーに話を聞きに行きましょう。ステークホルダーは敵じゃないんですよ。彼らだって成功させたいと思っているので、そんなに警戒しなくてもいい。カジュアルに聞けば、みんなプロダクトに成功してほしいと思っているのは変わらないはずです。

── もう少し小さめのことだと、何かありますか。

吉羽　まずチームの中だけでも隠し事のない状態、透明性の高い状態にするといいと思います。外の関係性の前に、まずチームの中の関係性が大事です。

ただ、ふりかえりの場であるレトロスペクティブなどで「オープンにした方がいいよね」と決めても、みんながそれにのっとってやってくれるかは分かりません。言い出した人は、他人がやらなくても自分がやっている姿を見せることがとても重要です。自分がやらないのに人に要求するのは最悪です。自分がオープンにして、あと1人くらい出てくると、だんだん自然にみんな乗ってくる感じはしますね。

── 実物を見せても、その場では反対が出ず、後から認識のズレが表面化することもありそうです。

吉羽　支援先のチームによく言っているのは、賛否両論が出るのがいいレビューだ、ということです。「これがいい」「あれがダメだ」と人によって意見が違うくらいの方がよくて、みんなが「まあいいんじゃない」と言ったら、多分、全然うまくいっていません。反対を表明しないからといって反対していないわけじゃないんですよ。賛同しているわけでもない。誰も言わないという時点で危ういんです。

それを防ぐ方法として、『Aligned』では「あなた、これでコミットしますか？」と一人ずつ確認していくやり方を紹介しています。みんなの前では言えなくても、一人ずつ当てていくと「ノーです」と出たりします。

ただ、テクニック以前の問題もあります。実物を見せるときに、あってもなくてもどちらでもいい機能を作っていたら、賛否両論なんて起こるわけがない。今フォーカスすべきことにフォーカスして、それでできたものに対してああだこうだ言われるというのが健全な状態です。

── 最後に、ステークホルダーとの関係づくりに悩むアジャイルチームへメッセージをお願いします。

吉羽　繰り返しになりますが、やっぱり「プロダクトがうまくいくと、全ての問題は拭い去られる」というのが何より重要です。だから、テクニック以上に、プロダクトをうまくいかせるために全員ができることをやらなきゃいけない。

そしてプロダクトをうまくいかせる責任は、全員にあります。そこには必ず人間が登場します。開発のスキルだけでなく、人との関係性を作ったり維持したりすることもプロダクトを作る上で必要なスキルです。「自分は開発だから関係ない」と言わないで、みんな、人とコミュニケーションをとり、関係性を作るトレーニングをしてみるといいですよ。

そういうことが苦手だという人は多いんですけど、口八丁手八丁で喋れという意味ではありません。うまく喋れなくても全然いいので、本当に必要な会話ができるように頑張ってほしいです。技術だけでなく、他人の動きに関心を持つ。そこが第一歩です。