エンジニアがビジネス組織に移ることのススメ

こんにちは。
プレイドでビジネス組織の中でエンジニアをしているharada_hiです。
このnoteではビジネス組織のエンジニアについて書いています。同僚との会話の中でそうした動きは独特だという話がきっかけとなっています。

このnoteの主な対象者としては以下の方々を想定しています。
・キャリアに悩んでいるエンジニア
・ビジネス側に興味のあるエンジニア

そうした方々にこうした考え方・動き方も面白そうと少しでも思っていただくことが目的です。またビジネス組織で既に活躍する方々にもこうしたポジションがいると面白いのではないか？と考えていただくきっかけにもなれば幸いです。

ビジネスエンジニアの区分けと今回のポイント

ビジネス組織のエンジニアにも2種類存在していると考えています。社外向け / 社内向け という方向性による分け方です。

社外向けビジネスエンジニアは世の中的にはCRE(Customer Reliability Engineer) / Product Specialistと言う呼称が使われるポジションです。私は社外向けのビジネスエンジニアとして動くことも多いですが、今回は社内向けのビジネスエンジニアに関して触れさせていただきます。

社内向けビジネスエンジニアの呼称は明確には存在していません。
最も近いのはコーポレートエンジニアであると考えています。ただし情シスの延長線上としての在り方ではなく、あくまでビジネス組織に所属しているという点が大きな違いです。以下が整理している図です。

緑に色付けしているのがビジネスエンジニアです。プレイドでは社内向けのビジネスエンジニアを暫定的にBusiness Growth Engineerと呼称しています。
コーポレートエンジニアとの大きな違いは矢印の向き先の違いです。全社に向いているか、あくまでビジネス組織に向いているかの違いです。

なぜ社内向けビジネスエンジニアは必要か？

エンジニアがエンジニア組織外に関わることは運用改善において大きなメリットがあることです。
エンジニア組織はテクノロジーを使った運用改善を最も効率良く進めることのできる組織です。これは所属しているエンジニア自身がテクノロジーに対してのプロフェッショナルであるためです。

当然エンジニア組織以外の組織でも運用改善は行われ続けています。ただしシステムを入れた自動化やその効率という点でエンジニア組織と大きな差が発生しているはずです。これはエンジニア組織にいると気付かないポイントではないかと考えています。
エンジニアの常識は世の中の非常識となっていることは往々にして存在しています。

究極的な理想はエンジニアメンバー以外もエンジニアリングできるようになることです。ただし、それは非常に難しいことです。一定の知識の習熟はできたとしても、それを使いこなすことや適切に設計すること、には大きな壁があります。エンジニアとしての経験があるからこそ対応できる領域は必ず発生します。

上記の整理はあくまでもエンジニア組織以外にエンジニアがいると良いという話でした。その上でビジネス組織への必要性について触れていきます。
理由としては大きく以下の２つです。

1つ目はビジネス組織の活動が多様であり型化が難しいものが多い点です。
どういった人を対象にして営業を掛けていくか？カスタマーサクセスの中でどういったクライアントが解約しそうなクライアントか、それぞれの効果測定はどうすれば良いか？
これはビジネスの種類によって全く異なるものであり、それをすべて綺麗に解決する手段はありません。

2つ目は組織の人数比です。事業がうまくいくと企業の中の人は増えます。
その中で一番人数を占めるのは一般的にはビジネスメンバーです。そして人が増えれば増えるほど、小さな負が大きな負に繋がります。例えばオペレーションが煩雑で毎日1時間かかるものを仕組みによって半分にできるとします。そうすると対象者が16人いれば、1人分の時間(1日8時間)が生まれることになります。
ここまで時間に作用する露骨なものは早々存在しません。ただし煩雑なオペレーションが無数に存在する状態は人のウィルパワーを削る大きな要因になります。

ここまでで
・ビジネス組織の運用改善を最大化することは意味がありそう
・それを進めるに当たってエンジニアが関わることは意味がありそう
という点に触れていきました。
ただしこの整理は今回noteを書くにあたって整理直したものです。
元々はプロダクトエンジニアとしてプロダクトが適切に届くにはビジネス組織が強いほど良いだろうという考えがスタートとなっています。
プロダクトは作って終わりでも届けて終わりでもなく、しっかり使ってもらうことで価値になると考えています。この使ってもらうという部分は人の力が最も重要となるところです。その人の力を適切な箇所に最大化できるような環境を作ることはとても重要だと考えています。

実際にどういう動き方をしているか？

実際にこれまでどう動いてきたのかに関して触れていきます。
最も意識したのはチームの中に入ることです。

先程の図ですが、この形は前述のビジネスエンジニアの違いを伝えるために整理したものなので微妙に実態と乖離があります。この図ではBusinessGrowthEngineerがSalesやCustomerSuccessは違うチームに所属しているような形になっています。このような形は現状取っていません。

こちらが正しいイメージです。伝えたい点は同じチームに所属しているということです。

これは以下の目的からそうした手段を取っています。
・業務の背景や前後のオペレーションを適切に理解する
・運用が適切に回るところまで進める

前者に関しては、業務Aを改善したいと言った話が上がった際にAのことしか知らないとAに10掛かっていたことを3にするという話になりがちです。そもそもAの前に存在する業務Bを改善すればA自体をなくせるというのは業務を理解していないと出てこないポイントです。これ自体は別のチームで動いていても業務をヒアリングして整理すれば対応できることです。ただし同じチームで事前に理解しているとまた違った話が言えます。そもそも業務Aを改善したいと言った話を出せるかどうかです。分かりやすい負の課題に関しては上がってきやすいですが、完全に新しいことや大きく問題になっていないことに関しては非常に捉えにくい問題です。これをエンジニアの視点で業務を理解していることで、そうした課題を見逃さないことが目的です。
後者に関しては、運用改善のために何かを作ったとしても作っただけで終わっては意味がありません。何かを作ったものが使われる。そのうえで運用に乗るところまで微調整を効率よく進めることが目的です

同じチームに所属するという形が絶対に正しいとは考えていません。組織の規模・種類によってはこの構成が適さないケースは十分に考えられます。当然プレイドでも上記の体制をすべてのチームで取れているわけではありません。あくまで本質は「背景や前後のオペレーションを適切に事前に理解する。運用を回すところまで進める」という部分です。これを満たす最も良い手段が現段階では同じチームであるということです。

どういう人が向いていそうか？

業務フローの整理が好きな人が向いていると考えています。向いていると考えています。その上で、最も効率の良い改善の道筋を描けるというポイントも重要だと考えています。社内オペレーションであれば、理想を突き詰めて改善まで時間が掛かるよりも短時間で一定の形というのが重要になる場面が多いかと考えています。＊当然そうしたものばかりではないです。
その他の趣向も様々考えられますが、一番はこの点が大きいかと考えています。
スキルに関してはどういった会社かによって大きく変わるとは思いますが、データを設計するという点だけは必要になるかと考えています。現代においてビジネスのデータ化が加速度的に進んでいるというのを否定する人はいないかと思います。今回整理してきたポジションはそうしたビジネスのデータ化に最も携わる可能性が高いです。それを考えると最低限データを扱うことにアレルギーがないということは必要だと考えています。

まとめ

今回書いた重要な点をまとめます。

1. 必要性について
　・ エンジニアが入ることで運用改善を加速させることができる
　・ ビジネス組織はその特徴(難しさ/人数)から特に運用改善の価値が大きい
2. 動き方について
　・ 業務の背景や前後のオペレーションを適切に理解できるようにする
　・ 運用が適切に回るところまで進める
3. どういう人が向いているか？
　・ 業務フローの整理が好きな人
　・ データを設計できる人

私自身、この領域に関して思考しきれているわけではありません。
同様のことを進めている方やこの領域に関して興味を持たれた方がいましたらtwitterでDMなどいただければと思っております。