初めに

開発するシステムの規模が大きいほど関係者の数も多いため、様々な場面で意見が対立しやすくなります。まずは、意見が対立する理由から考えてみます。

視点や文脈の違い

それぞれの関係者は、異なる視点から問題を見ています。例えば、システム開発において「品質」を議論する場合は、エンジニアは技術的な完成度として捉えるのに対し、営業は顧客満足度として捉え、経営者は収益と結びつくものとして捉えます。

情報の非対称性

それぞれの関係者が持つ情報や知識が異なります。また、専門性も違うため、同じ情報であってもその解釈が異なります。例えば、新技術の導入の議論において、エンジニアは技術的な詳細を理解しており、マネージャーはコストとリスクを理解しています。このときに、お互いの情報が十分に共有されていなければ、意見が対立しやすくなります。

価値判断の基準の違い

議論においては、短期的な価値を重視する人と長期的な価値を重視する人の間で意見が対立しやすいです。例えば、技術的負債の扱いについて考えると、短期的な価値を重視する場合は開発速度の改善が優先されますが、長期的な価値を重視する場合は保守性の改善が優先されます。

コミュニケーションの不完全性

言葉の定義や解釈の違いによってコミュニケーションが不完全になると、意見が対立することがあります。また、感情的なコミュニケーションが増えると、特定の人の価値観のみに基づく議論が展開されやすいため、議論の質が低下しやすくなります。例えば、「品質が高い」という言葉の意味を考えると、それぞれの人が品質に対して異なる基準や期待値を持っており、だからこそ感情的な価値判断が混ざりやすいです。

では、これらの理由で意見が対立した際に、どのように解消できるのでしょうか？

意見を分解する

エンジニアと関係者の間で起きがちな問題として、技術水準と予算の対立があります。エンジニアは高い技術水準を求めますが、顧客は予算内での実現を求めます。このような場合は、意見を分解すると解決策を見つけられます。この例では、エンジニア側が求める「高い技術水準」を以下の要素に分解します。

高い技術水準とは
- 保守性が高いこと
- キャリアの成長につながる新技術を採用すること

意見を分解したら、次は優先度を付けます。今回であれば「保守性が高いこと」は優先度が高く、「キャリアの成長につながる新技術を採用すること」は優先度が低いです。そのため、「高い技術水準」を求める代わりに、「保守性が高いこと」を求めるようにします。すると、それまで曖昧であった意見が具体的になり、技術 vs 予算という構図から、保守性 vs 予算という構図に変化するため、意見の対立を解消しやすくなります。

主張と提案に分ける

応用例として、「マイクロサービスアーキテクチャを採用すべきだ」という意見を、主張と提案に分けてみましょう。

譲れない主張
- システムが長期的に保守できること
- 機能を追加しやすい状態を保てること
- チームの技術力を維持・向上させること
改善の余地がある提案
- マイクロサービスアーキテクチャの採用
- サービスの分割方針
- 採用する技術スタックの選択
- 移行計画の詳細

このように、意見を主張と提案に分けることで主張に基づく合意が取りやすくなります。上記の例では、「保守性」、「拡張性」、「技術力」の観点から議論し、それぞれの具体的な実現方法を検討できます。さらに、提案については改善の余地を残しているため、マイクロサービス以外の選択肢も検討できます。例えば、モノリスをモジュールごとに整理することもできますし、段階的にマイクロサービス化を進めることもできます。

意見を分解することで、チームの価値観を守りながらも、現実的な制約の中で最適な解決策を見出し、建設的な合意形成ができます。

意見の対立を上手く解消するには