AIにお願いすれば、動くコードはすぐ出てくる。これは現場の実感として、もう当たり前になりました。

設計の叩き台も、テストコードも、ちょっとしたバッチ処理も、聞けば形になって返ってくる。手を動かす時間は、ここ一年ではっきり短くなりました。エンジニアと話していても、「まずAIに投げてみる」が最初の一手になっている人が増えています。

ただ、最近の現場で私が引っかかっているのは、速くなったこと自体ではありません。コードは速く書けるようになったのに、「なぜこの作りにしたのか」がチームに残りにくくなってきた。動くものはどんどん増えるのに、その理由だけが置いていかれる感覚があります。今日はその話を、創業して一年ほどの開発現場から、できるだけ正直に書いてみます。

AIに聞けば、形はすぐに整う

新しい機能をひとつ足すとき、以前なら参考になる実装を探したり、過去のプロジェクトを思い出したりしながら、自分の頭で少しずつ組み立てていました。今はその前段が一気に縮みます。やりたいことを伝えれば、それらしい構造が返ってくる。動かしてみて、気になるところを直して、また聞く。このやり取りが、とにかく速い。

速いこと自体は、良いことだと思っています。試せる回数が増えるし、調べ物に時間を取られて夕方になっていた、ということが減る。エンジニアが本当に考えるべきところに頭を使えるようになった面は、たしかにあります。私も一人のエンジニアとして、この変化はありがたいと感じています。

問題は、出てきたコードが「動く」ことと、その作りを「説明できる」ことが、まったく別物だという点でした。動くだけなら、理由を分かっていなくてもたどり着けてしまう。ここに、これまでとは違う落とし穴があります。

困ったのは、半年後に誰も説明できなかった時

ある案件で、こういうことがありました。前に書いた処理を別のメンバーが引き継いで直そうとしたとき、「ここ、なんでこの分け方になってるんですか」という質問が出た。書いた本人に聞いても、はっきりした答えが返ってこない。AIに提案された形をベースにして、動いたからそのまま進めた。当時はそれで困らなかったし、レビューも通っていた。

これは誰かを責めたい話ではありません。私自身も同じことを何度もやります。締め切りが近くて、目の前に動くものがあれば、先に進めたくなるのが普通です。一つ一つ「なぜ」を残していく余裕が、いつもあるわけではない。

ただ、半年後にその箇所へ手を入れるとき、そこに判断の記録が何も残っていないと、結局また一から考え直すことになります。前に一度通った道なのに、地図がないからまた迷う。同じ落とし穴を、もう一度踏んでしまうこともある。AIが書いたコードは、見た目がきれいに整っているぶん、「なぜ」が抜けていることに気づきにくい。手で一行ずつ書いていた頃なら、不格好でも自分の足跡が残っていました。ここが、いちばん大きな違いだと感じています。

しかも、この「なぜ」が抜ける現象は、本人にはなかなか自覚できません。書いた直後は、頭の中に文脈が残っているので、説明できるつもりでいる。困るのは時間がたってからで、しかも困るのはたいてい別の人です。だから、書いた本人が困っていないからといって、問題がないわけではない。むしろ、すぐに困らないからこそ、静かにたまっていく種類の負債だと思っています。

設計の意図は、コードの外側にある

動くコードの中には、「どう動くか」は書いてあります。でも「なぜそう作ることにしたか」は、たいていコードの外にあります。

別のやり方もあったけれど、運用する人のことを考えてこちらにした。将来こう広がる可能性があるから、あえて今は単純なままにして、後で手を入れやすくしておいた。この案件の規模だと、ここまで作り込むと過剰になるから、わざと薄くした。こういう判断は、できあがったコードを読むだけでは追えません。書いた人の頭の中にしか、もともと存在しないからです。

手で書いていた頃は、悩んだぶんだけ理由が記憶に残っていました。何時間も詰まって、ようやく決めた構造には、それなりの物語がついてくる。ところがAIに任せる部分が増えると、その「悩んだ時間」そのものが減ります。効率としては良くても、判断の手触りが薄くなる。意識して言葉にしておかないと、意図は本当にどこにも残らなくなる。これはAIが悪いという話ではなく、速くなった結果として自然に起きることだと捉えています。

私たちが、レビューで確かめていること

そこでCodenceの現場では、コードが動くかどうかとは別に、レビューのときに必ず確かめるようにしていることがあります。難しい仕組みではなく、習慣に近いものです。

ひとつは、「なぜこの形にしたのか」を一言でいいから添えてもらうこと。長い設計書はいりません。「運用で監視しやすいからこうした」「ここは変更が多い見込みだから切り離した」くらいの短いメモで十分です。これがあるだけで、引き継ぐ人の理解の速さがまるで変わります。コメント一行が、後の何時間かを助けてくれる。

もうひとつは、「AIに提案されたまま使ったところ」と「自分で考えて変えたところ」を、本人がちゃんと区別できているか。全部を自分で一から組む必要はありません。ただ、どこを任せてどこを自分で決めたのかが分かっていないと、後で問題が出たときに切り分けができなくなる。逆に、その区別がついている人は、トラブルのときに強い。原因にたどり着くのが早いからです。

三つ目は、迷ったときの「捨てた選択肢」も、ひとことだけ残しておくこと。採用した案だけでなく、検討してやめた案を一行書いておく。「最初はこの方法を考えたが、運用の手間が増えそうでやめた」。これがあると、後から見た人が同じ検討をもう一度やらずに済みます。やめた理由が分かれば、無駄な蒸し返しが減る。地味ですが、時間の節約としては大きい。

派手な取り組みではないです。それでも、離れた現場で働くメンバーが多い私たちにとって、この小さな積み重ねが効いてきます。隣の席で気軽に聞ける環境ではないぶん、書いて残すことの価値が大きい。完璧なドキュメントを作ろうとすると続かないので、あくまで一行、二行の負担に収める。続けられる軽さにしておくのが、結局いちばん効くと感じています。

AIを使うほど、言葉にする力が要る

少し意外に思われるかもしれませんが、AIを使う時間が増えるほど、自分の考えを言葉にする力が大事になってきた、というのが今のところの実感です。

AIに的確に頼むには、やりたいことを自分の中で整理しないといけない。ぼんやりした依頼からは、ぼんやりした答えしか返ってきません。返ってきたものが良いか悪いかを判断するにも、自分なりの基準がいる。そして、なぜその結論にしたかをチームに伝えるにも、やはり言葉が要る。コードを書く手間が減ったぶん、考えを説明する場面は、むしろ増えました。

これは、新しく入ってくれた人にも最初に話しています。AIが書いてくれるから楽になる、で終わる話ではない。楽になった時間を、設計をどうするか考えることや、自分の判断を言葉にしておくことに回してほしい。そこができる人は、現場が変わっても、何年たっても必要とされ続けます。逆に、出てきたものをそのまま流すだけだと、AIと自分の境目がだんだん曖昧になっていく。

受託や客先での開発だと、これはさらに効いてきます。自分たちだけで完結する開発と違って、相手に説明する場面が多いからです。「なぜこの作りにしたのか」を聞かれたとき、その場で筋の通った答えを返せるかどうかで、信頼の積み上がり方が変わる。コードが動くのは前提で、その先にある「説明できる力」が、実は現場でいちばん見られているところだったりします。AIが普及して、この傾向はむしろ強まったように感じます。

それでも、任せていい部分はある

誤解されたくないので書いておくと、私はAIを使うこと自体には前向きです。むしろ、もっと使っていいと思っています。ここを我慢する理由はありません。

調べ物や、定型的な実装や、たたき台づくりは、どんどん任せればいい。そこで浮いた時間を、判断が要るところに集中させる。要は、何を任せて何を自分の手元に持っておくか、その線引きの問題だと思っています。線引きさえはっきりしていれば、AIはかなり頼れる相方になります。

線が曖昧なまま全部を任せてしまうと、冒頭の「なぜ誰も説明できないのか」が起きる。かといって、こわがって何も任せないと、今の現場の速さにはついていけない。その間で、ちょうどいいところを自分なりに探していく。そこがこれからのエンジニアの腕の見せどころになる、と私は見ています。正解が一つに決まっていない問いだからこそ、面白いところでもあります。

任せきりの人と、線を引ける人

同じようにAIを使っていても、現場で見ていると、二つのタイプに分かれてくるのが分かります。

一人は、出てきたものをそのまま流していくタイプ。スピードは出ます。最初のうちは、むしろ速く見える。ただ、少し込み入った不具合が出たときに止まってしまう。自分が何を任せて何を決めたのか、線が引けていないから、どこを疑えばいいのか分からなくなる。AIにもう一度聞いても、前提が整理できていないので、堂々巡りになりがちです。

もう一人は、AIを使いながらも、要所で立ち止まるタイプ。ここは任せていい、ここは自分で決める、という線を毎回引いている。最初は前者より遅く見えることもあります。けれど、トラブルになったときの強さが違う。自分で決めた部分をはっきり覚えているから、原因に早くたどり着く。そして、その判断を一言メモに残しているので、次に触る人も助かる。

能力の差というより、習慣の差だと思っています。そして習慣は、後からでも変えられる。だから私は、入ってくれた人にこの線引きの話を、しつこいくらい伝えています。

一年やってみて、思うこと

創業してから一年、小さな組織で開発を続けてきて、はっきり感じることがあります。AIで手が速くなったぶん、人と人の差は「速さ」では出にくくなりました。差が出るのは、判断を残せるかどうか、考えを人に渡せるかどうか、そういう地味なところです。

大きな会社なら、仕組みやドキュメントの文化が、ある程度こうした抜けを補ってくれるのかもしれません。私たちのような規模だと、そこは一人ひとりの習慣に直接かかってきます。だからこそ、レビューで一言添える、自分の判断を区別しておく、といった小さなことを大事にしたい。地味だけれど、これが半年後、一年後のチームの強さを決めると思っています。

最後に

AIがコードを書く時代になっても、いや、なったからこそ、「なぜそう作るか」を考えて言葉にできる人の価値は上がっていく。私はそう見ています。手が速いことよりも、判断を残せること。これは小さなチームほど、はっきり差になって出ます。

もしこういう、設計の意図まで含めて開発を語れるようになりたい、という方がいたら、一度話してみませんか。Codenceでは、積み上げてきた実装経験を、設計を語れる強みに変えていきたいJavaエンジニアの方の募集を出しています。今日の話に少しでも近いものを感じたら、こちらの募集ものぞいてみてください。

Javaエンジニア｜積み上げた経験を、設計を語れる強みに磨きませんか