企業フェーズで変化していった副業受け入れ体勢
田中氏：本日はOffersを一緒に立ち上げたoverflowのCTO 大谷さんと私で、副業エンジニアの受け入れ方法や依頼してきた仕事内容、副業前提の開発組織の作り方についてざっくばらんにお話しできればと思います。よろしくお願いします。
大谷氏：紹介に預かりました大谷と申します。現在overflowの立ち上げから携わって4年目になります。現在の責務としては開発全般を見ており、エンジニアメンバーのマネジメントや、アーキテクチャの 設計や構築、インフラ周り、データサイエンスの架け橋、機能実装含めて「何でも屋」な動きをしています。
田中氏：よろしくお願いします。早速1つ目の話題ですが、僕らは副業を受け入れを柔軟に行い、いろいろなプロダクトの立ち上げを経て、開発立ち上げ期から運用のフェーズに移行していますね。
そもそも副業のエンジニア、デザイナー 、PMを受け入れていくのが難しいといった話を聞くので、まずは背景などお話ししていこうと思ってます。
最初のプロダクト立ち上げ時の開発の進め方としては、僕がPOとしてプロダクトのビジョン設定、企業の機能要望などを整理して、大きなイシューはJIRAにチケット作ってサブタスクで細い開発の要件などを一緒につめていくみたいな形で進めてきたかなと思います。
開発初期から大きなイシューはどうやって開発に落とし込んでいくかみたいなところで意識したことって何かありますか？
大谷氏：大きな部分に関して言うと、創業期や成長期で分かれています。意識した事は常に人的リソースが限られた状況ではあるので、いかにドメイン知識と呼ばれるその業界限定の知識が求められるタスクを特定のメンバーに任せるかとか、ドメイン知識が必要のないタスクを副業メンバーの方にアサインして依頼するかを意識していました。
田中氏：そうですね。最初は大谷さん、僕、デザイナーの前コーさん、業務委託でエンジニアの藤川さんの4人でワーカーと企業側の全画面を作っていて、一部マークアップのエンジニア2名にもショットで依頼していました。
その中でドメイン知識があるものは、ほぼ大谷さんがやりつつ、わりとドメイン知識関係なく藤川さんにはお願いして開発を進めてきたかなと思います。
創業期のタスクの進め方
▲創業最初期の写真。このときは創業メンバーの3人のみ。
大谷氏：そうですね。創業期はそのような感じでした。
田中氏：クライアントからよく、タスクの割り出しがしにくいみたいな話を聞きます。
わりと僕と大谷さんの役割分担が明確で、僕はOffersのアプリケーションの機能部分のチケット作成やプロダクトの方向性を示していくことがメインで、大谷さんはインフラ部分とか開発基盤周りで必要なチケットをバックログに入れて役割分担されていました。なので、さほどタスク割り振りで僕らは困ったことはないかなと思っています。
タスク割り振りで困ったこととか考えた事とかってありますか？
大谷氏：初期の頃は、細かい仕様周りっていうのは話し合いで進めるべきところが多くて、どちらかというとAsIsとToBeが大事です。何をしたいのかを整理して、早く進めることを常に意識していた部分です。
ただ今思うと当時のやり方はあやふやと言うか、ざっくりしたものが多かったですね。今進めているようなmini specの考え方、ファクト、やりたいことやスペックとして何を求められてるのかなどをイシュアーの方で出してもらって、それを元に足りない部分をエンジニアが肉付けしていく形が理想像に近いと思います。
創業から4年経ち、変化してきたこと
大谷氏：まとめると、創業期は結構ざっくりやってたけれど、現状は結構スペックに従ってきっちりやっていて元々考えていた方向性に近づいていますね。
田中氏：そうですね。ただ立ち上げで大きな問題が起きたことがないので、何とも言い難いんですけど。
大谷氏：初期はとにかく話し合いながら進めているところが多かったですね。正直なところ、チケットに詳細書かずその場で話して決めてしまっていたことが多いです。試行錯誤の連続だったかなという思い出がありますね。もう4年前になるから忘れてしまったところもありますが。
田中氏：Offersを立ち上げてから約2年ぐらいですよね。4年前といえば創業した直後でしたね。ほぼ毎年違うもの作っています。（笑）
創業当初は人数も少ないから今ほど積極的にドキュメントを書く必要性があまりなかったと言うか、今みたいにフルリモートではなかったので、ドキュメンテーションがないと意思疎通がはかれないとかはあまりありませんでした。コミュニケーションで齟齬が起きて実装したものと考えていたものが違うみたいなことのないように進めていましたよね。
少しずつ人が増えてきているのでmini specをしっかり書く、Notionに背景や細かい仕様を書いておくなどのドキュメンテーションを強化して、仕様の背景理解で誰が何やっても一定のアウトプットを出せる配慮がだんだん整ってきた感じがあります。
副業エンジニアのアサイン方法
▲多くの副業メンバーが在籍するエンジニア組織（現在は図よりも規模が拡大）
田中氏：副業のエンジニアを受け入れてましたけど、具体的にどういうスペックや経験の方に何をお願いをしたか聞きたいです。
大谷氏：まずは、弊社のエンジニアチームとしての全体像から話します。
今はコアメンバーはエンジニアが6名。デザイナーが2名。PDMが4-5名の10名程度のチームです。それ以外で副業メンバーとしてアサインして稼働している方は3名ほどいます。それ以外に一時停止している方を含めると副業メンバーは8名です。
主に副業の方たちにはDevOps周りの改善、Rubyのライブラリやアップグレードのための細かいタスクを対応してもらっています。また、データ分析や機械学習を対応いただいたり、マークアップ、フロントエンドの改善などドメイン知識の必要度が少ない部分をお願いしています。
副業の方のアサイン方法については、ドメイン知識がなるべく必要ないものを中心にお願いしています。
副業マッチングプラットフォームを提供している弊社の場合、次のような部分がドメイン知識が必要と思っています。
- 副業のマッチングプラットフォームを提供している中で、候補者と企業がマッチングするフロー
- その後のCSのチームが絡む運用
- 実際にユーザーが正しくサービスを使えるのかっていう認証
- 行動履歴に基づく課金や契約更新
こうした部分に絡む開発タスクへは、現状うまくアサインできていないという状況ですね。
今後も方向性としては、重要な部分はコンポーネントに閉じ込めてコアチームに属人化した形で進めて、それ以外に関しては副業の方にお願いするという方針でアサインをしていくと思います。
副業エンジニアのタスクの切り出し方
田中氏：副業の方々の稼働時間はどれくらいですか？
大谷氏：今は週1,2日の方が多いです、週単位で時間確保できない方も多く基本週単位での契約には落とし込んでいない場合が多いですね。
田中氏：Offersをリリースしてから1年ぐらいのタイミングで副業採用を始めた理由を知りたいです。なぜ、あのタイミングだったのでしょうか？
大谷氏：サービスは生き物で常に進化していかなければいけないと思っています。変化を怠ると、セキュリティ周りの穴を突かれたり、パフォーマンスにも影響が出ますよね。こうしたところは1年目は私一人でやってたんです。
ただ私はこうした部分に携わるとより、むしろ上位レイヤー、アーキテクチャの部分の設計をやるのがCTOの責務としてあると考えています。簡単な箇所はもう分解できて切り離してお願いできていたので、早い段階から他の方に依頼して徐々にドメイン知識を吸収してもらいながら進めるような体制を構築していきました。
田中氏：僕らの場合は、プロダクトを新規で立ち上げるタイミングで副業の方に活躍いただくことをしていました。
プロダクトのグロース具合や開発人数にもよると思うんですけど、半年から一年で契約をしてリリースした機能もありますか？
大谷氏：変更は緊急度は低いが、優先度が高いものが多いので、なるべく細かな部分で切り出しながら副業の方にお願いしていました。基本的にその1年後や2年後、スケールしやすく、かつ安定的に保守しやすいものが出来上がるようになっていましたね。
ドメイン知識不要なタスクのみ依頼する意図
田中氏：大谷さんはドメイン知識が必要ない分野にスコープを狭めて依頼した方が密度高いアウトプットが出るのと、稼働時間的な問題であえて閉じ込めていたと思います。ドメイン知識が必要な部分は依頼しないようにした意思決定の背景や考え方を教えてください。
大谷氏：サービスやアプリケーションの状態によって様々ですが、理想としてはドメイン知識層が完全に切り離され、それらを用いて問題解決するアプリケーション層のサンプルが豊富なほどよいと思っています。CleanArchitectureの構造ですね。
▲ 実際に副業エンジニアに依頼するタスク「Rubyのバージョンのアップグレード」
その構造が理想としてあるので、なるべくドメイン知識が必要な分野をモジュールに閉じ込め、利用する層を限定的にした上で、コアチームに属人的にお願いする対応していくのが考えていたチームの構造です。
立ち上げて2年で徐々に成長フェーズに入っていますが、まだドメイン層が完全に切り離されてない状況なんです。副業の方に依頼するタスクにドメイン知識が必要な部分が多すぎると、オンボーディングの時間が長くなったり、事前説明とレビュー、Q＆Aを含めるとかなり時間がかかってきてしまうんです。
なので、ドメイン部分が完全に切り離されてたり、限定的になっている部分を中心にお願いしてるという背景です。確認フローや、オンボーディングコストが下がる実利的な意味もあって、知識不要な部分をお願いしてる感じですかね。
副業として依頼する内容の切り分けバランス
田中氏：どのようなバランス感覚でそうしようと思われたのですか？
稼働時間やアウトプット、スピード感はタスクにによって異なりますが、いかがでしょうか。
大谷氏：サービス発展に貢献できる経験を持つ人がいて、その人に合致するタスクを依頼するケースと、私が抱えすぎて回っていない部分でドメイン知識切り離されている部分を依頼する2つのケースが主にあります。
もちろんフェーズごとで優先順位は変わってきます。機能拡張の速度を優先しなければいけないフェーズや、セキュリティ周りや諸々のエコシステムの改善をしなければいけないフェーズもあります。依頼するタスクに関してはすでに分離されてる状態なので、お金とバランスを見ながら調整していたのが実情です。
フェーズ毎の優先事項は感覚的な問題なんですけど、依頼するタスクの見極めはある程度分離化されたチケットの中からプライオリティの高い順に従って依頼していました。
副業の方からの情報やアドバイスに助けられることは多い
田中氏：副業の方々の相対評価が難しいんですけど、ビジネスや開発上貢献してくれた人は具体的にどのような方なのでしょうか？
働く側としては自分の能力が生きる部分で副業したい、もしくは自分が学びたいような領域で副業したい転職とかも含めて考える場合が多いと思います。
副業の方でも会社に貢献してくれる人を求めているわけですよね。参考事例があれば大谷さん視点で伺いたいです。
大谷氏：ライブラリやフレームワークのアップデートを依頼している方から、ボトムアップ的にサービスの技術選定の方向性につながるアドバイスを頂くことがあってそれが結構いいところですね。
▲副業エンジニアのアドバイスに助けられることも多々ある
このライブラリのメンテは止まっているので「できれば移行した方が良い」「内部的に使われすぎているので、次の対応で整理してください」といった具体的なアドバイスをもらうこともあります。
こういったアップデート情報やセキュリティ周りの対応状況って開発しながら追うのは難しいんですよね。情報収集的にも足りない部分でしたし、なおかつ改善として私から発案しきれない部分でしたので、すごく助かっている部分です。
あとは私の領域外の部分で、機械学習とかMLOpsに近い部分においては、データオペレーション基盤として不足している部分などアーキテクチャ上（現在はAutoMLなどを活用）の壁打ち相手にもなってくれます。
慌ただしくプロダクト開発していると、情報収集や頭の整理がゆっくりできない時が多いので、アドバイザーや並走者という言葉が合っている人が集まってきてくれています。
田中氏：技術顧問で入っていただいてる方もパフォーマンスチェックをお願いしていましたよね。元々サイバーエージェントの中でプロダクト立ち上げの監査をされている方で、濃いフィードバックをいただけたかなと思いますが改善には役立ちましたか？
大谷氏：はい、大いに役立っていますね。Webフロントエンド専任のメンバーが社内にはいないので、問題となってる動作はBrowserAPIの組み合わせでモニタリングできるなど専門的な話をもとに進められるケースが多く、非常にいい部分でしたね。アドバイザーとしてお願いして良かったと思ったシーンの1つです。
田中氏：フロントエンドのパフォーマンスはSEOやユーザー体験などだと思います。
滑らかさやユーザー検索など含めて早めに表示しないとUXが悪くなる部分を随時相談させて頂いた事例がありましたね。あのケースはすごかったです。
バックログを書き溜めることで副業の方への依頼はスムーズになる
田中氏：事業やプロダクトの方向性や開発の要件、解決したい課題をチケットに書いておいた方が副業の方に依頼しやすいですよね？
大谷氏：そうですね。出来る限り要望や背景を整理してから依頼すると、副業の方も既に経験済みであったりするので、ソリューションとして「こうした方がいいんじゃないですか」といった提案含めたやりとりが発生しやすいですね。
田中氏：今はチケットを作りまくってその後にバックログを分割みたいな、プロジェクトマネジメント方式で進めていますが、昔はバックログにそういうアイデアベースとか何でもいいから入れていっていましたね。
最初からmini specを求めて詳細を書き込むような運用方針でやってたらバックログが増えず、アイデアもまとまってないからチケットを書かない状態になってしまうので、バックログに書き込んでいくのは初期フェーズでは必要かなと思いました。
▲ プロジェクトマネジメントのフロー
大谷氏：プロダクトを運営する上で機能改善として必要な部分はもちろん、維持・保守するためにDevOpsとしてもすべきことはたくさんあります。気づいた段階で起票して優先順位を決めて、副業の方に依頼できるものを決めておくと、振り返るといつの間にか完了している流れに持っていけるので良いと思います。
田中氏：エンジニアに限りませんが、副業でPMの方がいる時に、タスクの割り振りも PM 同士で割り振る状態になっているので、副業の方を生かした理想形に近づいているイメージがありますね。
大谷氏：はい。それにはもう少しドメイン層を用いたアプリケーションサンプルを増やさないといけないので、鋭意改善という感じです。ただ徐々に理想型に近づいてきています。
---
後半記事（「副業エンジニアの最適なオンボーディング方法。カギはmini specの使い方【CTO×CPO対談】」）はこちら。
---
