skill-improver

Skill Improver

スキルはレビューではなく、摩擦から改善されます。問うべきことは「このスキルはもっと良くできるか」ではありません。何でも良くできます。実際に何がうまくいかなかったのか、そしてスキルを変更すれば防げたのかです。

ほとんどの摩擦は、スキルの変更につながるべきではありません。環境に起因するものだったり、一度きりのことだったり、すでに対処されているのに、単に適切なタイミングで働かなかっただけだったりします。ノイズに反応してスキルを変更すると、切れ味のあるものが肥大化します。ここで問題となる失敗の形は肥大化です。不要な一行が増えるたびに、必要な行が見えにくくなるからです。

実際に起きたことから始める

「どうだったか」ではなく、具体的にどこで混乱が起きたのか、同じことを繰り返したのか、誤った方向に進んで引き返したのか、その場しのぎの方法を考え出したのか、ユーザーから修正を受けたのかを確認します。

それぞれが候補になります。すべてを決める問いは、スキルがあればこれを防げたのか、そしてどのスキルが該当するのかです。

通常、答えは次のいずれかです。

• スキルは存在していたが、発動しなかった。 問題は本文ではなく、説明にあります。発動条件を修正します。
• スキルは発動したが、無視されたか、誤って適用された。 内容が伝わっていません。たいていは、埋もれている、曖昧な表現になっている、または一般論すぎて状況に結びつかなかったことが原因です。
• スキルは適切だったが、繰り返し起きる問題に対して不完全だった。 実際の抜け漏れです。
• これに対応するスキルがなく、今後も起きる。 新しいスキルが必要かもしれません。
• 何をしても防げなかった。 環境に起因するもの、新しい事態、または本当に一度きりのことです。最も多い答えですが、それで問題ありません。

2回起きましたか？

一度きりの発生は逸話です。一度の出来事から書かれたスキルは、二度と起きないかもしれない状況を固定化し、その後読み込むたびにコンテキストを消費します。

2回起きたなら、記録する価値のあるパターンです。一度なら、覚えておいて様子を見る価値があります。

例外は、費用がかかった、または取り返しがつかなかったであろう一度きりの失敗です。その場合は、初回でも変更に値します。

まず削る

失敗のあと、反射的にそのケースに対応する文言を付け足しがちです。それを何度か繰り返すと、長く、曖昧で、切れ味のないものになっていきます。付け足された文言は、どのスキルでも最も読まれない部分です。

そこで、まずこう問いかけます。既存の原則をより明確に述べれば、このケースに対応できたのではないか？ ほとんどの場合、答えは「はい」です。その場合に必要なのは文を一つ足すことではなく、より鋭い一文にすることです。スキルは短くなりながら、強くなります。

追加はまれであるべきで、その一行に値する必要があります。追加のために何を削るかを考え、削れるものがないなら、本当に追加が必要なのかを問い直します。

最も効果的な改善は、通常、既存のスキルの末尾に、失敗のパターンを一つ追加することです。たった一行に、密度高く、直前に陥った落とし穴を記します。

発動条件を修正する

発動しなかったスキルは、内容を改善しても修正されません。誰も読んでいないのです。

説明には、実際にユーザーが使った言葉で、その状況を記述する必要があります。抽象的なトピックではなく、ユーザーが実際に使った表現です。また、発動しないケースも記載します。どこでも発動するスキルはノイズになって無視されます。発動しないのと同じことです。

伝えるべきこと

簡潔かつ具体的にします。何が起きたのか、どのスキルが関係するのか、繰り返し起きるのか、変更点は一つ何か、その変更は削除なのか追加なのかを伝えます。

変更すべきことがなければ、そう伝えます。「変更不要」で終わる振り返りは、成功した振り返りです。自ら仕事を作り出して正当化する振り返りより、はるかに優れています。

失敗パターン

• 反射的な振り返り。 すべてのタスクのあとに実施し、蓄積して肥大化する小さな変更を生み出します。
• 想像に基づく改善。 実際には起きていない状況への変更を提案します。
• 際限のない追加。 摩擦が起きるたびに新しい文言を追加し、削り直すことがありません。
• 発動条件の問題に対して本文を修正する。 読み込まれなかった内容を書き直します。
• 所見の捏造。 リストが期待されているからという理由で、リストを作ります。
• 一度の出来事のために新しいスキルを作る。 一度しか見ていない状況に、恒久的なコンテキストコストを課します。