データドリブンでITサービスを支えるエンジニアチームを強化するための前準備

本記事はEmpower Your Engineers with a Data-Driven Approachの抄訳です。

エンジニア、ここでは幅広くITサービスを社内外に提供しているエンジニア（ソフトウエアエンジニア、ネットワークエンジニア、運用エンジニアなどなど）を指すことにしますが、エンジニアチームのマネージャーやリーダーなどチームを引っ張っていく役割皆様、チームのことをどれだけご存知でしょうか？「仕事が早い」「知識が豊富」「コミュニケーション力がある」などなど、メンバーにはそれぞれ活躍できる場面が違うでしょう。では、製品開発・提供において、どれだけチームが動いているのか皆様はご存知でしょうか？昨今、さまざまな環境変化に対応すべく、ウォーターフォール型の開発だけでなく反復型で少しずつ製品を成長させていくように体制を変えていたり、サービス・チーム・責務を分割して素早い判断ができるよう変わってきています。素早い対応を求められる現代、成功している企業では、ソフトウェアエンジニアを後押しするために、データを活用しその影響を計測しています。

理想論ではありますが、データを活用できるようになれば、「アプリケーションのパフォーマンスを最適化するためにソフトウェアエンジニアが次に何をすべきか」、「今世の中に提供しないといけない新機能は何か」、「サービスの停止やバグ、使い心地の悪いサービスによって顧客の喪失しないように何をすべきか」、このような問題に対して確度の高いヒントを得ることができます。

例えばエンジニアが、「Webページのパフォーマンスを最適化するためにWebサイトトラフィックを分析」したり、「コードが効率的に実行されているか保証するためにベンチマークを確認」したり、「サービス全体の異常を検出するために自分たちの知っているもの以外も確認」する、というようにサービスの最適化を計画する時のことを考えてみてください。より優れた計画をエンジニアが計画し、構築、デプロイ、そしてサービスを提供するまでには、メトリクス、イベント、ログ、トレースなどのあらゆるテレメトリデータを継続的に収集し、自分たちの欲しい形で確認できないといけません。そこで、オブザーバビリティ・プラットフォームが必要となってくるのです。

データドリブンエンジニアリングとは、エンジニアリングツールやプラットフォームから収集したテレメトリデータを利用して、ソフトウェアエンジニアリングチームの作業を最適化し、顧客、チーム、収益に直接的な利益をもたらすようにすることです。

データドリブンエンジニアリングのメリット

ここでは、そのようなメリットをいくつかご紹介します。

• データドリブンのアプローチは、不完全な情報や直感に頼るのではなく、あらゆるテレメトリデータを使って状況を明確かつ具体的理解できるようにし、ビジネス上の意思決定に利用することを意味します。
• 意思決定の背景にあるデータを可視化することで、ソフトウェアライフサイクルのすべての段階で、エンジニア全員がデータを見て理解し、データに基づいてパフォーマンスを最適化することができます。
• データを使ってお客様への影響を測定することで、お客様が何を必要としているのかが明らかになり、ビジネス上の意思決定、製品、サービスがそれらのニーズを解決することができるようになります。

実際、Accenture社のレポートによると、"エンタープライズ戦略を持つデータドリブンの組織は、実際に毎年30％以上の割合で成長している "とのことです。

しかし、データドリブンエンジニアリングとはなんでしょうか。イメージできますか？このように明確なメリットと、現代の組織がビジネスのあらゆる場面でデータを活用しているという事実があるにもかかわらず、コンセプトだけで定義が不十分なことが多く、私の担当するいくつかの企業でも試行錯誤の段階で、導入が困難なものだと感じています。

データドリブンエンジニアリングを実現するには

データドリブンエンジニアリングでは次のような問いかけをします:

• あなたのチームは正しいプロジェクトを担当していますか？
• あなたのチームは、エンドユーザーに望ましい効果をもたらす仕事をしていますか？
• チームのリソースはビジネス目標に対して適切に割り当てられていますか？

ソフトウェアエンジニアリングチームに関するこれらの質問にデータを使って答えているのであれば、すでにデータドリブンエンジニアリングを実践しており、その結果、顕著な効果が得られていると考えられます。しかし、これらの質問に経験則や感覚で答えている場合は、もしかするとエンジニアや会社全体の可能性を見つけられていないかもしれません。

では、データドリブンで、答えるにはどうすれば良いのでしょうか。

チーム・会社全体に導入するための前準備として、以下５つの質問について考えておきましょう。

1. どのようなデータを集めれば目標を達成できますか？
2. データの収集・測定方法はどうしますか？
3. さまざまなデータをまとめて分析するためにどのような方法を用意しますか？
4. データドリブンを組織全体に適用する方法はありますか？
5. データドリブンエンジニアリングをサポートするオブザーバビリティ・プラットフォームを選択する際には、どのような点に注意すべきでしょうか？

1. どのようなデータを集めれば目標を達成できますか？

ビジネスにおける重要業績評価指標（KPI）はすでにお持ちだと思いますが、ソフトウェアエンジニアリングチームはKPIをもっていますか？チームとして具体的な目標を定義し、その目標が達成できているか見るための指標を設計する必要があります。目標は、組織内の他のチームの目標と似ていても構いません。例えば、ユーザーのサインアップを増やすことは、マーケティングチームやセールスチームのKPIになるかもしれません。しかし、サインアップページやエクスペリエンスのコードを実際に実装しているのは開発チームですし、サービス提供には運用チームも関わってきます。同じく「ユーザーのサインアップを増やす」という目標を掲げたとしても、開発チームでは「サインアップフォームのUX改善で入力時間を短くし離脱を防ぐ」ことが目標となるかもしれませんし、運用チームでは「ソフトウエア単体では可用性99.9%のところ、運用で99.95%まで引き上げ、ユーザーが利用できるサービスの時間を増やす」ことが目標となるかもしれません。

エンジニアリングとは一歩遠い、ビジネスの一般的な組織目標に加えて、開発や運用などのエンジニアリングにのみ適用される特定の目標を設定することで、エンジニアリングチームの価値やサービスを提供する企業の印象はグッと上がります。以下の図は、ソフトウェアのライフサイクルの各段階で収集できる有用な遠隔測定データを示しています。

2. データの収集・測定方法はどうしますか？

JIRA、GitHub、Slackなど、エンジニアリングチームの作業を測定ができるような多くのツールをすでに導入していませんか？これらのツールでも、クローズしたチケットの総数やリリースした機能の数などのメトリクスを測ることができるでしょう。しかし、エンジニアリングチームが見るべき重要な評価指標はそれだけでしょうか？

例えば、中長期的なマーケティング戦略を行うために、マーケティングチームやウェブチームではGoogle AnalyticsやBIツールを使ってページビューや直帰率を測定しているかもしれません。しかし、それらのデータはサービスやソフトウエアのメトリクスと分断されており、企業全体の方針と開発や運用、エンジニアリングチームの方針が同じ方向を向いていない、ということにつながるかもしれません。不足を補うためにツールを組み合わせていくという方法も取れますし、サービス全体の構成要素を観測できるオブザーバビリティ・プラットフォームを利用するということも選択肢としてあるでしょう。

3. さまざまなデータをまとめて分析するためにどのような方法を用意しますか？

各々のチームがそれぞれ別のデータをみている場合、「木を見て森を見ず」という状況になりがちで、盲点があったりリソースの配分ミスにつながります。

データを一つにまとめて見ると、新たな気づきが生まれます。例えば、マーケティングチームがGoogle Analyticsでサインアップページのページビュー数の減少を確認している一方で、エンジニアリングチームがそのサインアップページに関連するチケット数の増加に対応している場合があります。これらのデータが相関していれば、マーケティングチームがこれまでにない打開策を考える時間は必要なく、機能の修正や運用改善だけで数の減少は収まるでしょう。両チームが問題を正しく特定できるようにするためには、別々のプラットフォームや情報を個別に見るのではなく、点と点との間を結びつけて見ることが必要です。

4. データドリブンを組織全体に適用できますか？

データドリブンなエンジニアリングは、エンジニアリングリーダーや経営陣だけでなく、組織のすべてのメンバーが採用すべきものです。「構築・測定・学習（評価等）のサイクル」のような反復型開発に近いプロセスの導入を意味します。

反復型開発のサイクルでは、単発で優れたソフトウェアを構築する、ということではなくその影響を測定し、その測定結果を評価・学習して、次のサイクルでそのソフトウェアを改善、これを繰り返し行うことを指します。KPIを決めたり目標を決める、それを組織で賛同を得て運用していくというのは、実行するよりも遥かに難しい決断であることは間違いありません。しかし、大きな目標のためにも、まずは「やってみる」というところからコツコツと成長につなげていくことが重要です。データドリブンな体制に変え、企業・組織全体で動いていくことは成功には欠かせません。

5. データドリブンエンジニアリングをするためのツール選びでの注意点はなんですか？

ポイントは以下の２点です。

1. 提供するサービス全体を漏れなく観測できるか
2. 日々発展していくオブサーバビリティ、テレメトリデータの技術に追従できるか

1. 提供するサービス全体を漏れなく観測できるか

市場に出回っているソリューションを使っていると、「リアルユーザーモニタリングの機能が不十分」、「継続利用するためにはサンプリングしないといけない」、「OSSでスケールアップをこれ以上しようとするとメンテナンスが大変」と言ったように、サービス全体を観測していくには課題が生まれることがあります。これらの課題は、システムが大きくなればなるほど顕著に現れてきます。単発のスナップショットで取れる情報ではなく、継続して全ての情報を収集し、サービス全体のありのまま情報を集めることは、データドリブンで動いていく前に、大前提としてクリアしておかなければいけません。

2. 日々発展していくオブサーバビリティ、テレメトリデータの技術に追従できるか

サービスを知るためには、メトリクス・イベント・ログ・トレースといったデータが欠かせません。OSSでもそれぞれに特化した機能を選ぶことはできると思いますが、成長が著しく、eBPFのような新しい手法まで出てきているオブザーバビリティ・テレメトリの世界に追従し続けられる社員を抱えていくことを選びますか？データドリブンで動いていくための最優先事項はデータの活用であって、データのためのプラットフォームを管理することではありません。餅は餅屋、皆様は皆様のサービスの効果・ビジネスを最大限に引き上げていくことに注力してください。

データドリブンでエンジニアが活躍できる組織へ

データドリブンエンジニアリングはエンジニアチーム、そして組織全体をうまく動かしていくためのピースの一つにすぎません。しかし、今まで見ていなかったことを見えるようにし、効果を最大化するためにピースとピースを繋ぐための重要なピースでもあります。皆様もまずは「やってみる」というところからビジネスのためのエンジニアリングを行い、30%成長企業の一社として仲間入りしませんか。