「中核サーバのデータを全て削除……」 事前に知りたい、読者の内製化トラブル事例集

第4回の本稿は「システム内製化」の調査結果を見ていく。読者のシステム内製化状況やシステム内製化の課題・トラブルのエピソードを紹介する。内製化を検討してる人は、読者の経験を知ることで内製化の失敗を避けられるだろう。

[キーマンズネット]

　キーマンズネット編集部は2024年に注目すべきトピックスとして「セキュリティ」「SaaS」「コミュニケーション／コラボレーション」「生成AI（人工知能）」「システム内製化」「データ活用」「Windows 11」の7つのトピックスを抽出し、読者調査を実施した（実施期間：2023年11月10日〜12月8日、有効回答数424件）。

　第5回の本稿は「システム内製化」の調査結果を見ていく。記事の前半では読者のシステム内製化状況の概要を、後半ではシステム内製化の課題やトラブルエピソードを紹介する。内製化を検討してる人は、トラブルエピソードを知ることで内製化の失敗を避けられるだろう。

結局はコスト削減が目的？　内製化状況の実態が明らかに

　まず、業務システムの内製化状況を聞いたところ、24.1％の企業が業務システムを全て内製化していることが分かった。その一方、26.9％が業務全ての開発を全てSIer（システムインテグレーター）に任せており、38.0％が内製と外注の両方を活用している状況から、64.9％の企業が何らかのシステムを外注しているのが分かる。（図1）。

図1　業務システムの内製化率

　従業員規模別に見ると、100人以下の企業は、全てのシステムを内製化している割合が31.1％、全てをSIerが開発している割合が27.4％と他の規模帯に比べて一番高く、システムを内製している企業と外注している企業の二極化が進んでいる。

　次にシステム内製化の目的を聞いた。内製化の目的は上位から「開発コストの削減」が59.9％、「技術力や知見の蓄積」（39.0％）、「DXの推進」（32.1％）と続き、1位の「開発コストの削減」が2位以降に大きく差をつけた（図2）。

図2　システム内製化の目的

　従業員規模別に見ると、100人以下の企業では「コスト削減」が75％、5001人以上の企業は「DXの推進」を目的とする割合が41.1％と顕著に高い。企業規模が大きくなるにしたがって、内製化の目的がコスト削減からビジネスへの寄与に変わるのだろう（図3）。

図3　企業規模別のシステム内製化の目的

　内製化しているシステム領域について聞いたところ、上位から「経費精算」（23.6％）、「販売」（22.8％）、「データ分析」（22.4％）と続き、極端に内製化されているシステムはないことが分かった（図3）。選択肢以外は、少数ではあるが「電子メール」や「コミュニケーションツール」「勤怠管理」「ワークフローツール」といった回答が寄せられた。

　業界別に見ると、IT関連業はプロジェクト管理のシステムを内製化する傾向があり、製造業は在庫管理や生産管理、品質管理のシステムを内製化する傾向にあった。企業規模別で見ると、5001人以上の企業は「データ分析」（39.4％）、「マーケティング」（13.6％）といった、データに関するシステムを内製する傾向にある。

図4　内製化している領域

　システム内製化をどのような方法で進めているのかを聞いたところ、「プログラミング」が63.5％と圧倒的に高く、2位以降は「Excelマクロ」（29.3％）、「ローコード開発ツール」（25.5％）、「ノーコード開発ツール」（17.5％）と続いた。

　企業規模別に見ると、100人以下の企業は「Excelマクロ」が46.4％となった。同規模帯の企業はシステム内製化の目的として「コスト削減」を掲げる企業が多いことから、コストをかけずに内製化を進められる「Microsoft Excel」が採用されるのだろう。

図5　内製化の方法

内製化前に知りたい、読者のトラブルエピソード集

　システム内製化の課題についてフリーコメントで聞いたところ、人材不足と属人化についてのコメントが多く寄せられた。

＜人材不足の課題に関するエピソード＞

• 人材が少なく、スキルも高くない。
• ベンダーロックインを避けるために始めたものの、内製化の人材を簡単には増やせない
• まともな技術者、まともなマネジャーが存在しない
• まともなスキルを持った管理者が長期にわたり不在なため
• 要件定義、設計、開発、テストを全て自社で行う必要があるためリソースが足りない

＜属人化の課題に関するエピソード＞

• システムの更改が担当者異動で困難になる例がある
• 内製化システムの後継者不足
• 一人体制のため属人化している
• 古いシステムとなりメンテナンス困難、製作者の退職によるブラックボックス化
• 情報リテラシーの高いスタッフの退職（流出）

　内製化を進める人が少ないだけではなく、内製化スキルを持った人が少ないというコメントも多い。

　続いて、システム内製化によって起きたトラブルを聞いた。まず、内製化の課題で多く寄せられた人材不足や属人化に起因するトラブルを紹介する。

＜人材不足や属人化に起因するトラブルエピソード＞

• ナレッジの継承に経営者が興味がないためブラックボックス化したシステムが存在している
• 担当者が退職してしまい、全部やり直しになった
• 特定要員に知見が限定される。人的流動性に課題あり
• プロジェクトや仕事の進め方、プログラミングコードのクオリティーなど、担当者スキルレベルがもろに影響するため、なかな新規人員を補填できない

　システム内製化の課題でも挙げられていたように、内製化したシステムがブラックボックス化したことによるトラブルが多く寄せられた。担当者が不在になったことでシステムが更改できない、全部作り直しになったといった本末転倒なトラブルもある。

　要件定義、開発、運用といった開発フェーズごとのトラブルに関するコメントも多い。各フェーズごとにトラブル詳細を見ていく。

＜要件定義のトラブルエピソード＞

• ヒアリング不足や情報共有不足により要件が後から変わり、要件未達成のシステムになってしまったことで、利用されない
• ユーザー部門間での相反する要求事項
• 使用する部門と開発部門が違いコミュニケーションが取れていない
• 情報不足による仕様漏れが発生した
• 要件が定義されない（なあなあになる）
• レアケースの評価と再現テスト
• 同じ業務なのに従業員ごとに要求する動作仕様が異なり、統一仕様が作れない

＜開発のトラブルエピソード＞

• 制作に時間がかかり過ぎた
• 要件定義後、実装中に利用部門からの仕様変更が多数発生
• プロジェクトがまともに管理されず破綻した
• 大型プロジェクトになると進捗管理が難しい
• ローコード開発ツール自体がもつバグや制約の存在
• 開発期間が予定より長くなり、サービス開始が遅れた

＜運用のトラブルエピソード＞

• 担当不在時に障害から復旧できず、作業効率が落ちてしまった
• サポートが終了する予定の古い技術を使って業務システムを作成していたため、全プログラムの見直しと修正が必要となっている
• 運用保守もやっていかないといけないためリソースが割かれる
• ローコード／ノーコードツールに関して、仕様確認、不具合問い合わせの窓口が社内にない
• メンテナンスされず脆弱（ぜいじゃく）性が放置されがち
• 適切に文書化されておらず、開発者の退社で問題が表面化する
• セキュリティ対応に追われる

　要件定義においては、「ユーザー部門間の異なる要求をまとめることに苦労している」といった意見が多く見られた。開発においてはプロジェクトの遅延や破綻、運用においては「障害時の担当者不在によるトラブル」が多い。内製化は開発に焦点が当てられがちだが、正しく運用にもリソースを避けなくては本来の目的は達成できない。中には「メンテナンスされず脆弱性が放置されがち」といったコメントがあり、事業リスクを抱えている企業もある。

　普段システム開発を専門としていないIT部門が開発することで起きるトラブルもある。「UI／UXが悪い」や「アプリの動き」が悪いなど、業務ロジック以外の指摘があった。

＜IT部門が内製化したことによるトラブルエピソード＞

• 業務ロジックは優秀だが、表示スピードが遅くストレスになるという従業員からの不満
• アプリが重くなって動作が不安定になるなどベンダーを介さない弊害が発生した
• UXが悪く誤操作や問合せが多い。常にマニュアルが必要
• コスト（人件費）が見えにくく、効果の無さそうな案件でも、安易に依頼されてしまう
• ユーザー側は、ITで何でもできると思いこみ、無理なことを強いられる
• 相手部門がやってくれて当たり前という態度になりがち

　最後に、システム内製化の失敗エピソードを紹介する。内製化を検討している人は参考にしてほしい。

＜失敗エピソード＞

• 中核データサーバのデータを全て削除した
• 社長が自分で責任をもってやると言った仕事が、いつの間にか社員の仕事に代わり、社長から理不尽に叱責された従業員が数多くいる
• しなきゃいけないルールとツールの機能が連動しきれてなくて、不足処理を後から指摘されて手戻りしたりする。SIerなのに恥ずかしい
• 多額の費用をかけたにも関わらず何も成果を出せなかったこと
• 開発担当者が異動しメンテナンスができなくなったため、結局パッケージシステムを導入することとなった