ビジネスサイドと開発サイドの相互理解はなぜ難しいのかを図示してみた

私自身営業職が強いベンチャー企業を渡り歩いてきたこともあり、思い入れの強いテーマです。ビジネスサイド（Biz）と開発サイド（Dev）のバランスを取ることがゴールではあるものの、お互いの生態が違いすぎるが故に相互理解できないという現状があります。Bizが強すぎると開発サイドには社内受託感が拡がり、Devが強すぎると妙な忖度とともに開発遅延が起きたり、企画部門が思い描いたものと違うものができがちです。私宛に頂く相談ごととして、組織改善の文脈で強すぎる営業組織に対して開発組織のプレゼンスを高めたいというBiz側が強すぎるというものも頂けば、開発組織に営業組織が遠慮してしまい、どうにも制御できずに開発遅延が続いているというものを頂くこともあります。

今回はBizとDevの相互理解について、図を交えながらお話します。

BizとDevの乖離

BizとDevの乖離を図示するに当たり、下記のような図を描いてみました。リンゴの木を農家が育て、リンゴの実をアウトプットとして出す。リンゴの実を受け取った営業部門はそれを市場などで売ってくるというフローです。営業部門と農家のの接点はリンゴの実を通してクロスするイメージです。

システム開発の現場では、開発者がリンゴの木に相当するシステムを育て、アウトプットとしてシステムをリリースします。パッケージシステムであれば配布パッケージがリンゴに相当し、Webシステムであればシステムリリースがリンゴに相当します。その後、リンゴの場合であれば市場に持っていくなり、レストランに売り込むなりして認知され、お金になります。古今東西分野を問わず、Devが強すぎる企業というのは存在し「良いものを作ったから売れるはず」という職人気質な誤解が存在します。しかし実際はブランディング、マーケティング、営業努力をすることによって買い手のに認知され、お金が発生します。

つまりBizとDevは両輪が尊重しあうのが最善です。社内にリンゴの木がない状態（システム開発者が居ない状態）であれば、他の人が出荷したリンゴの横流ししかできません。営業が居ない状態もまた、庭になったリンゴを親戚と隣近所で消費することくらいしかできないのです。

BizとDevのすれ違い

Bizが強すぎる組織の特徴として、実際のBizとDevの守備範囲（図内A、B）に対し、BizがDevに期待している理解範囲がCであることがあります。Bizが自分たちの領域であるAに対して暗黙のうちに一定数理解されているという前提でコミュニケーションをしているケースです。

Bizの立場からDevについて「もっとこういうコミュニケーションをしてほしい」と語る本として下記の「エンジニアがビジネスリーダーをめざすための10の法則」があります。本noteでもお勧めしている一冊ではあるのですが、かなりBizの立場（コンサルタント）から好き放題言われているので反発感はあります。実際私のお勧めから購入していただいたであろう方による最近の低評価コメントもあり、かなりお怒りになられているようです。

Devをどうにか理解しようというBiz側の動きも稀に見かけます。Devを理解するために「営業職が皆でProgateをしてみる」という組織はごく稀に見かけるのですが、普段の業務でDev側が抱いている苦悩に直面するには至らず、せいぜい未経験エンジニアの気持ちにしかなれません。アプローチとしては遠いなと思います。

私自身のアプローチとしてはBizDev研修にて複数のワークを通してBizとDevの相互理解を促す試みをしています。ゴールは相互理解であり歩み寄りです。本noteについても、極力エンジニアの思考、傾向、苦悩を言語化するように努めていますが、こうしたコンテンツがBiz側からのDevに対する理解を深めることになるのではないかなと思っています。

Bizの期待値と逆行するジョブ型雇用(D)

一方、BizとDevの歩み寄りやドメイン駆動設計（DDD）などの動きがある一方で、真逆の動きとして気になるのがジョブ型雇用であり、フリーランスの業務委託契約です（図内D）。スペシャリスト採用というと聞こえは良いですし、実際に自社の給与制度に見合わない高度人材を採用するには必要不可欠でしょう。しかし開発組織全員にジョブ型雇用を求めて良いのかというと疑問が残ります。お互いに守備範囲だけについてコミットする世界なわけですが、その相互のジョブを誰が統合するのでしょうか。お互いの意図を互いへの興味や歩み寄りなしにどこまですり合わせられるでしょうか。ビジネスモデルも含めて仕組み化された大型組織であれば可能かもしれませんが、中小規模の組織であれば統合コストが高いため、ジョブ型や業務委託だらけの組織に振り切る姿勢は危ういのではないかと考えています。

木の議論：クリエイティブ組織と成果主義

今回、リンゴの木に例えた絵でお話しました。リンゴの木というのにもう一つポイントがあります。納品して完全終了の契約形態であったり、スタートアップのリリース前のように世間に需要を問うのが第一目標でない限りは、来年の収穫についても考えなければなりません。

私の実家には柿の木やブドウなどがあるのですが、これらが実に気まぐれでして、各年でしか実をつけません。ITビジネスだと隔年でマネタイズするというものはあまり耳にしませんし、大半の企業では論外でしょう。その木を見限るか、木をメンテナンスして毎年収穫できるようにするか、他の作物で空いた期間をマネタイズするか、2倍の値段をつけて販売するかなどしないと行けません。

ある程度サービスとして成立してきたシステム開発の場合は、そのメンテナンス性・スケーラビリティ・耐故障性などが問われます。後から手が入れやすいように考慮しなければ将来的なリリース速度が落ちます。つまり成果だけでなく過程も見なければ将来を犠牲にすることになります。

Biz側がDev側に興味を持っていない組織の場合、Dev側で安定しないアウトプットがあったとしてその原因が木本体や土壌にあったとしても「よく分からないけどちゃんとしてください」というコミュニケーションに終始してしまっているケースを見かけます。

こうしたすれ違いが起きやすいイベントの一つが障害報告です。一般的なDevの場合、障害対応の過程で障害報告をまとめるため時系列に不具合が克明に書かれています。大規模障害などでも細かく分単位で何がどうダウンしたかなどがプレスリリースに書かれたりすることがありますが、それを称えるコメントはDevのみです。Bizとしては下記の4点が報告されれば十分な場合が殆どです。

• どのくらいの期間、機会損失があったか

• 想定被害額はどの程度か

• 次に同様の問題がある可能性はどの程度か

• 根本解決にかかる金額と期間はどの程度か

先の研修でも障害報告のワークを実施しました。BizとDevの人たちを一箇所に集め、ITに明るくない経営層に障害報告をしようという内容は大変好評で、Dev側が事象を解説し、Biz側がその事実を受けキャッチボールをしながら上記を報告をまとめる20分となりました。

このようにまずはBizとDevが一堂に会してフラットに話をする。共通言語も知識も違いますがお互いの仕事に興味を持ち、理解する姿勢を見せるだけでもBizとDevの溝問題はある程度解決できるものと考えています。