Claude Code・Codex時代に伸ばすべき能力と学び方——開発者・要件定義・テスター・PM・情シス向け実践ガイド
Claude Code、Codex、GitHub CopilotのようなAI開発支援ツールが普及し始めたことで、
ソフトウェア開発の現場では「コードを書く力」だけでなく、
「何を作るべきかを定義する力」「AIが作ったものを検証する力」「リスクを判断する力」が重要になりつつあります。
本記事で得られる3つのポイント
- AI時代に、開発者・要件定義担当・テスター・PM/PL・情シス/発注者が伸ばすべき能力が分かる
- 能力を伸ばすための具体的な学習方法、実務演習、成果物の作り方が分かる
- 公式情報・標準・書籍をもとに、年代を問わず学び直すためのロードマップが分かる
なぜ重要か：
AIが実装作業を支援する時代ほど、人間側には「正しく依頼し、正しく検証し、責任を持って判断する力」が求められるためです。
1. AI時代に求められる人材像はどう変わるのか
これまでのIT人材は、プログラミングスキルや開発経験が大きな評価軸でした。
もちろん、今後もコードを理解する力は重要です。
しかし、Claude CodeやCodexのようなAI開発エージェントが普及すると、
単純な実装作業の一部はAIに任せられるようになります。
その結果、人間側に求められる役割は、単なる作業者から、
要件を整理する人、設計を判断する人、品質を保証する人、リスクを管理する人へ移っていくと考えられます。
AnthropicのClaude Code公式ドキュメントでは、Claude Codeはコードベースを読み、ファイル編集、コマンド実行、開発ツール連携を行う
agentic coding tool として説明されています。
また、OpenAIのCodexは、開発者向けのAIコーディングエージェントとして案内されています。
GitHub Copilotも、単なるコード補完だけでなく、AIペアプログラミング、エージェント的な支援へ拡張されています。
- Claude Code公式ドキュメント：
https://code.claude.com/docs/en/overview - OpenAI Codex：
https://developers.openai.com/codex - GitHub Copilot：
https://github.com/features/copilot
2. 全職種共通で押さえるべき考え方
AI時代のスキルアップでは、流行ツールの操作だけを追いかけるのは危険です。
ツールは変わりますが、要件定義、品質保証、セキュリティ、プロジェクト管理、データ管理の基本は簡単には変わりません。
まず押さえるべきは、公式標準や公的資料です。
特に日本国内では、IPAのデジタルスキル標準が重要な基礎資料になります。
デジタルスキル標準は、DXリテラシー標準とDX推進スキル標準で構成され、
すべてのビジネスパーソンとDX推進人材の双方に向けたスキル体系として整理されています。
- IPA デジタルスキル標準：
https://www.ipa.go.jp/jinzai/skill-standard/dss/download.html - 経済産業省 デジタルスキル標準：
https://www.meti.go.jp/policy/it_policy/jinzai/skill_standard/main.html - World Economic Forum Future of Jobs Report 2025：
https://www.weforum.org/publications/the-future-of-jobs-report-2025/ - DORA State of AI-assisted Software Development 2025：
https://dora.dev/research/2025/dora-report/ - Stack Overflow Developer Survey 2025：
https://survey.stackoverflow.co/2025/ai
3. 職種別に伸ばすべき能力
| 人材タイプ | 伸ばすべき能力 | なぜ必要か |
|---|---|---|
| 開発者 | AI指示、コードレビュー、アーキテクチャ、セキュリティ、テスト設計 | AIが生成したコードを正しく評価し、安全にシステムへ組み込むため |
| 要件定義担当 | 業務分析、受入基準、非機能要件、データ設計、合意形成 | AIや開発者が迷わず実装できる粒度まで要求を整理するため |
| テスター | 探索的テスト、リスクベーステスト、AI出力検証、セキュリティ観点 | AI生成物の抜け漏れ、誤実装、業務上の危険箇所を見抜くため |
| PM/PL | AI開発プロセス設計、品質ゲート、コスト管理、説明責任 | AI活用による速度向上と品質・責任のバランスを取るため |
| 情シス・発注者 | ベンダー成果物の検証、AI利用条件、契約・監査・データ管理 | 外部委託やAI活用時の責任範囲、品質、情報管理を担保するため |
4. 開発者が能力を伸ばす方法
開発者は、AIにコードを書かせるだけでなく、
AIに正しく指示し、生成されたコードをレビューし、設計・セキュリティ・テストの観点で評価できる必要があります。
具体的には、小さなアプリケーションや既存コードを使い、
AIにバグ修正、テスト追加、リファクタリング、セキュリティ改善を依頼します。
その後、必ず差分レビューを行い、なぜその修正が妥当なのか、どのようなリスクがあるのかを記録します。
開発者向けの実践課題
- Claude CodeやCodexに小さな機能追加を依頼する
- AIが変更したファイル差分を1行ずつ確認する
- テストが不足している箇所を自分で洗い出す
- OWASP ASVSやNIST SSDFを参考に、セキュリティ観点を追加する
- AIにレビューさせた後、最終判断は自分で行う
開発者におすすめの書籍・資料
| 書籍・資料 | 伸ばせる能力 | 参照URL |
|---|---|---|
| Clean Architecture | アーキテクチャ設計、依存関係設計 | https://www.informit.com/store/clean-architecture-a-craftsmans-guide-to-software-structure-9780134494326 |
| Refactoring 2nd Edition | 既存コード改善、レビュー力 | https://martinfowler.com/books/refactoring.html |
| Designing Data-Intensive Applications | データ設計、信頼性、拡張性 | https://dataintensive.net/ |
| NIST Secure Software Development Framework | セキュア開発、サプライヤー管理 | https://csrc.nist.gov/pubs/sp/800/218/final |
| OWASP ASVS | Webアプリケーションのセキュリティ検証 | https://owasp.org/www-project-application-security-verification-standard/ |
5. 要件定義担当が能力を伸ばす方法
要件定義担当は、AI時代に最も価値が高まりやすい役割の一つです。
なぜなら、AIは曖昧な要求からでも、それらしい成果物を作ってしまうからです。
要件が曖昧であれば、AIは曖昧なまま高速に実装します。
重要なのは、業務を「人」「データ」「判断」「例外」「制約」に分解し、
AIや開発者が実装可能な粒度まで整理することです。
要件定義担当向けの実践課題
- 身近な業務を1つ選び、業務フロー図を作成する
- 登場人物、入力情報、出力情報、判断条件を整理する
- ユーザーストーリーを作成する
- Given / When / Then形式で受入基準を書く
- 性能、可用性、セキュリティ、監査ログなどの非機能要件を追加する
要件定義担当におすすめの書籍・資料
| 書籍・資料 | 伸ばせる能力 | 参照URL |
|---|---|---|
| IREB CPRE Foundation Level | 要求工学、要求定義、要求管理 | https://cpre.ireb.org/en/concept/foundationlevel |
| BABOK Guide | ビジネス分析、業務分析 | https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/ |
| Software Requirements, 3rd Edition | 要求開発、要求管理 | https://www.microsoftpressstore.com/store/software-requirements-9780735679665 |
| 要求工学知識体系 REBOK | 日本の開発現場に近い要求定義 | https://www.kindaikagaku.co.jp/book_list/detail/9784764904040/ |
6. テスターが能力を伸ばす方法
テスターは、単純な手順実行者ではなく、品質リスクを見抜く専門職へ移行していく必要があります。
AIはテストケースを大量に作成できますが、
「そのテストで本当に重要なリスクを確認できているか」は人間が判断する必要があります。
特に、探索的テスト、リスクベーステスト、AI生成テストの検証、セキュリティ観点は重要です。
AIが出したテストケースをそのまま採用するのではなく、
業務影響、権限、データ整合性、例外処理、監査ログまで確認する必要があります。
テスター向けの実践課題
- AIにテストケースを作らせる
- 自分で不足している観点を追加する
- リスクマトリクスを作成する
- 探索的テストチャーターを作成する
- バグ報告テンプレートを整備する
テスターにおすすめの書籍・資料
| 書籍・資料 | 伸ばせる能力 | 参照URL |
|---|---|---|
| ISTQB Certified Tester Foundation Level v4.0 | ソフトウェアテストの基礎体系 | https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/ |
| JSTQB Foundation Level シラバス | 日本語で学べるテスト標準 | https://jstqb.jp/syllabus.html |
| The Art of Software Testing | テストの基本思想 | https://dl.acm.org/doi/10.5555/2161638 |
| ソフトウェアテスト技法ドリル 第2版 | テスト設計、実践演習 | https://www.juse-p.co.jp/products/view/934 |
| SQuBOK Guide V3 | ソフトウェア品質体系 | https://www.juse.or.jp/sqip/squbok/ |
7. PM/PLが能力を伸ばす方法
PM/PLは、AI時代に「進捗管理者」だけでは足りません。
AIをどの工程で使うのか、どこから人間のレビューを必須にするのか、
どの品質ゲートを通過しなければリリースできないのかを設計する必要があります。
AI開発を安全に運用するには、AI利用ルール、Definition of Done、レビュー基準、RACI表、
コスト管理表、監査ログ設計が必要になります。
PM/PL向けの実践課題
- AI利用ポリシーを作成する
- AI生成物のレビュー基準を定義する
- Definition of Doneを整備する
- 品質ゲートを設計する
- AI利用料、レビュー工数、手戻り工数を管理する
PM/PLにおすすめの書籍・資料
| 書籍・資料 | 伸ばせる能力 | 参照URL |
|---|---|---|
| PMBOK Guide | プロジェクトマネジメント体系 | https://www.pmi.org/standards/pmbok |
| Scrum Guide | アジャイル開発、スクラム運営 | https://scrumguides.org/ |
| Accelerate | DevOps、DORA指標、開発生産性 | https://itrevolution.com/product/accelerate/ |
| Continuous Delivery | CI/CD、リリース品質 | https://martinfowler.com/books/continuousDelivery.html |
| Team Topologies | チーム設計、認知負荷、組織設計 | https://teamtopologies.com/book |
8. 情シス・発注者が能力を伸ばす方法
情シスや発注者は、AI時代に非常に重要な立場になります。
なぜなら、AIを活用した開発では、ベンダーがどのAIを使い、
どの情報を入力し、どの成果物をAIで作成し、誰が検証したのかを確認する必要があるからです。
特に、AI利用条件、機密情報の取り扱い、生成コードの責任範囲、著作権・ライセンス確認、
セキュリティ要求、監査証跡は、発注側が理解しておくべき領域です。
情シス・発注者向けの実践課題
- AI利用条件付きRFPを作成する
- 納品物チェックリストを整備する
- セキュリティ要求一覧を作成する
- データ管理台帳を作る
- AI利用の監査証跡テンプレートを作る
情シス・発注者におすすめの書籍・資料
| 書籍・資料 | 伸ばせる能力 | 参照URL |
|---|---|---|
| NIST Cybersecurity Framework 2.0 | サイバーリスク管理 | https://www.nist.gov/cyberframework |
| NIST AI Risk Management Framework | AIリスク管理 | https://www.nist.gov/itl/ai-risk-management-framework |
| OWASP Top 10 for LLM Applications | 生成AI特有のセキュリティリスク | https://owasp.org/www-project-top-10-for-large-language-model-applications/ |
| DAMA-DMBOK | データ管理、データガバナンス | https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/ |
| 個人情報保護委員会 | 個人情報保護、法令確認 | https://www.ppc.go.jp/ |
9. 年代を問わず使える学習ロードマップ
AI時代の学び直しに、年齢は大きな制約ではありません。
むしろ、業務経験、失敗経験、調整経験、品質へのこだわりがある人ほど、
AIを実務に活かしやすい可能性があります。
重要なのは、書籍や公式資料を読むだけで終わらせず、
実際に成果物を作り、AIや人間からレビューを受け、改善することです。
学習ステップ
| 段階 | やること | 成果物 |
|---|---|---|
| 第1段階 | 公式標準を確認する | 学習テーマ一覧、参照URLリスト |
| 第2段階 | 書籍で体系を学ぶ | 読書メモ、用語集、チェックリスト |
| 第3段階 | AIを使って成果物を作る | 要件定義書、テスト観点表、レビュー記録 |
| 第4段階 | AIと人間のレビューを受ける | 改善履歴、指摘一覧、再レビュー結果 |
| 第5段階 | 小さく業務に適用する | 社内テンプレート、運用ルール、事例メモ |
10. 90日間の実践プラン
| 人材タイプ | 1〜30日 | 31〜60日 | 61〜90日 |
|---|---|---|---|
| 開発者 | AIで小さな修正を行い、差分レビューする | テスト追加、リファクタリング、脆弱性修正を試す | AI利用時のレビュー観点表を作る |
| 要件定義担当 | 身近な業務を業務フローに分解する | ユーザーストーリーと受入基準を作る | 非機能要件とデータ定義を追加する |
| テスター | ISTQB/JSTQBの基本用語を押さえる | AI生成テストケースをレビューする | リスクベーステスト表と探索的テストチャーターを作る |
| PM/PL | AI利用工程と禁止事項を整理する | 品質ゲートとDefinition of Doneを作る | コスト管理表と監査ログ設計を作る |
| 情シス・発注者 | AI利用条件と機密情報の扱いを整理する | RFPと納品物チェックリストを作る | ベンダー比較表と監査証跡テンプレートを作る |
11. まとめ：AI時代に強いのは、AIを疑いながら使える人
AI時代に強い人材とは、単にAIツールを使える人ではありません。
AIに何を任せ、何を任せてはいけないかを判断できる人です。
開発者であれば、AI生成コードをレビューできること。
要件定義担当であれば、AIが迷わない要求へ落とし込めること。
テスターであれば、AIが見落とすリスクを発見できること。
PM/PLであれば、AI活用を前提に品質と責任を設計できること。
情シス・発注者であれば、AI利用条件、契約、監査、データ管理を判断できること。
これらが今後の実務価値になります。
実装だけをAIに任せる時代になるほど、
人間には「要件」「品質」「責任」「説明」の力が求められます。
逆に言えば、これらを鍛えれば、年代を問わずAI時代でも十分に価値を発揮できます。
最後に押さえておきたいのは、AIは万能の代替者ではなく、使い方によって成果を増幅する道具だという点です。
良い要件、良い設計、良いテスト、良いレビューがあってこそ、AIは力を発揮します。
そこを整える人材こそ、これからの現場で最も頼りにされる存在になるはずです。