開発の世界に入って以来、私はコンサルタントという役割を持ったことはなく、むしろチームに寄り添いながら一緒に働く「伴走者」として活動してきました。チームの一員として機能を実装したり、ミーティングに参加したり、自分の意見を述べたり、「テストは勝手に書かれない」と思い出させたりしてきました。
しかし近年では、実際に「コンサルタント」としての役割を担う機会が増えました。この役割は、単なる伴走者とは異なり、主な目的は「人々の成長を支援すること」であり、コードを書くことや機能を実装することではありません。考え方も「これは良い解決策かもしれない」から「こう言えば、相手が自分で正しい答えを導けるかもしれない」へと変わります。
これまでの経験から、役立つかもしれないいくつかの結論を挙げます：
-
自己信頼：それはインポスター症候群かもしれないし、新しい挑戦への恐れかもしれません。理由は何であれ、あなたがこのプロジェクトに参加しているのは、周りがあなたの力を信じているからです。チームの人々が感謝してくれたり、問題解決を頼ってくれたり、説明した内容を実践してくれたりすると、自分には対応できる力があると実感し、最初の困難が徐々に消えていきます。
-
階層的なコミュニケーション：これは、開発チームと一緒にコードを書かない上層部の人々が、会社に私たちの働き方を根付かせるために私たちを呼ぶようなケースです。このような場合、日々一緒に働く人たちが私たちの存在理由を理解していなかったり、変化に反対していたりすることがよくあります。そのため、最初に全員に「このコラボレーションから何を期待しているか」「あなたに何を望むか」を尋ね、次に私たちの目的を説明するだけで、初期段階から方向性を一致させ、問題を未然に防ぐことができます。
-
「やりたくない人はやらない」：前の点とも関連しますが、同じ方向に進みたくないメンバーがいても、個人的に受け止めないでください。私たちは会社全体を変えるために来たわけでも、上から目線で教えに来たわけでもありません。小さな改善を積み重ね、出発時より少しでも良い状態で終えることを目指しているのです。自分たちの考え方に近い人を見つけて、その人たちをよりサポートすることが大いに助けになります。そうすることで、彼らが他のメンバーを支援し、やがては雪だるまのように良い影響が広がっていきます。
-
「目で聞く」：誰もが自分の思うように表現できるわけではありません。小さなサインに注意を払いましょう。これは少し難しいですが、ミーティングや説明の際、あまり話さない人、話しすぎる人、自信にあふれている人などを観察することで、多くのことを間接的に学べます。全員に常に注意を向けるのは難しいですが、セッションを録画し、後で冷静に分析するのも一つの方法です。 例えば、普段あまり発言しない人に対して、以前の発言を引用して「覚えているよ」と伝えることで信頼を築けます。また、説明がうまく伝わらない相手には、再度説明する代わりに質問をして自分で考えてもらう方が効果的なこともあります。
他にも挙げられますが、これらが最も役立ったポイントです。私にとって最初のコンサルタントとしてのコラボレーションは「失敗」でした。2人のコンサルタントのうちの1人として参加し、同僚のおかげで最終的にはうまくいきました。後悔はありません。なぜなら、その失敗こそが私を成長させ、学ばせてくれたからです。完璧な人間などいません。最初からすべてを完璧にこなすことはできません。結局、私たちも「人間」なのです。 仲間を信頼し、コントロールできなかった状況を共有し、成功を分かち合い、疑問を恐れずに質問しましょう。それが次のコラボレーションで成功するための糧になります。
コードは勝手に変わりません。しかし、それを書く「人」は変わるのです。
この記事は、Lean Mindのブログでスペイン語で公開された記事「El código no lo es todo」の翻訳です。本バージョンはAIによって翻訳されたものですので、文章の一貫性が損なわれていたり、不自然な箇所があった場合はご了承ください。ご理解いただき、ありがとうございます。