開発チーム内外からの指摘により、作り手がいわゆる「作業の手戻り」を余儀なくされるケースは多い。場合によっては、それまでやってきたことが無になり、イチからプロダクトを作り直さなければならないこともあるだろう。それでは開発チーム全体にストレスがかかってしまうことは明白だ。

GMOペパボで、いくつもの開発チームを担当してきたエンジニア、井上拓哉氏もそんな「手戻り問題」に悩む開発者の一人だった。

同社では、プロダクトオーナーが解決したい問題を決めたのちに、デザイナーがUIを考え、エンジニアが実装するという一般的な開発フローを踏んでいた。しかしその後社内リリースをしてみると、指摘が多く、スムーズな正式リリースをすることができない。そこで井上氏は、オンラインショップ構築ASPサービス『カラーミーショップ』のカート画面リニューアルプロジェクトにて、開発フローを見直し、手戻り問題を改善することを試みた。

施策の内容は、9月8日に同社で行われた『第6回ペパボテックカンファレンス～もっとおもしろくできる、そして……伝説の夜～』内で、井上氏が講演した「開発フローの中のレビューポイント」にて紹介された。

GMOペパボ株式会社 EC事業部 カラーミーショップグループ エンジニア
井上 拓哉氏

大学を卒業後、刑務所、ヘッジファンド、大学などの勤務を経て、2011年にpaperboy&co.(現・GMOペパボ)へ転職。 オンラインショップ構築ASPサービスであるカラーミーショップの開発に従事。RailsとAngularJSでの開発を得意とし、現在ではカラーミーショップの「新しいショッピングカート」の開発を担当している

社内リリース時の「いまさら問題」を解決するレビューポイント

リリースできる段階までサービスを構築し、社内で披露すると、自分たちが予期していないフィードバックが返ってくることがある。GMOペパボ内でも、「なぜこのような仕様にしたのか？」、「こういった考え方もできるのではないだろうか？」という開発チーム外からの指摘があるたびに開発の手戻りが発生していたという。

そこで、井上氏が新プロジェクトをスタートする際に実践したのは、開発フローの中に、いくつかのレビューポイントを設定するという施策だった。

プロダクトを作り始める時、デザイン・UIを決める時、システムの仕様を定める時、それぞれ納期から逆算してあいまいに進めていた各フローを改め、適切なレビューを行う。その時に定めた、開発フロー改善のポイントは以下2点である。

こういったレビューポイントの設定は、トヨタ自動車で行われている「主査制度」という手法をヒントに考えられた。トヨタの「主査」とは、担当する車に関することすべてに責任を持つポジション。売れる車を開発するために、「必ず守らなければいけない点」を最初に設定し、それを守りながらプロジェクトを進めていく。課題解決の判断軸が明確になるため、後々になって問題が発生することが少ないのだ。

まず同プロジェクトでは、「プロトタイプを作成し、それを試した○人のうち、○人が～～～という状態になること」という定量的な目標を各フェーズごとに設定した。

「それまでは、デザイナーが考えたUIに対して、『専門家であるデザイナーが作ったわけだし、何だか良さそうなデザインだからこれでいこう』という雰囲気がありました。そのため、専門外であるメンバーが大きくデザインを変更することもなかったですし、デザイナーのセンスが絶対という空気のまま、UIが決定されてしまうことが多かったんです」

そう井上氏が語るように、各フェーズ担当者に対して、周りは指摘しづらい空気が漂ってしまうケースは多いのではないだろうか。しかし、最初に定めたレビューポイントをもとに、ユーザーがどんな状態になることを目指しているのか、が明確になっていれば、「この基準が満たせるデザインなのか？」という判断軸が生まれる。

こうしてポイントごとにレビューを明確にすることで、専門外の人でも良し悪しを判断でき、目的通りのプロダクト開発が可能になるのだ。

加えて、「何を目指すか」を定めるこのタイミングで、「何を目指さないか」を決めることも重要なのだそう。

「何を目指さないか、という基準は開発後半になって活きてきます。発生する問題に対して、取捨選択する判断軸にすることができるので。開発スケジュールの後半になると、タスクを落としてリリース日を優先するのか、その逆かを選択することが多い。その判断がしやすい軸を作っておくことで、より効果的にプロダクト開発を進めていけるのだと思います」

また、ポイント【1】の各条件を設定する際、開発チームがレビューするのではなく「ユーザーまたはそれに近い者が実際に触って、レビューをする」ことを意識したという。

実際に、UIやシステムの仕様を決定するフェーズでのレビューでは、同社のカスタマーサポートのメンバーがプロトタイプを操作して、テストをした。カスタマーサポートのメンバーであれば、一番ユーザーと近い距離にいるので、ユーザーの考えが分かっているということ、また仕様を知らないまっさらな状態で触ってもらうことができる、という点から選ばれた。

彼らが実際に操作している画面をモニタで映し出し、リアクションを見たり使用感をヒアリングする。すると、開発チームが予想した以上に、ユーザーが意図通りには操作してくれないことに気付いた。

「開発チーム内では分かりやすい仕様を作っていたはずだったんです。なのに、実際に利用してもらうと全然思ったとおりに動いてくれない。画面の中に説明が書いているのに、それすら見てくれずに勝手に動いてしまうこともあって驚きました」

しかし、この驚きが多くの気付きを生む結果となった。プロダクトの仕様を知り尽くしている開発メンバーだからこそ見落としてしまう、欠陥やUIの悪さを発見することができたのだ。

レビューポイントを設定した当初は、2回程度のレビュー会を想定していたものの、このような多くの気付きが発見されたことで、結局全てのポイントをクリアすることができたのは4回目のレビュー会だった。

質は必ず向上する。大切なのは「時間が掛かる」ことに対するコンセンサスを得ておくこと

各フェーズにこのようなレビューポイントを設けた結果、リリースするプロダクトの品質は確実に向上したいう。

「正直、時間も手間も掛かりましたよ。だけど、条件をクリアするのに4回掛かった、ということは今までリリース前にそれらを避けて通っていたということ。プロトタイプを作り直すごとにどんどん品質や操作する人のリアクションが変わっていきます。最初に作ったものと4回目のプロトタイプはもはや別物になっていました。なので、掛けた分の時間は十分ペイできているのではないかと感じています」

チーム外を巻き込んだレビュー会を導入すると、とにかく時間や人員調整などの手間は発生する。だからこそ、時間が掛かることは承知の上で、それを見越してスケジュールを組んだり、先回りすることも重要であると井上氏は振り返った。

「レビューポイントの設定をする際は、何よりも『こういうことをやっているので、開発には時間が掛かります』ということを予め上長や、チーム内外にコンセンサスを取っておくことは大事ですね。そうしないと、『あのプロジェクト、まだUIも決まらないの!? 』と、白い目で見られ始めますから（笑）」

全てを作ってから、手戻りが発生したのでは無駄が多い。プロトタイプを作ったのち、適切なポイントで目的に沿ったチェックを行う。そういった最適なPDCAサイクルこそが、開発チームの手戻り防止においては必要なのだろう。

※『第6回ペパボテックカンファレンス』で講演された他のテーマは以下動画にて。

取材・撮影・文／大室倫子（編集部）