AIでコードを書ける人が増えています。
その変化を見て、「エンジニアの仕事は終わる」「これまで積み上げた技術は無駄になる」と考える人もいるでしょう。しかし、この捉え方は少し粗すぎます。
変わるのは、エンジニアという職種そのものよりも、価値が発生する場所です。実装の一部が速くなったからこそ、何を作るか、誰のどんな成果を変えるか、完成と判断する基準は何か、といった設計の比重が高まります。
この記事では、技術を捨てるのではなく、顧客価値と再利用可能な資産へ移すための90日設計を整理します。
「コードが速い」だけでは成果にならない
業務システムの価値は、コードの行数や実装速度だけでは決まりません。
顧客が困っていることを特定する
業務のどこで時間やミスが発生しているか分解する
改善後に何が変われば成功か決める
実装し、テストし、現場で受け入れられるか確かめる
例外や停止条件を決め、運用できる形に残すAIはこの中の下書き、調査、コード生成、テスト案の作成を速くできます。一方で、目的が曖昧なまま実装だけを速くすると、使われない機能や説明できない仕組みが増えるだけです。
技術者が先に移るべきなのは、管理職という肩書きではありません。課題と成果の間を設計する位置です。
3つの移動で専門性を組み替える
1. 機能を作る人から、成果を設計する人へ
最初に作るべきは、機能一覧ではなく課題カードです。
対象者: 誰が使うのか
発生場面: いつ困るのか
現在の手段: いま何をしているのか
損失: 時間、ミス、待ち時間、機会損失のどれか
成功基準: 何がどの数値・状態になればよいか
例外: AIや自動化に任せてはいけない場面は何かこのカードがあれば、AIに「アプリを作って」と頼む前に、作るべきでない部分も見えてきます。エンジニアの経験は、機能を増やすためではなく、問題を小さく切り分けるために使えます。
2. 指示を待つ人から、検証可能な提案を見せる人へ
会社員の場合、担当範囲を越えて勝手に本番変更する必要はありません。ただし、改善案を出すことはできます。
提案は「AIを使えば便利です」では弱いものです。次の順番にすると、相手が判断しやすくなります。
- 現在の作業時間と手戻りを測る
- AIを使う箇所と、人間が確認する箇所を分ける
- 小さなサンプルで処理前後を比較する
- 品質、情報管理、契約上の制約を並べる
- 期間、担当者、停止条件を決めて試す
この形式なら、AI導入に慎重な組織でも「全面導入か、禁止か」の二択を避けられます。提案の価値は、ツール名ではなく、判断できる材料を揃えることにあります。
3. 時間を売る働き方から、運用資産を残す働き方へ
コードを納品して終わりにすると、同じ説明や修正が繰り返されます。再利用できる資産にするには、少なくとも次の要素を一緒に残します。
目的と対象業務
入力データの条件と禁止事項
出力の受け入れ基準
テストケースと失敗例
例外時の人間の判断
停止・ロールバックの手順
更新担当と見直し日これは大規模なマニュアルではありません。次の担当者が、同じ前提で安全に試せる最小単位の記録です。AIを使うほど、この記録の有無が品質差になります。
90日で作る「最初の資産」
いきなり副業や起業に移るのではなく、現在の業務で権利と機密を守りながら、再利用できる成果物を1つ作ります。
1〜30日目：作業と判断を分ける
直近2週間の仕事から、繰り返しが多い作業を10個書き出します。各作業を「転記・分類・下書き・判断・承認・例外対応」に分け、AIに任せたい箇所と任せない箇所を印付けします。
この段階ではツールを増やしません。測る項目は、所要時間、手戻り回数、確認者、入力情報、失敗時の影響です。
31〜60日目：1業務だけ小さく試す
課題カードから1つを選び、テスト用データでAIの下書きや分類を試します。出力をそのまま本番へ流さず、人間の確認を必須にします。
結果は「便利だった」ではなく、処理時間、修正件数、見落とし、確認にかかった時間で記録します。改善しなかった場合も、どの条件で使えないかが資産になります。
61〜90日目：提案と運用パックにする
最後の30日で、実測結果を1枚の提案にまとめます。導入を広げるのではなく、継続・修正・中止のいずれかを判断できる形にするのが目的です。
そのうえで、目的、入力、出力、テスト、例外、停止条件を1つの運用パックにします。将来、別の顧客や別の業務へ応用できるのは、コードそのものより、この判断構造です。
会社員が試すときの境界線
業務で作ったコード、資料、顧客情報、ログ、プロンプト、改善案が誰の資産かは、契約や社内規程によって変わります。会社の許可なく機密情報を個人のAIサービスへ入力したり、勤務先の成果物を副業へ転用したりしてはいけません。
副業や独立を考える場合も、まずは次の3つを分けて記録します。
会社の業務として作ったもの
公開情報だけで作った一般化された知識
自分が個人で新たに作るものAIを使ったこと自体より、データの出所、権利、承認、説明責任を曖昧にすることが危険です。技術者が強みを広げるほど、この境界線を設計できることが信頼になります。
残すべきエンジニアリング能力
AI時代に不要になるのは、エンジニアリングそのものではありません。むしろ次の能力は、AIを使うほど重要になります。
- 要件を分解し、曖昧さを見つける
- 受け入れ基準とテストを作る
- 出力の誤りや抜けを発見する
- 失敗時に安全に戻す
- 運用上の例外と責任者を決める
- 技術上の選択を、顧客や経営の言葉に翻訳する
コードを書く量が減っても、判断の質まで自動で保証されるわけではありません。実装をAIに任せるなら、何をもって完成とするかを人間側が持つ必要があります。
結論：技術を捨てず、価値が発生する場所を移す
AIで実装の入口が広がると、技術者の差はコードを独占しているかどうかではなくなります。
顧客の課題を選び、成果を定義し、小さく提案し、検証し、運用資産として残す。その一連の設計を担える人は、AIによって技術の価値を失うのではなく、技術を別の場所へ広げられます。
最初の一歩は、退職でも新しいツールの契約でもありません。直近の業務から1つを選び、課題カードと受け入れ基準を作ることです。