妥協する技術

はじめに

ぺんぎん（@jitepengin）です。
プロジェクトを進めていると、あるべき論と現実的な落としどころの間で葛藤する場面があると思います。
要件、設計、技術選定、スケジュール、組織調整、その他諸々あると思います。

理想を貫き通すには、様々な制約がある中では難しく、多くの場面で「妥協」することがほとんどだと思います。
しかし、「妥協」は必ずしも「諦め」や「敗北」ではなく、むしろ制約の中で価値を最大化するための技術であると思います。

今回は、落としどころの探り方と自分の中で納得感を作るための方法を考えてみたいと思います。

ちなみにプライベートでは妻と対立した際には妥協（戦略的撤退）をすることで家庭がうまく回っていたりします。
決して尻に敷かれているわけではありません！

落としどころを探るためのアプローチ

MUST/SHOULD/COULDを分類する

要求（または実現したいこと）の中には、すべてを満たす必要はなく、優先度がある場合が多いです。
落としどころを探る中で、これは本当に必須かどうかを改めて確認すると良いのかなと思います。

例えば

• MUST：守らないと目的を失う
• SHOULD：あったほうが良いが、代替可能（別名、運用でカバー）
• COULD：時間があればやりたい（やらないことが多い）

特に要件定義や設計・技術選定では、この線引きが曖昧だと議論が長引き、認識齟齬も生まれます。
MUSTが明確になれば、妥協ポイントも探りやすくなると思います。

制約を見える化する

できない理由を感覚や感情で語るより、制約を数値化、明文化する方が合意形成は早いです。

• 工数・予算
• チームのスキル
• コスト
• 外部システムとの依存関係
• リリース時期

制約が可視化されると、単なる対立が意見の衝突ではなく状況の分析・議論となります。
その結果、両者にとって納得感のある落としどころが見つかりやすくなると思います。

複数の代替案を用意する

ベストの案（A案）が通らない場合、腹案としてB案やC案の準備があると議論が前に進みます。

• 多少パフォーマンスは落ちるが構成がシンプル
• 初期対応は軽くし、後で拡張できる設計にする
• コストは増えるが、運用負荷が下がる

ここは、完全な妥協ではなく、別の視点での最適解が通ればいいくらいのスタンスで良いかなと思います。
複数案を出す場合、一つの案にあえてツッコミどころを忍ばせておくと、持っていきたい案を通せたりもしますね。

守りたいもののズレをすり合わせる

プロジェクトはクライアント、開発メンバー、インフラ担当者、保守担当者など様々な立場のメンバーで構成されます。
それぞれの立場によって、守るべきリスク・優先順位が違うことが多く、議論が停滞したり、かみ合わなくなる場面が出てきます。

• 開発サイドはあるべき論を元に品質を守りたい
• マネジメントサイドはスケジュールとリスクを守りたい
• クライアントサイドはコストと意思決定を守りたい（費用対効果を最大化したい）
• 保守サイドは運用容易性と可観測性を守りたい

目的は一致していても、守りたいものの順番が違えば話は噛み合わず平行線となることが多いです。
この守りたいもののズレをすり合わせる作業が必要となります。
それぞれの観点で評価軸を設けて判断することが重要です。

妥協とは立場のズレを言語化し優先順位の共通母集団をつくる作業と捉えると意思決定がスムーズになると思います。

自分の中で納得するための考え方

本質が守れたかで評価する

妥協するともっと良い案があったのに…という気持ちが残ることも多いと思います。
納得感を作るには、視点を変える必要もあります。（自己暗示ともいう）

ここでは本当に守りたいものは何かを問うことがポイントです。

• 機能？
• 可用性？
• 将来の拡張性？
• プロジェクトの成功？

最も重要なポイントを守れたのであれば、それは譲歩（敗北）ではなく調整だと考えてください。
致命傷じゃなければ、尊厳を守れればOKくらいに考えると気持ち的に楽かもしれません。

得られた成果に目を向ける

妥協の結果、何が確保できたのかを整理します。

• 納期の遵守
• チームの負荷軽減
• 依存関係をクリアした
• ビジネス側の意思決定が前に進んだ

失ったものではなく得たものをベースに考えると判断の意義が捉え直せるかなと思います。
つまり、あくまでも結果で判断することが重要です。
とはいえ、クライアントのビジネス価値の向上を主眼に置くことが前提になるので、折り合いをつけるのが大事です。

将来の改善余地を残す

妥協は永続的に諦めることではありません。
改善ポイントを明確にしておけば、今回は戦略的に退いただけになります。（負け惜しみに近い場合もある）

• 次回リリースで対応
• 技術的負債として管理
• 検証タスクで先にリスクを潰す

改善の余地があると納得感が得られやすくなります。

振り返りで判断基準を調整する

判断を後悔しないためにあとで短い振り返りをします。

• どの情報が不足していたか
• どの判断が良かったか、悪かったか
• 次回は何を基準にするか

感情ではなく、基準を言語化して蓄積することで次の妥協がより納得できるものになります。

一人で抱え込まない

妥協は個人の判断ではなく、プロジェクト全体での意思決定の結果となります。
多少の責任は伴いますが、あくまでも全体最適化の結果です。
時間が経てば、良い教訓になることも多いです。
とはいえ、どこかで愚痴をこぼすのが精神衛生上いいのかもしれません。

妥協と迎合の違い

妥協は価値を守るための手段で、迎合は自分の軸を失った状態と考えるのも重要です。

• 妥協とは目的を達成するための合理的調整
• 迎合とは誰かに合わせるための無条件な譲歩

この違いを意識しておくと、今回の判断は妥協だったのか？を正しく評価できると思います。

まとめ

実務での妥協は決して敗北ではありません。
限られた制約の中で成果を最大化するための技術です。

プロジェクトには様々な制約があり、理想を完全に実現できない場面は多いですが、守るべき本質を見極め、制約を明確にし、合理的な落としどころを探し、自分の中で納得できる基準を育てることが判断において重要になります。

この記事が、妥協でもやもやした気持ちを晴らすきっかけになれば幸いです。