メインコンテンツへスキップ
見出し画像

自律自走するエンジニア組織におけるエンジニアリングマネージャーのこれからの役割

    こんにちは!IVRyのエンジニアリングマネージャーの米元です。

    この記事は 株式会社IVRy 白組 Advent Calendar 2024 の13日目の記事です。白組の昨日の記事は Sales Ops 西浪さんの『マネジメント志向が低い私がIVRyでPOにチャレンジした理由』でした。明日は Customer Success 羽賀さんの記事です。どちらも合わせてご覧ください。

    紅組の記事もぜひご覧ください!

    はじめに

    IVRyでは yuriさんの記事 にあるようにエンジニア組織は今年1年で15名から34名と2倍以上の人数に増加しました。

    メンバーの平均年齢は約36歳でミドル以上のメンバーが多く、30代以上のメンバーが中心のため自律・自走したメンバーが多いです。また、成田さんを始めとして他社でのCTOやテックリード・マネージャーを経験した方がIC(Individual Contributor)として働いているケースもあり、開発上の課題の多くは自分たちで能動的に解決できています。
    一方で事業や組織の急速な成長に伴ってこれまで直面してこなかった課題が発生することも予想されており、それらに対処することや早期に発見し先回りして課題の目を摘むことも必要となります。
    本記事では、このような環境のなかでエンジニアリングマネージャー(以下、EM)にこれから求められることを開発組織の現状を踏まえながら述べていきたいと思います。

    事業の拡大と開発の課題

    おかげさまでIVRyの事業は順調に成長しており、11月には約95%の業界(※以下の記事参照)で利用されるまでになり、累計の着電数は3,000万件を超えました。

    この成長をシステム面で支えるため、インフラやアーキテクチャはもちろんフロントエンドやネイティブアプリまで様々な工夫をしています。

    ただ事業の急成長に伴うトラフィックの増加や、顧客層がSMB(中小企業)からMID・EP(中堅企業・大企業)に広がるにつれて、機能面や開発環境に様々な課題が見えてきました。
    いくつか例をあげると以下のようなものがあります。

    • シンプルなUI/UXを維持しながら機能要求の複雑化へ対処すること

    • 大手顧客の組織構造に対応するためのデータ構造のリモデリング

    • MID・EPのユースケースへの対応と既存機能との整合性の担保

    • サービスのスケールと電話という社会インフラの安定的な提供の両立

    • マルチプロダクト化に伴う認証基盤や請求基盤の構築

    • 音声対話やAI対話までカバーしたE2Eのテスト自動化

    • ネイティブアプリのUI/UXの電話体験の最適化

    • 音声対話まで一気通貫で開発できる環境の構築

    これらの課題に対処していくためにEMとしてどのように組織を作るべきか、またどのような役割を担うべきかについて私の考えを述べていきます。

    現状の組織構造

    IVRyの組織は事業部ごとに分けられておらず、代わりにプロジェクトとサークルを軸としたフラットな組織構造をしています。

    また、部長・本部長といった役職はありませんが、プロジェクトやサークルにオーナーを立て、それぞれの領域に責任を持つ構造になっています。
    2024年12月時点の開発組織でEM相当の役割を担っているメンバーは私を含めて5名です。
    ※12月にはこれまで2社でCTOを経験された海老原さんが入社され、EMの体制が一気に強化されました

    前述のyuriさんの記事でも言及されているように、組織構造はおおまかには以下の図のとおりになっています。

    画像
    https://speakerdeck.com/ivry/ivry-culture-deck-for-engineers

    現状はそれぞれのプロジェクトに1人のEMが所属してそれぞれのプロジェクトの運営を開発面から支えていたり、サークルに所属するメンバーのイネーブルメントや評価を担っています。

    IVRyのEMがこれから担っていくこと

    以下はこれからEMが担う仕事の一例です。

    組織やプロセスの継続的な改善とスケーラビリティの確保

    急速な組織拡大のなかで個人やチーム間のコミュニケーションパスが増加しつつあり、情報伝達や意思決定のプロセスが徐々に複雑化しています。
    現状は会社全体の情報の透明性の高さや、各自のオーナーシップによってカバーできており、大きな問題にはなっていません。ただし今後さらに人数やプロジェクトが増加していけば各自の認知負荷の限界を超えてしまい、重複作業の発生や曖昧な役割分担の増加、生産性やモチベーションの低下が発生するおそれがあります。

    それを防ぐための取り組みとしては、PdMやデザイナも含めた開発プロセスの標準化、DACIやRACIを用いた役割や意思決定プロセスの明確化、会議の棚卸しやドキュメントの整備、レビューやセキュリティチェックのガイドラインの整備などが考えられます。

    また、「Team Topologies」に記されているように、チーム構成とそのインタラクションを設計し、チームの認知負荷を下げながら組織のスピードを維持する取り組みも重要となります。

    画像
    引用元: https://martinfowler.com/bliki/TeamTopologies.html

    単にルールやプロセスを作るだけでなく、IVRyの組織構造やカルチャーに合わせてできるだけ軽量な仕組みを用い、組織の拡大やプロジェクトの増加に合わせて柔軟に変化させていくことがEMとしての腕の見せどころになると思います。
    これらの取り組みによって、各メンバーが自身の専門性を最大限に発揮でき、結果として組織全体のスピードと品質を両立した持続的な成長を実現できるのでないかと考えています。

    技術的負債・品質への戦略的投資

    以前の成田さんの記事にもあるように、IVRyはまだ大きな技術的負債を抱えているわけではありません。ただ急速な事業成長や領域の拡大によって、これまでは正しかった技術選択がある日を境に正しくなくなる状況が今後は増えていくと考えられます。
    たとえば直近では、

    • 複数の機能から利用されるコアなAPIの機能拡張とリファクタリング

    • エンタープライズ顧客に対応したアカウントデータのリモデリング

    などが必要となっています。

    今後も個々のメンバーだけでは優先度や影響範囲が判断しきれないような、組織やプロダクトを横断する課題が発生することが予想されます。

    開発者体験や品質向上の観点では、エンジニアの数が増えても品質や生産性が下がらないような仕組みづくりが必要となります。たとえば開発環境・ステージング環境の整備や、AIとの音声対話も含んだE2Eテストの拡充などが考えられます。

    これらの課題に対し、EMは日常的に課題をキャッチアップできる仕組みを整え、メンバーや他のEM・PdMとも協力ながら先回りして改善計画をプロダクトロードマップに織り込み、戦略的に投資できる状態を作ることが必要だと考えています。

    採用とオンボーディングプロセスの整備

    EMの重要な仕事の1つに採用があります。
    IVRyではまだまだエンジニアを募集しており、事業や組織の拡大に応じて採用職種とその要件も日々変化していきます。
    そのため採用要件のチューニングやジョブディスクリプションの継続的なアップデートが欠かせません。面接官によって評価のばらつきを防ぐための評価基準の明確化や、メンバーが面接官としてデビューするまでのトレーニング体制と仕組みの整備も必要です。
    加えて開発組織の認知度を向上させるために、テックブログの運営や勉強会などの技術イベントの企画と実施、社外イベントへの出展などの技術広報もこれまで以上に推進する必要があります。

    ※フロントエンドメンバー主体で出展したJSConfのレポート記事はこちら

    また、入社したメンバーに活躍してもらうためのオンボーディングプロセスの整備も必要になります。
    IVRyではこれまでもオンボーディングには力を入れており、入社時にはメンターがついて伴走しながらメンバーの立ち上がりをサポートすることで早期の立ち上がりを実現しています。

    ただ現在のペースで組織が拡大すると、入社するメンバーの数に対してメンターを担えるメンバーの数が不足する可能性が高く、十分なオンボーディングの支援ができなくなる可能性があります。

    ちなみに書籍「エレガントパズル」でもエンジニアの増加とともに発生する問題について触れられており、これらに対処するためにオンボーディング(書籍ではトレーニングという言い方)の重要性が説かれています。

    生産性を高めるために、多くのエンジニアをまとめ上げるのは難しいものである。 その難しさは、自走できるエンジニアをどれだけ早く育成できるかにより決まる。
    もし6か月ごとにエンジニア数が2倍になり、エンジニアが自走できるまでに6か月から12か月かかっているとしたら、トレーニングされていないエンジニアの数がトレーニング済みのエンジニアの数を上回ることは明らかだ。
    トレーニング済みのエンジニアは自分の時間のほとんどを、新しく入ってきたエンジニアのトレーニングに費やすことになってしまう。

    Will Larson. エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか (pp.36-37). 日経BP. Kindle 版.

    1.エンジニアの桁数が増えるごとに、新しいマネジメント層を設計し維持する必要がある。
    2.10人のエンジニアごとに、追加のチームが必要になり、調整がさらに必要になる。
    3.エンジニアが1人増えると、1日あたりのコミットとデプロイが増える。また、開発ツールに負荷がかかる。
    4.障害のほとんどはデプロイによって引き起こされる。したがって、デプロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポストモーテムが必要となる。
    5.エンジニアが増えると、専門化されたチームとシステムが増える。オンコール対応するエンジニアが本番環境の課題をデバッグして解決するためには、システムの背景を十分に理解する必要がある。そのため、少数のチームによるオンコールローテーションの必要性が増してくる。その結果、相対的にオンコールに費やす時間が増える。

    Will Larson. エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか (p.39). 日経BP. Kindle 版.

    対処としてはオンボーディングドキュメントを拡充することやトレーニングプランの策定、メンター制度・体制のアップデートなどに取り組むことが考えられます。

    チームメンバーの成長支援とキャリア開発

    最後に、忘れてはならないのがメンバーの成長支援とキャリア開発です。
    自律自走できるエンジニアが多いからこそ長期的に学び続け、キャリアを主体的に築ける環境を整えることが必要だと考えています。

    幸いIVRyではチャレンジに値するような課題が山積みで成長機会には事欠かない状況ではありますし、結果はどうあれトライすること自体を称賛するカルチャーもあります。
    それらを後押しするための組織の取り組みとしては、たとえば以下のようなものが考えられます。

    • 課題の大きさや重要度を可視化し、メンバーが主体的にそれを取りにいけるようにすること

    • 課題発見が得意なメンバーと課題解決することが得意なメンバーを組み合わせたチーム編成をおこなうこと

    また、キャリア開発の観点では

    • キャリアラダーを整備して個人が成長する方向性を示すこと

    • ICやマネジメントなどの役割を柔軟に行き来できるカルチャーと仕組みを作ること

    などが考えられます。

    中長期の視点では、今後組織をスケールさせていくために新卒やジュニア層の採用とその成長機会の創出についても検討を始めていく必要があると考えています。

    まとめ

    IVRyのEMが今後取り組んでいくことについて書きました。
    ここまで書いた内容はほんの一例ではありますが、急成長企業では起こりがちで想像がつきやすい人も多かったのではないでしょうか。
    実際には想像もつかないような出来事や、仕組みだけでは解決できず泥臭く対処する必要があることがたくさん発生するだろうと思っています。

    そんなカオスも受容しつつ、できるだけ先回りして課題の目を摘み、エンジニアがパフォーマンスを最大限発揮し成長できる環境をつくること。
    また、今まで築いてきた開発カルチャーを薄めることなく更に強固でより良いものにし、スピードを保ちながらVisionである”Work is Fun”を体現していくこと。

    それが今後のIVRyのEMの役割になると考えています。

    画像
    IVRyのVision, We made "Work is Fun" from now

    正直めちゃくちゃ難しいなという思いもありますが、一方でEMとして非常にチャレンジしがいのある環境とも感じており、改めてワクワクしています。

    IVRyではこのような面白い組織作りに一緒にチャレンジしてくれる人を募集しています。EMやエンジニア組織について、もっと聞いてみたいと思った方はぜひ面談などでお話させてください。

    ここまで読んでいただきありがとうございました。

    Sales, CS組織の拡大についてこちらの記事で詳しく書かれていますので、こちらもぜひご覧ください!

    この記事が参加している募集

     
     
    株式会社IVRyでエンジニアリングマネージャーをしています。

    あなたへのおすすめ