NEW! スキル
事前に合意していたはずなのに、なぜかレビューやデモの度に見つかる認識のズレ。エンジニアは「現場がないがしろにされている」と感じる一方で、プロダクトマネジャー（PdM）は「なぜ動いてくれないのか」と不満を募らせる。
プロダクト開発の現場では、チーム全体が“何となくうまくいかない”状態に陥ることが少なくない。
「良いプロダクトを作りたい」という思いは同じはず。全員が真面目に仕事をしており、それぞれの立場で最善を尽くしているにもかかわらず、なぜすれ違いが起きてしまうのか。
今回そんな相談にのってもらったのは、数多くの企業で手腕を奮ってきたアジャイルコーチであり、『Aligned―プロダクト開発におけるステークホルダーとの関係性の築き方』（オライリー・ジャパン）の翻訳に携わるなど、「組織」の課題に詳しい吉羽 龍太郎さん。チームがぎくしゃくする原因と、それを解消するために開発組織が向き合うべき課題について聞いた。
株式会社アトラクタ
Founder兼CTO/アジャイルコーチ
吉羽 龍太郎さん（@ryuzee）
野村総合研究所、Amazon Web Servicesなどを経て現職。アジャイル開発、DevOps、組織開発を中心としたコンサルティングやトレーニングが専門。Scrum Alliance認定スクラムトレーナー。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）など、訳書に『ダイナミックリチーミング』『Tidy First?』『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）『チームトポロジー』（日本能率協会マネジメントセンター）『ジョイ・インク』（翔泳社）など多数
ーープロダクト開発の現場では、全員が「良いプロダクトを作りたい」と考えているはずですよね。それなのに、なぜチーム内ですれ違いや衝突が生じてしまうのでしょう。
「良いプロダクト」の定義が、ポジションによって異なるためだと思います。
エンジニアにとっては、運用やセキュリティーの観点からみて優れた設計であることや、モダンな技術スタックを取り入れて開発することが「良さ」の一種です。ですが、PdMの場合は、顧客の課題を解決できることが最優先ですし、より経営に近い立場になると、「どれだけ利益を生み出せるか」が重要になります。
こうした前提の違いがあるまま議論が進むと、向かっているゴールが異なるので、いつまでも話は噛み合いません。大規模な組織や役割が細分化されているチームであればあるほど、利害が対立しやすくなります。
ーーでも、同じ職種のエンジニアが集まったチームにも関わらず、うまくいかない開発組織はありますよね。
職種が同じでも、個人の考え方にはグラデーションがあります。エンジニアの中にもPdM的な思考をするも人いれば、経営視点を持つ人もいる。すると、「今の顧客課題はこれだから、この機能開発を優先すべきだ」「まずは技術的負債を返済しないといけないので、新機能よりもリファクタリングや改善に時間を使うべきだ」という意見の違いが発生します。
ーー意見の食い違いを起こさない方法はあるのでしょうか？
そもそも、目指すゴールがきちんと定義されていないことも多いんですよね。うまくいっている組織は、トップが方向性を示し、現場が会話をしながら詳細を詰めていく「ブレイクダウン型」を採用しているケースが多い印象です。定性的でも定量的でもいいので、組織にとってのゴールを明文化しておくのが望ましいですね。
ーーブレイクダウン型を機能させられる強いリーダーがいればうまくいく、と。
それが、一概にそうとも言えないのが難しいところです。トップが方向性を示しても、ブレイクダウンが進む過程でさまざまな人の思惑が混在して意図が歪んでしまうケースはありますし、完璧だと思ったゴールそのものが誤っていないとも限りませんから。
元も子もない言い方になりますが、全員が同じゴールに向かうこと自体とても難しいんです。役割分担をしている時点で、個人が背負う目標は必ずしも一致しません。ユニークユーザー数、売上、開発した機能数など、それぞれ異なる指標で評価されます。
客観的に見て「良いプロダクト」になっていても、自分に課された目標が達成できていなければ評価は得られません。そうなると、プロダクト全体よりも自分の目標達成を優先して行動をとった方が、個人にとっては合理的な判断になってしまいます。
こうした「個人の評価」と「プロダクトのゴール」のズレは、組織内でのすれ違いを生む要因になりやすいんです。
ーーチームが何となくうまくいっていない場合、どこにボトルネックがあるのでしょうか？
大きく三つあります。「コミュニケーション量」「意思決定権」「目標設定」です。
第一に、うまくいっているチームは日常的にこまめなコミュニケーションを取っています。リモートワークであっても、朝の業務開始タイミングでZoomやTeamsにつなぎ、必要なときにすぐ話せる状態にしておくんです。通常は黙々と作業して、行き詰まった場合はすぐに画面共有して「ここ助けてください」と言えるような環境を整えています。
声を大にして言いたいのは「デイリースクラムが15分では終わらん」と悩みを抱えているチームは、スプリント期間中の開発者同士の接触時間が純粋に不足している。オンラインでもオンサイトでもいいけど、ばんばん会話すりゃいいし、翌日まで待つだけムダやで
— Ryutaro YOSHIBA (@ryuzee) January 6, 2026
一方、うまくいっていないチームの場合、コミュニケーションを「まとめてやろう」とする傾向があります。例えばスクラムであれば、15分しかないデイリースクラムで全て解決しようとして、結局毎回それ以上に時間をかけてしまう。しかも、そこで問題が発覚しても1日の作業は取り戻せませんよね。
こまめに話していれば、小さなズレにすぐに気付いて修正できます。かつては「まずは自分で調べろ」と言われることもありましたが、最近は開発スピードの重要性がどんどん増しているので、むしろ「少し考えて分からなければすぐ聞く」くらいの方が効率的だと思いますよ。
探せばどこかのドキュメントに解決方法が書かれているかもしれない。でも、そこで「これに書いてあるじゃん」と突き放してしまうと、次回以降も「自分で調べなければ」と思ってしまい時間が溶けていきます。なので、まずはスキルや経験のあるメンバーが率先して質問することで、「このチームでは気軽に質問していいんだ」という空気を作っていけるといいですね。
うまくいっていない組織がやりがちなのが、役割ごとに決まっている意思決定の範囲を尊重しないことです。
例えば、経営層が変わったり新しいマネジャーが組織にジョインしたりすると、「短期間で成果を出さなければいけない」というプレッシャーを感じるあまり、前任者が築き上げてきた方針を大きく変えたり、細部にまで口を出したりしてしまうことがあります。
本来は現場エンジニアの裁量で進められる範囲なのに、後から覆されるような状態になると、現場は疲弊していく。その結果、「どうすれば成果を出せるか」ではなく、「どうすれば面倒を避けられるか」が優先されるようになるんです。
アジャイル開発では、こうした事態を避けるために「チームに権限を委譲すること」が重要だと言われています。ですが、権限を渡す側が「本当に任せて大丈夫なのか」という不安を感じている限り、介入を減らすことはできません。
だからこそ、現場エンジニア側も日常的に説明責任を果たすことが重要です。進捗率とかタスクの完了数のような数字では状況が伝わらないので、実際に動くものを定期的に見せなければいけません。「プロダクトは今こうなっています」とデモできる場を用意すれば、それを見た側も安心して過度な介入は自然と減っていくはずです。
一般的に目標は「定量的に測れるように設定した方がよい」と言われますが、プロダクト開発に関する目標の場合は注意が必要です。
先ほども挙げたように、プロダクトには売上やユーザー数など、さまざまな指標があります。そうした「プロダクト全体のメトリクス」を目指していくのは健全です。ただ、それとは別に個人の作業レベルのような目標を設定してしまうと、途端にうまくいかなくなります。
例えば、「月に〇件のタスクを完了する」といった目標を個人に課すと、「良いプロダクトを作る」ことよりも、「自分の数字を達成する」ことが優先されやすくなる。そのため、プロダクト開発においては、個人ではなくチーム全体で追いかける目標を決めた方がいいと思います。
プロダクトマネジメントで言われるノーススターメトリック*のように、プロダクトの成功を示す指標を一つ定め、チーム全体で共有する。「自分の目標だけ達成すればいい」という構造ではなく、「みんなで同じ指標を目指す」構造になっているかどうかが大切です。
*ノーススターメトリック：プロダクトやサービスが顧客に提供している価値を最も端的に表す重要指標。事業成長の方向性を示す「北極星」のような役割を担う
ーーこれらのポイントを一つずつ解消すれば、チームの課題は解消されていくんですね。
そこまで単純な話でもないんですよね。コミュニケーション量、意思決定権、目標設定を見直すことはもちろん重要です。しかし、チームの中だけでそれらを整えれば、全ての問題が解消するわけではありません。
プロダクト開発でチーム内の意見がぶつかったとき、最終的にはチームの中で権限を持つ人の意見を選びがちです。また、チーム内では合意できていたとしても、経営層や他部門、顧客といったステークホルダーの期待や制約とずれていれば、チームの外から判断を覆されることもあります。
こればかりは、どうしてもゼロにはできません。それゆえに、意思決定に影響を持つ人たちとの関係を築かないまま仕事を進めてしまうと、最後になって大きな手戻りが発生しやすくなります。
重要なのは、日常的な説明を通じて、現場の意見に賛同してもらえる状態を作っておくことです。プロダクトの進捗や成果をきちんと見せて相手の不安を減らしていくことに加えて、相手が抱えている課題や目標を理解し、共感を示すことが必要です。こうしたコミュニケーションの積み重ねが、最終的な意思決定の場面で効いてきます。
もちろん、全ての人に同じように対応していると時間がいくらあっても足りないので、誰にどこまで説明すればよいかを見極めることも欠かせません。
ーー今後、チームが「何となくうまくいっていない気がする」と思ったら、まずは何からしたらよいでしょうか？
今回いくつかポイントを挙げてお話ししましたが、うまくいかない理由が「何となく」のままでは解決しようがありません。
チームの状態に違和感があるなら、まずは原因を突き止めること。その際は、違和感を覚えた出来事をできるだけ具体的な言葉にしていくのがおすすめです。
「この間の会議であの人が意見を言ったとき、もう一人がこう反論していた」といった場面を、できるだけ挙げていきましょう。その上で、何が根本の問題になっているのか紐解いていくと、「何となく」の正体が見えてきます。そこまで落とし込めれば、取るべき対処も自ずと見えてくるものですよ。
取材・文／福永太郎 編集／秋元 祐香里（編集部）
タグ
