コードを書くときに過去の様々な感情が蘇ってくることはないでしょうか。
初歩的なミスを指摘されて申し訳なく感じたこと。自分が書いたコードで不具合が発生し、チーム全体で面倒な対応に追われたこと。商用環境で問題が起きて、胃が痛くなりながら深夜まで対応したこと。
一方で、綺麗な設計を褒められて嬉しかったことや、難しい問題を解決してチームに感謝されたことも思い出します。これらの感情の記憶が、次のコードを書く時の私の手を動かしたり、止めたりしているのです。
この時、私たちの思考プロセスに影響を与えているのは、実際のレビュアーや上司ではないのかもしれません。過去の経験と感情から作り出された「仮想的な他者」—— 自分の心の中にいる評価者が、私たちの行動を左右しているのではないでしょうか。
建設的なフィードバックをもらっただけなのに、なぜか過剰に慎重になってしまう。その理由は、私たちが実際の状況以上に、自分の中の「仮想的な他者」に影響されているからなのかもしれません。
「仮想的な他者」という内なる評価者
例えば、上司からフィードバックを受けた時のことを考えてみましょう。
その瞬間は、具体的な改善点として受け止めます。しかし時間が経つと、私たちは心の中に上司のイメージを作り出し始めます。「次に同じことをしたらまた指摘される」「こうすれば認めてもらえるはず」—— この時、私たちが対話しているのは実際の上司ではなく、自分の中に作った上司の像なのです。
この「仮想的な他者」は、実際の人物より単純化され、時に厳格になります。本来は特定の文脈での指摘だったものが、普遍的なルールとして内在化されてしまう。そして、この仮想的な他者は、私たちの創造的な衝動を抑圧し、思考や行動を硬直化させていくのです。
技術的負債との付き合い方
通常「システム」というとコードやプロダクトのことを指していると思いますが、それらを扱う開発チームや組織をより大きなシステムとして捉え直すと、技術的負債の見え方も変わってきます。
コードの複雑さや保守性といった客観的な指標は、システムの一部分を測っているに過ぎません。チームに蓄積された「仮想的な他者」—— 過去のフィードバックやルールが作り出す心理的な制約も、このより大きなシステムにおける技術的負債の一部なのです。
「このコードは触ってはいけない」「この設計は変えられない」—— これらの制約を生み出しているのは、実際の技術的な制限だけでなく、過去の経験から作り出された心理的な壁である場合も多いのです。コードの複雑さとチームの心理的な重さは、同じシステムの中で相互に影響し合い、全体としての技術的負債を形成しているのかもしれません。
だからこそ、長く運用されたシステムほど、開発者の行動は硬直化し、創造的な改善提案が減っていく。実際の制約以上に、蓄積された「仮想的な他者」たちが、私たちの手を止めているのです
リファクタリングで健康を取り戻す
リファクタリングをシステムの健康を取り戻す営みとして捉えてみたいと思います。ここで言う「システム」とは、コードや機能だけでなく、それを開発し維持する開発チーム全体を含む、より広い概念です。
整体やマッサージに似ているかもしれません。バランスが崩れたところを整え、血行が悪くなったところを解きほぐす。コードの構造を整理することは、同時にチームの心理的な負担を軽減し、創造性の流れを回復させることでもあるのです。
コードのリファクタリングは、過去の制約から解放され、現在の要求に向き合い直すプロセスです。同様に、組織やチームにおいても、硬直化した関係性のリファクタリングが定期的に必要なのではないでしょうか。固定化された役割や暗黙のルールを見直し、今本当に必要なコミュニケーションの形を模索する。
リファクタリング後に感じる清々しさは、単に構造が整理されたからではなく、硬直化していたチーム全体が「仮想的な他者」から解放された自由さなのかもしれません。
フィードバックとの付き合い方
ここで一つのパラドックスに直面します。
フィードバックは「仮想的な他者」を生み出す原因でありながら、同時にシステムや関係性の健康状態を知るための重要な診断情報でもあるのです。上司からの指摘、メトリクスのダッシュボード、顧客インタビュー —— これらは全て、現在地を知るための貴重な情報源です。
しかし、一方的にフィードバックを与えるだけ、あるいは受けるだけでは、硬直化が進んでしまうのではないでしょうか。フィードバックの後に振り返りの時間を持たず、ただ指摘事項を積み重ねていくと、それらは全て「仮想的な他者」として内在化され、行動をより強く制約していきます。必要なのは、フィードバックと振り返りをセットで行い、何が本質的な改善点で、何が文脈に依存した一時的な指摘だったのかを整理することなのかもしれません。
大切なのは、フィードバックを「固定的な評価」として内在化するのではなく、「現時点での診断結果」として受け止めることではないでしょうか。健康診断の結果に一喜一憂するのではなく、それをもとに生活習慣を見直すように、フィードバックを活用していく。
そして定期的に、自分の中にある「仮想的な他者」たちを内省し、本当に必要な制約とそうでないものを見極める。これが、健全な成長のために必要なプロセスなのかもしれません。
AIとの協働における新たな課題
この考え方は、今まさに始まっているAIとの協働にも当てはまるのではないでしょうか。
私たちはAIとやり取りする中で、「AIはこれができない」「この聞き方では理解してもらえない」という仮想的なAI像を作り出します。これもまた、新しい形の関係性の硬直化と言えるかもしれません。一方で、AIも学習されたパターンに基づいて、特定の応答スタイルに固定化される可能性があります。
これからの時代、全てのエンジニアがAIエージェントのマネージャーになると言われています。その時に求められるのは、適切なフィードバックと振り返りを通じて、AIとの関係性を継続的にリファクタリングしていく能力なのかもしれません。プロンプトの調整、ルールの更新、メモリのアップデート —— これらは全て、AIとの関係性を健康に保つための「治療」と言えるでしょう。
定期的な健康診断の必要性
私たちは定期的に、コードも関係性も「健康診断」が必要なのかもしれません。
仮想的な他者に支配されていないか。創造的な衝動が適切に発揮できているか。フィードバックを恐れるのではなく、診断情報として活用できているか。
コードも、組織の関係性も、そしてAIとの協働も、すべて生き物のように変化し続けるシステムです。だからこそ、定期的な診断とリファクタリングを通じて、健康な状態を保ち続ける必要があるのではないでしょうか。
次にコードレビューを受けた時、あるいはフィードバックをもらった時、それが作り出す「仮想的な他者」に気づいてみてください。そして、その存在を内省した上で、本当に必要な改善と不要な制約を見極める。それが、創造性を保ちながら成長し続けるための第一歩なのかもしれません。