大規模サービス開発で起こりがちな「やり直し」が激減した私たちの仕様確認フロー #Zaim
こんにちは！Zaim でサービス開発部のマネージャをしている高山と言います。サービスの新規立ち上げやリニューアルなど大規模な開発をしていると、仕様の解釈に齟齬があったがために手戻りが発生してしまって困ったということはありませんか？
私たちも相当苦労しており、ベストプラクティスを模索してきました。まだまだ改善すべき点はありますが、以下のような仕様確認（レビュー）フローにしてから「やり直し」が激減したので、そのやり方を紹介してみます。
仕様確認フローは大きく三段階
ディレクターやデザイナーが仕様案を作成してからリリースまでのフローは、ざっくりと三段階に分かれます。
① プロトタイプ α … 実装の方向性を定める
② プロトタイプ β … 開発を進められるようにする
③ RC … 製品品質を評価する
実装の方向性を決める「プロトタイプ α」
まずはディレクターを兼ねたデザインチームが、目的を達成するための画面イメージを Prott などのプロトタイピングツールで作成します。これをブランディング視点で確認する「ブランディングレビュー」と、現場目線で齟齬がないかチェックする「プロフェッショナルレビュー」にかけていきます。
ブランディングレビューでは社内で共通認識として共有している、メインペルソナである「マリ」が使えるかどうか、Zaim の世界観と合致した表現になっているかを確認します。これはブランディングチームが中心となり実施しますが、それ以外の全メンバーも参加できる環境になっています。
メインペルソナの「マリ」については、以下の記事に掲載しています。
一方、プロフェッショナルレビューは各職務の立場として不都合が発生していないかをチェックする工程です。例えば営業職のメンバーは「広告は正しく表示されそうか？」といったことや、エンジニア職のメンバーは「開発しづらい仕様にならないだろうか？」といった観点で意見を出していきます。
開発の仕様を決める「プロトタイプ β」
プロトタイプ α のフィードバックをもとに、プロトタイプをブラッシュアップしていきます。「この画面はこういう動作をしてこういう要素が必要」という内容をできるだけ揃えた状態を目指します。要素が出揃ったら、責任者レベルのメンバーでチェック。具体的にはデザイナーのリーダーやエンジニアマネージャ、プロダクトマネージャといった面々です。これを「責任者レビュー」と呼んでいます。
責任者レビューをパスしたら、スプレッドシートによるドキュメントを用意します。ここに画面上のアニメーションやスクロール範囲など、細かい仕様をできるだけ具体的に記載しておきます。これを、開発に関わる全エンジニアメンバーで読み合わせます。これを「開発チームレビュー」と呼んでいます。開発を進めるのに問題がないか、不足してる情報がないかを確認していきます。「もし後々の実装するタイミングで問題が見つかったら、しばき倒される！」という気持ちで真剣にレビューするのがポイントです（そんな怖い人は誰もいませんが…）。
開発チームレビューで意見が上がったら、責任者レビューで再調整し、実装に入ります。
開発フェーズ
開発がんばります。
製品品質を評価する「リリース候補版（RC）」
実装が完了したら、希望者は社員誰でも参加できる「最終レビュー」を実施します。レビューポイントは以下の通りです。
仕様どおり実装されており製品の品質は確保されているか
メインペルソナの「マリ」は使えるか
現場目線で不都合はないか
この際に、最も重視しているのは「各メンバーが、自分の専門領域に関わる機能の品質にコミットする」という点です。問題が見つかれば修正し、リリースとなります。これまでの工程でしっかりレビューをしていれば、この段階で大きな変更が必要になることはありません。
メンバーみんなにお願いしていること
それぞれのレビュー工程では以下のような項目を「厳守絶対！」とメンバーに周知しています。「やり直し」を減らすために特に大事なことです。
厳守（１） レビューのスケジュールを守る
各プロセスにおいて、レビュー依頼を受けるタイミングがあります。定められた期限を過ぎてから意見を言うと、その後の工程への影響が大きくなるので、期限は必ず守ります。
厳守（２）真剣にレビューする
各レビュー工程では「もうここで決まった内容は変更できないんだ」くらいの気持ちでレビューをするように心がけます。
後々になって「あ、このパターンがあったことを忘れてました」ということが見つかると、その仕様をあわせるための調整が発生します。後になればなるほど影響が大きくなるので、できる限り漏れがないようにすることが大切です。
厳守（３）個人の感想はなるべく控える
ブランディングの面でも UX の面でも、方向性の統一は非常に重要です。「私は分かりにくいと思う」というような意見は大事ですが、みんなで個人的な意見を言い始めると話しがまとまりません。「メインペルソナであるマリだったらどう思うか」ということを念頭に置いて意見を出します。
厳守（４）今回の変更に関係がない指摘は控える
自由に意見を言い始めると収まりがつかなくなるので、あまり関係がない部分についての意見は別の機会にまわします。ちなみに弊社では「要望共有ミーティング」という名の集まりがあり、ユーザさんや社内からの要望を集めて検討ています。
ちなみに…失敗談
以上のようなレビューフローになる前は、社内で仕様や開発後の画面をチェックする度に、大幅な修正が出てしまっていました。
特に Prott などで仕様を共有しても、その際にはさらっとしか確認されず、締切直前や実装の段階になって細かくチェックが入ったことにより「ここがこうならこっちはどうなってしまうでしょう」「やっぱりここは使いづらい」という意見が多く出ていました。Zaim は職種に限らず全員が企画に意見ができるフラットなチームですが、本来よりもタイムロスが発生してしまったことは、大きな問題になりました。
こうした原因を振り返ると、
メンバーが各々の主観で良い・悪いを判断して意見していた
開発が進んでから、確認したはずの前提を覆すような案が出た
仕様の曖昧さを残したまま開発に進んでしまった
という点に集約されると考え、上記のようなレビューフローを作成し、メンバーに周知してきました。このフローにて運用するようになってから、意見が発散してまとまらなくなる、ということは激減し、スケジュール遅延は抑えられるようになりました。
終わりに
いかがでしたでしょうか？ 少人数でやっていた時は、それぞれの専門分野の担当が良きに計らってガツガツ開発を進めていく体制で、開発フローとしてはスピーディでした。しかし、人数が増えてきたこと、そしてそれに伴い職務などに応じ各メンバーが重視する視点が異なってきたことなどにより、これまでのやり方は通用しなくなりました。試行錯誤の末にたどり着いたのが、このフローなのです。
メンバーや会社によって正解は異なるかと思いますが、社内のレビューフローを考えるきっかけになるなど参考になれば幸いです。
一緒にサービス作りをしたい！そんなあなたとチーム開発について気軽にお話できればと思います。
この記事が気に入ったらサポートをしてみませんか？