こんにちは、LAPRASでソフトウェアエンジニアとして働いていることねです。本記事はLAPRASアドベントカレンダー二日目のコンテンツです。
2年ほど前、私は約2ヶ月の期間でNext.js on GCP (Cloud Run/Firestore) という構成で CharaXiv（きゃらしぶ）という「TRPGのキャラクターシートを管理するツール」を開発し、以来2年間ほとんど手放しの状態で運用してきました。積極的な宣伝や広告は打っていないのでユーザー数はせいぜい十数人程度ですが、使ってもらえた人には「使いやすい！」と好評をいただいています。個人的にCharaXivの開発目標が「とにかくユーザー体験のいいキャラシ管理を作ること」だったので嬉しい限りです。ロクに機能アップデートもしていないのになぜユーザーは使い続けてくれるのか？せっかくの機会なのでCharaXivがより使いやすいサービスとなるようにこだわったポイントがいくつかあるので実例をお見せしながら紹介して行きます。
例としてお見せするキャラクターシートのスクリーンショットに写っているアバター画像はキラキラ鱈メーカー3を使用して作成したものです。筆者が制作したものではありません。綾瀬様、素敵なメーカーを公開・ご利用させていただき誠にありがとうございます。
ツールの使いやすさにはさまざまな要素が影響しますが、どんな側面を切り取っても最終的には「認知負荷」に繋がっていると私は考えます。「知りたい情報がどこにあるかわからない」「UIが操作しにくい」「したいことが直感的にできない」「思ってたのと違うことが起きた」などなど。使いづらさの多くは見た目の整理（インターフェースデザイン）によって解決できるものも数多く存在しますが相互作用の整理（インタラクションデザイン）で解決しなければならないものもけして少なくはありません。ユーザーインターフェースとユーザーインタラクション、この2つをシームレスに統合したデザインプロセスこそがユーザー体験（UX）デザインであると考えています。
数多く存在する人間の知覚能力のうち、晴眼者※にとって最も優位なのは視覚と言っても差し支えないでしょう。視覚的なデザインが認知負荷に与える影響もそれだけ大きいことが逆に「デザイン」という言葉が視覚的な要素のみを指して使われることが多い所以なのかもしれません。CharaXivでは視覚の認知をうまく利用して画面デザインを行っています。
※目が見える人のこと。私が「晴眼者」という言葉を使うきっかけとなった連ツイが素敵なので気になった方はぜひご一読されることをおすすめします。
このスクリーンショットを見てどう感じたでしょうか？私が与えたかった印象は「さっぱりしている」です。シンプルなツーカラムレイアウトを採用し左側のカラムには「キャラクターに関するゲームシステムに関係のない情報」を、右側のカラムには「キャラクターに関するゲームシステムと関連する情報」を集約しています。余白の少なさよりもレイアウトのシンプルさを優先したことにより「アバター画像、名前、メモ情報」を参照したい場合は画面の左側を、「能力や技能などの数値情報」を参照したい場合は画面の右側を注視すればよく「どっちのカラムにどの情報があるか？」を覚えなくていいため認知負荷が減ります。二年が経過したことによってより効果的な画面資産の活用方法（右側のカラムを更に多列化することによって横方向のスペースを有効に利用するなど）も思いついていますが、こうして改めて当時の思考プロセスをふりかえって見るとCSS Gridの仕様などの理解が浅いことを素直に認めて妥協した割には極端に悪いデザインではなかったなと感じます。
さて、では次の話題に入る前に以下のスクリーンショットをご覧ください。
「ブラウザがシークレットウィンドウになっただけじゃないの？」と感じた方が多いのではないでしょうか？ある意味正解ではあるのですがそこには「ログインしているかどうか」の違いが生まれています。ポイントは「データの所有者であるかどうかによってほとんど見た目の差分が生じない」ことです。
実際に差分を可視化してみるとその違いの少なさが際立ちます。つまりほとんどWYSIWYG（What you see is what you get; 見た目通りに得られる状態）になっているのです。そのため自分のデータを編集している時も自分のものでないデータを閲覧している時も同じ場所を探せば同じ情報が見つかります。「メモ欄」は際限なく下に伸び続けることができますがそれ以外の配置が固定されている要素のほうが上に描画されているためズレが生じることがなく、「だいたいどこまでスクロールすればどんな情報がある」と直感的に理解することができます。
この「WYSIWYGなユーザー体験にしよう」という決断には過去に私がキャラクターシートを手書きで紙に書いていたことが影響しています。キャラクターシートは自分が記入するだけでなくゲームマスターやキーパーそして一緒に遊ぶプレイヤーなども物理的に同じモノに触れます。自分が書いた文章や設定した数値をそのまま他の人に見てもらう、そんな些細な気持ちをCharaXivユーザーには感じてほしいという願いが込められています。WYSIWYGにしたことで同じURLで編集画面と閲覧画面を表示しユーザー権限に基づいて内容を出し分けることが可能なため、編集用リンクと共有用リンクを別々に用意する必要がなかったのもユーザーの認知不可軽減に一役買っています。
アバター画像がカラム幅いっぱいになるように配置されていたり、名前とよみがなのテキストボックスをボーダーレスにしているのもWYSIWYGな体験よりシームレスに届けるためです。もちろんただ空白があるだけではそこに何かが入力できるのかわからないので、プレースホルダーを入れてカーソルがホバーした時に背景色がつくようになっています。ボタン等は閲覧時に必要な情報が含まれている要素に関してはあたかもページの一部として埋め込まれているかのように（見た目のスタイリングは変えずにdisabledかつcursor-defaultにしている）見せて、そもそも見せる必要のない追加・削除といった操作のためにあるものは非表示にしています。
他に細かいところでこだわった部分といえばこのWYSIWYGスタイルのテキストエディタです。現在はセキュリティパッチの更新のみが行われているDraft.jsというライブラリを使用しており、メモに項目分けやメリハリがつけられるようになっています。この自由度の高く使いやすいメモ機能（+OGP機能）のためだけにわざわざサポート外のシステムのキャラクターもCharaXivで作ってくださる方もいるくらい人気の高い機能です。
しかしそれだけではなくCharaXivは更に「秘匿メモ」という項目があり、これは編集権限のないユーザーがアクセスすると目玉ボタンを押すまで読めない仕様になっています。サーバーサイドでデータをフィルタリングしていないのはゲームマスターやキーパーが秘匿情報に配布内容と齟齬がないか確認したり、シナリオ通過後のプレイヤーがお互いの秘匿情報を読んで話に花を咲かせたりというユースケースを想定しています。ここ数年は特にプレイヤーごとに秘匿情報を配布するタイプのシナリオが増えているため重宝されている機能で、本家エモクロアTRPGのキャラクターシートツールにも（たぶん）逆輸入されています。
また一部の方はお気づきかもしれませんがMarkdownモード切り替えのボタンがあります。さすがにMarkdownのWYSIWYGは当時の実装力では実現できませんでしたが、外部アプリにMarkdownで書かいたメモをコピペして綺麗に表示されるというだけでも喜ばれました。こういった「使える人には使える」、フレーバー的な機能を入れているのもユーザーに愛されているポイントです。
さて、一見ユーザーインタラクションという側面から眺めるとほとんどの要素がよくあるテキストやボタンで構成されているように感じるCharaXivですが一つだけかなり深くこだわった部分があります。
それがこのスクリーンショットに映っている「スライドセレクター」です。TRPGのキャラクターシートは多くの数値を設定する必要があります。キャラクターの人格形成に関わる部分であるメモ作成に次いでキャラクターシートツールで触る時間が長いのが各種パラメータです。そこで私は「なるべくストレスフリーに数値を何度も変更できる」仕組みを追求して「スライドセレクター」に到達しました。ユーザーインターフェース要素としてはごく単純な「マウスやタップで左右に動かして真ん中の強調された値が選択される」という仕掛けですが、ここに至るまでには数多くの棄却案がありました。
一つ目は最もシンプルな「テキストボックス」です。実装が簡単でユーザーの馴染みも深いテキストボックスですが、特にスマホユーザーにとっては大きくユーザー体験を損ねる要素といえます。スマホの場合テキストボックスにフォーカスすると 1. バーチャルキーボードが開き 2. 値を正確に入力し 3. バーチャルキーボードを閉じるという3ステップの操作が生じます。しかもバーチャルキーボードの開閉をする際には画面が上下に大きく動き、その動作もOSによってまちまちなためユーザー体験はあまりよくありません。そのため私はバーチャルキーボードが絶対に必要な場面以外ではテキストボックスを極力使うべきではないと考えています。
二つ目は「プルダウンメニュー」です。とりうる値が事前に決まっているので自然と出てきた選択肢といえるでしょう。しかし結局は値を入力する際の正確性を取り除いただけでテキストボックスと同様にメニューを開いたり閉じたりといった余分な動作が生じるため却下としました。
三つ目は「ラジオボタン」です。テキストボックスやプルダウンメニューとは違い選択用の要素が侵襲的に展開されることはないためかなり希望に近い選択肢と言えました。ところが実際に実装してみるとスペース効率が悪いことがわかりました。排他スイッチ方式にしたとしてもとりうる値の数だけボタンを横並びにするとかなりの横幅になってしまうため、特に横幅の余裕が限られるスマホ環境を考慮すると厳しいものがありました。
そして様々な数値入力方式をとにかく探し続けていてふと目に止まったのが「ドラム式入力」でした。よくある出現パターンとして日付の選択に使われることが多いです。実はこの方式は日付選択の際に常々使いづらいと感じていたため試すことなく却下していました。ところがその日はふと「縦ではなく、横に並べればいいのでは？」というアイデアが頭に浮かびました。
その結果「スライドセレクター」が誕生し、このインターフェースのおかげでパラメータを上下方向に少ない余白で並べることができるようになりました。上下方向のパラメータ間の余白を少なくすることで同一グループ内のパラメータ要素の距離を短くすることができるため、グループ間の余白を減らしてもプレグナンツの法則に則ったグルーピングができ全体的に余白が減る効果を産みました。またパソコンユーザーもキーボードに触れずにパラメータを設定できるためパソコンに不慣れな人でもスマホと同じ感覚で操作できるというメリットもありました。
最後にキャラクターシート画面からは見えない部分のこだわりについて軽くまとめます。まず最重要な機能と位置づけていたのが「自動保存」です。どんなサービスでもそうですが手動で保存しなければならないのは手間です。最近は自動保存が標準化してきているため手動での保存が必要な場合はそれがぱっとみてわかるようなデザインになっていなければ認知負荷となります。幸いCharaXivでは利用者が少ないことを前提に、保存タイミングのスマートな制御を行うことで自動保存を実装することが可能でした。
もう一つのこだわりがOGPです。キャラクターシートは人と共有するものなので共有されたリンクのキャラクターの名前、ゲームシステム、そしてアバター画像がリンクを開く前にわかると一つ一つリンクを開いてブラウザとコミュニケーションツールの間を反復横飛する必要がなくなります。SPAでHackyなことをしなくてもOGPが設定できるようにするためにSSR可能なフレームワークを選んだと言っても過言ではありません。
結果的に二ヶ月で作り切ったこともあってまだこだわりきれていない部分が多いです。また発生頻度は低くても原因がわからない致命的なバグ（おそらくNext.jsの理解不足に伴うもの）があったり、認証認可周りを独自実装したことでセキュリティ的な不安があります。そのため当時と比べてまとまった個人開発の時間が取れず二ヶ月をゆうに超える月日が流れてしまっていますが着々と新しいバージョンを開発しています。
https://jpattonassociates.com/dont_know_what_i_want/
アジャイル開発ではよく「インクリメンタルに作るな、イテレーティブに作れ」と言われますが、Jeff Patton氏のブログから拝借した上記の画像でいえばすでに世の中のキャラクターシートツールは段階1に到達したところからのスタートでした。私の知る限りはいずれの既存ツールもクローズドソースなため手元のコード資産がゼロの状態から少なくとも1と2の間、基本的な機能に加えてユーザーの認知負荷をなるべく軽減する施策を追加した状態でリリースする必要がありました。これがレッドオーシャン（需要がさほど大きいわけではないのでレッドと言うほどレッドでもないですが）に飛び込む大変さかと身にしみました。しかし上手に実装するものの取捨選択を重ねたことで結果的に段階1.5くらいのツールがリリースできたと思っています。あれからSSRツールの選択肢が増え個人的に最近とても使いやすいと感じているSvelteKitだったりいっそ割り切って完全にFirebaseに乗っかる覚悟を決めたりと次のイテレーションを一人でまた回すために空き時間をなんとか探して実装を進めています。
ここまで読んでくださった方に私がUXにかける思い、ユーザーの負荷を減らすために思慮を尽くしていることが少しでも伝わっていたら嬉しいです。