このチェックは「自分がダメ」という話ではなく「詰みルートに入った」通知です。 会議中に「ちょっと今ここで触ってみます？」と言ってPCを開くのが当たり前になっている 「説明よりサンプル出すね」があなたの口から自然に出ている 他の人のタスクが、合意前にあなた経由の“仮プロト”で走り始めている 「これ一旦あなたが見てくれればいいから」という依頼の入り方が増えている（＝正式なOwnerや締切が書かれていない） 本来の自分の仕事より、“ちょっとだけ直しといて”のほうが時間を食っている このあたりが揃ってきたら、すでにステップ2〜3あたりです。放置するとステップ4に行きます。

GDQI型に「もっとちゃんと根回しして」「急がずに」と言っても意味がありません。 あなたの良さはそのままで、詰みだけ止めるやり方です。 全部やらなくていいので、1〜2個で十分効きます。 “これは暫定のたたき台”を最初の一言で必ずつける あなたが何か出すときに「これは正式版じゃなくて、判断用の叩き。Ownerはまだ決まってないから私の成果物にしないで」と言ってください。 これを言わないと、そのまま本番レールに乗せられて、責任と維持だけあなたのものにされます。 触り方メモを同時に残す コードでも仕様でも文案でも、「どこをいじれば何が変わるか」「何がまだ未定か」を3〜5行でいいので残してください。 完璧なドキュメントじゃなくていい。 それがあるだけで「あなたしか触れないもの」になりにくい＝あなたが夜中に呼ばれにくくなる。 依頼に“締切とスコープ”を口頭で固定する 「これは今日中に応急でここだけ直す。それ以降の改善は私じゃなくて△△さんがOwnerね」と、その場で線を引いてください。 これをやらないと、“ついでにこれも”が無限に増えます。 あえて“途中”を他人に渡す 完成してから丸ごと乗せるのではなく、途中の粗い状態でも他の人の手に渡してください。 それは丸投げではなく、「これは私の私物じゃなく組織のもの」という宣言です。 渡さないと、あなたが1人で抱える構造が固定されます。 「本来の自分のタスク」を声に出して可視化する 「これ、いま私が優先してるコアタスクはAとBだから、それ以外はスケジュールに載るまで対応しないね」とはっきり言っていいです。 これはワガママではなく、あなたが燃え尽きたらチームごと止まるからです。リスク共有です。

モーツァルトのケース：「ここ、こうするべきじゃない？」という形と音のイメージを瞬時に立ち上げ、その場で形にして見せ、短い時間で完成度の高いものを渡す──という人物像で語られることがあります。 依頼や場の期待より先に、「本来こう響くべき」という自分の基準（G）を持ち、実際の反応・聴感・その場の手応え（D）を頼りに素早く修正し、待たせずすぐに出す（Q）。 しかも、それを他人の会議や合議に委ねるより、自分の頭と手の中で完結させる（I）。 この動きは、まわりから見ると魔法です。 「何もなかったものが、急に出来上がっている」。 それは当然「もっとできるでしょ？」「これも頼んでいい？」という無限の追加期待を呼びます。 同時に、そのスピードは、他の人が入れないほど個人化された形で積み上がる。 結果的に、「属人すぎて危ない」「ちゃんとした形になってない」と責められる側に回されることも語られます。 これは「才能があるから頼られただけ」ではありません。 “その場を止めないために、自分の頭と手で即座に形にして渡し続けた結果、それがあなたしか触れないものとして積み上がり、最後はあなたごと負担として処理される”という、GDQI型の典型的な詰み方です。 GDQI型にとっての教訓はとてもシンプルです： あなたが速いこと自体は問題ではありません。 問題は、“動くもの”があなたの中だけに閉じていくことです。 まだ余力があるうちに、 ・これは叩き台だと宣言する ・触り方メモを一緒に置く ・Ownerや締切を言葉で分離する ・途中段階で他人の手に渡す この4つをやるだけで、「便利だから全部あなたに積む」が止まります。 それはわがままではなく、あなたが消えたらチーム全体が止まるのを防ぐための、安全策です。