私のチームで使っている、スクラム開発からリーンソフトウェア開発へ移行する過程で取り入れたプラクティス
ゲーム開発に使っているがWeb開発にも使えると思う。
60点品質の利点
ミニマムリリースが可能になる。
「絞った」リリースとそれに沿った開発になるため、開発速度が非常に早く、UX品質も高く保てる。
リリース後のユーザー反応を見ながら後出しジャンケンでユーザー要望に基づいた優先度をつけつつ改修できる。
問題
「絞った」開発であるので、機能的には完成していても、使ってみると粗があったりバグが見つかったりして全体的に「使いづらい」という感覚を持ちやすい。
これはフィーチャーベースのタスク管理をしているなどの問題もあるが、その「フィーチャーベースでの完成」と「UXベースでの完成」の間を埋めるプラクティスが必要になる。
そこで、継続的デリバリーを一歩進め、40点リリースというプラクティスを導入した。
40点リリースは「フィーチャーベースで完成」したプロダクトを、テストプレイとフィードバックをへて「UXベースでの完成」に近づけるプラクティスである。
成果
UXベースでのユーザー反応の値が相当改善された。
テストプレイしていても使いやすいプロダクトに感じる。
優先度をつけたタスク消化をしやすいため、開発速度を落とさずにUXを高く保てた。
40点リリース
α版のリリースのこと。
60点リリースの前には必ずプロダクトデザイナーによるユーザー品質の担保を目的としたUXテストを行う。
プロダクトデザイナーによるα版をプレイするためのたたき台。
この40点リリースするためのブランチがmasterないしdevelopになる。すなわち、本流のブランチは常に最低でもα版程度の完成度を有していなくてはならない。
α版であるので当然粗はある。
たとえばフラグ管理がおかしくてイベントを見ていないから開かないはずの扉が開いたり、セリフがおかしかったりする。当然それはITSにタスク起票される。
しかしそれはプロダクトデザイナーにとって最もチェックしたい項目ではない。
プロダクトデザイナーはそれをプレイし、「難易度のおかしさ」「xxパラメータのゲームバランスの問題」「UX的に見てこの情報の出し方は唐突だし見落としやすい」などのフィードバックを行う。
フィードバックには「可及的速やかに直す」ものから「直さずともリリース可能」なものまである。
それを取り込み、プロダクトデザイナがOkを出すと60点リリースが可能になる。
修正者もテストプレイする必要があるが、関心の向き先が狭く、見落としやすい。
また、見落としたものを探すためにだらだらと手動テストを時間をかけて行うのは無駄である。
そこで、効率良く、深く、執念深く探し、高い品質のフィードバックを返す存在としてプロダクトデザイナーが存在する。
プロダクトデザイナー
役職としてのロールの１つ。アメリカのゲーム業界やWeb業界に多い。
デザイナーを名乗るがWebやゲームでいうデザイナーとは異なり、「設計者」「意匠者」としての性格が強い。
デザイナーとしてのキャリアパスもUIデザイナーなどとは完全に別種であり、UXやユーザー欲求への知識と理解が求められる。
プロダクトを「ユーザー視点」で操作し、ユーザー視点に基づいた報告、提言や改修要望を出す。
100回以上のプレイを行うが、プレイのたびに「不慣れなユーザー」として振舞う。
時には「コーナーケースをつきまくる超上級者としてのプレイ」「説明の半分も読まない粗雑なプレイヤー」などの典型的なある種のロールプレイとして振舞いゲームをプレイする。
プロダクトデザイナーに要求される能力
深いUXへの知識と理解
プロダクトの方針と哲学、ビジョンへの理解
訴求対象、プレイ対象のユーザー層の分析と理解
高いフィードバック能力
プロダクトと現実の状況とリリース戦略を理解した対応優先度の判断能力
これらの能力を備えた人間でないと単なる「α版をプレイするテスター」に成り下がる。