「事業部制組織と機能別組織、どちらがいいのか」は企業経営においてよく話題になるテーマのひとつです。こちらのほうがよいという明確な正解があるわけではなく、企業フェーズによって変えていく企業も少なくありません。

専門性の強いエンジニアも組織の形態によって影響を受けやすい職種です。機能別組織で専門性を高めるべきか、事業部制組織で意思決定のスピードを上げていくべきか。全体最適か、個別最適か。組織形態について悩んでいるリーダーも多いのではないでしょうか。

この記事では、事業部制組織から機能別組織に移行したアソビュー株式会社(以降、「アソビュー」)の事例について、CTOの江部隼矢氏にご紹介いただきます。同社では、移行によって個別最適に偏っていた状況を改善するだけにとどまらず、2つのメリットを併存させる体制を目指しています。これまでの経緯や直面した課題、組織移行時に取り組んだことについて解説していただきました。

浮き彫りになった個別最適での非効率なシステム構造

アソビューは、創業からこれまで、不確実なビジネス環境の中で都度変化に適応するため、必要に応じて柔軟に組織体制を変更してきました。その中で、直近の事業別体制から機能別体制への移行事例についてお話したいと思います。

弊社は事業テーマとして「遊びのデジタル流通プラットフォーム」を掲げ、大別するとBtoCのサービスEC事業、BtoBのSaaS事業、そしてギフト事業や自治体、観光事業者向け事業などがあります。その中で、サービスEC事業およびBtoB事業が弊社の取り扱いにおいて大部分を占め、かつ他事業の基盤となっているコア事業となります。

2021年6月まで、弊社では事業部別の開発体制を採用しており、サービスEC、SaaS、ギフトそれぞれの事業にエンジニアが配置され、一部機能を横断するチーム体制となっていました。この体制下では、各事業ごとの成長戦略に基づき、独立した開発方針や優先順位の中で効率的に事業成長スピードをあげられるというメリットがあります。

特に、業界全体として新型コロナウイルスの蔓延による影響を受ける中で、弊社ではいかに各事業ごとにこの状況に適応しサービスの成長を止めることなく推進できるかの重要な局面であったため、この体制は合理的だったとも考えられます。

一方で、エンジニアが事業ごとに配置されていることにより、いくつかの弊害も生まれていました。ひとつは、開発の工数をほぼ攻めの施策にあて、システムの品質や運用観点での取り組みがおろそかになりがちという問題がありました。プロダクトバックログの優先順位上位は新規案件や顧客獲得施策に当てられ、品質改善やトイルの撲滅といった取り組みがおこなわれづらい体制であったことにより、障害などもちらほら発生する状況でした。

もうひとつは、システムの構造として事業部ごとに最適化が進みすぎてしまい、システムを会社全体で俯瞰した際に、事業ごとに重複する機能が存在したり、非効率なシステム構造になったりしてメンテナンス性を損なうなどのデメリットも生じました。

一例ではありますが、具体例を示してご説明します。

アソビューでは現在大きく分けて2種類のレジャーが存在します。ひとつはアクティビティ予約です。パラグライダーやスキューバダイビング、陶芸体験など、参加するプログラム、参加日時、人数などを指定して予約する形のものです。もうひとつは、電子チケットで遊園地、水族館、ランドマーク、博物館や美術館など、大型のレジャー施設でのチケット購入です。

このふたつはそれぞれ異なる顧客体験であり、導入先のレジャー提供事業者の形態も異なります。そのため別々の事業としてスタートし、別々のシステムを運用していました。


※事業部と商品は一部オーバーラップ

しかし、コロナ禍で各レジャー施設において単位面積あたりの入場制限が必要となり、電子チケットもアクティビティと同じような日時指定予約や在庫管理、販売枠管理が必要となりました。ただ、異なる事業のシステムを導入・運用することの煩雑さなどを理由に、チケットシステムに対してもアクティビティと同様の機能を実装することとなり、車輪の再開発をするような状況となりました。

ご想像のとおり、似通った複数のシステムを同時に開発、運用することは開発生産性の低下を招きます。それに加えて、それぞれ微妙に異なる仕様の違いなどを営業やサポートのメンバーが理解する必要があり、顧客への説明難易度も高いため早急に是正する必要があると感じました。

その結果、「長期的な目線でのシステムの全体最適」という戦略の重要性が全社的に明確になり、是正を進めるべきだと決断ができました。

事業部制組織から機能別組織への再編成

スタートアップとして顧客や投資家に期待されているサービスの拡充や価値向上を進めながら、全体最適への歩みも着実に進めなければ、根本的な課題解決はできません。しかも、これらはお互いに相反する側面も多くあり、両立させるのは簡単なことではありません。

これをなんとか実現するため、事業部制組織から機能別組織へ組織の再編をおこない、開発部門を大きく2部門に編成しました。目的は、「1. 短~中期での事業成長の継続」、「2. 中~長期での全体最適」の両立です。

前者を「プロダクト開発部」、後者を「システム統括部」が担い、各事業に配置されていたエンジニアチームをそれぞれに配属させました。また、当時わたしがCTO(最高技術責任者)とCPO(最高プロダクト責任者)を兼任していましたが、前者のリーダーとして新たにエンジニアバックグラウンドの事業責任者をCPOとして任命、わたし自身はCTOとして後者の部門を率いることとしました。

プロダクト開発部は、事業成長にフォーカスして、短~中期的なプロダクトの機能開発を進める事業部です。プロダクトごとのチームが存在し、それぞれのチームがビジネスサイドとコミュニケーションを取りながらスクラム開発をしています。各事業ごとの成長施策を実行しつつも、個別最適に陥らないような対応、調整をする役割も担っています。

システム統括部は、長期的な改善にフォーカスし、システムの全体構造やアーキテクチャに対する課題解決・業務効率化に対応する事業部です。複数のオーバーラップした機能を持つシステムを整理・統合するシステム刷新プロジェクトも開始しました。また、システム統括部のエンジニアチームは、SRE(サイト信頼性エンジニアリング)や、サービスの成長にかかわる業務オペレーションの効率化など事業全体の信頼性をトータルでサポートしています。

この2部署は毎週実施している開発統括会議でチームごとの進捗報告、新規案件の見通し、インシデントの管理やSLOのモニタリングなどを共同でおこない、お互いの動きがわかるようにしています。議事録は全社に公開され、だれでも状況が把握できます。

これにより、少しずつですが継続的事業成長と全体最適を両立して進められるようになりました。各チームの目的を明確化し情報共有を密におこなうことにより、全体最適の観点を損なうことなく、短期的な顧客ニーズを満たしながら長期的な施策を同時並行で進められるよう調整しています。

なお、今回の組織変更をおこなう上で考慮した点として、チーム単位では元の形をできるだけ残すようにしました。こういった組織変更は常に混乱を伴うものですが、チームをひとつの塊として動かすことで、ミッションは変わったもののメンバーが担当するプロダクトが大きく変わることを避け、混乱を招かないように工夫しています。

機能別組織の弱点をカバーするための施策

もちろん新体制はいいことばかりではなく、デメリットも多くあります。今回の組織移行では特に以下の問題が顕在化しました。

  1. 複数事業間での案件の優先順位調整が複雑化
  2. 他部門と開発のコミュニケーションが一方通行になりがち

1に関しては、これまで事業ごとに決定していた優先順位を、全社横断で調整する必要が出てきたことにより調整コストが多く発生するようになりました。

また、今回の編成以前に機能別組織を採用した際に発生していた問題として、全社の案件を並べて優先順位決定する際に、比較基準をROIに統一しようとすると一部の大型顧客向け案件に寄ってしまった経験があり、これをどう解決するかが課題となっていました。

ここはサービスEC事業責任者を兼任しているCPOが、全体視点をもって優先順位を調整しています。属人的ではありますが、各事業と開発組織のコミュニケーションのハブとなりながら、ときには経営会議に持ち込んで議論することにより最適な意思決定ができるようにしています。

2に関しては、ワークショップ、シャッフルランチ、週1回の全社集会後に意見を交換する機会を設けるなどを全社で実施することにより、双方向で意見が出し合えるカルチャーや、だれでも気兼ねなく意見発信できるような心理的安全性向上のための取り組みをおこなっています。

人事制度改訂も進行中。まずは評価基準を見直し

機能別組織に移行するとともにエンジニアの評価制度も見直しました。

これまでエンジニアには「目標設定の基準が非常に曖昧で、評価時に納得感がない」という課題がありました。同時に、全社的に統一された「成果」に重きをおいた評価制度のもとでは、目標設定がプロジェクトベースで定義される傾向が強くありました。プロジェクトベースでの成果定義は、常に優先順位が変化し、評価期間中にやることが変わるといったことが頻繁に起こるチームではうまく機能しません。

また、事業成果に関わらずその期間の行動・取り組みによる評価では、基準が全社全職種一律であったため、評価項目がファジーにならざるを得ず解釈もブレがちでした。

そこで機能別組織の中でもしっかりと目的意識を持ち、能動的に動くために、エンジニア版の評価基準を制作しました。これまでの「成果」から、「保有能力」に対する評価にシフトしたことにより、目標設定や振り返りの際の上司・メンバー間の会話がよりメンバーの成長にフォーカスしたものになりました。

加えて新規採用時の初期等級の基準が明確化され、既存メンバーとの等級の整合性が取れやすくなるという効果もあります。

「エンジニアの評価は難しい」とよく言われますが、原因のひとつに事業貢献度をエンジニアの働きと結びつけることの難度が高い点があります。今回は事業KPIをエンジニアの評価基準には入れず、代わりにユーザーニーズや顧客理解を評価に含めるようにしました。

たとえば「等級定義のガイドライン」では、バリューを専門的価値・専門能力・ナレッジ貢献といった3つに大分類し、それをさらに詳細に分け、当社でエンジニアに必要とされる知識や能力を明確に定義しました。

まだ運用を始めたばかりではありますが、評価基準を改訂したことでエンジニアからは「何を目指すべきなのかが理解できた」「目標が立てやすくなった」というフィードバックをもらっています。加えて「評価をする立場としても基準が明確でわかりやすくなった」など、評価をする側からもポジティブな意見が出ることが増えました。

組織変更で失敗しないために必要なことは

長年の課題であった個別最適と全体最適の両立という部分では、組織変更をしたことにより取り組みが進められており、手応えを感じています。

組織変更を検討する際は、まずは課題の明確化と周知を図り、社員からの理解を得ることが重要です。組織変更前後で全社戦略から落とし込んだ組織変更の必要性を説明する場を設け、メンバーに理解してもらえるように努めました。アソビューの場合、非効率な部分が増えていたことはメンバー内の共通の認識であったため、全体最適に取り組むという方向性と、そのための組織変更という意味でメンバーからの理解度は高かったと考えています。

一方で、人事制度は全体の一部しか改善できておらず、現在は報酬や条件、採用面、働き方などに関しても整理を進めており、近くアップデートする予定です。組織体制も人事制度も、正解がある類のものではないですし、完成形もありません。会社や事業が継続する限り、引き続き改善を続けていきたいと考えています。

そして、今回の組織変更をきっかけに事業もさらに成長させていきます。アソビューで楽しめるレジャーはどんどん増えていますが、今後もあらゆる休日やレジャーのシーンを網羅的にカバーし、当たり前のようにつかってもらえるようなサービスを目指していきます。


Share