職業単位ではなくタスク単位で見る理由
見出しは職業が生き残るかを問います。研究はもっと役立つ問いを立てます。その職業の中のどのタスクが、どれほど速く変わるのかという問いです。O*NETはソフトウェア開発を1つの活動ではなく、タスクの束として記述します。コードの作成とテストから、ユーザー要求の分析、システム設計、他チームとの調整まで含まれ、これらのタスクの運命は同じではありません。
実際のAI利用データも同じ方向を示します。AIアシスタントとの実際の会話を分析するAnthropicのEconomic Indexは、ソフトウェア関連タスクを生成AIの最も大きな実利用領域の1つとして一貫して挙げており、その多くは人が関与を続ける補助パターンで、完全な委任ではありません。したがって開発者にとっての実質的な問いは、AIとコード生成の速さを競うことではなく、1週間のどの部分を任せ、どの部分を意図的に残すかです。
1週間のどの業務から圧縮されるか
先に圧縮されるタスクには3つの共通点があります。入力が画面上のテキストやコードであること、成果物の構造を検査できること、人がレビューするため間違った初稿のコストが低いことです。定型コードと骨組みの作成、単体テストの生成、コードの説明、一次ドキュメント、フレームワークや言語間の移行の下書き、日常的なデバッグ提案がこれに当たります。
圧縮は消滅ではありません。生成されたテスト一式にも、何をテストする価値があるかを決める人が必要です。移行の下書きにも、旧システムの隠れた前提と新システムの制約の両方を理解する人が必要です。消えるのは主に中間のタイピング時間であり、両端の責任ではありません。
人に集中していく業務
下書きが安くなるほど、3種類の開発業務の相対的な価値が上がります。1つ目は設計です。境界、データモデル、障害モードの選択は、誤れば数か月を失い、1つのプロンプトに全文脈は収まりません。2つ目は検証です。微妙なバグ、安全でないデフォルト、ライセンス問題、性能の崖を本番より先に見つけられる深さでAIの出力を読む力です。3つ目は責任です。システムがなぜそう動くのかを説明でき、そう動かないときに答えを出す人になることです。
BLSの職業データも、ソフトウェア開発をタイピングの速さではなく、要求分析、設計、構築、保守というより大きなループとして記述しています。AIを積極的に導入したチームほど、開発者の時間をレビュー、統合、信頼性へ移す傾向があり、エンジニアリング判断の必要性そのものは減っていません。
現実的な90日プラン
最初の1か月は自分の1週間を計測します。下書き、レビュー、意思決定にそれぞれおおよそ何時間使っているかを記録します。テスト生成のような反復タスク1つにAI補助を導入し、出力は必ず1行ずつレビューして、ツールが依存ではなく読む力を鍛えるようにします。
2か月目は、自分が関わるシステムを1つ選び、誰も記録しなかったトレードオフまで含めて設計を文章化します。自分がすべて設計したわけではないシステムを説明する力こそ、検証業務が求める力です。3か月目は、障害件数やレビュー所要時間といった本番品質の指標を1つ引き受け、AIを組み込んで改善します。次の面接では、ツールの一覧より品質改善の前後の物語のほうがはるかに強いのです。
