システム内製化は、業者に頼むよりずっと難しい

私は2003年に新卒で商社系のSIerに入社し(今ではその会社は別会社になりました)、6年間SIerでエンジニアとして受託開発に携わりました。2009年に、輸入雑貨メーカー/卸の会社(完全にユーザー企業)のひとり情シスとして転職し、自社の販売管理システムを内製しました。業務インフラを高度に整備することが出来たおかげで、会社のビジネスモデルを転換することが可能となり、苦境を脱することが出来ました。

エンジニアのための経営学にその時の資料が掲載されています。

6年間は業者の立場、6年間はユーザーの立場を経験し、2016年に独立しました。両方の立場を経験して思うのが、潤沢なエンジニアリソースがない企業がシステムを内製することはオススメできない、ということです。

内製回帰を訴えた時に考えていたこと

ITは費用ではない、投資である

私がSIerに在籍していた頃は、内製回帰を訴えていました。同じお金をかけて失敗プロジェクトになってしまうのであれば、エンジニアを雇用してトライ・アンド・エラーを繰り返せる環境でシステムを構築したほうが結果的にROIが高くなるはずだ、と考えました。

ビジネスに貢献するシステムを作り運用することが目的なのだから、内製化を担当する部門を立ち上げるほうが長期的にメリットが大きい。ITは買って終わりではなく、事業と共に育て上げていくもの。その為の人員がいないことが不自然だ。そのように考えていました。

工程の分断を無くしたい

もう1つは業者の視点です。SI業界で一般的なゼネコン構造を脱するためにはエンジニアが直接ユーザー企業の中に入るほうが変化を生み出せると考えました。

ゼネコン構造というのは、元請から下請け、下請けから二次請け…という風に仕事が下に下に流れていく構造のことを指します。

受託開発のように別注でシステムを作る際、業者は｢単価｣×｢人数｣×｢期間｣の掛け算で料金を見積ります。単価というのはスキルに応じて上下する、1ヶ月あたりの技術者の価格です。作成するシステムの規模感や難易度から｢これぐらいの機能だと1ヶ月に9人投入する必要がある｣という理屈で、価格を決定します。

例えば単価100万の人間が3人で2ヶ月かけて完成するシステムだと、100 x3x2 =600万、という計算になります。このモデルで利益を最大化する方法は、｢高い単価で顧客から受注して、単価の低いシステム会社へ仕事を依頼する or 派遣して貰う｣ことです。期間短縮や人数削減では利益率は変わりません。

お客様から直接受注を請けるシステム会社のことを元請といいます。そして、元請から下請、下請から更に下請に流れていく構造になっています。元請が100万でお客様から受注したモノを下請けに50万で流せば、それだけで50万浮きます。20万なら80万浮きます。

それだったらよくある話なのですが、このモデルの癌は「末端にいるエンジニアのスキルが上がらず、使い捨てになるリスクが高い」という点です。

会社と会社を挟むことで、元請けの立場のエンジニアは｢仕様書｣や「設計書」を作ります。プログラムの実装手順を逐一説明した手順書のことです。板前の世界で例えると、このレシピの通り作ってくれというレシピを作る花板とレシピを実装する手足となる部下というイメージです。レシピを作る工程を「上流工程」、レシピに沿ってプログラムを作る工程を「下流工程」等と言います。業界用語です。

レシピを作る人とレシピに沿って作る人が分断されていることが、上述した「エンジニアのスキルが上がらない」に直結します。工程の分断は悪である理由は、自分で問題を解決することができない人材を生んでしまうことです。

上流工程ではドキュメントばかりを作ります。実装しないとそのドキュメントが正しいかどうかも分からないはずなのですが。下流工程では言われたことだけをやる。なぜその設計なのかを知らなければ善し悪しが判断できない。

お互いのフィードバックが断絶されてしまい、どうすれば良いシステムを作ることが出来るのか、その経験を積むことが困難になります。言われたことを実装するというのは大変退屈ですし、何が悪いのかも自分で感じることが出来ません。エンジニアとしてレベルアップする環境がほとんど皆無です。工程を分離するために専門性が蓄積されず、より高度な実装を作成するインセンティブも発生しません。

私は元請け・孫請け両方とも経験しています。元請けとして上流から下流まで全てを担当した仕事で書いたコードは、今でもある程度覚えています。イケてるなと思う設計にしたけど、あそこではひどい目にあったな、など。ですが、分断されて渡された仕様に乗っ取ったコードは、1ビットも覚えていません。

こういう状況になってしまう一端が現在のビジネスモデルにあるのであれば、業者の立場からユーザーの立場に立って自分でレシピを書いて実装してフィードバックを受け、エンジニアとして刺激的な日々を送るべきだと考えてました。この考えは正しかったと思っており、ITそのものを事業として展開する企業が2007年から比べると非常に多く増え、内製する体制を整えています。大変喜ばしい変化です。

ユーザー企業の立場に立つと、内製が正しいのか不安になった

1. 改善する前提でシステムを作るなら、エンジニアを雇用してトライ・アンド・エラーを繰り返せば良い
2. ゼネコン構造で「ユーザーの顔が見えない、システム開発」に疲弊しない為の受け口を作りたい

この２つの想いがあったので、システム開発会社にいながら「本来は、システム内製こそ正義」だと息巻いていました。20代後半に差し掛かり自分の腕を試したくてしょうがない時期だったこともありましたが、外注したら何千万もするようなシステムを自分で作ってやるぞと意気込んでいたのを昨日のことのように思い出します。

会社が変わったことで、所謂システム会社とのお付き合いは皆無となり、付き合う企業はほとんど事業会社の中小企業に変わりました。ここから、システム内製化への懸念が芽生えることになります。

業者以上のことをITの素人が出来るのか

不安を覚えた最大の理由は、人材不足です。

内製化を行うということは、プラットフォームは問いませんがそれらを使って成果を出した人間が必ず内部にいなければ(外部人材でも良いが、スキルトランスファー出来る人材が必要)なりません。そんな素養を持った人材を見たことがありませんでした。これが中小企業の現実なのかと思うと、大企業にしか適用できない理屈なのではないかと不安を覚えました。

エンジニアが仮に入社したとしても、ビジネスサイドに技術がわかる方(エンジニアと仕様策定・要件定義のコミュニケーションが取れる方）がいなければ、宝の持ち腐れになってしまいます。

属人化が激しく、退職後のフォローが出来ない

ITが専業でない中小企業の場合、IT担当者は兼業が当たり前です。ITはあくまでもツールでありコストであると捉えられていますので、積極的に投資する理由がない。素養のある方が1人いて、ITインフラ管理から簡易的なアプリケーションの開発を行っているというケースが典型的です。問題は、バックアップする人、スキルトランスファーしている体制がない会社がほとんどです。エンジニアを雇っても管理できそうもありません、指示を出す人はITは素人の経営者です。

このIT担当者が退職されたら、どうしようもないです。管理できない野良システムとして、厄介者になってしまいます。そういったリビングデッドになっているシステムの存在を耳にする機会も増えました。

内製する対象に限界があり、定期的に仕事を生み出せない

私が在籍していたユーザー企業は総勢10名弱、年商にして4億前後でした。足掛け2年間かけて販売管理システムを作り改修してきましたが、2年後には何も改修する箇所がなくなってしまいました。バグがなくなったという話ではなく、ビジネスモデルが完成されたので手を入れて変えるべき所が無いという意味です。自分で自分の仕事をなくしてしまったようなもの。

当時の会社が「販売チャネルはネットのみ、ECを通じて全ての売上を獲得する」というネット専業の雑貨メーカーであれば、内製し続ける余地はあったかもしれません。改善と売上の相関関係が認められます。ですが、そんな会社はほとんどありません。お客様はFAXでの注文が主体です。習熟コストがゼロに近い為です。

メルカリや楽天のように、ITそのものがビジネスモデルのコアになっている事業会社の場合は、エンジニアリングでサービスの拡充・改善を図ることが競争力の強化（売上の拡大）に直結します。しかし、そのような会社がどれだけあるかと言えば、1000社に1社、もしかしたら10000社に1社かもしれません。

色んな側面からリスクを述べましたが、共通しているのは「システム内製化を維持運営する体制を築くことが非常に難易度の高い行いである」という点です。

中小企業は予算100万円でIT投資の鍛錬をつもう

ITで会社を変えたいと考えている中小企業にとって現実的な回答としては、予算を100万円ご用意して頂き、技術顧問となる人に定期的にサポートしてもらい鍛錬を積むことだと考えています。アルバイトを1人雇うのと同じ予算で勉強代を用意する、という格好です。

開発に何ヶ月もかけることが出来る中小企業様はほとんどいないと思っています。大企業より諸条件は厳しいことが常です。1ヶ月で展開できるスピード感が必要なので、１からプログラムを書くよりもツールを活用するのが現実的です。Webアプリとして動くものが良いでしょう。展開が用意だからです。

ツールを活用する理由は、可能な限り属人性を下げることにあります。実装したコードが分かる人が内部にいなくても、外部に入れば良い。その為にはある程度シェアの高いツールを使うことをオススメします。ツールの使い方を覚えればある程度のことが誰でも出来るので、ノウハウが溜まりやすい。

今の時代はPaaSサービスを活用するほうが安いので、顧客と「対話」をして最適なITをキチッと落とし込んで、これだけのビジネス上の価値が生まれるよというイメージをしっかり共有する。その為のプロトタイプを作る技術を持っている人でなければ、その共有も困難です。プロトタイプが作れないのなら、そこで察して下さい。

100万の範囲で行えるシステムは、恐らく10画面前後の小規模なものになるでしょう。それで良いです。規模の大きさとビジネスインパクトは正比例しません。ツボを突くことで小規模でも大きな効果を出すことが可能です。私が内製した販売管理システムも最初はそんなものでした。

繰り返しになりますが、「小さな成功体験」が大きな成功体験につながるきっかけになります。業務品質の向上に最も寄与できる手段の１つは、IT活用であることは間違いありませんので、そのお手伝いをさせて頂く機会があれば嬉しく思います。

最後までお読みいただきありがとうございました。
こちらの記事にご興味を持っていただいた方には、こちらの記事もおすすめです。

プログラミング経験が無くても出来る、IT企画の立て方

システム開発の値段はどのように決まるのか

販売管理システムの選別に役立つポイント５点を紹介します

ITコンサルタントは、どんな仕事をする人たちなのか