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兼開発者としてリーダーっぽい動きをしています。 こんな重大なポジションを任せてもらったのも、周りを適切に巻き込んで自身が企画したサービスを最後までやりきったからだと思っています。 次は 人事評価管理システムを爆速リリースして、営業して、さらに多くの人に価値を届けたい です。 最後まで読んでくれた方へ 新卒エンジニアとは思えない、多くの経験をしました。 エンジニアだけど、エンジニアリングのみならず、ビジネスサイドにも興味があると思っている方も多いと思います。 もしかしたら弊社であればそれを叶えられるかもしれません。 ご興味を持っていただけた方がいらっしゃいましたら是非 こちら からご応募してみてください。

24年12月 25年1,2,3月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベント開催、イベント登壇など多様な関わり方で、合計19件のイベントに参加しました！ 主催・共催技術イベント ～Tech-Front Meetup～ 一歩先のフロントエンドへ 12/12に、渋谷スクランブルスクエアにある弊社の本社にて、「一歩先のフロントエンド」がテーマのLTイベントを開催しました。 （イベント詳細は こちら から） 障害対応の属人化から脱却。全員を巻き込む仕組みづくりの方法 12/17に、渋谷スクランブルスクエアにある弊社の本社にて、「インシデント対応」がテーマのLTイベントを開催しました。 （イベント詳細は こちら から） オフライン開催！「3年目」PMに送る、コミュニケーションのお悩みを解決する処方箋 1/16に、渋谷スクランブルスクエアにある弊社の本社にて、「コミュニケーションのお悩み」をテーマにディスカッションイベントを開催しました。 （イベント詳細は こちら から） RustのLT会#3 初心者〜中級者まで大歓迎！ @渋谷 1/22に、開発組織の拠点である弊社のポーラ渋谷ビルにて、Rustのオフライン勉強会を開催しました。 （イベント詳細は こちら から） 技術カンファレンスのCFPに応募しよう勉強会 2/26に、開発組織の拠点である弊社のポーラ渋谷ビルにて、CFP（call for proposal）に実際に応募しようという勉強会を開催しました。 （イベント詳細は こちら から） RustのLT会#4 初心者〜中級者まで大歓迎！ @渋谷 2/27に、渋谷スクランブルスクエアにある弊社の本社にて、Rustのオフライン勉強会を開催しました。 （イベント詳細は こちら から） エキスパート2人に聞く、春のGoお悩み相談会 3/5に、オンライン上で、「社内でGoの活用を推進したい」という課題を抱えているエンジニア向けに、最適な書籍を厳選して紹介し、Go学習の第一歩をスムーズに踏み出すための 相談会を開催しました。 （イベント詳細は こちら から） 【VPoE Meetup Vol.3】VPoEになってまず何をする？VPoEへのキャリアパスと役割 3/17に、開発組織の拠点である弊社のポーラ渋谷ビルにて、VPoE（Vice President of Engineering）経験者たちが一堂に会し、これまでの経験や実践的なノウハウを共有し、参加者の皆様と有意義な交流を図るイベントを開催しました。 （イベント詳細は こちら から） 必ず生まれる負債にどう向き合うか。ログラス・カミナシCTOに聞く、技術的負債をコントロールする方法 3/19に、渋谷スクランブルスクエアにある弊社の本社にて、株式会社ログラスCTOの伊藤博志氏と株式会社カミナシCTOの原トリ氏をゲストにお迎えし、技術的負債への向き合い方について、両社の実践を教えていただくイベントを開催しました。 （イベント詳細は こちら から） RustのLT会#5 初心者〜中級者まで大歓迎！ @渋谷 3/25に、開発組織の拠点である弊社のポーラ渋谷ビルにて、Rustのオフライン勉強会を開催しました。 （イベント詳細は こちら から） イベント登壇 Nihonbashi Test Talk #3 LT開発部の内藤が、Nihonbashi Test Talkに登壇しました。 (イベント詳細は こちら から) speakerdeck.com Security.any #02 セキュリティあの頃はLT LT開発部の松浪が、Nihonbashi Test Talkに登壇しました。 (イベント詳細は こちら から) speakerdeck.com 次世代DB戦略を支えるNewSQL 〜導入企業が語る導入背景と今後の展望〜 LT開発部の金澤が、次世代DB戦略を支えるNewSQL 〜導入企業が語る導入背景と今後の展望〜に登壇しました。 (イベント詳細は こちら から) speakerdeck.com shibuya.ts LT開発部の松浦が、shibuya.tsに登壇しました。 (イベント詳細は こちら から) speakerdeck.com イベントスポンサー SRE NEXT 2024 シルバースポンサー 12/5に行われたpmconf 2024にて、レバテック株式会社がシルバースポンサーとして協賛しました。 アジャイル経営カンファレンス プラチナスポンサー 1/25に行なわれたアジャイル経営カンファレンスにて、レバレジーズ株式会社よりAgile Effect事業部がプラチナスポンサーとして協賛しました。 SRE Kaigi 2025 プラチナスポンサー 1/25に行われたSRE Kaigi 2025にて、レバテック株式会社がプラチナスポンサーとして協賛しました。 会場スポンサー TSKaigi2025 第2回全体MTG “TSKaigi2025 第2回全体MTG”に、会場の提供をしました。 （イベント詳細は こちら から） アニメから得た学びを発表会 “アニメから得た学びを発表会”に、会場の提供をしました。 （イベント詳細は こちら から） We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、 こちらのページ からご応募ください。

はじめに こんにちは！レバレジーズ株式会社テクノロジー戦略室SREチームの竹村です。 テクノロジー戦略室のSREチームでは、全社のエンジニアの開発生産性の向上やシステムの信頼性向上に取り組んでいます。 エンジニアの生産性向上や工数削減を叶えるため、2024年にレバレジーズの開発組織全体で、GitHub Enterprise Cloud（GHEC） への移行を行いました。 今回は、複数の施策を積み上げることで、コスト増を上回るメリットを示し、導入に至った経緯を赤裸々に皆さんにお届けできればと思います！GHEC以外のサービス導入検討の参考にもなると思うので、何か新しいサービスやプランアップを検討されているかたもご一読いただけると幸いです。 苦労したポイント！ GHEC への移行・導入にあたっての一番苦労したポイントはやはり、大幅なコスト増をまわりに理解してもらうことでした。多くの高度な機能が利用可能になる点は魅力的でしたが、コストが約5倍に増加するため、コストに見合う価値があるかを理解してもらう必要がありました。 当初注目していたいくつかの機能だけでは費用対効果を説明できず、GHECで利用可能な機能を網羅的に調査し、それぞれがもたらす具体的なメリットと効果を洗い出すことにしました。結果的に20項目以上のメリットを特定し、可能な範囲で効果を試算・積み上げることで、総合的に費用対効果がプラスになることを示し、導入することができました。下記より詳細に記していきます！ GitHub Enterprise Cloud（GHEC）の紹介 そもそもGitHub Enterprise Cloud（GHEC）とは GitHub Enterprise Cloud（GHEC） は、GitHubが提供するエンタープライズ向けのクラウドベースのサービスで、企業や大規模なチームがソフトウェア開発を効率的かつ安全に行うための高度な機能を備えています。 プランによる大まかな機能違いについては、 GitHubプラン紹介ページ で確認できます。 導入背景 レバレジーズの事業運営とコスト意識 レバレジーズでは多くの事業を展開しており、事業部ごとに独立してP/L（損益計算書）を管理し、運営しています。そのため、各事業部やチームでは、日々のコストに対して比較的高い意識を持つことが多く、ツール導入や運用コストについても慎重に検討する傾向があります。GitHub の利用プランがこれまで Free プランや Team プラン混在だったのも、こうした背景のひとつでした。 GitHub利用の経緯と課題 背景 レバレジーズでは、もともと事業部やチームごとに GitHub の Organization を作って利用しており、Free プランや Team プランが混在していました。これは先ほどのコストに対する考え方もあり、コストを考慮しながら必要な機能に応じてプランを選んでいた、という経緯があります。 しかし、会社全体の成長や開発の規模が大きくなるにつれて、セキュリティルールの統一、ライセンス管理の効率化、そしてチーム同士がもっと連携しやすくする必要性などを感じるようになりました。そこで、会社全体での開発ツール基盤を見直すために、GHEC の導入を検討し、進めていくことになりました。 課題（実質的なコストとなっていた点） 非効率な協業・隠れた運用コスト・煩雑なアカウント管理・セキュリティリスク・ガバナンスの欠如 などの課題があり、単なる不便さに留まらず「 実質的な工数、機会損失、セキュリティリスク 」といった形で、無視できないコストとなっていました。GHEC へ移行し、運用体制を整備することで、これらの「見えにくいコスト」を解消できる可能性が高いと判断しました。 各課題とその詳細は下記の通りです！ 非効率な協業 他チームに参画する際、Organization が異なることによる権限管理やライセンス費用発生の問題で、スムーズな支援や共同作業に入れないことがありました。（機会損失コスト） 隠れた運用コスト コストを抑えるために Free プランを利用しているチームでは、本来 Team プラン以上で容易に実現できる管理・セキュリティ機能を、不足分を補うために自前でツールを作成・運用するなど、見えにくい人件費や工数が発生していました。（管理・開発工数コスト） 煩雑なアカウント管理 開発メンバーの人数の増減が毎月発生する中で、手動でのアカウント棚卸しや権限付与・削除に管理者の工数が割かれがちでした。（管理工数コスト） セキュリティリスク 手動管理に依存していたため、GitHub アカウントの削除漏れなどが発生するリスクを抱えていました。（インシデントリスクコスト） ガバナンスの欠如 各 Organization が個別のポリシーで運用されていたため、全社的な GitHub 利用のガバナンスを効かせることが難しく、標準化が進まない、統制が取れない状態でした。（非効率・統制コスト） 導入に至るまでのプロセス レバレジーズでは、当時40近くの Organization が存在し、それぞれ別々のポリシーで運用されていました。GHEC 移行は、単なるツール変更ではなく、これらの運用プロセスの標準化や変更を伴うため、開発者や管理者の皆さんにも協力をお願いする必要がありました。そのプロセスについて、少し詳しくお話しします。 検討フェーズ - コストに見合う価値はあるのか？（苦労ポイント！！！） 　GHEC 導入を考える上で、特に気になったのはコスト面でした。それまでの Free/Team プラン混在状態と比べると、GHEC では 1ライセンスあたりの費用が、単純に計算しても約5倍 になります。先ほどお話ししたように、コストを意識する文化の中では、このコスト増は、導入を考える上で乗り越えるべき大きな壁でした。 　そこで、この「 目に見えるコスト増 」に対して、導入することでどんなメリットがあるのか、特に「 見えにくいコスト 」がどれだけ減らせるのか、費用対効果を詳しく調査し、試算を行いました。 はじめに使いたいと考えた機能としては、以下の2つでした。 GitHub Environments（GitHub Actions の実行承認機能など） Rulesets（ブランチ保護ルールの一律適用機能など） しかしながら、これらの機能だけでは、ライセンス増加に見合う効果が得られないため、GHEC でどのような機能が使えるようになるのか調査して、それぞれどういったメリットが得られそうか「 開発メンバー 」「 開発リーダー（管理者） 」「 システム管理者 」のおおよその単価から試算していきました！また、GHEC で一元管理できる点についても管理工数の面からメリットとして試算しました！ 検討時に想定した主な機能とメリット SAML 機能概要 SAML を利用した Single Sign On（SSO）が利用可能 Organization 単位だけの設定であれば、System for Cross-domain Identity Management（SCIM）によるプロビジョニング可能 想定したメリット 退職など不要になったアカウントの権限をSAML Identity Provider（IdP）側で担保できる GitHub Enterprise Cloud - Managed Users（GHEC EMU） 機能概要 企業個別のクローズドな環境 SCIM による アカウントのプロビジョニングが可能 想定したメリット ユーザー管理の徹底やパブリックに秘密鍵を公開することが防止できる ※ 後の検証によりこの機能は利用しません Internal リポジトリ 機能概要 Enterprise 内の Organization に共有される Public と Private の間の権限リポジトリ 想定したメリット 社内向けのツール作成や企業内のソースコードを参照 Environments 機能概要 環境を作成して、デプロイの保護ルールが設定できる 想定したメリット デプロイ対象ブランチの制限による誤ったデプロイが防止できる Actions でのデプロイ時に承認フローを挟むことで安全なデプロイ作業ができる 環境固有のシークレットを設定でき柔軟な Actions ワークフローを組むことができる Rulesets 機能概要 Repository や Organization レベル（検討時）でブランチ・タグに対する操作ルールを一元的に定義・適用できる 想定したメリット 個々のリポジトリで設定していたブランチ保護ルールが不要になる 監査ログ 機能概要 監査ログの確認、API が利用可能、外部ストレージへのエクスポートが可能 想定したメリット インシデント時の調査用記録保管 Insights（Teamプラン以上からも可） 機能概要 Actions のワークフロー/Job 別の実行時間や成功/失敗確率の確認が可能 依存関係の状態と脆弱性レベルの確認が可能（dependabot 設定が必要） 想定したメリット Actions の実行時間が長い Job が簡単に特定できる 依存状態と Critical な脆弱性の依存を簡単に特定できる GitHub Pages Private 機能概要 Private な GitHub Pages を作成できる 想定したメリット 公開範囲を限定したいドキュメントなどをリポジトリと一元管理できる Actions の無料枠 機能概要 無料枠の拡張 想定したメリット 無料枠拡張分の従量課金料金の減少 機能以外のメリット（一元管理など） Organization の一元管理 他チームへのヘルプ時参画時に重複してライセンス費用が発生しないことによるコミュニケーションや時間、コストが削減できる Free プラン利用をしているチームが Team プラン以上で利用できる機能を使えることで工数削減やセキュリティリスク低減 アカウント、支払の一元管理 各 Organization 管理者で行っていたアカウントの権限作業を一元管理することによる工数削減ができる 検討時に見送った機能と理由 Advanced Security（GHAS）（Teamプラン以上から可） 機能概要 シフトレフトセキュリティな機能が使える コードスキャン、シークレットスキャン、依存関係管理 見送った理由 リポジトリへのアクティブなコミッターに対してへの従量課金であり、費用予測がつかないこと、また、この機能で得られる効果が不透明であった GHEC 導入と同時に検証する工数が取れなかった 　これらの面でメリットが得られそうだとわかり、 可能な範囲で定量化 しようと試みました。特に定量化しやすい管理工数削減に焦点を当て、それぞれのおおよその発生頻度や想定される作業時間から、 年間の見込み工数を算出 し、GHEC 導入によってこれらの作業がどれだけ自動化・効率化され、工数が削減できるかを試算しました。（もちろん、これはあくまで「概算」であり、全ての効果を事前に正確に数値化することは難しいですが、判断材料の一つとしました） 工数削減効果算出 こうした機能面からの定性的なメリット評価と、工数削減を中心とした定量的な効果試算を総合的に検討した結果、ライセンス費用の増加を考慮しても、それを上回る価値が期待できると判断し、次の検証フェーズに進むことを決定しました。 検証フェーズ − 各機能は組織の運用プロセスに沿うか 　メリットを享受するために利用できる機能の検証と現在の環境からの移行にかかる影響・コストの検証として、以下の項目に絞って検証を進めました。 検証には、Enterprise プランの無料期間1ヶ月を利用して実施するため事前に項目を整理＆準備を行うとともに、移行時に気になる点があったため GitHub 社へ依頼していくつか機能を開放してもらい検証に取り組みました。 検証内容 GitHub Enterprise Cloud - Enterprise Managed Users（GHEC - EMU） 概要 SCIMが利用可能なサービス GitHub の SCIM について 組織の環境に閉じるためより安全な運用が可能 ただし、完全にクローズドなため通常の環境からの完全なリポジトリ移行はできず、コピーに近い形になる。 GHEC - EMUについて 検証事項と結果 Organization 移行時の挙動 　→ 上記にも書きましたが、EMU の環境が完全にクローズドな環境のため完全なリポジトリ移行ができず、得たいメリットと比較して、開発者の移行コストが大きいことがわかりました。 GitHub Enterprise Importer というツールを使って移行を行うことになりますが、移行後に欠落するデータが多くレバレジーズでは採用できませんでした。 移行されないデータ ユーザーの作成削除の挙動 　→ 上記の検証結果からこちらの検証は不要なためスキップしました。 SAML SSO ログイン 概要 Enterprise での接続か Organization での接続が選択できる Organization での接続だとIdP側でユーザーの管理をすることも可能（SCIMを使って） Enterprise での接続について Organization での接続について 検証事項と結果 GHEC での SAML 挙動の確認 　→ 設定可能なIdP環境が限られており、当初利用している Google Workspace か IDaaS による設定を想定していましたが、Microsoft Entra ID による設定で行うこととしました。 　　幸運にも、Entra ID の外部 ID（無料利用可能）でも設定が行えたため追加の費用が発生せずスムーズに進めることができました。 SAML 無しから有りにしたときの挙動の確認（移行による開発者への手順書作成も兼ねてどういった遷移が行われるか） 　→ 検証時には特に問題が発生しそうな箇所はなく手順書作成のみとなりました。 　　※ 移行時にシステム上の問題で、少しだけ問題が発生しました。 GHEC で SAML 設定を行って、Organization で SCIM 設定可能かどうかの確認 　→ 問題はありませんでした。 Rulesets 概要 ブランチ保護ルールを全体に適用できるようにしたもの（個人的な理解） ブランチやタグなど柔軟にブランチ保護ルールで設定する項目と同等のものが設定可能 Enterprise プランからのみ利用可能 ブランチ保護ルールについて ルールセットについて 検証事項と結果 メインブランチへの直 Push の禁止 や マージに1人以上の Approve・Actions によるCIテスト通過が必要なこと を設定して意図したとおりに動作するか 　→ 基本的には意図したとおりに設定が行えました。 　　既存のブランチ保護ルールで CI テスト通過を必須にしていたものと同様の設定をルールセットで試みたところ、常に NG 扱いになってしまったため、ルールセットでの一律適用は見送りました。 Enterprise 全体で設定を反映・強制可能かどうか 　→ 検証/導入時（2024年6月頃）には、Organization 単位でしか設定できませんでしたが、その後 Enterprise 全体で設定を反映・強制できる機能が追加されました（2025年4月現在）。当時は、どのように一律な設定を行うか運用面でのカバーが必要でした。 　　また、チームによって運用が異なっていたため強制有効化したときの影響範囲が大きいことがわかりました。 システムアカウント・Personal Access Token（PAT） の排除 概要 システム上で動作させるためのトークン発行先として、一部のサービスではシステムアカウントを作成し、そのアカウントで PAT を発行し利用していました。 主な PAT の利用先 Terraform モジュール - SRE チームで作成している社内向けのモジュール ブログリンク： https://tech.leverages.jp/entry/2024/06/27/151539 社内向け Packages - 同上の社内向け Package 外部ツールとの認証 - CircleCI など 検証事項と結果 PAT による Organization を跨ぐ認証処理から GitHub Apps を利用したものへの変更 　→ 従量課金サービスの開放は、検証環境段階では不可能ということで完全な検証はできませんでした。 　　疑似的に再現するため、検証用の Organization を別途作成し、GitHub Apps で問題なく動くことを確認しました。 Terraform モジュールは問題なく動作させることが可能でしたが、一部外部ツールでは GitHub Apps による連携ができないことや GitHub Packages が仕様上 Apps での利用ができないことがあり、PAT の完全排除とはなりませんでした。 　　ただし、いくつかのシステムアカウントでは問題なく Apps への移行ができたため、完了次第アカウントの削除対応が可能なことがわかりました。 導入・切り替えフェーズ - いよいよ本番移行！段階的アプローチと予期せぬトラブル Enterprise への切り替えは、当面のゴールとして、大きく2つのステップに分けて切り替えを行いました。 ステップ1：Organization の Enterprise への参加 　検証項目で整理したドキュメントや切り替えの手順を管理者や開発者に周知して、1ヶ月程度の期間で段階的に切り替えを行いました。 　基本的な動作に影響が無いことは確認が取れていましたが、網羅できていない項目などがないか段階的に切り替えを行うことで確認と対応ができるようにこの方法で切り替えを進めました。 　ここは、個人的に周知の方法や事前準備など不慣れなこともあり多少の混乱を招いてしまいましたが、段階的に進めたことで開発自体の大きなインシデントなどは発生させずに進めることができました。 ステップ2：SAML SSO の Enterprise レベルでの適用 　全 Organization の参加後、Enterprise 全体で SAML SSO を有効化しました。この SAML の適用と GitHub の連携では、2つ問題が発生しました。 　① Entra ID で設定している特殊な漢字の名前が GitHub 側で利用できず SAML SSO ログインができない 　② SAML SSO を設定後、既存の連携システムでエラーが発生 　それぞれ以下のように対応しました。 　① Entra ID と GitHub の情報連携において、Entra ID の表示名も含めて連携しており、この項目がオプションであったため連携項目から除外することで解決しました。 　② SAML SSO 設定後の認証された OAuth Apps との認証情報が利用できなくなっており、一度認証を解除して再設定を行うことで解決できました。また、どのようなアプリが連携されているのか把握できていなかったため、追加で設定解除の手順を作成して展開することで解決しました。 　※ 連携アプリの一覧は、 https://github.com/settings/applications で確認できます。 運用安定化フェーズ - 運用ルールの整備と自動化へ向けて 　GHEC 環境のライセンスは前払いのため、未使用ライセンスの費用発生を防ぐことが重要でした。そこで、まずは Organization の Enterprise への参加を優先し、全体ルールの適用などの細かな設定は後回しにしました。安定化フェーズでは、これらの後回しにした設定の反映や、アカウント発行・削除などを自動化するフローの整備を進めました。（これにより、ライセンス費用の最適化も図っています。なお、ライセンス体系も変化しており、移行当時は年間契約のみでしたが、現在は従量課金プランも提供されているようです） 　利用側から見て一部不明瞭な点もあったため、質問対応やドキュメント修正などを随時行い、大きな問題を発生させることなく現在まで運用を進められています。また、運用を巻き取れたことで楽になったといった声をもらうこともあり、進めてきて良かったと感じています。 まとめ 結果的に当初予定していたいくつかの項目については完全な適用はできませんでしたが、ルールの徹底や運用の自動化によってカバーできる内容であったため、GitHub Enterprise Cloud（GHEC）への移行で得たいメリットは享受できたと考えています。 いくつか完全な自動化ができていないものがあるので、今後はそれらの自動化や運用フローを整備したり、ブランチの保護ルールを徹底していくことで、生産性向上やコスト削減、セキュリティの担保をより進めていきたいと思います。 弊社にご興味のある方へ レバレジーズでは、一緒に働く仲間を募集しています！ 少しでも興味を持っていただけたら、ぜひカジュアル面談にご応募ください！ hrmos.co