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

Processes as Code in HCL Launch の翻訳版です。

HCL Launch における “Process as Code”

2020年10月28日

著者: Hayden Schmackpfeffer / Product Manager

導入とユーティリティー

HCL Launch version 7.1.1.0 で追加されたエキサイティングな新機能の1つは、Web UI の外でアプリケーションやコンポーネントのプロセスを設定できることです。HCL Software の “Process as Code” フォーマットにより、開発チームはプロセスを定義し、簡単に変更可能なフォーマットで保存することができます。

HCL Launch サーバーには、いくつかのコマンドで構成されたユーティリティである Process as Code Compiler がバンドルされています。その主な目的は、Launch サーバーと対話し、PAC フォーマットと Launch サーバーによって理解される JSON フォーマットの間で変換することです。

最も便利なコマンドは upload と download です。これらのコマンドには、download-component-process、download-application-process、upload-component-process、upload-application-process の 4つがあります。

ダウンロードコマンドは、Launch 内のプロセスの特定のバージョンを指し示し、そのプロセスをダウンロードし、PAC 形式に変換して保存します。

download-<process-type>-process <user-name> <server-url> <process-id> [<version>|latest] output.pac

アップロードコマンドは逆のことをします; アップロードコマンドはローカルの PAC ファイルをサーバーが期待する JSON フォーマットに変換し、指定されたプロセスの新しいバージョンとしてアップロードします。

upload-<process-type>-process <user-name> <server-url> <process-id> <next-version | latest> input.pac

pacc スクリプトはローカルに保存されている Launch JSON ファイルを PAC フォーマットに変換し、 ccap スクリプトは PAC から JSON フォーマットに変換します。

基本的な構文

PACC ユーティリティの README には、私たちが定義したカスタム構文の詳細な説明が含まれていますが、ここでは基本的なことを説明します。

• "start" と "finish" は、プロセスの入口と出口を表すために使用されます。
• "start " は、定義されたステップを呼び出すために使用されます。
• "plugin step is" は、ステップを定義し、設定します。この一般的な構文は任意のプラグインコマンドを指定することができ、"shell" のような一般的に使用されるステップのための短縮記号があります。
  • "plugin" は使用するプラグインを指します。
  • "command" は、そのプラグインの中で使用する特定のプラグインステップを指します。
  • "on [success | failure | complete]" は、特定のステップが終了した後に実行されるその後のステップを定義する。
  • "property " = " は、プラグインのステップフィールドの値を指定します。

ここでは、シンプルな Tomcat ウェブアプリケーションのアーティファクトセットをダウンロードし、Tomcat プラグインを使用してアプリケーションをデプロイする小さなコンポーネントプロセスの例を示します。

start is
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
on success
    start "Deploy Tomcat Application"
end

plugin step "Deploy Tomcat Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "exampleTomcatUser"
    property "tomcatPassword" = "${p:environment/secureTomcatPassword}"
    property "tomcatContext" = "/TestA"
    property "warFile" = "./TestApp.war"
    property "configFile" = ""
on success
    finish
end

この例では、Deploy Application ステップのための特定のプロパティを明示的に定義していますが、成果物のダウンロードコマンドは基本的に空のままにして、ステップのデフォルト値を使用しています。PAC プロセスは HCL Launch に直接アップロードされ、サーバーが理解できる形式に変換されているので、プロパティを参照することができます。

始めるには、既存の Launch プロセスを PAC フォーマットに変換するためにプロセスのダウンロードコマンドを使用し、PAC の変更の出発点として使用することをお勧めします。

私は現在、開発用 Launch サーバー上のデプロイメントプロセスを Processes as Code とカスタム githook を使って管理しています。サーバー上で管理したいプロセスは、以下のディレクトリ構造を使って「deployment-processes」リポジトリに格納しています。

Deployment-processes/<processType>/<nameOfComponentOrApplication>/<ProcessID>.pac

これにより、変更した .PAC ファイルのパスには、コミット時に処理をアップロードするために githook が必要とするすべての情報が含まれていることが保証されます。この例では、ブランチにコミットしたらすぐにアップロードするために post-commit フックを使用していますが、toy 以外の例では、git サーバー側の pre-receive フックや post-receive フックのほうが適切です。

下の githook の例は python で書かれたもので、pexpect ライブラリを使用しています。現在のバージョンの PAC ユーティリティでは、Launch サーバーとやりとりするときにパスワードを手動で入力しなければならないという事実を回避しています。

#!/usr/bin/env python3 
from subprocess import check_output
import pexpect
import json
TYPE = 0
NAME = 1
ID = 2
username = ''
password = ''
serverUrl = ''
# returns tuple of type, name, processId
# assumes files are appropriately structured
def parseTargetsFromFile(filepath):
    #component/testComponent/175427f6-0a8b-93b4-d73a-6a8ba534b060.pac
    targets = filepath.split('/')
    filename = targets[ID]
    return targets[TYPE], targets[NAME], filename[:filename.index(".")]
def uploadProcess(cmd):
    child = pexpect.spawn(cmd)
    try:
        i = child.expect([pexpect.TIMEOUT,'password:'])
        if i == 0:
            print("Got unexpected output: %s %s" % (child.before, child.after))
        else:
            child.sendline(password)
        child.read()
    except:
        print("Problem encountered: ")
        print(str(child))
def uploadChangedProcesses():
    # git diff-tree -r --name-only --no-commit-id HEAD
    changedFiles = check_output(['git', 'diff-tree', '-r', '--name-only', '--no-commit-id', 'HEAD']).decode()
    lines = changedFiles.splitlines()
    for line in lines:
        print(f"uploading pac file: {line}")
        line = str(line)
        targets = parseTargetsFromFile(line)
        cmd = buildCommand(targets, line)
        uploadProcess(cmd)

def buildCommand(targets, filename):
    return f"upload-{targets[TYPE]}-process {username} {serverUrl} {targets[ID]} latest {filename}"
if __name__ == "__main__":
    with open('conf.json') as confFile:
        conf = json.load(confFile)   
        username =  conf['username']
        password = conf['password']
        serverUrl = conf['url']
    uploadChangedProcesses()

上記のスクリプトをポストコミットフックとして保存し、私のPACファイルに修正をコミットすると、それらのファイルは、以下のように私のLaunchサーバー上で同じIDを持つプロセスの最新バージョンとしてアップロードされます。

HCL Launch 7.1.1.1 の他のアップデートと一緒に、新しい "Processes as Code "機能が実際に動作しているのを見たい方は、こちらから登録してウェビナーに参加してください。

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

Identify the best offer using A/B Testing in Unica Interact の翻訳版です。

Unica Interact の A/B テストを使用して最適なオファーを特定する

2020年10月28日

著者: Gurpreet Singh / Test Lead for HCL Interact

すべてのマーケッターは、より良いクリック率、簡単なコンバージョン、解約率の低下、顧客の記憶に残る体験の創造を目指しています。そのためには、メールの送信、CTA の設計、ランディングページの設計、さらにはオファーの送信中に行う決定は、ターゲットとする顧客に沿ったものでなければなりません。何がうまくいくのか、何がうまくいかないのかという仮定を避けるために、スプリットテストとしても知られている A/B テストは、Webページ、アプリケーション、オファー、メール、または他のマーケティング資産の2つのバージョンを利用して、どちらがより良いパフォーマンスを発揮するかを分析し、理解するマーケティング手法です。

A/B テストは、異なる顧客が様々な状況に異なる反応を示す可能性があるため、不可欠です。例えば、「今すぐ購入」ボタンをページの中央に設置したいと思う人もいれば、右下に設置したいと思う人もいるでしょう。しかし、どちらが最もコンバージョンにつながるのでしょうか？それが A/B テストが提供できる答えです。

Interact での A/B テストの仕組み

Interactでは、A/B テストとは、すべてのプロパティが固定されているが、1つのパラメータだけが変化する処理ルールに対して行われるテストのことです。12.1 では、このパラメータは、オファーとそのオファー属性の組み合わせです。ルールの A/B テストでは、各変動パラメータはオーディエンス分布のパーセンテージを持つ 1 つのブランチを表します。設定されたテスト期間におけるオファーに対するオーディエンスの反応に応じて、その処理ルールに最適なオファーを選択することができます。

トリートメントルールの A/B テストを設定する

• ルールメニューに新しいオプション A/B が追加され、これを使用して A/B テストペインに直接アクセスすることができます。

• [A/B テスト] タブで［有効］チェックボックスを選択すると、ルールの A/B テストを有効にすることができます。
• ルールの A/B テストを有効にすると、ベースのルールから詳細をコピーしてデフォルトのブランチが追加されます。

• 「ブランチの追加」をクリックして、ブランチを追加することもできます。

• A/B テスト内で一意でなければならないブランチ名を変更することができます。
• ブランチは有効にしたり、無効にしたりできます。有効にしたブランチだけが、実行時にA/B テストに参加します。
• Sampling %はブランチ間のオーディエンスの分布です。
• また、Offer AttributesにExpression を追加することもできます。オファー属性に式を追加すると、「Offer Attributes」欄にその数が表示され、詳細を確認するためのドロップダウンが表示されます。

• また、A/B テストを有効にする「テスト期間」を設定することもできます。
• デフォルトブランチとは、A/B テストのブランチから分岐したもので、テストが終了すると、つまり有効期限が切れた後に実行されます。セルコード、オファー、またはパラメトリック化されたオファー属性のベースルールとは完全に独立しています。Unica 12.1 リリースでは、デフォルトブランチを指定する必要があり、常に有効にしておく必要があります。今後のリリースでは、デフォルトブランチの選択は、ブランチのパフォーマンスに自動的に依存するようになります。
• ルール一覧ページでA/B テストの詳細を保存すると、ルールに対してオレンジ色の「A/B テスト」アイコンが表示されます。

• ルールリストの編集モードまたは表示モードで「A/B テストルールのみを表示する」チェックボックスを選択することで、A/B テストルールのみをフィルタリングすることができます。

• A/B テストルールのみ表示」を有効にすると、限られたカラムのセットが表示され、セクションを拡大することで、サンプリング率やオファー属性の数などの分岐の詳細を式で確認することができます。

• また、「A/B テストルールのみ表示」フィルターでは、セグメントやゾーンで検索することで、ルールをさらに絞り込むことができます。

• A/B テスト付きインタラクティブチャンネルがデプロイされると、deploymentInfo.jspにルールの A/B テストの詳細も表示されます。

• A/B テストデータを Systems テーブルに保存するために、Design Time(Campaign) Schema の UACI_ABTest と UACI_ABTestBranch の 2 つのテーブルが新たに追加されました。

A/B テスト結果の分析

次の方法で、ブランチのパフォーマンスを分析し、そのブランチのオファーを処理ルールのデフォルトオファーに設定することができます。

1. ブランチのパフォーマンスをチェックするには、顧客は文字列データ型のカラム "ABTestBranch "をターゲットのCHStagingとDTLContactHistテーブルに追加する必要があり、その後、顧客はクエリを実行するか、カスタムレポートを作成して、ブランチのパフォーマンスを決定し、ルールのデフォルトブランチを設定することができます。

2. 顧客 は Cognos や Birt レポートを設定し、「Interactive Offer Performance Over Time」レポートをチェックして、オファーパフォーマンスのサマリーを確認し、どのブランチのオファーがうまくいっているかを判断することができます。

Unica Interact で A/B テストを実施できるようになることで、オファーの比較分析を利用して、顧客は自社の処理ルールに最適なオファーを特定することができます。これにより、お客様はより顧客に焦点を当てた意思決定を行うことができ、最終的にはオファーのコンバージョン率を向上させることができます。その他のご質問がございましたら、お気軽にお問い合わせください。

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

What's new in HCL Launch 7.1.1.0 の翻訳版です。

HCL Launch 7.1.1.0 の新機能

2020年10月27日

著者: Hayden Schmackpfeffer / Senior Developer

HCL Launch バージョン 7.1.1.1.0 では、これまで以上にデプロイメントの経験を向上させるために、信じられないほどの新しい機能と強化が追加されています。このリリースに含まれている機能セットは、デプロイメントの表示と設定がこれまで以上に簡単になり、QOL を向上させます。

HCL Launchアプリケーションとコンポーネントのプロセスを人間が読みやすい速記法で定義できる新しい言語を作成しました。当社の "Processes as Code" 言語を利用するために、"Tools" セクションに Processes as Code コンパイラが含まれており、既存のプロセスをダウンロードしてPACフォーマットに変換したり、指定したLaunchサーバに直接PACファイルを翻訳してアップロードすることができます。より詳細な情報は、近日中に詳細なフォローアップ記事でご紹介します。

新しい "Get Started" ページでは、HCL Launch と HCL Software DevOps に関する膨大な情報のリポジトリを、あなたの指先に置いています。アプリ内のチュートリアルの代わりに、このページでは、HCL Launch のチュートリアルのほか、ドキュメント、リリースノート、ビデオコンテンツ、そしてこのブログへのリンクが用意されています。ナビゲーションバーの "HCL Launch" セクションをクリックするか、ヘルプドロップダウンの "Get Started" オプションをクリックして、いつでもこのナレッジストアにアクセスしてください。

このリリースでは、便利なメールリンクを介して承認タスクに対処する機能を使用して、チームのデプロイメントを外出先でも管理することができます。バージョン7.1.1.1.0に含まれているデフォルトの通知テンプレートには、電子メールを受信したユーザーに関連付けられた応答URLが埋め込まれています。

このリンクをクリックすると、ユーザーは割り当てられたタスクを承認または拒否するためのモバイル応答ページに移動します。このリンクは、添付されたタスクへの応答にのみ使用でき、5日後に有効期限が切れます。既存のメールテンプレートはアップグレード時に保存されるため、お使いのサーバーがv7.1.1.1.0以前にインストールされていた場合は、承認とタスク通知のテンプレートXMLを変更して、応答URLを含める必要があります。この設定方法については、サポートチームまでお問い合わせください。

設定タブの新しいページでは、すべてのタグ付け可能なオブジェクトを俯瞰的に見ることができます。オートメーション設定の下の "タグ "ページには、エージェント、アプリケーション、コンポーネント、またはリソースのために作成されたすべてのタグを一覧表示するテーブルがあります。

これらのテーブルは、特定のタグのセットを表示するためにフィルタリングしたり、既存のタグ定義を変更したりすることができます。既存のタグの名前、説明、および色を変更することができ、そのタグは、タグが与えられたすべてのオブジェクトで更新されます。

また、ライセンス設定をシステム設定ページの外に移動し、ライセンスサーバー接続に特化した新しいページに移動することで、ライセンス設定を刷新しました。このページでは、接続の詳細を入力し、HCL Launchがライセンスサーバーへの接続に成功すると、ライセンスの使用状況に関する情報が表示されます。

11月5日（木）午後3時（米国東部標準時）に開催されるウェビナーでは、これらの新機能を実際にご覧いただけます。ライブ・ウェビナーに参加できない場合でも、ご登録いただければリプレイへのリンクをお送りします。ウェビナーに登録するには、ここをクリックしてください。

HCL Launchがあなたの生活をどのように楽にするかについて、他にもアイデアがありますか？こちらのアイデアポータルに投稿してください。

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

Enhancing Test Results Via Unified Reports の翻訳版です。

統一されたレポートによるテスト結果の改善

2020年10月26日

著者: Eshita Gupta / User Experience designer for HCL Software

ソフトウェアでは、製品の最適な品質が常に優先されています。

予期せぬ状況や期待される状況下でのソフトウェアコンポーネントの評価は非常に重要です。そのため、テストチームは製品の品質を評価することで、ビジネスの成長に大きな役割を果たしています。

テスターであるあなたは、レポートに迷い、メールボックスに書類をダンプしてしまうことが何度あるでしょうか。それはよくあることで、テスターはゼロからスタートしなければならないことが多いです。

HCL OneTest Server の新しい統一レポートにより、テスト結果を簡単にアクセスして分析できるようになりました：このレポートは、機能テストとWeb UIテストレポートの機能を統合し、HCL OneTest UIのすべてのテストタイプをサポートしています。広範囲で直感的なデザインを使用することで、統一レポートはテスト結果を分析するための以下の機能を提供します。

テスト実行の包括的な詳細を表示することで、テストの問題点を素早く深く掘り下げることができます。

• 複雑な複合テストから特定のテスト反復の詳細までのドリルダウン
• テスト実行からキャプチャしたスクリーンショットをカルーセル形式で表示します
• テスト実行からのライブレポート
• レポートからテスト結果をHTML形式でエクスポートすることができます

クイックビューアプローチ

レポートの最初のセクションでは、実行された結果が一目でわかるようになっています。これは、資産の健全性を素早く分析し、チーム内で同じことを伝えたいマネージャーやテスターに最適です。

結果レポートを素早く表示する方法について詳しく説明します。

• ドーナツチャートは、結果の新鮮で迅速なビューを提供します
• テストの合格・不合格の相対的な割合をカラーコードで表示する
• 大規模データの要約に役立つ
• 解析時間の短縮
• さらなる調査のために報告書を掘り下げるためのアンカー

サマリーとリソースタブ:新しい統一されたレポートで、重要な情報が前面に出て、ユーザーの体験を向上させるのに役立ちます。

サマリータブ

階層的アプローチ

階層構造により、作業と依存するテスト資産の明確な権限が確立されます。複雑なアセットをシンプルな構造で見ることができます。

視覚的な階層構造は、ユーザーの流れを簡単かつ直感的にナビゲートします。

イテレーション: 各データセットをイテレーション形式で見ることができます。

結果比較 - あらゆるタイプのデータの実際の結果と期待される結果の比較が、これまで以上に簡単になりました。さまざまなタイプのデータについては、次の表の例を参照してください。

フィルター: 資産の状態をフィルタリングすることで、故障の原因を簡単に掘り下げることができます。

差分だけを表示: チェックボックスを使用して、無関係な情報を除外することができます。

マイクロスコープ的詳細

ユニファイド・レポートは、データの拡大率がはるかに高く、誰でも階層の各レベルで資産の詳細を検出することができます。アコーディオンを拡大しなくても、関連するアイコンにカーソルを合わせることで、個々のアセットの微細な詳細を確認することができます。

アイコンにカーソルを合わせると、以下のような詳細を見ることができます。

• テストステップが何回失敗したか？
• 実行中に使用されたブラウザは？
• どのホストが関連付けられていたか？
• テストの実行にどれくらいの時間がかかりましたか？

スクリーンショットのキャプチャ。記録および再生中に、スクリーンショットがキャプチャされ、各テストアセットに添付されます。キャプチャしたすべてのスクリーンショットを説明とともにカルーセルで簡単に見ることができます。

ライブレポート

ライブレポート機能の助けを借りて、あなたはレポートを見るために実行するための完了を待つ必要はありません、リフレッシュせずにライブレポートを実行していると、経験がシームレスになります。

エキスポート

あなたの都合に合わせてレポートをエクスポートし、チームで共有することができます。レポートとエクスポートのカスタマイズされたビューは、統一されたレポートのために長い間要求された機能です。今、あなたは希望する形式でレポートをエクスポートすることができます。エクスポートされたテストレポートは、インタラクティブなHTML形式とPDF形式で利用できます。将来のリリースでは、他のフォーマットもサポートしています。

オートヒーリング

オートヒーリングは本製品の最も奥深い機能です。統一されたレポートでは、「オートヒーリング」タグでレポートの状況を知ることができます。

HCL OneTest は、リリースのたびにレポートを継続的に強化しています。

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

4 Features of a Cloud-Native Digital Experience の翻訳版です。

クラウドネイティブな HCL Digital Experience の4つの特長

2020年10月27日

著者: HCL Digital Experience Team

デジタル・エンタープライズ・プラットフォームをクラウドネイティブ環境でホスティングすることは、スピード、俊敏性、拡張性、統合性、コスト削減など、夢のように聞こえます。しかし、クラウド・ネイティブ環境とクラウド・ホスト環境との違いは何か、また、その違いは企業のワークフロー・ソリューションにどのように表れているのでしょうか。

ここでは、クラウドネイティブの HCL Digital Experience をユニークなものにしている点と、その機能の違いがなぜ重要なのかを見ていきましょう。

クラウドネイティブとは、単なるデジタル・プラットフォーム以上の意味がある

クラウドネイティブとは、環境だけではなく、設計と導入のアプローチを意味します。クラウド技術をより進歩的に利用することで、これまで受け入れられてきたメリット（主にストレージと利便性）を超え、クラウド上で実行するために特別に設計されたアプリケーションを特徴としています。

これらのアプリケーションは、クラウドに「ネイティブ」であること、つまり初日からクラウド用に構築されていることから、オンプレミスやクラウドでホスティングされているプラットフォームでは容易には実現できない規模と展開速度を持っています。クラウド・ネイティブ・システムを採用している企業は、これまで以上に時間が重要視され、常に進化し続けるデジタル・ワークスペースで成功するために構築されたデジタル・エクスペリエンスを利用することができます。

クラウドネイティブとクラウドホスティングは同じではありません

当たり前のように聞こえるかもしれませんが、この2つのシステムの違いを理解することで、クラウドネイティブ・インフラストラクチャーの利点に光を当てることができるため、言及する価値があります。

クラウド・ホスト型アプリケーションは、オンプレミス環境向けに設計されていますが、サービス・プロバイダーによってクラウドからデプロイされ、管理されています。このモデルは、もともとはプレミスのシステムを資本コストから運用コストへと移行させることで、企業の資本コストの負担を軽減したいという思いから生まれたものです。

クラウド型システムとは、クラウドのストレージや管理の一部の側面と、セキュリティや保守、インフラのレガシーシステムを組み合わせた妥協点のことです。しかし、クラウドホスト型サービスは、更新プロトコルが煩雑で時間のかかるものであり、必要に応じて拡張することが難しくなる可能性があります。

コンテナとマイクロサービスがデプロイとデリバリーをスピードアップする方法

クラウドネイティブアプリケーションは、一般的にコンテナにパッケージされたマイクロサービスで構成されています。マイクロサービスとは、アプリケーションが単機能のサービスで構成されたソフトウェアの一形態であり、非常にきめ細かく軽量な操作を可能にします。他のアプリケーションに依存したり、影響を与えたりすることなく、自分の仕事をすることができます。これにより、開発者は、より広範囲の操作に影響を与えることなく、特定のアプリケーションの問題に対処することができます。

コンテナは、マイクロサービスのようなアプリケーションを実行するためのすべてのものを保持することができるポータブルなファイルシステムです。この2つは、どちらも1つのことを行うことを意図して設計されているため、相性が良いのです。

これは、アプリ内で発生する可能性のある問題やバグをより速く、より具体的に解決することができることを意味します。また、大規模なシステム更新やオーバーホールを待たずに、特定のアプリケーションの更新を行うことができることも意味します。このようにして、クラウドネイティブ・ソフトウェアは常に具体的に改善することができます。

流動的なアーキテクチャーの利点

クラウド・ネイティブ・アプリケーションとサービスは、その適応性と柔軟性の高さから、より多くの企業で採用されています。アプリはアジャイルで自動化され、必要に応じて簡単にスケールアップやスケールダウンができるように開発されています。

マイクロサービスとそれが保持するコンテナの粒度が高いため、問題が発生した際には常に直接的な対応が可能で、レガシーシステムよりも弾力性のあるシステムを継続的に更新することができます?

クラウドネイティブは、サービス、トラブルシューティング、アップデートに多くの時間と費用を必要とするクラウドホスト型やオンプレミス型のプラットフォームと比較して、インフラストラクチャーやメンテナンスに関しては、システムへの負担が少ないです。

最終的には、今日のビジネス環境のスピードにマッチし、必然的に高速化していく中で歩調を合わせることができるデジタル・エクスペリエンスを実現することができます。デジタル・エクスペリエンスの変革とは、単に消費者の目線に立ったタッチポイントをきれいにするだけではなく、関連するすべてのコンテンツ、情報、体験を組み合わせて、オーディエンスにとって意味のあるものにすることです。HCL Digital Experience は、安全で、いつでも利用可能で、ビジネスのニーズに合わせて拡張可能なプラットフォームを必要とする企業にとって、ビジネスに不可欠なDigital Experienceのために信頼されています。

HCL Digital Experience では、ハイブリッドでクラウドネイティブなアーキテクチャーを採用できるようになったため、管理者は既存のオンプレミス環境で新しいコンテンツ制作やヘッドレスAPI機能を提供することができます。移行の必要はありません。当社は、市場で最も広範なクラウドネイティブ・プラットフォームのサポートを提供しており、最近では Azure EKS のサポートも追加されたため、デプロイを 10倍速で行うことができます。

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

2020年9月22日にポストした「HCL Digital Week 2020 開催決定」でお知らせしました HCL Digital Week 2020 ですが、日本語での開催内容をご案内する準備が整いました。

HCL Digital Week 2020 は HCL Software のコラボレーションと Web Experience を提供する Digital Solutions の最新情報をお届けするオンラインイベントです。

日本語版は 2020年12月1日 (火) ～ 4日 (金) の午後に開催されます。ウェビナー形式で開催し参加費無料です。自由退出・再入室できますので、お気軽にご参加いただければと思います。

詳細・お申し込み: HCL Digital Solutions Web Event – Digital Week 2020

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

Key Financial Findings from Ponemon Institute’s “Application Security in the DevOps Environment” の翻訳版です。

Ponemon Institute の「DevOps環境におけるアプリケーションセキュリティ」の主な財務上の知見

2020年10月23日

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution

IT支出の減少

ご存知のように、2020年は誰にとっても典型的な年ではありませんでした。以前、世界的な大流行がIT支出に与える影響について書いたことがあります。ガートナー社は2020年7月のレポートで、今年の世界のIT支出は3.5兆ドル (366兆円)（2019年比7.3％減）に減少すると予測しています。

アプリケーションの脆弱性が増加している

バー、レストラン、旅行などの世界経済の一部の要素は、パンデミックの影響からの回復が遅れていますが、悪意のある行為者は休んでいません。

それを裏付ける最近の統計をご紹介しましょう。

• 今年初め、TechRepublic誌に掲載された調査では、メールによるフィッシング攻撃が2020年2月末から2020年3月末にかけて667％増加したことが明らかになりました。
• 特にアプリケーションセキュリティの分野では、Security Boulevard誌に掲載された別の分析によると、2020年5月/6月の期間に80%以上のアプリケーションが SQL インジェクション攻撃を経験していることがわかりました。
• 同レポートによると、少なくとも3分の1のアプリケーションには、少なくとも1つの深刻な脆弱性が含まれていることが判明しています。

開発者の燃え尽きが課題に

これに加えて、今年のハイパーデジタルの世界を動かすために必要な新しいアプリケーションやアプリケーションのアップデートの数が膨大な数になっています。Wall Street Journal が報告した2019年の調査では、大企業がデプロイしたアプリケーションの平均数は129個という驚異的な数になっています。そう、その数は129個です。

管理すべきアプリケーションの量が増えていることに加えて、以下の要因が開発者の燃え尽きを助長しています。

• Octoverse Spotlight のブログによると、COVID-19 の時代には、開発者の仕事の時間は、従来のビジネスウィークと週末に 1 日 1 時間拡大しています。
• 同じ調査では、アクティブユーザーあたりのプルリクエスト、プッシュ、作成された課題など、ほぼすべての開発者活動のメトリクスが上昇していることがわかりました。
• アプリケーションボリュームの増加に伴い、今年作成されたオープンソースリポジトリの数もそれに応じて増加しており、2019年3月から2020年3月までの間に 28%近く増加しています。

要約すると、あなたのような組織が直面しているのは、予算の減少、脆弱性の増加、作業負荷の増加です。あなたの組織が直面しているサイバーセキュリティの脅威に対処し続けながら、これらの問題にどのように対処することができるでしょうか？いつものように、情報、経営陣の協力、予算の確保が手始めに重要なポイントとなります。

Ponemon Institute レポートの調査結果を経営陣と共有する

Ponemon Instituteは、2020年10月に "DevOps環境におけるアプリケーションセキュリティ "と題した調査を発表しました。HCL AppScanがスポンサーとなっているこの調査には、AppSecとDevOpsに関連した財務数値の宝庫が含まれており、経営陣と一緒にアプリケーションセキュリティテストを実施する際に活用することができます。この包括的なレポートはこちらからアクセスできます。

以下に、レポートから得られる主な財務上の知見を紹介します。

脆弱性のあるアプリケーションに対する攻撃による平均的な経済的損失総額

Ponemonの調査では、過去12ヶ月間に、脆弱性のあるアプリケーションに対する攻撃の結果、平均1,200万ドル (13億円)のコストが発生しています。言い換えれば、そのコストは月に約100万ドル (約1億円)であり、効果的なアプリケーションセキュリティテストプログラムを持たない企業では、さらに高くなる可能性があります。

経済的損失の合計 - 最悪のシナリオ

調査に含まれている組織の中には、脆弱性のあるアプリケーションへの攻撃の結果、1億ドルを超える信じられないような経済的損失を被ったものもあります。この1億ドルという数字は、フロリダ州交通局がタフニッケルに提供した見積もりによると、州間高速道路を13マイル建設するのにかかる費用とされています。この数字が経営者の注意を惹かないのであれば、何の意味もありません。

IT、AppSec、DevOps の平均予算

回答者によると、組織の平均 IT 予算は 9,960 万ドルでした。平均して、組織の今年度の IT 予算の 25% はアプリケーションセキュリティ活動に費やされることになります。さらに、組織の今年の IT 予算の 20% は、DevOps 活動に費やされることになります。

セキュリティ予算と投資の原動力

回答者の51％が、投資収益率（ROI）の向上が、組織のセキュリティ予算と投資の意思決定の重要な推進要因であると回答しています。総所有コスト（TCO）の削減が重要な推進要因であると答えたのは29%にとどまりました。

成功への障壁

回答者の41%が、予算が不足しているためにアプリケーション・セキュリティ・プログラムが効果的に機能していないと答えています。

AppSec と DevOps のその他の戦略的および財務的傾向については、こちらから包括的なレポートにアクセスできます。

詳細はこちら

10月29日午前11時（米国東部標準時）／午前8時（米国太平洋標準時）に開催されるウェビナーにご参加ください。Ponemon Institute の Larry Ponemon 氏と HCL AppScan の Eitan Worcel が調査結果を分析します。ライブセッションの後には、リプレイを視聴することができます。また、アプリケーション・セキュリティ・テスト技術をご自身でテストするために、今すぐ HCL AppScan の無料トライアルをリクエストしてください。

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

Ponemon Institute and HCL AppScan Reveal State of Application Security in DevOps Environments の翻訳版です。著者の許諾を得て翻訳版を公開しています。

Ponemon Institute と HCL AppScan、DevOps 環境におけるアプリケーションセキュリティーの現状を明らかに

2020年10月20日

著者: Larry Ponemon / Chairman and Founder of the Ponemon Institute

はじめに

HCL SoftwareがスポンサーとなったPonemon Instituteの「Application Security in the DevOps Environment」調査の目的は、アプリケーションの脆弱性を迅速に検出し、優先順位をつけて修復する組織の能力をよりよく理解することでした。

そのため、Ponemon Instituteは、ITセキュリティ、品質保証、または開発業務に従事する626名の個人を対象に調査を実施しました。さらに、調査回答者の組織はすべて、アプリケーションのセキュリティテストを含むDevOpsアプローチを利用しています。

このブログの目的は、この調査で得られた主な結果を要約することです。包括的なレポートを無料で入手するには、こちらをクリックしてください。

調査結果のショーケース

このレポートには、アプリケーション・セキュリティの保護と DevOps の利用に関する説得力のある調査結果が満載されていますが、その中でも最も説得力のある調査結果は以下の通りです。

• 脆弱性のあるアプリケーションへの攻撃は、私たちが予想している以上にコストがかかります。脆弱性のあるアプリケーションへの攻撃は、予想以上にコストがかかります。過去 12ヶ月間に、調査対象となった組織は、脆弱性のあるアプリケーションへの攻撃の結果、平均で 1,200万ドルの経済的損失を被っています。
• 調査対象となった組織の中には、脆弱性のあるアプリケーションに対する攻撃の結果、1億ドルを超える驚くべき経済的損失を被った組織もあります。この 1億ドルという数字は、調査に回答した組織の平均的な IT 予算総額を表しています。
• 脆弱性のあるアプリケーションへの攻撃を特定するのに平均8ヶ月近くかかり、攻撃から回復するのに 6ヶ月かかることがあります。
• 平均して、ビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを受けていません。
• 回答者の 74%が、セキュリティ上の懸念を評価する必要があるコードのために、多くのアプリケーションの開発サイクルが遅れており、それが組織のリリース期限に影響を与えていると述べています。
• 回答者の 71%が、DevOps セキュリティプラクティスにおける可視性と一貫性の欠如が、最終的に顧客や従業員のデータを危険にさらすことになると回答しています。

肯定的な傾向

本調査はまた、アプリケーション・セキュリティと DevOps のいくつかのポジティブな傾向にも光を当てています。

• 組織は、アプリケーション・セキュリティと DevOps に多額の投資を行っています。本調査の回答者の平均1億ドルのIT予算のうち、約 2,500万ドルがアプリケーションセキュリティ活動に、さらに 2,000万ドルがDevOps活動に割り当てられています。
• 組織がセキュリティ予算と投資を決定する主な要因は以下の通りです。リスクの低減（回答者の 65％）、コンプライアンス/規制の遵守（回答者の 53％）、投資収益率（ROI）の向上（回答者の 51％） * 組織がアプリケーションセキュリティテストを実施する際には、アプリケーションセキュリティのテストを実施しています。
• 組織がアプリケーションセキュリティテストを実施する際には、DAST、SAST、IAST、SCA、ペネトレーションテストなど、様々なテスト手法を活用しています。
• 特に有望な兆候として、回答者の 49％が、コーディングプロセス内の脆弱性を特定するために開発者に権限を与えていると回答し、47％が、コーディングプロセスの安全性を確保するためのトレーニングを確実に実施していると回答しています。
• 回答者の 52%が、ソフトウェア開発ライフサイクル (SDLC) の各段階での脆弱性スキャンの自動化が組織にとって重要であると回答し、56%が自動化ツールを使用して迅速に脆弱性を修正することが重要であると回答しています。

改善点

最後に、本調査では、AppSec と DevOps の専門家がより効果的であり、さらなる進展が必要な分野がいくつか明らかになりました。

• すでに配備されている脆弱性のあるアプリケーションに対する攻撃の 50%以上を防ぐことができたと答えた組織は 1 つもなく、回答者の 45%は、そのような攻撃を防ぐことができたのは 15%未満であったと答えています。
• 脆弱性のあるアプリケーションに対する攻撃が発生した場合、組織は、平均して 40%しか攻撃を検知し、食い止めることができないと報告しました。
• 半数近くの組織が、四半期ごとに、またはそれ以上の頻度でアプリケーションをテストしていますが、回答者の 6%は、1 年ごとにアプリケーションをテストしていると回答しています。回答者の 25%が、計画されたテストサイクルがないと回答しています。
• 調査回答者にとって、脆弱性のあるアプリケーションに対する攻撃を防ぐための主な障壁は、人手不足でした（回答者の 63%）。また、アラート疲労は引き続き大きな懸念事項であり、回答者の40%が、AppSec の調査結果がノイズを発生させすぎて、効果的に管理できないと報告しています。
• 脆弱性を可能な限り早期に修正できていると報告している組織は、わずか 38% にすぎません。

詳細

上記で説明した調査結果の詳細な分析を確認するには、レポートをダウンロードしてください。また、2020年10月29日の午前11時（東部標準時）、午前8時（太平洋標準時）、(翻訳者注: 日本時間 30日、午前1時) に開催されるウェビナーにもご参加ください。Eitan Worcel と私が、この研究の結果をより詳細に分析します。ライブセッションの後、ウェビナーの録画が利用可能になります。

Larry Ponemon 氏について

Ponemon Institute 会長・創設者

Larry Ponemon 博士は、Ponemon Institute の会長兼創設者であり、プライバシー監査と責任ある情報管理（RIM）フレームワークのパイオニアです。Ponemon 博士は、米国連邦取引委員会のオンラインアクセス＆セキュリティ諮問委員会に任命され、ホワイトハウスから国土安全保障省のデータプライバシー・整合性諮問委員会に任命されました。また、プライバシーおよびデータセキュリティ法に関するカリフォルニア州の 2 つのタスクフォースにも任命され、Shared Assessments の諮問委員会のメンバーでもあります。ユニオンカレッジで博士号を取得。ハーバード大学で修士号を取得し、カーネギーメロン大学のシステム科学の博士課程に在籍しています。Ponemon 博士は、アリゾナ州ツーソンにあるアリゾナ大学で学士号を取得しました。公認会計士、公認情報プライバシープロフェッショナル。