Hindsight のメリット: 指標に基づくコーチング方法

前回の記事では、評価——問い——学習——改善のサイクルを使用して、開発工程の改善を進めていることをお伝えしました。今回の記事では、このサイクルが、各個人が向上と成長の機会を理解するうえで役立つことを説明したいと思います。これは、正しく使うならば、強力なコーチングのツールとなり得えます。

metrics-driven coaching

Indeed では、個人の仕事の成果を測定する Hindsight という内製のウェブアプリを開発しました。このツールは、各社員と担当マネジャーのために、各々の成果の透明性をより高めてくれるものです。

Hindsight - metrics-driven coaching

各個人は、四半期ごとの時系列の行動が書かれた Hindsight カードを与えられています。そこには、 Jira の課題の完了数、報告数、コメント数などの数字が書かれています。その他は SDLC (システム開発ライフサイクル) ツールからの数字なども含まれています。全ての数字は、クリックすると詳細を確認することができます。

Hindsight を導入する際、ナンバー 6 の原理やグッドハートの法則(これらについては、以前の記事で紹介しています)を懸念していました。こうしたネガティブな影響を及ぼさないように、私たちは次の二つの指針を、継続して強調しています。

  • Hindsight は会話の糸口となるものです。話の全体像はここからはわかりませんが、掘り下げる価値のある傾向や現象を浮かび上がらせることが可能です。
  • 目標はありません。それぞれの職務やレベルに対する「妥当な数」という認識はありません。これら指標の中央値・平均値の分析を避けることすらしています。

Hindsight 実例: コードの品質は?

評価—問い—学習—改善のサイクルに、どう Hindsight が当てはまるか理解するには、こんな例を考えてみてください。先の四半期で、私が 100 件の課題を完了させ、テスト環境で、そのうち 30 件を reopen (解決されたjira チケットを再度未解決状態にすること) にしたとします。私のマネージャーであるあなたは、「ジャックは生産性が高いけれど、バグがあるコードを本番に送りがちだな。品質にもっと注意を払ってもらわないと。」なんて言いたくなるかもしれません。

ですが、思い出してください。指標は会話の糸口にしか過ぎないのです。問いを立て、データを読み込む必要があるのです。30 件の再び開かれた課題を読み込んでみたら、もしかしたらこの中の 10 件は実際のバグで、どちらかというとささいなものかもしれません。こうなると話は別です。調べたことが、チームがどのようにテスト環境でのコミュニケーションを改善するための洞察に繋がって行くかもしれません。

評価・測定し、問いかけ、学び、改善する

この 5 回に渡る特集では、Indeed ではどのように指標を活用し、作業改善に役立てているかを詳しくお伝えしました。全てのエンジニアリングの組織において、重要な会話を産み出すために、データを活用することが可能ですし、活用すべきだと思います。Imhotep やスプレッドシート、その他どんなツールを使用していても、そのすべてに価値があります。評価・測定できる事柄をすべて評価・測定するところから始めましょう。そして、その評価・測定結果に問いを立て、学ぶということを繰り返しましょう。すぐに、継続して改善が見られる、やりがいのあるサイクルになっていくでしょう。


本シリーズのその他の記事のリンク

Imhotepを活用しプロジェクトの動向を理解する- ASFの事例

これまでの投稿でお伝えしてきたように、Indeed では大規模な時系列データセットの高速な調査と分析を可能にする Imhotep というデータ分析のプラットフォームを開発しました。前回の投稿では、Atlassian 社の Jira に基づく Imhotep データセットが 開発工程の改善にどのように活用されているか説明しました。

私たちは、指標を収集する新しい方法を常に模索しています。Jira でのアクションを調査し、開発工程を観察するのに使用しているこのツールは、工程に関する洞察を得るのに、最適なように思われました。多くのプロジェクトの Jira の課題の履歴を、時系列に整理されたアクションとして Imhotep のデータセットに変換する方法を探すことに決めました。

オープンソースである Jira Actions Imhotep Builder はJira インスタンスの中の課題の動向を、Imhotep データセットに変換するものです。そこで作成されたデータセット内に存在する各ドキュメントは、作成、編集、移行、コメントなど、Jira の課題の中の各アクションに対応しています。

ビルダは、JIRA REST API に対して、指定された範囲の期間に存在する各 Jira 課題のクエリを送り、課題を一連のアクションに分解します。アクションは TSV ファイル(tab-separated valuesの略。項目をタブで区切る形式)に記録され、このファイルは Imhotep にアップロードされます。

私たちは、ビルダを使用し、 Apache ソフトウェア財団 (ASF) の Jira インスタンスから、彼らのプロジェクト内におけるアクティビティのデータセットを作成しました。Apache のプロジェクトが、データセットを活用して、デベロッパーとユーザーコミュニティのために、工程改善のための洞察を得られることを期待しました。

Jira Imhotep Builder and Apache Data

 

ASF の Jira データを読み解く

2016 年 1 月 1 日から現在までの ASF の Jira データの Imhotep データセットを作成しました。2018 年 10 日 17 日の時点で、apachejira というデータセットの様子は以下のようになっています。

  • 23 万 298 件の課題の作成、180 万件の編集、130 万件のコメントを含む、340 万件近い Jira のアクションが存在。
  • アクションごとには 81 バイトを必要とし、全体でディスク上の 274MB を必要とする。

apachejira データセットを使用して、ASF のプロジェクト内で起きている事に対し、様々な問いを立てることができます。

たとえば、 「7 月から 9 月の間に、ASF プロジェクトでバグを報告した回数が最も多いのは誰か?」という質問に対して、1 位は Beam JIRA Bot、2 位はおそらく実際の人物である Sebb という結果が表示されました。

from apachejira 2018-07-01 2018-10-01
   where action="create" issuetype="Bug"
   group by actor

Jira Imhotep Builder

「7 月から 9 月の間で、最もバグの報告回数が多かったプロジェクトはどれか?」という問いには、401 件のバグの報告があった Ignite が Ambari を抜いて1位となりました。

from apachejira 2018-07-01 2018-10-01
   where action="create" issuetype="Bug" 
   group by project

project with most bugs - Jira Imhotep Builder

次の二つの質問では、プロジェクトのワークフローに関する相違点を調べました。

「最も活発なプロジェクトには、明確なステータスはいくつ存在するのか?」

from apachejira 2018-01-01 today
   group by project[10] 
   select count(), distinct(status)

上位 10 件のプロジェクトのうち、5 件のプロジェクトは 6 つのステータスを使用しており、その他 5 件のプロジェクトは 5 つのステータスを使用しています。例えば、Apache Beam は 5 つのステータス、Apache Hive は 6 つのステータスを採用しています。

distinct status - Jira Imhotep Builder

「Apache Beam と Apache Hive で使用されているステータスはどのような違いかがあるか?」

from apachejira 2018-01-01 today
   where project in (Beam, Hive)
   group by status
   select project='Beam',project='Hive'

Hive は Patch Available (利用可能なパッチあり) のステータスも採用している一方で、Beam ではこのステータスを使用していません。また、Apache JIRA プロジェクトの 11% がこのステータスを活用していることが解りました。

compare Beam and Hive - Jira Imhotep Builder

「2018年に、最も多くのコントリビューターによって Patch Available にステータスを変更された課題はどのプロジェクトか?」

from apachejira 2018-01-01 2019-01-01
   where fieldschangedtok='status' 
      status='Patch Available'
   group by project[10]
   select distinct(actor)

Hive、HDFS、Hadoop Common、YARN、 HBase、そして Hadoop 分散データストアなどの Hadoop のエコシステムプロジェクト 6件がトップ10に入っていました。

Jira Imhotep Builder

「2018年に、最も Apache Hive に貢献した(Patch Available にステータスを変更した)のは誰か?」

from apachejira 2018-01-01 2019-01-01
   where fieldschangedtok='status' 
      status='Patch Available' project = 'Hive'
   group by actor[10]
   select count(), distinct(issuekey)

上位 10 名のコントリビューターは、2018 年に 578 件の課題に貢献していました。

hive contributors - Jira Imhotep Builder

「最も活発なプロジェクト 20 件において、パッチが承認されるまでにどれくらいの時間がかかっているか?」

from apachejira 2018-01-01 2019-01-01
   where prevstatus="Patch Available" 
      status="Resolved" 
      fieldschangedtok="status"
   group by project[10]
   select count(), timeinstate\3600/count() 
      /* hours in state */

Hadoop 分散データストアが最も速く、Patch Available から Resolved のステータスへの変更までかかる時間が平均 102 時間という結果が出ました。

Patch acceptance time - Jira Imhotep Builder

Kafka の平均もとても高いのですが、、Not A Problem (問題なし)、 Auto Closed(自動完了)、Duplicate(重複)、Won’t Fix(修復予定なし)、Won’t Do(実行不可)など、resolution で完了した約28 個の外れ値によって、平均値が上げられていました。

from apachejira 2018-01-01 2019-01-01
   where prevstatus="Patch Available" 
      status="Resolved" 
      fieldschangedtok="status" project = Kafka
   group by resolution
   select count(), timeinstate\3600/count() 
      /* hours in state */

これは、コミュニティにとって悪いことでもあるかもしれませんし、問題ではないかもしれません。いずれにせよ、これらのような数字を深く読み込むことで、興味深い問いが浮かび上がってくることがあります。

ここであげたものは、このデータセットに対する問いのほんの一部の例です。

自社の Jira データセットを作成し分析

Jira Actions Imhotep Builder はオープンソース化されています。自社で Jira に基づくImhotepデータセットを作成する際、ぜひご活用ください。このビルダは、私たちが公開した最初のものであり、新しい Imhotep ビルダディレクトリにも記載されています。

新しいビルダのアイデアや、Imhotep 導入に関するご質問は、GitHubリポジトリにissueを作成いただくか、Twitter 上でご連絡をいただければ嬉しいです。

次回の投稿では、社内コントリビューターの作業を視覚化し、コーチングする上での洞察を得られる、Hindsight という内製ツールについてお伝えしたいと思います。


本シリーズのその他の記事のリンク

指標に基づく工程改善の事例

前回の投稿では、どのように評価・測定、問いかけ、学習、改善というサイクルを用いて開発工程を向上しているかということを説明しました。これを、もう一度まとめると、以下のような手順を踏んでいます。

  1. 評価・測定できる全てのものを評価・測定する。
  2. 問いを立て、収集したデータを調査することで学ぶ。
  3. 学んだものを活用し、改善する。
  4. 改善を確認するために、評価・測定を続ける。

Indeed では、プロダクト内で起きる全てのことだけでなく、開発工程で起きる全てのデータを、可能な限り Imhotep に投入しています。開発に関連するデータセットには、Git のコミットや、Jira のチケットの更新、本番環境へのデプロイ、wiki の編集などがあります。

この評価・測定、問いかけ、学習、改善のサイクルを、どのように Indeed では問題に当てはめているかを、翻訳内容の検証の事例とともにお見せしたいと思います。

Translation Process - metrics-driven improvement

翻訳が「確認待ち」になっている期間は?

Indeed のインターナショナルチームは、プロダクト内のストリング翻訳(単語、フレーズレベルの翻訳)の確認に時間がかかりすぎていると考えていました。Jira 上で翻訳作業を追跡し、Jira のチケットの更新を Imhotep のデータセットで追跡しました。この問題を理解できるように、評価・測定結果に対する問いを立て始めました。

Imhotep のクエリは、Pending Verification (確認待ち) の状態でいる時間を日ごとにグループ分けしたデータを返してくれます。LOREM という名前のサンプル用プロジェクト内の、確認待ちではなくなった翻訳のチケットのみを含んでいます。

from jiraactions 2017-01-08 2017-04-02
where issuetype = 'Translation' AND
prevstatus = 'Pending Verification' AND
status != 'Pending Verification' AND
project = 'LOREM'
group by time(1d)
select timeinstate/86400 /* days pending */

Imhotep で、累積した時間の指標をグラフ化しました。3ヶ月の間に、翻訳のチケットは、累積233日間も「確認待ち」の状態となっていました。

Translation Days Pending - metrics driven process improvement

かなりの時間数のようですが、さらに問いを立てることが大切です。自分の仮説を裏付けるように見えても、そうでなくても、答えだと思われる事柄に疑問を持ちましょう。

  • このデータを更に詳しく見て、さらに理解を深めることは可能か?
  • このデータを読み解くには、他にどんな情報が必要か?
  • ノイズとなっているソースはどれか?
  • データを有用とする前に評価・測定を続ける必要があるか?

この例では、もし少数のチケットがこの合計時間数を占めていたとしたら?という問いをもとに、クエリを少しいじって、何件のチケットがこれだけの時間数をかけているのか見てみます。

from jiraactions 2017-01-08 2017-04-02
where issuetype = 'Translation' AND
      prevstatus = 'Pending Verification' AND
      status != 'Pending Verification' AND
      project = 'LOREM'
group by time(1d)
select distinct(issuekey) /* number of issues */

number of issues - metrics driven process improvement

翻訳チームが原因についてエンジニアと意見を交換したところ、翻訳の変更をテスト環境に表示させるには、フルビルドを待たなければならないことが意見に上げられました。この間、翻訳者は他の作業にうつり、後日確認を行います。こうした作業の切り替えが原因となり、翻訳スピードの遅延となっていました。

上記グラフ内で突出した部分は、その遅延を示しています。変更部分がテスト環境に到達する度に、多数の確認作業を表すイベントが近接して追いかけています。視覚化されたデータは、実際に作業を行う人々が説明したように非効率性を実証しました。

また、グラフを累積時間に切り替えると、同期間に翻訳者は278件のチケットを確認していました。これで、仮説を立証するにあたり、おそらく充分に大きいデータだということがわかります。

cumulative number of issues - metrics driven process improvement

こうした問いの例は、Imhotepを利用する際に、すぐに利用できますし、また繰り返し利用できます。きちんと評価・測定をし、良質な問いを立てることで、学びを得ることができます。その学びに基づき、改善を試みることができるのです。

翻訳の確認: より良い方法は

翻訳内容の変更が送信され次第、テスト環境にすぐに渡すことができれば、前述の非効率的な部分をなくすことができます。実際に、社内の数名のエンジニアが、コードから翻訳のデプロイを分離する方法を提案してくれたのです。これを、プロジェクトごとに、徐々に試していきました。この機能のおかげで、翻訳者は内容変更を終えてすぐに、チケットを確認できるようになりました。

しばらくして、私たちは二つの類似したプロジェクトを比較することができました。IPSUMプロジェクトでは、新しい翻訳のデプロイの仕組みを使用し、LOREMでは以前の方法を使用しました。

新しい仕組みの利点を説明するにあたり、最悪の事態を比較してみます。このクエリは、これら二つのプロジェクトに限り「確認待ち」の中にいる、90パーセンタイルの時間まで表示してくれます。

from jiraactions 2016-09-15 2017-02-28
where issuetype = 'Translation' AND
      prevstatus = 'Pending Verification' AND
      status != 'Pending Verification'
group by project in ('LOREM','IPSUM')
select percentile(timeinstate, 90)

compare translation times - metrics driven process improvement

新しい工程は90パーセンタイルが1.8日、以前の工程を利用したプロジェクトは12日と、早くなっています。

データを読み込み、問いを重ねて、さらに確認作業を行った後、私たちは、新しいシステムにさらに多くのプロジェクトを移行し、影響の評価・測定を続けることに決めました。

Imhotep を活用して、工程を理解する

Imhotep を利用して、Jira 上でのアクションを追跡するために、Jira から毎日データを抽出し、Imhotepの データセットに投入してくれるツールを作成しました。このツールもオープンソース化されており、Imhotep ビルダディレクトリ よりご利用いただけます。次回の投稿では、このビルダーを利用して、Apache ソフトウェア財団のプロジェクトを分析したいと思います。


本シリーズのその他の記事のリンク