ビジネス職が生成AIで業務でコーディングを取り入れるようになって難しいと思ったこと

この記事はウィルゲート Advent Calendar 2025 19日目の記事です。

adventar.org

はじめまして。 ウィルゲートのUchiiといいます。 普段は事業部側で、主にオペレーションの整備やメニュー開発を担当しています。

最近、業務の中で生成AIを使う機会が増え、 その流れで簡単なプログラミングに触れるようになりました。

私はあくまでビジネス職として働いており、エンジニアではないです。それでも生成AIに触れていると、「ビジネス職であっても、以前より作る側に近づける場面が増えた」と感じます。

この記事では、ビジネス職が生成AIを使って実際に開発に踏み込んでみたときに、開発業務をどのように理解し、どう協働できると感じたかについて書いていきます。

エンジニアの方にとっては当たり前の話も多いと思いますが、「ビジネス職が開発を考えるにあたりどこで壁にぶつかるのか」という視点で読んでもらえたら嬉しいです。

一人ひとりが強力な開発アシスタントを持つ時代になった

生成AIの登場で、コードを書く行為そのものは一気に身近になりました。

やりたいことを文章で伝えると、 それなりに動くコードが返ってきます。

ビジネス職である私にとっては、 常に開発アシスタントが隣にいる ような感覚でした。

この変化によって、 これまで「エンジニアの仕事」だと思っていた領域に、 一歩踏み込めるようになったと感じています。


ビジネス職でも「DIY」なら作れるようになった

実際に、次のような 社内向け・自分たちで使う前提のツール を作りました。

  • 複数のスプレッドシートやCSVを読み込み、必要な列だけを加工・統合するデータ整形スクリプト
  • 毎日手作業で行っていた集計処理を自動化する簡易バッチ
  • 条件に応じて定型文を生成し、Slackに投稿する小さな仕組み

これらに共通しているのは、

  • 利用者が社内に限定されている
  • 要件が頻繁に変わる
  • 壊れても自分たちで直せる
  • 最悪、使わなくなっても致命的ではない

という点です。

DIY的な開発 です。


DIYと大規模建築の違い

生成AIを使って開発してみて、 自分の中でしっくりきた比喩があります。

ひとことで「開発」といっても、「DIY」と「大規模建築」がある というものです。

DIYは、

  • 作る人と使う人が同じ
  • 壊れても自分が困るだけ
  • 責任の範囲が限定的

一方で、大規模建築は、

  • 多くの人が利用する
  • 長期間使われる
  • 安全性が最優先される
  • 法規制や基準が存在する
  • 事故が起きれば社会的責任が発生する

DIYが必要な場合もあれば、腰を据えて大規模建築が必要な場合もあります。 これは事業の状況によっても変化しますし、機能ひとつとっても、 まずはDIYで作ってみて、効果があれば大規模建築に発展させるという場合もあると思います。


DIYと大規模建築の「差分」を整理する

DIY的な開発をしてみて感じたのは、 DIYと大規模建築の差分は「大量のコードを書くかどうか」ではない、ということでした。

1. スコープの捉え方

DIYは目の前の目的に寄りがちですが、 大規模建築は影響範囲や将来を含めて考える必要があります。

2. 時間軸

DIYは短期、 大規模建築は数年単位の時間軸を含めることがあります。

3. 「動く」の基準

DIYにとっての「動く」は正常系中心。 大規模建築は失敗耐性や復旧まで含めて考える必要があります。

4. 責任の範囲

DIYは一定責任が閉じていることが多いです。 大規模建築では他人が使うことを前提に設計を行う必要があります。

これらの差分が積み重なった結果が、 DIYと大規模建築の違い なのだと思います。

また実装は生成AIが助けてくれても、DIYにするのか大規模建築にするのか、といった判断は人間の仕事として残ります。


生成AI時代における、事業部を越えた協働のパターン

生成AIによって、協働の形も変わりつつあります。

パターン1:ビジネス職がDIYで試作し、エンジニアが建築する

ビジネス職がDIYでイメージを作り、 エンジニアが設計・安全性を担保して作り直します。

パターン2:ビジネス職が要件と言語化に集中する

目的・制約・優先順位を整理し、 DIYや大規模建築の実装判断はエンジニアに委ねます。

パターン3:ビジネス職が運用改善を回し、エンジニアが基盤を支える

一定の基盤をエンジニアに作ってもらった上で、 DIY的な改善をビジネス職が担います。

パターン4:生成AIを共通の壁打ち相手として使う

AIを介して、ビジネス職とエンジニアが同じ前提で議論します。

どのパターンでも重要なのは、 DIYと建築の境界を曖昧にしないこと です。


おわりに:DIYができるようになった今だからこそ

生成AIによって、 ビジネス職でもDIY的な開発ができるようになりました。

これは間違いなく大きな前進です。

ただし、 DIYと大規模建築は同じではありません。

DIYと大規模建築のどちらが必要なのかを整理し、事業部の壁を超えてすり合わせていく姿勢が必要だと感じています。

ウィルゲート Advent Calendar 2025」、次回は野中さんの「DockerでLaravelの開発環境テンプレを2日で作りました」です!