AI時代、エンジニアは「実装しました」だけでは弱い——スキルシートに書く5つの実績
AI時代のエンジニアは、何を実績として残せばよいのか。
生成AIでコードを書けても、「実装しました」だけでは役割が伝わりにくい。
同じ「実装」でも、一行ずつ書いたのか、AIに任せたのかで、担った役割はまるで違う。
約500人のスキルシートを見てきた立場から、AIを使った開発経験を評価につなげる5つの実績を整理する。
この記事は AI時代、エンジニアは「実装しました」だけでは弱い——スキルシートに書く5つの実績 のダイジェスト版です。
各実績のBefore/Afterや「自分の実績と呼べる境界線」の詳細は、上記の完全版をどうぞ。
AI時代は「実装しました」だけでは役割が伝わらない
以前は、コードを書けること自体に大きな価値があった。
だが、コードを出力する作業の一部は、生成AIに任せられるようになった。
その結果、「実装しました」という言葉の意味が曖昧になった。
- 自分で一行ずつ書いたのか
- AIが出力したコードを貼り付けたのか
- 設計から検証までAIへ任せたのか
- 人間が全体を管理し、一部の作業にAIを使ったのか
同じ「実装」でも、エンジニアが担った役割は異なる。
だからこそ、これからのスキルシートでは、実装した事実だけでは足りない。
その実装において、何を考え、何を決めたのか。
どの範囲に責任を持ったのか。
そこまで書く必要がある。
そして「ChatGPTを使用して開発を効率化」「AIコーディングツールを活用」といった書き方では、評価につながりにくい。
これらの記述から分かるのは、ツールを使ったという事実だけだからだ。
AI時代に評価されるのは、AIを使った人ではない。AIを使った成果に責任を持てる人だ。
その責任の中身を、5つの実績に分けて書く。
実績1：何を作るべきか決めた実績
生成AIは、指示されたものを高速で作れる。
しかし、何を作るべきかまで、常に正しく決められるわけではない。
利用者が困っていることは何か。
今回の開発で解決すべき範囲はどこまでか。
反対に、作らなくてよい機能は何か。
こうした判断には、業務理解と優先順位の整理が必要になる。
| Before | After | |
|---|---|---|
| 記載 | 生成AIを活用して、管理画面の機能を実装 | 利用部門へのヒアリングから月次集計作業の負担を特定。必要機能をCSV取込・エラー確認・集計結果出力の3点に絞り、生成AIを活用して管理画面を実装 |
後者では、コードを書く前の仕事が見える。
誰の、どの問題を、どの機能で解決したか。
なぜ、その範囲に絞ったのか。
この判断が、AIだけでは代替しにくい実績になる。
実績2：AIへ任せる仕事を分解した実績
AIへ「この機能を作って」と伝えるだけでは、安定した成果は得にくい。
実務では、大きな仕事を小さな単位へ分解する必要がある。
既存仕様の調査、変更箇所の特定、実装方針の比較、コードの修正、テストと影響確認。
これらを一度に任せるのか、順番に進めるのか、人間が担当する部分をどこに残すのか。
仕事の分け方によって、AIの出力品質は変わる。
これは、プロンプトの小技だけの話ではない。
部下や外部パートナーへ仕事を依頼するときにも必要な、業務設計の能力だ。
「開発タスクを調査・設計・実装・検証に分解。生成AIへ任せる工程と人間が確認する工程を定義し、手戻りを抑えながら開発を進行」
期間や工数を計測していれば、その変化も加えたい。
「従来3日を要していた改修を1日に短縮」「レビュー前の指摘件数を平均8件から3件へ削減」。
具体的な数字があれば、AI活用が自己申告ではなく実績になる。
実績3：AIの出力を疑い、検証した実績
生成AIは、自信のある文章で誤った回答を返すことがある。
コードが動いているように見えても、問題がないとは限らない。
特定の入力でエラーになる。
既存機能を壊している。
認証や権限の確認が不足している。
そのため、AI時代には**「作れる能力」と同じくらい「疑える能力」が重要**になる。
何をもって完成とするのか。
どの部分に事故の可能性があるのか。
影響範囲をどこまで調べるのか。
この判断は、人間側に残る。
「生成AIによる実装後、認証・権限・異常系・既存機能への影響を確認。テストケースを追加し、リリース前に権限判定の不備を検出」
この書き方なら、品質に責任を持ったことが分かる。
AIの間違いを見つけた経験は、隠すべき失敗ではない。AIを実務で扱えることを示す実績になる。
実績4：AIの作業を疑い、中断・見直した実績
ここまでは、AIの出力を疑う話だった。
しかし、疑うべき対象はもう一つある。
出力そのものではなく、作業の進め方だ。
この4つ目が、他ではあまり語られない独自の視点になる。
AIツールと長期の開発を進めるなかで、進め方そのものを疑い、何度も中断して見直した経験がある。
AIツールが、何もしていなかったわけではない。
設計を整理し、変更前の条件を確認し、セルフレビューを行い、指摘を修正し、証跡も残していた。
個々の作業だけを見れば、どれも間違いではなかった。
問題は、安全性を重視するあまり、作業が細かく分割されすぎたことだ。
一つの確認が終わると、次の確認条件を定義する。
その条件をレビューし、指摘を修正する。
修正後の状態を記録し、さらに次の実行条件を作る。
安全性は高まっていた。
しかし、プロジェクトが終わる速度は落ちていた。
これは、AIが誤ったコードを書いた事例ではない。
局所的には正しい作業を積み重ねながらも、知らず知らずのうちにプロジェクト全体の目的から離れかけた事例だ。
AIツールは、与えられた評価基準に対して忠実に動く。
安全性を重視するよう指示すれば、考えられる危険を洗い出す。
レビューを徹底するよう指示すれば、追加の確認項目を提示する。
しかし、それらをどこまで行えば十分なのかは、技術的な正しさだけでは決められない。
現在のサービス規模に合っているか。
追加確認による安全性は、時間と労力に見合うか。
こうした判断には、プロジェクトの目的と事情が必要になる。
AIの作業がもっともらしく見えても、そのまま任せてよいのかを疑う。
本来の目的から外れていれば、作業を中断し、進め方を見直して適切な方向へ戻す。
「安全性を重視した開発工程が細分化していることを発見。作業を一時中断し、サービス規模とリスクに合わせてレビュー工程を再設計。必要な確認を維持しながら、実際の適用までの進行を改善」
AIの作業をどのような根拠で疑ったか。
どの時点で中断したか。
何を見直し、どう再開したか。
その一連の意思決定に、人間の実績が残る。
▶ 各実績のBefore/Afterや「自分の実績と呼べる境界線」の詳細はこちら → AI時代、エンジニアは「実装しました」だけでは弱い
実績5：AI活用の結果を数字で説明した実績
AIを使ったことより、結果として何が変わったかが重要だ。
開発期間が短くなった。
調査時間が減った。
一人で担当できる範囲が増えた。
こうした変化が、評価の対象になる。
BeforeとAfterを並べると伝わりやすい。
| 内容 | |
|---|---|
| Before | 仕様調査と影響範囲の確認に、毎回4時間かかっていた |
| After | AIによるコード調査と人間による確認を組み合わせ、平均1.5時間へ短縮 |
さらに、こう書ける。
「生成AIを導入し、テストコード作成時間を1機能あたり2時間から30分へ短縮。削減した時間を異常系と回帰テストの追加に充て、検証範囲を拡大」。
この例では、時間短縮だけで終わっていない。
浮いた時間を品質向上へ使ったことまで説明できている。
ただし、数字を作ってはいけない。
計測していなければ、「約」「従来比」などを使い、説明できる範囲で書くべきだ。
AIで作った成果を「自分の実績」と呼べる境界線
AIが作ったものを、自分の実績として書いてよいのか。
この問いに、道具を使ったかどうかだけで答えることはできない。
IDEの補完機能やフレームワークを使っても、成果物はエンジニアの実績として扱われる。
重要なのは、成果に対してどこまで説明と責任を持てるかだ。
- なぜ、その方法を選んだのか
- AIへ何を任せたのか
- 出力をどのように確認したのか
- 問題が起きたら、どこから調査するのか
- 同じ成果を再現する手順を説明できるか
これらを説明できるなら、AIを使った成果も自分の実績として書ける。
反対に、生成されたコードの内容を理解していない場合は注意が必要だ。
問題が起きても修正できないなら、自分の実力として強く主張すべきではない。
面談では、ツール名よりも、その後の質問で差が出る。
「なぜ、その設計にしたのですか」「AIの出力に問題はありませんでしたか」「もう一度作るなら、何を変えますか」。
この質問に答えられる状態まで含めて、AI活用経験だ。
AI時代の実績を残すために、作業中から記録する
スキルシートを書く段階で、数カ月前の判断を思い出すのは難しい。
そのため、AIを使った作業では、完成した機能だけでなく、途中の判断も記録しておきたい。
最低限、次の5項目を残す。
- 解決しようとした問題
- AIへ任せた作業と人間が担当した作業
- AIの出力で見つけた問題
- 中断・見直しを判断した理由
- 時間・品質・件数などの変化
長い報告書を作る必要はない。
案件ごとに数行のメモを残すだけでもよい。
この記録があれば、後からスキルシートへ転記しやすく、面談で深掘りされても自分の判断を説明できる。
Skillsheet-Port なら、各案件を担当工程・期間・技術ごとにフォームへ入力していくので、判断のメモも記憶が新しいうちに積める。
AI構成補助を使えば、「この判断、どう書けば伝わるか」を壁打ちできる。
途中の判断は、その場では地味だ。しかし記録して言語化すれば、AI時代にいちばん替えのきかない実績になる。
まとめ
- AI時代は「実装しました」だけでは役割が伝わらない。評価される場所が実装量から意思決定へ広がっている
- 書くべき5つの実績：①何を作るか決めた ②AIへ任せる仕事を分解した ③AIの出力を疑い検証した ④AIの作業を疑い中断・見直した ⑤結果を数字で説明した
- 特に④は独自。局所的に正しい作業でも、目的から外れれば止める判断が実績になる
- 自分の実績と呼べる境界は**「説明と責任を持てるか」**。ツールを使ったかどうかではない
- 途中の判断は、作業中に数行のメモで記録する
AIがコードを書ける時代だからこそ、スキルシートには人間が考え、決めたことを書く必要がある。
次の案件では、完成した機能だけでなく、その過程で自分が下した判断も残しておいてほしい。
▶ 完全版ガイドはこちら → AI時代、エンジニアは「実装しました」だけでは弱い
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/