「なぜ同じ間違いをするのか」
「前回の反省会で、その問題の原因が明らかにされたのではなかったのか」
残念ながら、上のやり取りは開発組織の中で、よく見掛ける光景です。
どうして要求が漏れたのか？
取り掛かりが遅れたため、顧客との打ち合わせの時間を多くとれなかったから。
どうして納期が３ヶ月も遅れたのか？
インプリメントの段階で、主機能の要求が変わったから。
新しいＯＳ環境に慣れるのに意外とてこずったから。
一部を外注に出したが、そこで分担モレが生じてしまったから。
どうして、プログラムサイズがオーバーしたのか。
設計段階でレビューができず、どのように設計されているかチェックできなかったから。
この種のやり取りが、「反省会」の場で行なわれます。そこで明らかにされる「原因」は、決して的を外してはいないのです。でも、それで原因が取り除かれることは殆どないのも事実です。それは一言でいって「反省」に終わっているからです。
反省会の場で行なわれているのは、皮肉にも、「失敗のパターン」を何度も何度も焼き直し（レジストし）ているだけで終わっているということです。彼らは、失敗しようとして失敗したのではありません。その方法しか知らないのです。それしか思い付かないし、それしか見たことがないのです。そしてそれをやっていったところが、納期が遅れる結果となったのです。途中、彼等には「選択肢」はありません。
彼らには、“ここでもう一度顧客と念のために打ち合わせをやっておこうか、それとも、このまま設計に入ってしまおうか”という選択肢は無かったはずです。ある程度、この種の「反省」を何度もやらされている人は、“再度顧客と打ち合わせの機会を作った方がいい”と感じていても、それは「選択肢」のレベルではありません。打ち合わせをするための適切な資料は、その時点では存在していないし、今からそれを作る時間となれば、それこそ確保できないわけです。こうして“気にはなりながら”も、そのまま設計作業に突っ込んでいくのです。それしかないのです。
そうして、再び顧客の要求モレが発覚し、その修正のために納期が遅れるといった結果になるのです。同じことの繰り返しです。その後の反省会では、１年前と同じ「原因」が、ボードに書かれることになるのです。まったく同じでは格好がつかないので、先方の窓口の担当者が替ったとか、こちら側のメンバーに新しい人が２人も入って来た、というように、多少は修飾されると思いますが、根本的なところは何も変わらないのです。
なぜ、こうなるのか。
それは、先の反省会で行なわれた行為は、「失敗のパターン」の焼き付け行為に過ぎなかったからです。
同じことが「不具合報告書」にも見ることが出来ます。そこでは発症のメカニズムが「再現」という行為を繰り返しながら、何時間もかかって追及され、ようやく掴んだ仕掛けが「原因」として書かれ、それを修正したことが記されています。
修正前の設計書に基づいてパラメータを渡してしまった。
事前の打ち合わせミスによって、同様の関数が複数個作られてしまったことによる・・
テスト・データが十分でなかった。
入力されるデータの取り得る値の確認が甘かった。
といった具合に、上手く行かなかった「パターン」が書かれています。というより、それしか書かれていません。これも結局、「失敗のパターン」をレジストする結果となり、問題の解決には繋がらないのです。
このようなことを防ぐために、「不具合報告書」に「所見」の欄を設け、担当者やリーダーが、「この事態をどのようにして避けるべきだったか」「次の機会にはどうするか」というように、「上手く行く為のパターン」を書くことが必要なのです。体に染み付いた「失敗のパターン」を消すためには、それ以上に「成功のパターン」をレジストしなければなりません。もちろん、この時点では「成功」の確証はないのですから、「上手く行くはずのパターン」と言うことになります。
そこで考えた「上手く行くはずのパターン」で、簡単に上手くいかないかも知れません。でも、大事なことは「上手く行くこと」をイメージすることであり、その分「失敗のパターン」を薄めることです。不具合の数だけ、そしてその度に「次の時はこうしよう」ということを考えているうちに、現実的にものが見えるようになってきます。
１００件バグがあれば、１００回考えることになります。１００件あっても、パターンは１０〜２０です。したがって、同じパターンに５〜１０回出くわすわけで、そのとき、所見の欄に「不具合＃７９と同じ」と書くようでは、この人は、将来の見込みがないと言うことになります。不具合報告書の「原因」の欄には、毎回「失敗のパターン」を書いているのに、それを打ち消すための「成功のパターン」は「不具合＃７９と同じ」では、事態が変わるはずがないでしょう。
不具合報告書にしても、反省会にしても、本当の「失敗の原因」を掴んでいるか、ということも問題になってきます。「原因」と言うのは、それが改善されれば症状が出ないものです。しかしながら、本当の「原因」が他にある場合、それに気付かなければ症状は改善しません。
例えば、上の例で、
設計段階でレビューができず、どのように設計されているかチェックできなかったから。
と言うとき、対策としては、これをひっくり返した形でまとめられることがしばしばあります。つまり、
次回は、設計段階でちゃんとレビューをする。
というものです。
しかしながら、このレビューが出来なかったことは、実は「原因」ではないかもしれません。もし、それが「原因」であるという場合は、「レビューが出来たのに、しなかった」ということになります。それなら、「次回はちゃんとレビューす」れば、この事態は改善されるはずです。でも、実際にはそのようなことは殆どなく、「レビューしようと思っても、出来なかった」のです。したがって、このような場合、「次回はちゃんとレビューしよう」では「成功のパターン」にならないことを認識してほしいのです。
「反省会」は、そこで提案された「改善案＝本来は成功のパターンになる」が、単に「失敗のパターン」を裏返しただけのものか、本当に「原因」に触れるものであるかどうかを議論する場でもあるのです。そうして、それが上手く行きそうだとすれば、何度も「レジスト」して焼き付けることです。
上に述べたことが、自然に行動として出るためトレーニングとして、普段から「上手く行ったパターン」を繰り返しイメージ・トレーニングすることです。
要求の書き方を変えてみたところ、お客さんとの打ち合わせが非常にスムースに運んだとか、バグの報告を受けたあと、「再現」に頼らずに、逆流法でしっかりと推論を働かせて、可能性を絞り込んで上手く行ったとか、設計書の構成を変えたことで設計書が書きやすくなり、結果としてインプリメントやテスト作業が捗ったとか、何でも言いから、「おっ、上手く行った！」ということを文字にするのです。
「なぜ上手く行ったのか」「何が効果を発揮したのか」を、文字にすることで確かめるのです。そしてそれを人に話すのです。そうすることで、「成功のパターン」を焼き付けることになり、次も同じように上手く出来るのです。組織的にこのような「運動」に取り組む方法もあります。さらには、そのような「事例」を掘り出して、『上手く行ったで賞』として評価することもできます。何も難しいことではありません。上手く行ったことを見つけて誉めることです。
これは、「評価」についても「上手く行くパターン」を探し、繰り返すことに外ならないのです。多くの組織では、評価は「失敗のパターン」を見つけては、それを一層焼き付けることに精力を費やしているのです。エンジニアがバグを出したことで、自ら「反省」と称してその「失敗のパターン」を焼き付けているのと同じように、「評価」においても、「失敗のパターン」を焼き付けることに力を貸しているのです。こんなことを何時まで繰り返しても、何も変わらないのです。
組織をあげて、「成功のパターン」を探し、それを評価し、皆で“レジスト”することです。これが、そんなに難しいでしょうか。