Accelerate: データ駆動型 DevOps パート4: ビジネス・アジリティ

2020/10/9 - 読み終える時間: 2 分

Data-Driven DevOps Part 4: Business Agility の翻訳版です。

データ駆動型DevOpsパート4：ビジネス・アジリティ

2020年10月9日

著者: Steve Boone / HCL Software DevOps Head of Product Management

シリーズの過去のパート

• Accelerate: データ駆動型 DevOps パート 1: 序章
• Accelerate: データ駆動型 DevOps パート 2: データ駆動型の文化
• Accelerate: データ駆動型 DevOps パート 3: データを使った追跡と計画

私がウェビナーやブログ記事、プレゼンテーションの中で、ビジネスの俊敏性についてよく話しているのを聞いたことがあると思います。それは、HCL Software DevOps のキャッチフレーズの一部でさえあります。セキュアでデータ駆動型のビジネス・アジリティ。しかし、ビジネス・アジリティとは実際には何を意味し、データ駆動型の DevOps 戦略にどのように適合するのでしょうか？

ビジネス・アジリティとは、ビジネスまたはその構成要素が、安定性を維持するために適応することで変化に迅速に対応する能力のことを指します。この概念は決して新しいものではありません。実際、アジャイル開発のコアとなるアイデアはここから得られます。変化に適応する能力は、アジャイルプロジェクト管理の要であり、アジャイル開発手法の主な利点の一つです。開発チームが時間を有効に使えば、ステークホルダーが求めているものをタイムリーに届けることができる。また、ステークホルダーのニーズが変われば、それに合わせてチームの行動もすぐに変化させることができます。

2020年、企業はコロナウイルスのパンデミックにより、かつてない状況に直面しています。これらの状況は、企業が日々の活動に慣れている方法、特に顧客とのやりとりに大きな混乱をもたらしています。このような荒れた時代を生き抜くためには、データ駆動型のビジネス・アジリティが必要であることは間違いありません。

データ駆動型の DevOps 組織は、何が破壊されているのかを迅速に特定し、コース修正のための迅速で積極的な会話ができるようにすることで、競合他社に対して優位に立っています。多くの個人やビジネス・ユニットが問題の解決策を考え出し、すべての新しいアイデアが優れたものになるわけではなく、また、これらのアイデアの多くが新たな課題を提示することになります。どのようにしてそのすべてを吟味するのか？ 問題を修正しすぎたり、修正しきれなかったりした場合、どのようにして認識するのでしょうか？

データがなければ、このプロセスは推測ゲームであり、新しいプロセスのテストに多くの無駄な時間を費やし、失敗する可能性があります。適切なデータがあれば、より早く失敗することができるので、より早く成功にたどり着くことができます。成功している組織は、偉大になるためには失敗しなければならないという考えを受け入れる文化を持って、早く失敗するという考えを受け入れています。失敗を早くして、その失敗を認識すればするほど、失敗はすぐに学習の機会となります。ヘンリー・フォードは、「失敗とは単に、もう一度やり直す機会であり、今回だけはもっと知的に」と言いました。これこそが、まさにデータ駆動型 DevOps の目標なのです。

このシリーズのパート 2 では、ソースコード管理やワークアイテム管理技術に由来する、個々の貢献者によって生成されたデータが、組織全体の文化や、利害関係者への成果物を正確に予測する能力の向上にどのように役立つかについて議論しました。ビジネスの俊敏性については、継続的インテグレーションやデプロイメントソリューションからテストの自動化やセキュリティスキャンの結果に至るまで、さまざまな DevOps テクノロジーから得られるデータに焦点を当てていきます。これらのデータをキャプチャし、可視化し、処理することができる組織は、以下のことが可能であることに気づくことでしょう。

• アイデアから顧客まで、現在のエンドツーエンドのソフトウェア・デリバリー・プロセスをベンチマークする
• 既存または新たに作成されたボトルネックの特定
• 新しいプロセスの変更やアイデアの影響を理解し、迅速に失敗して混乱を回避できるようにします。

究極のフィードバックループと継続的改善

ソフトウェア・デリバリ・パイプラインから送られてくるデータを可視化して分析することで、組織は貴重な「高速フィードバック」ループを実装するという DevOps のアプローチを取ることができます。多くの企業にとって、日々の業務をオーバーホールする機会は、年に一度か二度しかありません。これは単に十分なスピードではありません。文化的にも、私たちは日々向上していくことを受け入れなければなりません。そのためには、まず、現在の業務のベースライン、つまり現在のパフォーマンスのベンチマークを確立する必要があります。そのベンチマークが決まれば、データのライブ表示がリアルタイムのバリュー・ストリームとなり、組織は改善の余地があるところに焦点を当てることができます。

リアルタイム・バリュー・ストリームには、多くの優れた利点があります。最も明白な利点の1つは、特定の作業単位を追跡し、それをスプリント、リリース、チーム、および個々の貢献者に関連付けることができることです。この作業をバリューストリームの特定のステージに結びつけることができるので、作業が行き詰っている場所を簡単に発見することができます。

このような隠れたボトルネックのお気に入りの例の一つは、HCL Software の自社開発チームの一つにありました。このチームは、コードレビューに悩んでいました。彼らは、コードをマージする前に行わなければならないコードレビューのバックログを常に大量に抱えているようでした。バリュー・ストリームのデータを可視化することで、作業が行き詰った段階を正確に見ることができ、納品プロセスにボトルネックを作っていました。彼らはコードレビューを行うことに長けていましたが、システム内のコードレビューを承認する権限を与えられた人が十分にいなかっただけでした。それは取るに足らない利益のように見えるかもしれませんが、私たちのソフトウェア開発プロセス全体に散らばっている無駄のポケットが何十もあります。それらを取り除くことができればできるほど、馬からユニコーンへの移行のための道が開ける可能性が高くなります。

プロセスの変更と混乱

チームが現在の価値の流れを評価し始めると、現在のプロセスを合理化するための多くの創造的な 方法を思いつくでしょう。その中には良いものもあれば悪いものもあるかもしれませんが、重要なのは、チームとビジネスの両方が新しいプロセスの変更の結果を追跡して、スループットの増加があったかどうかを判断することができるということです。これにより、新しいプロセスを導入したことで、実際に高品質のソフトウェアをより早く、より早く提供できるかどうかを知ることができます。

このように大量のデータがあれば、すべてが意見である必要はありません。データは、会話から「私はそう思う」を取り除き、「私たちは知っている」に変えます。個人が「2週間のスプリントから1週間のスプリントに移行してから、私たちの方がうまくいっていると思います」と言うのではなく、データを調べて確かなことを知ることができます。これは、私たちが話していた文化についての対話に戻ってきます。チームが自分たちのプロセスを定義することを信頼しているのであれば、チームが自分たちのミスから学ぶのを助けるツールを提供する必要があります。これは、エンジニアリングチームがスピードを上げすぎて品質が低下することを防ぐと同時に、エンドツーエンドのプロセスが可能な限り堅牢で効率的であることを確認するためのものです。

データ駆動型 DevOps の旅にご参加いただき、ありがとうございました。これまで、データ改善の文化をどのように改善するか、ソフトウェア配信の追跡と計画をより効率的にし、組織にビジネスの俊敏性をもたらし、潜在的な混乱に迅速に対応できるようにするかについて見てきました。次回の記事では、すべてのデータを一堂に集めて、ビジネスの整合性についてこれまでにない可視性を提供することについてお話ししますので、ご期待ください。また、データがどのようにしてリスクを軽減し、組織をガバナンスの自動化への道へと導くのかについてもお話しします。