"How Google Tests Software"を読んでる

まだ読み途中だけど、本の中の↓の言葉で、何か自分の中でつながった感じがあったのでメモ。

"quality in not important until the software is important"


レガシーコード問題

どの現場にもレガシーコード問題だったり、何でこうやって作っちゃったの?みたいな話は転がっている気がして、トータルのコストを考えれば絶対にキレイに作るべきと考えてたけど、それは自分が担当したことのあるソフトウェアが新たに開発者を必要とするくらい世に必要とされたからで、そもそも品質なんて気にされることも無く、消えていったソフトウェアやサービスもいっぱいあるんだよな〜と。
冷静に考えてみると当たり前だけど、何か目から鱗の感じがあった。

20%ルール

Googleで有名になった20%ルールってのは、エンジニアのモチベーションアップのためのちょっとお洒落な取り組くらいに思ってたけど、実はとても合理的なモノじゃないかなと感じた。
20%ルール無しで(有象無象の色んな会議を経て、、)、ほんとのプロジェクトばかりになってしまうと、テストや運用の工数を含めてかっちりと決めねばならずやることが増えるけど、そもそもそのソフトウェアが重要かどうかってのが判断がつく前に、そこまで突っ込むこと自体がリスクだし、打てる数が少なくなってしまう。
20%ルールでソフトウェアの多産多死の状態を作りつつ、重要になったソフトウェアに対してはクオリティを保証するためのテストの準備やデプロイの自動化等をきっちりと行ってソフトウェアのデリバリーのスピードを早める。この両輪が大事なのかなと思った。


CIとかInfrastructure as Codeとか、内側のループの話は最近旬で、自分もどっちかというとそういう方面の話のほうが好きだけど、テストが無かろうがコードが汚かろうがスケーラビリティが無かろうが、外側のループを懸命にまわしながら、ユーザに必要とされるサービスやソフトウェアを作り上げたこと自体に敬意を払いながら、仕事に取り組んでいくべきと思ったのでした。


"quality in not important until the software is important"

大事な言葉なので2回書いておいた。


How Google Tests Software

How Google Tests Software


テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発