_ テストコードがもたらす◯個の良いこと

タイトルは釣りです。釣れたのかわかりませんが。

昨日はTDD Boot Camp Tokyoが行われたということで、申し込みに乗り遅れて参加できなかったので、色々とテストについて考えてみた。

自分が真面目にテストコードを書くようになったのは、東京Ruby会議03の@t_wadaさんのワークショップに参加してからだ。今でもこのワークショップで得た感動を覚えている。簡単なハンズオンではあるが、テストが開発を駆動するところを実感できた。それまで、テストコードは書きたくても

• テストコードを書くということはコード量が増えて、開発期間が伸びる
• コード量が増えるので、コードレビューの量も増える

といった漠然としたリスクを感じていたので、利点を感じつつも、テスト駆動開発をやる気が起きていなかった。 ところが、先のワークショップで、利点の方が大きいし、むしろこの不安はほとんど起き得ないと感じた。そして、今では実際にその不安は無い。

テストコードを書くということはコード量が増えて、開発期間が伸びるか？

テストの分も書かなければならないので、コード量は増えるかもしれない。だが、これが単純に開発期間を伸ばすかというと、そうではない。 ある機能を開発をする時、開発者が行うことは単にコードを書くだけではなく、その前に

• 機能の仕様を理解し、
• 機能の実現方法を考える

という2つの工程があり、そして、それをコードで表現すると思う。テストコードを書くということは、これら2つの前工程に相当する。

テスト駆動開発をやり始めの頃は、この過程に時間がかかるかもしれない。自分はそうだった。けれど、これはコード量が増えたからではなく、それまで頭のなかで仕様を理解する上で使っていた言葉が、自然言語からプログラミング言語に変わったためだ。本質的な仕様理解に時間がかかるようになったのではなく、その表現方法が変わったので、新しい表現方法に慣れさえすればいい。

つまり、TDD導入直後は学習コストの分だけ増えるけど、そのリスクは継続することで抑えることができる。

コードの量が増えるので、コードレビューの量も増えるか？

レビュワーは、変更されたコード、新たに追加されたコードをレビューする。レビューする観点はチームやプロジェクトに依るのが、TDDを導入した直後はテストコードが加わった分だけ、レビュー対象のコード量は増える。

レビュワーがやることは、開発者が書いたコードやドキュメントから

• 機能の仕様を理解し、
• 機能の実現方法を考える

そして、レビューすることだと思う。テストコードはこの工程を助ける。 テストコードには、開発者が理解した仕様が、「どういう時に（前提条件）、どうなっているべき（期待値）」という形で書かれているので、理解しやすい。 しかし、以前はそれが異なる言語、つまり自然言語だったのがプログラミング言語に変わっているので、TDD導入直後は時間がかかる。

結局、開発の時間が増えるかもしれない、というのと同じことで、学習コストによって時間は一時的に増えるが、継続することで抑えることができる。

上の2つのリスクは解消可能なので、利点の方が自然と大きくなる。 ドキュメントや口頭の自然言語でやりとりしていた仕様理解を、実行可能であるプログラミング言語にすることで色々捗る。

まとまりのない文章になってしまったけど、要するにテスト駆動で開発に取り組まない理由は無いと思うので、みなさんテストを書いてハッピーエンジニアライフを送りましょう。

_ Scrum Master Night 第4夜に行ってきた。

以前からFacebookとかでちらほら見ていて興味があったので、Scrum Master Night に行ってきました。

スクラムマスターが集まって、それぞれが持ってる疑問や悩み事を、会社の壁を超えて、オープンにディスカッションするといったイベント。ファシリテーターは、その場で決め、テーマも会場から応募・投票し、最終的には各ファシリテーターが決めるという、参加者主導型で面白かった。

で、折角なので、ファシリテーターに立候補してディスカッションしてきました。

選んだテーマは、

ということで、普段聞けない他社での評価とか、それに対してスクラムってどういう位置づけなのか、といったところで議論した。

ファシリテーターと言いつつ、「面白い話だ」とウンウンしながら、一番楽しんでいる聴衆であったような気がする。

議論したことできになる所を以下にメモ。

• プロジェクトの目標達成に向けて、スクラムはチーム一丸となって活動するので、評価できるのもチーム単位になってしまう。
• なので、スクラムは個人の評価について考えられてない（当たり前といえば当たり前）
• でも、現実世界としては、「個人を評価したい評価者」と「成果を生み出すチーム」が存在するので、その間のやりとりをするためのインターフェースが必要
  • でも、ストーリーポイントで評価する、というのはナンセンスだよねぇ。。。
• チームで活動しているのだから、チーム内でみんな均一の評価をされるべきだ。
• とはいえ、それで納得できるかというと、頑張った人と頑張ってない人が極端に現れていたら、納得いかないだろう。
• 頑張ってない、やることが少ないは悪だろうか。定義によりそう。
  • 専門とする分野の仕事が今はない。例）デザイナーだけど、今はインフラのトラブル対応が続いていて、特に手を出せるところがない。とか
  • そもそもやる気が無い。とは異なる。
  • 脱線した話だけど、チームとしてゆとりを持つというのは良いことという話に。

なんだかまとまりのない発散した議論になってしまいましたが、個人では考えるのが難しいところが、色々な視点（評価者、評価対象者であったり、SMだけでなくアジャイルコーチがいたり）の意見が聞けたので、非常に面白かった。

その後の懇親会でも、議論は絶えず、

• 見積が、時間ではない、というのがなかなか伝わらないよねー
  • 時間ではなく、作業量、難易度、リスクなど実は色々見積もる単位がある。
• スプリントバックログに良いツールってなんだろうねー
  • ホワイトボードカンバン最強説。
    • タスク管理だけでなく、チーム内のコミュニケーションツールとして使える。

みたいな話をした。

次回は8月下旬から9月上旬に開催するそうなので、SMの方もそうで無い方も都合が付く方は、日頃の悩みを持って行ってみると良いと思います。

参考

• 第4回 Scrum Masters Night （スクラムマスターズナイト） - connpass