Alison Polton-Simon氏はThoughtWorksのソフトウェアエンジニアであり、以前はGoCD Analyticチームの一員として、開発者や運用、ビジネスに関わる人に対して、スマートでデータ駆動な意思決定ができるよう支援した。
Polton-Simon氏は10月に開催されたDevOpsDays NZで'Metrics That Matter'と題して講演をした。継続的デリバリの理解と改善を支援するのに最も効果的なメトリクスについての氏の考えを共有した。
InfoQは、Polton-Simon氏にインタビューして、氏の現在の関心領域について、計測するべきメトリクスについて話を聞いた。
InfoQ: あなたの現在の役割について、そして、DevOpsの世界のどの領域に関心があるかについて教えてください。
Alison Polton-Simon: 私は今、ThoughtWorksのソフトウェアエンジニアとして働いています。これまでの5ヶ月間、あるアプリケーションパフォーマンス監視を提供する企業を新しいインフラに移行するのを支援しています。既存の一枚岩のコードベースとビルドシステムを独立したリポジトリに移植するのはゼロから新しいシステムを設計する素晴らしい機会でした。多くの複雑なケースをすでに知っていたのも役に立ちました。
技術と実践という点では、Infrastructure as Codeが盛り上がっているのに興奮しています。このプロジェクトでも、全てのパイプラインをDSLで構成しました。こうすることで、従来のソフトウェア開発では一般的な信頼性と再利用性を手に入れられます。また、ビルドエージェントの大多数をコンテナにしました。ビルド環境はより信頼性が増し、開発者はローカルのテスト環境を簡単にセットアップできるようになりました。
私たちの顧客は一緒に働いている開発者なので、このような変化がどれほどインパクトがあったのかを直接聞けました。素晴らしい成果がありました。
InfoQ:あなたのDevOpsDays NZの講演のタイトルは'Metrics That Matter'ですね。内容をもう少し教えていただけますか。
Polton-Simon: 今のプロジェクトに携わる前、ThoughtWorksのGoCDを企業向けに提供する仕事をしていました。私たちのゴールは分析サービスを提供し、チームがビルドやデリバリプロセスをどのように改善したらよいのかを理解できるようにすることでした。これは未知の領域のサービスです。なので、私たちは継続的デリバリを実践している人やコンサルタントに、価値があるメトリクスについて話を聞くことから始めました。講演では話を聞いて得られた共通のテーマと落とし穴について話します。
InfoQ: どのような種類のメトリクスを計測するべきでしょうか。
Polton-Simon:ソフトウェア開発チームのゴールは顧客に価値を確実に届けることです。役割に関係なく、皆が日々のプロセスの中で不効率さに不満を感じています。
開発者にとっては、コミットとビルド成功の間に長い時間がかかるというようなことがよくあります。
DevOpsの担当者にとっては、アプリケーションをデプロイするのが課題です。サイクルタイムや平均復旧時間のような私たちが選択したメトリクスは、痛いところを定量化しチームが成長を追跡し理解できるようにします。
InfoQ:これらのメトリクスの価値は、収集するチームのローカルな文脈にどの程度影響を受けますか。
Polton-Simon: 私たちはソフトウェア開発の領域ならどこでも関心の対象になり、チームのメンバーが皆、関係があると感じられるメトリクスを選ぼうとしました。しかし、これは、ローカルな文脈が無関係だという意味ではありません。
ローカルな状況がメトリクスの価値に影響を与える場合の重大な例は、メトリクスの確かさが信頼されていない環境でメトリクスが収集される場合と、個人やグループがメトリクスを収集、分析する場合です。
あるチームにとって重要だとみなされたメトリクスや組織のリーダーシップに対して信頼を置いているメトリクスが、別のチームにとっては馬鹿げたものだったり、有害だったりすることがあります。例えば、あるチームは速度を重視しており、振り返りではいつもデリバリの頻度をあげる方法について話してます。しかし、このメトリクスを無意味だと考える人は単に体裁を整えるために速度を膨らませて見積もります。
システムの怖さやゲーム性を刺激するメトリクス駆動の手法の可能性を前提にする場合、初期段階で信頼と共通のミッションを確立するためにエネルギーを投資するのが重要です。
InfoQ: 従来の、トップダウンのKPIと組織レベルのメトリクスはこの考えにどのように適合しますか。
Polton-Simon:チームレベルのメトリクスは、組織の目標やKPIに合わせて構築する必要があります。矛盾する指標を持つ組織の個人は、競合するインセンティブにとらわれてしまいます。組織のKPIは、企業の優先順位についての、高いレベルの指針を提供し、チームレベルの指標は日々の取り組みを推進するために使用します。
InfoQ: ローカルな文脈と組織の両方の効率を改善するために、デリバリとビジネスのメトリクスをコラボレーションさせた例を知っていますか。
Polton-Simon: ローカルなメトリクスと組織のメトリクスを調整するのはコンサルタントとしての私たちの仕事の重要な部分です。ローカルと組織全体の両方の効率性を改善するための機会を見つけるための有効なやり方は、チームを集めて、それぞれにプロダクションへの道を図示してもらうことです。
この方法では、プロセスの中のそれぞれのステップはプロセス時間、待ち時間、痛点が注釈として書かれます。この3つの領域を強調することで、チームは成長のためのローカルな領域(例えば、あてにならない、長い時間かかるテスト)を見つけられます。また、組織の効率性を改善する領域も見つかります。
チームと組織は最大の痛点を見つけ、それぞれの水準で対処するアクションを特定できます。この方法は組織横断の共通理解を促進し、主要な関心事に対処するようにチームを力づけます。
InfoQ: 顧客満足や顧客体験のような、より主観的、定性的な成功指標を計測することについてはどのように考えていますか。
Polton-Simon: このような指標を扱うにはふたつの補完的な方法があると思います。ひとつ、例えば、ネットプロモータスコアのような従来の方法を使うことです。ユーザーにある特定のプロダクトやサービスを友達にどの程度薦めるかを点数でつけてもらいます。長い間、実施されてきたやり方です。
もうひとつは比較的新しいやり方で、より定性的で、組織のパフォーマンスを理解するために測定を行います。重要なのは、企業の価値に合うように測定することです。
私が感銘を受けた奇抜な例はZapposです。Zapposは優れたカスタマーサービスを誇りにし、顧客の最善の利益を提供するためなら長時間のサポート電話も奨励されます。広く知られた例では、あるカスタマーサービスの担当者は11時間も顧客と話し、購入を支援しました。休暇や子供のころの話を交えながら、です。顧客に素晴らしい印象を与えたのです。
このような奇抜なメトリクスを追跡することで、競合他社のユニークなメリットを強化できます。
InfoQ: DevOps文化の協力的な側面が、レビューと測定のプロセスを通じて刺激を受けた例を教えてください。
Polton-Simon: 文化の変化を生み出すことはどのような組織にとっても難しいことです。しかし、計測するべきものは何かを特定するためのプロセスにチームを巻き込むことで協力関係は促進されます。
私たちが一緒に働いた企業では、チーム間ではほとんどコミュニケーションがありませんでした。また、回帰テスト(実行に14時間もかかる)は信頼ができず、いくつかのテストは常に失敗していました。テスト結果を無視する習慣が身につき、オールグリーンにするということを諦めていました。
この技術的、文化的問題に対処するため、ThoughtWorksのチームは3日間のワークショップを開催し、改善のための最も優先順位が高い領域を特定し、チームがお互いにプロセスと痛点を共有する機会を提供しました。
次のステップとして、チームは自分たちで見つけた課題に対して対処するためにすぐにできることを選択します。このやり方は、チーム横断の協力の機会を提供し、より高いレベルのメトリクスと改善の領域を特定します。
その後数ヶ月、フォローを行い、テストはグリーンになり、ある変更がコミットからデプロイされるまでの時間が18日から10日に減少しました。また、ビルドパイプラインの状態への関心が高まり、問題が起きたとき、正常な状態に戻すためにチームを跨いでコミュニケーションが行われるようになりました。チームはコミットからデプロイまでの時間を減らすための新しい領域を探し続けています。メトリクスは銀の弾丸ではありません。本物の協力関係と文化的改善には時間がかかります。労力をしっかりと投資する必要があります。
InfoQ: 計測を始めたいと思っている人に向けてアドバイスをお願いします。
Polton-Simon: 改善の計測をして協力的で反復的な手法を導入したいという人を勇気づけたいと思います。
新しいプロジェクトを始めるとき、チームにコードをコミットからプロダクションへ持っていくプロセスを図示してもらいます。これをやりつつ、痛点や問題がある領域について質問をします。あるチームでは最大の問題がすぐに見つかります。例えば、信頼できないビルドやパイプラインです。また、後半になって問題が見つかるケースもあります。長時間実行される結合テスト、頻繁に失敗する配置などです。
チームが痛点を列挙したら、最も大変な点について採決し、それについて定量化する方法を探ります。そして、素早くできる対策を試してみます。
私はメトリクスをとりたいと思っているチームに同じようなプロセスを実施することを薦めています。また、簡単に反復できるようにすることも推奨しています。メトリススを選んで何度かスプリントを実施した後に無関係に感じるなら、プロセスを反復して新しいことを試すと良いでしょう。
継続的な改善は、最大の痛点に対処するために調整された場合にとてもインパクトがあります。
InfoQ: DevOpsDays NZにはどのような期待をしていますか。
Polton-Simon: DevOpsDays NZに参加し学ぶことができるのをとても楽しみにしています。DevOpsDaysは実践を行なっている人から学ぶための素晴らしい機会であり、同じような問題を異なる技術スタック、異なる産業、企業のステージで解決しているのを比べてみることができます。私が参加した最後のDevOpsDays(コロラドはデンバーで開催)では、啓発的な講演と素晴らしいコミュニティに恵まれました。今回も同じだと思います。
DevOpsDayz NZは10月3日から4日に開催。Alison Polton-Simon氏と多くの登壇者が幅広い文化的技術的トピックについて話し合った。
Rate this Article
- Editor Review
- Chief Editor Action