RE ENGINE ツールのUX改善その後

RE ENGINE ツールのUX改善その後 「RE ENGINE ツールのUX改善その後」を始めます。 以前、2019年のカプコンオープンカンファレンスで、「ユーザー中心の設計思想による RE ENGINEのUX改善の取り組み」を 紹介させていただきました。 それから4年ほど経過していますので、今回は、その後どうなったか？という事でアップデート版として皆さんに 情報共有させていただきたいと思います。 よろしくお願いいたします。 -------Python® is registered trademarks or trademarks of Python Software Foundation. ©CAPCOM 1

今回のお題目 ・はじめに ・エンドユーザーとは誰？ ・で、どうなった？ ・プログラマー開発環境の改善 ・ShaderGraphでの改善例 ・デザイナーとの分業 ・デザイナーが意識したところ ・ツール改善の流れ 2019年のスライド ・UX改善の動機 ・デザインコンセプト ・UXデザイン方法論 ・エンドユーザーとは ・開発体制について ・UX改善プロセス ・デザインプロトタイプ ・ユーザビリティテスト ・プロモーション ・フィードバック ・まとめ ・まとめ 今回皆さんと共有する内容はこのようになります。 2019年は画面右のような内容を発表させてもらいました。 2 ©CAPCOM 2

今回のお題目 ・はじめに ・エンドユーザーとは誰？ ・で、どうなった？ ・プログラマー開発環境の改善 ・ShaderGraphでの改善例 ・デザイナーとの分業 ・デザイナーが意識したところ ・ツール改善の流れ 2019年のスライド ・UX改善の動機 ・デザインコンセプト ・UXデザイン方法論 ・エンドユーザーとは ・開発体制について ・UX改善プロセス ・デザインプロトタイプ ・ユーザビリティテスト ・プロモーション ・フィードバック ・まとめ ・まとめ 今回2023年は、このあたりについて情報をアップデートさせていただきます。 3 ©CAPCOM 3

はじめに まずはじめに、前提となるツールとしての、達成項目と開発者のモチベーションについてお話します。 4 ©CAPCOM 4

はじめに 達成必須項目 ツール実装での 優先順位 よりよくするために… 1 目的を達成できる 4 間違った表示をしない 2 安定して動作する 5 操作を間違いにくい 3 高速に動作する 6 他ツール同士の操作感が大体同じ 7 きれいな見た目 まず、何よりも大前提としてツール実装での優先順位はこのように考えています。 やりたい事が出来て、安定高速に動作する事は、まずもって優先されます。 ここがある程度出来ていないうちは、見た目や操作感の話は、なかなか出来ません。 ©CAPCOM 5 5

はじめに 達成必須項目 ツール実装での 優先順位 よりよくするために… 1 目的を達成できる 4 間違った表示をしない 2 安定して動作する 5 操作を間違いにくい 3 高速に動作する 6 他ツール同士の操作感が大体同じ 7 きれいな見た目 1.2.3 をベースに、 6 ©CAPCOM 6

はじめに 達成必須項目 ツール実装での 優先順位 よりよくするために… 1 目的を達成できる 4 間違った表示をしない 2 安定して動作する 5 操作を間違いにくい 3 高速に動作する 6 他ツール同士の操作感が大体同じ 7 きれいな見た目 4.5は、繰り返しゲームの面白さを試行錯誤するうえで重要です。 7 ©CAPCOM 7

はじめに 達成必須項目 ツール実装での 優先順位 よりよくするために… 1 目的を達成できる 4 間違った表示をしない 2 安定して動作する 5 操作を間違いにくい 3 高速に動作する 6 他ツール同士の操作感が大体同じ 7 きれいな見た目 6.7も、ゲームの試行錯誤や、ツール操作習得の学習コストにとって重要ですし、 長時間利用する場合の疲れへの配慮としても重要になってきます。 8 ©CAPCOM 8

はじめに 達成必須項目 ツール実装での 優先順位 よりよくするために… 1 目的を達成できる 4 間違った表示をしない 2 安定して動作する 5 操作を間違いにくい 3 高速に動作する 6 他ツール同士の操作感が大体同じ 7 きれいな見た目 達成必須の項目と、よりよくする為のものがあり、より良くする為に RE ENGINE で取り組んでいることが今日のテーマです。 9 ©CAPCOM 9

はじめに MT FRAMEWORK RE ENGINE 開発の大規模化は続く 複数ゲームの同時開発 2000人アクティブユーザー ※2019年のスライド 2019年のオープンカンファレンスでも発表したように、開発は大規模化しました。 １つのゲームの開発の大規模化もありますが、 RE ENGINE の場合は複数ゲーム開発が同時に行われる、横方向への開発の大規模化があります。 ©CAPCOM 10 10

はじめに 開発の大規模化は続く 複数ゲームの同時開発 2000人アクティブユーザー ユーザー側でのツール拡張が標準に 当然、RE ENGINE が提供するツール類は汎用のものが多く、特定のゲームに適したツールばかりではない為、 ユーザー側でのツール拡張も当然のものとなっています。 特にゲーム進行やキャラクターの個性付けなどのパラメーター調整などはゲームタイトル側の人間が作る必要があります。 11 今回はこのタイトル拡張の話はしません。 ©CAPCOM 11

はじめに ツール開発者の欲求 こういう事情があるため、RE ENGINE では、日々、UXを改善していく事は、以前よりも増して、重要な要素となっています。 では、ツール開発者個別、個人単位にとって、UX改善するモチベーションはどこにあるか？ 12 ©CAPCOM 12

はじめに 要求に応えたい ・高品質エンジン ・ラピッドイテレーション ツール開発者の欲求 まず、ゲーム開発を取り巻く、要求に応えたい RE ENGINE 全体が、RE ENGINE が目指す方向に沿いたいという事。 13 ©CAPCOM 13

はじめに 要求に応えたい ・高品質エンジン ・ラピッドイテレーション 達成したい ・ユーザーに喜ばれたい ツール開発者の欲求 ・良いものが出来る ・やってて楽しい 次に、達成したい ユーザーに喜ばれたい、良いものが出来たという達成感、そもそもツール開発自体が楽しいという事などが挙げられます。 14 ©CAPCOM 14

はじめに 要求に応えたい 避けたい ・高品質エンジン ・ラピッドイテレーション ・いやなフィードバックは 受けたくない ・苦手な仕事はやりたくない 達成したい ・ユーザーに喜ばれたい ・UX警察に見つかる ツール開発者の欲求 ・良いものが出来る ・やってて楽しい あとは、避けたい。 ユーザーから、ツールに関して嫌な事は言われたくないですし、 ツール開発に苦手意識があったら、積極的にやりたいとは普通は思わないです。 15 UX警察に見つかるのを「避けたい」という理由もあるでしょう。 開発している人数も多いので、能動的、受動的、ポジティブ、ネガティブ、どのような動機であれ、 最終的に UX改善につながってくれればなんでも良いです。 ©CAPCOM 15

はじめに 2019年にこんな問いかけをしました 2019年にこんな問いかけをしました。 16 ©CAPCOM 16

はじめに 2019年にこんな問いかけをしました 唐突ですが こんな経験ありませんか？ 唐突ですが、こんな経験ないでしょうか？ 17 ©CAPCOM 17

はじめに プログラマーにツールを頼むと ボタンやタブがたくさん並ぶ プログラマーが作ったツール、ツールの目的そのものは達成しますが、ボタンやタブがただただ沢山並んだり、 18 ©CAPCOM 18

はじめに プログラマーにツールを頼むと 似たエディターの ボタンやタブがたくさん並ぶ テイストが全然違う 似たようなツールのテイストや操作感が全部違う。 これはノードグラフ系ツールで実際に発生していました。 19 ©CAPCOM 19

はじめに 似たエディターの プログラマーにツールを頼むと ボタンやタブがたくさん並ぶ こんな経験 ありませんか？ テイストが全然違う みなさん経験ありますよね？ 20 ©CAPCOM 20

はじめに ツール開発の問題点 プログラムの問題点 ・デザインガイドラインが無く実装時に迷う ・ボタンのスタイルはどれが適切？ デザインの問題点 ・プログラマーのセンスが光る！（光らない） ・実装者の力量がむき出し ・時間の余裕がないことも含む ユーザーの問題点 ※2019年のスライド まずプログラム側の問題点としては、どのようなデザインにすればよいか迷う、UIデザインのゴールを決められないという事。 そして、それはプログラマーの感覚にゆだねられているという事。 あと、時間的な余裕がない事も大きな理由になります。 21 ©CAPCOM 21

はじめに ツール開発の問題点 プログラムの問題点 ・統一感がない 同じスパナアイコンが 違う意味で利用されている ・見た目、操作方法 ・一つのアイコンを使いまわし デザインの問題点 ・同じ機能で違うアイコン ・同じアイコンで違う機能 ・ボタンの並びがガタガタ ・UIの意味が伝わらない ユーザーの問題点 ※2019年のスライド デザインの問題点としては、統一感がなかったり、見た目や操作感が、ガタガタ。 アイコンが適切に役割を果たしていないなどが、簡単に発生してきます。 22 ©CAPCOM 22

はじめに ツール開発の問題点 プログラムの問題点 ・なんとか使えるが デザインの問題点 ・フラストレーション 小さな問題に ・慣れるのに時間がかかる 見えるだけ ・小さい問題なので改善優先を上げにくい ユーザーの問題点 ※2019年のスライド ユーザーからすると、我慢すればとりあえず使えるという状況です。 さらに良くないのが、小さい問題なのでユーザーが改善優先を上げにくい事です。 23 ©CAPCOM 23

はじめに ツール開発の問題点 プログラムの問題点 問題の集大成 デザインの問題点 ユーザーの問題点 これら沢山合わさって、 24 ©CAPCOM 24

はじめに ツール開発の問題点 プログラムの問題点 問題の集大成 デザインの問題点 ワークフローの問題 ユーザーの問題点 ワークフローの問題として表面化します。 25 ©CAPCOM 25

はじめに ワークフローの問題点 ・一部のツールに小さい問題（に見える）がある 問題の集大成が ワークフローの問題発生となり 効率を落とす ワーク ワーク ワーク フロー ※2019年のスライド １つのツールの機能不全が、 26 ©CAPCOM 26

はじめに ワークフローの問題点 ・迂回したワークフローを構築する場合がある 問題の集大成が ワークフローの問題発生となり 効率を落とす ワーク ワーク ワーク ワーク ワーク フロー ※2019年のスライド 迂回した、ゆがんだワークフローを構築する場合があります。 ワークフローの問題は、ツールの問題を避けようとした事が、原因である場合もよくあるという事です。 「運用で回避」は、出来る限りはやめに修正した方が良いのは、言うまでもありません。 ©CAPCOM 27 27

エンドユーザーとは誰？ 次に、エンドユーザー定義についてです。 28 ©CAPCOM 28

エンドユーザーとは誰？ ？ ツールを開発をするうえで、使用者にあたるエンドユーザーを定義する必要があります。 このあたりも2019年から変わっていません。 29 ©CAPCOM 29

エンドユーザーとは誰？ ユーザー範囲が広い RE ENGINE に限らず、ゲーム開発はユーザーの範囲が広いです。 ですので、ツール開発時に迷わない、ゆるぎない絶対的な基準がまず必要でした。 30 ©CAPCOM 30

エンドユーザーとは誰？ ユーザー範囲が広い テクニカルスキルで基準分け エンドユーザーを、作っているモノや担当している箇所ではなくて、問題解決能力を表す、テクニカルスキルで基準わけします。 31 ©CAPCOM 31

エンドユーザーとは誰？ テクニカルスキルとは ・自ら問題の解決が出来るかどうか ・問題解決の為に誰かの助けが必要 上級ユーザーたちの時間を消費する ・サポートコスト RE ENGINEプログラマー テ ク ニ カ ル ス キ ル の 習 熟 度 RE ENGINEを拡張できる Python®で拡張できる RE ENGINEのワークフローを把握 RE ENGINEの初心者 テクニカルスキルの低い層への エンドユーザーが最も多い サポートは高コスト テクニカルスキルとは、何かすごいモノを作れるスキルというわけではなく、 自分でツール上の問題を解決する事が出来るスキルです。 エンドユーザーは基本的に、自分でツール上の問題を解決する事が出来ないと定義します。 要は、ツールサポートの為に、誰かを呼び出す確率が高い集団をエンドユーザーとします。 32 エンドユーザーに使いやすく、わかりやすく、といったあいまいな基準に対して、 １つの、固い基準をツール開発者が共通して持つ事が出来るようにします。 ©CAPCOM 32

エンドユーザーとは誰？ サポートコストについて ・ユーザー数とグループ分け エンドユーザーが最も多い ・サポートコスト テクニカルスキルと人数を考慮 テ ク ニ カ ル ス キ ル の 習 熟 度 エンドユーザーが最も多い 「これは、使いにくいと思うよ？」というように、「より良くしよう」としても、実装優先が下がりがちですが、 「これは、たぶん呼ばれてサポート対応が大変になるよ」というように、 いわゆる、損失を避ける為のものとすると、優先して対応が必要な強い理由になります。 33 仮に、ツールを作った自分にまでサポート対応が来ずとも、ただそれは上級ユーザーがサポートを肩代わりしているだけですので、 また違った形で、上級ユーザー経由で改善要望が来ることになります。 ©CAPCOM 33

で、どうなった？ で、どうなったか。 2019 年からの、ツールを取り巻くところの変化を挙げてみます。 34 ©CAPCOM 34

で、どうなった？ 過去 現在 ・とりあえず使えれば良い ・細かな操作感の話は最初から聞く ・UIのズレが気になるが放置している ・多少はUXに気を使ったものが出てくる ・右クリックや謎のキーの組み合わせがある ・まだ重い ・重い ・ボタンサイズや マージンを統一 ・ボタンサイズずれ ｚ ・枠線が合ってない ｚ ・他のパネルと同じ挙動 ・マージンがまばら ・表示ずれを解消 左から右に、過去から現在です。 「とりあえず使えれば良い」なんて発言も実際に経験していますが、少なくとも私の周囲ではあまり聞かなくなり、35 最初から操作感の話やユーザーの意図に沿っているかなどの会話を耳にすることが多くなったような気がしています。 その結果、UXデザイナーが関与しない場合でも、多少は気を使ったものが出てきています。 ©CAPCOM 35

で、どうなった？ 過去 現在 ・デザインの話をすると煙たがられる ・プログラマーはUXデザイナーに相談できる ・エンジンの人にUX的な話が通じない ・最初からUXデザイナーを含める機会が増えた ・担当者ごとに操作感が異なる ・ツール同士の操作感は課題になり修正される 昔はプログラマーに操作感の話をすると面倒くさがられました。 今でも面倒ではありますが、プログラマーはUXデザイナーへの相談という手段が取れるので、 話を聞いてなんとかしようと行動するところまでは出来ています。 36 ツールによってはツール開発担当は違うが、ユーザーは同じというものがあります。 問題提起はユーザーからがほとんどですが、それらツールのテイストの違いも課題となって、 修正する動きがちょくちょく起きる事になりました。 そして、機能を新規開発するものは、最初からUXデザイナーが関与して欲しいという、 開発体制についての要望もユーザーから上がるようになっていきました。 プログラマーだけで作らず、UXデザイナーをまじえて作った方が、良いツールが出来上がるという事が、 ユーザー側でも認識されてきています。 ©CAPCOM 36

で、どうなった？ 過去 現在 ・状態を色だけで表現しがち ・UIのズレや細かな色味の違いは少なくなった ・色味は誰も監修していない ・原色はあまり使われなくなった ・アイコンや色の意味がツールによって異なる ・古いアイコンがまだ残っている ・原色がよく使われる 昔はプログラマーが UI/UX デザインをしていたので、ツール内のオブジェクトの状態は色だけで表現しがちでした。 色だけの違いは学習コストが高くて、覚えてもすぐ忘れてしまうのであまり多用は出来ませんので、 あくまでも補助的な役割に留めるべきではあります。 37 ©CAPCOM 37

で、どうなった？ 過去 現在 ・プログラマーが頑張って用意しても、落胆される ・Visual Studio Image Library から選ぶ アイコンは主語にならず、 価値提供の為の手段として利用するよう ・アイコンや色の意味がツールによって異なる になってきた ・勝手に大きさを変更してしまい、表示がにじむ 色だけでの種類分けは、プログラマーは自分自身でアイコンが作れず、選ぶことしかできないのでこれは当然かもしれません。 UXデザイナーがいる事で、アイコンなどの、形で表現するか、色で表現するか、レイアウトや操作の工夫で表現するかなど、 実装の選択肢が広がりました。 38 ©CAPCOM 38

で、どうなった？ ツールほぼできました！ UX 見てください！リリースは明日です！ UX改善を言い出した頃、最初はよくこういう事も、よくありました。 ツールできましたので、あとはUX的な監修をお願いします！！ 明日リリースします！！ 39 というような依頼です。 これ、確実にUX改善の登竜門ではあるのですが、 ©CAPCOM 39

で、どうなった？ ツールほぼできました！ UX 見てください！リリースは明日です！ 失敗 UI のごく一部の調整しか対応出来ない ・これは良くない事だという事を、チームプログラマーに理解してもらう ・レイアウトや操作感も含めて、UX デザイナーが関われる事を認識してもらう やり方としては失敗です。 UX改善の精神は、理解しているけれど手段がまだ伴っていない状態です。 40 次回の取り組みから、はやめに相談が貰えるように環境作りをしていけば良いかなと思っています。 ©CAPCOM 40

プログラマー開発環境の改善 過去と現在で変わった部分について紹介しましたが、プログラマーの開発環境についての改善も必要でした。 UXについて目を向けようとすると、UXの事を考える余裕を持ってもらわないといけません。 UXデザイナーの参加や、やろうという意思だけではなく、持続可能な取り組みとするためには、 実装面でのサポートも必要になります。 ©CAPCOM 41 41

プログラマー開発環境の改善 過去 現在 .NET Framework 4.8 .NET 6.0 WPF WPF C#7.3 C#10 Visual Studio 2019 Visual Studio 2022 ツールのコードは 10ユニット以上、100人以上が変更する 参考セッション 「RE ENGINE Philosophy」 「RE ENGINEのこれまでとこれから」 まず、ツールの開発環境は時代の流れとともに変わっています。 全てのツールコードを .NET Framework 4.8 から .NET 6.0 にアップデートしましたのでそれに伴って色々と変わっています。 .NET 6.0 は破壊的変更が大変多く、事前調査と変更はかなり慎重に計画を行い、実施しました。 42 ツールの開発者はかなりの人数がいますので、ツール基盤部分の充実と標準化は開発効率に大きく影響します。 この開発の体制と規模感は別セッションの 「RE ENGINE Philosophy」 「RE ENGINEのこれまでとこれから」でも解説していますので是非ご確認下さい。 ©CAPCOM 42

プログラマー開発環境の改善 WPFのXAMLコーディングルールを設定 統一したデザイン関連プログラミング リソースの指定方法 基本コントロールの整備 アイコンの使い方 ライブラリを整備してルールを守りやすくしていく WPF の XAML コーディングルールを定め、デザイン関連のプログラミングにも統一感を持たせるようにしました。 アイコンの使い方やリソースの指定方法の標準を作り、基本コントロールの整備と強化を行いました。 43 つまりは、デザイン関連のライブラリを整備してルールを守りやすくし、 問題があればライブラリの整備担当者に相談をしやすいようにします。 ©CAPCOM 43

プログラマー開発環境の改善 デザインガイドラインの整備 ・色、アイコン、サイズ等の指定 ・組み合わせたレイアウトはデザイン知識が必要 プログラマーは基本のみしか対応できない ・応用が効かない為、UXデザイナーに都度相談 ・プログラム記述時のサポート環境が必要 基本的な箇所に関して、デザインガイドラインを作っています。 簡単な色やアイコンの利用ルール、サイズ等の指定はプログラマーにもガイドラインは機能します。 44 ただ、レイアウトに関してはデザインの基本知識が必要で、組み合わせて応用したレイアウトはUXデザイナーへの相談が必要です。 プログラマー用にはデザイン関連のプログラム記述用のサポート環境の充実が必要でした。 ©CAPCOM 44

プログラマー開発環境の改善 マークアップ拡張で記述可能に ・基本的な WPF リソースは、 コンバーター マークアップでアクセス ・StaticResource 例外が発生しない ・MergedResourceDictionary 不要 ・XAML インテリセンスに優しくなることで、 ブラシ、カラー コンパイル対象になり利用箇所が把握可能に WPF のリソース指定方法を、マークアップ拡張で簡単に扱えるようにしました。 WPF のリソースは、キーを前方宣言する事が必要です。 前方宣言の記述は面倒ですので、#include の感覚で MeregedResourceDictionary を使って楽をすると、 45 同じ WPF リソースをXAML毎に重複して読み込む事になります。 XAML そのものは単なるリソースですので、コンパイルはされないので、記述の通りにリソースが重複して読み込まれ、 ツールが大きくなっていくにつれてじわじわと重くなって、結果的に使い物にならなくなります。 WPF を知っている方なら、App.xaml に記述する方法もあるんじゃないかと思うかもしれません。 それも良いのですが、マークアップ拡張を使うと、コンパイル対象になりますので利用箇所が把握しやすくなります。 また、StaticResource 例外を原理的に起こせなくなりますので非常に安心してプログラムが組めるようになります。 ©CAPCOM 45

プログラマー開発環境の改善 基本コントロールを再デザイン ・要求を満たし、高速化 ・亜種を作りたくならないように Sample Control ビュー ・動作するカタログをRE ENGINE 上で表示 ・非推奨コントロールには警告アイコン ・エンジン開発者とタイトルツール開発者は 共にこのビューを見る 様々な基本コントロールを再検討して、必要なものは再デザインしました。 RE ENGINE では基本的なコントロールも内製しています。 スライダーなどは特に、値の範囲の扱いを変えたいという要求から亜種が作られがちです。 重い場合も、各自で軽量版を作られてしまいがちです。 46 これらを再検討して、出来る限り通常利用の延長で賄えるように要求を満たして、高速化しました。 使って欲しいコントロールは Sample Control ビューでカタログとしてみる事が出来ます。 色々理由があって、使って欲しくないコントロールは Obsolete アトリビュート指定すれば カタログ内で警告マークを付ける事ができるようになって、開発意図を伝えやすくなります。 RE ENGINE のツール開発者も、ゲームタイトル側のツール開発者も共に同じビューをみます。 ©CAPCOM 46

プログラマー開発環境の改善 画像出力可能 マニュアルが作りやすい Description サイズの規定を作り 他所への転用を制限する 誤用を制限 種類の多いアイコンをRE ENGINE上で一覧可能に 誤用が多かったアイコンについても、アイコンビュー上で用途など確認可能にしました。 さすがにここを見て選んでもらっていれば、なんとなく、雰囲気で利用する事はなくなります。 アイコンビューを見ながら UXデザイナーに相談したり、UXデザイナー側での確認などもスムーズになります。 47 アイコンはベクター形式なのですが、png画像への出力ボタンがあるので、 プレゼン資料やマニュアルに使ったりする事も簡単になりました。 ©CAPCOM 47

プログラマー開発環境の改善 まだまだ不足している 手動でStyleを適用しがち TextBlock の文字色 White を指定 Margin = 2, Margin = 0 古いXAMLコード参照のStyle で 古いXAMLコードを参照する をつい書いてしまう 機能分けしている箇所がある 情報共有が行き届いていない 細かなデザイン調整を 書いてしまう とはいいつつも、まだまだ Margin 調整は必要ですし、手動で Style も適用してしまいますし、 動作モードのバリエーション変更の為に Style を適用しなければならない現状もあります。 TextBlock の Foreground 文字色に White をわざわざ指定してしまって文字がまぶしくなる事もあり、 情報共有が行き届いていない状況ではあります。 48 ライブラリ側でのサポートと、古いコードの修正、標準化をもっと進める必要があると考えています。 ©CAPCOM 48

プログラマー開発環境の改善 ツール作成を新人研修メニューに取り入れる 新入社員 10名～15名 講師社員 2年目～4年目 20人～30名 (中途社員も受講する場合がある) 各担当ユニットのメンバーが講師 ・カリキュラム構成の考案 ・中堅、ベテラン社員も手伝うことがある プログラマー環境改善の為、体系立てたツール作成研修を作って取り入れています。 受講生の新入社員、そして講師になる社員が何年も、研修を繰り返す事で入れ替わり、内容が定着し、文化となります。 49 ©CAPCOM 49

プログラマー開発環境の改善 GitLab の MergeRequest 上で指導 WPF に慣れる 段階的なカリキュラム構成 UI/UX 研修 リソースの扱い 成果物のDiffツール メニューとしては、WPFの段階的な基礎練習をしながら、現在は差分比較ツールを題材にUI/UXを含めた内容になっています。 差分比較ツールなら、プログラマーに重要な、データの扱い方についても自然に学べます。 50 ©CAPCOM 50

プログラマー開発環境の改善 ツール研修のポイント ・データ構造, C#, WPF, XAML ・３層アーキテクチャ(MVVM) を利用したもの ・最低限の UI、UX についても研修に含まれる プログラマーよがりなツールにならないように心がける 最初が肝心！ ツールを作りますので、データ構造、C#、WPF、XAML、そして、３層アーキテクチャについて学びます。 ３層アーキテクチャは、現在は MVVM の考え方を採用しています。 数年保守する前提のツール開発は専門学校や大学ではほとんど経験しない事ですので、 初めて UI を考えるという社員も多いです。 51 研修自体は、配属先での教育コスト削減が主な目的です。 この研修段階から UI/UX の事も普通に触れておくと、最初から、それが普通なんだという共通意識にもなります。 何が普通なのかといった事は、ある程度入社年数が経ってしまうと変わりにくくなりますので。 ボタンが押せればいいじゃんという意識は、最初から完全に否定しておきます。 とにかく、最初が肝心でございます。 ©CAPCOM 51

ShaderGraphでの改善例 実際に、やった大きな改善の例を紹介します。 52 ©CAPCOM 52

ShaderGraphでの改善例 Master Material Editor 旧来のシェーダーノード用のエディターの問題 ・起動が低速（3分～10分ほどかかる） ・ノード数に耐えられず、通常動作が低速 ・VertexShader と PixcelShader を 同じキャンバスで扱えない ・エラー箇所がわかりにくい ・10年以上利用し、耐用年数超過 速度について改善の要求が強いが抜本的な対策が難しい事が判明 シェーダーノード作成用のエディターの問題改善が必須でした。 動作が非常に重く、機能的にも、VertexShader と PixcelShader が別タブになっていた事も ユーザーの評判はあまり良くありませんでした。 53 いろいろな機能的な問題と速度の問題を解決しようとすると、このエディターの補修程度では既に頭打ちで、 アセットのデータ部分から作り直す必要があるという事に確信をもちましたので、 ShaderGraph エディターとして新しく作り直す事にしました。 ©CAPCOM 53

ShaderGraphでの改善例 ShaderGraph Editor 結果、お手本となるエディターの決定版が出来た ・完全に作り直す為、専任UXデザイナーをつける ・TA、Shaderアーティスト(ユーザー)全面参加 ・ユーザビリティテスト15名以上 取り組みの結果としては、ShaderGraph エディターは、RE ENGINE の中ではツールのお手本になるものとなりました。 この時、完全につくり直す為、専任のUXデザイナーをつけました。 TA や Shaderアーティストとの合意形成も早くから丁寧に行い、協力を得ました。 みなさん、高速になるという事で喜んで協力してくれましたので、かなり助かりました。 ©CAPCOM 54 54

ShaderGraphでの改善例 細かい表現を明確な色分けで対応 複雑なコントロール整理 エディター起動時のパフォーマンスを考慮したデザイン エディター起動時のボトルネックは、DataContractJsonSerializer の重さが大半を占めていましたが、 エディター起動後のパフォーマンスのボトルネックは、主にレイアウトの再計算コストでした。 パフォーマンスを重視しつつ、デザインとしても破綻しないように細かな部分まで調整する必要がありました。 ©CAPCOM 55 55

ShaderGraphでの改善例 接続コネクター部分をノードの内部に配置 ノードの中身は自前で描画してWPF のレイアウト要素は不使用 ノードサイズの無駄な変化が発生しないよう、固定値を多く使ったデザインに変更しました。 ノードの接続コネクター部分はプログラムが簡単になるという事と、 ノードと接続線のリサイズを原理的に発生させたくないという理由でノードの内部に置きました。 56 ノードは、内部要素の変化によってサイズ再計算を発生させない事と、 オーバーヘッド削減の為にノードの中身は自前で描画して WPF のレイアウト要素は使わないようにしました。 ©CAPCOM 56

ShaderGraphでの改善例 サイドに設置されているコントロールカテゴリは入れ替えが可能 RE ENGINEでは珍しい縦メニュー展開を提案 ノード以外には、より広い作業スペースを確保する為に、縦型のメニューを提案して採用しました。 メニューの場所が固定されやすくなり、メニューを探すときの目線移動も、少しの横移動だけで済みます。 結果的にメニューを見つけやすくなります。 ©CAPCOM 57 57

ShaderGraphでの改善例 モックアップツールの用意 ・初期から参加メンバーに触ってもらった ・デザインや操作感を合わせる ・それぞれのセクションが試しやすい環境を用意 これらのデザインの操作感や表示などは、モックアップツールだけで確認する時期がありました。 協力してもらっているテクニカルアーティスト、シェーダーアーティスト達とは、 新しいデザインのモックアップツールを通してコミュニケーションをとりました。 この中で、最終的な ShaderGraph エディターのデザインと操作感のイメージを合わせておきます。 58 エディターのパフォーマンスが出しやすく、プログラマーがプログラムしやすくて、 ユーザーが使いやすいデザインをこの段階で試行錯誤していきます。 UXデザイナーも一緒に全体の実装デザインの提案と、デザインリソースの作成をしてくれました。 この時点で、４名のユーザーが工数を割いて参加しています。 ©CAPCOM 58

ShaderGraphでの改善例 V1→V2アセットのアップコンバートサポートあり 同ノード構成は同 VGPR 値での動作を保障 ・パフォーマンスの差異は製品に影響する ・様々なテストを作成 あと、最も大切だったことは、出力したシェーダーコードのパフォーマンスと描画結果を同じにすることです。 アセットのデータから丸ごと作り変える為、過去のエディターと新しいエディターで差があると、 新しいエディターを使わない理由が生まれてしまいます。 アップコンバートするツールをユーザーの手元で手軽に使えるようにして、乗り換えやすくしました。 59 また、描画結果に関してもかなり様々な角度からのテストを用意し、発売済みの過去タイトルも利用して念入りに行いました。 ©CAPCOM 59

ShaderGraphでの改善例 パフォーマンス 改善 思 っ て い る 完 成 度 UX改善 シェーダーコード 維持 100％ 作業期間と完成のイメージの差 完成 ・モックアップ作業 ・周辺の関連ツールも同時に更新 90％ ・出力 HLSL のパフォーマンス維持が大変 50％ 100％ 実際の完成度 新しい ShaderGraph への乗り換えは UXデザイナーがいたおかげでプログラマーとしては、 楽ではありませんが専門外のデザイン面で悩む頻度は減りました。 ３か月程度はモックアップ作業をしていて、 使い勝手の確認はユーザーであるテクニカルアーティストとシェーダーアーティストが行い、 ツール開発者のUXデザイナーとプログラマーは随時モックアップのアップデートを行っています。 60 これらの期間、UXデザイン自体は当然試行錯誤はありましたが、 その試行錯誤自体も開発の通常工程として計上していきました。 全体でいうと、実際はパフォーマンスの互換性担保がこのツールの作り直しの全体の中でかなり大きなウェイトを閉めていて、 それだけで半年分くらいの工数がかかったもしれません。 ©CAPCOM 60

ShaderGraphでの改善例 ShaderGraph みたいにしたいけど、 後発のエディターが自然と追従してくる UXガイドラインありますか？ ExprGraph(算術式をノードで作成) VisualScript等 ShaderGraph を作っている途中やリリースした後には、 他のエディターでも ShaderGraph のように したい。と言われる事が増えました。 61 ©CAPCOM 61

ShaderGraphでの改善例 ShaderGraph みたいにしたいけど、 後発のエディターが自然と追従してくる UXガイドラインありますか？ ExprGraph(算術式をノードで作成) VisualScript等 自然発生的にグラフ系のお手本となった 強制は一切していない これは自然にお手本になり、自然に言われだした事で、 強制などは一切していないので ShaderGraph の取り組みの良い効果だったと言えると思います。 62 ©CAPCOM 62

デザイナーとの分業 次は、デザイナーとの分業についてです。 63 ©CAPCOM 63

デザイナーとの分業 分業のメリット それぞれが何年もかけて専門的な勉強をしてきている プログラマーから見て、UXデザイナーと分業する事はメリットが多いです。 プログラマーは、プログラムを仕事に出来るレベルでプログラムができると思いますし、 何年もかけて専門的な勉強してきています。 64 デザイナーも同じで、デザインを仕事に出来るレベルでデザインが出来ますし、何年もかけて専門的な勉強してきています。 ©CAPCOM 64

デザイナーとの分業 デザイナーが参加 すごく頑張ってデザインしても 責任を分担でき、 反応はイマイチ プログラマーが抱え込まなくて済む プログラマーから見て、デザインの専門知識を持った人間に、 同じコンテキストで相談できるという事はとてもメリットになります。 私はプログラマーですが、すごく頑張ってデザインしても、 ユーザーからの反応はイマイチだったという経験は結構あります。 65 そんな時、デザイナーがいれば、少なくともイマイチな出来にはならないですし、 イマイチな反応がきたとしても責任をデザイナーと分担できます。 イマイチだというユーザーからの要望を、解決方法がわからないまま、ダイレクトに抱え込まなくて済みます。 専門外の分野の問題を抱え込むのは、かなりしんどい事です。 ©CAPCOM 65

デザイナーとの分業 より使いやすいツールをユーザーに提供できる デザイナーは新しいコントロールやアイコンが 必要か判断して提案してくれる プログラマーにとって 新しい発見と可能性が見いだせる 他のメリットとして、より良いツールを提供できるようになってきます。 UXデザイナーに相談すると新しい発見がありますし、だいたい自分より良いレイアウトを作ってくれます。 プログラマーだけで考えていると、新しいボタンや新しいアイコンが必要だと思う場面でも、 無くても大丈夫にしてくれる場合もあります。 ©CAPCOM 66 66

デザイナーとの分業 プログラマーからは正確なデザイン指示は出ない ? ? ? デザイナーのことを、アイコンなど絵素材だけを 作ってくれる人だと思っている コミュニケーションをしっかり行い、 役割を明確にすることが重要 アイコンの話が出たのでもう少し掘り下げます。 デザイナーから見ても、プログラマーからは細かいデザイン指示は出てきません。 プログラマーから見ても、デザイナーはアイコンを作ってくれる人だと最初は思っていて、 何のアイコンを頼めば良いか？という事を良く考えてしまいます。 ©CAPCOM 67 67

デザイナーとの分業 プログラマーは機能を画面に足しがちになる 制作中は機能追加に集中してしまうため、 画面がボタンやアイコンでいっぱいになりやすい プログラマーは特に、機能を画面に足す事を考えがちです。 足し算が主な解決方法になると、どんどん画面が、ボタンやアイコンで埋め尽くされてしまいます。 68 ©CAPCOM 68

デザイナーとの分業 プログラマーは機能を画面に足しがちになる 制作中は機能追加に集中してしまうため、 画面がボタンやアイコンでいっぱいになりやすい 画面が忙しい状態 いわゆる、「画面が忙しい」という状態になっていきます。 UXデザインの基本にたちかえって、ボタンを足す前に、ツールで実現したい事を見直します。 異なるスキルを持った者同士が相談しあう事で、この基本に立ち返る場面を多く経験しました。 ©CAPCOM 69 69

デザイナーとの分業 プログラマーの課題 デザイナーの課題 一緒に開発することで、 レイアウトの工夫を見せて、 「アイコンを足す」 「アイコンを作ってくれる人」 思考から抜け出す を抜け出す UXデザイナーと一緒に開発する事で、 多くのプログラマーがおちいりがちな「アイコンを足す」という思考から抜け出せるようになってきます。 逆に言うと、UXデザイナー自身は、 うまくレイアウトの工夫をやって見せて、「アイコンを作ってくれる人」から抜け出す必要があります。 プログラマーが思いつく程度の、依頼されそうなアイコンは無い状態にする必要があります。 UXデザイナーは最初はアイコンなどのデザインリソース作りでとても忙しくなりました。 70 では、次のパートでは、RE ENGINE の UXデザイナーがデザインで意識したところについて紹介してもらいます。 ©CAPCOM 70

デザイナーが意識したところ では、ここからは RE ENGINE開発に関わった UXデザイナーが意識したところについて紹介します。 UXデザイン作業というと、アイコンや色の調整など見た目の作業が中心となりますが、 その中で何を意識して取り組んだかと、悩みや課題についてご紹介します。 ©CAPCOM 71 71

デザイナーが意識したところ それぞれのセクションが重視するポイント 目的に合った機能、少ない負荷 色、レイアウト、ディテール それぞれのセクションが重視するポイントとしては、 プログラマーは目的に合った機能や少ない負荷、デザイナーなら色やレイアウトなどがあげられますが、 ©CAPCOM 72 72

デザイナーが意識したところ それぞれのセクションが重視するポイント 目的に合った機能、少ない負荷 色、レイアウト、ディテール 認知負荷による業務へのストレスの軽減 UXデザインに関して最も重要なのは「認知負荷による業務へのストレスの軽減」となります。 73 ©CAPCOM 73

デザイナーが意識したところ 認知負荷による 業務へのストレス ユーザーが画面を見たときに 機能を探す作業は、 あ の どボ こタ だン っ け ・ ・ ・ スムーズでないといけない 大きな画面を開いたときにユーザーが次に行う作業は、必要なツールやボタンなど操作できるものを探すことです。 表示されている膨大な情報から見つける作業はスムーズでなければいけません。 ©CAPCOM 74 74

デザイナーが意識したところ 認知負荷による 業務へのストレス 些細な表示の違いで、 脳は情報の処理が走る なにかしらツール作業で必要な機能を探すときは、 レイアウトの変化や、色やアイコンの違い、差し込まれる線などを目で追って見分け、判断することで実行されます。 75 ©CAPCOM 75

デザイナーが意識したところ 認知負荷による 業務へのストレス 目で追いながら処理中……… 些細な表示の違いで、 脳は情報の処理が走る 色、線、アイコン、文字、線、色、場所、アイコン、文字 このような確認のための見る行為というものは、ちょっとした線や色でも頭の中では無意識に処理が働きます。 76 ©CAPCOM 76

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） その中で、コントラストを考えていない配色バランスや、見ていて目がつらい配色の問題 77 ©CAPCOM 77

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス レイアウトの問題 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） 操作手順に迷う、崩れなどによるレイアウトの問題 78 ©CAPCOM 78

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス レイアウトの問題 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） 挙動の問題 ボタンを押したときの反応、動きや誘導の問題 79 ©CAPCOM 79

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス レイアウトの問題 頻繁に 発生 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） 挙動の問題 といったことが頻繁に発生した場合、 80 ©CAPCOM 80

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス レイアウトの問題 頻繁に 発生 パフォーマンスの 低下 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） 挙動の問題 ユーザーは無駄に体力を使うことになり、本来行うべきである作業に支障が出てしまいます。 81 ©CAPCOM 81

デザイナーが意識したところ 認知負荷による 配色の問題 業務へのストレス レイアウトの問題 頻繁に 発生 パフォーマンスの 低下 意図できない体裁は、 無駄に脳の処理を増やす （ 高負荷になる ） 挙動の問題 デザイン調整が必要 それを少しでも和らげるためにUXデザインで調整することが必要です。 82 ©CAPCOM 82

デザイナーが意識したところ 配色の問題 ・色に統一感が無い ・眼に辛い配色 ・見にくい、色がキツイは 見るだけで体力を使う 色であれば、視認性を上げたいからといって、キツイ色を使いまくるのは良くありません。 また、背景色に近すぎて、目を凝らさないと確認できないのもNGです。 これをやりすぎるとかなり目が疲れるので、 ©CAPCOM 83 83

デザイナーが意識したところ 配色の問題 ・色に統一感が無い ・配色ルールを設定 ・眼に辛い配色 ・アイコンをカテゴリごとに色分け ・見にくい、色がキツイは ・落ち着いた色に調整して、 見るだけで体力を使う 目のダメージを軽減 見て内容が判断できるように、表示物と背景カラーとのコントラスト調整などバランスの良い配色を心掛けます。 見るだけで体力の消耗が激しい表現は絶対避けましょう。 84 強い色はここぞというときだけに使うといいと思います。 ©CAPCOM 84

デザイナーが意識したところ レイアウトの 問題 ・各入力の役割が理解しにくい ・ボタンなどの間隔が近い レイアウトについても、 昔に立ち上げたツールで、少しずつ機能を追加していっているものや、 新規でとりあえず作業できる状態のツールだと、機能が整理されていないケースがありますが、 ©CAPCOM 85 85

デザイナーが意識したところ レイアウトの 問題 ・各入力の役割が理解しにくい ・余裕のあるスペースの取り方 ・ボタンなどの間隔が近い ・操作を整理しボタンを一つに そういったものに関しては、 要素のグループ化、手順の整理、機能の場所などしっかり整理してあげることで、 作業のしやすさと、ツール自体のさらなる拡張性が見えることもあります。 ©CAPCOM 86 86

デザイナーが意識したところ 同じようなデザインで違う動作 ゲームオブジェクトの表示 アセットの編集 挙動の問題 ステータス挙動がバラバラ 操作時の挙動も重要です。 似たような表示のアイコンで、選択後の結果がツールごとに違う動作だったり、ツールごとにマウスオーバーの反応が違うと、 ユーザーは不安でツールを使いこなすことはできません。 87 ©CAPCOM 87

デザイナーが意識したところ 同じようなデザインで違う動作 デザイナーが制作、使用の管理 ゲームオブジェクトの表示 アセットの編集 挙動の問題 ステータス挙動がバラバラ エンジン内のインタラクションを統一 インタラクションによる表現は一貫性のある動きが無いのが一番ストレスになります。 ボタンに書かれている表記と反応は正しいのか、行った行動に対して誘導は正しく行われているかなど、 細かい配慮を形にして、行動を明確にしていきます。 88 想定された動きが確認できるようになっていると、ユーザーは変に違和感を感じることが無く、作業を行えます。 ©CAPCOM 88

デザイナーが意識したところ 一貫性のあるデザインを作っていくことで 心理的な努力を減らすことができる 配色の改善 レイアウトの 改善 挙動の改善 以上のような検討を繰り返し、日々取り組んでいます。 UXデザインを駆使して一貫性のあるデザインを作っていくことは、心理的な努力を必要としない部分が増えますので、 最終的にユーザーの作業効率を上げることができます。 89 ©CAPCOM 89

デザイナーの悩みと課題 コミュニケーション不足 ・ニーズを正しく理解できなかった ・改善内容をプログラマーに理解してもらえない ・認識違いが出やすくに壁を感じることがある プロジェクト開始のタイミング 悩みと課題 ・遅いタイミングだと、大した作業も出来ず 根本的な改善にならない UXデザイナーが参入して、うまくいかなかったことは結構あります。 参入したての頃などは当然ですが、なかなか手段が見いだせず悩みも多かったです。 その中でもコミュニケーションの問題は大きいです。 セクションごとの言葉の認識違いが思ったより発生し、ニーズを理解しきれず失敗したことがあります。 90 また、声を掛けられるタイミングもツールのリリース直前ですと、改善案を用意するとしても、時間的に足りないことがありました。 そういったものは色や要素の整列程度で、根本的なところが見れなくなることがあります。 ©CAPCOM 90

デザイナーの悩みと課題 ? 実装難易度、処理負荷の判断が難しい ・距離感がつかめず、ストレスが多い ・気になって遠慮がちな提案になる 未分野ツールの対応 悩みと課題 ・専門といっても、何でもできるわけでもない ・学んでいく必要があるので時間が必要 そして技術的なところが判断しにくいところ。 UXデザイナーが細かい処理や実装難度の判断をするのは、かなり困難です。 それが気になって提案自体が遠慮がちになってしまうこともあります。 91 最後は、UXデザイナーの未開拓分野のエディターだった場合です。 例えばモーションやシェーダーが専門外だった場合、知識的なところを埋めながら進めていく必要があります。 こういった課題は、コミュニケーションを重ね、認識を深めていくしかありません。 ©CAPCOM 91

ツール改善の流れ 次にツール改善の流れを紹介していきます。 92 ©CAPCOM 92

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース ざっくりと３フェーズにまとめると、このような感じです。 プログラマー、デザイナー、エンドユーザーの３セクションが関わります。 簡単な対応ですと最初の段階は簡略することがありますが、大体このような流れとなります。 ©CAPCOM 93 93

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース 内容は様々 ・色がわからないの調整してほしい ・追加機能の設計を頼みたい ・ツール全体を改修するので見て欲しい 対象のツールと 環境の準備と ・新規ツールの立ち上げに参加してほしい 業務内容の把握 役割の把握 課題の発生時は、エンドユーザーまたはツールの担当プログラマーから連絡が来ます。 内容は色の調整をしてほしいといった小さな相談から、 ツール全体を改修するため、深くかかわってほしいといった相談など様々です。 94 まずは、UXデザイナーと担当プログラマーで対象のツールや内容を把握していきます。 現行で確認できるものであれば、チャットツールを駆使してスグに取り掛かることもできるのですが、 規模が大きい場合は、確認しながら作業出来る環境が必要になるので、プログラマーに用意してもらいます。 ©CAPCOM 94

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース 内容は様々 ・色がわからないの調整してほしい ・追加機能の設計を頼みたい ・ツール全体を改修するので見て欲しい 対象のツールと 環境の準備と ・新規ツールの立ち上げに参加してほしい 業務内容の把握 役割の把握 業務内容と役割を明確に ただ、専門的すぎるツールの改善は、要点がつかみづらいので、業務の内容と役割を明確にする必要があります。 ここがまとまっていないと、何度でもこの段階に戻ることになります。 95 ©CAPCOM 95

ツール改善の流れ 課題の発生 ・内容を確認しながら デザイン作業 ・提案用資料を作成 プロジェクト進行中 テストとリリース ・質問回答の対応 ・細かい相談に対応 ・内容に対する相談と実装 ・要望を出す ・デザイナーに要望を出す ・チーム内の周知 固まってきたところで実作業の開始です。 プログラマー・選定されたエンドユーザーとコミュニケーションを重ね、 エンジン全体から見てどのような形が最適かを模索しながら改善案を用意していきます。 ©CAPCOM 96 96

ツール改善の流れ 課題の発生 ・内容を確認しながら デザイン作業 ・提案用資料を作成 プロジェクト進行中 テストとリリース ・質問回答の対応 ・細かい相談に対応 ・内容に対する相談と実装 ・要望を出す ・デザイナーに要望を出す ・チーム内の周知 実装・確認を繰り返し、理想の形へ 提出した案がよさそうであれば、モックアップで形にしていきます。 UXデザイナーは必要な絵素材を用意し、プログラマーが実装と確認を繰り返すことで理想の形を作り上げていきます。 97 ©CAPCOM 97

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース ユーザーテストを続けてリリースへ ・テスト時はマニュアルの準備を ・開発用に用意した資料のバックアップ 最終段階は、ユーザーテストを繰り返してリリースとなります。 リリース時はツールのチェックやマニュアルの準備、資料やデザインデータの整理などもしっかり行います。 リソースのまとめは今後参加される人員のためにも非常に重要です。 怠らないようにしましょう。 ©CAPCOM 98 98

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース このような流れで一旦のプロジェクトは終了しますが、 99 ©CAPCOM 99

ツール改善の流れ 課題の発生 プロジェクト進行中 テストとリリース 正式リリース後もツール改善は続く 時期や状況によって必要な機能、要望は変化する さらなるツールの向上を目指そう 正式な運用が始まった後も、様々な改善点は出てきます。 エンドユーザーからも意見や要望が来るでしょう。 内容によっては対応の可否を判断し、改善を行うことによって、さらなるツールの向上を目指します。 ©CAPCOM 100 100

ペルソナとユーザーテスト では次に、ペルソナとユーザーテストについてお伝えしていきます。 101 ©CAPCOM 101

ペルソナとユーザーテスト 対象のペルソナ タイトル開発をしている エンジンチーム 参加依頼 エンドユーザーまたは テクニカルアーティスト ユーザーの参加は実用化のために必須 専門の代表になりそうな方を選定して関わってもらう 内製ツールのUX改善におけるペルソナとは 今までに何度も出てきた、タイトル開発をしているエンドユーザーになります。 彼らの要望に合わせてエンジンチーム側は、 負荷やエンジン全体の実装ルール、UXデザインなど様々な要因から考慮し改善を行っていきます。 ©CAPCOM 102 102

ペルソナとユーザーテスト エンジンの人は忙しそうで 話しかけづらい 意見が却下されたら 心が痛い ユーザーの 何処に相談したらいいか わからない モチベーション ですが、ユーザーはエンジン開発者とは近いようで遠い存在なため、 規模が広すぎてどこに意見を出せばいいかわからなかったり、 103 ©CAPCOM 103

ペルソナとユーザーテスト 細かな見た目の粗は プログラマーに話が通じない エンジンの人は忙しそうで 話しかけづらい 出したい要望が技術的に 困難かわからない 意見が却下されたら 心が痛い ユーザーの 何処に相談したらいいか わからない モチベーション 使いにくいものを 使い続けたくない 技術的なことがわからず意見しづらいなど、貴重な案を出せずにいる機会がいまだに見られます。 エンジン側はそれらをどのようにスムーズにできるかが大きな課題となるでしょう。 特にツール改善の最終段階であるユーザーテストは彼らの力が絶対に必要です。 ©CAPCOM 104 104

ペルソナとユーザテスト 実装チェック ユーザーテスト 直前テスト 大掛かりなラボ形式はやらなくなった テクニカル アーティスト 小規模でテストの回数をこなす方針へ変更 エンドユーザー フェーズごとに対象ユーザーは違う ユーザーテストは一通り機能の実装が完了したところで開始します。 テストは今まで大掛かりなラボ形式で考えていたのですが、準備も手順も大変なので小規模に変更しました。 105 現在は複数に分けられ、段階に合わせて対象のユーザーのタイプを切り替えています。 ©CAPCOM 105

ペルソナとユーザテスト 実装チェック ユーザーテスト 直前テスト 大掛かりなラボ形式はやらなくなった テクニカル アーティスト 小規模でテストの回数をこなす方針へ変更 エンドユーザー Experimental版の準備 スグに試せる環境で早いフィードバック対応 フェーズごとに対象ユーザーは違う エンジンチームとユーザーの溝を埋める 進める際にはすぐに試してフィードバックを受けられるExperimental版の用意は大変重要です。 早い対応でエンジンチームとエンドユーザーの溝を埋めることができます。 ©CAPCOM 106 106

ペルソナとユーザーテスト 実装チェック メンバーは少数のＴＡを選定 期間は一週間程度 テクニカル アーティスト チャットで要望を聞き、早い対応を行う 最初のフェーズではテクニカルアーティストを少数集め、一週間程度の期間触ってもらいます。 コミュニケーションはチャットが中心で、問題のない要望から対応を行っていきます。 107 ©CAPCOM 107

ペルソナとユーザーテスト 実装チェック メンバーは少数のＴＡを選定 期間は一週間程度 テクニカル アーティスト チャットで要望を聞き、早い対応を行う ・課題が明確になり格段に内容が良くなる ・意思疎通と改善対応が早い ・セクション間で顔が効く人を含めるとなお良い 要望はチャットに流れたものをピックアップできますし履歴も残るので、早い対応が可能です。 メンバーの選定に関しては、セクション間で顔が効く人を含めることができると、 全体に周知されやすくなるので、進めやすくなります。 ©CAPCOM 108 108

ペルソナとユーザーテスト 直前テスト エンドユーザーは広い範囲のセクションで参加。 期間中に環境を触ってもらう エンドユーザー フィードバックはアンケートフォームを用意 ある程度改善できれば、次のテストです。 もう少し広い範囲のセクションで参加してもらいます。 ここでのフィードバックはチャットだと内容があふれて重要なものを取り逃してしまう可能性があるので、 専用のアンケートフォームを用意して、期間内に書き込んでもらうことにしました。 それを取りまとめて、リリースに向けた修正改善を行っていきます。 ©CAPCOM 109 109

ペルソナとユーザーテスト 直前テスト エンドユーザーは広い範囲のセクションで参加。 期間中に環境を触ってもらう エンドユーザー フィードバックはアンケートフォームを用意 ・エンドユーザーは誰でもいいわけではない ・スキルや役割が偏った人だけを集めないようにする ・プログラマーやテクニカルアーティストだけ、 ベテランばかりの選定は失敗しやすい エンドユーザーは誰でもいいわけではなく、対象のツールを使う可能性がある人をセクション間で選定してもらいます。 スキルや役割が偏った人だけを集めないようにしたほうが良いです。 プログラマーやテクニカルアーティストだけ、ベテランばかりの選定は失敗します。 110 デザイナーからは以上となります。 ©CAPCOM 110

まとめ では、まとめです。 111 ©CAPCOM 111

まとめ デザインガイドラインだけでは守り切れない 大半はデザイナー向けにしか機能しなかった ・簡単な色、サイズ等はプログラマーにも機能する ・組み合わせたレイアウトはデザイン知識が必要 プログラマーだけでは基本のみしか対応できない ・応用が効かない為、UXデザイナーに都度相談する ・プログラマーにはプログラム時のサポート環境が必要 やってみてわかりましたが、 簡単な色やアイコンの利用ルール、サイズ等の指定はプログラマーにもデザインガイドラインは機能します。 112 ただ、デザインの基本知識が必要な、これらを組み合わせた、応用したレイアウトはあまりうまく行かなかったと思います。 やはり、UXデザイナーに都度相談していく事が必要で、 プログラマー用にはデザイン関連のプログラム記述をサポートする環境の充実が必要でした。 ©CAPCOM 112

まとめ 大がかりなユーザーテストは避ける エンジンチーム側とユーザー側の溝を埋める ・少ない手間でテスト版を配布できる環境 ・持続可能な仕組みの構築が必要 テストは小規模で回数をこなす ・段階ごとにユーザーを切り替えていった ・チャットやアンケートをフル活用し、 早い対応を心掛けた 仕組みの上でも、ユーザーにテスト版の配布環境を用意する事は、エンジンチーム側とユーザー側の溝を埋めることができます。 UX改善と同時にスグに試せる環境があると、ユーザーからのフィードバックと、その反映を試すサイクルを早くする事に効果的です。 継続できるように、大掛かりな事は避けて小規模で回数をこなす事の方が効果的でした。 113 ©CAPCOM 113

まとめ プログラマーの意識の変化 過去 : UXの監修をお願いします！ 現在 : UXデザイナーに早く参加してもらう ツールが出来て、リリース直前に聞いてくる 要件が決まり切っていないが相談を開始しよう 色や多少の配置くらいしか手直しできない プログラマーがデザインで悩む時間が減った 過去には、ほぼツールが出来上がって、リリース直前に相談される事も多かったですが、 現在ではまだ要件が出そろっていないようなうちからUXデザイナーにも声がかかるようになりました。 プログラマーだけでデザインを考えていた時は、デザインの試行錯誤の為にXAMLを延々と触る事があり、 気が付いたら退社時間になって1日が終わったという事もありました。 114 今では「デザインに悩んで」 という理由でXAMLを延々と編集し続けるという事は無くなっています。 ©CAPCOM 114

まとめ ツール開発の変化 コミュニケーションの機会が増えた 質も向上した デザイン的な手戻りは少なくなった リリース前に検討した方が遠回りにならない ユーザーはフィードバックを ユーザーはフィードバックを あまり気負いせず言える あまり気負いせず言える 後から見つかった問題も気兼ねなく話せる環境 デザインの話も通じる 全体的には、プログラマーとUXデザイナーは適宜相談しあうようになってきており、 そこにユーザーも入ってきてコミュニケーションの質が向上しました。 ある程度ツール開発中にデザインについての監修が入りますので、デザイン的な手戻りは少なくなったと思います。 115 UXデザイナーも存在しているという事をユーザーが知ると、ユーザーが相談してくる内容にも幅がでます。 これまでよりは気負いせずにフィードバックが出来るようになったと思います。 ©CAPCOM 115

まとめ ユーザービリティは専門家に任せる ・デザインの試行錯誤に時間を使わない ツールエンジニアの時間 ・レスポンス問題の解決に時間を使おう ・研究開発に集中し、ツールや技術を進歩させる デザインの試行錯誤に時間を使わない ・コンテンツ作成ワークフローを支援する 結論としては、UXデザイナーはツールエンジニアからデザインの試行錯誤の時間を取り除きます。 UXデザインが得意な人に任せる事で、全体的な効率と品質向上につながると考えています。 116 UXデザイナーがツール開発で機能しだすと、デザインの話もプログラマーに通じるという事をユーザー側も知るようになります。 今まで宙に浮いていた、使い勝手の話が前進する原動力になります。 内製ツールにUXデザイナーの担当を用意する事は、今までとやり方が大きく変わる事があり、最初は戸惑いもあります。 お互いに、やった事が無い仕事のやり方になりましたので、試行錯誤の連続でしたが、 お互いの得意分野を活かせるようになるまで根気よくやってきて良かったと思っています。 まだ取り組まれていない場合は是非取り組んで見て下さい。 ©CAPCOM 116

ご清聴ありがとうございました 以上になります。ご清聴ありがとうございました。 117 ©CAPCOM 117