APROを研究している過程で、私は一つの衝動を抑え続けました：あまり早くラベルを貼らないこと。なぜなら、この市場では、急いでプロジェクトに結論を下すと、その後に得られる全ての情報が無意識にその結論に従うことになるからです。これは研究ではなく、自己説得です。そして、@APRO Oracle APROのようなプロジェクトは、早く定性されると誤解されやすいのです。

正直なところ、なぜ多くの人がAPROに迅速に評価を下したがるのか、私は完全に理解しています。結局、今や皆はある種のパターンに訓練されています：紹介を見て、構造を一瞥し、同類のプロジェクトと比較し、すぐに「参加するかどうか」を決定する。しかし問題は、このパターンは短期プロジェクトの判断にはより適しており、明らかに長期の状態に備えているものの判断にはあまり適していないということです。

私が結論を急がずに観察を続けることを選んだ理由は、APROの主要な価値が特定の単一のポイントに表れていないことに気づいたからです。それは「このステップが特に目立つから、すべてが成立する」というようなプロジェクトではありません。むしろ、多くの選択が重なり合って徐々に傾向を形成するようなものです。この傾向が正しいかどうかは、時間が必要であり、すぐに評価を与えることではありません。

過去の経験から、私は「初期に非常に正しいように見える」プロジェクトを数多く見てきましたが、最終的には複雑な段階で完全に形を変えてしまいました。その理由は技術が不十分だからではなく、最初から複雑性を必然的な結果として捉えていなかったからです。APROは少なくとも態度において、複雑さが必ず訪れると仮定し、事前にその準備をしています。この仮定が成立するかどうかは、ホワイトペーパーだけではわかりません。だからこそ、私はそれが現実の環境でどのように行動するかを観察することを好み、文書内の表現ではなく、例えばシステムが本当にプレッシャーを受け始めた時に、ルールを簡素化するか、制約を強化するか？拡張が困難になった時、構造を犠牲にするか、速度を犠牲にするか？これらの選択は、どんな壮大な物語よりも問題を明らかにすることができます。

もう一つの理由は、私はますます「早すぎる合意」に警戒を抱くようになったからです。プロジェクトが初期の段階で大量に統一解釈されると、逆に修正の余地を失いやすくなります。みんながある方向が正しいと仮定すると、実際の問題が明らかになった時には、すでに後戻りが難しくなります。APROは現在、明らかにこのような合意を形成していないため、私にとっては悪いことではありません。観察を続けることは、判断を回避することではなく、判断を遅らせることです。私はAPROに評価を与えたくないわけではなく、その評価が「何を選択したか」に基づくことをより望んでいるのです。「何を約束した未来」ではなく。時間自体が、最も効果的なフィルターなのです。$AT #APRO

私も、この態度が全ての人に適しているわけではないことを認めます。もしあなたが迅速な意思決定や迅速な調整に慣れているのなら、APROのペースはあなたを不快にさせるかもしれません。しかし私にとって、市場にはすでに迅速なフィードバックを提供するプロジェクトが不足しているわけではなく、本当に希少なのは、長期的に観察され、繰り返し検証されることができるサンプルです。

APROを観察する過程で、私が学んだことは一つです：すべてのプロジェクトに即座に参加する必要はなく、いくつかのプロジェクトの価値は、その進化の道筋を持続的に追跡できるかどうかにあります。異なる段階でどのように問題に対処するかを見ること自体が情報の蓄積です。だからこそ、私は「観察を続ける」を明確な選択として捉え、あいまいな態度ではなくしています。これは、私がこのプロジェクトに注意を向ける価値があると確認したが、結論を占有するにはまだ十分ではないことを意味します。この状態は、私にとって健康的です。

もしこの段階のAPROに位置を与えなければならないのなら、私はそれが「時間によって検証されている段階」にあると言いたいです。市場の感情によって検証されるわけでもなく、宣伝の強度によって検証されるわけでもなく、実際の複雑さによって徐々に検証されているのです。この検証プロセスは、賑やかさとは無縁ですが、しばしばよりリアルです。だから、この文では、「APROが良いか悪いか」をあなたに伝えるつもりはありません。むしろ、ある判断方法を共有したいのです：短期的なフィードバックのために生まれたプロジェクトではないことが明らかである場合、「観察を続ける」こと自体が、ポジションよりも重要な選択であるかもしれません。