プロジェクトチームの対立をどう扱うか：立場の衝突から問題解決へ戻る
プロジェクトの成果物をめぐって意見が割れたら、譲歩を求める前に現在の約束に戻ります。必要な成果、日付、使える人員、見積もりの根拠を確認し、調査すべき疑問と権限を持つ人が選ぶべき事項を分けましょう。「もっと協力する」という呼びかけだけでは、足りない時間は増えません。 この方法は、実際のプロジェクト上の約束に影響する対立を扱います。人柄ではなく、変更が必要な仕事に注目します。結論は範囲の調整、順序の変更、根拠のない追加要求を受け入れないことでもよく、二つの主張の中間である必要はありません。
変更点を現在の約束と並べる
少人数のチームが社内ワークショップのデモを準備しているとします。合意した内容は三つの機能ですが、一つ追加してほしいという要求が出て、担当者は確認時間がなくなると考えています。これは仮の例です。まず現在の範囲と開催日を確認し、四つ目の機能が以前からの約束か、新しい要求かを調べます。
追加する動作、必要と思われる作業、影響する確認を具体的に書きます。未検証の所要時間は見積もりと明示します。参照している範囲の版が異なるなら、先に現行版を確認します。作業速度の対立に見えて、実際には別の成果物を準備している場合があるからです。
各立場が守ろうとする条件を確かめる
今すぐ追加したいという意見は、参加者に必要な学びを守ろうとしているかもしれません。追加を見送りたい意見は、必要な確認を守ろうとしているかもしれません。参加者が何を見て何をできる必要があるのか、どの確認が欠かせないのかを聞きます。見栄えをよくしたいという希望と、確認済みの必要条件は分けます。
Harvard の Program on Negotiation は、立場とその背後の利害を区別し、客観的な基準を使うよう勧めています。ここではプロジェクトで合意した成果と根拠を基準にします。相手の動機を決めつけず、整理した内容がその人の重視する条件を正確に表しているか確認します。
技術上の疑問と範囲の判断を分ける
既存の部品で追加機能を実現できるかが争点なら、担当者、使える時間、観察する結果を決めて限定的に調べます。機能全体を作るのではなく、該当部分を確認します。何が分かれば案を実行可能と見なせるか、何がなお不明なのかを先に決めます。
追加作業が時間を超えることを全員が理解しているなら、技術の議論を続けても選択は進まないかもしれません。必要なのは範囲、日程、人員の判断です。反対に、小さな検証が成功しても追加作業の承認にはなりません。検証は判断の根拠を提供するもので、権限の代わりではありません。
追加要求がなくても、同じ区別は必要です。合意済みの成果に対して二人が別の実装方法を提案したとします。同じ入力、動作条件、受入基準でそれぞれの前提を比べ、自分の案を否定する観察結果は何かを双方に尋ねます。限定した比較で、依存する作業の見落としや条件の違いが分かる場合があります。確認済みの部分と残る未知を記録し、役職の高さを実現可能性の証拠にしないでください。
選択肢の影響を成果物全体で見る
元のデモを維持する、責任者の許可を得て既存の一機能と入れ替える、後の機会に追加するなど、実行できる案を比べます。準備、確認、配布資料、関係者への影響をそれぞれ記します。会議にいない人の作業が必要なら、その人の時間を勝手に約束しないで確認します。
Atlassian の Project Trade-Off Analysis は、範囲、時間、費用、品質、リスクの柔軟性を検討し、新情報が出たら優先順位を見直します。問いだけを借りてもよく、会議形式を丸ごと導入する必要はありません。日付を変えにくいからといって、必須の確認が省略可能になるわけではありません。
実行できる判断で話を閉じる
現在の権限に従って、元の約束、確認した事実、未確認の仮説、各案の影響を提出します。日付の変更や増員の権限がない場合は明記します。決定後は採用した内容、変更作業の担当、置き換えられる指示を記録し、関係者が次に動けるか確認します。
PON の交渉チームに関する説明は、課題についての意見の違いと個人への攻撃を区別します。対立が必ず成果をよくするという保証ではありません。次の確認時点で必要な成果と仮説を見直し、必要ならその判断を再検討します。過去の議論を、同僚への変わらない評価にしないことが大切です。