システム開発では様々なステークホルダーと関係を持つことになります。
プロジェクトを成功させるためには「みんなで協力してゴールを目指す」ことが重要です。
しかしプロジェクトによってはステークホルダーの利害や立場により関係性がうまくいかないこともあります。
そんなトラブルの１つに「ユーザがベンダに対して高圧的な態度をとる」があげられます
この状況は昔に比べて落ち着てきたと思います。
というのも、上下関係をつくるのではなく大切なビジネスパートナーとして対応していただけるユーザが増えてきたと感じています。
本当にありがたい話で、仕事のしやすさにも大きく影響していると思います。
しかし残念ながら令和の時代にあってもベンダを見下すユーザというのは存在します。
ベンダ側に問題があったとしても高圧的な対応は何も解決しません。
それ以前に問題有無に関係なくパワハラと評価されてもおかしくない言動を耳にすることもあります。
人間関係のトラブルは様々で、逆にベンダ側に問題がありプロジェクト遂行に支障をきたすこともありますが、その対処法は別の機会で話をするとして、今回はユーザ側が高圧的な場合を取り上げたいと思います。
※この構図が最も解決困難だと思います。
高圧的に接するとは
ユーザがベンダを高圧的に接するとはどういう状況でしょうか。
次のようなことはよく聞く話です。
・必要以上に責め立てる、個人攻撃する
・トラブル発生時、責任の所在を確認せず一方的にベンダを責める
・不当な作業環境や待遇を強いる
・ベンダの意見を聞かず一方的に仕事を押し付ける（ユーザ責務の仕事を肩代わりさせるなど）
人によっては、話し方や雰囲気が高圧的に見えるだけの場合もあります。
そういったケースは、今回は対象外です。
そのような場合はコミュニケーションを取る機会を増やし、相手の理解を深めることである程度は解消できます。
ここではユーザとの交渉や作業調整に支障がでたり、PMやメンバに体調不良がでるような事態を想定しています。
このような事態になると、何かしらプロジェクト遂行に支障が出ます。
場合によってはプロジェクト中止となることもあります。
では、そのような事態になったら誰に責任があるのでしょうか。
ここで過去にシステム開発未完成における法廷紛争の結果を見たいと思います。
論点の一部に「ユーザ側の高圧的な態度に問題があったのでは」というものがありました。
これは平成19年12月4日の東京地方裁判所の判例です。
ユーザ側は未完成の責を問い、ベンダ側はユーザの高圧的な言動によりPMがメンタル不調で離脱せざるを得ず、それが原因だった反訴しました。
結論からいうと、「ユーザ側の責任なし」「ベンダ側の労務管理に問題がある」という判決でした。
これはユーザ側が何を言ってもいい、という話ではなく、ベンダ側のプロジェクト管理が不十分だったということです。
ここでポイントとなるのがプロジェクト管理能力もそうですが、労務管理を問われている点です。
この件ではPMが体調不良となった原因として、ベンダ側がPMの状況を把握しておらず、適切な処置を行っていなかったことを指摘しているわけです。
つまり法律的にも組織として動く必要があるということです。
ＰＭがとるべき対策
ユーザが高圧的な相手の場合、ＰＭが取るべき対策について話します。
PMが取るべき対策と言っていますが、上記で述べたようにPMで対処できない問題については、個人ではなく組織として動く必要があります。
ＰＭの上司に相談
まず大前提であり最重要ポイントが「上司に相談」です。
ユーザが高圧的でプロジェクト遂行に支障が出ている場合、PMが対策して解消される状態ではないと思います。
粘り強くPMが交渉するのも良いですが、解決の糸口が見えないのであれば素直に上司へ相談し、アドバイスや対策を検討するべきです。
もし上司では対処できない場合は、上司に声掛けをしたうえで、さらに上役に相談したり同僚にアドバイスをもらうなど組織を頼ります。
個人で全て受け止めるのは限度があります。
ここで少し話を脱線させて「PM上司の役割」について触れたいと思います。
プロジェクトに参画しているメンバの状況をチェックするのはPMの役割です。
そのＰＭの状況をチェックするのは誰かというと、それはPMの上司です。
その上司がプロジェクト状況を詳しく知る必要はありませんが、次の３点については意識する必要があると考えています。
PMとの関係構築
日頃からPMと会話をしてコミュニケーションを取ることが大切です。
PMのメンタル状態や問題の有無を知ることも目的ですが、日頃からコミュニケーションを取ることでトラブル発生したときにPMから相談してもらえる関係を作ります。
日頃から会話しない相手にトラブル相談することは出来ません。
ユーザとの関係構築
ユーザからプロジェクトで困り事があったときに相談もらえる程度の関係を構築します。
例えば次のような対応を上司が行う場合、関係構築ができていると調整がしやすいです。
・プロジェクトに携わっているPMに言いづらいクレームを受け付ける窓口
・PMでは対処できないトラブル発生時の対応
・PM交代の交渉など
プロジェクトの最初だけ挨拶する程度ではなく、定期的にユーザ先に訪問するなどコミュニケーションを取って関係構築することは大切です。
ＰＭ能力の把握
PM任命後、問題なくプロジェクトが遂行されているかチェックします。
当然、PMごとに能力にはバラつきがあるため、PMの気づかない問題が起きていないか確認し、必要あれば指導します。
状況によってはPM交代という選択肢もあります。
任命したら全てお任せではなく、PMの行動には気を配ります。
ユーザの考え方を分析する
少し脱線が長くなりました。
次から対策方法について見ていきます。
ユーザが高圧的になっている理由はいくつか考えられます。
- プロジェクト遂行力が期待値に達していない
- ユーザとベンダで認識に齟齬がある
- ユーザの社内事情（企業文化含む）
- ユーザ個人の性格
まずは、その背景や理由について考察します。
ユーザに直接ヒアリングできれば良いですが、正直難しいケースが多いと思います。
そのようなときはユーザの言動をもとに分析を行います。
ＰＭが一人で分析しても思い込みにより意見に偏りが出るかもしれないので複数人、特にプロジェクト外の意見を取り入れることは有効です。
また複数のステークホルダーが登場する場合は、相関関係を図式して考えるとイメージしやすいです。
プロジェクトで対応策を検討する
上記でユーザの考えを分析したら対策を検討します。
分析結果や対策は仮説でもよいので対策案を検討します。
この対策案は、今後のユーザ交渉で利用していきます。
一方的に「ユーザが悪い」「ベンダ側が悪い」と決めつけるのではなく幅広い視野で考えていきます。
対策を検討するには「なぜなぜ分析」が有効です。
対応策を検討したら、ベンダ内でレビューを行います。
特にユーザ側に要求事項がある場合、入念にチェックを行います。
ユーザ交渉
ユーザの高圧的な態度を軟化させるためにユーザと交渉します。
もしベンダ側に問題がある場合でも、問題点を認識して対策を取ることを宣言します。
ユーザ側に要求事項を出す場合は慎重に行います。
プロジェクトに問題がある
プロジェクトに問題がある場合は検討した対応策を提示します。
もし仮説が外れたとしても、それは問題ありません。
仮説をもとにブラッシュアップしていくことで、真の問題点を見つけることができます。
重要なのは、自ら改善していこうとする姿勢を相手に見せることです。
ユーザに問題がある
ユーザ側に問題がある場合、ユーザ側に是正依頼を出します。
当然ハード交渉となるためベンダ側の社内で十分に方針を検討したうえで行います。
交渉において、もしベンダ側にも問題点がある場合は先にユーザに改善提案を提示します。
もしユーザの特定人物に問題があるのであれば、ユーザ側の上司に相談を持ち掛けます。
その際は、ベンダ側も相手側の役職にあった上役に同席してもらいます。
この交渉は非常に難しいのですが、何かしら手を打たないとメンバの負担が減りません。
ユーザ側の不興をかわないように穏便に済ませたいところですが、形だけで実態が変わらなければ意味がありません。
その交渉が難航するのであれば、ベンダ側のメンバをベテランなどに交代することも調整します。
契約形態によってはプロジェクト撤退も視野にいれて臨みます。
これは私の個人的な意見ですが、理不尽なユーザと無理して付き合うくらいなら他の案件を探すべきです。
メンバが退職するリスクを考慮して、それでも無理して付き合わなければいけない相手なのか見極めましょう。
※「それでも付き合う」というベンダ回答になるようなら、それこそ問題なのですが。
おわりに
日本のベンダ企業は、「お客様は神様」という考えが少なからずあると思います。
ＩＴバブルがはじけた後、仕事がなくて文句を言えない、また言わないのが当たり前の時代がありました。
その流れが今に残り、現場メンバが耐えて頑張らないといけない風潮があると感じています。
しかし、今はそのような時代ではありません。
ユーザとベンダが協力しながらプロジェクト推進することが求められています。
もし不当に高圧的な対応を受けるのであれば無理に付き合わず、他案件に切り替える方が健全です。
ただし、それはベンダがやるべきことを行っていることが前提です。
しっかりやっていると胸を張って言えるためにも、プロジェクトマネジメントの学習は継続していきましょう。
