こんにちは！シニアエンジニアの今枝です。 普段は SaaS 管理サービス「OPTiM サスマネ」や社内の物品管理サービス「OPTiM Asset」を開発しています。
私たちオプティムは、「ネットを空気に変える」というコンセプトのもと、AI・IoT・ロボティクス技術で様々な産業の DX を推進している企業です。そんな私たちは、この度 コーディングアシスタントサービスの全社導入 を決定しました 🎉
皆さんの開発組織では IDE（統合開発環境）など開発・運用をもっと便利にする「新しいツール・サービスの導入」をどのように進めていますか？ 特に最近話題の Claude Code, Cline, RooCode, Cursor 等のLLM によるコーディングアシスタント サービス は「便利そうだけど、費用対効果を説明するのが難しい…」「個人の感覚値だけでは導入に踏み切れない…」と感じている方も多いのではないでしょうか。
今回の記事では、一個人の「これ、やばいです！」という熱量から始まり、多くの開発組織が悩むであろう 「費用対効果(ROI)の壁」をどう乗り越え、Claude Code, Cline, RooCode, Cursor 等のコーディングアシスタントツールの全社導入に至ったのか、そのリアルな道のりをご紹介したいと思います。
きっかけは現場の熱量と、社長へ "直接語った" ことから
ことの発端は、昨年度 4月ごろに発足した 6 つの開発組織横断ワーキンググループ（WG）に遡ります。 （※WG の全体像については、また別の記事で後日詳しくご紹介します！）
その WG のうちの一つに「開発環境改善 WG」があります。この WG 内では全社で自由に利用できる CI/CD 用の Runner など、開発に関わる環境全般の整備などを進めていました。
そんな中、昨年度の下半期ごろから LLM によるコーディングアシスタント関連のサービス群の進化が著しく、「これはすごいぞ…！」と、いくつかのチームで自発的なトライアルが始まりました。
その熱量はかなりのもので、あるチームのメンバー（この記事を書いている私、今枝のことですが...）はなんと 全社懇親会の場で社長をつかまえて、コーディングアシスタントサービスの”やばい”を直接語る という場面も…🔥 当時は、V0やCursorを社長の目の前で実際にデモし、人間の生産性の限界を超える速度でコードが生成される様子をリアルタイムで共有しました。
現場のエンジニアが個人開発で使用したLLM周辺ツールには、「革命的」「ゲームチェンジャー」と感じるほどのポテンシャルがありました。しかし、OPTiM全体ではこれらのツールを活用できていない状況でした。
この個人・小規模チーム開発と全社開発における生産性ギャップを埋めるには、関係者に実際の動作を体験してもらうことが最も効果的だと考えました。 ツールの「すごさ」と、未導入による機会損失を体感してもらう一方で、全社導入時の現実的な課題も共有することで、より具体的で実現可能な導入プランを描けるようになったと考えています。
全社導入に立ちはだかる「費用対効果」の壁
現場の熱意は十分。しかし、個人のトライアル利用と全社での本格導入の間には大きな壁がありました。そう、「費用対効果（ROI）をどう説明するか」 という問題です。
- 「生産性が上がる」と言っても、具体的にどれくらい？
- その効果は、ライセンス費用に見合うものなのか？
こういったシーンにおける「開発生産性」の可視化は、どのような開発組織にとっても非常に難しい問題だと思います。感覚的に「良さそう」なのは分かっていても、それを客観的なデータとして示すのは至難の業です。
私たちもこの壁に直面し、「どうすれば導入効果を定量的に示せるか」を真剣に議論しました。
OPTiM 流、ROI 算出へのアプローチ
議論の末、私たちは以下のようなアプローチで生産性の変化を計測することにしました。
「エンジニア個人の生産性変化を、導入前後で比較する」
非常にシンプルですが、だからこそ本質的なアプローチだと考えました。具体的には以下の3つの指標を観測しました。
- 類似タスクにおける実装期間の比較
- SaaSとAPI連携という似たようなタスクが複数あったため、それらの実装期間を比較分析しました。タスクの性質を統一することで、より正確な生産性の変化を測定できました。
- 従来見積もりとの実装時間ギャップ
- 従来通りの工数見積もりを事前に行い、AIコーディングアシスタント利用時の実際の実装時間との差分を定量的に測定しました。
- 生産されるコード量の変化
- Cursorでは変更したコード行数や承認した行数が簡単に計測できるため、これらの定量的な値を活用してコード生産量の変化を観測しました。
これら3つの指標から、「エンジニア1人月あたりの生産性がどう変化するか」を多角的に導き出そうと試みました。 もちろん、このやり方には注意点もあります。プロジェクトやプロダクトのフェーズが異なる場合や、担当業務がコーディングが主ではない場合（マネジメントや設計など）は正確な比較は難しくなります。 そのため、今回は「コーディングが中心的な業務」であるエンジニアに協力してもらい、できるだけ条件を揃えて計測しました。
結果：生産性は平均 2.45 倍、全体でも 1.7 倍に向上！
そして計測の結果、驚くべき数字が出ました。 コーディングが中心業務であるエンジニアでサンプリング調査を行った結果…
- コーディング時間における生産性（コード量）が、平均で 2.45 倍に増加
- 会議やドキュメント作成など、その他の業務時間も加味したエンジニア 1 人としての生産性は、1.7 倍に向上
という結果を得ることができました！
もちろん、これはあくまでコーディング中心の業務を行うエンジニアの場合の数値です。 設計やマネジメントが主な業務のエンジニアも含むチーム単位、組織単位で見ればこの数字はもっと穏やかになるでしょう。
しかし「コーディング」という作業単体で見た時に、これだけのインパクトがあるという事実は導入を検討する上で非常に強力なデータとなりました。
ROI 試算、そして全社導入へ
私たちは、この「生産性 1.7 倍」 という数値を土台として ROI を試算し、説明を行いました。 その結果、無事に承認を得ることができ、晴れてコーディングアシスタントサービスの全社導入に踏み切ることができました！
おわりに
今回は、オプティムがコーディングアシスタントサービスを全社導入するまでの、泥臭くもデータに基づいた道のりをご紹介しました。 現場の「これ、すごい！」という熱意を起点にしつつも感覚だけに頼ることなく、自分たちなりの方法で効果を可視化し、組織としての意思決定に繋げられたのは大きな一歩だったと感じています。
私たちオプティム開発組織は、LLMをはじめとした進化の早い新しい技術やツールを積極的に活用し、エンジニアがより本質的な課題に集中できる環境づくりをこれからも進めていきます。 この記事が同じように新しいツールの導入に悩む開発者やマネージャーの方々の、何かの参考になれば嬉しいです！
最後にオプティムでは、AI・IoT・ロボティクスの力で社会の課題を解決していくエンジニアを募集しています！ データに基づいた意思決定を大切にするカルチャーで、一緒に未来の「当たり前」を作っていきませんか？
ご興味のある方は、ぜひ採用ページをご覧ください！
