White scenery @showyou, hatena

If you have any comments, you may also send twitter @shsub or @showyou.

補助部門と製造部門の乖離

「速度は守ってるよ!」「だけど逆走ですよ」――プロジェクトが暴走する原因 (1/2)
http://mag.executive.itmedia.co.jp/executive/articles/0803/13/news011.html

半ば愚痴っぽくなってしまうのだけど、いろいろ思うことがあったので書く。

大企業某社のA事業所の例である。製造部の生産管理システムを構築するに当たり、情シがまさに「リーダーシップ」を発揮した。(略)。製造部はシステム構築に積極的にコミットメントするとは宣言したものの、日常業務に追われて、どうしても実行が伴わなかった。


 まずプロジェクトチームを発足させる際、優秀なB生産管理課長を専従員として派遣しろというプロジェクト側の要求に対して、製造部はBを「半専従」という形で派遣した。Bが(略)午前中はライン業務に従事し、午後にプロジェクト室へ出かけてきた。そして残業時間になると、またラインに戻った。


(略)。Bは日頃関係者から頼りにされていたが、それだけにライン業務を離れられず、日がたつにつれて午後のプロジェクトの時間が削られ、1カ月もするとプロジェクトに顔を出さない日もあった。一方で、製造部は自分たちの要求をなかなか整理できず、些細なことや当面の問題にこだわったため、プロジェクトチームと製造部の定例打ち合わせ会議はたびたび紛糾した。


 (略)C情シ課長は、プロジェクト進行の半ばで製造部に期待することをあきらめ、このまま行くとプロジェクトの期限も守れないと判断。製造部を無視し、情シペースで行くことを決心した。

 中堅企業D社の情シでは、情シは黒子に徹するというのが伝統的考え方だった。要するに、情シは前面に出てはいけない、常にユーザー部門を立てて、ユーザーを前面に押し出すのだということである。(略)。そこでは、情シの遠慮がプロジェクトの進行を、しばしば妨げる結果を招いた。

 中堅企業E社のF情シ課長は、(略)。ユーザー部門の無理な要求を、そのままベンダーに押し付けた。いったん約束した仕様を無償で変更させた。(略)。当然、ベンダーとの間はギクシャクし、納得できるシステムが完成するわけがない。

ちょっと立場は違うんだけど、割と遭遇してることは似てるかなって思う。
今の私をA,別の立場の人をBとする。

  • Aは情シに近いもの(近いだけで実際は違う)
  • Bはユーザ部門

この条件の下私が遭遇してるのは次の通り。

  • Bの立場の担当が半専従。課長は比較的専従だが課長と担当の間で認識のずれがある
  • ユーザ部門を立てるべきと言われる
  • ユーザ部門の無理な要求をベンダーに投げる

・・全部じゃん!

先のblogで対策としてこう言われている。

 なぜ、彼らはそうなるのか。実は、情シの社内地位が相対的に低いことに原因がある。その裏返しとして、あるいは場合によってはそれがそのまま現れるのである。


 問題は、彼らがその間違いに気づいていないことである。彼らは、リーダーシップをとり、ユーザーを立て、はたまたトップの方針を忠実に実行している「つもり」なのである。


 A事業所の場合、B課長を思い切ってラインから抜いて専従にすればよい。できなければトップが決裁すべきだが、トップを説得するのは、C情シ課長の任務である。
(略)。


 情シには、IT導入に当たって求められる本来の活躍を大いにしてもらいたい。


 しかし、Bを引き抜けずにマイペースに陥ったA社のC課長のように、あるいは「存在価値」のまるでないD社の情シや、「イエスマン」のE社F課長のように、(略)

以上を踏まえると、

  • B側の課長を専従にする。また担当との意識共有を持ってもらう。担当がラインで忙しいならB側課長が意見をまとめられるようにする
  • 目的を達成するならば、ユーザの意見だけでなく、こちらの意見も出して議論すべき。折り合いつけられるところはつけるべき

となるのか。