適切なメトリクスの活用

経営陣はメトリクスを好みます。彼らの考え方は、「自分たちの状況を測るための数値が必要だ。数値は人々に焦点を当てさせ、成功を測るのに役立つ」といったものです。善意からではありますが、数値による管理は、直感に反して問題のある行動につながり、最終的にはより広範なプロジェクトや組織の目標を損なうことになります。メトリクスは本質的に悪いものではありません。ただ、多くの場合、不適切に使用されているだけです。このエッセイでは、経営陣による従来のメトリクスの使用によって引き起こされる多くの問題点を示し、これらの機能不全に対処するための代替案を提示します。

2013年2月19日



どのように私を評価するか教えてくれれば、私はどのように振る舞うか教えてあげよう。

-- エリヤフ・ゴールドラット

メトリクスの使い方に何が問題なのか?

数値管理の観点からメトリクスを見る組織は、次のようなプロセスに従います。

  1. 経営陣は目標を立て、測定方法を考え出す

  2. 経営陣は、作業を行う人々に対して、長期間(3~6か月から1年まで)の目標を設定する

  3. 経営陣は、目標のみを(合意されたメトリクスの形で)伝える

  4. 作業を行う人々は、目標数値を達成するために全力を尽くす

このプロセスは、メトリクスに以下の目的を過剰に負担させることを助長します

  • 目標としてのメトリクス - 数値メトリクスは、目標を伝える唯一の手段として使用することを特に容易にします。はるかに複雑な目標を説明するよりも、尺度と数値を伝える方がはるかに簡単なことがよくあります。目標はしばしば恣意的な数値であり、一部の組織は、その数値がどうあるべきかを決定するために過剰な時間を費やすことさえあります。

  • パフォーマンスの尺度としてのメトリクス - 明確に articulatedされた目標の代わりに数値が設定されると、管理者は、作業を行う人々が目標に向かってどれだけ早く進むかを追跡するために、同じ尺度を使用することが容易になります。多くの組織は、これらの数値を個々の業績目標に結びつけています。

  • ベストプラクティスとしてのメトリクス - メトリクスを目標とパフォーマンスの尺度の両方として使用すると、意図しない副作用が生じます。つまり、このメトリクスが目標達成のための最良の方法であるという暗示です。独立した第三者が数値目標を用いて他者を測定する場合、作業を行う者には、単に設定された数値を達成するというより大きなプレッシャーがかかります。彼らは、このメトリクスに対するパフォーマンスのみで評価されるため、その特定のメトリクスを達成するためにできる限りのことを行います。それは、最終目標を達成するための最良の方法が他にないことを意味します。

単一のメトリクスに複数の目的を過剰に負担させると、特にソフトウェアなどの知識労働を扱う場合、多くの問題が発生します。メトリクスは、はるかに複雑な属性を単純化したものです。複雑さを単純化することのコストは、真の最終目標を見失うことのコストであり、最適ではない結果に終わります。

例を見てみましょう

テストマネージャー、彼女をメアリーと呼びましょう、は開発リーダーのダンと毎週ミーティングを開いています。「バグの数はどうなっていますか?」と彼女は最近のミーティングで尋ねました。ダンは答えました。「優先度1のバグを3つ解消し、優先度2のバグを4つ修正し、優先度3のバグを記録的な12個解消しました。かなり良い週ですよね?」

開発リーダーを見て、軽く頭を振りながら、メアリーは答えました。「残念ながら、お客様から優先度1のバグが5件、優先度2のバグが6件、優先度3のバグが15件報告されています。来週はもっと頑張る必要があります。」目標を達成できなかったことに憤慨し、圧倒されたと感じたダンは、チームに週末もさらに働くように頼むことを考えながらミーティングを後にしました。

この非常にシンプルなストーリーでは、選択されたメトリクスは、ミーティングを非常に迅速に進めるという1つの利点を満たしています。ダンが結果を報告した後、そしてメアリーが応答したとき、 beiden 人はすぐに進捗状況を理解します。残念ながら、有用なソフトウェアを提供するという暗黙の目標は見落とされており、ダンはソフトウェアの問題をさらに引き起こし、ソフトウェアの品質を低下させる可能性の高いソリューションを持ってミーティングを後にします。

メアリーが目標を述べる方法は、ダンにバグの数を減らすようプレッシャーをかけます。それは立派な目標のように思えます。バグの数を減らすことは良い目標ですが、非常に受動的な解決策にも繋がります。ダンは、どれだけ懸命に働くかを考えながらミーティングを後にします。メアリーによって提起された質問は、より広範な目標を無視しており、彼女は、ダンと彼のチームをバグが存在する根本的な理由の修正へと導く重要な質問をすることができていません。この根本原因を解決しなければ、ダンと彼のチームは、バグを修正し続ける運命にあります。

ダンはシングルループ学習[1]を経験しています。シングルループ学習とは、同じ問題を繰り返し試みることで、方法のバリエーションがなく、目標に疑問を呈することもありません。ダンがこの悪循環から抜け出したいのであれば、何か違うことをする必要があります。ソフトウェアの不適切な使用は、ダンを有用なソフトウェアを提供し、ソフトウェアの全体的な品質を向上させるという最終目標から遠ざけます。アインシュタインの狂気の定義は、ここによく当てはまるようです。「同じことを何度も何度も繰り返しながら、異なる結果を期待すること」。

何を測定するかに注意する

組織は、目標の設定を容易にし、人々が目標の背後にある目標に疑問を呈することを discourage するため、メトリクスを好みます。これは、管理者を組織の効率性についての誤った感覚に陥らせます。強力なメトリクスに結びついた強力なインセンティブは、人々を仕事のほんの一部に集中させ、目標をより成功させる可能性のある他の contributing 要因を無視させます。組織は、人々を他の重要な要素を無視させる、この積極的に破壊的な焦点に注意しなければなりません。

アジャイル手法でさえ、チームを間違った数値の測定と追跡によって引き起こされる望ましくない行動から守ることはできません。たとえば、アジャイルチームは、開発作業にストーリーカード[2]をよく使用します。チームは、これらの小さな作業の increments を、組織のソフトウェアライフサイクル全体で移動するにつれて、ボード上に視覚化することがよくあります。典型的なプロセスは、ストーリーが左から右へと理想的に流れる次のようになります。

図1:ストーリーウォールの例

経営陣と製品管理は、しばしば「その機能はいつ完成しますか?」という質問をします。チームは、しばしばこれをコーディングが終了したときと解釈し、テストと本番環境へのパスはソフトウェアプロセスの些細で取るに足りない部分であるという考えに屈してしまいます。プロジェクト管理は、「今週は何個のストーリーのコーディングを終えましたか?」という質問をすることで、この認識をさらに強めています。「エンドユーザーにリリースしても問題ないストーリーは何個ありますか?」または、さらに良い質問として、「エンドユーザーにリリースしたストーリーは何個ありますか?」という質問の代わりに。さらに良い質問は、「最近のリリースからユーザーはどれだけの価値を見出しましたか?」です。

チームは正しいことをしたいと考えており、これらの質問とメトリクスは、結果として開発者がストーリーを開発完了させることに集中するように仕向けます。この最適ではない目標のみに過度に焦点を当てることの結果を見てみましょう。

マーケティング担当者のマルコムは、開発者が彼のために作ったものに常に強い関心を持っており、できるだけ頻繁にチームを訪ねていました。彼はよく開発者のダンと話をして、いつ彼の機能が完成するか尋ねていました。ダンは、マルコムを失望させたくないと思い、マルコムが頼んだことは何でも終わらせることに集中して取り組みました。彼はよく、「この機能は本当に重要に違いない」と考えていました。チームの最新のテスターであるティムは、新しく開発された機能をどのようにトリガーするかを理解するために、ダンのような開発者にアプローチする必要がありました。

ある日、ティムはダンに近づき、「こんにちは、ダン!先週あなたが完了したこの機能をどのようにテストするかを理解するために、本当にあなたの助けが必要です」と言いました。ダンは、プレッシャーに負けて、「自分で何もできないの?マルコムが私の背中から降りるように、この機能を完成させる必要があるんだ」と答えます。ダンの返答にショックを受けたティムは、自分の机に戻って待ちます。彼は、「ダンが助けてくれるまで、何もできない」と考えます。

これは毎週起こり、時間の経過とともに、テスト待ちのストーリーの山はどんどん大きくなっていきます。最終的に、マルコムは2か月前に彼が頼んだ機能がまだ本番環境にないことを懸念して、チームとミーティングを開きます。驚いたことに、ダンは1か月以上前にそれを完了したと言います。ティムは恥ずかしそうに、「ダンからの助けが必要だったのに、彼は他の仕事でとても忙しかったので、そのストーリーをテストできませんでした。彼を邪魔したくなかったんです」と答えます。

このストーリーから何が学べるでしょうか?第一に、マルコムにとって重要なのは、作業の流れが完了していることです。マルコムはいつ何かが完了するかを尋ねますが、彼が本当に望んでいるのは、本番環境でそれを使用できることです。ティムは完了に必要な知識を持っておらず、彼の仕事と、より多くの仕事を完了するというダンへのプレッシャーによって、ティムはより多くの知識を獲得することができませんでした。最終的な結果は、テストで作業が積み上がり、リリースされることなく、マルコムが彼が頼んだ機能を受け取らなかった理由を疑問に思うという悪循環でした。これが、カンバンソフトウェア開発のような方法が、明示的な仕掛かり中(WIP)の制限を推奨する理由です。これらの制限は、ボトルネックが発生したときに、人々が他の人を助けることを強制します。これらのWIP制限は、人々が提供された全体的な価値ではなく、個々の生産性という間違ったメトリクスによって測定されたときに現れる望ましくない行動を克服するために機能します。「リーンソフトウェア開発」という本は、プロセスのほんの一部ではなく、エンドツーエンドの結果を測定することの重要性を強調し、「全体を最適化する」という原則を呼びかけています。全体を最適化することは、使用中のメトリクスが、有用なソフトウェアを提供するという真の目標に向かって最適ではない行動を促進しないことを保証することを意味します。

より適切なメトリクスの使用のためのガイドライン

メトリクスの不適切な使用によって望ましくない行動が生じることを考えると、メトリクスに場はないのでしょうか?もちろん、メトリクスの場があります。必要なのは、異なる方法です。より適切なメトリクスの使用に導くために、次のガイドラインを使用してください。

  1. メトリクスを目標に明確に結び付ける

  2. 絶対数よりもトレンドの追跡を重視する

  3. より短い追跡期間を使用する

  4. 変化を促さなくなった場合はメトリクスを変更する

これらの意味を探るために、以下のセクションを使用します。

メトリクスを目標に明確に結び付ける

従来のスタイルでは、経営陣は特定の目標にとって最良の尺度を決定します。そして、その尺度に基づいて目標を設定します。その後、経営陣は、作業を行う担当者にはこの目標のみを、多くの場合数値で表現して伝えます。目標達成の進捗を監視するために選択された尺度と、実際の目標自体との境界線は曖昧になります。時間の経過とともに、尺度の背後にある理由が失われ、たとえその指標がもはや適切でなくても、目標の達成に注力するようになります。指標のより適切な使い方は、進捗状況を測るために選択された尺度(指標)を明確にしつつ、その目的(目標)と関連付けることです。

たとえば、ソフトウェア開発のコンテキストでは、次のような指標が定義されている場合があります。

メソッドは15行未満でなければならない。メソッドのパラメーターは4つ以下でなければならない。メソッドのサイクロマティック複雑度は20を超えてはならない。

指標を適切に使用する場合、すべての尺度は、その本来の目的に明確に関連付けられている必要があります。現在の追跡および監視のメカニズムは、その目標から切り離し、目標を明確にすることで、担当者が指標の意図をよりよく理解できるようにする必要があります。存在意義をより豊かに説明した指標は、担当者が目標に向けて、より適切で、現実的で、最終的に有用な意思決定を行うための指針となります。目的がない場合、費やされた努力は、人々がシステムを巧みに操作する方法を見つけることにつながり、最終的には真の目標から逸脱することになります。具体的には、次のようになります。

コードの複雑さを軽減し、変更を容易にする必要があります。そのため、サイクロマティック複雑度が低く(20未満が適切)、短いメソッド(15行未満)を作成することを目指すべきです。また、メソッドができるだけ焦点を絞ったものになるように、パラメーターの数を少なく(4つまで)する必要があります。

指標を目標に明示的に関連付けることで、担当者はその関連性に疑問を呈し、ニーズを満たす他の方法を見つけ、数字の背後にある意図を理解することができます。この明確な目的がない場合、担当者は意図せずに暗黙の目標に反するような方法を見つける可能性があります。たとえば、メソッドの長さを短縮するのに役立つ手法はいくつかありますが、正しい意図を持って適用しないと、読みづらくなって全体の複雑さが増す可能性があります。

ソフトウェア開発の性質上、ほとんどの作業は知識労働であり、そのため観察が困難です。アクティビティ(コンピューターの前に座っている時間)を監視するのは簡単ですが、彼らが生み出す価値(実際のニーズを満たす有用なソフトウェア)を観察するのは困難です。コードから離れるほど、関係する複雑さを理解するのが難しくなります。これは、作業から最も遠い場所にいる人々が、目標達成の進捗を監視するための最良の尺度を本当に知ることは、不可能ではないにしても非常に難しいことを意味します。

指標のより適切な使用への移行は、経営陣が単独で尺度を考案することはできないことを意味します。彼らはもはや、進捗を監視するための最良の方法を知っていると錯覚し、目標に関連しているかどうかわからない尺度を強制することをやめなければなりません。代わりに、経営陣は、最終目標を常に視野に入れ、システムを最もよく知っている担当者と協力して、進捗を監視するための最も理にかなった尺度を考案する責任があります。

絶対数よりもトレンドの追跡を重視する

経営陣は、指標の魅力に抗うのは難しいと考えています。なぜなら、指標は組織の複雑さを、誰もが理解できるもの、つまり数字に落とし込むからです。ある数字が別の数字よりも大きいか小さいか、またはある数字が別の数字からどれだけ離れているかは簡単にわかります。その数字がまだ関連性があるかどうかを判断するのははるかに困難です。この従来の経営アプローチは、目標が達成された時期を簡単に伝えることができるため、これらの指標を使用することを好みます。「この数字に到達すれば大丈夫です」

質的で解釈の余地が大きい問題(生産性、品質、使いやすさなど)を数字に変換すると、どの数字も相対的で恣意的になります。コードカバレッジが5%と95%の間には大きな違いがあるかもしれませんが、94%と95%の間に本当に大きな違いがあるでしょうか?95%を目標に設定すると、いつ停止するかを理解するのに役立ちますが、最後の1%を得るために桁違いの労力が必要な場合、それは本当に価値があるでしょうか?これは、担当者がそれぞれの組織の状況で主観的に判断しなければならないことです。

トレンドを見ることは、目標が達成されたかどうかよりも興味深い情報を提供します。目標が達成されたかどうかを判断するのは簡単です。難しい作業、そして経営陣がスキルを持つ担当者と協力して行わなければならないのは、トレンドが望ましい方向に、そして十分な速さで動いているかどうかを確認することです。トレンドは、組織の複雑さから生じるパフォーマンスの先行きを示す指標を提供します。トレンドが望ましい状態からますます遠ざかっている場合、数字のギャップに焦点を当てることは明らかに無意味です。

トレンドに焦点を当てることは重要です。なぜなら、実装された変更に関する実際のデータに基づいてフィードバックを提供し、組織が対応するためのより多くの選択肢を生み出すからです。たとえば、チームが望ましい状態から遠ざかっている場合、目標から遠ざかっている原因と、それについて何ができるかを自問自答できます。これは、単に数字を算出する前にできる限りのことを行うよりも、はるかに早く行動を起こすことができます。チームが望ましい状態に向かっていることに気付いた場合、目標達成に役立っているものと、その速度を加速するために他に何ができるかを自問自答できます。チームを測定することで、担当者はより多くの実験を行うようになります。1つのことを微調整し、トレンドへの影響を観察し、望ましい状態との距離を監視し、いつ停止するかを知ることができます。

恣意的な絶対数は、特に目標達成の進捗が遅く、他の部門への依存関係やグループの制御が及ばない企業ポリシーによって進捗が妨げられている場合、無力感を生み出します。トレンドは、解決不可能に見えるギャップの間に麻痺するのではなく、正しい方向に進むことに努力を集中させるのに役立ちます。

指標のより適切な使用には、トレンドの報告と記録における経営陣の関与がより多く必要になります。なぜなら、チームを取り巻くエコシステムは経営陣の責任だからです。このエコシステムには、組織のポリシー、作業のスケジュールまたは計画方法、チームと担当者の編成方法が含まれます。このエコシステムは、多くの場合、個人が費やす努力よりもトレンドに大きな影響を与えます。経営陣は、このエコシステムへの変更の影響を観察するために、トレンドに関心を持つべきです。

指標を適切に使用すると、絶対数よりもトレンドの方がはるかに役立つことがわかります。恣意的な目標は、正しいトレンドがなければ実際にはあまり意味がありません。トレンドに影響を与えるものと、トレンドに影響を与えるために他に何ができるかを考えるときに、恣意的な数字と現実とのギャップが何であるかを指摘するよりも、より良い疑問が生じます。

より短い追跡期間を使用する

多くの組織は、指標を使用して、通常3〜6か月、さらには1年以上もの非常に長い期間の目標を設定しています。管理者はこの目標を設定し、作業を行う担当者には、その目標を達成するためにできる限りのことを行う責任があります。経営陣は、期間の終わりにこの目標を再検討して、作業を行う担当者を*評価*します。このシステムでは、経営陣と従業員の関係は、せいぜい対立的であると言えます。従業員は最善を尽くして目標を達成するためにできる限りのことを行いますが、経営陣には何の責任もないという暗黙の了解があります。

長期間の後に指標を再検討することの結果として、経営陣の恣意的な目標を達成できないことは、ますます容認できなくなります。私は管理職が「目標を達成するのに1年間もあったのに、達成できなかった」などと言うのを聞いたことがあります。追跡期間が長くなるほど、失敗のリスクとコストは増加します。

アジャイルメソッドは、パフォーマンスのギャップのコストが低いため、レビュー期間が短いことを好みます。1週間で十分な進捗が得られないことは、1年間で十分な進捗が得られないことよりもはるかに重要ではありません。毎週の進捗状況を確認すると、1年後の進捗状況を確認するよりもはるかに多くの選択肢が生まれます。これは単に、対応して変更する機会が多いためです。1週間などの短期間の後、計画されたことではなく、実際に何が起こったかについてのデータがはるかに多くなり、これを変更の推進に利用することで結果に影響を与える必要があります。

組織は、追跡期間を短縮することで、最大の価値を実現する再計画の機会が増えるため、メリットがあります。

私は2週間ごとにソフトウェアを本番環境にリリースするチームと協力しました。ビジネスは、ソフトウェアをほぼすぐに使用できるため、定期的なリリースを気に入っていました。最新のリリース後にデプロイされたソフトウェアを使用すると、ビジネスは、新しいマーケティングイニシアチブに必要なほぼすべてを実行できる十分な機能があることを発見しました。それは彼らが最初に要求したもののほんの一部でした。

開発チームはおそらく使用されることのない機能を作成する代わりに、残りのストーリーの小さなサブセットを選択し、次のイニシアチブの作業を開始しました。

指標の適切な使用は、プロジェクトが将来どうなるかについての情報をはるかに多く提供するため、より小さなサイクルで進捗状況を追跡します。より短い期間を追跡することでトレンドを特定するのに役立ち、一時停止することで、組織は環境とトレンドの速度/方向に影響を与えるためのより多くの情報に基づいた立場を得ることができます。

より短い期間を追跡することで、経営陣が関与する機会が増えるため、より多くのコラボレーションが可能になります。より長い期間の終わりに単に人を*評価*するのではなく、より短い期間を追跡することで、実際に何が起こっているのか、トレンドに影響を与えているのかについてのより多くのデータが得られます。

変化を促さなくなった場合はメトリクスを変更する

組織が目標を容易に達成できるのであれば、指標は必要ありません。組織は方向転換すればすぐに目標を達成できるでしょう。残念ながら、現実にはそうはならないため、測定基準が存在します。目標の達成には、多くの場合、はるかに長い時間がかかります。指標の適切な使用に関する最初のガイドラインは、真の目標と、その目標への進捗状況を監視するために選択された測定基準を区別することです。真の目標は常に明確にされなければなりません。

ガイドライン#2と#3、トレンドの監視とより短い期間での監視は、組織が目標をより早く実現するのを支援するためのものです。それは、この章の前半で説明したシングルループ学習では達成されません。組織に必要なのは、Argyrisが書いているダブルループ学習です。指標の適切な使用は、人々に目標に疑問を投げかけ、実際のデータを収集することに基づいて、そこに到達するための変更を実装することを促します。

ダブルループ学習は次のようになります

毎週バグを修正することに不満を感じている開発者のダンは、なぜ常にバグを修正しているのかを考えます。過去3週間、マルコムは期待通りに動作しないことについて多くの問題を報告しています。彼は何が実際に起こっているのかを考えるために一歩下がり、常に尋ねられるバグの数よりも、そもそもなぜバグがあるのか​​についてより関心を持つようになります。

ダンがストーリーを取り上げると、彼はしばしばマルコムにそれがどのように機能するべきかについて多くの質問をします。ダンは、マルコムには彼を忙しくさせている他のマーケティング活動があり、マルコムが彼の質問に答えるために彼と一緒に座っていることはできないことを理解しています。ダンは何を提供するという途方もないプレッシャーにさらされているため、何も提供しないのではなく何かを提供できるようにするために、いくつかの仮定を立てます。

バグを見ると、ダンは報告されたバグの多くが、彼が立て続けている小さな仮定に基づいていることに気づきます。何かを提供するというプレッシャーは、ダンが最初から正しいものを構築することが決してないことを意味します。

ダンがこれをマルコムに説明すると、彼らは新しいストーリーが始まるたびに一緒に座って、ダンがコーディングを開始する前に彼のすべての質問に答えることに同意します。彼らは翌週にこれを試み、その週に報告されたバグの総数は減少します。

ダブルループ学習では、実際に何が起こっているのかについてのより多くのデータが必要です。期間が短くなるとデータポイントが増えるため、トレンドが見やすくなります。トレンドは、システムの現在のパフォーマンスに関する洞察を提供し、単にパフォーマンス測定を追跡するためではなく、システムで作用しているより深い根本的な力について考え、問題解決を促すために使用されるべきです。真の変化を実装することで、組織は現在の目標に向かって加速することができます。

人々が働くシステムを変更することは、個人がより一生懸命、またはより速く働く努力に焦点を当てるよりも、はるかに大きな影響を与えることがよくあります。私たちのストーリーでは、ダンは毎週より多くの時間をバグの修正に費やすことができたかもしれませんが、マルコムとダンの間の情報の流れと作業関係を調整することで、彼らはシステムをはるかに効果的に変更しました。

プロジェクトの事後分析は、プロジェクトが完了した後に振り返り、将来のプロジェクトに適用したり、組織全体に広めたりすることを期待して、学んだ教訓を探します。プロジェクトの最後に事後分析を実施しても、これらの学習をプロジェクト自体に実際に適用する機会はありません。『アジャイルレトロスペクティブ』は、プロジェクトが進行中の間に変更を求めるという点で意図が異なり、アクションは終了時よりも大きな影響を与えます。これらの会議は、チームが変化の機会を探す機会を生み出しますが、それでも人々と組織がこれらの変化にコミットすることに依存しています。

組織が目標を達成したら、それを達成するために使用された指標を返却する時です。組織が目標を瞬時に達成できれば、指標は必要ないことを忘れないでください。指標の定義、追跡、監視、解釈には、新しい目標に費やす方が良い時間とリソースが必要です。組織は、収集に慣れているすべての指標に固執するのではなく、もはや関連性のない指標を削除する必要があります。指標を適切に使用することで、どの指標を廃止すべきかを簡単に理解できます。なぜなら、これらの指標は目標に明示的に関連付けられており、期間中のトレンドの継続的な監視により、最終目標の状態の継続的なレビューが促進されるからです。

人々に「なぜこの数値を収集する必要があるのですか?」と尋ねることで、潜在的に時代遅れの指標の兆候を探すことができます。ひどい回答には、「それは私たちが常にやってきた方法だからです」またはさらに悪いことに「それは私たちのポリシーです」が含まれる場合があります。この質問は、説明の不十分な目標と時代遅れの指標を必ずしも区別するものではないため、もう少し掘り下げる必要があるかもしれません。組織の時間が不必要な指標の収集と維持に無駄に費やされないようにするのは、経営陣の責任です。

結論

指標には、組織やチームにおける目的と場所があります。それらは思考の代わりとして使用することはできません。また、組織は、数値による管理が効果的なソフトウェア配信に十分であると考えることもできません。組織は、指標の不適切な使用によって生じる望ましくない行動に警戒する必要があります。ダブルループ学習は、組織が指標のより適切な使用方法を学ぶまで、個人が異なる行動をとることに焦点を当てることはできないことを理解するのに役立ちます。

指標を適切に使用することで、組織は各測定基準を、誰もが理解している明確に articulatedされた目標に関連付けます。進捗状況を監視するために選択された測定基準は、目標から切り離す必要があり、時間の経過とともに各測定基準の関連性に疑問を投げかけることを歓迎する必要があります。指標をより適切に使用している組織は、個々の、管理、および組織の影響を理解するために、トレンドを観察し、より短い期間で監視することの価値を理解しています。より良い使用法とは、常に適合性について評価されている最終目標のコンテキストにおいて、トレンドが加速、減速、反転することを確実にするために、これらの影響を頻繁に検査し、適応させることも意味します。指標の最も適切な使用法は、測定基準がもはや関連性がなくなったときを理解し、それらを置き換えたり、目標に向かって進歩し、周囲の環境が変化するにつれてそれらを削除したりすることも意味します。


脚注

1: Chris ArygrisとDonald A.Schönは、著書『Organizational Learning: A theory of action perspective』の中で、シングルループ学習とダブルループ学習の概念について説明しています。

2: User Stories Applied: For Agile Software Development』で説明されているように

重要な改訂

2013年2月19日:初版