AI時代でもシステム開発が失敗する理由～中小企業のシステム自製の落とし穴～
AIによるコード生成技術の進歩で、システム開発のハードルは大きく下がりつつあります。一方、「AIを使えば業務フローを自動化できる」甘い認識が現場と管理職の間で思わぬ認識のギャップを生み出しています。
システム開発の失敗には共通点がある
前回の記事では、システム開発の現場ではAIに頼るだけでなく、開発担当者がシステムの運用・保守を見据えた開発を行うため、エンジニアリング的思考を学ぶことの重要性について解説しました。
システム開発では、こうした教科書に書いてるようなIT知識だけではうまくいかないことが多々あります。
私自身、様々な会社でシステム開発を見てきました。
その中で、気づいたことがあります。
失敗には共通点がある
今回は、システム開発における見えない壁についてお伝えします。
なぜ、あなたの会社はAIによるシステム開発が進まないのでしょうか。
AIが原因でシステム開発が失敗するわけではありません。
むしろ、人間同士の認識のズレが原因であることが少なくありません。
私が感じたシステム開発のギャップ
私が様々な職場、部署でシステム開発を行ったなかで、一番感じたギャップがあります。
それは、
幹部は「作れば終わり」
と考える一方、
現場は「運営が始まる」
と考える、危機感の不一致です。
落とし穴① 「コードを書く」ことが仕事だと思われる
理解が得られにくいことの一つに、システム開発は「コードを書くこと」がメインだと誤解されているケースがあります。
コード記述後のテスト・改修作業に十分な時間を確保できないまま稼働開始しようとするケースもみられてしまいます。
場合によっては、「コード1行を消すのになんでそんなに時間がかかるの？」と言われることもありました。
コードを削除するのにも、ほかに影響するコードはないか、テストを複数実施しなくてよいかなど、想像以上に工数がかかることが理解されないケースすらあります。
また、システムに関連する部署がダミーデータの提供や、データの要件確認等に対してあまり協力的でない場合もあり、「システム開発担当だけでなんとかして」といった無茶ぶりを要求されることがあります。
幹部がこうした部署間の橋渡し等について、サポートしないうえ、プロジェクトリーダーに部署間の調整を強気に行使するだけの権限がない場合には、過度なプレッシャーがかかり、プロジェクトがとん挫しかねない状況にすらなります。
こうした結果、プログラムが完成しても、
- 安定稼働できない
- 保守を開発担当者の経験に頼る
といったケースが発生し、システム稼働が逆に生産性を落とすことすらあります。
落とし穴② 運用・保守は軽視される
世の中にあふれているシステム化・自動化による生産性向上の事例を見ると、
- AIで〇〇を自動化
- Pythonでデータ連携
といったように、システム開発がゴールであるという誤解が生まれている気がしています。
プロジェクトリーダーとしてシステム開発に携わると、システム完成後の運用・保守について考えながら、設計を行います。
特に中小企業では、システム開発者が実質的に運用・保守の責任を担うという暗黙のルールが存在していることが多く、開発段階でこの負担を減らすことをしっかり考えておかないと、自分の首を絞めることになります。
一方、上司や関連部署など、システム開発の経験が少ない人は、データ連携や自動化など、システムの中核機能が実装されているかという点と金銭的コストのみに興味が集まりがちです。
このため、運用・保守負担の軽減に必要な
- エラー検知機能
- ログ出力機能
- エラー時のロールバック機能（データをシステム起動前の状態に戻す機能）
- システム障害時の対応マニュアル
といった、細かい機能が軽視されがちです。
システム開発では、こうした補助的な機能の実装は、メイン機能実装よりも工数が大きくなることがあります。
システムは開発が完了すればその後は自動的に業務生産性が向上すると思い込んでいる人がいると、システム設計に粗さが目立ちます。
結果としてシステムのエラーが頻繁に起こり、現場の負担だけが増えていくのです。
落とし穴③ システム開発を丸投げする
これは、どんな業種・職場でも体験してきました。
いわゆる管理職の立場の人は、職種の専門性にはある程度の知識がある一方、ITリテラシーが低いことがあります。
この結果、会社全体として生産性向上を課題とされることが多い中、知識・経験が多くない上に、「ITリテラシーを身につける機会を後回しにしてしまう」ケースも見られます。
その結果、「業務を自動化して」とか「システムを開発して」といった形で、生産性向上を丸投げします。
一方で、管理職として何かダメ出しをしなければならないという衝動に駆られるからか、
- なんとなく予算がかかりすぎではないか
- いつまでに完成するんですか
といったように、ただ、プレッシャーをかけるだけの進捗報告会になりがちです。
また、ＩＴリテラシーの格差が大きすぎて、システムの要件を具体的に説明しているときりがありません。
このため、開発に必要なシステムへのアクセス権限の付与や、他部署管理職への調整などについては、協力するどころか、「情報セキュリティ的にダメです」とか、「できる範囲で何とかしてください」といったように、無茶ぶりをするケースすらあります。
落とし穴④ 開発途中で要件を変更
システムのイメージが具体化してくると、仕様を変更したいと言い出す人が必ずと言っていいほど出てきます。
事前に機能や運用をすり合わせして、何度も確認しても、それでも仕様を変更したいと言ってきます。
しかも、こうした場合、予算やスケジュールを変更することに強い難色を示すことがあり、非常にストレスがかかります。
この点、システム開発者はパワーバランス的に弱い立場であることが多く、相手の無理な要求を受け入れざるを得ないこともあります。
こうした、様々なギャップを解消するのは難しく、今までシステム化が順調にいかないケースを多々見てきました。
落とし穴⑤ 開発担当だけ責任を負う
システム開発では、運用・保守を含めたシステムのライフサイクルに対する理解が少ないと、開発者に対して、「なぜそんなに工数がかかるのか」「早くシステムを稼働できないのか」といった過度なプレッシャーがかかることがあります。
これは、システム開発および運用が「スムーズにいくことを前提に話してしまう」ことが原因です。
ある程度経験のあるエンジニアであれば、むしろ「スムーズにいかないケースを想定しながら開発を進める」といった意識ができています。
一方で、こうした経験が浅い場合、
- 無理な予算配分
- 早すぎる納期
- システム要件を断続的に追加
といった形で、システム開発者に対する要求だけが増えていきます。
ただし、システム開発者に対するフォローは一切なし
本来責任を取るはずの管理職ですら、「システムについて詳しいことはわかりません」と言って、システム開発に対する知識や理解力を高めようとしないケースもあります。
こうした「開発担当だけが責任を負う」という構造が、現代の日本でプロジェクトリーダーが不足しているといわれる要因の一つだと考えています。
なぜ中小企業ほど失敗するのか
中小企業では、経営が安定してくるとデータ分析基盤の導入を検討するケースが増えてきます。
しかし、データ分析基盤の導入は技術的には可能でも、思わぬ落とし穴にハマる場合があります。
それは、
部署ごとの縦割り文化
です。
例えば、中小企業では部署ごとの文化が強く、データを自分たちの所有物と考えるケースがあります。
システム担当は「全部門のデータをください」と言う立場になりますが、各部署には協力するインセンティブがありません。
中小企業ではジョブローテーションが少なく、長年管理職が変わらない会社が多いです。
その結果、
- データの管理方法を他部署に合わせなければならない
- データ管理や要件の把握があいまいであることを指摘されたくない
- 他部署に協力しても自分たちの成果につながらない
といった心理的な壁ができてしまい、部署横断的な協力体制ができません。
システム開発は技術ではなく、人間関係で止まることがある
これは、システム開発担当者の力では限界があるため、経営層による強力なリーダーシップがなければ、プロジェクトが進まなくなるというのが現場のリアルです。
大企業は人件費をSaaS利用料に置き換えている
大企業では、データ分析基盤の導入に際して、SnowflakeやSalesforceなどのシステムを導入するケースが増えてきました。
ここで大事なのは、
「Snowflakeは有名だから高い」
ではありません。
Snowflakeが売っているのはデータベースではなく運営コストの削減です。
中小企業はお金がないから内製する。
しかし、内製すると
- 設計
- 保守
- 障害対応
- 監視
- 引継ぎ
全部自社になります。
結果として、システム利用料を払わない代わりに人件費という形で払うことになります。
これが、社員の負担になる点を考慮しなければ、現場のストレスはますます増えていきます。
大企業はSaaSを買っているのではありません。
運用を買っているのです。
本当に必要なのはシステム思考
経理現場では、生産性向上が長年の課題となっています。
しかし、最近のトレンドを考えると、
- AIを使った業務改善事例の収集
- データ分析基盤の構想を考える
- 新しいSaaSが導入できないか調べる
- 情報システム部にシステム開発を相談する
といった、「手法」に頼った生産性向上を目指しているケースが見られます。
しかし、AI時代に求められているのは、こうした「手法を知る」ことではなく、「システム思考」です。
経理業務であれば、
データ取得
↓
チェック
↓
異常検知
↓
修正
↓
証跡
といった流れがあります。
こうした事務処理の進め方は、システム設計にも応用できます。
経理業務で培ったデータ確認の流れ、異常を見つける観点といった目線をシステム開発に落とし込むことが求められています。
「ITの知識がないから」、とか、「業務の自動化経験がないから」と言って、AIにすべてを任せて開発を行っていては、運用・保守でつまづきます。
コードはAIが書いてくれるけど、運用・保守はまだまだ人間のエンジニアリング的思考が必要な部分です。
経理担当者も勉強なり、経験なりで、このエンジニアリング的思考を自発的に習得しようとできるかで、システムの開発・運用・保守のハードルが大きく下がっていくことをぜひ、体感してほしいです。
まとめ
今回は、エンジニアリング経験をもとに、システム開発で陥りやすい落とし穴について解説しました。
AI時代になっても、システム開発が失敗する原因の多くは技術ではなく、人や組織、運用設計にあります。
巷には、AIによる生産性向上事例があふれています。
経営者や管理職がシステム開発に対する理解ができていない場合、開発現場に過度な負担がかかります。
システムに関わる全ての方には、この記事を教訓に丁寧なコミュニケーションをとりつつ、開発・運用を行っていただければ幸いです。
AIが書くコードよりも、
人がつくる運用体制のほうが、
システムの成否を左右する。
だからこそ、AI時代ほど「システムを運営できる人」が価値を持つのだと思います。
さらに深掘りする：関連記事
別の記事では、業務効率化やシステム開発において意識しておきたいことを経験をもとに解説しています。
業務効率化
以下の記事では、会計業務におけるRPA導入における失敗談とその背景や原因について解説しています。
以下の記事では、業務効率化で意識しておきたい、保守負担とのトレードオフについても解説しています。
以下の記事では、会計業務におけるデータの二重入力をデータ連携により効率化したエピソードを紹介しています。
データ分析
以下の記事では、データドリブン経営を進めるうえでのポイントを、有名なFPSゲームAPEXのデータ分析を参考に解説しています。
システム開発
以下の記事では、通販会社で膨大な量の売上・入金データの突合システムをBigQueryで構築した実体験と大規模システム構築でぶち当たる悩みについて投稿しています。