「再発防止策はチェックリストによる目視確認」

開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。

そこでよくある議論として、

とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します！今後はリリース前確認でかならず目視でチェックリスト確認を実施します」
ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」

みたいな光景です。

ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてですが。目的は、「同じことが今後も発生しないこと」「それを事前に食い止めること」、であり、「自動化して確認が楽になること」ではないのですが、どうしても技術的な正しさやエンジニアとしての美学が目的ベースの判断を歪めることがあります。

再発防止に求める効果効能と時間軸による変化

さくっとチェックを自動化できるような場合は最初から自動化すればよいのですが、例えば、それが難しいような場合、エンジニアの美学としてのコードで解決することに時間を溶かすよりも、まずは原始的であろうが実利を即得られる方法を選択するほうが良いです。その対策を実装している間にまた類似システム障害が発生したら意味が本末転倒なので。

STEP1 まずは実利の即効性（フロー効率的）

まずは即効性が重要なので、一番早いやりかたを選択したほうがよいと思います。今すぐできることが重要なので。それがエクセルチェックリストならそれでもいいですし。そして、本来の目的を達成してから、あとはそれを今後N回繰り返していくときの効率面の問題に対処していくのが良いと思います。（Lintに定義追加する程度とかの問題ならSTEP2からでいいです。）よくありがちなのがテストを自動化すればいい！という対策で、これ事態は別に悪くなくむしろ自分もそうしたいのですが、開発の文脈を無視したこの手の解決策をうつと問題がおきます。本来すぐ防止策を打ちたいだけなのに、いざテストコード書こうとすると、おやおや、クラスが大きいな・・・、メソッドも細かく切られていないしテストコード自体が複雑になるなあ。。。これなら、まずはリファクタリングしないとなあ、、、さあ、どこからなおしていくかな。みたいなことが起こりがち。リードタイムが長くなる一方。それは後述のSTEP2でやりたい。まずは目的を今すぐ果たしたい。フロー効率性重視でやりたい。

※ フロー効率性やリソース効率性の考え方はこちらを参照ください。 i2key.hateblo.jp

STEP2 今後の作業量の効率性（リソース効率的）

一旦、イケてない方法にしろ再発防止という目的を達成したのであれば、次にN回繰り返すときのことや、人力作業による手戻り発生等の物理的な無駄を排除していくことになります。やりかたはコードによる自動化とかがメジャーだとは思います。もしくは、そもそも仕組みを組み直して、そもそも問題が発生しない構造にしてしまうとか。とはいえ、それなりのリードタイムを要する行為かと思います。もしくは、カネで解決するためにアウトソースで実施することもあるかもしれません。こちらはリソースの効率性の文脈が強いと思います。カイゼンは最終的には実利を得つつもやることが減っている状態だと思っているので、ここまできてカイゼンはDONEではあります。また、この場合は、恒久対応までDONEすることをマネジメントすることは言わずもがな必須です。運用がゴミまみれになり負債化するので。

今回の件はイメージにすると以下です。まずは実利をリードタイム最短で取りに行き、その後、スケールしやすいように作業の効率化をしていくイメージです。 f:id:i2key:20181027151432p:plain

普段の何気ない意思決定に介在するアウトカムフォーカス

ポイントは目的を意識した上で、STEP1とSTEP2双方を意図的に実施することです。何度もいいますが、STEP1を絶対非効率なやりかたでやれと言っているわけではなく、即効性のある方法をとるとよいという意味なので、手動目視チェックリストで絶対やれという意図ではないです。そして、この何気ない意思決定および行動の積み重ねが開発組織の文化につながっていくと思います。チェックリスト文化だけも良くないですし、文脈を無視した自動化文化も良くないと思います。まずは最短のリードタイムで実利をとり、そのあと効率化していけると良いのではないでしょうか。本件の障害対応においては、まあ、普通に暫定対応と恒久対応なだけの話なのですが、このパターンって結構あるなあと感じたのでブログにしました。例えば次の類似ケース。

類似ケース

例えば、開発における案件のリリースまでのリードタイムを改善のために計測しようとしたときに、目的でいうと「リードタイムの可視化」なので、メンバ全員に聞いて回って模造紙にまとめるでも即効性があればなんでもいいのですが、自分も含めてですがどうしてもタスク管理ツールのAPIリファレンスを覗きだし、自動でチケットの日付とステータスの推移を抽出できないかとか悩みだすんですんですよね。で、運用がうまくされていなくてチケット管理ツールから自動抽出できないとなると、うーん・・・・、となってまた別の技術的解決方法を探しに行ってしまう。で、本来の目的からどんどんそれていきなかなか可視化されないという事態に陥る。全員で集まって人力で計測した時間を模造紙に書き出すだけで一旦は解決するのに。また、別のケースでいうとリーンスタートアップなどででてくるMVPとかもそれに近いかもしれないですね。

さいごに

サービス開発の現場では結構この手のことが多い気がしていて、また、本件の例のベテランエンジニアのようにHOWの指摘をしたくなるのもわかるのですが、そこは本質を意識しアウトカムにフォーカスし、得たい実利とHOWとリードタイムを天秤にかけながら判断をすべきだと思います。どんなにHOWが秀逸でも実利に繋がっていないとやっていないことと変わりないので。つまり、プラクティスの使い方がどうこうとかそういう話ではなく、本質的にはこういうことこそがアジャイルをしようとせずに、結果的にアジャイルであることなのではないかなと思ったりします。（高い技術力で高速に打ち手が打てる状態が最高ではありますが自分はそんな才能はないので。）