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

Storing Code in Model Files Using CDATA の翻訳版です。

HCL RTist: CDATAを使ったモデルファイルへのコードの格納

ng Code in Model Files Using CDATA profile image Mattias Mohlin Senior Solutions Architect for HCL Software

RTistのモデルは、XMLファイル（.emx、.efx）に格納されています。このようなファイルをテキストエディタで開いたことがある方は、モデルに格納されているコードスニペットが、XMLで義務付けられている特定の文字のエンコーディングのために、非常に読みづらいことに気づかれたことでしょう。以下にその例を示します。

一部のコードスニペットはXMLの属性として格納されており、改行もコードスニペット全体が1行で表示されるようにエンコードされているため、見た目がさらに悪くなります。

RTist 11.0 2020.33からは、コードスニペットがXMLファイルのCDATAセクションに保存されるように設定することができます。これにより、コードをエスケープする必要がなくなり、読みやすさが大幅に向上します。この環境設定は「モデルファイルの保存時にCDATAを使用」というもので、「モデリング」環境設定ページにあります。この設定は、コード・スニペットだけでなく、ドキュメント・テキストの保存方法にも影響します。

この環境設定を設定すると、上記の例のコード・スニペットは次のようになります。

なお、RTistの古いバージョンでも、CDATAを使ったモデルファイルを読むことができます。その意味で、この機能は後方互換性があります。ただし、そのような古いバージョンのツールでモデルを編集して保存すると、コードスニペットは再びCDATAを使用せずに保存されることに注意してください。 モデルファイルにCDATAを使用することにした場合、ワークスペース内のすべてのファイルを新しいフォーマットで使用するために手動で保存し直すのは少々面倒です。簡略化するために、モデルフィクスアップを実行すると、すべてのモデルファイルが自動的にCDATAを使用するように変換されます。

詳細はこちらのビデオをご覧ください。

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

Latest HCL OneTest Release Boasts Several Benefits, Features の翻訳版です。

HCL OneTest の最新リリースの機能と利点

2021年4月2日

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

最新の HCL OneTest 10.1.3リリースには、プロジェクトのライフサイクルを通してUI、パフォーマンス、APIなどの分野で継続的にテストを行うためのいくつかの利点と機能が含まれています。

その内容を簡単にご紹介します。

テスト機能の拡充

GraphQLエンドポイント（マイクロサービス上でクエリを構築するための一般的な手段）を簡単にテストできるようになります。これはREST/JSONベースのサービスと似ていますが、クエリやミューテーションに関連する特定の機能があるため、専用の機能を提供することが望まれます。

以下のものを扱うためのサポートも充実しています。

• GraphQLクエリ
• クエリーとミューテーションの構築
• イントロスペクションによるGQLスキーマの取得
• GQLエンドポイントの仮想化

テスト中のアプリケーションの設定管理が容易に

HCL OneTest 10.1.3では、アプリケーション構成ツールキットが刷新され、Web、Android、iOS、Windowsアプリを使いやすいWebインターフェイスで構成できるようになりました。

AI/MLテストドリブンソリューション

HCL OneTest Dataには、複数の出力テーブル間のデータの相互相関を可能にする参照整合性モジュールが含まれており、ビジネス・シナリオを適切にモデル化するために必要なすべてのリンク・データを生成することができます。例えば、注文履歴テーブルに複数のリンクされた購入を持つ顧客レコードを設定することができます。

アプリケーションモデリング

HCL OneTest 10.1.3では、システムモデルビューの最初の部分が導入され、ユーザーは実行中のテストや仮想化しているコンポーネントがどのように接続されているのか、その品質の状態を素早く視覚的に把握することができます。

また、仮想サービスにおいては、アプリケーションのどの要素を仮想サービスで表現するのかを明確にすることで、モデル内の依存関係を置き換えるために仮想サービスの利用を迅速かつ容易に開始することができます。

例えば、外部依存性をモデル化し、そのモデルコンポーネントにバーチャルサービスを関連付けることで、ユーザーは膨大なバーチャルサービスのカタログを調べることなく、コストのかかるサードパーティのサービスを簡単に削除することができます。

SAPエコシステムサポートの更新

SAP GUI 7.60は最新のメジャーリリースであり、HCL OneTest 10.1.3は最新の機能や変更点を完全にサポートしています。

他にもたくさん

今回のリリースには、お客様のアイデアがいくつか含まれています。私たちは、テスターのコミュニティを大切にしており、提出されたすべてのアイデアを評価しています。製品に反映させるために最善を尽くしますので、どうかご意見をお寄せください。

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

Advancing Avionics Verification and Validation の翻訳版です。

HCL OneTest: 進化するアビオニクスの検証と妥当性

2021年3月31日

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

アビオニクス・ソフトウェア・エンジニアリング・プロジェクトの遅延を減らすことは、エラーが致命的な損失につながる可能性のあるソフトウェアの失敗リスクのために非常に困難です。実際に、ソフトウェア検証・妥当性確認プロジェクトの90％以上が遅れて納入されています。

航空電子機器の検証と妥当性確認は、規制要件である DO-178B または DO-178C ソフトウェア規格に準拠するために多大なエンジニアリングの努力を必要としますが、チームは市場投入までの時間の目標を達成するために、自動化によってこの労力を削減する方法を常に模索しています。

HCL Engineering and R&D Services (ERS) は、航空分野における世界最大級のサードパーティサービスプロバイダであり、ボーイング、エアバス、ボンバルディア、エンブラエル、ガルフストリーム、COMACなどの主要プログラムのアビオニクスおよびエレクトロメカニカルシステムについて、世界中の15社以上のアビオニクスのお客様と協力しています。

HCL ERSのアビオニクス・チームは、10～15年前から IBM Rational Test RealTime を使用しており、同製品に関する深い専門知識を持っていましたが、Test RealTime には検証プロセスをより効率的かつ効果的にするための機能がいくつか欠けていました。

そのため、HCL OneTest Embeddedのエンジニアリング・チームと協力して、HCL OneTest Embedded をすべてのテスト・フェーズで使用できるようにするための新機能を導入しました。

HCL ERSが導入したソリューション (eDAT) は、C/C++ ライブラリ（ディスクリートI/O、ARINC バス...をサポート）を介して、テスト対象のシステムとテスト専用のマシンをインタフェースするワークベンチに依存しており、OneTest Embedded の使用に基づいて、アビオニクス・ソフトウェア・テスト/検証・妥当性確認の上位5つのカテゴリ（コードレビュー、ローレベルテスト、ソフトウェア-ソフトウェア統合テスト、ハードウェア-ソフトウェア統合テスト、分析）を対象としています。

OneTest Embedded を使用して、ソフトウェアコードの正確性と一貫性を確保しながら、テストケース作成の労力を20～25％削減した事例をダウンロード できます。また、コード・カップリング解析の作業を3分の1に減らし、700時間以上の作業を削減しました。さらに、コールグラフやスクリプトレスのビジュアルテストエディタによるテスト作成支援により、14％以上の削減を達成しました。

2021/3/31 - 読み終える時間: ~1 分

Editorial: Value Stream Management in 2021 の翻訳版です。

2021年のバリューストリームマネジメント

2021年3月30日

著者: Oreste Egidio / Client Technical Advisor

ソフトウェア開発の世界では、新しい方法論やソリューションが頻繁に登場します。新しい手法はすぐに流行語になりますが、最近の流行語の一つに「バリューストリームマネジメント」があります。

新しいものは何でもそうですが、なぜバリューストリームマネジメントのソリューションを採用することが重要なのか、なぜ今が組織にとって真剣に評価すべき時なのかを詳しく説明した資料をオンラインで見つけることは難しくありません。私もその合唱に加わるつもりはありませんが、これから数行にわたり、私のお客様との経験から得た考察をお話ししたいと思います。

一般的に私は、ソフトウェア・プロダクション・チェーンの開発・管理を求められている人々の問題を、テクノロジーだけで解決できるとは考えたくありません。誰もがこのように考えているわけではありませんし、例えば、「人工知能」をどこにでも「注入」しようという、一般化された、おそらくあまり現実的ではない考え方につながるからです。

むしろ、優れたテクノロジーを賢明かつ実用的に採用し、正しい方法論の選択と組み合わせることで、違いを生み出している例がたくさんあることに気がつきました。Uber、Flixbus、Airbnbなど、デジタル・ディスラプションの波に乗った企業を挙げると、革新的なアイデアと優れた起業家精神のおかげであることは間違いありませんが、テクノロジーと方法論のバランスのとれた使用なしには、革新的な企業を実現することはできませんでした。

バリューストリームマネジメントのトピックを紹介する際には、テクノロジーと方法論的アプローチが具体的な価値をもたらす「ソリューション」として適切に位置づけることが重要ですが、それはどのような分野においてでしょうか？なぜ今なのか？表面的に見ただけでは、いくつかの検討事項があります。

• 適切な測定基準によって生産チェーンを「管理」するために、どれだけのことをしたいのか、そして何よりも、どれだけの価値があるのか。
• プロセスのパフォーマンスを「視覚的に」（つまり即時に）把握するためには、何を犠牲にすればよいのか？何が間違っているかを「一目で」コントロールするために？無駄な時間を省くことで、プロセスをより効率的にすることができます。あるいは、リリースまでの時間を最大で90％短縮したいのか？

このような考えは、適切な手法を用い、必要な技術を賢明に採用して、何年も前から非常にうまくいっている人々を苛立たせます。実際、大前提として、今までの仕事の仕方が悪かったと思われているようです。実際には、新しいアプローチを採用する原動力となるのは、いつものように文脈の変化です。今日では、多くの現実が「アジャイル」に取り組んでいます。ある人は「押し付けられた」方法で、ある人は始めたばかりで、ある人は（あるレベルでは長い間あきらめられない）選択肢を検討しています。アジャイル」アプローチは、完全に実現するのは簡単ではありませんが、工場の現場で「ビジネス指標」のレベルで完全なガバナンスを与える可能性を開きます。

これは、何年も前に自動車メーカーが制御システムを導入して、収益性を維持しながら同じラインで同じ車を200台カスタマイズして生産できるようにしたのと同じ論理とビジョンで、ソフトウェア工場に「装置」を導入する可能性を開くものです。現在の問題は、ROI と全体的な生産性に影響を与えることなく、このモデルをソフトウェア工場に導入する方法です。出発点は何でしょうか？

確かにこれまで、DevOps 分野をはじめとする多くの投資は、ベンダーのソリューションとオープンソースへの投資（オープンソースは完全に無料ではないことを学ぶ）、そして様々なレベルのコンサルティング活動の両方で行われてきました。そのため、最初のポイントは、これまでの投資を尊重し、保護することです。その上で、客観的なデータに基づいてビジネス上の意思決定（投資）を行うために有用な情報だけを収集し、公開する仕組みを構築することが課題です。現在の経済状況では、多くの企業が既存の開発を中断せずに投資を減らしている一方で、今すぐ投資して早く結果を出さなければならない企業もあります。いずれの場合も、「動く」ことが求められます。

自分の分析能力で下した最初の判断を、客観的なデータで補強したり、見直すことができるツールは、ソリューションにさらなる価値を付加するための投資のリスクを軽減するために、これまで以上に必要です。しかし、投資がビジネスにどのような価値をもたらしたかを理解する必要があるのは、その後です。決断を助けてくれた同じツールが、もたらした価値を迅速かつ客観的に評価してくれる。これは確かに、バリューストリームマネジメントソリューションを採用することのプラス面の一つです。

バリューストリームマネジメントソリューションを導入されているお客様の中には、投資リスクを低減する目的で、投資を段階的に行う方もいらっしゃいます。どのように？それは、パイロット・プロジェクトへの少額の投資から始めて、その結果を評価し、正しい判断を下すことです。決断とは、次のようなものです。

• プロジェクトがビジネスに付加価値を与えないことが判明したため、プロジェクトを断念する。しかし、行った投資と費やした時間は、行った試みに含まれており、DevOpsとAgile の原則である Fail Early, Fail Fast を適用していること。
• プロジェクトの価値を理解し、いくつかの決定をよりよく検討するのに役立つデータを持ち、ソリューションを採用するのに必要な時間をより正確に把握しているので、この時点では、リスクを減らしたという確信を持って投資を行うこと。

しかし、実際にはアプリケーション開発の世界を変えるような変革が起きています。それは、Just-In-Case（最悪のケースに備えてサイズを調整する）から Just-In-Time（その時々に応じて迅速に対応する）への移行と要約できます。このアプローチの変化は、痛みを伴わないものではありませんが、適切に実施されれば、確実に大きな競争上の優位性をもたらします。この Just-in-Case から Just-in-Time への移行は、クラウドの出現によってすでに実現しています。クラウドは、ハードウェアとソフトウェアを提供し、実際に使用されたリソースに対してのみ支払いを行うというシンプルさを利用して発展してきました。また、必要なときに処理能力のピークに対応し、厳密に必要な時間だけ新しいパワーを支払えます。

問題点は？企業にとってのクラウドソリューションのコストは、短期間で大幅に増加する可能性がありますが、それはなぜでしょうか？早くコストを削減したいという思いから、多くの企業がツールやアナリスト、開発者を手に入れようとしますが、常にコストとリリースされたものの品質が目的となってしまいます。結果として、リリースされるものの品質を忘れてしまうと、このような制約の中で開発されたアプリケーションは、使用するためにますます多くのリソースを必要とするという事実につながります。

水平方向にも垂直方向にも問題なく、迅速かつ透過的にスケールするクラウドの利用は、開発者がコストを認識していないため、それ自体が問題となります。しかし、より高いレベルでは、このコストの増加に対処し始め、多くの記事では、パフォーマンス・テストは、API や機能テストと同じようにパイプラインに追加するものであると提案されています。

現在では、ソフトウェア開発プロセスのアプローチは、決定論的な用語ではなく、測定や予測が容易なものではなく、確率的な用語でアプローチすることが多くの人に受け入れられています。そのため、プロジェクトミーティングで毎週のようにレビューされていた GANTT は、困難が生じたときにすぐに決断を下さなければならないことが多くなり、受け入れられなくなっています。これは、自分のプロセスを可視化し、プロジェクトの進捗状況を分析するために必要なメトリクスがリアルタイムに表示されていなければできないことです。だからこそ、バリューストリームマネジメントが必要なのです。個々のプロセスを評価できる柔軟性と、Just in Time のアプローチで自分の役割に適した測定基準を持つことができるバリューストリームマネジメントこそが勝者となります。

2021/3/23 - 読み終える時間: 6 分

How to deliver secure code more frequently の翻訳版です。

安全なコードをより頻繁に提供する方法

2021年3月22日

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

ソフトウェア・デリバリー・パイプラインにおいて、セキュリティは全員の責任です。アプリケーション・セキュリティと継続的デリバリーを組み合わせて、全体的にセキュアな DevOps ソリューションを構築する必要があります。ここでは、その方法を説明します。まず、同じページにたどり着くための定義を説明します。

継続的インテグレーション／継続的デプロイメント (CI/CD) パイプライン

CI/CD とは、コードの変更をより頻繁に、より確実に行うための手法の集合体です。CI/CD パイプラインは、HCL Launch のようなツールを使ってこれらのプラクティスを自動化します。

継続的インテグレーションとは、複数の開発者が同一機能のために開発したコードを頻繁に統合し、エラーを早期に発見するための開発手法です。このプロセスには次のようなステップがあります。

• 開発者は、開発ボックスにコードを記述
• 開発者はコードをバージョンコントロールリポジトリにプッシュする
• 自動化サーバーは、チェックインを確認するためのビルドを実行し、すべてのユニットテストと統合テストを実行
• 自動化サーバーは、ビルドとテストの結果を開発チームと共有
• 障害が発生した場合、チームはその修正に取り組む

継続的デプロイメントとは、以下の条件が満たされた場合、準備ができ次第、すべての良いビルドをユーザーにリリースすることです。

• ビルドとユニットテスト、統合テストが成功した場合、そのビルドは UAT サーバーにデプロイされます
• UAT が成功した場合、ビルドは本番サーバーにデプロイされます

AppSec

AppSec (Application Security) とは、ソフトウェアの開発サイクルの中で、セキュリティの脆弱性を発見し、修正し、防止するプロセスのことです。セキュリティインシデントの85％はアプリケーション層で観測されており、また、脅威の数は毎年着実に増加しているため、ソフトウェア開発ライフサイクルの中で AppSec を持つことは重要である。アプリケーション・セキュリティ対策は、SDLCの初期段階でセキュリティ問題を特定して修正し、全体的な開発コストを削減し、安全なコードを提供するために実施されます。広く使用されているアプリケーション・セキュリティ・テスト方法論は以下の通りです。

• Static Analysis Security Testing (SAST) - ホワイトボックステストで、ソースコードを内部から分析し、セキュリティの脆弱性を検出して報告します。問題点は、開発段階で発見することができるので、開発者にすぐにフィードバックできます。ツールやIDEプラグインが存在し、非実行状態やコードが実行されていない状態のソースやコンパイルされたバージョンのコードのセキュリティの欠陥を特定します。SAST レポートには、ファイル名、問題を修正するための行番号、偽陽性の特定など、必要な詳細情報がすべて含まれています。一般的で人気のある SAST ツールには、HCL AppScan Source、HCL AppScan on Cloud、Veracode、Checkmarx、SonarQubeなどがあります。SAST ツールは、開発者が問題を修正するために必要な情報を含むレポートを生成します。

• Software Composition Analysis (SCA) - アプリケーションにバンドルされている安全でないオープンソース・ライブラリーを特定し、これらのライブラリーが基本的なセキュリティ基準を満たし、組織にリスクをもたらさないことを確認するメカニズムです。SCAツールは、ソフトウェアライセンスや非推奨の依存関係も検出できます。一般的な SAC ソリューションとしては、HCL AppScan On Cloud、BlackDuck、Veracode、CheckMarx、WhiteSourceなどがあります。

• Dynamic Application Security Testing (DAST) - アプリケーションを外部からテストするブラックボックス・テストです。アプリケーションの実行中に外部からの攻撃をシミュレートすることで、セキュリティの脆弱性を探します。DAST は、アプリケーションの公開されたインターフェースに脆弱性や欠陥がないかをチェックすることで、外部からアプリケーションに侵入しようとします。いくつかの利点は、SAST では特定できないランタイムの問題を特定できること、技術に依存しないこと、偽陽性が少ないこと、サーバー構成の問題を特定できることです。利用可能な一般的な DAST ツールには、HCL AppScan Enterprise、HCL AppScan on Cloud、Veracode、Netsparker、Checkmarxなどがあります。

• インタラクティブ・アプリケーション・セキュリティ・テスト (IAST) - アプリケーションの実行中にコードを計測することで、アプリケーション内から動作し、セキュリティの脆弱性を検出して報告します。IAST は一般的に、自動/手動の機能テストに使用される際にQA環境に展開されます。 IAST レポートは、行番号を含む詳細な情報を提供し、開発者が問題を容易に修正し、偽陽性を特定するのに役立ちます。利用可能な一般的な IAST ツールには、HCL AppScan Enterprise、HCL AppScan on Cloud、Synopsis、Contrast Assessなどがあります。

AppSec による CI/CD パイプライン

AppSec のパイプラインは、DevOps の原則に従っており、DevSecOpsと呼ばれることもあります。セキュリティプラクティスを CI/CD パイプラインに含めることで、安全なコードをより頻繁に提供できます。

AppSec による継続的インテグレーション (CI)

• 開発者は、開発ボックスにコードを記述
• 開発者は、SAST IDEプラグインを使用してセキュリティテストを実行
• 開発者は、コードをバージョンコントロールリポジトリにプッシュ
• 自動化サーバーがビルドを実行してチェックインを確認し、すべてのユニットテストと統合テストを実行
• 自動化サーバーが、静的解析セキュリティテストのジョブを実行 (自動化)
• オートメーションサーバーがSCAジョブを実行 (自動化)
• 統合テスト、単体テスト、セキュリティテストの結果を、自動化サーバーが開発チームと共有
• 障害が発生した場合、チームはその修正に取り組む

AppSec による継続的デプロイメント (CD)

• ビルドとテストが成功すれば、ビルドは UAT サーバーにデプロイ
• DAST や IAST の実行 (自動化)
• UAT テストが成功した場合、ビルドはプロダクションサーバーにデプロイ

AppSec を CI/CD パイプラインに統合する手順

SAST をパイプラインに組み込む - SAST スキャンを自動化して、チェックインごとに実行することをお勧めします。SAST ツールのインクリメンタル スキャン機能を活用して、スキャン時間を短縮できます。

アプリケーションのオンボーディングは、CI/CD パイプラインにアプリケーションをオンボーディングするために、セキュリティの専門家と開発チームが一度にまとめて行う作業です。手順は以下の通りです。

• スキャン対象のファイル/パッケージをリストアップする。依存関係を省略もできます

• SAST ツールが必要とする設定ファイルを作成する

• スキャンを実行し、その結果をセントラル リポジトリにプッシュする

• 結果を中央リポジトリにプッシュするステップを自動化する

• スキャン結果をトリアージし、リポジトリで偽陽性をマークする

• スキャンのベースラインを設定します。その後のスキャンで新たな問題が発生すると、中央リポジトリでハイライトされます。これにより、解決されていない問題や再び現れた問題の再試行を避け、差分のみに集中できます。

• ビルドゲーティング (指定された基準を満たさない場合にビルドを失敗させる) を適用する前に、すべてのスキャンの結果を中央リポジトリにプッシュするプロセスを導入し、課題リポジトリに課題のマージ機能を持たせることが重要です。

SAST スキャンで留意すべき重要な点は以下の通りです。

• 最も正確で実用的な結果を得るためには、アプリケーションに特化したスキャン・ルール/コンフィグレーションとフィルターを作成することが重要です。これは、関心のある問題のセット (例：OWASPトップ10) に依存し、搭載されたアプリケーションの知識と、SAST の結果からシンク、ソース、テイントを理解する能力が必要です。

• SAST ツールは、コードが実行されるコンテキストを理解していないため、相対的に SAST はより多くの偽陽性を報告します。アプリケーションのコンテキスト、アプリケーションのユーザー、アプリケーションによって処理される情報、使用されている検証メカニズムを認識している人は、セキュリティ問題をトリアージし、偽陽性を識別してマークすることができるはずです。

• スキャンの自動化は、スキャンのベースライン化、問題のトリアージ、偽陽性の特定に続くプロセスの最後になります。スキャンを自動化するには、コマンドラインオプションかプラグインをオートメーションサーバーで使用します。

• スキャンが完了すると、欠陥追跡ツールにチケットを作成するプロセスが自動的に開始されます。fix-group (単一の修復タスクを必要とする問題) のような SAST ツールの機能を使用して、SAST 問題の束に対して単一のチケットを作成することが推奨されます。これにより、トリアージプロセスが簡素化され、迅速な修復が可能になります。

• 定義されたポリシーに応じて、ビルド/パイプラインを停止します。例: ((重要な問題の数 > 0) || (高い問題の数 > 5)) の場合、ビルドを停止する。

パイプラインへのDAST - コードのチェックインごとに、あるいは、1週間のうちの特定の日に、あるいは、アジャイル スプリントの特定のステージに到達したときに、DAST スキャンを実行したいと思うでしょう。DAST ツールのインクリメンタル スキャン機能を活用して、スキャン時間を短縮することをお勧めします。

DAST スキャンについて知っておくべき重要なこと

• アプリケーションのオンボーディングは、アプリケーションの開始 URL を特定し、記録されたログインシーケンスを生成してスキャンに含め、精度と速度のためにスキャン構成を調整する必要がある1回限りのアクティビティです。これはアプリケーションによって異なるため、スキャンの設定を行う担当者は、アプリケーションのコンテキストを把握する必要があります。

• Postman や SOAPUI などの API クライアントツールを使用した機能テストの際に、プロキシサーバー経由でキャプチャーされたトラフィックを含める必要がある Webサービス (例：REST API) をスキャンすることも同様に重要です。

• パイプラインを実行するたびに、アプリケーションの開始 URL を変更しないことが重要です。パイプラインが実行されるたびに、オートメーションサーバーーがアプリケーションを同じボックスにデプロイする必要があります。そうしないと、実行のたびにログインシーケンスが再生成され、スキャンに追加されることになります。

• 不具合追跡ツールでチケットを作成するプロセスを、スキャン完了時に自動的に開始させる。

• ポリシーに応じて、ビルド/パイプラインを停止する。

アプリケーションセキュリティを CI/CD パイプラインに適用することで、組織は以下のような一般的な問題を解決できます。

• 人的介入の削減 - 自動化により、退屈なプロセスから手作業を取り除くことでヒューマンエラーを削減します。

• セキュリティ問題の早期発見 - SDLCの早い段階でセキュリティテストを導入することで、脅威や脆弱性をより早く発見し、対処できます。

• 継続的な脆弱性のトリアージ - 自動化されたスキャンとチケット作成により、セキュリティエンジニアと開発者は、どれが直ちに対処しなければならないか、誰がその問題を解決する責任があるかを決定できます。

• 責任の明確化 - 自動化は、ソフトウェアのデプロイメントにおけるセキュリティの不確実性を取り除きます。セキュリティを移行すると、誰が何に責任を負うのかが混乱しますが、自動化されたスキャンは、開発のその段階で責任を負う当事者のための修復オプションを提示できます。

HCL Software のセキュアな DevOps ソリューションの詳細については、HCL Software DevOps ポートフォリオをご覧ください。

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

Why we joined the Value Stream Management Consortium の翻訳版です。

HCL Software がバリューストリームマネジメントコンソーシアムに参加した理由

2021年3月19日

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

このニュースをご存知ですか？HCL Softwareは、バリュー・ストリーム・マネジメント（VSM）の採用、標準化、革新を推進することを目的として設立された組織、バリュー・ストリーム・マネジメント・コンソーシアム（VSMC）の創設メンバーです。VSMCは、ベンダー、実務者、ソートリーダーを集め、VSMに関する情報や教育をワンストップで提供する組織です。

HCL Software では、DevOpsの実践を進め、組織がその潜在能力を最大限に発揮するためには、バリューストリームマネジメントが不可欠であると考えています。VSMCに参加したのは、VSMに対する認識とベストプラクティスを業界に浸透させ、DevOpsの「次」を先導するためです。

"HCL Software DevOpsの製品管理・開発ディレクターであるブライアン・ムスコフは、「バリューストリームマネジメントは、必ずしも新しいコンセプトではないと、誰もが認識できると思います」と述べています。今までと違うのは、"Day 1" と呼ぶべき多くの問題、つまりCI/CDやテスト自動化に関する基礎的な問題を解決したことです。私たちが一緒に仕事をしているお客様やこの分野のリーダーたちの多くは、次の課題、つまり "Day 2" に何があるのかを知りたがっています。我々の視点では、それはバリューストリームマネジメントです。我々は今、サイロでの最適化だけではなく、DevOpsツールチェーン全体での最適化を実現する技術を持っています」。

VSMCの最初の仕事は、リサーチプロジェクトでバリューストリーム・マネジメントの現状を把握することです。"The State of Value Stream Management Report "では、チームがバリュー・ストリーム・マネジメントの原則、プラクティス、メトリクスをどのように適用してバリュー・ストリーム・マネジメントに影響を与えているかを測定します。調査にはこちらからご参加いただけます。調査結果は5月初旬に公開される予定です。

VSMはまだ草の根的な普及段階にあるかもしれませんが、業界の専門家たちは、これこそがソフトウェア開発の未来であると考えています。

「今から 5年後、10年後に振り返ったとき、VSM はアジャイルや DevOps と並んで、ソフトウェア開発の主流となるでしょう」と Muskoff は述べています。「VSM市場がどのような形になるのか、そしてVSMCがどのように支援できるのか、期待しています」と述べています。

バリュー・ストリーム・マネジメント・コンソーシアムの詳細と会員登録方法については、以下の資料をご覧ください。

• バリュー・ストリーム・マネジメント・コンソーシアムのウェブサイト
• VSMCのメンバーになる
• VSMC発足のウェビナーを見る
• VSMC発足のプレスリリース

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

What is the team working on? Find out with Dynamic Swim Lanes in HCL Accelerate 2.3 の翻訳版です。

チームは何に取り組んでいるのか？HCL Accelerate 2.3 のダイナミック・スイムレーンで確認しよう

2021年3月18日

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

"Dynamic Swim Lanes"は、HCL Accelerate 2.3 でリリースされた新しい驚くべき機能で、チームは異なるディメンションで起こっているすべてのことをマクロレベルで見ることができます。この拡張バージョンのスイムレーンでは、以下の方法で作業を見ることができます。

• オーナー
• 優先度
• タイプ
• リリース
• スプリント
• エピック

動的なスイムレーンは、リスク分析、レトロスペクティブ・ビュー、ビジネスとのディスカッション、ボトルネックの特定、適切なアイテムへの集中など、様々な場面で役立ちます。これにフィルタリングと検索機能を組み合わせることで、任意の項目を絞り込むことができます。

HCL Accelerate 2.3では、折りたたみ可能なフェーズ、行をクリックしてすべてのドットを表示する機能、行を上部に固定する機能など、いくつかの素晴らしい機能強化を行いました。新しいダイナミックスイムレーンが解決できる一般的な問題点を見てみましょう。

期日に間に合うのか？

ほとんどの開発チームがこの問題に直面しています。エピックのような大きなアイテムの優先順位はわかっていても、その進捗状況が誰にもわからないのです。これは通常、状況確認のためのミーティングを意味しますが、最悪の場合、手遅れになるまでリスクを指摘できず、リリースを延期しなければならないこともあります。ツールの中には、このようなデータを非常に限定的に見ることができるものもありますが、多くの動きのある部分をまとめて表示することはほとんど不可能です。HCL Accelerateの新しいダイナミックスイムレーン機能を使うことで時間を節約できます。これにより、どのユーザーも、何が完了したのか、何が現在作業中なのか、何が次なのかを異なる次元で正確に見ることができます。より高いレベルの画像を見ることができるので、誰もがリスクを評価し、次の最善の決定を下すことができます。

作業量が多すぎるのでは？

このような疑問をお持ちの方は、決して一人ではありません。バリューストリームは、お客様に大きな成果をもたらす多くのミクロな価値の断片の合成物です。HCL Accelerateではこのすべてのマイクロデータを集約することができるため、パイプラインの比類のないビューを引き出すことができます。直前の四半期と、チームが取り組んでいたすべてのことを見ることができるのは衝撃的です。あるお客様は、四半期ごとに14個のEpicに取り組んでいたことがわかりましたが、これでは1つのピースも完成せず、半分または下降したEpicがたくさんできてしまいます。このお客様は、ダイナミックスイムレーンを使って、ビジネスとチームを調整し、いくつかのエピックにのみ集中することで、お客様にとってより良い結果を得ることができました。

優先度の高い項目に取り組んでいるのか？

優先度」のスイムレーンをクリックすると、最優先事項がどこにあるかがすぐにわかり、スタンドアップでより深い会話ができるようになりました。管理者は、お客様にとって重要なバグが必要な注意を払っているかどうかを簡単に確認でき、優先度の低い項目が先に行われていないかどうかを確認できます。

ダイナミック・スイムレーンやHCL Accelerate 2.3の他の新機能を実際に見てみたいですか？私たちのウェビナーに参加して、ライブデモをご覧ください。

2021/3/17 - 読み終える時間: ~1 分

HCL Software は DevOps を支援するソフトウェア群を開発・販売していますが、製品管理部門長の Brian Muskoff による、15分間の製品戦略解説がご覧になれます。

• TechStrong TV Live - Features Brian Muskoff, Director of Product Management, HCL Software DevOps - YouTube