システムの内製化を進めるために必要なのは何か？という議論が SNS で盛り上がっていました。 システムの内製化は非常に難しく、時間がかかります。
中には頓珍漢なアドバイスをする人もいて、何が正解かわかりにくいでしょう。
内製化しようとして実装系のエンジニア採用すると大体失敗します。実装そのものはSESでもSIerでもオフショアでもどこでも良いのです
— やまもんチャリ走社長／ITエンジニア転職／焼肉奢りおじ (@MotoyasuYamada) June 14, 2023
まずはプロマネと要件定義ができるSEとかPdM人材だけを採用しなさい！それ以外のエンジニアを最初に取ったら負けです https://t.co/jmszhwp71S
内製やってるけど、この通り。従来のSE採用しても意味ない。{' '} https://t.co/z8SGe0feGf
— フルスタ＠高年収エンジニアへの道 (@fullsta1000) June 16, 2023
内製化の成功パターンは既にあります。 「まずはプロマネと要件定義ができる SE とか PdM 人材だけを採用しなさい！」などというのは全くの不正解です。
内製化のスタートで最初に採用すべき人材は CTO
一番最初に採用しなければいけないのは、CTO です。 業界で名前が通った CTO を採用します。
ボトムアップで内製化しようとすると、絶対に失敗します。 社内で理解が得られないからです。
内製化を進める場合は、トップダウンで進めなければいけません。
とはいえ、システムを何も知らない人が内製化の号令をかけても誰もついてきませんし、号令自体が的外れになるでしょう。
なので、まずは CTO を採用しなければいけません。 CTO は企業のブランドにもなります。
一休は有名エンジニアである伊藤直也さんを CTO に迎えてから、エンジニアファーストの会社として生まれ変わりました。
CTO に就任して 6 年。伊藤直也と一休の「これまで」と「これから」
Mobility Technologies（旧 Japan Taxi）も岩田和宏さんが CTO に就任してから急激にエンジニアファーストの会社としてネームバリューを高めていきました。
CTO を最初に採用して、そこからエンジニア界隈の知名度を上げていく
まずは CTO を採用します。 エンジニアが働きやすい環境をトップダウンで作り上げていきます。 その内容を発信して、エンジニア界隈での知名度・認知度を上げていきます。
それから、エンジニア独自の年収水準を設定します。 一般的な職種よりも高めになる可能性は高いでしょう。
CTO が頑張っても、一般応募経由だと、最初はゴミのような人材を採用せざるを得ない場合があります。 内製化を始めてすぐに良い人材が集まるわけではありません。応募者にメリットを提示できるのは、内製化が進んだあとです。
どうなるかわからない会社でファーストペンギンになるメリットはないからです。
まともな人は応募してこないので、初期の採用は CTO の元々の知り合いが多数となります。
内製化を目指しつつも、最初はプロジェクトマネージャー、プロダクトオーナーの職種で人を集めて、開発は外部委託に任せる...というやり方になるかもしれません。
「要件定義が大事だから」という事情ではなく、開発要員が集められないからです。 要件定義しかできない人材がプロジェクトを回すと、当然負債が溜まっていきます。
外部委託が書くソースコードはゴミである確率が非常に高いのですが、自分で実装したことがない人はゴミをゴミと判別できません。それが悪いことでもありません。 ゴミを弾くのはエンジニアの仕事であり、プロジェクトマネージャーの仕事ではないからです。
外部委託に任せて、負債を溜めながらも、手を動かせるエンジニアを徐々に増やしていきます。
最初は「手を動かせるが実力はさほどでもないエンジニア」が多数を占めるでしょう。それでも採用を続けます。 この時点で、内製化を目指してから 2 年くらい経ってしまうことでしょう。
内製化は急にはできないのです。
プロジェクトマネージャーばかりになると、内製文化は失われていく
内製化したい組織では、SIer 出身のプロマネ人材には注意が必要です。 SIer には「プロマネが上で、手を動かす人は格下」とみなす文化があります。
「手を動かすのは単価の低い人間の仕事」という価値観が、DNA レベルで刻まれます。
内製組織では、社内で企画して、社内で実装し、社内でリリースが全て完結します。
「要件定義しかできない人材」は内製組織にとっては癌です。
要件定義しかできない人は、要件定義をして、実装者に仕事を投げて、スケジュールを詰める、という仕事に走りがちです。内製文化と相容れません。
プロダクトオーナーと要件について会話して、意見を交換し、実装して、動くプロダクトで動作を確認していく...というのが内製組織の動き方ですが、そこには目に見えない一体感があります。 SIer の開発は、工程を区切り、それぞれの工程の計画を作り、それぞれの工程の担当者に責任を負わせるような動き方をします。
SIer のプロジェクトマネージャーは「一緒に作る」のではなく、「作らせて管理する」という考え方を持っています。 外部委託に丸投げする開発とは相性が良いのですが、内製組織では「一緒に作る」のが基本です。
SIer 式のプロマネ人材が多数を占める組織では、内製が回らなくなります。 誰も手を動かせないからです。
「あ、こういうのが欲しいんですね、わかりました！作ってみます」
で実装して、
「できたんですけど、どうですか？」
と見せて確認する、というのが内製組織のスピード感です。
SIer のようなプロマネ中心の開発丸投げ組織では、
「こういうのが欲しい」を表現するために重厚な「設計書」を作り、開発者に設計書を渡し、成果物を「納品」させます。
それぞれの伝言ゲームに時間がかかる上に、責任の押し付け合いになるため、責任を取らないための文書が大量に生み出されます。
結果として、「要件定義に 3 ヶ月」みたいなスピード感になります。
そして出来上がったソースコードも底辺が書いたゴミなので、「ちょっと直せば 100 万円」みたいなツギハギだらけのポンコツになります。
やっぱ内製増やすべきだよ。
— タマゴケ (@s5ml) June 13, 2023
何度も内製とアウトソースの間を行ったり来たりするけど、エンジニアリングできる人材は社内で囲っておかないと、ゴミしかできないじゃん。
”ソースコードを書くなど単純な作業”なら外部委託してもいいけど。
要件定義がすごい！要件定義が偉い！みたいな価値観は、SIer 的な組織では骨の髄まで刷り込まれますが、自社開発（内製組織）にその価値観を持ち込むと破滅します。
「動くものを作れる人」の方が評価されるし、評価されないといけません。その上で、ユーザーにとって大きな価値を届けられるのが「立派」なのです。
ずっと（コードも書く）内製やってるけど、要件定義に異常なこだわり持ってる人は、組織がフラットじゃないのでは？全く定義しないわけではないがラフにやって、作ったもの触ってもらって認識すり合わせてる。要件定義がーとか言ってる会社では内製化が上手くいかなかった 社内SIerみたいになるから。{' '} https://t.co/U9bhY0Rvhj
— フルスタ＠高年収エンジニアへの道 (@fullsta1000) June 17, 2023
SIer ではユーザーがどうか、よりも、会社で決められた計画を遵守することが評価されます。 SIer は「お客様のため」と言いながら、客が使いやすいシステムを作ることはできません。
失敗したら怒られまくるからです。失敗しないように、計画どおりに、なるべく自分の責任にならないように、仕事を進めようとします。 病的な責任回避思考が染み付いてしまうのが、SIer で働く最大のデメリットです。
内製化の文脈でいうと、SIer 人材はエンジニアの人数が少ないうちは、プロジェクトを回してくれるので重宝します。 しかし、SIer の文化を持ち込むような人が多数を占めるような組織では内製化は不可能です。
初期に採用して、全体に占める割合は 2 割以下に抑えるのが健全です。
内製化を成功させるための手順
まずは有名な CTO を採用します。 CTO の人脈を使って、人を集めましょう。
CTO にエンジニア組織を束ねる権限と予算を委譲します。 信じて任せましょう。横から色々と口出ししてはいけません。
最初は SIer 人材でもいいので採用して、「自社の人間 + 外部委託」のチームでシステムを作っていきましょう。 いきなり全部内製するには人数が足りなすぎるからです。
システムを作って時間稼ぎしている間に、CTO は組織を整えていきます。最初はカオスですが、徐々にカルチャーが出来上がってくるでしょう。
1、2 年後からが勝負です。文化を作っていく時期です。
ウェブ系の会社で十分に経験を積んだ人を採用指定ください。
この辺で SIer 出身の人を採用すると、モダンなエンジニア文化が育まれません。 SIer 出身の人は古臭いルールしか知らないので、アンラーニングしてくれないとみんなが困ります。
CTO がトップダウンでウェブの文化を醸成できると強いです。逆に CTO が技術的に弱いと、声の大きい社員が文化を形成していくことになるので、要注意です。
社内で抱えるエンジニアが増えていくと同時に、外部委託の割合を減らしていきましょう。外部委託に依存しているうちは内製化は遠いです。 また、外部委託は底辺の雑魚プログラマーがよくいるため、技術的負債が急速に溜まっていきます。
欠陥住宅を修復するのは、新たに家を建てるよりも面倒で難しいのです。
完全内製を達成すると同時に、初期に採用したボンクラの給与を下げます。 急拡大する組織の場合、初期に採用されたボンクラが良いポジションにいたまま、居残ってしまうケースが多いです。
ボンクラの下で働く若手社員のモチベーションが上がらず、離職につながります。
無能の下で働く場合、優秀な人ほど離職していく傾向が強いです。 なので、無能をすぐに引きずり下ろせるようにしておきましょう。
無能を正しく評価して、ダメな人は降格させないと、優秀な人材をどんどん流出させてしまいます。