失敗から学ぶ
2月 17th, 2009
よく失敗をします。失敗が99で成功が1と言う位なんじゃないか？と言う比率で失敗します。一口に失敗と言っても色々なケースがありますが、仕事にしても、コミュニケーションにしても、「目的が達成出来なかった事」が失敗だと思っています。
常日頃から「目的」を明確にもって生きているわけでは無いので、往々にして後から「ああ、こうすれば良かった」と言う事の方が多いのですが、それもまた一つの失敗かなと。行動を起こした時には、目的が明確では無かったとしても、振り返ると「こうすれば良かった」と言う目的、目標がそこには存在しているわけです。ただ、それを意識しているか否か、それだけの違いです。
ただ、そんな風にだけ考えてしまうと、暗く憂鬱な毎日になってしまうので、こんな事を考える様にしています。
- その目的、目標は妥当だったのか？
- 行動によって、目的、目標はどの程度達成できたのか？何が達成できなかったのか？
- 目的、目標に至らなかった理由は何か？
そして、失敗をした直後では無く、少し時間を空けて、失敗の度合いによってはじっくり時間をかけて、客観的に考えて行くと、結果的に前向きなToDoとして「次回、失敗しないための方法」が浮かび上がってきます。そして此処からが重要です。浮かび上がってきた、「次回、失敗しないための方法」をただの「方法」にしておくと、経験上、また同じ事を繰り返すケースが多いので、その「方法」を「仕組み」に進化させます。
例えば、「プログラムの納期が間に合わなく、クライアントに迷惑をかけた」と言う失敗があった場合、こんな分析ができると思います。
- そもそもの納期は妥当だったのか？（その目的、目標は妥当だったのか？）
- 仕様確定のための期間が短期間過ぎた
- 何が出来ていて、何が出来ていないのか（行動によって、目的、目標はどの程度達成できたのか？何が達成できなかったのか？）
- 仕様は確定している
- プログラムの概ね完成。単体テストが途中。
- なぜ、納期に遅れたのか？（目的、目標に至らなかった理由は何か？）
- 仕様確定が遅延したにも関わらず、スケジュール調整をしなかった為
こう言う分析の結果になると、次回以降の対処方法は「仕様確定が遅延した場合、スケジュールを調整する（出来るか出来ないかわからないけどw）」と言う事になります。ただ、この状態ではただの「方法」です。次の段階では、これを「仕組み」に進化させます。
仕組みに必要な要素としては、
- 誰でも理解、納得する事ができるルールになっている
- ルーチン化する事ができる
などがあるかと思います。この例の場合、「仕様確定が遅延した場合、スケジュールを調整する」と言うのが失敗を繰り返さないための方法です。それを仕組みにすると言う事は、この方法を「ルール化し、誰でも理解、納得する事ができる状況を作り、ルーチン化する」わけです。
この「プログラムの納期が間に合わなかった」と言う例で言えば、こんな「仕組み」が言えるかと思います。
- プログラミング＆テストスケジュールは、仕様確定の段階で再スケジュールする事を契約書、覚え書き等に入れ込む（もしくは、プロジェクト開始時点でコンセンサスをとっておく）
- スケジュールの妥当性を計り、見直すタイミングをマイルストーンとしてスケジュールに予め設定し、コンセンサスを取る事を義務づける
他にも色々なアイデアがあるかと思いますが、一例としてあげておきます。
重要なのは、こうした仕組みを作って行く事によって、徐々に失敗リスクを軽減していく事だと思います。PDCAサイクルと言うイメージでしょうか。
ただ、やっかいなのは、「失敗」と言うのは常にユニークで、特に日常生活においての「失敗」は、対処策を仕組み化しにくいです。その時々の自分のメンタルや状況によっては、自分自身も思いもよらない行動をとるケースも少なくないですし、対処策を仕組みすると言うのも、僕らはロボットではなく人間ですから、難しいです。ただ、人間であると言うメリットから言えば、失敗に伴う痛みによって、次回、同じ様な事が起こった時、ブレーキがかかるなんて事が唯一の対処策、対処の仕組みなのかも知れません。
Posted in: 仕事のこと
コメントする