3つのステップに分けたフロー
田中氏：企業としては「副業で仕事を依頼してからでないと正社員として採用しづらい」という話も聞きます。企業によって魅力が異なり、それが候補者の方にどう写るかは正直個々の相性次第ではありますが、スタートアップ初期で潤沢な資金がなかったり、潤沢な資金があったとしてもプロダクトや会社が一定成長して成熟した状態で難易度の高い、1から設計/実行するような業務が少ない場合は採用が難しいと思います。
エンジニア採用は他の職種と比較して倍率の高いので採用難易度の高い採用です。弊社はその中で副業の受け入れを上手いことを活用してサービスを伸ばしてきました。
副業で良い人がいたときオンボーディングやアウトプットを出していただくまでの流れなど進め方も重要だと思いますが、いかがででしょうか？
大谷氏：当初、ToBeとAsIsのみを決めて依頼していたところ、やりとりの往復時間がかなりあってタスク解決までが滞ることがありました。そこから徐々にオンボーディングフェーズ、フローを変えていったというのが最初の取り組みでした。
現状は3つのステップに分けることを意識しています。
- ①ウェルカムフロー：契約後、稼働するまでの間の準備やチームメンバーへの紹介など会社の流れに入り込むステージ
- ②ファーストデー：稼働開始日に何をするか。開発環境のsetupから、初週で行うタスクの順番つけ
- ③ファーストマンス：1ヶ月の間で何を進めていくか。メンターをアサインし、タスク着手時の不明点を誰に聞くか明確にしています。
これらを大事にしていて、それぞれ契約の前とか合意が取れた段階で、オンボーディングドキュメントとして公開して可能な限りファーストデー、ファーストマンスの解像度を上げてもらうようにしています。
ファーストデーでは、ドメイン知識を含めた背景説明、スプリントとしてやっていること、チームとしてどういうワークフローでやっているか、バックエンドのストラクチャーの説明や、メンターとしてアサインしている人とのミーティングをしてその人と共にその週で行うタスクを決定する所までを意識してやってます。
ファーストマンスでは、オンボーディングで不足していたところの吸い上げ、最後に1on1を行って終了で、ファーストデー、ファーストマンスの解像度を上げる流れでオンボーディングを進めております。うまくいっている印象があります。
もちろん適宜改善しながらやっています。知識面では私の中だと過去で止まっている部分もあるので、エンジニアリングマネージャーを経験してる方に副業として関わって頂く場合はそのフローを体験してもらって各フェーズの改善アドバイス頂くこともあります。
オンボーディングプロセスを体験してもらって、本業で稼動してる会社での実例を踏まえて意見を言ってもらい、弊社で吸い上げて鋭意改善しています。
▲ 開発合宿の様子
タスクが増えてきたフェーズでは優先順位の整理やチケット準備が重要
田中氏：背景としてAsIs、ToBeで自主性でお任せしているイメージがあります。ただ、AsIs、ToBeだけでうまくいく可能性もありますが、より確度を上げるために活動を続けていった結果今がある感じですね。
オンボーディングのチェック項目、ファーストデーやファーストマンスの項目は自分で考えましたか？
大谷氏：はい、自分で考えました。外部から取り入れたりとかはしていないです。これは非公開です(笑) 公開権限はボードメンバーと開発メンバーですね。
田中氏：自社固有の情報を省いたら、開発者のオンボーディングフローとしてクライアントの皆様に提供しても良いのかなと思いました。
大谷氏：そうですね。
田中氏：現在のオンボーディングフローになる前あれば、業務契約前に先行してNDA結んで対応方法や準備などを副業の方ご自身で考えてもらっていたと思いますが変化などはいかがでしょう？
大谷氏：その場合、タスクの丸投げに近いので最初のフェーズであれば良かったのですが、プロジェクトが複雑化するにつれ背景や概要をある程度把握した上で進めるべきタスクも増えてきており、整理が必要でした。
現状は優先順位や課題に対する背景などが整理できた状態で依頼できていますし、タスクチケットを見てステークホルダーや非機能要件も含めて把握した上で依頼したほうが、受け入れる側としても戸惑いが少なく、仕様理解する上での時間も削減されていますね。今はこの形で良いかなと思っています。
田中氏：こうしたところも副業のタスクの切り出し準備がオンボーディングプロセスも含めて大変で、工数がかかると言われることが多いので、オンボーディングの参考資料として出せたらと。
PMのmini spec起票によってオンボーディングコストはほとんどなくなった
▲mini specのテンプレート
田中氏：「副業で依頼する時、準備が大変。どうしたらいいか迷う」と言われることがあります。
さほど弊社として課題に感じたことがなかったような気がしますが、大谷さんはコスト感・課題意識はいかがでしょうか？
大谷氏：オンボーディングにかかるコストは、日々タスクを切り出していった中でmini specとしてバックグラウンドとか、何を求めてるのかなどなるべく詳細に記載するようにしていました。
JIRAやドキュメントの起票の段階で書いておけば、切り出しや依頼する際のコストはほぼないです。依頼した方が、起票された情報を見て過去の経験や知識をもとにに解釈してソリューションを提供してもらったりもするので、弊社のコストはほぼないですね。
田中氏：mini specを書いてくれるPMの役割が重要で、要件定義、ワイヤフレーム書いたりとか詰めきれない部分がPMではあると思います。
大谷氏：そうですね。要件やワイヤーなどは細かくなくともいいので、ユーザ体験などのストーリーを書き出すことを意識してもらいたいですね。
田中氏：一番最初に話したその役割分担のところに戻りますが、当初はタスク単位だと仕様を詰めきれなかったり、PM側の機能確認が遅延したりしたこともありました。
僕がボトルネック状態な期間が2-3ヶ月あった後に、PMのワークフローを変えてmini specが書かれる状態になってスムーズに回るようになったと感じています。
PMがmini specを安定的に書いておく、一定以上の粒度で整理されているということが副業を受け入れのコストを下げることに間接的に役立ちそうですね。
大谷氏：はい。一番熱い時期に情報を入れておくのが大事ですね。
CTOとしてPMに求めること
田中氏：CTOがPMに求める役割やmini specの使い方についてはどの様に考えていらっしゃいますか？
大谷氏：私の考えですけど、背景知識とやりたいことをベースに書いてもらいたいですね。Tech的な部分やデータフロー的な部分を決めすぎると、話し合った上での合意事項なのか、PM個人の考えで書いたものなのかわからない部分があるんですよ。
ソリューションとして改めて整理した上で出すべき情報もあるので、開発に関わらない部分は書かずに、背景とファクトの部分、機能としてあるべき姿などを最初に書いてあるとやりやすいチケットになると思います。
その他にも、イシュアーは誰なのか、調整必要な部分はどこでどの部門が関連しうるのかを含めて必要なデータがまとまっていればさらにやりやすいですね。
田中氏：企業によってはPMに実装に関する詳細を書いて欲しいという相談をされます。今の話だとユーザー体験の話と実装上の話は別だという理解で良いでしょうか。
大谷氏：ユーザ体験のベストな状態を可視化できていれば、どのように実装されても良いと思っています。
課題のデータ化、洗い出しによって解像度を高める
田中氏：弊社はPO田中の役割が「ビジネス上の目的を達成するために必要なステークホルダーから必要な情報をヒアリングしてタスクを整理すること」です。
その実現のために必要なのは「安定的なプロダクトマネジメントが可能なチームを作ること」です。そこで副業PMにエンジニアやデザイナーとのコミュニケーション依頼し、安定した機能リリースを実現してきました。
他社ケースだとPM と 事業責任者は別でいるケースとか、社長がPM兼務している場合もありますが、ヒアリングからアプリケーションに関するチケット化についてはmini specにユーザーストーリーの詳細を記載、実装面に関することはあまり記載せずにエンジニアやデザイナーに実装内容は任せる。
このような役割分担があればもっと副業エンジニアの方がジョインして活躍していただきやすいのでしょうか？
大谷氏：mini specに解決すべき課題やユーザーストーリーとかプラットフォーム、KPIなどが書かれているほど副業向けのタスクが切りやすいですよね。
田中氏：僕がサイバーエージェントにいた6年前とかはなかった気がしますね。
大谷氏：当時は結構、緩くやっていましたね(笑) 要求定義・要件定義などはあまり実施されておらずワイヤーフレームや絵ベースだし、ホワイトボード使って簡単な機能単位で付箋をぺたぺた貼って「いける！」とかやっていましたね。今のようにフルリモートで要件定義・ワイヤーフレーム作成・デザイン・設計・実装・リリースまでを解決するみたいなのは当時から考えると想像できませんね。
コロナ禍でフルリモートにシフトしても、障害となった部分はなかったので、mini spec含めて課題を全てデータ化すること、エンジニアのオンボーディング含めてフローを洗い出して解像度を高めていったことが結果良い形で進められた要因なのかと思います。
田中氏：今回は副業エンジニアの事例や、オンボーディングなどの話を聞きましたがとても良かったです。
mini specの徹底と、mini specを記載する PM の方々の存在や役割、またスペックに求められるその実装面のユーザー体験をしっかり書いてほしいというところと、大谷さんお手製のオンボーディングドキュメント（Notion）が非常に採用活動含めて大事だと思いました。
今日はありがとうございました。
大谷氏：ありがとうございました。
