16
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「それはあなたの感想ですね」を封印する - 職種横断チームでの価値判断基準と戦略擦り合わせ術

Last updated at Posted at 2025-12-11

この記事はLITALICO Engineers Advent Calendar 2025 カレンダー4 の 12日目の記事です

この記事は実際のプロダクト開発現場で直面した課題と、その解決策を体系化したものです

はじめに

「それって、ユーザーが本当に求めているんですか?」
「データはありますか?根拠を示してください」
「それはあなたの感想ですよね?」

こんな言葉が飛び交うチームミーティング、経験ありませんか?

エンジニア、デザイナー、PdM(プロダクトマネージャー)が集まったとき、同じプロダクトについて話しているはずなのに、まるで別の惑星の話をしているような感覚に陥ることがあります。

私はソフトウェアエンジニアとして、これまで多くの職種横断プロジェクトに参画してきました。その中で痛感したのは、「リーン開発」や「データドリブン」だけでは解決できない根深い問題があるということです。

本記事では、異なる職種の専門家が建設的に議論し、共通の価値判断基準を構築するための実践的手法をお伝えします。

🎯 この記事で得られること

職種間の「感想戦」を回避する具体的手法
共通の価値判断基準を構築するフレームワーク
戦略擦り合わせのための構造化された対話術
解像度の高い議論を実現する質問テクニック


🚫 なぜ「それはあなたの感想ですね」が生まれるのか

職種別の「当たり前」の違い

まず、問題の根本を理解しましょう。各職種には固有の思考パターンと価値観があります。

🖥️ エンジニアの「当たり前」

  • 実装可能性重視: 「技術的に実現できるか」が最優先
  • 定量的判断: 数値、メトリクス、パフォーマンス指標で判断
  • リスク回避: バグ、セキュリティ、スケーラビリティへの懸念
  • 効率性追求: 保守性、再利用性、開発効率を重視

典型的な発言例:

「このAPIのレスポンス時間が300ms超えたら、UXに影響しますよ」
「この実装だと技術負債が蓄積します。後で必ず問題になります」
「なぜこの機能が必要なのか、データで説明してください」

🎨 デザイナーの「当たり前」

  • ユーザー体験重視: 「使いやすさ」「分かりやすさ」が最優先
  • 定性的判断: 認知心理学、人間工学、行動観察に基づく設計判断
  • 一貫性追求: ブランド、トーン&マナー、デザインシステム
  • 感情設計: ユーザーの感情的な反応、満足度を重視

典型的な発言例:

「このUIだとユーザーが迷子になります。認知負荷が高すぎます」
「ブランドの世界観と合いません。ユーザーに違和感を与えます」
「ユーザビリティテストの結果、この操作で多くの人が躓いています」

📊 PdMの「当たり前」

  • ビジネス価値重視: 「収益」「成長」「競争優位」が最優先
  • 戦略的判断: 市場、競合、事業目標で判断
  • ROI追求: 投資対効果、優先順位付け、リソース配分
  • 全体最適: 短期と長期のバランス、ステークホルダー調整

典型的な発言例:

「この機能でDAUがどれくらい上がる見込みですか?」
「競合がやっていないということは、市場ニーズがないのでは?」
「限られたリソースで最大の成果を出すには何を優先すべきか」

💥 衝突が起きる瞬間

これらの異なる「当たり前」がぶつかったとき、建設的な議論ではなく**「感想の押し付け合い」**が発生します。

よくある衝突パターン:

  1. 定量データ vs 定性データの対立

    • エンジニア:「定量的なデータがないなら根拠薄弱です」
    • デザイナー:「ユーザー行動観察で明確な課題が見えています」
  2. 短期 vs 長期の対立

    • PdM:「今四半期の目標達成が最優先」
    • エンジニア:「技術負債の解決が先決」
  3. 理想 vs 現実の対立

    • デザイナー:「最高のUXを提供したい」
    • エンジニア:「リソース制約で実装不可能」

🔄 リーン開発だけでは不十分な理由

リーン開発の限界

多くのチームが「リーン開発」「MVP」「仮説検証」を導入していますが、実際の現場では限界があります。

リーン開発でよく起きる問題

1. 仮説の質が低い

× 悪い例:「ユーザーはこの機能を欲しがっている」
○ 良い例:「月間利用回数3回以上のユーザーの65%が、
           検索結果の並び替え機能不足を理由に離脱している」

2. 検証方法が曖昧

× 悪い例:「ユーザーインタビューでポジティブな反応だった」
○ 良い例:「A/Bテストで新機能群のCVRが1.3倍向上、
           統計的有意性あり(p < 0.05)」

3. 学習の蓄積ができていない

× 悪い例:「とりあえずやってみて、ダメだったら次」
○ 良い例:「失敗要因の分析により、ユーザーセグメント別の
           需要パターンが明確化、次の仮説精度が向上」

必要なのは「戦略的擦り合わせ」

リーン開発を機能させるには、その前段階として職種間での戦略的合意形成が不可欠です。


🎯 解決策:3層構造の価値判断基準

フレームワーク概要

職種横断チームで共通の価値判断基準を構築するため、3つの層に分けて段階的に合意を形成します。

🏔️ Layer 3: 戦略・ビジョン層
   ├─ 事業目標・競争戦略
   ├─ ユーザー価値・ブランド戦略
   └─ 技術戦略・アーキテクチャ方針

⚙️ Layer 2: 判断基準・指標層
   ├─ 定量指標(KPI/メトリクス)
   ├─ 定性指標(品質基準)
   └─ 制約条件(リソース・技術・法規制)

🔍 Layer 1: 実装・検証層
   ├─ 具体的施策・機能
   ├─ 検証方法・成功基準
   └─ 学習・改善サイクル

🏔️ Layer 3: 戦略・ビジョンの擦り合わせ

ステップ1:各職種の戦略認識を可視化

まず、各職種が抱いている「戦略理解」を明確に言語化します。

構造化質問セット

🎯 事業戦略について

Q1. このプロダクトの3年後の理想像を、それぞれの職種の観点で述べてください

エンジニア視点:
「どんな技術的優位性を持っているか?」
「どの程度の規模(トラフィック・データ量)に対応しているか?」

デザイナー視点:
「ユーザーはこのプロダクトをどう感じているか?」
「競合と比べてどんな体験的差別化があるか?」

PdM視点:
「どの市場でどんなポジションを占めているか?」
「主要な収益構造・成長ドライバーは何か?」

🎯 ユーザー価値について

Q2. 「このプロダクトがなくなったら困る」と言うユーザーを具体的に描写してください

共通質問:
- そのユーザーは誰ですか?(デモグラフィック・サイコグラフィック)
- どんな課題・痛みを抱えていますか?
- なぜ他の選択肢ではなく、このプロダクトなのですか?
- そのユーザーにとっての「成功」とは何ですか?

🎯 競争戦略について

Q3. 競合との差別化ポイントを、それぞれの専門領域から説明してください

技術的差別化:
- 特許・独自技術、パフォーマンス、セキュリティ、拡張性

体験的差別化:
- UI/UX、ブランド・トーン、アクセシビリティ、感情的価値

事業的差別化:
- 価格モデル、流通・販売、パートナーシップ、データ資産

ステップ2:戦略ギャップの発見と調整

各職種の認識を比較し、ギャップや矛盾を特定します。

典型的なギャップパターン

Pattern 1: 技術戦略 vs ビジネス戦略の乖離

エンジニア:「マイクロサービス化で開発効率を上げる」
PdM:「新機能を高速でリリースして市場シェアを拡大」
→ ギャップ:短期の機能開発速度 vs 長期の技術基盤投資

Pattern 2: ユーザー価値の解釈違い

デザイナー:「直感的で美しいUIでユーザーを感動させる」
PdM:「機能の豊富さで競合に勝つ」
→ ギャップ:シンプル性 vs 機能性のトレードオフ

Pattern 3: 品質基準の認識違い

エンジニア:「99.9%の可用性とセキュリティが最低基準」
デザイナー:「ユーザビリティテストで80%の成功率が基準」
PdM:「月次NPS 50+、チャーン率5%以下が基準」
→ ギャップ:品質の定義・優先順位の違い

ギャップ調整の手法

1. トレードオフの明確化

「Aを取るとBを犠牲にする」関係を可視化

例:検索機能の高度化
├─ 技術投資(2ヶ月) → 検索精度向上(技術的価値)
├─ UI複雑化リスク → ユーザビリティ低下懸念(UX価値)
└─ 他機能開発遅延 → 売上機会損失(ビジネス価値)

→ 各職種で「何を最重視するか」の優先順位を議論

2. Win-Win解の模索

各職種の要求を同時に満たす第三の道を探る

例:「高機能 vs シンプル」の対立
→ 解決案:段階的機能開示(初心者向けシンプルUI + 上級者向け詳細設定)
→ 全職種の要求を部分的に満たす妥協案

3. 実験による検証

議論だけでは決着しない場合、小規模実験で検証

例:「データ主導 vs 直感主導」の設計判断
→ A/Bテスト:データ最適化版 vs デザイナー直感版
→ 実際のユーザー行動で客観的に判定

⚙️ Layer 2: 判断基準・指標の構築

戦略レベルの合意ができたら、次は具体的な判断基準を策定します。

ステップ1:職種横断指標の設計

各職種の専門性を活かしつつ、全員が理解・納得できる指標を作ります。

指標設計のテンプレート

🎯 ユーザー価値指標

定量指標:
├─ 利用継続率(DAU/MAU、リテンション)
├─ 機能利用深度(セッション時間、操作回数)
├─ 推奨度(NPS、口コミ・シェア率)
└─ 問題解決効率(タスク完了時間、成功率)

定性指標:
├─ ユーザビリティテスト結果(SUS、感情評価)
├─ カスタマーサポート問い合わせ内容分析
├─ ユーザーインタビュー定性フィードバック
└─ ブランド認知・好感度調査

🎯 技術品質指標

パフォーマンス:
├─ レスポンス時間(P50、P95、P99)
├─ 可用性(アップタイム、障害復旧時間)
├─ スケーラビリティ(負荷耐性、拡張容易性)
└─ セキュリティ(脆弱性、監査結果)

開発効率:
├─ 開発サイクル時間(機能着手〜リリース)
├─ バグ率(リリース後の不具合発生頻度)
├─ コード品質(複雑度、テストカバレッジ)
└─ 技術負債指標(コード負債、依存関係健全性)

🎯 ビジネス成果指標

短期成果:
├─ 利用者数(新規獲得、アクティブユーザー)
├─ 収益(売上、課金率、ARPU)
├─ 効率(CAC、LTV、チャーン率)
└─ 市場シェア(競合比較、認知度)

長期成果:
├─ 成長率(ユーザー・売上の成長トレンド)
├─ 競争優位(独自性、模倣困難性)
├─ 生態系(パートナー、データ資産蓄積)
└─ オプション価値(将来の拡張・展開可能性)

ステップ2:重要度・優先順位の合意

指標を列挙するだけでは不十分です。「何を最重視するか」の合意が必要です。

優先順位付けの手法

1. ICEマトリクス(改良版)

各施策・指標を以下の軸で評価:

Impact(インパクト):
├─ ユーザー価値への影響度(1-5)
├─ ビジネス成果への影響度(1-5)
└─ 技術・品質への影響度(1-5)

Confidence(確実性):
├─ 成功の確率(1-5)
├─ 根拠の強さ(データ・実績)(1-5)
└─ 実装の確実性(1-5)

Ease(容易さ):
├─ 開発工数(5-容易〜1-困難)
├─ リリースまでの期間(5-短〜1-長)
└─ リスクの低さ(5-安全〜1-危険)

総合スコア = (Impact平均 × Confidence平均) / Ease平均

2. ステークホルダー価値マップ

縦軸:ユーザー価値(低→高)
横軸:ビジネス価値(低→高)

右上象限「Win-Win」:最優先実行
├─ ユーザーにもビジネスにも高価値
├─ 全職種が納得しやすい
└─ 成功時の波及効果が大きい

左上象限「ユーザー重視」:中期投資
├─ 将来のビジネス価値につながる可能性
├─ ブランド・ロイヤルティ向上
└─ 差別化要因になりうる

右下象限「ビジネス重視」:短期収益
├─ 即座に売上・利益に貢献
├─ ただしユーザー価値は慎重に評価
└─ 持続性・競争優位性を検証

左下象限「両方低い」:実行しない
├─ リソースの無駄遣い
├─ より良い選択肢を探す
└─ または要件・アプローチを見直し

🔍 Layer 1: 解像度を上げる質問術

最後に、日々の議論で**「感想戦」を防ぎ、建設的な議論**を実現する質問テクニックを紹介します。

エンジニア向け:技術議論の解像度向上

❌ 避けるべき質問

「本当に必要ですか?」
「データはありますか?」
「根拠を示してください」
→ 相手を責める・否定するトーン

✅ 推奨する質問

「この機能がないと、ユーザーはどんな困りごとを抱えることになりますか?」
→ ユーザー視点での必要性を具体化

「どんなデータがあれば、この仮説の確からしさを判断できるでしょうか?」
→ データ収集の方向性を建設的に議論

「技術的な制約を考慮すると、どんな代替アプローチがありそうですか?」
→ 解決策を一緒に考える姿勢

🔍 技術的観点での深掘り質問例

パフォーマンス面:
「この機能を使うユーザーは、同時に何人くらい想定していますか?」
「レスポンス時間がXX秒を超えたら、ユーザー体験にどう影響しますか?」

拡張性面:
「将来、この機能を○○の用途にも使う可能性はありますか?」
「似たような要求が他の機能からも出てくる可能性はどの程度ですか?」

保守性面:
「この実装方法だと、将来の変更・修正はどの程度の工数になりそうですか?」
「他のエンジニアが引き継ぐ場合、どんな情報があると助かりますか?」

デザイナー向け:UX議論の解像度向上

❌ 避けるべき質問

「直感的って、具体的にどういう意味ですか?」
「それって主観ですよね?」
「美しさに根拠はありますか?」
→ 専門性を否定するトーン

✅ 推奨する質問

「『直感的』というのは、ユーザーがどんな行動をとることを想定していますか?」
→ 直感的さを行動レベルで具体化

「このデザインの狙いが最も伝わるのは、どんなユーザーでしょうか?」
→ ターゲットユーザーとの適合性を確認

「もしこのデザイン方向で進めるとしたら、どんな検証方法がありますか?」
→ デザインの効果測定を一緒に考える

🔍 UX観点での深掘り質問例

ユーザビリティ面:
「初めてこの画面を見るユーザーは、最初にどこを見ると思いますか?」
「ユーザーがこのタスクを完了するまで、何ステップくらい想定していますか?」

感情・体験面:
「このUIを使った後、ユーザーにはどんな気持ちになってほしいですか?」
「競合と比べて、どんな感情的な差別化を狙っていますか?」

一貫性面:
「このデザイン要素は、他のどの画面・機能でも同じように適用されますか?」
「将来、似たような機能が増えた時、このデザイン方針は拡張できますか?」

PdM向け:戦略議論の解像度向上

❌ 避けるべき質問

「ROIはどの程度ですか?」
「優先順位の根拠は?」
「なぜこれが重要なんですか?」
→ 尋問・詰問のトーン

✅ 推奨する質問

「この施策が成功した場合、どんなポジティブな連鎖反応が期待できますか?」
→ 波及効果・相乗効果を一緒に考える

「もしリソースが2倍あったら、この計画をどう変更しますか?」
→ 制約条件と理想状態のギャップを明確化

「この判断の前提となっている仮定で、最もリスクが高いのはどれですか?」
→ 不確実性を建設的に議論

🔍 戦略観点での深掘り質問例

市場・競合面:
「競合がもし同じ機能をリリースしたら、私たちの差別化はどこに残りますか?」
「この市場で、私たちが『絶対に負けられない』要素は何ですか?」

ユーザー面:
「この機能を最も喜ぶユーザーと、最も困るユーザーはどんな人ですか?」
「ユーザーがお金を払う動機は、どのタイミングで最も強くなりますか?」

事業面:
「この施策の成功を、半年後にどうやって判定しますか?」
「もし期待した成果が出なかった場合、どんな修正アプローチがありますか?」

🔧 実践的な運用方法

週次・月次での振り返り仕組み

理論だけでなく、継続的に改善していく仕組みが重要です。
現状は私が個人的に実施しておりますが、よりブラッシュアップしてチーム全体で取り組めるようにしていきたいです。

Weekly Review: 判断基準の検証

毎週金曜日に30分、以下を振り返り:

1. 今週の重要な意思決定を3つ挙げる
2. その決定の際に使った判断基準は適切だったか?
3. 異なる職種からの異議・懸念はあったか?
4. その議論は建設的だったか?改善点は?

目的:判断基準の有効性を継続的に検証・改善

Monthly Retrospective: 戦略擦り合わせの精度向上

毎月末に1時間、以下を振り返り:

1. 今月リリースした機能・施策の成果はどうだったか?
2. 事前の予想と実際の結果にギャップはあったか?
3. そのギャップはなぜ生まれたのか?(仮説・判断基準・実装のどこに問題?)
4. 来月の戦略・優先順位に反映すべき学びは?

目的:戦略擦り合わせの精度を継続的に向上

チーム文化の醸成

「感想戦」を防ぐための文化作り

1. 心理的安全性の確保

- 「分からないことを分からないと言える」環境
- 「失敗を責めるのではなく、学びを共有する」姿勢  
- 「異なる意見を歓迎し、対立を恐れない」文化

2. 共通言語の構築

- 各職種の専門用語を相互に理解する努力
- 「ユーザー価値」「ビジネス価値」「技術価値」の定義を統一
- 曖昧な表現(「直感的」「使いやすい」「効率的」)の具体化

3. 継続学習の推進

- 他職種の業務を理解する機会(シャドウイング)
- ユーザーインタビュー・ユーザビリティテストへの参加、または、結果の確認
- データ分析結果の共有と、異なる視点からの解釈議論

📝 最後に:「感想戦」を超えた先に

職種横断チームでの「感想戦」は、実は各職種の専門性と情熱の表れでもあります。問題なのは、その情熱が建設的な成果に結びついていないことです。

今回ご紹介した手法は、各職種の強みを活かしながら、共通のゴールに向かって歩むためのものです。

重要なのは

  • 🎯 戦略レベルでの合意があってこそ、戦術レベルの議論が意味を持つ
  • ⚙️ 共通の判断基準があってこそ、客観的な意思決定ができる
  • 🔍 構造化された対話があってこそ、解像度の高い議論ができる
  • 🔄 継続的な改善があってこそ、チームとして成長できる

「それはあなたの感想ですね」という言葉が聞こえなくなったとき、あなたのチームは真に協働するプロダクトチームに進化しているはずです。

ぜひ、明日から実践してみてください!


あなたのチームでも「感想戦」に悩んでいませんか?実際に試してみた結果や、他の工夫があれば、ぜひコメントで教えてください!

16
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?