Driving Technical Change

Driving Technical Change: Why people on Your Team Don’t Act on Good Idea, and How to Convince Them They Should

最近は純粋な技術書だけでなく、ソフトスキルに関する本も読み始めている。この本は最近読んだ中で最も心に響いた一冊だ。一般的なマネジメントやリーダーシップの本では、同僚に提案を拒絶されたときにどうすべきかまでは滅多に教えてくれない。正論を言っても話が通じず、悪循環に陥ってしまいがちだ。

開発の現場では、技術の陳腐化や時代遅れといった状況が往々にして発生する。そのため、技術スタックやフレームワーク、デプロイ手法を変えたいという思いが湧いてくることもある。

だが、チーム全体に自分の考えを受け入れてもらうには多くの試練が伴う。情熱や労力、時間をたっぷりかけて「布教」したにもかかわらず、チームからは完全にスルーされたり、挙句の果てには「何をやっているんだ」と煙たがられたりすることも珍しくない。

技術が使いにくく、バグが頻発していても、「とりあえず動いているから」と誰も変えようとしない。そうして時間が経つにつれ、自分自身も情熱のないエンジニアになり下がり、毎日質の低いコードを書いてその場しのぎで過ごすようになってしまう。

本書は、変化を拒む人々のパターンをいくつか分類している。読み終わってすぐに実践できるわけではないが、他のソフトスキル本に比べてよりリアルだと僕は感じた。職場では誰もが効果的なコミュニケーションを取れるわけではなく、こうした状況に遭遇することのほうがずっと多いからだ。

他人に自分の考えを受け入れてもらうよう説得することは、ソフトウェア開発に限らず他の領域でも起こりうるが、ソフトウェア開発の現場ではより頻繁に発生する。自分の考えをチームに伝えようとするとき、多くの場合は計画を練ってから行動するのではなく、自然と湧き出る好みや意見から始まる。

しかし、人にはさまざまなタイプがいる。全員が新しい技術の導入や刷新を歓迎してくれるわけではない。チーム全体にとって素晴らしいことを一生懸命やっているつもりでも、他人に認めてもらえないこともある。

だからこそ、いかにして広めるかが重要なのだ。自分の情熱と変化がチーム全体に徐々に伝わっていけば、他のメンバーからも支持を得やすくなる。本書は多くの効果的な実践法とアドバイスを提供してくれている。

7つのタイプ

本書では、変化を拒む人を7つのタイプに分類している：

• The Uninformed（無知な人）：関連する技術知識や話題を知らない人。

• The Herd（同調者）：付和雷同し、特定の立場を持たない人。

• The Cynic（皮肉屋）：本の中ではとても的を射た表現で形容されている。

  They’re that kid in college who always asked your professors annoying questions to show how smart they are. （大学時代、教授にうんざりするような質問ばかりして、自分がどれだけ賢いかを誇示していたあの学生のような連中だ。）

  彼らはあちこちの技術を浅く広くかじるのが好きで、変な昔話や経験談を持ち出して相手を脅そうとする。

• 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（コンピュータではなく人間であれ）：人には感情がある。相手の現在の手法が間違っていると指摘しても効果的なコミュニケーションにはならず、むしろ逆効果だ。「あなたは間違っている」と直接言うよりも、「このツールや手法を使えばより効率的で生産性が上がる」とアプローチするほうがよい。
• 熱意：新技術を導入したいと思うのは、作業全体をよりシンプルかつ迅速にできるからであって、単に自分が使っていて気持ちいいからだけではいけない。
• 命令ではなく提案を使う（例：「〇〇を検討したことはありますか？」など）。
• まず耳を傾ける：チーム内には過去に別の方法を試したメンバーがいるかもしれない。行動を起こす前に、まず彼らの経験を聞いてみよう。例えばCIを導入する際、以前CircleCIを試したものの途中で断念していたことが分かった。理由を聞いてみると、社内向けのCircleCIサーバーを利用するには権限申請が必要だったからだということが判明した。

具体的なアクション

• ピッチ（提案のプレゼン）の練習をする
• 自分が話している内容を客観的に聞いてみて、自分が聞き手側だったら納得できるかを確かめる

ここで僕から補足しておきたいのだが、現在日本で働いていて感じるのは、相手により納得してもらうには相手の母国語で話すほうが説得力が増すということだ。例えば同じ提案でも、英語より日本語で伝えたほうが相手にとっても理解しやすいため、ずっと説得力がある。

実演する（Demonstrate Your Technique）

口頭での説明やテキストを見せるよりも、実際に動く効果を見せるのが最も直接的な方法だ。そのためにプレゼンをしたり、ライブコーディングをしたり、PoC（概念実証）を作ったりするのはどれも良い方法だ。

People believe what they are shown more than what they are told

では、どうやってタイミングを見つけるか？ちょっとした空き時間を見つけてみんなを集めてもいいし、コードレビューの場で自分の解法を実演してみせるのもいい。

妥協案を提示する（Propose Compromise）

時には妥協案を探ることも必要だ。100%自分の思い通りには進まないかもしれないが、少なくともトレードオフを踏まえた解決策を見出すことができる。

信頼関係を築く（Create Trust）

これは上述のテクニックの中でも難易度が高い。信頼関係を築くというのは一筋縄ではいかず、「A、B、Cをやれば手に入る」というものではないからだ。しかしその効果は絶大で、相手から信頼されれば技術的な変化をはるかに推進しやすくなる。信頼を築くための決まった手法はないが、参考になる原則がいくつかある：

• 嘘をつかない
• 潔く誤りを認める

対面でのディスカッション

オンライン上（非同期）での議論は、時間や環境の影響で自分の意図を明確に伝えきれず、議論が難航しがちだ。時間が経つにつれてコミュニケーション不足から双方が忍耐力や信頼を失ってしまうこともある。そんなときは、対面でのコミュニケーションで問題を解決することを検討しよう。

いくつかの戦略

• 理屈の通じない人（The Irrational）は無視する：彼らと議論するのは骨折り損であり、彼らはただ新技術の導入を邪魔したいだけだからだ。
• 協力してくれる人に集中する
• 適切なタイミングで助けを求める
• 上司の問題解決を助ける：先述の通り、上司が提案を拒絶するのは技術がわからないからであることが多い。そのため、自分の提案によってどれだけ生産性が向上し、どれだけバグを減らせるかという観点で話を進めよう。

あとがき

以前の職場でも似たような状況を経験したことがある。情熱をたっぷり持ってやりたいことをチームに共有したものの、相手はまったく興味を示さず、しまいには「どうしてそんなことのために何週間も奔走しているんだ」と疑問視され、当時はかなり落ち込んだ。また、理屈の通じない人に似た同僚にも遭遇し、自分の技術ややり方だけを盲信しているような人で、チームに馴染むのがとても難しく感じられた。

ちょうど元同僚がこの本を薦めてくれた。たった100ページ余りで、1週間ほどの通勤時間で読み終えることができたが、書かれている内容や手法はどれも非常に実用的で、ぜひ皆さんにも読んでみてほしいと思う。

一朝一夕で状況が変わるわけではないし、現場で長く働いているエンジニアなら、こうした状況への対処法をすでに心得ているかもしれない。

しかしエンジニアは、面倒くさがったり億劫がったりして、人とのコミュニケーションの取り方を学ぼうとしないことがある。だが、チームでの協調作業において「人」が占める割合は非常に大きい。今後のキャリアを少しでも楽にしたいなら、「人間関係」の扱い方を学ばないわけにはいかないのだ。

これは読んですぐに実践できるハウツー本ではない。信頼の蓄積や提案の練習にはそれなりの時間がかかるからだ。しかし、正しい方法を取り、自分の情熱や責任感を少しずつ示していけば、やがてチームにも良い影響が波及していくはずだ。