当たり前のことを書きますが、改めて需要だなと思ったので文章化します。

状況はその時によってさまざまですが、ITに限らずプロジェクト内で発生する交渉ごとプロジェクトの成功を左右する重要な要素です。

どんなに技術的に、ビジネス的にうまくいっているプロジェクトでも、すべてのステークホルダーが納得できる形に交渉によって方向性をまとめあげなければ、プロジェクト終了前にメンバーの協力が得られなくなってプロジェクトが全体が失敗に終わってしまいます。

特に、複数の企業や複数の部署と様々な組織のメンバーが絡んいる場合や、メンバーの利害関係が複雑かつ「どちらかを立てれば、どちらかが立たず」のように相反している状況では交渉によってプロジェクトの目的、方法、予算、スケジュールなどに合意(いわゆるコンセンサス)をとっていなければ破綻します。

となると、まずは技術や営業といった役割や部署ごとに存在する組織から検討事項に対する方針や自分たちの立場を決めておき、徐々に企業といった大きな単位で決定を行っていく必要があります。

企業間の交渉でいつも仲間割れする先方

筆者が2年ほどベンダーの立場でプロジェクトを実施していたある製造業の顧客は、週次で実施していた企業間の進捗打ち合わせにいつも2,3部署の担当者が出席していたのですが、よく先方の部署間でプロジェクトの推進方針に関してもめてしまい、2時間の会議が1時間、2時間と延長してそれでも決まらないということがよくありました。

データ活用のための分析システム構築のためのPoC(技術検証プロジェクト)でしたが、PoCの実施方針が迷走するので常に進捗は振るわず、最終的にベンダー側のこちらから成功の見込みがないということでプロジェクトから降りる事になってしまいました。

どうやら、毎週先方は他社である我々との打ち合わせの場で初めて顔を合わせてお互いの認識を合わせていたようです。

内である社内の人間との調整は内でしませ、方針(長期的、短期的な目的や現時点で最低達成したい事項)を決めた上で外の人間との交渉に望むべきだとその時感じました。

現状は先方は単体で2万人、グループでは10万人の社員を抱える大企業で子会社間とのコミュニケーションも発生していたので、週次のベンダーとの打ち合わせの前にコミュニケーションを取ることはほぼ不可能だったのだと思います。

じゃぁ何が悪かったというと、外部との打ち合わせを毎週設定していたこと、そしてベンダーからの報告に対してその打ち合わせの場で方針を決めるのでは、一旦うちのメンバーに持ち帰って意見を合わせる必要があったと思います。

それでは、プロジェクトの推進スピードが遅くなってしまうというのが本音かもしれませんが、正直醜い社内での争いを他社に見せて、何も決められずにプロジェクトが破綻してしまうよりはマシです。

これ以外にも、こちらの営業と先方の現場部門、こちらの技術と先方の情シス部門が手を組んでまるで応仁の乱のように会社間をまたいで争うなんてこともありました。最終的に協力していた勢力も意見が合わず四つ巴の戦いになり、1ヶ月以上スケジュールが遅延しましたが、最後は奇跡的に各勢力の意見が1つにまとまりそのまま継続することができましたが、やはり内側で方針が揃ってない状況は避けるべきだったと思いました。

個人、タスクごとのチーム、部署、会社と小さな組織から意思統一を測っていく

プロジェクトチームは小さなチームの集合体ですが、小さい組織から認識を合わせていき最終的にプロジェクト全体で意思決定を図るのが丁寧な運営だと思います。

もちろん、検討事項によってはここまで労力を払って意思統一を図ることは必要ないかもしれませんが、ですが破綻のリスクがある事項はしっかり内では方針が決まった上で外に対して交渉を挑むという姿勢を徹底するべきです。

そして、ここで重要なのは一旦組織内で方針がきまったら全体条件が覆ることがない限り後で変えないことだと思います。メンバーによっては納得していない場合もあるかもしれませんが、次の交渉に臨む責任者に任せて後から文句を言わないことは重要です。

絶対こうすべきということは存在せず、常により良い選択を考えることが重要だと思います。

それでは。