- はじめに
- Q. LLM Week中の開発効率は普段よりも高かったですか?
- Q. 「自分で書いた方が早い」と思ったコードの変更行数の割合はどのくらいですか?
- Q. LLM Weekで一番使ったコーディングエージェントを教えてください
- Q. コーディングエージェントでの開発に向いている・向いていないと思った開発内容を教えてください
- LLM Firstな開発にするために
- 最後に
はじめに
こんにちは。クロスマートで開発部部長をしている上田です。
前回の佐藤さんの記事に書かれていたとおり、7月末にクロスマート社内でLLM Weekが開催されました。
フロントエンド・バックエンド・インフラ問わず、エンジニアはすべてのコードをコーディングエージェントに任せるルールです。
ある意味自由度がなくなるわけですが、これによって以下の2つを目論んでいました。
- コーディングエージェントを使っていない人にも強制的に使ってもらうことで底上げをする
- 「コーディングエージェントの仕事はここまで」という線引きをいったん無くし、現状のLLMの限界を確認する
LLM Week終了後、振り返りのためのアンケートを取りましたが、その内容が興味深かったので一部を共有しようと思います。
Q. LLM Week中の開発効率は普段よりも高かったですか?
クロスマートではコーディングエージェントを使った開発は推奨されており、Claude Codeのアカウントが全エンジニアに発行されていたり、DevinやGeminiやGitHub Copilotも使える状態になっています。
それらをすでに使っているエンジニアにとっては開発効率はあまり変わらず、人力での手直しが出来ない分「開発効率が落ちた」と考える人が出るのも自然かと思います。
Q. 「自分で書いた方が早い」と思ったコードの変更行数の割合はどのくらいですか?
「自分で書いたほうが早い」と思う割合は人によってかなり差がありますが、0%や100%は存在せず、ある程度コーディングエージェントで書くことが最善と思っていることが分かります。
Q. LLM Weekで一番使ったコーディングエージェントを教えてください
開催が7月末でしたのでClaude Code一強です。
今(8月後半)ですとGemini CLIやCodex CLIも入ってくるかもしれません。
トレンドが目まぐるしく変わるので、来年開催したら全然別の結果になりそうですね。
Q. コーディングエージェントでの開発に向いている・向いていないと思った開発内容を教えてください
こちらは自由文による回答だったのですが、まとめると以下のようになっていました。
向いている領域
向いている領域の回答は比較的分散していたのですが、あえてまとめると「要件が明確」「参照できるもの(テスト・既存コード)がある」「変更範囲が狭い」という特徴がありました。
向いていない領域
- フロントの細かいUIやCSSの調整
- デザイン準拠、余白微調整、ピクセルレベルの修正
- 横断的・大規模な改修
- 曖昧だったり複雑な仕様の実装
- 条件分岐が多い業務ロジックの修正
- 初期セットアップ
- 新規環境/ツールの導入、最新のドキュメントを横断して解釈する必要のある作業
- リファレンスのない未知の領域
- Webに事例がない、新規パラダイムの設計
向いていない領域は明確に偏りがあり、「UI周り」「要件が不明瞭」「変更範囲が大きい」というものでした。
LLM Firstな開発にするために
LLMやコーディングエージェントの性能はこの先も上がっていくと思われるため神経質になる必要は無いですが、今見えている課題を解消しておくとこの先もスムーズにVibe Codingができるかと思います。例えば、
- 意味のあるテストを充実させる
- 巨大ファイルになっているコードを分割する
- 細かいリポジトリ分割をやめる
のあたりは、コーディングエージェントも人間も助かる面が大きそうですね。
最後に
この半年でコーディングエージェントによるソフトウェア開発も一般的なものになってきました。
クロスマートではコーディングエージェントをフル活用してもっと開発効率を上げていきたいと思っています。
興味のある方はぜひ採用ページからご応募ください。
