この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。
スクラムチームと計画
変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。
私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。
私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末になんとか実装できた機能」だということを、私たちは経験的に知っています。
スクラムチームにとって一番身近な「計画」はスプリントプランニングでしょう。スプリントの計画がめちゃくちゃに混乱すれば、検討すべき事項の見落としやドキュメントに残らない仕様が生まれ、場当たり的な実装が行われ、手戻りが増え、結果的に時間とコードの品質を失います。それはアジリティからは程遠い状態です。
では、「スプリントの計画をめちゃめちゃにさせるもの」を事前に発見する可能性を上げるために何ができるでしょうか？私たちが取り入れているプラクティスの1つが、「死亡前死因分析」です。
「死亡前死因分析」とはなにか？
「死亡前死因分析(premortem)」とは「これから実行しようとしているプランに、どのような悪いことが起きうるか？」ではなく、「すでに悪いことが起きてしまった」という前提のもと、「原因は何か？」を問うものです。「ファスト＆スロー」では以下のように紹介されています。
組織であれば楽観主義をうまく抑えられるかもしれない。また個人の集団よりは一人の個人のほうが抑えやすいだろう。そのために一番よいと考えられるのは、私の「敵対的な共同研究者」ゲーリー・クラインが考え出した方法である。
やり方は簡単で、何か重要な決定に立ち至ったとき、まだそれを正式に発表しないうちに、その決定をよく知っている人たちに集まってもらう。そして、「いまが一年後だと想像してください。私たちは、さきほど決めた計画を実行しました。すると大失敗に終わりました。どんなふうに失敗したのか、5 ~ 10分でその経過を簡単にまとめてください」と頼む。
クラインはこの方法を「死亡前死因分析（premortem）」と名付けている。— 『ファスト&スロー: あなたの意思はどのように決まるか?（下）』 ダニエル・カーネマン
スプリントプランニングにおいて、私たちが死亡前死因分析に期待する効果は2つあります。
1つ目は「特定の結果が起きる理由を、より多く、具体的に思い浮かべることができる」効果です。「巨大システム 失敗の本質」は、Deborah J. Mitchellらの実験を引いて、この効果を説明しています。
死亡前死因分析のベースにあるのは、心理学者が「先見の後知恵」と呼ぶ考え方、つまりあるできごとがすでに起こったと想像することで頭に浮かぶ後知恵だ。先見の後知恵を用いると、特定の結果が起こる理由を見抜く能力が高まることが、1989年の画期的研究で報告されている。実験参加者は先見の後知恵を用いると、結果を想像しなかった場合に比べて、より多くの理由を思いつき、しかもそれらはより具体的でより正確だった。
— 『巨大システム 失敗の本質「組織の壊滅的失敗」を防ぐたった一つの方法』クリス・クリアフィールド、アンドラーシュ・ティルシック
２つ目は、「計画を失敗させる要因をあぶり出すことに対して、思考が前向きになる」効果です。これは「部分的な情報をつなぎ合わせて、自分に都合のよい解釈を生み出す」という楽観バイアスに対する強力な対抗策になります。同じく「巨大システム 失敗の本質」では、死亡前死因分析の提唱者であるゲーリー・クラインの説明が紹介されています。
また死亡前死因分析は、分析者の動機にも影響を与える。「要するに、優れた計画を考えつくことで賢さをひけらかす代わりに、プロジェクトが失敗する鋭い理由を考えて頭のよさを見せつけようという意識が働く」とゲーリー・クラインは説明する。「全員の意識が、調和を乱すようなことを避けようとする方向から、潜在的問題をあぶり出そうという方向に変わる」。
— 『巨大システム 失敗の本質「組織の壊滅的失敗」を防ぐたった一つの方法』 クリス・クリアフィールド、アンドラーシュ・ティルシック
どのように取り入れるか？
私たちのチームでは、死亡前死因分析をスプリントプランニング第2部の「完了の定義」に含めています。たとえば、次のような流れで実施しています。
- ファシリテーターが、「今が来週のスプリントレビューの場だと想定してください。このスプリントではスプリントゴールを達成できませんでした。私たちは悔しい思いをしています。では、どういった理由でスプリントは失敗したのでしょうか」を問いかける
- 各メンバーが、「スプリントを失敗させた理由」を挙げる。「Aが起きたために、Xになってしまった」のように、すでに起きてしまったこととして話す。「かもしれない」「可能性がある」などの「予測」的なワードは使わない
- 「スプリントを失敗させた理由」を挙げ終えたら、それらの回避策や、発生時の影響を軽減するプランをメンバー全員で考え、スプリント計画に含める
私たちはこのプラクティスで、「利用を予定しているAPIの仕様の認識の誤り」や「複雑すぎるデータマイグレーション操作」、「お客様企業の意思決定に関わる機能の致命的なバグ」といった、大きな手戻りを発生させるリスクを洗い出し、対応策を入念に検討することができました。
死亡前死因分析は、 “Measure twice, cut once” を志向する開発チームには、ぜひおすすめしたいプラクティスです。
HRMOS では、このような「人間的側面」からもエンジニアリングを考えることに情熱を傾けられるソフトウェアエンジニアを募集しています。
テックリード／HRMOS EX
ソフトウェアエンジニア／HRMOS EX
