フェイルマネージメント
検索しても出てきません。僕が作りました。
フェイルマネージメントとは
失敗を管理する事で強い開発組織にしていきましょうという話です。
開発組織では、沢山の失敗が存在します。
・プロマネの失敗
・要件定義の失敗
・設計の失敗
・プログラミングの失敗
・テストの失敗
・デプロイの失敗
・インフラの失敗
あなたの組織では、適切に管理出来ていますか？
この失敗は、開発組織にとって宝の山です。
状況を分析し、対策を施し、改善し、二度と同じ失敗を繰り返さない事が出来るのは、このフェイルマネージメントです。
体制の構築から
ある程度の組織になれば、失敗のログは残しているかもしれませんが、失敗を分析し適切に改善できている組織は少ないかもしれません。僕もこの改善プロセスは大嫌いです。特に当事者は、やりたくないものです。
必ず監査する別組織の立上げが必要です。この役目はCTOでは駄目です。
CTOがPJ側の立場で物事の推進をサポートする必要があります。
当事者では、優しさが生まれたり、難易度への配慮が入ったり手を抜いてしまいます。
従って、CTOとは別組織での構築が必要です。
失敗の記録だけでは足りない
失敗の記録だけでなく、成功の記録も必要です。
僕はゴルフが好きなのですが、ゴルフのスコアアップには、スイングの録画が重要な上達ポイントです。
上手く出来たスイングと失敗したスイングを比較して、どこにエラーが存在するのか、そのエラーを発生させないための対策はどうすれば良いのか。
成功した理由の分析も再現性には重要な手がかりとなります。
人に依存しない再現性を
失敗を分析し成功パターンにより対策が得られた場合は、成功するパターンを再現性あるモノに変えていく必要があります。
単純に分析しただけでは足りなくて、対策しただけでも足りません。
２度と失敗しない形、システムに落とし込んでいく必要があります。
最も良いパターンはプログラムに落とし込む事です。プログラムであれば、再現性は１００％です。
プログラム化が難しい場合もシステム化、フロー化を行い再現性を極限まで求めて行くことです。
失敗の対策は面倒くさい、だから１度だけ
エンジニアにとってプログラミングは楽しいです。新規に作り上げていくのに喜びを覚えます。
一方、失敗の対策は、地味だし、手間だし、やりたくないものです。なので１度だけ。２度と起きない様に。
全員で集中して対策しましょう。幸せなエンジニアライフのために。