品質はチームの問題です。品質を気にかけないチームに配属されると、どんなに優秀な開発者でも面倒な問題を修正する情熱を維持しづらく感じるようになるのです。さらに、こういった修正に時間を割くことに対してチームが消極的であれば、あるほど、問題は悪化していくのです。
 | アンドリュー ハント￥ 3,990  |
割れ窓理論というのはご存じですか？建物の窓が割れているのを放置していると、やがてすべての窓が破壊されていくという理論です。
ソフトウェア開発に置き換えると、小さなバグを知っているのにもかかわらず、放置しておくと、どんどんバグだらけになっていくということになります。これは、バグだけいえることではなく、テスト駆動開発にも同じことがいえます。テストファーストのアプローチをせずに、テストがないコードを少しでも積み上げた状態をそのままにすると、どんどんテストがないレガシーコードが生産されていきます。品質は低下していく一方です。
達人プログラマーはどうするのか？
p.229 第8章 達人のプロジェクト
全員が環境の変化を積極的に監視しているかどうかを確認するのです。また、水質検査のチーフを任命するのです。その人が幅広い視野と、短い時間尺度で定期的に、追加機能、新環境といった元々の合議事項に無かったものをチェックするのです。そして、新たな要求として管理するのです。
誰かがバグを直すだろう。誰かがテストを書くだろう。そんなことは無い。あるとすれば、問題が起きてからだ。そうなってからでは遅いのである。
すぐに経験豊富な幅広い視野を持ち合わせたメンバーを品質リーダーに任命しよう。そして、バグや漏れているテスト、重複化している部分などをピックアップして、新たな要求や要件として管理しよう。そう。新しい機能を追加するというリストに並べるのだ。実際に起きていることを把握するだけでも大事故は防げるだろう。
HIROCASTERの経験から
小さいバグや考えられる脆弱性などをピックアップしてくれるQAチームがいたとしたら、彼らはとても重要な役割を担ってくれます。
ですが、バグや脆弱性を直すのはプログラマー自身です。彼らがその問題を管理するかが問題なのです。Tracなどチケット管理をおこなっているのであれば、すぐさまチケットを発行しましょう。そして、チーム全員で定期的に優先度を見直すべきです。小さいバグでも数が増えてくると、チームとしての認識や優先度も変わってくるはずです。
いつ、どういうレベルで、設計レビューやコードレビューを実施するのか明確にしてチームメンバーと共有しましょう。そして、どういうレベルのテストコードを必須とするのかを明確にしましょう。それぞれのルールは現実的であるべきです。どんなに高い要求を立てても、実施できなければモチベーションも下がり、何の意味もないものになります。
上記について責任を持つ技術的なチーフを任命しましょう。チーフは開発スタイルとルールを立て、実施しましょう。そして、プロジェクトの進行と管理をおこなうマネージャーがこの役割を兼任するのは危険です。それぞれの役割は求められる役割が違います。そして、お互いの立場での意見や論議ができなければ、マネージャー兼チーフのワンマンプロジェクトができあがあるでしょう。
達人プログラマーがチームに入り、達人チームとなるための参考になれば幸いです。
 | Venkat Subramaniam￥ 2,520  |
