システムインテグレーターの謎、あるいは矛盾を抱えるということ

プロジェクトでSIer（システムインテグレーター）とご一緒することは多い。たいていは、システムを作ってくれるSIerをお客さんと一緒に選び、上流で構想したシステムを作ってもらう関係性だ。
かれこれ25年SIerさんとお付き合いしているが、いくつか解けない謎がある。その一つは、

「なぜ営業と開発が分業しているのか？」
である。

ツイッターなどでは昔から
・営業が「何でもできます！」とお客さんに風呂敷を広げる
・それに不平を言いながら、徹夜して対応するエンジニア
という愚痴が見聞きできる。
不思議なことにエンジニア側からのコメントばかりで、営業側の見解が見られない（これは、エンジニアの方がツイッターで仕事の愚痴を言う習慣があるからかも・・）。

とは言え、SIerで仕事した人はみなこれに似た経験があるだろう。


ちなみに、僕が就職活動した時はもっとひどかった。
あるSIerの先輩にOB訪問した際、
「（君のような）文系は営業になってもらうから。で、SEは理系がなる。能力的にそれが手っ取り早いからね」
と言い切られたのだ。

当時、業界について何も知らなかったが、直感的におかしいと思った。
学生時代にソフトウェア開発については何一つ経験していなかったが、社会人になってから学んでも遅くないだろう、という確信もあった。その辺の理系よりエンジニアとしての適正がないとも思えなかった（全く根拠のない自信ではあったが）。

あと、個人的にも「自分で開発する能力もない営業マン」にはなりたくなかった。やっててつまらないんじゃないかな？という予感があったから。
就職した後、この直感は正しかったことをすぐに理解した。文系の僕自身、SEとして優秀な部類だったし。

そういう「理系か文系かで職種が決まってしまう」という悪習は、今では廃れただろう。文理と職業適性に相関がないことは明らかだし。
だが、その慣習は廃れても、「営業と開発が別の職業として分離している」という役割分担は残ったままだ。また「入社して営業だった人はずっと営業。開発だった人はずっと開発」という会社も多い（またいだ異動をする会社もあるが）。

これ、なぜやっているんでしょうね？
「この体制、この価格、この期間でやりきれるか」を実際にやる責任者以外がコミットできる訳がない。
分業の弊害はそれに尽きるのだが、以下でもう少し丁寧に書いておこう。


★分業の弊害①：人の成長
a)お客さんから、どんな業務にしたいかをヒアリングする
b)お客さんに、それを実現するシステムを提案する
c)お客さんに、それを構築するためのプロセスを提案する
d)プロセスを実行し、システムを構築する
e)できたシステムをお客さんに見せ、フィードバックを受けて改善する

これらのプロセスのうち、a～c)を営業がやり、dとeを開発がやる会社が多いだろうか。でも、残念ながらこれらは不可分だ。全ての工程を経験した上で、d)を見据えてa)をやれるような人が最強だ。でも分業すると、そういう人材が育ちにくくなる。

ちなみに、d)が得意な開発者はコミュニケーション能力に欠けているケースが多く、a)やb)が苦手、という話をよく聞く。僕はこれには懐疑的だ。
a)やb)に必要なのは「お客さんとゴルフに行って仲良くなる」みたいなコミュニケーション力ではなく、業務ヒアリングの方法論を理解して、情報を整理する能力。優れたエンジニアには必ず備わっているはずだ。それがないとエンジニアとしても3流にしかなれないから。
（ここまで書いてて気づいたのだが、SIerの営業をエンジニアがやらないのは、a)やb)ではなく、「ゴルフに行って仲良くなる」の方が大事な能力だったからなのかもしれない・・。でもそんな時代はとっくに終わっている）


★分業の弊害②：矛盾をだれも背負わない
営業は売りたい。
だから目の前の案件が「それほど複雑ではなく、自社の技術を適用すればサクッとできる案件だと思いたい」という強いバイアスがある。もし簡単な案件であれば、安く提案できるし、お客さんが「半年でどうしても必要なんです」みたいな無茶なことを言っていても、「我社ならできます！」と言えるから。

一方で、開発者はもっと慎重だ。
蓋を開けてみたら実は厄介な案件だった、という経験は全てのエンジニアが経験している。自社の技術も、有効な場面とうまく適用できない場面があることも熟知している。
だからお客さんに対しても「現状では判断材料が不足していますが、1年は必要かもしれません」みたいな言い方になる。

・営業は「なるべくたくさん売る」がミッション
・開発は「確実に作り上げる」がミッション
であり、この2つのミッションは基本的に逆を向いていて、矛盾している。

システム開発の営業とは、この2つの力学の最適点を見つけること、と言ってもいい。
つまり、
「プロジェクトがどれほどの難易度なのかは、提案時点では分からない。かと言って何も分かりません、では決して受注できない。なるべくリスクを見極めた上で、それでも残るリスクについてはある程度許容する・・」
みたいな高度な綱渡りをするのだ。これを僕は「営業と開発の矛盾を背負う」と表現した。

だが、営業と開発が分業していると、この矛盾を誰も背負わない。
営業は楽観的なシナリオだけを語り、開発は悲観的なリスクばかりあげつらう。議論を重ねてもどこにも収束しない。

本来、営業と開発の両方に責任を持つ事業部長みたいな人がそれを背負うはずだ。事業部長の高い給料はこの矛盾を抱えることに払われていると言ってもいい。
だが酷い会社では、営業担当役員と開発担当役員が別にいて、社長に至るまで、この矛盾を背負わない構図になっている。
そういう会社で何が起こるのか？
それは「売上をあげなければ潰れてしまう」という言葉に追われて営業が無茶な条件で案件を受注し、それに対して呪詛の言葉を吐きながら開発者が仕事をする、ということが延々と繰り返されている。

どこにも救いがない。SNSで愚痴が書き込まれる訳だ。


★じゃあどうすればいいのか？
分業の弊害が大きいのだから、分業をやめればいいんじゃないですかね？
開発者やプロジェクトマネージャーとしてキャリアを積んだ人の次のステップとして営業をやる。
プロジェクトが正式に始まる前の提案は、実は最も高度で、最も影響力が大きな仕事だ。例えばシステム開発の場合は、「御社に最適なシステムアーキテクチャーはコレ」みたいな提案をする。だからベテラン開発者やエース開発者が担当するのは理にかなっている。

コンサルティング会社にはたいてい営業がいないか、いてもごく少人数だ。代わりにそれまでコンサルティングをしていた人が営業をやっている（パートナーと呼ばれる。そこまで偉くならなくても、マネージャーは営業を兼務していることが多い）。
これも「一番重要で難しい仕事は、現場で鍛えられた人のなかから、もっとも能力が高い人が担当する」という原理からきている。

今更、そういうキャリアパスを作るのが無理な会社もありそうだ（いまさら開発者になれないベテラン営業さんが大量にいるとか・・）。

この場合、営業と開発者の分業自体は仕方ないのかもしれない。
ただ、もう少し小さいチームに営業と開発者が同居している方がいい。つまり、両者のミッションがぶつかりあったときに、社長までいかないとその矛盾を背負えないよりは、20人くらいのチームの長が背負えたほうがまだいい。
責任が明確になるし、顔が見える関係性なので、「売上を上げるために、無茶な条件で受注する」みたいなことがなくなる。どうしても無茶な条件で受注せざるを得ないときだって、開発者がその辺の事情を理解しているならば、モチベーションが維持しやすい。

ここに書いたことは、四半世紀前から全く変わらない構図だし、SIerの中の人は、僕に言われるまでもなく、重々承知だろう。
でも相変わらず営業本部と開発本部を分けていたりする。なぜなのか。

********************Youtubeコンテンツのお知らせ

オンラインで業務ヒアリングをする様子を動画で作りました。「業務改革の教科書」にもヒアリングのコツを載せていますが、その実践編という感じ。単に実践している様子が見られるというだけでなく、解説/振り返りをしているのがミソ。
・「ヒアリングのコツ」を実践している様子を見てみたい
・オンラインでのファシリテーションのコツを掴みたい
・単に、コンサルタントのしごとを覗いてみたい
などなど、興味がある方はどうぞ。

コンサルタントはこんな感じでお客様ヒアリングしてます（解説付）
https://www.youtube.com/watch?v=bnsNa8l1I1g