こんにちはヤフオク!アプリ開発ワーキンググループ長の西です。

インターネット業界の変化の速さは皆さんもご存じの通りです。
毎年メジャーバージョンアップするiOS,Android、より洗練されたユーザー体験を実現するためのUIの構築手法、PlatformerたるApple、Googleの規約変更による対応、新登場するSwift言語、先日のGoogle Mobileセミナーで発表された新技術の数々とそれを受けて進化するサードパーティ製ライブラリ、競合サービスの登場によるユーザー体験の再試行、watchOS2やtvOSなどのiOS技術をベースにした新デバイスの登場などなど、1年に起きる変化の量は相当なものになってきました。

成長の早い犬にとっての1年が人間の7年に匹敵することをいわゆるドッグイヤーと呼び、インターネット技術の進化の速さをドッグイヤーで例えられることが多いのですが、ことスマートフォンのアプリ技術に限ってはドッグイヤーよりも更に早い速度で進化が進んでいます。人間の寿命の1/18であるマウスに例えられたマウスイヤーという言葉もありますが、スマートフォンのアプリ領域の進化の速さはまさにマウスイヤーと言ってもおかしくないでしょう。

今日はそんなマウスイヤーの時代でも活躍するヤフオク!のアプリ開発プロセスのお話をしようと思います。

また、ヤフオク!アプリチームからは、以前に「ヤフオク!アプリでの自動テストの事例紹介」という資料を公開させて頂いています。
よろしければこちらも御覧ください。

ヤフオク!アプリの開発プロセス

その前にヤフオク!について

ヤフオク!1999年に始まったサービスです。2015現在、常時出品数は3,800万点を超えており日本最大級のオークションサービスとなっています。サービスの出面としてはPC、スマホWeb、アプリがあります。このサービスを支える人員は運用・企画・制作・カスタマーセンター・開発含めて約300名となっており、ヤフーの1サービスでありながら一つの会社のような規模となっています。

※常時出品数の他、1秒あたりの落札数などの詳しい数字はこちらで確認できます
数字で見るヤフオク!

機能をリリースするまでの流れ

以下のような流れになります

各フェーズの概要を説明します。

• 課題発見フェーズ
  ユーザーインタビューやアプリレビューなどからユーザーの課題を見つけ出すフェーズ

• 考えるPJフェーズ
  発見した課題を解決する方法を考えるフェーズ

• ものづくりPJフェーズ
  考えるPJが考えた案を元にものづくりを行い、リリースするのに十分な品質を持つプロダクトを開発フェーズです。開発後のプロダクトはこのPJが責任を持ってリリースします。

• PDCAフェーズ
  リリース後、考えるPJフェーズで検討していた目標数値（KPI）に達するまでPDCAサイクルを回す

• 解散
  目標数値（KPI）に達することができたら解散。基本は達成できるまで解散不可（作戦変更による途中解散はあり）

各フェーズの詳細

課題発見フェーズ

ヤフオク!サービスについての課題を発見するフェーズです。概ね以下のようなところから課題を集めています。

• ご意見フォーム、アプリのレビュー、アンケートから意見を抽出
• ユーザーインタビュー
• 数値分析
• 社内からのフィードバック
• 普段自分がヤフオク!を利用していて不便だと思うこと

考えるPJフェーズ

新しい機能や改善策を検討するにあたり、１〜２名のチームを組織します。これを「考えるPJ」と呼んでいます。
考えるPJのメンバーは企画、開発、制作のどの職種でもありえます。「この施策でヤフオク!を良くしたい、ユーザーの課題を解決したい」という熱力や案がある人がメンバーに参画することが多いです。

「考えるPJ」が主に考えることは以下です。

• Why「ユーザーの○○○という課題を解決したい」
• How「△△△という手段を利用して」
• What「結果、☓☓という機能を作ります」

最後に、このWhatにあたる機能をリリースした場合に期待される効果を定量的に判断するため数値（KPI）を決定します。多くは取扱高や毎日の訪問者数をKPIとして設定することになります。その後考えるPJを解散しものづくりPJフェーズへと移行しています。
なお、この時点で効果が薄いと判断されたものは、ものづくりPJフェーズへは進まず、より効果的なアクションが無いか再検討を行います。 もしくは、この時点でやらないことを選択します。

効果が大きいアクションに厳選して実行することと、その効果を定量的に判断するために数値に落としこむことが重要です。

ものづくりPJフェーズ

新しい機能や改善策を実装するにあたり、２〜８名のチームを組織します。これを「ものづくりPJ」と呼んでいます。

一つのチームは企画、開発、制作の職種ミックスの人員で構成されています。いわゆるプロジェクトマネージャーにあたる存在は「考えるPJ」のメンバーだった人がなる場合が多いです。基本的にPJ内でも熱力が高く情熱をもってゴールまで導くことができる人がプロジェクトマネージャーになります。

作ったプロダクトをリリースした後はユーザーフィードバック対応や目標数値（KPI）を達成するためのアクションを継続して行います。

目標数値達成後、ものづくりPJは解散します。

PJ発足時に気をつけていること

全員でセットアップ

「考えるPJ」で新規に行う施策の概要については決定してるため、「ものづくりPJ」を発足する時点では作るものは一旦決まっています。
ですが、作るのに必要な手段・及びスキルセット（How）を持つ人員を集めて、さぁ「ものづくりPJ」スタートだ!とはなりません。
「ものづくりPJ」内の全員で「なぜその機能が必要なのか？」を共有します。

作るものが決まっているのでそのゴールに向かって走りだせばいいのですが、「なぜその機能が必要なのか？」ということを全員で改めて共有するのです。
その際に共有する情報はもちろん「考えるPJ」時代に考えた以下の３つです。

• Why「ユーザーの○○○という課題を解決したい」
• How「△△△という手段を利用して」
• What「結果、☓☓という機能を作ります」

このWhatの「結果、☓☓という機能を作ります」というところだけ「ものづくりPJ」メンバーに共有して開発をスタートしてしまった場合、機能を作ることだけが目的となり、最終的に出来上がったものが実はユーザーの課題を解決していなかった、ということが起きえてしまいます。

Whyである「ユーザーの○○○という課題を解決したい」という情報を事前に共有しておくことで、Whatである「結果、☓☓という機能を作ります」の機能の完成度がかなり変わってくるのです。
開発者の意識が常にWhyを解決できるかどうかを意識することで、開発中のプロダクトがユーザーの課題が解決できるプロダクトになっていないことにいち早く気づくことができます。こういう過程を経て「ものづくりPJ」内にアラートを発信することでプロダクト完成前からいち早くプロダクトの起動修正を行うことができるのです。こうやって作られたプロダクトは、Whatだけを伝えて作った場合よりも完成度が高いものになります。

さらには、仕様書等で決められていなかった動作や使い勝手、アニメーションが発覚した場合、仕様を作成した本人が不在の場合においても「ものづくりPJ」メンバーそれぞれが対処方法の検討に着手できます。これによりプロダクトの改善や作り込みに回せる時間を増やすことができます。

こうした、Whyの「ユーザーの○○○という課題を解決したい」を共有することは、サービスにとって不幸な「作ったはいいがユーザーの課題を解決することができなかった無駄な機能」を減らし、ユーザーの課題を解決する素晴らしい機能を量産するための打率をあげる重要なアクションです。

なお、最初に、Why「ユーザーの○○○という課題を解決したい」を共有した結果、
Howの「△△△という手段を利用して」というところが手段として適していないことが分かれば、Howを再考するところへ戻るようにします。手段を目的にしたアクションにならないように促しています。

できるだけスモールチームにする

ここまで述べて来たメリットを享受するためには10名、20名いるような大規模チームよりも、5〜6名のスモールチームの方が有利であると考えています。スモールチームのメリットはいくつもあるのですが、特に良いと考えているところは以下のところです。

• 話し合いの機会が増える
• オーナーシップ精神の発生

これら二つは相関して良い影響を与えます。

まず、スモールチームにすることで話し合うべき人数が少なくなります。結果、同じ相手と繰り返し話す回数が増えます。こうやって話し合いの回数が増えることで、実装する機能のより良い提供方法について話し合う機会も増えていきます。

さらに、そうやって何度も繰り返し話し合った機能を作りこんでいくと、その機能に対するオーナーシップ精神が生まれてきます。
「自分たちがこの機能をもっと良くしよう」という精神です。

この精神を持ったチームは強く、誰に言われるでもなく改善提案を出してくるなど自律的にアクションすることが増えてきます。スモールチームという体制はこういった自走集団が生まれやすいのも特徴です

マネジメント手法に固執しない

リリースまでの開発物のマネジメント手法はどういったものを採用すればよいでしょうか？
案件について非常に大きな括りで分けると以下の2種類に分かれます。

• 社内でのみ完遂する改善案件であり実装機能・リリース日の制約が少ない案件（通常はこちら）
• 契約等で実装機能・リリース日に制約がある案件（どちらかというと仕様を変更する余地が少ない）

開発プロセスを管理する手法はウォーターフォール、スクラム等ありますが案件の特性に合わせて選択しています。また、PJに属する人の特性も考慮します。

ウォーターフォールを押し付けたり、スクラムを押し付けたりすることはありません。ここで大事なのはその案件が成功するために最も適した開発プロセスを自分たちで選択していくことです。

現在の傾向としてスクラムを採用することが多いのですが、仕様に変更の余地がない場合にウォーターフォールを採用することもあります。

職種ミックスの人員構成にする

ウォーターフォールであってもスクラムであってもスモールチームで且つ企画、制作、開発の職種ミックスであることは変わりません。話し合う機会を増やすためのメリットは最大限享受しようとしています。

さまざまなPJのプロダクトのマージのために

お互いのプロダクトを見る機会を増やす

各PJで開発する体制をとっているためさまざまな機能の並行開発はできるのですが、それぞれがスモールチームであるが故にプロジェクト内で閉じた会話になりがちです。
結果隣のプロジェクトが作っている機能との整合性や、アプリ全体で見た時の統一感というものが失われてしまうこともあります。

そういった事態をできるだけ、しかもなるべく早く防ぐためにスプリントレビューはできるだけ同じ日になるようにしています。
（スプリントレビューを初めて聞いたという方は、開発途中での定期的なフィードバックのための時間と思ってください）

このようにお互いのPJで作っているものについてレビューしあえる状況を意図的に作っています。またウォーターフォールを採用した、いわゆるスプリントレビューがないプロセスを採用しているチームについても、リリース前にスプリントレビュー会に参加してもらいます。

ただし、復数のPJのスプリントレビューが同一日になると、一つ一つのPJに割くことができるレビュー時間が短くなってしまったり、お互いのPJのやっている内容が理解できず、スプリントレビューのフィードバックが少なくなってしまうことがあります。この問題を解消する工夫はまた別の機会にお話しようと思います。

レビュー内容

スクラム型PJのアウトプットのレビュー内容

スクラム型の組織のアウトプットは毎週のスプリントレビューのタイミングでレビューされます。
ヤフオク!カンパニーでは毎週金曜日がスプリントレビューの日となっており、スクラム型PJの場合は毎週開発途中のもののフィードバックを受けることで完成度を高めながら開発を進めています。

ウォーターフォール型PJのアウトプットのレビュー内容

ウォーターフォール型の組織のアウトアウトプットは２つのタイミングでレビューされます。

デザイン決定時

Prottなどのモックアップツールを利用してiPhoneでどのようなプロダクトに仕上がる予定かどうかレビューします。レビュー結果はPJへフィードバックされデザインの改善を行うことになります。

プロダクト完成時

出来上がったプロダクトをiPhoneやAndroid端末に実際にインストールしてアプリの実際の挙動をレビューします。ここでのレビューは、いわゆる結合テストのことではなくて、アプリ全体の整合性がとれているかなどの使用感の確認です。
レビューの結果出たフィードバックは、デザインチェックの時と同じように開発したPJへフィードバックされます。

レビュー結果を受けて

PJが主となり課題を解決していく

スプリントレビューで出た内容のフィードバックや指摘をそのまま対応する、ということはありません。人に言われたことをそのままやるのではなく、あくまで自分たちでどうするのか考えてアクションしていくためのPJ制となっています。
「自分たちがこの機能をもっと良くしよう」という各PJのオーナーシップ精神がより強い組織を作っていきます。

全体の概要

今まで説明した全体の概要については以下の通りとなっています。
図に出てくるアプリWG（ワーキング・グループ）というのはヤフオク!カンパニー内でも特にアプリについて詳しい部隊で、さまざまなPJへアプリ開発についてのノウハウを伝えたり、新しい技術のキャッチアップ等を行っています。

ドッグフーディング

開発が完了すると実際に自分達でアプリを利用し「考えるPJ」時代に考えたWhyを本当に解決できているのか今一度確認します。このプロセスを超えると実際にユーザーの元へリリースされます。
自分たちでアプリを触るとの同時に、社内にも配布します。いわゆる「ドッグフーディング」です。自分たちが作っているサービスを開発者自身や、同じ会社の社員たちで使い倒します。
ドッグフーディングは素晴らしい取り組みではあるのです。
ただ、社内の社員がドッグフーディングをした結果、そのフィードバック結果が開発者に届くまでにはさまざまな壁があります。

フィードバックする側の立場

社内に配布したアプリのフィードバックが届かない時、一体どういうことがおきているのでしょうか？

• フィードバックをしようと思って開発者の席に行ったら離席していた。その後フィードバックするのを忘れた。
• フィードバックをアンケートフォームに入れなければならず、入力画面をみて面倒になった。結果フィードバックするのを辞めた。
• アプリのスクショもセットで渡さないと伝わりそうにないフィードバック内容だったので、スクショの添付が面倒で結果フィードバックを辞めた。
• どんな言葉でフィードバックすればいいのか考えるのが面倒になった。結果フィードバックを辞めた。
• 使っている最中にクラッシュしたけどどうやってその画面にたどり着いたのか思い出せない。結果フィードバックをするのが億劫になってきた。

どうでしょうか?とても些細なことのように見えますが、人間は面倒くさがりなのです。そして、ドッグフーディングには実は結構な労力が発生しているのです。そしてフィードバックが少ないアプリというのは文句を言われるよりも切ないものです。

以下のような改善アプローチをとっています。

ボタン一つでフィードバック機能

App Storeに公開するアプリとは異なり、社内に配布するアプリには特別な機能を備えさせています。開発者へのフィードバック機能です。
このフィードバック用のボタンをタップすると以下の情報を社内のMYMというチャットシステムに一発で投稿します。

送られる情報は以下の通りです。

• 投稿するフィードバックの分類
• 任意のフリーコメント
• 報告者名
• その画面のスクリーンショット
• その画面のクラス名
• その画面に至るまでの詳細な操作ログ（個人情報はマスク済み）

これらの情報がフィードバックの分類を選択して送信するだけで一発で送ることができます。これだとフィードバックする側も気軽にできますね。先ほど挙げたさまざまな面倒くささを乗り越えられそうです。

実際にこの機能を利用することで社内にアンケートフォームを作ってアプリを配布するよりも100倍近いフィードバックを得ることができました。（通常だと1日に10件程度のフィードバックが1日1000件になったことも。ありがたいことです）

フィードバックを受ける側としても、詳細な操作ログを送信してもらっているために再現方法のヒアリングなど の手間も減り、開発者の作業も捗ります。

そして開発者が捗った結果、より多くのアプリ改善作業を行うことができます。

このようにフィードバックを求める側も、フィードバックをする側の立場に立った工夫をすることが大切です。

まとめると

ヤフオク!アプリの爆速開発を実現してるのは
「施策ごとにウォーターフォール、スクラムを最適に選択し、同時に進めることができるプロセスを構築している」
ことです。

最後に

実際のところ現在の開発手法が最高！とは思ってはおらず、より良い開発の進め方を求めて日々検討と実践を繰り返している毎日です。
今日は開発プロセスに焦点を当てた話をさせて頂きましたが次回はシステムの話ができたらと思います。

またヤフーでは一緒に働く仲間を募集しています！新卒・中途問わず気軽にご応募ください！
https://about.yahoo.co.jp/hr/job-info

イラストはこちらのサイトの素材を利用させて頂きました。感謝。
http://www.irasutoya.com/p/terms.html