はじめに
この記事は、ポエム Advent Calendar 2016 15日目の記事です。
過去
半年前に入社したときのSQUEEZEのコードは、いわゆる不吉な匂いに満ちていました。
- 重複したコード
- 長すぎるメソッド
- 巨大なクラス
- 長すぎるパラメータリスト
などなど。
ただスタートアップでスピード重視の開発をしていたので仕方なかったのだと思います。
現状
※ まだバグゼロは実現してません。少なからずバグは存在しています。
サービスをよりスケールさせていくために、それに耐えうる品質が求められています。 バグゼロに向けて、現在次のような取り組みを行っています。
これらに関しては、バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログの記事をおおいに参考にしています。
ここではこういった取り組み以外に、バズゼロに向けて自分が大事にしているエンジニアの教訓を紹介します。
- ボーイスカウトの規則
- 割れた窓の法則
ボーイスカウトの規則
http://d.hatena.ne.jp/asakichy/20100706/1278377244
アメリカのボーイスカウトにはシンプルな規則があります。「自分のいた場所は、そこを出て行くとき、来た時よりもきれいにしなければならない」というものです。
これは、実装作業にも当てはまります。コードは何度も洗練され続けなければならないからです。
割れ窓理論
http://d.hatena.ne.jp/asakichy/20101217
長期間修理されることのない割れた窓が1枚でもあると、ビルの住人に「投げやりな(ビルの状態など気にもかけないようになる)感覚」が植えつけられていきます。すると、次の窓が割れます。さらに、ゴミが撒き散らかるようになります。落書きもされるようになります。
このようにして、たった1枚の割れた窓から、建物全体に対する深刻な破損が起こり始めるのです。これが「割れ窓理論」です。
ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意志決定」「悪いコード」を放置してはいけません。ソフトウェアをごく短期間で腐敗させることになります。「割れた窓」が何枚かあるだけで、「残りのすべてのコードもガラクタなんだから、自分も適当に作業してしまえ」という考え方が忍び込みやすくなるのです。
伝えたいこと
つまりこういった日々の小さなカイゼンが、品質の継続的な向上につながっていくのだと。ここに銀の弾丸なんてものはない。
「忙しいからカイゼンできない?」 ちがう、カイゼンしないから、忙しいのだ。 :: by and for engineers
このタイトル通り、カイゼンしないことの積み重ねは未来の自分の首を締めることになる。
カイゼンすべき割れ窓に気がついたら、言い訳せずに見て見ぬ振りをせずに真摯に向き合っていく姿勢こそが、バグゼロ実現のために必要なことなのだと信じています。