前回の投稿では、どのように評価・測定、問いかけ、学習、改善というサイクルを用いて開発工程を向上しているかということを説明しました。これを、もう一度まとめると、以下のような手順を踏んでいます。
- 評価・測定できる全てのものを評価・測定する。
- 問いを立て、収集したデータを調査することで学ぶ。
- 学んだものを活用し、改善する。
- 改善を確認するために、評価・測定を続ける。
Indeed では、プロダクト内で起きる全てのことだけでなく、開発工程で起きる全てのデータを、可能な限り Imhotep に投入しています。開発に関連するデータセットには、Git のコミットや、Jira のチケットの更新、本番環境へのデプロイ、wiki の編集などがあります。
この評価・測定、問いかけ、学習、改善のサイクルを、どのように Indeed では問題に当てはめているかを、翻訳内容の検証の事例とともにお見せしたいと思います。
翻訳が「確認待ち」になっている期間は？
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日間も「確認待ち」の状態となっていました。
かなりの時間数のようですが、さらに問いを立てることが大切です。自分の仮説を裏付けるように見えても、そうでなくても、答えだと思われる事柄に疑問を持ちましょう。
- このデータを更に詳しく見て、さらに理解を深めることは可能か？
- このデータを読み解くには、他にどんな情報が必要か？
- ノイズとなっているソースはどれか？
- データを有用とする前に評価・測定を続ける必要があるか？
この例では、もし少数のチケットがこの合計時間数を占めていたとしたら？という問いをもとに、クエリを少しいじって、何件のチケットがこれだけの時間数をかけているのか見てみます。
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 */
翻訳チームが原因についてエンジニアと意見を交換したところ、翻訳の変更をテスト環境に表示させるには、フルビルドを待たなければならないことが意見に上げられました。この間、翻訳者は他の作業にうつり、後日確認を行います。こうした作業の切り替えが原因となり、翻訳スピードの遅延となっていました。
上記グラフ内で突出した部分は、その遅延を示しています。変更部分がテスト環境に到達する度に、多数の確認作業を表すイベントが近接して追いかけています。視覚化されたデータは、実際に作業を行う人々が説明したように非効率性を実証しました。
また、グラフを累積時間に切り替えると、同期間に翻訳者は278件のチケットを確認していました。これで、仮説を立証するにあたり、おそらく充分に大きいデータだということがわかります。
こうした問いの例は、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)
新しい工程は90パーセンタイルが1.8日、以前の工程を利用したプロジェクトは12日と、早くなっています。
データを読み込み、問いを重ねて、さらに確認作業を行った後、私たちは、新しいシステムにさらに多くのプロジェクトを移行し、影響の評価・測定を続けることに決めました。
Imhotep を活用して、工程を理解する
Imhotep を利用して、Jira 上でのアクションを追跡するために、Jira から毎日データを抽出し、Imhotepの データセットに投入してくれるツールを作成しました。このツールもオープンソース化されており、Imhotep ビルダディレクトリ よりご利用いただけます。次回の投稿では、このビルダーを利用して、Apache ソフトウェア財団のプロジェクトを分析したいと思います。
本シリーズのその他の記事のリンク