今日は趣(？)を変えて、「失敗」について考察してみます。
失敗に関わる名言
・一度も間違ったことのない人はいないだろう。いるのであれば、それは、何にも挑戦しなかった人だ。ウィリアム・ローゼンバーグ
・私の最大の光栄は、一度も失敗しないことではなく、倒れるごとに起きるところにある。本田宗一郎
・失敗は結果として起こり得るもの。失敗してないのならば、あなたは十分にイノベーティブであるとは言えないでしょう。イーロン・マスク
・失敗は問題だ。しかし、成功しようとしないのは、もっと問題である。セオドア・ルーズベルト
・人のやり方でうまくいくより自分の考えたやり方で失敗する方がマシだ。フョードル・ドストエフスキー
・私は失敗したことがない。ただ、1万通りの、うまく行かない方法を見つけただけだ。トーマス・エジソン
・成功することを学ぶには、まず失敗することを学ばねばならない。マイケル・ジョーダン
・人々が失敗について語るのは本当だ。成功から得るものはないからね。ダスティン・ホフマン
・人生に失敗した人の多くは、諦めたときに自分がどれほど成功に近づいていたか気づかなかった人たちだ。トーマス・エジソン
・失敗したところで やめてしまうから 失敗になる。成功するところまで 続ければそれは 成功になる。松下幸之助
・愚者は自分の失敗から学ぶ。賢者は他人の失敗(歴史)から学ぶ。ビスマルク
これ以外にも失敗にまつわる名言はたくさんあります。同じようなことを別の偉人が語っている場合も多々あります。
世間でも失敗を勧める言葉、失敗を恐れないマインドセットなどを謳う言葉や記事は多いですね。
本当に失敗を恐れていませんか？
一方、大企業や有名人の不祥事がニュースになると再起不能なくらい叩かれたりしますよね。もちろん、失敗の質にも寄りますが、失敗に対して非常に厳しい目を向けるのは日本人の性なのかもしれません。国を上げて期待されている製品の大きな開発遅延(開発中止)、公共交通機関による人命に関わる事故、大雪でのインフラ麻痺など・・・。
失敗とは？
ここでは私が会社勤めをしていた際の失敗にまつわる話を振り返ってみたいと思います。
私は技術職で主に製品開発等をしていました。なので失敗、と言えば、
・試作の日程に合わせて段取りしていた部品が何かの間違いで入ってこない。
・設計した製品、試作品がちょっとした抵抗値の間違いで設計通りの動作をしない。
・試作品を評価する際に配線を間違えて試作品を壊してしまう。
・初めて採用した部品が機能は出るものの、思いの他信頼性が低く、部品変更しなければならなくなった。
これらの失敗は開発スケジュールの遅延、開発費、製品コストの高騰につながる失敗です。上の名言で語られている失敗とはレベルが違いますが(笑)。ただ、本人達は一生懸命やっているし、ただ事業への影響はあるためこれらの失敗への再発防止策を求められます。
再発防止？
ニュースになるような失敗、不祥事や社内の小さな失敗でも再発防止のための検討は必要です。失敗から学ぶものは多いですからね。なぜなぜを5回繰り返し、真因まで掘り下げるというのが良く使われますが、時々、「なんでこうなるの？」ということ例が見られます。まぁ、ある意味正しいし仕方ないのかもしれませんが・・・。
失敗例）試作品のノイズ評価で不具合が発生し、設計を見直し。スケジュールが半年遅れた。
なぜなぜ１）使用している回路(部品)は他の製品で実績があり、(設計者が)問題ないと思っていた。
なぜなぜ２）設計段階でグループ内でレビューしたが、誰も指摘しなかった。
なぜなぜ３）グループ内に知見がなく、気づかなかった。
なぜなぜ４）グループ外に知見があることは後に分かったが、相手の人も忙しくて時間が合わずアドバイスを仰げなかった。
なぜなぜ５）そのような知見が誰でも見れるところになかった。
などなど・・・。この場合の問題はグループ内のレビューがレビューの形だけ実施されて(内規でレビューしなければならないし、開発会議でグループ内レビューしてその結果を報告しなければならない)、設計内容まで踏み込まれた内容ではなかったことかと思います。少なくとも課長クラスが入っていれば指摘できるようなことなんですけどね。
というか、ここまで尋問のようなことをされるとそれに時間を取られるし、もちろん楽しくない。ある種、罰ゲームというかペナルティのように感じると思います。私はそう思っていました(笑)。だから失敗は絶対したくないな、と。失敗を許す風土にはならないですよね(笑)。
出来た再発防止策
こういったなぜなぜ分析ですので、対応策は全社知見を整備する。知見を確認した結果を管理者が確認し、その結果を開発会議で報告する、ような新しい全社規則が出来ました・・・。
これでも、まぁ・・・、というところですが、その担当者、グループは何一つ成長していないし、知見のない課題に対して取り組む風土は出来ません。それどころか、ルール、規則があるからやった、なかったからやらなかった、という人、組織になってしまいそうです。これではまたちょっとした不具合で開発スケジュールが遅れる、ということは起こりそうな気がしませんか。
製品開発者として品質、信頼性、に対しての良識、良心に照らせば何をすればよいか、どうすればよいか、となるのですが規則で固めてしまうと規則だからやる。指摘しないような人を集めて会議はやりました。また、後の新人がなぜこのような規則があるのかを分からないまま年を取っていくことになります。原理原則を理解しないまま成長するとその人が管理職になった時に・・・、ですよね。本当にその失敗から手を打たなければいけないところはどこなんでしょうね。全社としては上記のような手当てになるのは仕方ないですが当事者、当部署は違う手当てをしていかないと規則通り、ルール通りの職場、結果的に技術部なのでリノベーションの生まれにくい組織になりますね。
大企業になるとある意味仕方ないでしょうか。こう言った組織ではある程度中間管理職が腹を括って管理者の元で失敗をさせ、全社的には失敗させない、という二枚舌が必要ですね。実際は日程に余裕がないので失敗させる余裕はないことが多いのですが。でもやはり管理職の腕の見せ所、と私は現役時代(？)に考えていました。気持ちが病むよりは全然良いと思います。
こちらでも軽く自己紹介しています。⇒https://www.c-sagaseru.com/ross-isshiki、https://syoukei-senmon.net/aichi/15180
Twitterでも軽く呟いています。⇒https://twitter.com/RossIsshiki
コメント