トラブルを報告したくなる風土を作る − @IT情報マネジメント(情報元のブックマーク数)

失敗は伝達ミス、形骸化によって起こる。

想定外の出来事が発生したとしても、早期に発見できれば大抵のことは解決できるからです。プロジェクトが頓挫するような大きなトラブルも、最初は小さな予兆からなのです。
「それなら、早くプロジェクトのメンバーなどに報告させるルールを作ればよいじゃないか」といわれる方もいらっしゃるかもしれません。しかし、これはルールを作ればよいというものではないのです。進ちょくミーティングを週1回行うだけでは、トラブルを早期発見するには十分ではありません。
なぜでしょうか。下を見てください。「失敗学」で有名な畑村洋太郎氏は、『失敗学(図解雑学)』(畑村洋太郎著、ナツメ社刊)で、次のように述べています。

1. 失敗の多くは、「情報伝達の途絶」で起こる(タテとヨコの情報断絶、「壁」)
2. 部分最適が「全体最悪」をもたらす(これについては、、全体を知ってそれを踏まえて自分の仕事ができる社員を育てていくしかない
3. 「管理の強化」では、失敗は防げない(管理強化一辺倒では形骸(けいがい)化しやすく、「面従腹背」が起こる、失敗を臆するようになるため、結局、いろいろな部門で同じような失敗が起こる)

 つまり、ルールや仕組みで管理を強化するだけでは、トラブルの早期発見は難しいのです。それでは、どうすればよいのでしょうか。

トラブルを報告したくなる風土を作る (2/2) - ITmedia エンタープライズ

トラブル報告に感謝とメンバーとのコミュニケーションや言葉尻を気にして会話って感じかな。

答えは1つです。「プロジェクトマネージャにメンバーがトラブルを報告したくなる」雰囲気を作るしかありません。ポイントは3つあります。

  • トラブルの報告に感謝する
  • 自分から情報を取りに行くため、メンバーには自分から聞く
  • いざというときにメンバーを守る(お客さまに怒られるのは自分の役目)

企業によっては、開発工程にチェックポイントを設け、トラブルを未然に発見できるように仕組みを作っているところもありますが、そのような仕組みはあくまでもメンバーからの報告の補助にすぎません。プロジェクトリーダーがメンバーから信頼されることが、最も有効なトラブル防止策となるのです。

トラブルを報告したくなる風土を作る (2/2) - ITmedia エンタープライズ

screenshot