AppScan: サードパーティ・コンポーネント・セキュリティ: 良いこともあれば、そうでないこともあるし、ひどいこともある。
2020/7/20 - 読み終える時間: 2 分
サードパーティーのコンポーネントが入っていないソフトウェアが今どきあるでしょうか。開発する側として、サードパーティーの安全性をどうやって担保すればよいのでしょうか。「サードパーティー製だったので気づきませんでした」は言い訳にならないでしょう。開発の利便性が高まる一方で、セキュリティー対策、特にサードパーティーコンポーネントに関することがますます重要になってきています。今回は Third-Party Component Security: The Good, The Not So Good and the Downright Ugly の翻訳版を掲載します。
サードパーティ・コンポーネント・セキュリティ。良いこともあれば、そうでないこともあるし、ひどいこともある。
2020年7月16日
著者: Shahar Sperling / Chief Architect at HCL AppScan
サードパーティのコンポーネント、特にオープンソースは、現代の開発努力として欠かせないものです。これらのコンポーネントは開発を加速させ、チームがコア技術のコード開発に集中できるようにしてくれます。
それはそれで良いことでしょう。
サードパーティ製コンポーネントを採用する際の課題は、コンポーネントの動作やセキュリティの問題も取り込まれることです。
挙動上の問題は通常、すぐに発見されます：コンポーネントの機能が使用されるにつれて、障害や予期せぬ結果が発見されます。挙動上の問題は、OO コミュニティによって回避したり、報告したり修正したりすることができます。
セキュリティの問題は発見しにくい
しかし、セキュリティ問題の場合はもう少し複雑です。なぜなら、セキュリティ問題を発見するのは予想外の使用方法であり、ほとんどの開発チームはセキュリティ上の欠陥を発見するために必要な固有のスキルを持っていないからです。脆弱性は、アプリケーションによって使用される機能に発生する可能性があります。しかし、多くの脆弱性は、コンポーネントによって公開されているが、アプリケーションによって使用されていない機能に悪用される可能性があります。このため、リモートの攻撃者によって悪用される可能性のあるコンポーネントが Web アプリケーションやモバイルアプリケーションで使用されている場合、脆弱性は特に危険なものとなります。
これはあまり良くないですね。マズいことです。
サードパーティ製のコンポーネントに脆弱性が確認されると、アップデートがリリースされます。これは完全に標準化されており、期待されていることです。しかし、あるコンポーネントがアップデートを提供したからといって、そのコンポーネントを使用するすべてのアプリケーションでアップデートが行われたとは限りません。
これは、物事が悪いだけではなく、醜いものになってしまうところです。サードパーティのコンポーネントのパッチが適用されていないことが原因で、ヘッドラインに載りたい人はいないでしょう。
チームは喜んでサードパーティ製の、ほとんどがオープンソースのコンポーネントを採用しますが、コンポーネントの迅速なアップデートには備えていません。私たちは自分のコードにコンポーネントを入れても、それを忘れてしまう傾向があります。結局のところ、自分のところで書いたコードには注意は払われるけれど、サードパーティ製のコンポーネントを採用している、ということで、サードパーティ製のコンポーネントについて関心が払われていないのが実際ではないでしょうか。
サードパーティ製のコンポーネントに対処しなかった場合の現実的な結果
数年前、世界は Equifax の大規模な侵害とその後の余波にさらされました。2017年5月から7月にかけてサードパーティ製のコンポーネントに悪用された脆弱性は、早くも2017年3月に報告されていますが、Equifax 内ではすぐに対処されていませんでした。
迅速なアップデートに備えることは重要ですが、迅速なアップデートは本質的に緊急性が高く未知の要素であるため、通常のプロトコルの一部として無視されがちです。ほとんどのチームにとって、深刻な脆弱性が原因で初めて更新を余儀なくされた場合、それはパニック状態の緊急事態になりますが、本来は日常的な準備訓練の一環であるはずです。
訓練の実行を恐れる必要はありません。訓練を実施する理由は準備を整えるためです。訓練を実施することで、緊急アップグレードが発生したときに、より良い対応をするためのスキルや考え方を身につけることができます。開発者が、自前のコードとサードパーティコードの間のすべてのインターフェイスと依存関係を理解していることを確認してください。これらの依存関係をチェックするためのテスト環境を準備しておけば、変更が必要になったときに、迅速かつ自信を持って変更を行うことができます。
アプリケーションが危険にさらされているかどうかは、どのようにして見分けることができるのでしょうか？
これで、サードパーティ製コンポーネントのセキュリティに関する一つの課題が解決されました。しかし、そもそもセキュリティ問題を特定することについてはどうでしょうか？アプリケーションが危険にさらされていることを知っていますか？そして、それらの兆候を可能な限り迅速に得るにはどうすればよいでしょうか？
動的解析には、長い間、公表されているサードパーティの脆弱性を特定するテストがありました。これらのテストは、ベンダによって公開された CVE を識別するテストエクスプロイトを実行するために、動的解析 (DAST) 技術を使用しています。しかし、脆弱性のためのエクスプロイトを作成するには長い時間がかかるかもしれません。しかし、ハッカーが先にエクスプロイトを作成するまで待ちたくはないでしょう。
HCL AppScan on Cloud (ASoC) では、ASoC Open Source Analyzer (OSA) を作成しました。OSAは、ASoCの静的解析ツールを活用して、プロジェクトが依存しているすべてのサードパーティ製コンポーネントのシグネチャを生成します。これらのシグネチャは ASoC サービスにアップロードされます。OSAはアプリケーション内の特定の暴露を示すのではなく、コンポーネントが脆弱性を持っており、何に対して脆弱であるかを示します。
それがどのように役立つのでしょうか。サードパーティのオープンソース・コンポーネントの新バージョンがリリースされると、ライブラリのシグネチャが作成され、保存されます。コンポーネントに対する脆弱性が報告されると、OSAは即座に認識し、その脆弱性はコンポーネントのシグネチャに関連付けられます。静的解析またはオープンソース解析がビルドパイプラインに統合され、スキャンが継続的に実行されている場合、コンポーネントとその特定のバージョンが脆弱であることを示すゼロデイ表示が表示されます。これは、エクスプロイトがまだ利用できない場合でも発生します。これにより、ハッカーを先回りしてアプリケーションが安全であることを確認することができます。
最近まで、OSA は静的解析スキャンの一部としてしか利用できませんでした。AppScan on Cloud では、OSA のみのスキャンを作成できるようになりました。これにより、オープンソースのスキャンを実行する際の応答時間がさらに向上します。アプリケーションが安全であることを確認しながら、開発を加速することができます。また、誤った理由でヘッドラインに載ることもありません。
これは良い状況です。
詳細
HCL AppScan on Cloudをご自身でテストドライブするには、今すぐ30日間の無料トライアルに登録してください。
HCL VersionVault のご紹介
2020/7/20 - 読み終える時間: ~1 分
HCL VersionVault は旧名 ClearCase です。ClearCase と言えば聞き覚えのある方がいらっしゃるかもしれません。コードのバージョン管理を得意とする製品です。新たに HCL VersionVault となるにあたり、ご紹介 Webinar: Introducing HCL VersionVault (英語) が開催されます。そのご案内の翻訳版を掲載します。
HCL VersionVault のご紹介
2020年7月15日
著者: Arlene Kim / Product Marketing Manager
HCL ソフトウェアは、製品のライフサイクル全体を通じて、製品のすべての成果物の変更にアクセスし、追跡し、管理するための、安全なバージョン管理および構成管理ソフトウェアであるHCL VerisonVaultを導入しました。HCL VersionVaultは、開発の柔軟性と、ファイルシステムに保存可能なあらゆるアセットの効果的な管理のバランスをとっています。
DevOpsのリーダーである Steve Boone と Howie Bernstein によるこのウェビナーに参加して、HCL VersionVault が実際にどのように機能しているのか、そして他のバージョン管理ソフトウェアと何が違うのかをご覧ください。コード、設計ドキュメント、モデル、テストなどのソフトアセットへのアクセスを管理するために、当社の製品がどのように組織を支援しているかをご覧ください。
このウェビナーは、自社のデプロイメントを近代化し、複雑な製品開発、リリース、保守プロジェクトをより良く管理したいと考えているエンジニアリングマネージャ、エンジニアリングチームメンバー、CTO、CIOの方々に最適な内容となっています。こちらから直接ご登録ください。
参考URL
クラウドホスティング: 終わりが新たな始まりを告げるとき
2020/7/20 - 読み終える時間: ~1 分
Cloud-Hosting: When an End Marks a New Beginning の翻訳版です。
クラウドホスティング: 終わりが新たな始まりを告げるとき
2020年7月15日
著者: Barry Rosen / Director of HCL Cloud Hosting MSP Program
約1年前に、Connections Cloud のサポート終了を発表しました。そして、その日となり、Connections Cloud サービスは終了しました。この終了に伴い、私たちはまた、エキサイティングな新しいスタートを切りました。クラウド・ホスティング・マスター・サービス・プロバイダー (Cloud Hosting MSP) ですが、その詳細については、クラウド・ホスティング・マスター・サービス・プロバイダー・センターをご覧ください。
これらの真に優れたプロバイダーと、HCL と IBM のチームが行ってくれた仕事を、これほど誇りに思うことはありません。 ここでは、昨年の多くの成果を簡単にご紹介します。
- 世界中の何千もの顧客に連絡を取り、計画をフォローしました。
- マルチテナント用 Connections コードを Cloud Hosting MSP に配信
- 7 回のウェビナーを開催し、約1500人の参加者が参加
- Connectionsを使用している 100 以上の組織を移行
- 16 TB以上のConnectionsデータを移行
信じられないような旅でしたが、この移行を実現するために懸命に働いてくれた Cloud Hosting MSP、HCL Connections Development、HCL Digital Solutions Product Management、HCL Digital Solutions Marketing、HCLとIBMのサポート、HCL White Gloveチーム、そして IBM と HCL の関係者の皆さんに感謝したいと思います。
移行に必要なステップを事前に行わなかった場合は、こちらから利用規約をご覧ください。
Barry Rosen
Director of HCL Cloud Hosting MSP Program
Notes/Domino サポート終了バージョンからのバージョンアップについての対応
2020/7/17 - 読み終える時間: ~1 分
これまでも HCL サポートでは、サポート終了済みからのバージョンアップに関するお問い合わせについて、できるかぎりの対応をしてまいりました。しかしながら、バージョンアップ手順の観点からは「一旦、サポートされているバージョンに上げてから、最新に上げる」ことを案内してきました。今回、直接のアップグレードについて、サポートはされていないものの、ベストエフォート対応とすることが明示されました。
事前の検証をするなどのリスク回避はお客様側で行っていただくことや、HCLのサポートがベストエフォートであることはこれまでと変わりませんが、「一旦、サポートされているバージョンに上げてから、最新に上げる」ことについては必須ではなくなりました。
-
HCL Notes/Domino、およびメール・テンプレート 11.0 のサポートされている混在バージョンと相互運用性
-
旧: Notes/Domino 11.0 をインストールしてアップグレードする前に、少なくとも Notes 9.0.1 および Domino 9.0 にアップグレードする必要があります。それより前のバージョンからのアップグレードも可能な場合もありますが、テストされておらず、正式にサポートされていません。
-
新: Domino 9.0 以降の Domino バージョンから Domino 11 へのアップグレードはテストされ、認証されています。明示的には認証されていませんが、HCL は Domino 9.0 より前のサーバーから Domino 11 への直接アップグレードをサポートするためにベストエフォートで対応します。
-
HCL Accelerate: DevOps メトリクスの重要性。なぜ、どれを、どのように
2020/7/15 - 読み終える時間: 4337 分
https://blog.hcltechsw.com/accelerate/devops-metrics-matter-why-which-ones-and-how-2/
DevOps Metrics Matter: Why, Which Ones, and How
HCL Accelerate: DevOps メトリクスの重要性。なぜ、どれを、どのように
2020年7月14日
著者: John Gelo / Senior Technical Architect
「自分が話していることを測定して、それを数字で表すことができれば、それについて何かを知ることができる」( ウィリアム・トムソン・ケルビン (物理学者・数学者・エンジニア))
もっと簡単に言えば、測定できないものは管理できないということです。DevOps （または何でも）をより良くするためには、自分が何をしてきたかを振り返り、現在の位置となりたい位置を比較する必要があります。そこにバリューストリームマネジメントの出番です。
アジャイルは、積極的な顧客とのコラボレーション、ダイナミックな変更対応、短い開発サイクル、頻繁な納品、継続的な対面チームコミュニケーション（スクラムとスプリント）、継続的な学習など、ソフトウェア開発製品とプロセスを改善し、管理するための基礎的な基盤を提供しました。リーンの主な推力は、顧客価値を最大化せずに資源、時間、スペースを消費する活動である無駄の識別と排除でした。
バリューストリームマネジメント（VSM）は、これらの概念に基づいて、製品、価値、時間のエンドツーエンドの全体的なワークフローの能力を可視化し、分析し、現在の状態（アイデアやコンセプト）から生産の流れを経て納品された状態に至るまでの時間を可視化します。VSMは、最高の品質を約束する効率的な運用環境を確保しながら、フローの改善とビジネス価値の継続的な最適化、アイデア（コード）から現金化までの生産、製品/開発管理会議への参加に焦点を当てています。
とてもパワフルに聞こえますよね？しかし、VSM ツールは、測定するメトリクスによってのみ効果を発揮します。メトリクスは、ソフトウェア開発チームがソフトウェアのライフサイクルの段階で、製品やプロセスの流れを理解し、評価し、コントロールし、情報に基づいた意思決定を行い、予測するのに役立ちます。別の言い方をすれば、以下のようになります。
「応用ソフトウェア測定の目標は、ソフトウェア管理者や専門家に、ソフトウェアプロジェクトのサイズ決定、見積もり、管理、制御を厳密かつ正確に行うための有用で具体的なデータポイントのセットを提供することである」(C.ジョーンズ、応用ソフトウェア測定。生産性と品質のグローバル分析)
メトリクスが重要であることをもっと納得させる必要がありますか？ここでは、時間をかけて正しいことを測定し、正しいことを測定するための 5 つの理由を紹介します。
- ソフトウェア・プロセスの問題を解決する（問題の特定、改善の機会）
- 品質の把握・向上（品質レベルの把握、品質向上、テストの徹底
- 問題の回避・修正（レスポンスの高速化、不具合の修正、挙動の変化、問題の実現を防ぐ
- アジャイル進捗管理（スプリントの進捗状況、可視性の向上、目標達成、ワークフローのバランス調整
- アジャイル計画（優先順位付け、スコップ、リソーシング
DevOps パフォーマンスの測定についての理解が深まったところで、何を測定すべきかについて説明しましょう。HCL Accelerate には、ソフトウェアデリバリパイプラインの多くの側面を追跡する機能がありますが、どの指標に注目するかは、組織独自の主要パフォーマンス指標に依存します。ほとんどの場合、注目したいメトリクスは以下のとおりです。
- リードタイム
- 待ち時間
- スループット
- ワークアイテムの配布
- 不良率の変化
- ロード
リードタイム
リードタイムとは、仕事の単位としてのアイデアが受け入れられてから、その仕事の価値が実現するまでに必要な時間であり、付加価値のある処理時間と付加価値のないサブプロセス間の待ち時間の両方を含む。作業項目の処理時間は、その活動に人またはチームが費やした時間の持続時間である。理想的には、市場投入までの時間を短縮し、顧客満足度を向上させるために、リードタイムの値は1日の傾向にあるべきです。
待ち時間（キューイングまたは無駄）は、ワークアイテムがバリューストリームで処理されている間、非生産的な状態のままアイドル状態で過ごす時間の推定値です。ソフトウェア製品のカスタマイズ(SPC)は、現在のソフトウェアリリースでの実装を必要とする顧客に合わせたソリューション(通常、優先度の高い)です。バリューストリーム管理者は、顧客と製品の価値を最大化するために、SPCの待ち時間を最小限にしたり、排除したりすることが求められています。
価値の流れのスループットは、ある期間に完了した作業単位項目の平均レートであり、流れの中の納品価値のレベルを定量化する。ある期間にあるステージで処理された作業単位の率は、そのステージのスループットとして表現されることがある。顧客要求への対応力を向上させるために、スループットの改善を識別する目標を設定し、それを実行することで、固定負荷容量を持つ価値の流れのリードタイムを短縮することができます。
作業項目分布は、与えられたセット（同じ項目タイプ）の作業項目の総数に対する完了した作業項目の割合である。セットはユーザーが指定し、プロセスベース（リリースまたはスプリント）または時間ベース（所定の期間に完了した項目）の項目を含むことができます。この指標は、予測される業績に合わせて特定の作業タイプに優先順位をつけるために使用されます。
バリューストリームでは、変更欠陥率は、バリューストリーム内に統合された欠陥の数が、所定の時間間隔内に完成したアイテムに占める割合で表される品質指標です。変更欠陥率は、バリューストリームの運用の予測可能性を理解するのに役立ち、以下の質問に対する洞察を提供します。 * 不具合は開発プロセスの初期段階で発見されているか。 * 顧客やビジネスに影響を与えることなく、本番環境で一貫性のある信頼性の高い納品が行われているか。 変更の欠陥率が高いチームは、迅速な進歩の可能性を秘めていますが、その代償として、不十分な品質基準が確立されていないため、効果的に迅速かつ効率的に作業を進めることができません。生産に入る前に、バリューストリームの中で欠陥を特定するためのチームの努力を修正することは、変更欠陥率の割合を低下させるための基礎となります。
負荷とは、ある時点においてバリューストリーム内でアクティブになっている作業項目（アクティブまたは待機中）の数である。負荷は、プロセスフローの生産性に関連するバリューストリームの利用能力を測定する。
ソフトウェア・デリバリ・パイプラインでこれらのメトリクスを追跡するのは大変なことのように思えるかもしれませんが、バラバラのツールから手動でデータを収集して測定するのは苦痛です。しかし、バリューストリーム管理では、測定が簡単にできてしまうため、これらのメトリクスは無視できないほど重要です。当社のバリューストリーム管理ツールである HCL Accelerate は、既存の DevOps ツールチェーン内のすべてのものを自動的に接続し、ビジュアル・レポートにデータを収集し、測定スペクトル全体を最大限に活用して、非常に調整されたソフトウェア・パフォーマンス体験を提供します。HCL Accelerate の無料 Community Edition でお試しください。
HCL Launch のご紹介
2020/7/14 - 読み終える時間: 2 分
HCL UrbanCode Deploy から名称変更となった HCL Launch についての、英語版ブログでのご紹介記事 Introducing HCL Launch の翻訳版を掲載します。
HCL Launch のご紹介
2020年6月16日
著者: Hayden Schmackpfeffer / Senior Developer
HCL Launch をご紹介できることを大変嬉しく思います。HCL Software DevOpsポートフォリオのこの継続的な配信部分は、エコシステムの成熟度に関係なく、DevOpsの変革に価値を提供することができます。
HCL Launchは、環境を介したアプリケーションのデプロイメントを自動化するためのツールです。本番環境で必要とされる監査証跡、バージョン管理、承認を提供しながら、アジャイル開発における迅速なフィードバックと継続的な配信を促進するように設計されています。Launch は複雑なデプロイメントシナリオを簡単に自動化し、アプリケーションが開発環境から本番環境に移行する際にガバナンスを強化するためのツールを提供します。さらに、Launchの100以上のプラグインは、DevOpsツールチェーン内のすべてのプラットフォームとの対話をこれまで以上に容易にします。
HCL Launchの最新リリースであるバージョン7.1.0.0 には、開発環境へのデプロイメントの自動化を促進し、デプロイメントを進めるべきかどうかを判断するために変更管理システムに最初に連絡することを可能にする機能を備えた、継続的なデリバリの近代化を支援するために調整されたエキサイティングな新機能が含まれています。このアップデートでは、エンタープライズグレードのニーズへのサポートが拡大されているため、将来に向けてアーキテクチャを構築し、デジタルトランスフォーメーションの旅を継続することができます。
外部からの承認
HCL Launch 7.1の新機能である外部承認プロセスでは、プラグインのステップを使用することができます。これらの承認プロセスは、デプロイメントの直前に実行され、その成否によって次のデプロイメントの実行が許可されるかどうかが決まります。これにより、変更管理システムの統合を使用して、デプロイとペアリングされた変更要求が有効な状態にあることを検証する、高度に拡張可能な承認プロセスが可能になります。
展開のトリガー
配置トリガーは、HCL Launch 環境が特定のコンポーネントをサブスクライブするための方法です。トリガーは、指定されたコンポーネント、配置プロセス、ユーザーから構成されます。コンポーネントがバージョンのインポートを完了するたびに、Launch サーバーは、そのコンポーネントに関連するすべての配置トリガーを自動的に実行し、新たにインポートされたバージョンを配置ペイロードとして使用して、トリガーの環境に対して設定された配置プロセスを実行します。デプロイメント トリガーを使用すると、開発環境は、最新のビルド成果物が Launch サーバーによって受信されるとすぐにデプロイされるように設定することができます。
サーバークラスタの改善
HCL Launch 7.1には、高可用性構成のためのいくつかのQOLの向上が含まれています。サーバー間の通信は、v7.0でエージェントに導入された堅牢なWebSocket通信を利用するようになりました。サーバーのネットワークページには、問題を簡単に診断できるように、サーバークラスタに関する接続情報が表示されるようになりました。
ユーザーエクスペリエンスの向上
HCL Launch UI には、あなたの生活をより簡単にするためのいくつかの変更があります。リソースツリーのページを一から再構築し、非常に大きなリソースツリーを表示する際のページのパフォーマンスを大幅に改善しました。
デプロイメントの要求は新しいページを介して提出されるようになり、デプロイメントに必要な情報がより整理されて表示されるようになりました。
アプリケーション環境リストは、UI のスタイリングを現代的にし、環境とインベントリ情報をより分かりやすく表示するために再設計されました。
zOSのバージョンをマージする
zOSメインフレームシステムにデプロイするHCL Launchの機能を利用しているお客様は、増分されたzOSコンポーネントのバージョンをマージして、マージされたすべてのバージョンの最新のファイルのセットにすべてのバージョンの成果物を統合した単一のバージョンにすることができることを知って喜ぶことでしょう。これにより、大規模なコンポーネント・バージョンのセットを、より管理しやすい単一のバージョンに変換することができます。
HCL Launchの動作を参照してください
HCL Launch の詳細と追加された新機能をご覧いただけるウェビナーがあります。オンデマンドでデモを見るには、ここをクリックしてください。
HCL Launch におけるデプロイのトリガー
2020/7/14 - 読み終える時間: ~1 分
HCL Launch のデプロイのトリガーの特長についての解説記事 Deployment Triggers in HCL Launch の翻訳版を掲載します。
HCL Launch におけるデプロイのトリガー
2020年7月9日
Diego Villafuerte / Solutions Specialist
私たちは、継続的デリバリプラットフォームである HCL Launch を使用している人たちの傾向に気づきました。多くのお客様は、デプロイ前に変更要求がいくつかの定義された基準を満たしているかどうかを検証するために、Jira や ServiceNow などのサードパーティのツールを使用しています。これはガバナンスのギャップにつながり、CR のステータスをチェックしてプロセスをグリーンライトにするために手動で承認する必要があります。この方法は機能はしますが、理想的な方法ではありません。
HCL Launch 7.1 では、あるバージョンがインポートされた後に発生する必要のあるタスクを自動化するために、デプロイメントトリガーを追加しました。主な機能は、プロセスを実行するユーザーを指定できることです。この機能強化の前は、プロセスは管理者として実行され、コンポーネントレベルで設定されていました。このため、ユーザーにとってセキュリティ上の問題があり、バージョンが作成された後に複数のプロセスを実行することは不可能でした。
現在は、環境の設定ペインでデプロイメント トリガーを見つけることができるようになり、この機能を利用する際の設定時間を大幅に短縮することができます。新しいデプロイメントトリガーでは、コンポーネントごとに作成できるトリガーの数に制限がないため、この機能がより便利になりました。以前は、承認を必要とするプロセスは、トリガーを介してキックオフされると自動的に失敗していました。今では、HCL Launch は、配置要求の説明に配置トリガーへの有用なリンクを表示することで、このようなケースを処理するのに役立ちます。
特定のユーザーとしてプロセスを実行するために、新しいセキュリティ権限を追加しました。ベスト プラクティスは、「バージョン・インポート・プロセス (version import processes)」ユーザーとして動作するように単一のユーザーを設定することです。そして、すべてのデプロイのトリガーにそのユーザーを指定します。この機能が更新される前から持っている「トリガー」はすべて移行され、デフォルトでは管理者ユーザーとして実行されるように設定されます。
HCL Launch 7.1 の新機能の詳細については、ブログ記事 「HCL Launch のご紹介」をお読みください。
Unica Campaign の実行スケーリングの詳細
2020/7/14 - 読み終える時間: 3 分
Unica Campain は柔軟な構成と実行が可能です。実際例を使いながらその詳細を解説した記事 Let’s Geek Out on Unica: Scaling Your Campaign Execution の翻訳版を掲載します。
Unica Campaign の実行スケーリングの詳細
2020年7月6日
著者: Tom Hannigan Jr. / HCL Unica Global Practice Leader
誰もが、より少ない時間でより多くのことを素早くやろうとしています。
私のクライアントはいつも私に「どうすれば物事を速くできるのか」「どうすればより多くのキャンペーンを行いながらキャンペーンの実行を合理化できるのか」と質問してきます。
どちらも有効な質問です。多くの人は、より多くの規模で実行し、より多くのパーソナライゼーションを行い、より多くのチャネルでより多くのキャンペーンを同時に実行したいと考えています。しかし、それを実現する方法がわかりません。
そこで、Unica という魔法が助けてくれるのです。
まず、課題を理解しましょう。私はそれを「多対多」のシナリオと呼んでいます。
Unica は、ダイレクトメールや単発のメールのような非常に基本的なキャンペーンに合わせてしばらく前に設定されていたことがよく見受けられます。その後、時間が経つにつれ、育成ストリームが追加され、カスタマージャーニーが追加され、モバイルアプリやコマースサイト、コールセンターなどのチャネルが追加されましたが、キャンペーン活動の拡大や成長をサポートするために、Unica のプラットフォームが見直されることはありませんでした。
その結果、さまざまなスタイルのコミュニケーションが Unica のフロントエンドに詰め込まれてしまいました。さまざまな実行に対応するために、オファーテンプレートのようなものには、より多くのフィールドが追加されていました。
最近の例では、オファーテンプレートに 35 の異なるフィールドがあり、シンプルなクーポンを含む単発のメールから、11 のコンテンツブロックを含む週刊ニュースレターまで、あらゆるものに対応できるようになっていました。そのうち 6 つは動的に入力されていました。
キャンペーンマネージャーが、35 のフィールドの中から今日のキャンペーンに適したフィールドを見つけ出すのに苦労していることを想像してみてください。これはキャンペーンフローチャートにも当てはまります。
私たちは、週一回のメールキャンペーンを、ダイナミックなパーソナライゼーションを用いた週三回のメールキャンペーンに成長させたクライアントを持っていました。
毎週、彼らは前の週のフローチャートのコピーを取り、名前を変えて、それを今週のキャンペーンの出発点として使用します。今日、彼らは最後に実行したもののコピーを取り、週に 3 つのコピーを作成します。
どのプロセスボックスを残し、どのプロセスボックスを削除し、どのプロセスボックスを前回の実行から削除されたものを追加するかを解釈しながら、次のキャンペーンの実行を設定することを想像してみてください。
最後に、出力があります。すべてのキャンペーンは、リスト、ファイル、または API コールの形でキャンペーンメンバーを生成します。出力仕様は多くのキャンペーン実行シナリオに対応しなければなりません。それは巨大です。
288フィールドの巨大なフィールド。
品質管理のためにファイルをレビューしようとしていることを想像してみてください。さらに悪いことに、エラーを発見した場合のトラブルシューティングを想像してみてください。そして、どのフィールドがどのキャンペーンに使用されるかが明確でない場合、エラーを発見するのはどれほど難しいでしょうか。空欄のフィールドはキャンペーンに必要ないことを意味しているかもしれませんし、誰かのミスを意味しているかもしれません。どちらでしょうか？
「多対多」の問題を解決するには、3つのステップを踏む必要があります。
- 実行シナリオを定義する
- シナリオに特化したテンプレートの作成
- 実行シナリオごとに Unica でテンプレートをまとめてマッピングする
これを Unica で事前に定義された「ジャングルを通るパス (path through the jungle)」を作成して、実行を合理化して拡張できるようにすることを、私たちはこれと呼んでいます。
マーケターは実行することが好きです。そのため、Unica を使用している人が、キャンペーンの実行の背後にある「方法」についてあまり考えたことがないのはよくあることです。
マーケティングの実行には常にパターンがあります。日常から少し離れてみると、それが見えてきます。一般的な小売店では、プロモーションカレンダーとそれに付随するクリエイティブ制作プロセスがあります。不規則に感じるかもしれませんが、歴史的な実行を見れば、プロモーションのパターンが浮かび上がってきます。毎週のプロモーションのニュース、クーポンメール、イベントや販売のためのプロモ、そして最後にカテゴリや部門のプロモーションがあります。私たちはプロモーションの処置の各タイプのためのテンプレートを作成することを推薦します。
同じことが、オファー、キャンペーン、アウトプットの仕様にも当てはまります。パターンを見つけ、それぞれのテンプレートを定義し、それぞれのフィールドのルールを書き出します。これにより、フロントエンドでの「多数」の問題が単純化されます。今日は、フィールドごとに、フィールドに何を入力する必要があるのか、何を入力する必要があるのかを把握しようとしています。テンプレートでは、必要なフィールド/プロセスだけがテンプレート内にあり、何のために何を実行するのか、そのタイプの実行のために何を入れるのか、という明確なルールがあります。
また、バックエンドの「多くの」課題にも対応します。入力フィールドが少ないということは、出力フィールドが少ないということです。そのキャンペーンシナリオに必要なフィールドだけが出力仕様に含まれています。すべてのフィールドは、事前に定義されたテンプレートからのデータで入力されなければならないので、QA が容易になります。
「ジャングルを通る道 (path through the jungle)」の作成は、Unica が本当に輝くところです。各キャンペーンテンプレートでは、キャンペーンサマリー情報に、あらかじめ定義されたオーディエンスと関連するオファーを追加することができます。
今回の Unica Campaign では、すでに 3 つのオーディエンスと 7 つのオファーを紐付けしています。これらのうちの 1 つが不要な場合は、簡単に削除することができます。新しいオーディエンスでテンプレートを更新する必要がある場合は、一度テンプレートに追加され、自動的に表示されます。
今回の Unica Campaign は、すでに 3 つのオーディエンスと 7 つのオファーを紐付けしています。もし必要ない場合は、簡単に削除することができます。新しいオーディエンスでテンプレートを更新する必要がある場合は、一度テンプレートに追加され、その後、すべてのキャンペーンに自動的に表示されます。
同じことがキャンペーンフローチャートにも当てはまります。各キャンペーン全体のテンプレートには、そのキャンペーンシナリオで実行されるプロセスボックス付きのフローチャートテンプレートをあらかじめデザインしておくことができます。何も表示されていない画面や最終週のキャンペーンを見るのではなく、すでに完全に QA が行われた事前定義のフローチャートから始めることができます。あなたはネットの新しい変更をチェックする必要があるだけです。
目標は、キャンペーンの構造の 70～80％ を Unica Plan と Campaign のテンプレートにマッピングしておくことです。週 3 回のキャンペーンを週 3 回実施している場合、テンプレートが変更されていない限り、スタート地点は毎回同じです。先週実行したキャンペーンの最後のバージョンに変更が加えられ、今週にコピーされたことを心配する必要はありません。
私たちは、多くのクライアントのために 8-10 のオファーとキャンペーンのテンプレートと 3-4 の出力仕様である実行シナリオごとに 1 つのテンプレートをお勧めします。
さて、Unica の設定方法を変更しても、マーケティングの実行は止まらないことを知っています。最高の状況では、マーケターは "ナイフをジャグリングしながら実行している "ことになります。
しかし、来週のキャンペーンを構築し始めたら、5 分かけて「これはどんなタイプのキャンペーンなのか」と自問してみてください。クーポンのためのキャンペーンなのか、それともロイヤルティプログラムのためのキャンペーンなのか？実行しながらメモを取り始めましょう。定期的に行われるオファー、メッセージ、プロモ、オーディエンスは何か？
そのうちにパターンが見えてくるでしょう。そうすれば、Unica Campaign にテンプレートをいつ、どこで導入するかを決めることができます。
このようにして、ジャングルを抜けていく道を見つけ、Unica を使って合理化し、スケールアップしていくことができるのです。
Unica をもっと知りたい方は "Let’s Geek Out on Unica" チームからの情報をご覧になりませんか？
ここをクリックして、Unica Live の Let's Geek Out on Unica ビデオライブラリをご覧ください。