トレタ開発組織振り返り 2019年版 - トレタ開発者ブログ

この記事はトレタ Advent Calendar 2019 12日目*1の記事です。

こんにちは。最近、子供に荷物に買い物かばんにとリアルポーターごっこに腰がつらくなってきた@joy04dです。

前回のAdvent Calendarでこんな事を書いていた自分ですが、その後、今年1月から VP of Engineering の役割を頂いております。まだ1年足らずのひよっこですが、日々頑張ってお仕事しております(=ω=)

今回の記事では、せっかくなのでこの1年の振り返りと知見(あるいはアンチパターン)の共有を兼ねて、つらつらと*2書いてみたいと思います。

どんなことしたか

今年のコンセプトを一言でいうと 個からチームへ になります。

トレタの開発組織では、創業期から自治をコンセプトとしており、フラットな組織のなかでエンジニアそれぞれが自身の裁量と責任を持って行動することを大事にしていました (この辺りで軽く触れられています)

これは個の力を全面に押し出すアプローチであり、創業期の小規模組織などにおいては理想的に働く一方で、今のトレタのように100人を超える組織規模では、様々な面でデメリットが目立つようになってきていました。対策としてプレイングマネージャー的な人を置いてみたりもしたのですが、皆がゴリゴリと手を動かさなくては行けない状況では、なかなか腰を据えてそちらに力を入れるのも難しく、組織のコンディションも徐々に悪化する形となってしまっていました。

そこで改めて専門職としてのマネージャーを置き、皆が効率的に動ける体制を作ろう、個人の頑張り依存ではなくチームで組織的に課題に向かえる体制を作ろう、と気合を入れたのが今年の流れになります(>∀<)

やったこと

ということで、今年の動きをつらつらと書いてみます。
地味です( ´_ゝ｀)

採用編

課題

事業や組織の成長にエンジニアの採用が追いついておらず、常に人手不足
- ベンチャー企業の必然ではある
即戦力を求めすぎて、間口が狭い。また組織として同質化が進みすぎる
- 組織の成長には適度な多様さが大事

対策

会える機会を増やす
- 採用は人と組織のマッチングであり、接触機会が多いほど求める人(あるいは組織)に出会いやすい
  - 巡り合わせ大事
- 面接フローのスリム化・レイヤー化
  - これまではできる限り全員で判断する方針
    - 面接回数が多く、双方にとっての負荷が大きい。
      - 6回面接したことも
    - 全員が採用に責任を持つ ≒ 誰も責任を持っていない状態になりがち
      - 各々が求めるすべてにマッチする人はそういない
  - これをエンジニアによる技術面接とマネージャーによる組織面接に分割
    - 誰がどの観点に責任を持って見るのかはっきりと
      - それぞれの立場からの擦り合わせも大事に
ヒット率を上げる
- リファラル採用の強化
  - 自分の会社にマッチする人は中の人が一番知っている
  - エンジニアに限らず社員総出で頑張る
自分たちをもっと知ってもらう
- これも機会が大事
  - 技術イベントへの登壇や開催、カジュアルに話せる場の用意
    - TORETA TECH TALKや立ち呑みトレタなど
  - 継続が大事なので来年も頑張りたい

結果

エンジニアの人数が倍になった。ﾔｯﾀｾﾞ
ジョインされた方々もすぐにvalueを発揮、楽しく仕事をしていただいている。ﾔｯﾀｾﾞ

反省点

急激に人が増えたために、オンボーディングやコードレビューのコストが大変なことに
- 裾野が広がるより早く人が増えたために一極集中化
  - 古株の方々、特に @m_nakamura145 の頑張りでどうにか乗り切れたところが大きい。正直ﾀｽｶｯﾀ
- 組織の拡大と地盤固めのバランス大事

組織編

課題

エンジニアを共有資源的に捉え、あちらこちらのプロダクトで隙間なくタスクをこなす状態
- キツキツパイプライン問題
  - 人手不足もありタスクが同時進行となることも多いが、人のコアはひとつでスイッチングコスト大
  - 1つのプロダクトの影響が他のすべてに伝搬するため、スケジュールの不確実性大
    - 優先度の判断も難しい
  - 隣の人が何やってるかわからない状態になりがちで、ノウハウの継承がされにくい
- 傭兵化問題
  - 腰を据えて1つのプロダクトに向き合う時間が取りにくいため、関わりが薄くなりがち
    - 目標(と評価)の軸も定めにくく、どうしても受け身寄りの動きとなる
  - 常に同じ技術領域で呼ばれるため、新たな技術領域に挑戦する機会を作りにくい
  - 継続的な保守・改善や技術的負債の返済に時間を割きにくい
    - 各々の隙間で頑張り対応だが、徐々に追いつかずに

対策

マトリクス型組織への移行
構成イメージ
- 縦軸に事業戦略の軸に合わせた開発チーム、横軸に横断的に動く基盤チーム
  - 例
    - 開発チーム → Toreta nowチーム
    - 基盤チーム → SREチーム
      - ちなみにSREチームは今回新設
        
        攻めの運用を目指す
  - チーム単位でミッションを持つ
    - 縦 or 横 → チームが効率的に動きやすい方向を主軸に
- 各チームにリーダーを設定
  - チームのミッション達成に責任を持つ
  - ある程度チーム体制が固まるまではマネージャーが兼務で乗り切る
    - 何もないところからいきなりリーダーをやってくれといわれても厳しい
- 技術的な横断役として各領域ごとにテックリードを設定
  - 技術的なよろずサポート・レビューから中長期的な技術戦略などを担当
事業・組織・個人の3軸の成長に目標を設定
- 事業 → Issue First
- 組織 → Respect All
- 個人 → Dive!
- に合わせた形。
  - 三方良し
  - 元々の自治の流れを失わないように
    - 人によりアプローチは様々で、特に組織・個人軸はその人次第
      - みんなで幸せになろうよ

結果

チームで集中して開発が行えるようになった。スケジュールの確実性も上がった。ﾔｯﾀｾﾞ
改善などに向けた主体的なアプローチがしやすくなり、個人・プロダクトともに成長機会が増えた。ﾔｯﾀｾﾞ
チーム内でノウハウの共有が活発化した。ﾔｯﾀｾﾞ
テックトークなどの横断的な社内勉強会も活発化。ﾔｯﾀｾﾞ
- 開発者ブログも活発化。ﾔｯﾀｾﾞ
  - (AdventCalendar効果だけど)

反省点

マネージャー集中問題
- チームリーダー兼務はチーム体制が固まるまでの繋ぎだったが、早々にオーバーフロー
  - 当初の想定よりもだいぶ早く各チームリーダーにバトンタッチ
    - 割とぶん投げになってしまったが、皆に助けられていい感じになった。正直ﾀｽｶｯﾀ
  - 人にちゃんと仕事を任せよう
    - 自分のキャパも考えよう
チームの柔軟性問題
- トレタのようなベンチャーでは短い期間で状況が変わることもある
- その変化に対してチーム構成が固くなりすぎて、運用でカバーなところが出てきてしまっていた
  - チーム間のアサイン問題など
  - バックオフィスのツールとの兼ね合いもある
- どんな体制も柔軟に運用できる遊びが大事
  - 準備不足・ω・