株式会社Good Labでエンジニアをしているコータローです。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。

Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト

はじめに

コードはAIが書ける時代になりました。

設計書のたたき台も、テストコードも、調査のまとめも、指示を出せば返ってきます。実装スピードで差をつけるのは、以前よりずっと難しくなりました。

では、現場で評価されるのは何なのか。

私は今の現場で、設計・開発・単体テストを担当しています。配属から半年ほど経ちましたが、評価につながったのは 実装が速いことではありませんでした。

決まっていないことに気づいて、それを人に投げたことでした。

この記事はその話です。技術の解説ではなく、現場での立ち回りの話になります。

前提：どんな現場か

システム間のデータ連携を担当しています。

【送る側】
連携用のファイルを入力 → 変換・加工 → 相手システムへ渡す

【受け取る側】
相手システムからファイルを受領 → 変換・加工 → DBへ取り込む

加工の部分は、画面上でフローを組み立てるタイプのツールを使っています。ゼロからコードを書く量は多くありません。

つまり 「実装が難しくて手が止まる」タイプの現場ではない、ということです。

ではどこで詰まるのか。

この現場の本質：仕様が決まっていない

詰まるのは、ほぼ全部ここでした。

どのパターンでどの処理を行うのか（例外系はどうするのか）
データをどう加工するのか（桁・形式・区切り・null の扱い）
相手システムへどう渡すのが最適なのか

決まっていないんです。 設計書を開いて手を動かそうとすると、書いていないことに突き当たる。

最初は「自分の理解が足りないから分からないんだ」と思っていました。違いました。本当に決まっていなかったのです。

なぜ決まらないのか

システム間連携には構造的な理由があります。相手がいるからです。

自分のシステムの中だけで完結する処理なら、設計者が決めれば終わります。しかしデータを相手システムへ渡す場合、「どう渡すのが最適か」は相手の受け取り方に依存します。相手の都合を確認しないと決められない。

だから決まらないまま残るし、放置されたまま実装フェーズに入ってくる。

これは特殊な現場の話ではないと思います。連携・移行・外部APIが絡む案件なら、どこでも起きているはずです。

評価された3つの行動

① 決まっていないことを見つけて、言語化する

いちばん効いたのはこれです。

実装していると「これ、どっちの挙動が正しいんだ？」という箇所に必ず当たります。そこで止まらず、何が決まっていないのかを文章にする。

実際に投げたQAを例に出します。テーマは桁の扱いでした。

悪い：「この項目、桁はどう扱えばいいですか？」

良い：「◯◯コードの桁の扱いについて3点確認させてください。

       (1) 桁揃えをするか（固定長）／しないか（可変長）
       (2) 桁揃えをする場合、埋める文字は半角スペースか、
           0などの固定文字か
       (3) 元の値に前後の空白が含まれる場合、
           除去して渡すか、そのまま渡すか

       設計書に記載がなく、貴システム側での受け取り方に
       依存するため、ご確認いただけますでしょうか」

ひとつの質問に見えて、論点は3つ入れ子になっています。 「桁を揃えるか」だけ決めても、埋める文字が決まっていなければ実装できません。空白の除去も、聞かなければ誰も触れないまま実装フェーズを通過します。

このケースは最終的に 「空白を除去して渡す」 で決まりました。

大事なのは、これが自分では決められない論点だったことです。空白を残したまま渡すと相手システム側の突合が落ちる可能性があり、正解は相手の実装に依存します。だから聞くしかない。そして聞かなければ、動かしてみて初めて発覚します。

下の形にすると、聞かれた側は選ぶだけで済みます。上の形だと、聞かれた側が状況を調べ直すところから始めなければならない。この差が、そのまま「話が早い人かどうか」の評価になります。

② 外に投げて、中に展開する

先ほどの桁の件は、相手システム側の担当者に投げて、決まった内容をチーム内に展開するという流れで進めました。ここが2段になっているのが重要だと思っています。

① 相手システム側の担当者へ質問を投げる（自分たちでは決められないので）
        ↓
② 回答が来る（「空白は除去して渡してほしい」）
        ↓
③ 決まった内容をチーム内に展開する

②で止めてしまうと、自分の担当箇所だけが正しくなります。でも同じ論点は他の人の担当箇所でも起きている。桁や空白の扱いは、ファイルが違っても同じ判断が必要になるからです。

だから「みんな気づいていないけど、ここ決めないといけないですよね」という内容を、チャットに流すようにしていました。

自分の担当外でも、影響しそうな論点は共有する
QAは投げっぱなしにせず、決まった内容まで共有する
「たぶんこうだと思う」で進めず、決定として残す

これをやると、自分ひとりの作業速度を超えたところで貢献できます。 一度共有すれば、5人分の手戻りが消えることがあるからです。

③ そのうえで成果物の量を出す

①②だけだと「よく質問する人」で終わります。量も評価対象でした。

ただ、量が出た理由は①②のおかげだと思っています。仕様の穴を先に潰しておけば手戻りが起きない。確認しないまま進めて後から作り直すほうが、トータルでは圧倒的に遅い。

先に決めるから速く作れる。順番はこっちでした。

評価は言葉より先にタスクの難易度に出た

ここで正直に書いておきたいことがあります。

「よくやってるね」と直接言われたことはありません。

代わりに、こう変わりました。

自分の所属とは別の会社のリーダーから、仕様の相談が先に来るようになった
チーム内で難易度の高いタスクを任されるようになった

「評価されている」と分かったのは、任されるものの難易度が変わったからです。言葉ではなく、割り振られるタスクで分かりました。

これは逆に言うと、褒められていないからといって評価されていないわけではないということです。自分に来る仕事の難易度が上がっているなら、それは評価の結果だと思っていいはずです。

そして相談が来る相手が自社の上司ではなく別の会社のリーダーだったのが、個人的には大きかったです。所属を超えて聞かれるのは、立場ではなく中身で判断されている証拠なので。

なぜこれがAI時代に効くのか

ここからが本題です。

AIは決まっている仕様を実装するのが非常に得意です。「この形式のファイルをこう変換して出力する」と決まっていれば、かなりの精度で書けます。

一方で、AIは**「この仕様には穴がある」と気づいてくれません。** 正確に言えば、聞けば指摘はしてくれます。しかし「そもそも何を聞くべきか」は、現場の文脈を持っている人しか分からない。

AIが得意：決まったことを速く正確に作る
人が必要：まだ決まっていないことを見つけて、決めに行く

実装力の価値が下がったわけではありません。ただ実装の前段で詰まる量のほうが、相対的に大きくなった。そこを動かせる人が評価される、というだけの話だと思います。

私自身、記事を書くのもコードを書くのもAIを使っています。使ってみて分かったのは、AIに投げる前の「何を作るか決める」工程がボトルネックになるということでした。現場でも同じ構造でした。

明日からできること

大げさな準備は要りません。実際にやっていたのはこれだけです。

手が止まったとき、止まった理由を言葉にする —— 「分からない」ではなく「何が決まっていないのか」まで分解する
質問は選択肢の形にする —— 相手が選ぶだけで答えられる形にして投げる
気づいた論点は担当外でも流す —— 自分のタスクが終わるかどうかとは別の軸で価値になる
決まったことを書いて残す —— 口頭で決まったまま消えると、同じ議論が2回起きる

特に1が起点です。「分からない」で止まっている時間を「何が決まっていないか」の特定に使うだけで、後の3つは自然につながります。

おわりに

転職前はテスト中心の業務が多く、決まった手順を正確に実行する仕事でした。今の現場では、決まっていないものを決めに行く動きが求められました。

変えたのはスキルではなく振る舞いです。

もし今、実装はできるのに評価が上がらないと感じているなら、詰まっている場所を見直してみてください。実装ではなく、その手前で止まっているかもしれません。そして手前で止まっている問題は、まだAIが解いてくれない領域です。

@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！