「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。

Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。

そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、11月7日に東京・六本木のGoogle東京オフィスにて『Startup Tech Night』というイベントが開催された。これは、トーマツ ベンチャー サポート協力の下、スタートアップのCTOクラスに集まってもらい、自社の開発体制を披露し合う勉強会だ。初回となったこの日は

■株式会社カブク　CTO　足立昌彦氏
■株式会社FiNC　CTO　南野充則氏
■ランサーズ株式会社　CTO　田邊賢司氏

の3人が登壇した。彼らの話から、昨今のスタートアップがどのような開発ポリシーでサービス開発に取り組み、どんな体制づくりに力を入れているのかが分かった。3社それぞれの手法を紹介しよう。

“カジュアル・ローンチ”をできる環境づくりが大切

ここ2～3年はリーン・スタートアップが普及し、どの企業も「すばらしいプロダクト」を生み出すにはMVP（必要最低限の機能）を選定した上で改善のPDCAサイクルを高速に回していくことが必要だと理解しているだろう。この開発・改善の速さを担保するには、やはり開発体制の整備が必要不可欠になる。

近年、有名アプリの開発チームでは機能追加やUI改善を1～2週間単位で行っている印象だったが、この日登壇した3社のCTOも「頻繁にローンチするための体制づくり」に力を注いでいると話した。

例えば、3Dプリンタなどのデジタル製造技術を誰にでも使えるようにするプラットフォームサービス『rinkak（リンカク）』を運営するカブクCTOの足立氏は、「現場が変なプレッシャーを感じず、カジュアルにローンチできるような環境づくり」を実践していると明かした。

「当社は週1～2回くらいのペースでローンチを繰り返していますが、スタートアップの開発だとスクラムでも遅過ぎるくらいだと思っています。そのため、できるだけローンチを『一大事』にしないようにするのが何より重要です。一方、そんなスピード感の中でもきちんとレビューを行い、リリースノートも書くようにするには、意識と仕組みの両方を変えていかなければなりません」（足立氏）

遺伝子検査や血液検査で得た定量データと食習慣アンケートのような定性データの両面から、ユーザー1人1人に合った健康管理サービスを提供しているFiNC南野氏も、「リリースを日常化するために、DeployGateやJenkinsなどを活用しながら自動化できる部分はなるべく自動化している」と語る。

「ローンチ時の手順漏れなど、間違えるのは結局『ヒト』ですからね。できるだけ自動化することで、現場の負担を軽くする努力が欠かせないと思っています。テストも、100％を目指してコツコツやっています」（南野氏）

足立氏の言う“カジュアル・ローンチ”のメリットは、開発・改善の高速化以外にもあるそうだ。

「一回あたりのマージ量を減らす意味でも、細かくローンチしていく方が良いと考えています。それに、不具合が生じた時の対応も、『今日不具合が発生したってことは昨日のローンチが原因だ』と分かりやすくなるんです」（足立氏）

カブクでは、どの機能の開発を優先し、どう切り分けるかをエンジニアが決定しており、「レポートラインは僕なので最小で2人の話し合いだけでローンチできる」ようにしているという。

急成長するクラウドソーシング市場の先駆者であるランサーズの田邊氏も同様に、「タスク管理はそれぞれのプロダクト開発チームに権限委譲しており、スタイルも現場がやりやすい手法でやっている」と話す。デイリー単位でローンチをしていくためには、意識レベルと環境の双方で土台を作らなければならないということだろう。

情報共有や自動化で最新ツールを導入する前に「決めるべき」ことは？

その「環境」の構築について、3社に共通していたのは最新のツールをHackしながら柔軟に取り入れているという点だった。そして、その上で「活用ポリシー」を徹底するというポイントが浮かび上がった。

登壇した順に活用ポリシーをまとめると、以下のようになる。

■開発は「共有至上主義」

例えば、ドキュメントは書いて書いて書きまくる。ただ、ドキュメントを書く作業が大変なのは承知しているので、Google Docs、Google Appsをうまく使って、できるだけ省力でやれるような環境を作っている。

エンジニア間でのチャットや情報共有はSlackで行い、社内全員とはFacebookチャットのグループを用意している。Facebookチャットだと、外部の方々ともすぐ会話が始められるからだ。

さらに、プロジェクト管理ツールとしては、オールインワン型のコラボレーション／プロジェクト管理ソフトである『Wrike』がオススメとのこと。

■最初から「人員増」を前提にドキュメントを準備

コーディング規約はほぼ完璧にそろえてる。今後人が増え、誰かの引き継ぎでもすぐ開発を行えるようにするには、大変だけど「最初から作っておく」ことが肝心だからだ。

また、将来外国人がチームに入っても大丈夫なように、コメントは英語で残すことを推奨している。

■ツールはなるべく「万人が使えるもの」を

開発はGitHubベースだが、タスク管理はGoogleスプレットシートも併用している。企画系の人との共有する際に、開発者だけに“閉じない”ようにとの配慮ゆえだ。日々のコミュニケーションも、Slackに合わせてLINEグループも使っている。

勤怠管理はSlackでやるなど、できるだけ特定のツールに集約するようにしている。

■サービスごとに「ユーザー視点」で考える

前述したようにリリースは頻繁に行う一方、サービスによってはあえて半月～1カ月単位で機能追加・改善を行う場合も。例えば、ダイエットの専門家や栄養士からパーソナライズされた健康管理アドバイスを受けられるアプリ『FiNCダイエット家庭教師』の場合、ユーザー層が必ずしも“アプリ・リテラシー”の高い人たちではないため、頻繁にUIや機能を変えないように配慮しているそうだ。

一方で、『FiNCダイエット家庭教師』に参加している各種アドバイザーには、レスポンススピードを高めるためのさまざまな可視化作業をシステムでどんどん行っている。「顧客第一」で開発するなら、機能によって改善スピードも変わるという考え方だ。

※以下は、当日南野氏が発表したFiNCの開発体制をまとめたSlideShare

■開発手法は各チームの「ベターなやり方」で

いくつかある機能の基本的な開発チーム構成は、プロジェクトオーナーをトップにデザイナー、エンジニアの少数チームで行う。社内のエンジニアは12名だが、自社サービスであるランサーズを利用しながらリモートで協力者を募るケースも。

機能ごとに進ちょくやリリースのスピード感は異なるため、「タスク管理はプロジェクトごとに行うようにし、スクラムっぽいチームもあれば、何ちゃってアジャイル開発のチームも」（田邊氏）あるという。

ただし、チーム間のコミュニケーションはChatWorkで統一し、ちょっとした機能開発でも極力ドキュメントを残すようにするなどの共通ルールを保つようにしている。今後は、構成管理のAnsibleやCIツールのJenkins、サーバ管理ツールのDockerといった最新の自動化ツールも採用していく予定だ。

■手法を現場に任せるからこそ重視する3箇条

情報共有はConfluenceで行っているが、最近特にチーム内／チーム間での情報共有に注力。現場には「暗黙知をなくす」、「事に向かう」、「HRT（謙虚と尊敬と信頼＝書籍『TeamGeek』より）」を徹底するようにしているという。

例えばGitHub上でアンチパターンを指摘する際にも、「相手に対して敬意を欠くような書き方はNGだ」など細かい気配りを大事にしている。「こういう配慮がないと、チーム内に邪推が生まれたりするから」（田邊氏）だそう。

こうして、各社それぞれに“哲学”を共有しながら、スピーディーなプロダクト開発に乗り出している。ツールの有用性や導入の是非について議論が行われるケースは多々あるが、そもそも論として「どんなポリシーで開発を進めていくか」から話し合うことが大事なのかもしれない。

この『Startup Tech Night』は、今後も不定期で開催していく計画があるという。興味があるエンジニアは、次回開催情報をこちらでチェックしてみては？

取材・文・撮影／伊藤健吾（編集部）