問いの抽象化が組織の壁を超える

note でも読む ↗
問いの抽象化が組織の壁を超える

エンジニアとしてパフォーマンス改善の重要性を訴えても、なかなか理解が得られない。コードの品質向上のための時間が必要だと説明しても、「今は機能追加を優先したい」と言われてしまう。

多くの場合、私たちはこれを「相手に技術的な理解がないから」と片付けてしまいがちです。そして、技術的な背景の説明に力を入れようとします。しかし、それは本当に正しいアプローチなのでしょうか?

プロダクトづくりにおける専門性の壁

プロダクトづくりには、様々な専門性を持つメンバーが関わっています。

エンジニアはプロダクトをシステムとして捉え、技術的な整合性や実現可能性の観点から問いを立てます。デザイナーはユーザー体験という観点から、プロダクトマネージャーは事業価値という観点から問いを立てます。

それぞれの専門性は、独自の文脈(コンテクスト)を持っています。その文脈の中では、当たり前のように思える問いや課題が、異なる専門性を持つメンバーには全く異なって見えることがあります。

なぜ相互理解のアプローチは機能しないのか

従来の「相手に理解してもらう」というアプローチには、大きな落とし穴があります。

専門性の文脈を理解してもらおうとすることは、相手に自分の専門領域の深い知識を求めることになります。しかし、それは現実的ではありません。エンジニアがデザインの専門知識を、デザイナーが技術の専門知識を、それぞれ深く理解することは容易ではないです。

問いの抽象化というアプローチ

ここで提案したいのが、「問いの抽象化」というアプローチです。

これは、自身の専門性における具体的な問いを、組織やプロダクトというより抽象的なレベルの問いへとつなげていく思考プロセスです。

例えば、以下のように問いには階層構造があります。

text
組織の問い:「なぜこのプロダクトが必要か」
↓
プロダクトの問い:「どのような価値を届けるか」
↓
専門性の問い:
- エンジニア:「どのような技術で実現するか」
- デザイナー:「どのような体験を作るか」
- PM:「どのような優先順位で進めるか」

より抽象度の高い組織・プロダクトレベルの問いは、異なる専門性を持つメンバー間で共有可能な「共通言語」となります。

実践:問いの抽象化と具体化の往復

では、具体的にどのように実践すればよいのでしょうか。

1. 上位の問いを常に意識する

自分の専門性における問いが、組織やプロダクトのどのような問いにつながっているのかを意識します。

例えば、パフォーマンス改善という技術的な問いは、以下のような問いにつながっていると考えられます。

  • ユーザー体験の向上という製品の問い
  • 顧客満足度の向上という事業の問い
  • 持続的な価値提供という組織の問い

2. 適切な抽象度で対話する

異なる専門性を持つメンバーと対話する際は、お互いの専門性の詳細に入り込むのではなく、共有できる抽象度の問いにフォーカスします。

技術的負債の解消という問いは、以下のように抽象化できます。

  • 「開発速度の維持」という観点
  • 「品質の持続的な担保」という観点
  • 「リスクの低減」という観点

3. 具体と抽象を行き来する

上位の問いを理解した上で、自身の専門性でどのように具体化できるかを考えます。また、他のメンバーの具体化の方向性を理解し、整合性を確認します。

組織としての効果

このアプローチを実践することで、以下のような効果が期待できます:

  1. より良い意思決定
    • 異なる専門性からの視点を統合できる
    • 組織の価値に基づいた判断ができる
  2. イノベーションの促進
    • 異なる専門性の組み合わせによる新しい価値の創造
    • 問いの抽象化による新しい解決策の発見
  3. チームの一体感
    • 共通の問いによる方向性の共有
    • 各専門性の価値の相互理解

おわりに

問いの抽象化は、単なるコミュニケーションテクニックではありません。それは、自身の専門性と組織の価値をつなぎ、より大きな価値を生み出すための思考プロセスです。

組織の規模や構造、役割の定義によっても、問いの階層構造や抽象化のプロセスは柔軟に変化します。また、プロダクト開発に限らず、様々な専門性が交わる場面で応用できると考えます。

日々の業務の中で、話が噛み合わなかったり対立してしまったりするときは、自分の立てている問いの抽象度を意識し、共通の文脈を作れるようにその意味を捉え直してみることで、新しい対話と価値創造が可能になると思います。