見出し画像

反省するだけならサルでもできる

一昔前にテレビに反省する猿が出てきて、茶の間をにぎやかしてくれました。

そこから「反省だけなら猿でもできる」という言葉が生まれました。
この猿と同じような光景を見かけることはないでしょうか。

PMO(プロジェクト・マネジメント・オフィス)の立場で、トラブル・プロジェクト(不採算・納期遅延など)の反省会…一般には「完了報告会」とか「振り返り」とか言いますが、これに参加すると、会社幹部や他部門からの指摘に「申し訳ありません」「反省しています」など機械的に反省の弁を述べるマネージャーがいると聞きます。

これだけでは、自己保身を目的とした処世のための安全弁にはなっても、"再発防止"の観点からみると、全く役に立っていません。そう、

 何一つ解決していない

のです。

私は…トラブルプロジェクトの火消しに参加して、ユーザーに説明しに行ったことや振り返りに参加することも幾度とあるんですけど、一度も謝ったこと無いんですよね。まぁ、トラブらせたのは私じゃないし。ってか、謝りたくなかったわけではなくて、それ以前に「謝ってる暇があったらもっと他にすることがあるだろう」と、心の中では常に行動することしか頭になかったもので。

そもそも、問題を指摘する側としては、起きてしまったことはもうどうしようもないので、今後のことを考え、原因を特定し、再発防止をしてほしいというだけなんですから、それに対して謝って見せたからと言って、不採算納期遅延も解決することは絶対にないってことは肝に銘じておきたいですね。

謝る暇があったら1分1秒でも早期に解決する努力、早期に再発させない対策を行う努力をするべきで、その解決の足掛かりとするためにも「何故そうなるまで放置していたのか」その理由を明らかにすべきなのです。

こればかりは『スキル不足』や『能力不足』で説明はつきません。

指摘する側としては、

 ・既にボヤが出始めた時点でなぜ報告しなかったのか
 ・自力では対策できなくなった時点でなぜ周囲に助けを求めなかったのか
 ・IT企業として、
なぜそうなるまでプロジェクトを放置し続けたのか

など聞きたいことはいくらでも出てくることでしょう。
もちろん、お客さまの立場であっても同様です。

また「このプロジェクトは当初から非常に難しいプロジェクトであった」あるいは「顧客の仕様変更や要求が厳しくて、不採算プロジェクトになってしまったのは仕方がなかった」というような顔をして、何の反省も感じられないプロジェクトの反省会も、世の中ではあると聞きます。

プロジェクトが失敗に終わったのであれば、失敗した原因を追究し「同じ失敗を二度と起こさないぞ」という心構えで、そのためにはどうすればよいかを、前向きに真剣に考えることこそが「反省会」の重要なテーマであり目的でなければなりません。

この目的を果たせなかった時点で、その完了報告会は時間とコストの無駄と言えます。反省会そのものですら、「まだこれ以上、マイナス評価を受けるようなことを積み重ねようと言うのか!?」と言われる行為にしかなりません。ただのポーズは要らないのです。

もし、失敗やミスをしたら反省をしなければ意味がありません。
反省だけしても、次に活かされなければ意味がありません。

反省は、上手に活用すれば『再発防止』『能力向上』に大いに役立ちますし、その取り組み方次第では今まで以上の信用を勝ち取ることも夢ではありません(まさにグッドマンの法則ですね)。ただただ、迅速に正確に、問題に対する対策を講じ、行動に移せばいいのです。それだけで、相手の評価はガラリと変わります。

画像1

グッドマンの法則は、購買反復行動に関する統計結果によるものですが、人はそれぞれプライベートでは一般消費者となる以上、心理的にはビジネスでもプライベートでも全く同じ傾向を示すはずです。

反省時には、一般的に次の2つのプロセスを実行することになるはずです。

プロセス1

 失敗の「真の原因」を徹底的に究明する:動機的原因の追求
 なぜ?なぜ?を繰り返すしつこさが必要です。
 時には「5W1H」で考えるのも有効です。

プロセス2

 二度と同じ失敗をしないように「行動を変える」:再発防止
 行動を変えるには、「思考や考え方を変える」必要もあります。
 時には仕組みを変えることも有効です。

このプロセスを中途半端にしたまま反省すると「反省だけなら猿でもできる」ということになるわけです。「同じ失敗はめったに再発しないが、同じ"ような"失敗は必ず発生する」という経験則に基づき、同じような失敗を再発させないためにはどうすればよいかを考え、議論することに意義があるのです。

成功や失敗の情報は、客観的に整理されていることが必要なのは言うまでもありません。これは、成功や失敗の詳細をつかむのにも大いに役立ちます。

しかし、これを新しい仕事に役立てるには、正確な経過や原因の他に

 「どうすればよいのか」

という知識化された情報が必要になってきます。

以前から、知識の"蓄積""活用"というナレッジ・マネジメントの重要性が叫ばれていますが、一番大事なことは、ナレッジ(知識)そのものが充実しているかどうかで、活用方式はその次の話です。すべては、成功や失敗情報が、他の人が活用するに値するナレッジ(価値知識)になっているかどうかなのです。

つまり、他の人が見て役立つような分かりやすい情報として纏め、知識化する必要があるということです。

たとえば、失敗や事故情報がなかなか伝わりにくいのは、

 失敗や事故自体を知られたくないとか、
 隠したい、恥ずべきものと感じること

がその原因です。それ以外に大層な理由はありません。

しかし、失敗や事故から得た教訓や再発防止策のような前向きな知識であれば、誰にも気遣いは不要なのです。その知識が拡がったとしても、当事者が不利になることはまずありません。正しい知識であれば、広く伝わった方が会社や組織に役立つからです。

 『知識化』

とは誰にでも役立ち、誰にでも伝わりやすい形にすることです。
コミュニケーションにおいては当然中の当然ともいえるべき観点です。

プロジェクトの反省会などで利用される資料も、真の意味で知識化されているか見直し、他の人やプロジェクトにとって役立つ記録にしなければなりません。

逆に言えば、そうなっていない報告や文書はただの自己満足でしかなく、本当に意味のある知識化には貢献できていないことを意味します。

ポーズとしての反省なんて要らないんです。1円の価値もありません。そんなものは芸を仕込まれたサルでもできることです。「反省」は常に、次の行動でのみ示すことができるものだと言うことを忘れないようにしましょう。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。