AIが実装しレビューする時代に、プロダクトエンジニアは何をするのか

はじめに

こんにちは、お客様向け管理画面チーム（以下、Irisチーム）TLのakariです。法人向けカード基盤提供事業において、BFF兼オーケストレーターに位置づけられるサービス（社内通称Iris）の開発をしています。Irisチームは、社内の基盤サービスを駆使して「ユーザーにどんな機能を届けるか」を先頭に立って考えるプロダクト開発チームです。そんな私たちのチームでは、プロダクトエンジニア（=PdE）がAI時代においてやるべきことは何かを検討し、それを踏まえて自分たちの業務フローを再構築し、日々実践しています。

この記事では、私たちのチームがAI時代におけるPdEの役割をどう捉え直し、それを踏まえてどのような業務フローを構築・実践しているのかを紹介します。AI時代におけるソフトウェア開発のあり方や、プロダクトチーム・PdEの業務のあり方について考えている方にとって、何かヒントになれば幸いです。

TL;DR

AI時代のPdE像：Irisチームは、エンジニアが注力すべき力を「①価値ある仕様を検討し、ステークホルダーと合意する力」「②プロダクトに適した設計に落とし込む力」「③実装〜デリバリーを自動化するパイプラインを構築・メンテする力」「④そのパイプラインの品質と信頼性を担保する力」の4つと定義した。
開発プロセス：仕様合意 → 設計とレビュー → ユーザーストーリー単位のチケット化とレビュー → コーディングエージェントによるPR作成・レビュー・修正の自動サイクル → 人間による最終確認、という流れに再構築した。
品質保証：QAチームと責任境界を引き、既存機能のリグレッションはE2Eテストで自動化（新規機能の実装時にE2Eを整備し、これを積み上げていく）。新規機能自体は手動＋目視でも確認し、リリース物の確認をリリーススキルに組み込んだ。
キーとなる概念：徹底的なシフトレフト／徹底的な自動化／人間に対する最終確認の要求。

PdEがAI時代においてやるべきこと

これを考えるには、まずソフトウェア開発の全工程を洗い出し、各工程の業務を一つひとつ「AIで自動化できるもの」と「できないもの」に仕分けていく必要があります。ソフトウェア開発の工程の粒度とその主担当は開発組織の規模・文化にも依りますが、100人規模の開発組織を抱えるベンチャー企業を想定すると、以下のように整理できます。

工程	主担当	業務	担い手
要件定義	PdM（副：PdE）	選択肢の列挙	AIによる補助
		メリット・デメリット分析	AIによる補助
		意思決定	人間
		文書化	AIによる自動化
設計	PdE	選択肢の列挙	AIによる補助
		メリット・デメリット分析	AIによる補助
		意思決定	人間
		文書化	AIによる自動化
実装	PdE	計画立案	AIによる自動化
		実装	AIによる自動化
		ローカル検証	AIによる自動化
		テスト・静的解析	機械による自動化
		PR作成	AIによる自動化
		PRレビュー	AIによる自動化
テスト	PdE、QAエンジニア	検証環境での動作確認（手動）	AIによる自動化 ※1
		検証環境での動作確認（E2Eテスト）	機械による自動化 ※1
デリバリー	PdE、SRE	リリース作業	AIによる自動化 ※2

※1 検証環境での動作確認は、手動・E2Eテストいずれも最終判断は人間が行う。
※2 リリース作業自体はAIで自動化できるが、最終的なリリースの実行判断は人間が行う。

こうして見ると、従来PdEが担っていた業務の大半はAIで自動化できるものであり、自動化を実現できれば、PdEの責務は要件定義・テスト・デリバリーの領域へと拡張していく余地がありそうです。そこで、AI時代におけるエンジニアがやるべきことを以下のように定義し、エンジニアがここにフォーカスできるよう業務プロセスを再構築していくことにしました。

価値ある仕様を検討し、ステークホルダーと合意する力
プロダクトに適した設計に落とし込む力
設計したものを自動で実装してデリバリーするパイプラインを構築・メンテする力
3のパイプラインが品質と信頼性を担保するようメンテする力

開発プロセス

AI時代においてエンジニアがやるべきことを定義できたら、次は、どうすればそれを実現できるかです。そのためにまず考えたのが、徹底的に自動化することでした。自動化するにあたってセットで考慮しなければならなかったのは、人間はどこで何を確認するべきか、という点です。そこでキーワードとなったのが「シフトレフト」でした。つまり、できるだけ前段に人間による確認を組み込み、後段はAIによる遂行に委ねる形で、業務をスキル化していきました。スキル化したものを列挙すると以下の通りです。

PdM観点でタスクチケットを作成するスキル
PdM観点のタスクチケットを元に設計書を作成するスキル
設計書を元にPR単位の実装方針をチケット化するスキル
PR単位の実装方針チケットを元にPRを作成するスキル
1. 実装計画の立案
2. 実装
3. コーディング規約の遵守
4. セキュリティチェック
5. ローカル検証
PRをレビューするスキル
1. コーディング規約の遵守
2. セキュリティチェック
3. 正規フローに則ってPRが作成されたかをチェック
リリーススキル
QAを行うスキル

そして、PR作成とPRレビューをスキル化するにあたって必要になるのが「ハーネスの整備」です。そのために行なったのは以下の通りです。

コーディング規約の厳格化
既存コードのコーディング規約遵守
単体テストのカバレッジ率向上と閾値設定
SAST（semgrep）の導入
シークレットスキャンの導入
Dockerfile・GitHub Actions Workflowの静的解析

つまり、あらゆる観点でルールをできるだけ厳格化し、それを遵守させることを意識しました。

そして、再度「シフトレフト」と「最終責任は人間」をキー概念として開発プロセスを整理し、以下のように並べました。

担当エンジニアがステークホルダーと仕様を検討し、仕様を合意する
1で決まった仕様を実現するための、プロダクトに適した設計を検討し、ドキュメント化する
チーム内の第三者エンジニアが2の設計ドキュメントをレビューする
3を通過した設計ドキュメントを元に、ユーザーストーリー単位でチケットを分割し、各ユーザーストーリーの仕様・設計の詳細・テスト観点を記載する
4のユーザーストーリーチケットをチーム全員で同期的にレビューする
5を通過したユーザーストーリーチケットを担当エンジニアがコーディングエージェントに渡し、PR作成 → PRレビュー → レビューコメントの対応をAIで自動的に行う。これを、AIが承認レビューを出すまで繰り返す
AIが承認レビューを出したことを確認したら、担当エンジニアがチーム内の第三者エンジニアにApprove依頼を出す。第三者エンジニアは、PRが正規フローに則って作成されたかを目視で確認し、Approveする
担当エンジニアは、4で作成したチケットに記載されたテスト観点を検証環境で動作確認する。全ての項目を確認し終えたらチケットをDoneとし、タスクを終了する

ここで意図しているのは、第三者エンジニアによる最終確認（手順7）を「コードの正しさ」ではなく「正規フローに則って作られたか」に絞っている点です。AIが書いてAIがレビューする以上、コードの正しさそのものを人間が1行ずつ追う運用は現実的ではありません。そこでコードの品質は、厳格化したハーネス（lint・SAST・単体テストのカバレッジ閾値）と、次章で述べるE2Eテスト・QA動作確認で担保する設計とし、人間は機械やAIだけでは担保しきれない最終判断に集中する、という役割分担にしています。

品質保証の方針・体制

前章で説明した開発プロセスを構築すると、生産性が爆上がりしました。正直に断っておくと、この「爆上がり」はいまのところ体感ベースで、定量的に示せてはいません（後述する今後の課題です）。それでも、生産のスループットが上がれば、それに見合う品質保証体制が必要になることは間違いありません。そこで品質保証を、「検証環境での動作確認」と「リリース時におけるリリース物確認」の2つの側面から再構築していきました。

なお、監視・アラート、ロールバック、Blue/Greenデプロイ、フィーチャーフラグといった本番運用のガードレールも当然整備しています。ただ、これらはAI時代以前から変わらず実践している内容なので、本記事では深掘りしません。ここで取り上げるのは、あくまで「AI時代ならではの変化があった部分」に絞ります。

検証環境での動作確認

まずは動作検証についてです。私たちのプロダクトは非常に大きいものなので、QAチームに協力を仰ぎ、QAチームとプロダクト開発チームとで以下のように責任境界を明確にして分担するようにしました。

機能種別	プロダクト開発チーム	QAチーム
既存機能	コンポーネント単体での動作確認を徹底する	コンポーネントを跨いだプロダクト全体の動作確認を徹底する
新規機能	主責務として動作確認を行う	動作確認をサポートする

この枠組みの中で、私たちプロダクト開発チームの責務のうち自動化できるのは、既存機能におけるコンポーネント単体での動作保証です。そこで、コンポーネントレベルのE2Eテストを整備し、テストシナリオのカバレッジを可能な限り上げる方針を採用しました。具体的には、新規機能を実装する際に、その機能のE2Eテストも合わせて実装します。こうして追加されたE2Eテストが、その機能が「既存機能」となったあとのリグレッションテストとして積み上がっていく仕組みです。そして、これらを平日日中に定期実行し、コンポーネントレベルのリグレッションにすぐ気づける体制を構築しました。

リリース時におけるリリース物確認

リリース時には、以下2つの観点でリリース物を確認する必要があります。

本番リリース時に、一時的に障害が発生し得る状態になっていないか
検証環境では動作検証に成功しているが、本番環境では動作保証できないものはないか

1についてですが、リリース時にはDBマイグレート → 非同期処理サーバ → 同期処理サーバ → フロントエンドという、被依存物から順番にデプロイが進んでいきます。そのため、リリース物を複合的に見て、この順序でデプロイが進行したときに一時的な不具合が発生し得ないかという観点で確認する必要があります。これは自動で検知できるので、リリーススキルの中で確認を行うように設定しました。

2についてですが、例えば外部サーバのIFが変更されたためにその追従変更を行なったものの、追従変更対応とリリースの速度が速く、依存先チームの変更がまだ検証環境止まりで本番環境にはデプロイされていない、という可能性があります。このような可能性についてもリリーススキルで人間による確認を要求するよう警告メッセージを出し、障害発生を未然に防げるような工夫を入れています。

今後の課題

これまでに紹介した開発プロセス・品質保証プロセスによって、デリバリー速度・品質ともに向上していることは体感しています。しかし、これを定量的に測定できているわけではありません。フィードバックサイクルを回して改善していくためにも、今後はこれを測定できるようにしていきたいと考えています。

一方で、明らかにわかっている改善課題もあります。それは、トークン消費量が激しく、AIツールの費用が高いことです。構築した開発プロセス・品質保証プロセスの質を担保しつつ、トークン消費量を抑制する工夫が早急に必要になっており、この改善を急いでいるところです。

まとめ

この記事では、私たちのプロダクト開発チームが実践しているAI時代の開発プロセス・品質保証プロセスについて紹介しました。今まさに、AIによってソフトウェア開発のフローそのものが見直されようとしている過渡期にあり、各社・各チームで日々試行錯誤しながら業務されていることと思います。本記事が少しでも、そのような方々の思考のヒントになれば嬉しいです。

法人カード基盤の外部提供の挑戦技術ブログバトンリレー

各エンジニア組織が法人カード基盤の外部提供の挑戦の中で得た知見を順次公開していきます！技術、開発設計や思想、Tipsなど、幅広くお伝えします。

▼公開予定表（各記事公開後、リンク集になります）

タイトル	チーム	執筆者
UPSIDERのカード基盤を「外部提供できる形」にするまで——マイクロサービス化とマルチブランドアーキテクチャ	法人カード基盤の外部提供全体構想	Mitsui
Spanner Change Streams を自前で読む ― 決済データを欠損なく取り込む	カード管理基盤チーム（Solaris）	Ohsako
1年動き続けるワークフローを壊さずにデプロイする ― Temporal Worker Versioning 導入記	請求基盤チーム（Hermes）	nishiwaki
GCP Error Reportingで「最低限の異常検知」を低コストに実現する	法人審査基盤チーム（Hestia）	Mitomi
複数の銀行データソースを1つに束ねる ― マルチブランド法人カードを支える銀行連携基盤	銀行連携基盤	terry
仮説駆動で取り組む負荷試験計画	processor	Kinsho
AIが実装しレビューする時代に、プロダクトエンジニアは何をするのか	お客様向け管理画面チーム（Iris）	Akari
法人カード基盤の外部提供にも耐えうる不正利用対策基盤の構築	Anti-fraudチーム	Ryutaro
法人カード基盤の外部提供という挑戦決済基盤を「他社にまるごと使ってもらう」QAの話	QAチーム	Naoki