様々な課題を乗り越えながら成長し続けるアウモ開発組織5年間の軌跡

2022-08-12

5年近くアウモの開発を担当している中で、この半年くらいで開発組織が組織らしい動きをできるようになったと思っています。そこに至るまでには紆余曲折がありました。どのように開発組織が変化していったのかを振り返っていきます。

アウモ開発グループのエンジニアでは最古参になった村田です。今年もGREE Tech Conferenceを開催予定で、アウモからも数人登壇する予定です。今年は多くのメンバーが登壇に対して手を挙げてくれたことがあり、開発グループの変化を感じてる今日この頃です。

本題に移りまして、今年に入ってエンジニアの人数が増え、アウモの事業構造が進化したことに伴い、開発組織も構造転換を行なったので、開発組織について事業フェーズに区切って振り返りをしていこうと思います。

現、開発組織に至るまでの軌跡

事業状況に応じて開発組織も変化させてきました。紆余曲折を経て現状の「メディアチーム」「SaaSチーム」2軸の開発組織に至るまでを振り返っていきます。事業状況の変化は、アウモ株式会社取締役の安藤さんが書いたnoteを見てください。

サービス立ち上げ期

エンジニアが0人の時期があった初期リリース直後

2017年3月1日がアウモのサービス開始日です。Web記事メディアのみのサービス展開から始まりました。ちなみにグリー株式会社には他にも複数メディアが存在し、その中でアウモが最後発になります。アウモリリース後にはエンジニア0人の時期があり、開発組織が存在しないような状態で、企画はするものの実現ができない、開発冬の時代があったようです。（わたしがアウモに携わる前の話なので明確な状況は知らず）

職能型で開発組織が組成されたアプリリリース前後

サービスリリース後の翌年、2018年1月にアプリをリリースしました。翌月の2月からわたしはアウモに業務委託としてJOINしました。その時の開発組織体制は「職能型」で、「iOS、Android、サーバーサイド、ディレクター」という括りで動いていました。

開発手法は基本的にアジャイルで進行し、2週間のスプリントを回すようにしていました。新規アプリ開発のような大規模開発をするような場合、ウォーターフォールで進めるようにしていました。企画側が要件出しをし、ディレクターが細かい要件を詰めて、それをチケットにしてエンジニアをアサインしていくというフローで開発を進めていました。

この時期の開発組織内は業務委託の割合が大半を占め、エンジニアの入れ替わりがまぁまぁあるような状況でした。スプリント期間内に割り当てられたチケットを消化していくようなフローだったことがあり、エンジニアは個々人に割り当てられているチケットのみ関心があるような状態で、他チケットの差込みは歓迎されないような硬直的な状況でした。

エンジニアはきっちりと要件、仕様を固められたチケットを捌く役割に専念し、社内の受託部門的な雰囲気があったことで、人の入れ替わりがあったとしても作業範囲、コミュニケーション範囲が狭いため、人が入れ替わった際のキャッチアップコストが低く、人員が安定しない状況下でのメリットはありました。

硬直的な開発体制で課題が表面化してきたサービス拡大期

2018年半ばくらいからアプリへのプロモーション投下やSEOの伸びに伴い、ユーザー規模は拡大していきました。この時も開発体制は以前と変わらず、仕様をきっちりと決められて割り当てられたチケットのみ捌く硬直的なフローによる課題が表面化してきている状況でした。

サービスにアクセスしづらくなる状況が定期的に発生しているのにも関わらず、エンジニア側では気が付かずに誰かに指摘されるまでそのような状態が放置されるなど、サービスのヘルスチェックができておらず、不健全な状態が常態化し、それが当たり前な状況に陥っていました。

この当時は監視、改善についても通常のタスクフローと同様にディレクター側で仕様を決め、それをチケットとして割り当てない限りエンジニア側は動かないような状態であることが、サービスが不健全な状態でも放置される大きな要因になっていました。

サービス拡大期の途中からエンジニアでマネージャーのポジションを置くようになり、ディレクター側に任せきりになっていたタスクコントロールを徐々にエンジニア側でも行うようにし、不健全な状況をタスクの合間を見て改善するように進めていくようにしていきました。

現、開発体制の基盤を作るきっかけとなったコロナショック期

事業・組織を縮小せざるを得ない状況になり、開発組織も半分ほどに縮小しました。これをきっかけに開発フローも大きく転換していきました。

職能毎の区切りは取り払い、プロジェクト毎に1〜2人のエンジニアをアサインし、そのプロジェクトで必要な技術領域全般を担当するような、フルスタックエンジニアであることを求めていきました。また、ビジネス側とエンジニアが要件定義から直接やり取りを行い、QAにビジネス側も入ってもらうようにし、コミュニケーションルートを短くし、エンジニアとビジネス側が密に連携することで、開発に関わる意思決定、調整などを迅速かつ柔軟に行うことができるようになりました。

結果的に開発スピード向上、エンジニアの配置に関する柔軟性が高まったのはもちろんのこと、エンジニアの事業、サービスに対しての関心が高まり、開発組織が社内の受託部門という雰囲気はなくなり、エンジニアを起点にサービスが改善されるような状態にまで変化していきました。

開発組織拡大を目指す再成長期（現在）

コロナショック期はエンジニア数が少なかったことがあり、チーム開発というよりは個人開発を束ねたような状態が開発組織でした。そのため、チーム開発での開発効率を高める、開発安全性を高めるような取り組みができていない状況でした。

そのような状況下で、アウモ社として開発組織を強化する方針があり、3年後を目安に30名超のエンジニアが所属している状態を目指していて、チーム開発での開発効率、開発安全性を担保していく必要性が必然的に高まった状況になりました。

現在では開発工数の一部を使って、開発組織全体での開発効率、開発安全性を高めるような改善活動を行っており、GitHub ActionsによるCI導入、ローカル開発環境のDocker化などの取り組みを随時行っています。

また、事業体はメディアのプロダクトをメインとした状態から、「メディア × SaaS」の2軸体制に変わりました。組織体制にシステムを合わせにいく意味合いも含めて、開発組織も「メディアチーム」「SaaSチーム」2軸で分割し、その中でさらにプロジェクトに分けて開発を進めるような体制にしています。

フェーズ毎にわたしが注力してきたこと

立ち上げ期〜コロナショック期の混沌期

サービス拡大期のフェーズまではエンジニアの大半が業務委託で流動性が高かったことがあり、短期的な視点で開発を行う傾向が強く、中長期の視点が欠けている状況で新機能の開発を最優先に進めている状態であったことから、サービスに安定してアクセスができるなどの当たり前の状態を提供できていない状況でした。

そのような状況下でエンジニアリングマネージャー（EM）として役割を担うようになったので、まずはEMが問題となる部分の洗い出しから手を動かすまでの全てのフローを担い、サービスがあるべき姿を保つための開発ベースを整えることに注力してきました。

この時に自分の中で、開発組織はマイナス状況であるので、最低でも0へ、その先の文化醸成ができるようなフェーズに開発組織が成長するまでは、この開発組織を最低でも見ていこうと思っていました。

再成長期（現在）

混沌期であったサービス拡大期、コロナショック期を経て開発組織のベースはマイナスから0の状態へ整った（と思っています）ので、次に注力していった（現在進行形）のが文化醸成により、プラスの状態に開発組織をしていくことです。

開発面で一部紹介すると以下のようなことを行っています。

テストを書く
レビューなどで気軽にコメント飛ばす（発言のハードルを低く）
改善すべきと思うことがあれば、声を出すだけでなく、その人が率先して手を動かす（改善活動のための工数はチームとして、定期的に確保するようにしてます）
開発者の経験の無い言語、フレームワークなどへの取り組み（取り組み姿勢を大事にしていて、チームとしてサポートするようにしています）

マインド面では仕事への動機付けを個々で行えることを目指し、以下の2つを特に意識しています。

仕事そのものが楽しいか、その中でどのような場面が楽しいか
- 楽しいと思えるようなタスクをなるべくアサインできるように調整しています
アウモという場を利用して、何を実現したいか、何を目指したいのかの思いがあるか
- 会社に利用されるという意識ではなく、自分の目指す姿を達成するために会社を利用するという意識を持ってほしいと思っています

文化醸成に繋がる取り組みになると、自分発信より、チームメンバーからの提案から始まることが多く、このような状況をみると、開発組織のベースはすでに0からプラスの状態になっているなと思ったりしています。