アジャイル開発におけるテスト自動化を自発的に行わせるためのアプローチ
セッションの第2部のメインテーマは「テスト自動化」で、伊藤宏幸氏が社内コーチとして行った現場支援の事例をベースに語られた。
昨今「Time to Market」の短縮が要望されているが、同時に品質の維持も求められている。となると「テスト自動化は製品開発の必須要素」である。
ただ、テストの自動化自体が難しいイメージを持たれている。現場からは「どう実施すればいいのか？ 本当にメリットがあるのか？ 工数が余計にかかるだけでは？」と、懸念が聞こえてくる。
伊藤氏たちコーチの役割は、そうした疑問に一つひとつ回答して施策をドライブすることで、テスト自動化が自発的に実施されるようにすることにある。
まず、テストの自動化はどのように始めればいいのか。伊藤氏らYahoo! JAPANのコーチは、原則としてユニットテスト（単体テストと同義）から始めることにしている。1つ目の理由は、他の受け入れテストや結合テストなどと比較して導入が簡単で、すぐに効果を出すことができるからだ。2つ目の理由は、ユニットテストは実行が簡単な上に実効性が高いこと、つまり各種テストの中で最もROIが高いといえるからだ。
こうして自動化に取り組み始めると、座学やワークショップに参加したり、実際にテスト自動化を実践している現場の見学に行ったりしがちだ。しかし伊藤氏は自らの経験から「ほとんど役に立たない！」と断言。「ハンズオンなどで実際に手を動かして、その価値を“体感”しない限りは効果が見込めない」と語る。
そこで伊藤氏は、次の学習方法を提案。
まずは学びのフリークラウドサービスCyber Dojoでテスト駆動開発やペアプログラミングを“体感”する。次にプロダクションコードへユニットテストを追加。つまり即実践で鍛える。そして必要になってから、理論やテクニックを学ぶ。
伊藤氏はここでCyber Dojoのデモを実施。Cyber Dojoは、5人から10人の集団でテスト駆動開発やペアプログラミングを学ぶには、非常に有効なサービスだという。
デモを終え、続いては「テスト自動化を進める上で、注意するべき落とし穴とその回避方法」が、アンチパターンとして紹介された。
1つ目は「コードカバレッジの罠」。伊藤氏がコーチングしたチームで、コードカバレッジの達成が自己目標化してしまっている事例が挙げられた。これでは「品質の確保」というテスト本来の目的を見失ってしまう。伊藤氏は「『価値あるテストを作る』という意識付けが必要」と痛感。障害が頻発する箇所などを重点的にテストし、そこを集中して自動化することがポイントとなる。
2つ目は「プロダクションコードが複雑すぎて解読できない場合」の対処法だ。伊藤氏は「テストをしやすくすればいい」と語る。まずはテストを補助するツールを探し出して適用する。例えばJavaなら「Mockito」、PHPなら「Phake」「AspectMock」といったものである。
また、テストを実施しやすいアーキテクチャに変えることも重要だ。そのためには仕様化テスト（現状のコードをベースにして作成するテスト）を整備した上で、リファクタリングを行うと良い。
3つ目の落とし穴が「目的を見失い、作業がマンネリ化する」ことである。改善活動を継続していくと、伸び悩み（プラトー）が生じる。しかし「そういうときこそ、壁を乗り越えてさらに伸びるチャンス」と、伊藤氏は語る。コーチにはチームに適切な刺激を与え、自発的な成長を促すことが求められる。
一番の解決策は「短期の目標設定と振り返り」を行うことだ。定期的に目標を設定させ、一定期間が経過したら目標の達成度合いを確認し、KPTベースで振り返りを行う。そして定期的かつ自発的に、次の改善アクションを提案・実施させる。このような刺激を与えるだけでも効果があり、自発性が刺激されてチームメンバー自ら解決策を考え出すようになる。
もう1つの解決策は「自主的なテストルールの策定」である。チームにテストのコーディング規約やテスト範囲などを決めさせ、ルール自体の定期的な見直しなどをしていく。すると自分たちで考えるクセがだんだんとついていき、そのチームがどんどん成長していく。
いずれにしても重要なのは「目的のために、良い手段を選ぶ」ことだ。
続いて、伊藤氏は「テスト自動化のためのステークホルダーマネジメント」について解説。
伊藤氏はある日、コーチングしていたチームから相談を受ける。内容は「部長、リーダー、サブリーダーからそれぞれ別途にチームの活動目標を提示するよう求められたため、チームが混乱状態に陥ってしまった。どう対処すればいいのか」というものだ。
調査の結果、ステークホルダーの人数がそもそも多い問題が判明した。それだけではなく、ステークホルダーごとの情報伝達度に差があり、ステークホルダー間の情報共有もうまくできていなかった。つまり、コミュニケーションマネジメントに問題があるということだ。
そこで伊藤氏は「コミュニケーション管理をやるべきだ」と提案。それに対しチームは「私たちはエンジニアだから、ユニットテストのコードを書くことに集中したい。ステークホルダーたちの問題だから、自分たちは関係ない」と主張し、状況を自ら改善することに消極的だった。しかし「情報の交通整理はステークホルダーを喜ばせる。それは仕事に集中できる環境作りにプラスとなるし、テスト自動化実現のための立派な行為である」と、伊藤氏は説得。
その結果、チーム自らステークホルダー全員が会する場を設定し、腹を割って話す機会を設けてくれた。すると、わずか30分間で必要な情報共有と次のアクション決めが達成され、全ての問題が解決した。
この成功体験から、そのチームは自発的にステークホルダーとの調整を進め、情報の齟齬がないよう振る舞うように変わった。現在、チームはコーチ陣の手を離れて自走しているという。
このように、テストの作成に集中でき環境を作ることも、立派なテスト自動化といえる。そのためにも、適切なステークホルダーマネジメントは重要だといえる。
伊藤氏は最後に「ここまでお話したことが“当たり前”ではなく、できないのであれば、そのチーム・組織・会社には問題があるといえる。そうした問題を解決・克服して“当たり前”に振る舞えるか？ それが、市場で勝ち続けるための品質を確保することにつながるだろう」と語り、セッションを終了した。
お問い合わせ
ヤフー株式会社
