適切なペルソナに焦点を当てる

Jim Beno 著 - Skyhigh Security ユーザーエクスペリエンス担当ディレクター

2022年11月10日 4 分で読めます

セキュリティ企業として、当社の製品ユーザーは通常、情報セキュリティ（InfoSec）部門に所属しています。しかし、当社のSecurity Service Edge (SSE)機能は、セキュリティチーム以外のユーザーを対象とすることが増えています。主に情報技術（IT）部門ですが、エンジニアリング/運用部門も含まれます。彼らはクラウドでアプリケーションを開発・展開し、それらへのアクセスを制御し、ネットワークのパフォーマンスを確保する人々です。

セキュリティ組織外の役割を対象とした、少なくとも4つの主要なSSEワークフローまたは機能があります。

• アプリケーションへのアクセス付与 – 企業がインフラストラクチャの多くをパブリッククラウドに移行するにつれて、そこにホストされているアプリケーションへのアクセスを制御する必要が生じます。当社のZero Trust Network Access (ZTNA)ソリューションは、この機能を提供します。これらのアクセスポリシーを管理し、従業員からのアクセス要求に対応することは、Security Operations Center (SOC)の仕事ではありません。これはIT部門およびITヘルプデスクが担う責任です。
• ファイアウォールポリシーの管理 – 公共クラウドにこれらすべてのインフラストラクチャがあるため、セキュリティのために、企業はこれらのアプリケーションを使用できる「誰」だけでなく、「どのように」—つまり、どのプロトコル、ポート、デバイス、場所などの詳細—によってもアクセスを制御する必要があります。
• デジタルエクスペリエンスモニタリング – 世界中にオフィスがあり、多くの人が在宅勤務をしているため、一部の従業員がアプリケーションやサービスへのアクセスに問題を抱えることは避けられません。これらの問題の範囲と原因を特定することは悪夢のような作業になりかねません。ITヘルプデスクに電話がかかってきても、セキュリティチームが電話に出ることはありません。
• 設定ミスと脆弱性の修正 – ITおよびエンジニアリング部門では、さまざまなチームがAmazon Web Services (AWS)、Google Cloud Platform (GCP)、またはMicrosoft Azure上でアプリケーションを構築している可能性があります。当社の仕事は、クラウドインフラストラクチャを担当するITアーキテクト、アプリケーションを開発および構成するアカウントオーナー、またはそれらをデプロイするDevOps/DevSecOps担当者など、企業がこれらのアプリケーションを保護するのを支援することです。脆弱性や設定ミスを検出した場合、セキュリティチームにはそれを修正するための「城の鍵」はありません。変更を行うことができるITまたはエンジニアリングの担当者に問題を提示する必要があります。

ペルソナの作成

Skyhigh Securityには、顧客を理解し、製品要件と設計に役立つ洞察を生み出すことを職務とする専任のユーザーリサーチャーがいます。新しい製品機能ごとに、適切なユーザーをターゲットにしていることを確認し、彼らについてあらゆることを学ぶ必要があります。彼らを動機づけるものは何か？どのようなタスクを実行するか？どのようなアプリケーションやシステムを使用するか？どのように他者と協力するか？彼らの最大の課題は何か？

まず、製品管理および営業部門の社内チームメンバーにこれらの質問をします。ワークセッションを開催し、仮想ホワイトボードに集合的な知識をまとめることがよくあります。ターゲットとする職務が分かったら、お客様にインタビューし、その働き方を観察します。これらのセッションを数回行った後、いくつかの共通のテーマが見えてきます。その後、すべての洞察を統合し、架空の人物、つまり「ペルソナ」を作成します。これがユースケースと設計の焦点となります。

FredとKawikaの紹介

最近、当社の研究者は、デジタルエクスペリエンス監視とファイアウォールポリシーを担当する2つの新しいペルソナを調査しています。ITヘルプデスクで働く「Fred」と、ネットワーク管理者である「Kawika」です。このダイナミックな二人組から得られた洞察の一部をご紹介します。

• Kawikaはネットワークのパフォーマンスに責任を負っています。すべてが正常に機能しているときは問題ありませんが、問題が発生すると、彼はすべてを中断してすぐに対応しなければなりません。これを避けるため、彼はネットワーク上の重要なアプリケーションを積極的に監視したいと考えています。多数のトラブルチケットが届くのを待つことはできません。
• SOCと同様に、IT部門にはサポート問題を処理するための異なる階層があります。従業員がアプリケーションへのアクセスで問題に遭遇した場合、ITヘルプデスクが対応するチケットを開きます。これは、Fredが最初に問題を調査することを意味します。彼はトラブルシューティングをガイドするプレイブックを持っています。ネットワークの問題のように見える場合、彼はそれをネットワークチームにエスカレートします。今度はKawikaの番です。
• ネットワークの問題を診断するのは容易ではありません。ネットワークアーキテクチャは複雑です。クラウドサービスにアクセスする場合、従業員のデバイスからのトラフィックは多くの異なるネットワークを経由します。パフォーマンスに影響を与える可能性のある多くの変数があり、状況は時間とともに変化する可能性があります。これらの問題を調査するために、Kawikaは必要な情報を得るために多くのツールとコンソールを使用しなければなりません。

曖昧さの回避

これらの洞察はすべて、Fred、Kawika、およびその同僚のために作成した1ページのデータシートにまとめられています。また、クロスファンクショナルチームにペルソナを紹介するためのトレーニングセッションも開催しています。製品マネージャーやエンジニアがペルソナを名前で参照するのを聞くと、私たちは自分たちの仕事が達成されたと分かります。

FigmaでのすべてのUXデザインフローは、ターゲットペルソナとユースケースを示すアートボードから始まります。これにより、全員が同じ認識を持ち、「管理者」や「セキュリティアーキテクト」といった曖昧な参照を避けることができます。デザインをレビュー中に誰かがターゲットペルソナに疑問を呈した場合、それは素晴らしいことです！私たちはその議論を歓迎します。実際、FredとKawikaはまさにそうして誕生しました。

新しい機能を設計・構築し、リリース後にターゲットユーザーに関する仮定が間違っていたと判明することほど悪いことはありません。それはワークフローに重大な影響を与え、完全な見直しを必要とする可能性があります。仮定を検証し、目標が正しいことを確認するために、事前に少量のユーザー調査に投資する方がはるかに良いでしょう。

ブログへ戻る