プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

「だから失敗は起こる」読了

だから失敗は起こる (NHK出版DVD+BOOK)

だから失敗は起こる (NHK出版DVD+BOOK)

失敗学の提唱者である畑村洋太郎さんの本。
これは良書です。ソフトウェアに限らず、ものづくりに携わっている人はぜひ読む(見る)べき。


本書の一番の要点は、
失敗が起こったらまず責任追及をするのではなく、原因追究を行え。
ということだったように思います。


ソフトウェアの世界でも、失敗(障害)が起こったら、

  • 直接的な原因を究明する
  • 暫定対策を施してシステムを復旧させ、業務続行させる
  • 根本的な原因を究明する
  • 根本対策を施してシステムを正しい状態にする

みたいな手順になるでしょうね。暫定対策と根本対策は同じになる可能性もありますが、やっぱり責任追及は後回しでしょう。


僕が個人的に面白いなと思ったのは、「逆演算」で失敗を防ぐという考え方。

「こうつくったから失敗しない」という方向だけではなく、あらゆる失敗を「ありうべきもの」と考え、「失敗をするとしたらどういう状態のときか」を抽象化し、チェックしていく―こうした、いわば失敗の「逆演算」こそが、失敗を予測し、防いでくれるのです。

ソフトウェア開発では、よくこれだけテストしたから大丈夫だろうと、信頼度成長曲線などを元に判断したりしますが、それとは別に、それでもこういう障害が起こったらと逆に考えることも重要だということです。
実は、この1年半でやってきた開発も、実にそういうことを良く考えるプロジェクトで、ここでこういう障害が起こったら、モジュールをリリース前のものに戻そうとか、こっちでこういう障害が起こったら、データのリカバリが発生するから、リカバリツールを作っておこうとか、障害計画に余念がなかったです。


まあ、それだけ止められないサービスだったというのもありますが、ここまでの取り組みを今までしたことが無かったので、そのやり方は随分勉強になりました。
たまたまこの時期にこの本を読んだおかげで、そのやり方が「逆演算」ということなのだということを知ることも出来ました。


いわゆるベストプラクティスにのみ焦点を当てるのではなく、こういうことをやると失敗する。だからこう設計するみたいな視点も必要なのだと思いました。


ただ、今まで数々の失敗に直面してはいるものの、失敗ってやっぱり忘れたい記憶なんですよね。
JALの安全啓発センターや、失敗知識データベースみたいに残していくことも重要で、なおかつ、それを今後ものづくりしていく人達の知識として定着し、「こういうことをやると失敗する。だからこう設計する」という考え方を持つことが大事でしょう。
僕自身もまだまだ過去の失敗事例(自分が経験したものも含め)から学びたいところです。