データ駆動型 DevOps パート 5: アライメントとガバナンス

2020/10/19 - 読み終える時間: 3 分

Data-Driven DevOps Part 5: Alignment and Governance の翻訳版です。


データ駆動型 DevOps パート 5: アライメントとガバナンス

2020年10月15日

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

画像の説明

多くの点で、データ駆動型のDevOpsは、ソフトウェア・ビジネスがどのように運営されているかを詳細に把握することを可能にします。この種の戦略は、製造工場の上の産業用キャットウォークのようなものだと考えてください。データは、アイデアからクライアントに至るまで、ソフトウェアのデリバリー・ライフサイクル全体を網羅することで、驚くほどの可視性を提供します。この可視性は非常に有益です。組織内で何が起こっているかを知ることができるだけでなく、再作業を減らし、コストを削減し、ビジネスにガバナンスを提供してリスクを軽減する機会を提供してくれます。

データ駆動型のDevOpsとバリュー・ストリーム管理は、「あったらいいな」と思う機能セットではないことを理解することが重要です。以下の問題解決に真剣に取り組みたいと考えている企業にとっては、「持っていなければならない」機能です。

ビジネスの整合性

まずは、いくつかの質問から始めてみましょう。顧客を喜ばせ、収益を向上させる機能は、積極的に取り組んでいますか?それらの機能はバックログに残っていますか?予定より早く、あるいは遅れていますか?いつになったら、クライアントに約束した価値を提供できるようになるのでしょうか?

簡単に言えば、ビジネスの整合性とは、エンジニアリングチームが行っている開発作業が、全体的なビジネス目標に可能な限り整合しているかどうかを確認することです。開発とビジネス目標が一致している企業は、より高品質なソフトウェアをより早く提供することができます。なぜでしょうか?それは、ビジネスの主な優先事項が明確だからです。個々のコントリビュータは、一日に何度も「すべきか、すべきでないか」の決断を迫られることはありません。

多くの企業は、エンジニアリングチームがどのような開発ツールやプラクティスを使用するかを強制しなくなっています。開発組織が毎日使いたいツールを選べば、より幸せで生産性の高いものになるという願いが込められています。これは必ずしも真実ではありませんが、ビジネスにとっては真の課題となります。実際にどのような作業が行われているかを可視化することは、すでに非常に困難な問題です。また、それぞれが独自のプロセスやツールを使用している何百もの開発チームのデータを集計しようとすると、さらに困難な手作業になってしまいます。

データ駆動型のDevOpsは、ビジネスの連携にこれまでにない機能を提供します。バリューストリームを流れる作業を可視化することで、開発マネージャ、プロダクトオーナー、リリースエンジニア、エグゼクティブなど、誰もがそれを見る必要がある人は誰でも、現在何に取り組んでいるのかを知ることができます。進行中の作業とまだ開発されていない作業(バックログ)の両方を検索して、実際のビジネス価値がどこにあるのかを明確にレポートすることができることを想像してみてください。

私の経験では、開発チームは正しいことをしたいと思っています。開発チームは、価値を提供してくれる機能に集中したいと考えています。多くの場合、最高の貢献者はいくつかの方向に引っ張られ、顧客を喜ばせ、真のビジネス価値を提供することに最も近い仕事から遠ざかってしまうことがあります。このような仕事は、時には無計画であるために、さらに困難を伴うこともあります。無計画な仕事は生産性を窒息させ、ビジネス価値を期限内に提供する組織の能力に大きな負担をかけることになります。

無計画な仕事

無計画な仕事を完全に払拭することはできませんが、それを管理できるかどうかは非常に重要です。計画外の仕事には多くの課題があります。

  • それは計画された優先順位のある仕事から焦点を奪う
  • 完成までの労力は不明
  • 成功の明確な定義がないことが多い
  • それは「スコープ・クリープ」の扉を開く。

企業は、計画していないことに対して、どのようにリソースと時間を配分しているのでしょうか?さらに重要なのは、どのようにして計画外の仕事を積極的に減らしていくかということです。その答えは、お察しの通り、私たちが毎日使用しているツールのデータの中にある。計画された作業を追跡するためにコードのコミットや作業項目を追跡するのと同じように、サポートツールや作業項目管理ツールからのデータを使用して、計画外の作業とそれがビジネス価値を提供する能力に与える影響を可視化することができます。

画像の説明

組織の最高の貢献者は、通常、予定外の作業に最も苦しんでいる人たちです。彼らは最も知識が豊富で、重要なサポート問題を支援するのに最も適していると考えられており、困難なシナリオでクライアントを支援した経験が最も豊富です。トップパフォーマーだけに頼ることの問題点は、同じ貢献者であっても、価値の高い非常に重要なビジネス上の成果物の大半を担っている可能性が高いということです。そのため、もしあなたのデフォルトの動きが、火事を消すために常に最も熟練した従業員を連れてくることであるならば、計画された仕事は苦戦を強いられることになります。

このような状況を改善するには、個々の貢献者がどの帯域幅を持っているかを可視化することで、余分なキャパシティを確保することができます。これにより、チームが一時的にフォーカスをシフトしている間に、ビジネス価値を牽引している余分な計画的な仕事を引き受けてくれる個人を特定することで、他のチームメンバーがそれぞれの役割で成長する機会を提供します。

計画外の仕事は予期せぬことであり、困難であり、主要なビジネスの専門家から労力を奪い、おそらく何よりも組織の文化を損なってしまう。計画外労働は、持続不可能な労働慣行と不健全な文化につながる可能性があります。計画外労働を根絶することはできませんが、データを利用してその影響を軽減し、組織の文化と生産価値を維持することはできます。

品質とセキュリティの取り組みを検証する

セキュリティと品質への取り組みが枯れてしまったり、早期に失敗したり、実を結ばなかったりするのを防ぐにはどうすればよいのでしょうか。個々のチームやビジネスユニットにとってはそれほど大変な作業ではないかもしれませんが、組織全体で管理することは非常に大きな作業です。

先に述べたように、多くの企業が生産性の向上を期待して、開発組織に自分たちが最も使いやすいと感じるツールを選択させています。これにはいくつかの利点がある一方で、全く新しい課題も発生します。組織は、何十ものツールセットと何十年もの技術にまたがるセキュリティと品質の取り組みをどのようにして追跡し、実施することになるのでしょうか?組織のすべてのアプリケーションとチーム全体の品質とセキュリティの結果を集約することで、企業はどの取り組みが健全で、どの取り組みにさらなる育成が必要なのかを見極めることができます。

リスクを軽減する自動化されたガバナンス

組織は、特定のリリースの「準備ができているかどうか」を計画し、検証するための会議にかなりの時間を費やしています。リリースエンジニアと変更諮問委員会 (CAB) のメンバーは、健全な量のチェックとバランスを提供していますが、これは大部分が長く、手動で行われるプロセスです。10年にわたる DevOps のベストプラクティスから何かを学んだとすれば、長くて手間のかかる手動の作業は、自動化されることを切望しているだけだということです。経験上、手動プロセスはエラーが発生しやすいことがわかっています。

品質とセキュリティのメトリクスの可視性を提供することは、最初のステップに過ぎません。次のステップは、ビジネスと顧客を保護するためにデータを使用することです。そのための最良の方法は、バリューストリームから送られてくるライブデータの定常的な流れを管理し、特定のビルド、デプロイメント、リリース、コンポーネント、機能、またはビジネスイニシアチブのセットがテストおよびスキャンされたかどうかに基づいて、インテリジェントな決定を下すことができるインテリジェントなゲーティングメカニズムを設定することです。

最高情報セキュリティ責任者 (CISO) は、組織内のすべてのバリューストリームを簡単に見ることができ、誰が会社で実施されているベストセキュリティプラクティスに従っているかを知ることができるので、コスト削減につながることを考えてみてください。また、リリースエンジニアが顧客に悪影響を及ぼす可能性のある品質リスクを簡単に特定できるようになれば、リリースエンジニアにとってのメリットを考えてみてください。

リスクを軽減し、セキュリティと品質を一貫して向上させる最善の方法は、これらを常にビジネスの優先事項とすることです。バリューストリームマネジメントは、お客様がこれらの取り組みを日々のタスクの最前線に置いておくことができるように支援します。

ベストプラクティスの特定

ベストプラクティスを見極めることは、重要なスキルです。ベストプラクティスは、問題を解決するための最も効果的な方法を伝えるのに役立ちます。組織のバリューストリーム全体のすべてのデータを見ることで、企業は単なる推測ではなく、何が本当にベストプラクティスなのかを特定し始めることができます。チームリーダーやその他の利害関係者は、パフォーマンスに関する重要な質問に答える機会を得ることができます。なぜ、あるバリューストリームの品質とセキュリティ(またはその他の技術的な側面)が他のバリューストリームよりも優れているのか?トレーニングの不足が原因なのか?適切なツールを使用していないのか?これらの質問に答えて質問することで、組織は社内で機能していることの根本原因を突き止め、それを組織全体で再現し、改善が必要なことは何かを迅速に対処することができるようになります。

データを使用してベストプラクティスを特定することのもう一つの大きな利点は、どのバリューストリームが高いパフォーマンスを発揮しているかが非常に明確になることです。高いパフォーマンスを発揮しているチームは、適切に定義されたDevOpsのベストプラクティスの結果である。組織内で高いパフォーマンスを発揮しているチームが特定されたら、そのチームの仕事を称えることは文化的にも重要です。彼らの努力は高く評価され、拍手喝采され、他のチームのベンチマークとして活用されるべきです。 データドリブンDevOps ebookデータドリブンDevOps eBookを入手する

私の新しいeBookで、データとDevOpsの関係について学び続けてください。ダウンロードはこちらから。


HCL Accelerate を Linux と Docker-Compose を使ってクイックスタートする

2020/10/15 - 読み終える時間: 5 分

HCL Accelerate Quick Start with Linux and Docker-Compose の翻訳版です。


HCL Accelerate を Linux と Docker-Compose を使ってクイックスタートする

2020年10月14日

著者: Daniel Trowbridge / Technical Lead

画像の説明

HCL Accelerate の無料の Community Edition を使えば簡単に始められます。このクイックスタートは Linux 上の Docker-Compose を対象としていますが、他のオーケストレーションプラットフォームにも対応しています。Mac や Windows 用のクイックスタートもありますが、コンテナ化されたアプリケーションなので手順は非常に似ています。詳細については、詳細なドキュメントを参照してください。

始める前に必要なものは以下の通りです。

  • Docker Composeがインストールされ、実行されていること
  • HCL Accelerate User Access Key (ここで入手できます)

画像の説明

1. インストーラのダウンロード

以下のリンクをクリックして、HCL Accelerate Linux インストーラをダウンロードしてください。

最新バージョン https://hcl-velocity-binaries.s3.amazonaws.com/accelerate-hcl-install-latest-linux

2. インストーラの実行

インストーラが実行に必要なパーミッションを持っていることを確認してください。

sudo chmod +x accelerate-hcl-install-latest-linux

インストーラーを実行します。

./accelerate-hcl-install-2.6.0-linux

以下の設定値を入力するように求められます。

  • アクセスキー: アクセスキー:製品版に応じたアクセスキーを入力してください。
  • ライセンス: ライセンス: ライセンスの承認が必要です。ライセンスを読んだ後、再度プロンプトが表示されたくない場合は、インストーラーに ?license=accept 引数を渡してください。
  • プラットフォーム: プラットフォーム: "Docker Compose" をプラットフォームとして選択してください。
  • インストールディレクトリー: Installation Directory: インストールフォルダーの親ディレクトリーーへのパスを指定します。インストールファイルは親ディレクトリーの下のバージョンフォルダーに配置されます。これにより、同じ親ディレクトリーを将来のアップグレードに使用することができます。
  • ホスト名: HCL Accelerate のホスト名を指定します。デフォルトは localhost です。ホスト名は、DNS 解決または hosts ファイルなどで、すでに構成されている必要があります。
  • ポート: ポート番号を指定します。デフォルトは 443 です。
  • Startup (起動): インストーラから HCL Accelerate を起動するか、以下の「HCL Accelerate の起動」を参照してください。

インストーラのオプション: インストーラには多くのコマンドラインオプションがあり、完全に自動化することができます。-help を付けてインストーラを実行して、何をサポートしているかを確認してください。

settings.json: アプリケーションの重要な一意のキーは、ユーザー固有のもので、[ユーザーホームディレクトリー] /.ucv/settings.json に保存されていることに注意してください。このファイルは、将来の再インストールやアップグレードで使用するために、インストーラーの入力も保存します。値は、必要に応じてバックアップおよび/または移動してください。

画像の説明

3. HCL Accelerate の起動

インストーラから直接 HCL Accelerate を起動するか、インストールされたバージョンのディレクトリーに移動して docker-compose up -d を実行します。この時点で HCL Accelerate イメージがDocker Hub からプルされているはずです。Docker Hub からプルできない場合は、圧縮されたイメージを含むオフラインインストーラも利用できます。

Docker Compose を学ぶには: Docker Compose CLI については、docker.com で詳しく説明しています。

4. 最初のログイン

ブラウザー(ChromiumベースまたはFirefoxを推奨)を開き、インストーラーに提供されたホスト名とポートに従って、HCL Accelerate のアドレス(https://<ホスト名>:<ポート>)に移動します。有効な証明書を設定していない場合、デフォルトの証明書は自己署名されているため、証明書の警告が表示されます。この警告を過ぎて進むと、HCL Accelerate ログイン画面が表示されるはずです。ユーザー名とパスワードの両方に「admin」を使用して、最初にログインすることができます。

5. 次のステップ

ナレッジセンター


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

画像の説明

シリーズの過去のパート

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

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

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

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

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

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

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

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

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

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

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

プロセスの変更と混乱

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

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

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


Accelerrate: データ駆動型 DevOps パート 3: データを使った追跡と計画

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

Data-Driven DevOps Part 3: Track and Plan with Data の翻訳版です。


データ駆動型 DevOps パート 3: データを使った追跡と計画

2020年10月7日

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

画像の説明

シリーズの過去のパート

応答性の高い、高度にアジャイルな開発組織を持つことに伴う課題は、ビジネス、顧客、自社のチームからの多数の要求を常にこなすことです。これにより、与えられたスプリント内で現実的に達成できる以上の作業を議論し、優先順位をつけなければならなくなります。スクラム、カンバン、エクストリームプログラミングからアダプティブ、ダイナミック、リーンソフトウェア開発に至るまで、チームは何年にもわたって多くの方法論を使ってトラッキングと計画を改善しようとしてきました。それぞれのアプローチは、予測可能でありながらも柔軟性があるという同じ課題に異なるひねりを加えています。

データは、開発チームの追跡と計画の能力において重要な役割を果たすことができます。前回の記事では、データが開発チーム全体のコラボレーションとコミュニケーションをどのように向上させることができるかについて説明しました。具体的には、チームがスプリントごとに作成したデータを分析することで、何がうまくいっていて何がうまくいっていないのかを特定するためのプロセス改善に関する会話が促進されることがわかります。文化を超えて、データ分析には、組織の追跡と計画の能力にいくつかの利点があります。

チームの速度を特定することで計画を改善する

スクラムチームにとって、ベロシティとは、チームが1回のスプリントでどれだけの作業に取り組めるかを示す指標であり、スプリントで配信されたストーリーポイントの数を合計して計算されます。チームのベロシティを知ることは、特定のスプリントやリリースの計画を立てるのに役立つだけでなく、組織全体や顧客とのコミュニケーションを改善するのにも役立ちます。

チームのベロシティを理解することは、意味のある期待値を設定するのに役立ちます。計画されたリリースの数週間前に、納品が予定されていたアイテムのうち、一握りのアイテムが届かないことに気付いたことは何度ありますか?それはいつもガッカリです。透明性を高め、混乱を減らすためには、利害関係者や顧客との間で意味のある現実的な期待値の設定が必要です。そして、この同じ透明性は、個々の貢献者が設定された目標の達成に成功する可能性を高めることになります。

リードタイム、サイクルタイム、スループットなど

組織の正確な予測能力を大幅に向上させることができる指標は、ベロシティだけではありません。リードタイムとサイクルタイムは、開発チーム、プロダクトマネージャ、およびリリースエンジニアが、組織を通じてソフトウェアを提供するのにかかる時間を理解するために追跡する最も一般的な統計量です。この 2 つの指標の違いは微妙です。

  • リードタイムとは、新しいタスクがバックログに表示されてから最終的に「完了」となるまでの期間のことです。多くのチームはリードタイムを定義する別の方法を使用するでしょう。そうでなければ、新しいタスクが優先順位を付けられる前に数ヶ月間バックログに残っている可能性があり、それがリードタイムを膨らませる可能性があります。

  • サイクルタイムとは、誰かがリクエストやタスクの作業を開始した瞬間から始まり、作業が完了するまでの期間を指します。

これらの測定基準はどちらも強力なものです。キャパシティをよりよく理解するのに役立つだけでなく、チームの現在の作業プロセスや、現在のワークフローのボトルネックを示す貴重な情報を提供してくれます。

しかし、リードタイムとサイクルタイムだけでは十分ではありません。これらを単独で解釈した場合、チームが特定のスプリントやリリースでどのような作業を完了できるかについて多くの疑問が残ります。これらの質問に対する答えをよりよく理解するために、スループット、分布、コントリビューターなどのデータ内で見られるさまざまな指標に注目しています。

  • スループットとは、与えられた期間に完了したタスクや作業項目の数のことです。これは、ストーリーポイントを考慮するベロシティとは異なります。

  • ディストリビューションとは、タスク、欠陥、機能など、スプリントのために完了した作業の種類の詳細な内訳です。

  • コントリビューターとは、与えられたスプリントに参加している開発者の数です。10人の開発者で構成されたチームが、常に10人の開発者が貢献しているとは限りません。休暇や病気、そして多くの種類の予定外の作業があるため、この数はかなり一貫性のないものになる可能性があります。

正確に成果物を予測しようとするときには、これらすべての指標を考慮することが重要です。 開発チームのリードタイム、サイクルタイム、ベロシティ、スループット、貢献者の平均数、および典型的な分布を知ることで、作業がいつ完了すべきか、そして最も可能性の高い作業の種類をより正確に把握できます。

リスクの特定

もちろん、どのチームでも時折、何らかの配送の遅延が発生することがあります。このようなシナリオでは、何をリリースの範囲から外すべきか、外すべきではないかについて、組織が計算された情報に基づいた意思決定を行うことが重要です。開発チームのデータを分析することの主な利点の1つは、特定のタスクをビジネス価値に結びつけることができるようになることです。開発用語で言うと、これはエピックス(ビジネス価値)と作業項目(タスク)をリンクさせることを意味します。

このリンクを作成することで、あるビジネス価値のうち、何%が完成しているかを把握し始めることができます。この情報は、リスクを特定し、ステークホルダーや顧客に伝え、意味のある期待値を設定する上で非常に貴重なものです。納品物が抜け落ちたときはいつでも、「なぜこの作業を完了できなかったのか」、「チームはこの納品物の他に何に集中していたのか」など、いくつかの質問が出てくることでしょう。これらの質問に対する答えは、データの中に見つけることができます。進行中の作業が多すぎたのかもしれないし、サポートの問題でチームが脇道にそれてしまい、予定していた作業から遠ざかってしまったのかもしれません。答えが何であれ、データを分析することで、開発チームはより意味のある回顧を行い、プロセスを調整して、同じ間違いが将来発生しないようにすることができます。

データ駆動型の DevOps は非常に強力です。これまでに、コミュニケーションとコラボレーションを改善することで文化を向上させる方法について説明してきましたが、データを活用することで、ビジネス価値の追跡と計画をより効果的に行うための能力を磨くことができる重要な方法をいくつか紹介してきました。次回は、データが組織のビジネス・アジリティ(安定性を維持するために適応することで変化に迅速に対応するビジネスの能力)をどのように向上させることができるかについてお話しします。


HCL Accelerate 2.1 のご紹介

2020/10/5 - 読み終える時間: 4 分

Introducing HCL Accelerate 2.1 の翻訳版です。


HCL Accelerate 2.1 のご紹介

2020年10月1日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

HCL Accelerate は、今、バリュー・ストリーム管理の未来を構築しています。HCL Accelerate 2.1 のリリースでは、この市場における当社の継続的な改善と最先端の機能の提供をご覧いただけます。お客様からのフィードバックと深い市場分析により、当社は、VSMの主要な価値領域に焦点を当て続けることができました。HCL Accelerate をお使いの場合にはアップグレードして、以下の最新機能を試してみてください。まだ HCL Accelerate を使用していない場合は、無料の Community Edition をここでチェックすることで、今すぐ HCL Accelerate を使い始められます。

データ駆動型インテリジェンスによるガバナンスの自動化

  • 自動化されたルールベースのゲート - セキュリティと品質データの統合を活用して、自動化されたルールベースのゲートで複数のアプリケーションを単一のパイプラインで管理します。自動プロモート機能を利用して、ハイブリッド集中型フルコントロール CI/CD システムでビルドをより低い環境にシームレスに移行できます。

  • オープンパイプライン - HCL Accelerate の特長は、パイプラインビューです。2.1 では、HCL Launch や Azure DevOps などの市場をリードするデプロイツールと接続する、真にオープンなパイプラインにより、ビルドから本番までの可視性がさらに向上しました。さらに、パイプラインビューのロード時間が 70% 速くなり、常に最新の作業状況を把握できるようになりました。

作業を可視化し、予測可能に

  • 新しいバリュー・ストリーム・メトリクス - ロード、スループット、およびディストリビューションの 3 つのメトリクスで、フローがどのように発生しているか、そして顧客に最も価値を提供するために最適な数値は何であるべきかを正確に確認できます。2.1 では、これらのメトリクスはダッシュボードで経時的な傾向を見るためにサポートされているだけでなく、バリュー・ストリームのメトリクス・バーを介して、チーム全体が素早くアクセスできます。

  • 強化されたレポート - 新しい「スプリントの状態」レポートでは、Velocity などのメトリクスを活用し、コントリビューターやポイントされたグラフとそうではないグラフなどの重要な情報を組み込むようになりました。また、2.1 の新機能として、ワンクリックでセキュリティ監査を実行し、HCL Accelerate のインスタンスで誰がどのような権限を持っているかを素早く確認できるようになりました。

  • 質問に答えられる表示 - バリューストリームを「お気に入り」にして、プロジェクトやチーム間の主要なメトリクスを素早く確認したり、比較したりすることができるようになりました。点や作業項目を確認し、DevOps クエリ言語 'issue.sprints.active=true' の拡張により、スプリントがどのように進行しているかを正確に視覚化します。

バリューを得るまでの時間が早い

  • HCL Software Factory (SoFy) で利用可能 - HCL Accelerate は、HCL Software Factory (SoFy) で利用可能になりました。SoFy は、Kubernetes 対応製品を Docker イメージや舵取り図としてカタログ化したもので、クラウドネイティブのレジストリでホストされています。SoFy がどのようにソリューションを合理化するかについての詳細は、こちらからお問い合わせください。

  • 複数のパフォーマンスと安定性の改善 - 私たちは、パフォーマンスと安定性を継続的に改善するよう努めています。今回のリリースサイクルも例外ではありません。技術的な詳細については、こちらの累積リリース情報をご覧ください。

小規模な機能強化

  • リリースオーケストレーションの改善 - リリース機能に様々な改善とバグ修正が行われました。これには、リリース参加者の表示の改善、情報の表示の改善、リリースロックの小さな強化が含まれます。

  • Jenkinsサーバー用の新しいプラグイン(プラグインバージョンv2.1.0) - HCL Accelerate v2.1.0では、Jenkinsサーバー用の新しい改良された v2.1.0 プラグインを使用する必要があります。

  • 複数の新しい HCL Accelerate プラグイン

    • ブラックダック
    • HCLコンパス
    • Azure DevOps
    • HCL Launch
    • まだまだ続く! Docker Hub をチェック
  • 既存のプラグインでより多くのデータを

    • プラグインのイメージバージョンがUIから明確に表示されるようになりました
    • Azure Devops プラグイン。マスター以外の別のブランチをコミットのために追跡できるようにする
    • SonarQube プラグイン。正しいビルドにリンクするメトリクスのアップロード
    • ServiceNow プラグイン。変更やインシデントと一緒に問題データを引き出す
    • Github プラグインのプロキシ対応
    • 壊れていたすべてのパーサープラグインの最新バージョンを修正し、すべてのドキュメントを更新しました。
  • 新しい Pipeline Designer ロール - この新しいロールは、パイプラインの編集を許可しながらも実行を禁止する権限を持っています。

  • ユーザーリストの改善 - 新しいシングルユーザーリストを使用して、LDAP、SSO、ローカルユーザーを表示できます。

これらの新機能は、10月8日(木)午後2時(EDT)に開催されるウェビナーでご確認ください。参加できない場合でも、サインアップしていただければ、録画を視聴できます。登録するにはここをクリックしてください。 画像の説明


HCL Accelerate 2.1 の新機能: 自動化されたルールベースのゲートを使用したパイプラインガバナンス

2020/10/1 - 読み終える時間: ~1 分

Pipeline Governance with Automated Rule Based Gates, new in HCL Accelerate 2.1 の翻訳版です。


HCL Accelerate 2.1 の新機能: 自動化されたルールベースのゲートを使用したパイプラインガバナンス

2020年9月30日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

バリューストリーム管理と聞くと、メトリクス、主要業績評価指標(KPI)、可視性を思い浮かべるかもしれませんが、HCL Accelerate は2.1 のリリースでそれをさらに向上させています。

2.0 では、ユーザーが手動でバージョンを承認または拒否することができる単一の場所を提供していましたが、エクスペリエンスを向上させることができることがわかっていました。そこで私たちは、DevOps データレイクとデータの深い複雑な関係を活用して、セキュリティルールと品質ルールを導入することで、ゲートを迅速に強化しました。

多くの開発チームにとってパイプラインは、CI/CD ツールがバラバラでプロセスが複雑なワイルドウェストであり、情報が失われる可能性のある領域を生み出しています。例えば、計画されていなかった Pull Request が、実際にはリリースの最終ビルドに含まれていたという状況があるかもしれません。その場合、この小さな変更が壊滅的な脆弱性をもたらしていた可能性があります。作業項目がなかったため、誰も変更が入るとは予想していなかったので、手遅れになる前に誰も戻ってセキュリティ脆弱性の結果をチェックしなかったのです。

これらは、私たちのほとんどが夜も眠れない原因となっています。さらに悪いのは、ツールでレポートをチェックしたり、他の部署に連絡したり、回答を待ったりするためにリリースを遅らせなければならない場合です。より速く、より良い品質を実現する唯一の方法は、プロセスを自動化することです。自動化されたルールベースのゲーティングでできることに飛び込んでみましょう。

画像の説明

まず最初に気づくのは、新しいルールが2.0の手動ルールをベースにしていることです。多くのお客様がBETAモードでこれを使用してきました。彼らは、すべてのツールを HCL Accelerate に接続していませんでしたが、手動ルールを使用して、どのツールが必要で、いつ接続できるかという目標を設定することから始めていました。アプリケーション・セキュリティ・スキャン・ツールを探しているのであれば、AppScan を強くお勧めします。

自動化されたルールは、コードカバレッジ、機能テスト、ユニットテスト、アプリケーションの脆弱性、コンテナの脆弱性、静的コード解析など、HCL Accelerate でおなじみのあらゆる種類のメトリクスをチェックすることができます。最も良い点は、これらが設定されると、バージョンに関連付けられたデータを完全に自動分析して実行するため、基準を満たさない限り、どのバージョンもこれらのゲートを通過しないことを信頼できるということです。しかし、心配しないでください - 私たちはすべてのコードを出荷しなければならなかったので、常に「確かですか?」という回避策がありますが、それは監査報告書にキャプチャされます。この機能は、実際には、チームが完全な自律性を持って顧客にできるだけ早くリリースできるようにするためのチェックとバランスを整えることです。 「自分はブロッカーが 0 であると言ったけど、あの時、自分は本当に正しいビルドを見ていたのか」などということを、徹夜して言い出すことがなくなります。

いつものように、質問があれば私や私のチームの誰にでも連絡してください。デモをお見せして、HCL Accelerate とバリュー・ストリーム・マネジメントがどのようにしてチームがタスクに集中することをやめ、より多くの価値を提供できるかをお見せしたいと思っています。


Accelerrate: データ駆動型 DevOps パート 2: データ駆動型の文化

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

data-driven-DevOps%e2%80%afpart-2-data-driven-culture の翻訳版です。


データ駆動型 DevOps パート 2: データ駆動型の文化

2020年9月29日

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

画像の説明

シリーズのパート1を読むにはここをクリックしてください。

堅固な文化は、どのような DevOps 組織にとっても非常に重要です。DevOps 文化の主要な特徴は、開発チームと運用チーム間のコラボレーションを強化し、サポートするアプリケーションの健全性と健全性に対する責任感を共有することです。これは、開発、IT/オペレーション、および「ビジネス」を横断する透明性、コミュニケーション、およびコラボレーションを高めることを意味します。職場内の文化的規範は、優先順位、コラボレーションの方法、問題解決のアプローチに関して意見の相違につながることがよくあります。特に最終的な目標や価値が誰にとっても明らかでない場合は、DevOps 文化は新しい働き方を採用するのに苦労することがあります。

このような文化の移行を容易にするにはどうすればよいのでしょうか?それはデータです。データは、チーム間の知識の公平性を提供することで最大の効果を発揮します。理想的には、優れたデータがあればあるほど、より良い知識を得ることができます。この新しい知識があれば、より効果的に仕事をし、より明確にコミュニケーションを取り、最終的には組織としての働き方を改善するために行動を起こすことができるようになります。つまり、データは、人々が互いに協力し、協力し合う方法を劇的に改善することができるのです。

カルチャーを改善したい場合、どのようなデータを調べればよいのでしょうか?手をつけるべき場所には事欠かないが、HCL Software DevOps での経験から、私たちは開発者、デザイナー、アーキテクトなど、個々の貢献者にとって最も馴染みのあるデータから始める傾向がある。これは通常、ソース・コントロール管理や、課題追跡やプロジェクト管理に関連するデータ(ソースの例としては、Atlassian、JIRA、Gitなどがあります)から来るデータです。

これらのツールから得られるデータからは、多くの分野の洞察が得られます。まず、コードをコミットし、コードの変更をビジネス価値のある特定の項目に関連付ける際に、チームメンバーが使用し、最もよく知っているプロセスを示します。これにより、日々の活動をよりよく理解し、改善点を見つけることができます。また、このデータを使用して、作業中のアプリケーションを特定したり、多くの場合、作業のタイプ(例えば、欠陥と機能)を特定することもできます。このデータは、特定のチーム全体の仕事の分布についての有用な洞察を引き出すために使用することができ、 チームがどのように連携して仕事をしているかを示すことができます。

個々の貢献者から得られるデータを調べることで、以下の7つの主要な分野で文化を改善することができます。

  • 誰が何に取り組んでいるか? 誰が何に取り組んでいるか? 誰がどのような作業をしているかを知ることは、優先順位に変更があった場合や要件が変更された場合に備えて、開発マネージャやチームの残りの部分を常に把握しておくのに役立ちます。

  • 何か重要なものが取り残されていないか? 進行中の作業を特定することができれば、そのリストをビジネスゴールや成果物のリストとクロスリファレンスすることができます。これにより、「やるべきことに取り組んでいるか」という質問に、より明確に答えられるようになり、時間通りに終わらないかもしれない項目を特定したり、優先順位をつけずに行われている作業を見つけることができます。

  • 誰が助けを必要としているのか? 遠隔地で働くスタッフが増えた今、手を挙げて助けを求めるのは難しい。多くの場合、最も優秀な従業員は、彼らの皿の上にあまりにも多くの仕事を抱えてしまうことになります。データを見ることで、仕事を完遂するのに苦労している貢献者を特定し、必要な助けを得ることができます。また、このデータは、時折行われる消防訓練で少し余力のある人を見つけるのにも役立ちます。

  • チームが日々の活動をどのように行うかを改善する。 どのプロセスにも改善の余地があります。より明確なデータがあれば、開発チームが使用しているシステムとどのように相互作用しているかを評価することができ、コードレビューからテストツール、バックログの項目のトリアージまで、ビジネス価値をより効率的に流すことができないボトルネックを明確にすることができます。

  • チームの速度を特定することで、計画を改善する。 進行中の作業を特定することで、どのような作業が完了したかを把握することができます。これにより、チームのベロシティを把握することができ、特定のスプリントやリリースに何をコミットできるかを容易に把握することができます。

  • スプリント/リリースのスコープがより良くなります。 リリースやスプリントに何をコミットできるかを知ることで、チーム全体がより個人的に責任を持ち、達成された仕事に「納得」するようになります。チームは、短い時間枠の中で過剰な成果を求められていると感じることが少なくなります。

  • 予定外の仕事を識別する。 計画外の作業は、時間通りに納品されないビジネス価値の最大のサイレントキラーです。チームがどのような開発努力をしているかを分析することで、そのデータを見て、計画的な作業と計画外の作業のどちらが多いかを判断し、計画外の作業の影響を最小限に抑えるための是正措置を取ることができます。

これらの分野に共通しているのは、開発チーム全体のコラボレーションとコミュニケーションの改善に焦点を当てていることです。個々の貢献者が自分に何が期待されているのかを知り、目標が明確に定義されている場合、貢献者はより積極的に参加し、日々の活動に価値を見出し、成功する可能性が高くなることがわかります。

データは非常に個人レベルでも支援する能力を持っています。DevOps Institute の 2020 Upskilling: Enterprise DevOps Skills Report の調査結果によると、DevOps 人材の採用を検討している企業では、新規採用の要件として「ヒューマンスキル」が上位にランクインしています。上位に挙げられたヒューマンスキルの1位は何だったのでしょうか?コラボレーションと協調性、次いで共有と知識の伝達、そして適応性、共感性。これらのヒューマンスキルはすべて、DevOps 文化がデータを受け入れることで成長させることができます。

DevOps Institute のレポートから得られた重要な調査結果の1つは、雇用主が「E字型」のスキルセットを持つ潜在的な候補者を見つけたいと考えていることでした。I字型、T字型、E字型のスキルセットについてよく知らない方は、下の図をご覧ください。I型スキルセットはスペシャリストです。彼らの知識は、一つのテーマについて非常に深いものです。T型のプロファイルは、特定の領域の専門家でありながら、ビジネス全体に関する幅広い一般的な知識を持っています。このため、機能横断的なチームとの連携を得意とし、より広い戦略をまとめる上で優位に立つことができます。E型スキルセットは、さらに一歩進んだものです。このような人材は、プロセスやフレームワークのスキルの専門知識だけでなく、幅広いヒューマンスキルを持っており、自動化の経験、新しいアイデアを探求する能力、高いレベルで実行する能力を備えています。

画像の説明

出典: DevOps インスティテュート

データは、個人が通常の役割以外の仕事に触れることで、「T字型」のスキルセットがより「E字型」の未来へと成長するのを支援する上で重要な役割を果たすことができる。このような経験は、共感を生み出し、積極的な DevOps 文化に不可欠な責任感を共有する感覚を高めるのに役立ちます。自分のコントロール外に存在する課題を他者が理解できるようにすることで、組織が真の意味で DevOps を受け入れるために必要な健全な対話を始めることができます。

データは DevOps に変革的なメリットをもたらす可能性があります。次回は、データがどのようにして組織がより効果的に作業を追跡し、計画を立てるのに役立つかについて説明します。最後までお読みいただきありがとうございました。


Accelerrate: データ駆動型 DevOps パート 1: 序章

2020/9/29 - 読み終える時間: ~1 分

Data-Driven DevOps Part 1: An Introduction の翻訳版です。


データ駆動型 DevOps パート 1: 序章

2020年9月28日

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

画像の説明

ソフトウェア開発の専門家が DevOps について議論するとき、多くの場合、人、プロセス、テクノロジーを中心とした3つの主要な会話が形成されます。これら3つのコンセプトは、DevOps の核心を語るものです。

人」のトピックは、コラボレーションと責任の共有をサポートする健全な文化を構築することに焦点を当てています。プロセスについて議論する場合、会話は特定のワークフローをいかに効率的にできるかに傾く傾向があります。DevOpsのテクノロジーの側面は、ソフトウェア開発における近代化、セキュリティの脆弱性、品質保証、自動化、その他多くの要因に至るまで、常に変化し続ける会話です。私たちは、何がうまくいき、何がうまくいかないかを判断するために、このような会話をしています。私たちは、これらの会話を DevOps が生み出す貴重なフィードバックサイクルの一部として受け入れ、日々の責任を改善する方法を学べます。

すでに DevOps の旅を始めている組織にとって、このような会話は日常生活の一部となっています。振り返りから計画会議まで、1週間を通していくつかの会議が行われますが、これらはすべて、組織全体がこれまでの行動から学び、より良い計画立案の支援に焦点を当てています。これらの会議は、組織のさまざまな部分がそれぞれの意図を共有し、より効果的に協力し、高品質のソフトウェアをリリースするために必要なすべての可動部分をよりよく理解するための素晴らしい方法です。この種の会議の欠点は、主に個人的な経験に基づいていることです。会話に参加している人は皆、自分の視点、自分の主張を示すためのデータ、そして(おそらく最も重要なのは)自分の感情を持ってきます。このため、全員の意見を一致させ、同じ目標に向かう努力は非常に困難です。それはまた構成のある部分にグループの残りの部分より競争の優先順位があれば職場内の分裂を作成できます。

バリューストリームマネジメント (VSM) は、このような継続的な議論から生じる多くの課題を解決できる DevOps のプラクティスとして位置づけられています。VSM の基本的な概念の中で、組織は、機能を市場に投入するために必要なアイデアから納品までのすべてのステップをよりよく理解できます。VSM は、組織のプロセスをマッピングするというコンセプトに基づいています。これには、貢献しているすべての主要なビジネスユニット(設計、開発、製品管理、リリースエンジニア、品質保証、セキュリティなど)と協力して、現在のビジネスがどのように運営されているかを正直に表現し、改善すべき領域を見つけることを目的としています。マッピングはプロセス全体を全体的に見るための素晴らしい方法ですが、ひとつの重要な要素が欠けています。

画像の説明

バリューストリームから生み出されるデータを収集・分析することで、あらゆるチームが直面する古くからの疑問の謎を解き明かす鍵を握っています。どこを改善できるのか?何がうまくいっているのか?何がうまくいっていないのか?データ自体は懐中電灯のような役割を果たし、組織が実際にどのように日々運営されているのか、有用な洞察を照らし出せます。これは、我々はプロアクティブに反応していることから会話をシフトすることができることを意味します。 反応的な会話は、ほとんどの場合、問題を理解し、何が問題を引き起こしたのかを理解し、最終的に問題の解決策を議論することに費やされます。プロアクティブな会話は、グループがリアルタイムで何が起こっているかを見ることができるときに行われます。リアルタイムのデータは、問題を予測し、痛みが現実になる前に解決策を実行に移すことを可能にします。データに基づいた会話をすることで、問題がどこにあるのか、より重要なのはなぜ問題なのかを関係者全員が明確にできるため、問題解決をより迅速に行うことができます。

画像の説明

HCL AccelerateのSwim Lanes ビューでは、チームの仕事の全体像を把握できます。

このブログシリーズでは、データが組織内で果たす重要な役割について見ていきます。特にコアとなる「影響を与える領域」と、データがどのようにDevOpsの主要な会話に影響を与えることができるかに焦点を当ててみたいと思います。

  • : データを通じたDevOpsの人間化
  • プロセス: データを使ったトラッキングとプランニング
  • テクノロジー: データ主導のビジネス・アジリティ

データに基づいて DevOps イニシアチブを推進することは、最終的には、個々の貢献者の努力がビジネス目標と明確に一致するような、より共感性の高い DevOps 組織を育てることにつながり、プロダクト・マネージャーは、何がデリバリーのために計画されているのか、何がリスクであり、何を残す必要があるのかを利害関係者や顧客に簡単に伝えることができるようになります。データを DevOps の目標の最前線に持ってくることで、組織全体として、リスク、コスト、収益をより良く管理することができるようになります。 データ駆動型の DevOps とバリュー・ストリーム管理が、組織におけるDevOpsの話を変え、効果的な変化を実感できるようにするために役立つ多くの方法を、今後数週間にわたってご紹介していきます。


このブログについて

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。