🤖

エンジニアリングチームでLLMを1週間使い倒してみた話

に公開

はじめに

こんにちは。
ツクリンク株式会社でエンジニアやっとります、ikarikomanです。

先日、社内で「LLM Week」という1週間のイベントを開催しました。
この記事では、LLM Weekを開催した背景や実施内容、得られた成果についてお話ししていきます。

なぜLLM Weekを開催したのか

LLMを活用した開発が主流になりつつあり、弊社でも個人レベルでは使い始めていましたが、「開発業務のどこまで使えるのか」「エンジニアリングチームとしてどう活用すべきか」といった共通認識がありませんでした。

そこで、実験的にエンジニアリングチーム全体で1週間徹底的にLLMを使い倒してみることにしました。

開催にあたっての主な狙いは以下の3点です。

  • 実務での限界を知る
    • 普段の業務でLLMを使うことで、「できること・できないこと」を実体験として理解する
  • チーム全体のスキルアップ
    • 1週間集中して取り組むことでLLM活用スキルを底上げする
  • 開発フロー改善のヒントを得る
    • LLMを前提とした開発スタイルや、効率的な使い方のノウハウをチームで蓄積する

LLM Weekの開催内容

日程

2025年9月17日から9月24日の1週間で実施しました。

ルール

シンプルに以下の2つのルールを設けました。

  • コーディングは全てLLMで行う
    • 実装・修正を問わず、コードは一切手で書かず、LLMに生成させる
  • 普段の業務で実践する
    • 特別な課題ではなく、日常業務の開発タスクを対象とする

LLM Weekで得られた成果と気づき

LLM Week終了後、参加メンバーにアンケートを実施しました。
以下、アンケート結果から見えてきたことや気づきをまとめていきます。

開発スピードへの影響

「開発のスピードは普段より上がったと思いますか?」という質問に対して、以下のような結果となりました。

開発スピードへの影響

  • 非常にそう思う:5名(約38%)
  • ややそう思う:5名(約38%)
  • どちらとも言えない:3名(約23%)
  • あまりそう思わない / 全くそう思わない:0名

多くのメンバーが開発スピードの向上を実感しており、LLMの活用が開発の生産性向上に一定寄与していることがわかりました。

コード品質への影響

「設計やコードの品質は普段より上がったと思いますか?」という質問に対しては、以下のような結果となりました。

コード品質への影響

  • 非常にそう思う:2名(約15%)
  • ややそう思う:6名(約46%)
  • どちらとも言えない:4名(約31%)
  • あまりそう思わない:1名(約8%)

品質面に関しては約61%のメンバーがポジティブな評価をしましたが、約31%が「どちらとも言えない」と回答しており、スピードほどの明確な効果は感じられなかったようです。

LLMを活用したタスク

参加者が実際にLLMを活用したタスクは以下の通りでした(複数回答可)。

LLMを活用したタスク

  • コーディング:12名
  • 設計:9名
  • テスト:6名
  • ドキュメント作成:4名
  • その他:コミットメッセージ生成、JIRAチケット作成、調査など

新しい技術への挑戦

LLM Weekをきっかけに、多くのメンバーが新しい試みに挑戦してくれました!

  • MCP(Model Context Protocol)の活用
    • Figma MCPやAtlassian MCPを導入し、デザインツールやプロジェクト管理ツールとの連携を試みたメンバーがいました。
  • チーム内での知見共有
    • Figma MCPに関する座談会を開催したり、プロンプトをチーム内で共有するなど、個人の学びをチーム全体に広げる動きが生まれました。
  • 仕様書駆動開発
    • 仕様書をベースにLLMに実装を任せるアプローチを試したメンバーもいました。

LLM Weekはきっかけに過ぎないかもしれませんが、こういった新しい取り組みを生み出せたことに関してはとてもよかったです。

LLMが適していない場面も

「LLMを使わずに手で作業したいと思った時はありましたか?」という質問に対して、多くのメンバーが「少しあった」「多々あった」と回答しました。

特に、スタイル実装など細かい調整が必要な作業では、全てLLMに任せることで逆に開発スピードが落ちたという声もありました。

この「LLMでできること・できないこと」の境界線を実務を通して体感できたことは、今後のLLM活用の判断基準を作る上で非常に良い経験だったと思います。

チーム全体のスキル向上

普段からLLMを活用しているメンバーが大半ではありますが、1週間を通じて、各々が自分なりのLLM活用法を見つけ、チーム全体としてのLLM活用スキルが底上げされたと感じています。

「意外と自分で書かなくても何とかなった」という気づきを得たメンバーもおり、LLMに対する心理的なハードルが下がったことも大きな成果だと思います。

今後やっていきたいこと

アンケートで「今後どのようにLLMを活用していきたいか」を聞いたところ、色々なアイデアが出てきました。

  • 開発プロセスの自動化
    • 夜間にコードを生成するなど、人が作業していない時間を有効活用したい
  • ドキュメント作成の改善
    • ADRなどのドキュメントを整備したい
  • AI向けドキュメントの整備
    • LLMがより適切なコードを生成できるよう、AI向けのプロジェクトドキュメントやルールを整備していきたい
  • QAテストケース作成の効率化
    • テストケース作成にLLMを活用して、QAの負担を減らしたい
  • 複数モデルの活用
    • 複数のLLMモデルを組み合わせて、コードレビューや品質向上に活かせないか試してみたい

LLM Weekは1週間で終わりましたが、ここで得た学びをもとに日常の開発フローを改善していきたいと思います。

次回に向けた改善点

今回のLLM Weekを振り返って、次回やるなら下記の点を改善したいなと思っています。

参加を促す仕組みづくり

イベント期間中、Notionに「手動でコーディングしてしまった時の懺悔スペース」と「Tips共有スペース」を用意しましたが、用意しただけでは活用が進まないことがわかりました。
次回は、Slackでの気軽なコミュニケーションや、定期的なリマインド、週の途中での振り返りの場など、もっと積極的に参加を促す仕組みを取り入れたいと思います。

タスクの性質に応じた柔軟な運用

コーディング以外の作業が多いメンバーもいたため、LLMの効果を十分に実感できなかったという声がありました。
次回は、コーディング以外のタスク(ドキュメント作成、調査、設計など)でのLLM活用事例も積極的に共有して、より広い範囲でLLMが活用できるようにしていきたいです。

より具体的なLLMのガイドラインの作成

LLMを本格的に使い始めたばかりのメンバーがいる場合、どのようにLLMを使えば効果的なのか分かりづらい部分があったかと思います。
MCPの活用方法やプロンプトのベストプラクティスなど、もう少し具体的なガイドラインを事前に用意しておけば、よりスムーズに参加できるかと思いました。

さいごに

今回のLLM Weekで、LLMができることとできないことを実務を通してエンジニアリングチーム全体で体験することができました。

多くのメンバーが開発スピードの向上を実感し、MCPの活用や組織内での知見共有など、新しい取り組みも生まれました。
参加者からは「楽しかった」「良い機会だった」というポジティブな声も多く、イベント自体は良い形で終われたかと思います。

この1週間で得た学びをそこで終わらせず、今後に活かして、より効果的なLLM活用を模索していきたいと思います。
もしエンジニアリングチームでのLLM活用に悩まれている方がいましたら、少しでも参考になると幸いです。

Discussion