「あとは実装するだけ」の「あと」には何が残っているのか

こんにちは、事業変革本部でエンジニアをやっているぴやてぃです。普段は目指せアーキテクトとして、プロダクトの実装や設計、レビューを担当しています。

同じチームの人たちと「お客さんの業務を良くするにはこうだよね」「開発のことを考えるとこっちだよね」と議論しながら開発を進めています。

本記事は『真夏のアドカレ事業部編』と題して、Algomaticメンバーそれぞれが自分の事業について語る会の18日目です。

前回の記事はこちら。

note.com

今回は「今の事業部の開発ってどんなことしてるの？」という紹介も兼ねて、AI駆動開発の話をします。以下のテックブログに書いた進め方で実際に開発したところ、レビューする側から見て「これ、事前にやっておけばよかった」と思うことがいくつか出てきました。

tech.algomatic.jp

AI駆動開発で何を作ったか

HR領域のクライアント向けに、以前自分たちで作った業務システムを全面的に刷新しました。

背景は、データの置き場所の統一です。このシステムで使うデータの一部は、これまで別のシステムを正として管理していました。それを同じシステム内で扱えるようにし、ついでに運用上の困っていたところも直そう、というものです。

「ついで」と言いつつ、開発規模は大きいです。もとの業務機能に加えて、新しいデータをまとめて管理するようになるためです。画面は20以上。ステータス遷移、アクティビティ記録、機能間でのデータの相互参照や更新があり、複雑な画面が多いシステムです。

体制は開発3人。メインで実装する2人と、アーキテクトとして設計レビューとコードレビューをやる私が1人です。実装期間は1ヶ月半という、なかなかのスケジュールでした。（AIがなかった頃なら、開発だけで半年くらいかかっていたと思うレベル）

進め方は、テックブログに書いた通りです。要件定義の段階でPdMと要件を確認しながらAIで動くモックを作り、そのモックでフロントの画面と、後ろでデータを管理するDBの仕様まで合意しました。

なので、実装期間に残っていたのはフロントとDBをつなぐAPIを作ることだけ。「あとはAPI実装するだけじゃん」という気持ちでした。

そう思って任せた結果、想定していなかった場所で詰まりました。それが今回の話です。

レビューがボトルネックになった

実装が速くなった結果、レビューと方針調整が追いつかなくなりました。

大きな機能のかたまりが2つあったので、それぞれを作成や更新などの機能単位に分け、AIに並列で実装してもらいました。

並列に実装できるということは、プルリクエストが10や20まとめて上がってくるということでもあります。結果、レビューが間に合わず、私がボトルネックになりました。

最終的には進め方を調整して、開発自体は無事に完了しました。具体的には、共通化はいったん後回しにし、「最初に見ればよかった」という観点をスキルにまとめて、AIにレビューさせたときにその観点が必ず出るようにしました。これで、レビューのたびに見る場所を探す手間が減りました。

では、なぜこうなったのか。この機会に振り返ってみます。

一言で言うと、決めていなかったことがあったからです。フロントもDBも決まっていたので「もう決めることはない」と思っていましたが、本来なら実装者とレビュアーの間で認識を合わせて決めていたことを決めていませんでした。

AIは実装が速いので、決まっていないことをそれぞれの判断で高速に決めていきます。その結果、AI同士の実装に差分が出てその差分がそのままレビュー負荷になっていました。

実装前に決まっていなかったこと

実装の前提は揃っていたつもりでした。要件定義に注力し、モックも作って画面として何を作るかは決めていました。DB設計も決めていましたし、「この機能はこういうものです」という設計の決定記録（ADR）も用意していました。

それでも、モックのフロントとDBからは決まらないものが結構ありました。

• CRUD操作をするAPIがレスポンスとして何を返すか

• コードの層の分け方

• データ取得の方針

• 性能

• インフラ構成

こうやって並べると、実装前に決まっていないことは意外と多かったです。

まずAPIです。更新系のAPIで「更新後の値を返す」実装が生まれました。一般的には正しいし、機能としても動きます。しかし画面側はその値を使っていません。しかも、それを返すために処理が複雑になっていたため、「いらないのでは？」となりました。

データ取得も同じでした。既存のプロジェクトはORMを使っていて、データアクセスの書き方はある程度統一しています。それなのに、AIは個別にSQLを書いていました。AIにとっては「データが取れればOK」なので、複雑な取得要件があると、既存の方針に合わせて簡素にする方法を考えるより、SQLを書いて解決しようとします。個別にSQLを書かれると、コードだけでなくSQL自体を読んで「これ何を取ってるんだっけ？」と確認する必要が出てくるので、保守性の面でつらいです。

性能では、いくつものテーブルにアクセスしてデータを取る部分で、性能を考えずにクエリを発行し、コネクションを食いつぶしかねない実装になっていました。業務で使うことを考えていない実装でした。

人間の開発との違い

人間が実装する場合は、決めていないことが実装の途中で決まっていきます。

人間が設計するときは、基本設計でインターフェースまでまとめ、詳細設計で処理の中身を書いていきます。その中で、方針はレビュアーと開発者の間で固まっていきます。

実装も直列につながります。実装のレビューで細かいずれを直して、次の実装に生かせる。この実装とレビューの往復の中で実装者の認識が揃っていき、「そういえばここも決めておかないと」というものが一つずつ決まっていきます。

今回は、そうなりませんでした。

ADRやコーディング規約はありました。しかし、人間が実装しても時々そこから逸脱するのと同じように、AIも逸脱します。

並列で実装したことで、共通化のタイミングも失われました。大きな機能を小さな機能単位に分けて実装していくので、ある機能の中に共通化できる部品があっても、隣の機能も同時に作られていて、まとめるタイミングがありません。

結果、レビューでは、並列に上がってきた複数の実装を見比べながら「共通化できるのはどこか」「規約から漏れていないか」「性能は大丈夫か」を見ていくことになりました。数と観点の多さが掛け合わさって、ボトルネックになりました。

AIに任せるほど、「人間が先に決めること」を選ぶ必要がある

AIに任せれば速くなるので、詳細設計をがっちりやる必要はありません。一方で、「ここだけは先に決めておく」というものはあります。

• 共通化：全部の機能を実装しきる前に、共通コンポーネントや共通部品を先に作っておく。「あれ、このファイルさっきも見なかったっけ」が減る

• 性能：性能への影響が大きい箇所は人間が事前に見る。設計段階で「この機能はいろんなテーブルに問い合わせることになる」と分かるなら、どういうクエリが最適かを先に人間が考える

• インフラ構成：AIは動けばいいものを作るので、「性能面やセキュリティ面で本当にこの構成でいいか」は人間が判断する

• 基本的な実装方針：ORMを使う、アーキテクチャに沿って処理の流れはこうする、など

この辺は、やはり人間がしっかりレビューしないとだめだと痛感しました。

もう一つ、こうすればよかったと思うことがあります。AIが出したプラン（実装計画）を、実装者だけでなくレビュアーも一緒に見ることです。

プランの段階で「AIはこうやろうとしているのか、ならこうしよう」「この観点が漏れているから詰めた方がいい」と言えます。設計レビューを、実装の前にできるようになります。

まとめ

性能も共通化も、コードに責任を持つのは結局エンジニアです。開発をAIでやる時代になっても、人間が決めるべきところはしっかり決めたい、というのが私の持論です。障害調査のしやすさや保守性、お客さんが使う上での性能やセキュリティまで含めて、どこまでをAIに任せ、どこからを人間が判断するのか。そこは考えておく必要があると改めて思いました。

AIには「HowではなくWhyを伝えよう」とよく言われます。Howを全部決めるのではなく、人間がここまでは責任を持つという判断と、AIに任せていい自由度とを分ける。AIは実装のためにいろいろな方法を取ってくれますし、その中には人間が判断するよりいいものもあります。だから、共通化、性能、アーキテクチャ、インフラ構成といった「最低限ここは決めておきたい」部分だけを決めて、あとはAIの自由度に任せるのがよい、と思いました。

一緒に働く仲間を募集しています！

AI駆動開発という、まだ「これが正解」と決まっていない中でも、一緒に試行錯誤できる仲間を募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

recruiting.algomatic.jp