AI開発合宿レポート ─ 仕様駆動開発で掴んだ「全員で作る」プロダクト開発体験

2025年の11月某日、アンケートの通知を受信。差出人はHRテック事業部長。

開くと「AI開発合宿をやります!」というタイトルと、概要、そして選択肢がありました。

  • ☑️ 1. 絶対に行きたい
  • ☑️ 2. 行きたいけどまだ行けるか分からない
  • ☑️ 3. 行きたいけど予定があり行けない

全部行きたい前提なんだ…と思いつつ、面白そうだったのでとりあえず2を選んで返信し、めくるめくAI開発合宿へのチケットを手に入れました━━━━

はじめに

初めまして!私はHRテック事業部で、NALYSYS労務管理プロダクトチームのリーダーをしている𠮷田と申します。

HRテック事業部では、HR系SaaSプロダクト「NALYSYS(ナリシス)」を開発しています。労務管理だけでなく、モチベーション管理など複数のサービスを展開しています。

本記事では、上記のように始まった1泊2日のAI開発合宿を通して、HRテック事業部でのAI活用状況や、チームで実践した仕様駆動開発の所感についてお話ししていきます!

対象読者

  • HRテック事業部内でのAI活用状況が気になる方
  • 開発者が実装に閉じず、プロダクトチーム一丸となったアジャイル開発をしてみたい方
  • 仕様駆動開発の実践に興味がある方

この記事を読むとわかること

  • HRテック事業部がどのようにAI活用の土壌を構築しているのか
  • Figma MCPと仕様駆動開発を組み合わせた開発の進め方
  • 職種を越えたチーム開発でAIが果たした役割

AI開発合宿とは?休日出勤なのか?

実際AIツールを導入している開発現場ではこんな状態ってありがちじゃないでしょうか?

  • 各々が自己流でAIを使用していてローカル設定やMCPなどの情報が共有されない
    • 他チームはおろか、自分のチームのメンバーがどうAIを使っているのかも分からない…😔
  • 一度使い始めたツールから乗り換えないため、どのエージェントが良いか比較ができない
  • 新しいAI活用方法に興味があっても、実務に導入する準備や検証をする時間が取れない
    • 不確定性を排除できないAIの性質上、品質に関わる部分へのAI導入には「やってみて」の実績が必要だが、実証実験には時間がかかるジレンマ🫨

これらの悩みを、2日間集中的にAI活用に投資する時間を囲って解決しちゃおう!というのが合宿のコンセプトです。

その2日間も、渋谷にあるオフィスを遠く離れた那須白河のリゾートホテルで、会議室とはいえ日常業務を離れたゴージャスな空間でチームごとに集中して楽しく開発できました。

また、金〜土の日程でしたが当然代休あり、交通費支給あり、三食豪華食事ありで、ワークライフバランスを重視する私としても迷いなく参加できて有難い限りでした✌️

先に結果をチラ見せしてしまうと、最終的にこんな成果が得られました!

  • AIを使いこなしているメンバーのノウハウを共有
  • 仕様駆動開発の効果と効率性を実感(後述)
  • 今までコーディングをしたことがないデザイナーがレスポンシブデザインを実装!
  • 普段開発に関わらないPdM2名が新機能を開発!!
  • AI活用度の最終結果で上記を評価され豪華景品(焼肉)

ではそこに至るまで、合宿前日譚から実際どういった内容だったかをお伝えしていきます。

合宿を価値ある時間に!部門全体でコミット

AI活用を促進する、HRテック事業部の『組織的な土壌』

いくら経営層が「AIを活用して業務効率を上げよう!」などと言ってその機会を作っても、日頃の積み重ねがないと動き出せませんよね。 その意味でHRテック事業部は備えを怠っていませんでした。

Geminiコーポレートアカウントの全社員提供など、レバレジーズでは全社的にAI活用に投資していくぞ!という姿勢を予算という形で打ち出しています。 エンジニア組織としても、Claude CodeやCursorの有料プラン、FigmaのDev Modeなど希望すれば柔軟に使用できる環境が整っています。

そんな中でHRテック事業部内では広くAI活用を展開しようという動きをエンジニアやデザイナー、QAが主体的に行っており、合宿の実現はそういった活動があってこそでした。

AI推進室

今回合宿の企画をしてくれたチームです。 普段は開発用AIエージェントツールの選定や管理から、自社開発している「NALYSYS AI面接」他、AI機能についてのテックリードとして開発や改善の仕組みの構築・管理まで、部門全体のAI活用の推進をしてくれています。

合宿に際しては事前に仕様駆動開発用のプロンプトの整備や参加者全員にClaude MAXプラン配布など、合宿中参加メンバーがAI駆動開発に集中できるようにセットアップをしてくれました。

NALYSYS デザインシステム HeaRT

NALYSYSではマイクロサービスアーキテクチャを採用しており、各プロダクトは別リポジトリで開発しています。またデザイナーも複数人いて一人が全部をレビューするのが難しい規模です。そのため、1年ほど前まではプロダクトごとにコンポーネントを作成したり、微妙なデザインのバラツキがあったのですが、それを解決すべく立ち上がってくれたエンジニア・デザイナーの混成チームにより、NALYSYS デザインシステム HeaRT(ハート)が生まれました。 当初は車輪の再発明やUXのブレを防ぐためという目的が大きかったのですが、デザインシステムというシングル・ソース・オブ・トゥルースが出来たことで、気がつけばAIの恩恵をフルに受けられるという状態になっていたのです。

プロンプト一発でFigmaに作ったデザインが出来上がるという圧倒的な開発体験を得る手法を、今回の合宿で教えてもらいました。

ちなみにHeaRTについて、詳しくはこちらの記事で担当者が話しているのでぜひご覧ください!

tech.leverages.jp

QAチーム

アジャイルQAという難しいミッションに果敢に挑戦し、プロダクトチームと共に品質改善を牽引してくれるQAチームの方々とも日々AI活用によるQA工数の削減について話し合っています。 その中で具体的な機能に依存しないテスト観点表とデザインや仕様書からフロントエンドのコンポーネントテスト項目を生成できないか?その上で実装箇所のQAテスト工数を削減して、探索的テストに当てられないか?という試みを行っています。

テスト観点表はすでに出来ていたのですが、それを実際新機能に使ってみることがまだ出来ていなかったので、今回の合宿はその実践の場になりました。

【合宿1週間前】チーム分け・準備

そういった素地があって企画が始まったAI開発合宿。 合宿の前週から実質的に参加者はその準備を始めました。

まずチーム分けと「実務のプロダクトに新機能を付ける」というテーマ、「27時間で各グループでAI駆動開発を実践、開発の精度やAI活用度合いを競う」というワーク、そして優勝者には豪華焼肉という重大な事実が共有されました。

チーム紹介

プロダクトを軸に3つのチームがエントリー。

労務管理チームとして集まった4人は以下のような構成でした!

  • 労務管理・年末調整PdM
  • UI/UXデザイナー
  • 年末調整担当エンジニア
  • 労務管理担当エンジニア(私)

私とPdM以外は労務管理の開発に関わったことはなく、ましてやデザイナーはほとんどコーディングというものをしたことがない。 どーなっちゃうの?!と言いたいところですが、実際にはこのチーム強いな、と思ってました。

なぜなら年末調整担当のエンジニアは、ほぼ一名でレビューまで全てAIとのタッグで開発を回しているのを日々隣の席で見てましたし、デザイナーも恐るべきキャッチアップ力で新プロダクトのPoCを回したりAIでデザイン業務改善を進めていることを知っていたからです。

そこに3度の飯よりAIが好きなPdMもおりますから、全く不安はなく、これはイケるぞ焼肉!!と思いました。

テーマ選定

「合宿後も役立つ成果を」ということで、各チームでプロダクトの未実装企画の中から事前に決めました。 事業部長とどんな機能が実装できたら熱いかなどを話し、事業へのインパクトを考慮してチョイス。

結論的に、私のチームは2つの大きな挑戦をすることにしました。

  1. 既存の十数ページ分のレスポンシブ対応
  2. 次のフェーズで作る予定の新機能

1つ目は、バックエンドが関わらない一方でデザインの再現性が重要なため、主にデザイナーとPdMが担当。 2つ目は、本来なら労務チームで1ヶ月以上かけて開発する予定だった機能を「2日間で本気出したら(ガチったら)どこまで形にできるか」という大実験!こちらは主にエンジニア2名で担当することにしました。

いざ合宿!

同僚たちと新幹線に乗って福島県へ。

上でも貼ったような、冬のリゾートホテルに大興奮しながらも、一目散にホテルの会議室に向かいレクチャーを受けました。

以下、スケジュールから実際どういうことをしたのかかいつまんで説明します。

オープニング(AI駆動レクチャー)

あらかじめ搬送してもらったモニターとWiFiでPCをセットアップし、まずはAI推進室とデザインシステムチームによるレクチャーからスタート。

内容は大きく2つ。

1つ目は、AI推進室が整備してくれた仕様駆動開発の手法とプロンプト。要件や仕様をAIに読み込ませ、設計から実装までを一貫して駆動させるためのお作法です。 2つ目は、デザインシステムチームによるFigma MCP連携。Figmaのデザインデータをそのままエージェントに読み取らせ、デザインシステムのコンポーネントで再現させるためのプロンプトと手順の解説でした。

どちらも日頃の業務の中で必要性を感じつつも、実務にいきなり導入できずにいたノウハウを丁寧に教えてもらい、早速それを取り入れながらの開発を開始しました。

グループワーク(一日目)

まずは開発に着手する前に、AI開発環境のセットアップと試運転。

事前の予想として「AI駆動開発はレビューがボトルネックになるだろう」というものがあったため、その対策を共有し合いました。

日頃からAIをフル活用して開発している年末調整のエンジニアからは、開発やレビューの効率化のために自作していたClaude Code command(あらかじめ作成したプロンプトをスラッシュコマンドで呼び出す機能)をセットアップしてもらいました。 適切な内容でPRを作成してくれるコマンドなども便利でしたが、特に工夫がすごい!と思ったのはレビューコマンドです。

「レビュー観点を与えてチェックさせる」一般的なコマンドの後に、さらに「そのレビュー内容が妥当か」を検証するコマンドを組み合わせました。 AIのレビューは、どうしても内容が冗長になったり、変更点だけを見て誤った指摘(嘘)をしたりすることがあります。しかし、この検証プロセスを通すことで「本当に読むべき箇所」だけを的確に抽出でき、レビューを確認する心理的負荷が驚くほど軽減されました。

もう一つは私が用意してきたもので、QAと検討して作成した機能によらないテスト観点基準とデザインや仕様書をまとめてAIに食わせることで、フロントエンドのコンポーネントテストケースを生成する仕組みでした。このテストケースの良いところは優先順位も合わせて教えてくれるので、その上位の数ケースだけでも自動テストを書けば、最低限の動作は保証されてレビュー負荷もだいぶ下がるだろうという目論見です。

しかしその用途とは別にこの設定をしている時に、この合宿で最大の発見をしてしまいました。 Figma Dev Mode MCPが強すぎる、という事実です。

Figma Dev Mode MCPが強すぎる

半年以上前にもFigma MCP活用は話題になっていましたが、その時話題になったのはFigma-Context-MCPという、オープンソースのMCPサーバーでした。 こちらもFigmaで作成したデザインの内部情報を読み取って、複雑なものでなければそのまま再現してくれました。その時も「おっ、便利だな」というくらいの感想を抱いたのを覚えています。

対して、満を持してFigmaが公式にリリースしたFigma Dev Mode MCP、こちらもやってくれること自体は概ね同じですが、その読み取り精度の高さ、思った以上に大きい範囲のセクションを雑に渡しても読み取ってくれるなど、さすが公式が出しているだけあるパワフルさで感動しました。 ちなみにFigJamも読み取れます。

なのでFigmaのデザインと、FigJam上に作った簡単なモデリング図などを用意すれば、MCP経由でClaude Codeが取得し、バックエンドからフロントエンドまで詳細に仕様書を作成する材料が整うのです。

その上、設計や技術選定など人間が判断しなければいけないことでもAI推進室がセットしてくれたプロンプトによって、考慮漏れしがちな部分はAI側から聞いてくれるので、想像以上のクオリティの仕様書が一発で作成されてチームで深夜に爆沸きしました🙌🙌

話は戻って、初日のグループワークタイム、我々はまずは急がず焦らず仕様の理解や、既存実装のモデリングに時間を使いました。
今回エンジニア二人で作る予定の新機能は、全てゼロからではなく以前作った機能単体のマイクロサービスがあります。しかし提供する機能は同じでも、その時の想定と違う労務管理クライアントから呼び出すためのギャップを埋める再設計とAPI作成が必要でした。

なのでマイクロサービスを読み込ませてER図の作成や提供APIの仕様の洗い出しをClaude Codeにしてもらいつつ、その情報をもとに二人で機能単体のドメインと、労務管理のドメインを繋ぐドメインモデリングを行い、実装が必要なテーブルやAPIの検討を行いました。

今後本当に製品として提供するものなので、合宿だからと言って雑に進めると意味がないと考え、認識統一と設計でほぼ一日目の持ち時間を使い切りました。

並行して、フロントエンド出身のPdMがサポートしながらデザイナーは着々とレスポンシブデザインを完成しており、私も自分のタスクをClaude Codeに調査させている間にそのレビューをしました。

こちらもそのままプロダクトとしてリリースする予定なので妥協したレビューはしませんでしたが、レスポンシブにするロジックなどきっちり作られていました!

中間発表&夕食

私たちの班からは、レスポンシブ対応の成果と、コマンドによる開発の効率化などを発表。

すでに他のチームは2つほど機能を実装していたり、開発未経験のPdMが新機能を完成させていたりと各々が別のスタイルで着々と進めている様子でした。

その後は待ちに待った夕飯です!結婚式みたいな丸テーブルで、フレンチのコース料理を頂きました。

「本当に、会社のお金でこんなに豪華な食事をいただいて良いんですか!?」と、お昼の豪華な御膳からずっと、驚きと感謝が止まりませんでした。

グループワーク(延長戦)

各々温泉に入った後、寝るまで続きをやろう!と予定してたのですが、気がついたら他メンバーがカラオケルームに吸収されていたため、私も楽しく任意参加カラオケ(※)をして、そこから部屋での延長戦開始となりました。

※経費で落ちないため事業部長のポケットマネーにより開催

しかしこの時が一番楽しかったですね。

日中に既存実装の調査もあらかた終わり、FigJam上にモデリング図などもできた状態で、上にも書いたFigma MCPが仕様の生成に使えるんじゃない?と気付いて試した時、その生成された仕様をさらにチーム全員で話し合っている時、これは絶対日常業務でも使える新しい開発のあり方を実践できているという確かな手応えがありました。

実際問題、HRテック事業部で2年ほどエンジニアをやってきて、これまでも企画から下の要求定義や基本設計からエンジニアとして関わり、PdMやデザイナーと一緒にプロダクトを設計していくという働き方をしていましたし、ドメインモデリングと実装を連動させて育てていくDDD的なこともしてきました。

だからやっていることは大きく変わらないのですが、このやり方によって、圧倒的にそういう職務横断的なチームプレイをする時に面倒なことが減るという確信をその夜得たのです。 何しろ、デザイン・要求定義書/仕様書・UML図という各職種がプロダクトを表現するために使っているツールで作った情報を、人の手を介さずに変換・生成できるのですから。

本当のコラボレーションというものがここから始まるんじゃないかと言うワクワク感ですね。

てなわけでワクワクと仕様書と、API設計書を作成して、この日は全くコーディングをしないまま、普段より少し遅めの時間に就寝。

グループワーク(二日目)

翌日爽やかな天気の中目覚め、ゴルフに行く人たちに囲まれて朝食バイキングで美味しいエッグベネディクトを頂き、作業開始です。

(若干数名、飲酒により正常に開始できてない人もいましたが…)

この日はフロントエンドとバックエンドに分かれ、とにかく実装あるのみでした。 なので書くことはあまりありません。

強いて言えばやはりFigma MCPが強く、フロントエンド側はデザインURLと期待挙動の仕様書を読ませるだけでどんどんできていくなぁと横目で見ながら、バックエンドは純粋なロジックだけではできない部分(他マイクロサービスとの接続設定など)はそうすんなりとは行かなかったです、正直に言うと。

そんなこんなで各人で黙々と実装をして15時にグループワーク終了。

チームの結果としては、レスポンシブ対応が6画面ほど完了し、新機能はフロントエンド側が9割(スタイル調整以外)、バックエンドが7割(他サービスとの連携部分など意外)が完成しました!

最終発表

仕様駆動開発に真っ直ぐ向き合って、プロンプトのやり取りだけで仕様書を作ってそのまま実装してみたら、文章量が多くレビューしきれない部分に不具合があって大変だったというチームや、個々が小さい機能を受け持って堅実にいくつも小さい機能を実装したというチームなど、各チームのアプローチに個性があって、発表はとても面白かったです。

我々のチームは、新機能完成こそしなかったものの、フロントエンドはレスポンシブ対応や新機能のUIが完成していたのでそれを見せつつ、MCPやClaude Code commandを活用した開発効率の上げ方と合わせて発表。その結果…

━━━━━見事優勝の座をGET!!🎉🎉🎉

焼肉へのチケットを手に入れ、良い気分で帰路につきました。

〜Happy End〜

祝杯

お肉美味しかったです

合宿で成し遂げたこと・気付き

ここまで時系列でお伝えしてきましたが、改めて27時間で私たちのチームが成し遂げたことや気付きを振り返ります。

実装未経験のデザイナーがレスポンシブデザインを実装

コーディングの経験がほとんどなかったデザイナーが、Figma MCPとデザインシステムHeaRTの力を借りて、既存画面のレスポンシブ対応を6画面分完成させました。

Claude Codeと共にデザイナー自身が「自分のデザインを自分で実装する」という体験を実現。しかもそのままプロダクトにリリースできるクオリティでした。

AIがコーディングの壁を取り払い、職種の境界を越えたコラボレーションを可能にした象徴的な成果だったと思います。

ドメインモデリング × Figma MCPで設計から実装へ

新機能の開発では、いきなりコードを書くのではなく以下のステップを踏みました。

  • 既存マイクロサービスのコードをClaude Codeに読み込ませ、ER図やAPI仕様を整理
  • FigJam上でチームでドメインモデリングを行い、モデリング図を作成
  • FigmaのデザインとFigJamのモデリング図をFigma MCP経由でClaude Codeに渡し、仕様書を生成
  • 生成された仕様書をチーム全員で議論し、設計の方向性を固める

ここで大事だったのは、AIが出力した仕様書が「議論のたたき台」として非常に優秀だったことです。 デザイン・ドメインモデル・要求定義といった各職種のアウトプットを、人手を介さず統合して仕様書という形にしてくれる。それをみんなで囲んで「ここはこうじゃない?」「この仕様だとこのケースは?」と話し合う。

AIが翻訳者となることで、エンジニアもPdMもデザイナーも同じ土俵で会話できたのが画期的でした。

設計書からの網羅的なUI実装

チームで合意した仕様書とFigmaデザインをそのままClaude Codeに渡すことで、フロントエンドの実装が驚くほどスムーズに進みました。

  • 仕様書に記述された画面ごとの期待挙動をそのまま実装指示として使用
  • Figma MCPでデザインを参照させつつ、デザインシステムのコンポーネントで構築
  • 結果、新機能のフロントエンドUIが9割完成(スタイル微調整を除く)
  • 仕様書の精度が高いと、AIへの指示もブレないし、レビュー時に「これは仕様通りか?」の判断基準も明確になる。

設計に時間を使った初日の判断が、二日目の爆速実装につながりました。

#### 仕様駆動開発で実現する「みんなで話して進める」開発 正直に言うと、合宿前は「仕様駆動開発」を「AIに仕様を食わせたら勝手に作ってくれる手法」くらいに捉えていました。 でも実際にやってみて気づいたのは、その本質的な価値は仕様を中心軸にして、チーム全員が同じものを見ながら話し合って進められることだということです。

  • AIが生成した仕様書は完璧ではない。でもそれをたたき台にチームで議論することで、認識のズレが早期に見つかる
  • デザイン・ドメインモデル・コードという異なる言語で表現されたものを、仕様書という共通言語に変換してくれる
  • 結果として、企画・設計・実装のサイクルが驚くほど速く回る

これはAIが主役というよりも、AIが優秀なファシリテーターとして機能し、人間同士のコミュニケーションを加速してくれたという感覚に近いです。 2年間プロダクトチームで職種横断的に開発してきた自分にとって、「やっていることは同じだけど、面倒なことが圧倒的に減る」——これがこの合宿で得た一番の収穫でした。

まとめ

AI開発合宿を通じて実感したのは、AIは魔法の杖ではなく、チームの力を引き出すための道具だということです。

仕様駆動開発もFigma MCPも、結局はそれを使って何を作るか話し合い、出てきたものをレビューし、より良くしていくのは人間です。ただ、その「話し合って、作って、確かめる」というサイクルの中にあった面倒や壁を、AIが驚くほど取り払ってくれる。デザイナーがコードを書き、PdMが機能を実装し、エンジニアがドメインモデルをみんなで囲んで議論できたのは、その証拠だと思います。

そして何より、こうやって部門を挙げてAI活用の素地を作ってくれたAI推進室やデザインシステムチーム、QAチーム、合宿を企画してくれた事業部長、そして一緒に深夜まで仕様書を囲んで盛り上がれるチームメンバーがいるという環境が、本当にありがたいなと改めて感じました。 今もこの時得たMCPやcommandの活用しつつ、仕様駆動開発の実務適用にチャレンジ中です。

こんなふうに、常に新しいノウハウを取り入れながら職種の垣根を越えてプロダクトチーム全員でものづくりをする働き方に興味がある方、HRテック事業部で一緒に働きませんか?

エンジニアに閉じない開発がしたい方、AIを活用したプロダクト開発に本気で取り組みたい方、大歓迎です!

ここまでお読み頂きありがとうございました!


We are hiring!

この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか?

私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。

あなたからのご応募を、心からお待ちしています。


■会社説明資料

speakerdeck.com

■採用情報はこちら(HRMOS)

hrmos.co

■まずはカジュアル面談から

hrmos.co

■開発部の雰囲気がもっとわかる動画はこちら!

テックフェス2026 冬レポート

はじめに

こんにちは、レバレジーズ株式会社で普段はエンジニアをしているスガノです。
今回、「テックフェス2026冬」運営委員長を務めさせていただきました。

本記事では、レバレジーズグループ全体のエンジニアが一堂に会した 「テックフェス 2026 冬」 の様子を紹介します。

今回のテックフェスは「セキュリティ」 を軸に、
基調講演、総勢100名以上が参加したテックバトル、セキュリティにまつわるハンズオンやセッションなど、さまざまなコンテンツを実施しました。特にテックバトルやハンズオンは、セキュリティ専門チームが主導し、テックフェス用のオリジナルコンテンツとして作成しました。
この一日を通し、セキュリティへの学び・楽しさはもちろん、横との繋がりを実感できる場となりました!

テックフェスとは

テックフェスは、レバレジーズグループに所属するエンジニアを対象に、半年に一度開催される社内最大級の技術イベントです。
エンジニアが新しい技術に興味を持ち、みんなで学び合うことを目的に、組織全体の技術力と交流を高める “社内の技術祭” として続いています。

このイベントの特徴は、事業部の垣根を超えて “有志のエンジニアたち” が自ら運営していること
普段は異なる開発チームに所属するメンバーが全部署から横断的に集まり、テーマ設計から企画・広報・当日の運営までを自分たちの手で作り上げています。

2026年2月に開催された 「テックフェス2026 冬」 のテーマは、
急成長のその先へ。セキュリティで信頼と未来を創る」。

このテーマの背景には、会社として掲げている “1兆円規模の企業を目指す” という大きな目標があります。
その未来を支えるエンジニア組織として、攻めと守りを両軸に、次の2つの側面から進化していく必要があると考えました。

① 学ぶ機会の創出
なんとなく苦手意識があったり、学ぶ機会が乏しいことのあるセキュリティ。昨今、ニュースでも大規模なインシデントが複数報道されました。
これからのレバレジーズは1兆円規模の企業を目指します。セキュリティの文脈で、狙われる機会も増えてくるでしょう。
今だからこそ、学ぶことが不可欠と捉えました。

② 楽しみながら学ぶ
「そうは言っても知らないこと多そうだな...」と思う方もいるでしょう。
そこで、守りだけでなく、攻めたり壊したりすることで、攻撃者の目線も学びつつ、アクティビティとしてのめり込める楽しさも必要条件だと考えました。
やらされる学びより、やりたくなる学びを。こんな思いでコンテンツを作ってまいりました。

セキュリティを専門とするエンジニアが中心となった今回のテックフェスは、どのようなものになったのか?
早速、コンテンツの様子を見ていきましょう!

CTFをモチーフにしたテックバトル

テックフェスの目玉コンテンツであるテックバトル。今年は1回戦、2回戦に分けて実施しました。

1回戦

1回戦は「セキュリティ×謎解き」と呼ばれるCTFを元にした、Webアプリの脆弱性を突く「攻撃者の視点」を体験できるテックバトルをしました。セキュリティを専門とするエンジニア社員らが作ったこのバトルでは、 セキュリティ未経験者を含む約100名が参加し、システムに隠された脆弱性を特定し、制限時間内にどれだけ多くのFlag(答え)を獲得できるかを最終的な合計得点を競うクイズ(Jeopardy)形式で実施しました。

採点には、正解者数に応じて問題の配点がリアルタイムに変動する「ダイナミックスコアリング」を採用。多くの人が解いた問題は価値が下がり、誰も解けない難問は高得点を維持し続ける仕組みにより、どの問題から着手すべきかという戦略性と、刻一刻と順位が入れ替わる緊張感を演出しました。
また、あえて「AIによる自動解答の禁止」をルールとし、代わりにヒント機能を充実させることで、安易な解決ではなく参加者自身の「閃き」と「調査能力」を問う設計にもしました。

この1回戦は、参加者が「攻撃者の視点」を安全な環境で体験できるよう企画・開発を進めました。実際に手を動かしてシステムを攻略する快感を通じ、教科書だけでは学べない「なぜそのコードが危険なのか」という防御の勘所を、楽しみながら肌感覚で習得できる場を目指しました。

2回戦

2回戦のテーマはハードニング競技会をモチーフにした「システムをぶちこわしてバトル」!
1回戦の結果を踏まえて分けられたチームに、ECサイトを模したWebサイトのソースコードが配布されます。各チームをスタートアップ企業に見立て、セキュリティインシデントが株価に影響するという緊張感のある設定です。 制限時間内に自チームのECサイトのセキュリティ対策をしたり、他チームのECサイトの脆弱性をつくような攻撃をしたりして、自チームのスコアを稼ぎます。
採点は株価だけでなく、ソーシャルエンジニアリングの考え方を加味した方法で実施しました。具体的には、開始前に配布されたパスワードの紙を、競技中に会場内を歩き回る運営に撮影されたら減点という形です。

このように2回戦は、獲得点数を株価と定義することで、参加者のセキュリティ意識が会社の信用度に直結することを、楽しみながら意識できるルールにしました。

テックバトルの内容は好評で、フェス翌日も、「セキュリティ面白い!解けていない問題があるし、楽しかったから続きをやらせて!」という問い合わせが相次ぎ、急遽コンテンツの閉鎖を1週間延長するほどでした。

ペネトレーションテストのハンズオン

今回のテックフェスでは、完全内製の「ペネトレーションテスト・ハンズオン」を90分の枠で開催しました!
このハンズオンは、今回のためにセキュリティ専門チームが作った特製のハンズオンです。
「セキュリティを身近に」をコンセプトに、自社サービスを模した“やられサイト”を用意。セキュリティチームも使用しているテストツール(Burp Suite)を用い、社内事例をベースにした脆弱性攻撃を初心者でも迷わず体験できるよう難易度設計に極限までこだわりました。

ハンズオンが始まるとSlackのスレッドは質問や実況で大変賑わい、「ハッキング体験が楽しい」「リスクを肌で感じた」との声も多く、アンケートでもほとんどの参加者から「大変満足」という回答を頂きました。準備は大変でしたが挑戦して本当に良かったです。
ご参加いただいた皆様、ありがとうございました!

セッション

セッションには、セキュリティを専門とするエンジニア社員を中心に、5名の方に登壇いただきました。
ハイレベルな専門的内容もありましたが、とてもわかりやすくお話しいただき、セキュリティ未経験者・経験者に関わらず学びの多い時間となりました。
発表者の社員の皆さん、お忙しい中ありがとうございました!

  • 「ただの訓練」で終わらせない。標的型攻撃の実態と脅威(レバレジーズ 情報セキュリティ室 杉本)
  • この if 文を突破できる?TypeScriptで学ぶコードの脆弱性(レバレジーズ レバテック開発部 松浪)
  • “いくら損する?“を計算する。EDC手法による定量的なリスク評価と対策効果の可視化(レバレジーズ テクノロジー戦略室 原田)
  • AWSセキュリティインシデント対応実録と教訓(レバレジーズ ソリューション開発部 橘)
  • 退職者アカウントを削除しても要注意!人的脅威からは簡単に逃れられない…(レバレジーズ 情報システム室 高田)

懇親会

テックフェス終了後は、お待ちかねの懇親会を開催!
今年は「縦と横との繋がりを作る」を裏テーマに、コミュニケーションを促進させる話しかけやすい雰囲気の場を設計しました。

会場のメインコンテンツは、参加者全員を巻き込んだ「スタンプラリー」。
「出身地が同じのメンバーを探す」「Slackアイコンしか知らない人と交流する」といったミッションをきっかけに、初対面同士でも自然と会話が弾む仕掛けを用意しました。

結果、アンケートでは参加者の85%が「他事業部の人と交流できた」と回答するなど、まさに事業部の垣根を越えたコラボレーションの種があちこちで芽吹いていました。

もちろん、尽きない会話に華を添えるのは、寿司やピザなどの豪華な食事たち。 そこで生まれた、人とのつながりによる化学反応が、組織の結束をより強固なものにし、熱気冷めやらぬまま幕を閉じました。

最後に

今回のテックフェス2026冬は、「急成長のその先へ。セキュリティで信頼と未来を創る」というテーマのもと、学びやつながりが各所で萌芽する特別な1日となりました。
セキュリティは難しい、発表機会が少ない分野の1つと言われることも多いですが、今回のフェスではセキュリティ専門チームが中心となり、ハイレベルかつワクワクするような時間を作ることができました。

加えて、この1日は運営・参加者全員の笑顔と熱意があったからこそ成り立ったのだと思っています。
いつの時代も、“人と人がつながる力” こそが最大のエンジニアリングではないでしょうか。

最後までお読みいただきありがとうございます!
それでは、次回のテックフェスでまたお会いしましょう!

P.S.

今回のテックフェスも、朝から会場がいい香りに包まれていました。
実は社内エンジニア有志の「コーヒー事業部」がまたまたコーヒーを提供してくれてました!
コードも書けて、豆も挽ける。そんな“フルスタックな男たち”の奮闘記はこちら

レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。
レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。

■関連リンク

~ 過去のテックフェスレポート ~
-【1日密着】AIと共に次世代のエンジニアへ/レバレジーズテックフェス/AIハッカソン - テックフェス2025 夏レポート
- テックフェス2025 冬レポート
- テックフェス2024 夏レポート
- テックフェス2024 冬レポート
- テックフェス2023 春レポート
- テックフェス2022 秋レポート

Tech Leverages 技術活動レポート 25年3Q期号

2025年10〜12月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催や、イベント登壇など多様な関わり方で、合計16件のイベントに参加しました!

AI Builders Dayスポンサーブースの様子

主催・共催技術イベント

AIが変えるアジャイル、変えられないアジャイル〈MeetUp#4〉

9/4に、開発組織の拠点であるポーラ渋谷ビルにて、「AIが現場にもたらした変化」と「AIでは変えられないアジャイルの本質」について語るイベントを開催しました。 (イベント詳細はこちらから)

実装の精度を上げる、設計フェーズのAI活用

10/10に、オンラインにて、「設計のどの部分にAIを使っているのか?」「なぜ、AIに任せられると判断したのか?」といった内容についてリアルな事例を深掘りしていくイベントを開催しました。 (イベント詳細はこちらから)

AI時代を生きるエンジニアのLT&交流イベント〜うひょ氏・ミノ駆動氏登壇〜 集まっtail 2025

10/23に、「AI時代を生きるエンジニアの学びやキャリア」をテーマに、「これからのAI時代を生きるエンジニア」として考えるきっかけとなるような内容の交流イベントを開催しました。 (イベント詳細はこちらから)

AIが変えるアジャイル、変えられないアジャイル

11/6に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話&交流イベントを開催しました。 (イベント詳細はこちらから)

工数・コストを大幅削減!「脆弱性診断の自動化」で実現する持続可能なセキュリティチェック体制

脆弱性診断によるリリースサイクルの遅延やコスト増大、属人化といった課題に焦点を当て、これらを解決するための自動化について、実践事例を交えて紹介するイベントを開催しました。 (イベント詳細はこちらから)

Langfuse Night #4 - Langfuse Team 来日記念 -

LLMエンジニアリングプラットフォームとして国内外で注目度急成長中の Langfuse についてのノウハウを共有するコミュニティイベントを開催しました。 (イベント詳細はこちらから)

紅白LTセッション & 2025年ラストMeetup#6(agile effect)

12/11に、アジャイル開発やチーム改善に関心のある方を対象とした、オフライン/オンライン対話&交流イベントを開催しました。 (イベント詳細はこちらから)

オフライン開催!【プロダクトトップに聞く】未経験プロダクトマネージャーを育てる方法とその実践

12/17に、「未経験のプロダクトマネージャーを育てる方法」にフォーカスし、各社がどのように試行錯誤しながら育成を行っているのかを紐解くイベントを開催しました。 (イベント詳細はこちらから)

レバテックMeetup~2025年のフロントエンド~

12/23に、各社の「2025年のフロントエンド」の取り組みやトレンドについて語り合うライトニングトークイベントを開催しました。 (イベント詳細はこちらから)

イベント登壇

Fivetran Japan - Meet up #2 in TOKYO!

テクノロジー戦略室のゲンシュンが、Fivetran Japan - Meet up #2 in TOKYO! に登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

Data Engineering Summit 前夜祭

テクノロジー戦略室のゲンシュンが、 Data Engineering Summit 前夜祭に登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

Langfuse Night #4 - Langfuse Team 来日記念 -

テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

アジャイルデータモデリング事例共有会

テクノロジー戦略室のゲンシュンが、アジャイルデータモデリング事例共有会に登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

JAWS-UG Presents - AI Builders Day

テクノロジー戦略室の苑田が、JAWS-UG Presents - AI Builders Dayに登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

レバテックMeetup~2025年のフロントエンド~

NALYSYS開発部の縄巻が、レバテックMeetupに登壇しました。 (イベント詳細はこちらから)

speakerdeck.com

カンファレンススポンサー

pmconf 2025 ゴールドスポンサー

12/4に行われたpmconf 2025にて、レバレジーズ株式会社がゴールドスポンサーとして協賛しました。

JAWS-UG Presents - AI Builders Day

12/4に行われたJAWS-UG Presents - AI Builders Dayにて、レバレジーズ株式会社がシルバースポンサーとして協賛しました。

会場スポンサー

TSKaigi 2026 キックオフ

“TSKaigi2026 キックオフ”イベントに、イベントスポンサーとして会場の提供をしました。 (イベント詳細はこちらから)

Vercel Meetup #4 - Vercelの内側見せちゃいます special

“Vercel Meetup”イベントに、イベントスポンサーとして会場の提供をしました。

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。

HRMOS求人ページ

会社説明資料

技術は好きに、運用は本気で。社内ブログ「ぷれぽす」を作って育てている話

はじめに

こんにちは。レバレジーズ テクノロジー戦略室 SREチームの横江です。
普段は、事業部横断で他チームのSRE活動をサポートしています。
今回は、私がpdm(プロダクトマネージャー)を務め、有志メンバーと 「サイドプロジェクト」 として開発した社内テックブログ 「prairie post(通称:ぷれぽす)」 についてのお話です。

ぷれぽすのアイコンです

「社内の課題を解決したい」という思いから始まったこのプロジェクトですが、ただのツール作りには留まらないプロジェクトになりました。

そこは、エンジニアとして技術を楽しむ実験場であると同時に、ユーザーに向き合いサービスを育てる「本気のものづくり」の場でもあったのです。

  • 技術選定の自由度が高い環境で挑戦したい
  • 職種の枠を超えて、技術領域を広げたい
  • 作ったものを改善し続ける「プロダクト志向」な開発がしたい

そんな「技術もプロダクトも好き」なエンジニアの方に、レバレジーズでの開発の雰囲気が少しでも伝われば嬉しいです!


プロジェクトの立ち上がりの背景

「気軽にアウトプットできる場が欲しいから、社内ブログを作りたいな」 プロジェクトが始まったきっかけは、室長からのシンプルな一言でした。

この言葉の裏には、プロジェクト始動のきっかけとなる課題意識がありました。

弊社には多くのエンジニアが在籍していますが、当時はナレッジ共有に「改善余地」があり、横断的に知見を活かせる場づくりが必要だと感じていたのです。

※ 記載している課題感は、当時の状況を踏まえたプロジェクトメンバー個人の視点であり、組織やプロセスそのものを否定するものではありません。

そこで、「それなら自分たちで作ろう」とテクノロジー戦略室内部で有志を募りました。 データエンジニア、TQC(品質管理)、SRE/プラットフォームエンジニア、AIエンジニアなど、多様な職種のメンバーが集結しました!

私たちは、以下の2つを大きな目的として掲げ、サイドプロジェクトを始動しました。

  1. 【課題解決】ナレッジ共有の活性化
    • 事業部を跨いで、エンジニア同士がより活発にナレッジを共有できる最適な場を提供する。
  2. 【技術者の成長】スキルアップと挑戦の機会
    • 開発を通じて自分たちのスキルアップを図り、モダンな技術の検証と実践的な挑戦の場として活用する。

こうしてプロジェクトは始まりましたが、メンバーは皆、本業の業務を抱えています。

忙しい中でモチベーションを維持し続けるには、「開発プロセスそのものを最高に楽しめるものにする」 必要がありました。

そこで私たちは、「技術は好きに遊ぶ」「でもプロダクトとしては本気で作る」 という2つのこだわりを大切にして開発を進めることにしました。


こだわり①:技術的な「実験場」として遊び尽くす

せっかく自分たちで作るなら、開発プロセスそのものを最高に楽しめるものにしたい。

そこで1つ目に大切にしたのが、ここを技術やキャリアの「実験場」にすることです。

1. モダンな技術を自由に選ぶ

普段の業務アプリケーション開発では、どうしても「安定稼働」が最優先されるため、最新技術の導入には慎重にならざるを得ません。
そこで、ぷれぽすでは、社内標準言語の TypeScript をベースにしつつ、それ以外は「今、使ってみたい技術」を自由に選びました。

実際に、「ぷれぽす」での検証を経て、いくつかの技術は本番のプロダクト開発でも採用されるようになりました。

今回はせっかくなので、ぷれぽすを支えるアーキテクチャと技術スタックを少しだけご紹介します! ※詳しい話は今回の趣旨から外れるため、おまけ程度にご紹介します。

AWSアーキテクチャ

ぷれぽす AWSアーキテクチャ

技術スタック

  • SPA構成
  • フロントエンド
    • React/Vite
    • shadcn/ui, tailwindcss
    • TanStack Router & Query
  • バックエンド
    • Hono
  • インフラ
    • K8s(EKS), Helm
    • Terraform
  • 監視ツール
    • Grafana
    • Prometheus, Grafana Tempo
    • OpenTelemetry 他

2. 職種の壁を越えた「やりたい」の尊重

また、技術選定だけでなく、誰が何を担当するかについても、あえて「得意領域」ではなく、メンバーが今チャレンジしたいことを最優先で決めています。

  • データエンジニアやSREバックエンド実装を担当
  • 普段k8sを触っているプラットフォームエンジニア が フロントエンド実装を担当

それぞれ専門領域を持ちながら、希望に応じて新領域に挑戦し、最初は不慣れな部分もありましたが、お互いにコードレビューし合い、知見を深めていきました。

その結果、今ではプラットフォームエンジニアがフロントエンドを、SREがバックエンドの実装を、それぞれ自走できるレベルまでスキルアップしています。


こだわり②:運用は「いちプロダクト」として本気で向き合う

2つ目に大切にしたのは、「本気でプロダクトを作る」 ということです。

技術は「遊び心」を持ちつつも、リリース後の運用や品質には「いちプロダクト」として本気で向き合っています。

どれだけ技術的に面白いものを作っても、ユーザー(社内エンジニア)に使ってもらえなければ意味がありません。

「作って満足」で終わらせないために、チームで以下のような活動を行っています。

  • 知恵を出し合う
    • 定期的にチームで集まり、「どうすれば投稿が増えるか?」「使い続けてもらうには?」を議論しています。
  • 自分たちで目標を立て、リリースする
    • 明確な目標を設定し、自分たちで新機能を企画・開発・デプロイしています。

ただコードを書くだけでなく、限られた時間の中で「使われるもの」を作る難しさと楽しさを味わえるのも、このプロジェクトの醍醐味です。


おわりに

社内の「ナレッジ共有不足」という課題に対し、有志が集まり、自分たちで技術を選び、楽しみながら解決していく。 レバレジーズには、技術的な挑戦による自律的な成長機会があり、プロダクト志向でものづくりができる環境があります!

そんな環境で一緒に働きたい方や、技術が好きでプロダクト志向がある方、ぜひ採用情報をご覧ください。


We are hiring!

この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか?

私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。 あなたからのご応募を、心からお待ちしています。

テックフェス2025 夏レポート

はじめに

こんにちは、レバレジーズ株式会社で普段はSREをしている斉藤です。
そして今回は、「テックフェス2025夏」運営委員長を務めさせていただきました。

本記事では、レバレジーズグループ全体のエンジニアが一堂に会した 「テックフェス 2025 夏」 の様子を紹介します。

今回のテックフェスでは、「AI × エンジニア」 を軸に、
御田稔(みのるん)氏によるAIをテーマにした基調講演、総勢80名が参加したAIハッカソン、AWS社をお招きして行われたAIエージェントのハンズオンなど、さまざまなコンテンツを実施しました。
この一日を通して、「AIをどう活かし、どう学び、どう仲間とつながるか」を全員で考える場となりました。

当日の雰囲気は動画でも紹介していますので、👇️からぜひご覧ください!

www.youtube.com

テックフェスとは

テックフェスは、レバレジーズグループに所属するエンジニアを対象に、半年に一度開催される社内最大級の技術イベントです。
エンジニアが新しい技術に興味を持ち、みんなで学び合うことを目的に、組織全体の技術力と交流を高める“社内の技術祭”として続いています。

このイベントの特徴は、事業部の垣根を超えて“有志のエンジニアたち”が自ら運営していること。
普段は異なる開発チームに所属するメンバーが横断的に集まり、テーマ設計から企画・広報・当日の運営までを自分たちの手で作り上げています。

2025年8月7日に開催された 「テックフェス2025 夏」 のテーマは、
「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」

このテーマを掲げた背景には、会社として掲げている“1兆円規模の企業を目指す”という大きな目標があります。
その未来を支えるエンジニア組織として、AIを軸に次の2つの側面から進化していく必要があると考えました。

① 既存サービスの成長加速
AIを活用することで、日々の開発生産性を大きく引き上げるだけでなく、サービス自体にAIを組み込むことで価値を何倍にも拡張できる。そうした未来が現実的になってきています。
その第一歩として、全エンジニアが“AIを使いこなす”きっかけを提供したいという思いがありました。

② 新規プロダクトの創出
これからのレバレジーズには、既存の延長線ではない新しい事業を自ら生み出す力が求められます。
AIの登場によって、アイデアを形にするまでのハードルは劇的に下がりました。
「自分でも作れるかもしれない」
「ちょっと試してみようかな」
そう思える文化を根づかせるためにも、AIをテーマにしたフェスを通して、全員が挑戦できる環境がすでにここにあることを伝えたい、という狙いがありました。

このような背景のもと、「AI × エンジニア」という共通テーマで、全員が同じスタートラインに立ち学べる1日をつくりました。

下記では今年のテックフェスのそれぞれのコンテンツの様子を書いていきます。

基調講演

今回は御田稔(みのるん)氏に「まだ間に合う!AIエージェントに入門して、LLM時代に生き残れるエンジニアになろう」という題名で、最新トレンドとAIエージェントの今後の展望についてお話ししていただきました。

登壇者紹介

御田稔(みのるん)氏

  • KDDIアジャイル開発センター株式会社 テックエバンジェリスト
  • 技術の楽しさを伝える活動を行いながら、クラウドやAI領域の内製開発・プリセールス・技術コンサルティングに従事しています。
  • AWS Community Hero、AWS Samurai、2025 Japan AWS Top Engineer & All Certs、Qiita 2024 Top Contributor認定
  • 著書:
    • 『Amazon Bedrock 生成AIアプリ開発入門(SBクリエイティブ)』
    • 『やさしいMCP入門(秀和システム)』
    • 『AIエージェント開発/運用入門(SBクリエイティブ)』

学び、感想

今回の基調講演は、まさに「AI × 人間の未来」を体感できる時間でした。
AIエージェントやMCPのような進化の激しいテーマを、AIの進化の流れやトレンドの変化とともに紹介いただき、AIの基礎から最前線までを一気に学べる貴重な2時間でした!

AIの理解が整理され、「実際に触ってみたい」に変わった瞬間
みのるんさんの解説によって、これまで断片的だった AIエージェントやMCPの仕組みが整理され、全体像として理解できた という声が多くありました。「点だった知識が線になった」というイメージに近いと思います。
また、ライブデモでは、Claude Codeを使ったAIコーディング実演を披露していただき、みのるんさんの普段の使い方や、AIコーディングツールを活用する際に意識しているポイントなど、目から鱗の情報が満載でした。
参加後のアンケートでも、「これなら自分も試せそう」「AIエージェントを触ってみたい」など、講演が行動につながったという声が多く寄せられています。

キャリアの話が心に刺さった
30歳を過ぎてからフルスタックに転身したというみのるんさんの言葉に、
「自分もまだ挑戦できる」「AIを家庭教師にして学んでみよう」と勇気をもらった人がたくさん。
特に「手を動かすことが一番の学び」というメッセージは、多くの参加者の原動力になったと思います。

運営として感じたこと
今回のテーマ「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」を、みのるんさんがまさに体現してくれました。
AIはエンジニアを置き換えるのではなく、可能性を拡張する存在。その希望を、会場中が共有できた時間でした。

みのるんさん、心動かされる講演をしてくださり、本当にありがとうございました!
参加者・運営ともに、忘れられない一日になりました。

AIハッカソン

概要

テックフェスで特に盛り上がったメイン企画が「AIハッカソン」です。
当日ランダムに組まれた3人1組のチームが、コードを書かずに自然言語だけでアプリケーションを開発させるバイブコーディング形式で実施しました。
審査については、予選を各ブロックの参加者同士がお互いに発表・評価をし、決勝は各ブロックの1位が全体に対して発表し、参加者全員に加えて決勝用の審査員が評価をする形式で行いました。審査員は、エンジニア職種以外の他部門の方々、基調講演のみのるんさん、AWSハンズオンでいらっしゃったAWS社員の方々にご参加いただきました。

この企画の根底には「自分の考えを、AIの力を使ってすぐに形にできる」という感動を参加者に体験してもらいたいという思いがありました。この企画を単なるおもしろアプリ開発大会で終わらせないために、運営チームで様々な角度で議論を重ねました。運営チームが拘った2つのポイントを紹介します。

評価軸について

どのような観点で、誰が評価するべきか?という点で
当初は「完成度(見た目)」と「アプリの面白さ」の2軸で詰めていたのですが、ウケ狙いを求めたおもしろアプリを作る大会になり得るのが懸念でした。一方、「社会へのインパクト」「マネタイズ」「市場規模」などのビジネス観点を求めてしまうと、参加するエンジニアが評価を適切にできないのが課題でした。
あくまでも社内イベントで事業ハッカソンではないため、今回は「あたなはその事業に参加したいか?」という主観的な熱量をもたせた評価軸を設けることにしました。

環境の整備

当初は、既に業務で利用されているGeminiやCopilotで十分だろう、という声が多数ありました。しかし運営メンバーがBolt.newやReplitといった最新のAIツールを実際に使ったところ、アウトプットのクオリティにかなり感動しました。この感動をぜひ参加者全員にも体験してほしい!という強い思いから、情シス部門と交渉し、Bolt.newやReplitを利用できる環境を用意しました。

当日の様子

予選から、どのチームも想像を超えるクオリティのアプリケーションを生み出してました。予選を勝ち抜いた4チームによる決勝戦は、M-1グランプリ方式のプレゼンバトルに加え、審査員からの鋭い質問との攻防戦も相まってかなり大盛り上がり!優勝はなんと「ヒエログリフ教育アプリ」でした笑。
また終了後のアンケートでは、満足度96%を記録。「楽しかった」「Replitが凄かった」等嬉しい声を多数いただきました。

AWSハンズオン

今回は、AWS社のソリューションアーキテクト(SA)の方を講師にお招きし、「AIエージェントシステムの開発からAWSデプロイまでを体験できる実践ワークショップ」を開催しました。
AIエージェントの仕組みを学ぶだけでなく、実際に手を動かして開発からAWSへのデプロイまでを一貫して体験していただきました。
参加してくださった方々から「AIエージェントに触れる良いきっかけとなった」「理解が深まった」というご意見をいただき、大変嬉しく思います☺️

ご登壇いただいたAWS社のソリューションアーキテクトの方、そしてご参加してくださった皆様、本当にありがとうございました!!

セッション・LT

セッションには、8名の方に登壇していただきました。
発表者の皆さん、ありがとうございました。

  • AIエージェント開発組織を構築してみた(レバレジーズ システム人事戦略室 田中瑚大さん)
  • 開発した/開発中製品をGo To Marketするために生成AIをフル活用してみた(レバレジーズ NALYSYS開発部 瀬上真宏さん)
  • 失敗から学ぶAI駆動開発:ハッカソンで直面した課題と打開策(レバレジーズ テクノロジー戦略室 苑田朝彰さん)
  • コンサルティングサービスの仮想化を通じたAI時代における新しいBPR方法論(レバテック クオリティアシュアランス事業部 篠塚亮彦さん)
  • Devinとは何だったのか(レバレジーズ NALYSYS開発部 桐生直輝さん)
  • AIで成長を加速させる ─ Obsidian in Cursor 活用(レバレジーズ ソリューション開発部 斎木克馬さん)
  • AITuberの構築に伴うコンテキスト管理と記憶要約戦略(レバレジーズ テクノロジー戦略室 原田将貴さん)
  • 「感謝」を「コード」で紡ぐ:LevLetter開発秘話とAI時代のキャリア(レバレジーズ メディアシステム部 阿部倉怜さん)

懇親会

テックフェス終了後には、懇親会も開催。事業部の垣根を越えた交流が生まれていました。
ここでも「仲間とつながる」というテーマのとおり、普段なかなか交流のない事業部同士のエンジニアたちが垣根を越えて盛り上がる時間になりました。

会場では、フェスで登壇・体験した内容をもとにしたテックフェスクイズ大会を実施。学びを振り返りながら、自然と会話と笑顔が生まれていました。

さらに、テーブルにはピザ、寿司、お酒など豪華な食事も用意され、「技術×食×人」の三拍子がそろった最高の締めくくりとなりました。
最後まで“お祭り”らしい熱量と笑顔に包まれた夜でした。

最後に

今回のテックフェス2025夏は、「Leverages Singularity 〜仲間とつながり、AIとともに歩む未来〜」というテーマのもと、AIを軸に“学び・挑戦・つながり”が交差する特別な1日となりました。
参加者の全体満足度 8.4 / 10、AI活用への期待値 7.9 / 10 と、過去最高の評価をいただきました。
基調講演・AIハッカソン・ハンズオン・LT・懇親会のすべてが連動し、「AIが人の創造力を拡張する瞬間」をみんなで体感できたことが、今回最大の成果です。

運営委員長として迎えた初のテックフェス。
250名近くが参加する大規模イベントということもあり、正直、準備段階からずっと緊張していました。
それでも、当日あの熱気と笑顔に包まれた瞬間、「やってよかった」と心から思えました!
何より、このテックフェスを支えてくれた13名の運営メンバーに心から感謝しています。
それぞれが本業の合間を縫いながら、企画・広報・司会・映像・装飾・運営と全力で取り組んでくれました。
そして、当日の様子を撮影・編集を担当してくださった採用広報チームの清水さん。
フェスの熱量をそのまま映像に残してくださり、本当にありがとうございました!(動画はこちら )
みんなの笑顔と熱意があったからこそ、このテックフェスは成功しました。
AIの時代になっても、“人と人がつながる力”こそが最大のエンジニアリングだと思います。

最後までお読みいただきありがとうございます!
それでは、次回のテックフェスでまたお会いしましょう!

レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。
レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。

会社説明資料

エンジニア職採用|レバレジーズ株式会社

P.S.

今回のテックフェス、朝から会場がいい香りに包まれていたのをご存じでしょうか?
実は社内エンジニア有志の「コーヒー事業部」がコーヒーを提供してくれてました!
コードも書けて、豆も挽ける。そんな“フルスタックな男たち”の奮闘記はこちら

過去のテックフェスレポート

エンジニア歴 2 年目の私が、SaaS のデザインシステムを導入した話

こんにちは、レバレジーズの HR テック事業部でフロントエンドエンジニアをしている縄巻です。

  • 「日々の実装タスクをこなすだけじゃ、なんだか物足りない…」
  • 「もっとプロダクトの根幹に関わるような、インパクトの大きな仕事がしたい!」

エンジニアとして少しずつ経験を積んできた今、そんな風に感じている方はいませんか?

この記事では、実務経験 2 年未満だった私が、チームをまたがる大きな課題であったデザインシステムの導入に、オーナーシップを持って挑戦した経験をお話しします。

この記事を読めば、若手であっても自ら課題を発見し、最新技術を駆使しながら事業を前に進めていける、レバレジーズの挑戦的な文化を感じていただけるはずです。

そもそもデザインシステムとは?

本題に入る前に、少しだけ「デザインシステム」という言葉について説明させてください。

デザインシステムとは、単なる UI コンポーネントのライブラリではありません。それは、一貫したユーザー体験を効率的に提供するための「仕組み」そのものを指します。具体的には、再利用可能な UI コンポーネント、デザインの原則やガイドライン、そしてそれらを運用するためのルールやツール群を体系的にまとめたものです。

デザイナーとエンジニアが共通の言語と思想を持つことで、プロダクト全体の品質と開発速度を飛躍的に向上させることを目的としています。

課題:オーナー不在のデザインシステム

私が所属する SaaS プロダクトには、もともと「共通コンポーネント」として管理されている npm パッケージが存在しました。 しかし、専任のメンテナーはおらず、各開発者が必要に応じてコンポーネントを“継ぎ足し”していく運用が続き、体系的な管理がなされていない状態でした。

その結果、開発現場では、次のような数々の問題が起きていました。

  • Figma と実装の乖離:Figma にはないのに、React コンポーネントだけが存在する。
  • 命名の不統一:Figma と React でコンポーネント名が異なり、探すだけで一苦労。
  • 巨大モノリスパッケージ:たった一つのコンポーネントを更新したいだけなのに、パッケージ全体への影響調査が必要になる高い更新コスト。
  • ドキュメントとテストの不足:誰も正確な仕様を把握できない、ドキュメントもテストもないコンポーネントたち。
  • 過剰な依存関係:特定のライブラリに依存し、他の場所で再利用できないコンポーネント。
  • アクセシビリティの欠如:キーボードで操作できない、スクリーンリーダーで読み上げられないなど、アクセシビリティへの配慮不足。

これらの課題は、多くのメンバーが「問題だよね」と認識しつつも、日々のサービス開発が優先され、誰も根本的な改善に着手できずにいました。

「誰かがやる」から「自分がやる」へ

こうした状況に、私は強い危機感を覚えていました。

最初は、個人として既存コンポーネントのメンテナンスや機能追加といったコントリビュートを始めました。しかし、プロダクトが急成長する中で、一個人の部分的な改善では到底追いつかないことはすぐに明らかになりました。

そこで私は、上長との 1on1 でこの問題の大変さと、抜本的な改善の必要性について話しました。そして、「誰かがやってくれるのを待つのではなく、自分が主体となってこの状況を解決したい」と伝え、この課題のオーナーになることを志願しました。

幸いにも、同時期にジョインしたデザイナーも既存の Figma 運用に強い課題意識を持っていました。こうして、エンジニアリングとデザインの両側面からアプローチする「デザインシステム刷新プロジェクト」が、ついに本格始動しました。

そして、このプロジェクトの担当エンジニアは、私一人。もちろん不安はありましたが、それ以上に「この状況を自分の手で変えられるんだ」というワクワク感の方が大きかったのを覚えています。

実行:若手の裁量で進めた課題解決

山積する課題を解決するため、技術選定はゼロベースで、その意思決定はすべて私に一任されていました。

若手の提案だからと色眼鏡で見られることは一切なく、ロジックと熱意さえあれば挑戦させてもらえる。そんな文化が、このプロジェクトを前に進める大きな力になりました。

ここでは、導入した主要な技術や、開発を加速させた AI ツールの活用法について解説します。

1. 開発体験の向上を目指した基盤整備とコンポーネント再開発

まず、デザイナーとエンジニア間の連携をスムーズにするため、Figma コンポーネントの再設計と命名規則の統一を行い、React コンポーネントもより使いやすい形に再定義しました。これにより、デザインと実装の間の認識齟齬をなくし、コミュニケーションコストを削減しました。

幸いなことに、レバレジーズにはレバテックの「VoLT」というデザインシステムをリードしたデザイナーが在籍しており、その知見を惜しみなく共有してもらえました。

参考:レバテックのデザインシステム「VoLT」

裁量を持って挑戦できるだけでなく、こういった組織の横の繋がりからノウハウを吸収できるのも、大きく成長している会社ならではの魅力だと思います。

2. 独立したパッケージとして管理

巨大な単一パッケージが引き起こしていた更新コストの問題を解決するため、モノレポ構成への移行を決定しました。

Nx なども候補に上がりましたが、私たちのチーム規模や設定の学習コストを考慮した結果、ビルドキャッシュによる高速な CI/CD とシンプルな設定が魅力のTurborepoを選択しました。また、pnpmを組み合わせることで、ディスク容量を効率的に利用しつつ、厳密な依存関係管理を実現しています。

これにより、各コンポーネントを独立したパッケージとして管理し、サービスごとに必要なコンポーネントだけを選択的に更新できる、柔軟な運用体制を構築しました。

3. Radix UI でアクセシビリティを当たり前に

コンポーネントの品質、特にアクセシビリティを担保するために、ヘッドレス UI ライブラリであるRadix UIを採用しました。

MUI や Chakra UI のようなスタイル付きのコンポーネントライブラリも検討しましたが、プロダクト独自の厳密なデザイントークンを適用する必要があったため、スタイリングの自由度が低い点は懸念でした。

Radix UI は、スタイルを持たず、WAI-ARIA に準拠した高品質な振る舞いのみを提供してくれます。 これにより、デザインの制約を受けることなく、アクセシビリティを当たり前の品質として確保することができました。

4. Storybook によるドキュメント管理

ドキュメント不足を解消し、コンポーネントの利用を促進するためにStorybookを導入しました。

コンポーネントのカタログツールは他にも存在しますが、業界のデファクトスタンダードであり、アドオンによる拡張性が非常に高い点を評価し採用しました。

特にテストとの連携は強力です。Storybook のplay関数を使って定義したインタラクションテストを、vitestがテストファイルとして実行する仕組みを導入しました。これにより、Playwright 経由で実際のブラウザを起動してコンポーネントの操作をテストできるため、より信頼性の高い品質保証体制を構築できています。

また、各コンポーネントの Props、使用例、インタラクティブなデモを Storybook 上で一元管理することで、誰もがコンポーネントの仕様を容易に理解できる仕様書として機能させています。

5. AI は、本質的な仕事に集中するための“相棒”

担当エンジニアは私一人。これらの施策を、通常のサービス開発と並行して進める上で、AI コーディングツール(Cursor, Claude Code など)の活用は、もはや“選択肢”ではなく“必需品”でした。

これは、単に流行りの技術を使いたかったからではありません。たった一人のリソースで、最速で価値を届けるための、極めて合理的な戦略でした。

コンポーネントの雛形作成、Storybook のドキュメント生成、リファクタリング、単体テストの実装……。もしこれら全てを手作業でやっていたら、半年で今の状態に到達することは不可能だったでしょう。

定型的な作業を AI という“相棒”に任せることで、私はより本質的なコンポーネントの設計や、デザイナーとのコミュニケーションに集中できました。

成果:個人の挑戦がもたらしたチームへの好影響

デザインシステムの構築から約半年、その効果を測定するために、利用しているエンジニアを対象としたアンケートを実施しました。

開発体験の向上を裏付けるデータ

アンケートでは、デザインシステムの貢献度について 5 段階評価で回答してもらいました。

  • UI 実装速度の向上:4.05 点
  • UI の一貫性担保:4.27 点
  • 総合的な貢献度:4.27 点

特に、UI の一貫性担保や総合的な貢献度で高い評価を得られたことは、このプロジェクトの目的を達成できた証だと感じています。 さらに、これらの改善活動により、フロントエンド全体の UI 実装速度が 30% 向上したこともデータで確認できました。

開発現場からのリアルな声

定性的なフィードバックとして、開発者からは以下のような嬉しいコメントが寄せられています。

「Figma のコンポーネント名と実装名が一致しているので、迷わず実装できるようになった」 「Storybook を見れば使い方が一目でわかるので、コミュニケーションコストが大幅に削減された」 「これまで各サービスで独自実装していた UI が共通化され、無駄な実装がなくなった」

エンジニア歴 2 年目の私の活動が、実際に事業やチームの開発体験にこれだけポジティブな影響を与えられたという事実は、私にとって大きな自信になりました。

今後の展望:AI で開発生産性をさらに高める

デザインシステムは作って終わりではありません。むしろ、ここからが本当のスタート。このデザインシステムを、事業の成長をさらに加速させる強力な武器へと育てていくために、短期・長期でこんな野望を抱いています。

短期的な目標:コンポーネントの拡充と適用範囲の拡大

まずは、デザインシステムがカバーする UI パターンを増やし、より多くの開発シーンでその価値を発揮できるようにすることに注力します。

  • コンポーネントの拡充:現在の基盤に加え、より複雑で多くのサービスで必要とされるコンポーネントを拡充していきます。デザイナーと協力して汎用的な仕様を定義し、開発を進めることで、各サービスでの車輪の再発明をなくします。
  • 適用範囲の拡大:構築したデザインシステムを、プロダクト内のさらに多くのサービスに展開していきます。そのために、既存 UI からの移行ガイドを整備したり、導入を検討しているチーム向けの勉強会を開催したりと、導入をスムーズにする活動に力を入れていきたいです。

これらの活動を通じて、デザインシステムをプロダクト開発に不可欠な存在へと成長させていきます。

長期的な夢:AI とデザインシステムを融合させ、仮説検証の速度を極限まで高める

そして長期的には、AI の力を最大限に活用し、「デザインと実装の境界線を溶かす」ことに挑戦したいと考えています。

皆さんも、Figma のデザインを実装に落とし込む際の、ちょっとしたズレや手戻りに悩まされた経験はありませんか?私たちは、その根本的な課題を解決したいのです。

目指すのは、例えばこんな世界です。

  • デザイナーが Figma でワイヤーフレームを描き、「ここのボタンは、ユーザー登録を促すためのものです」といった意図を AI に伝える
  • AI がその意図を解釈し、デザインシステムに定義されたコンポーネントの中から最適なものを提案。さらに、A/B テストのための複数のデザインパターンを自動で生成してくれる
  • プロダクトマネージャーやデザイナーは、生成された実際に動くプロトタイプを使って、エンジニアが一行もコードを書く前にユーザーテストを実施する

この仕組みが実現すれば、アイデアの仮説検証サイクルは、数週間から数時間へと劇的に短縮されるでしょう。エンジニアは「Figma を再現する」作業から解放され、より複雑なロジックの実装やアーキテクチャ設計といった、本質的な課題解決に集中できます。

「自ら課題を見つけ、最新技術を駆使して事業を前に進めていける」—そんなレバレジーズの文化を体現するような、未来の開発生産性を創り出すのが、私の野望です。

まとめ:私がレバレジーズで働く理由

ここまで、エンジニア歴 2 年目の私がデザインシステムという大きな課題に挑戦できた話をしてきました。

なぜ、このような挑戦ができたのか。それは、レバレジーズに根付く「オーナーシップを尊重する文化」と「挑戦を推奨する風土」があったからだと思います。

大きな課題に対して、たとえ担当者が一人であっても、「やりたいです!」と手を挙げれば、年次に関係なく「まず、やってみなよ」と背中を押してくれる。たとえ実力不足な面があっても、周りの先輩たちがサポートしてくれます。そして、その挑戦を「いいね!」と称賛してくれる仲間がいます。

また、Cursor や Claude Code といった最新の AI ツールをいち早く全社に導入するなど、世の中の新しい流れを柔軟に取り入れ、開発体験や品質について妥協せず考え抜く文化も、私にとって大きな魅力です。「現状維持」ではなく、常により良いプロダクト、より良い組織を目指して本気で議論できる環境が、ここにはあると思います。

もし、この記事を読んでいるあなたが、

  • 「言われたものを作るだけじゃ物足りない」
  • 「もっと主体的に、事業にインパクトを与えるような開発がしたい」
  • 「自分の仕事に責任と誇りを持ち、最高のプロダクトを追求したい」

そう感じているなら、レバレジーズは最高の環境かもしれません。

私たちと一緒に、未来の開発生産性を創りませんか?

最後までお読みいただき、ありがとうございました!

We are hiring!

この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか?

私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。

あなたからのご応募を、心からお待ちしています。


■会社説明資料

speakerdeck.com

■採用情報はこちら(HRMOS)

hrmos.co

■まずはカジュアル面談から

hrmos.co

■開発部の雰囲気がもっとわかる動画はこちら!

Tech Leverages 技術活動レポート 25年2Q期号

2025年7,8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催や、イベント登壇など多様な関わり方で、合計9件のイベントに参加しました!

※OctoNihon登壇の様子

主催・共催技術イベント

未来を拓くAI技術〜エージェント開発とAI駆動開発〜

7/8に、オンラインにて、AI駆動開発について実際の運用のノウハウも交えながら、現役エンジニアがこれらの技術の基礎から実践的な内容を解説するイベントを開催しました。 (イベント詳細はこちらから)

Agile Effect MeetUp #3 アジャイル実践者の“言えなかったこと”を話す夜

7/10に、開発組織の拠点であるポーラ渋谷ビルにて、アジャイル開発に関心のある方を対象とした、オフラインの対話&交流イベントを開催しました。 (イベント詳細はこちらから)

AI・LLM活用による事業ドライブの実践

7/16に、Sansan株式会社の本社であるサクラステージにて、レバレジーズ、Sansan、Macbee Planetの三社共同主催で、AIを事業に適合させる実践的なプラクティスを共有するLTイベントを開催しました。(イベント詳細はこちらから)

Devin/Cursor/Cline全社導入 セキュリティリスクにどう対策した?

7/23に、オンラインにて、AIコーディングエージェントをスピーディーに全社導入した、DMM .com、エムスリー、freee 3社の実践事例をもとに、具体的なセキュリティ対策とその導入プロセスを語るイベントを開催しました。 (イベント詳細はこちらから)

【Product × AI Night】AI時代のつくりかたを語ろう

8/28に、開発組織の拠点であるポーラ渋谷ビルにて、レバレジーズ、Anotherworksの二社共同主催で、開発とプロダクトの二観点でのAI利用を語るLTイベントを開催しました。 (イベント詳細はこちらから)

AIが変えるアジャイル、変えられないアジャイル〈MeetUp#4〉

9/4に、開発組織の拠点であるポーラ渋谷ビルにて、「AIが現場にもたらした変化」と「AIでは変えられないアジャイルの本質」について語るイベントを開催しました。 (イベント詳細はこちらから)

イベント登壇

未来を拓くAI技術〜エージェント開発とAI駆動開発〜

テクノロジー戦略室の安藤が、未来を拓くAI技術〜エージェント開発とAI駆動開発〜 に登壇しました。 (イベント詳細はこちらから)

https://speakerdeck.com/leveragestech/wei-lai-wotuo-kuaiji-shu-ezientokai-fa-toaiqu-dong-kai-fa

OctoNihon

テクノロジー戦略室の竹下が、OctoNihonに登壇しました。 (イベント詳細はこちらから)

https://speakerdeck.com/leveragestech/speckitdedokomadedekiru-kosutohadorekurai

会場スポンサー

CTO協会スナック理事

“CTO協会スナック理事”イベントに、会場の提供をしました。 (イベント詳細はこちらから)

React Tokyo ミートアップ #9

“React Tokyo ミートアップ #9”イベントに、イベントスポンサーとして会場の提供をしました。 (イベント詳細はこちらから)

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。

HRMOS求人ページ

会社説明資料

「新卒から圧倒的成長ができる」のはナゼ?入社〜半年のリアルな証言!

1. はじめに:「新卒からでも圧倒的に成長・活躍できる」と謳うレバレジーズ。これはナゼなのか?

「圧倒的成長・早期活躍」を軸に就活していた私 “スガノ” は、レバレジーズに新卒入社し、2025年9月現在、半年が経ちました。そんな私だから語れる、「新卒からでも圧倒的に成長・活躍できる」のはナゼなのかを、2025年新卒入社〜半年実際にした体験をベースに、結論→根拠となる2つの事実、という順序で証言します。
レバレジーズで叶う「圧倒的成長環境」とは?どんな「活躍」ができるのか? このブログにて、その真相をぜひ、あなたの目で確かめていただきたいです。

2. 結論:”新卒研修中”でも仕事を”創れる”!

成長・活躍ができると言える根拠は、以下の2点です。

1. 入社4ヶ月で、かつ研修中にも関わらず、熱意と挙手によって仕事を創れたので、成長の初速が大きい
2. その打席で、役員陣や活躍する優秀先輩社員との交流ができ、更なる成長・活躍の土台が形成された。

それを証明する2つの事例を、これから具体的にお見せします。

3.1. 事例1:新規事業開発コンテストに参加し、圧倒的行動量を発揮できた!

7月某日の朝、私はあるマネジャーから次のことを言われました。

「昨日、僕らは岩槻さん(レバレジーズ代表取締役)に、僕らのチームの事業案を壁打ちしたね。そこで頂いたフィードバックを元に、本部長と精査しながら〇〇と△△(商社や物流等、超大手複数社)にヒアリングしようか。スガノ君はアプリ開発も、◻︎◻︎部長と連携頼んだ!試算も含め任せたよ!」

研修中の新卒が、入社4ヶ月目でする会話にしてはかなり濃厚ですが、事実です。 では、この前にどのような経緯があったのか。時間を巻き戻してみましょう。

時は4月。入社直後の新卒全体研修の最中、運営側から以下のアナウンスがありました。 「近々、LEGOの参加申し込みが開始されます!熱意のある人は、ぜひ応募してくださいね!」 それを聞いて私は、「なぜここでデンマークのおもちゃの話題になるんだ?」と訝しみました。が、よくよく聞いたら、LEGOとは

  • レバレジーズ社内で行う、新規事業開発コンテストの名称
  • 優秀な社員が集い、5人チームを組んで、2泊3日で社長や役員等と合宿する催し

とのことでした。...これは応募するしかない!「圧倒的成長と早期活躍」を軸にしていた私は、溢れる熱意を応募フォームに書き綴り、参加を祈りました (LEGO詳細は、以下をご覧ください)。
www.youtube.com

無事選考を突破し、約3ヶ月、新卒研修と並行して、優秀な方々と共にアツい「活躍・成長・学び」の日々を過ごしました。私が行った「活躍」ついて、実例を3つ取り上げます。

①圧倒的量の案をアウトプット

事業案の業界を定めた後、チームメンバー間で事業案を出すフェーズがありました。他の方が0~2案を出す中、私は40を超える事業案をアウトプットしました。実際に、その中から良いものを追加調査するなど、その後のチームに大きな好影響をもたらすことができました。

②普段やらない体験で、生の声と先端技術の知見を回収

例えば、自らの意思で地元のボランティアをしたり、朝4時に起床して某市場を視察したり、関連する書籍を10冊ほど購入して読み漁ったりしました。某市場の視察時は、その場の資料や展示物を眺めるだけではなく、サポート窓口係の方や外国人観光客、清掃や交通整理をする方々にも個別に話しかけ、徹底してリアルな声を得ました。これを、何の活動・目的もなしに突然しようとする人は少ないでしょう。この行動を生んだ熱源は、LEGOなのです。

③モックをvibe coading!

昨今、動くプロダクトによって、関係者間でイメージを具体的に共有するのは当たり前になっています。開発職がチームで私のみだったので、このプロダクト作成を一手に任されました。
AI OCRを使って多様な見た目の書類のPDFを読み込み、グラフや文章を生成するネイティブアプリを作ったり、それを社員別に管理するため、組織図と対応させたwebアプリを作ったり...。
開発職の私だからこその介在価値を発揮しました。

こうした能動的な活動から、オリジナルの価値提供を重ねていけました。 また、成長・学びについては、例えば以下があります。

  • 経営企画本部長から事業立案に関する講義を限定受講
  • 他職種の解像度が爆上がりし、活躍する人の仕事を文字通り真隣で体感
  • 役員の方々や活躍社員と、オン/オフで議論や交流ができ、ビジネスへの熱意と理解が段違いにレベルアップ
  • 何より、滅多にできない新規事業立案を、3ヶ月かけて実学的に学んで実践

このLEGOを通じて、何段階もビジネスパーソンとして磨き上げられたと胸を張って言えます。 この参加を経て、私と面識がない方からも
「LEGOに参加してるの?研修と並行して頑張ってるね!」と褒めてもらえたり、
「あ、LEGOに参加してた子でしょ、社内報とかYoutubeで見たよ!
と声を掛けてもらえたりしました。 これはまさしく「活躍」であり、「圧倒的成長」だと言えると思います。

LEGOには、結果で選ばれた優秀な先輩社員も当然いますし、ポテンシャル選抜もしてくれるおかげで私は打席に立てました。本当に感謝しかないですし、手を挙げて大正解だったと思います。

おまけに、声をかけてくださった方々や一緒にLEGOに参加した有志、役員陣全員に触れ、感じたことがあります。それは、私がレバレジーズへの入社を決めた大きな理由の一つである「一緒に働きたいと思える”良い人”(熱量、スキル、他者への感情貢献力が高い優秀な人)」が多いという面です。改めて、レバレジーズは期待値を超えてくるなぁ、と実感した次第です。

3.2. 事例2:入社4ヶ月目で、プロジェクトマネジャー(PM)になり、全社的プロジェクトを任された!

7月上旬。新卒研修を行っていた私は、エンジニア組織の本部長から次のことを言われました。

「例のプロジェクトについてだけど、PMになりたい?他の選択肢は、メンバーとして引き続き参画するか、他の人に完全に渡すか、とかだけど。」
(このプロジェクトとは、社内ネットワークを最適化させるプロジェクトの一環で、エンジニア組織の内外の部署や、外部の複数企業とも連携する、全社的なものでした。)

これらも新卒研修やLEGOと並行ですが、当然、回答は当然一択ですよね。
「もちろんPMやります。私でよろしければ、ぜひ任命お願いします!」
この事実についても、「他との比較」と「具体的学び」の2点で深掘ってみます。

まず比較として、一般的に大手企業でマネジャー職は入社5~10年目、ベンチャー企業でも3~4年目とかでも珍しくないです。
しかしこれらと比べ、レバレジーズで私はたった4ヶ月でPM職を創り出せました。正直、「自分次第で早期から活躍・成長できる」と聞いて入社はしたものの、ここまでの環境とは予想していませんでした。LEGOの時と同様、新卒研修中にも関わらず、熱意と挙手でここまで行えたこと、これら成長の早さと大きさには感動と感謝しかないです。このPM経験は「圧倒的成長・早期の活躍」の機会そのものでした。

学びに関しては、マネジャーのやり方を「知る」のと「実行する」のは雲泥の差だと、実務レベルで学ぶことができました。もちろん、コンピュータサイエンス的なハードスキルのノウハウはとても勉強になりましたが、同時に大きかったのがソフトスキル面の学びです。順に具体を示します。

ハードスキル

例えば「netstat | grep tcp4 | wc -l」というコマンドの存在と、それでどんな情報が入手でき、その情報が何に使えるかを説明できるようになりました。これによって、NAT(NAPT)やセッション数、webアプリへの理解がより深まりました。

ソフトスキル

幅広い学びとして、対人折衝(期待値調整)力、ピープル・タスクマネジメント、リーダーシップやイニシアチブ、巻き込み力などがありました。以前から私は書籍や、学生時代・研修等でのリーダー経験から、ノウハウは持っていたのですが、会社組織でのPMはそれらとは全く異なりました。
例えば、連絡手段や頻度は何が最適で、タスクはどの粒度に分解して誰に割り振るのか、どう割り振るのか(解決策を探るhow的思考だけでなく、そもそも解くべき問を立てるwhy的思考は重要で、ハードルも高い!)、頭で考えるだけなら難しくないとは思います。
しかし、同じ脳みそを共有しているわけではなく、初対面で年齢・スキル・価値観、抱えている仕事もバラバラなメンバーらと協働し、タスクを理想的に実行していくのは、想像以上に難儀しました。
ここでの学びは、学生時代やインターンのそれとはレベルが異なり、大変貴重で実践性に溢れていました。

このPM経験によって、活躍する先輩らからも
「もうPMやってるの?まだ半年すら経ってないよね?早いね!」と認められたり、
外部勉強会でお会いした、外部のITベンチャー企業の方からも
「君と話してて、本当に新卒とは思えないよ。え〜、うちに来ない?(笑)」と半ば冗談を言われたりしています(笑)。
ここでの多種多様な経験が、今後の更なる「活躍」の土台となると確信していますし、そのために一層努力する所存です!

4. さいごに

客観的事実から見ても「自分次第で仕事は創れるし、圧倒的に成長・活躍できる!」と言えると思います。もしあなたが、学びや成長、活躍を軸にしているなら、レバレジーズという会社はその期待に応えるどころか超えてくる企業の一つだと言えます。これは上記を経験した私が、自信を持って保証します!

ここに”環境”は揃っています。どう輝くかはあなた次第。「成長したい!」「活躍したい!」と熱く燃える心をお持ちなら、後述のリンクの参照や、弊社社員とのカジュアル面談、または選考の次のステップへ向かうことをおすすめします。噂レベルではない、本当にレバレジーズで働く人から生まれるモノは熱く、面白いと思いますよ?

このブログが、あなたの企業選び、そして未来への一歩のきっかけになれば、筆者冥利に尽きます。最後までお読みいただき、誠にありがとうございました。

新卒エンジニアの1ヶ月目について知りたい!➡︎レバレジーズの新卒エンジニアって何するの?そんな君に伝えたい、1ヶ月目のリアル。 tech.leverages.jp

開発部全体をもっと知りたい!➡︎ 【密着】レバレジーズで活躍する26歳中途エンジニアの1日
www.youtube.com
会社説明資料:
https://speakerdeck.com/leverages/leverages-hui-she-shao-jie-zi-liao-zhong-tu-cai-yong-xiang-ke
HRMOS求人ページ:
https://hrmos.co/pages/leverages/jobs?jobType=FULL&category=1819634044861276161

なぜレバレジーズのエンジニアはコーヒーを淹れるのか?テックイベントで200杯提供した「珈琲事業部」に見る企業文化

読む前に

この記事に出てくる「珈琲事業部」というのはNALYSYS開発部というシステム本部内開発部の有志による取り組みのことです。実際の事業部ではありません。
万が一珈琲事業部に入りたくてレバレジーズを志望される場合は、システム開発部のエンジニアとしてご応募ください。

はじめに

こんにちは。レバレジーズでHRTech系SaaS NALYSYSの開発チーム、NALYSYS開発部でEMをやっております、下畑と申します。
私個人の珈琲入れてみたいなという気持ちから始まったNALYSYS開発部珈琲事業部という取り組みが、全社のテックイベントにて珈琲スポンサーとしてエンジニアたちに珈琲を振る舞うまでに至った経緯を書いてみました。

レバレジーズの雰囲気や楽しさ、珈琲事業部に対する取り組みへの真剣さが伝わる記事になっておりますので、ぜひ読んでみてください。

読むとわかること

  • レバレジーズシステム本部に入ると美味しい珈琲が飲める
  • レバレジーズシステム本部に入るとさまざまな味の珈琲が飲めて珈琲の魅力に気付ける
  • 会社の人たちに珈琲を淹れると普段エンジニアが得にくい喜びが得られる
  • やりたいことを損得なしに一緒に楽しんでくれる人や応援してくれる人が社内にいること
  • 珈琲事業部の本気度
  • レバレジーズシステム本部の雰囲気

ことの発端

名古屋に住んでいる私の友人からGolpie Coffeeという珈琲ロースターの存在を教えてもらいました。ここの豆を納得いく美味しさで淹れるのに半年かかった、という面白い話も同時に教えてもらったので自分もチャレンジしてみたくなりました。

ただ、珈琲を淹れるための器具を調べてみると、そこそこお金をかけないといけない気がしてきて、始めることを躊躇しておりました。

そんなことを考えていたおり、チームメンバーにも珈琲好きがいることが判明。
自分のためだけに器具を揃えるのではなく、彼らが道具を使って会社で珈琲を淹れてくれるのであればいい投資になるなと思い、購入を決意しました。

Go!珈琲事業部!

どうやって淹れるの?

LIGHTUP COFFEEというお店が三鷹にあります。ここではハンドドリップ講習をやっているので、まずは自分がノウハウを収集するために赴きました。
ここでの体験はとても面白かったです。講師が教えてくれたレシピをもとに生徒が珈琲を淹れるのですが、生徒が淹れた珈琲の味がそれぞれ全然違うことに驚きました。
先生が淹れてくれた珈琲は酸味や甘味などのバランスがちょうどよくカドがない珈琲だったのですが、生徒が淹れたものは酸味が強調されていたり、苦味が強調されていたりと、これはがんばり甲斐がある趣味だなと思いました。

淹れてみよう

講習で教えていただいたレシピと珈琲器具とGolpie Coffeeの豆を引っ提げて出社しました。Golpie Coffeeの豆はちょっと高いものでしたので、各フロアにある全自動コーヒーマシンに入っている豆を拝借し、淹れる練習から始めました。

マシンでいれるより美味しく淹れられて嬉しかったのを覚えています。

いい豆夢気分

Golpie Coffeeの豆を3種類購入しました。
どれも中煎り(通常のお店の浅煎り)のものでしたが、1つとても妖艶な香りのする豆がありました。珈琲の実から豆を取り出す精製という工程がありますが、ダブルアナエロビックという方法で精製されたこの豆は、珈琲とは思えないほどのフルーツ感で、パイナップルみたいな味がしたのを覚えています。

みんなでこの珈琲を飲み、珈琲の可能性を珈琲事業部内で共有できたことで、メンバー各々がいろんなお店で珈琲豆を購入してくるようになります。

豆主制度

自分たちで珈琲豆を購入して、自分たちで飲むのもいいのですが、私たちが所属しているNALYSYS開発部のメンバーたちにも飲んで欲しいなという思いが出てきました。
一方で、美味しい珈琲豆は高価なものが多いため、無償で提供し続けるには無理があると感じてもいました。

そこで、開発部のメンバーから豆を提供してもらい、自分たちは技術を持って飲める状態の珈琲をお返しする、という循環を作ろうと考えました。

豆主制度と名付け、現在もこの方式で運用しています。
珈琲好きな開発部メンバーに最初は辻斬りならぬ辻淹れを行い、胃袋をつかみます。
取り組みを面白がってくれた人や胃袋を掴まれた方達が豆主様になってくれました。

通常エンジニアは顧客との距離が遠かったり、自分1人でやった仕事が顧客から評価されることは多くはありません。
自分が淹れた珈琲を豆主様に直接提供したときに感謝される営みはエンジニアにとっては尊いものだと思えました。同じように、自分達で作ったものを自分達で営業するという取り組みをNALYSYS開発部の一部のチームが行なっていますが、彼らはこの喜びの味を知っているのかもしれません。

認知拡大へ

珈琲事業部の取り組みは口コミでNALYSYS開発部以外にも知られることとなります。
レバレジーズではslackに部活チャンネルというものを作ることができます。事業部メンバーがzc-珈琲という部活チャンネルを作ってくれたため、そこに珈琲を注文するためのワークフローを作りました。

会社に対してオープンな場を提供することによって、NALYSYS開発部だけでなく、システム本部長や別事業部の方からの注文も入るようになりました。
この取り組みによって珈琲事業部の名前が色々なところに広まっていくことになりました。

Go!テックフェス!

テックフェスで珈琲スポンサーもやるぞ

レバレジーズでは年に2度テックフェスというシステム本部全員参加型の勉強会があります。
過去のテックフェスの様子についてはこちらをご覧ください。
tech.leverages.jp

テックフェスの運営さんと珈琲事業部のメンバーの仲が良かったこともあり、珈琲事業部がテックフェスで珈琲を提供する話が持ち上がりました。
200人規模のイベントでしたので、それなりに準備が大変なんだろうなと思いつつも、面白そうだったので参加を表明しました。

エプロン欲しいなぁ

テックフェスで珈琲を淹れる際、本気度と一体感を演出するためにみんなでデザインしたロゴの入ったエプロンを作りました。自腹でしたが、大人の遊び感が出て面白かったです。

制約

200人分の珈琲を提供するとなると、豆が2kg程度必要であると見積もりました。
その豆を自腹で払うのは流石に懐が痛いので、システム本部に予算を出してもらうことにしました。通常購入している豆が1000〜2000円/100g程度でしたが、そうなると20000円以上かかります。
提示された予算が20000円程度という制限の中で、これに紙コップやアイスコーヒー用の氷を用意した場合オーバーしてしまうことになります。豆選びを頑張らなくてはいけなくなりました。

豆選び

レバレジーズの開発拠点がある渋谷一丁目支店の近くにSingle Oというコーヒー店があります。
そこのKILLER BEEというブレンドコーヒーを飲んだ時ハチミツのような甘い香りを感じました。

コーヒーがあまり好きではない人の中には、酸っぱい味が苦手という人が多くいらっしゃいます。ここで飲んだコーヒーは酸味が少なく、苦味もそこそこで、甘い香りが強く感じられる珈琲だったのと、価格も1000円/100g以下と手頃だったため、この豆を採用することに決めました。提供を終えた今となってはニーズをしっかり捉えられていたんじゃないかと思います。

大量抽出用のレシピ開発

200人に対して珈琲を都度都度ハンドドリップで淹れていくためには一度に大量の珈琲を淹れる必要がありました。美味しい珈琲を淹れるためのパラメータとして豆を挽いた際の粉の粒度とお湯の温度が特に重要になってきます。

珈琲の粉にお湯を注いでいき、最終的に2〜3分くらいで抽出が終わると渋みが出にくいと言われております。いつもの1杯取りレシピの場合より高速でお湯を落とす必要があったため、まずはいつもより粗めの挽き目で美味しい珈琲が作れるように調整を行いました。挽き目の調整が終わったら温度を変えながら味を見ていき、美味しく作れるレシピを考案していきました。

退勤後にこれらの作業を行なっていたのですが、夜遅くに大量のカフェインを摂取する羽目になりました。飲みすぎて頭が痛くなったのもいい思い出かもしれません。

オペレーションと前日準備の検討

テックフェスの開催が夏だったこともあり、アイスコーヒーの需要が高いことが予想できました。代々木にあるフグレンコーヒーというお店ではアイスコーヒーを頼むと瓶に入ったコーヒーを注ぐだけのオペレーションで手早く客を捌いていきます。これを参考に、事前にアイスコーヒーを仕込んでいくことにしました。

また、テックフェスは著名なエンジニアをお招きしてお話ししていただく基調講演(今回はみのるんさん)やレバレジーズエンジニアのLTを聞く場でもあるので、ミルで豆を挽く音がうるさいだろうと判断し、前日に大量の豆を挽いてから現地に赴くことにしました。

珈琲事業部には電動のミルがないため、コマンダンテという手挽きのミル2台を使ってゴリゴリ挽き続け、傍らで大量のアイスコーヒーを抽出しました。

テックフェス運営による宣伝

テックフェスの運営さんは今回特に気合が入っていて、事前に広報活動を積極的に行なっていました。珈琲事業部が参加することもこのような形で宣伝してくれました。

嬉しい宣伝

いざ当日

エプロン、備品、珈琲の粉、アイスコーヒーの準備を終え、万全の状態で当日を迎えました。
氷は当日コンビニで購入する予定でしたので、メンバーには先に会場に入って準備をしてもらい、自分は氷を購入してから会場に入りました。
すると謎の行列が出来ており、その先頭には珈琲事業部のブースが。運営の方の宣伝効果があったのか、テックフェス開始前に珈琲を飲みたいエンジニアの方達がたくさんいたようです。こちらとしては大興奮で急いで氷を持ってブースに向かいアイスコーヒーを注いでいるメンバーを手伝いました。

すごい行列に慄く

8L用意していた珈琲も開始から2時間程度で無くなってしまったため、ホットコーヒーとアイスコーヒーを現場でたくさん淹れることに。嬉しい悲鳴を上げながらいつものテックフェスをまた違った立場で楽しむことが出来ました。

仕込んだアイスコーヒーを捌くメンバー達

反省など

アイスコーヒー需要や宣伝による集客効果を見誤りました。もっとアイスコーヒーを準備してから参加したほうがよかったです。ただ、現場では珈琲事業部メンバーが機転を効かせて給湯室への往復を少なくするための工夫をしてくれたり、珈琲事業部ではないNALYSYS開発部メンバーの自主的な協力のもとなんとか珈琲を淀みなく提供出来たのではないかと思います。

珈琲を飲まれた方からは、「いつもは砂糖を入れているがブラックでも美味しく飲めた」など嬉しい感想をいただきました。運営の方がテックフェス自体のFBを募集していたのですが、そこにも珈琲が美味しかったという旨のコメントがあり嬉しかったです。

新たな挑戦

テックフェスでの取り組みでシステム本部内での認知は広がったと思います。
レバレジーズの全社イベントである「納涼祭」にも参加することとなり、さらに多くの方達に珈琲を提供できる機会を得ました。
最近はカケハシさんが行なっている珈琲スポンサーのように外部イベント等でも珈琲を提供できるような存在に憧れを抱いています。NALYSYSが出展するHR系の展示会であったり、レバレジーズが企画している外部勉強会等で珈琲を振る舞える日がくるといいなと思っています。

最後に

自分の好奇心から始まった珈琲事業部という取り組みですが、珈琲好きなメンバー達がただ集まって珈琲を飲んでいるだけだったのが、活動の場所を広げ色々な方に珈琲を提供する立場になったことが不思議でもあり面白く思っております。
メンバーたちが、珈琲の奥深さや提供する喜びに本気でハマりつつあるので、社内でのプレゼンスを高めて本当の事業部になる日がくるといいなぁなんてことを半分本気で考えています。
NALYSYS開発部やシステム本部の皆さんがどういう気持ちで我々を見ているのかはわからないのですが、こんな取り組みを続けさせてくれていることに感謝しています。

私は他にも以下の2つのエントリーをこのブログに書いておりますが、記事を書くときはいつも、人に恵まれたいい会社だなと感じております。

tech.leverages.jp
tech.leverages.jp

改めて、取り組みに関わったり、温かい目で見守ってくれている皆様、豆主様へこの場を借りて感謝いたします。

一緒に珈琲を淹れてみませんか?

毎度宣伝いたしますが、この会社楽しそうだなと思ってくれた方おりましたら、ぜひ採用のご応募お待ちしております!
一緒に珈琲を淹れてくれるエンジニアの方達を心よりお待ちしております。

会社説明資料
HRMOS求人ページ
カジュアル面談はこちら

NALYSYS開発部の雰囲気がもっとわかる動画


www.youtube.com

Tech Leverages 技術活動レポート 25年1Q期号

2025年4,5,6月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催やイベント登壇など多様な関わり方で、合計14件のイベントに参加しました!

※TSKaigi2025スポンサーの様子

主催・共催技術イベント

バックエンドTypeScript勉強会 ~Macbee Planet x レバレジーズの事例大公開~

4/8に、本社渋谷スクランブルスクエアにて、バックエンドTypeScriptについて実際の運用のノウハウも交えながら、実践で役立つ内容を語る、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

ドキュメントの鮮度を維持する「しくみ化」の方法 CADDi、DMM.com、IVRyの実践例から

4/23に、オンラインにて、組織体制や運用ルールによる「仕組化」、AI技術による「自動化」の両側面から再現可能な解決策を語る、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

AI ×フロントエンド開発のリアル

5/15に、開発組織の拠点であるポーラ渋谷ビルにて、開発現場での事例をもとにAIを活用したフロントエンド開発をテーマにした、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

Tech-QA Meetup ~品質で未来を拓く最前線~

5/15に、オンラインにて、各社の現場でのチャレンジや、実務にすぐ活かせる知見、そしてこれからのQAの在り方について、ライトニングトーク形式で語るイベントを開催しました。 (イベント詳細はこちらから)

技術的負債へのアプローチを考えよう

5/21に、開発組織の拠点であるポーラ渋谷ビルにて、TypeScript好きな若手エンジニアを対象にしたライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

はじめてのLT - TypeScript好き若手エンジニアのためのゆる懇親ナイト

5/21に、トグルホールディングス株式会社様の会場にて、システム・インフラ・プロダクト戦略の3視点から学ぶ負債解消をテーマに、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

開発チームでどう活かす? MCPでできたこと・できなかったこと

5/28に、オンラインにて、エス・エム・エス、Ubie、SmartHR、クローバの4社から、開発現場でのMCP活用事例について語る、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

ビズリーチ社合同勉強会

6/12に、オンラインにて、株式会社ビズリーチの開発組織の方々と合同勉強会を開催しました。

AIの出力の質を上げる。チームの集合知をAIに注入する方法

6/25に、オンラインにて、AIエージェントにチームの集合知を効率的に注入するための工夫について語る、ライトニングトーク形式のイベントを開催しました。 (イベント詳細はこちらから)

イベント登壇

バックエンドTypeScript勉強会 ~Macbee Planet x レバレジーズの事例大公開~

レバテック開発部の大内が、バックエンドTypeScript勉強会に登壇しました。 (イベント詳細はこちらから)

https://speakerdeck.com/leveragestech/rihuakutaringuituyaruno-yi-cun-nozheng-li

PHPカンファレンス小田原2025

レバテック開発部の檜垣が、PHPカンファレンス小田原2025に登壇しました。 (イベント詳細はこちらから)

https://speakerdeck.com/leveragestech/gu-kiliang-ki-laravel-nosisutemuha-guan-shu-xing-sutairuderihuakutadekirunoka

イベントスポンサー

PHPカンファレンス小田原2025 松スポンサー

4/12に行われたPHPカンファレンス小田原2025にて、レバテック株式会社が松スポンサーとして協賛しました。

TSKaigi2025 ゴールドスポンサー

5/23,24に行われたTSKaigi2025にて、レバレジーズ株式会社がゴールドスポンサーとして協賛しました。

会場スポンサー

技術書とお金の話

“技術書とお金の話”イベントに、会場の提供をしました。 (イベント詳細はこちらから)

酒とゲームとインフラとGCP@レバレジーズ ~新緑に乾杯!初夏のクラウド談義〜

“酒とゲームとインフラとGCP”イベントに、会場の提供をしました。 (イベント詳細はこちらから)

GitHubCopilotとAI時代のデータ管理方法 ~開発生産性向上やデータ管理・MCPまで~

“GitHubCopilotとAI時代のデータ管理方法”イベントに、会場の提供をしました。 (イベント詳細はこちらから)

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、以下のサイトからご応募ください。

HRMOS求人ページ

会社説明資料

AIに全権委任したら黒☆魔☆術コードが生まれた話 - 生成AIハッカソンで試したVibe Coding実践録

こんにちは!テクノロジー戦略室AI推進チームの苑田です! AWS Summit 2025 生成AIハッカソンがあり、全部で150チームほど参加した中、準優勝することができました!その時に試したAI駆動開発を時系列順でまとめました!

作成したアプリに関しては別のメンバーが記事を書いてくれたので、一緒にみてもらえるとイメージしやすいと思います!

AWS Summit 生成AIハッカソンで準優勝しました!

AI駆動開発で使用したツール

  • GitHub Copilot
  • GitHub Copilot Coding Agent
  • GitHub
  • v0

担当範囲

  • 苑田:AI Agent(Strands Agents)周り、Backend
  • メンバーA:Backend、スライド作成
  • メンバーB:Backend、デモ動画作成
  • メンバーC:Frontend

開発までのスケジュール

生成AIハッカソンの流れ

6月25日に予選があり、作ったアプリケーションを披露する必要があります。スケジュールは上記の通りですが、通常業務や諸々の対応をしていると、実際の構築期間は3週間となりました。当然、通常業務もあるので、メンテ性と可読性の品質を担保する開発ではなく、スピード重視のVibe Codingで進めることにしました。

Vibe Coding

人間がコードを書かずに自然言語でLLMアプリに指示して開発することをVibe Codingといいます。とはいえ、適当に開発すると変なコードが出来上がるので、以下の順番でコーディングするようにしました。

  • 作りたいものをAIと壁打ちして要件を決める
  • AIに詳細設計を作成してもらう
  • 何をすべきかTODOリストを作成してもらう
  • どのAIでもタスクを処理できるように、GitHub IssuesにTODOを登録する
  • Issueを元にAIがコードを書く
  • AIがPRを作成する
  • PRをレビューして問題なければマージ

できるかぎり人間の動作を減らすために、Issueの登録やPRの作成はGitHub MCPを使って自動化しました。 下記のようにcopilot-instructions.mdにOrganizationとリポジトリの詳細を記載することで、エンターキーを押すだけで開発が進んでいきます。

<!-- I want to review in Japanese. -->
# リポジトリ
- Organization: "現在の組織"
- repository: "現在のリポジトリ"
<!-- I want to review in Japanese. -->

また、「なぜGitHub issuesを使うのか」という話は後で出てきます。

AIの書いたコードを全て許可する

Vibe Codingをしていると、AIの開発スピードが早すぎてレビュワーの負荷がかかり、人間がボトルネックになってしまいます。なので、基本的にAIが書いたコードは全て許可する方針で開発を進めました。

これは実験的な部分もあったのですが、今後AIが賢くなって行った時に、全部AIが開発、運用、テスト、レビュー、修正をやってくれるといいよね!とチーム内で会話になったのがきっかけです。

設計は人間が行い、開発、修正に関してはAIに任せるというスタイルで開発を進めました。

黒☆魔☆術コードができてしまった

基本的にレビューせずに即マージすることはまずあり得ないので、とても気持ちが良くポチポチマージしていました。このタイミングではもうすでに人間が読めるコードではなくなっており、これが本当のVibe Codingと意味不明なことを言ってました。しかし、発表1週間前に大問題が発生しました。

これAPIから取ったデータを表示してないんじゃね?

どういうことかというと、APIからデータを取得してフロントに表示するはずが、毎回同じデータを返してくるという問題が発生しました。

調査した結果、AIエージェントが処理を失敗した時に返す値をそれっぽい固定値で設定しており、APIと連携できていなくとも、きちんとした値を返すようにしていたのが原因でした。

例:
def analyze_sentiment(self, text):
    try:
        # 実際のAPI呼び出し
        response = self.sentiment_api.analyze(text)
         return response['sentiment']
     except:
        # API失敗時の固定値フォールバック
        return "neutral"

例のように、API呼び出しが失敗したとしても、「neutral」が返ってくるので、フロントエンドではエラーが発生しません。

よくよく考えると、AIエージェントは目的を達成するためにタスク分解して処理をするので、最終的なゴールがフロントに表示することであれば、こういうコードを書いてしまうのは当然でした。

「なるほどな〜」と思いながらリファクタリングをしようとしたのですが、人間の介入はしない前提で開発を進めていたため、ここからが地獄の始まりでした。

人間によるリファクタリング

発表1週間前に黒魔術コードが完成してしまったので、以下の内容でリファクタリングを行うことにしました。

  • 過剰なtry-exceptを削除
  • エラーが発生した時に文字列ではなく、エラーコードを返すように修正
  • 人間が確認しやすいように、ディレクトリ構成を整理
  • APIの疎通ができていない箇所を修正

先ほど記載した通り、AIエージェントは目的を達成するためにコーディングするので、大量のtry-exceptを生成します。なので、不必要なtry-exceptは削除し、エラーが発生した場合、すぐ検出できるように変更しました。

また、とてつもない量のファイルやコードを生成するので、人間が全部確認するのは不可能と判断し、人間が確認しやすいようにディレクトリ構成を整理しました。この時はわかりませんでしたが、ディレクトリ構成や内容をREADME.mdに記載すると、AIの迷いが少なくなった気がします。

APIの疎通に関しても、Mockを大量に生成していたので、全て削除しました。

これらの作業に丸3日かかりましたが、なんとかBackendだけリファクタリングを終えることができました。 Frontendは私の担当ではないのでなんとかしてもらおうという魂胆です。当然担当は地獄を見ていました。

AIが開発しやすいような開発環境の作成

発表まで残り4日。リファクタリングが終わり、AI駆動開発がなかなかうまくいかないなぁと思いながら開発していたのですが、1つの仮説が浮かびました。それは、AIが開発しやすいような開発環境を用意すれば、AI駆動開発がもっと楽になるのではないかということです。

今まではAIが好き勝手にコードを書いていたのですが、AIが必要な情報を取得できないと関連する箇所を次々と調査してしまい、本来の目的を見失ってループに入ってしまいます。したがって、AIが効率的に必要な情報へ辿り着けるよう、専用ツールを作成しました。

  • docker-compose関連のコマンドを叩くシェル
    • ワンコマンドでAIが使用できる
  • MCPの活用
    • GitHub MCPを駆使して、AIが自動でIssueやPRの確認、作成できるようにする
    • Strands AgentsのDocs MCPを使用することで、最新の情報でもドキュメントを参照できるようにする
  • git worktreeの活用
    • 複数のブランチを同時に開発できるようにする(これは長いので下で書く)

作成したツールをAIに使用してもらうために、copilot-instructions.mdで以下のような指示を書きました。

# 利用可能なスクリプト
- `./scripts/run-dev.sh` - 開発環境の起動(自動ポート割り当て)
- `./scripts/status-dev.sh` - 全worktreeの状況確認
- `./scripts/stop-dev.sh` - 環境停止
- `./scripts/create-worktree.sh` - 新worktree作成
- `./scripts/remove-worktree.sh` - worktree削除

# AIエージェント向け指示
- `docker-compose logs` などの標準コマンドは使用禁止
- 環境の状況確認は `./scripts/status-dev.sh` を使用
- ポート競合やログ確認が必要な場合は上記スクリプトの出力を参照

これにより、人間がやることを極限まで減らし、AIが開発しやすい環境を整えることができました。以下の画像は、AIが実際に叩くシェルの例で、今このプロジェクトでどのコンテナが動いているかを確認できます。

このようなツールを用意してルールに記載しておくと、ツールを使った結果をAIが確認し、それを元に修正をするようになります。

例えば、エラーが発生した時に以下の手順でAIは修正します。

  • ステータス確認シェルでコンテナの状況を確認する
  • 確認したコンテナ名やステータスを元に、ログ確認シェルを使用し、ログを確認する
  • 対象箇所を調査する
  • 修正する
  • 動作確認し、エラーが無くなれば終了

このように、適切なツールを渡すことで、変なことをする回数が減りました。

git worktreeによる並列開発

AIが開発しやすい環境を作ってうまく開発ができてきました。しかし、待ち時間が暇なんですよね。 Twitterを見ると怒られるし、どうしようかなと考えていたら、AIがコードを書いている間に、別のブランチで開発を進めることができるかもしれないと思いつきました。

そこで、git worktreeを使って、複数のブランチを同時に開発できるようにしました。 git worktreeの説明は以下のブログが参考になります。

AIエージェントで並列実装なら必須技術! Git Worktree を理解する

git worktreeを使うと、AIが開発する環境を簡単に作成できます。 私はworktreeを作成、削除するシェル(script以下)を用意しており、以下の構成で使用していました。 親は基本的にworktreeを作成、削除、本番環境のデプロイを行う場所で、子はAIが実際に開発する場所と定義していました。

ここで必要なのが、AIが動作確認するための環境です。 docker-composeを使用しているため、並列で開発しているとportが枯渇する問題が発生しました。なので、portを動的に割り当ててdocker-compose upするシェルを作りました。 これにより、AIが簡単に動作確認できます。

また、git worktreeを使用することで、以下のメリットがありました。

  • AIがコードを書いている間に、別のブランチで別のIssueを進めることができる
  • 同じIssueを複数のAIに処理させ、一番いいものを採用できる

1つ目はそのままですが、2つ目が結構便利でした。 AIは同じプロンプトでも生成する内容が異なるため、2〜4並列でAIに同じプロンプトで生成させ、その中でいいものを選択していました。私たちはこの開発をリセマラ駆動開発と呼んでいます。

完成!

無事予選前日の深夜12時にアプリケーションが完成しました。なんとか完成したのでワイワイしていると、スライド作成していないことに気づき、予選当日の開始1時間前にスライドが完成しました。ここら辺の話は色々あったので、また別のタイミングで話せたらなと思います。

実際にAI駆動開発やってみた結果

今回色々な仮説をもとに検証を行なっていましたが、AIが開発しやすい環境を作成した途端、爆発的に開発が進みました。 AIが指示通りに動いてくれない理由は、考えることが多すぎて変な方向に進んでいくからという結論になりました。AI駆動開発はコーディングしてもらうだけだと思っていたので、タスクを処理しやすいように環境を整えてるのは新鮮で面白かったです。

また、ある程度コードを人間が読めるようにする必要があると感じました。今回はハッカソンだったので最悪全部壊せばいいですが、本番稼働しているアプリだと必ず人間がリファクタリングする必要があります。したがって、ある程度人間が読めるようにドキュメントを整備したり、コーディング規約を言語化しておくことで、最悪の事態は避けられると思います。

どうすればもっと開発が楽になるか考えてみた

ひとまずアプリをリリースできましたが、今後組織に普及していくために、チーム内でどうすればもっと開発が楽になるかを考えました。話題として上がったのがAIが暴走してしまい、人間が対応するのが大変だったという点です。実際に試したわけではないので話半ばで聞いて欲しいですが、チーム内で結論付けたことを記載しておきます。

テストを書く

今回スピード重視で開発していたため、テストを書かずに構築していました。しかし、AIは目的を達成するために、モックを作ったり、都合のいい処理を書いたりします。明確なテストを用意しておくことで、ある程度この暴走は抑えられるのではないかと考えました。

また、AIがすごいスピードでリファクタリングするので、いきなりコードが動かなくなることも多々ありました。その観点でも、テストがあると人間は安心でき、AIもテストが失敗したら修正を行なってくれるので、チーム内では必須だと結論付けました。

しかし、テストを書いたとしても、そのテストが通るようにコードを生成したりするので、ある程度人間がレビューする必要があります。

プロンプトを使い分ける

copilot-instructions.mdに守って欲しいことや設計手法など全部記載しても、AIは完全にそれ通りに動くわけではないことを学びました。 したがって、TODO作成プロンプト、構築プロンプト、テストプロンプトのように、プロンプトを分けることで役割分担するのもいいのではないかと考えました。

今回のハッカソンでは、各専門エージェントを使用したマルチエージェントで構築しており、1つのエージェントで構築するより精度が向上しました。

この要領でプロンプトを分ける(claude codeだとカスタムスラッシュコマンド)と、AIが暴走することは少なくなると思います。

まとめ

Copilotのプレミアムリクエストが1週間で無くなった時はどうなるかと思いましたが、なんとか乗り切ることができました。 期限内に構築完了し、準優勝できたのは、間違いなくAI駆動開発のおかげだと思っています。

次の目標としては、このAI駆動開発をもっと楽にするような仕組みを開発して、他のチームに展開していきたいです。

おまけ

引き継ぎコンシェルジュ ko☆shiで出しましたが、引☆継☆王 ko☆shiの可能性もありました。 この命名を考えるのに、冗談抜きで数時間かかったので、もっとマシな会話をしたらよかったなと反省しています。

最後に

最後まで読んでいただきありがとうございます!AI推進チームでは一緒にAI推進を行うメンバーを募集しています!もっとAI推進チームやレバレジーズについて知りたい方は会社説明資料をご覧いただき、ぜひこちらからご応募ください!
AIソリューションアーキテクト(AIエンジニア)
AI/機械学習系 研究員

レバレジーズの新卒エンジニアって何するの?そんな君に伝えたい、1ヶ月目のリアル。

はじめに

こんにちは!レバレジーズに25卒のエンジニアとして入社したイツキです。

この記事を読んでくださっている方の中には、レバレジーズに少しでも興味を持っている就活生も少なくないかもしれません。 「実際に入社したらどんな感じなんだろう?」と、リアルな情報を集めている最中なのではないでしょうか。

この記事は、新卒エンジニアとして入社した、イツキ、スガノ、アミタニの3人が最初の1ヶ月をどのように過ごしたか書いた体験談です。

レバレジーズの新卒エンジニアが最初の1ヶ月でどのようなミッションに挑戦するのか。 技術スタックの話やチームの雰囲気だけでなく、それ以上に『ここで働くことは面白いのか、成長できるのか』

現在まさに企業研究を進めている方、レバレジーズのエンジニア職に少しでも興味を持ってくださっている方にとって、何かしらのヒントになる情報を届けられたら幸いです。

【第1章】ミッションは「俺たちのことを知ってもらえ!」~ゼロからの企画挑戦~

入社して間もない私を含む3名の新卒エンジニアに、最初のミッションが与えられました。

開発本部全体のキックオフ(250名規模)で30分間の枠を提供する。そこで君たち3人のことを、先輩エンジニアたちに知らしめてほしい。

驚いたのは、その自由度の高さでした。「君たちがこの会社でどうなりたいか、そのために先輩たちにどう認知されたいかという目的から考え、それを達成する手段を自分たちで企画・提案して良い。唯一の制約は、30分の時間と、何かしらのシステムを開発して使用すること」。

ゼロからの企画を任せてもらえるのかと、同期と共に驚いたことを覚えています。若いうちから裁量を持って挑戦したいと考えていた私にとっては、はじめの一歩として願ってもないチャンスでした。

私たちが目指したのは、単に顔と名前を覚えてもらうだけではありません。「この新人たちは、なかなか面白いじゃないか」「何かやってくれそうだ」「一緒に働いたら楽しそうだ」と、ポジティブな第一印象を持ってもらうこと。それが、これから私たちがこの会社で価値を発揮していくための、重要な一歩になると考えたからです。

そこでまず考えたのが、社内の膨大なナレッジをまとめ、質問に答えてくれるAI Botの開発でした。これならば、私たち自身が会社の情報をキャッチアップするのにも役立ちますし、先輩方の役にも立てるかもしれない、一石二鳥だと盛り上がりました。AIと議論しながら開発を進め、2週間ほどで動作するものが完成。このBotを使って社内ナレッジクイズ大会を実施したら盛り上がるのではないかと、期待は膨らむばかりでした。

そして2週間目の終わり。意気揚々と進捗を報告した私たちに、上司が一言。

「それで、君たちの目的は達成されるの?」

その言葉に、私たちは詰まってしまいました。頭の中が真っ白になるというのは、こういうことかと感じました。

「AI Botを開発しました!」というだけで、私たちのことを「面白い」と思ってもらえるのでしょうか。「一緒に働きたい」と感じてもらえるのでしょうか。

答えは、明確にNoでした。 私たちが社内ナレッジをキャッチアップしたい。私たちがAI Botを作ってみたい。これらは全て、私たちの都合、私たちのやりたいことでした。参加者(先輩エンジニアたち)の視点が、完全に抜け落ちていたのです。

「顧客価値の創造」。レバレジーズが大切にしているこの言葉の意味を、肌で理解した瞬間でした。

私たちの目指した「先輩社員にポジティブな第一印象を持ってもらうこと」という目標を達成するためは、まずは顧客(=相手、今回は先輩社員)の視点に立って考える必要があります。ただ技術的に面白いもの、自分たちが面白いと思うものを作ればいいわけではありません。

この失敗と気づきこそが、最初の大きな成長の糧となりました。上司のたった一言の質問は、厳しさではなく、私たちに本質を考えさせるための、最良の道しるべだったのかもしれません。

【第2章】大幅な方針転換!「自己紹介ゲーム」爆速開発の舞台裏

上司の一言で、私たちの自信作(であったはずの)AI Bot企画は、白紙に戻りました。 正直、少し落ち込みましたが、それ以上に「確かに!」という納得感と、「ではどうするべきか!?」という新たな挑戦への意欲が湧いてきました。この切り替えの早さ、そして「どうすればできるか」を考える前向きな雰囲気がチーム全体にあったことは、振り返るととても良いことだと思います。

改めて、私たちの目的に立ち返りました。

  • 私たちのことを先輩方に知ってもらい、
  • 彼らが面白いと感じてくれ、
  • 一緒に働きたいと思ってもらう。

この3つを、250人の参加者の前で、たった30分で達成するにはどうすればよいか。そして、そこに「エンジニアらしさ」、つまり私たちが開発したシステムをどのように絡めるか。

知ってもらうにも、ただの自己紹介では面白みに欠けるから、ゲーム形式にする。クイズやパズルを解いてもらう中で、自然と私たちの人となりやスキル(の片鱗でも!)に触れてもらう。そして、ゲーム自体の作り込みで「お、この新人たちは技術もなかなかやるな」という期待感を持ってもらう。

悩んだ末、私たちが出した答えは「参加者全員を巻き込む自己紹介ゲームを作ろう!」でした。 振り返ると、シンプルでやや安直な感じもしますね。しかし、目的に照らし合わせた上で、「それを実現するためには?」ということを考えた結果です。目的を達成できるのであれば、安直であるかどうかは問題になりません。

【第3章】「ただ作るだけじゃない」面白さと気持ちの良い大変さ

さて、目的が定まった私たちは、活気を取り戻しました。

しかし同時に、残された時間は、もう3週間を切っていました。設計、開発、テスト…全てを行うには、正直に言って非常に厳しい時間でした。ここからが、まさに「爆速開発」の日々の始まりです。チーム3人で毎日顔を突き合わせ、アイデアを出し合い、役割分担して、猛烈な勢いでコードを書き続けました。

未経験の技術はもちろんありました。新しいフレームワーク、初めて触れるライブラリ…。しかし、レバレジーズには、それを乗り越えるための環境が整っていました。頼れる先輩エンジニアたちが、私たちの初歩的な質問にも根気強く付き合ってくださり、技術選定のアドバイスもいただきました。(本当に感謝しかありません…!)この「いつでも質問でき、助けを求められる」安心感が、私たちの挑戦を後押ししてくれたのは間違いありません。

そして、ここだけの話になりますが、開発の相棒として社内で利用できるGeminiの力も大いに活用しました。 アイデアの壁打ち相手になってもらったり、エラー解決のヒントをもらったり…。まさに現代のエンジニアリングだと感じました。使えるものは何でも使い、最短距離でゴールを目指す。このスピード感は、レバレジーズならではかもしれません。目的ベースで思考し、そのためならば新しい技術やツールでも積極的に試すことを推奨してくれる文化があるからこそ、私たち新卒も臆することなくAIを活用できたのです。

まずはとにかく「面白いゲーム」を作ることに全力を注ぎました。新卒3人、AIにも相談しつつ、アイデアを形にしては壊し、また作る、というサイクルを繰り返しました。1週間で10個以上のミニゲームのプロトタイプが生まれたと思います。

例えば、時間制限付きで次々とクイズが出題されるタイムショック風ゲーム、リアルタイム通信で2人が協力して謎を解くゲーム、そして、私たちが特にこだわったコードエディターを使った謎解きゲームなどです。毎日、作成したゲームをチーム内でお互いにプレイしては、「これは本当に面白いか?」「もっと面白くするにはどうしたら良いか?」と、熱心に議論を交わしました。ただ動作するだけでは不十分です。触っていて「心地よい」「ニヤニヤする」、そんな手触り感を追求しました。この試行錯誤のプロセス自体が、非常に勉強になり、何よりも楽しかったです。

最終的に、私たちが選んだのは2つのゲームでした。1つは、例の「コードエディターを使う謎解きゲーム」。もう1つは、「タイムショック風クイズゲーム」です。

コードエディターを使う謎解きゲームは、画面下部のコードを操作しながら、次の問題に進むためのパスワードを画面上から探すゲームです。このパスワードが、私たちの自己紹介にまつわるキーワードになっています。例えば「家庭菜園」。これは、チームメンバーのアミタニの趣味で、正解すると、彼が実際に作った作物の情報など、ちょっとしたエピソードが見られる仕掛けです。これで、ゲームを楽しみながら私たちのことを知ってもらえます。

タイムショック風クイズゲームでは、先ほど知ってもらった私たちの情報を元にした4択クイズを、テンポ良く出題します。数分前に見た情報を思い出してもらうことで、私たちのことをより深く印象付ける狙いです。ゲーム体験としては、かなり面白いものができたという手応えがありました。

しかし、ここでまた一つ、大事な視点に気づきました。

「このゲームは確かに面白い。しかし、参加者の先輩方は、そもそもなぜこのゲームをプレイしようと思うのだろうか?会場の250人全員を、本当に巻き込めるのだろうか?」

第1章での失敗が頭をよぎりました。ただ「私たちのことを知ってください!」だけでは、動機としては弱いかもしれません。ゲームをプレイした先に、何か彼らにとってもメリットや楽しみがなければ…。

残り時間は、もう1週間を切っていました。しかし不思議と、この新たな問題と向き合うのは楽しかったです。以前のAI Botの時とは違い、目的ベースで考えたがゆえに指摘される前に自分たちで発見できたこと。そして、それを乗り越えようとすること自体が、前回の反省が身になっていると言う成長を実感できる「気持ちの良い大変さ」だったからかもしれません。

ああでもない、こうでもないと議論しながら、ラストスパートを駆け抜けた、あの数日間は本当に濃密でした。

【第4章】そしてキックオフ当日!

その後、私たちが見つけた最後のピース。それは…「会場全体を巻き込むチーム対抗戦にして、最後はジェスチャークイズで盛り上げよう!」でした。

開発したゲームにログインしてくれた参加者をランダムに2チームに分け、ゲームのスコアを競ってもらいます。そして、そのスコアに応じて、最後のジェスチャークイズの制限時間が変わるというものです。私たち新卒がお題(私たちの趣味など!)をジェスチャーで表現し、会場全体から声を出して当ててもらうのです!これなら、一体感が生まれますし、何より楽しそうです!

結果からお話しすると、このジェスチャークイズがしっかりハマりました。 開発した、エディタークイズなどで、私たちの名前やちょっとした個性を知ってもらえていたのも、盛り上がりの要因でしょう。 会場のあちこちから声が飛び交い、全体に一体感が生まれ、想像以上の盛り上がりになりました。拙い部分もありましたが、前向きに参加して、場を盛り上げてくれた諸先輩方にも感謝しかないです。

30分間の発表が終わった時、私たちは汗だくでしたが、それ以上に大きな達成感と、やりきったぞ!という喜びでいっぱいでした。 社内イベントだからこその温かさも感じました。当日、機材トラブルもあったのですが、先輩方がサポートしてくださり事なきを得たり…。本当に感謝しかありません。

【まとめ】企画からできるエンジニアって、おもしろい

怒涛の1ヶ月。ゼロからの企画、まさかの大ピボット、そして爆速開発からのキックオフ本番…。本当に、あっという間でしたが、非常に濃い時間でした。

この経験を通して改めて感じたのは、レバレジーズの「新卒の『やってみたい!』を本気で応援してくれる文化」です。企画から任せてもらえる裁量、それを実現するための予算や頼れる先輩というリソース、そして何より、決定から実行までのスピード感。

ただ言われたものを作るだけのエンジニアにはなりたくない。 若いうちから自分で考えて、価値を生み出す挑戦がしたい。 チームで一丸となって何かを成し遂げたい。

── 就活生の時、私が抱いていたそんな想いを、レバレジーズは真正面から受け止めてくれたのだと思います。

反省点も、成長の糧。

もちろん、反省点も山ほどあります。というより、反省だらけかもしれません。特に大きかったのはこの2点です。

  • 当日のネットワーク負荷の見積もり: 想定以上の同時アクセスで、ゲームログインに少しお待たせしてしまいました…。事前の負荷テストや、もっと段階的なアクセス分散を考えるべきでした。これは完全に私たちの準備不足です。

  • 目的意識の再徹底のタイミング: 最初のAI Bot開発は、今思えば「作りたいもの」に目が向き、肝心の「誰に、何を知ってもらいたいか」が甘かったと反省しています。上司に指摘されてハッとしましたが、本当は企画の最初期に、もっと深くチームで突き詰めるべきでした。2回目のゲームの動機付けの課題は自分たちで気づけましたが、これももっと早く気づければ、さらに良いものが作れたかもしれません。

しかし、だからこそ、この1ヶ月での成長の実感は非常に大きいです。できなかったことができるようになった。見えなかったものが見えるようになった。まだまだ未熟なエンジニアですが、確かに、大きな一歩を踏み出せたと感じています。失敗を恐れずに挑戦させてもらえる環境、そしてその失敗から学ぶことを推奨してくれる文化が、この成長を後押ししてくれたのです。

実際、キックオフが終わってから、様々な先輩エンジニアの方々から声をかけていただく機会が増えました。「あのゲーム面白かったよ!」とか、「イツキくん、カードゲーム何をやっているの?」などと。私たちが最初に掲げた「自分たちのことを知ってもらい、肯定的に思ってもらう」という目的は、少しは達成できたのではないかと、今は自信を持って言えます。

もし皆さんが、「ただ作るだけじゃない、企画から関われるエンジニアになりたい」「若いうちから裁量を持って、面白いことに挑戦したい」「最高のチームで、ユーザーに価値を届けたい」そう思っているのであれば、レバレジーズは最高の環境かもしれません。

このブログが、就活生である皆さんの企業選びの、そして未来への一歩の、小さなきっかけになれば幸いです。最後までお読みいただき、ありがとうございました。

もう少し、開発部全体のことを知りたいという方は、弊社の開発部に1日密着した動画がYouTubeに上がっていますので、ご覧ください。

www.youtube.com

宣伝

レバレジーズでは、エンジニアの皆さんにも、様々な業務を通じて成長の機会を提供し、一緒に未来を切り開いていきたいと考えています。 このような価値観に共感し、「自分のアイデアで世の中に影響を与えたい」 そんな情熱を持ったあなたの応募をお待ちしています! とのことです!今年もサマーインターンシップを開催予定なので、気になる方は下記サイトから応募してみてください〜〜!

◆レバレジーズ 2027卒新卒 エンジニアサマーインターン 応募フォーム leverages-internship.goodfind.jp

◆新卒採用ページ

recruit.leverages.jp

◆エンジニア採用サイト

recruit.leverages.jp

人工知能学会全国大会(JSAI2025)に参加しました!

はじめに

はじめまして! テクノロジー戦略室先端技術グループの永安と申します。普段はAI/MLに関してプロダクトへの適用を目指した研究開発をしています。レバレジーズって研究していたの?と思ったそこのあなた、鋭いですね。先端技術グループは2025年4月に発足したばかりのチームです! Gemini2.5より年下でGPT 4.1よりは年上ですね。

先端技術グループは、AI/MLの最新技術をキャッチアップまたは新規技術を開発し、それを実際のプロダクトに落とし込んで実用化していくことを目標にしています。その一環として、先日開催された人工知能学会全国大会(JSAI2025)に参加しました。大学企業を問わず様々な研究発表を聞くだけでなく、研究者や技術者と交流することができ、自分の研究活動にとって大きな刺激となりました。 本記事ではそんな人工知能学会の様子や気になった発表について紹介します。

JSAI2025とは

JSAI2025は、JSAIが主催する、日本最大級のAIに関する学術イベントです。企業でAI開発や研究を行う技術者の参加も多く、企業所属の研究者にとって貴重な情報交換の機会となっています。今年は第39回で、前回の約3800名からさらに参加者が増加し4900人超となっていました。多くのセッションがあり、講演やポスター発表から国内研究者の研究を知ることができました。また、企業ブースの出展もあり、企業所属の研究者、技術者から各社の取り組みを直接質問することができました。2日目には学会が企画した懇親会があり、それ以外にも連日有志企画の大小様々な交流会がありました。自分は2日目の公式懇親会に参加できませんでしたが、翌日の非公式懇親会に参加したところ、普段関わらない業種でAIの研究、活用をしている研究者、エンジニアと知り合うことができ非常に有意義でした。

発表のトレンド、技術動向

近年のトレンドを反映し、LLMに関する研究発表が最も多数を占めていました。特に、LLMを個別事例へ利用することが増えたため、評価、アノテーションに関する研究が多かったです。また、LLMエージェントに関する研究も増えており、リアルユースでのワークフローの組み方の工夫がよく議論されていました。原理的に内部構造を解釈しづらいLLMの重要度がより増したことを背景に、アラインメント、解釈可能性に関する研究も多かったです。解釈性がメインのセッションが複数あり、この分野への関心が高まっていることを感じました。レバレジーズに関係する人材領域でのAI研究についても企業を中心に発表されていました。

イチオシの発表

双方向推薦システムにおけるコントラスト効果の応用

  • ある対象を別の対象と比較して提示することで相対的な価値や魅力が変化する心理的効果であるコントラスト効果をマッチング領域の推薦システムに応用した研究です。ユーザーの行動履歴を元にユーザーの行動を促す魅力的な推薦と現実的にマッチングする推薦のバランスを取ることが特徴です。双方向推薦において重要なユーザーから見た魅力と現実的なマッチングのバランスを行動履歴という時系列情報から決定する手法を述べていた点が非常に面白かったです。レバレジーズの人材推薦でも求職者の行動変化による双方向推薦のバランス調整は活用できると感じました。

エンジニアの職歴データによるスキルネットワーク分析

  • エンジニアが持つスキル同士の関係をネットワーク分析した研究です。職歴のデータセットからエンジニアの集合とスキルの集合で二部グラフを作り、ネットワーク構造の傾向を見ています。レバレジーズの中でもエンジニアの転職支援は重要で、エンジニアスキルのネットワーク構造には関心がありました。発表者はネットワーク分析の専門家で分析手法が上手く参考になりました。

LLMエージェントによるエルファロル・バー問題の解析

  • ゲーム理論におけるエルファロル・バー問題についてAIエージェントでシミュレーションを行った研究です。元々のエルファロル・バー問題は、空いている時にバー行くと良いが混んでる時には行きたくないという状況における集団の意思決定と戦略に関する問題でした。この研究では二次元上で互いの接近時に情報を伝達できる複数のAIエージェントでこの問題をシミュレーションしていました。この研究の面白い点として、LLMのプロンプトにタスクを明記せず、バー内の混雑具合に応じた快、不快のフィードバックのみから自律的にバーに入る、出るという行動をとっていたことがあります。さらに、エージェント同士の会話により、バー内で不快な状態でエージェント同士が密集して動かなくなるという現象が観察されたのも面白かったです。コントロールした環境で面白い現象を観察した研究なので、今後エージェントに関する一般的な知見が得られることも期待できるように感じました。

深層基盤モデルの数理

  • ディープラーニングに関する近年の理論研究についてまとめたチュートリアルです。機械学習理論の国内トップ研究者による講演で情報量の多さに圧倒されました。資料は一見の価値ありです。CoTの理論に関しては全く追えていなかったので新鮮に感じました。また、テスト時スケーリングの理論は今後LLMを作る側だけでなく、レバレジーズのような使う側にとっても精度向上に利用できそうで面白かったです。豊富な内容から優秀な研究者のキャッチアップの多さを感じることができ、自分自身のモチベーションにもつながるチュートリアルでした。

最後に

今回は聴講のみの参加でしたが、国内のAI研究を知ることができ、また研究者や他企業の技術者と交流することで有意義な知見が得られました。次回はレバレジーズからも発表ができるように取り組んでいきたいですね。

先端技術グループではAIに関する技術開発を行うメンバーを募集しています。ビジネスに関わる領域で研究しつつも裁量を大きく持てるところが魅力だと思います。少しでも興味を持っていただけた方はこちらからご応募いただけると嬉しいです。

「機械にはできない」はもう古い?AI技術のMCPで負荷試験を自動化してみた

1. はじめに

こんにちは。テクノロジー戦略室TQCチームの原田です。
僕達のチームはTotal Quality Control、つまり全社の全システム品質管理・システム品質向上を目的に活動しています。
この目的を効果的に達成するため、データ分析に深い知識を持つ社員や、複雑な課題を整理し新たな概念を構築する社員など、それぞれの専門性や強みを共有し、協力し合いながら活動する面白いチームです。

その中で僕達が注目しているのがAI技術です。
皆さんは「この業務は人にしかできない」と言う考えを持ったことはないでしょうか?
人の判断が必要だから、機械的には処理できない——そのような業務も自動化すべく、僕達はAI技術を活用しています。

本記事では僕達が活用しているAI技術の中から、特に注目しているMCPという技術に焦点を当て、システム品質としてシステムの安定性や性能を保証する上で不可欠な試験である負荷試験を「どのように自動化したか?」をお伝えします。

2. 負荷試験自動化の現状と課題

近年負荷試験の自動化は部分的に進んでいますが、依然として経験や知識に依存する作業が多く存在します。

例えば適切な負荷量を知るために閾値を探す作業は、様々な負荷量で負荷試験を実行し、その結果を分析しながら段階的に負荷を調整していく必要があります。負荷量の調整ー負荷試験の実行ー結果の分析ー次の負荷量の決定という一連の反復的なプロセスは、今までの経験や対象システムのシステム特性を深く理解する必要があり、機械的な自動化を困難にしてきました。

例えばWebサーバーの負荷試験において、システムが安定して処理できる秒間リクエスト数の上限、つまり閾値を探す場合を考えてみます。
あるWebサーバーでは秒間リクエスト数を増やしていくにつれてCPU使用率が上昇し、その結果としてレスポンスタイムが徐々に悪化し始めるかもしれません。しかし別のWebサーバーではメモリ使用量が特定量を超えた時に、特定の処理でメモリリークが発生し、リクエスト数とは直接的な関係なしに突発的なエラーが発生するかもしれません。

このようにWebサーバーの種類や構成、アプリケーションの特性によって、負荷に対する反応は大きく異なります。このため全システム共通の負荷量で閾値を確認することができず、それぞれシステム固有の挙動を理解する必要があります。
そしてシステム固有の挙動を把握して適切な閾値を判断するためには、類似システムでの負荷試験経験や、対象Webサーバーに対する様々な負荷パターンの検証、さらに結果を分析する推論能力が必要となります。

また他にも、負荷試験結果の分析といった経験に基づく推論作業が多く存在します。

今回TQCチームでは、機械的な自動化が特に困難であった負荷量の閾値探しに着目し、AI技術であるMCPを使用して自動化を行いました。
さらにその前後の業務である負荷試験実行用スクリプトの作成と、負荷試験結果の保存についてもAIによる自動化を実現しました。

3. MCPとは?

負荷の閾値探し作業の自動化に活用した主要なAI技術であるMCP(Model Context Protocol)について、その概要を説明します。

MCP(Model Context Protocol)とは、AIが外部の様々なデータソースやツールにアクセスするためのプロトコルです。負荷の閾値探しにおいては、MCP経由で過去の負荷試験データ、現在のサーバーリソース情報、システム構成情報、負荷試験ツール(k6など)の状態といった情報にアクセスさせることができます。

4. どうやって負荷の閾値探し作業を自動化したのか?

ではどのようにして負荷の閾値探し作業を自動化したかについてお伝えします。
そのためにはまず、簡単な図ですが現在のシステム構成図を紹介します。
(システム構成図にはGeminiとPlaywright、k6に関して記載があると思いますが、そちらの説明も行うと長くなってしまうので割愛します)

特筆すべきは図の2~3と5~6です。
図の2~3で負荷試験実行用スクリプトの作成を行うのですが、ユーザーが「〇〇Webサイトにおいて、トップページへアクセス後、ログインページへ遷移してログインを実行してください。その後ユーザー登録を行うというシナリオで負荷試験を行ってください」と負荷シナリオをAIエージェントに指示すると、AIエージェントはPlaywright-MCPで指示された通りに〇〇Webサイトへアクセスした後、Playwrightから送信されたHTTPリクエストを再現する負荷試験実行用スクリプトを作成します。

そして図の5で負荷の閾値探しを行います。AIエージェントがk6を利用し、様々な負荷パターンを試しながら閾値を探します。例えば負荷シナリオを秒間20回実行した時に負荷がかからなかった場合、秒間30回で実行するといった動作を行います。
この時AIエージェントがレスポンスタイムやエラー率を確認し、負荷がかかっているかどうか判断します。

最後に図の6で負荷試験結果の保存を行い、AIエージェントは処理を終了します。
AIエージェントがMCP経由でファイルシステムにアクセスし、負荷試験結果を指定したディレクトリ配下に保存します。
例えば、送信に成功した合計HTTPリクエスト数、秒間HTTPリクエスト数、エラー率、レスポンスタイムといった負荷試験結果を指定したディレクトリ配下に保存します。

これだけでもすごく助かっているのですが、見て分かる通り今回は単一のAIエージェントで動作する構成になっています。
実は執筆前の技術検証時点では複数のAIエージェントを使用して、以下の構成で動作させていました。

  • 統括AIエージェント:以下AIエージェントの取りまとめ役。それぞれのAIエージェントと対話し、対話結果をユーザーに伝える役割
    • クローリングAIエージェント:クローリング専用AIエージェント。どんなWebページがあるか知る役割
    • 負荷試験実行AIエージェント:負荷試験を実行するAIエージェント。統括エージェントから渡された負荷試験実行用スクリプトを実行して、負荷試験を行う役割
    • ファイルシステムAIエージェント:負荷試験実行AIエージェントから負荷試験結果を受け取り、結果をファイルに保存する役割

今後は複数のAIエージェント構成による運用を行うべく再設計中になるのですが、なぜ今は複数のAIエージェント構成をやめて単一のAIエージェント構成にしているかには理由があります。

複数のAIエージェント構成を採用する場合、AIエージェント同士が対話を行い協力してタスクを進める過程において、予期しない問題が発生したのです。それはAIエージェント間での認識のずれや、意図しないAIエージェントへの間違った指示が発生し、結果として期待通りの動作が得られにくいという問題でした。

MCPの真価は、複数のAIエージェントがMCPツールを使った自律的な連携によって発揮されると僕は考えています。
例えば複数のAIエージェント構成を設計することで、以下の1~2と3を並行して処理することが可能になります。

1: 負荷試験の指示を行う統括AIエージェントはMCP経由でシステム情報を取得し、負荷シナリオ設計AIエージェントに負荷試験実行用スクリプトの生成を指示する。
2: 負荷シナリオ設計AIエージェントと負荷試験実行AIエージェントを協力させて負荷試験の実行を指示する。
3: Webサーバー監視AIエージェントがWebサーバーのリソースやWebページへアクセスして、負荷によってシステム異常が発生していないかユーザーに状況を報告する。

なお複数のAIエージェント構成を構築するにはA2Aという技術を使います。
A2A(Agent2Agent)とは複数のAIエージェント同士が対話し、互いに協力して目標を達成するためのプロトコルです。
このプロトコルを使用することで、AIエージェントがより複雑なタスクを処理できるようになります。
また、独自プログラムを実装せずにMCP同士を連携することが可能になります。
※ A2Aに則ったプログラムは必要です。

こういったこれらの結果を踏まえ、今後は自動化の業務範囲をさらに広げてより高度な負荷試験の実現を目指すべく、複数のAIエージェント構成を採用した上で以下の活用も予定しています。

  • ユーザーとの認識のすり合わせ:ユーザーが「〇〇機能にピーク時の80%の負荷をかけたい」と曖昧な要求を出した場合、MCP経由でシステムの運用データやシステム構成情報を参照し、「ピーク時」や「80%の負荷」を具体的な同時接続数やトランザクション数に落とし込むといった、要求の具体化とユーザーとの共通認識の構築に活用します。
  • テストシナリオの設計:複雑な業務フローの負荷シナリオを設計する際、各APIの依存関係やデータ連携の流れをMCP経由でAIに提供することで、網羅的かつ効率的なテストシナリオ設計に活用します。
  • 負荷試験結果の分析:試験結果やサーバーリソース情報をMCP経由で参照し、AIエージェントが異常の兆候やボトルネック箇所を推論します。
    例えば「特定APIのレスポンスタイムが平均値の3倍になっている」といった異常を認知し、対象APIにボトルネックがあるのではないかとユーザーに助言するよう活用します。

5. さいごに

最後まで読んでいただきありがとうございます。
TQCチームでは一緒に全システムの品質向上を行うメンバーを募集しています。
もっとTQCチームやレバレジーズについて知りたい方は会社説明資料をご覧いただき、ぜひこちらからご応募ください。

レバレジーズのアグリゲートサービス開発に飛び込む魅力とは?

こんにちは、ソリューション開発部でフリーランスHubの開発リーダーをしている吉本です。

レバレジーズでは様々なサービスを開発しており、その中にアグリゲートサービスがあります。

本記事では、レバレジーズで運営しているアグリゲートサービスの「フリーランスHub」と「mikaru」がどのようなサービスなのかを以下の内容をもとにご紹介していきます。

アグリゲートサービスとは

インターネット上には、日々膨大な情報やサービスが生まれています。

ユーザーは複数の情報源やサービスを行き来し比較する必要に迫られ、それは煩雑で非効率的であったりします。

その課題を解決するため、複数の異なるデータソースやサービスから情報を集約し提供するサービスがアグリゲートサービスです。

その中で、レバレジーズで運営している「フリーランスHub」と「mikaru」をご紹介します。

フリーランスHubとは

フリーランスHubは2021年4月にサービスリリースし、「フリーランスのインフラとなるサービス」をコンセプトに、現在はフリーランスエンジニア・クリエイター案件を中心にサービスを展開しているアグリゲートサービスです。

サイト内では、案件を言語や職種別に検索でき、案件の保存や保存した検索条件による新着案件メールを受け取る事などができ、自分にあった案件を見つけることができます。

フリーランスになるならまずフリーランスHubに登録するという世界を目指してサービス拡張しています。

現在は案件以外の提携サービスの紹介なども行っています。

mikaruとは

mikaruは2023年6月にサービスリリースし、医療・福祉領域における求人を中心に全国の人材紹介会社から集約した求人を掲載しているアグリゲートサービスです。 給与や職場環境などの条件で求人の検索ができることに加え、紹介会社の特徴やメリットなどを比較でき、自分にあった求人を見つけることができます。

開発体制について

チーム構成

フリーランスHub、mikaruともに、マーケター、エンジニア、デザイナーの職種が所属して日々開発を進めています。

マーケター、エンジニア、デザイナーの距離が近く、施策構想段階から各職種と相談しながらサービス開発を進めたりということもあります。

データをもとにマーケターとエンジニアで案件のレコメンドロジックを検討するなど、エンジニアも顧客価値の最大化に貢献できることがレバレジーズの強みです。職域を超えて連携することで、よりユーザーに響くサービス開発を実現しています。

エンジニアはフロントエンド、バックエンドの役割分けをしておらず、全員がフロントエンド、バックエンドの開発に携われるため様々な開発言語を経験できます。

また、インフラ構築も自チーム内で行っております。

技術スタック

フリーランスHub、mikaruともにいくつかのサービスがあり、そのサービスごとに適した開発環境を採用しています。

  • フロントエンド:Nuxt.js、Next.js
  • バックエンド:PHP(Laravel)
  • バックグラウンド処理:Go、PHP
  • インフラ:AWS(Aurora、ECS、SQS、OpenSearchなど)
  • データベース:MySQL
  • メール送信:SendGrid
  • バージョン管理:GitHub
  • CI/CD:GitHub Actions

最近では、Amazon Bedrockなどの生成AIをサービスに活用したりしています。

多くの案件・求人が存在するので、以下のような様々なアプローチで処理効率向上を実現しています。

  • バックグラウンドでのSQSを用いた非同期処理
  • データベースのパーティショニング
  • 効果的なキャッシュ活用

やりがい

フリーランスHub、mikaruともにエンジニアが実施した施策がサービス利用者数向上につながりやすいサービスです。

自分たちが実施した施策により、メディアを通じて人々が最良の選択ができる世界の実現に貢献することができます。

フリーランスHubについては、フリーランスエンジニア・クリエイター案件のアグリゲートサービスとしては一定の知名度を獲得してきたため、今後はよりフリーランスのインフラとなるようなサービスを追加し、フリーランスになるならまずフリーランスHubに登録するという世界を実現するためのフェーズに突入します。

mikaruは参入した業界規模が大きく扱う求人数が多いため、よりシステムの処理効率向上とスケールを意識した開発を行い、業界No.1を目指すフェーズです。

フリーランスHub、mikaruとも、単にプロダクトを作るだけでなくそれぞれのフェーズで「どうやって顧客への価値提供するか」を考えながら、マーケターやデザイナーと取り組んでいるため活発な環境です。

終わりに

ここまで読んでいただき、レバレジーズのアグリゲートサービスの魅力を感じて頂けたのではないでしょうか。

レバレジーズでは一緒にプロダクトづくりに取り組むメンバーを募集中です!

ご興味いただけましたら、カジュアル面談を実施しておりますのでお待ちしております。