年単位でトラブルを起こさないための考え方についてまとめました。システムがトラブル続きだとビジネス速度がどんどん落ちていくので、気をつけましょう。

1. ノートラブルシステムへの道
ビジネス速度を落とさないために
TOCQ： 山崎大輔（@yamaz)

2. こういうこと、あるあるです
• 勢いよくクラウド上に作られたアプリがある
• テストやCI/CDはあんまり整備されてない
• コードの質もイマイチで結構デグレする
• だけどビジネスはそこそこ回ってる
• トラブルに時間取られて開発速度低下（ビジネス速度も低下）
• トラブル起因で顧客をライバルに取られる
• 対策はやってるものの、モグラたたき感が拭えない

3. システムのクオリティは超大事
1. クオリティが低いとトラブル対応のため、エンジニアはもと
より関係各所の工数が無駄に発生（意味のない工数）
2. クオリティの低さは意味のないチャーン（解約）を産む
折角マーケ費用をかけて育てたユーザをライバルにタダで取られる
3. システムのクオリティを低いと開発速度が下がる
よって成長期においてはシステムクオリティは機能追加より大事
になりえる

4. 逆にシステムのクオリティが高いと
1. トラブルがないため、エンジニアはもとより関係各所の工数
がかからない（コストが低くなる）
2. 安定性はマーケ施策ともなりえる
ライバルがマーケ費用などをかけて育てたユーザを奪えるチャンス
3. 気分良く開発できて開発速度が下がらない
（開発速度が上がるわけではないのに注意！）

5. ミスやトラブルに対する考え方

6. その前に
ハインリッヒの法則

7. ハインリッヒの法則を3行で
1. 1つの重大事故の裏には29の軽微な事故があり、その裏には
300の異常が存在するという事故発生に関する経験則
2. だから異常を見逃さず対処することが大事
3. 対策に際しては安全工学の考え方が大事

8. 1つの重大事故の裏には29の軽微な事故があり、そ
の裏には300の異常が存在する
同じ人間の起こした同じ種類の330件の災害のうち，300件は無
傷で，29件は軽い傷害を伴い，1件は報告を要する重い傷害を
伴っていることが判明した。このことは5000件以上について調
べた研究により追認されている
(Wikipedia: ハインリッヒの法則より）
→300の異常を見逃してると大事故が起きるということ

9. ミスやトラブルに対する考え方
1. ミスやトラブルは確率的に起きるものと考える
2. 不安定な仕組みの上に安定した仕組みを構築することは可能だと
考える
3. ミスは許容する.ただし最初の一回だけ
4. 根性論は禁止です
順番に説明していきます

10. 1. ミスやトラブルは確率的に起きると
考える
→ トラブルはありとあらゆる隙間をぬっておきるので、原因を漏れなく
潰すというやり方は限界があると考える
トラブルの発生回数 =
機能数＊アクセス数＊ユーザ数＊データ量*発生確率
→事業がうまくいくほど辛くなる(事業がうまくいかないともっと辛い）

11. トラブルの発生頻度は複雑化の兆候
トラブルの発生回数 =
機能数＊アクセス数＊ユーザ数＊データ量*発生確率
売上
複雑性
一般の人が考える複雑性の増加
（一次関数）
実際の複雑性の
増加（n次関数）

12. トラブルの発生頻度は複雑化の兆候
複雑性増加に対してエンジニアの単調増加（一次関数）では
対抗できない→これが遅くなる真の理由
→複雑性が一定以上になると個人の頑張りではどうにもならなくなる
売上
複雑性
一般の人が考える複雑性の増加
実際の複雑性の
増加（n次関数）

13. 2. 不安定な仕組みの上に安定した仕
組みを構築することは可能だと考える
RAIDやロードバランサーと同じ考え方。パーツが確率的に不安定に
なるとしても、システム全体の安定性を諦める必要はない

14. 3. ミスは許容する。ただし最初の一回だけ
どんなに馬鹿げた理由であっても、
そんなことを許したシステムのせいと考える
→ただし必ず対策を要求し、全く同じ理由による再発は許容しない
（トラブル報告自体をしないことはもっと許容しない）

15. 3. ミスは許容する。ただし最初の一回だけ
（補足）
1. たくさんアウトプットをする人は確率的にトラブルを踏みがちなので、
責めるのではなく、たまたまトラブルを踏んだ人と考える
2. むしろトラブルが発見できて良かったと考える
3. 犯人捜しに意味はない

16. 4.根性論は禁止です
「以後気をつけます」とか「死ぬ気で頑張ります」は基本ナシ
理由：個人の英雄的努力を永遠に期待することになり、
頑張りきれなくなったら破綻するから
頑張りはとても貴重な資源で無限には供給されない

17. 対策の考え方

18. 対策の考え方
対策には2種類ある
• 発生対策: 不良品が発生しないようにするための対策（そもそもそんなミスが起きえな
いようにする）
• 流出対策: 不良品が発生した際に外部に出ないための対策（そのミスが万一おきても
大丈夫なようにする）
→こっちが超重要。なのにあんまり実施されてない！
再発防止に際してこの２方向の対策を徹底することでトラブルは激減します

19. 対策の考え方
例）工場の2階から工具を落とし、頭にあたる事故が頻発するという
トラブルの対策を考える
• ✖ダメな方法
• 工具を落とさないように気をつける（根性論禁止）
• 〇より良い方法
• 落としても大丈夫なように工具に紐を付けておく
（発生対策:そのミスが起きえないようにする）
• 落としても大丈夫なように工場内ではヘルメットを着用
（流出対策：そのミスが万一おきても大丈夫なようにする）

20. 本当にトラブルをなくすために
• 対策は必ず発生対策と流出対策の両面で
• トラブルは絶対にゼロにできると心から信じ、社内に発信し続ける
• 軽微以上のトラブル対応の優先度を最大にする
(優先度最大というのは文字通りの意味で、対応者が他のことやってるのならその開発自体を止める）
• QAがあぶり出してくれた不具合もトラブル扱いとして対処
• ヒヤリハットは必ず報告（対応は必要そうなら行う。全部は対処しない）
↑上記は前職で実際にやってたことです

21. 対策がしんどくなりすぎないために

22. 対策のための開発はしんどくなりがち
• 直しにくいトラブルの存在
• 検知が改善するとヒヤリハットの発見精度があがり、対策のバックロ
グが積み上がりすぎる
• 積み上がりすぎたバックログの優先度付けがしんどい

23. 対策のための開発がしんどくなりすぎ
ないためのいくつかの方法
• 直しにくいトラブルは頑張りすぎず、でも検知だけはより速く・より高
精度でできるように
（ユーザに気づかれなければギリセーフ）
• 検知が積み上がっていくとそれはテストのように機能するようになる
ので、未来的に楽になると考える
• 積み上がりすぎた対策のバックログは、今となってはそこまで重要で
はなかったと考え、定期的に一旦全部捨て、今から起きたトラブルに
対して積み上げなおす

24. 最後に
ノートラブルな状況を作り、システムで
ビジネスを加速させていきましょう
追加の質問などあれば
Twitter: @yamaz まで

25. いくつか雑多なメモ
1. 機能追加なしであっても単に売れるだけでシステムは痛みはじめる
2. エンジニアであってもこの構造は気づきにくい（のでケアが必要）
3. 機能追加は売上に常にポジティブなので選択されがちだが、マイナ
スの積み上げも同時に行われてることに気づきづらい
4. なので守りの開発も重視しないといけない
5. 設計をちゃんとしてないと、因数分解しても成果が出ない
6. エンジニアは尻を叩かれても個人だとどうにもならないと負の学習を
してしまいがち