トーク

アプリケーション開発をしていると、どうしても不具合は生まれます。
バグ、障害、故障、エラー…近接する概念が色々とありますが、その中でも「プログラムetcの修正で修復できるもの・根治できるもの」が確かに存在します。

実際の所、皆さんのサービスで、それらはどのくらい発生しているでしょうか？その内、直せるはずの「バグ」「欠陥」はどのくらいあるでしょうか？
パッと答えが浮かばない、という方も多いと思います。
どうやってこの状況を脱していきますか。

とにもかくにも、「可視化」「現実的な目標」「コントロール可能な状況を作る」「割れ窓状態を脱する」のが重要だと思います。
そして、それに勝るとも劣らず「なぜ、エラーを少ない状態を実現したいのか。そこにどんな価値があるのか」という認識の統一も欠かせません。
チーム全体を方向づけ、小さな実践を押し進めながら「それらは夢物語なんかじゃない」と勇気づけるような成果を上げていきましょう。

本セッションでは、まずは「エラーやバグがもたらす不経済」について説明します。併せて「なぜ、検知と修復を急ぎたいのか」「遅れが何をもたらすか」も扱います。
その後に、自身の体験も踏まえながら「どうやって・何を努力していき、チーム一丸となって”エラーを減らす”を実現していくか」について共有します。

想定するオーディエンス

• 「エラーを減らしたいな」「バグを減らしたいな」という気持ちのある人
  • もしくは「減らせるのだろうか」と気にしたこともなかった人
  • とはいえ「ガチガチのレギュレーション」や「窮屈さ」は望んでいない人
• チームの生産性に課題を感じている人、向上させたいと考えている人

本セッションで得られるもの

• 「なぜエラーを減らしたいか」の理論的な背景、根拠となりそうな情報
• 組織として、どのようにエラーやバグを減らしていくか？という導入-出口の戦略
• アプリケーションエラートラッキングツールの活用方針
  • Sentryの利用を想定しています

本セッションで話さないこと

• アーキテクチャや「良いコードの書き方」といった、品質面の話

関連リンク、参考書籍

• ウェッブアプリケーションのエラーを無くしていきたいわよねという話 - 大好き！にちようび
  • 過去に、エラー管理についてのスタンスについて吐き出した自ブログの記事
• LeanとDevOpsの科学
• This is Lean
• レガシーコードからの脱却
• アート・オブ・アジャイル・デベロップメント
• アジャイルプラクティス