システム内製化の闇・ひずみ
今回はシステムの内製化の話をしていきたいと思います。
システムの内製化のメリット・デメリットは一般的に
メリットは
- アジャイル開発ができる
- システムの知見がたまる
- ベンダーロックされない
- 開発コストを抑えられる
デメリットは
- エンジニアの採用が難しい
- エンジニアを雇い続けるコストがかかる
と一般的には言われています。
最近はデメリットがメリットを上回るので内製化している会社が多いと思います。
しかし、内製化する事でこれら以外のあまり知られていないデメリットがあります。
1.解雇できない
諸悪の根源ITゼネコンの原因の一つと他の動画でも説明してきた通り
日本の労働基準ではどれだけできないプログラマーでも一旦正社員で採用した場合はなかなか解雇できないです。
面接ではしっかりしてるけどいざコーディングすると全然できないケースってよくある話です。
ちなみに小松が採用する時はプログラミングさせてコードを見て判断するのでそういうことはないですが。
それだけではなく、元々優秀だったプログラマー・エンジニアでも解雇されないと思い、徐々に生産性が落ちていくケースもあります。
2.昇給 = コスト増のジレンマ
外注であればコストが増えることは大きな追加改修がない限りありえないのですが
社員として抱えてしまう場合は、エンジニア本人が成長すれば当然それに見合った昇給が必要になり、同じプロジェクトでの運用保守費用が自然と高くなっていってしまいます。
3.自社エンジニア以外の選択肢がない
複数の会社に外注する場合はその会社同士を比較して、どちらが生産性が高いのか比較検討できますが、
全て自社内で内製する場合はそのエンジニアチームのスキルが全てになってしまい、自社のエンジニアチームの生産性がいいのか悪いのかの比較ができないです。
例えば、WEBサイト３ページの追加改修という案件があった場合
「１週間でできます」
と言われようが
「１年かかります」
と言われようが、それに従うしかないです。
つまり事業側としては他に依頼する選択肢がないです。
4.属人的になる
外注ではベンダーロックになる可能性がありますが、自社で内製化した場合は個人のエンジニアに同じタスクが集中して属人的になる現場は多いかと思います。
そして、多くの属人的な機能を作ったエンジニアが退職すると慌てて別のエンジニアをアサインしたり、最悪その機能が止まる可能性もあります。
結局ブラックボックスが会社に依存するのか個人に依存するのかの違いになってしまいます。
5.エンジニアの意見が通りやすい
外注の場合は発注者の会社の人事的な事については全然関係ない話ですが、内製化システムで社員として働く場合はシステムを知っているエンジニアが発言権やアイデア出しの場面でも影響力が大きくなります。
さらに3.の他の選択肢がなく、4.の属人的になる事でエンジニア側が
「○○だから実装できない」「こうすれば実装できる」
と言われてしまえばそれに従わざるをえなくなってしまいます。
それもあって、
DDD, Clean Architecture, Typescript, SCSS, AWS, Docker
などの不必要なキラキラ技術が流行る理由にもなっています。
なぜなら、複数の会社に案件をコンペして外注する場合は当然一番安い見積もりをした会社に依頼をする事が多いのでこのようなキラキラ技術を使っている時間とお金の余裕が生まれません。
技術が進歩するという事は以前よりも開発は早く・運用コストは安くなるべきであり
そうでなければそういった技術を採用すべきではないのが本来当たり前の判断なのですが
エンジニアの意見が通りやすい状態でこの技術が必要ですとエンジニア側に言われてしまえばシステムの事すら知らない社長はYESとしか言いようがないのが事実です。
元々、WEBサービスを構築する知識はそこまで必要ではなく、とても簡単で実践動画で紹介している全１０回の動画で事足ります。
つまり新人エンジニアでも十分にWEBサービスを作成できるくらい簡単です。
そうなってくると、経験のあるエンジニアからすれば新人エンジニアとの差がなくなってしまうので、無理矢理にでも何かしらのプラスアルファのスキルを得ようとします。
でなければ、昇給が見込めないからです。
その無理やりスキルを付けたいという気持ちと自社内では意見が通るという事が重なって不必要な技術のために開発は遅くなり、運用コストは高くなるといった本末転倒な事になっています。
6.社内政治がはびこりやすくなる
外注であれば、システムの仕組みを問い合わせる窓口担当がいることが多くその窓口担当がまとめると思いますが、自社のシステムで同じ社員のエンジニアの場合は窓口とかではなく誰でも気軽に質問できることが多いと思います。
それ自体はいい事なのですが、エンジニア側からすると忖度できる状態なので、
Aさんはエンジニアに対してきついのでAさんの案件は放置しておいて
Bさんとは仲がいいので案件をどんどんこなしていく
といった事がおこると必然的にBさんの評価が高くなると行ったことになります
外注であれば、外注先の社員が受注元の人事などの影響力もないので、どうでもいいことと済ませる事ができますが、自社の正社員であれば昇進や昇給も関係してくるので、昇進できないような案件を任したり任されたりなどエンジニア内でも社内政治が起きやすくなるかと思います。
エンジニア自身の立場で考えると意見が通る、納期も自分で決めて理由を付ければ伸ばす事も可能であり、自分の好きな技術で開発できるのでいい事だらけということになります。
なので、ネットなどでもSESやSierなどよりできる限りシステムを内製化している会社に転職することをすすめる理由です。
しかし受託している会社からすればそういった内製化されてる会社はぬるま湯ですので、ずっとそうしたぬるま湯に浸かっていると、スキルがない社内政治だけが得意なエンジニアといつの間にかなってしまう可能性もあります。
受託開発をやってきたエンジニアが内製化されたシステムの会社に転職したとき「ゆるい」「楽」という話をよく聞きます。
社長や事業者からすれば苦労してエンジニアを雇い内製化しているので、内製化して生産性が下がったとは思いたくない部分もあると思います。
それもあって、ネットの情報ではこれらの長期的視点で見た隠された内製化のデメリットの情報がないのではと思います。
エンジニアも雇った直後はモチベーションがあると思いますが、気づかないうちに徐々に生産性が下がっているかもしれないので、自社のエンジニアの生産性を考え直してみる必要があるのかもしれません。
以前の会社ではトップのCTOを外部から雇って交代させてた所もありましたが、そこまで上手くいってた印象は受けなかったです。
会社の規模にもよりますが、完全新規のプロジェクトを社内のコンペ方式にするとかも１つの案です。
あと受託の仕事を取ってくるのも一つの案です。
ただ、小松が知る限りは自社の案件のぬるま湯に浸かってるエンジニア達が受託案件の仕事をしても利益が取れる程の生産性が上がらず失敗していると聞きます。
今回内製化後の長期的なデメリットを多く取り上げましたが、それでもベンダーに丸投げするよりも、内製化したほうがいいかと思います。
要はエンジニアがサボると解雇、クビにできて、生産性がいいと給料が上がる仕組みができていればいいのですが、いかんせん、日本の法律では解雇ができません
それをふまえると、5人チームの場合4人を業務委託にして一人のみ正社員にするといったチーム構成であれば、解雇できるので、パフォーマンスに合わして賃金をコントロールできるかと思います。
それでも同じポジションで評価する人が同じ場合何年もすればどれだけ優秀なエンジニアでも馴れ合いになってしまうので、3年間程度を基準として他のエンジニアと交代する前提で契約しておけば、いい緊張のまま仕事ができ、エンジニアとしても違う環境の違う目線からの評価をされることで、いいスキルを保ち続ける事ができるのではと思います。
2022年10月追記
働く期間ですが、３年間は少し短いのかもと感じています。
プロジェクトや規模によりけりですが、4年～8年ぐらいがもしかしたら働く期間としてパフォーマンスが上がるのかもと考えています。
アメリカの大統領や日本の首相の期間もそれぐらいなので、それぐらいかなぁっとまだ働く期間は考える余地があるかもです。
登録日：
更新日：