レビューが加速させるチーム開発(2) 「UIレビュー」で「何を作るのか」を具体化する

どう実現するかを「レビュー」しよう

「社内向けプレスリリース」により「なぜ作るのか (Why)」という点を明らかにしたら、次はそれを実現するために「何を作るのか（What）」を明確にしていくステップになる。

作るものには様々な形態があるが、今回はWebサービスやモバイルアプリなど誰かしらの利用者（ユーザー）が存在するものを対象として、どのようなレビューがこのステップで必要なのかを紹介する。

目的を実現に導く、チームの視点での繰り返しプロセス

新機能や機能改善などの開発において、それを利用するユーザーが「どんな画面を見て」「何をするのか」といったUI（ユーザインタフェース）の設計が非常に重要なポイントになる。UIを定義するドキュメントとして「画面設計書」や「ワイヤーフレーム」などがあり、おそらく多くの方が、そういったドキュメントを作成したり、チームやプロジェクトのメンバーと確認したりといった経験はお持ちだろう。

筆者は、この「UIレビュー」を実際に開発を進める前や初期の段階での重要なプロセスと位置づけている。

ワイヤーフレームを共有し、チーム全員でじっくりとレビューすることが重要

UIレビューは、何度もチームレビューと図の修正を繰り返し、多くのチームメンバーが参加して進められる。特に、以下に挙げられる点をレビューの重要ポイントとしている。

ユーザーが容易に機能の内容を理解でき、目的に導くことのできる画面か？
機能を実現するのに必要なボタンやリンクなどの要素は不足していないか？
ユーザーが遭遇しうる、すべてのケースを想定できているか？
目的に沿った仕様を正しく理解できているか？

これらのポイントは、前回紹介した「社内向けプレスリリース」で明確にした「目的」を実現させるうえで、必要不可欠なものである。さらに、チームメンバーそれぞれが持つ「知識」「理解」「アイディア（発想）」を活かすため、なるべく多くのチームメンバーが参加し、多角的な「視点」を持ち寄りレビューを行うことで、最終的な機能の品質や完成度を高めることも目的としている。

レビューと修正を繰り返すことを前提としており、作成するワイヤーフレームは最初から作りこみすぎないように留意

なお、時間を要するUIレビューのポイントは、繰り返しプロセスをなるべく迅速に、省力化して進められるように工夫することだ。またレビューという観点においては、ワイヤーフレーム単体としての完成度よりも、上記の4つのポイントを満たしているかどうかを重視したい。なお、ワイヤーフレームを完成させた後の画面のグラフィックスデザインにおいても同様のレビューを行い、同様のポイントが満たされているかを確認しつつ開発に組み込むようにもしている。

次回は「どう作るのか (How)」をテーマに、開発工程におけるレビューについて紹介する。