メインコンテンツまでスキップ

機能しているかを知る

変更を加えることは、システムを改善することとは異なります。変更の中には感情的な安堵、新鮮さ、または一時的なコントロール感をもたらすことで、生産的に感じられるものがあります。本当の問いは、その変更がプラクティスをより機能的にしたかどうかです。

Adaptable Disciplineにおいて、評価とは介入が興奮させるものだったか、正しいと感じたかを問うことではありません。根底にある状況を有益な形で変えたかどうかを問うことです。だからこそ評価は小さな実験を走らせることと一体です。変更は最終的な答えではなく、作業説明のテストであることが多いです。

良い変更が改善すべきもの​

良い変更は通常、以下の一つ以上を改善します：

  • return： driftの後に戻ることが easier になる
  • friction： 始める、または再開するコストが下がる
  • capacityとの適合： プラクティスが現在の状況下でより現実的になる
  • direction： プラクティスが大切なことにより明確につながる
  • visibility： システムで何が起きているかをより見えやすくなる

それらのいずれも変わらなければ、介入は構造的に有益でなく感情的に満足するものだったかもしれません。また、介入の背後にある仮説が不完全だったか、間違った制約を指していた可能性もあります。

正しいものを評価する​

多くの人は変更を早まって評価するか、間違ったシグナルで評価します。気持ち良かったか、意志力があるように見えたか、数日間完璧にこなせたかを問います。それらのシグナルは誤解を招くことがあります。

より良い評価は問います：

  • returnは今より安くなっているか？
  • プラクティスを始めることは easier になっているか？
  • システムは以前より低いcapacityでも持ちこたえているか？
  • 次に何をすべきかについての混乱が減っているか？
  • comeback speedは改善しているか？

これらの問いは評価を気分ではなくフレームワークに結びつけています。また、実験が仮説を確認しているか、弱めているか、または考えていた問題とは異なる問題を明らかにしているかを判断するのに役立ちます。

frictionの移動に注目する​

介入が一箇所でfrictionを取り除いても、別の場所で生み出すことがあります。新しいツールは状態を保存するかもしれませんが、メンテナンスの負担を加えるかもしれません。縮小バージョンはリターンを easier にするかもしれませんが、それだけが使われるバージョンになると方向性を弱めるかもしれません。指標は可視性を改善するかもしれませんが、自己監視を増やすかもしれません。

それは自動的に介入が悪いということにはなりません。最初のメリットだけでなく、全体的な効果を評価する必要があることを意味します。実験的な観点から見ると、意図した効果だけでなく、副作用とfrictionの移動も見ています。

結果が通常意味すること​

評価は、利用できる解釈の小さなセットがあると easier になります。

  • より良い結果： 変更がリターンをより安く、明確に、または着実にした
  • 部分的な結果： 変更は助けになったが、狭い条件下でのみ
  • 問題の移動： 元のボトルネックが緩和したが、別のものが今システムを制限している
  • 偽の安堵： 変更は気持ち良かったが、リターン、明確さ、または安定性を改善しなかった
  • 新しい負担： 変更は一つの問題を解決したが、他の場所でメンテナンス、プレッシャー、または混乱を多く生み出した

これが有益な反復とランダムな混乱の違いであることが多いです。変更がうまくいったかどうかを問うだけでなく、結果がシステムについて何を伝えているかを問っています。

変更が自分を示すのに十分な時間を与える​

すべての介入がすぐにその価値を明らかにするわけではありません。すぐに助けになる変更もあります。次の辛い日が来たときにのみ価値を示すものもあります。変更が再開を助けることを意図しているなら、次にシステムがぐらつくまでうまくいくかどうかを本当に知ることはできないかもしれません。

だからこそ評価には、即時の感触とストレステストの価値の両方を含めるべきです。理想的な条件下ではエレガントに感じるが、分散の下で失敗するプラクティスは、まだ取り組みが必要です。有益な実験は、何が実際に真実かを明らかにするのに十分な時間とプレッシャーが必要なことが多いです。

記録すべきこと​

評価は具体的であると better になります。精巧なダッシュボードは必要ありませんが、以下を記録することが役立ちます：

  • どんな変更を加えたか
  • 変更がテストしていた仮説は何か
  • 何を改善するはずだったか
  • 実際に何が easier になったか
  • 何が依然として難しかったか
  • どんな新しいfrictionが現れたか

これにより、システムが曖昧な印象のぼかしにならないようにします。

例えば、シンプルなメモはこのようになるかもしれません：「各ライティングセッションの後に次のステップを見えるようにしておいた。2日間は再開が easier だった。最初の失敗の後、羞恥心がまだリターンを遅らせた。Frictionは改善したが、mindsetはまだボトルネックの一部。」

本当のテスト​

変更の本当のテストはシンプルです：プラクティスをより構築しやすくするか？

リターンをより利用しやすくし、不要なコストを減らし、方向性を改善し、または現実の条件下でシステムが持ちこたえるのを助けるなら、おそらく残す価値があります。主に複雑さ、プレッシャー、またはノイズを加えるなら、調整または取り除きが必要でしょう。いずれにしても、評価によってシステムの次のパスのための better な仮説が得られるはずです。

試してみる：最近加えた変更を評価する

過去一、二週間でプラクティスに加えた変更を選んでください。

  1. 何を変えたかを名前付けする。 一文で。
  2. それが何を改善するはずだったかを名前付けする。 リターンが安く？入口が明確に？恥が少なく？capacityへの適合が better ？ターゲットがなかったなら、それも情報です。
  3. 実際のシグナルを見る。 comeback speedは違うか？プラクティスは辛い日でも better に持ちこたえているか？再開は安くなっているか、それとも以前と同じコストがかかるか？
  4. 結果を分類する。 Better（ターゲットが改善した）、部分的（良い条件下でのみ助けになった）、問題の移動（一つのボトルネックが緩和し、別のものが現れた）、偽の安堵（気持ち良かったが、構造的には何も変えなかった）、または新しい負担（一つの問題を解決し、別の問題を生み出した）。

完了の目安： 分類と、それが次の変更について何を示唆しているかの一文があるとき。

次のステップ： 進みながら調整するでは結果を受け取って次の反復に変えます。

に最終更新