現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。2016の13日目の記事です。一覧はこちら皆さんこんにちは。宏幸(@hageyahhoo)です。技術支援本部所属のアジャイルコーチ&自動化コーチとして、社内各サービスによるアジャイルおよびテスト自動化の自発的な実現を日々支援しております。Alliance公認の認定スクラムプロフェッショナル(CSP)でもあります。Calendarを担当させていただきます。今回は、特に今年、アジャイルコーチ&自動化コーチとして現場で気付いた課題とその解決策について紹介します。皆さんの日々の仕事をより良くするための何らかのヒントになれば幸いです。仕事をしやすい環境を自分たちで作ろうあるチームで、ユニットテストの自動化について教えていた時の話です。チームの活動目標を提示するよう「サブリーダー」から求められ、キチンと「サブリーダー」に提示したのだけれども、そのあとに「部長」と「リーダー」から別途目標を提示するよう求められ、混乱しているという相談を受けました。いうことなのか調べてみたところ、以下のことが分かりました。ステークホルダーがそもそも多い。サブリーダー・リーダー(複数名)・部長・テクニカルディレクターなどなどステークホルダーで、情報が届いている人と届いていない人がいる。ステークホルダーの間でも、情報をやりとりしている人としていない人とがいる。要は、ステークホルダーの管理、特にコミュニケーションの管理ができていないため、言っていることが全員違う、伝言ゲームのような状態が生じていたのです。これだけならば、わりとどこでも聞く話です。厄介だったのは、このチームが「ユニットテストを書くことに集中したい」・「ステークホルダーたちの問題だから、自分たちは関係ない」と言い張り、この状況を自ら改善することに消極的だったことです。そこで私は、以下のことをチームメンバーに説き、この状況を自ら改善することを促しました。情報の交通整理をすることは、ステークホルダーを喜ばせる行為であること。ステークホルダーを喜ばせることは、仕事に集中できる環境を作るためにプラスになること。仕事に集中できる環境を作ることは、テスト自動化を実現するための立派な行為であること。結果、チーム自ら、ステークホルダー全員が会する場を設け、お互い何が分かっているのか/いないのか・何が必要なのかを、腹を割って話し合いました。あれだけ情報の行き違いがあったはずなのに、わずか30分で必要な情報共有と次のアクションが決定してしまったのです。この成功体験からか、その後このチームは、自発的にステークホルダーとの調整を進め、情報の齟齬がないよう振る舞ってくれるようになりました。仕事をしやすい環境を作ることは、立派な仕事です。仕事をしやすくするために、ステークホルダーを喜ばせましょう。ステークホルダーの欲する価値を探り、痒いところに手を届けましょう。コミュニケーションは、できるだけ一度に取れるようにしましょう。伝言ゲームは、諸悪の根源です。事実に基づいて計画しようある日、見積もりを作成しているメンバーがいたので、その様子を観察してみました。見積もりの対象となる仕事は、50のプロダクションコードのクラスを対象にユニットテストを作るというもの。期間は2カ月、チームメンバーは10名で、1名あたり週6時間この仕事へアサインできます。このメンバーは、これらの情報を元に、必要な工数を次のように算出しました。480時間その結果に対して私は、「計画・見積もりとして役に立たないから捨てなさい」とアドバイスしました。いうのも、既にチームメンバーがこの仕事に先行着手していて、最初の1クラスのユニットテストを作成するのに40時間かけていたからです。この事実に基づくと、見積もりは以下のようになるでしょう。2000時間4倍以上の開きがありますね。作業に慣れて、1クラスあたりの作業時間が徐々に減ることを(希望的観測として)考慮に入れたとしても、かなりの開きがあることは否定できないでしょう。この見積もりの「誤り」の原因は、事実を考慮せずに、与えられた「リソース」を計算式に当てはめただけで見積もりを算出しようとしたことにあります。ある意味、「妄想で」「計画を」「立てた気になっていた」だけだったと言うこともできるでしょう。ところで、スクラムには「ベロシティ」という考え方があります。「スプリント」(2週間などの一定の期間)ごとに、どれだけの仕事ができたのかを計測したものです。次のスプリントでどの程度仕事できるかを、この数値をベースに、相対見積もりで算出します。先述の、事実に基づいた見積もり方法に近いことが分かるかと思います。この「ベロシティ」を使うと、スプリント(≒仕事)を繰り返すうちに、現実に近い見積もりを算出するためのベースを作っていくことができます。可能な限り、事実に基づいて計画・見積もりをしましょう。現実に近い答えが得られるはずです。メトリクスでチームとプロダクトを成長させよう昨今アジャイル界隈では、「メトリクス」(KPIとほぼ同義)というものを活用して、プロダクトおよび開発プロセスの良し悪しを「見える化」する動きが、世界的に広まりつつあります。言う私も、このメトリクスを業務で頻繁に取得・活用しています。メトリクスには、施策の推進、ステークホルダーマネジメント、人・チーム・組織の成長という点で効果があります。チームとプロダクトの成長という点について、私が現在ユニットテストの自動化を支援しているチームのエピソードを紹介します。はじめ私たちは、コードカバレッジとテストケースの増減を見て、チームの活動と成長を確認していました。これらの数値が停滞している時には、支援する質と量を増やし、徐々にチームのテストを書くスキルを高めていきました。順調だと思っていました。ある日、普段使われていない機能に対して、ユニットテストが多く追加され始めていることに気付きました。メンバーの一部でコードカバレッジを上げることが目的化してしまい、価値のないテストを作り始めていたのです。そこで私たちは、以下のようなアクションを実施しました。価値のある箇所を意識して、テストを作るよう徹底指導する。Requestの量やコメント数など、追加したテストの質を計測する別のメトリクスも、合わせて取得するようにした。(導出メトリクス)マネジャーらに、コードカバレッジをメンバーの評価軸に使わないよう説得した。結果、価値のないテストがなくなった一方、障害につながりかねないいくつかのバグをリリース前に検出することができました。メンバーが日々価値・効果を考えながらユニットテストを書くよう、態度が変わりました。メトリクスはこのように、チームとプロダクトの成長を促進するために活用できます。メトリクスの基礎(「導出メトリクス」などの用語)やその取得・活用方法については、以下の資料が参考になります。