Skip to Content
Docs09. ビジネス実務AI 前提の開発プロセス再設計
中級processorganizationreviewsoftware-process更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

AI 前提の開発プロセス再設計

この記事の目的

「既存プロセスに AI を足す」から「AI 前提でプロセスを引き直す」への移行を設計できるようになります。開発の重心の移動・仕様の文書化が資産になる構造・レビュー体制の再設計・品質ゲートの再配置・段階的な移行を、組織の意思決定として持ち帰れる状態を目指します。

対象読者

前提知識

本文

概要: 「足す」ではなく「引き直す」

AI を開発に取り入れるとき、最初は「既存のプロセスに AI を足す」形になります。しかし生成量が増え、開発の重心が移ると、既存プロセスのままでは別の場所がボトルネックになります。本記事は、AI を前提にプロセスそのものを引き直す視点を扱います。

ツール固有の導入実務は コーディングエージェントのチーム導入 が正本で、ここではプロセス一般——重心の移動・レビュー・品質ゲート・見積り——をどう再設計するかを扱います。本記事は、生成量が増えた現場でレビューや検証の容量を見直すための設計案です。AI の導入効果はタスク・利用者・既存コードへの習熟で異なり、工程が一律に短縮されるとは仮定しません。

重心の移動(書く → 仕様化・検証)

AI がコードを生成できるようになると、開発者の時間の使い方が変わります。仕様化・生成・検証のどこに時間を使うかを測り直します。

  • 工程別の増減を測る: コードを打つ時間が減る場合でも、「何を作らせるか(仕様化)」と「生成物が正しいか(検証)」の時間が増えます。総量が減るとは限りません
  • レビューがボトルネックになる: 生成量が増えると、それをレビューする容量が追いつかなくなります。従来は「書く」が律速でしたが、AI 前提ではレビューが新しい律速になりがちです。この構造を見落とすと、生成は速いのに全体が詰まります
  • 判断の比重が上がる: 「これでよいか」「どう直すか」という判断が、開発者の主な仕事になります。プロセスは、この判断が滞りなく行える形に組み直します

仕様・意図の文書化が資産になる

AI に正しく作らせるには、何を・なぜ作るかを明確に伝える必要があります。これにより、従来は軽視されがちだった文書の価値が上がります。

レビュー体制の再設計

レビュー待ちが律速と分かった場合は、レビュー体制を再設計します。

  • AI 生成物のレビュー観点: 人が書いたコードと、AI が生成したコードでは、注意すべき点が変わります。もっともらしいが誤った実装、テストのない箇所、規約からの逸脱などを重点的に見ます
  • レビュー容量を計画する: 生成量に対してレビュー容量が足りるかを計画します。全件の人手精査が必要な案件では、その時間も含めて生成の便益を測ります。機械で落とせるもの(lint・テスト・型)は機械で落とし、人のレビューを重要な箇所に集中させます
  • レビューを分担・分散する: レビューが一部の人に集中しないよう、分担・自動化・段階化(一次は自動、重要箇所は人)を設計します

品質ゲートの再配置(テスト・CI が律速)

生成量が増えるほど、それを受け止める品質ゲートの負荷が上がります。

  • テスト・CI が新しい律速: 生成が速くても、テストと CI が追いつかなければ本番に届きません。生成量に見合うテスト・CI の容量(回帰テストと CI 組み込み)を計画します
  • 品質ゲートを前倒しする: 問題を後段で見つけるほど手戻りが大きくなります。生成の近くで検証を回し、早く弾く設計にします
  • 自動検証を厚くする: 人のレビューだけに頼らず、テスト・静的解析・型チェックといった自動検証を厚くします。生成量の増加は、自動検証への投資で受け止めます

見積り・計画の変化

開発の速度と不確実性が変わると、見積り・計画の前提も変わります。

  • 速度の内訳が変わる: 「実装が速くなった分、レビュー・検証に時間がかかる」ため、単純に速くなるとは限りません。工程ごとの時間配分の変化を見積りに反映します
  • 不確実性の扱い: AI の生成品質はタスクで変動します。楽観的な見積りを避け、検証・手戻りの時間を織り込みます
  • 計測して調整する: 実際の工程別の時間を計測し、見積りを継続的に補正します。導入初期の感覚だけで固定しません

段階的な移行

プロセスの再設計は、一気に変えると混乱します。段階的に移行します。

  • 一気に変えない: 全工程を同時に変えると、負荷増や品質低下の原因を切り分けにくくなります。効果と負荷を見ながら、範囲を広げます
  • ボトルネックを見て順序を決める: 生成を増やす前に、レビュー容量・CI 容量を整えます。律速を先に広げてから、生成を増やします
  • SE の工程別各論と接続: 企業システム開発の工程別の具体は SE 工程別活用マップ が扱います。本記事のプロセス再設計を、工程別に落とすときに参照します

実務での注意点

アンチパターン

  • 既存プロセスに AI を足すだけで済ませる → レビュー・CI が新しい律速になり詰まる → 重心の移動を踏まえてプロセス自体を引き直す
  • 生成量を増やす前にレビュー・CI 容量を整えない → 生成は速いのに本番に届かない → 律速(レビュー・品質ゲート)を先に広げる
  • 必要な人手レビューの費用を見積もらない → 必須の検証を回せず、品質や採算を損なう → 自動検査で支援しつつ、全件精査が必要な案件ではその工数を含めて便益を評価する
  • 仕様・意図の文書化を後回しにする → 曖昧な指示が曖昧な生成物を生む → 文書化を生成の入力として位置づける
  • 導入初期の感覚で見積りを固定する → 実態とずれる → 工程別の時間を計測して継続的に補正する
  • 全工程を一気に AI 前提へ変える → 混乱と品質低下を招く → 段階的に、律速を見ながら移行する

チェックリスト

  • 開発の重心(書く → 仕様化・検証)の移動を、プロセス設計に反映したか
  • レビューが新しい律速になる構造を踏まえ、レビュー体制を再設計したか
  • 仕様・意図・ルールファイルの文書化を、生成の入力として位置づけたか
  • 生成量に見合うテスト・CI の容量を計画し、自動検証を厚くしたか
  • 見積りに工程別の時間配分の変化・検証の時間を織り込んだか
  • 律速を先に広げてから生成を増やす、段階的な移行にしたか

関連トピック

参考資料

TODO・未確認事項

なし

AI 業界レイヤーマップAI 時代のチームトポロジー