適切なペルソナにフォーカスする

ジム・ベノ - ユーザー・エクスペリエンス・ディレクター、Skyhigh Security

2022年11月10日 4 分読み

セキュリティ企業として、当社の製品のユーザーは通常、情報セキュリティ（InfoSec）組織で働いています。しかし、当社のSecurity Service Edge (SSE)機能が、セキュリティ・チーム以外のユーザーをターゲットにしていることが分かってきました。これらの人々は、クラウドでアプリケーションを開発・展開し、それらへのアクセスを制御し、ネットワークのパフォーマンスを保証する人々です。

セキュリティ組織外の役割をターゲットにしたSSEの主要なワークフローや機能は、少なくとも4つあります：

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

ペルソナを作成する

Skyhigh Security では、専任のユーザー・リサーチャーがお客様を理解し、製品要件や設計に役立つインサイトを生み出すことを仕事としています。新製品ができるたびに、適切なユーザーをターゲットにしていることを確認し、そのユーザーについてできる限りのことを学ぶ必要があります：何が彼らを動機づけるのか？どのようなタスクを行っているのか？どのようなアプリケーションやシステムを使用しているのか？どのように他者とコラボレーションしているのか？彼らの最大の悩みは何か？

私たちはまず、プロダクトマネジメントやセールスの社内メンバーに対して、このような質問を投げかけます。ワークセッションを開き、バーチャルのホワイトボードに集合知を書き込むこともあります。そして、ターゲットとなる職種が決まったら、お客さまにインタビューして、その働きぶりを観察します。何度かセッションを重ねると、共通のテーマが浮かび上がってきます。そして、すべてのインサイトを統合し、架空の人物である「ペルソナ」を作り、ユースケースやデザインを書く際の中心的な存在とします。

フレッドとカウィカの紹介

最近、私たちの研究者は、デジタル体験のモニタリングとファイアウォールポリシーを担当する2人の新しいペルソナについて調査しています：「ITヘルプデスクに勤めるフレッドと、ネットワーク管理者のカウィカです。このダイナミックな二人から得た知見をご紹介します：

• カイカはネットワークの性能に責任を持つ。すべてがうまくいっているときは、人生うまくいっている。しかし、何か問題が起きると、彼はすべてを投げ出して行動を開始しなければなりません。このような事態を避けるため、彼はネットワーク上の重要なアプリケーションをプロアクティブに監視したいと考えています - トラブルチケットが大量に送られてくるのを待つことはできません。
• SOCと同様に、ITにもサポート問題を処理するためのさまざまな階層があります。従業員がアプリケーションにアクセスする際に問題が発生した場合、ITヘルプデスクが対応するチケットを作成します。つまり、フレッドは問題を調査する最初の行となるのです。彼にはトラブルシューティングのガイドとなるプレイブックがあります。もし、ネットワークの問題であれば、ネットワークチームにエスカレーションする。次はカイカの番だ。
• ネットワークの問題を診断するのは簡単ではありません。ネットワーク・アーキテクチャは複雑です。クラウドサービスにアクセスする場合、従業員のデバイスからのトラフィックは、多くの異なるネットワークを移動します。パフォーマンスに影響を与える変数も多く、時間と共に条件が変化することもあります。これらの問題を調査するために、カワイカは多くのツールやコンソールを使って、必要な情報を得る必要があります。

あいまいな表現にならないようにする

これらのインサイトはすべて、フレッド、カウィカ、そして彼らの同僚たちのために作成した1ページのデータシートにまとめられます。また、クロスファンクショナルチームにペルソナを紹介するトレーニングセッションも開催しています。プロダクトマネージャーやエンジニアがペルソナの名前に言及するのを聞くと、私たちは自分たちの仕事をやり遂げたと実感します！

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

新機能を設計・構築しても、リリース後にターゲットユーザーの想定が誤っていたことが判明するほど最悪なことはありません。ワークフローに重大な影響を及ぼし、全面的な見直しが必要になる可能性もあります。事前にユーザー調査を行い、想定を検証し、目標が達成されていることを確認する方がはるかに良いのです。

ブログへ戻る