プログラミング教育を受けた世代の受け皿となる会社へ
「システム開発の内製化」と聞くと、すべてのシステムを社員だけで開発する姿を想像するかもしれません。
現在使っているWindowsをLinuxへ置き換え、社内にプログラマーを置き、大規模な独自システムをゼロから作る。そのような取り組みを内製化だと考えてしまえば、多くの中小企業にとって現実的な選択肢にはなりません。
しかし、本来の内製化はそのようなものではありません。
既存の環境や外部の専門家を活用しながら、会社が自社の業務とシステムの方向性を自分で決められる状態を、少しずつ作っていく取り組みです。
Windowsを捨ててLinuxへ移行する話ではない
システム開発にLinuxを利用するといっても、社員が日常業務で使用しているWindows端末をLinuxへ置き換えるわけではありません。
社員は、これまでどおりWindowsを使用します。Microsoft 365などの既存サービスも、必要であればそのまま使い続けます。
一方、独自のWebシステムを開発する場合、その開発環境や本番サーバーにはLinuxを使用します。完成したシステムはサーバー上で動き、社員はWindowsのブラウザから利用します。
役割を整理すると、次のようになります。
- Windowsは、社員が日常業務を行うための端末
- Linuxは、独自システムを開発し、動かすための環境
- ブラウザは、Windowsからシステムへ接続するための窓口
研修でLinuxに触れることも、社員の日常端末をLinuxへ変更するためではありません。
完成したサービスの画面だけでは見えない、サーバー、データベース、権限、処理、記録といった「システムの裏側」を体験するためです。
経営者や担当者を専門技術者にすることが目的ではありません。外部の技術者へ開発を依頼するときにも、何を質問し、何を確認し、何を自社で決めなければならないのかを理解することが目的です。
内製化とは、すべてを社員だけで作ることではない
システム開発の内製化は、外部委託を否定するものではありません。
専門的な開発作業は、外部のエンジニアへ依頼しても構いません。重要なのは、自社の業務、データ、権限、判断基準まで外部へ丸投げしないことです。
外部へ任せるのは「手」であり、会社の「脳」まで任せてはいけません。
最初に内製化すべきものは、コードではなく判断です。
- 何のためにシステムを作るのか
- どの業務を改善するのか
- 何を会社の正式な記録とするのか
- 誰が入力し、誰が確認するのか
- どの状態になれば次の担当者へ渡すのか
- 間違いが起きたとき、どこまで戻せるようにするのか
- 外部へ何を依頼し、何を社内に残すのか
これらを会社自身が決められる状態を作ることが、システム開発の内製化です。
内製化は、一気に進めるものではない
システム開発の内製化は、大規模な開発計画から始める必要はありません。
最初は、現在困っている業務を一つだけ選べばよいのです。
例えば、次のような小さな課題です。
「通知が多く、重要な連絡が埋もれてしまう」
「資料が保存されたことに気づかず、対応が遅れる」
「誰が確認済みなのか分からない」
「次に誰が動くべきなのか見えない」
このような課題に対して、いきなり独自システムを開発する必要はありません。
まず、現在の業務を整理します。
誰が情報を発生させ、誰が知る必要があり、どの状態になったら次の担当者が動くのか。その流れを言葉にし、既存のクラウドサービスや表計算、WordPressなどを使って小さく試します。
既存サービスの設定や運用ルールだけで解決できるなら、それで十分です。
試してみて初めて、既存サービスでは対応できない部分が見えてきます。その段階で、必要な部分だけを独自システムとして開発します。
この順番であれば、大きな費用をかける前に、本当に必要な機能を確認できます。
試作と本番システムを混同しない
小さく始めることは、すべてを簡易的な仕組みで済ませることではありません。
情報を蓄積し、業務の流れを試す段階では、WordPressや表計算などを使った試作が有効です。
一方、次のような処理は、試作の延長で本番運用してはいけません。
- 会計情報を変化させる処理
- 請求金額を確定する処理
- 在庫数を増減させる処理
- 閲覧・操作権限を管理する処理
- 会社の資産や契約状態を変化させる処理
この段階では、データ構造、権限、操作履歴、同時処理、エラー時の復旧などを整理し、本番用のシステムとして設計し直す必要があります。
小さく試す段階と、会社の資産を預ける本番システムを明確に分けることが重要です。
会社のシステム戦略ができてから資金を用意する
内製化を始めた直後から、大きな開発費を用意する必要はありません。
小さな改善と試作を繰り返すことで、次第に会社に必要なシステムの全体像が見えてきます。
- どの業務を優先するのか
- どこまで既存サービスを使うのか
- どの部分を独自開発するのか
- 社内にどのような担当者が必要なのか
- 外部の専門家へ何を依頼するのか
- どれだけの投資効果が期待できるのか
これらが明確になったとき、初めて本格的な資金計画を立てます。
公的な支援制度を活用する方法もあります。出資金を積み増す方法もあります。事業計画を示し、金融機関から融資を受ける方法もあります。
大切なのは、補助金があるからシステムを作るのではなく、会社の戦略を実現するために必要な資金調達手段を選ぶことです。
資金は、方向を決めるために使うものではありません。会社が決めた方向へ、より速く進むために使うものです。
プログラミング教育を受けた世代が社会へ出てくる
日本では、2020年度から小学校でプログラミング教育が必修化され、2021年度から中学校で内容が拡充されました。
2022年度からは、高校の共通必履修科目「情報Ⅰ」で、すべての生徒がプログラミング、ネットワーク、データベースの基礎などを学ぶようになっています。これは文部科学省の資料にも示されています。
もちろん、学校でプログラミング教育を受けた人が、全員そのままシステムエンジニアになるわけではありません。
それでも、コンピューターは完成したサービスを利用するだけのものではなく、自分の指示によって動かせるものだという感覚を持った世代が、これから社会へ増えていきます。
生成AIの普及によって、その動きはさらに加速します。
従業員がAIへ指示し、表計算の自動化、簡単なプログラム、業務用の画面などを自分で作ることは、特別な出来事ではなくなります。
経営者が「内製化しない」と決めていても、現場では小さな内製化が自然に始まります。
問題は、それを禁止するか許可するかだけではありません。会社として管理し、育てられるかどうかです。
若い人材を「一人だけのシステム担当者」にしてはいけない
プログラミング教育を受けた若い社員が入社しても、会社側に受け入れる仕組みがなければ、その能力を生かせません。
詳しい社員一人にすべてを任せれば、システムはその人に属人化します。本人が異動・退職した途端に、誰も仕組みを理解できなくなります。
反対に、自由な改善をすべて禁止すれば、せっかくの能力と意欲を失わせます。
会社が用意すべきものは、若い人材を孤立させず、安全に挑戦させられる土台です。
- 試作してよい範囲を決める
- 本番データへ直接触れさせない
- ソースコードや設計情報を会社で共有する
- 一人で判断せず、確認を受ける仕組みを作る
- データ、権限、履歴に関する基本ルールを設ける
- 必要な場面では外部の専門家へ相談する
- 作った人がいなくなっても継続できる状態にする
これらが整っていれば、若い社員の能力を会社の知識として蓄積できます。
内製化とは、優秀な個人へ仕事を集中させることではありません。個人の知識を、会社全体が継続して使える仕組みへ変えることです。
最初の一歩は、一つの困りごとを言葉にすること
システム開発の内製化は、完成した大規模システムを目指して始めるものではありません。
まず、一つの困りごとを選びます。
その業務について、誰が、何を、いつ、どの状態で、どの理由によって扱っているのかを整理します。
既存の道具で小さく試し、足りないものを見つけます。会社として必要な判断基準を蓄積し、少しずつシステム戦略を作ります。
戦略が固まった段階で、公的資金、出資、融資などを活用し、外部の専門家とも連携しながら本番システムへ育てていきます。
そして将来、プログラミング教育を受けた人材が入社したとき、その知識と発想を安全に受け止め、会社の力へ変えられる状態を作ります。
内製化の目的は、社員だけですべてのコードを書くことではありません。
会社が、自分たちの業務とシステムの将来を、自分たちで決められるようになることです。
一つの業務を整理し、一つの小さな改善を試す。
その積み重ねが、将来の人材を受け止め、自社の知識を育て続けられる会社へつながります。