管理職から DevOps ツールに対する同意を得る方法

この記事は、CircleCI デベロッパー アドボケイトの Ron Powell が The New Stack に[寄稿][4]{: target=”_blank”}した記事の転載です。

あなたは、チームが抱えている問題を解決できそうな新しいツールを発見した経験はあるでしょうか。そして、そのツールを管理職に意気込んで報告したものの、費用対効果の分析や投資効果の話を出され、にべもなく却下されてしまったことはありませんか。決定権を持たない人にとって、新しいツールの導入は一筋縄ではいかないかもしれません。

そこで、DevOps のマインドセットをツール導入に応用する方法をご紹介します。DevOps 体制では、反復性を高めること、およびある選択が及ぼす影響をチームやエンドユーザーといった関係者までを含む幅広い視野で考えることに常に努めます。新しいツールの導入に際しても、同じアプローチを応用できます。変更を試みるときには、段階的に物事を進め、テストと検証を行い、関係者全員を考慮するのです。この記事では、その方法を説明すると共に、その過程で管理職やチーム メンバーに対して使うと効果的な言葉を具体的に紹介します。

ツールではなく、課題を強調する

話し合いを始める前に、要対処事項を明らかにしておく必要があります。行動につながるインサイトが得られないミーティングに、時間を割こうとする管理職はいません。

新しいツールを発見したらやるべきことは、(そのツールによってどれほどチームの問題を解決できるかわかっているとしても) 週末に組織のリポジトリ全体をそのツールに移行することではありません。はっきり言えば、新しいツールの導入の可否を調査する許可を得ることです。この段階では、調査の許可こそが必要なのです。

するべきことがわかったら、今度はどのように許可を得るかを考えましょう。管理職は常に、さまざまな人から新しい製品の提案を受けています。マーケティングや営業の売り込みでは、その製品やプラットフォームが持つメリット、つまりそれらによって得られる利益をアピールするものです。しかし、社内での提案では、人が持つ損失を避ける傾向を利用すべきです。潜在的な利益を示すよりも、避けられる損失を示した方が、意思決定に強く、大きく影響することが研究でわかっています。そこで、リスクや損失を緩和する方法として提案を構成すると、管理職の同意が得やすくなるでしょう。

さて、そのツールで解決できる課題は何でしょうか。たとえば、CircleCI を導入しようとしているとしたら、変更がキューを通過するまで開発者が手持無沙汰になってしまう課題を解決できることをアピールします。

効果的な言葉の例:「コード変更の待ち時間がエンジニアのボトルネックになっています。この課題を解決できるアイデアがあります」

NG 例:「コード変更のデプロイを増やすのに便利な新しいツールを見つけました」

データを活用する

データ生成のプロである開発者として、管理職に要望を伝える際には、具体的な統計データを示すようにしましょう。管理職はデータが大好きです。ただし、調査の許可を得たい人に “アイデアを投げかける” ことを意識してください。どのようなトゲを抜こうとしているのかを明確にするのが非常に重要です。正確に測るのが難しいこと (感情など) や、具体性に欠けること、証拠に基づかないこと、データによる裏付けがないことを言うのは避けましょう。管理職から賛同を得る方法は、数字を見せることです。

効果的な言葉の例: 「キューのために開発者 1 人あたり毎日 2 時間が無駄になっています。私に解決策があります」

NG 例: 「キューによる待ち時間をエンジニアが不満に思っています」

チーム内で最も反対していそうなメンバーから賛同を得る

管理職から調査の許可を得たら、ツールの導入により仕事に影響を受けるメンバーと、新しいツールに対して意見を持っていそうなメンバー (特に、そのツール自体やツールの導入に関して詳しいメンバー) を、調査プロセスに加えることが重要です。他人の領域立ち入ることを避けるべき作業とは考えずに、ツールに対する貴重なフィードバックを得るチャンスだと捉えましょう。多くの場合、確固たる意見は経験によって形成されます。導入後すぐの (特に、避けられるはずの) 大きな落とし穴を避けることは、だれにとっても利益になります。

この段階でも、目的は、ツールを課題の解決策として利用できるかどうか調査することです。まだツールの導入について他のメンバーを説得する段階ではありません。自分の意見を主張するのではなく、協力を依頼するようにしたら、好意的な反応が得られるでしょう。寄せられた意見を尊重し、参考にすることを伝えます。反対しそうな人を避けるのは、チームに新しいツールを導入する方法として悪手であり、チーム メンバーに対してすべき行いではありません。最も否定的なメンバーから賛同を得るには、そのメンバーの経験と知識に対する敬意を示すことです。

否定的なメンバーに適した言葉の例: 「このツールに関するあなたの経験を詳しく聞かせてください」

NG 例: 「上司に話してこのソリューションを導入する許可を得ました」

小さな成功を積み重ねる

最終的な目標は、新しいツールの導入です。目標達成のためには、ツールの効果を示すことです。そのための取り組みはすぐに始める必要があります。小さなプロジェクトを立ち上げて新しいツールを使い始めると、そのツールを少し大きな環境に統合したときに生じる課題に対処することになるので、ある程度の妥当性確認を行えます。小さく始めれば、管理職やチーム メンバーに見せることができる簡素な動作デモも手に入ります。ソリューションが 1 つのプロジェクトで有効であることを示したら、それを他のプロジェクトでも繰り返しましょう。

チームに伝えるべき言葉の例: 「この新しいツールの性能を示すために小さなプロジェクトを実施しました」

NG 例: 「新しいツールを本番環境のパイプラインに統合したので意見を聞かせてください」

デモ、共有、質問募集する

“Hello World” デモは製品の動作をすばやく確認するのにはうってつけですが、実際の課題を解決するようにはできていません。この CircleCI 2.0 向け “Hello World” デモは、すばやく実行でき、数分でビルドを完了できます。また、CircleCI　設定ファイルの概要も示すことができます。

しかも、このデモにはすべてのコード行に説明が付記されています。新しいツールを共有するときは、Hello World デモを実演してから、自分の小さなプロジェクトを紹介するとよいでしょう。このデモで、その後に説明する、複雑すぎずかつ現実に即したソリューションを理解するための基礎を示します。これで、2 つの設定ファイルの違いについて話し合うきっかけが生まれます。そうすれば、ツールの導入で目指している方向性を示し、質問の具体性を高められます。その後、次にどのようなプロジェクトでツールを使用すべきか提案を募り、ツールの用途についてメンバーに思索を促します。この時間は、各自の専門知識を披露しあう絶好の機会にもなるでしょう。ツール導入の過程で問題が発生しそうかどうかをチーム メンバーに質問します。

意見をうまく引き出す質問の例: 「このツールの効果を小さなプロジェクトでお見せしましたが、他にどのようなプロジェクトで使用すればパフォーマンスの向上が期待できるでしょうか。また、私が見落としていると思われる統合分野はないでしょうか。リスクになりそうな点や懸念事項がありましたら教えてください」

NG 例: 「この例をお見せしたことで、このツールの価値はわかってもらえたと思います。さっそく全体への導入に取り掛かります」

この記事を参考にすれば、今までよりも気軽に新しいツールをチームに紹介できるようになることでしょう。エンジニアとしてすばらしいキャリアを築くには、チームの抱える問題を特定し、効果的にソリューションを提案することが肝要です。成功をお祈りしています！