何かを改善するときに、
「ちゃんと○○できるようにするには」
みたいな方向にどうしても行きがちになる気がする。
ex1. 本番障害が発生した → テストをちゃんとやる ex2. デモで手戻りが発生した → ちゃんと要件・仕様を詰める
みたいな。
この「ちゃんと」病に取り憑かれるのは、Waterfall 時代の癖なのかもしれない。
もちろん、事前に抑えられるなら事前に抑えたほうが良いのは絶対にある。が、限度もある。
100% をちゃんと事前に抑えるのは無理だと諦めたほうが良くて、せいぜい8割が事前に抑えられれば良い方だと思う。（要出典）
で、残りの2割に対して、「ちゃんと○○しよう」というアプローチでやっても、無駄なコストがかかるばかりになってしまう。
そもそも、「ちゃんと要件を事前に決めるなんて無理でしょ」みたいな事実から継続的に検査と適応をしないといけないよね、というのがアジャイル開発のモチベーションの大きな一つなはず。
じゃあ、どうするか。
MTTR vs MTBF を両輪で使い分けるのが大事な気がする。
問題を起こさないことと、問題が起きたときにその影響を極小化したりすることで問題の影響を抑制する方向を考える。
ex.社内でインフルエンザが流行って作業が進まず、遅延が発生する → インフルエンザが流行らないようにする ← そのために、注意喚起、手洗いうがい、アルコール消毒機器を置く → インフルエンザが流行っても問題が大きくならないようにする ←タスクを属人化させない、バッファを確保する、休みやすい環境にする、Plan B を決めておく
ex. メモリが貼りついて本番障害が発生し、売り上げ機会を逸した → メモリが貼りつかないようにする ← スタックした部分を修正する → メモリが貼りついても問題が大きくならないようにする ← 構成を冗長化する、スケーラブルな設計にしておく、定期的に再起動する
どっちも重要だし、どっちもやったほうがよさそう。
どちらかだけで何とかしようとするのは割と悪手な気がする。
どちらがいいというわけではなく、「ちゃんと○○しましょう」という言葉が出てきたら、ちょっと待てよ？無理スジなのでは？って考えるようにしたい。
