ノートラブルシステムへの道 ビジネス速度を落とさないために
ノートラブルシステムへの道ビジネス速度を落とさないためにTOCQ： 山崎大輔（@yamaz)
View Slide
こういうこと、あるあるです• 勢いよくクラウド上に作られたアプリがある• テストやCI/CDはあんまり整備されてない• コードの質もイマイチで結構デグレする• だけどビジネスはそこそこ回ってる• トラブルに時間取られて開発速度低下（ビジネス速度も低下）• トラブル起因で顧客をライバルに取られる• 対策はやってるものの、モグラたたき感が拭えない2
システムのクオリティは超大事1. クオリティが低いとトラブル対応のため、エンジニアはもとより関係各所の⼯数が無駄に発⽣（意味のない⼯数）2. クオリティの低さは意味のないチャーン（解約）を産む折⾓マーケ費⽤をかけて育てたユーザをライバルにタダで取られる3. システムのクオリティを低いと開発速度が下がるよって成⻑期においてはシステムクオリティは機能追加より⼤事になりえる3
逆にシステムのクオリティが高いと1. トラブルがないため、エンジニアはもとより関係各所の⼯数がかからない（コストが低くなる）2. 安定性はマーケ施策ともなりえるライバルがマーケ費⽤などをかけて育てたユーザを奪えるチャンス3. 気分良く開発できて開発速度が下がらない（開発速度が上がるわけではないのに注意！）4
ミスやトラブルに対する考え⽅5
その前にハインリッヒの法則6
ハインリッヒの法則を3行で1. 1つの重⼤事故の裏には29の軽微な事故があり、その裏には300の異常が存在するという事故発⽣に関する経験則2. だから異常を⾒逃さず対処することが⼤事3. 対策に際しては安全⼯学の考え⽅が⼤事7
1つの重⼤事故の裏には29の軽微な事故があり、その裏には300の異常が存在する同じ⼈間の起こした同じ種類の330件の災害のうち，300件は無傷で，29件は軽い傷害を伴い，1件は報告を要する重い傷害を伴っていることが判明した。このことは5000件以上について調べた研究により追認されている(Wikipedia: ハインリッヒの法則より）→300の異常を⾒逃してると⼤事故が起きるということ8
(あらためて）ミスやトラブルに対する考え⽅1. ミスやトラブルは確率的に起きるものと考える2. 不安定な仕組みの上に安定した仕組みを構築することは可能だと考える3. ミスは許容する.ただし最初の一回だけ4. 根性論は禁止です順番に説明していきます9
1. ミスやトラブルは確率的に起きると考える→ トラブルはありとあらゆる隙間をぬっておきるので、原因を漏れなく潰すというやり方は限界があると考えるトラブルの発生回数 =機能数＊アクセス数＊ユーザ数＊データ量*発生確率→事業がうまくいくほど辛くなる(事業がうまくいかないと別の意味でもっと辛い）10
トラブルの発生増加は複雑化の兆候トラブルの発生回数 =機能数＊アクセス数＊ユーザ数＊データ量*発生確率売上複雑性⼀般の⼈が考える複雑性の増加（⼀次関数）実際の複雑性の増加（n次関数）11
トラブルの発生増加は複雑化の兆候複雑性増加に対してエンジニアの単調増加（一次関数）では対抗できなくなる→開発がどんどん遅くなる真の理由→複雑性が一定以上になると個人の頑張りではどうにもならなくなる売上複雑性⼀般の⼈が考える複雑性の増加実際の複雑性の増加（n次関数）12
2. 不安定な仕組みの上に安定した仕組みを構築することは可能だと考えるRAIDやロードバランサーと同じ考え方。パーツが不安定であっても、システム全体の安定性を諦める必要はない13
3. ミスは許容する。ただし最初の一回だけどんなに馬鹿げた理由であっても、そんなことを許したシステムのせいと考える→ただし必ず対策を要求し、全く同じ理由による再発は許容しない（トラブル報告自体をしないことはもっと許容しない）14
3. ミスは許容する。ただし最初の一回だけ（補足）1. たくさんアウトプットをする人は確率的にトラブルを踏みがちなので、責めるのではなく、たまたまトラブルを踏んだ人と考える2. そうでないとトラブルを起こさないよう、何もしないという行為が個人の最適解になってしまう（それは困るでしょ？）3. なのでむしろ今トラブルが発見できて良かったと考える今後会社が成長するなら今回のトラブルは最も規模が小さいはず→もっとでかいトラブルになる前に発見できてよかったと常に考える（歯を食いしばりながら）4. 犯人捜しに意味はない15
4.根性論は禁止です「以後気をつけます」とか「死ぬ気で頑張ります」は基本ナシ理由：個人の英雄的努力を永遠に期待することになり、頑張りきれなくなったら破綻するから頑張りはとても貴重な資源で無限には供給されない16
対策の考え方17
対策の考え方トラブルが外部に出たら事故扱い。対策には2種類ある• 発生対策: トラブルが発生しないようにするための対策（そもそもそんなトラブルが起きえないようにする）• 流出対策: トラブルが発生した際に外部に出ないための対策（そのトラブルが万一おきても大丈夫なようにする）→流出対策が超大事。なのにあんまり実施されてない！再発防止に際してこの２種類の対策を徹底することでトラブルは激減(!!!)します18
対策の考え方例）工場の2階から工具を落とし、頭にあたる事故が頻発するというトラブルの対策を考える• ✖ダメな方法• 工具を落とさないように気をつける（根性論禁止）• 〇より良い方法• 落としても大丈夫なように工具に紐を付けておく（発生対策:そのトラブルが起きえないようにする）• 落としても大丈夫なように工場内ではヘルメットを着用（流出対策：そのトラブルが万一おきても大丈夫なようにする）19
対策は流出対策の方が圧倒的に大事！！なぜか？？• 発生対策: トラブルが発生しないようにするための対策• 流出対策: トラブルが発生した際に外部に出ないための対策トラブルはありとあらゆる隙間を縫って確率的に発生する→よってすべての発生原因を事前に潰すことはできない→よって流出対策がとても大事となるでもあんまり重視されてない(´･ω･`)20
本当にトラブルをなくすために• 対策は必ず発生対策と流出対策の両面で• トラブルは絶対にゼロにできると心から信じ、社内に発信し続ける• 軽微以上のトラブル対応の優先度を最大にする(優先度最大というのは文字通りの意味で、対応者が他のことやってるのならその開発自体を止める）• QAがあぶり出してくれた不具合もトラブル扱いとして対処• ヒヤリハットは必ず報告（対応は必要そうなら行う。全部は対処しない）↑上記は前職で実際にやってたことです21
対策がしんどくなりすぎないために22
対策のための開発はしんどくなりがち• 直しにくいトラブルの存在• 検知が改善するとヒヤリハットの発見精度があがり、対策のバックログが積み上がりすぎる• 積み上がりすぎたバックログの優先度付けがしんどい23
対策のための開発がしんどくなりすぎないためのいくつかの方法• 直しにくいトラブルは頑張りすぎず、でも検知だけはより速く・より高精度でできるように（ユーザに気づかれなければギリセーフ）• 検知が積み上がっていくとそれはテストのように機能するようになるので、未来的に楽になると考える• 積み上がりすぎた対策のバックログは、今となってはそこまで重要ではなかったと考え、定期的に一旦全部捨て、今から起きたトラブルに対して積み上げなおす24
いくつか雑多なメモ1. 機能追加なしであっても、単に売れるだけでシステムは痛みはじめる2. エンジニアであってもこの構造は気づきにくい（のでケアが必要）3. 機能追加は売上に常にポジティブなので選択されがちだが、マイナスの積み上げも同時に行われてることに気づきづらい4. なので守りの開発も重視しないといけない5. 設計をちゃんとしてないと、因数分解しても成果が出ない6. エンジニアは尻を叩かれても、個人だとどうにもならないと負の学習をしてしまいがち25
最後にノートラブルな状況を作り、システムでビジネスを加速させていきましょう追加の質問などあればTwitter: @yamazWeb: tocq.comまで26
yamaz
bitkey
whywaita
eiki
newrelic2023
matsujirushi
daihiraoka
optim
takashi1029
yuyakakizaki08
hayaok3
m3hiro3
chmikata
addyosmani
speakerdeck
malarkey
productmarketing
holman
sugarenia
mza
erikaheidi
philhawksworth
mojombo
schacon
philnash