『自分たちで作ればうまくいくはず』——そんな期待を裏切り、現場も経営層も疲弊したシステム内製化プロジェクト。
なぜこのような結末になったのか、現場のリアルな声と失敗から学ぶべきポイントを、失敗体験をもとに丁寧に解説します。
【関連記事】SIerの課題を解決！PMOの導入メリットとは
プロジェクト始動——内製化への決断とその波紋
老朽化した社内システムに悩む自動車部品メーカーが、システムの内製化という大きな決断を下し、その実行に踏み切るまでの過程を紹介します。
A社の現状とシステム刷新の必要性
自動車部品メーカーA社は、従業員約1000名規模で国内外に拠点を構える中堅企業です。主に自動車のドア部品やロックヒンジ、シート部品などを製造し、国内大手自動車メーカーを中心に安定的な取引を続けてきました。不況やコロナ禍を乗り越え、業績は堅調に推移していますが、長年運用してきた社内システムの老朽化と、それに伴う維持費の高騰が経営の足かせとなっています。
老朽化したシステムを使い続けることによるデメリットは以下の通りです。
- 業務効率の低下：手作業や二重入力が増え、作業ミスや無駄が発生しやすい。
- 柔軟性の欠如：新しい業務や部門間連携に対応できず、ビジネスチャンスを逃す。
- 属人化・ブラックボックス化：特定の担当者に依存し、全体の把握や引き継ぎが困難。
- コスト負担の増大：保守費用やライセンス料が年々増加し、経営圧迫要因となる。
- データ活用の限界：最新のデータ分析やAI活用が難しく、経営判断の迅速化が阻害される。
こうした課題に対して経営層は強い危機感を抱いています。
「このままでは競争に遅れてしまう。何とかしなければならない」
現場からはシステム刷新を求める声が高まっており、経営陣も現状打破の必要性を強く認識しています。
システム更改の決断――外注か、内製か
これまでA社は外部のシステムベンダーに基幹システムの開発・運用を委託してきました。ベンダーの対応は丁寧でしたが、システムの改修やUIの改善など、現場の要望がすぐに反映されない点に不満が募っていました。何か変更を依頼するたびに時間がかかり、業務効率の低下に直結していました。
そんな中、経営層の旧知のコンサルタントから「内製化してはどうか」という提案が持ち上がりました。ローコードツールを使えば、ITに詳しくない社員でも簡単にアプリケーション開発が可能です。現場の声をダイレクトに反映したシステムが短期間で構築できるというメリットがあります。
外注と内製化のメリットを比較すると、以下の通りです。
外注のメリット
- 専門知識やノウハウを活用できる。
- 大規模なシステム開発も外部リソースで対応可能。
- 運用保守もベンダーが責任を持って対応する。
内製化のメリット
- 現場の業務知識を活かしたシステム設計が可能。
- 要望や改善が迅速に反映される。
- コスト削減やノウハウの社内蓄積が期待できる。
- ローコードツールでIT未経験者も開発に参加可能。
A社はこれらのメリットを比較検討し、内製化によるシステム更改を選択しました。
「ローコードなら、ITに詳しくない人でも開発に参加できるはず…」
現場の声を活かし、自社の業務に最適なシステムを自ら作り上げることで、今後の競争力を高めていくことを決意しました。
システム内製化プロジェクトの始動
SIer頼みだった基幹業務システムを、ローコードツールを使って内製化するプロジェクトがスタートしました。経営層は「これからは自分たちでシステムを作る時代だ」と意気込み、全社的な体制でプロジェクトを推進することを決定しました。
コンサルタントのアドバイスを受け、まずはプロジェクトの計画を立て、各部門から選抜されたメンバーをアサイン。ローコードツールのトレーニングも実施し、IT未経験者でも開発に参加できる環境を整えました。表向きは順調にプロジェクトが進んでいます。
システム更改のミーティングでは経営層から様々な要望が出ました。
「生産計画がリアルタイムで見えると面白いよね」「この際だから、AIによる不良品検出もやってしまおう」など、理想的な機能への期待が次々と語られました。
結果として、要求機能は既存システムの置き換えの範囲を超えて、以下のように膨れ上がることとなりました。
- 生産計画や進捗管理のリアルタイム可視化
- 在庫状況の自動集計とアラート機能
- 発注・受注データの自動連携とダッシュボード表示
- 品質管理データの一元管理と異常検知
- 社内外のコミュニケーションを支援する内製チャット機能
- 現場作業のマニュアルや手順書の電子化・共有化
- AIによる不良品検出の自動化（将来的な拡張）
最終的に完成したプロジェクト計画書は、関係者の夢や希望が詰まったものとなりました。一方、実際にプロジェクトに参加する関係者からは「現状のシステムの課題をすべて解決し、さらに多数の機能を取り入れようとしている。本当にうまくいくのだろうか」との不安の声も上がっていました。結果として予感は的中し、このプロジェクトは理想と現実の間で迷走することになります。
プロジェクトの迷走と結末
プロジェクトが本格的に始動すると、関係者の懸念は現実のものとなりました。現場では作業の遅れや仕様のやり直しが頻発し、誰もが困惑と疲労を感じ始めます。
プロジェクトの現実
実際にプロジェクトが開始されると、現場ではすぐに作業の遅れや仕様のやり直しが頻発しました。仕様書や設計書のバージョンが乱立し、どの文書が最新か分からなくなる状況も続きました。
「今週中に仕様を確定する予定だったのに、またやり直しになった。追加機能の要望が毎週のように出てきて、どこまでやればいいのか分からない」
現場の担当者はこう漏らします。
「こんなに仕様が変わるなら、最初からしっかり決めてほしかった」
「ベンダーへの問い合わせが山積みで、作業が止まってしまう」
現場からは疲弊と混乱の声が上がり続けました。
「朝から夜まで会議が続き、肝心の開発が進まない。また、誰が何を決める権限を持っているのかも分からない」
あるリーダーはため息混じりに語ります。
「仕様書が毎日書き換わる。昨日まで決まっていたはずのことが、朝会議で覆る。こんな状況でどうやって開発を進めればいいのか」
現場のエンジニアは困惑の表情を浮かべます。
混乱の背景
これらの問題の背景には、以下のような根本的な課題がありました。
プロジェクトの目的やゴールが曖昧
プロジェクトの目的やゴールが明確に共有されず、関係者間で認識が大きく異なっていました。現場では「何のためにこのプロジェクトをやっているのか」「最終的にどんなシステムができれば成功なのか」が誰にもはっきり分かりませんでした。そのため、各人が自分の理想や都合を主張し、仕様が常に揺れ動く状況が続きました。
関係者間の認識が揃わない
現場・経営層・部門間で意見が食い違い、作業の重複や仕様の齟齬が多発しました。会議では同じ内容を何度も話し合い、結論が出ないまま時間だけが過ぎていきました。誰もが「自分が正しい」と思い込み、他の意見に耳を傾けない空気が蔓延していました。
開発対象がどんどん拡大
一部機能の刷新から始まったはずが、気づけばシステム全体の刷新へと膨れ上がり、当初のリリース予定を大幅に超過しました。「この機能も必要だ」「あの機能も入れたい」と要望が次々と追加され、開発範囲が際限なく広がっていきました。現場では「もうどこまでやれば終わるのか分からない」という声が上がり始めました。
現場の混乱
プロジェクトの目的やゴールが曖昧なまま進んだことで、現場は混乱の極みに陥りました。事前にローコードツールの基礎研修は実施したものの、実際の開発経験がないまま本番開発に突入したメンバーが大半でした。大規模システムの開発ノウハウを持たない現場は、仕様の不明確さや設計の甘さに悩まされ、トラブル対応に追われる日々が続きました。
「ローコードツールの使い方が分からない部分が多く、ベンダーへの問い合わせが山積みになっている。回答があるまで作業が止まってしまう」
現場のエンジニアはこう訴えます。
「要件定義や設計はベンダーに丸投げしている。社内にノウハウが蓄積されず、いつまでたってもベンダー依存体質から抜け出せない」
プロジェクトリーダーはため息をつきます。
結合テストとプロジェクトの破綻
それでも、なんとか製造からテスト工程へとこぎつけました。しかし、品質基準やドキュメント作成ルールの曖昧さが露呈し、各担当者の自己流の記載が目立つようになりました。ドキュメントを読むだけで一苦労する状況が続き、現場の混乱はさらに深まっていきました。
「ドキュメントの書き方がバラバラで、読むだけで疲れる。誰が何を書いたのかも分からない」
ある品質管理担当者は頭を抱えます。
単体テストでは発見できなかった不具合が結合時に一挙に露呈し、結合テストを途中で中止せざるを得ないほどの状況に陥りました。
「単体では問題なかったのに、結合したら一気に不具合が出てきた。もうどうしていいか分からない」
現場のエンジニアは困惑の表情を浮かべます。
最終局面と関係者の疲労
最終的に、A社は外部の専門人材の投入を決断しました。これにより、予定していたスケジュールとコストを大幅に超過しながらも、ようやくシステムの完成にこぎつけることができました。しかし、関係者の間には疲労感しか残らず、プロジェクトの成功を祝う余裕もありませんでした。
「とにかく疲れた。振り返る気力もない」
この一言に、プロジェクトに関わった全員の心情が集約されていました。
「やらない方がマシだった」という結末と、得られた教訓
膨大な手間とコストを費やしながらも、プロジェクトは当初の期待を大きく裏切る結果となりました。どこに問題があったのでしょうか？ここでは、A社の内製化プロジェクトの結末とそこから得られた教訓について解説します。
【参考】システムの内製化を成功させるには
プロジェクトの結末と現場の混乱
膨大なリソースと時間を費やしたにもかかわらず、プロジェクトが残したものは少なく、現場には疲弊と失望が広がりました。
システムは特定の担当者に依存し、属人化・ブラックボックス化が進みました。保守性は著しく低下し、ちょっとした仕様変更や障害対応にも多大な時間と手間がかかるようになりました。
経営層の熱意も失速し、プロジェクトの意義そのものが問われる状況に。会議では「こんなに苦労したのに、何が良くなったんだ？」「本当にやるべきだったのか？」といった不満が口をついて出るようになりました。
リリース後もトラブル対応や仕様の問い合わせが相次ぎ、システム部門は対応に追われてパンク状態。現場の環境の悪さから離職者も出始め、体制はさらに脆弱化しました。
経営層・プロジェクト関係者・一般社員が口を揃えて言うのは、
「やらない方がマシだった」
という一言です。
内製化が失敗した原因の整理
A社の内製化プロジェクトが失敗した原因は何だったのでしょうか。ここまでのエピソードから考えられる失敗の原因を整理します。
- 目的・ゴールの曖昧さ：プロジェクトの目的やゴールが明確に共有されず、関係者間で認識が大きく異なっていました。その結果、開発範囲が際限なく拡大し、現場は混乱に陥りました。
- 関係者間の認識の不一致：現場・経営層・部門間で意見が食い違い、作業の重複や仕様の齟齬が多発しました。誰もが「自分が正しい」と思い込み、他の意見に耳を傾けない空気が蔓延していました。
- 開発対象の拡大とスコープクリープ：一部機能の刷新から始まったはずが、システム全体の刷新へと膨れ上がり、当初のリリース予定を大幅に超過しました。要望が次々と追加され、開発範囲が際限なく広がっていきました。
- 品質基準・ドキュメント作成ルールの曖昧さ：品質基準やドキュメント作成ルールが明確でなく、各担当者の自己流記載が目立ちました。ドキュメントを読むだけで一苦労する状況が続き、現場の混乱はさらに深まっていきました。
- 事前トレーニング不足と現場の習熟度不足：ローコードツールの基礎研修は実施したものの、実際の開発経験がないまま本番開発に突入したメンバーが大半でした。大規模システムの開発ノウハウも不足しており、トラブル対応に追われる日々が続きました。
- 人材の欠如とナレッジ蓄積の失敗：社内に大規模システムの要件定義や設計を行える人材がいなかったため、必要なスキルを持つ人材を外部から得る必要がありました。また、最終的に外注に頼った結果、社内には技術的な知識が蓄積されませんでした。
もし、ローコード開発と業務改革に精通したPMがいれば…
外部PMやPMOの知見があれば、以下のような改善が実現できたと考えられます。
- 目的・ゴールの明確化と範囲の整理：プロジェクトの目的やゴールを明確にし、範囲を現実的に絞り込むことでスコープクリープを防ぎ、現場の混乱を最小限に抑えられた。
- 必要なスキルやリソースの見積もり：現場の習熟度やリソース状況を客観的に把握し、必要なトレーニングやリソース確保を事前に計画できた。
- 事前研修やPoCによる現場の習熟度向上：ローコードツールの実践的な研修やPoC（概念実証）を実施し、現場の習熟度を高めることができた。
- ベンダーとの役割分担やノウハウ移転の仕組み設計：ベンダーとの役割分担を明確にし、ノウハウ移転の仕組みを設計することで、社内に知識やスキルが蓄積された。
- 開発プロセスや品質基準の標準化：開発プロセスや品質基準を標準化し、ドキュメント作成ルールも明確にすることで、現場の混乱を防げた。
- 経営層と現場の橋渡し：経営層と現場の認識を一致させ、意思決定を迅速化できた。
- 運用・保守体制の構築：リリース後の運用・保守体制も事前に設計し、トラブル対応や問い合わせにも迅速に対応できた。
A社の失敗から学ぶべきことは、内製化そのものが目的化してしまい、本来のメリットを活かしきれなかった点にあります。システムの内製化は、目的・ゴールの明確化、現実的な範囲設定、必要な人材やスキルの確保、ベンダーとの適切な役割分担、そしてリスク管理が不可欠です。
内製化のメリットを活かすために何が必要か
A社の事例を読んで、「やっぱり内製化は怖い」と感じた方もいるかもしれません。しかし、リスクを適切に管理できれば、内製化には様々なメリットがあります。
内製化のメリットは、「自社の業務に最適なシステムを柔軟に構築できる」「ノウハウが社内に蓄積される」「運用・改善のサイクルが速くなる」など多岐にわたります。しかし、これらのメリットを享受するには、プロジェクトの初期段階で目的・範囲・体制・リスクを明確にし、現場と経営層の認識を一致させることが重要です。
また、外部PMやPMOの知見を活用し、現実的なスモールスタートから始めることで、失敗のリスクを大きく減らすことができます。A社の経験は、内製化の本質を見誤った場合にどれほど大きな代償を払うことになるかを示す教訓となりました。
今後、内製化を検討する際には、A社の失敗から学び、目的・範囲・体制・リスク管理を徹底することが求められます。内製化のメリットを活かすためには、何よりも「何のために内製化するのか」を明確にし、現場と経営層が一丸となって取り組むことが不可欠です。
この記事を書いた人
