最近、チームメンバーへの依頼がほぼゼロになった。仕事が減ったわけじゃない。むしろ逆で、なかなか興味深い状況になっている。
私の今の開発フロー
正直に言うと、今の私の開発における人との協働は、ほぼない。
代わりに、こんなサイクルで物事が動いている。
設計依頼 → 設計レビュー → 実装依頼 → PRレビュー → 動作確認 → マージ
全部AIが相手になっている。
設計はAIに叩き台を出してもらう。それをレビューして方向性を確認し、実装はそのまま依頼する。上がってきたPRを見てマージ判断して、動作確認をして、問題なければマージ。
以前なら「◯◯さん、この設計どう思う？」「実装お願いできる？」とチームに投げていたことが、全部このサイクルに収まるようになった。
何が変わったのか
QCDという言葉がある。Quality（品質）・Cost（コスト）・Delivery（納期）。システム開発における永遠のトレードオフとして語られてきた概念。
速くしたければ品質を犠牲に。品質を上げようとすればコストがかかる。安くすれば納期が延びる——それが「常識」だった。
この常識が、今の私の現場では成立しなくなっている。
AIを使ってからというもの、品質は落ちていない。むしろ設計の一貫性は上がった。コストは明らかに下がった。納期も早くなった。QCDが全部、同じ方向に動いている感覚がある。
最初は自分でも信じられなかったけれど、今は実感として腹に落ちてきている。
「任せる」ではなく「チェックし続ける」
ただし、AIに「いい感じにやっておいて」は通じない。
これが人間との最大の違いだと感じている。優秀なメンバーなら、多少ふわっとした依頼でも文脈を読んで補完してくれる。AIはそれが苦手で、補完はしてくれるのだが、その補完が正しいとは限らない。放置すると、気づかないうちに想定外の方向に走り出してしまう。
だから私がやっているのは、一言で言えば道筋を示してチェックし続けることになる。
PRレビューで見ているのは、具体的にはこの4点。
- アーキテクチャのルールに準拠しているか
- やるべき内容が、適切なレイヤーで、適切な単位で設計・実装されているか
- 単一責務の原則に準拠しているか
- 過剰な変更を加えていないか
コードの1行1行を追うというより、構造として正しいかを見ている感じ。枠組みとして逸脱していなければ、細部はAIを信頼する。枠組みがズレていたら、そこで止める。
従来の「コードレビュー」とはやや違う感覚で、人間メンバーのPRをレビューするときに近いが、速度が桁違いに速いので、判断の連打になっている。
これって、マイクロマネジメントかもしれない
振り返ると、私がやっていることはマイクロマネジメントに近い気がしている。
マイクロマネジメントは、人間相手には悪手とされてきた。細かく口を出すことでメンバーの自律性を損ない、モチベーションを下げる。だから「任せる」「権限を委譲する」が美徳とされてきた。
でも、AIにはこの話が当てはまらない。
AIはモチベーションを持たないし、細かく指示されても傷つかない。むしろ、細かく指示されるほど、アウトプットの質が上がる。設計の意図を明確に伝えるほど実装が意図に近づき、レビューで軌道修正するほど次の出力がよくなっていく。
人間のチームで「悪手」とされてきたマネジメントスタイルが、AIチームでは「正解」に変わる。この逆転が、なかなか面白いと感じている。
ただし、前提がある
このやり方が機能するには、一つ条件がある。
自分が、タスクの詳細を理解していること。
設計依頼をかけるとき、私はすでにある程度の答えを持っている。「こういう構造にすべきでは」という仮説がある。AIの設計案はその仮説を検証するものとして受け取り、ズレていれば修正を指示する。
PRレビューで「アーキテクチャのルールに準拠しているか」を見るためには、そのルールを自分が理解していないといけない。「単一責務の原則」に照らすためには、その概念を自分の言葉で説明できる必要がある。
つまり、AIをうまく使えるかどうかは、自分の技術的な理解の深さに、ほぼ比例する。
「AIがあれば実力は関係ない」という話を聞くことがあるけれど、実際は逆で、AIを使いこなすほど、自分の理解の解像度がアウトプットに直結してくる。わかっていない領域は、指示できないし、レビューもできない。
ではどうするのか
少し具体的な話をすると。
まず、「なぜ」を問い続ける習慣。 設計の選択肢を前にしたとき、「なぜこの構造なのか」「なぜこのレイヤーなのか」を自分に問う。AIに投げる前に、自分の中に仮説を持っておく。これがないと、AIの出力を評価しにくくなる。
次に、AIとの差分を意識する。 AIが出した設計や実装を「そのまま正解」にしない。「自分ならどうするか」を常に比較してみる。差分があるとき、どちらが正しいかを考える。この往復が、スキルを磨くことにつながっている気がしている。
そして、言語化する習慣を持つ。 AIへの指示は、設計書であり仕様書でもある。うまく指示できないということは、自分が理解できていないサインでもある。「ちゃんと伝えられるか」を、自分の理解度のバロメーターとして使えると便利。
業務委託のエンジニアへの影響
少しシビアな話もしておきたい。
今の私のワークフローには、人間への依頼がほぼない。以前なら業務委託のエンジニアに頼んでいた実装タスクが、今はAIに流れている。
正社員はすぐには切れない。組織のルールがある。でも業務委託の場合、契約更新のタイミングで、静かに依頼が来なくなることがある。ドラマチックな「クビ」ではなく、フェードアウトという形で。
これは私が実際に見ている変化で、決して他人事じゃないと感じている。
ただ、これはエンジニアの終わりじゃないとも思っている。「何でも実装できる人」の需要が下がり、「何を作るか判断できる人」の需要が上がっている、という変化として捉えると少し見え方が変わってくる。
AIが書いたコードを適切に評価できる人。設計の意図を言語化できる人。アーキテクチャのルールを持ち、それへの準拠を判断できる人。
そういうエンジニアは、AIと競合するのではなく、AIを動かす側に回れる。
結局、地力がものをいう
私のワークフローは、一見するとラクに見えるかもしれない。AIに指示して、チェックするだけ、という感じに。
でも実態は、判断の連打になっている。設計の方向性は正しいか。実装は設計通りか。変更範囲は適切か。動作は意図通りか。
この判断を高速・高精度で下すためには、技術的な地力が要る。アーキテクチャへの理解、設計原則の体得、ドメインへの精通。これらは、AIが代わりに持ってくれるものではない。
AI時代に求められるエンジニアの条件は、案外シンプルかもしれない。
ちゃんと理解していること。それを言語化できること。
近道はないけれど、やることは変わらない。
AIが当たり前になった今、「技術を知っている」ことの価値は下がっていない。むしろ、それを持っている人が「使う側」に回れる——そういう時代になってきた、と感じている。