技術的変化の推進

技術的変革を推進する：チームのメンバーが良いアイデアに行動しない理由と、彼らを納得させる方法

最近、純粋な技術書だけでなく、ソフトスキルに関する書籍も読むようになりました。この本は、最近読んだ中で最も心に響いた一冊です。一般的に管理やリーダーシップについての書籍は、同僚が提案を拒否したときにどうすべきかについてはあまり触れません。理論を述べても通じないことが多く、悪循環に陥りがちです。

開発の現場では、技術が陳腐化したり、時代遅れになることがよくあります。そのため、技術スタックやフレームワーク、デプロイ方法を変更したいという考えが生まれます。

しかし、チーム全体があなたのアイデアを受け入れるには、多くの試練が必要です。あなたが「布教」に多くの情熱、思考、時間を費やしても、チームが全く無視したり、あなたが何をしているのか理解しないことがよくあります。

技術が使いづらく、バグが頻発していても、少なくとも皆が使える状態であれば、変えたくないと思うのが普通です。そうしているうちに、あなたも情熱を失ったエンジニアになり、毎日適当にコードを書くだけになってしまいます。

この本は、変化を拒む人のいくつかのパターンをまとめています。すぐに応用できるわけではありませんが、ソフトスキルに関する書籍の中では、この本はよりリアルです。職場ではこのような状況に出くわすことが多く、皆が効果的にコミュニケーションを取れるわけではないからです。

他人に自分の考えを受け入れてもらうことは、ソフトウェア開発だけでなく、他の分野でも起こりますが、ソフトウェア開発ではさらに頻繁に発生します。自分の考えをチームに伝えたい場合、計画を立ててから行動するのではなく、自然に出てくる好みや意見が重要です。

しかし、人々にはさまざまなタイプがあり、あなたの技術の導入や古いものの更新を喜んでくれるわけではありません。あなたはチーム全体にとって素晴らしいことをするために努力していても、他の人に認められないことがあります。

したがって、どうやって推進するかが重要です。あなたの情熱と変化がチーム全体に広がれば、他のチームメンバーもあなたを支持しやすくなります。この本は、効果的な実践や提案を多数提供しています。

七つのタイプ

この本では、変化を拒む人を七つのタイプに分類しています。

• The Uninformed：無知者。関連する技術知識やトピックを知らない人

• The Herd：群れ。流れに沿って、特定の立場を持たない人

• The Cynic：皮肉屋。本書では非常に的確な方法で表現されています。

  彼らは大学で教授に嫌な質問をして、賢い自分を見せようとする学生のようなものです。

  彼らは技術を広く浅く見て回り、奇妙なストーリーや経験であなたを脅かします。

• The Burned：過去の失敗から特定の技術やフレームワークに対して強く反対する人。彼らは現在のソリューションを好む傾向があります。

• The Time Crunched：時間がない人。新しい知識や技術を学ぶ時間がない。

• The Boss：上司。彼らがあなたの提案を拒否するのは、しばしば技術を理解していないからです。

• The Irrational：無理者。彼らはあなたの提案を拒否するためにあらゆる手段を使い、論点が通じないとすぐに次の論点に移ります。彼らは前述のタイプの複合体です。 無理者に対して最善の方法は、彼らを無視することです。

前提条件：問題と解決策の定義

新しい技術を導入する前に、最も重要なのは問題と解決策を定義して、今解決しようとしている問題が正しいか確認することです。例えば、自動デプロイメントの導入を希望している場合、自動デプロイメントが現在の問題を解決できるのか？または、ページの状態が複雑なのでSPA構造を導入したいが、それが本当に状態の複雑さを効果的に解決できるのか？

技術を導入する前に、問題や達成したい目標を明確にする必要があります。これは、新しい技術を導入することの利点だけでなく、将来同僚や上司からの疑問に対しても同様の考えを持たれる可能性があります。

あなたが間違っている可能性

誰でも間違いを犯すことがあります。疑問に直面したとき、相手があなたを妨げているとは考えないでください（少なくとも最初は）、彼らにはそれぞれの考慮事項があるかもしれません。自動デプロイを導入したばかりの頃、私は同僚に、なぜコンパイル後のハッシュをgitタグとして使用するのか尋ねたことがあります。バージョン番号に変えられないのか？と聞くと、それが過去のハッシュを追跡する方法であることに気づき、そのために自動デプロイメントがコンパイルされたハッシュを自動的に記録できるように少し手法を変更し、同僚も私の方法を支持してくれました。

一部のテクニック

各タイプの人に対して、本書ではいくつかのテクニックを提案しています。

専門家になる（Gain Expertise）

新しい技術やツールを導入する前に、その技術について十分に理解していることを確認してください。そうすることで、他の人の質問にも対応できるようになります。ドキュメントやQ&Aをざっと見るだけでは不十分であり、少なくともその技術を十分にマスターしている必要があります。この目標を達成するために、以下のことができます：

• 他の専門家を探す
• 教える
• それを使用する（自分のプロジェクトで）

実際の行動

1. ドキュメントをすべて読む
2. 関連する技術フォーラムで人々がこの技術についてどのように議論しているか、彼らの疑問に答えられるかを確認する
3. この技術に関するブログを書き始める

宣伝（Deliver your message）

あなたの提案を他の人に勧める際、彼らを敵と考えず、一緒に参加するよう招待します。相手の支持を得るためには、いくつかの重要な点があります：

• Be a Person, Not a Computer：人は感情を持っており、相手の現在の提案が間違っていると指摘することは効果的なコミュニケーションにならず、逆効果です。相手に「あなたは間違っている」と直接言うよりも、このツールや方法の方が効率的で生産性が高いという提案をすることが有効です。
• 情熱：新しい技術を導入したい理由は、全体の作業をより簡単で迅速にするためであり、あなた自身が使いやすいからだけではないはずです。
• 命令の代わりに提案を用いる、「あなたはxxxを考えたことはありますか？」など
• まず聞く：チーム内に異なる提案を試したことのあるメンバーがいるかもしれないので、行動する前に彼らの経験を尋ねることができます。例えばCIを導入する際に、皆がかつてCircleCIを使用していたが、後に放棄した理由を尋ねると、社内のCircleCIサーバーを利用するには権限を申請する必要があることがわかりました。

実際の行動

• ピッチの練習をする
• 自分が話した内容を聞き返し、もし他の人が言ったことならあなたを説得できますか？

さらに、日本で働いている現在、相手をより納得させるためには、相手の言語を使うことが非常に説得力があります。同じ提案を日本語で話すことで、英語よりも説得力が増します。なぜなら、相手がより理解しやすくなるからです。

デモンストレーション（Demonstrate Your Technique）

話すことや単純に文字を見ることよりも、直接効果を示すことが最も効果的な方法です。そのため、プレゼンテーションやライブコーディング、POCを行うなど、いくつかの良い方法があります。

人々は、見せられたことを聞かされたことよりも信じます。

では、どのようにタイミングを見つけるか？自分で皆を集める時間を見つけるか、コードレビューで自分の解決策を示すことができます。

妥協案の提案（Propose Compromise）

時には妥協案を見つけることが必要です。自分の思う通りに100％進めることはできないかもしれませんが、少なくともバランスの取れた解決策を見つけることができます。

信頼を築く（Create Trust）

これは上記のテクニックの中で最も難しいことです。信頼を築くことは簡単ではなく、ABCを行ったからといってすぐに信頼を得られるわけではありません。しかし、信頼を得ることには大きな効果があり、一度信頼されれば、技術的な変化を推進するのが容易になります。特定の方法で信頼を築くことはありませんが、参考にできるいくつかの原則があります：

• 嘘をつかない
• 誤りを認める勇気を持つ

対面での議論

オンラインでの議論（非同期）は、時間や環境の制約により、自分の意図を明確に表現できないことが多く、議論が難航することがあります。それが長引くと、お互いにコミュニケーションの悪さから忍耐や信頼を失うことがあります。このような場合、対面でのコミュニケーションを検討することが解決策となります。

いくつかの戦略

• 無理者（The Irrational）を無視する。無理者との議論は無駄になりがちで、彼らは単にあなたの技術導入を妨げたいだけです。
• あなたを助けたいと思っている人に注力する
• 適切なタイミングで支援を求める
• 上司の問題解決を手伝う：上司があなたの提案を拒否するのは、技術を理解していないからです。したがって、あなたの提案がどれだけ生産性を向上させ、bugを減らすかを基に話を進めます。

後記

以前、職場で似たような状況に遭遇しました。情熱を持ってチームに自分のやりたいことを共有したところ、相手は興味を示さず、なぜこのようなことに数週間も忙しいのか疑問を持たれました。その時、非常に落胆しました。また、無理者の同僚にも出会い、自分の技術ややり方に固執していて、チーム全体に溶け込むのが難しいと感じました。

ちょうど前の同僚がこの本を推薦してくれました。短い100ページほどで、通勤時間を利用して約1週間で読み終えましたが、内容と方法は非常に実用的で、ぜひ皆さんにも読んでいただきたいと思います。

一夜にして変わるわけではありませんが、長年職場で働いているエンジニアは、こうした状況への対処法を知っているかもしれません。

しかし、エンジニアは時々面倒くささや怠惰から、他人とのコミュニケーションの方法を学ばないことがあります。しかし、協力において人が大きな要素であることを知らずにいると、将来のキャリアをより楽にするためには、人間関係の処理を学ぶ必要があります。

これは、読んで直ちに適用できる教科書ではありません。信用を築き、上記のアドバイスを実践するには時間がかかりますが、正しい方法を用いれば、少しずつ自分の情熱と責任感を示し、長い目で見ればチームにも影響を与えることができるでしょう。