アジャイルとテスト自動化の現場2016

皆さんこんにちは。ヤフー株式会社の第6代黒帯（アジャイル開発プロセス）、伊藤　宏幸（@hageyahhoo）です。

システム統括本部　技術支援本部所属のアジャイルコーチ＆自動化コーチとして、社内各サービスによるアジャイルおよびテスト自動化の自発的な実現を日々支援しております。また、Scrum Alliance公認の認定スクラムプロフェッショナル（CSP）でもあります。
12月19日のAdvent Calendarを担当させていただきます。

今回は、特に今年、アジャイルコーチ＆自動化コーチとして現場で気付いた課題とその解決策について紹介します。皆さんの日々の仕事をより良くするための何らかのヒントになれば幸いです。

1. 仕事をしやすい環境を自分たちで作ろう

あるチームで、ユニットテストの自動化について教えていた時の話です。

チームの活動目標を提示するよう「サブリーダー」から求められ、キチンと「サブリーダー」に提示したのだけれども、そのあとに「部長」と「リーダー」から別途目標を提示するよう求められ、混乱しているという相談を受けました。

どういうことなのか調べてみたところ、以下のことが分かりました。

• ステークホルダーがそもそも多い。
  • サブリーダー・リーダー（複数名）・部長・テクニカルディレクターなどなど
• ステークホルダーで、情報が届いている人と届いていない人がいる。
• ステークホルダーの間でも、情報をやりとりしている人としていない人とがいる。

要は、ステークホルダーの管理、特にコミュニケーションの管理ができていないため、言っていることが全員違う、伝言ゲームのような状態が生じていたのです。

ただ、これだけならば、わりとどこでも聞く話です。厄介だったのは、このチームが「ユニットテストを書くことに集中したい」・「ステークホルダーたちの問題だから、自分たちは関係ない」と言い張り、この状況を自ら改善することに消極的だったことです。

そこで私は、以下のことをチームメンバーに説き、この状況を自ら改善することを促しました。

• 情報の交通整理をすることは、ステークホルダーを喜ばせる行為であること。
• ステークホルダーを喜ばせることは、仕事に集中できる環境を作るためにプラスになること。
• 仕事に集中できる環境を作ることは、テスト自動化を実現するための立派な行為であること。

結果、チーム自ら、ステークホルダー全員が会する場を設け、お互い何が分かっているのか/いないのか・何が必要なのかを、腹を割って話し合いました。するとどうでしょう。あれだけ情報の行き違いがあったはずなのに、わずか30分で必要な情報共有と次のアクションが決定してしまったのです。この成功体験からか、その後このチームは、自発的にステークホルダーとの調整を進め、情報の齟齬がないよう振る舞ってくれるようになりました。

まとめです。

• 仕事をしやすい環境を作ることは、立派な仕事です。
• 仕事をしやすくするために、ステークホルダーを喜ばせましょう。
  • ステークホルダーの欲する価値を探り、痒いところに手を届けましょう。
• コミュニケーションは、できるだけ一度に取れるようにしましょう。
  • 伝言ゲームは、諸悪の根源です。

2. 事実に基づいて計画しよう

ある日、見積もりを作成しているメンバーがいたので、その様子を観察してみました。

見積もりの対象となる仕事は、50のプロダクションコードのクラスを対象にユニットテストを作るというもの。期間は2カ月、チームメンバーは10名で、1名あたり週6時間この仕事へアサインできます。
このメンバーは、これらの情報を元に、必要な工数を次のように算出しました。

2カ月 ×　10名　×　（6時間　×　4週）　＝　480時間

その結果に対して私は、「計画・見積もりとして役に立たないから捨てなさい」とアドバイスしました。というのも、既にチームメンバーがこの仕事に先行着手していて、最初の1クラスのユニットテストを作成するのに40時間かけていたからです。この事実に基づくと、見積もりは以下のようになるでしょう。

40時間 ×　50クラス　＝　2000時間

4倍以上の開きがありますね。作業に慣れて、1クラスあたりの作業時間が徐々に減ることを（希望的観測として）考慮に入れたとしても、かなりの開きがあることは否定できないでしょう。

この見積もりの「誤り」の原因は、事実を考慮せずに、与えられた「リソース」を計算式に当てはめただけで見積もりを算出しようとしたことにあります。ある意味、「妄想で」「計画を」「立てた気になっていた」だけだったと言うこともできるでしょう。

ところで、スクラムには「ベロシティ」という考え方があります。「スプリント」（2週間などの一定の期間）ごとに、どれだけの仕事ができたのかを計測したものです。次のスプリントでどの程度仕事できるかを、この数値をベースに、相対見積もりで算出します。先述の、事実に基づいた見積もり方法に近いことが分かるかと思います。この「ベロシティ」を使うと、スプリント（≒仕事）を繰り返すうちに、現実に近い見積もりを算出するためのベースを作っていくことができます。

まとめです。可能な限り、事実に基づいて計画・見積もりをしましょう。より現実に近い答えが得られるはずです。

3. メトリクスでチームとプロダクトを成長させよう

昨今アジャイル界隈では、「メトリクス」（KPIとほぼ同義）というものを活用して、プロダクトおよび開発プロセスの良し悪しを「見える化」する動きが、世界的に広まりつつあります。かく言う私も、このメトリクスを業務で頻繁に取得・活用しています。メトリクスには、施策の推進、ステークホルダーマネジメント、人・チーム・組織の成長という点で効果があります。

特にチームとプロダクトの成長という点について、私が現在ユニットテストの自動化を支援しているチームのエピソードを紹介します。

はじめ私たちは、コードカバレッジとテストケースの増減を見て、チームの活動と成長を確認していました。これらの数値が停滞している時には、支援する質と量を増やし、徐々にチームのテストを書くスキルを高めていきました。

順調だと思っていました。

しかしある日、普段使われていない機能に対して、ユニットテストが多く追加され始めていることに気付きました。メンバーの一部でコードカバレッジを上げることが目的化してしまい、価値のないテストを作り始めていたのです。

そこで私たちは、以下のようなアクションを実施しました。

• 価値のある箇所を意識して、テストを作るよう徹底指導する。
  • よく障害が発生する箇所
  • 金銭取引に影響が出る箇所（マネースイートパス）
  • 頻繁に更新される箇所
  • 新規に追加/更新される箇所
• Pull Requestの量やコメント数など、追加したテストの質を計測する別のメトリクスも、合わせて取得するようにした。（導出メトリクス）
• マネジャーらに、コードカバレッジをメンバーの評価軸に使わないよう説得した。

結果、価値のないテストがなくなった一方、障害につながりかねないいくつかのバグをリリース前に検出することができました。また、メンバーが日々価値・効果を考えながらユニットテストを書くよう、態度が変わりました。

メトリクスはこのように、チームとプロダクトの成長を促進するために活用できます。

メトリクスの基礎（「導出メトリクス」などの用語）やその取得・活用方法については、以下の資料が参考になります。ご活用ください。

4. 成果にフォーカスして実験を重ねよう

私の同僚の森　高（もり　たかし）さん。
初めて会った頃は、自分に自信がなく、常に他者の目線を気にし、指示されたことだけをやりたがる「受け身型」の仕事スタイルの人でした。また、仕事の目的をよく見失い、自分の持っているスキルでとりあえず成果物を作り上げようという、「手段のために目的を選ばない」振る舞いが多く見受けられました。

私が所属しているチームは、アジャイルおよびテスト自動化の、サービスによる自発的な実現を支援する業務を担当しています。そのため、常に支援先の状況を把握し、その時に適したアクションを迅速に実施するという主体性が求められます。そうしたチームの性格上、森さんの上述の傾向・振る舞いは看過できないものでした。自分の頭で考え、主体的に行動できるように、森さんを「変える」必要がありました。

そこで私は、森さんを「変える」ために、さまざまな「実験」を繰り返しました。「5 Whys」や「そのアクションの目的は何ですか？」と言った質問を繰り返したり、危機感を煽ってみたり、あえて突き放してみたりなどなど。しかしながら、いずれも成功したとは言い難かったです。

多くの失敗を重ねたのちに私は、「成功体験を多く積ませることが重要なのではないか」という仮説に行き着きました。というのも、話を重ねていくうちに、森さんに「仕事で成果を出せた！」と胸を張れる経験が少なかったことが、徐々に明らかになってきたためです。成果を出すことを体に染み込ませられれば、自信を持つことができ、仕事の「カタ」ができあがるのではないか？　そう考えた私は、あるチームのユニットテスト自動化支援で、次のように振る舞いました。成果にフォーカスする形で、小さな成功体験を徹底して積んでもらう実験を重ねたのです。

• 2-3日おきに、目に見える成果を出させるようにした。
  • 具体的には、コードカバレッジとテストケース数を見るようにしました。
• 難しいユニットテストを簡単に書けるようにするための「ツール」を渡した。
  • 具体的には、PHPの「AspectMock」を教えました。
• ツールを渡して習得させるだけではなく、その使い方を他の人に教える機会を意識して設けた。
  • 「AspectMockで困ったら森さんに質問しよう！」という状況を、意識して作り上げました。
• 成果が出た時に、「何が良い結果につながったのか」を都度質問して、考える機会を作った。

一連の実験の成果については、森さんの下記資料をご覧いただければと思います。この資料にある活動を自分の頭で考えて実践できるようになったことに加え、このような活動成果を「DevLOVE」というコミュニティーのイベント（2016/11/30）で発表するまでになりました。

森さんだけに限らず、私は「成果にフォーカスして実験を重ねる」こうした活動で成長していった人・チームをいくつかみてきました。もし人・チームの成長でお困りの方がいらっしゃれば、一度この方法を試してみてはいかがでしょう。何らかのきっかけになるかもしれません。

5. 甘えさせないようにしよう

仕事をする上で「頼りにされること」は、非常に励みになることであり、また自信にもなることです。しかしながら、「頼りにされること」は時として「甘えられること」と非常に似ていて、見分けがつかないことがあります。甘えられた時の対処を誤ると大きなマイナスにつながるため、注意が必要です。

とあるチームを支援していた時のことです。直近の計画・アクションプランをうまく策定できなくて困っているということだったので、私がアドバイスをして決定できたということがありました。それを機に、そのチームのメンバーたちとマネジャーから、何かあるごとに「頼られる」ようになりました。

初めのうちは、見積もりの仕方の指導など、支援先チームが自発的に成長していくプラスにつながる要望が多い印象でした。しかしながら、要望は徐々にエスカレートしていきました。そのチームおよびメンバーの成果を評価する観点の提示や、評価項目案そのものの提示に至り、しまいには評価そのものを代行して欲しいと言われるようになりました。その時点でわれわれは、そのチームの支援を一時停止しました。「甘えられている」と判断したためです。

先述した通り、私が所属しているチームは、アジャイルおよびテスト自動化の、サービスによる自発的な実現を支援する業務を担当しています。すなわち、「自発性」を培うことが私たちの仕事のポイントです。一方で上述のエスカレートした要求は、支援先チームによる明らかな「甘え」でした。「甘えられること」・「甘えさせること」は、自分で考え行動する意欲を奪い、結果として自発性を発揮したり成長する機会を奪ってしまうことになりかねません。それはひいては、会社を弱くすることにもつながります。それは、私たちのチームのミッションに明らかに反します。

仕事をする上では、「頼りにされること」と「甘えられること」とを、明確に区別して対処しましょう。その行動一つで、あなたのチーム・組織・会社を強くも弱くもできるのです。

6. 結論

上記の論点を、以下に簡潔にまとめてみました。

1) 自分の枠や境目を作らず、オープンに何でもやれることをやろう。

• 仕事をしやすい環境を自分たちで作ろう

ITだけではなく、コミュニケーションも立派な「仕事」です。変に自分の枠を作って、自縄自縛にならないようにしましょう。

2) 定量的な情報や成果をうまく活用して、仕事をよりよく進められるようにしよう。

• 事実に基づいて計画しよう
• メトリクスでチームとプロダクトを成長させよう
• 成果にフォーカスして実験を重ねよう

3) 自分のことは自分でやらせ、学習の機会を奪わないようにしよう。

• 甘えさせないようにしよう

いかに自発的にチーム・組織・会社を成長させるか？
そのためにはどのような振る舞いと心構えが必要か？
どこまではやってよくて、どこからはやってはいけないか？

上記のアプローチが絶対的な正解ではありません。あくまでヤフーの一部の現場では効果があったものです。私は最近、仕事とは日々の実験の積み重ねの成果であると考えるようになりました。皆さんも、自分たちのチーム・組織・会社に合った方法を、実験を重ねて見つけ出してみてください。この記事が、そのための何らかのヒントになればと思います。

最後に

2017年1月12日に、「Regional SCRUM GATHERING Tokyo 2017」というイベントで、先述のメトリクスについて、スクラムに特化した形でお話させていただきます。資料も公開しますので、メトリクスを現場で利活用するためのヒントとしてご利用いただければと思います。