背景
以前、転職活動を行っていた際に、ビジネスサイドと開発サイドとの分断を課題にあげているスタートアップ企業が、少なからずありました。こういった分断は大企業で起こるイメージを持っていたため、少数でスピーディに動くことが求められるスタートアップでも起きていることは意外に感じました。各社共通の課題なんだなと気づき興味を持ち、分断が起こるメカニズムや対処方法を書籍やブログ記事から調べてみました。
調べてみると、事例としてはよく散見されるものの、分断に対してあまり明確な打ち手は出ておらず、企業ごとに試行錯誤が行われているという印象を持ちました。また、この問題に対して共通のキーワードが定義されておらず、いくつかのキーワードを駆使して検索する必要があり、思いのほか大変でした。
自分の理解の整理と備忘録として、「ビジネスサイトと開発サイドの分断」というテーマで、調査した内容をまとめてみました。自分なりの理解をまとめたものですので、ご指摘・マサカリ・マシュマロ大歓迎です。なお、この分断はスタートアップに限らず起こるものですが、調査範囲を限定するため、スタートアップを前提とした調査とします。
BizとDevの分断とはどういった状態か？
「BizとDevの分断」とは、営業やマーケティング、企画といったビジネスを担う組織と、エンジニアやQA、SREといったプロダクトの開発からデプロイを担う組織とで、互いの組織間で目的のずれや情報の遮断が起こり、大きな溝ができた状態を指します。別の言葉では、セクショナリズムとかサイロ化とかで表される状態です。BizとDevの分断が起こると、スタートアップ組織として以下の不利益が生じます。
BizとDevの分断により起こる不利益
部分最適化により全体の目的を達成しづらくなる
KPIが部門ごとに設定されることで、全体最適ではなく、部門ごとの最適を追いかける構図になり、結果、全体の目的から遠のくということが起こります。場合によっては、営業と開発が敵対し足を引っ張りあうような問題がわかりやすく表出することもあります。
- 事例）
- 営業目標達成のため無理な開発スケジュールが組まれてしまい、エンジニアが疲弊する
- 「期限内に仕様通りに作ること」が目的になり、使いやすさ等の非機能要件が犠牲になる
情報の滞留が質の低下、スピードの低下を招く
部門間での情報の遮断が起こると、エンドユーザー側の学びとプロダクト側の学びが上手くつながらず、PDCAの質が下がってしまいます。また開発側の情報がタイムリーに共有されないことで営業の機会損失を招くこともあります。
エンジニアのモチベーションの低下
BizとDevの分断が行き過ぎると、ビジネスサイドから降りてきた仕様通りにただ開発するだけという、社内外注のような状態になることがあります。エンジニア目線で見ると、エンドユーザーから距離があり目的や成果が見えづらいプロダクト開発は、モチベーション低下の要因になります。イソップ寓話「3人のレンガ職人」の話でいうところの、ゴールである大聖堂をイメージして働く職人ではなく、ただレンガを積み上げるだけの職人になってしまいます。
分断を加速させる力学
なぜスタートアップ企業でBizとDevの分断は起こるのでしょうか？一般的にセクショナリズムは、部門間の交流の少なさや行き過ぎた成果主義により縄張り意識が生じて陥るものとされています。さらにスタートアップの場合、BizとDevの分断を加速させる力学が３つあると考えます。
シード期以降の急激な組織拡大
もともと少人数で始まるスタートアップですが、PMF（Product Market Fit）後やまとまった資金調達ができた時などで、チャンスを活かすために急激な組織拡大をはかることがあります。分断を気にしなくてよかった状況から、人員増加と組織構成の変更が一気に進むため、ビジョン浸透やコミュニケーション設計が間に合わないことで分断が起きやすくなってしまいます。
効率を求め細分化された組織編制
スタートアップの組織編成には定石のようなものがあり、規模に応じて役割ごとに組織を細分化していく企業が多いように感じます。例えば営業部門であれば「マーケティング」「インサイドセールス」「カスタマーサクセス」、開発部門であれば「フロントエンド」「バックエンド」「SRE」「QA」に分かれるといった感じです。だんだんと縦割りの細かい組織編成になっていくことで、組織間の連携がしづらい状況が生まれてしまいます。
人員不足によるエンジニアへの負担過多
スタートアップに限らず、エンジニアは採用困難な状況が続いています。リソースが足りない中期限が迫ってくると「とにかくこの通りにつくってくれ！」と、ビジネス部門から降りてきた仕様通りに開発することで精一杯になってしまうことがあります。その状態が続くと、仕様を決める側と開発する側というように役割が分かれてしまい、まるで社内外注のように分断された状態になってしまうことがあります。
分断を解消する方向性
各社の事例を整理すると、BizとDevを解消する施策は、大きく３つの方向性にまとめることができました。（参考にした事例は下にリンクを紹介しています）
同じベクトルを向く
部門を超えた共通の目標を持ち、同じベクトルを向くようにします。部門ごとのKPIも持ちますが、共通目標とどう紐づくかを意識できるようにします。各社事例で見ると、強めのコンセプトやスローガンを立てている企業が見受けられました。また、気を抜くと分断の力学が働いてしまうため、フェイズの節目など継続的に啓蒙することが大事そうだと感じました。
- 事例）
- 「乳化」という全社的なコンセプト（READYFOR）
- 事業成長にコミットするエンジニア組織（リクルートライフスタイル）
相互理解を深める
密なコミュニケーションを促し、部門間の相互理解を深めます。上の「同じベクトルを向く」と比べると、こちらは現場から取り組めることが多いなと感じました。
組織編成で間をつなぐ
プロダクトごとのチームを作ったり、BizとDevをつなぐロールを持たせたりと、組織編成やロールを変える方法もあります。
- 事例）
- 目的別の組織編制（一休）
- PMMの設置（SmartHR）
各社の取り組み事例
私が調べた中で見つかった、各社での分断に対する具体的な取り組みを列挙してみました。ここではポイントを抜粋していますので、気になった方はリンク先から詳細を読んでみてください。こういった組織課題への対処は、どういった前提があり何をゴールとするかという文脈によって解は変わってくるものなので、あくまで一つの方法としてとらえてもらうのが良いと思います。
なぜSaaS組織に分断が起きるのか？「PLG Loop」で打破するセクショナリズムの壁
https://note.com/kota_sasaki_shr/n/ne2ad944e6478
SmartHRさんでは、部門間のセクショナリズムを解消するため、PMM（Product Marketing Manager）というロールを設置しています。PMMは「何が売れるか」「それをどう売るか」を考えるロールで、PdMとセットで、ビジネス側と開発側の各部門をつなぎ全体を連携させる役割を担っているとのことです。部門間の連携が希薄化することで起こる負のスパイラルの話も分かりやすく書かれていますので、とても参考になります。
事業成長にコミットするエンジニア組織への道のり
https://www.slideshare.net/RecruitLifestyle/ss-72258738
リクルートライフスタイルさんのケーススタディです。エンジニア組織の急拡大により社内エンジニアの価値が一時不明瞭に。ネガティブな声が上がる中で、社内エンジニアの意義を「事業貢献とそれを実現するための技術的成長」ととらえなおし、理想のエンジニア像を「技術×熱意×プロダクト理解」と定義されていました。そのための文化形成を重視し、プロダクト志向での開発文化を作ってきた取り組みが紹介されています。スタートアップではありませんが、エンジニア増員により起こるひずみを新規事業の中でトライアルで改善していった動きはスタートアップでも参考にできると思います。
READYFORが目指す「乳化」 への取り組み
https://tech.readyfor.jp/entry/2020/12/01/162301
READYFORさんでは「乳化」というおもしろい取り組みをされています。「乳化」とは「組織の中にエンジニアリングが自然に溶け込んでいる状態」を指し、ビジネスとエンジニアリングが対立するのではなく混ざり合うことで組織の価値を最大化させることを狙っています。「乳化」という概念を浸透させたうえで実現するために「ビジネスプロセスの可視化」「ミッションの共有」「日常をハックする」といった具体的な取り組みを行われています。
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち
https://www.amazon.co.jp/dp/B08GSQ4BL3/
書籍からの紹介です。VOYAGEグループさんのサポーターズという就活支援サービスの開発事例です。フルリニューアルのタイミングで開発組織からビジネス部門へ歩み寄り、社内外注のような関係を大きく改善した話が載っています。「事業に関するヒアリング」「物理的に対面で会う機会を作る」「開発側からも意見をあげる」といったことを行い、ビジネスと開発の距離を縮められたようです。
▽第五章 サポーターズ から引用
それまでの旧システムでは社内受託みたいな関係性だったものが、同じビジネスを共有する仲間になり、仲間なので言われたことに従うだけではないし、容赦しないし、その代わり互いに腹をくくってよいものを作っていく関係性になったというか。
“ITスタートアップあるある”「ビジネス」と「開発」の対立を回避するためにシェルフィーが行った５つのこと
https://www.wantedly.com/companies/shelfy/post_articles/24789
シェルフィーさんでは、サービスの成長に伴い、ビジネスサイドと開発サイドの共通認識が充分にとれていない状態に陥っていました。根本の問題は二者間の情報格差にあるととらえ、社内の情報流通量を増やすため「エンジニアが営業に同行」「ビジネスサイドもGitHubを使用」といった全部で５つの施策を実施。結果として、プロダクトの改善サイクルを劇的に速めることに成功したそうです。
エンジニアとビジネスサイド間の課題改善の話
https://engineer.crowdworks.jp/entry/2021/04/02/102106
クラウドワークスさんのクラウドテックというサービスの事例です。エンジニアとビジネスサイド間の課題として、「サービスの障害・不具合の検知が遅いこと」「ビジネスサイドのエンジニア業務の理解不足」があり、前者は「リリース情報の共有」や「問題報告フォーマットの刷新」を実施。後者は、サービス特有の問題で、「エンジニア主導の勉強会」や「Q&Aチャンネルの作成」を行ったそうです。
おわりに
まとめてみて、銀の弾丸はないなと改めて思いました。部門をまたぐ問題なのでボトムアップだけでの解消は難しそうです。 自分がエンジニアリングマネージャーをしているので、エンジニアからの歩み寄りとしては、部門をまたぐ交流を増やすところから行うのが始めやすいところだなと感じました。事業や組織のフェイズによって対処療法は変わってきそうなので、meetyとかで経験者の方に聞いてみたいところです。
