ベンチャー・スタートアップフェーズにおける開発メンバーのオンボーディング【イベントレポート】
2019年1月17日、スタートアップやベンチャー企業がHRのナレッジをシェアするイベント「TeamUp Developers LAB」の第１回が南青山にて開催されました。今回のテーマは「ベンチャー・スタートアップフェーズにおける開発メンバーのオンボーディング」。GVA TECH株式会社、株式会社エバーセンス、シタテル株式会社の開発チームを率いる３名が登壇し、各社のオンボーディングの取り組みに関する成功事例や失敗談を語りました。
オンボーディング（on-boarding）とは？
新卒・中途を問わず、新しく採用した人材を組織に慣れさせ、戦力化するプロセスのことを「オンボーディング（on-boarding）」といいます。人材や時間のリソースが限られているスタートアップやベンチャー企業にとっては、新しく採用したエンジニアにいかに早く本来の力を発揮してもらい、会社の戦力となってもらえるかが重要になります。
登壇者紹介
本田 勝寛 氏
GVA TECH株式会社 取締役 CTO / エンジニア
TechCrunch Tokyo2018のスタートアップバトルにて「Microsoft Award」を受賞。CTO of the year 2018 ファイナリスト。北海道大学卒業後、フリーランス、インフラ・ネットワークエンジニア、プログラマーを経験。主にスタートアップにてソーシャルゲーム・アドテク・シェアリングエコノミー領域に携わる。2017年9月、GVA TECH株式会社にCTOとして参画。2018年8月に取締役に就任。AWS Summit、PyConにも登壇。
和泉 信生 氏
シタテル株式会社 CTO / 開発・R&D
2009年に博士（情報工学）を九州工業大学大学院情報工学府にて取得。専門はソフトウェア工学。同年4月から9年間熊本県の崇城大学情報学部助教として教育・研究活動に従事。「市民共働のための雨水グリッドの開発」や「市街地のユニバーサルデザイン支援ツールの研究」などの学術研究を行う。 一方、iOSやアンドロイドアプリを企業と共同開発するなどエンジニアリングを実社会に応用するソフトウェア開発者としても活動。社会活動として、スタートアップイベントのメンターや、ソフトウェア技術者の育成を目指した「社会人若手エンジニアのための逆インターンシップ」「子供向けプログラミング教室」などを実施。2017年4月、シタテル技術アドバイザーに就任。2018年4月、シタテル株式会社入社。*著書 『Unity4マスターブック―3Dゲームエンジンを使いこなす』カットシステム（2013年）
西山 修 氏
株式会社エバーセンス / 開発部 部長
大学を中退後、独学でエンジニアに。その後、青年海外協力隊のコンピュータ技術者として２年間東アフリカのタンザニアで指導にあたる。帰国後はWebエンジニアとしてソーシャルビジネスのスタートアップを経験。 現在は、株式会社エバーセンスでエンジニアとデザイナーを統括する開発部 部長。妊娠アプリ「ninaru（ニナル）」の初代プロダクトオーナーも務め、iOS/Androidのストアでメディカル1位を達成、レビュー平均★4.7+／3万件を超え、妊娠アプリとして絶大なる人気を集めている。２児の父。
「急成長するプロダクトの開発の現場で、CTOが取り組む自律型組織をつくる仕組み〜事業とメンバーが共に成長できるように〜」（GVA TECH株式会社・本田氏）
機械学習を使って契約リスクを判定する「AI-CON」
本田：私たちの開発している「AI-CON」というサービスは、契約リスクを判定するサービスです。契約にどのような条項があり、それがユーザーにとって有利なのか不利なのかを機械学習を使って判別しています。「AI-CON グラフト」という契約書をつくるサービス、「AI-CON ドラフト」という法務局に提出する書類を作成するサービスなどを展開しています。
弁護士だった創業者と私の２人で事業を始めましたが、現在ではエンジニアが12名、デザイナー・コーダーが２名在籍するチームになっています。
オンボーディングの失敗から「自律型組織」を目指した
本田：私たちの場合は、はじめにオンボーディングの失敗体験がありました。「人が足りない」「とにかく人手が欲しい」という理由でスキルに特化した人を採用したのですが、意識を合わせるのが難しいという問題が発生しました。その問題を解消するために、私はマイクロマネジメントに走ってしまい、気が付いたらイエスマンばかりのチームになっていて、自分がいなければ回らないようなトップ依存型のチームができあがっていました。
エンジニアが各自で考えて動いたほうが、それぞれの強みを発揮できると気付いたのはそのときです。それから、「メンタリング」を開始しました。まず、入社後３カ月は１週間に１回、1on1ミーティングを実施するようにしました。もともと飲みニケーションが好きではなかったのも、1on1ミーティングという形を採用した理由です。個人の悩みや組織の改善事項は、1on1ミーティングの機会を利用して解消していくようにしました。
マイクロマネジメントをして失敗した経験から「やり方は人それぞれ」と思うようになったので、1on1ミーティングでは話を聞くこと自体が大切だと思って取り組んでいました。1on1ミーティングで聞いていたのは、「アウトプットはどうだったか？」「パフォーマンスを発揮する上で困っていることはないか？」「チャレンジしたいことができているか？」の３項目です。また、基本的には聞き役に徹するようにしていました。
1on1ミーティングはログの管理が肝
本田：1on1ミーティングを始めた当初は、Macのメモ帳にログを溜めていました。後で見返しても何を書いてあるかが分かりにくいことや、自分だけが見られる状態で本人に共有しにくいことが気になっていました。それらの問題を解消し、ログを管理できるサービスはないか探していたときに、TeamUpを見つけました。
今は、開発組織を対象にした従業員満足度アンケートを月１回、匿名で実施しています。組織の状態を見える化し、バランス良く働けているかどうかを気にかけながら、組織運営を進めています。
「一貫した価値観」のために、開発チームにクレドを導入
本田：採用・育成・評価のために「一貫した価値観」が必要だと考えて、クレドをつくりました。「組織としてどう振る舞うか？」はクレドにすべてまとまっています。その前にも会社自体のバリュー（経営理念）はしっかり明文化されていましたが、バリューはすべての役職で共通のものでスコープが広すぎたので、開発メンバーに特化したクレドを新たにつくることにしたのです。
クレドは、ボトムアップでつくりました。合宿もしましたが、基本的には日にちをあけて、頭を冷やしながら週に３回、1.5時間ずつクレドについて話し合う時間を設けました。みんなで考えてつくったこともあり、現場への浸透は早かったように思います。クレドが固まってからは、「毎日どのような働き方をしているか？」「クレドに沿った行動ができているか？」をそれぞれが認識し、議論できるようになりました。
クレドは採用にも使っています。例えば、一次面接をCTOがおこない、そのあとの１日業務体験で現場のメンバーと顔を合わせると、Slackで「〇〇さんはクレド共感が～」というような会話が流れていることがあります。会話するときや最終意思決定のときも、「クレド」という言葉が自然と出ます。採用フローを通してクレドを浸透させていっているという感覚です。今のところ不満は出ていないので、クレドの運用はうまくいっていると思います。
入社後のキャッチアップを促進する情報共有
本田：入社してからプロダクトについて早くキャッチアップしてもらうために、必要な情報やドキュメントには誰もがアクセスできるようにしています。どうしても属人化しがちな部分も、「誰が何を知っているのか」をわかるようにすることで、自分で調べられるようにしています。
正直言って、現状で十分だとは思っていません。ドキュメントを残すのにもコストがかかります。「どうやってメンバーの負荷を減らすか？」「他のアプローチをとった方が良いのか？」といったことを日々考えながら、試行錯誤しているところです。
ドキュメントの管理には、「esa」という情報共有サービスを使っています。うまくいったことだけでなく、失敗したことや、それによる教訓や反省も残すようにしています。また、日ごろの悩みや日報もesaを通じて情報共有しているので、誰が今どんなことを考えて働いているのかがよくわかります。社長の悩みですら、共有されていますからね。コメント欄で会話や議論が行われ、健全に意見交換できる場となっています。
「ベンチャーフェーズで実現する“急がば回れ”のオンボーディング～全ては組織とプロダクトのコンセプトのために～」（株式会社エバーセンス・西山氏）
３万レビューで高評価、妊婦さん向けアプリ「ninaru」
西山：エバーセンスという会社で開発部部長を務めています。これまでベンチャー企業におけるエンジニアのマネジメントや、プロダクトの立ち上げといった０→１の仕事に携わってきました。エバーセンスの社員数は45名ほどで、少人数の開発組織で複数のプロダクトを手掛けているので、１つのプロダクトをディレクター・エンジニア・デザイナーの３～４名規模で回している状態です。当社のミッションは「家族を幸せにすることで笑顔あふれる会社にする」、バリューは「エバーセンスのみんなが笑顔になる」です。
私たちが提供している「ninaru」は、妊婦さん向けのアプリです。時期に応じてメッセージや記事が届き、妊婦さんが必要な情報を効率よく手に入れることができるものです。AppStoreとGoogle Playを合わせて３万件以上のレビューがついており、高い評価をいただいています。
私は「ninaru」の立ち上げに関わったほか、いくつかのプロダクトのPO（プロダクトオーナー）を務めています。私自身も２人の子どもがいますが、「ninaru」のような価値あるプロダクトを仲間と生み出すことにやりがいを感じています。
「〇〇エンジニア」という肩書きがない
西山：みなさんに今日お伝えしたいのは、「うちのエンジニアメンバーはすごい」ということです。何がすごいのかというと、「〇〇エンジニア」という肩書きがないことです。アプリエンジニア、インフラエンジニアといった区別はなく、エンジニアメンバーの大半がネイティブ・サーバサイド・インフラのほとんどの領域の開発経験を持っています。
以前、各領域の業務経験について「半年以上の経験がある」「自信はないけどやったことはある」といったグレードを付けてもらうヒアリング調査を実施したときに、各メンバーがどの分野も８割程度はできる状態にあることが判明しました。実はこれは、最初から全部できる人を採用しているわけではなく、みんなで勉強した結果です。当社に勉強する文化が根付いているからです。
採用で大事なのは、ビジョン共感と「一緒に働きたいか」
西山：勉強してスキルアップできる環境があるとはいえ、「採用」は大事です。なぜなら、いくら環境が整っていても、誰もがこれを実践できるわけではないからです。私が最も重視しているのは、ビジョンへの共感です。ビジョンに共感していれば、技術力は二の次です。あるに越したことはありませんが、足りなくても構わないということです。
高い技術力よりも高いポテンシャル、「これから頑張ってくれそうか？」「一緒に働きたいと思えるかどうか？」の方が大事です。なぜなら、「一緒に働きたい」と思えない人の人生を良くしたいとは思えないですから……。
他の技術領域にも積極的にチャレンジさせる
西山：例えば、今２名のインフラエンジニアがいます。どちらも面接時にはアプリ開発経験はありませんでしたが、やってみたいという意欲があったので採用しました。１つの領域でしかキャリアを積んでいなくても、他の領域に挑戦したいのなら、そちらを優先してやってもらうようにしています。
入社後は必ずメンターをつけ、研修期間も必要があれば１カ月くらい取ってしっかりやります。長期的に見れば、それだけの価値があると判断しています。インフラ業務からアプリ開発へ移るといったローテーションも積極的に行っています。これは業務を属人化しないためでもありますが、本人がやりたいことをやれる環境をつくりたいという思いからです。ですから、基本的には本人の希望を優先しています。
「いいヤツ」を集めるから「いいプロダクト」が生まれる
西山：「サービスの企画をしながら開発もする」というのが、私たちの開発スタイルです。サービスの機能や私たちの取り組みについて誰もが意見を言えるし、「意見を言いたい」と思うような組織にしたいと思っています。
なぜ、このような開発チームを目指すようになったのか。それは、「良い仲間がいて、みんなで成長するから、良いプロダクトが生まれる」と信じているからです。論理的ではなく、エモい話なのですが……（笑）事業の成長と同じく、仲間の成長にもコミットできる「いいヤツ」を選んで採用することで、良いチームができると考えています。
「チーム全体での相互補完で実践する“リモート×オンボーディング”」（シタテル株式会社・和泉氏）
誰もが自由に服を生産できるサービス「シタテル」
和泉：私は、４月にシタテルのCTOに就任しました。それまでは大学で10年間ほど教員をして、Unityを触っていました。シタテルは、誰もが自由に服を生産できるようにするサービスを展開している会社です。
服の仕立てにはさまざまな人がかかわっていますが、生産拠点が海外に移されたりするなかで、縫製工場などは仕事が減り苦しくなっている状況があります。また、服をつくりたいという人が請け負ってくれる工場を探せず、新規参入しにくい業界でもあります。私たちはそのような工場とデザイナーやアパレルブランドをつなぐネットワークを持っています。最近では、会社のユニフォーム制作などの案件も増えています。
リモートでオンボーディングを実現する仕組みとは？
和泉：現在シタテルには60人ほどの社員がいますが、そのうちエンジニアとデザイナーは16人です。熊本と東京に拠点があり、ファーストコンタクトは熊本（本社）で受けていますが、営業や工場対応の部署は東京にあります。エンジニアは熊本と東京に分かれて在籍しているので、リモートで開発できる仕組みが必要でした。開発チームは熊本と東京を合わせて、現在４つ。各チームが２週間でスプリントを回して開発を進め、最後に「何をしたのか」をそれぞれ発表する機会を設けています。
Slack上に「firefighter（消防士）」というチャンネルを開設していて、困ったことがあればいつでもこのチャンネル上で誰かに聞いて、すぐに解決することができます。また、それぞれが得意な分野についてアドバイスし合うことも少なくありません。もとは炎上案件が発生したときのために開設したチャンネルですが、今では営業部門や生産部門と開発部門が頻繁に議論やフィードバックをしあう場になっています。遠隔地にいても、隣で仕事をしているような感覚ですね。
入社後のオンボーディングのポイント
和泉：東京と熊本どちらで採用したとしても、入社後に必ずもう一つの拠点に行くようにして、拠点間交流を図っています。また、１日目からフラストレーションを抱えないように、開発環境の初期セットアップのためのドキュメントはしっかり整備しています。採用する人のなかには業務委託などスポットで入ってもらうメンバーもいますが、社員と同じように扱っています。
当社では週２日のリモートワークが許可されています。リモートワークに関するルールづくりは開発チームで行っていますが、ルールをつくるときに議論された内容をSlack上に残しているので、新しく入ってきたメンバーも「どうしてこのようなルールなのか？」がわかるようになっています。また、ルールをつくるときには改定方法も一緒に定めるようにしています。例えば、「３割の人が改定したいと言ったら改定する」といったようなことです。
オンボーディングの成功で「離職率ゼロ」
和泉：リモートワーク中に困ったことがあれば、すぐに画面をつないで通話し、解決できるようにしています。業務委託のメンバーなど週３日だけ稼働するような人もいるので、そういった人たちが困らないように、ドキュメントを揃えたり情報共有を頻繁にしたりもしています。
依頼内容（Issue）に書かれていない開発部分に関しては、自分で自由に決めていいということにしています。それで失敗しても、問題としては扱いません。ただし、その方法を変えたほうがいい場合は変えますよ、というように運用しています。今のところ離職率は０なので、オンボーディングは成功していると思います。
小さなことでもCTOが間に入って解決する
和泉：以前あった問題としては、社員から業務委託の方へのレビュー内容について、悪気はないけれど厳しすぎたという問題がありました。そのときは、すぐに私との1on1ミーティングを設定してそれぞれの思っていることを引き出し、お互いの認識の齟齬がないように間に入りました。小さなことでも問題が発生しそうであれば、すぐに間に入るのもCTOの仕事だと思っています。
また、接し方としては各自の意見を尊重するようにして、トップダウン型の組織にならないように気を付けています。経営者の議論であっても、現場に落とせるものはなるべく公開します。また、自律性や自主性を阻害する可能性のある権力者の発言は、全力で修正しています。評価については、リクルート出身の人事が自分で成し遂げることを宣言する「ミッションシート」をベースにした評価制度をつくったので、それを半年に1回実施しています。
まとめ
各登壇者の発表の後、イベント参加者からはより踏み込んだ質問がなされ、スタートアップやベンチャーフェーズにおけるオンボーディングについて活発な意見交換がなされました。「TeamUp Developers LAB」は今後も開催される予定なので、興味がある方はぜひ次回参加してみてください。
