はじめに
最近、Claude CodeやCodexといったAIコーディングツールを、ツール開発や提案用のPoC（概念実証）開発で活用する機会が増えてきました。
また、Google Apps Script（GAS）を使ったちょっとした業務改善などでも、AIを活用することがあります。
実際に使ってみると、単純にコードを書く時間が短くなるだけでなく、開発に対する考え方そのものが少しずつ変わってきていると感じます。
例えば、最初から細かい設計を固めて実装に入るのではなく、まずAIに作ってもらい、動かしてみて、気になったところを修正する。ある程度形になった段階で、設計書や仕様を整理する。
こうした進め方は、試行錯誤の多いツール開発やPoCと相性がよいと感じています。
一方で、AIを活用して開発するようになると、実装の進め方だけでなく、開発プロセスやプロジェクト管理、さらにはチームで開発することの意味まで、いろいろと考えさせられるようになりました。
今回は、日々のAI活用を通じて感じていることと、これからの開発のあり方について考えてみます。
1. まず作って、動かしながら考える
これまでの開発では、要件を整理し、設計を固め、それから実装に進むという流れが基本でした。
もちろん、現在でもこの進め方が適している場面は多くあります。特に、品質や安全性、既存システムとの整合性が重要な開発では、事前の検討が欠かせません。
ただ、ツール開発やPoCのように、実際に動かしてみないと正解が分からないものでは、最初からすべてを決め切ることが難しい場合もあります。
そこで、AIコーディングツールを活用し、次のような流れで開発を進めています。
- 作りたいものや目的をAIに伝える
- まず動くものを実装してもらう
- 実際に動かして、期待どおりか確認する
- 気づいたことや追加要件を伝えて修正する
- 仕様や設計が見えてきた段階で、ドキュメントを整理する
この流れのよいところは、頭の中で考えているだけでは気づきにくい課題を、実際に動かしながら発見できることです。
画面の使い勝手や処理の流れなども、動くものがあれば具体的に議論できます。
また、AIが実装を支援してくれることで、アイデアを形にするまでのハードルも下がります。以前なら実装コストを考えて見送っていた案でも、まずは試してみるという選択がしやすくなりました。
ここで重要なのは、設計書を作らなくてよいという話ではないことです。
設計やドキュメントをなくすのではなく、何を、いつ、どこまで整理するかを考え直すということです。
PoCであれば、まず動くものを作って仮説を検証する。長期運用するシステムであれば、必要な設計やテスト、セキュリティの確認をしっかり行う。
AIによって実装のコストが下がったからこそ、開発の目的に合わせて進め方を選びやすくなると感じています。
2. AIによって、開発プロセスそのものも変わるのではないか
AIコーディングツールを使うと、実装にかかる時間を短縮できる場面があります。
しかし、プロジェクト全体で考えると、実装以外にもさまざまな作業があります。
- 要件の整理や関係者との認識合わせ
- タスクの分割や優先順位付け
- 設計内容や技術選定の検討
- コードレビューやテスト
- 進捗の把握や課題管理
- 仕様書、議事録、設計書などの作成と更新
仮に実装が速くなっても、これらの作業に時間がかかっていれば、プロジェクト全体のスピードは期待したほど上がらないかもしれません。
むしろ、実装が速くなるほど、次に何を作るべきかを決める時間や、生成された成果物を確認する時間がボトルネックになる可能性もあります。
だからこそ、個々の作業をAIで効率化するだけでなく、開発プロセス全体を見直すことが重要なのではないかと考えています。
例えば、要件整理の段階からAIを活用して曖昧な点を洗い出し、設計や作業分割を支援させる。実装後はテストやレビューを行い、その結果を次の作業につなげる。
こうした流れを個人の工夫だけに任せず、プロジェクト全体の仕組みとして設計できれば、より大きな効果が期待できます。
そのためにも、AIを前提とした開発手法やプロジェクト管理の考え方を知り、自分たちに合った進め方を探していきたいと思っています。
3. AI-DLCなどの開発手法から学ぶ
最近、AIを前提とした開発プロセスを考えるうえで気になっているのが、AWSが提唱する「AI-DLC（AI-Driven Development Life Cycle）」です。
AI-DLCは、AIを単なるコード生成ツールとして扱うのではなく、要件の具体化から設計、実装、運用まで、開発ライフサイクル全体で協働する存在として位置づける考え方です。
基本的な説明では、開発ライフサイクルを大きく次の3つのフェーズに分けています。
- Inception（開始・具体化）：ビジネス上の意図を要件や作業単位などに具体化する
- Construction（構築）：設計、実装、テストなどを進め、ソフトウェアを形にする
- Operations（運用）：デプロイや監視など、リリース後の運用を行う
実際のワークフローでは、これらのフェーズの中に、要件分析、アーキテクチャ設計、作業分割、コード生成、ビルド・テストなどの細かいステージが定義されています。
AI-DLCのような方法論で興味深いのは、単にAIに作業を任せるのではなく、AIと人間がそれぞれ何を行い、どの段階で確認や判断を行うのかまで、開発プロセスとして考えられていることです。
一方で、どのプロジェクトでも同じ工程をすべて適用すればよいわけではありません。
小さな業務改善ツールと、大規模な業務システムの開発では、必要な計画やレビュー、ドキュメントの量も異なります。
AI-DLCに限らず、ほかの開発手法やプロジェクト管理の考え方も調べながら、開発規模や目的に応じて、どのようなプロセスが適しているのかを考えていきたいです。
既存の方法論をそのまま導入することが目的ではなく、実際に試しながら、自分たちに合った進め方を見つけることが重要だと思っています。
4. そもそも、複数人で開発することが前提なのだろうか
AIを使った開発を続ける中で、最近もう一つ気になっていることがあります。
それは、これからの開発も、今までと同じように複数人で役割を分担して進めることが前提なのだろうか、という疑問です。
従来のシステム開発では、要件定義、設計、実装、テストなどを複数のメンバーで分担し、それぞれの成果物を共有しながら進めることが一般的でした。
そのために、タスク管理や進捗管理、設計書や議事録による情報共有、レビューなどの仕組みが整えられてきました。
もちろん、複数人で開発することには大きな意味があります。異なる視点からの検討や相互レビュー、専門知識の共有、属人化の防止など、人数がいるからこそ得られる価値もあります。
ただ、AIによって一人で対応できる作業の範囲が広がってくると、これまで複数人で分担していた作業を、AIと一緒に一人で進められる場面も増えてくるのではないでしょうか。
例えば、ちょっとした業務改善であれば、GASを使って自分で実装し、動作確認や修正まで進められる。ツール開発やPoCでも、AIと対話しながら、要件の整理から実装、テスト、ドキュメント作成までを一貫して進められる場面があります。
こうした開発では、必ずしも最初から複数人のチームを組み、細かくタスクを分担する必要はないかもしれません。
一人で進めた方が、認識合わせや作業の引き継ぎが少なく、試行錯誤を速く回せる場合もあります。
一方で、一人とAIだけで進める場合には、レビューの独立性や品質の担保、知識の属人化といった課題もあります。AIが作ったものをAI自身に確認させるだけで、十分な品質を保証できるわけでもありません。
そのため、すべての開発を一人で行う形に変わるとは思っていません。
ただ、これまで当然のように前提としてきた「人間が複数人で役割を分担して開発する」という形も、開発対象やリスクに応じて見直されていくのではないかと感じています。
一人でAIと進める開発、少人数で進める開発、大規模なチームで進める開発。それぞれに適したプロセスがあってもよいのではないか。
AIの活用が進むほど、開発体制やプロジェクト管理のあり方も、より柔軟に考える必要が出てくるのかもしれません。
5. エンジニアの役割も変わっていくのかもしれない
開発プロセスやチームのあり方が変わるのであれば、エンジニアに求められる役割も変わっていくはずです。
AIが実装だけでなく、調査、設計、テスト、ドキュメント作成なども支援できるようになると、人間が直接手を動かす範囲は変わっていく可能性があります。
その一方で、何を作るべきかを決めることや、AIに適切な情報や制約を与えること、成果物の妥当性を判断することの重要性は、むしろ高まるのではないでしょうか。
例えば、次のような役割です。
- 解決すべき課題や目的を明確にする
- AIに適切な情報や制約を与える
- 設計や実装の妥当性を判断する
- 品質やセキュリティを確認する
- 関係者との合意形成や最終的な意思決定を行う
これからは、コードを書く能力だけでなく、問題を整理する力、AIに仕事を任せる力、生成された成果物を評価する力なども、より重要になっていくのかもしれません。
そして、AIが前提になったとき、チームの価値も「人間が作業を分担して実行すること」だけではなく、「人間とAIを組み合わせて、成果を出せる仕組みを作ること」へと広がっていく可能性があります。
もちろん、どのような開発体制が最適なのか、現時点で答えが出ているわけではありません。
だからこそ、実際にAIを活用しながら、その変化を考えていきたいと思っています。
6. これから取り組みたいこと
今後は、日々のツール開発やPoC、GASを使った業務改善などでAIを活用しながら、個々の作業の効率化だけでなく、開発の進め方そのものも見直していきたいです。
具体的には、次のようなことに取り組みたいと考えています。
- AI-DLCやほかの開発手法を調べ、AIを前提とした開発プロセスについて理解を深める
- 開発規模や目的に応じて、どのようなプロジェクト管理が適しているのかを考える
- 一人で進める開発と複数人で進める開発の違いや、それぞれに必要な品質管理の方法を整理する
- 実際の開発で試し、効果や課題を確認しながら、自分たちに合った進め方を探す
最初から完成されたプロセスを作るのではなく、小さく試して改善していくことが大切だと思っています。
AIの進化に合わせて、開発の進め方も変化していくはずです。その変化を追いかけるだけでなく、自分たちの業務やプロジェクトに合った形で取り入れていきたいです。
おわりに
Claude CodeやCodexを使った開発を通じて感じているのは、AIの価値はコード生成だけにとどまらないということです。
まず作って動かしてみる。試行錯誤を通じて仕様を具体化する。必要な情報を整理し、次の作業につなげる。
こうした進め方を個人の工夫だけで終わらせず、開発プロセスやプロジェクト運営の仕組みとして考えることで、AIの活用範囲はさらに広がるのではないでしょうか。
そして、AIが開発のさまざまな工程を担うようになったとき、これまでのチームのあり方や、エンジニアの役割も変わっていくのかもしれません。
今までの開発手法をそのまま維持するのでも、すべてをAIに任せるのでもなく、実際に試しながら、自分たちに合った開発の形を探していきたいと思います。
AIを使ってコードを書くことから、AIを前提とした開発の仕組みを考えることへ。
これからも、実践を通じて考えていきたいテーマです。
……と、ここまで偉そうに書いてきましたが、この記事もAIに書いてもらって推敲したものです（笑）。
まずは自分で実践してみる、ということで。