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

HCL OneTest Data はテスト用のデータを生成するツールです。Developing the Data Needed for Testing On Demand の翻訳版です。

オンデマンドテストに必要なデータの開発

2020年8月25日

著者: Nabeel Jaitapker / Product Marketing Lead, HCL Software

テスト用に適切なデータが手元にあるかどうかを確認するのは大変な作業です。

従来のアプローチでは、本番システムから既存のデータを複製し、テスト環境で使用します。GDPRやその他のプライバシー規制が施行されたことで、この種のテストは、特に個人データに関係する場合には、はるかにリスクが高くなっています。また、まだ本番システムがないため、使用する本番データがない場合も多くあります。

HCL OneTest Dataは、テスト環境用のモックデータを生成し、データ漏洩やプライバシー問題のリスクなしに合成データセットを生成します。

強力なビルトイン API により、テスト担当者は、定義済みのデータセットの使用、データ生成ルールの使用、またはあらゆる環境に対応したカスタムデータ生成スクリプトの使用など、さまざまな方法でデータを生成することができます。

HCL OneTest Dataの詳細については、こちらをご覧ください。

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

ソフトウェアのテストツールである HCL OneTest には組み込み用の HCL OneTest Embedded があります。 Combatting Component Testing and Runtime Analysis の日本語版です。

HCL OneTest Embedded: コンポーネントテストとランタイム解析との戦い

2020年8月24日

著者: Nabeel Jaitapker / Product Marketing Lead, HCL Software

バグを発見して修正するのに最適な時期は開発中です。

したがって、コード作成者だけが効果的に実行できる開発者テストに焦点を当てなければなりません。さらに、開発者は、記述されたコンポーネントを簡単にテストし、ホスト開発システム上で実行されるアプリケーションの信頼性と性能を分析できるようにしなければなりません。

さらに、詳細なテストとランタイム解析レポートは、関連するソースコードにハイパーリンクされていなければなりません。

HCL OneTest Embedded は、コンポーネントテストとランタイム解析を単一の統合された開発者中心のテストソリューションに統合します。

HCL OneTest Embedded のグラフィカル・ユーザー・インターフェースは、ランタイム解析結果（コードカバレッジとランタイム解析）をソース・コードに直接リンクし、ツールを離れることなくコードの修復を可能にします。

コンポーネント・テスト・ハーネス、テスト・スタブ、テスト・ドライバの作成と展開を自動化することは、HCL OneTest Embedded のおかげで簡単です。

どのような開発環境からでもワンクリックで、メモリとパフォーマンスをプロファイルし、コードカバレッジを分析し、プログラムの実行動作を可視化することができます。

さらに、HCL OneTest Embedded は、チームがより積極的にデバッグを行い、コードが壊れる前に修正することを支援します。

HCL OneTest Embedded の詳細については、こちらをご覧ください。

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

HCL OneTest UIは、HTML 5、Java、Windows、.NET、Visual Basic、SAP、Silverlight、Eclipse、Siebel、Flex、Ajax、Dojo、GEF、PowerBuilderアプリケーションを含む、HTMLをテストするオブジェクト指向の自動機能テストツールです。また、ビジネス・プロセス・フローの検証にも対応できます。そのことについて書かれた英語版ブログの記事 Automating and Validating Business Process Flows の翻訳版です。

ビジネス・プロセス・フローの自動化と検証

2020年8月21日

著者: Nabeel Jaitapker / Product Marketing Lead, HCL Software

ビジネスプロセスの検証は、数回クリックするだけで作成される複雑なテストアサーションを可能にする、シンプルでありながら強力なスクリプトツールを介して行う必要があります。

さらに、ユーザーが開発プロセスに自動テストを組み込み、納品物の品質を向上させることができるように、DevOps パイプライン（Jenkins、UrbanCodeなど）への統合が必要です。

HCL OneTest UI は、3270 インターフェイスを持つメインフレーム端末から、.NET や Java ベースのシッククライアントアプリケーションを介して、テスト担当者が自動化を行うことを可能にします。

さらに、最新のトップブラウザ、SAP や Oracle などの ERP システム、Angular、React、Vue.js などの最新フレームワークで構築された HTML5 ベースのレスポンシブ Web アプリケーションにも対応しています。

HCL OneTest UIの詳細については、こちらをご覧ください。

2020/8/22 - 読み終える時間: 2 分

HCL Accelerate はボトルネックを特定するツールですが、その前提として、あらゆる工程を追跡する機能を持っています。その特長について記した記事 Your item tracking tools aren't enough. Here's why の翻訳版です。

あなたがお使いのアイテム追跡ツールだけでは不十分な理由

2020年8月21日

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

スクラムボードのようなアイテムトラッキングツールについてどう思うか、開発者やチームリーダーに聞いてみると、否定的な答えが返ってくるでしょう。ほとんどの開発チームが使用しているトラッキングツールは、必要悪とみなされたり、貴重な仕事を成し遂げるための障害物とみなされたりします。スクラムボードは常に時代遅れで、開発者だけが知っている微妙な情報があり、ボード上では簡単には伝えられません。スクラムボードは手作業であるため、いくら状態やカラムを作成しても、情報には常にわずかな矛盾があります。

Jira のような作業項目追跡ツールは、プロジェクトの初期計画のために最低限の要件を収集し、チームの作業項目のバックログを構築するという目的には最適です。これらのトラッキングツールがバラバラになり始めるのは、作業が最初の計画段階から進行中の段階に移ったときです。この時点で、多くのチームはスクラムボードやカンバンボードを使用して、作業アイテムがパイプラインのどこにあるかのステータスを追跡しています。これでは、たくさんの列がある乱雑なボードになってしまい、開発者は自分のワークアイテムカードが正しい位置にあるかどうかを確認するために、多くの手作業や退屈な作業をしなければならなくなる可能性があります。その結果、ボードを整理したり、カードが正しい位置にあるかどうかを確認したりするために、無駄な時間を使ってステータスミーティングを行うことになります。ボードが常に正確でないと、本来の価値を失い、管理者は計画を立てるためにボードを頼りにすることができなくなります。そうなると、管理者は開発者を困らせ、状況の更新を求めて開発者に直接連絡を取るようになります。

Standups は、開発者がスプリントを成功裏に完了させるために何をすべきかを知るための方法ではなく、管理者のためのステータスミーティングになってしまっているのです。ミーティングは、ステータスレポートの更新ではなく、価値を高めるためのものでなければなりません。では、なぜステータス ミーティングで時間を無駄にしているのでしょうか？それは、作業を追跡するために使用しているツールが、実際にはより多くの作業を生み出しているからです。

複数のツールにまたがって DevOps データの集計を開始すると、ステータスミーティングの必要性がなくなります。これがまさに、バリューストリーム管理ツールである HCL Accelerate が行うものです。 開発者から手動で入力することなく、チーム全体のすべての作業項目の誰、何、いつ、どこにいるかを明確に示す、常に最新のライブバリューストリームにすべてのデータをまとめます。

HCL Accelerate は、すでに使用しているすべてのツールからデータを集約するので、手動でのステータス更新に別れを告げることができます。

ステータスチェックの必要性がなくなると、最初の大きな成果は、立ち見のミーティングの時間を取り戻すことです。価値を生み出す本当の仕事にすぐに集中し、開発者が仕事を完了させるために直面している障害に対処し始めることができます。スタンドアップ ミーティングでの会話は、「これは正しいデータか」から「どうすればチームの進歩に貢献できるか」へと変化します。さらに良いことに、「カードを作るのを忘れてしまった」という話を二度と聞く必要がありません。 DevOps パイプライン内のすべてのツールからデータが集約されているので、Jiraの問題、ServiceNowのチケット、またはGitHubの不正なプルリクエストから来る予定外の作業によるサプライズを心配する必要はありません。

HCL Accelerate は手動入力に頼るのではなく自動化されているため、正確なステージ完了データを得ることができ、パフォーマンスの高いチームを特定したり、ボトルネックをクリアしたりすることができます。開発者にとっては、これは管理作業を減らし、パイプラインに直接影響を与えるタスクでのマネージャーのサポートを増やすことを意味します。管理者にとっては、信頼できるデータ、可視性の向上、より正確な計画の策定を意味します。

しかし、開発者は新しいツールへの切り替えを嫌がり、使用しているアイテムトラッキングソフトウェアの周りにはすでにプロセスがあります。私たちはそれを理解しています。しかし、HCL Accelerate は、リッピング＆リプレース型のソフトウェアではありません。Jira、GitHub、Jenkinsなどの使い慣れたツールを使い続けることができ、HCL Accelerate はデータを掬い上げて、価値の流れの真実の単一ソースを提供します。プロジェクトの全体像をまとめるためにツールからツールに切り替える時代は終わりました。HCL Accelerate は、ツール間、チーム間、職務間のギャップを埋めます。

HCL Accelerateの「スイムレーン」ビューでは、作業項目がどこにあるのか、どのチームメンバーにサポートが必要なのかを明確に把握することができます。

すべてのソフトウェア企業は、競争の一歩先を行き、より多くの価値を生み出す方法を探しています。しかし、パイプラインがつながっていなければ、データや手動プロセスのギャップを埋めようとすることで、常に不利な状況に陥ってしまいます。HCL Accelerate は、ワークアイテムのトラッキングと KPI 測定を自動化し、チームがこれまで以上に機能するようにします。競争上の優位性はどうでしょうか？

自動化されていない限り、誰もデータを信じません。開発者と管理者の両方にとって、HCL Accelerate は、より良い意思決定のための正確でライブなデータにより、仕事を楽にします。無料の HCL Accelerate Community Edition で今すぐ始めましょう。

2020/8/22 - 読み終える時間: 9 分

今回は Jira と GitHub の活動を統合して見える化する内容 HCL Accelerate VSM with GitHub and Jira の翻訳版です。

GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management

2020年8月20日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate で GitHub 統合を作成する方法を説明します。これは、Jira、GitHub 、Jenkins を使用して HCL Accelerateのバリューストリームを設定し、使用するチュートリアルシリーズの第2部です。一部のバリューストリームのステップは、Jiraチュートリアルの完了を前提としています。Jiraチュートリアルを完了していない場合は、ここで完了できます。

1. GitHub リポジトリを設定する

GitHub の要件は以下のとおりです。

• GitHub リポジトリへのアクセス (このワークブックでは公開リポジトリを想定しています)
• GitHub API トークン
• プルリクエスト (PR) を作成する機能。

このワークブックは、公開 GitHub アカウントと公開リポジトリを前提としています。公開 GitHub アカウントを持っていない場合は、公開リポジトリと同様に作成する必要があります。リポジトリの内容は重要ではありませんが、PRが必要で、PR名には、フォローするJira課題の課題IDが含まれていなければなりません（ここでの例は"JKET-1"）。

2. GitHub インテグレーションを作成する

注: GitHub プラグインの設定はバージョン 1.0.31 から変更されました。バージョン1.0.31 以降では、URL フィールドは必要ありませんが、下記のステップ 9 のようにユーザーアクセスキーが必要になります。

• HCL Accelerateのプラグインページ（設定＞統合＞プラグイン）から統合を追加できます。

• このワークブックの統合名は「JKE GitHub App1」としてください。

• GitHub のURLはリポジトリへのURLにしてください (プラグインのバージョン1.0.31以降では必要ありません)

• GitHub リポジトリ URL から「名前」（リポジトリ名）および「所有者」（リポジトリアカウント）フィールドを取得できます。

• API URLは GitHub のインスタンスに依存します。このワークブックでは、"https://api.github.com" を使用する GitHub のパブリックインスタンスを想定しています。

• リポジトリにアクセスできるアカウント用の GitHub パーソナルアクセストークンを作成し、そのトークンをコピーして統合フォームに貼り付けます。GitHub の公開トークンは https://github.com/settings/tokens で作成できます。トークンを作成する際に、「スコープ/権限」のチェックボックスを選択する必要はありません。

• 追加」ボタンをクリックして統合を作成します。統合」ビューに移動して、統合が作成され、「オンライン」になっていることを確認します。ドロップダウンを展開して、統合の詳細を確認できます。(以下に示す Jira 統合は、別の演習の一部として作成されたことに注意してください)

• 統合名の横にある青い点は、アップグレードが可能であることを示しています。この時点でプラグインをアップグレードしておくと良いでしょう。三角点（カボブ）メニューの下にある「アップグレード」をクリックします。プラグインイメージが最新バージョン（1.0.36以降）に更新されるはずです。

• ユーザーアクセスキー（ GitHub プラグインのバージョン1.0.31以降。

1. GitHub プラグインのバージョン1.0.31以降では、HCL Accelerateユーザーアクセスキーが必要です。URLフィールドも削除されました。1.0.31以前のバージョンからのアップデートでは、ユーザー・アクセス・キーとの統合を編集する必要があります。

2. アクセスキーを作成するには、「設定」→「マイプロフィール」で「作成」をクリックします。アクセスキーを作成するには、「設定」→「マイプロファイル」→「作成」をクリックします。アクセスキーの名前は、それを使用する統合に合わせて、「JKE GitHub App1」のような名前にするのが良いでしょう。この時点でキーをコピーしておくと後でコピーできなくなるので、必ずコピーしておきましょう。

3. キーを作成したら、統合ページに戻ります。GitHub 統合の kabob メニューから「編集」をクリックします。フォームにユーザーアクセスキーを入力します。

3. GitHub インテグレーションをバリューストリームに追加する

vsm.json ファイルを使って、GitHub 統合と linkRule を値のストリームに追加します。ファイルをダウンロードして、以下のセクションを追加して修正し、再度ファイルをアップロードして変更を適用します。PR が開いているので、作業項目 (ドット) は"In Progress" ステージに移動するはずです。PR またはコミットが作業項目に正しくリンクされていない場合、四角（PR）または三角（コミット）として表示されますが、ドットはリンクされたすべての PR とコミットを含む実際の作業項目を表します。1つの作業項目に複数のPRをリンクできます。PR ブランチへのコミットは、ワークアイテムを更新します。

注: この時点から、いくつかのステップでは、Jira チュートリアルを使用して VSM を事前に完了していることを前提としています。チュートリアルをまだ終えていない場合は、今すぐ完了させるか、Jira との統合を行わずに先に進んでください。GitHub は統合されて PR やコミットを表示できます。しかし、イシュートラッカーの統合とそれに対応するリンクルールがなければ、作業項目のリンクはできません。以下のように vsm.json ファイルを編集して GitHub との連携を含めることに加えて、ステージクエリを編集する必要があります。

"query":"pr.status=open".

1. 作業用の vsm.json ファイルを値ストリームからダウンロードします。

2. GitHub 統合を .json コンテンツに追加します。

別のチュートリアルでJiraの統合を追加するために使用したjsonと同様に、もう一つのjsonオブジェクトを統合配列に追加する必要があります。ここでの名前は、先ほど作成した GitHub 統合の名前と一致させなければなりません。今のところ必要なのは、GitHub オブジェクトをシングルネームプロパティで追加するだけです。vsm.json に Jira のような他の統合が含まれている場合は、無視しても構いません。

"integrations". [
 {
* 名前":"JKE GitHub App1"
 }
 //その他の統合...
],

3. vsm.json の設定に GitHub -Jira の linkRule を追加します。

空のリンクルールの配列を置き換える...

"linkRules". [],

に新しいリンクルールオブジェクトを含む配列を指定します。この linkRule は、pr.name の中の jira.id を認識する正規表現パターンに基づいて GitHub の PR と Jira の課題をリンクします。

"linkRules". [
 {
* fromIntegrationName"。"JKE GitHub App1".
* toIntegrationName"。"JKE Jira 1".
*"fromField"."pr.name":"pr.name
*"toField"."issue.id":"issue.id
*"パターン"です。"([A-Z]+-[0-9]+)"
 }
],

4. vsm.jsonファイルを保存してアップロードします。

四角が見えますか？

GitHub の活動にもよりますが、"Merged" のようなステージにいくつかの四角が表示されていることに気づくかもしれません。これは、Jira カードにリンクされていない以前のコミットを表しています。私たちは新しい PR を作成して Jira カードにリンクさせることに焦点を当てているので、このような四角が表示されても無視して構いません。

4. Jiraと GitHub を使ったステージ変更

さて、GitHub をインテグレーションとして設定したところで、次はバリューストリームの中で GitHub を実際に使ってみましょう。GitHub はスタンドアロンの統合として使うこともできますし、さまざまな統合と一緒に使うこともできます。ここでは、Jira チュートリアルの VSM を使用していることに注意してください。

4.1 ドットを「進行中 (In Progress)」に移動する（PRを作成する)

ドットを「進行中」の段階に移動させるには、GitHub でプルリクエスト（PR）を作成する必要があります。

• リポジトリ内の任意のファイルを編集します。この例では、ファイルの右上にある鉛筆のアイコンをクリックして編集できる、README ファイルを編集しています。

• ファイルに変更を加えます。これらの変更は、以前に作成した Jira カードに対応するものと考えてください。これは、そのカードのコード変更を表しています。

• 変更を別のブランチにコミットします。コミットメッセージとブランチ名は好きなように設定できます。

• プルリクエストを作成するように促されたら、プルリクエスト名に Jira カードの ID/コード (例："JKET-1") を入力し、"Create pull request" をクリックします。

• プルリクエストがオープンで、JiraカードのIDが含まれていることを確認します。

• HCL Accelerateが検出して更新されるのを待った後、「進行中」の段階でドットが表示されるはずです。

4.2 ドットを「レビュー中 "In Review"」に移動する

• Jiraカードを"In Review"に更新してください。
• HCL Accelerateが更新されるのを待ちます。ドットが "In Progress" から "In Review" に移動するはずです。

4.3 ドットを「マージ済み (Merged)」に移動する

• 先に進み、GitHub で PR をマージします。

• HCL Accelerateがアップデートされるのを待ちます。ドットが"In Review"から"Merged"に移動するはずです。

次のステップへ。開発からサーバー構築、そしてその先へ

Wow! Jiraと GitHub の両方の活動が、HCL Accelerateで一つの真実のソースになるのを目の当たりにしています。次のステップは、ビルドとデプロイメントを統合して、本番まで作業項目を追跡することです。そのためには、Jenkins との統合を作成する必要があります。

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

Design Sprint? It's all the rage, but will it work for your team?

Design Sprint? 流行っていますが、あなたのチームには効果があるでしょうか？

2020年8月19日

著者: Ben Vance / UI Designer for HCL Software DevOps

バックストーリー(生い立ち、これまでのこと)。どのようにしてここまで来たのか？

率直に言います。

COVID-19 パンデミックとワーク・フロム・ホームの「ニューノーマル」の始まりに際し、私たちはかなり大きな設計プロセスの失敗をしました。設計に1ヶ月もかからないはずの新機能が、3ヶ月近くもかかってしまいました...最終設計はかなり最初の設計に近いものになってしまいました。全員がオフィスにいたとしても、非効率なことは起きていたでしょうが、リモートであることが問題をさらに悪化させ、そのうちのいくつかの問題が発生しました。

• プロジェクトの開始時に明確な要件がなかったこと
• 最初のミーティングにキーパーソンがいないこと
• プロセスを通して新しい人を連れてくる
• 会議の間隔が長い

では、それぞれの問題を詳しく見ていきましょう

• 私たちが始めたとき、「成功」とは何を意味するのか、明確な考えがありませんでした。さらに悪いことに、誰もが「成功」の意味するところが違っていました。だからデザイナーとして、私たちは動き続ける的中率の矢を暗闇の中で撃っていました。私たちは、ある用語が実際に何を意味するのかを定義し、再定義することに何時間も費やしました。
• 私たちは、ビジネスの "上の方 "にいる数人の主要なステークホルダーからプロセスを始めました。私たちは、彼らの考えと賛同を得ることで、デザイナーがまとめたソリューションを実装するために開発者を引き入れることができると考えました。問題は、開発者がそれぞれの考えを持っていたこと、さらに重要なことは、以前に設計された製品からの洞察を含めて、製品がどのように機能するべきかについての異なる洞察を持っていたことでした。
• 開発者を引っ張っていくと、追加の質問やポイントが出てきて、それを主要な利害関係者のところに持ち帰らなければならないことがわかりました。私たちは、各段階で追加の開発者を入れ続けることで、この問題をさらに悪化させてしまいました。これは結局、一連の循環型の議論を生み出し、タイムラインをさらに悪化させ続けました。
• 最終的には、会議やデザインレビューの間に時間がかかりすぎてしまいました。デザインの更新は1日で終わるのに、チームでレビューするのに1週間も待たされていました。これがリモートワークの一番の弊害だと思います。オフィスでは、即興のフィードバックを得るために人の肩を叩いていました。リモートで仕事をしていると、会議のスケジュールを組んだり、かなり忙しいスケジュールの中で仕事をしたりしなければなりませんでした。

だから、解決策は？全く逆のことをして、次のデザイン機能を1週間以内に完成させよう。何がいけないのでしょうか？

Design Sprint。それはまさにプロセスなり

私たちはリモートで仕事をしていたので、在宅勤務の方針に合わせて Design Sprint の方法論を少し修正しなければなりませんでした。

• すべての会議は、会議室で個人的に行うのではなく、GoToMeeting を介して行われます。
• このデザインを素早く把握するために部屋に入る必要があるキープレイヤーを把握する。私たちは、デザイナー、開発者リード、開発者のミックスに着地しました。我々はまた、日進月歩のレビューを与えるために、"上の人 "とのいくつかのフォローアップミーティングを持つことを決めました。
• チームメンバーを選ぶことで、その人たちがチームの残りの部分を代表して話すことを明確にしました。会社全体をまとめて100%の合意を得ることは不可能でしょう。ある時点では、チームのリーダーは他の人にコントロールを委譲しなければならないでしょう。
• 公式の」 Design Sprint の方法論に従って、チームはこのプロセスに40時間を費やす必要があります。現在進行中の作業と、これが「ベータ版」の取り組みであるという事実を考えると、この機能を完成させるためには1日90分という時間が必要になります。
• デザインチームは、毎日達成したいことを網羅したアウトラインをまとめました（※脚注やスケジュールのスクリーンショットを追加してください）。
• 公式な方法論を確認しましたが、私たちのためにプロセスをかなり自由にしました。

結果はどうだったか

手短に言うと...本当によくできました。

• 開発者は、設計プロセスにもっと参加したいという希望を表明しています。 Design Sprint では、初日から自分たちの考えを表現することができました。また、このプロセスでは、彼らが考えていた解決策をスケッチし、デザインする機会を与えてくれました...それがペンと紙であっても、シンプルなパワーポイントであっても。

• 私たちは、バーチャルホワイトボードとして壁画ソフトを利用することにしました。これは、ブレインストーミング中に全員が自分の考えをタイプしたり、さらに発展したものを見たいと思った項目を「スターリング」したりすることができるようにするための素晴らしい決断であったと思います。一週間を通して、グループは初日のメモやスケッチを参照し続けました。

• 1日目は予定より遅れてしまいました。1日90分というのは、このプロセスを始めるにあたり、私が一番恐れていたことでした。私は、会議がどれだけすぐに逸脱してしまうかを知っているので、簡単に1時間を失ってしまうことになります。私たちは、このような議論をできるだけ早く終わらせるように心がけていましたが、実際にはそうなってしまいました。

次回は何をするか

Design Sprint は成功しましたが、プロセスを改善するために変更できることがいくつかあります。

• 毎日、より多くの時間を割くこと。1日90分だけでは、全員の考えを完全に具現化するには十分な時間ではありませんでした。
• 理想的には、ホワイトボードやポストイット、目と目が合うような形で、直接会って行うのが良いでしょう。電話でできる限りのことはしましたが、やはり対面でのフィードバックが理想です。
• プロトタイプのフィードバックをしてくれる時間を割いてくれる顧客の具体的なグループを持っている。

まとめ

これはあなたのチームでも当てはまることなのでしょうか？私はそう思います。

HCL Software DevOps では、非常に意見の多いチームがあり、彼らの声を聞きたいと思っています。このプロセスは、それを可能にしてくれました。全員が自分たちが取り組んでいることに興奮し、エンドツーエンドのプロセスに手を貸したと感じたとき、製品は恩恵を受けることができます。それを実現するためには、日々の仕事に追われていると感じないように、時間を割き、チームに必要なリソースを与えなければなりません。しかし、最終的には、テスト可能な具体的な成果物プロトタイプができあがります...1週間の作業も悪くありません。

HCL Accelerate は、チームが世界中に分散している場合でも、オフィスで一緒に作業している場合でも、スプリントを成功させるためのお手伝いをします。チームメンバーごとに作業を整理するスイムレーンのような機能や、すでに使用しているツールと統合する機能を備えた HCL Accelerateは、DevOps パイプラインの測定、トラッキング、最適化をこれまで以上に容易にします。ここから無料でダウンロードしてください。

2020/8/19 - 読み終える時間: 2 分

ニューノーマルを見据えた DevOps の取り組みの重要性について説いた Leading the Transformation with DevOps の翻訳版です。

DevOps で変革を導く

2020年8月17日

著者: Elise Yahner / HCL

ここ数年、あらゆる規模の組織でデジタルトランスフォーメーションが行われていますが、多くの企業ではそのプロセスが十分に速く動いているとは言えません。DevOps はどのようにしてデジタルトランスフォーメーションの速度とインパクトを向上させることができるのでしょうか？DevOps.com のエキスパートが、新しいeBook「How DevOps Leads the Way to Digital Business Transformation」でそれについて深く掘り下げています。

このeBookでは、ITエグゼクティブや技術リーダーからの洞察をもとに、最新のデジタル・ビジネス・アプリケーションの構築と展開を加速させる唯一の方法は、最高のDevOpsプラクティスを採用することであると主張しています。もちろん、それは言うは易く行うは難しであり、特にCOVID時代のリモートワークで直面した新たな課題など、DevOps の採用にはいくつかの障害があります。

HCL Software の DevOps 戦略担当ディレクターであるブライアン・ムスコフ氏は、「DevOpsの変革を成功させるための第一の障害は、組織の変化です。結局のところ、自動化とプロセスの改善は簡単なことです。何年も同じように運用してきたチームや個人の行動を変えることが真の課題です」と述べています。

DevOps.com は、業界の専門家を招いたパネル・ウェビナーで DevOpsの 変革についての話を続けました。HCL Software の DevOps アドバイザリー＆採用担当ディレクターである Chris Nowak 氏は、変革の文化をサポートするために適切な人材を雇用することの重要性を指摘しました。

「カリスマ性のある一人の人間だけではなく、それ以上の人間を中心にトランスフォーメーションを構築することが本当に重要です。リーダーシップと説明責任を外注することはできません。それはうまくいきません。どちらかといえば、インソースすることです。専門家に頼ったり、コンサルタントを雇ったり、人材を雇ったりするのです。常に人材と才能が重要なのです」と彼は語っています。

DevOpsトランスフォーメーションの重要なポイント

心に刻んでおくべきこと

• DevOpsの採用は、デジタルビジネスが "ニューノーマル "に突入する中で、成功するか、単に生き残るかの違いを分ける鍵となります。
• セキュリティは、デジタルトランスフォーメーションを成功させるための最重要事項ですが、テクノロジーを活用した新しい取り組みのうち、最初からセキュリティチームを含むものは、わずか3分の1にすぎません。
• ビジネスリーダーのサポートがなければ、デジタルビジネスの取り組みは失敗する可能性が高くなります。
• デジタル・ビジネス・アプリケーションを構築・展開するためにマイクロサービスをうまく取り入れることができれば、競争上の優位性は格段に高まります。

チームを編成したら、チームの全員にデジタルトランスフォーメーションが彼らにとってどのような意味を持つのか、個人的にも組織の一員としても透明性を持たせる必要があります。

「組織の DevOps トランスフォーメーションの背後にある「なぜ」を伝えましょう。デジタルトランスフォーメーションの中で、自分たちがどのようにビジネスの目標に沿っているかを理解してもらいましょう。その結果、透明性が高まり、コミュニケーションが向上します。彼らに理由を与え、境界線を与え、そこに到達できるように支援してください」と Nowak 氏は語ります。

これらはすべて、DevOps の変革はチームの努力であり、一人で行うものではないという考えを裏付けるものであり、顧客に焦点を当てたミッションであるということを示しています。

「私たちは、本番の境界線を超えて考え始めなければなりません。価値とは、それを製品化することではなく、製品化した後に誰かが喜んで製品を使用することです。まだ始まったばかりにもかかわらず、私たちは、製品化までたどり着いたということで、自分たちの旅を限定しています」と、Nowak 氏は説明します。

DevOps.com の eBook で、デジタルトランスフォーメーションを推進するための詳細な洞察とアドバイスを得ることができます。お客様の組織に合わせたマンツーマンのアドバイスをご希望の場合は、ここをクリックして、Chris Nowak 氏の無料戦略セッションをリクエストしてください。

2020/8/15 - 読み終える時間: 3 分

デプロイメントツールである HCL Launch がダウンすることで影響がでないように、高可用性を確保することが重要です。それについて書かれた英語版ブログの記事 Planning for High Availability of HCL Launch の記事です。

HCL Launch の高可用性について計画作成

2020年8月14日

著者: Madhavarao Kulkarni / Associate General Manager

IT 標準の要件の 1 つは、優先度の高いすべてのツールに高可用性を提供することである。この点で使用される最も有名な用語は、高可用性(HA)、冗長性、ディザスタリカバリ(DR)です。IT部門は、いくつかのアプリケーションに対してこのようなセットアップを行っているかもしれませんが、アプリケーションは多くの面で異なるため、アプリケーションごとに「何をすべきか、どのようにすべきか」を知っておくことは理にかなっています。HCL Software のお客様のために、この記事では、HCL Launch に関する有益な情報を提供したいと思います。

高可用性を達成するためのフェーズ

• 高可用性を必要とする背景
• HA/DR/リダンダンシーでの業務開始のための業務明細書
• HAを表現するための展開計画
• タイムラインと取り組み
• 予算の検討
• 重要なことを見逃さないための実行計画

HAの背景

まず、何を設定しようとしているのかを確認しておきましょう。

高可用性 (HA) - 使用量が増加している場合、パフォーマンスが重要になっている/パフォーマンスの問題を解決しなければならない場合、ビジネスクリティカルなアプリケーションやSLA駆動のアプリケーションのダウンタイムゼロを達成することができます。

ディザスターリカバリー(DR) - アプリケーションがデータセンターのいかなる災害に対しても回復可能であることを保証しなければならない場合。

冗長性 - アプリケーションが応答時間で改善され、より多くの要求を処理したり、期待される応答基準を提供する場合

それぞれが似たようなケースもあるが、重要なポイントは「何を目標にしているか」を決めなければならないということだ。一部の組織では、DR を確保するためにコンプライアンスの必要性があるので、それを実行しなければならない。他のケースでは、成長、パフォーマンス、標準などの他の要件に追われている。高可用性のために行かなければならないかどうかを決定したら、我々はそれが冗長性か HA かを考えなければならない。

成果物: ユースケース、アプリケーションのパフォーマンス/採用、ダウンタイムや収益への影響の数字、将来の成長率のメトリクス。

HAのためのビジネスステートメント

ビジネスステートメントは、「重要なエンタープライズアプリケーションの HCL Launch へのオンボードを開始したい」とか、「HCL Launch のダウンタイムがゼロになるようにしたい」というようなものです。これは、なぜHAを達成しなければならないのかという方向性と明確さを与えてくれます。HCL Launch の中で、新しいサーバーやリレーを追加して水平展開することで実現できるアプリケーションの数が増えているのであれば、HA のために頑張る必要はありません。そのため、この時点では成果を重視してください。

成果物: ミッションステートメントの詳細、実行、予算、スケジュール、各ステークホルダーの承認などが記載された文書。

期待される事業目標を達成するための展開計画

基本的なリファレンスとして当社の展開図を使用して、サーバー名、地理的な場所、データセンター間のネットワーク遅延、容量などのラベルで図を覆って、組織のために 1 つの図を作成することで、図は多くの情報を提供するようにしてください。その良い負荷要因を言及することによって、それらに期待される負荷を置くことができます。ITの情報を示すようにしようとすると、ストレージ、レプリケーションの必要性（はい/いいえ）、計算の詳細のように尋ねます。ファイアウォール、データセンター名、地理的な場所を含むだけでなく、ラベルポートと通信の有効化計画。あなたは、ネットワークチームと協力する必要があるかもしれません]。

成果物: 洞察力に富んだアプリケーション展開の現在および将来の状態を表現したもの、あなたの組織に特有のチェックリスト、将来のアップグレードのためのチェックリスト、サポート、およびその他の IT の定期的な取り組みを網羅したもの。

タイムラインと努力

調達から展開までのタイムライン計画を作成します。また、ダウンタイムや、あなたのグループと一緒に作業しなければならない他のチームのように整列させる。ネットワーク、データベース、ストレージ、コンピュート、HCL Launch のサポートのように、すべての利害関係者（チェックリストの利害関係者がリストされていることを確認してください）とのタイムラインのレビューを得るための良い練習になります。

成果物: タイムライン情報、ステークホルダーリストと承認、イベントとリード情報。

予算

予算の計画を立てる際には、以下のことを考慮してください。

• HCL Launch のライセンス費用の予算 [各サーバーにかかる費用]について
• 計算、ストレージ、データベースの追加ライセンスのコスト
• バックアップ戦略とコストは、クロスチャージとして組織内のアプリケーションの場合
• 人工コスト

実行計画

実行計画には以下のものが必要です。

• 必要なものの一覧
• サポートチケットのステータス、ステータス、承認
• ダウンタイムウィンドウ
• ロールバックプラン
• テストのチェックリスト
• HCL Launch に期待するサポートのレベルを確認する
• HCL Launch チームにアップグレード計画を伝えるためのサポートチケットを作成し、それは HCL Software が最高のサポートを提供するのに役立ちます。
• 選択したソフトウェアのバージョン一覧 [選択したバージョンのサポート終了情報にご注意ください] ※選択したソフトウェアのバージョン一覧
• HCL Launch で他の製品との統合を使用している場合は、新しい展開計画での動作を確認するためにチェックリストを作成してください。
• 実行中の問題をトラブルシューティングするために、ネットワーク、アプリケーション、統合、プラグインなどのレベルでロギングを有効にするためのチェックリスト