AI時代、システム部門は何を担い、ITベンダーに何を頼むのか？

これまで、業務部門が困り事を伝え、システム部門が要件を整理し、ベンダーが開発する進め方は珍しくなかった。その場合、利用者が実物を触るまでに時間がかかり、完成してから使い勝手の認識が食い違うこともある。

業務を知る人が自ら試作できれば、話し合いの出発点が変わる。見積書のどの項目を自動で埋めたいのか、どこは担当者が確認したいのか。画面を操作しながら確かめられるからだ。

Microsoftは、業務知識を持つ利用者と専門の開発者、システムの運用を担う担当者が協力する開発の考え方を、Power Platformの公式資料で示している。^[1] 現場で作る人と専門家が分担する発想は、生成AI以前からある。AIによるコード作成支援を取り入れる際にも、参考になる。

ただし、業務部門が作ったものを、そのまま全社に配ればよいわけではない。システム部門への依頼は、「一から作ってほしい」に加えて、「この試作を、会社の業務で使えるようにしてほしい」という形になる。

試作品には、要望書では伝わりにくかった現場の知識が入っている。それを生かしながら、どの部分を引き継ぎ、どこを設計し直すかを判断する仕事が必要になる。

見積作成ツールを全社で使うなら、まず価格の出所を確認しなければならない。個人が保存した表を参照していれば、価格改定の翌日に古い金額で見積もる恐れがある。

文章をAIが作る場合も、商品説明の下書きと、価格・値引きの決定は分けて考えたい。この例では、金額は承認済みの価格情報と計算ルールで求め、AIには説明文の作成を任せる設計が考えられる。何でもAIに判断させる必要はない。

さらに、誰が値引きを認めるのか、誰が顧客へ送信するのかを決める。承認前の見積書を送れないようにするなら、画面上の注意書きだけでなく、システムの動作として制御する必要がある。

GitHubも、Copilotの生成した提案について、利用者によるレビューと検証が必要だと説明している。^[2] コードをAIが書いたことは、業務上の正しさや安全性の保証にはならない。

試作品を本番に移す際には、正常に動くかだけでなく、価格が取得できない場合、同じ処理を二度実行した場合、誤った見積書を作った場合まで確かめる必要がある。ここに時間と費用がかかることを、最初から計画に含めておきたい。

システム部門に残すべきなのは、外注先との連絡窓口だけではない。個々のツールを、会社全体のデータやシステムにつなぐための判断である。

見積作成ツールなら、正式な価格情報はどこにあり、顧客情報をどの権限で参照できるのか。既存の販売管理システムと何を共有し、どの処理は分けておくのか。部署ごとに別の仕組みが増える前に、共通の方針を用意したい。

一方、値引きの条件や営業上の承認基準まで、システム部門だけで決めることはできない。業務のルールと導入効果には営業部門の責任者が関わり、大きな投資や部門間の優先順位には経営の判断が必要になる。

システム部門は、それらの判断を技術的に実現できる形へ整理する。外部の提案を評価し、制約と選択肢を業務部門へ説明し、何を満たせば利用を認めるかを決める役割だ。

そのためには、技術を理解する人材を社内に残す必要がある。すべてのコードを書ける人数をそろえるという意味ではない。データの流れを追い、設計やテストの妥当性を確かめ、障害時に状況を判断できる力が必要になる。

また、すべてを個別審査していては、システム部門が新しい待ち行列を作ってしまう。使ってよい開発環境、接続してよいデータ、相談が必要になる条件を先に示す。Microsoftの導入ガイダンスも、利用者が開発できる環境と、管理・運用・復旧の仕組みを併せて扱っている。^[3]

自社で試作できるようになっても、専門家に頼む価値は残る。むしろ、何を依頼するかを具体的に説明しやすくなる。

見積作成ツールの場合、販売管理システムとの接続、利用者ごとの権限設定、同時利用時の性能確認などは、外部の経験が役立つ領域だ。試作品を調べ、本番で再利用できる部分と作り直す部分を判断してもらうことにも意味がある。

稼働後の支援も重要だ。価格情報の連携が止まった際に、誰が原因を調べ、いつまでに復旧するのか。利用するクラウドやAIモデルの仕様が変わったとき、誰が影響を確認するのか。作った社員の善意だけに頼れない仕事を、サービスとして引き受けてもらう。

経済産業省が2025年に公表したレガシーシステムのモダン化に関する報告でも、ベンダーによるユーザー企業の内製化支援・伴走が必要とされている。^[4] 内製化を支援すること自体が、外部企業の役割になり得る。

ただし、ベンダーには「このAI製ツールをそのまま保証してほしい」と渡せば済むわけではない。現状調査や修正の範囲を定め、どの条件で運用を引き受けるかを合意する必要がある。

企業が買うのは、開発作業だけでなく、社内だけでは確保しにくい専門性と、担当者が変わっても支え続けられる体制である。

ここまでは発注する企業から見た役割分担を考えた。受注するベンダーにとっては、もう一つの問いがある。顧客が自分で作る範囲を広げたとき、何の仕事が減り、どこで売上を立てるのか。

見積作成ツールの例なら、入力画面や帳票を一から作る案件は、以前より小さくなるかもしれない。社内で使い切れる仕組みなら、外注自体がなくなることもある。従来と同じものを依頼されても、顧客が試作を経験していれば、価格や納期の説明をより具体的に求められるだろう。

ただし、試作にかかった時間だけで、本番システムの開発費を判断することはできない。ベンダーには、何を作る工数なのかに加え、何を確かめ、どの状態まで使えるようにする費用なのかを説明する力が必要になる。

小さな開発案件と、複雑なシステムでは変化が違う

定型的な画面や個人用ツールと、既存の販売管理システムに接続する仕組みでは、仕事の中身が異なる。後者では、既存のデータや業務ルールを理解し、他の機能への影響を確かめ、稼働中の業務を止めずに変更する必要がある。コードを書く作業が速くなっても、こうした仕事まで同じ割合で短縮できるとは限らない。

一方で、複雑な開発なら従来の体制や価格を維持できる、と考えるのも早い。調査やテストの一部を効率化できれば、必要な人数や期間は変わり得る。判断すべきなのは、案件の大小だけでなく、どの工程に専門家の時間が必要かである。

※上表は仕事ごとの変化を考えるための見立てであり、市場規模の予測ではない。顧客の内製能力やシステムの重要度によって、変化の速さと範囲は異なる。

新しい仕事が、減った売上を埋めるとは限らない

内製化支援や本番化の仕事が生まれても、それが従来の開発売上を同額で置き換えるとは限らない。顧客自身で運用できる場合もあれば、クラウドや業務ソフトの標準機能で用が足りる場合もある。

保守や運用も、移れば安心という領域ではない。顧客が作ったツールが増えるほど、構成や品質の異なる仕組みを調べる負担が生じる。一律の低い料金で引き受ければ、問い合わせや障害対応が増えたときに採算が崩れる恐れがある。

そのため、運用を引き受ける前の調査、本番利用に必要な改修、稼働後の支援を分けて提案することが考えられる。顧客にとっても、初期の整備費と継続費用が見えれば、内製を続けるか、外部へ任せるかを判断しやすい。

顧客の業務を理解することを、提案に結び付けられるか

見積作成ツールの入力画面だけを請け負うベンダーと、価格情報の管理や承認の流れまで理解するベンダーでは、提案できる範囲が違う。後者なら、担当者が何度も確認している作業や、部門間で重複する入力を見つけ、次の改善を提案できる。

もっとも、顧客の業務に詳しいだけで受注が続くわけではない。その知識を使って、確認の負担を減らす、変更を安全に行う、障害から早く復旧するといった価値を示す必要がある。顧客に知識を渡さず、特定の担当者にしか分からない状態を残すこととは区別したい。

ベンダーにとっての課題は、顧客が自分で作れる部分を見極め、その先の難しい仕事を引き受けることだ。ただし、専門性や引き受ける責任に見合う対価を得られなければ、仕事の難度だけが上がり、売上や利益は減る可能性もある。

AI時代にも仕事は残る。しかし、従来と同じ売り方で採算が合うとは限らない。役割分担の変化は、何を基準に見積もり、何に対して料金を受け取るのかという、ベンダーの事業の仕組みにも及ぶ。

判断の出発点は、「AIで作れるか」よりも、「止まったり間違ったりした場合に、誰がどれだけ困るか」に置きたい。

これは固定的な区分ではない。少人数しか使わなくても、取引条件を決めたり重要な情報を扱ったりするツールには慎重な設計が必要だ。

また、内製には保守を続ける時間も必要になる。作るのが得意な社員が一人いても、その人が日常業務の合間に直し続けるなら、組織として維持できるとは限らない。

見積作成ツールなら、営業部門が入力画面や業務の流れを試し、システム部門が接続先と権限を設計し、ベンダーが連携部分の実装や運用を担う組み合わせが考えられる。すべてを一方へ寄せる必要はない。

ベンダーへの依頼が「この画面を作ってほしい」だけでは、見積もりも画面を作る作業が中心になる。必要な支援を受けるには、使い始めた後の条件まで伝えたい。

例えば、正式な価格情報だけを参照すること、承認前に顧客へ送信できないこと、価格が取得できない場合は処理を止めること。さらに、どの情報を使って見積もったか確認でき、障害時には従来の手順へ戻せることを求める。

納品物も、動く画面だけでは足りない。自社で変更するための設計情報、設定内容、テスト、運用手順を、採用するサービスや契約に応じて受け取る。ソースコードを保有できる場合でも、それだけで別の担当者が保守できるとは限らない。

ベンダーの評価では、初期費用に加え、変更時にかかる手間、障害対応の体制、自社への知識の引き継ぎを見る。利用サービスの料金も含めて、使い続ける費用を比較したい。

そして、何を満たせば完成なのかを、発注前に業務部門とシステム部門でそろえる。画面が動くこと、見積金額が正しいこと、営業担当者の負担が減ることは、それぞれ別の確認事項である。

※見積作成ツールを想定した分担例。専門部署の有無や委託範囲によって調整し、大きな投資判断は経営が担う。

AIで試作しやすくなれば、社内から寄せられる改善案は、文章だけでなく動く形で示せるようになる。その価値を生かすには、試作した人に運用まで背負わせず、適切な段階で専門家へつなぐ必要がある。

システム部門が持つべきなのは、自社の業務と技術を結び付けて判断する力だ。ITベンダーには、その判断を支える知識と、実装・運用を継続して担う力を求める。

見積作成ツールを全社に広げる会議で、最初に決めたいのは発注先だけではない。価格の正しさを誰が確認し、誰が変更を承認し、止まったときに誰が動くのか。そこまで決まって初めて、何を内製し、何を外部に頼むかが具体的になる。