■前年度の反省 （No.061）
多くの会社では４月より事業年度が変わったところである。新しい事業年度を始める前に，必ず前年度の反省がある。ここでは，その反省に注目してみる。そのほかにも，ある仕事が終わったとき，或いは一定期間が過ぎたときなど，これまでやってきたことに対して，振り返りと云うことをやることがある。上手く行ったこと，逆に上手く行かなかったことなどを反省して，次のステップで活かそうとするものである。しかし，その振り返りの中身がどれだけ充実しているものか否かによって，単なる形式の反省会で終わるか，次のステップでの大きな飛躍につながるかの分かれ目である。そこで，反省に関する主なポイントについて述べて見る。
計画時点で，明確な目標（数値化されたもの）があり，目標に対する実績値があること振り返りの第一のポイントは，まず自分が立てた計画に対して，計画通りできたか，否かを見ることである。そのためには，最初に明確な目標があることが必要な要件となる。目標が曖昧だと，できたかできなかったかの判断がいい加減になってしまい，本当の意味の振り返りにならないことがある。計画と実績の差が判ることが重要なのである。この差分が良くても悪くても反省材料になる。通常は，目標を定めて活動するが，必ずしも明確になっていない場合もある。こうした場合，振り返り時点で，どのように判断するかが，主観的なものになってしまう恐れがある。こうなると，見解の相違など見方で如何様にも判断できるため，真の振り返りができないこともある。
計画（予測）と実績の差に対して，その要因分析がきっちりできていること次に，計画（予測）と実績の差がでれば，その差の要因を分析する。計画時点では，ある程度予測値として決めたものが，実際やってみると，違った結果となることがある。そうした場合，なぜ計画時点で予測したことと実際とが違っていたかについて，あらゆる観点から眺めて見る。環境の変化，自分の能力の見込み違い，プロセスの不具合，モチベーションが非常に悪化した，などその要因は様々である。思わぬリスクが発覚した場合もありうる。そうした要因を先ずは洗い出す。次に，その要因となる本当の原因が何だったのかを探る。
これには，なぜなぜと５回繰り返すことが有効とされている。表面的なことでなく，本質的な原因を抽出することが望ましい。しかし，これは一朝一夕にはできないし，ある程度経験が必要である。そういう意味で，いろいろな人に参加してもらって分析することが望まれる。そうして抽出した真の原因に対して，一番効率の良いもの（効果が大きいもの）から手を打つようにするとよい。
効率で測るものと，質的なものや創造性を求めるものとは区別すること明確な目標値を立てたのでその実績値が１００％達成した。だからこの活動は申し分なかった。とするのは早計である。もちろん，目標値なのでそれが達成したか否かで，できたできないの判定を下すことは正しい。それは評価基準の一つであって，だから十分だったとは言い切れないものがある。それは，目標とした数値は達成したが，本来活動目標としている中身の評価はこれだけでは不十分である。活動の中身，即ち，質の部分も十分吟味しておく必要がある。数値目標の８０％しか達成していないが，中身の活動は充実していて，１００％達成を上回る効果を上げている場合もある。これは，あまり点数ばかりを追い求めると，点数を稼ぐことが目的になって，本来の目的を見失う危険性がある。
特に，リーダになっている人はそうした中身の見極めまで十分しないと，目標値は達成しているが，効果がはかばかしくないようなことにならない注意が必要である。これと同じようなものが，創造性を求める場合である。特に,技術開発などでは，新規性，特許性など数値化が難しい評価尺度がある。こうしたものに対する見方の基準を単なる効率とは区分して明確にしておかないと，真の会社貢献が活かされないことになり兼ねないので十分配慮しておかなければならない。
特殊なことでなく，一般化されたものであること（汎用性があること）振り返りをする場合，いろいろな反省点が出てくることは歓迎すべきことであるが，そのプロジェクト固有の現象や，特殊条件下での現象を深く追っかけることは,本来の目的から外れることになる。つまり，反省（振り返り）は，次に役立たせるために行うのであって，当該プロジェクト固有の現象を詳細に振り返っても，次には役立たず，無駄になることが多い。
固有の現象であっても，より一般化，汎用化させて，次に役立つものにさせるべきである。この点についても，リーダが上手く誘導することで，振り返りが活かされるか否かの分かれ目になってしまうので注意したい。
できるだけいろいろな観点から振り返りをすることプロジェクト開発者だけで振り返るより，プロジェクト関係者全員で振り返る方がよい。何故ならば，開発者だけのように，一方側のものだけで振り返ると開発側から見た視野が狭い範囲での振り返りに終わってしまう。それよりも，そのプロジェクトの関係者，営業，企画，生産技術，購買，品質保証，製造などが一同に介しての振り返りの方が，多角的な振り返りができ，また，意見に誘発されて見出す反省点も出るなど効果が大きい。もちろん，開発側だけで技術問題点を深彫りしたい場合は，それだけを別にやればよい。また，こうした振り返りは，いろいろな角度からの意見が出て，お互いが学び合うことにもなる。
人への追求でなく，起こった現象に対する仕組みを考えることこの反省（振り返り）で注意することといえば，起こった現象に対する反省を他人のせいにしないことである。自分たちの問題として捉えて，反省すべきである。また，それも人への追求でなく，仕組みの問題点として捉える方がよい。個人のスキルに起因させてしまうと，そこで問題が止まってしまう。或いは，個人への責任のなすりつけ合いのような形で，仲間同士で傷つけ合うだけで得られるものは少ない。
[Reported by H.Nishimura 2008.04.07]
Copyright (C)2008 Hitoshi Nishimura
