前回の記事では、評価——問い——学習——改善のサイクルを使用して、開発工程の改善を進めていることをお伝えしました。今回の記事では、このサイクルが、各個人が向上と成長の機会を理解するうえで役立つことを説明したいと思います。これは、正しく使うならば、強力なコーチングのツールとなり得えます。
Indeed では、個人の仕事の成果を測定する Hindsight という内製のウェブアプリを開発しました。このツールは、各社員と担当マネジャーのために、各々の成果の透明性をより高めてくれるものです。
各個人は、四半期ごとの時系列の行動が書かれた Hindsight カードを与えられています。そこには、 Jira の課題の完了数、報告数、コメント数などの数字が書かれています。その他は SDLC (システム開発ライフサイクル) ツールからの数字なども含まれています。全ての数字は、クリックすると詳細を確認することができます。
Hindsight を導入する際、ナンバー 6 の原理やグッドハートの法則（これらについては、以前の記事で紹介しています）を懸念していました。こうしたネガティブな影響を及ぼさないように、私たちは次の二つの指針を、継続して強調しています。
- Hindsight は会話の糸口となるものです。話の全体像はここからはわかりませんが、掘り下げる価値のある傾向や現象を浮かび上がらせることが可能です。
- 目標はありません。それぞれの職務やレベルに対する「妥当な数」という認識はありません。これら指標の中央値・平均値の分析を避けることすらしています。
Hindsight 実例: コードの品質は？
評価—問い—学習—改善のサイクルに、どう Hindsight が当てはまるか理解するには、こんな例を考えてみてください。先の四半期で、私が 100 件の課題を完了させ、テスト環境で、そのうち 30 件を reopen (解決されたjira チケットを再度未解決状態にすること) にしたとします。私のマネージャーであるあなたは、「ジャックは生産性が高いけれど、バグがあるコードを本番に送りがちだな。品質にもっと注意を払ってもらわないと。」なんて言いたくなるかもしれません。
ですが、思い出してください。指標は会話の糸口にしか過ぎないのです。問いを立て、データを読み込む必要があるのです。30 件の再び開かれた課題を読み込んでみたら、もしかしたらこの中の 10 件は実際のバグで、どちらかというとささいなものかもしれません。こうなると話は別です。調べたことが、チームがどのようにテスト環境でのコミュニケーションを改善するための洞察に繋がって行くかもしれません。
評価・測定し、問いかけ、学び、改善する
この 5 回に渡る特集では、Indeed ではどのように指標を活用し、作業改善に役立てているかを詳しくお伝えしました。全てのエンジニアリングの組織において、重要な会話を産み出すために、データを活用することが可能ですし、活用すべきだと思います。Imhotep やスプレッドシート、その他どんなツールを使用していても、そのすべてに価値があります。評価・測定できる事柄をすべて評価・測定するところから始めましょう。そして、その評価・測定結果に問いを立て、学ぶということを繰り返しましょう。すぐに、継続して改善が見られる、やりがいのあるサイクルになっていくでしょう。
本シリーズのその他の記事のリンク
- スケーラブル、効率的、そして高速 —— Imhotepとは
- 開発工程の改善（とコーチング）に指標を活用する方法
- 指標に基づく工程改善の事例
- Imhotepを活用しプロジェクトの動向を理解する- ASFの事例
- Hindsight のメリット: 指標に基づくコーチング方法