※本記事は2019年2月に公開された内容です。

「ワクワクを、すべての人に」というミッションのもと、日本最大級の遊びのマーケットプレイス「asoview！」を運営しているアソビュー株式会社。その他に、非日常の体験をギフトとして贈る「asoview!GIFT」や、レジャー施設向けのオンライン予約・チケット販売管理システム「satsuki」などのサービスを手掛ける一方、100を超える自治体や官公庁と組んで地方創生や観光観光産業の成長を目的としたコンサルティング事業にも取り組んでいます。

同社のCTOを務めるのは、リクルートライフスタイルにおいてホットペッパービューティーをはじめとする数々の事業の開発責任者を務めた山崎さん。現在アソビューにおいてどのような開発組織を作り上げているのか、またリクルート時代の開発体制改革についてもお伺いしました。

日本とベトナム、海を隔てた2拠点での開発をスムーズにする秘訣

御社のエンジニア組織の体制について、概要をお教えください。

山崎：アソビューのエンジニア組織は２拠点あり、国内に30名、ベトナムのオフショア拠点に20名ほど。総勢50名弱のプロダクトメンバーです。一般的にオフショアというと、日本で要件定義した案件を受注する下請け的な動きが多いのですが、当社の場合はベトナムの拠点においても日本と同じ案件を一緒に進めて、なるべく当事者意識を持って開発をしてもらえるようにチャレンジしています。
そのために大事にしているのはお互いが信頼関係を築くことです。コミュニケーションのベースを醸成できれば、特に抵抗感なく案件を進行できます。その一環として、日本とベトナム間で毎月交換留学のような形でメンバーが行き来していて、先日もベトナムのメンバーが1週間日本に滞在していました。僕自身も、先月ベトナムに赴きましたよ。
開発はGitで管理して、会話はすべてSlack。会議はappear.inのようなテレビ会議システムを使用します。言語と距離が違うだけであとは同じ、という感覚で進めているんです。

開発の具体的な流れはどのようなものなのでしょうか。

山崎：運営サイトごとにプロダクトオーナー自体を決めてアサインしていますが、エンジニアがプロダクトオーナーになっているケースも珍しくありません。
技術選定などはメンバー同士で話し合いながら決めていきます。当社は基本的にはJavaを扱っていますが、新しいプロダクトでは新しい技術にチャレンジしようという方針があり、GoやPythonで製作しているツールもありますね。
新しい技術を学ぶためにエンジニアの自発的な勉強会が週に2回ほど行われていますし、外部の勉強会への参加は会社として奨励しています。外部で得た知識は勉強会で社内にフィードバックするサイクルで、技術を磨き上げる環境が構築されています。

50名弱のエンジニア組織ということで、どのような人事制度を採用していますか？

山崎：スタートアップのベンチャー企業ですので、大手企業のようなしっかりと整った制度ではありませんが、等級・評価・報酬制度を始め、基本的な人事制度があるに留まっていました。現在はプロダクト側の人事制度を見直すためのタスクフォースを動かしている最中です。
リモートワークや副業の推進、土日以外にも休みを取れる制度の導入など、多様な働き方を受け入れていこうとしています。
特に休日制度については、遊びを提供する会社として「社員もワクワクする」ということをテーマに考えたときに、人が多く混んでいる土日以外にも休めた方がいいだろう、という発想から生まれました。

企画者不在の組織。エンジニアがプロダクトの価値創造まで担う

アソビューならではの開発手法としてはどんなポイントが挙げられますか？

山崎：大きく言うと２つあります。一つは、社内に企画者がいないこと。アジャイル的にデザイナーやエンジニアがユーザーストーリーを構築し、どんなプロダクトを提供したら一番いいのかという価値創造まで行うのが特色です。エンジニアが企画もできるという状態ですね。
もう一つは、DDDを開発に強く採り入れていることです。DDDとはDomain-driven design、ドメイン駆動設計と呼ばれるエリック・エヴァンスによる海外発の設計概念です。ざっくり言うと、事業をドメインごとに分類した上で、営業、経営、開発、すべてのメンバーが共通言語を使用し、その共通言語をソフトウェアの中にも表現していくというものです。どちらかといえば事業会社の進め方の概念に近いですね。
例えば「お店」という言葉があったときに、人や会社によっては店舗やストアと表現するなど、物事の表現はブレてしまいます。そこを社内で「お店」という名前に統一する。さらにお店というものがどういう概念を持つものかを言語化し、ソフトウェアやクラス設計の中にも「お店」が階層としてきちんと表現されるようにする、というイメージです。

事業の失敗を期に、ビジネス・マネジメントを磨く道を選択

山崎さんの個人的なキャリアについて教えていただけますでしょうか？

山崎：１社目は大手企業のSIerとしてスタートし、通信設備のソフトウェア開発に従事していました。
エンジニアにありがちではありますが、だんだんSIとしてではなく事業に責任を持ったエンジニアとして働きたいという意志が強くなり、Yahoo！JAPANに転職。
当時はヤフーオークションが国内ECのトップだったので、ヤフオクにかなりの人員がアサインされており、僕自身もヤフオク本体のほかに自治体や財務省向けのオークションといったさまざまなサービスの立ち上げに携わりました。

3社目は知人に誘われたベンチャー企業です。大手クーポンシステムの開発やオウンドメディアの製作などを行っていたのですが、上手く軌道に乗らず失敗を経験しました。エンジニアとしてものをつくることには自信があったものの、サービスを世に送り出すことには失敗した。そんな自分を振り返りエンジニアとしての人生を考えたときに、「ビジネス・マネジメントや市場に価値を届けるためのスキルを学ばなければだめだ」と感じて入社したのが、4社目のリクルートです。ホールディングス化した後は分社化したリクルートライフスタイルで、当初の要望通り開発マネジメントやビジネスサイドに近い働き方をさせてもらえました。
具体的にはホットペッパービューティーやホットペッパーグルメ、ポンパレモールなどの開発責任者を担い、マネージャーも経験。さらにリクルート全体のQAチームの立ち上げや独自のインフラ構築、ビッグデータの基盤マネジメントなども行いましたね。
6年弱の間でビジネス、マネジメント、さらには組織の立ち上げに至るまでも色濃く学ぶことができたので、もう一度ベンチャー企業で自分の力を活かし、最終的に何か大きな課題を解決できる人物になれればと思い、アソビューに入社を決めました。

アソビューは2018年の1月にCTO候補として入社し、7月にCTOに就任しています。現在は人数が少ないのでコードレビューなどの技術的な作業も行っていますが、本質的にはビジネスの中長期的目標に対して、開発組織をどうスケールしていくかという部分に責任を持ちたいと思い取り組んでいます。

大規模なエンジニア組織における技術責任者の「権限委譲」の重要性

リクルート時代は500～1000名規模のエンジニアをマネジメントされてきたそうですが、大規模なエンジニア組織を統括するためのポイントを教えていただけますか？

山崎：基本的に人数が増えると自分の目が届かなくなるということが前提になるので、一番大事なのは「どのような形で権限委譲するマネジメントパスを作るか」という点です。CTOは技術の最終責任者ではありますが、技術の一番のスペシャリストであろうとすると、人員が増えた際に必ず限界がきます。技術について一番詳しいのは現場のメンバーだということを、まずは自分が納得する。技術的なイニシアティブは他者に委譲することが必要なのです。

実際、リクルートで500名以上のエンジニアを見ていたときは採用も行いましたが、コーディングテストなど技術的な見極めは技術的なリーダーであるテックリードに権限委譲していました。僕自身は最終面接に近い段階で地頭の良さや成長の伸びしろの有無、カルチャーマッチなどの部分を見ていましたね。

当時は開発組織の内製化も進められたそうですが、その点についても重視すべき部分をお伺いできればと思います。

山崎：まずは、何をもって内製化と定義するかという問題があります。同じオフィスにいるだけでいいのか、意志を持って開発をマネジメントするところまで踏み込みたいのか。後者であれば、何のためにそうしたいのかを言語化する必要があります。極端な話、資金が無尽蔵にあれば大手のSIerに仕事を発注してしまうのが一番確実です。そこをコストリダクションしたいなど、何か目的があるからこそ内製化を目指すはずですよね。内製化自体が目的ではないので、何を得たいのかが重要です。

同じような例を2つ挙げます。
1つは開発手法として、最初に要件を定義してから開発に落とすウォーターフォール的なやり方は世の中的には古い、良くない手法として見られる傾向がありますが、必ずしもすべてが悪いのではなく、ウォーターフォールが適している場面も当然存在します。そういった可能性を検討せずに、単に細かいことを先に考えたくないというだけでアジャイルにして開発を進めるのは非常に危険です。
もう1つの例はビッグデータ。近年の流れからビッグデータをやりたがるエンジニアはたくさんいます。好奇心で興味を持つのは悪いことではありませんが、ビッグデータ自体は非常にお金がかかるものなので、事業のサイズと会社の規模感、そしてその中で何をやりたいのかということを要件定義せずに技術ファーストで進めると、必ず失敗します。
同じように課題を明確にしてからでないと、内製化も上手くいかないのです。

戦略的パートナーシップが大規模エンジニア組織の管理を可能にする

内製化の話に関連して、リクルートにおいて社外発注主体から内製化へ改革した際の状況と、改革の内容についてお教えいただけますか？

山崎：当時、リクルートはエンジニアが仮に500名いたとしたらそのうち450名は業務委託という状態でした。Webメディアに対する投資が拡大する中で開発スピードを最大化するため、開発部隊の内製化と常駐化、開発管理社員の配置などを行ったのですが、それではパワーが足りなかったので、優秀なエンジニアをさらに大量に採用することにしました。
ただ、分母が増えると、誰かが辞める、誰かを増やす、誰かと誰かが合わない、そういったことのすべてをマネジメントするのが非常に困難になる問題が発生しました。解決したい課題をまとめると、以下のような内容です。

解決したい課題
課題１：やりたいことをやるための物理的パワーが足りない（人数の問題）
課題２：人数を増やしても管理に限界がある（組織の問題）
課題３：大人数で案件をまわすフローが策定されていない（仕組みの問題）

課題2の部分において、開発管理専門社員に過負荷がかかっている状態を解消すべく、選定観点を満たしたいくつかの中小規模のソフトウェアハウスさんと戦略的パートナーシップを結び、出島のようなものをリクルート社内に作ることにしました。機能やプロダクト単位で責任と権限を切り出し、各パートナー会社をアサインしていく形です。これによって、構造は以下のように変化しました。

パートナーが作り上げた組織内の活動においては裁量権を渡します。採用を行うのも自由です。パートナー側には客先において人員育成ができ、自分たちで代謝していける組織づくりが可能になるという点でメリットがあります。その代わり、組織における責任は自分たちで担保してもらい、新人教育や優秀な人を定着させるための努力もしてもらうという、健全な関係性ができあがりました。僕は各社のトップと話すだけでいいので、管理も容易になり、一気に人数を増やすことができたというわけです。課題1と2の解決です。

課題3 「大人数で案件をまわすフロー」としては、どのような仕組みを作ったのでしょうか？

山崎：いろいろありますが、基本的には僕のような開発責任者やエンジニアメンバーが、ビジネスサイドに対して自分たちのコップの量、すなわちキャパシティを提示するようにしました。突発的な案件でコップが溢れてしまうとビジネスは成長しないので、ビジネスの中長期的な視点で重要な案件からコップの水を満たしていき、余った容積で手近な案件をこなしていく、というフローを策定したのです。

そのフローは可視化して、ビジネスサイドも現在のコップの水の量を見られる状態にします。さらにコップの中に入っている案件は進捗を可視化して…という仕組みによって、すべての課題解決を図りました。

〜編集部　後記〜

大規模なエンジニア組織から、ベンチャー企業CTOとしてご活躍される山崎さん。ご経験に基づいた開発組織構築の貴重なお話有難うございました！

技術顧問の副業案件を詳しくみてみたい方は下記ボタンからご確認ください。