新しいツールのチームへの導入方法（そして、プロセスに押しつぶされない方法）： 導入を成功させる 5 つのヒント

新しいツールを組織に導入することは、困難な闘いのように感じられるかもしれません。ワークフローを改善でき、必ず効率的にしてみせると約束しても、チームに存在する惰性を克服することは容易ではありません。「これまで通りにやること」に執着する場合、どのような変化であっても実現は難しくなります。優れた方法があるとわかっているときに、どのようにしてチームを啓蒙すればよいのでしょうか？

CircleCI を組織に導入してきた多くのお客様と長年にわたって対話を重ねていますので、新しいツールを採用しようとしている組織に対するヒントについて尋ねました。

これらのヒントは CircleCI への移行を担当したユーザー間で特に共有されましたが、チームに変更をもたらせることを検討しているすべての方にも役立つはずです。

CircleCI や他のツールを試してみたいが、新しいツールをチームに導入する方法がわからない場合、組織に変化をもたらす方法について、CircleCI のお客様から得られた以下の 5 つのヒントをご覧ください。

マネージャーの賛同を得る

上司と良好な関係を築くための一般的なヒントを次に示します。上司を突然驚かせることは避けましょう。新しいツールやプロセスを試してみるときには、マネージャーに知らせるようにしましょう。あなたがしていることが伝わっておらず、自分以外の誰かが、あなたがしていることについて上司に尋ねるような状況は決して好ましくありません。このような状況では、ツールの導入は失敗しがちになります。

どのようにあなたの計画を、チームリーダーにもっていくかをじっくり考えることには、価値があります。

たとえば、次のような会話によってどのような結果になるのかを考えてみましょう。「私たちのビルドの実行には最大で 30 分がかっており、チームで多くのキューが発生しています。私たちがビルドしている新しいマイクロサービスで、新しい無料のツールを試してみたいと思っています。自分の空き時間にこのツールを導入して、その効果を確認してもよいでしょうか？私の他のすべての目標については、達成に向けて順調に進んでいます。これはちょっとした調査なのですが、チームにとってプラスの効果をもたらす可能性があります。」

このような対話とは対照的に、「私たちのビルドの実行には 30 分がかかっており、チーム全体がキューで時間を浪費しています。すべてのプロダクト関係の作業を停止して、この問題を解決することに専念する必要があると思います。新しいソリューションを見つけて実装するまで、自分の業務はいったん後回しにしたいと思います。」

後者のようなアプローチがチームの問題を解決するのに効果的となる場合もあるかもしれませんが、このような手法では賛同を得ることは非常に難しいでしょう。上司は、これが解決すべき最重要の問題であり、あなたが解決できることを確認し、業務が遅延または停止することを同僚に伝えるための政治的資質をあなたが持っていることをすべて是認しなければなりません。これは非常に難しい注文です。

自分の好奇心を満たし、チームの助けになり、自分に課せられている目標や優先事項から逸脱することのない副次的なプロジェクトとして取り組むと、成功する可能性が高まります。一般的に、優れたマネージャーは、自分が「いいですね」と言えることを探しており、試してほしいと考えています。

ただし、最終的には、マネージャーが最善の方策を選択するためにどのように反応するかについて、自分の知識を駆使して判断することになります。上司が絶対に副次的なプロジェクトを受け付けないことがわかっている場合は、「小さく始めて、契機を作る」という古い格言を示して、赦しを得るようにすると良いかもしれません。

小さく始めて、契機を作る

最も大きく複雑なレポジトリを使用し、最も困難なシナリオでもツールが正しく機能することを示すことができれば素晴らしい訴求力になるでしょう。しかし、これは絶対にしないでください。すべてのツールには学習曲線があります。小規模なプロジェクトから始めることは、最終的には、ゴールの近道になります。

また、小規模なプロジェクトから開始すると、チームにとって影響が最も少なくなり、習得した内容を他のスタッフと共有する前に、実験を行い、ツールが適切に導入され稼働することを確認できます。Fortune 100 の企業に、イノベーションラボやプロジェクト X チームがあり、コアのビジネスラインから別の場所で新しいアイデアが試行されているのには理由があります。中核業務とは離れた場所では、実験し、失敗を何度も繰り返しても影響は大きくありません。

パーソナルファイナンスについて詳しい方は、スノーボールの方法を採用して、ツールの導入でこの手法を適用することもできます。つまり、最小で最も簡単なプロジェクトから着手し、新しいツールまたはプロセスに移行し、それを実行してから、次のプロジェクトに進む手法です。この手法では、すぐに最大の効果が得られるわけではありませんが、この取り組みが契機となって、最終的な導入の目標をより早く達成するのに役立つはずです。

変更を嫌う可能性が最も高いチームのスタッフを意識する。このようなスタッフとは話し合うことが重要となる。

チームの所属している期間が長い場合、自分が提案している変更について誰が最も消極的であるかに分かるでしょう（消極的になりそうなメンバーが思いつかない場合は、新しいアイデアに最も抵抗しそうなメンバーは誰かを、信頼できる同僚に尋ねてみましょう）。

あなたが変更しようとしている既存のツールまたはプロセスの維持や管理を担当されている方がチームにいるかもしれません。あるいは、あなたが導入しようとしているツールについて同僚が前の職場で酷い体験をしたことがあり、そのツールが話題に上るたびに、どれほど酷かったかを話しているかもしれません。

そのメンバーの動機に関係なく、最も抵抗すると考えられるメンバーと直接かつ率直に話し合うことが常に最善の方法になります。このようなメンバーと話し合うための打ち合わせを予約してもいいですし、彼らの意見を聞くことができるようにコーヒーブレークやランチを一緒にするように頼んでみてください。

この会話の目的は、自分のやり方が最良の方法であると納得させることではありません。同僚の意見を聞いて学び、どうして異議があるのかを正しく理解することです。反対意見を持っている理由は何か？反対しているメンバーが何を達成しようとしているのか？変化についてどのような懸念を持っているのか？を確認しましょう。

次のように言ってみても良いかもしれません。「わたしたちのチームにこの問題があることに気が付きましたので、問題を修正するために、いくつかの方法を試してみたいと思っていました。この問題についてあなたは多くの時間を費やしており、いくつかのアイデアを持っているのではないでしょうか？この問題についての意見を教えていただけますか？」

通常は、人は、特に早い段階で自分の計画に参加するように依頼され、意見や考察を求められると、協力的になります。では、反対のシナリオも示しますので、前者と比較してください。あなたが自分のチームにおける特定分野の専門家またはドメインオーナーだと仮定し、チームの別のメンバー（あなたの親しい同僚でないかもしれません、または別のチームのメンバーかもしれません）があなたの専門の分野で何か新しいことをしようとしているとしましょう。この取り組みの初期の段階から参加するように依頼されていなければ、おそらくフラストレーションを感じ、このメンバーに協力する可能性ははるかに低くなるでしょう。

変化を成しえるためには、達成するべき勝利ではなく、回避するべきリスクとして戦略を立てる。

自分が提案している変化の「理由」を疎かにしてはいけません。あなたのチームは忙しく、膨大な数の優先事項があるはずです。また、予算も人員も足りず、スケジュールも遅れているかもしれません。そのような中でチームが、新しい自分のアイデアを取り入れてくれて、変化を取り入れるための時間を費やしてくれるようにするにはどうしたらよいでしょうか？

有名な心理学者のダニエル・カーネマンとエイモス・トベルスキーは、人がどのように意思決定を行うか、特に、さまざまな議論やフレームが人に変化をもたらすきっかけになる重要な要因として、認知バイアスのフレーミング効果について説明しています。人は利得を求めるよりも損失を嫌う傾向が強いため、ポジティブな結果を求めるよりもネガティブな結果を回避する行動をとることが多くあります。

この性質を活用することはできないでしょうか？

実際に、自分の提案によって、利益がもたらされると説明する場合（たとえば、これまでより格段に速く処理でき、チームはよりハッピーになります」のような説明）、他者を説得して、自分のアイデアに同意してもらうことは難しくなるでしょう。その代わりに、潜在的な損失に焦点を当てて説明すると（「開発者 1 人あたりの生産性が 1 日 2 時間失われており、メンバーのフラストレーションが高まっており離職の恐れがある）、変化を取り入れる機運は高まりやすくなります。これが科学です。

これは、単に新しい、流行っている、または従来とは異なるといった理由だけで、使ってみたくなるという固定観念や誤認を避けるのにも役立ちます。

ツールをデモおよび共有し、質問を歓迎する。

新しいツールを導入して実行したら、チームを招待して見てもらいましょう。多くのエンジニアリングチームが、デモや説明会を開き、何に取り組んでいるのか、何を学んできたのかを紹介しています。デモや説明会は、自分が学んできたこと、そして、気に入っている理由を他のメンバーに伝えるための絶好の機会です。

覚えておいてほしい重要なヒントの 1 つは、まだ十分に確認していない領域や、自分の期待どおりに機能していない場所について、正直に伝え、透明性を保つことです。長所と短所のリストを正直かつ正確に伝える方が、「かつてない最高のツール」などと、大上段に構えて説明するよりもはるかに優れています。プレゼンテーションで美辞麗句を単に並べて、粗探しを受けるのではなく、ツールがうまくいっている領域やほとんど機能していない領域についてオープンに対話すると、チームと一緒にブレーンストーミングすることが可能になり優れた結果になることが多くあります。

これは、新しいプロセスを取り入れる契機を作り出すための良い方法でもあります。このデモの結果、同僚にもツールやプロセスを試してもらうことができれば、目標を達成したことになります。

ツールは特効薬ではありません。

チームが、継続的デリバリーへ移行すること、または DevOps のマインドセットを採用することを目標としている場合、ツールの変更は 1 つの方法になる場合がありますが、変化を推進するための包括的な戦略にはなりません。

ツールを採用しただけで、「DevOps を採用できた」または「デジタルトランスフォーメーションを開始できた」と誤って考えてしまう場合があります。目的にたどり着くために、ツールの変更が役立つかもしれませんが、多くの場合、基盤となる組織のプロセスやチームの特性があり、これらの要素も同様に変えていく必要があります。文化を変更することなく、ツールだけを変更しても、表紙だけを差し替えただけで、新たな問題が発生する恐れがあります。新しいことを試みることを恐れないでください。ただ、目的を達成するために現実的な方法を模索するのであれば、ここで説明した内容を思い出してください。

共有いただけるヒントが他にありましたら、ぜひ教えてください。チームに変化をもたらした経験があればぜひその方法を共有してください。