#9 システム内製化の闇・ひずみ
今回はシステムの内製化の話をしていきたいと思います。
システムの内製化のメリット・デメリットは一般的に
メリットは
・アジャイル開発ができる
・システムの知見がたまる
・ベンダーロックされない
・開発コストを抑えられる
デメリットは
・エンジニアの採用が難しい
・エンジニアを雇い続けるコストがかかる
と一般的には言われています。
最近はデメリットがメリットを上回るので内製化している
会社が多いと思います。
しかし、内製化する事でこれら以外のあまり知られていない
デメリットがあります。
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年間程度を基準として
他のエンジニアと交代する前提で契約しておけば、いい緊張のまま仕事ができ、
エンジニアとしても違う環境の違う目線からの評価をされることで、
いいスキルを保ち続ける事ができるのではと思います。
