プレイドが自律・分散型チームをつくる上で大切にしたコト|#9 プレイドCPO柴山氏|TECH TEAM BUILDERS

Webサイト訪問者やアプリ利用者の行動をリアルタイムに解析し、1人ひとりに合った体験を提供するCX(顧客体験)プラットフォーム「KARTE(カルテ)」。パーソナライズされた顧客体験を実現するサービスとして、ECだけでなくさまざまな企業の顧客接点で導入・活用が進められています。そんなKARTEの開発を担う株式会社プレイドは、エンジニアの採用基準と開発組織の運営方針の面で、他社とは一線を画しているといいます。『TECH TEAM BUILDERS』第9回目は、独自の手法を貫く背景と効果について、同社の創業者であり取締役CPOを務める柴山直樹氏に聞きました。

株式会社プレイド
Co-Founder / 取締役 CPO
柴山 直樹氏

1982年生まれ。東京大学工学部にて神経科学、チューリッヒ工科大学にてロボティクス、東大大学院にて分散環境における機械学習の研究に従事。2009年「未踏ソフトウェア創造事業」採択。2013年同大学院博士をドロップアウトし、プレイドにCTOとして参画。2019年からCPO(Chief Product Officer)。
https://www.wantedly.com/id/nashibao

プレイドに優秀な人材が集まる理由

プレイド 柴山

——本日はお時間をいただきありがとうございます。早速ですが改めて柴山さんの現在のお立場から聞かせてください。

2013年に入社以来、5年にわたりCTOとしてプロダクト開発を担ってきました。2019年からはCPOとして、プロダクトの成長に責任を負っています。主な職務は、プロダクトのあるべき姿を構想し成長戦略の指針を定めること。各プロダクトの特性や市場動向、コストを勘案しながら、プロダクトグロースさせるのが私の責務です。

——現在の開発体制を教えてください。

KARTEをはじめとするサービスの開発を担うのは「Product Division」という組織で、所属メンバー80のうち50名がエンジニアです。エンジニアたちは、同じDivisionに所属するデザイナー、プロダクトマネジャーたちと3名から7名までのユニットを組み、担当するプロダクトの機能開発にあたります。ユニットの開発テーマやメンバー構成は状況の変化に合わせて2~3ヶ月程度で見直し、開発組織の硬直化を防いでいます。

——創業当初はどのような手段でエンジニア採用に取り組んでいらしたのでしょうか?

2013年にKARTEの開発を開始して2015年にリリースし、2~3年ほどは、リファラル採用が中心。具体的には私の知り合いや関係者からの紹介、もしくはWantedlyで当社の存在を知ってくださった方から採用することが大半でした。

——御社の採用基準を満たすエンジニアの条件を教えてください。採用においてはどのような点を重視されていますか?

もっとも重視しているのは目的志向の強い人物かどうか。そのため面接では、柔軟性や学習意欲の高さ、真面目さ、前向きなマインド、地頭の良さ、協調性がどの程度あるかを見極めるようにしています。開発経験や経験年数はあまり重視していません。

——エンジニア採用の現場では、開発経験や経験年数を重視する企業が大半です。なぜ実績よりも素養を重視するのでしょうか?

もちろんエンジニアリング経験を評価しないわけではありません。かといってエンジニアとしての経歴やスキルだけで採用することもないということです。私たちは成熟産業に属する企業ではなく、未知の領域を開拓するスタートアップ。「このスキルセットがあれば必ず勝てる」という方程式があるわけではないので、自分たちで「勝ち筋」を見出していかなければなりません。プレイドが掲げる「データによって人の価値を最大化する」というミッションは不変でも、取るべき手段やアプローチは状況によって変化します。事業ミッションという抽象性の高い目標を視野に入れつつ、変化に対応し続けられるエンジニアには何が必要か突き詰めた結果、次の素養が重要だという結論に至りました。目的志向や学習意欲の高さ、これらを構成する柔軟性や真面目さ、前向きなマインド、地頭の良さ、協調性などです。

プレイド 図版

必要な技術は必要なタイミングでキャッチアップすればいいという考えが生まれた背景には、創業当初、プレイドにはWebサービスの開発経験があるメンバーがいなかったことが挙げられます。だからこそ過去の経歴よりも目的志向や学習意欲の高さを重視する採用方針が根付いたんです。

——確かに変化を前提とするなら、表面的な経歴よりもより本質に近い素養を重視するのも頷けます。しかし優れた素養を持つ人材は引く手あまた。なぜプレイドには優秀な人材が集まるのでしょうか?

工夫しているのは、難題を解くことに集中してもらいたいのでできるだけ高い給与水準を維持し、働く環境を整えることに注力しています。資金が必要な取り組みなのですが、幸い私たちの主要プロダクトであるKARTEは、比較的単価が高いBtoB向けのSaaSです。おかげさまでサービスも順調に成長しているので、得た利益を惜しまず人材や環境に投資することが可能です。

また、KARTEのプロダクトとしての品質や、バックエンドのスケーラビリティ可能性に興味を持ってくださっているエンジニアに対しては、プレイドのプロダクトビジョンドリブンな姿勢、社風を知っていただくため、あくまでプロダクトという実体を軸にビジネス戦略を語るようにしています。優秀なエンジニアは一般的に成し遂げたい理想が高いものです。「ここで一緒に優れたプロダクトを創り、自己実現につなげたい」という気持ちを刺激するよう、常に心がけています。

——優秀な人材が集まるのは給与や待遇の魅力だけではないわけですね。

もちろんです。人間の欲求を5つの段階で表した「マズローの五段階欲求説」でいうところの、もっとも高度な「自己実現欲求」を、仕事の面白さや優秀な仲間、プロダクトや会社の成長によって刺激するイメージです。自己実現欲求の下位に分類される、承認欲求、社会的欲求、安全欲求、生理的欲求などを目的とさせず、単に満足させるために人や環境への投資を過剰に行っていると考えていただくとわかりやすいかも知れません。

「レアルマドリードスタイル」の限界と可能性

プレイド 柴山

——創業期から現在までの変遷をご存じの柴山さんから見て、プレイドの開発カルチャーはどのように映っていますか?

エンジニアが15名を超えるまでは、自分たちの開発組織をスペインの名門サッカーチームになぞらえ、内部では「レアルマドリード」スタイルと表現していました。細かなすりあわせをしなくても意思疎通が図れ、連携プレーができる優秀なメンバーが揃っていたからです。もともと役職にこだわりのないメンバーが多く、ミドルマネジメントの必要性を感じる場面もなかったため、複雑な階層構造をつくる必要はありませんでした。メンバー全員がリーダーシップを持っていることが前提。そのため、キックオフミーティングの際に、左上に名前が書かれた人がリードを取るというような、ふわっとした決め方でも問題ないですし、仮にリードが途中で入れ替わっても組織はうまく機能します。これらの特徴は創業当時からいまもあまり変わっていない開発カルチャーと言えます。ただ、ずっと変わらなかったかというとそうでもなく、エンジニアが増えたことで修正を加えた部分もあります。

——エンジニアが増えたことで、変えざるを得なかったのはどのような点でしょうか?

2016年以前は、制度らしい制度やサポート体制がほとんどなく、入社したばかりのメンバーから「砂漠のようだ」と指摘されたこともありました。それでもうまく機能したのは、メンバーの優秀さもさることながら、人数が15名程度と少なかったから。その後、事業フェーズが変わるたびに検討すべき課題が増え、次第に組織の全体像を掴みづらくなってきたので、2017年に、現在のユニット制を導入。チームのダウンサイジングを実施しました。さらに必須ではなく、ユニットごと形も様々ですがデイリー、ウィークリーでリズムを作るようなMTGを行うなど細かいチューニングを実施。増員により停滞気味だった開発組織にリズムとキレを取り戻せました。さらに2019年には、CTOの直下に「Dev Planning」というチームを設け、開発項目の優先順位付けや課題解決に適任なメンバーをアサインする機能を持たせたところ、プロジェクトの動き出しがさらにスムーズになりました。それ以降、自由度が高い開発カルチャーを維持できているのは、現場に裁量を与えることでエンゲージメントを高めつつ、最低限の統制でバランスを取るのに必要なさじ加減がわかってきたからだと思います。優秀な人材を増やすだけでは、柔軟性に富んだ組織を維持するのは難しいようです。

——いかに優れたメンバーが揃っているとはいえ、ユニットに判断を委ねると解釈にブレが出たり、サービスの品質が担保できなくなったりする危険はありませんか?

アウトプットの品質に差が出ることはあります。もちろんマネジメントコストをかければ「失敗しない組織」はつくれるでしょう。でもその結果、手にするものが、ごく平均的な成果を出し続ける平凡な組織なら、対価に見合うだけの価値があるといえるでしょうか。もちろんビジネスやサービスの根幹を揺るがしかねない失敗避けるべきです。ただクリティカルな問題は毎日発生するものではありませんし、事前に把握していれば準備も回避もできます。アウトプットのブレについても、大きな問題になる前に是正すればいいだけの話。滅多に起こらない大失敗を恐れるあまり、マイクロマネジメントを走らせるのは、エンジニアのコミットメントやエンゲージメントを低下させ、ひいてはプロダクトの成長力を削ぐことになりかねません。こうした考えから、プレイドのなかに失敗を許容するカルチャーが生まれました。私たちは小さな失敗を避けるよりも、果敢にチャレンジして想定を大きく超えるような成果を出してくれるエンジニアやチームにこそ、価値があると考えています。

プレイド 柴山

自律・分散型組織をつくるためのポイント

プレイド 柴山

——優秀なメンバーの存在と彼らの能力を最大限に引き出すことが、開発カルチャーの基盤にあることがわかりました。こうした組織を作り上げるために参考にした事例などがあれば教えてください。

プロジェクトによって毎回チーム編成が異なる外資系コンサルティングファームの動き方や、スクラム開発手法、チームとして学び合い協力し合う学習型組織など、「組織力」や「柔軟性」を高めるさまざまな施策を取り入れています。しかし、特定のフレームワークをそのまま社内に持ち込んだことはありません。別の要素と組み合わせたり、主要なポイントだけを抜き出したりして活用するのがほとんどです。またフレームワークが行動や物事を判断する際の制約にならないよう、独自の名前を付けるといった工夫をしています。自分たちがフレームワークのオーナーであるという自覚を持ってほしいからです。

——プレイドの開発体制を象徴するフレームワークをご紹介いただけますか?

Product Divisionで「フォーカス」と呼び習わしているフレームワークが代表的なものです。このフォーカスとは、現時点の状況や優先度に基づいて、Product Divisionとして集中して取り組むと決めたテーマとチームアサインを指し、2~3ヶ月という短いスパンで見直しを行っています。テーマは比較的抽象度の高いものが多いですがプロジェクトの方向性や方法論を選ぶ際の基盤となる考え方で、プレイドの開発スタイルの中核をなすもの。細部にわたって厳格なルールを定めるというより、ある程度の「ゆるさ」を許容しているのが特徴です。なぜゆるさを加味しているかといえば、個人の裁量を認めつつ、変化にも柔軟に対応したいから。このフォーカスが開発環境の目安になっているからこそ、プレイドは自由と柔軟性、成果をうまくコントロールできると考えています。

プレイド 柴山

——ほかに最適な組織構築のために心がけていることはありますか?

2018年からは組織のケイパビリティを充実させるため、採用の前提条件を一部改め、セキュリティや個人情報管理など、特定分野に尖った知見を持つプロフェッショナル人材を採用できるようになりました。プロダクト開発の根幹を担うコア人材が組織全体にいき渡り、多様な人材を受け入れられる状況になったからです。基本的にエンジニアの採用は「いい人がいれば採用する」というスタンスなので、大量採用による開発カルチャーの混乱もありません。抑制気味の採用方針も、結果的に自律・分散型組織を築く上でいい影響を与えていると思います。

——今後、開発組織をどのように発展させたいとお考えですか?

2020年12月に東証マザーズへの上場を果たすまで組織を成長させることができました。今後は、収益基盤を盤石なものにしつつ、海外を含めた新たな市場の開拓に力を注いでいくつもりです。むろん開発組織もそれに応じて順次拡大していくことになるでしょうが、SaaSビジネスの特性上、仮にプロダクトの売上が指数関数的に成長しても、同じペースで人を集めることはできません。当面は組織の生産性を高めながら事業の成長を支えていきたいと考えています。

成長志向の強い人材を獲得するためにやるべきこと

プレイド 柴山

——リソースの乏しいスタートアップがエンジニア採用を成功させるために何をすべきでしょうか。アドバイスをお願いします。

一口にスタートアップといってもそれぞれ状況は異なるので、最適解は自分たちで模索すべきです。それを前提に申し上げると、リソースがなくてもできる施策は2つあります。1つはプロダクトを徹底して磨くこと、もう1つは成長の伸び代がある才能ある人材を正しく見極めて採用することです。とくに誇るべきものが少ないスタートアップにとってプロダクトは想像以上に雄弁です。「エンジニア採用を成功させるためにプロダクトを開発する」くらいの意気込みで取り組んでも、やり過ぎとはいえません。さらにベンチャーキャピタルに提示するピッチ資料と同じくらいの熱量で、エンジニア採用に的を絞り、これから何をどのように成し遂げたいのか、技術、ビジネスの両面から伝えられれば、きっと目的志向が強く、成長意欲の高い人材の関心を惹けるでしょう。お金がなくてもできることは少なくありません。

——素養あるエンジニアを見極めるポイントがあれば教えてください。

話を引き出す技術はいるかもしれませんが、聞き手が興味を持つ話題を察して、それをわかりやすく伝えられる人は、総じてロジカルですし、協調性が備わっているように思います。経験に根ざしたリアルで興味深い体験談を話せる人も同様です。私が面接する際、その方がやりたいことや、過去の経験を掘り下げて聞くのは、そうした話から応募者の考え方や素養を知りたいからなんです。成長力の高い人材を見つけたいなら、過去の実績や経験年数を絶対視せず、生身の人間として接してみるべきでしょう。こうした採用基準を持っているスタートアップは、私の知る限りあまり無いので狙い目だと思います。

<柴山氏推奨。シード期、アーリー期の技術責任者にお勧めする情報源>

「チームが機能するとはどういうことか」(Amy C. Edmondson著)
学習と実行をしっかり切り分けて組織にインプリするための、基礎的な思考が身についた気がします。自分の組織を考える上でのベースになっていると考えています。

 

「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」(Jeff Sutherland著)
インタビューでは既存フレームは壊す前提の話をしましたが、一般的なフレームとその考え方を知るための古典として良い一冊だと思います。開発に限らず全てのチームで参考にしています。

 

Microservices
Defining the microservices architectural style by describing their nine common characteristics

「Microservices」(James Lewis/Martin Fowler)
開発チームは開発フローと切り離せず、開発フローはシステムとコードの分離方針と切り離せないため、数十人のフェーズからはMicro Serviceは深く理解しておく必要があると思います。解釈と適用にばらつきがあり、また完全でもないないので、原著を自分たちの組織に合わせて咀嚼出来ると良さそうです。

著者プロフィール

武田敏則

Writer

株式会社グレタケ代表取締役ライター。デザイナー、広告制作ディレクター、情報誌編集長などを経て2006年に独立。 ウェブ、雑誌、書籍のインタビューライター兼編集に。経営、ビジネス、採用、テクノロジーの裏にあるエモい話が好物です。

タイトルとURLをコピーしました