2020/12/5 - 読み終える時間: 3 分

Your VSM questions, answered by experts の翻訳版です。

VSM に関するご質問に専門家がお答えします

2020年12月1日

著者: Allan Wagner / HCL Software Transformation Architect

バリューストリーム管理は、DevOps のホットなトピックであり、すぐになくなるわけではありません。実際、VSM の人気と使用率は来年にかけて高まると予想されています。つまり、競合他社の一歩先を行くためには、VSM に精通し、VSM が提供するメリットを活用する必要があるということです。しかし、バリュー・ストリーム・マネジメントに関するカンファレンス、ウェビナー、eBook、ブログなどが数多くある中で、このトピックに関する情報の山をふるいにかけるのは大変なことです。そこで先日、バリュー・ストリーム管理に関する質問に答えるためのウェビナーを開催しました。

今回のウェビナーでは、VSM の開始、利害関係者への説得、VSM のベストプラクティスの活用などについて、多くの質問をいただきました。バリュー・ストリーム管理の専門家であるスティーブ・ブーン、アル・ワグナー、スティーブ・ペレイラは、1時間に及ぶウェビナーで可能な限り多くの質問に答えましたが、すべての質問に答えることはできませんでした。録画されたウェビナーはこちらからご覧いただけます。残りの質問への回答はこちらをご覧ください。

Q: DevOps トランスフォーメーションのために VSM を実行するためのガイドやベストプラクティスはありますか？

世の中にはたくさんのガイドがありますが、私たちの VSM エキスパートの意見では、以下のようなものがベストです。

• How DevOps Leads the Way to Digital Business Transformation by DevOps.com
• Data-Driven DevOps by Steve Boone
• Value Stream Management Essentials by DZone
• Visible Thinking from Visible Value Stream Consulting

Q: プロジェクトチーム用の VSM を作っています。ユーザーストーリーをバッチサイズとして考えてもいいですか？

バリューストリーム管理のボトルネックの1つは、パイプラインのステージをバッチでロードすることです。私は、スプリント計画を構築し、リリースで導入するストーリーや機能を特定し、フローを最適化することに焦点を当てて作業を次のステージに滞りなく引き込むことで、開発から本番リリースまでのシームレスな作業の流れを作ることを提案したいと思います。バッチングとは対照的に、プルアプローチでは、特定の段階で処理できる以上の作業をチームに押し付けることがないため、人為的なボトルネックの発生を避けることができます。

Q: VSM は、トップダウンで「幹部レベルの完全なバイイン」を得た場合に最も成功すると聞いたことがありますが、現時点ではそれができず、これ以上待つ余裕はありません。経営陣が実際の問題に気づいていないか、実際の問題を掘り下げようとしていないように見える場合に、現場の作業員（開発者）がボトムアップで指揮を執ることは可能でしょうか？

トップダウンのアプローチが最善であるが、多くの DevOps の変革は草の根レベルから始まる。チームは改善を必要とする何かを特定し、変更を実施します。しかし、その規模のイニシアチブを組織全体に拡大するのは難しいでしょう。では、どのようにして彼らの注意を引くのでしょうか？私達はビジネスの利害関係者にとって重要である事を理解することを提案する。それはコストを下げることなのか、新機能を迅速に市場に投入して競合他社を混乱させることなのか、それとも品質レベルを向上させることなのか。次に現在の状態を理解し、それに対して測定するためのベンチマークを作成することです。そして最後に、上述したように、その改善が事業目標にプラスに貢献するような課題を特定し、変更を実施して実験することです。しかし、必ず測定してください。経営陣の賛同を得たいのであれば、ビジネスの成果という観点から正当性を示す必要があります。"ねえ、ボス！」と言ってください。私たちはこれを行い、XYZ のコストを 20% 削減しました。改善のためにもっと多くのことをしたいと思っていますが、あなたのサポートを頼りにしてもいいですか？

Q: フューチャーステート VSM のベストプラクティスへの提案があれば教えてください。

VSM は非常に新しく進化している分野であり、将来的に何が起こるかを予測することは困難です。また、今の DevOps の世界の変化の速度を考えると、何がすぐそこにあるかはわかりません。私が提案したいのは、来るかもしれないものを受け入れ、組織にとって意味のあるものを受け入れることです。 VSM の実践は、より多くの組織が VSM の列車に乗るようになるにつれて、進化し続けていくだろう。

Q: どのようにすれば OKR と VSM を使って相乗効果を得ることができますか？

ご存知ない方のために説明すると、OKR とは、フレームワークの一部として定義され、見直された「目的と重要な結果」のことです。すべての VSM ベンダーのことを言えるわけではありませんが、HCLのバリュー・ストリーム管理ソリューションである HCL Accelerate は、複数のソースからデータを収集する機能を提供し、そのデータを組織の目的や重要な指標に沿ったダッシュボードやレポートなど、さまざまな形で提示します。HCL Accelerate はまた、トレンドも表示するので、組織は、測定値が正しい方向に向かっているかどうか、あるいは何らかのアクションを取るべきかどうかを確認することができます。このように、両者は本質的には似ていますが、完全に同じではないかもしれません。

Q: アジャイルの世界に移行しようとしている会社に参加する際に、既存の製品の価値の流れをどのように識別するのでしょうか？

ソフトウェアを含むあらゆる製品の製造には、その製品を製造するために取られるステップのパイプラインがあります。ある程度のレベルの計画、設計、開発、品質チェックが行われ、最終的には消費者へのリリースが行われます。そして、実践された方法論に関わらず、価値の流れは存在します。さて、何かがアイデアから実装に至るまでにどのくらいの時間がかかるのかを理解するために、価値の流れにまたがって、実行されたすべてのプロセスステップと作成された成果物を理解するために、我々は価値の流れのマッピングの練習を提案するだろう。現状を理解した上で、各プロセスのステップや成果物を見て、それが価値を提供しているかどうかに挑戦していきます。価値がない場合は、なぜ何かが行われているのかを疑問に思わなければならず、流れからそれを除去することを検討しなければならない。

Q: VSM の研修会に利害関係者をどのようにして参加させればよいでしょうか。

利害関係者は現在のプロセスを知り、変更を実現させてもいいものであるので VSM の研修会にキーである。彼らやワークショップに参加している人を巻き込むためには、意見を共有し、現在のプロセスに挑戦し、自由に発言できる安全な環境を提供することが重要です。その人がその分野の専門家であれば、その人の意見を求める。物事が実際にどのように機能しているのかを共有してもらいましょう。しかし、彼らが改善に向けて努力する気がない場合や、ワークショップに興味がない場合は、そのような人と入れ替わる必要があります。

Q: HCL Accelerateは、他のソースの GIT REPO（GitLab、BitBucket、GitHub）や JIRA や ARCAD のようなツールから VSM のメトリクスを利用することができますか？どのような形式で HCL Accelerate に持ち込むことができますか？

HCL Accelerate は、多くのソリューションとの統合を提供しており、バリュー・ストリーム内でのプレゼンテーションやレポート内のデータ・ポイントとしてデータを取り込むことができます。各ソースはデータ形式が異なるため、HCL Accelerate はソースのデータモデルを見て、リポジトリにインポートするためにそれを正規化することができます。これがHCL Accelerate の強みです。複数のソースからのデータ形式を理解する能力に続いて、そのデータを意味のある方法で提示する能力があるため、組織は単一のビューでデータに基づいて意思決定を行うことができます。また、統合が容易に利用できない場合は、当社にお知らせください。当社の開発チームは、他の DevOps ツールとの新しい統合を常に提供しています。今、待てない場合は、HCL Accelerate の API を使用することで、組織はコマンドを実行することで HCL のリポジトリにデータをインポートすることができます。

下の HCL Accelerate のプラグインライブラリのスクリーンショットをチェックして、どのような統合がすぐに利用できるかを確認してください。

学習を続けたいですか？ここをクリックして、録画された「Ask the VSM Experts」ウェビナーをチェックしてください。また、1対1の DevOps アドバイスをご希望の方は、ここをクリックして無料コンサルテーションをリクエストしてください。

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

New Interactive Demo of HCL Accelerate の翻訳版です。

HCL Accelerate の新しいインタラクティブ・デモ

2020年10月22日

著者: Elise Yahner / HCL

これまで私たちは、バリュー・ストリーム管理ツールである HCL Accelerate についてよく話してきました。私たちはこのツールを本当に誇りに思っており、チームのプロセスと文化を改善するのに役立つと信じています。しかし、実際に HCL Accelerate を見るまでは、それがどのように機能するかを正確に想像するのは難しいです。仕事が忙しくなり、時間に追われているときに、ソフトウェアのデモをスケジューリングすることは、誰もがやるべきことリストの一番下に落ちてしまいます。そこで、オンデマンドでインタラクティブな HCL Accelerate デモを作成しました。

accelerate.hcltechsw.com にアクセスして、ご自身で HCL Accelerate の機能と機能を探索してみてください。タブと赤い点をクリックして、HCL Accelerate がなぜ機能するのか、この VSM (Value Stream Management) ツールの特長は何か、そして誰が恩恵を受けることができるのかをご覧ください。このインタラクティブなデモは、HCL Accelerate がチームに役立つかどうかを確認したい場合に最適です。次に、完全な1対1のデモを受ける準備ができたら、ページの一番下までスクロールして、デモをリクエストしてください。

HCL Software DevOps で HCL Accelerate は何ができるかをご覧になれば、それが組織にどのような利益をもたらすかを理解していただけるかと思います。今すぐ accelerate.hcltechsw.com にアクセスして、ご自身の目でお確かめてください。

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

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

HCL Accelerate: Windows と Docker-Compose と組み合わせてクイックスタート

2020年10月20日

著者: Daniel Trowbridge / Technical Lead

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

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

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

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

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

最新バージョン

2. インストーラの実行

インストーラをダブルクリックして実行します。以下に示すように、設定値の入力を求められます。

• アクセスキー。アクセスキー: 製品版に応じたアクセスキーを入力してください。
• ライセンス。ライセンス: ライセンスの承認が必要です。ライセンス: ライセンスの受諾が必要です。ライセンスを読んだ後に再度プロンプトが表示されたくない場合は、 インストーラーに -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. 次のステップ

チュートリアルとブログ: https://blog.hcltechsw.com/accelerate/

動画: https://www.youtube.com/playlist?list=PL2tETTrnR4wviGuleB2xwSR7-P7m-rzTa

ナレッジセンター

• 管理業務

  • 概要
  • 統合の設定
  • LDAPでユーザーを設定する
  • インストーラとSSL証明書

• バリューストリームマネジメント

  • バリューストリーム
  • 洞察力
  • メトリクス

• その他

  • リリース
  • パイプライン
  • 用語解説

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

• Accelerate: データ駆動型 DevOps パート 1: 序章
• Accelerate: データ駆動型 DevOps パート 2: データ駆動型の文化
• Accelerate: データ駆動型 DevOps パート 3: データを使った追跡と計画
• Accelerate: データ駆動型 DevOps パート 4: ビジネス・アジリティ
• データ駆動型 DevOps eBookですべてを手に入れよう

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

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

ビジネスの整合性

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

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

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

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

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

無計画な仕事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 次のステップ

• チュートリアルとブログ: https://blog.hcltechsw.com/accelerate/
• 動画： https://www.youtube.com/playlist?list=PL2tETTrnR4wviGuleB2xwSR7-P7m-rzTa

ナレッジセンター

• 管理
  • 概要
  • 統合の設定
  • LDAP でユーザーを設定する
  • インストーラと SSL 証明書
• バリューストリームマネジメント
  • バリューストリーム
  • 洞察力
  • メトリクス
• その他
  • リリース
  • パイプライン
  • 用語解説

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

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

シリーズの過去のパート

• Accelerate: データ駆動型 DevOps パート 1: 序章
• Accelerate: データ駆動型 DevOps パート 2: データ駆動型の文化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リスクの特定

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

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

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

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）に開催されるウェビナーでご確認ください。参加できない場合でも、サインアップしていただければ、録画を視聴できます。登録するにはここをクリックしてください。