こんにちは、kickflowでCTOを務めている小林です。
3ヶ月ほど前の以下の記事で、AIコーディングツールClineの活用について少し触れましたが、この分野の進化は凄まじく、kickflowの開発現場でもツールの利用方法や業務フローが目まぐるしく変化しています。
今回は、その後のkickflowのプロダクト開発におけるAI活用の現在地と、本格的な導入を進める中で得られた学びについてお話しします。
現在のAI利用状況
以前紹介したClineに始まり、その後もkickflowでは積極的に新しいAIツールを試してきました。様々なツールを比較検討した結果、現在は主に以下の2つのツールを職種に合わせて使い分けています。
- エンジニア・QAエンジニア: Claude Code
- PdM・デザイナー: Roo Code
開発チームではClineやRoo Codeの導入前から開発環境としてRubyMineを使用していましたが、なかなかRubyMineと相性のいいコーディングエージェントが現れず、「Roo Codeを使うためにVSCodeに移行するか、RubyMineとVSCodeを併用するか」と悩んでいました。そんな矢先にClaude CodeがRubyMineと連携可能になったことが決め手となり、開発チームではClaude Codeを主なコーディングエージェントとして使用することにしました。現在ではエンジニア全員にClaude Max 20x（月額200ドル）を付与しており、Opus 4の高い性能を活かしてコーディングしています。
一方で、仕様検討やドキュメント作成が中心となるPdMやデザイナーは元々RubyMineを使用していないため、GUIベースで非エンジニアでもとっつきやすいRoo Codeをメインで使用しています。Roo Codeで使用するLLMは、Claude Sonnet 4を採用しています。
なお、コーディングやドキュメント作成以外の領域では、以下のように様々なAIツールを使い分けています。
- コードレビュー: CodeRabbit
- ソースコードの検索や調査: Devin
- リリースノートの作成: Devin
- その他業務の自動化やAI化: Dify
AI活用の浸透は一筋縄ではいかなかった
Clineをはじめて社内で紹介したときには、「ツールの導入や契約など使うための環境整備だけでしておけば、これだけ便利だから勝手に普及するだろう」と楽観視していました。 ところが、1〜2ヶ月経過してもAIが作成したと思われるPull Requestの数が目に見えて増えず、開発チーム内でアンケートを取ったところ、「AIを使って複雑な機能開発を行う方法が分からない」「AIにデバッグさせてもうまく行かない」といった課題があることが分かりました。
こうした現場の課題を解消するため、「AIコーディングに関する勉強会を開催する」「実際にほぼAIコーディングのみで新規機能を作ってみる」「AIの利用実績が多いメンバーから順番にClaude Maxを付与する」といった活動を3か月の間に地道に実行しました。 こうした甲斐があってか、ようやく7月くらいからAnthropicのコンソールでのAPI利用量が伸び始め、実際にClaude Codeで作成されたと思われるPRが増加し始める状態になりました。
このプロセスを通じて、私たちは3つの重要な学びを得ました。
1. AI導入は強烈なトップダウンで推進する
AIの導入は、単なるツール追加ではなく、業務プロセス全体の変革を伴います。このような大きな変化をボトムアップで進めるには限界があります。
新規サービスの導入決裁権やチームを横断した業務フローへの発言権を持つ経営層が「AI活用を本気で推進する」という強い意志を示し、トップダウンで旗を振る必要があります。これは、変化に対する組織的な障壁を取り除き、全員が同じ方向を向くために不可欠なステップだと思っています。
kickflowでは開発部門以外でも全社的に「AI 1st」というバリューを掲げて業務全体を変革している最中ですが、こちらは社長の重松が中心となり先陣を切ってAI活用に取り組んでいます。一部のアーリーアダプター気質なメンバーに任せっきりにしていると、「AIを積極的に使う人」と「AIに消極的な人」で二分されてしまうため、経営陣が全員に対して「AIを使いこなすことはもはや当たり前で、kickflow社の全員の義務である」くらいの強いメッセージを発信する必要があります。
（重松のAIに対する強い思いは、以下のnoteをご覧ください）
2. 「やってみせる」ことでノウハウを伝播させる
単に「ツールを導入したので、皆さん使ってください」と呼びかけるだけでは、誰も使ってくれません。特にAIのような新しい技術に対しては、「どう使えば良いのかわからない」「本当に役立つのか？」といった疑問や不安がつきものです。
こうした不安を解消して前向きに使ってもらうために、具体的な活用方法を「やってみせる」ことに注力しました。
- 月1のAI勉強会を開催
- Claude Codeのコマンドや、カスタムスラッシュコマンド、フックの活用などの基本的な内容から、実際に自分たちのコードでどのように適用すればいいかといった実践的な内容までを網羅的に解説しました。
- 実際の機能開発をAI 100%で開発してみる
- 私自身が、実際のプロダクトの機能開発をClaude Codeのみを使用してPull Requestを作成しました。これにより、「現在のコーディングエージェントならどこまでできるか」の目線が引き上げられたと思います。
- 以下の2つの機能は、実際にほぼClaude Codeのみで2時間程度で実装した機能になります。
こうした地道な活動の結果、今では開発チームでは自発的に毎週勉強会を開催し、各々が発見したノウハウを共有する文化が生まれています。
3. "AI筋"を鍛えるには、あえて不慣れな領域で試す
プログラミングに習熟したエンジニアほど、「自分で書いた方が速い」と感じ、AIの利用に抵抗を感じることがあります。確かに、慣れ親しんだ言語やフレームワークであれば、その感覚は正しいかもしれません。
しかし、その考えに固執していると、いつまで経ってもAIを使いこなすスキル、いわば"AI筋"が鍛えられません。
そこで効果的だったのが、あえて不慣れな技術領域や、少し面倒な定型タスクでAIを使ってみるアプローチです。例えば、普段あまり書かない言語でのスクリプト作成や、複雑な正規表現の生成などでAIの力を借りることで、その圧倒的なサポート能力を実感しやすくなります。
この小さな成功体験が、より複雑なタスクにもAIを活用してみようという意欲に繋がっていきます。
今後の展望: AI中心の業務フローへ
現在kickflowでは、AIの活用をさらに一歩進め、AIを前提とした業務フローの再構築に取り組んでいます。
スペック駆動開発への移行
これまで仕様書や設計書は社内のドキュメント共有ツールであるesaで管理していましたが、AIとの連携を最大化するため、管理場所をGitHubに移行しました。
これにより、プロダクトマネージャーがRoo Codeを駆使して仕様書を作成し、その内容に基づいてエンジニアがClaude Codeを駆使して設計書やコードを生成するというスペック駆動開発の実現を目指しています。このフローが確立されれば、仕様の変更が即座にコードへ反映されるようになり、開発のリードタイム短縮と品質向上の両立が期待できます。また、コードを元に設計書や仕様書をメンテナンスすることで、よくある「仕様書と実装がズレやすい問題」に対しても解決できるのではないかと期待しています。
E2Eテストの効率化・高速化
現在、E2EテストにはAutifyを利用していますが、kickflowの複雑な仕様を網羅しているためテストの実行時間が非常に長い問題や、主にUIの変更に追従するためのメンテナンスコストに課題を感じています。
今後の展望として、QAチームではコードベースのE2EテストフレームワークであるPlaywrightへの移行を検討しています。Playwrightに移行してソースコードと同じリポジトリでE2Eテストのコードを管理することで、AIにテストコードの生成や保守を任せ、テスト実行時間を大幅に短縮しつつ、より網羅的なテストを実現できるのではないかと考えています。まずは、これから立ち上げる予定の新規プロダクトのリポジトリで、試験的にPlaywright中心のE2Eテストの構築をやってみる予定です。
おわりに
kickflowにおけるAI活用の取り組みはまだ過渡期で、これからも最先端の技術やナレッジを積極的に取り入れていきます。今後も様々な試行錯誤を繰り返しながら、テクノロジーの力でプロダクト開発の生産性を最大化し、お客様により良い価値を届けられる組織を目指していきます。
kickflowでは、このような新しい技術の活用や開発プロセスの改善に一緒に挑戦してくれる仲間を募集しています！ 少しでもご興味を持っていただけた方は、ぜひ採用サイトをご覧ください。
