「チーム移籍」を実践するMakuakeに見る、次世代の組織拡大の手法とは。受託ではなく“裁量”を持つパートナーに。
クラウドファンディングサービス『Makuake』は、2019年8月26日、プロジェクトを応援する支援者向けに『シェア支援機能』を公開した。
シェア支援機能とは、Makuakeで実施中のプロジェクトの支援者が、自分専用のシェア支援リンクをSNSなどで第三者にシェアすると、そのリンク経由で何人がプロジェクトページに訪問し、何人が支援したかが分かる機能だ。
従来のSNSシェア機能との違いは、支援者のアクションによってどれだけプロジェクトページが閲覧され、何人が支援を実行したか数値で知ることができる点にある。つまり、情報拡散の成果を可視化することによって支援者の参加意識を高め、プロジェクトの成功を後押しするのが狙いだ。
このシェア支援機能の開発を担当したのは、マクアケ社の開発パートナーであるジシバリ社。ジシバリは外部の開発会社という立場でありながら、マクアケのメンバーを含むエンジニアとチームを組成し、プロジェクト支援者向け機能を主体的に開発している。
なぜ、こうした開発体制を敷いているのか。その経緯と目的について、マクアケのCTO生内洋平さんと、ジシバリの代表を務める藤池匡史さんに話を聞いた。
「“発注”という概念がない」新しいSESのカタチ
「Makuakeが提供するサービスは大きく分けて、アイデアを形にしたい実行者をサポートする機能と、プロジェクトを応援する支援者をサポートする機能があるのですが、ジシバリさんには開発パートナーとして、支援者向け機能の改善や新機能開発をお任せしています」(生内さん)
マクアケのCTOである生内さんは自社とジシバリとの関係をそう説明する。
両者の関係は、成果物が明確に定められている業務委託契約ではなく、技術力の提供によって対価を支払う、いわゆるSES契約(準委任契約)がベースになっているが、一般的な発注者と受注者の関係とは趣を異にする。
なぜならマクアケは、ジシバリのエンジニアチームに支援者向け機能の改善案の企画から、提案、実装までの一連の業務を託しているからだ。
「SES契約に基づく業務フローでは、発注者が開発タスクを切り分け、SES会社に発注し、目的の機能を開発してもらうのが一般的です。しかしジシバリには支援者向けの開発を継続的に担ってもらっており、業務フローの中に“発注”という概念がありません。
あるのは『支援者を幸せにする』という終わりのない課題を一緒に追いかけ、サービスを継続的にブラッシュアップするというミッション。そういう意味ではプロパーのエンジニアリングチームと同じような意識で動いてもらっているといえます」(生内さん)
ジシバリ・代表の藤池さんも頷く。
「私たちは支援者の皆さんの体験をより良いものにするというミッションにフォーカスしているので、マクアケから個別の案件を託され、その都度開発しているわけではないんです。新機能を開発する際には、生内さんやCEOの中山(亮太郎)さん同席のもと、Makuakeが実現したい世界観を聞かせていただきながら、ディスカッションを重ね、アイデアや企画を積極的に提案させてもらっています」(藤池さん)
“完成された開発チーム”をスカウトするという試み
だがここで一つ疑問が湧く。ジシバリは2017年創業の若い受託開発会社だ。彼らに一定の権限と責任を与えて開発を任せるメリットはどこにあるのだろうか。
「2018年にマクアケのCTOに就任して採用戦略を考えていた時に、4〜5人のエンジニアをバラバラに集めてチームビルディングをするのはそれなりのパワーと時間が必要だと思いました。
しかし、既に開発をともにしているエンジニアリングチームなら、開発フローやカルチャーもできあがっているので、任せたい開発領域もイメージしやすい。そう考えたときに頭に浮かんだのが、藤池さんたちのチームでした」(生内さん)
藤池さんは、かつて生内さんが経営していたベンチャーで1年ほど指導を仰いだ傍ら、自らも学生スタートアップの共同経営者兼CTOとして2年間自社サービスを運営した経験がある。しかも2017年にはジシバリという受託開発会社を新たに立ち上げていた。
「藤池さんは大学生の頃からよく知っていますし、以前から一貫してエンジニアリングを通して事業と向き合い続けているところに、自分と相通じるところがあると思っていました。藤池さんが指揮を取っているエンジニアリングチームをマクアケに巻き込むことができれば、お互いにとってメリットがあるのではないかと。そこで、抽象度の高いテーマを共にできるチームとして開発に協力してくれないか、と声を掛けてみたんです」(生内さん)
「メンバーに実績を積ませ、開発力を高めたい」と考えていた藤池さんにとって、恩師ともいえる生内さんからの打診を断る理由はなかった。
「当初はごく一般的な受託開発の依頼だと思っていたのですが、実際には想像以上に深いレベルまで関わらせてもらえると聞き、驚いたのが率直な印象でした。Makuakeはすでにたくさんのユーザーに使われているサービスです。
数多くのトラフィックが集まるサービスでしか得られない知見もありますし、そもそも創業間もない受託開発会社に、これだけの責任ある仕事を任せてもらえる機会はそう多くありません。なんとか成果でお返ししようという意識はどうしたって高まります」(藤池さん)
コンバージョンレートを細かく分析し、数字が伸びればともに喜び、課題が見つかれば率先してアイデアを出して改善策を実装にまで持っていく。一般的な受託開発の業務フローでは見られない動きといえるかもしれない。
「ジシバリに在籍する9名のメンバーのうち、私を含む6名がMakuakeの開発に関わっていますが、『多くのユーザーに愛されているMakuakeに貢献したい』という意識が全員にあります。その気持ちにプロパーエンジニアとの差はないと自負していますね」(藤池さん)
伸び悩んでいるスタートアップと接点を持つのも一つの手
とはいえ当初から順調だったわけではなかった。生内さんは次のように振り返る。
「前例のない取り組みなので、当初は外部のエンジニアを重用することに対して慎重な意見もあったんです。しかし実際にやってみると、最小限のマネジメントで自走可能なチームが開発に深く関わってくれることによって、先日のシェア支援機能のような機能もリリースすることができました。今後、私たちの関係性がどのような形態に発展するか分かりませんが、現状ではデメリットよりもメリットの方が勝っていると感じています」(生内さん)
藤池さんも、自社の経営やメンバーの成長にとって、マクアケとの関わりはメリットがあると感じている。本来であれば自社サービスを立ち上げ、一定の規模にまで成長させなければ得られない技術的知見を吸収できるからだ。とはいえ、一般的な受託開発との違いに戸惑う場面もあったと明かす。
「想定していた見積りよりも開発に時間を要する場合など、スケジュールを優先すべきかアウトプットの質を優先させるべきかで迷うことはありました。でも、自分たちがサービスのオーナーであり、自分たちが書いたコードのライフサイクルに責任を持つという環境に身を置いたことで、『どちらの選択が支援者の皆さんにとって正しいのか』という本質的な判断が徐々にできるようになっていったように思います」(藤池さん)
マクアケとジシバリがこうした取り組みを始めてから約1年。生内さんも藤池さんも、まだまだ改善点は出てくるだろうと見ている。だが、外部の開発リソースをチーム単位で自社の開発体制に取り込む試みは、概ね成功していると言って良さそうだ。
もしエンジニアリング組織の拡大を急務とする企業がこの試みに挑戦するとしたら、どんなことに注意すべきだろうか。生内さんはまず、信頼できる開発チームを見つけるところから始めるべきだと話す。
「私たちの場合は旧知の間柄だということもあって共創関係の構築は比較的スムーズにいきましたが、ごく普通の受託開発会社やSES企業に同様の依頼をしても、うまくいくとは限りません。業務フローや責任の範囲、追うべき目標の捉え方が異なるからです。発注者側と同じ事業目線、もしくは発注者側にはない高度な技術力を持つなど、現状のニーズにマッチするエンジニアリングチームを見つけることが先決でしょう」(生内さん)
もし身近にニーズに合致するエンジニアリングチームが見つからない場合は、どうすればいいか。生内さんは、成長の踊り場に差し掛かっているスタートアップと接点を持つのも一つの手だと言う。
「伸び悩んでいるスタートアップの多くが解散してしまうわけですが、事業と向き合って苦労してきた経験やチームワークは、一朝一夕に得られるものではなく、非常に貴重な専門性です。そしてこの専門性は技術的な専門性に比べて見逃されてしまいがちだし、よくある採用レジュメで表現しにくいから、市場でも見つけにくいんですよね。
そんな経験を持つことが分かっているエンジニアリングチームにチーム移籍のような選択肢を提供できれば、貴重な知見を散逸させることもなくなり、受け入れ側も一定の経験値を持ったエンジニアリングチームを自社のサービスの向上に生かすことができます。双方にとってメリットの多い選択になるはずです」(生内さん)
ただし出会いは偶然の要素が大きく左右する。日頃からさまざまなフェーズの企業と接点を持つよう努力すべきだと生内さんは付け加える。「それは仕事を請ける側も同様」と藤池さん。
「ジシバリを立ち上げる前から、生内さんには開発体制のあり方についての相談を何度も持ち掛けていました。そうやって接点を持っていたからこそMakuakeの開発のお話をいただけたところはあると思いますし、相談できるメンターを持つことによって、思いもしなかった新たな道が開けるかもしれません。仕事を請ける側からも積極的にコミュニケーションを取るよう働き掛けるべきだと思います」(藤池さん)
成長フェーズに入った企業にとって、エンジニア採用やチームビルディングがサービスのスケールを阻むアキレス腱になることがある。マクアケとジシバリの関係を見ても分かる通り、やり方によってはチーム単位で開発リソースを確保することもできるのだ。採用や業務委託だけが開発リソースではないというのは、知っておいて損はない話だろう。
取材・文/武田敏則(グレタケ) 撮影/赤松洋太
RELATED関連記事
RANKING人気記事ランキング
米国優位が揺らぐ?ひろゆき「CPUの進化でGPU神話って崩壊しません?」【AI研究者・今井翔太が回答】
NEW!
表面的なテクニックより「基礎基本の重要性」に気付かされた一冊【Node.js 日本ユーザーグループ代表・古川陽介】
AWS認定資格10種類を一覧で解説! 難易度や費用、おすすめの学習方法も
NEW!
正論モンスター化に要注意!ぎくしゃくしない「ミスの指摘」のコツ【澤円「コミュ力おばけ」への道】
社会で成功するゲーマーに、ひろゆきが聞く「現実世界を攻略できないゲーマーに足りないものって何すか?」
JOB BOARD編集部オススメ求人特集
タグ