書き起こし
Roa: 私はYury Niño、コロンビア出身です。この発表では、可観測性、カオス エンジニアリング、視覚的メタファーについて話をします。私はGoogleでクラウドインフラエンジニアをしています。また母国では、カオス エンジニアの提唱者でもあります。これから、可観測性、可視化、そしてもちろんカオスという3つの概念についても定義をしていきます。後編では、システムを監視するために使っている古典的なチャートやダッシュボードを説明し、その弱点をいくつか紹介してゆきます。これに関連して、いわゆる視覚的メタファーと私が話しているもうひとつの視点を探ってゆきます。最後に、私が同僚に行ったアンケートの結果を発表します。この調査では、古典的なチャートやダッシュボードの効果を見ようとしています。視覚的メタファーがソフトウェアシステムの可観測性向上に有効かどうかを確認しようとしています。
ニューグラナダへの王立植物探検隊
私はコロンビア人です。私の国は、おいしいコーヒーが栽培されているとか、美しい風景があるといったことがよく話題になります。私の国には、もうひとつ凄いことがあります。ニューグラナダへの王立植物探検隊です。1783 年から 1816 年にかけて、コロンビア、エクアドル、パナマ、ベネズエラ、ペルー、ブラジル北部で実施されました。この遠征は、植物学者、数学者、そしてイラストレーターであるJose Celestino Mutisによって実施されました。Jose Celestino Mutis は、25 年間に 20,000 枚以上の図面を用いてニューグラナダの動植物を記録したことで知られています。（画面が肖像画に切り替わる：2分30秒あたり）彼がJose Celestino Mutisです。彼のイラストは、わが国の動植物の視覚的な宝物であり、王立植物探検隊の最高の可視化例です。
おそらくみなさんの多くが、なぜ私がソフトウェアカンファレンスで植物や昆虫のイラストについて話しているのか疑問に思っていることでしょう。なぜならその答えは、人間は非常に視覚的な生き物だからです。おそらくそれが、Jose Celestino Mutisが5000点以上の花や昆虫を描いた理由の1つでした。私たちの調査によると、人間の脳の半分は直接的または間接的に視覚情報の処理に費やされています。例えば脳では、視覚処理に費やされるニューロンが約 30% を占めるのに対し、触覚で占める割合は 8% 、聴覚ではわずか 3% です。この調査で科学者たちは、少なくとも 65% の人が視覚学習者であることを確認しました。また、視覚補助資料を使用したプレゼンテーションは、使用しないプレゼンテーションよりも 43% 説得力があることもわかりました。
用語
私たちの文脈では、可視化、チャート、およびグラフィックスが非常に重要です。ここでは、ソフトウェアリリース実施中と現在のインシデントのタイムラインを表示しています。こちらは、「Incident Management Operations」（出典：動画内のURLより）というとても素晴らしい書籍から引用したものです。コマンドマネージャーからの最初の指示は、分析ダッシュボードを確認することでしたが、ダッシュボードへのアクセスはまだ機能していませんでした（動画では"The SME reports they are not able to log in and check tha dashboard."という表現でハイライトされている：4分4秒あたり）。さて、可観測性とカオス エンジニアリングについて学ぶ前に、明確にしておくべきいくつかの定義を確認しましょう。可観測性とは、私たちのシステムを完全に理解できることです。例えば制御理論では、可観測性は、あるシステムの内部状態を、外部出力の知識からいかにうまく推測できるかを示す指標として定義されます。私にとって可観測性とは、質問をし、答えを提供し、システムに関する知識を構築することです。ここでもう 1 つの重要な定義があります。現代のソフトウェア システムでは、可観測性とは数学的な方程式ではなく、人々がどのように複雑なシステムと対話し、理解しようとするかということなのです。
可観測性は監視とは異なります。そして、その違いの理由を理解することが遥かに重要です。Google SRE ブックによると、監視とは、システムのリアルタイムな定量的データを集め、処理し、集約、表示することです。長いトレンドの分析など、システムを監視する理由はたくさんあります。例えば、データベースのサイズと増加速度の監視。よくあることですが、何かが壊れている場合のアラート。修正するには誰かにそれを知らせる必要があります。ダッシュボードの作成は、インシデント タイムラインで行います。ダッシュボードは、サービスに関する基本的な質問に答えるものであり、システムに何が起こっているのかを理解しようとする最初のツールです。私たちは、システムが送信しているシグナルを通じてシステムを監視します。これらのシグナルはメトリクスと呼ばれます。メトリクスは、クエリ数、エラー数、処理時間、サーバーの寿命など、グループ化と検索用にオプションでタグ付けされた単一の数値です。Jason Englishによれば（出典：動画内のURLより）、データの視覚化はより一般的な概念であり、データの流れや保管データのようなメトリクスをよりわかりやすく人間が認識し分析できるように、人間とコンピュータのインターフェースを設計し、エンジニアリングすることです。最後にダッシュボード。これは通常 Web ページなんですが、サービスのコアメトリクスの概要ビューを提供するアプリケーションです。ダッシュボードにはフィルターやセレクタがあり、ユーザーにとってもっとも重要なメトリクスを表示することを目的としています。
この講演はグラフィックス、ダッシュボード、可視化、そして可観測性についてのものなので、これらの定義をこちらのスケッチに入れました。観測可能性とは、メトリクスを監視、分析することでシステムの健全性を完全に理解できることです。監視とは、システムのリアルタイムなメトリクスを収集、処理、集約、および表示することです。メトリクスとは、ここで重要な用語なんですが、クエリー数、処理時間、サーバー寿命などのタグがオプションで付加された単一の数値のことです。可視化には、例えば人が見て理解できるように、ヒューマン・コンピューター・インターフェースやメトリクスダッシュボードの設計やエンジニアリングが含まれます。ダッシュボードは、システムに関する一連のメトリクスの概要ビューを提供するアプリケーションです。最後に、ここで新しい概念を紹介したいと思います。カオスです。この講演は可観測性に関するものですが、カオス エンジニアリングに関するものでもあります。カオスとは、予測不可能でランダムな結果をもたらすシステムの乱流状態のことです。
可観測性とカオス エンジニアリングの関係
可観測性とカオス エンジニアリングは何が関係しているのでしょう？ 「Principle of Chaos」というウェブサイトによれば、そこにはカオス エンジニアのためのマニフェストが書かれています。 カオス エンジニアリングは、本番環境において乱流条件に直面するシステム能力に自信を持つために、システムで実験するための規律です。カオス エンジニアリングと可観測性は密接な関係にあり、個人的にはこの表現を使用して両方の概念を関連付けることができます。カオス エンジニアリングとは、カオス、可観測性、レジリエンス（回復力）の総和です。カオス実験を自信を持って実行するためには、システムがいつ正常であるか、および実験の実行時にシステムがその定常状態からどのように逸脱しているかを可観測性によって検出する必要があります。この表現にはある大切な概念があり、その「知識」についてお話しします。具体的には、この文脈において「知識」を定義するためのパーツが、カオスと可観測性から得られます。もし、システムが正常でないことを特定し、カオス的な状況に対してシステムがどのように反応するかを判断できれば、私たちはシステムを理解していると言えるでしょう。厳密には、「知識」とは、カオス エンジニアリングと可観測性という 2 つの概念をつなぐ概念です。可観測性のこの定義を見てください。可観測性は、メトリクス＋質問＋回答の合計として定義できます。可観測性とは、適切な質問を作成し、正しい答えを提供するためのツールを持つことです。このような質問の答えを知っているのであれば、そのシステムを理解している、ということを考慮すると、この定義で、「知識」という概念が再び登場します。こちらが私が説明しようとしていたことの要約です。この2つの概念は相補的であり、「知識」という重要な概念によって橋渡しされています。つまり、システムの定常状態からの逸脱を検出できるため、カオス エンジニアリングは可観測性によって活用されます。可観測性は、システムの弱点を発見して克服するのに役立つため、カオス エンジニアリングによって活用されます。
シグナル
再び可観測性に焦点を当てましょう。こちらをシェアしたいと思います。可観測性は、システムが発するシグナルに基づき、システムの挙動に関する未加工のデータを提供します。可観測性は、システムが出力するシグナルと、そのシグナルの品質によって制限を受けます。私は 4つのゴールデンシグナル「レイテンシ」「サチュレーション」「トラフィック」「エラー」について話しています。Denise Yu の美しいスケッチノートを使って、みなさんのために短い定義を思い出させてください。レイテンシは、リクエストを処理するのにかかる時間として定義されます。これは、例えば、インシデントでシステムのパフォーマンスが低下している兆候です。トラフィックは、システムにどれだけの要求がかかっているかを示す指標です。例としては、HTTP 要求、セッション、エラー数などです。エラーは、HTTP 500エラーなど、失敗したリクエストの割合です。最後に、サチュレーションとはリソースの使用率のことで、例えばCPUやメモリの使用率です。
こういったシグナルをどのように確かめているでしょう？（画面がダッシュボードに切り替わる：12分12秒あたり）ここでは、システム動作を表示しているGoogle Cloud Platform の一連のダッシュボードを可視化しています。ここでみなさんに質問です。このダッシュボードのカオスがわかったかたは何名ぐらいでしょうか？ カオスとは、システムの正常な状態からの逸脱です。私には、このダッシュボードでは、地域ごとのQPS（秒間クエリ数）に問題があるようにみえます。チャートラインは、このようなタイプのインシデントでは、もっとも一般的な可視化ですが、これは混乱します。というのもタイトルからは波のカウンター（クエリ数）を見てるようで、Y軸は秒単位で時間をマッピングしているからです。軸に適切な色、レイヤー、変数を使わなければ、もっともシンプルなチャートがもっとも分かりにくいチャートに変貌してしまう可能性があることを指摘しておきます。もう一つの一般的なチャートは棒グラフです。棒グラフは、カテゴリーデータを長方形の帯で表したグラフで、高さと長さが、表す値に比例しています。課題は同じです。適切なカテゴリを使用しないと、チャートが混乱する可能性があります。そうした制約を考えると、可視化についてどう思いますか？ これらはカオスを可視化するのに適したチャートです。この話がカオス エンジニアリングについてのものであることを覚えていますか？
視覚的メタファー
ここで、視覚的メタファーという新しい定義を紹介します。視覚的メタファーとは、シミュレートされたアプリケーション・ドメインの概念とオブジェクトから、類似性と類推のシステムへのマッピングです。コンピュータメタファーは、双方向な視覚的オブジェクトとアプリケーション・ドメインのモデル オブジェクトの間で行われる、シミュレーションの基本的なアイデアと考えられています。地図、都市、幾何学的係数などがその例です。（画面がアメリカ合衆国の地図に切り替わる：14分6秒あたり）このイラストレーターの美しい地図をご覧ください。都市メタファーは、プログラムコードの特性を視覚化する一般的な方法です。
多くのプロジェクトが、例えばソフトウェア・リポジトリの特性を可視化するために、このメタファーを採用しています。既存の研究では、パッケージ、クラス、ツールのサイズ、サイクロマティック複雑度を可視化するために都市のメタファーが使われてきました。詳しくは次のスライドでお見せします。（画面が都市に切り替わる：14分42秒あたり）例えば、ここではソフトウェア・システムの特性を示すために、都市のメタファーを用いています。この場合、都市メタファーは、Javaパッケージを近隣、Javaクラスを建物、縦横奥行の寸法をクラスのプロパティ、またはサイクロマティック複雑度として表現しています。
調査
ソフトウェアの運用活動に携わるエンジニアリング・チームの感じ方を明らかにすることを目的にした、あるインシデントに関する具体的な質問の構成で研究しました。ひとつは伝統的なチャート、例えば折れ線グラフや棒グラフで、もうひとつは視覚的メタファーを使いました。状況ごとに、各タイプの可視化の価値が分析されました。そのうちの28人が、従来のダッシュボードと視覚的メタファーについて調査を受けました。具体的には、エラー、レイテンシ、トラフィック、サチュレーション（飽和度）の 4 つのカテゴリまたはメトリクスで、インシデントについて質問を受け、それらを従来のダッシュボード 対 視覚的メタファーで視覚化しました。（棒グラフ：15分37秒あたり）参加者の経歴は、バックエンドエンジニア、フロントエンドエンジニア、フルスタックエンジニア、ソフトウェアアーキテクト、データエンジニア、SREエンジニアに分散していました。ここに示されているように、バックエンド開発エンジニアの参加がもっとも多いです。
最初の質問はサチュレーションのシグナルについてでした。基本的に、ここでは5つのマイクロサービスの状態を尋ねるために、折れ線グラフと都市メタファーの2つのダッシュボードが使われました。認証マイクロサービス、患者マイクロサービス、決済マイクロサービス、投薬マイクロサービス、予約マイクロサービス。これらのマイクロサービスは、架空の医療システムの一部でした。具体的には、この従来の折れ線グラフを使用して、どのマイクロサービスが影響を受けたか？という質問をしました。こちらは各マイクロサービスでのCPU使用率を都市メタファーで表しています。例えば、オレンジ色の線は、決済マイクロサービスの使用率を表しています。この問題の正解は「認証マイクロサービス」でした。どの線と色が各マイクロサービスを表しているかが明確でないため、答えはわかりにくいものです。おそらく、この折れ線グラフは参加者を混乱させたと思われます。というのも、答えはいくつかの選択肢に分散しており、正解を選択したのは55％だったからです。思い出してください。（パイチャート：17分32秒あたり）正解は認証マイクロサービスです。パイチャートの中のオレンジ色のラインを見てください。その一方で興味深いのは、参加者の 11.1% が決済を選択していて、事実上消費が多かったサービスですが、前日はそうではありませんでした※。 ※訳者補足：原文では[聞き取り不可 00:17:49]となっているため内容から類推。
（都市メタファー：17分50秒あたり）同じ質問を、今度は視覚的な都市メタファーにしてみました。各マイクロサービスを表す建物を使用しましたが、例えば、薬局は投薬マイクロサービスを表しています※。 ※訳者補足：原文ではmeditation（瞑想）になっているが動画ではmedicationと発言しており恐らく誤記。 人々のシルエットを使用して、サチュレーションのレベルをマッピングしました。人数はCPUの使用率に比例します。最後に赤色を使用して別の世界を表現したのですが、サチュレーションがある値よりも高い場合、建物はオレンジ色で塗られます。ご覧のとおり、視覚的メタファーは従来のダッシュボードよりも便利でした。参加者全員が、CPUの高い使用率によって影響を受けたマイクロサービスは認証であることに同意しました。仮説の証明にはなりませんでしたが、色や形、大きさによって参加者の「感じ方」が変わるという事実があります。現在私が見ている一部の参加者の公開回答は、例えば最初のかたは、都市メタファーが CPU の現在の状態を確認するのに非常に役立ったと述べています。しかし彼らは都市メタファーは、時間の経過による動きは表現しなかったという主張もしています。他のシグナルはどうでしょう。2 番目のゴールデンシグナルであるエラーについてですが、ご覧のように、従来の棒グラフ、およびツリーマップを使用して、各マイクロサービスのエラーの平均を計算するように参加者にお願いしました。計算すると、正解は予約マイクロサービスであることがわかります。参加者はそれを選択しませんでしたが、視覚的メタファーを使用すると多くの人が答えを変えました。（ツリーマップ：19分43秒あたり）この図は、私が行き詰っていることを示しています。これは参加者の38％が選択したに過ぎません。88％の参加者が、ノードの数が多いだけで、必ずしもエラーが多いわけではなく、正解は認証だと考えているのは非常に興味深いです。
ツリーマップで分布割合は変わりましたが、大多数は正解は認証だと考え続けています。ここでは、従来のダッシュボード、視覚的メタファー、そして正解の答えの分布について、可視化を使用して内容をまとめます。視覚的メタファーは、私たちがデータを適切に解釈していることのもうひとつの保証である、と結論づけることができて興味深いです。2 番目のケースで視覚的メタファーを使用すると、32.1% だけが正しい答えを選択します。（幾何学的メタファー：21分00秒あたり）トラフィックシグナルについては、古典的な棒グラフと幾何学的メタファーを用いて、参加者にどちらのサードパーティサービスにより多くのトラフィック量があるかを尋ねました。このケースでは、オリジナル、マイクロサービス、新しいサードパーティ・サービス、サービスLDAP、サービス・ガバメント、サービス・アシュアランス、サービス認証の相互作用が分析されました。これらは、私たちのマイクロサービスとやり取りする外部またはサードパーティのサービスです。この図は、棒グラフと幾何学的な比喩を用いてこの統合を表現しています。メタファーでは、円はサービスやマイクロサービスを表し、線はそれらの関係を結んでいます。このマイクロサービスとサードパーティ・サービス間の接続とトラフィック負荷を表す線と大きさがあるにもかかわらず、このメタファーは参加者を混乱させました。円の大きさは、少なくともサービス LDAP のパーセンテージに関連付けることができます。それが正解です。これは、円グラフの緑色の部分で表されています。（パイチャート：22分14秒あたり）最後に、もっとも多くの人が、ここに示されているメタファーがより有用であると答えました。ご覧のように、大多数はより良い結果を得るために視覚的メタファーを選んでいます。
重要ポイント
現代のソフトウェア・システムにとって、可観測性とは数学的な方程式のことではありません。それは、人々が複雑なシステムとどのように相互作用し、理解しようとするかということです。ここでの 2 番目の重要なポイントは、カオス エンジニアリングと可観測性には人間とその個々の解釈が関係していることを考慮することです。ダッシュボードの設計者はそれらの解釈にバイアスをかける可能性があるということです。この意味で、視覚的メタファーは、このデータを適切な方法で解釈しているという保証にはなりません。最後に、可観測性とはシステムが発するシグナルのことであり、システムの挙動に関する未加工のデータを提供することを念頭に置くことが重要です。
Q & A
Bangser: さまざまな視覚的メタファーに関する戦略を探ろうと思った理由をお伺いできたら面白いです。どのようにしてこれを始めたのでしょうか。
Roa: ご質問についてですが、なぜこの戦略を検討することにしたのかというと、私の経験では、プレゼンテーションで述べたように、カオス エンジニアリング、可観測性、およびパフォーマンスの視覚化です。プレゼンテーションの個人、ダッシュボードの設計者がそれらの解釈にバイアスをかけられるのは事実です。それが私のこの研究の主な動機です。バイアスが、ここでは主なトピックです。古典的なダッシュボードはバイアスにつながる可能性があるため、ダッシュボードを探索する代替オプションがあれば、オペレーターシステムやエンジニア、クラウドエンジニアにとって非常に価値があるのではないかと考えていました。そのため、視覚的メタファーに基づくダッシュボードは、古典的な視覚化よりも有用なデータを提供できると考えました。しかし、私が先ほど共有した研究の後、どちらの戦略にも同じ懸念があることがわかりました。例えば、幾何学的メタファーに関連する 3 番目の研究を見せたとき、参加者は逆にメタファーによって混乱しました。私にとって、主な動機はバイアスに関連しています。私はこのプレゼンテーションの準備をしているこの研究の間に、どちらの戦略も、またどんな戦略であっても、私たちは人と相互作用しているためバイアスがかかる可能性がある、ということを発見しました。これは、ダッシュボードの設計者にとって非常に挑みがいのある課題です。
Bangser: 「嘘もあれば統計もある」ということわざを以前聞いたことがあります。このことわざの背後にあるジョークは、統計にどのようなフレームとレンズを適用するかによって、人々に見てもらいたいもののバイアスを如実に示すことができるということです。あなたが見せているもの、そして探求しているものは何で、私たちの可視化の伝統的なものが何で、そしてそれがどのようにバイアスに変わるのかが重要です。というのも、私たちは自分の中にあるバイアスに気づいておらず、いつも当たり前にやっているからです。これが本当に重要です。
視覚的メタファーのダッシュボードを改善するために、理解度を評価できると思いますか？
Roa: はい、そうですね。それが私たちへのインプットですから。私たちデザイナーにとって、それは人間の「感じ方」というインプットです。おそらく、より多くの「感じ方」をカバーする、より多くの戦略とより多くのメタファーを提供できるでしょう。これは事実ですが、ダッシュボードを読む人の解釈、経験、背景には限界があります。しかし、効果的なのは、「感じ方、理解」だと思います。より多くの戦略を設計するための最良のインプットを得るために、この「感じ方」を分析するためのいくつかのフレームワークを文献に載せています。というのも、現時点では折れ線グラフや棒グラフなど、クラウドプロバイダーが提供するチャートに限られているからです。一部のツールは可観測性と監視に特化していますが、システムを監視するためのより多くの戦略があります。それは事実です。私たちにはたくさんの可能性があります。現時点で、監視するための戦略はほとんどありませんが、私たちはメタファーの宇宙を持っています。その中には、私の研究がヘルスケアに関連しているように、ビジネスに関連するものもあります。医療、病院、薬局、投薬に関連する建物を使用しました。多くのツールを作り、このトピックについての考えを共有する絶好の機会です。
Bangser: なのでしばしば、ツールのいたちごっこが存在します。そうすると、人々はより多くのツールを使用し始めるるため、ツールはより幅広く、より多くのことに影響を及ぼすようになります。そういうツールがないと、なかなか始められません。あなたが行ったような可視化を作成するためのツールの提案はありますか？ 具体的には、都市の可視化について、他の人たちはどのように始めたらいいと思いますか？
Roa: 私は研究で、今回のケースのために、この都市メタファーをデザインしました。ツリーマップの設計と提供には、一般的なツールを使用しました。いくつかのツールが市場に出回っていますが、例えば都市の場合、3Dで可視化するツールがあります。過去に発表した論文の成果として、いくつかの可視化を提供するツールを作成したので、Slack でリンクを共有します。これらの可視化は、ソフトウェアを可視化すること、ソフトウェアの特性を可視化することに焦点を当てています。具体的には、監視のためのツールが市場にありません。ここでは、拡張や利用が可能なツールをいくつか紹介します。この研究のため、このトピックに関する私の「感じ方」を証明するために、私は円や線を描いているということをはっきりさせないといけないです。
Bangser: これらの視覚的メタファーを見るとき、色はどれほど重要でしょう。この問いをさらに膨らませてお伺いしたいのですが、赤と緑など、色彩が見せたいものの大きな部分を占めている場合、アクセシビリティにはどう対処するのでしょうか？
Roa: 色は本当に重要です。そうです、ここで色はとても重要で、例えば私のメタファーでは、病院では赤色を使っています。ダッシュボードに赤い部分または赤いセクションが表示されると、すぐに注意を引くことができます。これらの色には慣れているからです。赤は火災を表し、警告を表します。同じように緑は何であるか、とか。適切な色を使用することは非常に重要です。例えば、3つ目のメタファーで、私は地球中心的なメタファーを使っていたのですが、それは私にとって本当に興味小深いことでした。というのも、こうしたメタファーは参加者にとってもっと価値のあるものになると期待していたからです。私は同じ色、青とグレーを使っていたのですが、これは紛らわしかったです。例えば、赤や緑は使わない、今回は大きさや形を使おうとしたのですが、参加者を混乱させてしまいました。色は本当に重要だと思うし、人間にとって馴染みのある方法で使用することが本当に大切です。というのも、私たちの理解や経験では、例えば赤色は警告を表すからです。それを利用するべきです。
Bangser: 私たちが最初に注目するのは母集団の大きな部分です。私は色覚異常がないという点で恵まれています。私は赤を見て、赤が停止、悪い、エラーを意味する文化で育ったので、この考え方はしっくりきます。産業は、最後の例で使用しようとした幾何学的な形状とサイズを人々にとってより一般的なものにすることで、よりアクセスしやすくなり、色覚異常やその他の理由により、すべての人に有効かどうかはわからない色への依存度を下げることができると思いますか？
Roa: アクセシビリティの見出しを考えると、それは事実です。現時点では、これは別の実験を行う絶好の機会だと考えています。というのも、私たちのツールにアクセスするために、このような課題を抱えている人が他にもいることを、おそらく私たちは無視しているためです。そのためのアクセシビリティの基準を検討する必要があります。正確には、私はこのトピックに関連するInfoQが発表した研究を読んでいたのですが、ユーザーにとってアクセシブルなアプリケーションを構築するための10のガイドラインが掲載されていました。このための実験を計画できると思いますが、私はこのトピックを研究で考慮していませんでした。それは事実です。このような考察もまた、実に興味深いと思います。
Bangser: そうですね。たくさんの視点があります。それらの多くに取り組まなければなりません。私たちが絶対に取り入れたい側面の 1 つはアクセシビリティですが、他にも非常に多くのものがあり、この調査を通じて、本当に興味深い洞察を得られました。
これはアニメーションに関する素晴らしい質問だと気づいたのですが、というのも、お見せいただいたものがすべて静的であり、方向を指しているという意味で動きのある矢印でさえ、ただの静止した矢印だったからです。可視化にアニメーションや「動き」を追加することを考えたことはありますか？
Roa: はい、システムの状況や状態を示す変数を増やすことができますので、この機会が得られれば素晴らしいと思います。この場合、同じダッシュボードに多くの変数やものがあると、混乱を招く可能性があることを考慮することが重要です。例えば、ダッシュボードに「動き」があると、その「動き」で気が散ってしまいます。ダッシュボードにとっては非常に良いアイデアですが、例えば、ダッシュボード内の「動き」が速いダッシュボードで、ページのこのセクションに適切なダッシュボードがある場合、高い確率で他のダッシュボードに気を取られてしまう可能性を考えると、リスクを考慮する必要があります。それを考慮することが重要です。（少し考えている素振り：36分24秒あたり）うーん、「動き」の欠如。これは、このトピックに関する興味深い議論です。なぜなら、この「動き」というものは、私たちにとってより多くの情報を提供してくれるし、読者にとって非常に価値のあるものになる可能性があるからです。同様のケースで実験する必要があり、ユーザーを理解するために彼らのところに行く必要があります。おそらく、UXの専門家は貴重な存在になるだろうし、ここでも非常に役に立つと思います。ユーザーに適切な可視化を提供するためには、あらゆる選択肢を検討する必要があると思います。これは産学双方にとって絶好の機会です。例えば、可視化や人的要因、アクセシビリティに関連したトピックを研究している人たちがいることを考えると、これは学術的に重要なことであり、例えば博士論文には最適なトピックです。学界でもこれらのトピックを探求する絶好の機会があります。
Bangser: あなたはそこで、色や形や動きを追加するときに使用できる基準の数という、実に興味深いレバーの引き方についておっしゃっていました。これらはすべて、異なる属性を表現する方法です。属性を増やせば増やすほど、さらに混乱する可能性があります。
私はただ興味深いなと思いました。あなたがいくつかの研究結果や、人々を混乱させるようなこと、期待していたような結果が得られなかったことに少し驚いているように見えたので。その驚きや予想外の結果の原因は何だと思いますか？
Roa: おそらく、トラフィックのシグナルに関する 3 番目の研究では、従来の棒グラフと幾何学的メタファーが使用されました。というのも、円や線がユーザーにより多くの情報を提供できると思っていた私にとって、これは本当に意外だったからです。現実は違っていました。トラフィックシグナルに関してはですね、私にとって意外でした。メタファーでは、円はサービスを表し、マイクロサービスはサードパーティ サービス間の関係を表しますが、線とサイズがあります。ここで適切な色を使用しなかったため、このメタファーの問題は色に関連していると思います。もうひとつのケースでは、このインシデント、このカオスですが、おそらく折れ線グラフと単純さは、出席者にとってより役立つ可能性があります。結論から言えば、主な原因は人間にあり、システムに対する私たちの「感じ方」にあると考えます。というのも、私たち一人ひとりが異なる経験を持ち、異なる背景を持つユニークな宇宙だからです。この混乱の主な根本原因は、例えば背景に関するものでした。というのも、詳しく調べてみると、同じような「感じ方」を持っているバックエンドのソフトウェア・エンジニアとフロントエンド・エンジニアは、例えばクラウドインフラストラクチャエンジニアや、エンジニアリングチームで運用トピックを担当する人とは異なることがわかりました。その背景には、少なからず経験があると思います。それが、この種のダッシュボードのデザイナーにとっての挑みがいのある課題です。
Bangser: まさに挑みがいのある課題です。とはいえ、毎日見慣れているものを推測したり、読み始めたりするのは合理的です。例えば、アプリのサイドバーを開くような意味の3つのバーが新しくなったときのことを覚えています。でも今はみんなに認知されて、レパートリーを作り始めることができます。バックエンド、フロントエンド、運用、これら全てといったような幅広い裾野に対応する場合は本当に大変です。
このような新しい視覚的メタファーは、様々な背景を持つ課題や、その他ありとあらゆる問題がありつつも、将来この産業に持ち込むことができると考えていますか？
Roa: はい。ただし、彼らの役に立つようになれたらと願っています。将来的には、メタファーを使ってクラウドと対話できる可能性があることを期待しています。それは素晴らしいことだなと思っています。参加者のために公開された回答を考えることは大切です。カオスの可視化、特に本番環境に関わるインシデントの可視化は、産学にとっていくつかの挑戦であると思います。私はこの扉とメタファーの宇宙を、この産業のプロバイダーのために開放したいです。例えば、いくつかのクラウド・プロバイダーは、私たちのオペレーター・システムにより多くの戦略を提供するために、例えば、ツリーマップやヒートマップで仕事をしています。彼らはそれに取り組んでいます。
今のところ、例えば都市メタファーや、地球中心メタファーを利用する可能性はありません。というのも、例えば、それらのメタファーはビジネスに関連し、組織に関連し、適切で具体的なビジネストピックに関連しているからです。例えば、このようなメタファーを構築するためのツール、メタファーを提供するためのツール、ビジネスや関心事、優先事項をダッシュボードと結びつけるためのダッシュボードを描いたり、提供したり、デザインしたりするためのツールを提供できると思います。クラウド・プロバイダーでダッシュボードをデザインできる可能性があれば、素晴らしいことです。それは、私たちのオペレーターのシステムに価値を生み出す可能性があります。それは大変なことだと思いますが、イマジネーションが許す限りものづくりへの扉は開かれています。
Bangser: おっしゃるように、これらの問題を解決するためには、産学が協力しなければなりません。本当にエキサイティングなのは、クラウド プロバイダーがこの分野で活動を開始すれば、彼らは非常に大きな規模で運用されているため、学界に実際にフィードバックを得ることができるようになり、実際に大規模な研究を実施してフィードバックを得ることができるようになることです。それは産業にとって非常にエキサイティングな機会になるでしょう。