Co-LABO MAKER様：スタートアップでのリソースとスピードのトレードオフ、その釣り合いをとりながらのプロダクト開発支援

Co-LABO MAKER（コラボメーカー） は、時間や日単位で利用できる研究機器や委託・技術開発を依頼できる組織を、日本中からマッチングするサービスです。
利用者はマッチングに際して、適切な機器や依頼先について専門家に相談することもできます。また、機器・技術の提供者・組織は余剰リソースを活用することで収益化へつなげたり、共同研究のきっかけとすることが期待できます。
Co-LABO MAKERは、ギルドワークスおよびSBメディアホールディングスの主催する第二回MVPアワード（2016年）で最優秀賞を受賞しています。

## 開発の”基礎固め”からスタート

Co-LABO MAKER 代表 古谷優貴 氏（以下敬称略、古谷）「2016年にMVPアワードで最優秀賞を受賞したあと、2017年4月に法人化しました。プロダクト・サービスの正式リリースに向けて体制を整えようとしていたのですが、その当時はリードエンジニアがまだフリーランスという形でしたので、週3〜4日しか稼働できない状況でした。さらに、あとからジョインした開発メンバーも全員が週2日ほどの稼働で、かつリモートワークという状態でした。
こうした状況でしたので、最初から自分たちですべてやるより、ギルドワークスに開発マネジメントに入っていただきながら、プロダクトの基盤を整え、運用からは自分たちで引き継いでいく形がいいのではないか、と思い、依頼しました」

ギルドワークス 佐々木（以下、佐々木）「当時、リードエンジニアはマネジメントの適性と意欲がありました。しかしながら、開発マネジメントの経験はあまりない状態で、しかも、開発メンバーは皆副業状態でかつリモートワークという特徴がありました。
こうしたチームをとりまわすというのは非常に大変です。そこで、私が開発マネジメントの下地をつくり、開発プロセスやインフラを整備し、徐々に内製化できるような体制を整えていきました。
スタートアップはスピード感が大切ですので、初動の基礎固めはしっかりサポートし、ずっとギルドワークスが主導するわけにはいきませんので、最終的に自走できるチームを目指していきました」

### 頭の中にあるものをプロダクトバックログに落とし込む

古谷「開発手前の要件定義から佐々木さんに手伝っていただきました。かかった時間は1ヶ月ほどでしたね。この段階では私と佐々木さんが仙台、リードエンジニアが名古屋にいましたので、議論やアウトプットの共有はリモートで行いました。
Slack、Trello、Googleスプレッドシートを含めた、こうしたリモート開発の体制を要件定義の段階からある程度作っておけた、というのはこの後の開発を進めるにあたってもメリットがあったと思います」

佐々木「ギルドワークスも開発をリモート主体でやっているので経験値もありましたし、うちはこういう背景でこうやっている、というのを伝えれば、皆さんそのまま実践してくれました。実際、メンバーの皆さんとも最初のうちはほとんど直接お会いしていなくて、Skypeでこんにちは、というような形でした」

要件定義では、カスタマージャーニーマップ、ユーザーストーリー、機能一覧とそれぞれの大まかな工数、主要画面のざっくりしたペーパープロトタイプを作成し、来る開発フェーズ「つくるべきもの」を見立てた。
議論はクラウドサービスを利用して遠隔地にいるメンバーにもリアルタイム共有しながら進められた。

古谷「私自身はこれまでウェブ業界にいたというわけでも、プロダクトの作り方を知っていたわけでもなかったんです。ギルドワークスさんに入ってもらうことで、”こういうものを作りたい”という構想をユーザーストーリーベースで整理して要件に落とす、ということをすんなりできたのは非常にありがたかったです」

佐々木「どういうものを作りたいか、というのが古谷さんの頭の中にはあったので、それを形にする、というのが要件定義の段階での主な目的でした。それと、古谷さんがMVPアワードの時にすでに仮説キャンバスを作ってらして、私自身がそれをレビューしているのでやりとりもスムーズでした」

古谷「開発にあたって他の会社に依頼することは考えてなかったんです。ギルドワークスというか、佐々木さんとは本当に奇跡的すぎる偶然がありました。佐々木さんはたまたま同じ大学の先輩で、同じキャンパスに通っていましたし、MVPアワードに応募した時にやりとりしたのも佐々木さん。自分が転職で仙台に戻ることになった時にコワーキングスペースに行ったらユーザー代表で佐々木さんの写真があった、とか、すごい偶然が重なっていて、なんなんだこれは、と」

## スタートアップならではの開発の壁

### リソースが足りない中でどう組むか

佐々木「スタートアップあるあるなんですが、ファーストリリースの開発は、そんなに資金が潤沢にあるわけではないんですね。通常のギルドワークスの開発だと、開発チームをギルドメンバーで揃えて、私がマネジメントをすることが多いのですが、Co-LABO MAKER さんの状況だとそれだと折り合いがつかないことがわかっていました。
資金が足りない、とはいえ同じように人的リソースも限られているので外部パートナーが必要。そうした状況でしたので、今回は、スクラムマスターとしての立ち位置で、開発マネジメントのサポートやインフラの整備を行うことで、コストを最低限におさえながらの支援でした」

### 全員がリモートで副業状態

佐々木「ファーストリリースは、MVP（Minimum Viable Product）を実装し、デザインにも手をかけずグラフィカルなデザインはなし。当初の見立てとしては1ヶ月程度で検証に入れるだろう、と思っていました。ただ、実際は2ヶ月かかってしまいました」

— 開発プロジェクトというのは見立てがずれたり、見積りが揺れることがままあります。今回の大きな要因は何だったんでしょうか。

佐々木「さきほどもお話にありましたが、開発チームがみんなリモートかつ副業状態だったんです。一番稼働が多いメンバーで週3〜4日、他のメンバーはそれぞれ週1〜2日ほど。そうした中では互いの意識合わせが難しい。週1日だと情報共有だけで終わってしまいます。リソースだけ単純に足し算すると2日にも3日にもなりますが、実際はその半分くらいのパフォーマンスしか出せなかった。これが最初にぶつかった大きな壁ですね」

システム開発にはそれぞれリソースが限られており、”時間、予算、品質、スコープ”の”荒ぶる四天王”をつねにトレードオフしながら進める必要がある。

古谷「この時点では資金調達などできてなかったので、このままでやらざるを得ないという状況に陥ってしまっていました。期間を延ばすしかない、という選択です」

佐々木「開発での難しさをもうひとつ言うと、フィードバックループが長いんです。たとえば水曜日が定例で、スプリントデモがあったとき、稼働日が火曜のメンバーはそこで得られたフィードバックに対応するのは翌週の火曜になります。
こうした状況に対応するために、定例の曜日を固定して全員参加にし、”ふりかえり”をみんなでやって、その内容を残しておいて、思い出す時間、共有のための時間を減らすようにしました。作業的なところでは、直前のプログラムコードのマージミスを防ぐためにプルリクの日を決めうちにするなどもしました。
ギルドワークスでは1スプリントを1週間でまわすことが多いんですが、今回こういう体制でしたので1スプリントを2週間に変更したり、メンバーの判断と合意に基づいてタイムボックスを変更したりと、教科書通りではなく、柔軟に、限られた時間の中でうまくまわせるように進めていきました」

— 開発チームは古谷さんに対してどのような期待をしていたのですか。

佐々木「今のサービス品質でリリースしてアルファ版として検証するのか、それとももっと開発を進めるのか、というのを常に古谷さんに選択してもらっていました。このジャッジは非常に難しかったと思います」

古谷「開発が一段落するあたりまでは、まだ全員別の仕事があるような状態でした。開発開始から3ヶ月くらい経った2017年の9月頃、フルタイムでコミットできるメンバーを入れることができて、ようやくある程度推進力をもって開発を進められるようになりました」

### 誰のためのサービスなのか

古谷「こうした状況の中で、機能開発について何を主軸にするのか、いつまで、どこまで作るか、といったあたりがそんなに明確に持てていない状態の時もありました」

佐々木「そうした曖昧な状態でとりあえずこれやろうか、という感じになって、”とりあえずってなんだよ”、と、1回揉めたこともありました。そういう曖昧なときに何が起こるかというと、実装方針から入っちゃうんです。このサービスは誰かのために作っているはずなのに、”ある機能をどう作るか”が先に来てしまいます。フルスクラッチで作るか、似たような機能をプラグインとして入れるのでもいいんじゃないか、みたいな議論になってしまいました。
本来は、こうした機能開発についてはプロダクト全体の方針に基づいた判断をしないといけないのに、いつのまにか実装方針の話にすり替わっていました。みんなどこに向かっているかが曖昧にしかわかっていないから、曖昧にしか判断できない。
結果的に、この時議論していた機能は自前で作りました。今後この機能がサービスの発展に不可欠である、という前提があったし、別サービスをオプトインして検証を先に進めなくてはいけないような機能ではなかったので、フルスクラッチで、という判断をしました」

### プロダクト検証の難しさ

古谷「プロダクト全体の方針や仮説検証という点からいうと、検証を重視する部分と、作り込むべき部分の切り分けができていればよかったかもしれません。これができていなかったらプロダクトとして成立しない、という、正式リリースを待たずに確かめに行く部分と、この次の検証のためにこれは作っておく、という判断ができていればよかったなと思います」

佐々木「この点については私も反省しているところがあります。スタートアップだと時間の制約が一番強い。下手したら一年後二年後にはサービスや会社がないかもしれない、という温度感があるので、スケジュールが伸びることにより、そうした検証が間に合わなくなる、という議論をしておくべきだったかもしれません」

## 自走できる開発チームへ

佐々木「フルコミットのメンバーが増えたので、私の行っていたスクラムイベントや開発マネジメントをCo-LABO MAKERのメンバーへ引き継いでいきました。当初の目的どおり、徐々に内製化をしていきました」

— こうしたスクラムのプラクティスをもとにしたアジャイル開発に、メンバーの皆さんは慣れていたんですか。

古谷「慣れてはいなかったです。リードエンジニアがある程度やったことがある、というくらいで、他のメンバーはこういうやりかたがあるんだ、という新鮮な感じだったようです」

佐々木「おそらく最初は大変だったと思います。これまでメンバーはしっかり仕様が決まった状態から開発していたようで、”この部分は決まってないんですか”、”この部分は決めてください”というような発言が出てしまう場面がありました。最初のうちはアジリティをもって動く、というのは難しかったと思います。
開発メンバーが迷わないようにフォローはするものの、結局ものをつくるには、開発者がわかっているかどうかでしかない。開発者がコードを書こうとした時に飲み込めないものが出てきたときに、何をつくるべきか、どうつくるべきかは、会話でしか埋められないと私は思っているんですが、そういう感覚はリモートだと共有しにくいので、苦労されたんじゃないかなと思います」

古谷「引き継ぎをはじめて、社内でほぼまわせるようになってからもフォローしていただいたり、開発も手伝っていただき、2018年3月までご支援いただきました」

## Co-LABO MAKERの今後

古谷「Co-LABO MAKERは研究機器を使って技術開発を行いたい人と、そうした技術や機器を保有している組織をマッチングするサービスですが、オンラインでのみマッチングができるというのは相当高いレベルのことだと思っています。ランサーズやクラウドワークスといった有名なマッチングサービスも、営業というオフラインに頼っている部分がまだまだあるはずなんです。
こういう従来のマッチングサービスを脱するには、技術や機器の提供者に対してしっかりしたメリットを提示し、提供者と利用者双方に、このプラットフォームを挟むからこそいい、成立する、というように思ってもらえることが必要だと考えています。開発という意味ではそういうところを強化していって、提供者側も利用者側もスケールしていきたいです」

佐々木「今後もぜひ何かの際にお手伝いさせてください」

古谷「はい、今日お話して、またいろいろお願いしたいな、という気持ちになりました」