振り返りの『なぜ』は順番にしていこうという話

いわゆる『なぜなぜ分析』の話です。

弊社のエンジニアチームでは最近プロジェクト内で開発に関する振り返りを行なっていて、生産性を高めようだったり開発体験をよくしようだったり、開発者同士の知見を共有してお互いにレベルアップしようだったり、いろんな思いを込めて振り返る文化を形成中です。

そんな中で参画中のプロジェクトで行なった、障害対応について振り返りポストモーテム作成時に感じたこと、正確にはその時はちょっとした違和感以外は特に何も感じていなくて、後からさらにその時のことを振り返って感じたこと、を記しておこうと思います（ややこしい）。

"振り返り"

使えるべきサービスが使えない、という障害でした。以後エラーと書きます。
エラーが発生した原因はいくつもありました。ハインリッヒの法則に通じるものがあります。
私たちはそのエラーがなぜ起こったのか、まずは Miro を用いて、関係メンバーで書き出していきました。

Miro は、オンラインの仮想ホワイトボードに付箋やペンなどを組み合わせて、メンバーがリアルタイムに考えを共有したり可視化・整理したりできるコミュニケーションツールです。対話的にコミュニケーションを取りたい時はよく使います。今回も使いました。

付箋がペタペタ貼られていきます。
直接原因は何か、根本原因は何か。ああ〜こういうことあったなーとか、ここのタイミングで気づけなかったかなぁとか、もっと早く検知できる仕組み欲しいねとか。
誰かが話している間にも誰かのふとした気づきが書かれていって、なるほど結構でたね、いっぱいあるね、よしじゃあどうする？、これに対してはこうしていこうか、と話は続いていきます。

大体出し切ったところで内容を整理し、後日見出しを整理して改めてメンバーで内容を確認。
記載の不足があれば指摘し、あとは必要な対応をしていこう、となってポストモーテム作成完了、ひと通りが終了します。

"振り返り" の振り返り

振り返りの振り返り、をするタイミングがあります。弊社エンジニアチームは振り返り文化を形成するにあたって振り返りの効果を確認していく段階にありました。
その時に初めてあの振り返り自分的にはうまくいってなかったのかも、という違和感を表現するに至ります。

違和感の正体は、深度の異なる『なぜ』が矢継ぎ早に出てきたことによる、なんだか整頓された気がしないなというものでした。とてもまどろっこしい表現ですが、そんな感じです。

"振り返り"をした時に出てきた付箋はいくつかのまとまりになっています。エラーが発生したコードの箇所がどこか、そのコードが期待したものではないことに気づかなかった原因は何か・防げなかった原因は何か、エラーがあることにもっと早く気づけなかったか。

おそらくこの中でたくさん出てくるのは、なぜ気づけなかったのか、防げなかったのか、というところかと思います。なぜを考えるの、楽しいですよね。
実際 Miro のボードにはその内容が記載された付箋が割合多く貼られていました。実装メンバーが多いので、特に自身の身近なところから書き始めていきがちです。

でもそうすると、付箋が集まった時によくわからなくなります。
「テストケースが揃っていなかった」と「レスポンスが想定外の値だった」と「レスポンス内容を把握・共有できていない」という内容が出てきた時に、私はこの関係性をぱっと把握することができませんでした。
すごく近かったり似ていたりする言葉や内容の並びだけど、本質的なところは違ってすぐに頭に入ってこない感じです。なんだか整理されていなくない？

確かにそれぞれの対応策は書いてあるし、ああこれはしなきゃいけないねとなるものの、そこに出てきた「改善」はまたもや関係性が把握できないもので、改めて整理が必要になってきます。
パズルのように繋げることはできるかもしれませんが、せっかくメンバーが集まって振り返るタイミングと時間があるのだから、ここは『なぜ』を出すときから一つずつ整理していきたいところです。

それがおそらく順番に『なぜ』をした方がいい、ということに繋がるのだと思います。
なぜなぜ分析です。最終的な『なぜ』が「人間が存在しているから」となる、真理を追求するあの手法（違う）。

なぜなぜ分析

なぜなぜ分析というのは根本原因を探る分析手法の一つです。トヨタ生産方式を構成するものでもある。ポストモーテムでしたかったことです。
ウィキペディアでは以下のように説明が書かれていました^[1]。

• まず、問題となる事象を提示する。このとき、次に提示する『なぜ』との論理的なつながりを明確にするため、問題点を絞っておくことが望ましい。
• 次に、その事象が発生するに至った要因を提示する。これが 1 回目の『なぜ』である。要因はひとつだけとは限らない。また、事象に対して、論理的なつながりがなければならない。
• 次に、各要因ごとに、それが発生するに至った要因を提示する。これが 2 回目の『なぜ』である。1 回目と同様、ひとつだけとは限らず、また、論理的なつながりがなければならない。
• 同様にして、3 回目の『なぜ』の提示、4 回目の『なぜ』の提示…を繰り返していく。

大事なのは、その『なぜ』が並列で存在するのか、論理的なつながりがあって存在するのかを明らかにしておくことです。
私たちのケースだとどのように進めることができるでしょう。

「コードが期待された動作をしないことに気づけなかった」
→ 1 回目『なぜ』 「テストケースが揃っていなかった」
→ 2 回目『なぜ』 「レスポンスが想定外の値だった」
→ 3 回目『なぜ』 「そのレスポンスの元となる値の根拠を理解・把握していなかった」
→ 4 回目『なぜ』 「開発時に口頭での共有のみで、記憶から抜けている」「開発者同士で共有できていたか不確か」
...等々になるのかしらぁと思います（頑張って）。

実際には 1 回目の『なぜ』は他にもあるのですが、ひとまず「テストケースが揃っていなかった」についてなぜを進めてみました。
さて、『改善』については最後に出てきた『なぜ』から考えていきます。

「開発時に口頭での共有のみで、記憶から抜けている」「開発者同士で共有できていたか不確か」
→ 開発時にドキュメントに起こす、コメントに記載する
→ 書いたものを元に開発者で共有する時間を持つ
→ そこで不明瞭な点があれば、確認する

「そのレスポンスの元となる値の根拠を理解・把握していなかった」
→ 前項の改善ができていれば、把握できるはず

「レスポンスが想定外の値だった」
→ 前項の改善ができていれば、値も想定できるはず

「テストケースが揃っていなかった」
→ 前項の改善ができていれば、テストケースは出せるはず

...と言った感じになるのかしらぁと思います（頑張って）。
細部を省いているところもあるため少し物足りない部分はあるかもしれませんが、テストケースが揃っていなかった点については、「当時の実装者がすでにチームから外れており、今いるメンバーでおそらくこうであろう、という記憶と推測からテストケースを作成したこと」により起こったことであると考えます^[2]。
これを他にも出た『なぜ』に対しても行なっていくと、いくつかの根本原因が明らかになり、それに対する『改善』を出すことができるのではと思います。

そんなところで、以下のようにまとめたいと思います。

• 『なぜ』を順番に深掘りしていくと、深掘りしたところから対応方法を導くことができる
• 深掘りしたさきは小さなインシデントであるから、ごくわずかな改善で発生しうるインシデントを摘んでいくことができる
• 振り返りの『なぜ』を順番にしていくことは、効果的でおすすめ

おわりに

実際に振り返りどうだったと聞かれた時はこんなに話せるわけもなく、メンバーが発言する時に整理していければもっと良かったなぁということを口にした気がします。多分。

もともと自分自身の直感・違和感には殊更に敏感なのですが、なんせその感じたことに対する言語化がスーパースローペースなので、聞かれた時はモニャモニャするしかなく、ああ言いたいことこれやったわと気づいたのは、勤務時間を終え夜ご飯を食べシャワーを浴びさて温かいお茶でもいただこうかしらとしたときで、ゆうに 5 時間後です。
一山登って降りられる、高尾山を 2 往復できる時間です。ハイペースなハイキング。

だからいつでもことの後には内省の時間を取ることが必要だなと実感します。

経験長けている方にとってはなぜなぜ分析何を今更、と思われるところあると思います。まあまあ、見守っていただけると幸いです。そしてこのような思考・分析手法については、少しずつ身につけていきたいところです。
学びはまだまだ続きます。なぜなぜ分析、してみましょう。こんなやり方もいいよ〜というのがあればいただけますと幸いです。

まとめ

振り返り、結構すきです。

脚注

1. ウィキペディア 「なぜなぜ分析」より

2. この記事を読んだリーダーからツッコミをいただけるかもしれません。いただいたら追記します