生成AIがドキュメントもコードも書くようになり、成果物を作るコストを大きく下げられる場面が増えた。一方で、成果物を作る速度や量が増えれば、人間による確認やレビューが相対的なボトルネックになりやすい。
では、生成AIを前提としたソフトウェア開発では、開発者とレビュアーの役割をどのように考えるべきなのだろうか。少し考察してみた。
先に要約すると、私の考えは次のようになる。
- 人間が手書きしようが、生成AIが生成しようが、レビュアーへ提出する成果物の内容と品質には、開発者自身が一次的な責任を持つべきである。
- すべてを人間が同じ密度で確認することが現実的でない場合でも、要求・設計方針・テスト観点・リスクなど、品質を左右する判断は人間が押さえる必要がある。
- レビュアーは、生成AIやツールに任せられる部分と、人間が重点的に見るべき部分を改めて見極める必要がある。
- 生成AIをチームの各メンバーの配下にアサインしたと考えたとき、どのような役割分担にすればチーム全体のパフォーマンスと品質を高められるかを考えることで、道が見えるのではないか。
生成AIによって品質問題が生まれたのか
生成AIが業務に活用されるようになっても、成果物の品質問題はなくなっていない。
もちろん、ハルシネーションなど生成AI特有の問題もある。一方で、現在目にする品質問題のすべてが生成AIによって新しく生まれたわけでもない。
要求の抜け、暗黙知の伝達不足、不十分なテスト、成果物を十分に理解しないまま利用するといった問題は、以前から存在していた。
生成AIは、そうした従来から存在する弱点を、生成速度や生成量によって目立たせる側面があるのではないか。
代表的な例をいくつか考えてみる。
1. 暗黙知が反映されない
ドキュメントをどれほど整備しても、暗黙知は存在する。それは業務知識にとどまらない。過去の経緯、ユーザーの好み、プロジェクト固有の制約、「なぜこのような設計になっているのか」といった事情など、多岐にわたる。
これまでは、プロジェクトに長く従事していれば、仕事をする中で自然とそれらを学ぶことができた。そのため、メンバーに対して明示的に指示をしなくても、暗黙知がある程度反映された成果物が出てきた。
現在の生成AIは、リポジトリや設計書、過去の履歴などを参照し、それらを踏まえて成果物を生成することもできる。
ただし、AIがアクセスできる形になっていない情報は、AIも利用できない。
人間のメンバーであれば、会議で聞いた話や過去のトラブル、ユーザーとのやり取りなどから自然と身につけてきた情報がある。しかし、それが文書やデータとして残っていなければ、生成AIからは見えない。
これは、プロジェクトに参加したばかりで暗黙知を持たないメンバーと似ている。そのようなメンバーに仕事を依頼するときと同じように、必要な背景や制約を伝える必要がある。
むしろ生成AIの利用をきっかけに、これまで暗黙知だったもののうち、何を明文化して共有すべきなのかが改めて問われるようになったともいえる。
2. 指示されていない要求は満たされないかもしれない
生成AIに対して、ある機能を実装するよう指示したとする。要求された機能は正しく実装されている。しかし、パフォーマンスが悲惨なコードになっているかもしれない。機能については詳しく指示したものの、パフォーマンスについては何も伝えていなかったからだ。
では、テストでカバーすればよいだろうか。生成AIに大量のテストケースを作らせ、それらをすべてパスすることで品質を担保しようとするかもしれない。
しかし、そのテスト観点が十分であることを、誰が確認するのだろうか。先ほどの例でいえば、パフォーマンスに関するテストは含まれているだろうか。
生成AIがコードを書き、そのコードに対するテストまで生成して、すべてのテストをパスしたとしても、そもそも要求やテスト観点に抜けがあれば、それを発見できないことがある。
理想をいえば、生成されたコードを人間が確認し、十分なテストも実施すべきだろう。しかし、大量のコードが生成される状況で形式的な全量確認を求めても、流し読みになれば意味がない。
だからといって、実装の確認が不要というわけでもない。
重要なのは、要求・設計方針・テスト観点・リスクなど、品質を左右する判断を人間が押さえたうえで、生成AI・自動テスト・人間によるレビューなどをどう組み合わせるかを考えることだ。
すべての組織が同じ方法を取れるわけではない。それぞれのチームが、自分たちの開発速度と品質を両立できる落としどころを探していく必要がある。
3. 「作れるから作る」ドキュメントが増える
生成AIの利用が広がってから、ボリュームは多いものの、中身の薄いドキュメントを目にする機会が増えたように感じる。
以前は、ドキュメントを書くこと自体にそれなりの負担があった。そのため、「誰が何のために読むのか」「何を伝えたいのか」という目的を多少なりとも意識して書く必要があった。
生成AIを使えば、その作成コストは大きく下がる。しかし、人間が内容を理解し、妥当性を判断するコストまで同じ割合で下がるわけではない。
100ページのドキュメントを短時間で生成できても、その100ページに本当に意味があるのかを判断する仕事は残る。
生成AI時代には、「どう効率よく作るか」だけではなく、「そもそも、その成果物を作る必要があるのか」を考えることも、開発者側の責任となる。
4. 生成結果を盲目的に信じる
生成AIに技術的な解説を生成させ、その説明をうのみにし、公式ドキュメントや一次情報で裏付けを取らないケースもある。
裏付けを取らずに情報を信じるという意味では、個人ブログやQ&Aサイトを盲信する問題と共通している。一方で、生成AIは存在しない情報をもっともらしく作ることもできるため、その点では従来以上に注意が必要だろう。
それでも基本は変わらない。重要な判断をするのであれば、一次情報を確認する。情報の根拠を確認する。
生成AIを使うようになったからこそ、その原則はむしろ重要になっている。
生成AIは既存の弱点を増幅する
ここまで挙げた問題には、生成AI固有のものもあれば、以前から存在していたものもある。
私が特に問題だと感じているのは後者である。
要求が曖昧なまま実装する。十分なテスト観点を持たない。成果物を理解しないままレビューへ流す。必要性を考えずドキュメントを作る。情報源を確認せず内容を信じる。
こうしたことは、生成AI以前から起きていた。
生成AIは、それらを圧倒的な速度で行えるようにした。そのため、一つ一つの確認が不十分なままでも、大量の成果物を生み出せてしまう。
だからこそ、AI生成物だけを特別扱いするのではなく、生成速度が上がったことを前提として、開発者とレビュアーの役割を見直す必要があるのではないだろうか。
開発者は「作る人」から「生成物に責任を持つ人」へ
これまでも、設計者や実装者が成果物を作り、それを別のメンバーがレビューするという工程は一般的だった。
もちろん、レビュアーが確認していたのは誤字脱字や細かな実装ミスだけではない。要件に対して設計が妥当なのか、将来の保守性に問題はないのか、性能やセキュリティ上の懸念はないのかといった、より俯瞰した観点も含めてレビューしていたはずである。
つまり、以前から成果物の品質は、作成者とレビュアーの双方によって支えられていた。
だが、生成AIによって、その役割の比重は変わりつつある。
従来は、設計者・実装者自身が成果物を書く作業に多くの時間を使っていた。生成AIがその一部を担うようになると、人間は「何を作らせるのか」「どのような方針で作らせるのか」「どの観点で品質を確認するのか」を判断する比重が大きくなる。
開発者の責任は、すべてを自分の手で書くことではない。
自分がレビューへ提出する成果物について、その目的・設計・テスト・重要なリスクの根拠を理解し、説明できる状態にすることだ。
一方、レビュアーの役割は、その確認作業を代行することではない。作成者とは異なる視点から、設計や実装、リスクを改めて検証することにある。
レビューとは、作成者が何も確認していない成果物を、代わりに検査してもらう工程ではない。
この意識への転換が、生成AI時代にはこれまで以上に重要になる。
レビュアーの役割も変わる
従来のレビュアーも、自身の役割を見直す時期に来ている。
誤字脱字、文章表現、形式上の不整合、静的解析で検出できる問題など、機械的に確認しやすい項目は増えている。生成AIによるレビューも、その一次確認に利用できる。
その分、人間が判断すべき部分へ時間を振り向けるべきだろう。
例えば、
- 要件に対して設計方針が妥当か
- 過去の経緯や組織の暗黙知と矛盾していないか
- 利用者にとって使いやすいか
- 性能、セキュリティ、運用上のリスクを見落としていないか
- 将来的な保守まで考えて、この設計を採用してよいか
といった判断である。
もちろん、人間が実装を見なくてよいという意味ではない。
重要なのは、すべてのレビュー項目を同じ方法、同じ密度で確認し続けることではなく、自動化できる確認と人間が判断すべき確認を整理し、限られたレビュー時間をどこへ使うかを考えることだ。
生成AIを「新入社員」と考えてみる
あくまで役割分担を考えるための比喩だが、生成AIを「広範な知識を持ち、圧倒的な速度で作業できる一方、組織固有の事情を十分には知らない新入社員」のように捉えると分かりやすい。
もし、各チームメンバーの配下に、このような新入社員が一人ずつ突然アサインされたとしたらどうするだろうか。
何を任せるのか。何を本人に確認させ、何を上位者がレビューするのか。どのような知識をドキュメント化して共有するのか。そして、作れるからという理由だけで、成果物を際限なく増やしてよいのか。
生成AI時代の開発プロセスを考えることは、こうした組織設計を考えることに近い。
今後、生成AIが社内ドキュメントや過去の成果物から固有の事情を読み取る能力はさらに高まっていくだろう。それでも、AIがアクセスできる形になっていない情報や、人間の判断の中にしか存在しない前提が完全になくなるとは考えにくい。
そこにこそ人間が介入し、生成AIをより良い方向へ導く役割が残るのではないだろうか。
生成AIによって人間の仕事が単純に減るのではなく、仕事の重心が「自分で書くこと」から「何を作るべきかを決め、どのような観点で品質を確保し、その結果に責任を持つこと」へ移っていく。
その変化を前提として、開発者とレビュアーの役割を改めて設計する必要がある。
本記事におけるAIの活用について
この記事の初稿は筆者自身が作成した。その後、ChatGPT を使用して文章表現の推敲、論点の整理、不足している観点の洗い出しを行った。また、公開前には Deep Research を利用し、記事中の主張について関連する研究や公的資料を調査したうえで、反論を含めたレビューも行った。
それらの結果を参考にしながら、どの指摘を採用するかは筆者自身が判断し、最終的な文章を作成している。
この記事で述べてきた通り、生成AIを利用したとしても、最終的な成果物に対する責任は人間にあると考えている。本記事についても、その考え方に基づいて作成した。
