サイタ cyta.jp は、カメラ、ドラム、ギター、ピアノ、英語、フランス語、イタリア語、簿記、司法書士、漫画、はたまた手品（！）まで、さまざまなジャンルの、教えたい人と習いたい人をマッチングするC2Cマーケットプレイスです。

プラットフォームを自律的に成長させていくための運営ノウハウの中で、今回は、サイタで採用している「売り手の数を自動調整する仕組み」について書いてみました。

@tkiyama

目次

売り手と買い手の数のバランスが重要な理由
売り手の満足度を高めるために売り手の数をコントロールする
サイタの需給バランス策：簡単な数式で生態系を作る
売り手は気合で集まるけど、買い手は仕組みが必要
鶏が先か卵が先か問題
さいごに

売り手と買い手の数のバランスが重要な理由

全てのマーケットプレイスには売り手と買い手がいます。メルカリならモノを売る人と買う人、Airbnbなら部屋を貸す人と借りる人、などなど。クラウドワークス、ランサーズ、ココナラ、チケットキャンプ等もマーケットプレイスです（プラットフォームと呼ぶことも多いです）。

習い事マーケットプレイスのサイタの場合は、教える人が「売り手」、習いたい人が「買い手」となります。

どちらかが多すぎても良くない。ちょうどよくバランスをとることが必要です。リアルなファーマーズマーケットとかをイメージするとわかりやすいと思いますが、お店（売り手）はたくさんあるけど買い物客（買い手）が少ない、もしくはお店はちょっとしかないのに買い物客が押し寄せたら、 売り手／買い手が離れていってそのプラットフォームはすぐに廃れてしまいます。そうならないように、売り手／買い手の両方の数を、ちょうどよくバランスさせながら成長させていく仕組みが重要となるわけですね。

とはいえ、後述する通り、買い手を集める方が断然難しいので、実際問題としては売り手の数をどう適正コントロールするか、という話になります。
※逆に言うと、爆速で買い手が集まるプラットフォームは、頑張って売り手を集めるだけ。

売り手の満足度を高めるために売り手の数をコントロールする

プラットフォームの質を決めるのは売り手です。サービス／商品を買い手に提供するのは売り手そのものなので。売り手に喜んでもらえたプラットフォームだけが大きくなれます。
プロカメラマンが撮影した部屋の写真、SMSによる通知などなど、Airbnbの各種仕組みももちろんすごいんだけど、直接的には、Airbnbが素晴らしいのではなく、Airbnbで提供しているXXXさんの部屋が素晴らしいから、プラットフォームとしてのAirbnbが成長できるわけですね。

良い売り手に定着してもらうために、大事なKPIの一つは「売り手一人あたりの注文数」だと思います。要は、注文が入るかどうか。注文が入らないプラットフォームから売り手がいなくなるのは当然だし、離れるときは一瞬です。

ニコニコ動画でのやり方について、「ルールを変える思考法」で、川上さんはこんなことを書いています。

ルールを変える思考法 (角川EPUB選書)

一般に、CGMでは、「ユーザーにいかに良質なコンテンツをつくってもらうか」が問われます。そのために、コンテンツをつくってくれるユーザーをどう増やすかを最優先に考えるCGMサイトが多いのですが、ニコニコ動画のコンセプトは少し違います。むしろ、コンテンツの作り手側になるためにはプレミアム会員として会費を支払わなければいけないというような、逆にハードルをつくるケースも多いのです。それは、「パフォーマー」と「視聴者」の数が適切なバランスになるようにするためです。なぜパフォーマーがそのサービスにコンテンツを提供するのかといえば、「みんなに見てもらえるから」という一点に尽きます。「いいモチベーションを保てる環境づくり」こそが大切になる。そのためにも、パフォーマー1人あたりの視聴者数を増やすことが最も重要なのです。

川上さんの言う「パフォーマーと視聴者の数が適切なバランスになるようにする」とは、このブログのテーマの「売り手と買い手のバランス」そのものです。
ニコニコ動画の「パフォーマー1人あたりの視聴者数」が、マーケットプレイスの「売り手一人あたり注文数」になるわけですね。

売り手が増えすぎるとどうなるか。「インターネットだから在庫コストはゼロ。売り手が増えれば増えるほどオーガニックコンテンツが増えてSEOも効くし。ロングテールだぜ！！」みたいな誤解がよくありますが、そんなことない。

売り手一人あたりの注文数が下がってしまうと、せっかく頑張って来てもらった素晴らしい売り手の皆さんが離れていってしまう。それに、売り手が増えすぎるとサポートの手が回らなくなって色々なトラブルが起きるので、対応コストが膨れ上がっていいことないです。
オーガニックコンテンツが増えてSEOが効く（＝アクセスが増える）のは事実だけど、やり過ぎるとメリットを上回るコストが発生してしまうわけですね。

サイタの需給バランス策：簡単な数式で生態系を作る

サイタでは、この「売り手と買い手のバランスをとる」ために、さまざまな施策があるのですが、それを支える一つの柱がこのアルゴリズムです。

y%を上回っている＝適切な状態であると定義しています
y%を下回ると「売り手一人あたり注文数」が少なすぎると判断して、売り手の数がこれ以上増えないように、新しい売り手の新規登録が自動停止されます。その後、買い手が増えるか、売り手が自然減すると、新規登録が自動再開されます。これを、エリアとジャンルごとにやっています。
（n, x, y のパラメーターについては、実態を見ながら時々調整してます。このあたりは職人技。）

要は、注文数が少ないと売り手の新規登録を抑制するわけです。
とても簡単な数式だけど、どこのプラットフォームもこういう簡単なアルゴリズムに落ち着いているんじゃないかなー、と推測しています。
簡単な四則演算で理解できる程度にしておかないと、いろんな追加施策をやっている間に自分でもわかんなくなっちゃうので、結局メンテできない。分析や集計のロジックがどんどん複雑になって、レビューするにも時間がかかるし。

Simple is best というか、複雑にすることは犯罪です。

売り手は気合で集まるけど、買い手は仕組みが必要

売り手と買い手、両方とも集めるのは大変です。どっちも超難しいけど、どっちがより難しいか。

プラットフォームごとに事情は全然違うと思うけど、自分のを含めていろんな事例を見ていると、売り手は気合の問題で、買い手は仕組みの問題、ということが多いように思います。

質の高い売り手を確保して維持するのは、それはそれで超難しいけど、売り手は何らかのコミュニティに属していることが多いので、そこのコミュニティに協力してもらうとか、イベントで声かけまくるとか、気合と根性で何とかなる。要は努力の問題。

買い手の方は、努力だけではなんともならない。一番最初は広告を出すのが手っ取り早い（というか短期的には広告の方がコスト安い）ですが、それを続けたらすぐに資金が枯渇してしまいます。

圧倒的に質が高くて価格が安いモノ／サービスが提供できれば理想だけど、現実はそんなに甘くないので、ビジネスモデルそのものに成長エンジンが入っていないとダメというか、CPA（顧客獲得コスト）を低く抑えられる仕組みが必要です。広告に頼らない顧客獲得手段がないと黒字化できない。

※成長エンジンの話は「リーンスタートアップ」に詳しいです。

リーン・スタートアップ

鶏が先か卵が先か問題

ちょっと本題から外れますが、売り手も買い手もいないところから始める、プラットフォームの立ち上げは本当に難しい。

売り手がいないとはじまらないので、（買い手はいないけど）少数の売り手を集めて、広告で買い手を集めながらまずは小規模にプラットフォームをスタートさせて、あの手この手でなんかいろいろ頑張っているうちに施策のどれかが当たってプラットフォームとして離陸する（または離陸できずに閉鎖する）、というのが一般的だと思います。

この、売り手と買い手のどっちを先に集めればいいの？が「鶏が先か卵が先か (chicken and egg)」問題で、Quora で “chicken and egg” で検索するとたくさん出てきます。例えば、

AirbnbはCraigslistをうまく使ったとか、

Etsyはebayから乗り換えた売り手が買い手を自分で連れてきてくれたとか。

それぞれのマーケットプレイスで、表向きの美談から人には言えない裏話まで、いろいろなストーリーがあります。

さいごに

新しいプラットフォームを作るとは、新しい未来を作ること。

みんなの人生が変わるような体験を生み出す場を作ることを夢見て、毎年たくさんの新しいプラットフォームが出てきます。しかし、売り手をがんばって集めて体裁を整えても買い手が集まらず、今度はメディアに露出して華々しくデビューしてもそれだけでは意味がないとあとで気づき、トランザクションがやっと入りはじめてもその後に黒字化できるのは本当に一握りの会社だけ。

プラットフォームが生き残るには、そこに需要があるのはもちろん前提として、数字で裏打ちされたアルゴリズムでプラットフォーム内に自律した生態系を作ることができるかどうかにかかっています。

今回の記事が、C2CやB2Bマーケットプレイスに限らず、プラットフォームを作ることに興味のある人に役立てばうれしいです。
それから、この記事に興味をもっていただけた方は、いいねとかシェアとかしていただけると、もっと会社のノウハウをがしがし書くぞ！というモチベーションにつながるので是非お願いします！

※サイタでは エンジニア、 プロデューサー、 デザイナー、 ユーザーサポート を募集しています。ご興味ある方はぜひ！

弊社では、プロジェクト管理ツールとしてGitHubを全社員に導入し、非エンジニアのプロデューサーやユーザーサポート、経理や法務担当にいたるまで、社員全員がGitHubアカウントを持つようになりました。

今回の記事では、なぜGitHubをプロジェクト管理ツールとして全社員に導入したのか、導入にあたって苦労したこと、どうやって運用しているかなどをご紹介します。

@tkiyama

※GitHubって何？という方は、「今さら聞けない！GitHubの使い方」などをご覧ください。

目次

前提として（CU社のプロジェクト管理とコミュニケーションツール）
なぜ導入したか：全員がエンジニア目線を持つ
導入してよかった3つのこと
非エンジニアのためのGitHub運用マニュアル
情報共有と未読管理（notification設定）
Issueの立て方とテンプレート
Labelでソースコード管理を区分する
LGTMはスタッフ写真でほっこりする
その他、導入にあたって苦労したこと
さいごに

前提として（CU社のプロジェクト管理とコミュニケーションツール）

弊社（CU社）では、GitHubの全社員導入前までは、エンジニアだけがGitHubとSlackを使っていて、非エンジニアが使うのはYammer（社内SNS）だけでした。

プロジェクト管理ツールは使っていなかったので、各担当者が自分なりに工夫して、ExcelとかGoogle SpreadsheetとかEvernote等でプロジェクト管理をしていました。

よく言うと優先順位を随時組み替えながらアジャイルに、悪く言うと（実態は）てきとーにプロジェクト管理していたわけです。

プロジェクト管理ツールとしては、JIRAみたいなガッツリしたものとか、ZenHubみたいな拡張タイプとか色々ありますが、弊社の場合は専用ソフトを導入していなかったので、全社員のプロジェクト管理ツールとしてGitHubを導入しやすかったと思います。

なぜ導入したか：全員がエンジニア目線を持つ

Wantedly社のこのブログを読んだのがきっかけでした。

Wantedly社の法務部門ではタスク管理にGitHubを使ってるよという話なんですが、読んだ直後は「契約書のバージョン管理には使いたいけど、法務の人にrepositoryとかissueとか無理でしょー」と思ったものの、よくよく考えると、「ありかも」と思い直しました。

非エンジニアが、エンジニアと同じツール（GitHub）でプロジェクト管理するようになれば、自分の企画の結果（何が変わったか）をコードで見ることになります。企画者がコードを理解するようになれば、全社員がエンジニアと同じ目線でサービス開発（オペレーション設計）するという理想に近づけるのではないか、と考えたわけです。

ユーザーファーストなサービス設計を目指す上で、オペレーター、プロデューサー、エンジニア、デザイナーの全員がサイト構造（＝コードそのもの）を理解しているかいないかは大きな違いです。多少なりともコードが理解できないと、毎回エンジニアに確認する時間が無駄だし、エンジニアと非エンジニアで認識の齟齬がでてしまって、エンジニアの仕事が遅れてしまったり、手戻りが発生してしまう。

以前から、「プロジェクト管理ツール入れた方がいいかもなー」とか「Yammerの使い方が独自進化しちゃってるから、新しいスタッフがCU社のやり方に慣れてもらう時間が無駄だなー」などと考えていたことも、今回のGitHub全社員導入を後押ししました。

例えば契約書の修正とか、エンジニアと全然関係ない仕事も多いですが、思い切って全社員を対象にしました。同じ社内で異なるツールを使っていると、毎回翻訳作業のようなものが発生して、とにかく時間が無駄。小さな組織の最大の武器はスピードなのに、ツールで足を引っ張らないようにするためにも、共通言語（＝GitHub）を使うことにしたわけです。

導入してよかった3つのこと

良かったことは主に3つありました。

その1：コミュニケーションのロスがなくなって、エンジニアと企画の溝がなくなった

全社員が同じツール、同じキーワードを使って会話することで、コミュニケーションのロスがなくなり、企画からリリースまでが一直線になりました。

GitHubの全社員導入前は、Yammerで企画の目的をいろいろ議論した後で、その結果をエンジニアに「あとよろしく」で渡していました。企画をもらったエンジニアがIssueを立てて、作業が終わったら、Yammerで「preview環境にリリースしたので確認してください」云々とやっていたわけです。

こういうやり方をしていると、どうしても企画側とエンジニア側の溝が少しずつ深くなって、別の組織として振る舞い始めてしまう。設計の意図とか理念とかが途中で抜け落ちていくわけです。細かいことをいうとdatabaseのcolumnの命名のニュアンスが違ってたりする。そして、頻繁なすりあわせとか手戻りに延々と時間がかかってしまうので、何よりも全体のスピードが落ちてしまいます。そういうことが、全員がGitHubを使うことで解消しました。

その2：新しくジョインした人がすぐにキャッチアップできる

エンジニアの共通言語となっているGitHubにあわせたことで、それまで他社でGitHubを使っていた人がすぐに参加できるようになりました。
これまでの開発の経緯もすぐに理解できるし、ここでも無駄なコミュニケーションコストを削減することができました。

その3：プロジェクト管理レベルが上がった

特にキャリアの浅いスタッフが、ものすごく顕著にレベルアップしました。チームを動かす力がついて、なんというか、いきなりプロフェッショナルになった。ツールでこんなに急成長することってあるんだなーと驚きました。

そもそも私がプロジェクト管理ツールをそれまで導入しなかったのも、（ぐいぐい動くガントチャートとかがある）高機能ツールの場合、ツールに振り回される時間が無駄だし、優先順位を臨機応変に入れ替えしにくいからですが、Issue／Assign／LabelといったGitHubの各機能はとてもシンプルで、過不足なくてちょうどいい。
弊社の場合は大型プロジェクトよりも小さなプロジェクトをたくさんまわしていくので、それも（プロジェクト管理ツールとしての）GitHubの仕様とフィットしていたと思います。

加えて、タスクやプロジェクトをYammerから切り離したことで、コミュニケーションとプロジェクトの区分が明確になって、重要なプロジェクトが日々のコミュニケーションに埋もれなくなったことも良かったです。

非エンジニアのためのGitHub運用マニュアル

これは、非エンジニアがGitHubをうまく使いこなせるように、弊社が作っているマニュアルの目次です。

（弊社のマニュアル構築については「チームが強くなるマニュアルの作り方：大事なポイントは2つだけ」をご参考。）

最初ちょっと苦労したのが、情報共有とIssueの立て方でした。

情報共有と未読管理（notification設定）

GitHubはそもそもプロジェクト管理ツールではないので、基本理念が違うというか、各個人の情報共有と未読管理についてはちょっと工夫する必要があって、この方法に行きつきました。

このURLをブックマークして、最低でも1日1回、3つのページにアクセスすることにしました。
https://github.com/issues/assigned

【その1】Assigned
自分ボールとなっているIssue

「あー、これやらないとなー（他の人を待たせてる）」とかって思う。
とてもシンプルな機能だけど、Assign仕様がプロジェクト管理ツールとしてのGitHubのキモです。

【その2】Created
自分が作ったIssue

「あ、これじゃあスケジュール間に合わない！」とかって思う。

【その3】Notifications
自分がwatchしているrepository更新情報＝他スタッフのIssueの最新状況

「ふむふむ、あいつがんばってるな〜」とかって思う。
※全て細かく目を通す必要はありません。自分が関係するとこだけ読めばOK。

Issueの立て方とテンプレート

Issueの最初のコメント欄を使って、プロジェクトの進捗管理をしています。

こんな感じ。

Checkboxを重要視しています。すごい簡単な機能なんだけど、完了確認がしやすいのと、Issue一覧のところに進捗状況が出るのが便利。

こういうルールにしています。
・原則として、Checkboxを必ず使う。
・誰が何をいつまでにやるのかを記入する。(見込)スケジュールを作る。
・状況が変わったら随時変更すればOK。最初に全体の見通しをたてることがとても大切。

こういうのは習慣付けなんですが、スケジュールがないタスクは、「いつでもいい仕事」＝「やらなくてもいい仕事」だと、自分もチームも考えてしまう。外圧がなくても自分に厳しいスケジュールを課せる人はほとんどいません。 最初にスケジュールを宣言してしまうことが大事。

これがテンプレート（使うときは改行いれてね）。

このテンプレートも、進捗管理の方法も、あくまで推奨です。GitHubを使いこなせてプロジェクト管理できる人は好きにやってOK。「Issueのレベル感問題」（どの程度のプロジェクト／タスクをIssueとするか）があるんだけど、厳密にルールを決めるより、各人の裁量に任せた方がうまくいくと考えています。

Labelでソースコード管理を区分する

非エンジニアがGitHubでプロジェクト管理しはじめると、ソースコードとは直接関係ないIssueがあふれることになります。加えて、Assignされるまでエンジニア／デザイナーにはプロジェクトの進捗が適切に通知されないので、プロジェクトの終盤になってから、いきなり「これやってください」ということが発生してしまう。
これまではプロジェクト管理のコミュニケーションはYammerで行っていたので、そういう問題は発生していませんでしたが、全てGitHubでやるとなると、コードを書く人が、コードを書くIssueを最初から区別して管理する仕組みが必要となります。

とても簡単な方法ですが、これをLabelで解決することにしました。

エンジニアチーム（Tech）とデザイナーチーム（Design）の業務が発生する見込があるものは、Issueを立てた時点で"Tech" “Design” というラベルをつけることにしました。

こんな感じ。

これにより、エンジニアチームとデザイナーチームが数ヶ月先までの業務を見込めるようになり、かつ初期段階でプロジェクトの方向性を修正できるようになりました。

LGTMはスタッフ写真でほっこりする

LGTM画像は、コードだけでなく、施策の企画レビューにも使っていて、スタッフの画像を素材にしています。リリース時の緊張がちょっとだけなごやかに。

※社内イベントのときとかに、LGTMカメラを使ってLGTM画像を大量生成してます。このアプリおすすめ。

その他、導入にあたって苦労したこと

実は、GitHubが日本語対応してない（英語だけ）、というのが結構なハードルでした。orz…

それまで英語を使う必要のない環境で過ごしてきた人にとっては、英語のツールを使えっていうのは相当なストレスなわけです。
余談ですが、日本人は英語ができないっていうのはウソで、こんなに国民全員が英語ができる国はほとんどない。日本中どこでも外国人が道を聞いたら英語で教えてくれるし。スラスラしゃべれないだけで、ごく簡単な日常会話ならほとんどの日本人ができます。GitHubで使われてる英語は、文法はわかりやすいし表現のパターンが決まっているので、いくつかの業界用語を覚えれば中学英語レベルで全然問題ないんだけど、「英語が苦手！」っていう意識はなかなか消えないですねー。

ま、「全員が共通言語を持つ」（＝同じツールとキーワードを使う）ことが何よりも大事なので、頑張って英語でGitHubを使ってもらうしかないんだけどね。

さいごに

今回の施策には、これまで @tmtysk が取り組んできた「全社員を開発者にする」という取り組みが土壌にありました。職種はエンジニアじゃないけど普段からPull Requestまでやるスタッフが何人もいて、そのスタッフが他メンバーをサポートしてくれたので、GitHub導入をスムーズに行うことができたと言えます。
（参考：「全社員を開発者にする取り組みと進捗について」）

会社はそんなに簡単には変われないというか、過去の積み重ねがあって組織は進化していくんだなーと思います。今回のGitHub全社導入でエンジニアと同じツールを使うことにより、なんというか、雰囲気なんだけど、「開発者」としての意識がより強くなったように感じます。企画する人、作る人、日々動かす人、これらの人達が同じ「開発者」としての目線を持った組織が、ユーザーファーストなサービスを生み出し続けることができるんじゃないかと思います。

今回の記事が、GitHubをエンジニア以外にも使わせたいなーとか、簡単なプロジェクト管理ツール入れようかなーと思っている方の参考になればうれしいです。
それから、この記事に興味をもっていただけた方は、いいねとかシェアとかしていただけると、もっと会社のノウハウをがしがし書くぞ！というモチベーションにつながるので是非お願いします！

※サイタではエンジニア、プロデューサー、デザイナー、ユーザーサポートを募集しています。ご興味ある方はぜひ！