見出し画像

エンジニアの定着と活躍／BizとDevの高い壁はどこから来るのか

久松剛／IT百物語の蒐集家

（一部にはPjMも居ますが）基本的にはメンバーとして生きていく誓いであるフリーランス。出世に興味のないことによる中間管理職離れ。過去の技術や制度といったしがらみから解放されることを願っての0-1のSeed期スタートアップ。ITエンジニアを取り巻くメンバーとして生きていくという風潮の強さと、それができてしまうご時世があります。

この潮流に対し人材が出ていく側の企業は、現職に留まる意味づけや理由付けをしていかなければなりません。人材が流出する企業の特徴としては「正社員雇用している間はどう使っても大丈夫だ、マネージメント（管理）しよう」という発想が根底に流れています。昨今の状況を見るに企業が大好きな若手20代の転職具合は体感として1-2年が平均的に思われますし、違和感を感じたらより短い数ヶ月で転職します。経営層はエンジニアに対してサービスに関わることの意味づけと、それに関わることで自己がどう成長できるのかという発信は継続しなければなりません。

一方で、Seed期スタートアップに転職したエンジニア達がうまく行っているかと言うと、プロダクトを作りたいディレクターと実装者としてのエンジニアの間に隔たりがあり「思うようにエンジニアが動いてくれない」「エンジニアと意思疎通ができない」という声がそれらの経営者から聞こえてきます。8/30月にこのあたりについてのお話をベンチャーキャピタルのANOBAKAさんとします。

こうしたエンジニアの定着、活躍という観点から考えていくと企業の大小を問わずBizDevのサイクルを回す繋ぎこみに帰着するように思います。今回のテーマはBizとDevの壁についてです。

Bizは顧客を見るが、Devは実装物を見る

よくある一般的な開発サイクルについて、BizDevの概念と共に図示したものが下記になります。まずはこの各要素についてお話していきます。

BizDevの高い壁 (1)

顧客の定義と距離

一般的にはDevが顧客と直接やり取りするケースが少ない場合が多く、顧客との距離が問題になりやすいです。

「ユーザーの顔が見たい」とおっしゃる方の中には、toCの一般ユーザーのみが顧客だと思っておられる方が一定数居られるのですが、そのようなことはありません。

toBであれば納品先が顧客です。私も現在のクライアントワークでは、必ず実装者に納品物を受け取った責任者の方から総評を頂くようにしています。間に数社挟むと顧客までの距離が遠くなり、感想の回収コストが上がります。

社内システム開発であれば利用部門が顧客です。営業部門だったりマーケティング部門だったり、バックオフィスだったりと色々な顧客が存在します。

いずれの場合でも、既存事業で収益が上がっていれば何かしらの顧客は居ます。顧客がついていないのは新規事業やスタートアップのみです。新規事業やスタートアップは仮想顧客を想定して動くので、実態がありません。たまに「顧客の声が聞きたい」とSIerからSeed期スタートアップに行く方が居られるのですが、ちょっとよく分からないです。

一般的なBizのお仕事

顧客のヒアリングをし、課題を明確化するコンサルティング。

課題を元にした提案。

提案に対する顧客からのの合意、受注。

ここまでが一般的なBizのお仕事です。

一般的なDevのお仕事

やりたいことを形にしていく上での要件定義。

開発に落とし込むための設計。

そして開発、テスト、リリース。

その後は運用フェーズに入りますが、運用に期待されることはプロジェクトによってマチマチです。

納品がゴールの受託型の開発であれば多くの場合はここで終了しますし、運用によるサービスの状態や顧客の判断を踏まえて次のループが始まることもあります。

BizとDevの高い壁

上記のサイクルで行くと、受注と要件定義の間でプレイヤーが変わるケースが多いです。

また、運用で得られたデータを元に次の企画をする運用とコンサルティングの間もプレイヤーが変わりがちです。

プレイヤーが変わることで自然とこれらの間には高い壁ができます。明確に役割を分けた形の一つとして「コンサル部」「企画部」と「開発部」の分断が発生します。これが世間的によく見られる「BizとDevの壁」です。

BizとDevの相互理解

DevがBizを理解するための本としては本コンテンツでもよくオススメしている下記のものになります。

一方でDevをBizが理解するためのコンテンツというのはあまり無いような気がしています。下記の2冊はおすすめです。

先の「エンジニアがビジネスリーダーをめざすための10の法則」のようにDevがBizに対して「もっとこうしないと駄目なんだ！」というスタンスの本はあまりないような印象です。BizとDevの相互理解の重要性は高まっていますので、本コンテンツでもその一助になればと思っています。

画像2

BizDevを繋ぐ研修始めました

詳しくは別のコンテンツに譲りますが、

・企業の状況・社内政治
・プロジェクトの状況
・人員の状況、スキルセット、キャリア
・評価制度、給与
・チーム編成
・採用経路
・退職理由
など

をヒアリングし、専門職も巻き込んだチームビルディング研修を作りまして実施しています。丁度あるベンチャー企業さんで第一回の2時間×2日で1セットを終了したところです。

今回のコンテンツで言うところのBizとDevを混在させ、お互いの視野や考え方を対話と相互理解をしながら合意形成をしていくコンテンツとなっております。「BizとDevが協力をして以下の障害情報を読み解き、経営層に障害報告をしなさい」というワークがなかなか好評です。ご興味がございましたらご連絡下さい。

執筆の励みになりますので、記事を気に入って頂けましたらAmazonウィッシュリストをクリックして頂ければ幸いです。
https://www.amazon.jp/hz/wishlist/ls/COUMZEXAU6MU?ref_=wl_share


頂いたサポートは執筆・業務を支えるガジェット類に昇華されます！