『組織にテストを書く文化を根付かせる戦略と戦術』の再演に参加してきました

2016年3月11日（金）に、『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術＋α』というイベントに参加してきました。

@t_wadaさんの下記スライドが、今まさに自分がやっているテスト自動化支援・アジャイル支援のヒント満載だったため、どうしても直接お話を伺いたく参加した次第です。
『組織にテストを書く文化を根付かせる戦略と戦術』
http://www.slideshare.net/t_wada/test-strategy-and-tactics

以下、個人的に気付きがあった点のメモです。

戦略編（6-19ページ）

7ページ目

導入を目的にしてはいけない。
- ついやりがち。
- 現実を見せ、現実に即した解決策で改善していくことになる。（伊藤）

11ページ目

文化を変えるのには、2-5年はかかるとのこと。
環境は変わり続けるので、コードに触れないわけにはいかない。

13ページ目

AS-IS & NotToBeから始める。
人は自分の速度でしか成長できない。
- プロジェクトについても、同様のことが言える。（伊藤）
  - 早過ぎてもダメ、遅過ぎてもダメ。
  - 自分の支援しているプロジェクトの進め方は妥当だったか？

14ページ目

人を知る
- メンバーが何によってモチベートされるかを考えてアクションすべし。

15ページ目

リファクタリングのジレンマ（独立タスク化すると、却って行われなくなってしまう）
- ビジネス価値を提供していないように見えてしまうため。

17ページ目

全ては変化する
- 仕様・理解・スキル・技術 etc.

18ページ目

技術的負債の４象限 by Martin Fowler
- http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

19ページ目

テストは品質を上げない
- 品質は分かるようになる
- 品質を上げるのは、設計とプログラミング
- テストを作って既存プロダクトを「壊す」ことで、プロジェクトに改善の必要を気づかせることは可能。（伊藤）

戦術編（20-33ページ）

21ページ目

どこからやるか？
- 不具合駆動
- マネーパス etc.

22ページ目

テスト指針（Lean from the trenches）
- リスク
- 手動テストのコスト
- テストの自動化コスト

23ページ目

誰とやるか？
- 全員でやるのではなく、できる人を少しずつ増やして行く方が良い。
- 教えられる人を増やす。
- ペアプロでひとりずつ。
  - いつも「遅すぎないか」というジレンマに襲われているけれども、これでいいのだという安堵感を感じた次第。（伊藤）

24ページ目

最初から全部やろうとはしないこと！

25ページ目

こだわるべきところ・優先度
- repeatability
- independent

27ページ目

見える化 → メトリクス

29ページ目

コードレビューだけでも、改善につながる。
- 誰かに見られる → 改善

30ページ目

実装を変えることを後押しするテストをつくるべし。

31ページ目

（テストの）サンプル・デモは大事。
動かして初めて実感してもらえる

所感

現在PHPのテスト自動化支援を主にやっているのですが、必ずしもユニットテストにこだわらなくても良いのかな、と感じた次第です。というのも、PHPにはstaticベースのフレームワークが多くて、モックを差し挟んで…といったレガシーコード改善ガイドチックなテクニックがほとんど使えない。で、それでも無理矢理テストを書こうとすると、DBやAPIを直接叩くものになってしまい、そこがビルドを壊す脆い点になってしまうのではないかと…
しかし今回の講演で、出来るところから確実に改善すべしと伺い、別にそんなテストでも無いよりまし、プロダクトの改善につながるのであれば良いのではないかと。
そういう気付きを得られたという意味では、@t_wadaさんに感謝です。