フルスクラッチは体力

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活用を推進していくことが求められている。

誤解されるコスト削減

実はローコード・ノーコードツールを使えば、開発が必要なくなるので安くなるというのは正しくない。たしかに、ノーコードツールを社内メンバーでCMSを使ってソフトを作るという場面は開発費用はかからない。

CMSとはコンテンツ・マネジメント・システムの略で、たとえばWebサイトのコンテンツを構成するテキストや画像、デザインなどを非エンジニアがプログラミングをせずに作成や管理できる仕組みのことである。ローコードツールはそれに加えて少しのプログラミング知識でシステムやツールを作成できることである。

開発手法の選択基準

断じてローコード開発だからといって安いわけではない。開発手法の特性による得手不得手を上手に使い分けるからトータルとして価格が安くなるということである。非エンジニア営業の金額調整という意味での判断でローコード開発を選択する場合は失敗することがある。

システム導入の本質理解

ローコード開発でも、システム導入の目的や条件が本質的にわかっていなければ、仕様要件のブレによって結果としてトータルが安くなることはない。これはローコード開発ということが問題なのではなく、フルスクラッチ開発であっても、SaaSと利用する場合であっても同じことが言える。

負債の危険

本来ローコード開発が適さない場合にも関わらず無理やりに合わせることで、プログラム部分の複雑性が増し、技術的負債となって大きな問題になっていく。結果として安くはならず、ローコード開発のメリットであるメンテナンス性までも損なうため、トータルで考えると高くなる。

まとめ

お客様の予算内で考えないといけないので、といった口癖があれば注意が必要である。クライアントの言いなり状態であれば、無理な要求は開発における仕様だけではないだろう。金額を含めた総合的な判断ができる人が、結果としてローコード開発を選択するわけである。

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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