という概念が存在しない

退屈な

失敗

Web開発2016/12/19 ShippaiNightおーはら @ohrdev

発表の趣旨• ( 私の ) 失敗に対する考え方• ( 私の失敗 ) 事例紹介• 知見共有

発表の趣旨• ( 私の ) 失敗に対する考え方• ( 私の失敗 ) 事例紹介• 知見共有• ローストビーフ

Agenda• 自己紹介• 失敗とは• 失敗時の対応• 失敗の防止• 事例紹介• まとめ

自己紹介• おーはら @ohrdev• 株式会社ドリコム– 基盤技術部 / 広告チーム– サーバーサイド /AD/ スペシャリスト– Elixir/Phoenix, Erlang, Ruby/Rails, Lisp, etc– 仏像制作 / 広告配信 / 全社基盤システムのお世話

• tokyo.ex, ElixirConf, VRTech.tokyo の主催運営• # 仏像 , # 寺社仏閣 , # 写経 , # 丸太 , #VR,

#LEGO, # 丸太収集

事故紹介

宣伝 (1)

• 株式会社ドリコム– エンジニアを絶賛募集中です– http://www.drecom.co.jp/recruit/

– TechBlog 始めました– https://tech.drecom.co.jp/

宣伝 (2)• SoftwareDesign 2016/11, 12 月号– [ 次世代言語 ] Elixir の実力を知る– http://gihyo.jp/magazine/SD/archive/2016/

201611– http://gihyo.jp/magazine/SD/archive/2016/

201612

失敗とは• 人は必ず失敗する– 失敗しない xxx はない

• 失敗のサイクル– 挑戦 -> 失敗 -> 発展 -> 挑戦 -> 失敗 -> 発展 -> …

• 成長の裏には失敗がある

本当に役にたつ「失敗学」 より

失敗とは• Web 開発における失敗分類– 組織 / チームの失敗– サービスの失敗– テクノロジーの失敗– アーキテクチャの失敗– ソフトウェアの失敗– オペレーションの失敗

失敗とは• 失敗 == 間違い ではない– (web サービス開発の文脈では ) フェーズによって、最適解が異なる– ex) テストを書かない• プロトタイピング、 α 版

– ex) マイクロサービス vs モノシリック• サービスの規模による

• 障害 /Bug ⊂ 失敗– 本発表では障害 /Bug は失敗に含めます

失敗とは• 失敗 ( 障害 ) 原因の階層

件数

重大度

個々人が原因

未知なる原因社会が原因組織が原因チームが原因

トランプが戦争起こした大地震が起きたAWS/GCP の障害取引先が倒産した

長期間続く高稼働状態適切な人員配置ができていないレビュー体制が無いテスト /CI が無い引き継ぎが無い

考慮不足うっかり確認漏れ無知勉強不足

失敗時の対応• チーム / 組織としてどうすべきか• 放置しない• 助ける / られる

失敗時の対応• チーム / 組織としてどうすべきか

失敗

組織長

組織

チーム

上司

教育者

先輩

同僚

致命的な事故を防止する( 失敗した者の ) 成長を考える重大な事故を予防する

( 失敗した者の ) 成長を考える小さな失敗をさせる失敗の後始末を手伝う

失敗者を助けて自分も学ぶ

失敗時の対応• 放置しない– 失敗を放置すると失敗が成長 ( 拡大 ) する• テストコード不足、コードメトリクス• チーム文化• スロークエリ、 N+1 問題• データ量 ( ログのローテート忘れ )• ログのとりわすれ

–割れ窓を防ぐ– 大きな失敗 / 障害 /Bug の原因になる

失敗時の対応• 助ける / られる– 失敗時は周りに助けを求めるべき

• 責任感の強い人ほど自分でなんとかしようとする• 自分ではどうしようも無い場合は詰む

–日頃から助けを求められるパスを作っておく• 普段から周りを助けておかないと、いざという時に助けてもらえない（助ける : 助けられる =5:1 くらい )

–仕組みが無いと辛い（組織として取り組む )• エンジニア間のつながり• 助け合える文化、失敗を許容する文化• 空気

失敗時の対応• 助けられる

失敗時の対応 (空気 )

社内コミュニケーションにおける unk の可能性http://onk.bz/data/2008-02-24/1000speakers2.html

失敗時の対応 (空気 )

失敗時の対応 (空気 )

失敗時の対応 (空気 )

失敗時の対応 (空気 )

失敗時の対応 (空気 )

失敗時の対応 (空気 )

• 助け合える文化、助け合える空気• 失敗を許容する文化、失敗を許容する空気• ミスを憎んで人を憎まず

失敗の対策• 知見を貯める• 情報の残し方• トップダウンで

失敗の対策• 知見を貯める–客観的な失敗情報 (だけ ) は役に立たない– 当事者の心理状態、行動、考えが重要

失敗 記述 記録 伝達知見化背景

心理状態経緯 原因

対応総括

連鎖の防止共通認識

仕組み・system

失敗の対策• マニュアル– 失敗しない手順しかない– マニュアルにない手順を行うとどうなるかが無い–想定外の事態が発生するとどうにもならない

• 失敗時の記録 / 知見が重要– どう失敗したか– どうして失敗したか– どうすれば回避できたか

失敗時の対策 (情報の残し方 )マニュアル

S

G

想定外のケースに対処できない

失敗時の対策 (情報の残し方 )べからず

想定外のケースに対処できない

失敗時の対策 (情報の残し方 )失敗事例

想定外のケースに対処できない

失敗時の対策 (情報の残し方 )知識・知見

どんな失敗、どうして失敗、どう回避するか

失敗の対策• トップダウンで–ボトムアップではぬるい対策になりがち– トップが率先してやる– 個人努力ではなく、仕組み・ルールとして実行しないと中途半端になる• ルール・プラクティスの導入• Spec/lint/CI の強制実行など

–痛み（心理的障害）が発生するので、ある程度の強制力があるとスムーズに導入できる

事例紹介 ( 組織 / チーム )

• 職種間 ( 営業 /企画 / 開発 / 運用 ) の断絶– 開発だから〜まで、営業だから〜まで–⇨お見合い状態からの情報落ち–⇨音頭取り不在によるサイクルスピード低下– スクラム /1 チーム感の醸成（空気 )

• 教育としての失敗 ( どう失敗経験をさせるか )– ペアプロ , コードレビュー–検証環境へのリリース & ストレステスト

事例紹介 ( テクノロジー )

• ライブラリ・ミドルウェアのバージョン– 後回しにすればするほど、バージョンアップコストが増大する–⇨Ruby1系、 Rails2系バージョンのシステム–⇨セキュリティ対応ができなく , 自力でやらないといけなくなる（パッチが出ない）– レガシーバージョンのシステムのメンテコストが非常に大きい– お金を稼いでいるのであれば、レジェンドコード

事例紹介 ( アーキテクチャ )

• 自動化 (CI による自動 deploy/operation)–初期フェーズから導入しないと高いコストが必要になる–⇨初期から導入していないと Deploy周りの操作は心理的ハードルが高い• AWS のサービス管理 : Terraform から

ServerlessFrameworkへの移行–仮想化は初期フェーズから入れておかないと導入するのが難しい /ハードルが高くなる

事例紹介 ( アーキテクチャ )

• 失敗に強いアーキテクチャ–耐障害、監視機構、 etc–負荷分散、スケールアウト / アップ– マイクロサービス• リアーキテクチャ、サービスの入れ替え etc

事例紹介 ( プログラミング )

• Lint/ 自動テスト /CI– 開発初期に Lint/ 自動テスト /CI を導入していなかった–⇨ある程度開発が進んだ状態で導入した時にワーニングが大量に出て導入コストが増大–⇨( 知見 )初期フェーズに必ず入れるべき–⇨( 知見 ) 失敗を放置してはいけない– テストが無い状態からテスト導入 (80%程度のカバレッジ ) まで年単位のコストを支払った

事例紹介 ( プラクティス )

• 変更に対する恐怖と戦う– リファクタリング– リアーキテクチャ–変更に対する恐怖とどう戦うか• テスト• 検知• マイクロサービス化

–⇨小さな変更を多く繰り返す

まとめ• 失敗に対して正しいアクションを• 失敗を成長の糧に• 失敗を怖がらない

という概念が存在しない

退屈な

失敗

Web開発

という概念が存在するからこそ

退屈せずに楽しめる

失敗

Web開発

参考文献• 「使える失敗学」• 「図解 使える失敗学」• 「 Code Simplicity 」• 私のチームの Redmine/Wiki• OSS の issue リスト• etc