システム開発でPMをしています。 パッケージに新規モジュールを追加する超巨大プロジェクトで

Question

システム開発でPMをしています。
パッケージに新規モジュールを追加する超巨大プロジェクトでユーザー部門が必要以上に開発の内容に介入しフェーズ定義をわきまえずに状況報告を求めてくることにうんざりしています。

具体的には、設計の初期フェーズでコーディングのイメージや詳細なテスト計画の報告を求めてきます。(すでに入れてあるカスタマイズを新規モジュールにどう載せていくのかの説明をしろという内容です)
設計中フェーズなので検討を進めているところであると伝えたところユーザー部門の上層部にまでエスカレーションをされ開発部門が開発のイメージをもてていないと問題として報告され大騒ぎとなりました。

ユーザー部の担当は開発経験の浅い超若手です。
プロジェクト管理や組織論の正論で相手の認識が誤っていることを冷静に反論したいです。
同じ業界の方、同じ状況ならどう対処しますか？

Answer 1

既に初動で失敗している印象を受けますねえ。結構敗戦処理になるのでは。

超巨大プロジェクトということは、事前に検討が行われていたはずですよね？
当然に時系列に対しても立案がされて資料化されていたのではないですか？
ユーザー部門の上層部に、全然できてないという印象を持たれたということは
この事前資料にそれらの検討が抜け落ちていたという事なのではないですか？

もし自分がユーザー部門の上層部だったら、初期資料でプロジェクトの
ネックポイントとして挙げられて居れば、そこは懸念点が発火しただけと
受け取られるだけで大規模な炎上状態になるとは思えません。
もちろんそこは何とかなるのか？みたいな確認は入ると思いますし
回復が無理なら何らかのアラームが鳴り響くことにはなると思いますけど
それで開発部門が失敗したかのように言い立てられる事は無いかと。

今回はユーザー部門が「騙された」と思ったんじゃあないですか？
でなければ末端の担当の言うことを上層部に安易に同意はしないでしょ。
一度そういう印象を持たれてしまうと非常に修復は困難になるかと思います
まずは相手を悪者扱いするのを止めて
両者の認識のすり合わせをするのが第一優先だと思いますよ。
相手に誤解があるなら正し、こちらに不備があったら詫びるところからですね。

Answer 2

ユーザー部が素人考えで現場を混乱させている、と上司に■文書で■訴えます。

紙に出力し、日付、署名は手書きで、そして押印しましょう。自分は勿論、生でを記載する場合には必ず部署役職まで全て含めたフルネームで記述します。
その文書の中で『プロジェクト管理や組織論の正論で相手の認識が誤っていることを冷静に反論』しましょう。
落ち着いて考えること、相手が実際にやらかしたことを何年何月何日何時何分まで厳密に時系列に沿って書きましょう。
用紙はA4で文字は24ポイントなど大き目にして、ご老人にも見易くしましょう。会社のロゴなどのテンプレートがあるならばそれを利用して正式な文書っぽく仕上げましょう。

論文などの書き方を参考にして、最初に主旨と結論、途中に大量の事例（一つ一つを詳細に長目に書くのがコツ）、最後にもう一度主旨と結論を（今度は同情に訴えるように）書きます。普通は概要を掴む為に最初か最後だけを読みますので、このように書くことで、事例の一つ一つを検討するよりも先に意図通りの印象操作が可能になります。

Answer 3

＞ユーザー部の担当は開発経験の浅い超若手

転職の準備をします。ユーザに付け入る隙を与えたので、あなた方のチームは早々に浸食されて全くの役立たずの集団になります。それは、非効率を煮詰めたような産廃ということです。

初手で対応を間違えたからです。わざとそういうところに超若手の人材を配置した人間も何かしらの意図をもってそこに配置したと思われるので、何かしらの旨味があってあなた方のチームの空中分解を望んでいるからです。

つまり、介入するための窓口をわざと設けたという意味なので、これはもう転職するしかないです。炎上必死であり、ともすれば自殺者も出るプロジェクトになるので、それなりの手柄を立てたらいいところで逃げます。

要するにかなり初期でユーザのクレーム対応をミスったので反射のように付け入られて終わりです。あなた方はカネを吐き出すだけのハコになるからです。

Answer 4

> 開発の内容に介入しフェーズ定義をわきまえずに状況報告を求めてくる

これが全てなんでしょうね。フェーズ定義についてそれぞれのフェーズでどこまでを報告するのかをはっきりとさせ、しかもそれを第三者（上層部）を交えて説明することはできませんか？