やさしい「事業がわかるエンジニア」入門
副業や本業で経営者の方や様々な管理職の方々と話してきて「事業のわかるエンジニアがほしい」という言葉を耳にすることがあります。一方でメンバーや社外の人と話していて「事業がわかるエンジニアになりたい」ということを聞いており、「ほしい側」「なりたい側」が存在し、それぞれ概念としてて言わんとすることはわかりつつもズレているなと感じることや言語化が足りないと思うことがよくあります。
ほしい側もなりたい側ももっと言語化してほしいな〜と思うので「事業」の意味するところ・なにを「わかる」べきなのかを私なりに分解していこうと思います。
「事業」とは何
事業とはなんぞや。そもそも定義を見てもよくわからないものでしゃべるなというのもあるんですが、一般的なインターネット企業などで思いつくだけでも以下のようなものがあると思います。
・「売上や利益」を指す
・「原価やコスト」を指す
・「上記に関する副次的なKPI（有料化率・退会率など）」を指す
・「運営方法や利益構造」を指す
・「市場や業界構造」を指す
etc...
言う人・状況・背景によって指しているものはバラバラです。
なのでそもそも言葉自体は何を示しているか、解釈や表現が異なってきます。理解をすすめるために 「事業」 という言葉から一歩踏み込んで表現するだけでも
・「売上や利益」のわかるエンジニア
⇒ PLやBSを理解し、運用・改善できるエンジニア
・「原価やコスト」のわかるエンジニア
⇒ コスト・リソース関心が高く削減や管理ができるエンジニア
・「上記に関する副次的なKPI（有料化率・退会率など）」のわかるエンジニア
⇒ PM,PdM的にプロジェクト・プロダクトの追うべき数値を管理・改善できる エンジニア
・「運営方法や利益構造」のわかるエンジニア
⇒ ドメイン知識を理解して、管理・改善ができるエンジニア
・「市場や業界構造」のわかるエンジニア
⇒ 客観的に事業戦略に意見を出し、取るべき施策を判断・実施できるエンジニア
というような感じで、それぞれが大きく異る意味を持つことがわかります。
・コスト・リソース関心が高く削減や管理ができるエンジニア
・PM,PdM的にプロジェクト・プロダクトの追うべき数値を管理・改善できる エンジニア
という2つを取ったとしてもそれぞれに求められるスキルやマインドは異なるため、意味を明確にしないと「ほしい側」にとっても「どう育成・採用したらいいか謎」、「なりたい側」にとっても「何を目指せばいいかが謎」という非常に不幸な状況になります。
なのでどちらの観点でも、
「事業」がわかる ＝ 「何」がわかる
を明確にする必要があります。この「何」に着目して考えてみましょう。
「ほしい側」の観点
「事業」がわかる＝「収益・経営・組織」がわかる・関心がある
ほしい側には経営者・管理職・プロジェクトやプロダクトの責任者などが多いと思います。彼らが求めている事業のわかるは「収益・経営・組織」がわかる・関心のあるエンジニアを指していることが多いように思います。
case１. マジ困り
彼らがは会社・プロジェクト・チームをリードするときに発生し、かつ一人で解決困難な課題を常に抱えています。これを助けてもらいたくて思わず「事業がわかるエンジニアがほしい」と口にしてしまう場合があります。
特に上記「何」における１つだけの問題を抱えていることは少なく、基本的に複数の問題を抱えているため、まるめて「事業」という言葉を使ってしまっているように思います。
これらを解決するエンジニア的役割は「CTO」「VPoE」「EM」などのようなポジションです。組織を俯瞰して経営層・事業管理者との橋渡し・意思決定をする役割を担います。なのでこのポジションがいない・作れていない・あるけど権限移譲しきれてないケースがこのケースです。
case 2. 組織全体の事業への関心を高めたい
どうしても職責・技術に集中するとプロダクトへの関心や、数字がどこか他人事になってしまう問題があります。。ここに課題感を感じているときもこの言葉を聞きます。 これを聞くと「選択と集中」「技術のわかる経営者」のような言葉が頭をよぎりますが、プロダクトやビジネスモデルに対してエンゲージメントの高い状態を作りたいというのはすごくよく分かる話です。
誰でもみんなで納得感を持っていいもの作りたいじゃないっすか、音楽の方向性合わせていきたいじゃないですか・・・というのは建前で「関心」というのは単純に「問題の早期解決」「効率的な情報伝達」を作ることができるので、プロダクトやプロジェクトを効率的にすすめるために関心を参加者に上げてもらうことは自然なことだと思います。
どんなにスキルがあっても、技術的に素晴らしくともプロダクトやビジネスモデル、マーケットに関心を持った人じゃないと0から全部説明する必要が出てきてチームとしては効率悪く感じることもあり、その実、組織意識に課題を感じているケースがこれです。
「なりたい側」の観点
「事業」がわかる＝「何かしらの数値に何かしらの方法で貢献する方法」がわかる
なりたい側には主にプレイヤーとして活躍するエンジニア、ある程度一人で開発やリリースまでこなせて保守も経験した人が次のキャリアを考えて言うことがあります。ここで意味することは「何かしらの数値に何かしらの方法で貢献する」など結構ふわっとしていることが多いです。ただこれは全然悪いことではなく、当たり前でそれまで必死にエンジニアリングに食いついてきて勉強してきた人が急に「どうやったら数値の貢献できますか？」などと言われてもハードルは低くないと思います。
言語化のステップ
まずは「ほしい側」でも出てきた自分の「関心」を持てる数値を探すのが良いと思います。ベロシティ・レスポンスタイム・障害件数・売上・利益率・原価・継続率・インフラコスト・稼働率・・・思いつくだけでもエンジニアリングは数値に囲まれています。
数値は正直なので向き合い続けることは最初は困難なので、まずは自分の裁量でも改善できるものや、面白そうだと思うものを探して小さくPDCAを回しましょう。あまり最初から失敗し続けちゃうと数値にアレルギーが出ちゃうので向き合い続けられるように小さく失敗しましょう。
次にそれを改善する意図や目的、必要性を関係者とすりあわせつつ、適切にそれが観測できる状態を目指す必要があります。。数値は正直ですが、人が作るものなので前提を間違えたりするとすぐ有意性が失われます。
そしてそれを改善するPDCAを実行しましょう。一発で数値が改善することなんて殆どないのでどんどん失敗してください。リスク管理は赤ちゃんのうちは偉い人に任せましょう。（ちゃんと話した上で）
最後はそれを振り返って、成功体験・失敗体験を言語化して自分のキャリアに積みましょう。それはきっと再現性があって価値のあるものです。
この工程は自分に主眼をおいていますが、PdMやPM、経営者においてもスコープや結果のサイズがことなるだけで刻むべきステップは親しいものがあります。この数値のPDCAサイクルの規模をどんどん大きい規模で回せるようになることを目指すことが大事です、そこから逆算して必要なスキルや経験を積んでいってください。小さい規模でこれができない人が急にPdMやPMに抜擢されることはよっぽどその組織が人に困っているか、ソフトスキルがエグい高いかしかないです。組織におけるポジションは与えられるものじゃなく、作り・取りに行くものだと考えるとキャリア形成がしやすくなると思います。
最後に
「事業がわかるエンジニア」、この言葉の周りには「ほしい側」「なりたい側」が存在してそれぞれ意味することが異なること、そこにたどり着くためにどうすべきか、への私の理解を書いてみました。
「ほしい側」「なりたい側」が同じ組織にいる場合は、それぞれが歩み寄って「関心」を作り合い、ポジションを考えそれを実現することがEMとしてのミッションかなと思うので、私もがんばっていきたい所存でござる。
この記事が気に入ったらサポートをしてみませんか？