開発部隊は「イケてるBS（資産）を作る」のが仕事！
前部署でアプリ導入を検証した際
DX推進に反対する「現場レベルの理由」として挙がってきたのは以下のような理由であった。
❶デジタルを使いこなせれば便利になるのは理解できるが、「変えていくのは費用も時間もかかり、投下コストの回収見込みがつきにくい」
❷「通常の業務を行いながら移行するので、仕事の円滑な遂行を妨げる！
❸「現状の仕組みでも不自由なく間に合っているの で、無理して変える必要性がない」
などが多かった。
こうした声が発生する原因は、現場も管理者もDXに対して腹落ちできていないことにあると考える。
そもそも、DXを推進する主体者は誰なのでしょうか。現場の役割なのか、それとも経営者・管理者が担うべきものなのか。まずはDXという言葉から、DXの推進が誰の役割なのかを考えてみましょう。
DX推進は誰の役割？
「デジタル化」と
「トランスフォーメーション」のジレンマ
DXの概念は、「デジタル(化) 」と「トランスフォーメーション」という2つの単語から成立する。
・デジタル化：デジタルを活用した「業務改善」
→本来は現場主導のボトムアップで進めるべきもの
・トランスフォーメーション：事業や業務の「変革」→ トップダウンで全体像を描いて進めるべきもの
DXの推進で大切なのは、それがただの流行や現場レベルの改善ではなく「企業戦路のなかに位置づけられたものとして明確なビジョンが示されている」ということである。
私が働いていた当時、toC向けアプリの導入推進をしていました。当時はシステムの要件定義のことなど何もわからず、現場の立場として提案した時には、「なぜ顧客に求められるような機能を導入しないのか！」と思いましたし、元々レガシーな会計システムに不満を持っていたこともあり「なぜ会計ソフトと導入予定アプリのインターオペーラビリティを担保しないんだ！」と激オコプンプン丸になっていたものです。「せっかく僕たちが（売上を）作っているに・・・」
とよく話していました。
何よりも、顧客に求められている画期的な機能を導入しないのであれば現状のオペレーションに対して負荷のかかるシステムをわざわざ多額のお金をかけ導入する意味もわかりませんでしたし、当時自分が大変な苦労をして得た信頼や顧客情報を、じゃぶじゃぶシステムに投下され、しかも開発に対して行った機能要望は大して反映されないという状況に常に不満を抱えていました。
そんな中で、かつて自分が現場レベルとしてとして対峙していたアプリ導入側とは反対に経営企画室の同僚と社外のSIer側の方と私も同じ立場として携わることになりました。
逆の立場になると、今度は「いかに技術的負債を貯めないか」「いかに今後のビジネスに沿った機能開発ができるか」「いかに将来を考えた投資ができるか」といった、まったく違う文脈で頭を悩ませることになり、営業から上がってくる機能要望リストが全く違う景色になっていました。
こちらでは「せっかく僕たちが（システムを）作っていこうとしているのに・・・」と頭を抱えていました。
こうした両面での経験を得られたことに加え、その後複数の社外のSaaSプロダクトを開発する会社の方のお話を聞く中で「なぜ営業、現場部隊と開発部隊は意見が合わなくなるのか」を考えることが多くなってきました。
同じくプロダクトをを伸ばしていきたい！といったミッションは同じベクトルを向いているはずなのになぜこんなにも目線が違ってしまうのだろうか？と当時は疑問に思っていました。
また、「パッケージ発注の仕組みではなくアジャイル開発であればそうなっていなかったのか？」と考えましたが、他者が自社開発したプロジェクトでも大きさの違いはあれど似た問題が起こっていたり、自社開発しているスタートアップの知人のからも同様の話を聞くことが多くあり、そこだけが原因ではないのだという見解に至った。
ではなぜ同じベクトルであるはずの営業、現場部隊と開発部隊のすれ違いが発生するのか。
それは、それぞれが重視するものが「PL（売上/利益）」と「BS（資産）」で異なっているから
である。
開発部隊は「イケてるBS（資産）を作る」のが仕事であり、営業、現場部隊はそうして作られたBS（資産）から「PL（売上/利益）を作る」のが仕事だととらえています。
「Sales」機能はPLに責任を持つようにし、定量的な売上を目標として活動させる。主にプロダクトの提供価値が明確になった後のプロダクトのみ担当させる。（プロダクトの初期では資産価値向上を目的とするため、Salesはつけない）
「Business Development」機能はプロダクトの資産価値向上にビジネス面から責任を持つ。Product Managerと協働しながらプロダクトの初期の立ち上がりからPMF実現を目指す。
明示的に分けて組織してみると、Business Development機能の重要性が凄く良くわかる。「ビジネス面からプロダクトの資産価値向上させる」がよりシンプルになる。
また、赤字ベンチャーPMF前フェーズの技術シーズの調達費用の方がPMF後のBizDev組織構築の調達費用より断然高価になり
PMF後の資金調達は超イージー確変突入となる。今度は人材調達が成長のボトルネックになってしまう。
大企業の予算であれば、「再現性の高いものに投下される予算」と「再現性の低いものに投下される予算」がある。それは、「どの部署の予算から出ているか?」を見れば、すぐに判断がつきやすい。
大企業の組織構造の中で、新規事業部やR&D部門から出てくる予算は、「直接的に収益化しなくても最悪問題ない、リスク許容度の比較的高い予算」である。
取締役会決裁(短期目線での投資であって、取締役会が正しく機能としている前提)のものや、事業部やDXIT 事業部などからの受注こそ、再現性のあるトラクションと言えるのかもしれない。
PEファンド(バイアウト)、ベンチャーキャピタルがどのリスクをとっているかと同じで
三菱UFJ信託銀行
大企業の中でも、部門によってどのリスクを取っているかは明確に異なる。
逆に、資金の出し手となる大企業や投資家サイドは、「大手とのトラクションがあります！」とアピールする起業家に対して
「それはどこの部署による、どのようなフローによる決裁ですか？」と質問すると良い。
索
W
x
ミ
この記事が気に入ったらサポートをしてみませんか？