chomeブログ

エンジニアリングマネージャーの備忘録です

プレイングマネージャーは悪手か?

■背景

いくつかのチームでマネージャーを経験する中で得た、プレイングマネージャーについての考えを整理してみました。以前は、マネージャーはマネジメントに専念すべきでプレイングマネージャーは人手不足を補う次善の策でしかないという考えを持っていました。ただ、いくつかのチームでマネジメント業務を経験する中で、プレイングマネージャーにもメリットがあり組織設計次第で取りうる選択肢になるという考えに変わりました。

プレイングマネージャーは悪手か?

◎成果が最大化できるかで考える

マネージャーの仕事はチームの成果を最大化させることです。そう考えると、必ずしもメンバーに任せるだけが正解ではなく、自分が動いた方が成果が出せる場合は動いても良いことになります。マネージャー自身のリソースは有限であるため、自分がプレイする割合とマネジメントにまわりメンバーに任せる割合を調整し、成果が最大化される塩梅を見つける必要があります。その時々で以下の方程式を解くようなイメージです。

成果を求める方程式

ただし、この方程式には時間軸は考慮されていません。眼の前の成果を優先しマネージャーがプレイし続けていると権限委譲が進まずメンバーの成長が阻害されてしまいうことがあります。上の方程式で言うと「メンバーのプレイスキル(定数)」がずっと変わらないことになり、そうなると長期的には成果が頭打ちすることになります。マネージャーがプレイングを担うことは短期的にはありですが、長期的な成果を考えると成長につながるようなタスクは極力マネージャーから手放していくべきだろうと考えます。

プレイングマネージャーはなぜ忙しいのか?

◎相反する動きが求められる

プレイングマネージャーは業務過多になりがちです。単純にやることが多いからといえばそれまでですが、私の経験上、相反する性質の動きが求められることで、物理的にも体感的にも忙しさが増していると考えます。

マネージャーに求められる動きは環境によって変わるのであくまで私の場合の話ですが、当時私がマネージャーとして求められていたのは、他のメンバーが成果を出しやすい状況を作ることでした。それには全体を俯瞰して見ながら社内調整などの細かいタスクをマルチに素早く打ち返すといった動きが必要でした。一方で、リードプレイヤーであることも求められており、他の人にはできない難易度の高い仕事を担当し、まとまった時間と集中を要する仕事をしていました。

前者と後者は真逆の性質の動きになっていたため、タスクの優先度付けも時間の確保もめちゃくちゃ難しくなり、結果、プレイヤー業務は残業時間に集中してやることでなんとかカバーしていました。くわえて、業務によってマインドを切り替えることのオーバーヘッドは大きく、体感的な忙しさも飛躍的に上がっていたと思います。まるで、ボクシング選手とセコンドとの両方を一人で担っているような感覚がありました。

前述の「成果を求める方程式」のところでメンバーの育成観点で長期的にはプレイングマネージャーは脱するべきと書きましたが、マネージャー自身の負担的にも、過度な疲弊を生むため長続きするものではないと考えます。

■専任マネージャーのジレンマ

◎現場感の喪失

ではマネージャーに専任できることは幸せでしょうか?

私もずっとプレイングマネージャーをしていたわけではなく、マネジメントに集中できていた時期もあります。その時はメンバーが成長し権限委譲も進んでいたこともあり、私自身はメンバーをサポートすることに集中でき、チームとしても成果が出ていたと思います。ただ悩みがなかったわけではありません。

しばらく自分で手を動かす業務から離れることで、メンバーの方が今のシステムに詳しいことが多くなっていくことに、淋しさと焦りを感じるようになりました。気持ちの問題だけであればまだ良いですが、現場の感覚が薄れることで技術的な判断やメンバーの評価がだんだんと難しくなっていきました。まるで技術の貯金が切り崩されていくような感覚がありました。

マネージャーであり続けるためには、現場感を失わないためのキャッチアップが必要となり、定期的にプレイヤーよりの動きに戻らねばならないというジレンマのようなものを感じました。 (最近マネージャーからICに戻る人の話をよく耳にしますが、あれはここに起因するところがあるのかなと想像します)

■一つの理想形

◎小さく優先度の低い「ささやかな作業」を担当する

プレイングマネージャーであることは、現場感を維持するのに良い方法のように見えます。ただ前述のようなリードプレイヤーの動きも求められるマネージャーだと、疲弊を生み長続きしません。

書籍「エンジニアのためのマネジメントキャリアパス」によると、管理者は管理業務のかたわら「バグの処理やちょっとした機能の作成」といったささやかな作業をするとよいとあります。ITスキルを維持し、現場の問題を察知することにつながるためです。また、ささやかな作業であれば、いざというときは優先度を下げ、管理者がボトルネックになることを避けることもできます。

前述のリードプレイヤーは、マネージャー自身が直接成果に貢献するアプローチでしたが、こちらの「ささやかな作業」を担当する方法は現場感を維持することで「マネージャーのマネジメントスキル」を保ち、長期的に高い成果を上げるアプローチだと言えます。

マネージャーは現場感・マネジメント力を維持する目的で小さく優先度の低い「ささやかな作業」を担当する、成長につながる難易度の高いタスクはメンバーに渡しチーム全体の成長を促す、という在り方が、長期的に安定して高い成果を出せる形であると考えます。

◎マネージャーオブマネージャー

では専任のマネージャーは必ず成り立たないものでしょうか?一つありうるのは、プレイングマネージャーをマネージするマネージャーオブマネージャーであれば持続可能なのかなと考えます。

専任マネージャーの問題は現場感の喪失にあると述べました。ただ、マネージする対象がマネージャーであれば、その接点は自分が専門とするマネジメントに関する判断や評価、壁打ちになることが主となるため、相手の方がいつの間にか詳しくなっているということが起きにくいのかなと思います。少なくとも全く話についていけなくなるということは無いはずです。プレイヤーをマネージする専任マネージャーよりも、ジレンマにはおちいらず長続きするのではないかと考えます。

採用難易度を踏まえるとそんなにマネージャー集められるのかという疑問もあるのであくまで理想形の話として、プレイングマネージャーをマネージするマネージャーオブマネージャー(長い!)はありではないでしょうか。

■おわりに

プレイングマネージャーについて考察してみました。コア業務を担うようなプレイングマネージャーは、短期的にはありだが、育成観点と難易度の高さから、長期的には脱するべきであるという考えを述べました。一つの理想形として、「ささやかな作業」をするプレイングマネージャー、およびマネージャーオブマネージャーの形を提示しました。

理想の形を書いたものの、昨今のエンジニア不足を考えると、チーム内のできるエンジニアがマネージャーに選ばれ、なし崩し的にマネジメントとプレイングを両立せざる得なくなることはあるあるだろうなと思います。採用や育成、長期的な組織設計で、プレイングマネージャーが無理を被らないチームにしたいものです。

EMが転職後の焦りと仲良く付き合っていくためにやったこと

こんにちは、エンジニアリングマネージャーの chome (@anachro3)です。この記事は Engineering Manager Advent Calendar 2021(その2) の20日目の記事です。

今年の10月に転職し、Baseconnect Inc.にエンジニアリングマネージャー(以下EM)として入社しました。初めての転職ということもあり、入社後に感じたこと試したことを書いてみます。

これはなに?

EMが転職後に感じた焦りと向き合い、焦りと仲良く付き合っていくために試したことをまとめた記事です。

私自身は今回が生まれて初めての転職でした。くわえて技術スタックもLAMP環境主体からRuby、React主体の環境に変わりました。マネジメントも前職で行っていたのはプロジェクトや運用チームのマネジメントが主で、エンジニアチームのマネージを任されるのは初めてという、変化の大きい転職でした。(正確にはまだマネージャー候補です)

新しい環境で2ヶ月を過ごして思うのは、想像していたよりも焦りを感じたということです。私自身、受け入れる側として転職者と向き合ってきた中で、入社後オンボーディング中の辛さは聞いていましたが、いざ当事者になってみると聞いていた以上だなと感じました。

日増しに焦りがつのっていく日々に、私は思い悩み、自信が崩れ、自暴自棄になり、毎晩酒に逃げるように・・・ということには全くならず「え、何この感情?めっちゃレアじゃん!貴重な体験やし自分自身を観察して対策を立ててみよう!」と、何でもネタにしようとする関西人のノリが発動しました。

転職後の焦りがどこから来るかを自分なりに整理し、自己のはたらきかけで解消できるものとどうしようもないものを分類し、解消に向けたアクションをとってみました。これからEMを目指す人や、エンジニア部門の人事担当者の方に参考にしてもらえると幸いです。前提として、EM職の場合の事例であることにご留意ください。

転職後の焦りはどこから来るか

まず、自分が転職後に感じた焦りの要因を分類しました。

①マネジメントされる側になるギャップ

新しい職場ではオンボーディングを丁寧に行ってもらいました。どの領域で力を発揮していきたいかのすり合わせや、エンジニアとしての社内ルールのレクチャーなど、部門長とオンボーディング担当者に丁寧にみてもらえる環境でした。それは良いことのはずなのですが、困ったことに、丁寧に接してもらうほど、前職では自分が行っていたマネジメントを自分が受けていることにギャップを感じ、もどかしさがありました。職業感の中でのアイデンティティが無くなるような感覚でした。

②情報を持っていないことによる不安

マネージャーの仕事に一つに「情報を活かすこと」があります。書籍「HIGH OUTPUT MANAGEMENT」ではマネージャーがすべき行動として、現場での情報を収集し活かすこと、現場に必要な情報をもたらすことがあげられています。前職でも、経営層と現場、クライアントと自社、メンバーの間に立ち、情報をつなぐ動きをしていた感覚があります。

転職後は、当たり前ですが、事業のことも組織のこともプロダクトのことも、さっぱりわからないことばかりです。これは、マネージャー職にとっては、まるで武器をもたずパンツ一丁でモンスターがいるフィールドに立っているような感覚です。マネージャーにとって何をするにしても情報が足場になることを認識しました。

③期待値の大きさ

入社後、経営層やメンバーと話していくうちに、嬉しいことに思ったよりも期待をいただいている事に気づきました。もちろん、ポジションに限らず中途入社者は何かしらの期待があって採用されているので、期待されるのは当たり前です。また、雰囲気から感じてそう思っているところもあるので、実際のところの期待値はわかりません(自意識過剰かもしれません)。

ただ、リップサービスもあるとはいえ「これまでの豊富なプロジェクト経験を活かして〜」といわれれば「いやそこまで豊富でもないんだけどな・・・」と思ったり、「これまでのうちのやり方に縛られずに新しいことを〜」と言われると「いやまだ現状を知るのに精一杯なんですけど・・・」と思ったりして、期待が先走っているような感覚をうけました。この期待値のギャップは、採用面談の時に受かるために自分を良く魅せようとしていたことが要因なので、身から出たサビ、起こるべくして起こるギャップではあるのですが、正直プレッシャーは感じます・・・。

④結果が出るまでの期間の長さ

入社して2週間ほど経つと、徐々にですが、1on1や開発フローの改善検討、エンジニア採用といった具体的な仕事を任せてもらえるようになりました。ただ、こういったマネジメント系の業務はすぐには結果がでず、結果がでるまで数ヶ月とか一定の期間がかかるものです。

開発系のタスクも一部担っていたので、「あいつ何もしてなくない?」と思われないためにより早くプルリクを出そうともがんばりました。ただ、EMとして求められているのはそこではないよなー、と、プルリクを出せば出すほどEMとしての結果がすぐに出ないことにもどかしさを感じました。

⑤関心事の多さ

EMの職務領域は明確な定義はなく企業によって変わるところですが、一般的には広くなりがちです。広木大地さんの「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」で定義される強いEMを求めてしまうと、エンジニア部門のマネージに加えてプロジェクトやプロダクトについても働きかけが必要になり、関心事はかなり多くなってしまいます。

私の場合は組織自体が変化のタイミングということもあり、EMとして何をしていくか領域を絞らず進めながらすり合わせていく事になっていました。くわえて技術スタック自体が変わるため、基礎的な技術領域の再勉強も必要になり、関心事の多さにプチパニックでした。

焦りと仲良くするためにやったこと

次に、焦りの要因に対して、どういうアクションが取れるかを考えました。

情報が集まる場に行く

まずは組織のことを知るのが大事だと思い、自分から情報収集の機会をつくるようにしました。具体的には、自分がアサインされていないプロジェクトや他部門のミーティングに、情報が集まっていそうだと思えば許可をもらって参加していました。入社してしばらくは時間的余裕があったのでできたことです。

特にプロジェクトふりかえり会への参加は、これまでの情報が凝縮されており開発プロセスの課題感がつかめたのでとてもよかったです。直近では、メンバーのGoogleカレンダーを見て面白そうなミーティングがないかを探るのが日課になっています。

また、部門長のはからいで、営業や企画といった他部門の方との1on1の機会を作っていただき、これも部門間の連携の課題を掴むのに非常に役立ちました。部門を超える調整になるので会社によっては難しいかもしれませんが、はたらきかけてみる価値はあると思います。

注力する領域を絞る

情報が集まってくると、少しずつ開発部門の解像度が上がり、課題感がわかるようになってきました。組織的な課題や技術的な課題の全てに手を広げてしまうと中途半端になることは見えていたので、注力するポイントを絞ることにしました。

前述の広木大地さんの記事を参考に、EMの4象限の中から、自分がやりたいこと・できることと、開発組織にとって必要なことの重なる部分がどこか考えました。私の場合、デプロイや品質周りの課題に対して自分の経験が活かせるイメージがあったので、特にプロジェクトマネジメントに注力しようと考えました。

自分の中で比重を置くところを明確にしたというだけですが、それだけでも関心事の優先度が整理でき、頭をすっきりさせることができました

メンバーからの期待値を不要にあげない

1on1の機会があったので、自分が得意なことに加えて、苦手なこと、やっていきたいことがあるが中長期的にはなることを伝えるようにし、期待値の調整を行いました。

また、メンバーには「EMに期待していることを聞かない」ように注意していました。期待をメンバーに聞いても全てに応えられるわけではなく、応えられなかった時にがっかりさせてしまうためです。1on1では課題感を探るようにし、組織の目標と合わせて何ができるかを考えることを大事にしました。

※ この「期待していることをメンバーに聞かないようにする」やり方は、Meetyで面談させていただいた西場さんからアドバイスいただいたものです(その節はありがとうございました!)。Meety では転職前にEMのキャリアについて複数の方にご相談させていただき、アドバイスをいただきました。こういった面談ツールの活用も転職の不安解消の方法としてオススメできます。

焦らずに焦りを受け入れる

ここまで3つ対策を立ててみましたが、焦りを解消しきるには十分ではありませんでした。ただ、やれることをやってみると、あとはもう時間が解決するのを待つしかないなと気持ちを切り替えることができました。それまでは焦ることをネガティブに捉えていましたが、無理に焦る気持ちを否定せず、「ちょっと焦るくらいがちょうどよいよね」と焦る自分を認めるようなスタンスでいることが、バランスがいいなと思うようになりました。

転職者からするとまわりの評価は気になるものですが、受け入れ側からすると意外と急かす気持ちはなく、中長期的に活躍してくれることを期待しているものです。当事者がそのマインドを持つのは難しいですが、私の場合、以下の記事が気持ちを切り替える助けに非常になりました。

note.com

終わりに

EMとして転職した後に感じた焦りと向き合い、やってきたことについてまとめました。転職後の焦りにはいくつかの要因があり、それを紐解いていくだけで少し心の安定を得ることができました。手を打てることは打った上で、どうしようもないことに対しては、焦らずに焦りと長期的に付き合っていく思考になることが肝要だと学びました(タイトルの“仲良くする”はここから来ています)。

初めての転職は、不安だけではありません。新しい職場では、エンジニア同士が助けあう雰囲気があり、ご多分に漏れず助けてもらっています。社内勉強会も盛んで、私自身、入社1週間目でLTする機会があり、刺激を与え合う環境があります。総じて、挑戦することを楽しむ雰囲気の中で前を向いて仕事ができています。

また辛いことがでてきたらネタにして、長期視点でやっていこうと思います。

BizとDevが分断するメカニズムと、各社の取り組み事例

背景

以前、転職活動を行っていた際に、ビジネスサイドと開発サイドとの分断を課題にあげているスタートアップ企業が、少なからずありました。こういった分断は大企業で起こるイメージを持っていたため、少数でスピーディに動くことが求められるスタートアップでも起きていることは意外に感じました。各社共通の課題なんだなと気づき興味を持ち、分断が起こるメカニズムや対処方法を書籍やブログ記事から調べてみました。

調べてみると、事例としてはよく散見されるものの、分断に対してあまり明確な打ち手は出ておらず、企業ごとに試行錯誤が行われているという印象を持ちました。また、この問題に対して共通のキーワードが定義されておらず、いくつかのキーワードを駆使して検索する必要があり、思いのほか大変でした。

自分の理解の整理と備忘録として、「ビジネスサイトと開発サイドの分断」というテーマで、調査した内容をまとめてみました。自分なりの理解をまとめたものですので、ご指摘・マサカリ・マシュマロ大歓迎です。なお、この分断はスタートアップに限らず起こるものですが、調査範囲を限定するため、スタートアップを前提とした調査とします。

BizとDevの分断とはどういった状態か?

「BizとDevの分断」とは、営業やマーケティング、企画といったビジネスを担う組織と、エンジニアやQA、SREといったプロダクトの開発からデプロイを担う組織とで、互いの組織間で目的のずれや情報の遮断が起こり、大きな溝ができた状態を指します。別の言葉では、セクショナリズムとかサイロ化とかで表される状態です。BizとDevの分断が起こると、スタートアップ組織として以下の不利益が生じます。

BizとDevの分断により起こる不利益

部分最適化により全体の目的を達成しづらくなる

KPIが部門ごとに設定されることで、全体最適ではなく、部門ごとの最適を追いかける構図になり、結果、全体の目的から遠のくということが起こります。場合によっては、営業と開発が敵対し足を引っ張りあうような問題がわかりやすく表出することもあります。

  • 事例)
    • 営業目標達成のため無理な開発スケジュールが組まれてしまい、エンジニアが疲弊する
    • 「期限内に仕様通りに作ること」が目的になり、使いやすさ等の非機能要件が犠牲になる

情報の滞留が質の低下、スピードの低下を招く

部門間での情報の遮断が起こると、エンドユーザー側の学びとプロダクト側の学びが上手くつながらず、PDCAの質が下がってしまいます。また開発側の情報がタイムリーに共有されないことで営業の機会損失を招くこともあります。

  • 事例)
    • Biz側の課題感とDev側で見ている情報がつながらずPDCAが回らない
    • リリース内容がBiz側に伝わらずタイムリーに営業に活かせない
    • サービスの障害・不具合の検知が遅い

エンジニアのモチベーションの低下

BizとDevの分断が行き過ぎると、ビジネスサイドから降りてきた仕様通りにただ開発するだけという、社内外注のような状態になることがあります。エンジニア目線で見ると、エンドユーザーから距離があり目的や成果が見えづらいプロダクト開発は、モチベーション低下の要因になります。イソップ寓話「3人のレンガ職人」の話でいうところの、ゴールである大聖堂をイメージして働く職人ではなく、ただレンガを積み上げるだけの職人になってしまいます。

分断を加速させる力学

なぜスタートアップ企業でBizとDevの分断は起こるのでしょうか?一般的にセクショナリズムは、部門間の交流の少なさや行き過ぎた成果主義により縄張り意識が生じて陥るものとされています。さらにスタートアップの場合、BizとDevの分断を加速させる力学が3つあると考えます。

シード期以降の急激な組織拡大

もともと少人数で始まるスタートアップですが、PMF(Product Market Fit)後やまとまった資金調達ができた時などで、チャンスを活かすために急激な組織拡大をはかることがあります。分断を気にしなくてよかった状況から、人員増加と組織構成の変更が一気に進むため、ビジョン浸透やコミュニケーション設計が間に合わないことで分断が起きやすくなってしまいます。

効率を求め細分化された組織編制

スタートアップの組織編成には定石のようなものがあり、規模に応じて役割ごとに組織を細分化していく企業が多いように感じます。例えば営業部門であれば「マーケティング」「インサイドセールス」「カスタマーサクセス」、開発部門であれば「フロントエンド」「バックエンド」「SRE」「QA」に分かれるといった感じです。だんだんと縦割りの細かい組織編成になっていくことで、組織間の連携がしづらい状況が生まれてしまいます。

人員不足によるエンジニアへの負担過多

スタートアップに限らず、エンジニアは採用困難な状況が続いています。リソースが足りない中期限が迫ってくると「とにかくこの通りにつくってくれ!」と、ビジネス部門から降りてきた仕様通りに開発することで精一杯になってしまうことがあります。その状態が続くと、仕様を決める側と開発する側というように役割が分かれてしまい、まるで社内外注のように分断された状態になってしまうことがあります。

分断を解消する方向性

各社の事例を整理すると、BizとDevを解消する施策は、大きく3つの方向性にまとめることができました。(参考にした事例は下にリンクを紹介しています)

同じベクトルを向く

部門を超えた共通の目標を持ち、同じベクトルを向くようにします。部門ごとのKPIも持ちますが、共通目標とどう紐づくかを意識できるようにします。各社事例で見ると、強めのコンセプトやスローガンを立てている企業が見受けられました。また、気を抜くと分断の力学が働いてしまうため、フェイズの節目など継続的に啓蒙することが大事そうだと感じました。

  • 事例)
    • 「乳化」という全社的なコンセプト(READYFOR)
    • 事業成長にコミットするエンジニア組織(リクルートライフスタイル)

相互理解を深める

密なコミュニケーションを促し、部門間の相互理解を深めます。上の「同じベクトルを向く」と比べると、こちらは現場から取り組めることが多いなと感じました。

  • 事例)
    • 物理的に席を近づける
    • エンジニアが営業に同行する
    • SlackでのQ&Aチャンネルの作成
    • エンジニア主導の勉強会開催
    • Githubなど共通のツールを使う

組織編成で間をつなぐ

プロダクトごとのチームを作ったり、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スタートアップあるある”「ビジネス」と「開発」の対立を回避するためにシェルフィーが行った5つのこと

https://www.wantedly.com/companies/shelfy/post_articles/24789

シェルフィーさんでは、サービスの成長に伴い、ビジネスサイドと開発サイドの共通認識が充分にとれていない状態に陥っていました。根本の問題は二者間の情報格差にあるととらえ、社内の情報流通量を増やすため「エンジニアが営業に同行」「ビジネスサイドもGitHubを使用」といった全部で5つの施策を実施。結果として、プロダクトの改善サイクルを劇的に速めることに成功したそうです。

エンジニアとビジネスサイド間の課題改善の話

https://engineer.crowdworks.jp/entry/2021/04/02/102106

クラウドワークスさんのクラウドテックというサービスの事例です。エンジニアとビジネスサイド間の課題として、「サービスの障害・不具合の検知が遅いこと」「ビジネスサイドのエンジニア業務の理解不足」があり、前者は「リリース情報の共有」や「問題報告フォーマットの刷新」を実施。後者は、サービス特有の問題で、「エンジニア主導の勉強会」や「Q&Aチャンネルの作成」を行ったそうです。

おわりに

まとめてみて、銀の弾丸はないなと改めて思いました。部門をまたぐ問題なのでボトムアップだけでの解消は難しそうです。 自分がエンジニアリングマネージャーをしているので、エンジニアからの歩み寄りとしては、部門をまたぐ交流を増やすところから行うのが始めやすいところだなと感じました。事業や組織のフェイズによって対処療法は変わってきそうなので、meetyとかで経験者の方に聞いてみたいところです。