なぜベトナムはERPシステム開発に向いているか

2025年のAI活用

2025年は企業におけるAI活用が実証実験から本格導入へと移行する転換期となっている。生成AI市場は急速な拡大を続けており、専門人材の不足を補うソリューションとして中堅企業にも急速に普及が進んでいる。大手企業では数百億円規模の投資計画が発表され、業務効率化だけでなく新規事業創出への期待も高まっている。本記事では、2025年に押さえておくべきAI活用の主要トレンドを解説する。

自律型AIエージェントの台頭

2025年の最大のトレンドは「AIエージェント」の台頭である。エージェント型AIは、ユーザーが設定した目標に向けて自律的に計画を立て行動する新しいAIシステムであり、従来のAIアシスタントとは異なり人間からの直接的な指示がなくても主体性を持って行動できる点が特徴である。また、画像、音声、テキストを統合的に処理するマルチモーダル技術の進化により、業務プロセスは新たな段階へと移行している。複数の情報形式を同時に分析することで、これまで見えなかった相関関係の発見が可能となり、意思決定の精度向上に貢献している。

成功と失敗の分岐点

一方で、AI導入には課題も存在する。2024年の実績から、導入効果に大きな差が生じていることも明らかになってきた。成功企業と失敗企業の分岐点として、経営層のコミットメント、段階的な展開計画、現場との密な連携が挙げられている。さらにAIの過剰な期待の時代から、AIの成果が問われる時代へと移行しており、企業は投資から明確で測定可能な価値を生み出す準備が求められている。加えて、AIガバナンスと偽情報対策の重要性も増しており、AIの責任ある活用と安全な運用が求められている。セキュリティリスクへの対応も含め、戦略的なAI導入計画の策定が不可欠となっている。

段階的導入の重要性

AI活用を成功させるためには、いきなり大規模導入を目指すのではなく、自社の課題を正確に把握した上で小規模な実証実験から始めることが推奨される。成功企業に共通するのは、経営層の強いコミットメント、段階的な展開計画、そして現場との密な連携である。特に重要なのは、AIを単なるツールとしてではなく、業務プロセス全体を見直す契機として捉えることである。現場の声を反映しながら、継続的な改善サイクルを回すことで、投資対効果を最大化できる。外部の専門家による伴走支援を受けながら、自社に最適なAI活用戦略を構築していくことが成功への近道となるであろう。

まとめ

2025年のAI活用は、AIエージェントやマルチモーダル技術の進化により大きな転換期を迎えている。しかし、成果を出すためには段階的な導入計画と現場との連携が不可欠である。ROIの実証やガバナンス体制の構築も含め、戦略的なアプローチでAI活用を推進していくことが求められている。

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。