AI時代のシステム内製化──必要なのは開発力ではなく、業務を再設計する力である
生成AIの登場によって、システム開発のあり方は大きく変わり始めています。
これまで専門的な知識がなければ難しかったコード作成、画面案の作成、仕様書の整理、テストケースの洗い出し、SQLの作成、マニュアル作成なども、AIの支援によって以前より身近なものになりました。
ノーコード、ローコード、生成AI、AIエージェント。
こうした技術の進化によって、企業の中でも「自分たちでシステムを作れるのではないか」という期待が高まっています。
では、AI時代のシステム内製化とは、社内で開発できる人材を増やすことでしょうか。
エンジニアを採用し、AIを使い、社内でアプリケーションを作れるようになることが、本当の内製化なのでしょうか。
答えは、必ずしもそうではありません。
AIによって「作ること」のハードルは確かに下がります。しかし、だからこそ企業に問われるのは、開発力そのものではなくなります。
本当に必要なのは、自社の業務を理解し、課題を見極め、業務プロセスを再設計し、システムやAIをどこに組み込むべきかを判断する力です。
ただし、こうした話は「言うは易く行うは難し」の典型でもあります。業務を再設計する、業務を捨てる、例外をなくす――これらはどのDX論でも15年以上前から語られてきた正論です。本当に難しいのは、正論を知ることではなく、正論を阻む現実と向き合うことです。この記事では、その現実的な壁にもできるだけ踏み込んでいきます。
AI時代のシステム内製化とは、開発会社になることではありません。業務変革の主導権を、自社に取り戻すことです。ただし、それは掛け声だけで実現するものではありません。
AIによって「作ること」のハードルは下がっている
これまでシステム開発は、専門性の高い領域でした。
業務要件を整理し、画面を設計し、データベースを作り、プログラムを書き、テストし、運用する。その多くは、開発会社や専門エンジニアに依頼するのが一般的でした。
しかし、生成AIの登場によって、その状況は変わり始めています。たとえば、次のような作業は、AIの支援によって以前よりも短時間で進められるようになっています。
- 業務メモから要件定義のたたき台を作る
- 画面項目の案を整理する
- 業務フローを文章化する
- SQLや簡易なプログラムを生成する
- テスト観点を洗い出す
- FAQやマニュアルを作成する
- 問い合わせ対応の文案を作る
- データ集計や分析の補助を行う
もちろん、AIだけで本格的な業務システムを安全に構築できるわけではありません。セキュリティ、権限管理、データ設計、運用設計、既存システムとの連携など、専門的な判断が必要な領域は多く残ります。
それでも、これまで「専門家にしかできない」と思われていた作業の一部が、AIによって補助されるようになったことは間違いありません。その意味で、企業がシステム開発に関与できる範囲は広がっています。
ただし、ここで重要なことがあります。
AIは「作ること」を支援してくれます。しかし、「何を作るべきか」までは決めてくれません。
AIは「何を作るべきか」までは決めてくれない
AIは、与えられた問いに対して答えを返すことは得意です。
- 仕様書を整理してください
- この業務を効率化する案を出してください
- この画面に必要な項目を考えてください
- この処理を自動化するコードを書いてください
こうした依頼に対して、AIは一定の答えを返してくれます。しかし、その前提となる問いそのものを立てるのは、企業側です。
- そもそも、この業務は残すべきなのか
- この承認フローは本当に必要なのか
- この例外対応はシステム化すべきなのか
- この帳票は今後も必要なのか
- この業務は人が判断すべきなのか、AIに任せてもよいのか
- このシステム投資は経営上、本当に優先すべきなのか
こうした判断は、AIが自動的に決めてくれるものではありません。AIは便利な回答を返してくれますが、企業の業務背景、組織事情、顧客対応方針、リスク許容度、経営判断までを完全に理解しているわけではありません。
だからこそ、AI時代には「作れること」以上に、「何を作るべきかを判断できること」が重要になります。簡単に作れる時代になるほど、間違ったものも簡単に作れてしまいます。
- 古い業務をそのままAI化すれば、古い業務が少し便利になるだけです
- 非効率な承認フローをそのまま電子化すれば、非効率な承認がデジタル上で続くだけです
- 不要な帳票をAIで自動作成すれば、不要な帳票がより速く作られるだけです
AIによって作業は速くなります。しかし、向かう方向を間違えれば、間違った業務が高速化されるだけです。
AIが出す「それっぽい答え」を信用してはいけない
ここまで「作ることのハードルは下がった」と述べましたが、この言葉には補足が必要です。生成AIが出すコードや仕様書は、見た目が整っているほど危険です。
AIが生成するコード、SQL、仕様書には、一定の確率で「ハルシネーション」と呼ばれる事実と異なる出力や、構造的な欠陥が含まれます。存在しない関数を呼び出す、権限チェックが抜けている、想定外の入力でエラーになる、テーブル設計が将来の拡張に耐えられない。こうした問題は、一見すると自然な文章やコードの中に紛れ込んでいるため、専門知識のない人が見ても気づけません。
- セキュリティホールが埋め込まれていないか
- 権限管理やアクセス制御が適切に設計されているか
- データの整合性が保たれる設計になっているか
- 将来の変更や拡張に耐えられる構造になっているか
- テストが十分に行われているか
これらを見抜き、判断するには、結局のところ高度なエンジニアリングの知識が必要です。「開発力は不要になる」という言い方は、正確ではありません。開発力の使われ方が変わるのです。
これまでのようにゼロからすべてを書く力よりも、AIが出したものを検証し、危険な箇所を見抜き、責任を持って手直しできる力が重要になります。この検証ができなければ、社内に「AIが作った、誰も保守できないシステム」が量産される結果になりかねません。担当者が退職した瞬間に誰も直せなくなる、いわゆるスパゲティシステムのAI版です。
したがって、内製化を目指す企業であっても、AIの出力を検証できる技術的な目を、社内かパートナーのどちらかに必ず確保しておく必要があります。業務設計力だけでは、この壁は乗り越えられません。
これまでの内製化は「開発力」を持つことだと誤解されてきた
システム内製化という言葉を聞くと、多くの企業は「社内で開発できる体制を持つこと」を想像します。
- 社内エンジニアを採用する
- 情報システム部門を強化する
- 開発チームを作る
- ベンダ依存を減らす
- アジャイル開発を導入する
- ノーコードツールを使って現場でアプリを作る
もちろん、これらは有効な取り組みです。すべてを外部に任せきりにする状態から脱却するためには、社内に一定の技術理解や開発リテラシーを持つことは重要です。
しかし、これだけで内製化が成功するわけではありません。社内でシステムを作れるようになっても、業務を変える判断ができなければ、内製化の効果は限定的です。
- 現場から上がってきた要望を、そのままシステム化する
- 既存のExcelを、そのままWeb画面に置き換える
- 紙の申請書を、そのまま電子申請にする
- 複雑な承認ルートを、そのままワークフローに載せる
- 例外処理を減らさず、そのまま機能追加で対応する
このような進め方では、開発を社内で行っていたとしても、業務の本質は変わりません。むしろ、社内で作れるようになったことで、現場要望への対応が増え、機能が肥大化し、運用が複雑になることもあります。
内製化の目的は、社内に小さな開発会社を作ることではありません。自社の業務を自分たちで理解し、判断し、変えていける状態を作ることです。
AI時代に必要なのは「業務を再設計する力」である
AI時代のシステム内製化で最も重要になるのは、開発力ではなく、業務を再設計する力です。
業務再設計とは、単なる業務改善ではありません。
- 既存業務の一部を便利にすることでもありません
- 今ある作業をそのまま自動化することでもありません
- 現場要望をそのままシステム機能に置き換えることでもありません
業務再設計とは、業務の目的、流れ、判断基準、役割分担、データの持ち方を見直し、会社として最適な形に組み直すことです。たとえば、次のような問いを立てることです。
- この業務は、そもそも何のために存在しているのか
- この作業は、本当に人が行う必要があるのか
- この承認は、何を確認するために行っているのか
- この帳票は、誰が何の判断に使っているのか
- この例外対応は、業務ルールを見直せば減らせないのか
- この情報は、どの時点で、誰が、どの粒度で入力すべきなのか
- AIに任せるべき業務と、人が判断すべき業務はどこで分けるべきか
こうした問いを立てずにAIを導入しても、効果は限定的です。AIは、整理された業務を加速させることはできますが、整理されていない業務を、勝手に整えてくれるわけではありません。
- 業務が曖昧なままなら、AI活用も曖昧になります
- 判断基準が人によって違えば、AIに与える指示もぶれます
- データが整っていなければ、AIの出力品質も安定しません
- 例外処理が多すぎれば、自動化の範囲も限定されます
つまり、AI活用の前に必要なのは、AIツールの選定ではありません。まず必要なのは、自社の業務を棚卸しし、どこを変えるべきかを設計することです。
AI導入で見えてくるのは、技術課題ではなく組織課題である
AI導入というと、技術の話に見えます。
- どのAIツールを使うのか
- どの生成AIモデルを選ぶのか
- どのクラウド環境に構築するのか
- セキュリティをどう担保するのか
- 社内データとどう連携するのか
もちろん、これらは重要です。しかし、実際にAI活用を進めようとすると、より大きな課題が見えてきます。それは、組織として業務を決める力の不足です。
- 誰が業務ルールを決めるのか
- 誰が例外処理を減らすのか
- 誰が現場部門と情報システム部門の間をつなぐのか
- 誰がAIの出力結果に責任を持つのか
- 誰が業務変更を承認するのか
- 誰がベンダや外部パートナーに正しく指示を出すのか
AI導入でつまずく企業の多くは、AIそのものが使えないのではありません。AIを組み込む前提となる業務や組織の整理ができていないのです。
たとえば、社内FAQにAIを導入しようとしても、そもそも社内ルールが整理されていなければ、AIに学習させる情報がありません。問い合わせ対応にAIを使おうとしても、回答方針や判断基準が担当者ごとに違っていれば、AIの回答も安定しません。見積作成にAIを使おうとしても、原価の考え方や提案基準が曖昧であれば、AIはそれらしい文章を作るだけで、判断の質は高まりません。
AIは、組織の曖昧さを映し出します。
AI導入を進めるほど、自社の業務がどれだけ整理されているか、判断基準がどれだけ明確か、責任範囲がどれだけ定義されているかが問われます。AI時代に必要なのは、AIを使うスキルだけではなく、AIを業務に組み込むための判断能力です。
「正論」が現場で機能しない理由――業務再設計を阻む組織の利害
ここまで「業務を再設計すべき」「例外をなくすべき」と述べてきましたが、これ自体は決して新しい主張ではありません。同じ趣旨の正論は、DXという言葉が生まれる以前から、何度も語られてきました。それでも多くの企業がこれを実行できないのは、やり方を知らないからではありません。
実行を止めているのは、社内のドロドロとした利害関係と政治です。たとえば、次のようなことが現場では日常的に起きています。
- 例外対応をなくすと、それを理由に取引していた大口顧客が離れるかもしれない
- 属人化した業務を標準化すると、その業務を長年担ってきたベテラン社員の社内での立場がなくなる
- ある帳票や承認ルートを廃止しようとすると、それを管理してきた部門の存在意義そのものが問われる
- 業務プロセスの見直しを提案した担当者が、既存業務の否定だと受け取られ、社内の反発を招く
つまり、業務再設計とは、技術の問題であると同時に、誰かの立場や既得権益に手を突っ込む行為でもあります。この記事で述べてきた「業務を捨てる力」「例外をなくす力」は、正しいがゆえに、社内の誰かにとっては都合の悪い正論になります。
この衝突を魔法のように解消する方法はありません。しかし、衝突を前提に進め方を組み立てることはできます。
- 経営層が「なぜこの再設計が必要か」を自ら語り、担当者個人の責任にしない
- 影響を受ける当事者を、決定してから伝えるのではなく、設計の初期段階から巻き込む
- 一気に全社を変えようとせず、小さな範囲で成功事例を作り、反対の声を実績で覆す
- 失敗した場合の責任の所在を、着手前に経営層と現場の間で合意しておく
業務再設計とは、正しい設計図を描くことよりも、その設計図をめぐる社内政治とどう向き合うかの方が、はるかに難しく、はるかに価値のある仕事です。ここに踏み込まないまま「業務を再設計すべきだ」と語ることは、上から目線の理想論に過ぎません。
AIに指示できる会社は、業務を言語化できる会社である
生成AIを活用するうえで、よく「プロンプト」が重要だと言われます。確かに、AIに対してどのような指示を出すかは重要です。しかし、良いプロンプトを書く以前に、もっと大事なことがあります。
それは、自社の業務を言語化できているかどうかです。
AIに指示を出すには、業務の目的、条件、判断基準、前提情報、例外条件、期待する出力を伝える必要があります。たとえば、次のような情報です。
- この業務の目的は何か
- どの情報を入力として使うのか
- どのような出力が必要なのか
- どの条件なら承認し、どの条件なら差し戻すのか
- どこまでをAIに任せ、どこから人が確認するのか
- どのようなリスクを避けるべきなのか
- どのような表現や判断は避けるべきなのか
これらを言語化できなければ、AIに正しく指示することはできません。そして、これはAIに限った話ではありません。
- AIに指示できない会社は、ベンダにも正しく指示できません
- AIに業務を説明できない会社は、要件定義でもつまずきます
- AIに判断基準を伝えられない会社は、システム開発でも判断を外部に委ねることになります
AI時代になって、要件定義や業務設計が不要になるわけではありません。むしろ重要性は高まります。なぜなら、AIもシステムもベンダも、自社の業務を完全には理解していないからです。
自社の業務を最も深く理解し、どう変えるべきかを決めるのは、あくまで自社でなければなりません。
AI時代の内製化とは「ベンダを使わない」ことではない
ここで誤解してはいけないのは、内製化とは外部ベンダを使わないことではない、という点です。
AI時代になっても、すべてを自社だけで行う必要はありません。むしろ、技術の進化が速いからこそ、外部パートナーの力を活用することは重要です。AI基盤の構築、クラウド環境の設計、セキュリティ対策、既存システムとの連携、データ基盤整備、運用設計など、専門的な知見が必要な領域は多くあります。これらを無理に自社だけで抱え込む必要はありません。
重要なのは、外部に任せることではなく、外部に丸投げしないことです。自社が持つべきなのは、次のような力です。
- 業務課題を定義する力
- 優先順位を判断する力
- 業務変更を決める力
- AI活用の方針を決める力
- データ活用の方向性を決める力
- 投資判断を行う力
- ベンダに対して、何を依頼するのかを明確に伝える力
一方で、外部に任せてもよいものもあります。
- 開発作業
- インフラ構築
- AI基盤の技術検証
- セキュリティ設計
- 実装支援
- 運用設計の一部
- 専門技術に関する調査や実装
つまり、AI時代の内製化とは、すべてを自社で作ることではありません。外部の力を使いながらも、業務の設計と判断の主導権を自社に残すことです。
なお、これまで多くの企業がシステム開発をベンダに丸投げしてきた背景には、単なる技術力不足だけではなく、失敗した際の責任の所在をベンダ側に置きたいという事情もありました。この点については、後ほど評価制度の話であらためて触れます。
誰がコードを書くかではありません。誰が業務のあり方を決め、その結果に責任を持つかです。
AI時代に企業が持つべき内製化能力
AI時代のシステム内製化において、企業が持つべき能力は大きく六つあります。
1. 業務を可視化する力
業務フロー、データの流れ、判断ポイント、例外処理、承認ルートを見える化すること。これができなければ、どこにAIを使うべきか、どこをシステム化すべきかを判断できません。
2. 業務を捨てる力
AIを使って効率化する前に、本当にその業務が必要かを問う必要があります。不要な承認、重複入力、慣例的な帳票、誰も見ていないレポート、属人的なチェック作業。これらを残したままAI化しても、会社は大きく変わりません。ただし、これを実行するには、後述する組織の利害調整が避けられません。
3. 判断基準を定義する力
AIに任せるにしても、人が判断するにしても、基準が必要です。何をもって承認するのか。何をもって異常とみなすのか。どの条件なら自動処理し、どの条件なら人に回すのか。こうした基準を定義する力が求められます。
4. データを整える力
AI活用は、データ品質に大きく左右されます。データが散在している、マスタが乱れている、入力ルールが統一されていない、同じ意味の項目が複数存在する。このような状態では、AIを導入しても十分な効果は出ません。
5. 外部パートナーを使いこなす力
AI、クラウド、セキュリティ、システム開発には専門性が必要です。すべてを自社で抱えるのではなく、外部の力を適切に活用する。ただし、何を任せ、何を自社で決めるのかは明確にする。
6. AIの出力を検証する力
AIが生成したコード、仕様書、SQL、データ構造には、ハルシネーションや構造的な欠陥が含まれる可能性があります。それを見抜き、セキュリティや保守性を担保できる技術的な目を、社内か信頼できるパートナーとして必ず確保しておく力です。
この六つの力があって初めて、AI時代の内製化は現実的なものになります。
主導権を「取り戻す」には、評価制度とガバナンスの見直しが欠かせない
ここまで述べてきた能力は、すべて「誰かがそれを担う」ことを前提にしています。しかし、その「誰か」を会社がどう評価し、どう守るのかという設計を忘れると、能力論はすべて絵に描いた餅になります。
多くの日本企業の評価制度は、加点よりも減点の要素が大きく働きます。この構造のもとでは、業務を大きく変えてリスクを取るよりも、現状を維持する方が個人にとって合理的な選択になります。業務再設計を提案した担当者が、失敗した場合にすべての責任を負わされるなら、誰も手を挙げません。
また、これまでシステム開発を外部ベンダに丸投げしてきた背景の一つには、失敗したときの責任転嫁先を確保するという、あまり語られない事情もありました。ベンダに任せておけば、うまくいかなかったときに「ベンダの提案が悪かった」と説明できます。これは、内製化を進める際に必ず直面する構造的な問題です。
この構造に手をつけずに「業務変革の主導権を自社に取り戻せ」と呼びかけることは、現場に責任だけを押し付け、デスマーチを強いる結果になりかねません。主導権を取り戻すのであれば、それを担う人材を守り、育てる仕組みも同時に整える必要があります。
- 業務変革を担う人材を、失敗の減点だけで評価しない仕組みを作る
- 業務デザイナーやPMといった役割に、明確なキャリアパスと評価軸を用意する
- 失敗を個人の責任にせず、経営層が結果に対する責任を分担する体制をつくる
- ベンダを「責任の受け皿」として使う構造そのものを、経営として見直す
業務変革の主導権を自社に取り戻すという話は、能力論だけでは完結しません。それを実行する人が安心してリスクを取れるだけの評価制度とガバナンスがあって、初めて現実の取り組みになります。
AI導入の前に、システム構想を描く必要がある
次のような相談は、今後ますます増えていくはずです。
- AIを業務に活用したい
- 生成AIを使って業務効率化を進めたい
- 社内データを活用して、より高度な判断を行いたい
しかし、そこでいきなりAIツールの選定から入るのは危険です。
- どの業務にAIを使うのか
- どの業務は人が判断するのか
- AIの出力を誰が確認するのか
- 既存システムとどう連携するのか
- データはどこに存在しているのか
- セキュリティや権限管理をどう設計するのか
- 外部ベンダに何を依頼するのか
- 社内では何を持つのか
- 段階導入するなら、どこから始めるのか
- 誰がこの変革を推進し、その責任をどう分担するのか
こうした論点を整理しないままAI導入を進めると、便利な機能は増えても、会社全体の業務は変わりません。AIは強力な道具ですが、設計図のないまま導入すれば、便利な機能が点在するだけで、会社全体の仕組みは変わりません。
AI時代だからこそ、システム構想策定が重要になります。
- 業務をどう変えるのか
- どこにAIを組み込むのか
- 既存システムをどう見直すのか
- どこまでを自社で判断し、どこから外部に依頼するのか
この設計図を描くことが、AI時代のシステム内製化の出発点です。
まずは自分たちだけでできる、業務棚卸しワークショップの始め方
ここまで「設計図が必要だ」と述べてきましたが、それは必ずしも外部の力を借りなければ始められないものではありません。業務の棚卸しは、社内だけで、今日から始められます。まずは、自社でできる範囲を一つ具体的に紹介します。
ステップ1. 関係者を集める
対象の業務に関わる現場担当者、その上長、情報システム部門の担当者を、最低でも一人ずつ集めます。現場だけ、管理職だけで進めると、後で必ず「話が違う」という反発が起きます。2時間ほどの時間を確保できれば十分です。
ステップ2. 業務を一つずつ書き出す
ホワイトボードや付箋、オンラインなら共有スプレッドシートやFigJamのようなツールを使い、対象範囲の業務・帳票・承認ステップを、思いつく限りすべて書き出します。この時点では、良し悪しの判断はしません。
ステップ3. 業務ごとに「目的」「頻度」「困りごと」を書き込む
書き出した業務それぞれについて、次の3つを付箋やセルに書き込みます。
- この業務は、そもそも何のためにあるのか
- どのくらいの頻度で発生し、誰が対応しているのか
- 現場が実際に困っている点、時間がかかっている点は何か
ステップ4.「これがなくなったら困る人は誰か」を問う
各業務について、「この業務や帳票がなくなったら、誰が一番困るか」を参加者に問いかけます。ここで名前が挙がる人や部門こそが、その業務を変えるときに調整が必要になる相手です。この段階で利害関係を可視化しておくだけで、後の衝突をかなり減らせます。
ステップ5. 小さく変える対象を一つだけ選ぶ
洗い出した業務の中から、影響範囲が小さく、かつ効果が見えやすいものを一つだけ選び、そこから見直しを始めます。最初から全社的な業務を対象にすると、必ず利害調整で止まります。小さな成功体験を作ることが、次の見直しへの推進力になります。
ここまでは、外部の力を借りなくても、社内の会議室とホワイトボードだけで始められます。
一方で、実際にこのワークショップを進めると、多くの企業が同じ壁にぶつかります。声の大きい人の意見がそのまま結論になってしまう、部門間の力関係で本音が出てこない、自社の常識に慣れすぎていて「そもそも要るのか」という問いが出てこない。これは、社内の人間関係の中にいる以上、避けにくい構造的な限界です。
社内の利害から距離があり、フラットに「これは本当に必要ですか」と問える立場が必要になったとき、外部のファシリテーターを交通整理役として頼るのも一つの手です。そこから先、洗い出した課題をどう優先順位づけし、どこにAIやシステムを組み込むかという設計図に落とし込む段階では、社内だけで完結させるより、第三者の視点を挟んだ方が早く、かつ社内政治に振られずに進むことが少なくありません。
AI時代のシステム内製化は、まず「業務とシステムの設計図」から始まる
AI活用やシステム内製化を進めるうえで重要なのは、いきなりツールを選ぶことでも、開発体制を作ることでもありません。まず必要なのは、自社の業務を整理し、どこを変えるべきか、どこにAIやシステムを組み込むべきかを明確にすることです。前段の棚卸しワークショップは、その第一歩として、まずは自社だけで試してみてください。
そのうえで、社内政治の調整が難しい、あるいは客観的な交通整理役が必要だと感じた場合は、外部の専門家を挟むという選択肢もあります。オーシャン・アンド・パートナーズでは、発注者側の立場に立ち、業務課題の整理、システム構想策定、RFP作成、ベンダ選定、基幹システム再構築までを支援しています。自社の業務とシステムの全体像を整理したい方は、以下のサービスをご覧ください。
システム構想策定支援
業務課題、システム課題、投資判断を整理し、プロジェクトの設計図を描く支援です。
RFP作成・ベンダ選定支援
自社の意図をベンダに正しく伝え、比較可能な提案を受けるためのRFP作成・ベンダ選定を支援します。
基幹システム再構築支援
老朽化した基幹システム、レガシーシステム、ERP刷新に向けた構想策定から再構築までを支援します。
AI時代に必要なのは、単なる開発力ではありません。自社の業務をどう変えるべきかを考え、決め、外部パートナーを使いながら実行していく力です。そして、それを実行する人を守り、評価する仕組みです。
まとめ：AI時代に本当に内製化すべきなのは、開発作業ではない
生成AIによって、システム開発の一部は確実に身近になります。これまで外部に依頼しなければ難しかった作業の一部を、社内で進められる場面も増えていくでしょう。
しかし、それによって企業に求められる能力は、単純な開発力ではなくなります。むしろ重要になるのは、自社の業務を理解し、問い直し、再設計し、AIやシステムをどこに組み込むべきかを判断する力です。
内製化とは、社内にエンジニアを増やすことではありません。開発会社になることでもありません。
AI時代のシステム内製化とは、業務変革の主導権を自社に取り戻すことです。
- 外部ベンダを使っても構いません
- AIを活用しても構いません
- 開発作業を外部に任せても構いません
重要なのは、自社が業務を理解し、判断し、舵を取れる状態にあることです。ただし、それは正論を語るだけで実現するものではありません。
- 業務再設計を阻む社内の利害と政治に、正面から向き合うこと
- AIの出力を過信せず、検証できる技術的な力を確保すること
- その両方を担う人材を、正しく評価し、守る仕組みを整えること
AI時代に本当に内製化すべきなのは、開発作業ではありません。自社の業務をどう変えるべきかを考え、決め、そのために現実の壁と向き合う力です。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
