小さく失敗する？

さて、いきなり失敗するって書いてあって驚きましたか？そもそも失敗なんてしたくないわって思う人がほとんどだと思います。実際僕もそうです。失敗なんてしたくない。失敗をゼロにすることこそが本質だろうと。

だが、人間は失敗する

そうなんです。いくら失敗したくないと思って注意したところで、僕らが人間である限りは必ず失敗します。悲しい事実として人間は決して完璧な生き物ではないのです。恥ずかしながら僕はありとあらゆる失敗を経験してきました。辛いですね。

当然ながら完璧な物を作りたい。失敗なんてゼロにしたい。バグゼロだ！！と思って日々開発を進めるわけですが、こう思って寝る間を惜しんで開発に着手してありとあらゆるテストをして不安に押し潰されそうになりながら日々を生きたところで、いざリリースをしてみると残念ながらバグは発生します。ちょっとしたバグからクリティカルで死にたくなるようなバグまで。

失敗の影響をコントロールする

バグを出さないように努力することは当然の義務ではあるんですが、少し視点を変えてみます。そもそもバグは必ず起こる。だったらそのバグで発生する影響を最小限にできるようコントロールすることで安心を得ることができるのではないかと。バグは不確実性だと思っているんですが、バグの影響を最小限に留めつつリリースを行う環境を整備し、チームに浸透させていくこと、つまり不確実性をコントロール出来るようにすることもエンジニアリングマネージャーとしての仕事なのではないかと思っています。以下、弊チームで推進している小さく失敗するための施策を紹介します。

小さく失敗するための工夫

小さくリリース

リリースするうえで、如何に必要最低限の機能をリリースするのかを意識して動きます。一つの機能を考える時、全てを同時に出すことに拘りがちですが、一度立ち止まってもっと小さく機能を分解してリリースしていけるのではないかと考えてみます。最小限の機能で小さくリリースすることで以下のメリットを享受することができます。

最小限の工数でリリースしていくためスピードが早い
リリースしていく中で新たな課題が見つかり方向転換しやすい

プルリクを小さく

小さくリリースにも関連しますが、プルリクを出来る限り小さい単位に区切ります。例えばですが、modelの実装のみ先にプルリクを出す等です。プルリクを小さくすることで下記のメリットを享受できます。

レビューしやすい

差分が少ないため当然レビューに対する労力は減ります。変更点に焦点を絞れるためレビューの見逃しも減ります。

バグの影響範囲を絞りやすい

差分が少ないため、どこの変更が影響しているのか調査が容易になる

バグが出た時にロールバックしやすい

コードに差分が少ないため、リリース後バグを検知したあとに一旦releaseのバージョンを下げてデプロイする際の影響範囲が少ない。
※リリースされる機能が絞られているため他の機能までロールバックしなければいけないみたいな状況が少なくなる。
※エラーの検知をしっかり整備しておくとより安心した開発が可能になります。

feature togglesとcanary release

特定の機能やrubyのバージョンアップ等の段階的なリリースを可能にしてくれます。例えばですが全体の1%にのみ機能をリリースしてエラーが発生するかどうかを確認しつつ、徐々に公開率をあげて確かめて行くことができます。特に複雑な作りになっている箇所だったり支払い周りといったクリティカルな箇所に修正を加えたりといった場合に圧倒的な安心感を与えてくれます。メリットは下記です。

user単位であったり公開比率といった段階的リリースが可能
ごく一部のユーザーにのみ公開し挙動をチェックすることが可能
仮にバグを発見した場合、一旦公開率を0%に戻す事で落ち着いてバグの修正に取り組める
公開比率を調整できるため、A/Bテストも気軽に行う事ができる

※feature togglesとcanary releaseの考え方はujihisa氏がfablic時代に持ち込んでくれました。感謝

まとめ

失敗は必ず起こるもの
失敗の影響範囲をコントロールできるようにすれば開発に圧倒的な安心感が生まれる
安全にリリースするための手法を導入・展開していくこともエンジニアリングマネージャーの役割だと思う

※当然の事ですが、バグ自体は起こさないように全力を尽くしましょうね！！

では、楽しんで開発していきましょう！！

酒と俺と色々

仕事だったりプライベートの事をつらつらと書いていくつもりです。

小さく失敗しませんか？