第5章　ビジネス視点の改善～効果検証に基づく機能改善と、チームでの仕事の進め方

サービス成長のために

はじめまして、paperboy&co.（以下、ペパボ）でショッピングモール「カラメル」の事業部長をしている安宅（あたか）です。

本章ではビジネス面から見たサービス改善のための効果検証方法と、チームを作る際に意識していること、そしてプロジェクトの進め方について、実際にカラメルであった事例とともに解説していきます。

カラメル

カラメルは、2006年4月にリリースされたオンラインショッピングモールのサービスです。ペパボが運営しているネットショップ作成ASPサービス「カラーミーショップ」を利用したショップを含め、執筆時現在（2013年5月）約2万のショップが出店し、180万人を超えるユーザが利用し、チームのメンバーも増えてきています。

筆者は2007年4月にカラメルのディレクターとして入社し、2009年12月よりマネージャとしてサービスに関わっています。

サービス継続に収益は不可欠

企業でサービスを運営するためには、ユーザに価値を提供し、その価値の対価としてお金を継続的に支払ってもらうことで売り上げを作ることが前提となります。サービス運営には、関わるスタッフの人件費、サーバ代金、広告費といったコストを継続的に支払う必要があるため、「⁠売り上げ－コスト」の差額となる「利益」を生み続ける目星がないと、サービスを継続して運営することはできません。

筆者はカラメルの運営に関わりながら新規サービスの立ち上げに関わったことがありますが、うまく成長させることができずに、開始から1年でサービスが終了するといった経験もしています。チームの仲間と一生懸命サービスを作ったとしても、利用してくれるユーザがいなければ、企業はサービスは終了するという判断をします。

Web業界では次から次へと新しいサービスがリリースされて、ものすごい勢いで成長するサービスの影で、気づいたら終了しているサービスもたくさんあります。サービスを継続して運営していくためには、利益を生み続けるしくみを作ることが重要です。

サービス成長のKPI分解

サービスを運営するには、まず売り上げ・利益の業績目標を立て、目標を達成するための戦略を考え、具体的な施策の計画を作り、施策の効果を定量的に計測するための指標を決める必要があります。業績目標を達成するための重要な指標のことを、KPI（Key Performance Indicator、重要業績評価指標）と言います。

「カラメル」であれば、商品の流通額や出店数がKPIになります。ペパボで売り上げ・利益の柱となっているレンタルサーバ「ロリポップ！」や、先述したカラーミーショップなどのストック型のサービスであれば、毎日の新規会員の申し込み数や契約率、既存会員の継続率などがKPIです。KPIを達成するために、申し込み数をアップさせるキャンペーンを実施したり、継続率をアップさせる機能追加を通じて既存ユーザの満足度を高める施策を行います。

KPIは、図1のように細かく因数分解できます。

施策の優先順位

サービスに関係するKPIを分解・計測し、伸びしろがありそうなKPIを見極めて高める施策を考えます。ただ、流通額を上げる施策一つとっても、ユニークユーザ数を上げる施策を優先させるのか、コンバージョン率[1]を上げる施策を優先させるのかで、サービスの成長速度が変わってきます。

そこで効果的にサービスを成長させるために、期待できそうな効果と実現にかかる工数のバランスをとり、施策の優先順位を決めていきます。たとえば1ヵ月の訪問者数が1万人で、1訪問あたりのコンバージョン率が10％、毎月の販売件数が1,000件のECサイトがあり、次の2つの施策案があったとします。

a．訪問者数を2倍（2万人）にアップできそうな1ヵ月間限定のキャンペーン
b．コンバージョン率を12％にアップできそうな機能開発

また、このときa、bともに、10人日の開発工数がかかるとします。

a案の1ヵ月の販売件数は、2 万人の10％なので2,000件（＋1,000件）です。それに対してb案の1ヵ月の販売件数は、1万人の12％なので1,200件（＋200件）です。つまり短期的に見るとa案のほうが効果がありますが、a案は1ヵ月しか販売件数がアップしません。長期的（6ヵ月以上）に見るとb案のほうが累計の合計販売件数が上回り、そのあとも高い販売件数を維持します。

短期的に実現可能な売り上げが求められているのか、長期的にストック可能な売り上げが求められているのか、状況により選択する施策が変わってきます。

サービスを運営している実際の現場では、この施策を進めれば必ず何％KPIがアップするというはっきりとした根拠があることはまれで、期待値で優先順位を決めていることも多々あります。でも施策の効果を早めに検証することができれば、成功する確率を高めることも可能になります。次節では成功の確率を高めるための効果検証について説明します。

効果検証と機能改善

効果検証の重要性

Webサービスの運営に関わっている人であれば、「⁠この新機能は絶対にユーザに使われるはず！」と気合を入れてリリースしたけど、全然使われずに残念な思いを味わったことが何度かあるのではないでしょうか。すべての施策が絶対にうまくいくという保証はどこにもありません。リリースしてみないと、ユーザの需要があるのかどうかわからない場合も多々あります。

そのために、ユーザに価値を提供できる最小の形のものをなるべく短いスパンで開発してリリースしてみて、需要があるかどうか、期待していた効果が得られるかどうかを効果検証しながらサービス改善を進めていくことが重要です。

開発最低限の形で効果検証

ペパボでは、より多くの人に低価格でサービスを提供するために、できる限り効率良いサービス運営が可能になるよう、ユーザが利用する機能や運営側が使う機能をしくみ化し、運用にかかるコストが最低限になるよう心がけています。しかし、すべてを最初からしくみ化する必要はないと考えています。

ここでは、先日カラメルで新しい広告メニューを提供した事例を紹介します。

通常のサービス運営のしくみ

通常カラメルでショップ向けに有料の広告メニュー機能を追加する場合は、次の運用をしくみ化し、広告の申し込みから掲載、入金までに、サービス運用側のコストがかからないようにしています。

① ネットショップ作成ASPサービス「カラーミーショップ」の管理画面内で、機能の案内ページを用意する
② 広告出稿に必要な情報はユーザが申し込む際にデータベースに記録し、ショッピングモールやネットショップに自動で反映させる
③ 料金の支払いは、ユーザが管理画面内でポイントを購入して行う
④ サービス運営側の入金確認は、運営側の顧客管理画面で行う

開発最低限のβ版メニューの提供

先日リリースした広告メニューは、最初に提供した時点では上記のようなしくみ化はせず、次のような一部人力の対応を行い、ディレクター、デザイナ、エンジニア合計5人日程度で広告メニューを提供しました。

① 広告メニューの案内ページはショップ向けのブログ記事に記載し、ショップ向けのメルマガで露出を増やし、メールで広告のお申し込みを受け付ける
② 広告出稿に必要な情報（商品画像、商品名、URL）をショップさんからメールで連絡をもらい、ディレクターがExcelで情報を管理する
③ デザイナが静的に商品情報をコーディングし、エンジニアが表示させる情報を条件分岐させるプログラムを実装する
④ 広告料金の入金連絡・確認は、ディレクターがすべてメールで行う

伸びしろがあるメニューをしくみ化

上記のような開発を最小にしたβ版広告メニューを2ヵ月で4つ提供したところ、その中に、申し込みの需要があり、かつユーザに価値を提供できそうなものが2つあることを確認できました。

そこから初めてしくみ化させる開発に着手しリリースしたところ、β版提供時と同等の反応を得ることができました。またβ版提供時に運営側とユーザの手間になっていた部分もしくみ化を行い、無駄な運営コストがかからない形になりました。

新しい機能追加の場合はこのようにはいかず、時間をかけて開発をしないと新しい価値そのものをユーザに提供できない場合も多々あります。しかしそのようなケースでも、すべてをしくみ化させなくても効果検証できることがあるでしょう。

時間をかけて開発したけど、まったく利用されないということを回避するためにも、極力時間をかけずに効果検証できる方法を考えることが重要です。

要件を削って工数を少なくする

筆者のチームでは、新しい機能やオプションメニューの開発に着手する前に、要件を固めるディレクター・マネージャと、要件を形にするエンジニアの双方が、工数を最小に削る提案をします。前項で紹介した広告メニューをしくみ化させる開発の場合は、まずはじめに「できる限り要件を削り、必要最低限の機能を最速でリリースする」という方針を決めました。広告として掲載できる情報を絞る、広告掲載のタイミングをリアルタイムではなく1日1回のバッチ処理で実装する、ディレクターにとって便利な広告利用状況確認のための管理画面の機能も削るなど、合計2.5人月程度まで予定工数を削ってから開発に着手しました。

関係者で議論し、より便利で効果がありそうな案をたくさん出すことも大切ですが、最小の形で実現できる方法を導き出すこともそれ以上に重要だと考えています。

リリース後の改善が重要

リーンスタートアップでは、ユーザやマーケットのフィードバックから市場のニーズを検証し、プロダクトのコンセプト、機能、価格などに反映させながらビジネスモデルを構築していくことが大切と言われています。

実際サービスを運営していると、運営側では思い浮かばない需要がユーザから得られる場合があります。カラメルの広告メニューの場合も、サービス提供後にショップさんから得た要望には、事前に想定していなかったものもありました。そのような要望をかなえていくこともサービスの成長に必要な要素です。

申し込み数が低いようであれば、まだリーチできていない層にアプローチできる機能を追加したり、案内ページの内容を変えたりすると違う反応が得られるかもしれません。

申し込みは獲得できているが継続率が低い場合には、利用中のユーザに、より費用対効果の高い価値を提供することで、継続率を上げられるかもしれません。費用対効果が高い価値を提供できているが継続されていないのであれば、費用対効果の高さをアピールし納得感を感じてもらえれば継続率が上がるかもしれません。

需要がなく、現状のままだと成長が見込めない場合には、別のメニューの提供を検討したほうがよいかもしません。

上記のような「たられば論」は結局リリースしてみないとどうなるのかわからないので、まずリリースしてみて、反応を見ながらサービスの方向性を軌道修正し改善していく方針でサービスを運営しています。

チームのコミュニケーション促進

チーム体制

ペパボでは、サービスごとにチーム制（事業部制）をとっています。現在のカラメルは、エンジニア5人、デザイナ3 人、ディレクター4 人、マネージャ（事業部長、筆者）1人の合計13人のメンバーで運営を行っています。

コミュニケーションの量を増やす

チームの人数が増えるにつれ問題になるのは、意識してコミュニケーションをとらないと意思疎通が難しくなることです。コミュニケーションをあまりとらずに機能開発を進めると、途中で要件とずれていることが発覚し開発の巻き戻しが発生したりすることもあります。

そのためカラメルでは、チーム内のコミュニケーションを促進させるため、次のような会議を実施しています。

朝会（毎日）
定例会議（週一）
キープアップ会議（週一）
プロジェクトの相談会議（必要に応じて）
ふりかえり会（プロジェクト終了後）

朝会

朝会は、毎日出勤時刻の10時から15分程度、チーム全員で挨拶をして、各自が今日やることを確認しています。何か大きめの機能追加を行う際は、チーム内でプロジェクトチームを組み、プロジェクトごとに進捗確認の会議を毎朝行い、プロジェクトの軌道修正を行っています。

朝会やプロジェクトごとの会議を実施するようになり、いつでも相談しやすい空気ができ、チーム内の意思疎通が円滑に行われるようになった結果、機能開発もスムーズに進められるようになりました。

定例会議

定例会議は週1回30分～1時間程度、チームの全員が参加して行います。

定例会議の目的は3つあります。

サービスの業績、KPIをチームのメンバー全員に把握してもらうこと
今サービスに必要なことを、チーム全員で面と向かって議論する場を作ることで、普段から相談しやすい環境を作ること
今進めている施策に関して、マネージャ、施策責任者の想いを直接伝え、時に議論をし、サービスの目指す方向性がぶれないようにチームで一致団結すること

キープアップ会議

キープアップ会議は週1回30分程度、マネージャ、ディレクター、経営陣が参加して行います。それぞれのサービスの状況を社長が把握するため、サービスの業績、KPIを報告します。重要な事項に関して意思決定をするための場でもあります。

プロジェクトの相談会議

プロジェクトの相談会議は、施策を進める中で相談が必要な場合に、都度会議の時間をとり関係者で集まって行います。

プロジェクトの相談会議をする際には、10ヵ条の会議のルールを作って守ることで、無駄な時間を極力作らないようにしています。

アジェンダ大事: 会議実施の1時間以上前に、アジェンダを用意しよう
会議の目的明確化: アジェンダでは、会議名、会議の目的、参加者、日時、場所を参加者に共有しよう
参加者も要準備: 参加者はアジェンダを確認したうえで会議に参加しよう
遅刻NG: 定刻時間に会議室に集合しよう。部屋が空いていない場合は会議室前に待機
会議のゴール: 会議開始前にアジェンダを再確認し、会議のゴールを決めよう
即議事録: 会議をしたら①ToDo、②期限、③次回開催日を決めて議事録に記載し、即日共有。議事録は鮮度が重要、文章の質にはこだわるな
結論ファースト: できる限り結論ファーストで意見を言えるようになろう（結論から先に意見を述べることは、社会人として持っておいたほうがよいマナーなので、皆で訓練する）
アイデアは質より量: アイデア出し会議の場合、質より量を出すことが大事。人のアイデアは否定しない
判断基準を認識せよ: 意思決定する会議の場合、判断基準を明確にしよう。何の重要度、優先度が高いのかを参加者に共有しないと、基準がぶれた決定になる
不要な会議は捨てる: その会議は果たして必要なのか？必要がない会議はコストの無駄なのでやめよう

ふりかえり会

サービスの改善だけでなく、業務の改善についてもメンバーから意見を出してもらうようにしています。プロジェクトチームを組んで大きめの機能追加を行った際は、プロジェクト終了後にふりかえり会を行い、仕事の進め方を改善しています（写真1⁠）⁠。

「これは微妙だな」と思うことを放置しておくとメンバーのモチベーションが下がることもあるので、チームのメンバーがストレスが少なく気持ち良く仕事に取り組むためにどうすればよいのかを、プロジェクトに関わったメンバー全員で意見を出しあいます。

たとえばリリースに手間取った場合、次回のプロジェクトではどうやったらスムーズにリリースできるかを意見しあいます。それを次回から実践することで、チームで進める仕事を改善します。ふりかえり会では、黄色の付箋に今回チャレンジしてみて良かったこと、赤い付箋に次回改善したいことを書いています。

仕事の改善

チームの組織力を高めていくためには、個人のスキルや仕事の進め方を高めるだけでなく、チームで進めた仕事の中で良かったこと、悪かったことのノウハウをためていくことが大切だと考えています。

業務の進め方や開発手法に関しても、何か改善できそうなアイデアがメンバーから提案があった場合には、極力試してみて、うまくいけば残し、失敗したけど改善できそうなところがあれば次のプロジェクトで改善して試します。

それを繰り返し、個々でうまくいった仕事の進め方をノウハウ化し、チームでの仕事の進め方の原則を作ることで、組織力を高めていければと考えています。

GitHub のIssueを利用した仕事の進め方

Issueを利用したタスク管理

これまでカラメルでは、業務の報告、連絡、相談は口頭またはIRCで、情報を残す場合にはWikiを利用していました。しかし、IRCとWikiは現在進行中のタスクの共有、連絡に向いていませんでした。

そんなとき、チームのエンジニアから「タスクの管理方法が個々でバラバラなので、GitHubのIssueに集約してみるのはどうか？」という提案がありました。現在では日々の施策の相談、プロジェクトのタスク管理に、GitHub EnterpriseのIssueを活用しています（図2⁠）⁠。

1つのリポジトリのIssueで、1人で完結する1時間単位の細かいタスクから、複数人で進める施策までを管理しています。Issueには「アイデア投下」「⁠広告」「⁠バグ」「⁠デザイン」といったラベルを付けています。タスクの詳細はIssueに記載し、毎日進めることは朝会で確認といった形でチームで仕事を進めています。

サービス改善案の相談やタスクの進捗確認など、毎日平均10件のIssueが作られ、150のコメントが投稿されています。最近ではIssueに書き込まれた意見から、よりサービス改善につながるようなアイデアが生まれることが多々あります。

Issueを利用するメリット

GitHubのIssueは、1つの話題に沿って複数人でコミュニケーションをとることができるため、新機能追加の相談やサービス改善のアイデア出しに向いています。意見をもらいたい人宛にメンション（@）を付けてコメントすると相手にメールで通知されるので、確認する側は自分の仕事のきりが良いタイミングで反応できます。相手の仕事を止めなくてよいため、意見を求めるほうも気軽に相談できます（図3⁠）⁠。

社内用Gyazoでデザインの進捗確認

ペパボでは、全社員が利用するIRCや社内SNS（Social Networking Service）上でスクリーンショットを共有するために、Gyazoをカスタマイズし社内環境で閲覧できる環境を構築しています。共有したいスクリーンショットのURLをGitHubのIssueに記載すると、画像を表示するブラウザのユーザスクリプトを社内配布しており、GitHub上で気軽に画像の確認ができるようになっています（図4⁠）⁠。

デザインをしていく過程や、ユーザインタフェース変更のビフォー／アフター、変更後のKPIの変化など、1つの施策の過程や効果を把握できるので、関係者以外のメンバーへの施策の情報共有にも適しています。

プロジェクトのIssue管理

複数人で進めるプロジェクトの場合は、ディレクトリとなる親Issueを立てて、細かいタスクは子Issueとして投稿し、1つの親Issueの中で必要なタスクが完了したかどうかを把握できるようにしています（図5⁠）⁠。

スケジュールを決めて取り組むプロジェクトでは別途スケジュール管理ツールを利用したりバックログを作ったりして、進捗の確認を行いプロジェクトを進めています。

チームの環境作り（リーダー向け）

メンバーの主体性を高めるために

サービスを成長させていくためには、チームのメンバー全員が、ユーザに価値を提供できそうな施策を考え、KPIの浮き沈みに敏感になり、主体的に日々サービス改善に取り組むことが重要です。ただなんとなく機能追加を進めるといった意識だと、機能のリリース後にKPIが変化しても、その変化に気づくことができず、サービスを成長させるチャンスをつかむことが難しくなります。

チームのメンバーの意識を高めることはマネージャやリーダーの役割でもあります。主体的に取り組んでもらうために、施策の中での個々の判断は極力メンバーに権限を委譲するようにして、各々の役割の中で責任を持って仕事に取り組んでもらうことを心がけています。

チームワークを発揮できる環境作り

メンバー個々の意識を高めるだけではなく、チームワークを発揮できる環境作りも重要です。カラメルでは、チームで仕事を進める際に大切にしたい考え方を定め、現在は次のことを意識して仕事を進めています。

コミュニケーションを活発にとる
早くリリースできる方法を提案する
効果測定を行い、日々改善していく
仕事の進め方も改善していく

運用の際にはメンバーに内容を共有するだけでなく、大切にしたい考えに沿った行動をしているメンバーがいた場合は皆で褒め合い、逆に外れた行動をしている人には個別面談で直してほしい行動を伝えるようにしています。

チームでの役割分担

チームのメンバーにモチベーション高く仕事を進めてもらうために、メンバーが個人的にチャレンジしてみたいと考えている分野、技術的課題、チームの中での役割があれば、できる限り担当してもらうようにしています。

チームのメンバーが少ない場合には一人一人が複数の役割を果たす必要がありますが、チームのメンバーがある程度増えれば、1人が担当する役割を絞って専門性を深めることも必要になってきます。個人面談や会議の場でチャレンジしたいことを聞いて、

サービスでその役割が必要となる機会があれば割り当てています。

また、チームのメンバーの役割、得意なことリストを作り社内に共有すると、他部署からも相談がくるようになり、役割を任されたメンバーのモチベーションが高まることがあります。

成果を意識してもらうために

サービスを成長させるためには、利益につながる成果をチームのメンバーに意識してもらうことが大切です。成果を意識してもらうために、マネージャやディレクターが率先して、エンジニア、デザイナに施策の効果を共有しています。

何か機能をリリースしたあとは、機能の利用数や影響しているKPIを毎朝チームに共有したり、KPIをより高めるためにどうすればよいのかを会議で議論しています。また、チームで業績目標を達成できたときは、会議の場で関係者の健闘をたたえたり、部署全員で焼肉ランチや達成会を開催しています。

本章のまとめ

チームの皆が気持ち良く仕事を進めた結果、ユーザに価値を提供でき、成果が生まれて、サービスを成長させ続けられるのが理想です。時折、外的要因などで思うような成果が上げられない場合もありますが、チームの組織力が高ければ挽回できると信じています。

そのような強いチームを作るために、マネージャやリーダーは、サービスを成長させることと同様にチームの組織力を高めることも必要です。

強いチームを作ることが、サービス成長のカギになります。

特集のまとめ

いかがでしたでしょうか。開発環境、パフォーマンス、インフラ、ビジネスの視点で、ペパボの継続的Webサービス改善を紹介してきましたが、これはあくまでも現時点での一例であり、完成形ではありません。

変化の激しいWebサービス業界では、技術的環境の変化、ビジネス環境の変化、トレンドの変化に常に対応していかないと、サービスを成長させることはできません。より多くのユーザに価値を提供するようなサービスを運営していくために、私たちは常に改善を続け、変化し続けていく必要があります。本特集が読者のみなさまの継続的Webサービス改善のお役に少しでも立てることを願っています。