前回の投稿では、私たちが開発した、スケーラブルで効率的かつ高速なオープンソースのデータ分析プラットフォーム、Imhotep について説明しました。Imhotep は Indeed において、素早く繰り返し行う実験に指標を使用することを可能にし、プロダクトの改善を推進します。
工程の改善とコーチング
わたしたちは、開発工程を改善するために同じツールとテクニックを使用していますが、これは「評価・測定—問いかけ—学習—改善」というサイクルにしたがっています。
- 評価・測定できる全てのものを評価・測定する。
- 問いを立て、収集したデータを調査することで学ぶ。
- 学んだものを活用し、改善する。
- 改善を確認するために、評価・測定を続ける。
工程改善だけでなく、このアプローチは人間にも応用することができます。データは、自身の働きを把握し、他者をコーチングするうえで役立ちます。
- 自分はどれくらい成果をあげているのか？
- 自分は他のチームとどのように関わりあっているか？
- 時間が経つにつれて、自分の仕事は時間がどのように変化したか？
- 自分の盲点はどこか？
工程と人の評価・測定は良案か？
工程改善と人間の成果測定に、このアプローチを使う事に対し、懐疑的に感じるかもしれません。疑ってもいいのです。このアプローチを本当に有効に活用するためには、慎重に進める必要があります。
統計の操作 (グッドハートの法則)
一つ目の注意すべき点は、グッドハートの法則というものです。これは、「評価指を目的とすると、それは良い評価指標でなくなってしまう」といものです。例えば、マネージャーがこんなことを言ったとします。「評価・測定の結果によると、チームの生産性が下がっています。次の四半期では、機能を20% 増やす目標を設定しましょう。達成出来れば、大きな報奨金も出します！」
けれど、チームは「統計を操作」し始めるかもしれません。つまり、生産性をあげることなく、指標を改善できるような変更を行うかもしれません。こうなると、生産性を正当に評価するための手段は無意味になり、チームには、目標を推進しない、逆効果の手段を与えてしまったことになります。
ナンバー ６ の原理
二つ目の注意すべき点は、わたしが(あるテレビ番組の登場人物と決め台詞に影響されて) ナンバー 6 の原理と名付けたものです。「人間を数字に置き換えてはならない」というものです。
数字のみで評価されることを喜ぶ人間はいません。もしあなたが、チームに対して彼らを評価・測定していることを伝えると、士気に重大な悪影響を及ぼすリスクがあります。多くの人々は、あなたが定性での成果を考慮していないと考えるでしょう。
使い方次第
注意をすれば、こうした落とし穴にはまることは避けられます。チームが生産性の指標が抜け漏れることを懸念してしまう、という上記の例をよく考えるべきなのです。数字を詳細に確認し、文脈を理解したうえで状況を判断するならば、改善のための生産的な対話をすることが出来るでしょう。
もしかしたら、チームはもっと複雑な機能に取り組んでいたから、完成された機能が少なかったのかも知れません。それならば問題ないこともあるでしょう。あるいは、機能の動作を単純化するなど改善の余地があった、という意見にチームとしてたどり着くかもしれません。
もしくは、異なる指標を確認したところ、顧客ベースに伸びがあったため、全体のサポート業務量が 50％ も上昇しているかもしれません。そのうえで、そのバランスを受け入れるか、新機能を開発しながらサポートに対応するための受け皿を増やす試みを図るか、決断をすることができます。
評価・測定から始め、考慮された討論は具体的な工程改善を導くことが可能です。次回の投稿では、Imhotepを活用して、Indeed で有効だと立証され評価・測定を行った工程改善についてお伝えしたいと思います。
本シリーズのその他の記事のリンク
- スケーラブル、効率的、そして高速 —— Imhotepとは
- 開発工程の改善（とコーチング）に指標を活用する方法
- 指標に基づく工程改善の事例
- Imhotepを活用しプロジェクトの動向を理解する- ASFの事例
- Hindsight のメリット: 指標に基づくコーチング方法