ヤフーがたどった、UXの品質を担保するチェック体制の変遷
CreatorZine編集部（以下、編集部） 本日はよろしくお願いします。まずは町田さんのご経歴からお伺いできますか？
町田 私は2007年にヤフーに中途入社し、前職はチームラボで受託開発のデザインを行っていました。ヤフーではメディアやコマース、検索などいろいろなサービスに携わり、現在はYahoo!ニュースのニュースデザイン部の部長とUX推進本部の本部長を兼務しています。経歴の特徴としては、サービス開発のデザインを行いながら、入社して1～2年でUIガイドラインチームのいちメンバーになり、UIや品質管理にまつわることも並行して取り組んできた点です。
編集部 さまざまなサービスに関わる中で、ヤフーのUI/UXへの取り組みはどのような変遷をたどってきたのですか？
町田 ご存じのとおり、メディアやコマース、金融、検索まで、ヤフーのサービスは非常に多岐にわたります。各サービスの市場におけるステータスは、立ち上げフェーズ、グロースフェーズなど当然異なりますし、ターゲットの違いから追うべき事業KPIもさまざま。市場も成熟度もバラバラなサービスが集まっている点が、ヤフーの大きな特徴です。
編集部 幅広いサービスをそれぞれ提供している中でも、UIや品質管理への熱は高かったわけですよね。
町田 そうですね。3代前の社長・井上雅博の時代までさかのぼると、当時は「UIガイドライン」という基準を定めたドキュメントや、品質をチェックする専門部隊「QA」がありました。そこからOKをもらうことができないとリリースができないため、一定の「当たり前品質」が守られる。ただ一方で承認プロセスが多くなるため、膨大な時間を要している一面もありました。
その後、もっとスピードを追求して良いものを作っていこうというマインドの「爆速体制」と呼ばれる時代になります。「爆速」の名のもと、UIガイドラインやQA、そのほかさまざまな規制を緩和したり、撤廃したりしました。同時に各サービスや部門に品質管理の役目も権限委譲され、そのおかげで良い機能やサービスをスピーディーかつたくさんリリースすることもできました。しかし、事故が増えたり、品質が高いとは言えないものも一部存在したりと、まさに一長一短の状況でした。
そこで「やはりこれではいけない。かつての品質管理のような仕組みを考えてほしい」というミッションが私のもとにおりてきて、そこからいろいろな仕組みをつくりました。
編集部 町田さんが整えてきた仕組みは、具体的にどのようなものですか？
町田 まず仕組みをつくるとき、かつてのQAはやりたくないと思いました。というのは、品質を考える組織がサービスの外に別にあるよりも、実際にサービスをつくる側が品質を考える必要があると感じていたので、中から品質について取り組むことができる体制にしたいと考えました。
編集部 たしかに、組織の外でチェックを行うことは開発側との温度差を生む可能性もありそうです。
町田 そこで、そのサービス以外のデザイン責任者が第三者としてチェックする仕組み「リリース前チェック」をつくりました。たとえばYahoo!ニュースで新しい機能をリリースする場合は、Yahoo!ニュース以外のYahoo!メールやヤフオク!などのデザイン責任者がチェックを行うという形です。そのやりかたとして採用しているのは「認知的ウォークスルー」という手法。実際にサービスを自由に使い、その中で発見されるエラーを指摘したり、アドバイスをしたりする仕組みです。
発見したエラーに対しては、そのエラーがユーザーに与える影響度を効率・効果・満足の観点からレベル分けを実施。影響度が「大」であればリリースすべきではない、影響度が「中」の場合はリリース後1ヵ月以内には直したほうが良い、といった客観的なチェック結果をサービス側にフィードバックします。
編集部 ほかのサービスのデザイン責任者、という点がカギなんですね。
町田 デザイン部長やそれに近い責任者は、エキスパートとしてデザインの経験を積んできた人たちです。そんなエキスパートからのフィードバックをもとに、どのように修正するのかをサービス内で検討し、対応方針を当該サービスの事業責任者がさらにチェックする。
これをサービス内だけで完結させると、「これは工数がかかるよね」、「技術的に難しそう」など内部の事情が入ってしまうケースもあると思うんです。だからこそ第三者目線であるべき姿を伝えてもらえることがポイントですね。
