エビデンスベースドマネジメントガイド by Scrum.org

角 征典 (@kdmsnr)

·

Follow

Published in

ワイクル株式会社：ブログ

·

Oct 24, 2018

--

Share

※本記事は旧版です。最新版はオフィシャルサイトからPDFをダウンロード可能です。

ビジネス価値の計測と経験的マネジメントの活用によるビジネス成果の継続的改善方法

2018年9月

この作品は、Scrum.orgが提供する「Evidence-Based Management Guide」の日本語訳であり、クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。

概要

アジャイルなプロダクトデリバリーのプラクティスを導入している組織は、ビジネス成果よりも活動やアウトプットの改善にフォーカスしがちであり、提供する価値を向上させるという本当の目的を見失いやすい。

アジャイルは目的を達成するための手段であり、目的そのものではない。つまり、アジャイルプラクティスを導入するときに最も重要なのは、ビジネスの業績を向上させることである。組織がこのことを見失うと、意図しない、望ましくないような結果を招く、それでいて「わかっている」かのような質問をマネージャーがするようになる。たとえば、以下のような質問だ。

• 「コードの品質レベルは？」
• 「ビルドは自動化してる？」
• 「コードの規約に沿ってる？」
• 「コードを頻繁に統合してる？どのくらい？」
• 「チームのベロシティは向上してる？」
• 「テストファーストやってる？」

これらの質問に対する答えは興味深いかもしれないが、組織が提供する価値やそれを引き出す能力を向上させるものではない。プラクティスそのものを監視しても、その有効性を示すエビデンスにはならない。たとえば、チームのベロシティを追跡しても、チームが顧客やユーザーにとって有益な何かを提供できているかどうかはわからない。

価値を計測しなければ、アジャイルの取り組みは直感と想定にもとづくものになってしまう。一方、エビデンスベースドマネジメント（EBM: Evidence-Based Management）のアプローチでは、組織が提供した価値を計測することで、組織のアジリティのエビデンスとする。また、組織が価値を提供する能力の計測と向上の手段を提供する。このアプローチにより、組織の会話は個人的な好みや意見から、実証的なエビデンス、ロジック、インサイトにもとづいたものへと変わり、組織は合理的かつ事実による意思決定を行えるようになる。

エビデンスベースドマネジメント

エビデンスベースマネジメント（EBM）は、経験主義的なアプローチである。顧客に届ける価値とその手段を計測する能力、その両方を改善するために指標を利用する能力を組織に提供する。

それぞれの重要価値領域（KVA）は、価値の異なる側面、あるいは組織が価値を提供する能力にフォーカスしている。これら4つのKVAをすべて備えていない組織は、短期的には価値を提供できるかもしれないが、それを持続させることはできないだろう。価値を提供すること、ステークホルダーが幸せなこと、従業員が満足していることも重要だが（現在の価値）、市場からの需要にあわせてタイムリーに提供できること（市場に出すまでの時間）や、イノベーションを持続できること（イノベーションの能力）についても、組織は明らかにする必要がある。プロダクトに対する継続的な投資は、そのプロダクトが適切な能力を保持していれば実現できる指標（未実現の価値）によって正当化される。

現在の価値（CV: Current Value）

現在、プロダクトが顧客に提供している価値を明らかにする。

CV（現在価値）を見る目的は、現時点で組織が顧客やステークホルダーに提供している価値を最大化することである。このとき、将来の可能性のある価値ではなく、現在に存在する価値だけを考慮する。組織がCVを継続的に評価するために必要な質問を以下に挙げる。

1. ユーザーと顧客はどれだけ幸せか？その幸せは増加しているか？減少しているか？
2. 従業員はどれだけ幸せか？その幸せは増加しているか？減少しているか？
3. 投資家やステークホルダーはどれだけ幸せか？その幸せは増加しているか？減少しているか？

CVを向上させるものはさまざまである。たとえば、ユーザビリティの向上、顧客やユーザーのアウトカムの改善、働きやすい職場環境の構築などがある。CVを顧客やユーザー、投資家の視点から見るのは当然だが、従業員の態度まで考慮すると、価値の生産者は従業員だと認めることができる。価値の保守・持続・強化の方法を理解した従業員は、組織のなかで最も重要な資産である。幸せな従業員の生産性は高い。

それぞれのKVAの例は、付録に記載している。

市場に出すまでの時間（T2M: Time-to-Market）

新しい機能、サービス、プロダクトをすばやく提供する組織の能力を示す。

市場に出すまでの時間（T2M）の目的は、組織が価値を提供するためにかかる時間を最小化することである。T2Mを積極的に管理しなければ、これからも価値を持続的に提供する能力があるとはいえない。組織がT2Mを継続的に評価するために必要な質問を以下に挙げる。

1. 組織は新しい実験からどれだけ早く学ぶことができるか？
2. どれだけ早く新しい情報から学び、取り入れることができるか？
3. どれだけ早く顧客に価値を届けることができるか？

T2Mを向上させるものはさまざまである。たとえば、社内のコミュニケーションのボトルネックの解消、デリバリーパイプラインの自動化の改善、アプリケーションの保守性の向上、技術的負債の排除などがある。つまり、待機時間や仕事の遂行時間を短縮するものすべてが該当する。

イノベーションの能力（A2I: Ability to Innovate）

顧客のニーズをうまく満たせるような新しい機能を提供するプロダクト開発組織の能力を示す。

イノベーションの能力（A2I）を見る目的は、新しい機能を提供したり革新的なソリューションを提供したりする組織の能力を最大限に引き出すことである。組織がA2Iを継続的に評価するために必要な質問を以下に挙げる。

1. 組織が新しい価値を提供することを妨げる要因は何か？
2. 顧客やユーザーがイノベーションの恩恵を受けられなくする要因は何か？

チームが新しい機能や価値を提供することを妨げるものはさまざまである。たとえば、欠陥の修正や技術的負債の排除に時間をかけすぎる、複数のブランチやバージョンを保守する必要がある、アプリケーションアーキテクチャが複雑だったりモノリシックだったりする、本番環境のようなテスト環境がない、オペレーショナルエクセレンスの欠如、コードマネジメントプラクティスが貧弱、分散型意思決定の欠如、有能で情熱的なチームメンバーを教育・雇用できない、などがある。価値の低い機能やシステムの障害物が累積すると、プロダクトの保守や障害物の排除に予算や時間が消費され、イノベーションの能力が低下していく。また、ソフトウェアのインストールが難しい、インストールしたいと思えるほどの機能がないなど、ユーザーや顧客がイノベーションの恩恵を受けられなくする要因によってもA2Iは低下していく。

未実現の価値（UV: Unrealized Value）

潜在的なすべての顧客のニーズを完全に満たせば実現可能な将来の価値を示す。

未現実の価値（UV）を見る目的は、これから組織がプロダクトによって実現するであろう価値を最大化することである。組織がUVを継続的に評価するために必要な質問を以下に挙げる。

1. 現在の市場または他の市場で、組織は追加的な価値を創造できるか？
2. 未開拓の機会を追求する労力とリスクに価値はあるか​​？
3. 追加的なUVを獲得するために追加投資すべきか？

これらの質問は、他のプロダクトのUVと切り離して答えられるものではない。あるプロダクトに投資するという決定は、他のプロダクトに投資しないことを意味する。CVとUVの両方を考慮することで、組織は現在と将来のメリットのバランスをとることができる。

たとえば、市場のテストのために使用されている初期バージョンなので、CVが低くなっているプロダクトであっても、市場の可能性が高いことを示すことができれば、UVは非常に高いものとなる。CVが高くなくても、潜在的なリターンが見込めるのであれば、CVを向上させるためにそのプロダクトに投資することが認められることもあるだろう。

逆に、CVが非常に高く、市場シェアが大きく、競合他社がおらず、顧客が非常に満足しているプロダクトは、追加の投資は認められないだろう。これは、利益性は高いが、プロダクトの投資サイクルは終わりに近づいている古典的な「金のなる木」のプロダクトである。

先行指標と遅行指標

先行指標は、KVMの変化を比較的すばやく検知して、高速な反応を可能にする。遅行指標は、しばらくあとになってから変化を示す。指標は本来、先行指標でも遅行指標でもないが、計測の頻度によっていずれかになる。したがって、収益を毎日計測するなら、それは先行指標となる。毎月あるいはさらに頻度が少なければ、それは遅行指標となる。

真の先行指標ならば、遅行指標から報告される成果を推測できる。たとえば、ビルドや統合の成功は、リリースの安定性や予測可能性を示す有望な予測因子である。

顧客満足度の先行指標は入手が困難だが、利用データをプロキシとして使えばいい。トランザクションの放棄率を見れば、アクティビティが正常に完了したかどうかを把握できる。シンプルな利用データであっても、少なくとも機能が使用されているかどうかは把握できるだろう。場合によっては、プロダクトの利用方法についても把握できる可能性がある。

満足度の計測は、情報を収集する時間によって、先行指標にも遅行指標にもなりうる。たとえば、「従業員の満足度」の先行指標ならば、退出前に「今日の仕事はどうでしたか？」などの簡単な質問に答えるボタン😀😐🙁を押すことで情報を収集できる。

「従業員1人あたりの収益」やプロダクトの収益性を計測する「プロダクト比率」のような真の遅行指標は、さまざまな要因の影響を受けるため、プロダクトがうまく価値を生み出せたかという一般的なことしか把握できない。

指標を検査するときは、相関関係と因果関係を区別することが課題となるだろう。指標の変化の真因を探る仮説を導くために、意義のあるデータ駆動の会話をするためには、人間の判断とボトムアップの知性が必要になる。こうした会話は、指標を望ましい方向に変えるための、新しい行動につながるインサイト、仮説、実験を引き起こす可能性がある。

EBMを使って実証的に改善する

「どっちに行くのかわからなければ、どっちの道へ行ったって大した違いはないさ」
― ルイス・キャロル

KVAを計測するだけで、いくつかの改善が始まる。すぐに改善機会が示されるからだ。体系化されたアプローチを使用すれば、組織はソフトウェアの投資からもたらされる価値を継続的に学習・改善することができるため、さらによい結果がもたらされる。本物の長期的な改善を生み出すために、以下の学習ループを確立してもらいたい。

1. 価値を定量化する

EBM学習ループの最初のステップは、価値をKVMとして定量化することである。KVMそのものを定義してそれに合わせるプロセスは、組織にとって有益なものとなるだろう。最適化すべきものの周囲に透明性を生み出すからである。

2. KVMを計測する

EBM学習ループの次のステップは、関心のあるKVMの初期値またはベースラインを確定することである。このステップは、プロダクトの実用可能性と、組織がプロダクトを提供する能力について、初期の視点を提供する。そして、相対的な長所と短所の周囲に透明性を生み出す。

3. 改善するKVAを選択する

現在の組織の価値とそれを明らかにする指標を明確に理解することで、ソフトウェア組織のマネージャーは、どのKVAを変化させるのが最も有益かについて、情報にもとづいた決定を下すことができる。

ひとつの学習ループで多くのKVAに影響を与えないようにしてほしい。一度に多くの要因を変えようとして改善や計測が遅くなるよりも、漸進的な小さな変化によってすばやく結果を計測するほうが優れている。同時に複数の要因を変えてしまうと、活動と成果の因果関係を把握するのが困難になる可能性もある。短いサイクルと少しの変化が、組織全体のアジリティを持続的に改善する最も効果的な方法である。

4. 対象となるKVAを改善する実験をする

改善するKVAを選択したら、効果があると思われるプラクティスをいくつか選択して（多すぎてはいけない）実験を始めよう。たとえば、品質を向上させたいソフトウェア組織は、欠陥のKVMを削減することにフォーカスするだろう。あるいは、開発チームのテストカバレッジや品質を向上させるために、テストファーストのプラクティスを導入しようとするだろう。

5. 結果を評価する

実験の結果を計測できたら、変更前のKVMと比較すべきである（ステップ4を参照）。実験によって改善が見られたら、その変更は継続する。改善が見られなかったら、別の改善に挑戦する。KVAが望ましい結果になるまで、学習ループを続ける。

結論

「計測できなければ改善できない」
―ピーター・ドラッカー

EBMのKVAは、プロダクトのデリバリーのパフォーマンスについて、全体的な視点を提供する。プロダクトが顧客やユーザーに価値を提供していなければ、生き残ることはできないため、CVが最も重要である。ただし、顧客やユーザーの体験は全体像の一部にすぎない。幸せで熱心な従業員がいなければ、顧客に届ける価値を持続および改善することは不可能である。また、幸せな投資家がいなければ、従業員が改善するのに必要な資金が不足する。

プロダクトが提供する価値をすばやく改善するには、新しい価値を頻繁に提供する必要がある。つまり、プロダクトのT2Mを改善する必要がある。仕事を高速化するというだけではない。高速化しても持続させることは困難である。そうではなく、障害物の把握と排除をすることが、高速なサイクルでデリバリーするのに必要不可欠なのである。

高速なT2Mで話は終わりではない。高速なリリースサイクルがわずかな改善しかもたらさないのであれば、プロダクトの価値を高速に向上させることはできない。組織のイノベーション能力は、リリースごとに重大なイノベーションを提供する能力によっても決まる。この能力を計測することで、組織は過去に囚われた障壁を取り除くために必要なインサイトを手に入れることができる。

組織のパフォーマンスを改善することは、周期的で反復的なプロセスである。現状の計測、パフォーマンス目標の設定、すばやく実行できる小さな改善の実験の作成、その影響を見るための再計測、それを何度も繰り返す。

注記

エビデンスベースドマネジメントは無料であり、このガイドによって提供されている。EBMの一部のみを導入することは可能だが、その結果はエビデンスベースドマネジメントではない。

謝辞

エビデンスベースドマネジメントは、Scrum.org、Professional Scrum Trainerのコミュニティ、Engagement Managerのコミュニティ、Ken Schwaber、Christina Schwaberによって共同開発された。

付録 — KVMの例

CV

• 従業員1人あたりの収益：この比率（総収益 / 従業員数）は業界内の主要な競争指標である。業界によって大きく異なる。
• プロダクトコスト比率：計測対象のプロダクトやシステムにかかる総費用およびコスト。運用コストも含まれる。
• 従業員満足度：従業員のエンゲージメント、エネルギー、熱意を計測するのに役立つ感情分析の一種。
• 顧客満足度：プロダクトに対する顧客のエンゲージメントと幸福度を計測するのに役立つ感情分析の一種。
• 使用指標：機能別の利用状況を計測して、顧客がプロダクトをどの程度有益だと思っているかを推測する。また、機能にかける実際の使用時間が、期待と一致しているかを確認する。

T2M

• ビルドと統合の頻度：単位時間あたりのビルド（統合されてテストされたもの）の回数。頻繁にあるいは継続的にリリースしているチームであれば、実際のリリース回数を計測する。
• リリースの頻度：単位時間あたり（継続的、日次、週次、月次、四半期ごとなど）のリリース回数。これは、新規的で競争力のあるプロダクトにおいて、顧客を満足させるために必要な時間を評価するのに役立つ。
• リリースの安定期間：開発者がリリースの準備ができたと言ったときから、プロダクトの問題を修正して、実際に顧客にリリースされるまでにかかった時間。これは、貧弱な開発プラクティス、その基盤となる設計やコードベースの影響を表すのに役立つ。
• 平均修復時間：エラーが発見されてから修正されるまでの平均時間。これは、組織がエラーを修正するときの効率性を明らかにする。
• サイクルタイム：リリース作業に着手してから実際にリリースするまでの時間。組織が顧客にリーチするための能力を計測するのに役立つ。
• リードタイム：アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを享受できるようになるまでの時間。顧客やプロダクトによって、この指標は大きく異なる。顧客満足度の要因でもある。
• 学習時間：アイデアや改善をスケッチして、構築して、ユーザーに提供して、その利用を学習するまでにかかる時間。

A2I

• 使用指標：頻繁に使用されるプロダクトの機能を計測したもの。使用されない機能を特定するのに役立つ。
• イノベーション率：新しいプロダクトの機能に費やした労力やコストを、すべてのプロダクトに費やした労力やコストで割ったもの。新しいプロダクトを提供する組織の能力についてのインサイトが得られる。
• 欠陥のトレンド：前回の計測から欠陥の変化を計測したもの。欠陥とは、顧客、ユーザー、組織にとってのプロダクトの価値を低下させるものである。一般的には、意図したとおりに動作しないことを指す。
• オンプロダクト指標：現在のバージョンのプロダクトを使用しているユーザーの割合。
• インストールされたバージョンの指標：現在サポートしているプロダクトのバージョン数。これは、組織が古いバージョンのサポートや保守にかけている労力を表している。
• 技術的負債：プログラミングにおける概念であり、「クイック・アンド・ダーティ」なソリューションをあとで修正することになったときに発生する、追加の開発やテストの作業を表したもの。
• 本番環境のインシデントのトレンド：インストールされたプロダクトの問題を修正するために開発チームが中断された回数。インシデントの回数は、本番環境の安定性を示すのに役立つ。
• アクティブなブランチ数、ブランチ間でコードをマージする時間：デプロイするバージョンが異なると、コードのブランチも異なるため、「インストールされたバージョンの指標」とよく似ている。
• コンテキストスイッチにかかる時間：ひとりあたりの一日のミーティングの回数や、チームメンバーがチーム外の人を助けるために中断された回数がわかれば、問題の規模を把握するのに役立つ。

UV

• 市場占有率：プロダクトが市場を占める相対的な割合。
• 顧客（ユーザー）満足度ギャップ：顧客またはユーザーが望む体験と実際の体験の格差。