見出し画像

MIDAS TECH STUDY 開発組織の変革と挑戦の参加ログ

もつお

こちらのイベントにオフラインで参加したログです

グループ会社を横断したエンジニア組織の立ち上げと挑戦

短期的な採用をする必要があったが、認知度が低く採用上の課題があった

  1. 正社員の採用はどうしてもリードタイムが長いので、まずは業務委託採用と並行して短期的な開発対応を行った。
    段階を経て正社員の方が多い状況に持っていった

    1. １つの組織に所属→複数のプロダクトに対して、柔軟にアサインできるようにした

    2. 認知を広げるために

      1. コーポレートサイトリニューアル、勉強会への登壇

      2. 技術・ミッションを広く公開した

      3. 比較検討の材料として、メンバー・経営陣とあってもらったり制度をオープンにしていった

    3. 採用は全エンジニアを巻き込んで母集団を形成していった

  2. グループ会社(組織)を横断したエンジニア組織の組成方法

    1. 横串の情報共有の方法

      1. 技術スタック・担当プロダクト関係なく１部署に所属していて、週１のミーティングで情報共有している。
        それ以外にも週に１回勉強会をしていて、他チームの状況などを共有している

    2. 業務委託の人を増やすにあたってオンボーディングで工夫したこと

      1. まずは採用の部分から工夫している。リファラル前提になるので、一定の人間関係が有り信頼関係があることが成功要因の１つ

    3. 組織横串になった時に、リソースの取り合いにならないようにする工夫

      1. 短期的に業務委託の人に入ってもらって、短期的な開発の山は乗り越えようとしている

      2. が、実態は難しいところが多い。長期的に見た時には社員を増やすことで対応していきたい、と思っている

    4. 新しい技術を求められた時のキャッチアップ方法

      1. 各Chapter毎に勉強会を行っており、学習に対して投資をしている

急成長する組織を支える人事制度とその変遷

  1. EM制度を導入する時に工夫したこと

    1. マネージャはあくまで役割であって、「偉い人」ではないことを丁寧に説明していく

    2. EMの役割は「エンゲージメント改善等を通じてアウトプットを最大化する人」

    3. マネージャになりたくない人への対応について

      1. マネージャ手当を出した→が、後に廃止。マネージャにならないと待遇が上がらない構造になりそうだったので。
        役職ではなく結果で評価されるように制度設計した

      2. マネージャのしごとの面白さを伝える。例えば、プロダクトを伸ばすためのやり方として、マネジメントをがあることを伝える

        1. 管理だけをする人、というイメージを払拭する

  2. エンジニア横断組織について

    1. 全エンジニアが参加できるパブリックな会議体を作って、皆んなで組織を改善できるようにした

    2. EMという役割の有無に関わらず、組織改善を促すことが大事。マネジメント=EMではなく、グラデーション付けて組織に関われる部分を増やしていった

  3. 急成長をする上で評価の納得感や公平性を担保する必要があった

    1. グレード定義を詳細化して、全社公開レビューを通じて運用を開始

    2. グレード定義以外にも公平性や納得感を支える仕組みを作った

      1. 1on1, eNPSの活用

      2. 360°フィードフォワード (バリュー体現)

      3. マネージャー間での評価のキャリブレーションを行った

      4. マネージャーからの評価フィードフォワードでの納得感調査を行う

    3. テックリード等の役割をきちんと定義をしつつ、役割は横断可能として個々人が描くキャリアを後押しした

領域が広いサービスの分割統治と開発ガバナンス

  1. 複雑かつ正確性が求められる、広いドメイン領域にエンジニア組織としてどう立ち向かっていくか

    1. モノリシックなしくみで立ち向かった時

      1. メリット

        1. 高速なドメイン理解

        2. 事業機会の最大化

        3. ニーズへの柔軟な対応

      2. デメリット

        1. 認知コストの増大

        2. オーナーシップの希薄化

        3. アドホックな個別対応

    2. モノリスな組織をドメイン単位で分割をすることによる狙い

      1. チームごとの継続的な改善サイクル

      2. ドメインに立ち入った開発の加速

      3. 長期目線に立った仕様のコントロール

    3. コンウェイの法則などを活用して、チームの境界とシステムの境界を作っていく

懇親会感想

今回はオフラインで参加したので、懇親会にも参加させて頂きました。印象的だったのは

  • どの会社も採用は永遠の課題として捉えている

    • リファラル採用を使っても人数はどうしても限られてくるので、様々な施策を通じた認知向上やダイレクトリクルーティングが必須。

    • エージェントとの良好な関係を築けるかどうかも１つの要素

  • 技術戦略について

    • ドクターメイトもそうですが、バックエンドとフロントエンドの言語の統一メリットについて盛り上がりました。統一することで

      • バックエンド⇔フロントエンドのコンテキストスイッチの低減。それに伴う、チーム間の溝をなくす。

      • 候補者の母集団形成が楽になる

最後に

オフサイトのミートアップ参加だと、登壇者の方に色々と質問など出来て面白いですね。
意外と業務のドメイン領域が近い方ともつながることも出来て、非常に有意義な内容となりました。
また機会があれば、是非参加したいと思います！

この記事が気に入ったらサポートをしてみませんか？