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を使いこなしているメンバーのノウハウを共有 仕様駆動開発の効果と効率性を実感（後述） 今までコーディングをしたことがないデザイナーがレスポンシブデザインを実装！ 普段開発に関わらないPdM２名が新機能を開発！！ 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テスト工数を削減して、探索的テストに当てられないか？という試みを行っています。 テスト観点表はすでに出来ていたのですが、それを実際新機能に使ってみることがまだ出来ていなかったので、今回の合宿はその実践の場になりました。 【合宿１週間前】チーム分け・準備 そういった素地があって企画が始まったAI開発合宿。 合宿の前週から実質的に参加者はその準備を始めました。 まずチーム分けと「実務のプロダクトに新機能を付ける」というテーマ、「27時間で各グループでAI駆動開発を実践、開発の精度やAI活用度合いを競う」というワーク、そして 優勝者には豪華焼肉という重大な事実が共有されました。 チーム紹介 プロダクトを軸に3つのチームがエントリー。 労務管理チームとして集まった4人は以下のような構成でした！ 労務管理・年末調整PdM UI/UXデザイナー 年末調整担当エンジニア 労務管理担当エンジニア（私） 私とPdM以外は労務管理の開発に関わったことはなく、ましてやデザイナーはほとんどコーディングというものをしたことがない。 どーなっちゃうの？！と言いたいところですが、実際にはこのチーム強いな、と思ってました。 なぜなら年末調整担当のエンジニアは、ほぼ一名でレビューまで全てAIとのタッグで開発を回しているのを日々隣の席で見てましたし、デザイナーも恐るべきキャッチアップ力で新プロダクトのPoCを回したりAIでデザイン業務改善を進めていることを知っていたからです。 そこに3度の飯よりAIが好きなPdMもおりますから、全く不安はなく、 これはイケるぞ焼肉！！ と思いました。 テーマ選定 「合宿後も役立つ成果を」ということで、各チームでプロダクトの未実装企画の中から事前に決めました。 事業部長とどんな機能が実装できたら熱いかなどを話し、事業へのインパクトを考慮してチョイス。 結論的に、私のチームは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 冬」 の様子を紹介します。 今回のテックフェスは「 セキュリティ 」 を軸に、 基調講演、総勢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 秋レポート

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求人ページ 会社説明資料

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求人ページ 会社説明資料

はじめに プロジェクトの立ち上がりの背景 こだわり①：技術的な「実験場」として遊び尽くす 1. モダンな技術を自由に選ぶ AWSアーキテクチャ 技術スタック 2. 職種の壁を越えた「やりたい」の尊重 こだわり②：運用は「いちプロダクト」として本気で向き合う おわりに We are hiring! はじめに こんにちは。レバレジーズ テクノロジー戦略室 SREチームの横江です。 普段は、事業部横断で他チームのSRE活動をサポートしています。 今回は、私がpdm（プロダクトマネージャー）を務め、有志メンバーと 「サイドプロジェクト」 として開発した社内テックブログ 「prairie post（通称：ぷれぽす）」 についてのお話です。 ぷれぽすのアイコンです 「社内の課題を解決したい」という思いから始まったこのプロジェクトですが、ただのツール作りには留まらないプロジェクトになりました。 そこは、エンジニアとして技術を楽しむ実験場であると同時に、 ユーザーに向き合いサービスを育てる「本気のものづくり」の場 でもあったのです。 技術選定の自由度が高い環境で挑戦したい 職種の枠を超えて、技術領域を広げたい 作ったものを改善し続ける「プロダクト志向」な開発がしたい そんな「技術もプロダクトも好き」なエンジニアの方に、レバレジーズでの開発の雰囲気が少しでも伝われば嬉しいです！ プロジェクトの立ち上がりの背景 「気軽にアウトプットできる場が欲しいから、社内ブログを作りたいな」 プロジェクトが始まったきっかけは、室長からのシンプルな一言でした。 この言葉の裏には、プロジェクト始動のきっかけとなる課題意識がありました。 弊社には多くのエンジニアが在籍していますが、当時はナレッジ共有に「改善余地」があり、横断的に知見を活かせる場づくりが必要だと感じていたのです。 ※ 記載している課題感は、当時の状況を踏まえたプロジェクトメンバー個人の視点であり、組織やプロセスそのものを否定するものではありません。 そこで、「それなら自分たちで作ろう」とテクノロジー戦略室内部で有志を募りました。 データエンジニア、TQC（品質管理）、SRE/プラットフォームエンジニア、AIエンジニア など、多様な職種のメンバーが集結しました！ 私たちは、以下の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! この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか？ 私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。 あなたからのご応募を、心からお待ちしています。 会社説明資料 採用情報はこちら（HRMOS） まずはカジュアル面談から

はじめに こんにちは、レバレジーズ株式会社で普段は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. 今回のテックフェス、朝から会場がいい香りに包まれていたのをご存じでしょうか？ 実は 社内エンジニア有志の「コーヒー事業部」 がコーヒーを提供してくれてました！ コードも書けて、豆も挽ける。そんな “フルスタックな男たち” の奮闘記は こちら 過去のテックフェスレポート テックフェス2025Winter レポート - Leverages Tech Blog テックフェス2024夏 レポート - Leverages Tech Blog レバレジーズ テックフェス2024冬レポート - Leverages Tech Blog レバレジーズテックフェス 2023 春レポート - Leverages Tech Blog テックフェス2022秋レポート React Suspense ~ v18から見えること ~ - Leverages Tech Blog

こんにちは、レバレジーズの 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 ■開発部の雰囲気がもっとわかる動画はこちら！

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

読む前に この記事に出てくる「珈琲事業部」というのは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

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推進チームの苑田です！ 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日に予選があり、作ったアプリケーションを披露する必要があります。 スケジュール は上記の通りですが、通常業務や諸々の対応をしていると、実際の構築期間は ３週間 となりました。当然、通常業務もあるので、メンテ性と可読性の品質を担保する開発ではなく、 スピード重視の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 と意味不明なことを言ってました。しかし、 発表１週間前 に大問題が発生しました。 これ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エージェントは目的を達成するためにタスク分解して処理をするので、最終的なゴールがフロントに表示することであれば、こういうコードを書いてしまうのは当然でした。 「なるほどな〜」と思いながらリファクタリングをしようとしたのですが、人間の介入はしない前提で開発を進めていたため、ここからが地獄の始まりでした。 人間によるリファクタリング 発表１週間前に黒魔術コードが完成 してしまったので、以下の内容でリファクタリングを行うことにしました。 過剰な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は同じプロンプトでも生成する内容が異なるため、２〜4並列でAIに同じプロンプトで生成させ、その中でいいものを選択していました。私たちはこの開発を リセマラ駆動開発 と呼んでいます。 完成！ 無事予選前日の深夜12時にアプリケーションが完成 しました。なんとか完成したのでワイワイしていると、スライド作成していないことに気づき、予選当日の開始１時間前にスライドが完成しました。ここら辺の話は色々あったので、また別のタイミングで話せたらなと思います。 実際にAI駆動開発やってみた結果 今回色々な仮説をもとに検証を行なっていましたが、 AIが開発しやすい環境を作成した途端、爆発的に開発が進みました 。 AIが指示通りに動いてくれない理由は、 考えることが多すぎて変な方向に進んでいく からという結論になりました。AI駆動開発はコーディングしてもらうだけだと思っていたので、タスクを処理しやすいように環境を整えてるのは新鮮で面白かったです。 また、ある程度コードを人間が読めるようにする必要があると感じました。今回はハッカソンだったので最悪全部壊せばいいですが、本番稼働しているアプリだと必ず人間がリファクタリングする必要があります。したがって、 ある程度人間が読めるようにドキュメントを整備したり、コーディング規約を言語化しておく ことで、最悪の事態は避けられると思います。 どうすればもっと開発が楽になるか考えてみた ひとまずアプリをリリースできましたが、今後組織に普及していくために、チーム内でどうすればもっと開発が楽になるかを考えました。話題として上がったのが AIが暴走してしまい、人間が対応するのが大変だった という点です。実際に試したわけではないので話半ばで聞いて欲しいですが、チーム内で結論付けたことを記載しておきます。 テストを書く 今回スピード重視で開発していたため、テストを書かずに構築していました。しかし、AIは目的を達成するために、モックを作ったり、都合のいい処理を書いたりします。明確なテストを用意しておくことで、ある程度この暴走は抑えられるのではないかと考えました。 また、AIがすごいスピードでリファクタリングするので、いきなりコードが動かなくなることも多々ありました。その観点でも、テストがあると人間は安心でき、AIもテストが失敗したら修正を行なってくれるので、チーム内では必須だと結論付けました。 しかし、テストを書いたとしても、そのテストが通るようにコードを生成したりするので、ある程度人間がレビューする必要があります。 プロンプトを使い分ける copilot-instructions.md に守って欲しいことや設計手法など全部記載しても、AIは完全にそれ通りに動くわけではないことを学びました。 したがって、TODO作成プロンプト、構築プロンプト、テストプロンプトのように、プロンプトを分けることで役割分担するのもいいのではないかと考えました。 今回のハッカソンでは、各専門エージェントを使用したマルチエージェントで構築しており、1つのエージェントで構築するより精度が向上しました。 この要領でプロンプトを分ける(claude codeだとカスタムスラッシュコマンド)と、AIが暴走することは少なくなると思います。 まとめ Copilotのプレミアムリクエストが１週間で無くなった時はどうなるかと思いましたが、なんとか乗り切ることができました。 期限内に構築完了し、準優勝できたのは、間違いなくAI駆動開発のおかげだと思っています。 次の目標としては、このAI駆動開発をもっと楽にするような仕組みを開発して、他のチームに展開していきたいです。 おまけ 引き継ぎコンシェルジュ ko☆shi で出しましたが、 引☆継☆王 ko☆shi の可能性もありました。 この命名を考えるのに、冗談抜きで数時間かかったので、もっとマシな会話をしたらよかったなと反省しています。 最後に 最後まで読んでいただきありがとうございます！AI推進チームでは一緒にAI推進を行うメンバーを募集しています！もっとAI推進チームやレバレジーズについて知りたい方は会社説明資料をご覧いただき、ぜひこちらからご応募ください！ AIソリューションアーキテクト（AIエンジニア） AI/機械学習系 研究員

はじめに こんにちは！レバレジーズに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

はじめに はじめまして! テクノロジー戦略室先端技術グループの永安と申します。普段は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に関する技術開発を行うメンバーを募集しています。ビジネスに関わる領域で研究しつつも裁量を大きく持てるところが魅力だと思います。少しでも興味を持っていただけた方は こちら からご応募いただけると嬉しいです。

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」と「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とも、単にプロダクトを作るだけでなくそれぞれのフェーズで「どうやって顧客への価値提供するか」を考えながら、マーケターやデザイナーと取り組んでいるため活発な環境です。 終わりに ここまで読んでいただき、レバレジーズのアグリゲートサービスの魅力を感じて頂けたのではないでしょうか。 レバレジーズでは一緒にプロダクトづくりに取り組むメンバーを募集中です！ ご興味いただけましたら、 カジュアル面談 を実施しておりますのでお待ちしております。

こんにちは、レバレジーズ株式会社医療テック事業部の大島です。 本記事では、医療・介護業界に特化したバーティカルSaaSとして「わんコネ」がどのように開発され、どのような課題を乗り越えてきたのか、その過程と得られた知見をまとめています。厳しい法規制下でのセキュリティ要件や、業務でパソコンを使わない現場との連携など、一般的なSaaS開発とは異なる特有の苦労が存在します。そうした実態と課題解決のポイントを順を追ってご紹介します。 ◆わんコネとは？ わんコネ は、病院や施設での入退院連携業務を効率化するために開発されたバーティカルSaaS（特定業界特化型クラウドサービス）です。 入退院連携とは、患者が入院している医療機関や介護施設から、別の病院や施設へ転院・入居する際に行われる一連の手続きを指します。具体的には、メディカルソーシャルワーカー（MSW）や退院支援看護師が患者の病状や希望を踏まえながら、受け入れ先の候補を探し、連絡・調整を行う必要があります。 しかし、現在の多くの医療・介護現場では、転院先候補とのやり取りが電話やFAXなど従来型のアナログ手段に依存しており、以下のような課題が発生しやすくなっています。 情報共有の煩雑さ 複数の施設に問い合わせる際に同じ内容を繰り返し説明しなければならないため、担当者の負担が増える。 進捗の不透明感 調整がどの段階まで完了しているのか、複数の担当者や関係機関がいつでも把握しづらい。 業務負担の増大 連絡ミスやFAXの送信漏れなど、人的ミスを誘発しやすく、担当者に精神的なストレスがかかる。 わんコネでは、こうした課題を解決するために、入退院支援業務の進捗管理やコミュニケーションを一元化できる仕組みを提供しています。具体的には以下のような特徴を持ち、MSWや退院支援看護師のみなさまの負担軽減を目指しています。 リアルタイムでの情報共有 患者の転院進捗や問い合わせ状況を、関係者全員がリアルタイムで把握可能。 安全性・信頼性の確保 患者情報など機密性が高いデータを取り扱うため、通信の暗号化やアクセス権限管理などセキュリティ面を万全に整備。 導入のしやすさ クラウドベースで提供されるため、お客様でインストールなどの手間をかけずに導入可能。 患者一人ひとりにとって最適な転院先をスピーディーに見つけ、スムーズに移ってもらうためにも、入退院連携を効率化するわんコネは医療・介護現場にとって欠かせない存在になりつつあります。 こうした医療・介護分野特化型のバーティカルSaaSがもたらす最大の利点は、「現場で必要な機能を現場に寄り添った形で提供できる」ことです。一見するとニッチに見えるかもしれませんが、非常に大きな社会的インパクトがある領域でもあり、現場レベルから効率化を図ることは、少子高齢化社会において重要なテーマといえます。 ◆医療介護業界の特徴と課題 医療・介護分野は超高齢社会の日本において、今後ますます重要性が高まる領域です。しかし、ICTの導入が遅れていることや複雑な法規制が存在することなどから、他業界では当たり前に進んでいるデジタル化が進まず、人力による属人的な業務が数多く残っているのが現状です。ここでは代表的な課題を4つ取り上げ、それぞれ詳しく解説します。 ICT化の遅れとアナログ文化 電話・FAX・紙台帳が今なお主流。情報を重複入力する非効率や伝達ミスが日常的に発生しています。 超高齢化による業務量の急増 患者・利用者は年々増加する一方で、MSWや看護師は慢性的に不足。転院調整に割く時間と負荷が膨らんでいます。 複雑な法規制・セキュリティ要件 個人情報保護法や医療法などに厳格に準拠する必要があり、高いセキュリティ設計と運用体制が導入のハードルになります。 属人的フローと暗黙知 病院ごとに手順がばらつき、業務ノウハウが個人に依存。新人や異動者がすぐに戦力化しにくい構造的課題があります。 ◆わんコネが解決に挑む課題 1. 施設データの“ばらつき”と更新負荷 病院・介護施設ごとに項目名や表記が統一されておらず、空床や診療科情報を最新の状態で保つのが困難。 MSW が電話・FAXで都度確認するため、転院調整に時間がかかる。 2. 高いセキュリティ水準と複雑なアクセス制御 機密性の高い情報を取り扱うため、業法や業界ガイドラインなどにより高いセキュリティ水準が求められる。 病院と施設の多職種ユーザーが同じデータを扱うため、細かな権限設定と監査証跡が求められる。 3. 病院ごとに異なる属人的フロー 入退院調整の手順や判断基準が施設・担当者ごとにばらつき、暗黙知に依存。 進捗管理や帳票作成が個人任せになり、新人や異動者は即戦力になりにくい。 ◆わんコネの開発内部 ─ 課題と解決のリアル わんコネは「医療・介護業界における入退院連携業務を効率化する」という大きなミッションを掲げ、日々開発と運用を続けています。 その過程では、業界特有の複雑さや法規制、電話やFAXなどを用いた属人的な業務など多くの課題に直面しました。ここでは、代表的な開発上の課題とその解決策、さらに得られた教訓をご紹介します。 1. 施設データのばらつきと最新性 課題 病院・施設情報（病棟構成、病床数、診療科、介護サービスなど）が多岐にわたり、表記や更新頻度が統一されていない。 入退院連携をスムーズに行うには最新かつ正確な施設情報が必要だが、従来は利用者が手作業で都度確認していた。 解決策 データモデルの設計と自動整形 データベース側で標準化のためのスキーマを設計し、機械的に表記ゆれなどを修正する仕組みを導入。 継続的なデータ更新フローの構築 定期的に施設へ更新を促すフォームやAPIを用意し、担当者自身にメンテナンスを行ってもらう運用を実施。 検索・マッチングアルゴリズムの最適化 空床数や診療科、地域など多種多様な条件を高速かつ正確に検索できるよう、インデックスやキャッシュを最適化。 得られた教訓 完璧なデータベースを最初から目指すのではなく、施設スタッフが継続的に更新しやすい仕組みづくりが重要。 現場が「使いたくなる」UXやインセンティブを提供することで、データの鮮度を保ちやすくなる。 2. セキュリティと法規制への対応 課題 機密性の高い患者情報を取り扱うため、医療・介護現場ごとに厳格なルールがある。 病院と介護施設が同じシステム上で情報を閲覧・編集するため、アクセス権限を細かく制御しなければならない。 業法や業界ガイドラインへの対応。 解決策 権限管理とアクセスコントロールの設計 患者データの閲覧範囲を設計観点に盛り込む セキュアなクラウド基盤の選定と設計 医療データに対応可能なクラウドサービスを利用し、通信の暗号化、バックアップ、DR（災害復旧）対策を整備。 定期的なセキュリティ診断の実施 レバレジーズ内部の品質管理チームによる定期的なペネトレーションテスト（模擬侵入テスト）や脆弱性診断を実施。 業界ガイドラインへの対応 厚労省ガイドラインには様々なセキュリティ要件の記載がありますが、例えば、今後必須化される予定になっている2要素認証にも先行して対応済み。このように順次ガイドラインへの準拠を実施しております。 法規制・ガイドライン対応のドキュメント化 サービスに関連する法規制やガイドラインをドキュメント化し、アップデートがあるたびに対応方針を更新。 得られた教訓 技術面だけでなく運用面のルール整備やユーザーへの周知が不可欠。 セキュリティと利便性はトレードオフになりがちなので、エンジニア・プロダクトマネージャー・法務/セキュリティチームが密接に連携し、バランスを取ることがポイント。 設計観点だけではなく、ロールベースアクセス制御（RBAC：Role-Based Access Control）のような仕組みが今後必要 3. 属人化された業務プロセスの吸収 課題 病院や施設によって入退院調整フローが異なり、属人化が進みやすい。 MSWや看護師など個々のノウハウで業務が成立しているため、新人が担当すると一気に効率が落ちる。 「進捗管理」「メッセージのやり取り」「患者情報の帳票作成」など多岐にわたる要素を、どこまでシステム化するかが難しい。 解決策 プロセスの可視化とフロー設計 ユーザーインタビューを重ねて入退院調整の共通項を抽出し、ワークフローを定義することで「誰がいつ何をするのか」を明確化。 コラボレーション機能の拡充 チャット機能、メモ機能を取り入れ、複数担当者がリアルタイムで連携しやすい仕組みを整備。 業務手順・帳票のテンプレート化 ベテランスタッフの暗黙知を整理し、必要項目や操作手順をテンプレート化。施設ごとの細かなカスタマイズも許容する柔軟性を持たせる。 得られた教訓 フローが複雑な業務ほど、無理に100％標準化するよりも、ある程度のカスタマイズを認めることで導入ハードルを下げられる。 システム導入と並行してユーザートレーニングや運用ルールの策定を行うことで、属人化の解消が加速する。 ◆まとめ：課題解決型アプローチが生み出す医療介護SaaSの価値 わんコネは、医療・介護業界における入退院支援の非効率や属人化という根本的な課題に対して、4つの大きなテーマを軸に解決策を追求してきました。 これらの取り組みを通じてわんコネが得た大きな学びは、 技術はあくまで課題解決の“手段”であり、現場の声とニーズを起点に柔軟に選択・最適化していくことが重要 だという点です。医療・介護のように法規制が厳しく保守的な分野では、現場に馴染みながら着実に業務を改善するアプローチが求められます。 属人化の解消には、技術だけでなく現場フローの深い理解とユーザーの声の反映が不可欠。 初期段階からセキュリティ要件を組み込み、やり取りする個人情報を最小限に抑える設計を行うことで、導入障壁を下げられる。 既存業務を尊重しながら小さなステップで新しい仕組みを定着させるハイブリッド開発は、保守的な業界との相性が高い。 わんコネは今後、より多くの医療機関・介護施設にご利用いただき、業務効率化のご支援ができるよう、さらなる機能拡充を計画しています。患者様の命や生活の質を最優先に考える医療・介護の現場でこそ、 「現場の負担軽減」と「業務効率化」を両立する デジタルソリューションが求められています。わんコネはそのニーズに応え、社会全体に貢献するサービスとして、これからも着実に進化し続けます。 現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ 採用サイト をご覧ください。 hrmos.co

はじまり はじめまして、テクノロジー戦略室TQCチームの柳澤といいます。ちいかわ大好きエンジニアをしています。 TQCとはあまり聞き慣れない名前かもしれませんが、Total Quality Controlの略で全社的なシステム品質管理を担当しており、負荷試験や脆弱性診断などのテストを通じて各システムの品質向上に取り組むことも多いです。 かくいう私も負荷試験を担当することが多くなり、どうやって負荷試験をやっているのかと聞かれることが増えてきたため、自分が初めて負荷試験を担当した時を思い出しつつチームの負荷試験実施方法についてご紹介できればと思います。 さて、あれはTQCチームに入って数ヶ月、仕事にも慣れてきた頃…突然先輩に言われました。 「そろそろ柳澤さんに負荷試験やってもらおうかな！」 なんということでしょう。前職で負荷試験を担当していたのはエンジニア歴が20年くらいの熟練エンジニアばかり。チームに入ってきたばかりの私がそんな難易度高そうな仕事ができるだろうか。負荷試験をやったことがない私には最終的に失敗して「泣いちゃった！」なんて言われる未来しか見えません。 「わァ…あ…」なんとか言葉を捻り出し、申し訳ありませんがお断りしますの意を伝えたところ、「 k6だったら簡単に負荷試験できるから大丈夫ですよ！ブラウザで見た内容をそのままテストシナリオにできるんで！ 」え、そうなの？それならなんとかなるかな…。こうして頭の中で「なんとかなれーッ！」と叫びながら実施する負荷試験が始まったのでした。 k6とは タイトルにもある通り、TQCチームはk6というオープンソースの負荷試験ツールを使用しています。Go言語で作られていてパフォーマンスが良いのが特徴ですが、私たちエンジニアにとって嬉しいのは、 テストシナリオをJavaScriptで書ける こと。普段フロントエンドやNode.jsで慣れ親しんだ言語で書けるので、学習コストが低く、直感的にシナリオを組み立てることができます。 主な特徴はこんな感じです。 開発者フレンドリー : JavaScriptでシナリオを書けるほか、CLIツールが非常に使いやすいです。 パフォーマンス : Go言語製のため、少ないマシンリソースで高い負荷を生成できます。 豊富な連携機能 : 実行結果をGrafanaなどの外部サービスに連携すればリッチな可視化もできます。 これまで負荷試験というと、専門的なツールや複雑な設定が必要なイメージがありましたが、k6は「開発者が、開発プロセスの中で継続的に実施すること」を重視して作られているため、私のように初めて負荷試験を担当するような人でもとっつきやすい設計になっているのです。 har-to-k6を使ってテストシナリオを効率的に作る 先輩が言っていた「ブラウザで見た内容をそのままテストシナリオにできる」の正体がこれ、 har-to-k6 です。これは、 ブラウザの開発者ツールで記録した通信内容（HARファイル）を、k6のテストシナリオに変換してくれる 魔法のようなツールです。 使い方はとっても簡単。 1. ブラウザで操作を記録する Firefoxの開発者ツールを開き、「Network」タブを選択します。(Chromeをご利用の方は適宜読み替えてください) 設定ボタンから「Persist Logs」にチェックを入れ、記録を開始します。 負荷試験の対象としたい一連の操作（例：ログインして、見たい記事へのリンクをクリックするなど）を実際に行います。 2. HARファイルを保存する ここまでの操作でネットワークログが貯まったはずなので、それらを負荷試験対象サイトのドメインのログだけに絞り込むため、「Filter URLs」の枠内に「domain:hoge.jp」のように入力しておきます ログの絞り込みができたらネットワークログが表示されているところで右クリックし、「Save all as HAR」を選択してHARファイルを保存します。 3. k6スクリプトに変換する 保存したHARファイルを har-to-k6 コマンドで変換します。 har-to-k6 your-file.har -o loadtest.js たったこれだけで、実際のブラウザ操作に基づいたリアルなテストシナリオの雛形が完成します。あとは生成されたloadtest.jsを少し手直し（不要なリクエストを削除したり、動的な値をパラメータ化したり）するだけで、すぐに負荷試験を開始できるのです。APIの仕様書を片手に、一つ一つリクエストを組み立てる…なんて手間が不要なので喜びがあります。 次のようなコマンドでテストシナリオを実行するだけで負荷試験が動き始めます。 k6 run loadtest.js しかし、このままでは負荷試験としては十分ではありません。実際にこのまま実行した方はお気づきだと思うのですが、並列実行数=1、実行シナリオ数=1となるため負荷が全くかかっていない状態にあることが分かります。 ここでloadtest.jsのソースコード中のoptionsを以下のように変更してみましょう。 export const options = { discardResponseBodies: true, scenarios: { contacts: { executor: 'shared-iterations', vus: 20, iterations: 300, maxDuration: '300s', gracefulStop: '30s', }, }, } ここで重要なのは vus 、 iterations です。 vus : Virtual Usersの略。サイトに同時アクセスしているユーザー数と考えて良い。 iterations : 負荷試験シナリオが全体として回った数。300と指定するのであれば全VUsがシナリオを合計300回実行完了したら終了となる。 この2つを使いこなせれば多くの負荷試験課題に取り組めるようになります。 実行結果の集計がわかりやすい k6は、実行後の結果サマリーが非常にわかりやすくまとまって出力されるのも魅力です。 実際にこちらの画像のような結果が標準出力で表示されます。 http_req_duration （リクエストの応答時間）の平均(avg)、中央値(med)、最大(max)、p(95)（95パーセンタイル値）などが一目でわかり、システムの性能を多角的に評価できます。 また、先述のvusとiterationsについては画像下部の vus_max と（紛らわしいですが） iterations に数値が反映されていることが分かると思います。 実際の運用のお話 さて、ここまでで負荷試験を実施して結果を出す、というところまではできるようになるはずです。そうなると、次はどうやって使えば効果的な負荷試験が実施できるのかという話になってきます。 あくまで私の経験的な持論にはなるのですが、負荷試験は試験回数を増やして 負荷状況を立体的に把握 していくということが大事になります。 ここで再び vus と iterations に焦点を当て、その値を調整しながら何度も負荷試験を実行してみましょう。例えばvus=10、iterations=100で実行したらシステムは負荷が小さくサクサク試験が動いていくはずです。 しかし、vus=100、iterations=500にして実行してみた時はどうでしょうか？あるいはvus=300、iterations=1000にして実行してみてください。かなり負荷が高くなって完了まで時間がかかってきたり、あるいはiterationsの完了数が全く増えないなどの変化が見えてくるのではないでしょうか。 もし想定通りの負荷状況になっていなければ、そこには何かボトルネックとなる要素があるはずです。例えば実はDBが負荷に耐えられなくなって処理が止まってしまっていたり、ネットワークのトラフィックが捌ききれなくなっていたりなど様々な可能性があります。このような 隠れていた要素を明らかにすること に私は 負荷試験の価値 があると考えます。 もちろん、同時アクセス数=100に耐えられることが確認できればOK、というような要件の場合は単純にvus=100で実行してhttp_req_durationが大きく増えたりしないことが確認できれば完了にしても良いかもしれませんが、先述のような負荷状況の変化を把握できるようにしておけば、 過剰でも過小でもない最適なインフラリソースを実現できているか といった結論に辿りつけるため、実際に負荷試験を始める方はまずはここを目指していくのが良いと思います。 気になる部分と課題 k6は素晴らしいツールですが、使っていく中で「こうだったらもっと良いのに…」と感じる部分もありました。 複数のシナリオやvus設定で実行して結果を一覧で見たい時に辛い 負荷試験を進めていくとvusを小さい値から大きい値にして変化を見たり、ユースケースに従って複数のテストスクリプトを作り実行するということが発生すると思いますが、そうなったときに前述の画像のような結果出力だけだと、まとめるのに苦労するようになります。 Grafanaなどの外部サービスと連携させていれば複数シナリオをまとめて把握するのも楽になるのかもしれませんが、私たちのチームではまだ連携するまでには至っていなかったため、標準出力の結果をスプレッドシートにまとめて関係者には共有していました。しかし、作業としては大変だったため、ここも自動化することが課題となっています。 認証情報の更新が大変 Webアプリケーションの負荷試験では、ログインして取得した認証トークン（JWTなど）を後続のリクエストに含める必要がありますが、このトークンの有効期限が短い場合、テストの途中でトークンが無効になっても自動で更新する仕組みは標準では提供されていないため、「リクエストが失敗したらトークンを再取得してリトライする」ということをなんとか実現していました。しかし、毎回それをやるのは手間なのでプラグインなどを利用してログイン情報の自動取得を実現したいと思っています。 また、ログイン情報の自動取得が実現できれば多数の別個のユーザーがWebアプリケーションに負荷をかけるというシナリオを作成できるようになるため、かなり負荷試験の幅が広がると考えており、それが今後解決するべき課題となっています。 おわりに 「負荷試験」と聞いただけで震えていた私ですが、 k6 と har-to-k6 のおかげで、なんとか負荷試験を完了させ、無事にタスクをやり遂げることができました。特に、 実際のブラウザ操作を元にシナリオを自動生成できる手軽さ は、負荷試験初心者にとって本当に心強い味方です。 もちろん、認証周りのように少し工夫が必要な場面もありますが、基本的な負荷試験であれば驚くほど簡単に始められます。もし、あなたがかつての私のように「負荷試験こわい…」と思っているなら、ぜひk6を試してみてください。 最後になりますが、TQCチームはシステム品質の向上を目指し全社的に活動できるメンバーを募集中です！システムの品質向上やテストに関心がある方はカジュアル面談もできますのでお気軽にご連絡ください！色々とお話しできることを楽しみにしています。 hrmos.co

はじめに こんにちは、レバレジーズテクノロジー戦略室SREチームのLEEです。 テクノロジー戦略室では部署横断的な技術に関するプロジェクトを推進しており、私が担当しているのは Kubernetes（クバネティス） の導入と将来的にプラットフォーム化していくプロジェクトです。 ところでみなさん、Kubernetes（以下K8s）について最近気になっていませんか？ 気になりますよね？ そう、気になるんですよ。 そんなみなさんに本記事ではレバレジーズテクノロジー戦略室が推進するK8s化プロジェクトの導入事例やメリットについてご紹介いたします。K8sについてまだよくわからない方もご安心ください、簡単に説明させていただきます。 K8sのよさ K8sって何？ K8s は、コンテナ化されたアプリのデプロイ、スケーリング、管理を自動化するためのオープンソースのプラットフォームです。コンテナオーケストレーションツールとして広く利用されており、複雑なアプリケーションの運用を大幅に簡素化できます。 コンテナ化されたアプリを運用するのに最適なツールです。比較的大規模かつ可用性を必要とするシステムに向いていると言えますね。 K8s、特にEKSのよさ EKSとは？ EKS EKS（Amazon Elastic Kubernetes Service） は、AWSが提供するマネージドK8sサービスです。AWSの他のサービスと簡単に連携できたり、メンテナンスを一部AWS側でサポートしてくれます。 一番便利だと感じたのはAWS側が コントロールプレーンを 管理してくれるところですね。K8s導入のネックと言われる頻繁なバージョンアップデートも、EKSならAWS側のサポートありで対応できます。イメージとしてはAurora RDSと同じですね。マネージドノードグループを使うことで、バージョンアップグレードも思ったより簡単にテストできて便利です。より詳しいバージョンアップ戦略についてはまた別の機会に紹介します。 バージョンアップに関する公式のドキュメントは こちら 。 ※ コントロールプレーンって何？ K8sのメリット、デメリット K8sってどんなメリットがあるの？デメリットは何？って思いはじめた頃なんじゃないでしょうか。 それでは以下をご覧ください。 メリット 高い柔軟性と拡張性: K8sは豊富な機能と拡張性を備えています。あらゆる規模のアプリケーションに対応でき、親和性の高いOSSツールも多く、高度なデプロイ戦略やワークフローの実装が可能です。 高い可用性と信頼性: アプリケーションの自動的な再起動や配置により、ダウンタイムを最小限に抑え、高い可用性を実現します。 活発なOSSコミュニティ: K8sはGoogleで開発され、今や世界中の開発者から支援されているプロジェクトであり、活発なコミュニティが存在します。技術的なサポートや情報が豊富で、 公式ドキュメント も優れています。 効率的なリソース管理: コンテナ化されたアプリケーションを効率的に管理し、リソースの利用率を最適化できます。 デメリット 複雑性: 導入するまでの敷居が高く、運用が少し複雑で、高度な知識やスキルが必要です。 学習コスト: 習得に時間がかかり、学習コストが高い方です。 リソース消費: K8s自体が一定のリソースを消費します。中規模以上のプロジェクトでは気にならない程度ですが、小規模なアプリケーションや環境では、オーバーヘッドが大きくなる場合があります。 もしK8sを導入したいと思う方がいらっしゃいましたら、上記のメリットやデメリットを考慮しておくと良いと思います。 ArgoCDを使ってもっと便利にしたい ArgoCDとは？ ArgoCD とは、GitOpsの原則に基づいたCD（継続的デリバリー）ツールです。Gitリポジトリで管理されたアプリケーションの設定を自動的にK8sクラスタに適用し、デプロイ作業を効率化します。 ArgoCDはArgoProjectというOSSコミュニティによって開発されているツールで、K8sとの親和性が特に高く、K8s内部を可視化してくれるダッシュボードがとても優れています。 ArgoCDのダッシュボード Gitリポジトリを更新したら自動で変更がデプロイされるところが特に便利ですし、ダッシュボードでは権限を持っているユーザーがpodを再起動させたり、kubectlを使わずとも内部構成が見れたりするので、K8sに詳しくないメンバーとの連携もサポートしてくれるツールだなと感じました。 まとめると... ダッシュボードが使いやすい 自動デプロイが便利 K8s知らない人にもわかりやすい です！ Argo Rolloutsで Blue/Greenデプロイしたい Argo Rolloutsとは？ Argo Rollouts とは、Blue/Greenデプロイ、カナリアデプロイなど高度なデプロイ戦略をK8s上で実現するためのツールです。デプロイ中のダウンタイムを最小限に抑えつつ、安全にアプリケーションをリリースできるようにしてくれます。 Argo RolloutsもArgoProjectで管理されているOSSで、同じくダッシュボードが提供されます。 こちらの 公式ドキュメント を参照してテストを行い、values.yamlファイルをカスタマイズしてデプロイしました。 専用のダッシュボードはデフォルトでは有効化されてないので、 Helm チャート で有効化しましょう。 Blue/Green デプロイの導入 今回のK8s移行プロジェクトでは、レバレジーズ社製サービスである teratail（テラテイル） のFrontEndアプリに Blue/Greenデプロイ を導入しました。 自動でデプロイされた本番同様のプレビュー環境で開発者がUIなどを確認し、確認が終わったらArgo Rolloutsのダッシュボードで昇格（プロモート）できるようにしました！ 下記のような流れで、安全な本番環境リリース作業を実現させました。 開発者がGithubリポジトリを更新する ArgoCDがGithubの更新を検知し、自動でプレビュー環境をデプロイ 開発者がプレビュー環境を確認する 問題なければ昇格（プロモート）！問題があったらリリース作業を中断！ 昇格（プロモート）後はプレビュー環境が自動削除される Blue/Green デプロイの注意点 ALBを残さない！ 今回導入したプレビュー環境は独自のDNSやALBを持つようにしました。 プレビュー環境での確認が終わると、ArgoRolloutsが自動的にプレビュー環境のpodを削除してくれます。ですが、ALBは削除してくれないので、小さいながらALB分の稼働コストが無駄になってしまいます！ これはいけない。そこで今回はAnalysisTemplateを使ってALBも自動で削除するように設定しました。 AnalysisTemplate はArgoRolloutsのロールアウトが完了した時点でトリガーされるタスクです。 今回はプレビュー環境のALBと紐づいてるingressを自動で削除することで、プレビュー環境が不要な時に無駄なALBのコストが発生しないようにしました。 AnalysisTemplateはK8sのJobと同じく、クラスター内での権限を設定してあげる必要があります。 ServiceAccountを作成し、適切なロールと権限を付与してあげましょう。 ※下記コンポーネントたちは同じNamespaceに属する必要があります。 apiVersion : argoproj.io/v1alpha1 kind : AnalysisTemplate metadata : name : <your_custom_name> namespace : <namespace> spec : metrics : - name : <job_name> provider : job : spec : ttlSecondsAfterFinished : 30 template : spec : serviceAccountName : analysistemplate containers : - name : <your_container_name> image : bitnami/kubectl:latest command : [ "sh" , "-c" , "kubectl -n <namespace> delete ingress <your_ingress_name>" ] restartPolicy : OnFailure — apiVersion : v1 kind : ServiceAccount metadata : name : analysistemplate namespace : <namespace> — apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata : name : ingress-deleter namespace : <namespace> rules : - apiGroups : [ "networking.k8s.io" ] resources : [ "ingresses" ] verbs : - get - list - delete — apiVersion : rbac.authorization.k8s.io/v1 kind : RoleBinding metadata : name : ingress-deleter-binding namespace : <namespace> subjects : - kind : ServiceAccount name : analysistemplate namespace : <namespace> roleRef : kind : Role name : ingress-deleter apiGroup : rbac.authorization.k8s.io Blue/Greenデプロイのやり方は色々あると思いますが、やっぱり無駄なコストを削るというのが重要なポイントだと思います。 運用効率化とコスト削減の二兎をうまく捕まえられるかどうかが鍵となります！ Prometheus + Grafana + ElasticSearchでもっと可視化したい Prometheus / Grafana / ElasticSearch K8sの監視ツールと言えばやっぱり Prometheus+Grafana を思い浮かべる方が多いんじゃないでしょうか。また、ログ収集と検索では ElasticSearch も外せないですよね。K8sにおいてこれらのツールは定番で、OSSなので別途の費用負担なく導入できるのが最大のメリットです。 まずは各ツールについて簡単に説明させていただきます。 Prometheus ：コンテナのメトリクス収集・監視ツール Grafana：Prometheus、ElasticSearch等で収集したデータを可視化するためのダッシュボードツール ElasticSearch：ログ収集・検索用データベース これらのツールは突き詰めると奥が深いので詳しい説明はまた今度の機会とさせてください！ ここはまず導入時の試行錯誤をいくつかご紹介いたします。 アラートをカスタマイズしたい！ 監視ツールを使う上で可視化と同じように重要なのが適切な アラート を飛ばすことだと思うんですよね。今回私たちが導入した Prometheus + Grafanaは kube-prometheus-stack という Helmチャート を使っており、PrometheusとGrafanaをセットでデプロイしてくれる便利なチャートです。 このチャートではデフォルトで設定されているPrometheusの アラートルール があり、チャート上で使いたいルールを選択して適用しました。 他には Prometheus Blackbox Exporter を使用してサイトの死活監視を設定しました。 Blackbox Exporterはまた 別のHelmチャート でデプロイしてあげる必要があります。 kube-prometheus-stack Helmチャートでの設定値は以下の通りです。 prometheus : prometheusSpec : additionalScrapeConfigs : - job_name : 'external-targets' metrics_path : /probe params : module : [ http_2xx ] static_configs : - targets : - <TARGET_URL> relabel_configs : - source_labels : [ __address__ ] target_label : __param_target - source_labels : [ __param_target ] target_label : instance - target_label : __address__ replacement : prometheus-blackbox-exporter.monitoring.svc.cluster.local:9115 retention : 30d additionalPrometheusRulesMap : - name : external-monitoring-alerts groups : - name : external-targets-alerts rules : - alert : ExternalTargetWarning expr : probe_success == 0 for : 30s labels : severity : warning annotations : summary : "External target {{ $labels.instance }} might be down" description : "The external target {{ $labels.instance }} has intermittent issues." - alert : ExternalTargetCritical expr : probe_success == 0 for : 5m labels : severity : critical annotations : summary : "External target {{ $labels.instance }} is down" description : "The external target {{ $labels.instance }} is unreachable for 5 minutes." 他にもGrafanaのコンソール上でアラートを設定したり、 additionalPrometheusRulesMap 配下で追加のPrometheusのルールを追加することもできます！ ログをS3にも格納したい ElasticSearch は単体ではログを収集できないので、必ずログを集めてきてくれるパートナーが必要です。 そこでまず最初に検討したパートナーがElasticSearchと同じくElastic社が開発した「Filebeat」です。Filebeatはとても軽量なログ収集ツールで、ECK-Stackという Helmチャート にも含まれていてElasticSearchとの親和性も高くて良さげに見えました。 しかし、私たちが使っているのはOSS版。OSS版のFilebeat単体ではS3にログをアウトプットする機能がなく、同じくElastic社のLogStashが必須でしたがLogStashはリソース消費量の多いアプリなのでどうしたものか... そこで採用したのが「 Fluentbit 」です。FluentbitはFilebeatと同じく軽量でありながらOSSコミュニティの開発も活発で、単体でS3へのアウトプット機能も備えていて最適なツールでした。Fluentbitは別途の Helmチャート を使ってデプロイし、アウトプットの設定はこのようにしました。 outputs : | [ OUTPUT ] Name s3 Match kube.* region ap-northeast-1 bucket <YOUR_BUCKET_NAME> storage_class STANDARD total_file_size 100M このようにOSSツールをフル活用してマイクロサービスやクラスターの監視体系を構築しました！ K8s内にホスティングさせている分リソースは食いますが、OSSなのでランニングコストが無料なのが最大のメリットです！ カスタマイズもし放題ですしね。 アプリケーションを乗せよう 使用した技術スタック さて、ある程度ツールの話を進めたところで今回のプロジェクトで使用した技術スタックをまとめてみたいと思います。 今回のK8s移行では、以下の技術スタックを使用しました。 K8s (EKS) : - version : v1.31 APP : - TypeScript CI/CD : - ArgoCD v2.13.0 - Argo Rollouts v1.7.2 - Github Actions 監視 : - Prometheus v0.81.0 - Prometheus-blackbox-exporter v0.25.0 - Grafana v11.6.0 - ElasticSearch v9.0.0 - Kibana v9.0.0 - Fluentbit v3.2.0 - CloudWatch DB : - MySQL v8.x - PostgreSQL v16.x ネットワーク : - gRPC - Envoy Dify, Airflowを乗せる K8s導入プロジェクトの最初の一歩として、OSSアプリケーションをK8s上に乗せました。 誰でも簡単にコンソール上でAI/LLMアプリが作れる「 Dify 」と、ワークフロー自動化ツールである「 Apache Airflow 」です。 Dify / Airflow こちらのHelm Chart( Dify , Airflow )を用いてデプロイし、テスト段階ではコスト削減のためEKS内部でPostgreSQL DBを作ってテストし、本番運用開始後はAurora RDS PostgreSQLに移行させました。 後述しますが、Airflowを運用するEKSクラスターではコスト削減のためにSpotインスタンスを導入しています！ レバレジーズのサービスを移行させる ここまでは主にOSSツールのデプロイについて話してきましたが、この章では自社製アプリケーションのデプロイについて説明します！ 今回はレバレジーズ社製サービスである「 teratail（テラテイル） 」をECS on FargateからEKS on EC2に移行させました！ teratailとは？ 「 teratail（テラテイル） 」は、2014年7月にオープンしたエンジニアの問題解決プラットフォームです。学生やプログラミング初心者から第一線で活躍する方々まで、幅広いエンジニアの問題解決をサポートするサービスです。 コスト削減と可用性 主な目標は「コスト削減」と「可用性の向上」でした。 K8sクラスター本体の維持コストが月$75ほどかかってしまうのはありますが、EC2のリソースを共有しながら有効活用できる＋ALBの数を減らせたので結果的には約１割ほどのコストダウンに成功しました。 また、可用性向上のため 水平Pod自動スケーリング（HPA） や Cluster Autoscaler を導入しています。可用性を測るための負荷試験では k6 というツールを利用しました。 そろそろみなさんもだいぶK8sの良さがわかって来たんじゃないでしょうか！ 次の章では私がK8sの構築中に踏んだいくつかの罠の事例をご紹介いたします。 K8sで注意したいこと gRPCの罠 gRPC は、Google社が開発した高性能なオープンソースのRemote Procedure Call（RPC）フレームワークです。 HTTP/2を通信プロトコルとして使用しているのが大きな特徴であり、K8sのクラスター内部通信は基本的にHTTP/1.1であるため、K8sでgRPCを使うには専用の設定をいろいろしてあげないといけませんでした。 コンテナのgRPCヘルスチェック gRPCを使っているマイクロサービスならコンテナのヘルスチェックもgRPCでやりたいですよね？ そんなあなたにピッタリなのが gRPC probe（プローブ）です。 K8sにはコンテナを監視する様々な種類のprobeがあり、それぞれのprobeは決められた通信方法でコンテナを監視します。 K8s v1.27からはこのprobeの通信方法にgRPCが追加され、特別なプラグインとかがなくてもK8sの機能でgRPCヘルスチェックを使うことができます。 ※用意するもの ヘルスチェック用のgRPCサービス gRPC probe 👇K8sでの設定ではgrpc.service名を指定してあげるのがポイントです（livenessでもreadinessでも可） livenessProbe : grpc : port : 50051 service : "Health" 負荷分散しない問題 gRPCを使う場合、負荷が高くなってpodの数が増えても一般的な K8s Serviceオブジェクトでは適切に増えたpodに負荷分散されない問題があります。詳しい説明は割愛させていただきますが、これはgRPCがコネクションを使い回す性質が原因であり、Serviceの裏にあるpodが増えても既存のpodのIPを使い回しているのです。 ここで登場するのが「 Headless Service 」で、簡単に説明するとHeadless Serviceは裏のpodの仮想IPを返すのではなく、DNSで名前解決しているような挙動をすることでgRPCが特定のIPと紐づかなくなります。 まだこれで終わりではありません、K8s内でgRPCを適切に扱うにはさらに「 Envoy 」コンテナが必要になります。 Envoyを活用しよう Envoy は主にプロキシとして使われることが多いサービスですが、今回はHTTP/1.1をHTTP/2に変換する用途で使用します。 本来の構成ではBFFサービスが各バックエンドサービスへの振り分けを行っていましたが、バックエンドとBFFの間にEnvoyコンテナを下の図のように入れる形にしています。 こうすることで追加するEnvoyコンテナは最低限にしつつ、gRPC通信をK8s上で適切に使うことができました。 Envoyコンテナの数が増えるとその分リソースも使いますしね。 メモリーリークをなんとかしたい 今回K8sに移行したteratailサービスには、フロントエンドコンテナでメモリリークが起きるというバグがありました。 K8sではコンテナごとにリソースの上限を割り当てていて、上限に達すると強制的にOOMによるKillが発生し、podが再起動されます。しかし、自動的に再起動されるとはいえOOMが発生してしまうとわずかながらフロントエンドにアクセスできなくなる時間が出てしまいます。 これをK8sのレイヤーで解決するために、OOMが起きる前に定期的にフロントエンドサービスを再起動させる仕組みを導入しました。 CronJobを活用しよう CronJob は時間を決めて自動で指定したタスクを実行するK8sのオブジェクトです。 今回はOOMが発生するのがおおよそ4時間ごとだったため、このCronJobでは3時間ごとにフロントエンドサービスをダウンタイムなしで再起動させるようにしました。 CronJob内で実行したいコマンドは事前に用意しましょう。 今回はArgo-Rollouts用の「rollout」というオブジェクトを再起動させるため、kubectlとArgo-Rolloutsのプラグインをインストールし、再起動コマンドを実行させています。 apiVersion : batch/v1 kind : CronJob metadata : name : front-auto-restart namespace : <NAMESPACE> spec : successfulJobsHistoryLimit : 1 schedule : 10 */3 * * * jobTemplate : spec : ttlSecondsAfterFinished : 3600 template : spec : serviceAccountName : front restartPolicy : OnFailure containers : - name : alpine image : public.ecr.aws/docker/library/alpine:3.21.3 imagePullPolicy : IfNotPresent command : - /bin/sh - "-c" args : - set -e; echo "Installing dependencies..." ; apk add --no-cache curl bash; echo "Download, Installing kubectl..." ; curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" ; chmod +x kubectl; mv kubectl /usr/local/bin/; echo "Download, Installing kubectl argo-rollouts plugin..." ; curl -LO "https://github.com/argoproj/argo-rollouts/releases/download/v1.8.0/kubectl-argo-rollouts-linux-amd64" ; chmod +x kubectl-argo-rollouts-linux-amd64; mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts; echo "Restarting rollout..." ; kubectl argo rollouts restart front-rollout -n <NAMESPACE>; echo "Restart complete" 次はこのCronJobに必要な権限とServiceAccountを用意すればOKです。 apiVersion : v1 kind : ServiceAccount metadata : name : front namespace : <NAMESPACE> automountServiceAccountToken : true --- apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata : name : front-auto-restart-role namespace : <NAMESPACE> rules : - apiGroups : [ "argoproj.io" ] resources : [ "rollouts" ] verbs : [ "get" , "list" , "patch" , "update" ] - apiGroups : [ "" ] resources : [ "pods" ] verbs : [ "get" , "list" ] --- apiVersion : rbac.authorization.k8s.io/v1 kind : RoleBinding metadata : name : front-auto-restart-rolebinding namespace : <NAMESPACE> subjects : - kind : ServiceAccount name : front namespace : <NAMESPACE> roleRef : kind : Role name : front-auto-restart-role apiGroup : rbac.authorization.k8s.io これらはほんの一例に過ぎないものたちでしたが、結構頻繁に遭遇する罠だと思いますので気をつけたいですね。 コスト削減したい Spotインスタンスを活用しよう EKS on EC2ではノードグループを複数に分けることで、一部だけEC2 Spotインスタンスを使うことができます。 Spotインスタンス は格安な代わりに突然使えなくなることがあるようなEC2です。そのため、Spotインスタンスでは「いつ突然再起動されても大丈夫なもの」だけ乗せたいですね。 具体的には定期実行のジョブやバッチなどです。 今回の移行においてこのSpotインスタンスの活用にピッタリなものがApache Airflowでした。Airflowでは定期的に実行されるワークフローを組めるサービスですが、このワークフローを実行するpodだけをSpotインスタンスに乗せたいということです。この方法は AWSの公式ドキュメント でも推奨されており、このドキュメントに沿って設定を行ったら簡単にできました。 Apache Airflowの公式Helmチャートを使う場合は以下のような設定が必要です。 workers : # EC2 Spot Instanceを使うための設定 tolerations : - key : "spotInstance" operator : "Equal" value : "true" effect : "PreferNoSchedule" affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : "lifecycle" operator : "In" values : - "Ec2Spot" Savings PlanとRIを活用しよう EKS on EC2を使う最大のメリットと言っても過言ではないのがAWSの Savings Plan と Reserved Instance の恩恵を受けられることだと思います。 もし使う予定のEC2のスペックやファミリーが1年以上変わらないのであれば、RI全額前払い購入が断然お得です。 私たちはこれからも新規サービスを開発してどんどんK8s上に乗せる予定があったため、EC2のスペックやファミリーの指定がない Compute Savings Planで購入しました。 これだけでも約50%ほどのAWSコストを削減できます！ 今後の計画 プラットフォーム化 レバレジーズテクノロジー戦略室では事業にとらわれず全社横断のプロジェクトを推進しています。将来的には社内で統一された K8sのプラットフォーム を構築し、社内で簡単に使えるプラットフォームとして提供できることが目標です。 現在はAWSを主軸としていますが、ゆくゆくは マルチクラウド化 することも視野に入れています。 監視の集約 プラットフォーム化が進められれば、コンテナを監視するツールであるPrometheus+Grafanaや、ログ収集のElasticSearchなどのツールを１つのクラスターに集約し、全社の各クラスターを監視する監視基盤を構築することも計画しています。 また、今回はまだ導入できていませんが、 OpenTelemetry も導入を検討しています。 終わりに K8s移行プロジェクトは最初の敷居こそ高いものの、移行後のアプリケーションの運用や実装はとてもスピーディーになるんですよね。新しいアプリケーションを乗せたい時も、コンテナさえあればデプロイとテストが非常にスムーズに行えます。 これでみなさんもK8sに移行してみたくなったんじゃないでしょうか！？ 長い文章にお付き合いいただきありがとうございました。 弊社にご興味のある方へ レバレジーズでは、一緒に働く仲間を募集しています！ 少しでも興味を持っていただけたら、ぜひカジュアル面談にご応募ください！ hrmos.co

はじめに こんにちは。 新卒でレバレジーズにエンジニアとして入社し、HRTech系SaaS NALYSYSで開発をしている、矢野と申します。 最近、流行ってきている AI議事録ツールを、企画立案から設計、開発、リリース、社内展開まで約4ヶ月で完了 させました。 右も左もわからない新卒エンジニアが、色んな苦難や葛藤と戦いながら、爆速で企画立案から社内展開まで成功させた軌跡をお伝えします。 この記事に書かれていること 新卒エンジニアが1人でプロダクトの企画から社内営業までを一気通貫でやり遂げた奮闘記 オールインハウスの現場で、新卒エンジニアが多種多様な職種の人と関わり成長していく過程 はじめに この記事に書かれていること この記事を読むとわかること 新人賞を取りたい！ ことの発端 周りの目 高すぎるハードル 心強い仲間の登場 まずはNo.1取るための計画だな 初めての経験で大きな壁にぶち当たる AI議事録ツール Yanoniの誕生 爆速での設計・実装 複数回のリリースで全社員が使用できるツールへ 初めての営業 AI議事録ツール Yanoniの開発を終えて 私の職種って何？ 新人賞は受賞できたのか 総括と今後 普通の新卒ではできない経験をたくさんした 新規プロダクトのPdM兼開発者を任された 最後まで読んでくれた方へ この記事を読むとわかること 弊社の新卒エンジニアはこんなことやってる 新卒エンジニアが新規プロダクトのリーダーに任命されるまでの軌跡 とりあえず1年目はがむしゃらに仕事してNo.1目指すべきだと思います 新人賞を取りたい！ ことの発端 私の入社直後、1年目のエンジニアの先輩が全社総会で新人賞に輝きました。 半年間で、 新卒採用管理システムのフロントエンドでは58画面/62画面を実装、バックエンドでは68本/94本のAPIを実装し（2024/3/5時点）、特許も出願するという半端ない成果 を出していました。 私も先輩を超える成果を出し、あの舞台に立ちたいと考えるようになりました。 周りの目 そう考えてからすぐに行動できたわけではありません。 「新人賞を取りたい！」と言ったら周りは何を思うのだろうか、行動に移しても新人賞を取れなかったらどうしよう、とかそんなことが頭の中をうごめいていたからです。 しかし、エゴグラムでいう拡散が極めて高い私は、そんな考えより、「楽しそう！とりあえずやってみるか！」という気持ちの方が強く、気づいたらシステム本部長にDMを送っていました。 高すぎるハードル 何はともあれ、賞レースは比較なので、過去にどんな成果をあげて新人賞に選出されているのか調査しようと考えました。 社外秘のため調査結果は記載できませんが、 新卒が1年間で成し遂げられるレベルをはるかに超えた成果 でした。 言い訳かもしれませんが、特にエンジニアはすぐに成果が出る職種ではありません。 さらに、エンジニア研修と並行してそれらに匹敵する成果を出さなければなりません。 そのため、成果がすぐに出しやすい営業に比べてかなり厳しい戦いになることは覚悟しました。 心強い仲間の登場 営業やエンジニア、PdM等幅広い経験をお持ちということで他職種と戦う賞レースにおいて、的確なアドバイスが期待できると、システム本部長がHRテック事業部長を紹介してくださいました。 ということで、仲間というと語弊がありますが、事業部長が伴走してくださることになりました。 HRテック事業部長の初めの印象は、「筋肉マンすぎて怖い」 でした。 しかし、話していくうちにユーモアがあり、真剣に私に向き合ってくれていると感じるようになりました。 まずはNo.1取るための計画だな 過去の受賞者の成果や、全社投票や各事業部の部長陣の会議によって受賞者が決定することから下記の要素を満たすような成果を出す必要があると考えました。 事業部内や新卒内で1位をとっている 全社の年間テーマ（次代を、創る。土台を、創る。）に沿った成果を出している 全社に影響を与える成果である そして、私は売上をあげるより、工数削減の方で成果をあげようと考えました。 過去の受賞者の具体的な利益を算出し、それを上回る工数削減ができれば、成果がでていると判断できるのではないかと考えました。 そのため、 全社員が使うシステムを開発し、営業の利益を上回る工数削減を達成することを目標 にしました。 さらに「次代を、創る。」ために、最近流行りのAIを取り入れることも考えました。 後は、 企画して、設計して、開発して、社内営業して、全社展開すれば私の勝ちだと、これが私の計画 です。 しかし、ここからが苦難の始まりなのです。 初めての経験で大きな壁にぶち当たる 何を作るか決めることから始めました。 しかし、私がプロダクトを0→1で生み出した経験は0です。 とりあえず、会社に落ちている課題を知るために、本部長にヒアリングに行きました。 人事評価ツールが使いにくい オフィスシュミレーションが欲しい 全社総会をオンラインでみる時にネットワークが遅い 他にも多くの課題が出てきました。 しかし、どれも自身がワクワクするような施策ではありませんでした。 それからというもの、部長陣やリーダー等、職種問わず壁打ちをするもアイデアは何も浮かばずに時間だけが過ぎていきました。 時間も半年しかないのに、こんな初めの段階で足踏みをしている自分に苛立つことも多々ありました。 AI議事録ツール Yanoniの誕生 伴走してくれている方とは、1週間に1度30分程度話していました。 そこで、「まずは目の前の人の課題を解決するのが良いんじゃないかな」と助言をいただき、さらに弊社は営業職が多いので、インパクトを出せる営業の方に絞ってヒアリングを続けました。 まずは、リーダーから新卒問わず、事業部も様々で偏りのない標本をとり、業務フローを洗い出しました。 その中で、商談や面談、面接、議事録の作成、お礼メールの作成に最も時間がかかっていることに気づきました。 さらに、この業務はどの事業部においても発生している工数なので、インパクトも大きいと考えました。 面談や面接の内容をAIやシステムの力で議事録、お礼メールを自動生成するプロダクトを作ること にしました。 ここでやっとAI議事録ツールの開発が決定しました。 残り4ヶ月。。。 爆速での設計・実装 特に設計で考えたのは、どの音声認識APIを使用すれば、高精度の文字起こしが可能かということです。 そのため、 高精度と言われているAPI10個を全て試して、最も高精度の音声認識APIを選定 しました。 そのおかげで、他社のサービスよりも精度が良いと言われることが多々あります。 設計は3週間で終えました。 こんなに爆速で設計できたのも多くの人に助けてもらいました。 システム本部の様々なチームに直接FBをもらいに行って、設計をしました。 実装に関しては、最初から要求を全て満たそうとすると、ユーザーに価値を届けるのが遅れるため、まずは、自身が所属する事業部が使える仕様にして実装しました。 今考えれば、 フロントエンドもバックエンドも無茶苦茶なコードを書いていました。反省です。 1.5ヶ月で1回目のリリースを果たしました。 複数回のリリースで全社員が使用できるツールへ 初回リリースは完了しましたが、問題だらけです。 まずは他事業部でも使用できる仕様に変更しました。 UI/UXにおいても使いにくいという声が多く寄せられたため、早急に対応しました。 2回目、3回目とリリースを重ね、ついに全社員が使用できるAI議事録ツールへと成長しました。 プロダクトが完成したからロゴが欲しいよねということでこの記事のトップにある画像をロゴにしました。 自分の顔です。 プロダクト名も「Yanoni」にしました。 由来は下記です。 開発者の名前 You’re Absolutely Not Overlooking Necessary Insightsの頭文字（必要な情報を見逃すことは絶対にない） 自分のプロダクトなので、自分でロゴ作ってプロダクト名まで決められるのは良いですね。 多くの人から自己主張が強過ぎると言われました。 普通のプロダクトじゃ面白くないですよね。 これが自分らしさ全開のプロダクトです。 初めての営業 伴走してくださっている方の繋がりで 他事業部のリーダーや部長と商談できる機会 をいただきました。 とりあえず、アジェンダとYanoniを使用している動画を用意して商談に挑みました。 初めての商談は全然ダメでした。 クロージングがうまくいかず、中途半端な感じで終了しました。 しかし、機能自体は気に入ってくださったみたいで導入が決定しました。 その後は、経営企画の方と戦略を練って、営業資料作成したり、使い方ドキュメントを整備したり、ユーザーがお問い合わせできる場所を作ったり、できる限りのことは行って商談を進めていきました。 商談を重ねるごとに、質疑応答やクロージングもスムーズになりました。 結果、様々な事業部でYanoniが使われることになりました。 AI議事録ツール Yanoniの開発を終えて 私の職種って何？ 企画、開発、営業、カスタマーサクセス全てを経験 しました。 「あれ？自分の職種って何なんだろう？」と思いましたが、私にとってはそんなことどうでも良いです。 開発したサービスでより多くの人に価値を届けられるのであれば、何でもやるべきで、職種を跨いで行動するべきだと思っているからです。 新人賞は受賞できたのか 結論、受賞できませんでした。 とても悔しかったですが、めちゃくちゃ凹んだわけではありません。 その理由は、多くの人に「助かった」「ありがとう」といった感謝の気持ちをいただいたからです。 自身が生み出したサービスで多くの人に影響を及ぼし、感謝やフィードバックをいただけて本当に幸せ でした。 総括と今後 普通の新卒ではできない経験をたくさんした 新卒で入社したエンジニアに1人で企画から開発、営業まで経験させてくれる会社ってあるんですかね。 プロダクトを企画する経験、0→1で開発する経験、商談をする経験、ユーザーから直接きたフィードバックを自身で改修する経験、全て1年目で経験しました。 新規プロダクトのPdM兼開発者を任された 今は、HRTech系SaaS NALYSYSで人事評価管理システムのPdM兼開発者としてリーダーっぽい動きをしています。 こんな重大なポジションを任せてもらったのも、周りを適切に巻き込んで自身が企画したサービスを最後までやりきったからだと思っています。 次は 人事評価管理システムを爆速リリースして、営業して、さらに多くの人に価値を届けたい です。 最後まで読んでくれた方へ 新卒エンジニアとは思えない、多くの経験をしました。 エンジニアだけど、エンジニアリングのみならず、ビジネスサイドにも興味があると思っている方も多いと思います。 もしかしたら弊社であればそれを叶えられるかもしれません。 ご興味を持っていただけた方がいらっしゃいましたら是非 こちら からご応募してみてください。