« 人生は一回だから軽いのか、重いのか『存在の耐えられない軽さ』 | トップページ | 問いの質を底上げする『問いの技法』 »

失敗の質を上げる『「正しく」失敗できるチームを作る』

N/A

誰だって失敗なんてしたくない。

自分のミスが原因で、手戻りが起きたり納期が遅れたりしたら、自分自身を責めたくなる。さらに「なぜ起きたのか?」「再発防止は?」などと責任追及されたら、いたたまれない。

失敗の不安と恐怖に圧し潰されそうになる。そんな現場のリーダーに向けた失敗とリカバリをエンジニアリングしたのが本書になる。

本書は面白いことに、「正しい失敗」と「間違った失敗」に分ける。そして、どうせするなら「正しく」失敗しなさいと説く。

「正しく」失敗?それは何だろうか。

速く失敗せよ

例えば、速く(早く)失敗する。

ITプロジェクトならDevOpsやアジャイルといった「小さく作り、駄目ならロールバックする」という技術革新の恩恵が受けられる。一般に適用するなら、まず少し手を付けて、見積もった想定とズレたら修正していく。出来の良さより「終わらせる」ことを優先し、周囲や上司のフィードバックを貰うといったやり方だ。

「事前に失敗する」というやり方もある。プロジェクトが始まる前に集まって「このプロジェクトは大失敗しました」と皆で絶望する。そしてその後、なぜ失敗したのか、どんな失敗の可能性が高いのかを話し合うのだ。

これ、プレモーテムというのだが、私もよく使う。始まってすらいないから、みんな気軽にノッてくれる。重要度×緊急度のマトリクス表にプロットしていく。自分の失敗だけでなく、他部署の怖い話をしてもいい(開発機と本番機を間違えたとかが定番)。

未来の後知恵をつけることで、「このプロジェクトにどんなリスクがあるか」を共有することができる。

失敗を歓迎せよ

あるいは、失敗を称賛する。

もちろん、失敗なんて誉められたものではない。だが、失敗を報告する人を褒め称える姿勢が重要だという。

これは「バグを厳罰化した課長の話」が良い例になる。その課長は、着任早々、プロジェクトメンバーに「高品質のソフトウェアを開発するため、バグを作り込んだらペナルティを課す」と宣言した。

オチはもう読めると思うけれど、一応言っておくと、バグが報告されないプロジェクトとなった。不具合は大事になるまで隠され、最終的には管理者責任となった。

「失敗したら非難される」という恐怖や、「私のせいにされるかもしれない」という不安が、報告をためらわせる。その恐怖や不安を取り除くために、失敗を報告してきた勇気を称えろという。

私が気を付けているのは、トラブルの第一報を受けたとき、必ず(必ず!だ)「ありがとう」から始めるところだ。「いま教えてくれたおかげで、リスケジュールできるかもしれない」とか「もっと後だったらゾッとすることになってた」なんてフォローする。

そして、失敗や課題はホワイトボードなどで外在化させる。原因は「人」ではない。たとえ人為的なミスだとしても、そうさせた仕組みなり、トラブルに発展するまで見つけられなかったプロセスが真の原因だ(「人為トラブル撲滅」というスローガンに違和感を覚えるのは、トラブルの原因を「人為」としているように読み取れるところだ)。

失敗を歓迎し、失敗から学ぶ姿勢は、医療現場の方が進んでいる。例えば『なぜエラーが医療事故を減らすのか』ではその実践的な事例が紹介されている。

同じ失敗を繰り返す

では、「間違った失敗」とは?

例えば本書では、「同じ失敗を繰り返す」事例が出てくる。

同じ失敗を繰り返すなんて、学習していない証拠なのだが、実際にある。

例えば、失敗を非難する空気の中だと、原因について振り返ったり再発防止を検討するプロセスはなおざりになる。その失敗の悪影響を回避する対策「だけ」にリソースを使い果たし、メンバーを疲弊させてしまう。

これは、「同じ失敗をしている」と認識していないことからも生じている。

マーチン・ファウラーによると、失敗の定義はこうなる。

プロジェクトの失敗はスケジュールの遅れや予算の超過による失敗ではなく、見積りの失敗です。プロジェクトが遅れた、またはコスト超過したために失敗したと言うのではなく、失敗したのは見積りなのです。

失敗とは何か(What Is Failure)

表面上では、「納期遅れ」や「予算超過」という事象だが、結局のところ、失敗とは、見積もった予想からの逸脱が大事に至った現象だ。

だから、失敗の事象の原因を特定するとき、「どの見積もりが失敗していたのか?」という視点から分析することで、学習することができる。

例えば、「納期遅れの原因は、途中で仕様変更が捻じ込まれたから」で思考停止するのではなく、「その仕様変更を受け入れて間に合うと見積もった根拠は何だったか?」という問いに置き換えることができる。その上で、その根拠の見通しの甘さや、再発防止策を考える。

失敗しないプロジェクトは無い。大なり小なり、仕事に失敗はつきものだが、その扱い方は学べる。「正しい」失敗は学びにつながり、チームを成長させる。「間違った失敗」は恐怖と不安を招き、同じ過ちを繰り返すことになる。

失敗を味方につけ、恐怖と不安を乗り越える一冊。



このエントリーをはてなブックマークに追加

|

« 人生は一回だから軽いのか、重いのか『存在の耐えられない軽さ』 | トップページ | 問いの質を底上げする『問いの技法』 »

コメント

失敗を許さないソフトウェア開発プロジェクトざらにありますね。現代でも。ほんとに。
失敗を許さないだけで、もう最初から暗雲垂れこめてる、って感じを抱く今日この頃。
認められるリカバリー方法が残業だけというのって、どうなんでしょうか?
昼寝するとか早退するとかのほうが、ずっと前向きな気がするんですけど、そんなこと言える雰囲気ないのは、まだ戦前を引きずってる気がします。

投稿: 美崎薫 | 2025.08.31 19:40

>>美崎薫さん

確かにそんなプロジェクト、想像以上に当たりますよね……自分がマネジメントできる立場の場合は、代替案とともに「ノー」とはっきり伝えますが、巻き込まれ型だとそうも言えず、もどかしい思いで死んだ魚の目をしています。

投稿: Dain | 2025.09.01 21:07

そうなんですよ!
自分が能動的にかかわれるかどうかは大きな要素だなと思います。プログラマひとりプロジェクトだとのびのびできます。複数人だと魚のように無口で。

投稿: 美崎薫 | 2025.09.07 18:08

>>美崎薫さん

確かに、自分の裁量が影響してきますね。同じ仕事であっても、精神衛生上、かなり違います。

投稿: Dain | 2025.09.09 09:53

コメントを書く



(ウェブ上には掲載しません)




« 人生は一回だから軽いのか、重いのか『存在の耐えられない軽さ』 | トップページ | 問いの質を底上げする『問いの技法』 »