はじめに こんにちは、データ・AIシステム本部 検索基盤部 検索基盤ブロックの吉永です。 ZOZOは2026年5月30日（土）に東京・新宿のベルサール新宿グランドで開催された「 JJUG CCC 2026 Spring 」にブーススポンサーとして協賛しました。JJUGは、日本におけるJava技術の向上・発展と一層の普及・活性化を目指して設立された、ボランティアメンバーで運営される日本のJavaユーザーコミュニティです。CCCは、JJUGが主催する「Javaに閉じず」「技術に閉じず」オープンソースを中心とする様々なコミュニティから参加者を募って、コミュニティを横断した「クロスコミュニティなカンファレンス」です。 ZOZOTOWNでは、検索、カート決済、ショップ直送、基幹システムなど、多くの領域でJavaを使用しています。私たちが日々使っている技術を支えてくれているコミュニティへ貢献したいという思いから、昨年秋に引き続き今回も協賛しました。 本記事では、ZOZOのエンジニアが気になったセッションの紹介と、ZOZOブースの様子をお伝えします。 目次 はじめに 目次 Javaエンジニアが気になったセッションの紹介 普通のFeature Flag実践入門 AI時代のソフトウェア設計の学び方 不変条件と整合性境界ービジネスが決める設計判断と実現パターン アンカンファレンス（2）「テーマ：AI×レビュー」 Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変 ZOZOブース 「ソウゾウのナナメウエ × Java」 集まった体験談 バージョン・言語仕様 関連 AI 関連 ”沼”系の苦労話 まとめ Javaエンジニアが気になったセッションの紹介 ZOZOのJavaエンジニアが気になったセッションをいくつか紹介します。 普通のFeature Flag実践入門 ZOZOMO部OMOブロックの木目沢です。irofさん（ @irof ）の『普通のFeature Flag実践入門』を紹介します。 speakerdeck.com Feature Flagについて体系的にまとまった情報があまりなく、非常に役に立つセッションでした。自チームの現状を振り返ると、Feature Flagの利用は散発的でした。導入後の撤去漏れや、AWS AppConfigにおける「インフラ側の管理とコード側の管理を同時に意識しなければならない」という運用コストが課題となっていました。ここ最近は後方互換を保てるリリースだったり、先行リリースしても問題ない状況だったのでFeature Flagをそれほど使わずに済んでいましたが、常にそうした条件が揃うとは限りません。そういう意味でも、今後は積極的に活用していきたいと考えていたので、体系的に説明いただいた今回のセッションは大変貴重でした。 「デプロイとリリースを分離することで、誰が嬉しいのか」という問いが良かったです。その恩恵を受けるのはエンジニアではなくビジネスサイドであるという視点は、改めて重要な示唆を与えてくれるものでした。生成AIの活用によって開発速度が向上しても、リリースプロセスが重ければ効果はあまりありません。自チームはスクラムを採用していますが、スクラムにおいてもスプリントを通じてリリース可能なインクリメントを作り上げることが前提であり、そのリリース自体が重いというのはいい傾向ではありません。 実装面では、Feature Flagの設計におけるON/OFFの制御方針、if/elseの構造、else節の要否といった意思決定が大事であること、撤去が極めて重要であることも改めて確認しました。ログ・監視・マイグレーションとの整合性など、運用上の注意点も網羅されており、実践に直結するセッションでした。 AI時代のソフトウェア設計の学び方 引き続き木目沢が、増田さん（ @masuda220 ）の『AI時代のソフトウェア設計の学び方』を紹介します。 speakerdeck.com 正解のあるなしではなく、増田さんの考えという前提ではありましたが、自分の仕事の範囲における解釈でもやはり「小さな設計の反復×人の活動支援」が今のところ合っていると感じています。コンテキストの制限やLost in the Middleの現象も避けられない現状を見ると、小さな設計の反復をやっていくほうが良いというのが現時点での自分の理解です。 同様に、「ソフトウェア開発」は「事業開発」と「組織開発」と強く結びついているということもすんなり入ってきました。むしろ生成AIで実装は速くできるようになったので、開発者も事業開発や組織開発といった領域に足を踏み入れる余裕が持てるようになったのではないでしょうか？OMOブロックでも去年からビジネス部門と開発部門が一緒になって仕事をすることを始めています。ビジネス部門と一緒にソフトウェア開発をするのはとても良い体験です。 ソフトウェア開発の根底原則は「事業目的の適合性」と「変更容易性」です。特に「ソフトウェア設計のあらゆる原則とパターンは、この変更容易性の原則の特殊化」という言葉には納得しかありません。 気になるのは、生成AIでこのあたりが変わっていくのか、つまり生成AIが読めればなんでもいいのではないでしょうかという論調も囁かれたりします。少なくとも生成AIは「人の活動支援」というスタンスでいるうちは「変更容易性」の原則は変わらないでしょう。私のケースですが、生成AIが変更容易性の高いコードを書くように色々な設計原則をSkillで伝えているのもそういうことかと思います。 「事業目的の適合性」「変更容易性」を学ぶための初級編として「区分」に注目するのは面白いと思いました。思い返せば、売上に直結するような変更をするのに大体「◯◯区分」に手が入っていました。新しいプラン、プランの内容の変更、ルールの追加や変更などですね。 最後に印象的だったのが、内容はあくまで増田さん自身の考えであると繰り返しおっしゃっていたことです。他にも多くの考え方があると承知した上での内容でした（そのとおりの言葉ではないですが、ニュアンスは合っているかと思います）。そもそも生成AIの時代はかつてなく不確実性が高く、1つの答えが存在するはずもありません。そういう意味でも、今の時代は「人と人との相互作用」がより大事なフェーズではないでしょうか。生成AIがこんなに発展しているのに人が大事とはまた面白い時代ですよね。 不変条件と整合性境界ービジネスが決める設計判断と実現パターン 商品基盤部1ブロックの井草です。nrsさん（ @nrslib ）の『不変条件と整合性境界ービジネスが決める設計判断と実現パターン』を紹介します。 speakerdeck.com スピーカーのnrsさんも仰っていましたが、朝一から頭をフル回転させるセッションでした。今回のテーマは「不変条件（Invariant）」と「整合性境界（Consistency Boundary）」です。私自身、オブジェクト指向設計に慣れていることもあり、設計を考えるときは「どのオブジェクトをまとめるか」「どこで集約を切るか」から考え始めることが少なくありません。しかし、このセッションで特に印象的だった考え方があります。 「不変条件が先、集約が後」 です。まず考えるべきなのは、システムが守るべきビジネス上のルールです。そして、そのルールが「一瞬たりとも破ってはいけない真の不変条件」なのか、「最終的に整合していればよい遅延可能な不変条件」なのかを見極めることが重要だと説明されていました。 例えば、二重引き落としや二重予約のように、一度破られると後から補償できないルールは即時整合性が必要です。一方で、後から整合性を回復できるものは、プロセスによる結果整合性という選択肢もあります。 なぜこの見極めが重要なのか。それは、すべてを即時整合性で守ろうとすると、トランザクションや集約が肥大化し、システムの変更や分割が難しくなるからです。マイクロサービス化や分散システムを多く扱う今においては、次の問いを持つことが大切です。 「そのルールは本当に遅延を許容できないのか？」 設計者として、この問いを意識することの重要性を感じました。集約から考えがちな自分にとっても、「まず守るべきルールを見つける」という視点は非常に学びの大きいセッションでした。 アンカンファレンス（2）「テーマ：AI×レビュー」 ECプラットフォーム部マイクロサービス戦略ブロックの半澤です。アンカンファレンスの第二部に参加しました。テーマは「AIが生成したコードを全部見るのか」「レビューする手間は増えていないか」で、Javaチャンピオンの谷本さんの進行のもと、ディスカッションが行われました。生成AIを活用した開発が身近になりつつある今、多くのエンジニアにとって関心の高いテーマではないでしょうか。 今回のアンカンファレンスでは、さまざまな観点から意見が交わされました。AIが生成したコードの確認はもちろん、レビューの認知負荷やコードレビューと品質保証の関係、テストや設計で何を担保するのかといった幅広い話題に及びました。 話題の中で興味深かったのは、AIによってコードを書く時間とレビューする時間のバランスが変わってきているという観点です。AIがコード生成を担う場面が増えると、コードを書く時間は短くなります。一方で生成されたコードを確認する作業が連続しやすくなり、レビューの負荷が大きく感じられるのではないか、という話がありました。その負荷を下げる工夫として、コードだけを見るのではなく確認しやすい形を整える方法が挙がりました。AIや自動化を活用して変更内容の可視化・スクリーンショット・テストコード・補助的なドキュメントを用意するのがその例です。 また、コードレビューだけで品質を保証できるのか、という話題も印象に残りました。レビューでソースコードをすべて確認することだけが品質保証ではなく、テストや設計段階での確認など、複数の仕組みを組み合わせて品質を支える必要があります。一方で、レビューによって見つけられる問題があることも確かです。 レビューで何を見るかも、考え方はさまざまです。細かな実装の書き方すべてを見るというより、リスクが高そうな箇所や、自分が実装するとしても迷いそうな箇所を重点的に見るという考え方があります。たとえば次のような観点は、人間が注意して見る価値があります。データの処理方式、アーキテクチャによって影響が大きく変わる部分、テストでは見つけにくい同時処理や状態管理の問題、後から変更しやすい構造になっているかなどです。AIが生成したコードであっても、人間が書いたコードであっても、こうした観点自体は大きく変わらないのだと感じました。 一方で、AIの生成するコードには、生成させた本人も意図を説明しづらい処理が混入することもあります。なぜその実装になっているのか、不要な処理ではないのか、後から変更しやすい構造になっているのか。そうした点を確認するには、単にコードを眺めるだけでなく、テストケースや設計の意図、変更の影響範囲も含めて見ていく必要があります。 品質に対する考え方は、システムの特性によっても変わります。利用者が限られたシステムで、非常に低い確率でしか発生しない不具合であれば、完全に防ぐために大きなコストをかけるよりも、発生時の対応も含めて合理的に判断する方がよいケースもあります。求められる品質水準は、システムの用途や利用規模、影響範囲によって変わるという点も、アンカンファレンスの中で印象に残った話題でした。 私が普段携わっているZOZOTOWNは、多くのユーザーや取引先に関わるサービスです。そのため、一見すると小さな不具合であっても、実際にはユーザー体験や業務に少なからず影響を与えることがあります。 もちろん、あらゆるケースを事前に防ぎきることはできません。しかし、開発工程が後半に進むほど修正コストが大きくなりやすいため、レビューやテストで気づける問題については、できるだけ早い段階で見つけ、未然に防ぎたいと感じています。そして、そのエラーの先には、実際にサービスを利用するユーザーがいます。また、不具合が発生した際には、その対応にあたる営業やカスタマーサポートなどの仲間もいます。小さく見える不具合であっても、そうした対応が積み重なることで、サービスやチームへの信頼に影響するかもしれません。 だからこそ、合理的な判断は大切にしながらも、ユーザーに届けるものに対してできる限り誠実に向き合いたいと思います。今回のアンカンファレンスを通じて、コードレビューを品質保証における重要な工程の1つとして捉える自分の考えを、改めて認識しました。 AIが書いたかどうかにかかわらず、エンジニアとしても、自分たちが届けるものに責任を持つ姿勢は変わりません。AI生成コードとの向き合い方を通じて、自分たちのレビュー観や品質への向き合い方を見直す、有意義なアンカンファレンスでした。 Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変 引き続き半澤が、Ayana Murakamiさんの『Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変』について紹介します。 speakerdeck.com Murakamiさんは、大学院で情報可視化を専攻していた「可視化オタク」として、遡れる限りの過去のJJUG CCCの発表データを分析されていました。松尾芭蕉の言葉として知られる「不易流行」を軸に、変わらず語られ続けているテーマと、時代に応じて関心が高まっているテーマを、テキスト分析と可視化によって読み解く内容でした。 まず、「変わらないもの」として挙げられていたのは、DBやテーブル設計に関するトピックです。業務の現場で複雑な要件をどのようにテーブル設計へ落とし込むのか、変化に強く柔軟な設計をどう実現するのかといったテーマは、継続して高い関心を集めていました。また、ファイルやクラスといったトピックからは、業務システムの設計だけでなく、Javaそのものの仕組みや内部構造への関心も根強くあるようです。前者は現場での永遠のテーマであり、後者はJJUG CCCでこそ聞きたいテーマでもあります。もし同時間帯に両テーマのセッションがあった場合、どちらを聴講するか迷ってしまいそうです。 次に、関心の高さに周期性があるトピックとして、Spring Bootのアップデートや周辺技術も紹介されていました。Spring BootのメジャーアップデートやJava LTSのリリースに連動するという分析は、自分の経験からも納得感がありました。 「変わるもの」としては、GraalVM / Native Image、Gradle / Maven、コミュニティといった、過去により強く関心を集めていたトピックが取り上げられていました。これらは廃れたというより、現在も議論され続けているテーマです。特にコミュニティに関する発表では、キャリアに関する話題も多かったとのことで、技術だけでなくエンジニアとしてどう成長していくかも、JJUG CCCで語られてきた大切なテーマなのだと感じました。周囲にも「JJUGに育てられた」と感じている人がいますし、自分自身もその一人です。技術的な学びだけでなく、エンジニアとしての視野を広げ、自分の歩み方を考えるきっかけを得られることも、JJUG CCCの大きな魅力だと感じています。 近年関心が高まっているトピックとして、2023年以降ではAIやLLMが挙げられていました。JJUG CCCでは生産性向上や効率化、エンタープライズ領域でのAI・LLM活用が多く語られています。一方、海外のJavaカンファレンスではAIをどうサービスに組み込むかという観点の議論が多いという比較も印象的でした。 JJUG CCCには、コンピュータサイエンスや設計の基礎のように長く大切にされてきた「不易」と、AIやLLMのように時代とともに関心が高まる「流行」の両方があります。Murakamiさんは、その根底にはJavaを使って安定したサービスを届けたいという思いがあると述べられていました。基礎的な知識や新しい技術の両方に触れられる場として、JJUG CCCの魅力を改めて感じるセッションでした。 ZOZOブース 「 ソウゾウのナナメウエ × Java 」 今回のZOZOブースのテーマは「 ソウゾウのナナメウエ × Java 」。 お題として「あなたのソウゾウのナナメウエなJava体験を教えて」を掲げ、来場者の皆さんに体験談を付箋に書いてパネルに貼っていただく企画を実施しました。”ソウゾウのナナメウエ”はZOZOのカルチャーです。ZOZOらしくJavaコミュニティを盛り上げたいという思いからこのテーマを企画しました。やらかし談、ドハマりしたバグ、救われた話など、ジャンルを問わずJavaにまつわるエピソードを募ったところ、 約70件 の体験談が集まりました。 参加してくださった方には、JJUG CCC限定の「 Duke×箱猫マックスステッカー 」をプレゼントしました。 集まった体験談 集まった付箋を分類すると、以下のような5つのトピックに分かれました。 トピック 件数 バージョン・言語仕様 19件 Spring・フレームワーク 14件 コミュニティ・その他 14件 JVM・ビルド・運用 13件 AI・他言語・開発スタイル 11件 注目のトピックをいくつか紹介します。なお、付箋に書かれた体験談は、参加者の皆さんの表現を活かすため原文のまま掲載しています。 バージョン・言語仕様 関連 新機能への歓迎と現場の苦労がリアルに表れていました。「recordクラス誕生！」「Virtual Threadはいいぞ」という新機能への期待の声がある一方、「Java 8→21移行中！」という苦労話も。「Springバージョン上げたいけどJavaバージョン上げられない…」「JavaのVerupするしないで顧客ともめがち…」という現場の率直な声も並びました。「まだJava 8（担当）」という付箋には、多くの参加者が共感していた様子でした。 AI 関連 今年ならではの傾向が出ていました。「AIが書いてくれるのでJavaを書けない」「AIでGradleの使い方を忘れた」「AIネイティブすぎてJavaが読めない」という声が集まりました。「コードのライセンスの問題でAIが使えなかった」という実務的な課題まで登場し、AIに任せる快適さと任せすぎることへの不安が同居しています。エンジニアコミュニティとして今まさに向き合っているテーマだと感じました。 ”沼”系の苦労話 「Eclipseでの環境構築で6営業日溶かした（泣）」「GCチューニングで全部止めた」「ビルド時間にコーヒーのめる」「カレンダーの月が0始まり…」など、思わず笑いを誘うエピソードが並びました。苦労話もユーモアに包んで共有されているのが、JJUGコミュニティらしい温かい雰囲気でした。 今回のお題を通じて、バージョン移行の苦労やAI時代の新しい戸惑いといった技術的なリアルはもちろん、まさに”ナナメウエ”な体験まで、Javaエンジニアのリアルな声が集まりました。苦労話ややらかし談を楽しく共有できる。そんなオープンで温かい雰囲気こそが、JJUGコミュニティの魅力だと改めて感じました！ ご参加いただいた皆さん、ありがとうございました！ まとめ ブースやセッションで交流してくださった皆さん、本当にありがとうございました。これからも一緒に楽しみながらコミュニティを盛り上げていけたら嬉しいです。次のJJUG CCCでもぜひお会いしましょう！ ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

こんにちは、事業開発室の里中裕輔です。 本記事では、Engineers GUILDのご紹介と、その8回目のイベントであった Engineers GUILD Vol8 「世界トップの学会コンペの優勝者が解説する、最先端のDeep Researchシステムのアーキテクチャ」 についてレポートします。 Engineers GUILDとは Engineers GUILD（エンジニアズ・ギルド）は「エンジニアの、エンジニアによる、エンジニアのためのギルド」を掲げる、分野横断型の技術コミュニティです。現場で活躍するエンジニア同士が、副業や越境活動を通じて学び合い、つながり、共創できる場を目指します。 https://engineersguild.peatix.com/ その第8回目として、2026年04月22日（水）に、Deep Researchに関する勉強会を開催しました。 2025年2月に Deep Research が登場し、市場調査、競合分析、先端技術調査など、Web上を調査する様々な場面で活用されています。このように、ブラウザのチャットUIで利用する場面が多い一方で、システムへの組み込みも検討されています。 Deep Researchをプロダクトや業務システムに組み込もうとすると、すぐに大きな壁にぶつかります。商用APIを利用すればスピーディに始められる一方で、継続利用にはコスト面のハードルがあります。また、自社で内製しようとしても、Deep Researchのアーキテクチャは十分に公開されていないケースが多く、検索、推論、ツール制御、エラー処理まで含めて自分たちで設計するのは簡単ではありません。だからこそ、「Deep Researchをどう作るのか」をアーキテクチャの観点から理解することには、大きな価値があります。 タイトルにもありますが、我々のチームは昨年のNeurIPSコンペで優勝を果たしました。 https://www.dentsusoken.com/news/release/2025/1219.html 今回の勉強会は、私たちのチームが注目している「DR Tulu」という論文で公開された Deep Research システムのアーキテクチャについて解説し、参加者の方々と活発に議論できた会になりました。 勉強会の内容としては以下のとおりです。 ・電通総研『尾崎 尚憲』さん： 「DR Tuluのアーキテクチャ解説」 ・懇親会 DR Tuluのアーキテクチャ解説 尾崎さんからは、オープンソース技術で構築されたDeep Research システムである「DR Tulu」に関する講演がありました。今回は、モデルの解説のような理論には踏み込まず、どういったアーキテクチャであるのかの解説がメインでした。 多くの方にとって、Deep ResearchはブラウザのチャットUIから利用するものだと思います。そのため、一見すると「高性能な生成AIモデルが、うまく調査してくれている」と見えるかもしれません。しかし、実際のDeep Researchは単体のAIモデルではありません。 検索エンジン、Webクローラー、キャッシュ、API連携、ツール制御層、エラー処理など、複数のコンポーネントが連携して動く“調査システム”です。つまり、良いDeep Researchを作るには、モデルの知識だけではなく検索・取得・制御・復旧まで含めた総合的なシステムエンジニアリングの力が求められます。 尾崎さんより、「DR Tulu」を題材に全体のアーキテクチャの概要や、システムエンジニアリング上の10個の工夫など、アーキテクチャ面の紹介がされました。 発表スライドはこちらで公開されているので、興味のある方はご覧ください。 https://speakerdeck.com/hisanoriozaki/dr-turu-akitekutiyawan-quan-jie-shuo 懇親会 懇親会も多くの方に残っていただき、発表内容に関する質疑や広くAIについてのディスカッションができました。今回、アーキテクチャにフォーカスしたイベントだったので、日ごろAIエージェントの開発を行っている方に多く参加していただける会になったと思います。 意外だったのは、モデルの学習方法や評価方法などの議論も行われたことです。事前の想定では、アーキテクチャや実装面での工夫に関する議論が多くなると考えていたので、最初は不思議に思いました。参加者の方々と会話を進めると、AIの導入を推進しているエンジニアの方々は、各ステークホルダーに「そのシステムがなぜそういった出力をしたのか」を説明する責任を負っており、モデルのアーキテクチャについての知識も必要とされているということがわかりました。 そのため、エンジニアの方々もモデルの学習方法や評価方法などに踏み込んだ質問をされるということになりました。 私自身としても、多様な視点で会話することができ、有意義な懇親会だったと感じております。 まとめ 今回は、Engineers GUILDのご紹介と、その8回目のイベントであった 「世界トップの学会コンペの優勝者が解説する、最先端のDeep Researchシステムのアーキテクチャ」 についてレポートしました。 私が勉強会を通じて感じたのは、エンジニアの方々の情報収集において Deep Researchシステムは身近なものになったということでした。そんな状況の中で、コストの面や機密情報の投入など、Deep Researchシステムを使ううえでの課題があることを感じました。 Deep Researchは、単なる便利な調査ツールから、プロダクトや業務システムに組み込まれる“知的基盤”へと進化しつつあります。その流れの中で、生成AI、LLM、AIエージェントをどのように設計し、どう運用し、どう継続的に価値へつなげるのか。今回の勉強会は、その問いに向き合う非常に良い機会となりました。 電通総研は、引き続きこのような勉強会を開催する予定ですので、興味ある方はぜひご参加ください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @satonaka.yusuke レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

システム開発を進めるなかで、開発会社から想定外の追加見積もりを提示されることがあります。 「当初の見積金額に含まれていると思っていた」「本当に支払う必要があるのか分からない」と戸惑う発注担当者も少なくありません。 ただし、追加費用が発生したからといって、すべてが不当な請求とは限りません。 当初の契約に含まれていない機能の追加や、合意後の仕様変更によって作業が増えた場合は、追加費用が必要になることがあります。 一方で、当初の仕様どおりに動かない不具合の修正や、開発会社側の設計ミスまで発注者が負担すべきとは限りません。 重要なのは、 当初の契約範囲と追加された作業を切り分け、金額の根拠や合意の経緯を確認すること です。 そこで今回は、システム開発で追加費用が発生する原因と請求の妥当性を見極める方法を、確認すべき順番で整理しました！ 不要な支出を抑えながらプロジェクトを前へ進めるために、追加見積もりを受け取ったときの判断材料として役立ててください。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド システム開発で追加費用が発生する仕組みを理解しましょう！ システム開発の追加費用とは、一般的に 当初合意した作業範囲を超える対応に必要な費用 を指します。 見積金額は、要件、機能、作業工程、開発期間、必要な人員などの前提条件をもとに算出されます。 そのため、開発開始後に前提条件が変われば、必要な工数やスケジュールも変わり、当初の金額では対応できなくなる場合があります。 特に、システム開発では、完成前の製品を見ながら要望を確認することが難しく、開発が進んでから認識の違いや要件の不足が判明しがちです。 追加費用の発生自体を問題視するのではなく、 何が変わり、どの作業が増え、なぜその金額になるのか を確認する必要があります。 また、追加開発、仕様変更、不具合修正では、費用負担の考え方が異なります。 まずは、それぞれの違いを整理し、請求内容がどこに該当するのかを明らかにしましょう。 追加開発・仕様変更・不具合修正の違いを整理しましょう！ 追加開発 とは、当初の要件や仕様に含まれていなかった機能や作業を、新たに加えることです。 たとえば、当初は予定していなかった決済機能や管理画面を追加する場合は、追加開発に該当しやすくなります。 仕様変更 は、すでに合意した画面、処理方法、入力項目、業務フローなどを途中で変更することです。 既存の設計やプログラムを作り直す必要があれば、変更箇所が小さく見えても追加工数が発生します。 一方、 不具合修正 は、合意した仕様どおりに動作しない箇所を直す作業です。 当初の仕様を満たすために必要な修正であれば、原則として追加開発とは分けて考える必要があります。 ただし、仕様書の表現が曖昧な場合は、不具合なのか新たな要望なのかを判断できないことがあります。 作業の名称だけで決めず、 要件定義書や仕様書に記載された完成条件と、今回求める動作を比較すること が重要です。 仕様変更や機能追加で作業範囲が広がるからです！ 開発途中で利用部門や経営層から新しい要望が出ると、当初予定していなかった作業が増えます。 たとえば、入力項目を一つ追加する場合でも、画面だけを直せば終わるとは限りません。 データベースの変更、入力チェックの追加、帳票への反映、既存データとの整合性確認、テストなどが必要になることがあります。 そのため、発注者側には小さな変更に見えても、開発会社側では複数の担当者や工程に影響する場合があります。 また、納期を変えずに追加要望を実現しようとすると、人員の追加や作業時間の延長が必要となり、費用がさらに増える可能性があります。 「少しだけ変更してほしい」と依頼するときも、作業を始める前に 追加工数、追加金額、納期、既存機能への影響 を確認しましょう。 影響範囲を把握せずに口頭で依頼を重ねると、後から追加費用が積み上がり、予算超過につながります。 要件定義の曖昧さが後から認識のズレを生むからです！ 要件定義では、システムで実現する機能や業務上の条件を具体的に決めます。 ところが、「使いやすい画面にする」「作業を自動化する」といった抽象的な要望だけでは、完成形を共通認識にできません。 発注者側が当然含まれていると考えていた処理を、開発会社側が見積もりの対象外と認識していることもあります。 利用者数、データ量、承認手順、例外処理、外部システムとの連携条件などが未確定のまま開発を始めると、後から必要な作業が判明します。 開発の初期段階であれば比較的小さな修正で済む内容でも、設計や実装が進んでから変更すると、作り直す範囲が広がります。 要件定義書では、機能名を並べるだけでなく、 誰が、どのような場面で、何を行い、どの状態になれば完成なのか まで明確にすることが大切です。 未決事項を放置せず、決定期限と担当者を定めて管理することも、追加費用の予防につながります。 技術的な問題や外部環境の変化が後から判明するからです！ 既存システムの改修や連携を伴う開発では、事前調査だけでは把握できない技術的な問題が見つかることがあります。 古いシステムの設計資料が残っていない場合や、実際のデータ構造が想定と異なる場合は、追加調査や設計の見直しが必要です。 データ移行では、表記の不統一、重複、欠損、文字化けなどが判明し、データを整える作業が増えることもあります。 外部サービスとの連携についても、提供される機能や通信方法、利用料金、セキュリティ条件が途中で変わる可能性があります。 さらに、法令改正や社内のセキュリティ基準の変更により、当初予定していなかった対応が必要になるケースもあります。 こうした問題を完全に予測することは困難ですが、事前調査の範囲や想定条件を見積書に明記しておけば、追加費用の理由を確認しやすくなります。 想定外の事態に備え、 開発予算の一部を予備費として確保し、変更時の協議手順を決めておくこと も重要です。 見積もり条件や契約形態が実態と合っていないからです！ 見積書に作業範囲や前提条件が明記されていないと、追加費用を巡る認識の違いが起こりやすくなります。 「システム開発一式」としか記載されていない場合、どこまでが当初金額に含まれるのかを判断できません。 契約形態も費用の考え方に影響します。 請負契約では、合意した成果物を完成させることが中心となり、仕様が確定した開発に適しています。 準委任契約では、一定期間の作業や専門的な支援に対して費用を支払うため、要件が変わりやすい開発で用いられることがあります。 仕様が固まっていない案件を固定金額の請負契約だけで進めると、変更のたびに追加見積もりが発生しやすくなります。 また、初期見積もりが極端に安い場合は、テスト、管理、データ移行などの必要工程が除外されていないか確認が必要です。 比較するときは金額だけでなく、 成果物、対象工程、除外事項、契約形態、仕様変更時の扱い まで確認しましょう。 提示された追加費用が妥当か、順番に確認しましょう！ 追加見積もりを受け取ったときは、すぐに承認したり、根拠なく拒否したりすることは避けましょう。 最初に確認するのは、追加対象とされている作業が、当初の契約範囲に含まれていたかどうかです。 次に、変更が必要になった原因、増える作業、金額の内訳、納期への影響、承認の経緯を整理します。 資料を時系列で確認すれば、妥当な費用、説明が不足している費用、条件を交渉できる費用を切り分けやすくなります。 確認内容はメールや議事録に残し、担当者同士の記憶だけに頼らないことが重要です。 なお、契約条項の解釈や支払義務について意見が対立している場合は、社内の法務担当者やシステム開発契約に詳しい専門家への相談も検討しましょう。 契約書・見積書・要件定義書の範囲を照合しましょう！ まず、契約書に記載された業務範囲、成果物、納期、検収条件、仕様変更の手続きを確認します。 次に、見積書の作業項目だけでなく、前提条件、数量、対応回数、対象外事項、備考欄まで読み込みます。 要件定義書や仕様書では、追加対象とされている機能や処理が、当初から記載されていたかを確認しましょう。 たとえば、「データ移行」とだけ記載されていても、移行件数、対象項目、データ整備の有無によって作業範囲は変わります。 契約書、見積書、仕様書で記載内容が異なる場合は、どの資料を正式な合意内容として扱うのかも確認が必要です。 「必要に応じて対応する」といった曖昧な表現だけでは、費用負担を判断しにくくなります。 対象となる画面、機能、データ、作業工程、対応回数を具体化し、 当初範囲と追加範囲を対比できる状態 にしましょう。 「追加作業」と「本来行うべき修正」を切り分けましょう！ 追加費用の妥当性を確認するには、作業が増えた原因を整理する必要があります。 発注後に新しい要望を加えたのであれば、追加開発として費用が必要になる可能性があります。 一方、合意した仕様どおりに動作しない場合は、本来の成果物を完成させるための不具合修正と考えられます。 また、開発会社側の見積もり漏れや設計上の誤りが原因であれば、すべてを発注者負担とすることが妥当とは限りません。 反対に、発注者側から必要な資料が提供されなかった場合や、確認回答が遅れた場合は、自社側の対応が追加工数に影響している可能性もあります。 重要なのは、どちらか一方を責めることではありません。 当初の合意内容、変更の発生時期、変更を求めた側、増えた作業との因果関係 を事実に基づいて整理しましょう。 双方の事情を切り分けることで、負担範囲について建設的に協議しやすくなります。 追加金額の内訳と費用への影響を確認しましょう！ 追加見積書には、作業項目、担当者、工数、単価、作業期間を可能な範囲で記載してもらいましょう。 設計、プログラム開発、テスト、プロジェクト管理、環境構築など、どの工程に費用が発生するのかを確認します。 金額が「追加対応一式」としか書かれていない場合は、判断できる単位に分けた説明を依頼することが大切です。 ただし、工数だけを減らせばよいとは限りません。 必要な設計確認やテストを削ると、品質低下や稼働後の不具合につながり、結果的に費用が増える可能性があります。 追加費用とあわせて、納期、品質、保守費用、運用負担への影響も確認しましょう。 また、一つの仕様変更が既存機能や外部連携に及ぼす影響についても、説明を求める必要があります。 金額の根拠と変更後に得られる成果を対応させること で、社内でも承認の必要性を説明しやすくなります。 メール・議事録・変更履歴から合意の経緯を確認しましょう！ 追加作業の合意状況を確認するため、メール、チャット、議事録、課題管理表などを時系列に並べます。 誰が、いつ、どのような変更を依頼し、開発会社がどのように回答したのかを整理しましょう。 打ち合わせで追加費用や納期変更の説明があった場合は、その内容が議事録に残っているかを確認します。 口頭だけで依頼が進んでいた場合は、現時点で双方の認識を書面にまとめ直す必要があります。 また、変更を了承した担当者に、追加費用を承認する権限があったかどうかも重要です。 現場担当者の返答を正式承認として扱うのか、責任者の決裁が必要なのかを明確にしましょう。 承認前に作業が始まっていた場合は、開始した理由と事前にどのような説明があったのかを確認します。 今後は、 変更内容、費用、納期への影響、承認者を一つの記録に残す運用 を整えることが再発防止になります。 承認・交渉・保留の3つに分けて判断しましょう！ 確認した追加費用は、承認、交渉、保留の三つに分けると判断しやすくなります。 根拠と金額が明確で、事業上必要な追加作業であれば、納期や成果物を確認したうえで承認します。 必要な機能であっても、金額や作業範囲に疑問が残る場合は、そのまま受け入れずに条件を交渉しましょう。 機能を分割する、実装方法を簡素化する、優先度の低い部分を次期開発へ回すといった方法があります。 説明資料や内訳が不足している場合は、回答期限を示したうえで判断を保留します。 ただし、保留によって作業や納期に影響が出る場合もあるため、その影響も確認が必要です。 合意後は口頭で済ませず、 変更内容、追加金額、支払条件、納期、成果物 を注文書や変更合意書などに残しましょう。 記録を残すことで、後の請求や検収時の認識違いを防ぎやすくなります。 予算超過を防ぐ仕組みを、発注前と開発中に整えましょう！ 追加費用を完全になくすことは難しいものの、予算を管理できない状態は防げます。 大切なのは、変更を早期に発見し、費用や納期への影響を把握してから実施を決める仕組みを整えることです。 そのためには、要件定義、見積もり、契約、進捗確認、変更管理を別々に考えず、一つの流れとして設計する必要があります。 開発会社だけに管理を任せるのではなく、発注者側にも意思決定者と管理責任者を置きましょう。 予算だけを優先して必要な設計やテストを削ると、品質低下や再開発につながる可能性があります。 費用、納期、品質、事業効果のバランスを見ながら変更を判断できる体制 を作ることが、予算超過を防ぐ基本です。 発注前に目的・必須機能・完成条件を明確にしましょう！ 発注前には、どのようなシステムを作るかだけでなく、何のために作るのかを明確にします。 業務時間を短縮する、入力ミスを減らす、顧客対応を迅速化するなど、解決したい課題を具体化しましょう。 機能は、必ず必要なものと、余裕があれば実装したいものに分けます。 すべての要望を同じ優先度で扱うと、予算が不足したときに判断できなくなります。 画面イメージ、利用者、業務フロー、データ量、承認手順、例外処理も事前に整理することが重要です。 さらに、どの状態になれば完成と判断するのか、受け入れテストの条件も決めておきましょう。 社内の複数部門から要望が出る場合は、意見を集約する担当者と最終承認者を定めます。 目的、必須機能、完成条件、承認者を発注前に共有すること で、開発途中の大幅な変更を減らせます。 見積もりは金額ではなく範囲と前提条件まで確認しましょう！ 見積書を確認するときは、合計金額だけでなく、その金額で何をどこまで行うのかを確認しましょう。 機能別または工程別に作業内容が分かれていれば、金額の根拠を理解しやすくなります。 要件定義、設計、開発、テスト、データ移行、外部連携、操作説明、マニュアル、保守などの扱いを確認します。 あわせて、見積もりに含まれない作業や、発注者側が用意すべき資料・環境も整理しましょう。 概算見積もりなのか、仕様確定後の見積もりなのかも重要な確認事項です。 仕様変更が生じた場合の単価、再見積もりの時期、承認方法についても事前に決めておきます。 複数社の見積書を比較するときは、同じ作業範囲と条件で算出されているかを確認してください。 金額が安いかではなく、必要な作業が過不足なく含まれているか を判断することが、追加費用の予防につながります。 契約書に仕様変更の手順と費用ルールを定めましょう！ 契約書には、仕様変更が発生した場合の手続きを具体的に定めておきます。 変更依頼を出せる担当者と、追加費用を承認できる責任者を明確にしましょう。 変更を実施する前に、変更内容、追加費用、納期、品質、既存機能への影響を提示するルールも必要です。 原則として、発注者側が書面で承認するまでは追加作業を始めない運用にします。 ただし、障害対応など緊急性が高い作業では、通常の承認を待てないことがあります。 その場合に備え、仮承認できる担当者、承認可能な金額、事後報告の期限を定めておきましょう。 発注者側が提供する資料や回答の期限、開発会社側が報告すべき事項も明記すると、遅延の責任範囲を整理しやすくなります。 変更時の協議と承認を契約上の手続きとして定めること で、口頭依頼による予算超過を防げます。 開発中は短い間隔で成果物と予算を確認しましょう！ 開発中は、週次または隔週など短い間隔で進捗確認の場を設けましょう。 確認するのは、予定に対する進み具合だけではありません。 完成した画面や機能を実際に見ながら、想定した動作や業務の流れと合っているかを確かめます。 早い段階で認識の違いに気づけば、作り直す範囲を小さくできます。 定例会では、課題、未決事項、変更要望、残予算、追加費用の見込みも確認しましょう。 未決事項には担当者と回答期限を設定し、放置しないことが重要です。 予算消化率と完成している機能の割合を照らし合わせれば、資金不足の兆候も把握しやすくなります。 「順調」という報告だけで判断せず、 成果物、工数、予算、リスクをセットで確認すること が予算管理のポイントです。 機能の優先順位を決め、段階的に開発しましょう！ 限られた予算で必要な成果を得るには、機能の優先順位を明確にする必要があります。 事業への効果、利用頻度、緊急度、開発費用などを基準に評価しましょう。 最初からすべての機能を完成させるのではなく、業務を開始するために必要な最小限の機能を先に開発する方法もあります。 低優先度の機能は第二段階以降へ回し、実際の利用状況を確認してから追加投資を判断します。 開発途中で新しい要望が出た場合は、機能を追加するだけでなく、代わりに別の機能を外す選択肢も検討しましょう。 追加する機能の効果が費用に見合うかを確認しなければ、予算だけが膨らむ可能性があります。 今すぐ必要な機能と、将来でも問題ない機能を分けること で、品質を保ちながら初期費用を抑えやすくなります。 変更管理表で「誰が・何を・いくらで」を記録しましょう！ 仕様変更や追加要望は、変更管理表で一元管理しましょう。 変更内容、変更理由、依頼者、依頼日、対象機能を記録します。 さらに、追加工数、追加費用、納期への影響、既存機能への影響も記載してください。 承認者、承認日、対応状況を明確にすれば、未承認の変更が作業に入ることを防げます。 関連するメール、議事録、見積書、仕様書の更新箇所もひも付けておくと、後から経緯を確認しやすくなります。 変更一件あたりの金額が小さくても、積み重なると大きな予算超過につながります。 定例会で変更管理表を確認し、追加費用の累計と残予算を共有しましょう。 誰が、何を、なぜ変更し、いくら増え、誰が承認したのか を追跡できる状態が、追加費用を管理する土台になります。 まとめ システム開発の追加費用は、仕様変更、機能追加、要件定義の曖昧さ、技術的な問題、契約条件の不一致などによって発生します。 追加見積もりを受け取ったときは、金額だけを見て承認や拒否を決めるべきではありません。 契約書、見積書、要件定義書、仕様書を照合し、追加対象の作業が当初範囲に含まれていたかを確認しましょう。 そのうえで、追加開発なのか、不具合修正なのか、作業が増えた原因はどこにあるのかを整理します。 金額の内訳、納期や品質への影響、変更を承認した記録も重要な判断材料です。 追加費用を防ぐには、発注前に目的と完成条件を明確にし、契約書に変更手続きを定める必要があります。 開発中も成果物と予算を短い間隔で確認し、変更管理表で追加要望を一元管理しましょう。 まずは提示された追加見積もりを当初の契約内容と照合し、 不明な作業、金額、合意事項を一覧にしたうえで開発会社と話し合うこと が大切です。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）