「NetSuiteを入れたのに、現場は全然楽にならない」という声をよく聞きます。カスタマイズしたくても外注は高い、社内に人がいない、AIツールの稟議も通らない。そんな状況を、AIと業務知識だけで突破した経験をお伝えします。
はじめに：NetSuiteはそもそもEUCを意図したシステムである
NetSuiteはもともと、エンドユーザーコンピューティング（EUC）を強く意識して設計されたERPです。ワークフローの自動化、カスタムフィールドの追加、フォームのレイアウト変更といった設定の多くは、プログラミングの知識がなくてもユーザー自身が画面上で操作できます。「基幹システムをユーザー企業が自分たちで育てていける」というコンセプトは、NetSuiteの大きな強みのひとつです。
ただし、より高度なカスタマイズ、特にSuiteScriptと呼ばれるスクリプト機能になると話が変わります。JavaScriptをベースにした独自の開発環境であり、NetSuiteの設計思想や内部構造への理解が前提となります。いくらEUCを謳うシステムであっても、スクリプトの実装はエンドユーザーが直接担うには敷居が高く、結果として専門ベンダーへの依存が生まれてきたのが実情でした。
AIの登場は、この構造を変えつつあります。今回の開発を通じて実感したのは、「コードを書く能力」よりも「何を作るべきかを判断する業務知識」の方が、はるかに重要になっているということです。そしてその業務知識の習得自体にも、AIは大きく貢献してくれました。
プロジェクトの背景
NetSuiteには標準のフォーム機能がありますが、業務要件によってはそれでは足りないことがあります。今回はSuiteletと呼ばれるカスタムWebアプリ機能を使って、完全にスクラッチに近い形でシステムを構築する必要がありました。
規模感はこうです。フォームが40画面、1画面あたりスクリプトが2〜3本、合計すると120本前後のスクリプトを書くことになります。NetSuiteの標準トランザクション（受注・請求など）を使わず、データフローも独自設計が必要な、いわゆる「完全アドオン」の案件でした。
通常想定 vs 実績
なぜ人を増やせなかったのか
単純にリソースを増やせばいい、という話ではありませんでした。この種のNetSuiteカスタマイズには、業務知識・会計知識・NetSuiteの設計思想という3つの軸がすべて必要になります。
実装できるエンジニアは見つかるかもしれません。しかし会計がわからないとデータフローの設計ができません。NetSuiteの挙動を知らないとハマる箇所が事前に読めません。この3つが揃う人材は、社内外を探しても見つかりませんでした。
AIツールについても同様で、会社として実績がない以上、有償版の稟議を通すのは難しい状況でした。そこで自己負担でClaudeを契約することにしました。無償版・Pro版と試していく中で、ChatGPTやGeminiなど他のAIツールとも比較しましたが、コード生成の精度という点ではClaudeが現時点で突出していると感じました。最終的にはMax（×20）プランまで契約を引き上げ、本格的な開発に臨みました。
工数削減だけではない：コミュニケーションロスがゼロになる
AI開発による効果として真っ先に語られるのは工数削減ですが、今回実感した最大のメリットはむしろ別のところにありました。要件を把握している人間が直接実装に関わることで、従来の開発プロセスに構造的に組み込まれていたコミュニケーションロスがほぼゼロになるということです。
従来の開発では、要件定義者と実装者は基本的に別の人間でした。要件を実装者に伝えるために設計書を書き、不明点のQAをやり取りし、それでも認識のズレは生まれます。そもそも実装者は業務を深く理解していないため、仕様書に書かれたことを書かれた通りに実装するのが精一杯です。結果として機能としては動いているが使いづらい、非機能要件（パフォーマンス、エラー処理、例外ケースなど）の実装が薄い、といった問題が生まれます。
要件定義 → 設計書作成 → QAやり取り → 実装 → テストで不備発覚 → 手直し → 再テスト……
要件定義 → AIに指示して実装 → 動作確認 → 完了
これらの問題はテスト段階で表面化し、そのたびに実装の手直しが発生します。手直しのたびに工数が積み上がるだけでなく、稼働増による担当者の疲弊も深刻です。「なぜこちらの意図が伝わらないのか」「なぜ仕様通りに動かないのか」という繰り返しのやり取りは、やがて単なる業務上の行き違いを超え、人間関係のトラブルへと発展することも珍しくありません。
こうした摩擦が積み重なると、優秀な担当者ほど「もうこの環境でやっていけない」と感じて離職を選ぶ場合があります。システム開発の非効率は、スケジュールやコストの問題に留まらず、組織の人材流出という形で静かに、しかし確実にダメージを与え続けます。
AIとの開発の実際――要件定義編
AIの活用はコード生成だけではありませんでした。むしろ要件定義のフェーズでこそ、AIが大きな力を発揮しました。
今回心がけたのは、要件定義の場で「その業務はどういうものですか？」という、いわゆる"What is it?"の質問を禁止することでした。こうした質問は話が際限なく広がり、要件が固まらない原因になりがちです。
代わりに実践したのは、顧客との打ち合わせの前にAIを使って業界・業務の予備知識を徹底的に仕入れておくことです。「この業務は一般的にどのような方法で行われているのか」「業界標準ではどういった処理フローが多いか」をAIに質問し、あらかじめA案・B案・C案という選択肢を準備してから打ち合わせに臨みました。
この進め方には、もう一つ重要な効果がありました。スクラッチ開発でよく起きる問題として、「要求者の言葉通りに実装したら、他の人には使いにくい機能になってしまった」というケースがあります。特定の担当者の頭の中にしかない業務フローをそのままシステム化すると、その人が異動・退職した途端に誰も使い方がわからなくなる、いわゆる属人性の高いシステムが生まれてしまいます。業界標準を起点に選択肢を提示する進め方は、こうした属人的な要件の混入を自然に防ぐことにもつながりました。
AIとの開発の実際――コーディング編
指示の質がコードの質を決める
SuiteScriptのコードを生成させるとき、重要なのはAIへの指示の質だと実感しました。「こういうコードを書いて」だけでは動きません。
「このフォームは受注入力画面で、品目コードを入力したら在庫数と単価を自動取得し、数量×単価で金額を計算する。保存前に合計金額が0円のケースは警告を出す。NetSuiteのSuitelet + ClientScriptで実装すること」
このような粒度で指示できるのは、業務とNetSuiteの両方を知っているからです。AIはコードを生成し、自分はビジネスロジックを判断する。この役割分担が生産性の核心でした。
AIに任せてはいけない部分がある――管理設計は人間が主導する
ここで一点、重要な注意をお伝えしたいと思います。AIがコードを生成してくれるからといって、すべてをAIに任せれば良いわけではありません。今回痛感したのが、実装後のメンテナンスを見据えた管理設計の重要性です。
今回のプロジェクトはスクリプト120本超えという、社内でも前例のない規模でした。社内のこれまでのNetSuiteプロジェクトでも、多くて20〜30本程度です。その感覚のまま開発を進めていたら、スクリプトが同一フォルダに無造作に積み上がっていくだけになっていたでしょう。そうなると問題発生時の原因特定も、機能改修時の影響範囲の調査も、手がつけられない状態になります。
AIはこうした管理設計を、明示的に指示しない限り自発的にはやってくれません。「フォルダ構成はどうあるべきか」「命名規約はどう統一するか」「共通処理はどこまでモジュール化するか」といった判断は、開発者側が先に決めておき、AIへの指示に織り込む必要があります。
この経験から考えること
AIがこれだけコードを書けるなら、SuiteScript専門家の仕事はなくなるのか、という問いが出てきます。ベンダー側の立場から正直にお伝えすると、「コードを書く専門家」への依存度は今後下がっていくでしょう。一方で、「何を作るべきかを判断できる人」「AIに正しい文脈で指示を出せる人」の価値は上がります。
見方を変えれば、AIはNetSuiteが本来目指していたEUCの姿を、スクリプトの領域にまで押し広げるものだとも言えます。ユーザー企業の担当者が業務知識を武器にAIを使いこなせれば、専門ベンダーへの依存なしに高度なカスタマイズを実現できる時代がすでに始まっています。
まとめ
「NetSuiteのカスタマイズ＝専門ベンダーに頼む」という構造は、AIによって少しずつ崩れていきます。30人月の開発規模を1人で走りきれたのは、AIのおかげではなく、AIをうまく使える業務知識があったからです。NetSuiteが本来意図していたEUCの精神を、AIがスクリプトの領域にまで実現してくれた、そんな経験でした。
次回は、フォルダ構成・命名規約・モジュール化の具体的な設計パターンについて書いてみたいと思います。
