しばしば、技術と経営・ビジネスの間に境界線がある、などと語られることがあります。
特に、技術と経営・ビジネスの間に乖離、分断が発生してしまうような場合を取り上げて、境界線について言及する場合が多いようです。
この記事では、そうした境界線や分断について理解を深めるとともに、対策について考えます。
※なお、以下この記事において、話を簡単にするために「技術と経営・ビジネス」という語を「開発と営業」という語で置き換えて話をします。この２つの語は、厳密にはニュアンスが違うと思っており、「技術と経営・ビジネス」という言い方では「開発者は必ずしも技術だけではなくて、事業に関しての経営・ビジネス的視点を持つべきである」といったニュアンスも含み得るので、狭義の開発と狭義の営業の間の分断とはまたちょっとニュアンスが違ってしまうのですが、話の筋が大きく変わることはないと思うので、置き換えたまま話を進めます。
一般論：境界線はなぜ生まれるのか
前提として、ここでいう「境界線」というのは、本質的に物理的な存在のことではありません。部署や事業部を分けて、壁や建物などによって居室を変えることによって物理的に線を引くことはできますが、それはあくまでも形式的・結果的な事であって、本質的には「それぞれの人が、そこに境界線が存在すると思っているから存在する」という種類の概念的なものです。
ただし一方で、その存在を明示的に自覚しているという事を意味する訳でもないです。ある会社における開発の人間が、営業との間に境界線というものの存在を自覚していなかったとしても、開発者の全員が「自分は営業部の仕事には興味もないし、全く手伝いたいとも思わない」という考え方であったなら、そこには開発と営業の間の何らかの境界があると考えるべきです。この場合、境界線は開発の人の考え方によって生じていますが、しかし開発の人が自覚的ではないということです。
さて、このような境界線は
- 個人の特性、思考
- 組織の暗黙的なルール（文化）
- 組織の明示的なルール
のいずれかによってもたらされます。以下で詳しく確認します。
事例A：個人的な考え方
開発の人が個人的に
「自分の仕事はここからここまで、と事前にはっきり決める」
「自分は楽しく開発作業をする事が目的であって、事業として業績を挙げる・成果を出す事は目的ではない」
という２つの事を信条のように考えていたとしたら、開発と営業の間には明確に境界線が生じます。
事例B：組織体制
組織体制として開発と営業が明確に区分されていて、
「営業から開発に仕事を依頼するには、必ず上司からの承認を得る必要があり、営業からの依頼は部長間での合意が必要」
「開発と営業の予算は別で組まれていて、それぞれの事業目標は異なり、かつ目標達成に対して大きな圧がある」
という2つの事があったとしたら、開発と営業の間には明確に境界線が生じます。
このような体制は、事業部が実際に分離していて社内規約で相互の仕事のやりとりについて定義されていれば明示的なルールによってもたらされるものですが、暗黙的に「開発部長は開発目標の達成に厳しくて、営業からの仕事を勝手に受けたりすると嫌がらせをうけるので、営業と距離を置く」といった事で発生する可能性もあります。後者の場合、目標達成に厳しいというのが会社の文化的なものであったとすれば、それは開発部長個人の問題というよりは組織構造上自然に発生するものであって、大きく分類するならば組織体制によって生じたものとなります。
事例Aと事例Bの相似性
事例Aは個人のレベルで、事例Bは組織のレベルでの話ですが、概念的に似ている部分があります。つまり、いずれの場合も仕事の領域を区分して、また目的・目標といった事を規定することによって、それが他者・他部署と異なることで境界線が発生するという構造です。このことに注意しておきます。
境界線の存在そのものは、必ずしも問題ではない
ここまで境界線が何によって発生するのかという事を考えましたが、境界線が存在するという事が直ちに問題であるかというと、そういう事ではありません。
実際、技術・経営・ビジネスのそれぞれのプロ集団があったとすれば、それぞれの業務にある程度特化した振る舞いが必要となるはずで、それぞれのプロ集団の中でしか通用しないような言葉遣いであったり、振る舞いであったりという事は自然に発生すると考えられます。そのような意味では境界線には合理的な側面もあり、境界線があるからといって直ちに問題とはなりません。
実際、技術特化の会社と、事業経営特化の会社が組んで、事業を展開して成功するという事例は存在します。明らかに2つの会社の間には概念としての境界線が存在しますが、その境界線が存在するから絶対に失敗するというような事ではないのです。
境界線を問題視する場合は、それをきっかけとして発生する 分断 が問題となります。つまり、例えば開発と営業の間で方針への合意を得られなかったり、その合意について双方全力を尽くすという構造にならない事が問題となるのです。
本来あるべき姿：
それぞれの専門家集団が、合意した目標を達成するために協力して全力を尽くす。
分断が生じた姿：
それぞれの専門家集団が、合意した目標を達成するために協力しようとしなかったり、全力を尽くさなかったり、近視眼的な視野でのみ行動してしまう。ひどい場合には対立して足を引っ張り合う。
なぜ分断が生じるのか、分断への対策
分断が生じる理由は、端的には「少なくとも一方が、相手のことを十分に信頼・尊重していないから」という事になります。
仮に、開発と営業で意見が対立したとして、善意から意見すべきことは主張するにしても、しかし最終的に決まったことには従って力を尽くすというNetflixなどでも求められる考え方をしていれば、分断は生じません。相手のことを十分に信頼・尊重していれば、相手がその意見を主張する背景を厳密に理解できていなかったとしても、そこまで主張する事には意味があると信じて議論することができ、最終的に決定に従うことができるからです。
したがって、相手のことを十分に信頼・尊重していないから、決定が正しいと心から信じることができないという事になります。
そうすると、分断が生じなくするには、次のような考え方が有効になります。
振る舞いの改善
情報・判断について
- 必ずしも自分・自部署・自チームなどで持っている情報から合理的に思えない主張が生じたとしても、相手の立場を考えて納得できるようにする（自分が高いハードルを超えられるようにする）
- 合理的に思えない主張が生じないようにするために、できる限り情報の透明性を高める（相手のハードルを低くする）
意見に対する感情について
- 単純に自分・自部署・自チームの意見に固執せず、相手にも一定の合理性があることを理解する（自分が高いハードルを超えられるようにする）
- 相手の感情が昂ぶらないようにするため、丁寧に意見を述べるようにする（相手のハードルを低くする）
事実の受け入れ方について
- 「これだから営業は」などのようなレッテルを貼って考えるのをやめる、事実関係をフラットに見る
- 最終的な結論はどうあれ、相手の意見が発生する背景について、それを相手の認識している主観的事実としては受け入れる
- 数値が間違っていないかの確認は必要な場合がある
組織の改善
また、一方で組織構造などの面では次のような事でそもそも対立的構造が生まれにくくすることができます。
- 各部署・チーム等を通して全体で共通の目標を持つ、具体的なKPIを共有する
- 会社のミッションやプリンシプル等を定義して、明確な判断軸を共有する
- 会社の文化を通して、暗黙のうちに外れた行動が生じにくくする
このように、分断にはいくつかの対処方法があります。いずれも言うは易く行うは難しというところがありますが、こうした振る舞いの積み重ねで分断が生じない状態を保つ事が重要です。
分断の発生が誘導されるケース
以下のリンクで話されるような、開発生産性を評価するという事になると、分断が発生する場合があります。
この記事の冒頭に書いてあるとおり、開発者からすると、自身の生産性が高い/低いという事はセンシティブな議論になる事があるので、そもそもの生産性の定義とは？というような事で意見が合わずに分断が発生したり、あるいは事実が間違っていなくても単純に感情的になってしまったりという問題が生じがちです。
そうすると、評価をするには 相互の信頼/尊重が不可欠 という事になります。
例えば、もし開発生産性を測定したうえでそれに詳しくない人にも開示する必要があるとしたら、開発生産性が多義的であるという事を説明したうえで、特定の値が高い/低いだけで素人的に決めつけをしないという理解を得ることが必要になります。また、そもそも開発生産性を何のために測定するのか、という事についての認識を合わせることも重要です。そのあたりについては、詳しく次の記事を参照ください。
ちなみに、開発生産性に関する議論は本当に難しく、先程引用した「開発生産性について議論する前に知っておきたいこと」の記事においてもリソース効率・フロー効率に関する言及は一部間違っているところがあります。何がどう間違っているかは私の別の記事
にまとめてありますが、一般的なアジャイル開発の文脈ではそもそもリソース効率とフロー効率は単純なトレードオフのような関係にはなく（コールセンター等ではトレードオフですが）、いかにして必要なタスクを取捨選択してリソース効率を大きく下げずにフロー効率を上げるか が重要になります。
おまけ：境界線が無いとどうなるのか
以下おまけですが、しかし必ずしも多くの人が体験していない事でもあると思うので、境界線が無い場合について記載します。
私は、技術と経営・ビジネスの間に境界線があるとおそらく仕事がしにくいと思い、意図的にそのような境界線が無い環境を選んできました。そのため、社員数でいえば30人以下の環境でしか働いた事がなく、技術と経営・ビジネスの間に境界線というのはある種の都市伝説なのではないかと思うところもあります。
ただ、境界線が無いというのは、私としては伸び伸びと働ける反面、人によっては苦しいようにも思います。そこで、少しそのあたりに触れておきます。
例えば、私は就職してからずっとシステム開発者として働いていますが、キャリアのごく初期には「自分のコストがいくらかを徹底して考えろ」という事を非常に厳しく言われました。自分が作業をするときの一分一秒が何円に相当するものであるべきなのか、ということです。ふつう、開発の仕事をしていて、自分の一秒が何円、という事を頭の片隅に置きながら作業をしている人は少ないと思いますが、「技術と経営・ビジネスの境界線が無い」という状態ではそれが基本です。自分の作業が、常に価値を生み出すものになっているか、自己評価をし続ける必要があります。
あくまでもこれは基本であって、0から1の事業を作るときには、自分のコストだけではなくてサービスが完成するまでの間の営業のコストについても考える必要があります。つまり、サービスが販売できる状態になるまでは、関係性を作ったりヒアリングをしたりと営業に動ける事も存在しているとはいえ、基本的にはコストだけが発生する状態になるので、「サービスをどのように開発すれば営業がコストだけの存在で無くなるか」という事を考え続けないといけません。
もちろん、それが開発者だけの仕事であるべきではなく、営業としてはいつ頃からどうやって販売していくかという戦略を立てるのですが、「機能に対してどれぐらいの時間がかかりそうで、いつまでにこれぐらい準備できる/いつまでにこれぐらい準備すべき」という事を算出できるのは、究極的には開発者だけです。0→1のビジネスにおいて、技術と経営・ビジネスの間に境界線を設けないという事は、これを考えて組み立てて遂行するという事を意味します。
最低限のサービスを作ってリリースすると、今度は拡販の為に機能追加や安定してスケールする構造、十分なセキュリティ対策などが必要になります。これらにも優先順位をつけながら、どのissueに対応すれば少なくとも当座の最低限の資金は確保できて、このissueはいつまでにやる必要があって、このissueは期日はないけどドラクエで言うスクルト/バイキルト/フバーハのようにその後の開発速度に影響するので早めに対応した方がよくて、...といった事を最適化していく事になります。
これを、あらゆるシステム開発者に求めると、おそらくすぐに破綻してしまいます。実際に、事業の金勘定を除いて、またチームマネジメントも必要でないような場面でも、破綻してしまう開発者を見ました。
そのような意味でも、少なくとも個人としてはある種の境界線が必要で、従ってチームのレベルでもある程度の境界線はあるべきで、しかし分断が発生しないようにする、という事が大事なのかなと思いました。