How I Develop in 2026
2026年現在、カリフォルニアの会社でソフトウェアエンジニアとして働いている。
この記事では、現時点で私がどのように開発を進めているのか、また、Coding Agentを活用した開発において、どのような方法が機能しているのかを記録する。
近い将来、完全に自律的な開発手法が確立されれば、ソフトウェアエンジニアという職業はなくなるかもしれない。少なくとも、必要とされる人数は減るだろう。ここに書くのは、あくまで現時点での開発方法である。
Development Workflow
会社のセキュリティ基準やポリシー、アプリケーションの性質に応じて調整しているが、基本的には以下の流れで実装を進めている。
- Triage
- Planning / Spec
- Dev
- Test(Static Test、TDD、E2Eのいずれか、または組み合わせ)
- PR(+ CI/CD)
- Summary(個人的な学びがあれば)
1. Triage
このフェーズでは、実際に何に取り組むべきかを決定する。四半期ごとの目標、顧客の課題、タスクの優先度などを考慮し、なるべく優先度が高く、インパクトの大きいものから着手する。
タスク間の依存関係によっては、優先順位を適切に設定しなければ開発が円滑に進まない。そのため、チーム内やクライアントとの合意形成も重要である。
2. Planning / Spec
取り組むべきことが決まれば、次にどのように進めるか、PlanningとSpecを定義する。抽象的な目標に対して複数のアプローチを検討し、それぞれのトレードオフを把握した上で、最適解を選択する。
最適解はアプリケーション固有の性質やビジネスニーズに依存する場合があるため、Agent単体では導き出せないこともある。ただし、適切なコンテキストを与えることができれば、Agentでも対応できるかもしれない。
現在はSuperpowersのような便利なSkillsも存在している。それらを活用するか、自身で用意したAGENTS.mdなどのInstructionを利用して進めるのが好ましい。
3. Dev
ここでは実際に実装を行う。既存リポジトリのコーディングルールに従うこと、変更を最小限に抑えること、デグレを防止することを意識しながらAgentを活用する。
必要なコンテキストを取得する際、Agentが外部ツールを利用する場合がある。その際には適切な情報管理が必要となる。例えば、どのアクションを許可するのかを事前に定義する。AWSを利用している場合は、IAM権限によってRead Onlyのアクションのみを許可するのも一つの方法である。
また、.envなどの機密情報をAgentに参照させないようにする。どの情報へのアクセスを許可し、どこを制限するのかを適切に設計することで、安全性を確保しながら開発効率を向上させることができる。
4. Test
Linterなどによる静的チェックや、Unit Test、E2E Testを実施する。
TDDにはデグレを防止しやすいというメリットがある。一方、機能ごとにテストコードが追加されることで、コードベースの肥大化やトークン使用量の増加につながるというデメリットもある。そのため、状況に応じて適切なテスト手法を選択している。
E2Eでは、Agentにブラウザ操作を行わせたり、DBの更新結果などを確認したりする。ただし、DBなどリスクの高い領域については、適切にバックアップを取得した上で、人間が直接操作・確認する方が好ましいと考えている。
5. PR
チーム開発でコードレビューを行う場合や、将来的に変更内容を参照する可能性がある場合は、PRを作成する方が良い。PR Templateなどを利用すれば、変更内容や背景、テスト結果などを、人間が理解しやすい構成で記述できる。
6. Summary
セッション内で個人的な学びや定量的な測定結果が得られた場合は、Markdownファイルとしてまとめるようにしている。課題、対応方法、結果、学びを整理するためのSkillsを個人で作成し、活用している。
What Works Well
Triage & Planning / Spec
ステークホルダーと対話し、優先順位を決め、正しい方向に開発を進めることの重要性は、今の時代においてますます高まっていると感じる。誤った機能の追加や、優先度の低い開発に時間を費やすのはもったいない。
正しい方向に素早く進むために、何が必要なのか、何を優先すべきなのかを考え、意思決定しながら進める力が重要である。
Summary
AIに思考を外注するだけでは、学びが得られない。何が良くて、何が悪かったのかをセッション内で理解し、次回のより良い設計や意思決定につなげる必要がある。
そのためには、AIが作業を完了するだけでなく、人間自身が何を学んだのかを理解することが重要である。
What Doesn't Work Well
TDD / Testing
TDDを徹底すると、実際にコードベースの量が増え、時間的な制約からすべてを理解することが難しくなる。そのため、状況によってはE2Eに重点を置き、最終的な動作確認と責任を人間が担う形で対応している。
また、CLIベースのテストは、Agentに逐一実行させるよりも、自動化した方が効率的である。すべてのログをAgentに読ませるとトークン消費量が大きくなるため、静的チェック用のコマンドを用意し、その実行結果だけをAgentに確認させる運用が効率的だと感じている。
基本的なタスク、重複するタスク、全体の方針はMarkdownファイルでメモリ管理を行い、Agentを育てるとさらに良い。
Conclusion
Coding Agentの普及によって開発速度が向上する一方、求められるスピードも高速化し、人間の負荷は高まっている。また、すべてのコードベースを人間が正しく理解し、実装やテストを行うことは、ますます難しくなっている。
そのため、どのように信頼できるコードを実装するのか、何が期待する結果なのか、変更による影響範囲はどの程度なのかを把握することが重要である。
すべてのコードを詳細に理解するのではなく、コアとなる部分を理解し、適切な検証と意思決定を行うことで、安全性の高い開発を実現できるよう、今後も工夫していく必要がある。