変化をチャンスに変えるエンジニア組織の成長アプローチ
こんにちは、Startup Tech Live事務局です。「エンジニア組織のグロースに必要な知見の流通」をテーマに様々なイベントを開催しております。
こちらは2023年10月4日に開催したイベント「変化をチャンスに変えるエンジニア組織の成長アプローチ」のイベントレポートになります。
今回はモデレータとしてアソビュー株式会社CTO江部さん、スピーカーとしてakippa株式会社プロダクト開発責任者井上さん、株式会社Voicy開発部門責任者山元さんに登壇いただきました。是非ご覧ください。
モデレータ
取締役上級執行役員CTOスインバーン工科大学情報技術学科卒、シカゴ大学MBA修了。2008年、フューチャーアーキテクト株式会社に入社。業務系、決済系、消費者向けサービスなど、大手企業向け案件を中心に、サービス・技術共に多様な分野での開発を経験。
2012年、カタリズム株式会社（現アソビュー株式会社）に参画。執行役員CTOとしてアソビュー！の事業立ち上げを実施し、プロダクト領域の執行役員を経て、2019年より取締役執行役員CTO。2022年10月より取締役上級執行役員CTO（現任）
スピーカー
プロダクト開発責任者akippaでプロダクト開発の責任者としてエンジニア・デザイナー・企画職が所属する部門のマネジメントを行ってます。また、PdMとしてakippaのプロダクト全般のサービス企画・マネジメントも行っています。趣味は釣りで関東・関西で釣り友達を積極的に募集中です。
開発部門責任者早稲田大学でマルチメディアと機械学習の研究を行い修士号を取得後、ヤフーに入社し検索サービスのバックエンドをフルスクラッチで開発。Voicyではエンジニア部門の責任者として開発組織全体の統括をしており、技術戦略策定/チーム設計/アジャイル開発導入/エンジニア組織開発などを行いつつインフラとサーバサイドとデータ/機械学習領域ではプレイヤーとしても従事。
エンジニアリングチームの進化と再構築
江部さん）まずは2社の組織変遷を見ていきたいと思います。まずはakippa社からお願いします。
井上さん）第一次成長期、第二次成長期、リビルド、第三次成長期の４つにフェーズを分けております。リビルドは立て直し期間です。
今はちょうど第三成長期に入っているといますね。4つのフェーズに分けたときに、大きく二つ区切りがあります。
ビジネスドリブンとプロダクトドリブンです。ビジネスドリブンは、マーケティング・営業主体のビジネス成長、プロダクトドリブンは、プロダクトの実現したい未来から逆算した開発の実行を表しています。
プロダクトドリブンへの変革は、ビジネス推進する事業成長の領域がなくなったわけではなく、事業成長を前提とし、その上でプロダクトのチャレンジをしないといけないということになりリビルド期から舵を切っていきました。
今は350万人ぐらいの規模のサービスになっていますが開発組織は非常にスモールで、現在20名を超えた規模感です。
今までは増えたり減ったりを繰り返しているような歴史があります。
江部さん）続いてvoicy社の組織変遷についてご紹介お願いします。
山元さん）我々も４つのフェーズに分けています。創業期はMVPを重視してサービスを作っており、当時はウォーターフォールで開発を進めていました。その後、資金調達を行い採用を強化しましたが、10名ほどが退職してしまうという苦しい時期を迎えました。
オフショアのパートナーと協力し、なんとかサービス開発を進めました。MVPで機能開発していたことで、負債もたまりリアーキテクトをやると決めた中での退職だったので非常に大変な時期でしたね。
シリーズA後期では、プロダクトドリブンで成果に向き合い、お客様価値を追求するためにアジャイル開発を導入できるように整理を始めました。立ち上げ時やプロセスの変更は一部混乱が生じましたが、これを乗り越えたチームメンバーだからこそ、いまは安定しています。
シリーズB期にはいり、リアーキテクトの失敗もあり、非常に負債がたまっていました。品質やバグの発生に加えて、開発スピードが遅いという問題も出てきました。スピード感と品質を高く保つことが難しい状態になっていました。そこから改めてアジャイル開発の徹底、ユーザーに向き合うこと、カルチャーの合う仲間達を集めることをやっていました。
ようやく開発負債を解消できるチームを立ち上げることができてきました。
江部さん）２社ともに色々なターニングポイントがあったと思います。色んな組織が経験しそうな課題がありましたね。
akippaさんは技術領域に関する意思決定はどのようにしていますか？
井上さん）いまはCTO不在、VPoE、EMもいない状況です。
akippaに長くいるメンバーが意思決定をリードすることが多いですが、最近は新しいメンバーも議論のきっかけを作ってくれています。
江部さん）マネジメントミッションを明確に持っていないが、ナレッジを提供しながら自律的なチームとしてやれているということですね。素晴らしいです。
逆にマネジメントポジションをエンジニアから持って来たりはしないですか？
井上さん）必要だとは思います。エンジニアの人数も増えてきていますし、今後より良いチームにもしていきたいと思ってます。
もう一段新しいチャレンジをするためにも、組織を強くしていくようなエンジニアリングマネージャーを増やしていきたいと思ってます。
江部さん）Voicyさんは、CTOがいらっしゃらないと聞いてます。技術的な意思決定はどのようにしていますか？
山元さん）技術的なところは、私が主に意思決定しております。必要に応じてチームメンバーにも権限を渡してます。
今は自分のところでリアーキテクトに向けてバックエンドを書き直したりしています。
一方でアプリ等の自分の専門領域外のところは、チームメンバーとコミュニケーションしながら決めている状況です。
江部さん）実質的には山元さんがCTO的なふるまいをされているということですね。
では次は各組織で過去どのようなことが起こったのか伺っていきます。
まずはakippa社について振り返っていきます。
変革を求めたエンジニアチームの試練
井上さん）第一次成長期あたりに資金調達をして、エンジニアの採用を強化して1名から8名に増えました。
メンバーのそれぞれやりたいことがあってakippaに入ってきましたが、CTOもいなかったため、開発の方向性が定まりませんでした。
みんなで合議制でやるべきことを決めたり、プロダクトを抜本的に作り変えるようなチャレンジをしたりと中途メンバーを中心にやっていました。
一方でビジネス理解も甘い、技術的な事情もちゃんと理解できてない中で、抜本的な作り変えというのはかなり結構ハードなチャレンジングだったと思います。
プロジェクトが頓挫したタイミングでメンバーのモチベーションが下がってしまい、退職するメンバーがでました。人数が減った1つのタイミングです。
2つ目のタイミングは、プロダクトをリアーキテクトした時期です。システムが古く、成長に耐えられるものにするためです。
一気にフルリニューアルするのではなくて、少しずつやり始めようという形で第二次成長期を進めました。これをやるにあたって、人数的に厳しいということから採用人数を増やしました。
このタイミングでカルチャーや価値観のミスマッチが起こりました。統一感がなくて、当時会社としてもしっかりとしたバリューが定められてなかったため、議論したとしてもそれぞれを正論で殴り合うみたいな、悲惨な状況も発生するようにになっていました。
みんなが正しいこと言ってるんだけど、それで殴り合っても仕方ないよねというような状況でしたね。お互いの信頼関係がなくなってしまって、疑心暗鬼のような状況でメンバーが抜けたのが第二次成長期でした。
江部さん）リアーキテクトする際の失敗について、今まで積み上げてきたものを後から入ってきた人たちが、作り直したいという話はよくある話ですよね。
井上さん）そうですね。経験者がいたら、それはわかるけど、ちょっとずつこうやっていこうぜ、と話ができると思いますが、当時は勢いで進めてしまったのが失敗の原因でした。
江部さん）なるほど、ありがとうございます。
Voicyさんも似たようなことがあったと思いますが、いかがでしょうか。リアーキテクトの失敗についてご紹介頂きたいです。
山元さん）まさに同じですね。
創業期に作り上げたプロダクトが機能開発優先なところに中途メンバーがジョインし、「これ、おかしいぞ」というような形でリアーキテクトのプロジェクトを立ち上げました。
一方で、技術検討をしっかりしなかったという失敗がありました。具体的には、モダンな技術を掛け合わせたリアーキテクトができるように検討を進めていましたが、途中で頓挫したことで成長を止めるようなことに繋がりました。
もしリアーキテクトを考えている方がいれば、ぜひ慎重に検討を進めてほしいと思ってます。
とはいえ、失敗した要因を今改めて振り返るとやはりカルチャーが合わないことによる、組織崩壊だったと思います。
音声で新しい価値を作る、ビジネスモデルを創造するということに共感してすごく優秀なプレーヤーの方が集まってくれました。
皆さんの今まで成功した経験を当てはめようということをしましたが、結果には結びつきませんでした。
組織崩壊を経て、カルチャーを改めて定義をして、makeValueを掲げて、音声で価値を作るところに共感するということ、それに挑戦をしていく泥臭さについてオンボーディングや採用のプロセスに組み込んでいます。
江部さん）初期の技術選定は、本当に大事ですよね。
それが後々までずっと続いていくんですけど一番最初の頃って、真っ新なキャンバスに何でも作れる気持ちになっていろいろやりたくなるんですよね、本当に固くいったほうが良いですよ。改めてしみじみと感じました。
2人とも、ビジネスドリブンからプロダクトドリブンへの変化があり、組織全体のマインドシフトが起こっていると思いますが、何がきっかけになりましたか？
井上さん）現場と、経営層の両方から話があったと思います。
改めてちゃんとakippaの開発組織はどうあるべきか、理想から逆算してやっていきたいという話になりました。akippaを成長させていくためには、今までの営業やマーケティングによるビジネスドリブン的な成長だけではなくて、プロダクトで伸ばしていかないと、akippaの目指すビジョンを達成できないと思い決定しました。
社外取締役の方からもアドバイスをいただき、noteでそれを発信したりしました。外部からのアドバイスと、現場の思いが合致して、意識が変わったというところがあります。
江部さん）ありがとうございます。まさに開発組織だけじゃなくて、会社全体に影響があるところだと思います。
プロダクトドリブンだと、ビジネスサイドからするとどうシフトチェンジするのか、反発など課題にはならなかったですか？
井上さん）ビジネスサイドからは否定されることはなかったです。ビジネスサイドの成長が１階として、プロダクトサイドの成長が２階とすると、１階のビジネスサイドの成長があってこそ、プロダクトドリブンの成長につながると思っています。
開発側もその意識を持っており、うまく切り替えることができていると思います。この件についても社外取締役の方からアドバイスを受けました。
山元さん）プロダクトビジョンや目指す方向性をどうやって開発メンバーと共有したか教えて頂きたいです。
井上さん）Howを考えることは後だよ、ということはメンバーに伝えていました。まずはプロダクトとしてここを目指したいという理想像を固めようと話をしました。
これまでは”One akippa”を掲げて、１つのチームでプロジェクトを進めていましたが、駐車場を借りるドライバー様と、駐車場を提供するオーナー様の２つにチームを分けました。
これによってエンジニアやデザイナーが誰に対して、どんな価値を提供するのか、お客様に提供するプロダクトの解像度が上がっていきました。
山元さん）まさに私も同じ考えでチーム編成をしています。誰にどんな価値を提供していくかは重要だと思ってます。価値に向き合うチーム編成はありだと思いました。
技術開発の進化と組織変革
江部さん）ウォーターフォール開発とアジャイル開発がありますが、どのような背景があって、開発方法の変化がありましたか？
山元さん） 当時は品質面と開発手法が合っていませんでした。
プロジェクトを立ち上げて、エンジニアやプロジェクトマネージャーを筆頭に検討を進めていましたが、開発のサイロ化が進んでしまう状況でした。
１つのプロダクトだが、機能が横に繋がっていない状況が発生していました。共通的な機能が設計されていないことが課題でしたね。
結果的にバグが発生しやすく、品質問題に発展していました。
そのため、開発プロセスの見直しをすることになりました。過去の失敗に向き合って、設計の時間を取って成果に向き合うためにアジャイル開発にすることにしました。
江部さん）プロジェクト毎の立ち上げで品質が低下していた問題に焦点をあてるより、組織やチームに焦点をあてた課題設定できたと思いますが、どのように気づくことができましたか。
山元さん）そうですね。品質問題の改善はもちろんですが、新しいビジネスを立ち上げていくタイミングなので、不確実性に立ち向かうチーム構成をどうやっていくのが良いか、考えて行く中で気付くことができました。
もともとウォーターフォール開発が得意でプロジェクトをしっかりマネジメントするようなスタイルの方が多かったですが、新しいチャレンジとしてアジャイル開発に進めるようにしました。
江部さん）これまでの話を聞いて、カルチャーとバリューを両社ともに大事にしていると感じました。
ここが明確化されていないことで組織崩壊が起きてしまったと思いますが、ここからバリューを創ろうとした場合どのようなプロセスで創っていくべきでしょうか？
井上さん）ちょうど会社のバリューが定義されたタイミングで、開発組織ではどう解釈するかを話し合いました。
会社として全社共通のバリューを創ったタイミングでしたが、チームの価値観を合わせるためにバリューを再定義していました。
再定義のプロセスの中で、メンバーに納得感があり現場で運用できるるように自分たちでバリューを解釈して揃えて、再定義をしていきました。
議論の中でバリューの目線合わせをしていましたし、自分たちで決めたことは、危機的な状況を乗り越えるためにも大事だと考えています。
江部さん）Voicyさんはいかがでしょうか？
山元さん）４つのバリューがあり、メンバーの納得感もあると思います。
採用プロセスの中でも重要視しており、共感頂ける方を採用しています。バリューの浸透を図るために、クレドという行動指針をメンバーに考えてもらっていました。
合わせて、全社に浸透させるプロジェクトもやっていますね。創るだけではなく浸透することにも力を入れています。
江部さん）バリューを浸透させるプロジェクトは具体的にどんなことをやっていますか？
山元さん）Slackのスタンプを作ったり、Peerボーナスに絡めたり、身近に簡単に拡がるような施策を考えていました。
江部さん）弊社も開発組織におけるバリューを定義しましたが、一方で人が増えていくにつれて、あとから入ったメンバーは浸透が薄れてしまうことがありました。
なので日常的に使うようにしないと浸透しないと思っています。
メンバーにバリューをどう意識してもらうか、工夫はありますか？
井上さん）いまのフェーズでいうと、最低限の共通認識を持つためのラインとしてバリューを活用していたが、次はより引き上げていくようなバリューの設定をしていきたいと思っています。
これから進めようとしているのですが、例えばバリューを目標に組み込んで、評価していくのはありだと思っています。
あと、社員に広げるためにバリューをオンラインミーティングの壁紙に設定するなど試みています。
江部さん）少しリモートの話にも触れていきたいですね。コロナでリモートワークが進んだと思いますが、akippaさんはちょうどリビルドの時期と重なっていると思いますが、この時期をリモートでどう乗り越えていきましたか？
井上さん）リモートはネガティブ要素にはならなかったですね。一方で顔が見えない寂しさはありましたが、古くから参画しているメンバーの4人がリードして結束感と信頼感を強くしながら、コミュニケーション設計をしてくれました。
うまくリモートにアジャストできたと思っています。
江部さん）もともと信頼関係があるメンバーでリセットできたということですね。
お２人ともにメンバーが増えて、メンバーが減ってという経験をされていると思いますが、どんなメンタルで乗り越えてきましたか？
井上さん）正直つらい部分もありましたね。すぐに解決しようとするのではなく、時間をかけて少しづつチームをリビルドしていきました。
プロダクトの責任者としても、少しリフレッシュする期間を挟みながらやりました。
経営側も危機感を持ち、しっかり私やチームと向きかい合ってくれいたと思います。
江部さん）Voicyではコロナ期間をどう乗り越えていましたか？
山元さん）シリーズA後期くらいにコロナになりました。リモート中心になっていくのは最初苦労しましたが、色々なリモートツールを使ってみて、みんなポジティブに捉えていました。
組織崩壊と技術負債の乗り越え方
江部さん）組織崩壊はどのようなメンタルで乗り越えていましたか？お二人はどのように見ていましたか？
山元さん）ちょうど私が参画するタイミングで、エンジニアが減っていくような時期でした。よくない状態というのはすぐに気が付きました。
その中でも残ってくれたメンバーは、Voicyのカルチャーを大事にしてきたメンバーだと思いますし、そのメンバーに共感して参画したので、一緒にチャレンジしたいと思っていました。
改めて強い気持ちを持って進みたいと思いましたね。
江部さん）お２人の話から組織崩壊はもちろんポジティブなことではないですし、危機的な状況であると思います。
しかしミッションに共感している人がしっかり残ってくれることができれば、ミッション強化の純度が上がり再出発に至ったと思いました。
技術負債に関する品質解消についても話を伺いたいです。
山元さん）創業期に開発したものや業務委託メンバー中心に開発したものの一部がコードが異なる書かれ方をしているプロダクトがあり、不具合がたまってきた時期がシリーズA後期でした。かつスピードが上がらない状況で、アジャイル開発に取り組んでいました。
負債の品質問題は一旦目をつむって、成果とお客様に向き合うことを優先に集中していました。
チームが安定したタイミングで技術負債に向き合うことを決めました。今は、リアーキテクトをして、各エンジニアに負債の解消をしてもらうような動きをしています。
江部さん）日々の開発の中で技術負債を解消するというよりは、まとまった単位で負債に向き合うということですか？
山元さん）大きい負債と小さい負債がありまして、小さい負債は開発しながら解消することを意識しています。
先日も負債を解消するための１日のイベントをやりました。
小さい負債に日々向き合う文化を創っていますし、大きい負債についてはしっかり時間を割いて、チームとして取り組まないとなくならないと思ってます。
チームメンバーをしっかり後押ししつつ、その問題を分析し、投資価値を一緒に考えるような立ち回りを意識しています。
江部さん）大きい負債に立ち向かう時に新しい機能開発にも一定制限がかかると思います。
エンジニア組織だけでなく、他の組織や経営層への説明はどのようにされていますか？
山元さん）説明するときは事業効果を説明することを意識しています。これが解消できれば、開発スピードが改善されるということや、負債に向き合っている時間を推定で表現しながら、開発工数への削減効果をしっかり説明するようにしています。
江部さん）定量的に効果を示すようにしているということですね。akippaさんは技術負債への向き合い方はどうでしょうか？
井上さん）技術負債への向き合い方は似てますね。
チーム力がない時に負債に取り組むと組織崩壊になっていくと思いますが、いまはチームとしてのレベルが上がってきているのでリアーキテクトをやれるフェーズにはあると思ってます。
会社内での合意の取り方ですが、経営層から任せてもらっており、将来のプロダクトを考えた時にこういうアーキテクチャに変えていかないとプロダクトが伸びていかないことや、ビジョンを説明して会社の目指す方向についてすり合わせすることをしています。
合致していれば任せてもらうことが多いです。
江部さん）みなさん本日は様々な事例をありがとうございました。
Startup Tech Live
こちらのグループはVC「Globis Capital Partners」が主催するTechnologyにフォーカスしたcommunityになります。 スタートアップ×Engineeringに関する情報はもちろん、著名な方の登壇イベント等を発信していきます。
Globis Capital Partnersは日本初の本格的ハンズオン型ベンチャーキャピタルとして1996年に設立しました。 日々次世代のリーディングカンパニーを生み出すためにチーム一丸となり精進しております。
Twittter: https://twitter.com/gcp_byvc
connpass: https://gcp-tech.connpass.com/
この記事が気に入ったらサポートをしてみませんか？