DevOps 技術: チームによるツールの選択をサポートする

ソフトウェア デリバリー パフォーマンスを向上させて、技術スタッフの仕事の満足度を高めるためには、仕事で使用するツールとテクノロジーについて、スタッフ自身が十分な情報に基づいて選択できるようサポートする必要があります。DevOps Research and Assessment(DORA)チームによる調査結果(PDF)には、こうしたサポートが継続的デリバリーの改善にもソフトウェア デリバリー パフォーマンスの向上にもつながることが示されています。チームが独自のツールを選択できるようにすれば、チームは仕事の進め方と実施しなければならないタスクに基づいてツールを選択できます。効果的に仕事をするために必要なものについて、最も精通しているのは実務担当者です。実務担当者自身がツールを選択すれば、より良い結果がもたらされることは想像がつきます。

チームにツールを選択させるからといって、各チームにどのツールでも思うままに選択できる自由を与えるわけではありません。テクノロジーの導入に制約を設けなければ、技術的負担が増し、脆弱性が高まる可能性があります。ただし、ツールを選択できるようにすると同時に、たとえばシステムの全体像を把握できるようにする、すばやくフィードバックを提供する、作成するコードに対する責任を理解できるようにするなどといった措置を講じると、技術者は使用するツールとサポートする必要があるツールについて賢い判断を下せるようになります。推奨される技術スタックをデフォルトでサポートするというパターンは、Google や Netflix などの企業で採用されています。ただし、チームが仕事に最善であると確信するツールやテクノロジーがそのスタックに含まれていない場合、チームにはそのツール / テクノロジーを選択する自由もあります。チームは、別の技術スタックを選択する場合、そのスタックをサポートする作業が伴うことも理解しています。

チームによるツールの選択をサポートする方法

チームがツールを選択できるよう組織がサポートする際は、ツールを選択する自由と、ツールの取得とサポートに伴うコスト、ならびにチーム間で使用するツールが異なる場合に考えられるコミュニケーションの複雑化との間でバランスを取ることが重要です。チームが独自のツールを選択できるようサポートするには、次のような方法があります。

  • チーム間のベースラインを確立する。各チームからの代表者と各部門からの代表者(プロダクト マネージャー、デベロッパー、テスター、オペレーター)とともに、ツールのベースラインを確立します。ベースラインとするツールのセットには、組織のニーズの大部分に対応できるだけの多種多様なツールを含めることをおすすめします。ベースラインに含めるツールの例としては、プログラミング言語とライブラリ、テストツールとデプロイツール、モニタリング インフラストラクチャ、データ バックエンドが挙げられます。

  • ツールの定期的レビューを行う。定期的に、またはスプリントの事後分析の一環として、ツールの有効性を確認するためにベースライン ツールを厳密に評価します。こうしたレビューは、新しいテクノロジーについて話し合い、実証する機会にもなります。

  • 例外に対処するプロセスを定義する。基本ツールセットから外れるケースに対処する際の明確に定義されたプロセスを作成します。プロジェクトのベースラインから外れている新しいテクノロジーを使用する場合は、新しいツールの概要と、そのツールを使用することにした理由を文書化します。このドキュメントは、プロジェクトのトラブルシューティングとメンテナンスを行う際に不可欠となります。さらに、プロジェクトに含まれるドキュメントを使用して、後で新しいツールをベースラインに追加する根拠を示すこともできます。

別のアプローチは、チームにツールを選択させることです。この戦略では、各チームが独自のツールチェーンを使用し、必要に応じてソフトウェア デリバリー プロセス(ビジネス要件、開発、運用)のできるだけ多くの部分に対処します。ただし、チーム間やサービス分野間で共有しているリソースがある場合は、コミュニケーションへの影響を考慮することが重要です。

主な注意点

チームにツール選択の自由を与える際に最もよくある問題は、たとえばエンジニアにツールの選択肢を与えない、あるいは与えすぎるなどといった極端な立場をとることです。

使用するツールとテクノロジーを実務担当者に強制すれば、標準化を推進できます。 ただし、あるケースで功を奏するとしても、すべてのケースで最適なソリューションになるとは限りません。このアプローチは、新しいテクノロジーを使ってみてテストするという、実験して成長する機会も制限します。多くの場合、新しいテクノロジーを試してから導入することで、パフォーマンスが大幅に向上する結果となります。たとえば、組織のどのチームにも、コンテナ化や Platform as a Service などの新しいテクノロジーを試すことが許可されていないとしたら、その組織は新しいテクノロジーによるパフォーマンスの向上を実現できません。

その一方で、プロジェクトやサービスごとに異なるツールとテクノロジーを選択すると、技術的負担が増し、脆弱性が高まる可能性があります。ツールチェーンに何かが追加されるたびに、維持費と運用経費は増します。そのうち、そのような費用によって新しいテクノロジーからもたらされるパフォーマンスのメリットが打ち消されてしまう可能性もあります。

チームでのツールの選択の改善方法

ツールの選択において重要な側面となるのは、パフォーマンスです。作業を行うチームがその作業に最適なツールを選択できるようにしなければなりません。これを踏まえ、次のことをおすすめします。

  • 技術スタックを定期的に評価する。評価の際に、現在のツールがどの程度要件を満たしているかを厳密に評価するよう、チームメンバーを促します。こうした定期的なレビューでは、既存のツールに関する問題について話し合い、新しく導入する候補のツールのテストを検討、計画する必要もあります。
  • 新しいプロジェクトに使用する新しいツールを積極的に調査する。チームのメンバーに新しいツールの導入を検討してもらいます。さらに、候補として挙がったツールをテストして、サポートする価値があるかどうかを判断してもらいます。期待されるメリットが形になるかどうかを調べるために、既存のテクノロジーと導入候補のテクノロジーの両方を使用した新しいシステムを実装してみます。使用するテクノロジーを選択する際は、そのテクノロジーに伴う費用を十分に把握していなければなりません。費用には、ライセンスやサポートの費用、さらにそのツールを実行するために必要なインフラストラクチャの費用も含まれます。さらに、テクノロジーの導入とメンテナンスをサポートする人員を増やさなければならない場合もあります。
  • 新しいツールを試すための時間をスケジュールする。定期的に、チームが新しいプロジェクトと新しいテクノロジーを試すことができるセッション(ハッカソンなど)を開催します。こうした試みの結果として、導入候補から外れるツールもあるでしょう。重要な点は、新しいテクノロジーをスタックに導入しやすくすること、あるいは新しいテクノロジーの導入は適切でないと判断できるようにすることです。
  • 定期的にプレゼンテーションを行い、新しいツールについて説明する。新しいテクノロジーのプレゼンテーションと説明を目的とした会議(ランチ ミーティング)などを企画して主催します。非公式のミーティングにして、チームが新しいテクノロジーで取り組んでいるプロジェクトや調査していることについて、各チームメンバーがプレゼンテーションを行うこともできます。このような非公式のミーティングは、グループで新しいテクノロジーについて話し合い、最新情報を入手するうえで役立ちます。おすすめのアプローチは、チームメンバーが順番にプレゼンテーションを行うことです。あるいは、他のチームのメンバーや社外のゲストを招いてプレゼンテーションを行ってもらうこともできます。組織外の関係者を関与させると役立つことがあります。特に、その人物がツールを使用したことがある場合は、長期間使ってみないと明らかにならない費用や複雑さについて情報を入手できるからです。

目標は、会話の中でテクノロジーを話題に取り上げて、チームに適切なツールとテクノロジーをチームが決定できるようにすることです。こうした会話の結果、現在のツールを使い続けるという判断に至る場合もあります。

チームにツールの選択権が与えられているかどうかを評価する方法

チームがツールの選択権を与えられていると感じているかどうかを判断する最良の方法は、質問をすることです。チームが使用しているツールの数やツールの変更頻度を数えても、これを判断することはできません。チームが同じツールを使い続けるか、ツールを変更するかを、指示に従って行う場合があるためです。

次のステップ