« なぜなに Data Domain - 第十回 - Data Domain システムのアップグレード | メイン | なぜ正確なIOブロックサイズの頻出度とワークロードの分布メトリックが重要なのか? »

2016/06/06

優れた製品を生み出すPernixDataのアプローチ

本ブログエントリーはPernixData社のUser Experience DesignerであるBryan Crowe氏のブログの翻訳版です。Brayan氏はPernixData社のソフトウェアアプリケーションのデザインとユーザビリティ全般の責任者です。PernixDataに入社する前にはVMwareとGoogleで同様な役割を担っていました。PernixDataでは彼の強みであるVMwareでの仮想化のバックグラウンドとGoogleでのビジネスインテリジェンスや分析で培った強力な情報をうまい方法で有益に伝えるというインターフェイス作成の経験を融合させて活動を行っています。

Fig401

Brayan氏はケント州立大学でコンピュータサイエンスの学士と、カーネギーメロン大学でヒューマンコンピューターインタラクションの修士を納めています。彼は素晴らしい技術バックグラウンドを武器に、チームのエンジニアと議論/討論をいといませんし、彼は自身のデザインでいつも周りの開発者が様々なクリエイティビティを発揮することをとても喜んでいます。

本記事の原文はPernixData's Approach to Creating Great Productsで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

私の名前はBryan Croweです。PernixDataでユーザエクスペリエンスデザイナーをしています。ユーザエクスペリエンス(UX)とはいっても、どのようなものなのでしょうか?アプリケーションUIのビジュアル的なルック&フィールのことを思い浮かべる方もいるでしょう。また、全体の構造から情報をプレゼンテーションしながらワークフローを構成することだと考える方もおられるかもしれません。私自身は製品の最も日の当たる部分で、ユーザーに最も総合的に影響を及ぼす部分だと考えています。UIのユーザービリティの部分であることもありますが、あるときはストレージシステムのIOPSやレイテンシレベルだったりもします(例 : 高いIOPSを低いレイテンシで提供するストレージシステム = 優れたユーザーエクスペリエンス)。ですから、ユーザーエクスペリエンスはUXデザイナーだけで完結するものではありません。コードのすべての行、そして暗黙的に提供されるバックエンドの機能をの全てがユーザーエクスペリエンスに影響を及ぼします。本人が自覚していようが、いまいがバックエンドのエンジニアは製品のUXにとても重要な貢献をしているのです。

これまでのところ、上に述べてきた観点、つまり優れたUXという意味では、我々は優れた製品を生み出す素晴らしい仕事ができていると思っています。しかし、何故なのでしょう? PernixData社の製品とエンジニアリングチームはどうしてこれが実現できているのでしょうか?

マネーボール

私はクリーブランド・ブラウンズのファンです(まぁ、まぁ・・・わかってますよ)、更に最近も政権交代が有りました。今回は「マネーボール」の小説/映画のモチーフを地で行く、ポール・デポデスタが買収を行いました。最初の会見でポールは優れた組織はどう見えるものか、競争相手と自身を差別化するためにどのような特別なことをしていくのか、ということについてコメントを述べました。オークランドのAリーグにおいては先進的な分析によって彼はこれを実現してきました。彼のコメントは文字通りです、ですが私は同時に面白いと感じました。それによって私は何がPernixDataのチームにとって特別なものなのか、他との差別化になるのかを考えるきっかけとなったのです。

ユーザーにフォーカスを当てる

ユーザーとカスタマーには厳密な違いが有ります。びっくりすることはありません。カスタマーは製品の購入の責任者ですが、ユーザーはそれを利用する人です。コンシューマーソフトウェアの世界ではこれらの役割はたびたび重複しますが、エンタープライズソフトウェアでは区別されています。エンタープライズソフトウェア製品を作っていながら、カスタマーへフォーカスをしていると、幾つかのハイレベルな機能のチェックを行うことで売上が伸びることに気が付き、一方で実際のユーザーのための細かな部分やニュアンスを見失ってしまいます。これについては最初の取っ掛かりとしては非常に良いソフトウェア製品の作成の仕方だと思いますが、製品を毎日の様に使っていくようなユーザーが短時間に様々な操作を行い、様々なことを発見していくとなるとうまくいかない事になってしまいます。

PernixDataはかなり最初の段階からユーザーにフォーカスをしていました。VP of ProductのBala氏は非常にテクニカルですが、初期の段階からユーザーを巻き込み、ハイレベルから下の方までどのようなニーズを持っているのかということを理解することに積極的でした。さらに、プロダクトのメジャーリリースの度、私はシステムのプロトタイプを使ったユーザビリティ実験を繰り返し、ユーザーが言葉にするどの機能が好き、嫌いという意見だけでなく、どこでユーザーが苦労するのか、どんなユーザビリティ上の問題があるのか、という客観的なデータも集めています。加えて、外部でのベータプログラム(FVP 1.0の際には150ユーザー)も行っていますが、その目的は単に出荷前にバックエンドのクリティカルなバグを探しだすことだけではありませんでした。我々はあらゆるレイヤのスタックそれぞれでどのようにすればシステムがより良くなるかということを探し、理解しようとしています。一度製品が出荷されるとSE達はユーザーからのフィードバックを吸い上げてくれる優れた水路にもなってくれます。とにかく我々は色んな意見やフィードバックを我々のユーザーから積極的に集めようとしています。もちろん、何もしようとしていないのであればこうしたデータは無意味です。。。

変化に挑む

ソフトウェアを生み出す際には事故認識をしっかりとしておくことが重要です。UIのある部分が誤解しやすい、コードのいくらかはバグが有る、そしてとある要件はご判断を生むことが有ります。人間ですから、完璧であるということはありえません、ですからこうした物を横にのけておいたり、単に無視してしまうのではなく、より良い変化のためのきっかけとして利用します。ですが、言うは易し、行うは難しです。

ベータプログラムやユーザビリティテストを事前に行い、結果を利用することは製品出荷前に様々なことがわかるという点では理想的です(SEからフィールドのレポートを待つのとは反対です)。ですが、こうした手法はプロダクトの開発サイクルの終盤に訪れます。すべての会社はもちろん、こうしたメカニズムを通して製品がおかしくなるようなクリティカルなバグは発見、解決済みですが、他の問題やバグは将来に先送りされ、修正されるかもしれませんし、されないかもしれません。では、この問題を解決する秘密の魔法は何でしょうか? そんなもの、ありません。もちろん、プロセスの初期段階で何らかはできるでしょう(例:完成版からは程遠いプロトタイプを使ったユーザビリティテストは初期段階でも行えます)、しかし、そもそも全てを初期段階で行うということは全くもって、現実的ではありません。

実際に最高で、最もしっかりとしたフィードバックはプロセスの終盤にしか出てこないことが有ります。前に述べたとおり、簡単な解決策はありません。ですが、効率的に管理することは出来るのです。まず、情報は適切な組織に全てに行き渡らなくてはなりません。フィードバックが組織の階層とそれによるエンジニアリングチームへの伝達の時間によって極度にフィルタされてしまうということがあります。もういまさら遅い、ということもありますし、何をしていいかわからなくなっているということも有ります。一方で、情報が適切に管理され、伝達されることで、少なくとも戦うチャンスを得ることは可能です。

チャンスを得るためには、適切に配置された正しいチームが必要なのです。正しいことをすることに情熱を燃やし、実現のために延長戦を厭わないエンジニアが必要です。どのアイテムに優先順位があり、適切なエンジニアをアサインするという素晴らしい決定と効率的な判断ができるリーダーシップを発揮するメンバーも必要です。全ての優先順位が適切になった際に、本当に素晴らしいことができるようになるのです。PernixDataでは幸運にもこうした環境があるのです。

驚きと喜び

ユーザーにフォーカスして話をしていると、ここからの学びがどのように活用されているかを話しそびれてしまいます。これは本当にとても長いアイテムのチェックリストになり、それぞれ1つ1つ対応していく事になります。そして、多くの場合これが正しいやり方です。例えば、そこからの考察を経てそれをバネにしてもっと高く飛び上がり、もっと良いことを実現できる場合もあります。例えば、Satyam氏とPoojan氏が会社を設立した時、すでに存在しているソフトウェアの延長線上にあるような改善版を作ろうというようなことは考えませんでした。彼らは自身のユーザー、業界、そして市場に対する知識を用いて、本当にユニークな、新しく、これまでにない方法でストレージのパフォーマンスのモンダを解決するものを作ろうとしたのです。そして、FVPが生まれました。

同様に、FVPの最初のヴァージョンを生み出す中で、ユーザーはIOPS、レイテンシ、スループットが重要なメトリクスであるということは我々はユーザーに対する基礎知識として知っていました。これによって、今日これらの統計の状態を表すグラフを含めるということも比較的簡単に行うことが出来そうでした。ですが、我々はそうしなかったのです。もっといいものがあるという予感があったからです。単にそうした統計グラフを表示するだけではなく、ユーザーが様々なレベルで情報が引き出せ、注目しているデータをブレイクダウンしてもっと環境についての考察ができるようにしたのです。これはエンジニアの工数をより多く使うことになりますが、ユーザーにより気に入ってもらえると考えるものです。その努力は結果に見合うものだったとすぐに証明されました、充分なほどに。ですからすぐに我々は自分自身でインフラストラクチャ分析を中心とする製品の制作に取り掛かったのです。そしてArchitectが生まれました。

細部に神が宿る

FVPの以前のヴァージョンで我々は色盲のユーザーにとってももっと利用しやすいようにと可視化部分で利用されている色を微調整しました。それ以外にも様々な異なる要素を考慮しており、色盲シミュレーターを利用して様々なパレットを検証しました。UXの人間としてこれぐらいは最初にやっておくべきだったのではと思うかもしれません。予想外のことといえば、CTOのSatyam氏のことでしょう。この問題については様々なフィードバック会議を実施しました。実際 Satyam氏はレビューを行い、私が作成したデザインドキュメントのほとんどすべてに対して詳細なコメントを返してくれました。これは彼がある種の凶悪な独裁者だからでしょうか?それはご自身でご判断ください。ですが、真面目な話、これは彼が本当に優れたソフトウェアを作りたいということに情熱を燃やしているからに他なりません。それがUIにおけるほんの僅かな問題であったり、ほんの小さな学区エンドの機能であったとしても彼はその洞察、知見をそれに取り組んでいる人間に惜しげも無く貸してくれます。そうしながら、取り組んでいる人間の最終的な判断を信頼してくれているのです。

正しいことをほんの小さな細かな部分でも徹底するという決意はチームの血肉となっています。我々は小さなことを気にします。個人的にはこうした小さな問題を全て把握しておくことは時折効率が良くないと言われることも理解しています。ですが、それらを集約していくことは結果的には大きな変化となります。これが我々がユーザーから出来る限りの多くのフィードバックを集めそれを解決し、「将来のリリース」まで待ってくださいと放置しない大きな理由です。

まとめ

多くの人や会社が私がここに列挙したようなものが重要だと気がついていると思いますが、多くの人々は上手くやっているとは言いがたいと考えています。知識と実行、この2つは後から見れば全く別のものです。こうしたアイテムを難しくすることは技術的な魔術や分析の能力ではありません。それよりも中途半端に満足せずより予期を目指す取り組む姿勢や志が重要です。PernixDataはより良くなろうと戦い続けており、それが製品に反映されていれば嬉しいです。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)