2026年8月18日、名古屋市立大学経済学部の講義「情報システム論」にて、実務家による特別講義として「AIがシステム開発会社に与えた影響について」をテーマに講演しました。本記事では、当日のスライドとスライドごとのトークスクリプトをあわせて公開します。

講演の進行説明、参加者への挙手、授業運営に固有の内容は公開版では省略しています。トークスクリプトは、当日の話し言葉を読みやすく整えたものです。質疑応答は、質問者や個人を特定できる情報を削り、論点ごとに要約しています。

この講演で伝えたかったこと

  • AIは、質問に答える道具から、調査・判断・操作までを含む仕事の実行主体へ変わりつつある。
  • 置き換わりやすさは職業名ではなく、PC内で完結するか、手順化されているか、データを扱うか、反復的かで考えられる。
  • 人に残る価値は、何をするかを決めること、現場や相手を理解すること、周囲を動かすこと、最後の責任を持つことに移っていく。
  • AIビジネスの中心はAIモデルを作ることではなく、AIを使って仕事のやり方と人の役割を作り直すことにある。

スライドとトークスクリプト

講演タイトル「AIがシステム開発会社に与えた影響について」

Slide 01

こんにちは。株式会社DEPARTUREの高木です。今日はお招きいただき、ありがとうございます。

AIがビジネスを、どう変えているか

AIがビジネスをどう変えているかという講演の問題提起

Slide 07

なくなる、とも言い切れない。起業できる、とも言い切れない。
そのあいだで、いま実際に何が起きているか。

AIがビジネスを、どう変えているか。
それを、実際に会社を経営している立場から話します。

先に、私自身のことを少しだけ話します。

講演者のプロフィールと、システム開発会社を始めた経緯

Slide 08

私は、この大学の卒業生です。経済学部を出ています。皆さんの先輩にあたります。

卒業して、ARアプリを作っているベンチャー企業に就職しました。立ち上げから、終わりまでいました。最後は、給料が支払われなくなって、辞めました。

そのときに身につけたノウハウを使って、2016年に自分でDEPARTUREを作りました。

ノマドワーカーに憧れていたというキャリア選択

Slide 09

なぜ普通の就職をしなかったのか。当時、ノマドワーカーに憧れていたからです。パソコン一台あればどこでも働ける、みたいな。それで、普通の会社に就職する、という道を目指さなくなりました。

なので、キャリアの正解を教えに来たわけではありません。うまくいかなかった話も含めて、現場で今何が起きているかを話します。

株式会社DEPARTUREの事業紹介

Slide 10

株式会社DEPARTUREという会社をやっています。2016年創業で、いま11期目です。

  • システム開発・コンサルの会社を経営しています
  • エンジニア中心の、20名弱の小さな会社です
  • 受託開発、データ活用、Web、業務システムなどをやってきました
  • 生成AI以前から、ITビジネスをやっています
  • 今シーズンより、東京ユナイテッドバスケットボールクラブのオフィシャルパートナーになる予定です
AIによってシステム開発会社そのものを変えるという問題提起

Slide 11

そして今、AIによって、自分たちの会社そのものも変えなければならなくなっている。

今日は、その現場の話です。

まず、いま何が起きているかを、できるだけシンプルに共有します。

以前は、こうでした。

AIは「質問」から「仕事を任せる」へ

人間がソフトウェアを操作して仕事をする従来の流れ

Slide 12

人間

ソフトウェアを操作する

仕事をする

Excelを開く。ブラウザで調べる。メールを書く。コードを書く。全部、人間がソフトウェアを操作していました。

これから、こうなり始めています。

人間がAIに指示し、AIがソフトウェアを操作して仕事をする流れ

Slide 13

人間

AIに指示する

AIがソフトウェアを操作する

仕事をする

人間は、画面の前で手を動かす人ではなくなる。
AIに「これをやって」と指示する人になる。

もう一段いうと、

AIに質問することからAIに仕事を任せることへの変化

Slide 14

「AIに質問する」から、「AIに仕事を任せる」へ

変わっています。

ここは名前だけ、景色として共有します。全部使え、という話ではありません。

ChatGPT、コーディングAI、AIエージェント、MCP、AIによるブラウザ操作の一覧

Slide 15

  • ChatGPT

聞く、書く、まとめる。皆さんがいちばん使っているやつです。

  • Claude や Codex のような、コーディングAI

プログラムを書く、テストする、直す。エンジニアの仕事のかなりの部分を、すでに一緒にやっています。

  • AIエージェント

質問に答えるだけでなく、調べる、判断する、次の作業に進む。一連の仕事を回し始めるものです。

  • MCP

AIが、社内のツールやデータに接続するための仕組みです。名前は覚えなくていいです。意味だけ覚えてください。AIが、仕事の現場に入り始めた。

  • AIによるブラウザ操作

人がサイトを開いてクリックしていた作業を、AIが代わりにやる。情報収集、申し込み、テスト、そういうことです。

要するに、AIはもう「賢い検索窓」ではない。

AIがパソコンの中で働くもう一人になるという説明

Slide 16

パソコンの中で働く、もう一人になり始めています。

労力とお金を交換する仕事は、人からAIに置き換わります。

仕事は、一連の流れとして実行できる

労力とお金の交換が崩れるという説明

Slide 17

これまで多くの仕事は、

人が1時間働く → その対価としてお金をもらう

という構造でした。

でもAIエージェントは、

調べる → 判断する → PCを操作する → 結果を報告する

ところまでできるようになってきています。

なので、「パソコンの前で人間が頑張っていた仕事」のかなりの部分が、AIに移っていきます。

IT業界では、これを「人月」と呼んできました。人を増やせば売上が伸びる。手を動かせば価値になる。

それが、成り立たなくなってきています。

一人がAIを使うことで、少ない時間で大きな価値を生む比較

Slide 18

10人で100時間かけて作ったものより、1人がAIを使って10時間で作ったものの方が価値が高い、ということが実際に起きています。

人が行ってきた作業とAIエージェントが行う仕事の比較表

Slide 19

皆さんにも分かりやすい例なら、こんな感じです。

今まで人がやっていたことAIエージェントがやると
就活サイトから企業を100社調べる条件を渡せば100社調査して一覧化
営業先を探して企業情報を調べる見込み客を探して優先順位まで付ける
問い合わせメールを読んで返信する内容を判断して返信案を作り、場合によっては返信まで
会議を聞いて議事録を書く会議を記録し、要点・TODO・担当者を整理
Excelに数字を入力して集計するデータを取得し、集計してレポートを作る
ECサイトの商品を登録する商品情報を読み取り、説明文・カテゴリ・価格情報を登録
SNS投稿を毎日考えるネタ探し→文章→画像→投稿予約まで行う
Webサイトをテストするブラウザを操作して購入や会員登録をテスト
プログラムを書く要件からコードを書き、テストして修正
経費精算を確認する領収書を読み、規定と照合して異常だけ人に渡す

ここで強調したいのは、これです。

AIが仕事を一連の流れとして実行できるという説明

Slide 20

「AIが文章を書ける」という話ではありません。
AIが、“仕事を一連の流れとして実行できる”ようになってきた。

質問に答えるAIと、仕事を回すAIは、別物です。

AIに置き換わりやすい仕事の4条件

Slide 21

置き換わりやすい仕事は具体的な職業名で考えない方がいいです。「営業は残る」「事務は消える」みたいな話は、だいたい外れます。

この4つで考えてもらうと、かなり正確です。

  1. PCの中だけで完結する
  2. 手順がある程度決まっている
  3. インプットとアウトプットがデータになっている
  4. 何度も繰り返す

たとえば、

「メールを読んで、顧客情報を調べて、マニュアルを見て、返信する」

人間からすると、立派な「仕事」です。
AIからすると、

メール対応を読む・調べる・判断する・書く・送るに分解した図

Slide 22

読む → 調べる → 判断する → 書く → 送る

という処理の組み合わせです。

ここが、AIエージェントのインパクトです。仕事という塊が、処理の組み合わせに分解された。

では、少しドキッとする問いを出します。

新卒で任される仕事の例

Slide 23

皆さんが新卒で会社に入ったときに、任される仕事を考えてみてください。

「まずこれ調べといて」
「このデータまとめといて」
「議事録お願い」
「この会社についてリスト作って」
「メールの返信作って」
「この資料のたたき台作って」

実はこれ、

新卒が最初にやる仕事ほどAIエージェントと競合しやすいという説明

Slide 24

新卒が最初にやる仕事ほど、AIエージェントと競合しやすい。

「まずは簡単な仕事から覚えてもらう」という育成の前提が、崩れてきています。
簡単な仕事が、いちばんAIに向いているからです。

ただし、ここで「だから就職できなくなる」で終わらせません。

人間に残る仕事として、判断・理解・責任・人を動かすこと・問いを作ることを示すスライド

Slide 25

では、人間に何が残るのか?

残るのは、こういう仕事です。

  • 何をやるべきかを決める
  • 顧客が本当に困っていることを理解する
  • 責任を取る
  • 人を動かす
  • 新しい問いを作る

つまり、

作業する人からAIに仕事をさせる人へ価値が移ることを示すスライド

Slide 26

作業する人 → AIに仕事をさせる人

へ、価値が移っていく。

会社の業務を、AI前提で作り直す

AIによって会社をどう変えるかという章の導入

Slide 27

ここからは、うちの会社の話です。綺麗な話だけではありません。

業務システムをAI・既存SaaS・少量の開発で実現する考え方

Slide 28

以前なら、

1000万円かけて、業務システムを作る

だったものが、

AI + 既存のSaaS + 少量の開発

で実現できるケースが増えています。

ちょっとしたアプリなら、非エンジニアでも作れるようになりました。
皆さんの中にも、もう自由に作れる人はいるでしょう。

エンジニア一人あたり月100万円で稼働する従来のビジネスモデル

Slide 29

我々はざっくりいうと、エンジニア一人あたり月100万円で稼働します、というビジネスモデルです。

売上が人の時間に紐づいている会社にとって、時間単価が崩れるというのは、事業の前提が崩れる、ということです。

これが分かった3年くらい前は、本当にずっと体調が悪かったです。

会社の業務そのものをAI前提で作り直せるかという問い

Slide 30

「AIを使っているか」ではありません。

会社の業務そのものを、AI前提で作り直せるか

が重要になります。

道具を配っただけでは、何も変わりません。仕事の手順、役割分担、評価、お客様への売り方。そこまで作り直した会社が、残ります。

我々がいま目指しているのは、単純に「AIを使って最高の成果を出す」ことです。
ただし、使う、だけでは足りない、というのが現場の実感です。

AIを部下・同僚・上司として扱うチームづくり

Slide 31

AIを部下に、同僚に、上司に据えて、組織的に仕事ができる人は、まだ少ないです。
マネジメント層の人材は、もともと希少です。それが、さらに希少になる。

デスクの上で仕事を完結させたいなら、次に求められるのはこれです。

  • AIを、ある意味「人」だと思って部下をマネジメントする
  • 同僚と一緒に仕事をする
  • 上司に、報告・連絡・相談する

社内では、こういうことが起きています。コードをレビューするAI、設計の叩き台を作るAI、ドキュメントを整理するAI、テストを回すAI。一人なのに、チームで動いているのと同じアウトプットが出せる。作業者ではなく、AIというチームを率いる側に回る、ということです。

つまり、ツールの操作だけの話ではありません。AIを社員だと思ってチームを作る、組織を作る、ということです。

そしてこれは、皆さんが今まさに学んでいる、経営学の延長線上にあります。

新しい分野の話をしているように聞こえるかもしれませんが、やっていることは、人の代わりにAIが入っただけの組織論です。皆さんが勉強していることは、そのまま効きます。

ただし、これが「だからホワイトカラーを目指せ」という話か、というと、私はそうは思っていません。この話は、最後に戻します。

受託開発から事業側へ染み出し、リスクを共有するビジネスモデル

Slide 32

もう一つ、会社としての決断があります。

従来の受託開発は、作って納品したら、その後の事業の操業リスクはお客様が100%持っていました。作った側は、納品した時点で仕事が終わる。

そうではなく、我々もAIを使って価値を提供し、リスクの割合に応じて収入をもらうビジネスモデルにシフトしようとしています。

事業側に、もっと染み出していく。
作業を受注するんじゃなくて、価値を提供しに行く。

今期の取り組みとして、東京ユナイテッドバスケットボールクラブのオフィシャルパートナーになる予定です。ファンビジネス。来場しているお客様への直接露出。事業のお困りごとを相談いただける会社という認知をしていただく。

現場に出て、接点を作る。一緒にリスクを共有していけるパートナーを探して、事業を大きくする。こういったストーリーを描いています。

AIビジネスは、仕事のやり方を作り直すこと

AIモデルがすごければビジネスになるのかという問い

Slide 33

ここで、少し逆張りします。

学生は、

AIモデルがすごければ、ビジネスになる

と思いがちです。実際には、そうではない。

例えば、AI × 議事録
これだけなら、今や誰でも作れます。ChatGPTに「議事録にして」と言えば、それっぽいものは出る。

重要なのは、

誰のどんな面倒な仕事をどこまでAIに任せるかという問い

Slide 34

誰の、どんな面倒な仕事を、どこまでAIに任せるのか

です。

会議の録音を文字に起こすだけなら、差別化にならない。
「この会社の、この会議体で、この人のTODOまで落として、翌週のアジェンダまで作る」までやると、初めて仕事になる。

そして、セットで考えないといけない問いが、もう一つあります。

そして人間にしかできない価値ある仕事を、何と定義するのか。

AIに任せる範囲を決めるということは、裏返せば、人間が何をやるかを決めるということです。ここを決めずに「AIを導入しました」だけやると、空いた時間に別の作業が入ってくるだけで終わります。楽になりません。

つまり、

AIビジネスはAIを作ることではなく仕事のやり方を作り直すことという結論

Slide 35

AIビジネス ≠ AIを作ること
AIビジネス = AIを使って「仕事のやり方」を作り直すこと

そして、

人間にしかできない価値ある仕事に、集中できる環境にするのか。

そこまで設計して、初めて商売になります。

モデルを作る会社は、ごく一部です。
ほとんどの会社は、モデルを使って、現場の仕事を組み替える側です。うちも、そっち側です。

「AIで起業できる」と挙げてくれた人へ。
起業できるかどうかは、モデルの性能じゃなくて、誰の面倒を、どこまで引き受けるかで決まります。

最後に、自分ごと化してください。

現場を知っている人が、AIを使う

AIが使えるだけでは差別化にならないという説明

Slide 36

「AIが使える」だけでは、差別化になりません。

Excelが使える、Google検索ができる、と同じになります。使えて当たり前。使えないと困る。でも、それ自体は強みにならない。今の大学生が社会人になるころには、間違いなくそうなります。

もう一つ、見落としがちなことがあります。

自分が使うように、お客様も、面接官も、AIを使っています。

AIで書いた志望動機を、AIが読む。AIで作った提案書を、AIが要約して読む。そういうことが普通に起きます。

その上で、どうコミュニケーションを取るのか。どこを自分の言葉で言うのか。そこが差になります。

それよりも、価値が上がるのはこれです。

問題発見・業務理解・AIへの分解・判断・巻き込み・責任という価値

Slide 37

  • 問題を見つける
  • 相手の仕事を理解する
  • AIに仕事を分解して渡す
  • 出てきた結果を判断する
  • 人を巻き込む
  • 最後の責任を持つ

新卒の仕事がAIと競合する、という話をしました。
だからこそ、最初から「作業する人」で入るんじゃなくて、AIに仕事をさせる人として入る。あるいは、そういう会社を選ぶ。そういう働き方を自分で作る。

ここで、さっき保留にした話に戻します。

ホワイトカラーを目指すことから現場でAIを使うことへの視点転換

Slide 38

経済学部だと、なんとなく「ホワイトカラーになる」が正解に見えやすい。
オフィスに座って、資料を作って、会議をして、判断する。それが上流で、現場は下流。そう教わりがちです。

私は、これからの勝ち筋は、たぶん逆だと思っています。

ホワイトカラーを目指すんじゃなくて、AIが使える現場の人間の方が、価値が高くなる。こっちの方が、ラクに高給を取れる可能性もあります。

理由は単純で、AIがいちばん強いのは、PCの中の反復作業だからです。
資料をまとめる、メールを返す、数字を集計する。いわゆる「オフィスで賢く見える仕事」ほど、先に持っていかれる。

残るのは、現場を知っている人です。
お客様の顔が見える。何が面倒か、自分の手で分かっている。その上でAIに仕事を放れる。

現場に入り込むFDE(Forward Deployed Engineer)の説明

Slide 39

これ、私の願望を言っているわけではありません。すでに証明されている話があります。

さっき、会社の話で「事業側に染み出していく」と言いました。同じことが、エンジニアという職種そのものにも起きています。

Palantirという、アメリカの会社があります。ここがFDEForward Deployed Engineerという職種を作りました。直訳すると「前線に配置されたエンジニア」です。

普通の受託開発のエンジニアは、要件をもらって、自分の会社の席で作ります。FDEは違います。お客様の現場に入り込んで、そこで一緒に課題を見つけて、その場で作る。

面白いのは、これが最近の話ではないことです。作られたのは2010年代の前半。生成AIが出てくる10年以上前です。しかもこの会社、一時期は普通のソフトウェアエンジニアより、FDEの方が人数が多かった。

そして今になって、AI業界がこのやり方を真似しようとしています。 OpenAIは2025年から、この職種の採用を始めました。ほかにもSalesforceやGoogleなど、100社以上が同じ動きをしています。

なぜかというと、AIがどれだけ強力な道具でも、それを「どの現場の、どの面倒に当てるか」は、現場に行かないと分からないからです。さっきの話と、まったく同じ構造です。

つまり、現場に入る人間の価値が上がる、というのは、エンジニアの世界では十数年前に先に起きていて、AIによって、それが他の職種にも広がってきている、ということです。

現場を知る人がAIを使うことの価値

Slide 40

現場を知らない人がAIに指示しても、的外れな仕事が速く回るだけです。
現場を知っている人がAIを使うと、今まで一人では届かなかった量と質が出る。

なので、就活の地図を少し書き換えてほしいです。
「現場を経由せず、最初から企画・管理側に行きたい」より、現場に足をつけて、そこでAIを使い倒す方が、これからは強い。

AIでできることが増えるほど求められる水準も上がるという率直な話

Slide 41

で、最後に、綺麗じゃない話をします。

私自身、求められるレベルが、どんどん高まっているのを感じています。
AIが出る前より、考える量も、判断の量も、責任の範囲も、明らかに増えた。楽になった、という感覚は、少なくとも経営側にはないです。

正直に言うと、辞めたい、と思うことがあります。

楽になるためにAIを入れたつもりが、できるようになった分だけ、求められる天井が上がっていく。
ホワイトカラーの上の方に行けば行くほど、その圧力は強いです。

だからこそ、皆さんには「いい会社に入って、デスクで上流をやる」だけを正解にしないでほしい。
泥くさい現場で、AIを使って、自分で価値を出せる人の方が、これから面白くて、たぶん稼げる。

ただし、じゃあ「現場に行け」「何かを作れ」と言って終わるつもりもありません。

自分は何をするのが好きかという問い

Slide 42

「AIに仕事を奪われないために、何を勉強するか」でもないし、
「自分なら何を作るか」でも、まだ足りない。

本当に考えないといけないのは、

自分は、何をするのが好きか。
何をやって、社会と関わっていきたいか。

スキルの話でも、職種の話でもないです。好きなことと、社会との接点を、自分の言葉で持てるかどうか。

これだけは、誰かに教えてもらうことができません。親にも、大学にも、就活の先輩にも、AIにも、聞けない。

自分のことは自分で知るしかないという結論

Slide 43

自分のことは、自分で知るしかない。

AIが仕事を肩代わりしてくれるほど、この問いから逃げられなくなります。
作業は代わりにやってくれる。でも、何をしたいかは、代わりに決めてくれない。

講演の締めくくり

Slide 44

以上です。ご清聴ありがとうございました。質問は、チャットへどうぞ。講演に関係ないことでも構いません。

質疑応答(抜粋)

01AIに仕事を任せたとき、使い手はどのような責任を負うのか?

最終的な成果物の責任は人が負います。AIを使うかどうかに関わらず、法令・倫理・契約・安全に関わる確認は必要です。生成物の中身、セキュリティ、事業上のリスクを確認し、ブラックボックスのまま運用しないことが重要です。

02コーディングが一般化したとき、エンジニアの価値はどこにあるのか?

コードを書く作業だけの差別化は難しくなります。一方で、業務を理解して要件や設計を整理すること、セキュリティや事業リスクを判断すること、生成されたものを保守し説明できる状態にすることには、引き続き価値があります。AIに任せるほど、人が担う判断と責任を明確にする必要があります。

03AIがコードを書く時代に、プログラミングを学ぶ意味はあるのか?

何をしているか分からないものは、適切に扱えず、責任も持てません。AIにコードを書かせる場合でも、概要を説明させ、実際のコードを読み、テストや修正の妥当性を確認できる基礎が必要です。AIを個別指導の相手として使いながら、自分で読める・判断できる状態を目指すのが現実的です。

04就職活動で、人間性や個性を伝えるために意識することは?

AIを壁打ち相手にして、自分の考えを何度も言い換えたり、反論させたりする使い方は有効です。ただし、AIが一度に作った自己紹介や資料をそのまま読むだけでは、自分の言葉になりません。細かく聞かれても自分の経験として答えられるところまで、内容を理解し、磨き込むことが大切です。

05AIを使うための柔軟な思考は、どう身につければよいか?

AIの出力をそのまま受け取らず、理由を問い返し、反対意見や別の見方を出させます。複数のAIに同じ問いを投げて比較する方法もあります。AI以外では、人が書いた本や歴史に触れ、変化するものと変わらないものを考える時間を持つ。直線的に一つの答えへ進まないことが、思考の引き出しを増やします。

06現場に入るエンジニアの役割を広げるとき、どのような課題があるか?

技術だけでなく、現場との関係づくりが課題になります。外から来た人が一方的に正しさを押しつけると、現場との摩擦が起きます。また、手順に沿って作業する力から、課題を見つけ、考え、責任を持つ力への転換にも時間がかかります。人間関係と学び直しの両方を、継続的に扱う必要があります。

07AIを積極的に取り入れた方がよい仕事や分野は?

PCの中で完結し、手順があり、データを扱い、繰り返しが多い仕事から検討しやすいです。人手不足が深刻な行政やバックオフィスなどでは、AIで作業を補助しないとサービスを維持しにくくなる可能性があります。ただし、機密情報や誤判断の影響を確認し、人が最終判断する範囲を先に設計することが前提です。

08これから求められる人材には、どのような特徴があるか?

現場を観察して課題を見つけ、相手と会話し、その課題にAIをどう使えるかを提案できる人です。AIの得意・不得意、利用コスト、精度や安全面の限界を把握していないと、実行可能な提案になりません。技術知識だけでなく、信頼関係をつくる力も重要になります。

09少人数のスタートアップに入る場合、何を大切にすればよいか?

職種の境界が曖昧になりやすいため、開発だけでなく営業・業務改善・顧客との対話にも関わる姿勢が役立ちます。AIを使って議事録や資料のたたき台を作るなど、周囲の仕事を効率化する提案を自分から試すことです。教育体制が整っていない環境ほど、分からないことを整理して質問し、試して検証する習慣が大切です。

10特定のAIサービスに依存し、料金や仕様が変わるリスクにはどう備えるか?

最先端モデルを使う以上、料金・性能・提供条件が変わる可能性は前提にします。そのうえで、複数の選択肢を比較できる構成にし、用途によってはオープンモデルや自社管理に近い環境を検討します。単一サービスへの依存度と切り替えコストを把握し、事業計画にリスクとして織り込むことが重要です。