ルールもナレッジも、
人と AI が
同じものを読む。

何を作るかを決め、境界を設計し、出てきたものを判断する仕事が増えます。手を動かす量は減りますが、決める量は増えます。ルールや手順書を書くことも、仕事のうちです。

いいえ。前に挙げたツールを、場面に応じて使い分けてきました。ルールと手順書はツールから独立した形で持っているので、道具は自分で選べます。新しく良いものが出れば、そちらへ移ります。

そのうえで、開発に生かせそうなサービスやツールは、まず試せるように環境と予算を用意しています。人数が少ないぶん、1人あたりの効率がそのまま成果に効くからです。費用対効果はもちろん問われますが、「高そうだから試さない」で止まらないようにしたい —— というのが基本のスタンスです。

これまでの経験や強みに応じて、フロントエンド寄り・バックエンド寄りといった主な守備範囲はあります。ただ、そこで線を引いて終わりにはしません。

AIを介してお互いの領域に踏み込み、メンバーに確認しながらカバーし合う形で進めています。守備範囲の外側を触るときの敷居が、以前よりずっと低くなった —— これが体制として一番変わったところです。一人で全部を抱える形ではありません。

少人数でも、誰か1人が抜けた瞬間に手が止まるということは起きにくくなりました。やり方と判断の基準がリポジトリに書いてあり、AIエージェントがそれを読んで動くので、引き継ぎにかかる手間が小さいからです。もちろん、記録で引き継げるのは手順と判断の基準までです。その人が積み上げてきた勘どころまでは代われません。少ない人数でカバーし合うためにAIを使っている、という面もあります。

PRを出す前に複数の観点で自己レビューし、型・テスト・lintを通してからpushします。破ってはいけない約束は自動テストで検出します。最後に人がレビューして本番へ出す流れは変えていません。

ツールに詳しいかどうかは関係ありません。ただし、仕事が簡単になるという意味ではありません。

求められるのは、目の前にどんな課題があり、そのどこをAIに任せられるのかを検証しながら見極めていく力です。AIの使い方には、まだ定石と呼べるものがありません。だから、自分で試し、確かめ、判断し続ける必要があります。求められていることを言語化し、それがコードの上でどう実現されているかを照らし合わせ、まだ言葉になっていない部分を見つける —— その作業そのものが仕事になります。

一方で、問いをどう立て、どう解決へ持っていくかを考える部分は、AIが当たり前になる前から何も変わっていません。コードを書く量は減りましたが、設計する力も、問題を解きほぐす力も、むしろ以前より要ります。前に出したグラフで量が増えたのは、人のやることが減ったからではありません。一人が扱える範囲が広がったからだと考えています。

あります。まず、顧客の元へ直接届く操作と、本番への反映は人が判断します。規約として明文化し、破られていないかを自動テストで検出し、開発中は外部への書き込みそのものを遮断する —— この3つで守っています。

もうひとつ、そもそも任せていない領域があります。どうすれば飲食店の売上が上がるのか、現場のオペレーションが楽になるのか —— それを考え、試し、仕組みに落としていく部分です。AIがどれだけ進化しても、現場に人が関わり続けるかぎり課題は新しく生まれます。そのときどきの最適を選ぶのは、人の仕事です。