ほぼ複業メンバーのチーム体制で、1年以上開発を続けて学んだこと

Kyohei Ikematsu
KAUCHE Tech Blog
Published in
Dec 21, 2022

--

こんにちは。カウシェでエンジニアリングマネージャーをしているikeです。

僕は事業者向け管理ツール(以下、パートナー管理画面)の開発チームにいます。カウシェに商品を出品してくださる事業者の方が利用するプロダクトです。

チームには9名いて、僕とデザイナーのkikku-san以外は複業メンバーです。カウシェは全社的に複業メンバーが多いですが、その中でもかなり複業比率の高いチームだと思っています。

1年以上この体制で開発を継続しています。振り返ると「スムーズに開発を進めるする上で重要だったな」という点や「いくら頑張ってもこの体制ではできないこともあるな」などがあります。

今回はこのチームでの開発で学んだことを、シェア買いアプリ「カウシェ」 Advent Calendar 2022の21日目の記事として書こうと思います。

↓こんなことを書いていきます。

  • チーム構成
  • 約14ヶ月で開発した機能
  • 新規複業メンバーの立ち上げで大切なこと
  • 最初にどんな仕事をお願いすると良いか
  • お願いを控えたほうがよい仕事
  • 心構えとして重要なこと
  • 困難なこと

チーム構成

この1年で多少変化はあったものの、おおよそ以下の構成でした。

僕たちのチームの複業メンバーはどなたも本業をお持ちです。カウシェでの月の稼働時間は30〜40時間です。平日夜に稼働する方、週末に稼働する方など様々です。

そういえば:最初は現CPOのakky-sanがPMで、デザイナーは全員複業でした。その状態から徐々に変化して上記になり…もうすぐ新たな仲間としてPM、バックエンドエンジニア、QAのフルタイムメンバーが加入予定です。それによって僕のロール兼任状態を改善できそうで楽しみです。

約14ヶ月で開発した機能

パートナー管理画面はゼロイチの開発でした。この1年は以下のようなEC管理画面に必須な機能の開発が中心でした。

  • 認証(ログイン、ログアウト、アカウント一覧)
  • ストア管理(送料、ストア情報設定)
  • 商品管理(商品登録・編集、一括操作周り)
  • 注文管理(シェア買い成功した購入の一覧、変更、一括操作周り)
  • 内部オペレーションで必要な機能
初期リリース時のパートナー管理画面

新規複業メンバーの立ち上げで大切なこと

オンボーディングのドキュメントを作っておき、最初に必要な作業(各種アカウントの登録など)や必要な情報(仕様やアーキテクチャ図など)へのアクセスを整えておきつつ、以下を行うのが良いと思っています。

1回目の1on1を30分、早いタイミングで行う

  • お互いの自己紹介を話す、カウシェでやれたら嬉しいこと・あまりやりたくないことなどを聞く( 今まで経験したことのない業務ロジックの実装に関わりたい、など、人によっては求めているものがあったりする)
  • 「どこまで口を挟んでよいのだろう」など、複業側としてなんとなく不安な部分が序盤はある
  • 安心感を持っていただく、お互いを知る、今後どのようなことをおまかせするのが良いか肌感を掴むために行う

最初の1ヶ月は毎週30分くらい、1on1を行う

  • 実装過程での不明点、ちょっとした困りごとが序盤は特にある
  • だが、慣れるまではフルタイムメンバーに聞くのを遠慮しがち
  • フルタイムメンバーの時間をとるの申し訳ないと思っているケースもある
  • slackで聞くほどではないけどこの場があるなら聞いてみるか、のノリで会話が始まり、有益な情報を伝えることができるシーンが序盤は多い
  • なので最初は少し頻度多くても、費用対効果が高い感覚
  • 解決を早期に行えるし、ここまで聞いて良いんだ、こう進めれば良いんだ、という状態を早めに作りやすい
  • 2ヶ月目以降は頻度を減らす
  • ただし数ヶ月に1回程度は1on1を続ける

チーム内外の人との1on1(1onN)の時間を、最初の方に作る

  • 業務上近づく可能性がある人を中心に10名前後
  • 定性感覚だが、やるかやらないかで馴染みやすさが変わると思う
  • ちなみにカウシェではパートナー管理画面チームだけではなく、welcome 1on1という名目で全社的にこれは行われている

作業者として迎え入れるのではなく、チームの一員として迎え入れるという姿勢が重要と思います。このあたりを何もやらないと、加入者側はなんとなく一歩引いた状態が継続してしまいやすいと思います。

週次でやっているチーム定例の開始待ち

最初にどんな仕事をお願いすると良いか

小さくてかつチーム貢献感のある仕事、が良いと思います。

  • 1–2ヶ月かかりそうな大きめものとかは避ける
  • 要件や仕様がふわふわしているものは避ける(これは常に避ける)
  • 複業の時間の範囲で、1–2週間でできるものが良い
  • 既存機能の小改善、開発体験悪い部分の改善など
  • 優先度の高いものでなくても良い
  • 小さいものであることがより重要

最初の1つ2つの仕事で小さな成功体験を積んでいただくのが重要、というイメージです。なので優先度が高いことよりもサイズが小さいことのほうが大事かな、と思います。

小さい仕事を進めていくうちにキャッチアップもできるし、何より、アウトプットを少しでも残せると焦りも減ります(任せる側の焦りも加入者側の焦りも)。

お願いを控えたほうがよい仕事

どんな仕事をお願いするか、控えるかは、フルタイムにどんな能力を持つ人がいて、複業にどんな能力を持つ人がいるか、によって少し変わるかなとも思います。

今の僕たちのチーム構成だと以下かな、と考えています。

期日が近いもの、または期日調整をし難いものは控える

  • 複業の方には本業があり、時間を使えるタイミング・使えないタイミングが日ごとや週ごとで異なる
  • なので緊急度の高い仕事は相性が悪い
  • 重要だが期日に余裕のあるもの、または期日を調整可能なものをお願いする

対複業エンジニアに、要件定義や仕様調整をお願いするのは控える

  • 能力的に要件定義などができる方であっても控える
  • How(設計や実装)に集中してもらったほうが全体生産性が高い

対複業PMに、抽象度が高すぎる課題をお願いするのは控える

  • 長期ロードマップ、戦略検討の丸投げなど
  • そのようなものは社内の広範囲な情報が必要になる
  • 多くの人やチームから情報を得る必要がある
  • 社内の状況変化が早いので、常にキャッチアップが必要になる
  • 月30–40時間と限られた中でやるのは、おそらく誰であっても不可能
  • 特定機能の要件定義や数値分析、UXリサーチなど、スコープをある程度は限定したものをお願いしたほうが良い

基本的な考えとしてブロッカー要素が少ない状態、なるべく複業メンバーが独立して進められる状態を事前に作れるか、が大事だと思っています。

時間は限られているが優秀な人達が複業で協力してくださるという状況において、フルタイムメンバーが一定の時間を準備のために使って動きやすい状態を作ったほうが、全体として生産性が高くなる感覚です(準備=要件定義をしっかりやってから開発を開始する、などを含む)。

複業メンバーの時間が潤沢なら話は変わると思います。

心構えとして重要なこと

個人的に思っていることです。僕の性格だと以下のように考えた方がうまくいく、という感じです。

頼るし遠慮をしない

  • 複業だからこのくらいまでにしとこうかな、と、勝手に思わない
  • 大きかったり難しそうなことも、相談してみる
  • 副業ではなく複業である、と考える(カウシェは相手にとって2つ目の本業である、という考え)
  • 公開する情報にもフルタイムと差を設けない、とりあえず伝える

とはいえ本業があるがゆえの制約を頭に入れる

  • 認知できる情報量にそもそも限度がある(どんなに長くカウシェ複業に関わっていても、キャッチアップできない部分がでてくる)
  • 相手の忙しさ等をふまえて、こちら側で調整の努力を行う

困難なこと

スケジュール通りに進めるのが通常より難しい

  • 複業の方には本業がある
  • 本業の忙しさによってカウシェに割ける時間は変動するが、その忙しさはこちらでコントロールできない
  • 本業の忙しさを聞いた上でスケジュールを立てる、スコープに削れるものを用意しておく、などが回避策だが、通常より難易度が高い

開発からリリースまでのサイクルを早めるのが難しい

  • フルタイム主体の場合と比べると1機能を開発するための期間が絶対に長くなる
  • 複業メンバーを増やしたとしても早めるのは困難(タスクを分割して分担実施する場合、相互コミュニケーションがおそらくネックになる。分割しないで進める場合、フルタイムと比べると期間が必要になる)
  • 開発終了⇒QA⇒改修確認などのように開発は進むと思うが、エンジニアもQAも両方複業だと、お互いの待ち時間により、期間が長くるリスクが高くなる(フルタイム同士の場合と比べると特に)

その他

「複業主体だとマネジメントなどのコストが高くなって大変なのでは?」という質問をいただくことがあります。

高くなる部分はあると思います。例えば以下です。

  • 緊急度の高いものは控えたいため、アサインの考慮が通常より必要
  • スケジュール通り進まないリスクが高いため、調整コストが発生しやすい

一方で「要件定義や仕様策定などの準備をしっかり行う」などはフルタイム主体の場合とチームトータルでは変わらないのではと思っています。

複業主体の方が準備に手を抜いたときの跳ね返りが強い印象があり、ゆえに準備の負担がフルタイムに寄りやすい気はしています。ただし複業主体だろうとフルタイム主体だろうと、どっちみち誰かが負担していたコストが寄っているだけで、チームトータルで見ると実はそんなに変わらないのでは、と思っています。

まとめ

複業主体のチーム運営について書いてみましたが、いかがでしたでしょうか?書いてて思いましたが、複業・フルタイムに限らず普通に重要そうなことも多そうですねー…。

どなたかの参考になれば嬉しいです!

最後になりますがカウシェではバックエンドエンジニア、SREなど多くのポジションを募集しています。カジュアル面談で色々お話できることも多いので、興味のある方はぜひ以下も見ていただけると!

--

--