キ?マンズネット編集部は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が?い」や「アプリの動き」が?いなど、業務ロジック以外の指摘があった。
- 業務ロジックは優秀だが、表示スピ?ドが?くストレスになるという?業員からの不?
- アプリが重くなって動作が不安定になるなどベンダ?を介さない弊害が?生した
- UXが?く誤操作や問合せが多い。常にマニュアルが必要
- コスト（人件費）が見えにくく、?果の無さそうな案件でも、安易に依?されてしまう
- ユ?ザ?側は、ITで何でもできると思いこみ、無理なことを?いられる
- 相手部門がやってくれて?たり前という態度になりがち
最後に、システム?製化の失敗エピソ?ドを紹介する。?製化を?討している人は?考にしてほしい。
- 中核デ?タサ?バのデ?タを全て削除した
- 社長が自分で責任をもってやると言った仕事が、いつの間にか社員の仕事に代わり、社長から理不?に叱責された?業員が?多くいる
- しなきゃいけないル?ルとツ?ルの機能が連動しきれてなくて、不足?理を後から指摘されて手?りしたりする。SIerなのに恥ずかしい
- 多額の費用をかけたにも?わらず何も成果を出せなかったこと
- 開???者が異動しメンテナンスができなくなったため、結局パッケ?ジシステムを導入することとなった