2021/7/23 - 読み終える時間: ~1 分

Who is Value Stream Management for? の翻訳版です。

バリューストリームマネジメントは誰のためのものか？

2021年7月22日

著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps

バリューストリームマネジメントは決して新しい概念ではありません。リーン生産方式の分野では何十年も前から存在しており、ソフトウェア・デリバリーの分野でもしばらく前から徐々に浸透してきています。今までと違うのは、組織がCI/CDやテスト自動化の基礎など、多くの「Day 1」の問題を解決し、次の問題を探していることです。DevOpsの "Day2 "のステージは、バリューストリームマネジメントです。

VSMは、「DevOpsをより良くするにはどうすればよいか」という問いに答えるものです。VSM ツールは、DevOps パイプライン上のバラバラのツールに格納されているデータを接続し、サイロではなくツールチェーン全体で最適化を図ることができます。適切なプラットフォーム があれば、バリューストリームマネジメントは、データをダッシュボードに集約するだけではありません。VSMは、すべての機能や職務レベルでのコミュニケーション、意思決定、リソースの割り当て、文化の変化をサポートします。

このインタラクティブなガイド では、開発、品質、ビジネスの各分野における個々の貢献者、マネージャー、エグゼクティブに価値観の流れがどのように影響するかを具体的に説明しています。ページをスクロールしたり、クリックしたりして、VSMが様々な役割の特定のペインポイントをどのように解決するかを見ることができます。例えば、開発マネージャーは、リソースの割り当てや作業の配分を戦略的に行うことに苦労しているかもしれません。価値観の流れを管理することで、開発マネージャーは、チームのすべての開発活動の「誰が」「何を」「いつ」「どこで」を把握することができ、十分な情報に基づいた意思決定を行い、適切な優先順位で適切な作業に集中することができます。このバリュー・ストリーム・マネジメント・ガイド では、開発者からCTOまでのすべての人を対象に、VSM が実際にどのようなものであるかを示す例とともに、問題点や解決策についての詳細な情報を提供しています。

バリューストリームマネジメントは誰のためにあるのか」ガイドでは、職務レベルや分野別に役割を選択して、VSMの影響を探ることができます。

私たちは、DevOps におけるバリュー・ストリーム・マネジメントの革命の始まりにいます。この方法論を早く活用すればするほど、競合他社に先んじて、より優れた安全なソフトウェアをより早くリリースすることが可能になります。HCL Accelerate の無料セルフサービスの Community Edition は、hclsw.co/getaccelerate で今すぐ始めることができます。

2021/7/22 - 読み終える時間: 3 分

HCL Software DevOps is Cloud Native の翻訳版です。

HCL Software の DevOps はクラウドネイティブ

2021年7月20日

著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps

5年前、HCL Software チームは、当社のソフトウェア製品がダイナミックなパブリッククラウド、プライベートクラウド、ハイブリッドクラウドに数分でデプロイされる未来を想像していました。今、私たちは HCL SoFy と HCL Now の立ち上げにより、その時点に到達しました。HCL Software DevOps グループは、このクラウドネイティブな変革の一翼を担えることに興奮しています。私たちのお客様にとってのハイライトは以下の通りです。

• 当社のバリュー・ストリーム・マネジメント、自動テスト、変更管理、および継続的デリバリー・ソリューションが、最新のクラウド標準をサポートするようになりました。
• 2,000以上の REST API エンドポイントにより、開発者はミッションクリティカルな企業システムの拡張、統合、カスタマイズを容易に行えます。
• クラウドで提供される DevOps ソフトウェアのデモやトライアルを、購入前にセルフサービスで試せます。

最後の点は、当社の DevOps ソリューションを実際に体験して、既存の DevOps パイプラインとの連携を確認したい場合に特に有効です。HCL SoFy を使用すると、HCL Software のお客様とパートナーは、HCL Accelerate、HCL Launch、HCL Compass、または HCL OneTest のトライアルを数秒で入手できます。以下のステップに従うだけです。

• hclsofy.com にアクセスし、Request Access をクリックします。リクエストが承認されると、SoFy のログイン情報が記載された確認メールが送られてきます。
• SoFy にログインして、カタログを見ながら試したいソフトを選びます。オンラインショッピングのような感覚で、すべて無料でご利用いただけます。
• サンドボックスやローカルにデプロイできるソリューションを即座に構築するために、好きなだけ製品を追加して「作成」をクリックします。作成した SoFy ソリューションは最大30日間有効です。

HCL Software のお客様やパートナー様でなくても、SoFy へのアクセスは可能です。まずはこちらからデモをご依頼ください。

SoFy サンドボックスにソリューションを導入すると、事前に入力されたデータが得られるので、自分でデータを入力しなくてもソリューションを遊ぶことができ、ソフトウェアの体験にすぐに飛び込めます。現在、HCL Software DevOps ソリューションの SoFy には以下のデモが存在します。

• HCL Accelerate

  • Value Stream Bottleneck Detection (バリューストリームボトルネック検出)
  • 自分のエピックはどこにある?
  • コードはどこにある?
  • KPIs: ワークアイテム、デプロイ、テストの洞察

• HCL Launch

  • Storefront のサインインの変更

• HCL OneTest

  • UI、API、パフォーマンステストのためのストアフロント変更のテスト

• HCL Compass

  • 不具合管理システム
  • SAFe を使用した HCL Commerce 開発チーム

また、ソリューションをローカルにダウンロードして、ご自身のデータで当社のDevOpsソフトウェアをお試しいただくことも可能です。さらに、1対1のサポートをご希望の場合は、いつでも対応いたします。当社のDevOpsエキスパートチームは、ベストプラクティスを説明し、お客様のユニークな組織をサポートする戦略を立てるのが得意です。

クラウドネイティブなソリューションに対して、よりマネージドなアプローチをご希望ですか？HCL Nowはクラウド・ネイティブ・アズ・ア・サービスのソリューションで、お客様が選択したパブリック・クラウド上に専用のセキュアな環境を展開し、管理します。HCL Now は、最新バージョンの HCL Software DevOps ソリューションと、専任のエキスパートによる管理を、クラウドの柔軟性、拡張性、利便性とともに提供します。

当社のすべての DevOps ソリューションは、HCL Now でオンデマンドで利用できますが、HCL Now での HCL OneTest Performance は、テストを簡単にしたい HCL Commerce ユーザーにとって特に便利です。このセットアップでは、インフラストラクチャー管理、製品のアップグレードとサポート、セキュリティとプライバシーコントロールのメンテナンスを含むターンキーテストソリューションを提供します。つまり、新しいインフラに投資することなく、実際のピーク時の負荷を簡単にテストすることで、より早く開始し、コストを抑えることができるのです。

今こそ、DevOps の旅をクラウドで実現する時です。9月16日午後12時（米国東部時間）に開催されるウェビナー に参加して、HCL Now が選択したクラウド・ネイティブ・プラットフォーム上で、当社の DevOps ソリューションの可能性を最大限に引き出す方法を学んでください。HCL Now は、お客様が選択したクラウド・ネイティブ・プラットフォーム上で、HCL Software のDevOps ソリューションの可能性を最大限に引き出します。登録はこちら から。

最後にもう一度。HCL Software の DevOps はクラウドネイティブです。

2021/7/22 - 読み終える時間: 2 分

Becoming a High Performing Organization with an Engineering-First Mindset - HCL SW Blogs の翻訳版です。

エンジニアリング・ファーストの考え方で高いパフォーマンスを発揮する組織へ

2021年7月22日

著者: HCL Software / A division of HCL Technologies (HCL)

HCL Accelerate: 「必要性を感じる、スピードの必要性を」("I feel the need - the need for speed.")

1986年の『トップガン』でトム・クルーズが演じたピート・"マーベリック"・ミッチェルの言葉は、当時の戦闘機パイロットやレースカーのドライバーにとって真実味を帯びたものでした。2021年のソフトウェア製品開発の世界でも、この言葉は真実であり、組織は現在よりも何倍もの速さで作業を進める必要性を感じています。ソフトウェアを迅速に、確実に、安全に提供することは、テクノロジーの変革と組織のパフォーマンスの中核をなすものです。

今日、高い業績を上げている組織は、DevOps を早期に導入しています。Google 社が発表した State of DevOps 2019 レポートでも紹介されているように、業界で最も高い業績を上げている人の割合は 3倍になり、現在では全チームの 20％を占めています。これは、優れた成果を上げることが可能であることを示しており、重要な能力を実行した者はその効果を実感しています。このホワイトペーパー は、HCL Software のデジタル・アナリティクス部門で Engineering Uplift Initiatives Lead を務める Ashita Dhir が、Google の DevOps Research program (DORA) から得られた主要な構成要素を紹介しており、スピードを上げてリターンを実現するためのギアを特定するのに役立ちます。DORA は、組織の現在のパフォーマンスや成熟度を測る作業を4つの主要な測定基準によって簡素化する広範な研究プログラムです。この 4つの指標は、ビジネスのアジリティ、クオリティ、レジリエンスに関する組織のパフォーマンスを測定します。ホワイトペーパー をダウンロードすると、DORA メトリクスを使用して、生産性を向上させる可能性のあるレバーやギアを特定し、各エンジニアリング向上イニシアチブに対する潜在的な ROI を見積もる方法を紹介したガイドとして使用できます。

エリートパフォーマーは、優れたソフトウェアデリバリーやオンデマンドデプロイメントから最大の利益を得ており、1日のうちで最も付加価値のある時間を過ごし、付加価値のない仕事に費やす時間はすべてのグループの中で最も少ない。

ハイパフォーマーは、1週間に何度もコードをデプロイし、障害が発生しても数時間以内に対処しています。安定性とスループットの面でも優れていますが、エリートと肩を並べるためにはさらに改善を続けなければなりません。DORA が発表した State of DevOps Report 2019 によると、金融サービスや政府機関などの規制が厳しい業界を含め、あらゆる種類と規模の組織が高いレベルのパフォーマンスを達成できるとしています。

中程度のパフォーマーは、スピードの点でハイパフォーマーの後塵を拝しています。これらの企業は、付加価値のないプロセスを排除することによる自動化や、「依存関係の親和性」に基づく組織の再設計から最大限の利益を得られます。これは、依存関係が企業規模でスピードを達成するための主要なキラーであるためです。バリューストリームマネジメント や WIP リミットなどのリーンの原則やプラクティスは、「付加価値のない」作業を特定することで、ソフトウェアデリバリーや組織のパフォーマンスを向上させます。

IT パフォーマンスが低い企業は、伝統的な運営をしていたり、複雑なレガシーシステムを抱えていたり、あるいは DevOps への取り組みを始めたばかりだったりします。これらの企業には、人材、プロセス、技術のすべての分野でチャンスがあります。技術的負債を削減し、コストよりもスピードと価値を最適化することに集中してください。

HCL Software がさまざまな業界のお客様に実施した DORA アセスメントでは、パフォーマンスが低～中程度の組織でも、エンジニアリング・プラクティス、クラウドの採用、組織的なプラクティス（変更承認プロセスを含む）、リーン・プラクティス、カルチャーの継続的な改善を推進することで、望ましいスピードを達成できるという、証拠に基づくガイダンスが示されています。今後の道筋を簡単に説明すると、次のようになります。まずは基礎から始め、独自の制約条件を特定して取り組むことで、継続的な改善マインドセットを採用します。制約がなくなったら、そのプロセスを繰り返すのです。

ホワイトペーパー Becoming a High Performing Organization with an Engineering-First Mindset のダウンロードはこちらから。

2021/5月/19 - 読み終える時間: 6 分

A "day in the life" with HCL Software DevOps の翻訳版です。

HCL Software DevOps: "Day in the Life" のデモ

2021年5月18日

著者: Allan Wagner / HCL Software Transformation Architect

HCL Software DevOps は、あらゆる組織の DevOps ニーズを満たす統合ソリューションを提供しています。証拠が必要ですか？Emerald と呼ぶ架空のeコマース企業を使った例を見てみましょう。

エメラルドのメモリアルデーのビッグセールが数週間後に迫っています。この年に一度のセールイベントは、エメラルドの会計年度の中で2番目に大きな収益源であるため、サイトのすべてが完璧に機能していることが非常に重要です。残念ながら、エメラルドのサイトを訪れた人から、新規顧客として登録する方法がわからない、エメラルドのアプリケーションへのサインインに問題があるという報告がありました。製品チームはこの問題を修正し、Emerald がメモリアルデーのセールに間に合うように、できるだけ早く変更を本番に移さなければなりません。幸いなことに、Emerald は以下のような HCL Software DevOps ソリューションを使用しています。

• 計画のための HCL Compass
• バリュー・ストリーム・マネジメントのための HCL Accelerate
• デプロイメント・オートメーションのための HCL Launch
• テスト自動化のための HCL OneTest

これらのソリューションはすべて、HCLソフトウェアのクラウドネイティブソリューションである HCL SoFy に導入されており、Kubernetesを簡単に利用することができます。ユーザーは、HCL SoFyのカタログから使いたい製品を選び、「デプロイ」ボタンをクリックするだけ。数分後には、ユーザーは仕事に必要なソリューションを手に入れることができます。

Emerald社のプロジェクトマネージャーであるPaula氏は、HCL Compassでの作業中に、優先度の高い不具合が提出されたことに気付き、修復を開始するための計画フィールドを完成させました。その際、彼女はチーム、オーナー、そして履歴に基づいて適切と思われるストーリーポイントの数を特定します。また、ビジネス上の重要性を考慮して、サービスクラスを「迅速」に設定します。さらに、その修正が含まれるべきリリースとスプリントを選択し、バックログの状態に移行します。

次に、EmeraldのアナリストであるAlは、このワークアイテムをレビューし、開発者に追加情報を提供する。Alは、HCL Compassでバックログのすべてのワークアイテムを検索して、この最新のワークアイテムを見つけます。項目を開いて「計画」セクションを展開すると、AlはPaulaがこれを「迅速」とフラグを立て、アクティブなスプリントでの納品を予定していることがわかります。問題を完全に理解するために、Alはまず本番のEmeraldアプリケーションを調査し、ウェブサイトの訪問者がなぜ混乱しているかを確認します。彼は、HCL Compassで欠陥の説明を更新し、ワークアイテムを「分析済み」の状態にします。

エメラルドの開発者であるダイアンは、このスプリントですでにいくつかの仕事を割り当てられていますが、現在はいくつかの依存タスクが完了するのを待っています。帯域幅に余裕があるので、彼女はHCL Compassにログインして、作業状態に引き込める優先度の高いワークアイテムがないかチェックします。そこで彼女は、「迅速」とマークされた欠陥を見つけ、その作業項目のオーナーシップを受け入れ、修正作業を開始しました。

LindaはEmeraldの開発チームのリーダーです。彼女の一日は、この新しい欠陥を知らせるメールやメッセージが飛び交う中で始まり、その修正を製品に反映させることがいかに重要であるかを強調しています。このストレスに加えて、リンダはすでに自分のチームがキャパシティに達していることを懸念しており、根本的な原因やこのキャパシティの問題に対処する方法の答えを持っていません。HCL Accelerate では、Linda はバリューストリームのダッシュボードを見て、本番インシデントの概要を確認し、HCL Accelerate が Emerald Commerce Storefront バリューストリームの作業段階でボトルネックを特定したことに気づきます。バリューストリームを掘り下げると、Linda はボトルネックにカーソルを合わせ、それがフローの不均衡の結果であること、つまり「作業」段階に入る作業が出る作業よりも多いことを確認します。HCL Accelerateは、AI機能を使用してボトルネックを特定し、Accelerateのリポジトリに保存されているデータにアルゴリズムを適用することで、チームがスロースポットを特定するのを支援し、根本原因の詳細を提供して改善を加速させることができます。リンダは、チームの準備が整う前に作業を段階的に進めると、潜在的にチームの認知能力を超えてしまい、人為的でありながら回避可能なバリューストリームのボトルネックが発生することを知っています。リンダはまた、HCL Accelerate が「作業」ステージの「進行中の作業」制限を超えていることを強調していることに気づきます。彼女は、ワークアイテムのリストを確認し、過去24時間に2つの追加があることを確認します。ワークアイテムIDを素早く検索することで、Lindaは2つのワークアイテムを簡単に分離して確認することができます。また、スプリントごとにワークアイテムをフィルタリングすることで、アクティブなスプリントに関連する作業のみが実際に作業段階にあることを確認できます。必要なデータを手に入れたリンダは、次のスタンドアップミーティングで、作業をパイプラインステージに押し込んだり、引き込んだりするとフローが乱れることについて話し合うことにしました。

このデイリースタンドアップミーティングで、リンダは HCL Accelerate のスイムレーンビューを所有者別にフィルタリングした画面を共有しました。各チームメンバーが自分に割り当てられた作業の最新情報を共有した後、リンダは懸念を表明し、ストーリーの1つを分析段階に戻すことについてチームの考えを求めます。これにより、HCL Accelerate が指摘したボトルネックと仕掛かり品の問題が解決され、チームは優先度の高いタスクに集中することができます。

Emerald の製品オーナーである Peter は、機能リリースを遅らせる可能性のある顧客の問題が生産中であると人づてに聞いたため、心配になっています。状況に関する最新のデータを得るために、ピーターはHCL Accelerateのスイムレーンビューに行き、エピックでフィルタリングします。彼は、最も懸念している2つのエピックと、それらが本番でどのような状況にあるかをすぐに確認することができます。

LindaはDianeのソフトウェア修正を確認した後、Dianeからのプルリクエストをクローズし、変更を受け入れます。プルリクエストを閉じることで、マージとビルドが行われ、新しいバージョンがデプロイできるようになります。事態を迅速に進めるために、リンダは HCL Accelerate のパイプラインビューに移動し、新バージョンがベースのユニットテストと静的スキャンを持つ展開可能なアーティファクトとしてリストアップされていることを確認します。Linda は、最新バージョンを開発環境にデプロイする準備ができており、そこでレベルの高いテストを受けることになります。

HCL Launchで作業するLindaは、最新のアプリケーション・バージョンがどの環境にもデプロイされていないことを確認することから始めます。HCL Launchのスナップショット・ビューで、Lindaは新バージョンがデプロイ可能であることを確認し、従うべきデプロイメント・プロセスを選択して開発環境へのデプロイを要求します。実行ログでは、Linda氏はデプロイメントプロセスのすべてのステップを発生時に確認し、出力ログにドリルダウンして各ステップの詳細を見ることができます。API の力を利用して、HCL Launch は HCL Accelerate にデータを送信してパイプライン ビューを更新し、最新のアプリケーション バージョンが開発環境に正常にデプロイされたことを示します。

エメラルド社のテスターであるティムは、ある変更が開発環境にデプロイされることを知り、新しい機能を検証したいと思っています。ティムはHCL OneTest Serverで作業を行い、必要なテストを立ち上げます。Emeraldプロジェクトのダッシュボードを確認すると、さまざまなテストタイプの7つのテストスイートが実行されたが、そのうちの1つのテストスイートが失敗したことがわかる。アラームを鳴らす前に、ティムは失敗したテストスイートのHCL OneTestテスト実行結果をチェックします。実行されたテストステップをスクロールし、テスト中に実行されたアプリケーション画面の画像を見て、ティムはアプリケーションが正常に動作しており、テストも正しく実行されているという結論に達した。問題は、テストデータにある。

ティムは、テストデータが悪いためにテストが失敗することに不満を感じており、さらにテストデータファイルの管理に無駄な時間を費やしていることにも不満を感じていました。そこで彼は、HCL OneTest Serverのテストデータ作成機能で作成した合成テストデータを使って実験を行い、テストを実行することにしました。この実験が成功すれば、長期的には時間の節約になり、Emerald社のテスト活動を新たなレベルで最適化することができるとTim氏は考えている。HCL OneTest Serverのデータ作成画面で、ここで提供されたスキーマが、必要なデータフィールドを正確に含むテストデータファイルを生成することを確認しました。テストデータ作成用のスキーマを使ってテストを再実行したところ、合格しました。

すべてのテストが行われているので、テスト実行結果は自動的にHCL Accelerateに送られます。Linda は HCL Accelerate の「洞察」ビューで品質レポートを介して最新のテストデータを得ることができ、Emerald の関係者にアプリケーション修正の最新情報を簡単に伝えることができます。Linda は、このコード変更をさまざまな環境を通じて本番環境に移行し、HCL Accelerate でその進捗を追跡することができます。

HCL Software DevOps ポートフォリオのいくつかのソリューションを使用して、Emerald の製品チームは以下のことができました。

• 配信パイプラインへの新しい作業の迅速な導入
• バリューストリーム全体での作業の迅速化
• チーム内での効果的なコラボレーション
• ソフトウェアの変更を効率的かつ正確にデプロイし、テストすることができる。
• プロセス改善を取り入れ、パイプラインの最適化を図る
• ビジネスのリスクを排除し、お客様を喜ばせる

このストーリーを実際にご覧になるには、以下のビデオをご覧ください。

2021/5月/18 - 読み終える時間: ~1 分

HCL DevOps製品群を使ったリアルなデモを作成しました。

具体的には、HCL Compass、HCL Accelerate、HCL Launch、HCL OneTest を使用したものです。開発現場の実際をリアルに模した A Day in the Life 型のデモです。その分、17分弱とちょっと長めです。

• HCL Secure DevOps ソフトウェア (ページの一番下にあります)

こちらの解説記事もあわせてご覧ください。

2021/5月/13 - 読み終える時間: 3 分

How to optimize a secure DevOps pipeline with automation の翻訳版です。

SecureDevOps パイプラインを自動化で最適化する方法

2021年5月12日

著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps

DevOpsの主な目標の1つは、フィードバックループを加速することです。しかし、このフィードバックループは、しばしば手動プロセスによって停滞してしまいます。これらの手動タスクの一部を自動化することで、機能的なパフォーマンスやセキュリティチェックなどをプロセスの早い段階でシフトさせることができ、フィードバックループの高速化への道が開け、開発者はプロダクションインシデントを回避するできます。私たちのバリュー・ストリーム・マネージメント・プラットフォームである HCL Accelerate には、これを実現するためのいくつかの機能があります。

スマートゲートでは、テスト実行中に取得したデータを使用して、インテリジェントな決定を下せます。例えば、HCL OneTest を HCL Accelerate と統合することで、次の環境に移る前に、すべての機能テストが0回の失敗で合格しなければならないという自動化されたルールを追加できます。同様に、HCL AppScan を使って、静的コード解析でブロッカーがあることがわかった場合、コードを本番環境に移行できないようなルールを設定することもできます。テストと品質のためのこのレベルの自動化は、QAチームに蓄積されるテスト要求のバックログを防ぎ、品質チェックにおけるヒューマン・エラーのリスクを排除します。

同様に、当社の継続的デリバリツールである HCL Launch は、テストとセキュリティのための品質ゲートを提供します。HCL Accelerate を統合することで、HCL Launch で実行されたテスト、スキャン、デプロイメント情報のデータが自動的に HCL Accelerate に送られ、レポートやトレンド分析に利用されます。

HCL Accelerate のオートプロモート機能は、時間を節約し、パイプラインの最適化に役立つもう一つの自動化機能です。本番リリース用のデプロイメントプロセスを構築し、機能テスト、パフォーマンステスト、セキュリティスキャンなどのチェックを含むロジックを追加できます。その後、HCL Accelerate は展開ツールと通信し、どのバージョンをどの環境にどのような条件で展開できるかの指示を送信します。

HCL Accelerate は、テスト・ツールやセキュリティ・ツールを含むパイプライン内のすべてのツールから自動的にデータを取り込むため、すべての DevOps データを1か所に集められます。HCL Accelerate では、利害関係者に合わせたカスタム・ダッシュボードを作成できるため、何を修正すべきか、どのプラクティスを再現すべきかを知るための適切なレベルの情報を得られます。

全体的に、HCL Accelerate は、サイロ化された作業に起因する手動のハンドオフとボトルネックを排除します。多くのソフトウェア・デリバリー環境では、開発チームは、コードがコミットできる状態になったら、リリースチームにメモを送らなければなりません。次に、リリースチームは、コードがテストの準備ができたことを示すメモをQAに送る必要があります。そして、QAはテスト結果のメモをリリースに送り返す必要があります。HCL Accelerate は、アプリケーションが安全であることを確認するためのチェックとレポートを自動的に適用することで、これらすべてのメモを取り除きます。

自動化プロセスに適切なレベルの品質チェックを実装することで、継続的なデプロイメントモデルに真に移行できます。この機能は現在利用可能で、パイプラインの最適化に大きな違いをもたらします。これらの自動化機能のデモをご覧ください。

2021/5月/10 - 読み終える時間: 5 分

What is Value Stream Management for Software Delivery (and why it matters) の翻訳版です。

ソフトウェア・デリバリーにおけるバリュー・ストリーム・マネジメントとは何か (そしてなぜ重要なのか)

2021年5月8日

著者: Steven Wong / Solutions Lead for HCL Software

バリューストリームマネジメント (VSM) は、最近、特にITの世界で注目を集めています。私が話をした多くの人は、これがITにおける「新たな流行」に過ぎないのではないかと問いかけています。今回のブログでは、VSMに対する私の個人的な見解と、なぜそれがソフトウェア・デリバリーにとって重要なのかを紹介したいと思います。

バリューストリームマネジメント (VSM) とは？

VSMは、組織変革のためのアプローチです。

他の多くの組織変革のアプローチとは対照的に、VSM は、お客様と、お客様が最初に組織に近づいたときに期待したものである価値を提供するための組織全体の仕事の流れに、絶え間なく焦点を当てています。

ビジネスや組織を、一方で顧客からの要求を受け、他方でサービスや製品を提供するブラックボックスと想像すると、VSM はそのブラックボックス内のハイレベルな構成要素を評価し、要求がそれらの構成要素を経由して、結果として他方でサービスや製品を顧客に提供する流れを評価することである。

バリューストリームマッピングと呼ばれる手法を用いて、組織はバリューストリーム全体の仕事の流れをマッピングする。バリューストリームマップでは、さまざまなタイプの活動、システム、情報の流れを表す表記を使用します。さらに、ある活動にどれだけの時間が費やされているか、活動の外でどれだけの時間が待たされているか、その活動の成果物の品質、可用性などを明らかにするために、具体的な測定を行います。

ここで重要なのは、VSM は可視性を重視しているということです。可視性を示すのに、フローを図式化すること以上の方法があるでしょうか。

下の図は、バリューストリームマップの一例です。

バリューストリームマップがあれば、企業や組織は、潜在的な問題がどこにあるのかを確認し、パフォーマンス低下の根本原因を明らかにし、さらに重要なことに、どこで、どのように変革し、改善すべきかを明らかにできます。

VSM は新しい手法ではありません。長い間、VSM は主に、バリューストリームが工場の製造現場にある製造業の領域で使用されていました。

2010年初頭、カレン・マーティンやマイク・オスターリングのような組織変革の第一人者が、大成功を収めた著書『バリュー・ストリーム・マッピング』で、VSM とバリュー・ストリーム・マッピングの実践をオフィスやサービス業界に広めた。How to Visualize Work and Align Leadership for Organizational Transformation を出版しました。

なぜなら、顧客が組織に求めるものは「価値」であり、すべての組織はその価値を提供するシステムを持っているからである。

組織のパフォーマンスは、そのシステム (またはバリューストリーム) がいかにうまく機能して製品やサービスを提供できるかにかかっている。

VSM はソフトウェアデリバリーにどのように利用できるか？

「ソフトウェアが世界を食っている (“software is eating the world”)」という言葉を聞いたことがある人は多いと思いますが、これは今日のビジネス環境の文脈で語られることがほとんどで、テクノロジーが私たちの生活のほぼすべての局面に浸透しているため、すべてのビジネスにソフトウェアが必要であるということを意味しています。

それは、テクノロジーが私たちの生活のほとんどすべての側面に浸透しているからです。これを受けて、企業はデジタル面でのイノベーションにますます注力するようになっています。顧客エンゲージメントを高めるオンラインサービスの展開、サプライチェーンを最適化するバックエンドサービス、迅速な意思決定のためにビジネスにリアルタイムの情報を提供するアナリティクスなどです。

多くの場合、勝者と敗者の違いは、いかに早く変化に対応できるか、ソフトウェアの変更を競合他社よりも早く、高品質に展開できるか、ということに尽きるでしょう。

この適応能力を支えているのが、2000年代初頭から導入が進んでいるアジャイルや DevOps の手法です。

このアプローチにより、IT 部門では、IT が顧客 (ほとんどの場合、企業) に提供する製品に焦点を当てたクロスファンクショナルチームが形成されました。これらの「製品」チームは、リクエストから納品までの作業と、生産現場での製品の運用を管理します。

これを VSM と関連付けると、各製品チームとバリューストリームを直接比較できます。

もちろん、これは非常に単純化された見方です。というのも、ご存知の通り、複数の製品チームの間には相互依存関係が存在するからです。IT業界では、単独で存在する製品を見つけることは非常に稀です。

むしろ、ある製品／サービス (製品／サービス A とします) が、製品／サービス B の機能や特徴を必要とし、その製品／サービス B が製品／サービス C に相互依存している場合の方が多いでしょう。

ビジネス (または顧客) からのリクエストの種類に応じて、作業の流れは、単一のチームまたは複数のチームのいずれかによって実行されます。

ここで重要なのは、ソフトウェアデリバリーにおいて VSM を効果的に行うためには、異なる粒度のバリューストリームを見ることができ、ITに寄せられるリクエストの種類が異なることが非常に重要であるということです。

VSMでソフトウェア・デリバリーを最適化するには？

先に述べたように、VSMが有効なのは、あるアクティビティから次のアクティビティへのハンドオフの間の時間、労力、リワークなどの指標を可視化するからです。

製造業におけるオリジナルのVSMでは、これらの指標は、"Gemba Walk" と呼ばれる工場の現場に実際に行って、バリューストリームを構成するアクティビティの各ステップを観察し、測定することで得られます。

ソフトウェア・デリバリーの世界では、"Gemba Walk" をする意味はないかもしれません。むしろ、もっと単純なことかもしれません。

今日のソフトウェア・デリバリー・チームは、仕事を提供するために無数のツールを使用しています。

例えば、プロジェクトの計画と追跡には、Atlassian JIRAやBroadcom Rallyなどのプロジェクト計画・追跡ツールを使用します。並行開発の管理には、Gitやエンタープライズ版のGitHub、Bitbucketなどのソース構成管理 (SCM) ツールを使用しています。テストについては、テスト管理ツールや自動テストツールを使用して、テストの実行や欠陥の管理を行います。

これらのツールは基本的に、ソフトウェアデリバリーのバリューストリームを流れる作業を記録するシステムです。つまり、物理的な "Gemba Walk" を行う代わりに、ツールからデータを取得することで同じ目的を達成することができるのです。

唯一の問題は、各ツールは、そのツールが使用されたアクティビティの記録しか持っていないということです。

つまり、バリューストリーム全体のさまざまなリポジトリに、バラバラのデータが置かれているのです。

エンド・ツー・エンドの可視化のために必要なのは、これらのツールからのすべての異種の情報を、最終的に顧客からの最初の要求に関連する単一のエンド・ツー・エンドのビューにまとめる機能です。

例えば、ソフトウェア・デリバリーのためのVSMソリューションである HCL Accelerate のスクリーンショットをご覧ください。

このビューでは、各ドットが顧客からのリクエストを表しています。ドットの色は異なる優先順位を表しており、また異なるタイプのリクエストを表していることもあります。

ドットは、ServiceNOW、JIRA、TFS、HCL Compassなどのさまざまなツールから「引き込まれ」、バリューストリームのさまざまなプロセスステップやアクティビティを表すさまざまなバブルやカラムを左から右へと流れていきます。

ドットがバリューストリームを横切って進むと、HCL Accelerate のようなVSMツールは、Github、Bitbucket、HCL VersionVault のようなコードリポジトリのような他のツールからのデータを「蓄積」し、これらは顧客からの実際のリクエストにリンクされます。

ここでは、あるリクエスト (技術的な問題) がバックログから本番まで進んだ様子を紹介します。

上の画像で明らかなように、VSMソリューションは、異種ツールからの異なるデータの断片を、リクエストの単一のエンド・ツー・エンドのフローに自動的につなぎ合わせ、各段階でプロセスステップやアクティビティに費やした時間などの詳細を記録します。

HCL Accelerate は、セキュリティスキャンやテストツールとも連携できるため、コード品質やセキュリティに関する関連データを取り込むこともできます。

上記のような単一のワークアイテムでエンド・ツー・エンドの可視性を得ることは良いことですが、より価値があるのは、継続的な改善のためのフローやトレンドに関する洞察を生み出すために、バリューストリームを流れる何百、何千ものリクエストを観察し、分析する能力です。

以下に、これらのメトリクスとインサイトの例を示します。

特定のリクエストが1日遅れることで失われる機会コストをビジネスが特定できる場合、HCL Accelerate のような VSM ツールが提供するリードタイム (アイデア出しから生産までの時間) とサイクルタイム (コードコミットから生産までの時間) を比較する機能は、優先度の高いアイテムをキューに残しておくことのコストを簡単に浮き彫りにします。

バリューストリーム内のアクティビティで計画された作業と計画されていない作業の数を観察し、計画されていない作業がどのように遅延の原因となっているか (例えば、過剰な仕掛品を作成している) を観察することで、IT は作業を計画する必要がある理由をビジネスに伝えられます。

ここでの考え方は、VSM が提供する可視性は、事実に基づいた改善の手段となり、責任のなすり合いをなくすことができるということです。また、フローの最適化に焦点を当て、フローのステップではなく、フローの最適化に焦点を当てます。

まとめ

この記事では、組織変革のための実証済みのアプローチである VSM の方法論やテクニックを紹介しました。VSM は製造業の世界で生まれたものですが、ソフトウェアが普及した今日の世界でも同じように強力で効果的な手法です。VSM の手法は似ていますが、ソフトウェア・デリバリーに VSM を適用すると、いくつかの活動を異なる方法で行うことになります。例えば、ソフトウェア・デリバリーにおける VSM は、"Gemba Walk" でメトリクスを収集する代わりに、ソフトウェア・デリバリー・チームが使用するツールからメトリクスを収集しなければなりません。

HCL Accelerate は、まさにそのような要件のためにゼロから構築された HCL Software の VSM ソリューションです。

2021/5月/7 - 読み終える時間: 2 分

Three lessons from the 2021 Upskilling: Enterprise DevOps Skills Report の翻訳版です。

2021 Upskilling から得られた3つの教訓: エンタープライズ DevOps スキルレポート

2021年5月6日

著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps.

DevOps Institute は3年前から、世界中の何百人もの IT プロフェッショナルを対象に、どのようなスキルが "must-have"、"nice-to-have"、"optional"なのかを調査してきました。最近発表された 2021 Upskilling: Enterprise DevOps Skills Report では、パンデミックによって仕事のやり方を変えざるを得なくなったときに、DevOps がどのように変化したかを明らかにしています（ネタバレになりますが、デジタルトランスフォーメーションの必要性が高まったということです）。DevOps Institute チームによる統計データと洞察を得るために、ここでレポートの全文を読むことをお勧めします。しかしその前に、本レポートが提供する数多くの教訓のうち、3つだけを紹介します。

1つのフレームワークやベスト・プラクティス・モデルは存在しない

組織がDevOpsを実践していると言っても、通常はアジャイル、リーン、ITILなどのプラクティスが混ざっています。DevOpsは組織ごとに異なるものであり、技術的なものであると同時に文化的なものでもあります。IT業界でキャリアを積みたいと考えている人は、自分のプロセスに柔軟性を持ち、新しいツールを学ぶことを厭わない必要があります。また、DevOpsを重視する組織のマネージャーは、チームメンバーが自分の好きな働き方に合ったツールやプロセスを使うことを受け入れる必要があります。HCL Accelerateのようなエンタープライズレベルのバリューストリーム管理ツールは、組織がこれを達成するのに役立ちます。組織のバラバラなDevOpsツールのすべてからデータを集約し、レポートやインサイトに正規化することで、HCL Accelerateはパイプライン全体の方法論に柔軟性を持たせることができます。

重要性を増し続けるバリューストリーム管理

Upskillingの調査回答者の39%が、VSMのスキルはプロセスとフレームワークのスキル領域で必須であると回答しています。その理由は？それは、セキュリティと同様に、お客様に価値を証明することが、ソフトウェア開発のパイプラインの中で左遷されているからです。ソフトウェア・デリバリー・ライフサイクルのエンド・ツー・エンドのインタラクティブなモデルを提供するバリュー・ストリーム・マネージメント・プラットフォームがあれば、さらなる価値の向上に向けてどこにピボットすべきか、より多くの情報に基づいた決断を下すことができます。

DevOpsは進化であり、導入すればいいというものではない

DevOpsはヨガのようなもので、完璧ではなく練習です。"DevOpsを実行する」とは、単に開発チームと運用チームが一緒に作業することではありません。異なる規律を同じ目標に向けて調整するために、文化を持続的に調整することです。DevOpsへの変革を成功させるには、組織内のあらゆるレベルのすべてのステークホルダーの関与が必要です。Upskilling社の調査では、回答者の68%がIT環境における主要なフレームワークとしてDevOpsを採用していると答えていますが、多くの回答者がDesign Thinking、SRE、Agile at Scaleも適用していると答えています。他のオペレーティング・モデルは、適切な文化が存在する限り、実際にはDevOpsを補完し、組織がDevOpsの道を歩むのに役立ちます。

2021 Upskilling.DevOps Enterprise Skills Reportには、非常に多くの素晴らしい洞察と興味深い統計があります。2021 Upskilling: DevOps Enterprise Skills Report」には、就職活動中の方、新入社員を探している方、現在の職務をスキルアップしたい方などに役立つ素晴らしい洞察や興味深い統計がたくさんあります。ダウンロードはこちらから。