レバレジーズ 株式会社 の技術ブログ
全142件
はじめに システム本部レバウェル開発部部長の高木です。 レバレジーズでは、企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、各個人の成長を促す」ことを掲げており、社内で様々な学習支援制度を設けています。 開発組織でも、2023年度から「Leveragese Engineer Growth(仮) 」というタイトルで技術支援制度の運用を開始し、私は「オンライン学習支援(Udemy Business学び放題)」の導入と運用を担当しておりました。 技術支援制度の内容は以下の通りです。 技術書支援：技術書購入を月1万円補助 オンライン学習支援：Udemy Business学び放題 カンファレンス費用補助：有料カンファレンスの費用を1回上限1万円まで補助 スクラムマスター研修補助：一定基準を満たした希望者に対する外部研修参加費補助 オンライン学習支援制度を開始したのが、ちょうどクリスマスからだったので、まばゆく光るクリスマスイルミネーションに思いを馳せながら、1年間運用してみた結果についてまとめてみました。 この記事を読んで分かること なぜUdemy Businessを選んだのか 導入前のちょっとした懸念 1年運用してみた結果 なぜUdemy Businessを選んだのか 技術支援制度策定時には、オンライン学習支援サービスとしてUdemy Business含む4サービスを比較・検討していました。 当時、オンライン学習支援ツールに求めていたのは下記3点で、各ツールが提供している機能を比較したところ、最もバランスが良かったサービスがUdemy Businessでした。 (だんだんUdemyの宣伝をしている気持ちになってきた) ①予算内に収まること ②学習コンテンツの幅が広く・深いこと ③学習促進・管理機能があること ①は自明のため割愛しますが、②と③の要求は、弊社開発組織に所属するエンジニアの特徴を踏まえた内容だったため、それぞれ補足します。 ②学習コンテンツの幅が広く深いこと 弊社開発組織に所属するエンジニアの大半は、中途入社者で占められており、一定のWEB開発経験を持った方が多く在籍しています。 ただ、オンライン学習支援サービスの大半は、初学者向けコンテンツがより豊富に用意されていました。 学習コンテンツが初学者向けだと、利用ユーザーが少ない可能性が高いことが想定されたため、なるべく学習コンテンツの幅広さ、そして内容の深さを要求に含めていました。 ③学習促進・管理機能があること エンジニアの学習手段は、オンライン学習の他にも技術書での学習、社内勉強会、カンファレンス参加と多岐に渡ります。そして、他の技術支援制度でも前述した学習手段を支援していました。 オンライン学習支援制度は、 弊社開発組織における学習支援の主軸というより、数ある支援手段の1つという建付けだったため、なるべく管理者が学習進捗へのマイクロマネジメントを行わず、利用者が自分自身の進捗を確認できるような機能を求めていました。 導入前のちょっとした懸念 Udemy Businessは、候補の中でもバランスが良いサービスでしたが、「②学習コンテンツの幅が広く・深いこと」に関してはちょっとした懸念がありました。 それは、UdemyとUdemy Businessでは、学習できる講座数に差があることでした。 そもそも、Udemy Businessは法人向けに用意されたサービスであるため、Udemy上の講座から厳選された講座が、学び放題の対象となっていました。 厳選されているとは言え、1万講座以上はありましたが、エンジニアが学び続けられるコンテンツの幅広さ・深さを担保していると断言はできませんでした。 Udemyを個人で契約して学習しているエンジニアも一定数いたため、ありがたいことにオンライン学習支援制度への期待も寄せられていましたが、学びたい講座が無くログインしない利用者が多いと、導入後の振り返りも難しい…。 上記懸念があったため、オンライン学習支援制度の利用を希望をする方には、Udemy Businessの講座ラインナップの中で自身が学びたい講座があるかを確認した上で、意思表明してもらうようにしてみました。 1年運用してみた結果 希望者制にした結果、この1年でのべ92名のエンジニアが利用し、弊社開発組織内での学習傾向が見えてきました。 そのうち、想定通りの結果と予想外の結果を要約してご紹介します。 想定通りの結果 若手エンジニアの方が、Udemy Businessでの学習時間が長い 開発チームで利用している言語・フレームワークに関する講座が、よく視聴されている AWS認定資格取得講座が、よく視聴されている 導入から時間が経つにつれて、学習時間が減少する Udemy Businessを導入している企業の中では、学習時間が平均以上となった 予想外の結果 ソフトスキルに関する講座が、エンジニアの経験問わずよく視聴されている 例：リーダーシップ、ロジカルシンキング、コミュニケーション講座 AWS認定資格以外の資格取得講座が、よく視聴されている 例：PMBOK、データスペシャリスト、情報セキュリティマネジメント試験 英会話・TOEIC対策講座が、異様なほど視聴されている まとめ 想定通りではありましたが、オンライン学習支援制度を導入した当初は希望者・学習時間ともに最大値を記録しましたが、時間の経過と共にいずれも減少傾向となりました。 一方で、特定領域に閉じず幅広く学習したい方にとっては、自己学習の手段として有効である示唆を得られたため、引き続き同制度を運用する予定です。 (来年度の目標は、採用数、定着率、生産性などで定量的に効果を示すことです！) We're hiring！ 今回の記事では、レバレジーズ開発組織で運用しているオンライン学習支援制度の導入検討材料と1年間運用してみた結果について取り上げてみました。 レバレジーズに少しでも興味を持っていただけた方は、 こちら からぜひエントリーをお願いします！ イルミネーションが光輝く渋谷にて、お待ちしております！💡
はじめに こんにちは。 レバレジーズでHRTech系SaaS NALYSYS の開発チームでEMをやっております、下畑と申します。 11月に弊社エンジニア6人 + 人事1人の計7人でフルマラソンに参加しました。 全員フルマラソン未経験でしたが、7人中6人が完走することができました。 この喜びを多くの人に伝えたいと思い、今回記事にしてみました。 この記事を読むとわかること 4ヶ月でフルマラソンを完走する方法 4ヶ月の練習を乗り切る術 弊社エンジニアの人柄 フットワーク軽すぎぃ！ やり切る胆力もってんだよな 弊社エンジニア組織のハートフル感 ことの発端 弊社では朝の始まりをご機嫌な気分で始めるために、毎朝Good & Newという時間があります。 週替わりで部署を跨いだ社員同士の予定が組まれ、昨日あった面白かったことや、最近始めたことを紹介しあいます。 7月某日のGood & Newがことの発端でした。 弊社PdM「最近妻に太ってるのをなんとかしろって言われてフルマラソン出ることになったんですよ。」 わたくし「いいじゃん。いつ走るの？」 弊社PdM「11月のひたちシーサイドマラソンに出ます。」 わたくし「いいじゃん。俺も出たろ。」 なぜ二つ返事で参加すると言ったかというと、私はPdMのお腹がそこそこ出ていることを知っていたからです。 この人が走れて自分が走れないわけがない。 走れなかったとしても、彼も走れないから別に恥ずかしくない。 だったら出ようと。 そういうことです。 仲間を求めて 2人だけの参加だとイマイチ盛り上がりにかけると思ったので、事業部内のメンバーに声をかけてみました。 日課でマラソンをしている人を筆頭に色々声をかけた結果、今回のエンジニアランナー6人が集まりました。 まさかこんなに集まるとは思いもしていなかったです。 フルマラソンという競技のもつ魅力と、弊社エンジニアのフットワークの軽さに驚きました。 今回仲間集めで学んだことは、 「筋トレをしている方は、有酸素運動の量にうるさい傾向があるため誘わない方がいい」 ということです。 練習メニューの模索 フルマラソンを走るために我々はなにをやればいいのか？ 周りに専門家がいるわけでもなかったので、情報収集から始めました。 7月中旬に走ろうと発起したので、本番まで4ヶ月ちょっと。 しらべてみるとこんな記事を見つけました。 【4ヶ月の練習でフルマラソン完走！】初心者用16週間トレーニングプラン これを守って練習しようと決めました。 要約するとこんな感じです。 1ヶ月目： 平日 30分〜40分 × 2 週末 60分〜80分 2ヶ月目： 平日 30分〜40分 × 2 週末 16km〜20.8km 3ヶ月目： 平日 30分〜40分 × 3 週末 25km 4ヶ月目（最初の2週間）： 平日 30分〜40分 × 3 週末 30km以上 4ヶ月目（最後の2週間）： 休息期間 週に1時間くらい走る 当時はこのメニューのおそろしさを知らぬまま、4ヶ月の練習でも完走できる希望があることにただ喜んでいました。 絶望と人間の持つ可能性に震えた初週 練習を開始してまもなくみんなが感じたことを書きます。 30分走ると4kmから6kmくらい走ることになりますが、その時点でとてつもない筋肉痛をみんな味わいました。 フルマラソンを走り切るためには10倍くらい走らないといけないと想像したとき、 やろうとしていることの過酷さを感じるとともに、 4ヶ月間このトレーニングメニューをこなしフルマラソンを完走できるのであれば、人間の成長ってすごいんじゃない？ と感じざるをえませんでした。 この困難に打ち勝つにはなにかしなきゃと。様々な策を講じていきます。 困難に打ち勝つための作戦 その1 strava というサービスをご存じでしょうか？ ランナーや自転車乗り向けのSNSなのですが、走ったデータを記録し、フォロワーに対して共有することができるサービスです。 参加するメンバーにはこのSNSに登録してもらい、走った記録を共有するようにしました。 もちろんSNSなので、いいね機能（stravaだと”kudos”です☺️）やコメント機能があり、 走った記録に対して毎回みんなからいいねやコメントがもらえました。 実際にもらえたkudosやコメント 同じ辛さを共有しているメンバーからの励ましは嬉しいですし、 メンバーの頑張りも見えるのでとても励みになりました。 困難に打ち勝つための作戦 その2 カレンダーに定期ランの予定を入れました。 走ってサウナ入って、たらふく食べて酒を飲む会なのですが、 日々の練習とは違い、おしゃべりしながらゆっくり走りますし、 マラソンのストイックなイメージを払拭するにはいい効果があったかなと思います。 予定はこんな感じで人が集まったら開催です。 参加者が2人以上いれば開催です スカイツリーを目指して隅田川沿いを走ってました ランニングステーションは ととけん を利用していました。 走ったあとのサウナとビールが最高のお店です。おすすめです。 意外な副作用 定期ランは「フルマラソンに挑戦するのは遠慮しておきます」という方であっても誘いやすく、 会社の飲み会などで興味を持った方を積極的に誘いました。 この定期ランをきっかけに、フルマラソンに参加すると決めた人事部の方がいらっしゃいます。 彼女も無事に完走しました。（すごい） 他部門との交流が多いのも弊社の特徴かもしれません。 怪我との戦いと練習メニューの見直し 毎週1.6km（1マイル）ずつロングランの距離を増やしていきますが、距離が20kmを超えたあたりで皆どこかしらの故障を経験しました。 怪我をすると練習時間を失うため、4ヶ月という限られた時間で練習している我々は精神的にも追い詰められました。 まわりが練習するなか練習できない不安感は筆舌に尽くしがたいものがあります。 フルマラソンを完走するために必要な要件を新たに探し求めたところ、 この記事 に出会いメンバーに共有しました。 ロングランの距離を伸ばすのではなく、週の距離を伸ばすよう練習メニューを変えた結果、怪我をせずにフルマラソン当日を迎えることができました。 部活動チャンネル 弊社では非公式の部活を勝手に旗揚げすることができます。 slackで部活用のチャンネルを自由に作ることができるのですが、我々もこのようにチャンネルを作成し情報共有する際に使っておりました。 チャンネルでの共有 いざ、フルマラソン旅行 日立市での開催だったので、月曜日に有給を取得し2泊3日のフルマラソン旅行になりました。 マラソンは日曜日だったのですが、翌日のダメージが想像できず、帰りの道路で事故のリスクもあったためこの日程を組みました。 行きと帰りはわちゃわちゃ観光を楽しみ美味いものを食べ、宿はairbnbにみんなで泊まりわちゃわちゃしました。 大洗のめんたいパークに行きました これまでの練習や仕事で関係性ができていたため、観光中も宿泊中も無駄な気遣いをせず、ストレスなく過ごせました。 これって地味にすごいことかなと思っています。 こうして記事を書いてみると当日のことはあまり書けることはなく、ひたすら辛かった。 皆身体を壊さず完走出来たのが良かったです。 凱旋 東京に帰ってきてから、なんだか思いが溢れちゃってLINEのグループでメンバーへの感謝を伝えました。 それに応じてみんなも色々書いてくれてとてもエモかったです。 6人同時に有給をとった我々を、温かく応援してくれた他のチームのメンバーにもここで感謝させてください。 おわりに 皆仕事の合間を縫ってやりたいことをやるために練習時間を捻出しました。 社会人として大事なことな気がします。 こうして過程を書いてみると、計画を立てたりそれを履行したりと、仕事とやってることあんまり変わらないんじゃねえかと思いました。 ただ、普段はあまり一緒に仕事をしない、チームを超えた関係性のなかでそれが出来たことがとても貴重だったと思います。 また、マラソンの経験者がいるなかでの話だとまた違った感情になりそうだと思います。 みんなが未経験で訳も分からないなかでフルマラソンに挑戦した、という経験がもたらすもののかけがえのなさは確かに存在するのかもなと思いました。 フットワーク軽く誘いにのってくれて、これほどの辛い練習に付き合ってくれたメンバーの皆様。ありがとうございました。 ここまで読んでくれて、こんなハートフルな仲間と働いてみたいと感じた読者の方。仕事を超えた関係性を作りたいと感じたそこのあなた。フルマラソンを人生で1回は走ってみたいと思っているそこのエンジニアの方。 是非是非、 こちら からご応募待ってます☺️ 我々のチームの雰囲気がよくわかる動画がYoutubeにも上がっておりますので、 興味を持たれた方はお時間ある時にみてみてください。 www.youtube.com
はじめに こんにちは。レバレジーズ株式会社システム本部の及川です。 2024年9月に転職スカウトサービスである「キャリアチケット転職」をリリースしました！ 既存の新卒向け就職支援サービス「キャリアチケット就職」が生んだ、若手×成長志向に特化した転職メディアとなっています。 今回、求人機能やスカウト機能、応募機能などを盛り込んだ大きなリリースとなりました。このような新規事業では開発にとどまらず、設計やマーケティング、オペレーション周りにも関わることができました。 本記事では「キャリアチケット転職」のリリースにあたって、下記4点を紹介したいと思います。 サービスの詳細 技術選定の背景 技術的こだわり 今後の取り組み この記事を通じて、本サービスの詳細だけでなく、技術選定の背景や私たちの技術へのこだわりが伝われば幸いです。 はじめに サービスの詳細 技術選定の背景 アーキテクチャ フロントエンド バックエンド API インフラ 技術的こだわり GraphQL Federationの活用 モノレポの導入 CI/CDの自動化 開発環境構築の自動化 今後の取り組み さいごに サービスの詳細 まず今回リリースしたサービスの特徴を説明します。 サービスの背景として、既存の「キャリアチケット就職」では、2017年のサービス開始以降、年間1.4万人の学生一人ひとりの価値観に合った就活支援を行ってきました。 昨今の若手の転職ニーズの高まりを受け、キャリアチケットの強みである「一人ひとりに適したキャリア支援」を行い、現状のキャリアに不安や迷いを感じる若手を支援するサービスとして、「キャリアチケット転職」をリリースすることになりました。 サービスの特徴としては、求職者には経歴だけでなく、仕事で重視することや実現したいことを記入してもらうことによってより価値観が合った求職者を見つけることを可能にしています。 技術選定の背景 次に技術選定の背景についてです。 レバレジーズの新規事業は技術選定も0から自分たちで行うので、自分が挑戦したい技術なども選択肢に出しやすく、モチベーションアップに繋がりました。 今回のプロジェクトでは、スピード感を持った開発を最優先事項として掲げ、開発メンバーの技術力向上も同時に目指しました。そのため、既にチームに知見のある技術を基盤として採用しつつ、メンバーが挑戦できる新しい技術も積極的に取り入れるようにしました。 アーキテクチャ 言語はフロントエンドにTypeScript、バックエンドにGoを採用しました。TypeScriptのメリットは、静的型付けにより事前に型エラーが分かる型安全性があることが挙げられます。また既にチームに知見のある技術でもありました。 Goのメリットは文法がシンプルで覚えやすく、直感的に書けるため学習コストが低いこと、静的型付けによる型の安全性があること、パフォーマンスが高く運用コストが抑えられることが挙げられます。社内で知見の多いPHP（Laravel）やTypeScriptもバックエンドの候補に上がりましたが、開発メンバーの技術力向上を目指して新しい技術としてGoを採用することになりました。 フロントエンド TypeScriptで開発するにあたり、フレームワークとして Next.jsを使用しました。これらはチームメンバーの知見が豊富であることを理由に選定しています。 さらに、データ取得には GraphQLを利用しており、GraphQL Codegenを用いることで、型安全なクエリやミューテーションの操作を自動生成しています。生成された Document を活用して、useQueryやuseMutationといった React Hooks 経由で簡潔かつ型安全にクエリを実行できる仕組みを構築しています。 フォーム操作では react-hook-formを採用しており、軽量で柔軟性の高いフォーム管理を実現しています。また、サーバーからのレスポンスに基づいた動的なバリデーションも組み込みやすくなっています。 テスト環境では、msw (Mock Service Worker) を利用して、API レスポンスをモックすることで、ネットワーク依存を排除したテストを可能にしています。これにより、開発初期段階やバックエンドが未完成の場合でも、フロントエンド側でのテストやデバッグが容易になっています。 これらのツールを組み合わせることで、開発の生産性とコードの品質を高めるとともに、保守性の向上を図っています。 バックエンド Goで実装するにあたってFWは採用しませんでした。理由としてBEがAPIサーバーとしての役割だったので、 標準ライブラリ（net/http）で十分であり、FWを使わない方がシンプルに実装ができると考えたからです。 ORMはSqlBoilerを採用しました。SqlBoilerはデータベースのスキーマからコードを自動生成するため、型安全性が高く、SQLクエリの構築ミスや型の不一致によるエラーを未然に防げます。 また、CRUD操作が即座に利用可能なコードを生成するため、開発効率も向上します。スキーマ変更時も再生成でコードを簡単に更新できるため、保守性が高いのも特徴です。ただし、マイグレーション機能は備わっていないため、外部ツール（golang-migrate）を併用して対応しています。これにより、安全で効率的なデータベース操作が実現可能です。 API APIには GraphQL を採用しました。 本サービスはマイクロサービスアーキテクチャを採用しているため、GraphQL Federationを活用することで、各サービス間のデータ統合を効率化し、パフォーマンスの向上を目指しています。GraphQL Federationについては後ほど詳しく説明します。 また、APIの効率的な処理を実現するために Apollo Routerを活用し、これと併せて Apollo を採用しました。Apollo Routerは、高速でスケーラブルなGraphQLリクエストのルーティングを可能にするツールであり、特にマイクロサービス環境やGraphQL Federation構成においてその真価を発揮します。これにより、複数のサービスからのデータを統合し、シームレスでパフォーマンスの高いAPI提供を実現しています。 インフラ インフラ周りはAWSを基盤として、環境の構築はAWS CDKを採用しました。TypeScriptでコード化することで、インフラの知識があれば慣れたプログラミング言語で誰でも簡単にインフラ環境を構築できて、コードやCLIから簡単にレビューできる体制を目指しました。 技術的こだわり 次に技術的こだわりを紹介します。 GraphQL Federationの活用 GraphQL Federationは、複数のGraphQLサービスを統合して一つのGraphQL APIとして提供する設計手法およびツールセットです。これにより、分散型アーキテクチャでも効率的にデータへアクセスが可能となっています。 各マイクロサービスが独自のGraphQLスキーマを持ち、独立して開発・デプロイできるため、当サービスで採用しているマイクロサービスアーキテクチャとの親和性が高いです。 さらに、スキーマの拡張性が高く、あるサービスで定義した型を他のサービスで簡単に拡張することが可能です。この特性により、マイクロサービス間でのデータ共有や拡張が柔軟に行うことができます。詳細については、以下のリンクで図を用いて分かりやすく解説されているので、ぜひご参照ください。 www.apollographql.com モノレポの導入 モノレポ（Monorepo）は、複数のプロジェクトを1つのリポジトリで管理する手法です。この仕組みにより、以下のメリットを実現しています。 コードと依存関係の管理が簡単 共通ライブラリやユーティリティをリポジトリ内で共有し、外部パッケージのバージョン管理の複雑さを軽減しています。 一貫した開発環境 ESLint、Prettier、テストフレームワークの設定が統一され、全プロジェクトに一貫性を持たせています。 CI/CDの自動化 当サービスでは、継続的インテグレーション（CI）と継続的デリバリー（CD）を自動化することで、開発とデプロイの効率化を実現しています。 一貫性のあるビルドとテスト コード変更がリポジトリにプッシュされるたびに、自動でビルドとテストが実行されます。これにより、バグを早期に発見し、リリースの品質を高めることができます。 自動デプロイ 特定のブランチにマージされたコードは、ステージング環境または本番環境に自動的にデプロイされます。このプロセスにより、手動デプロイによるミスを防ぎ、リリースサイクルを短縮します。 モノレポとの連携 モノレポ内の変更に応じて、影響を受けるプロジェクトのみをビルド・デプロイする仕組みを採用。たとえば、Aサービスに変更が加わった場合、Bサービスのデプロイはスキップされます。これにより、CI/CDプロセスの実行時間を大幅に短縮できます。 これらの仕組みを通じて、迅速かつ高品質なリリースを継続的に行えるようにしています。 開発環境構築の自動化 エンジニアが迅速に作業を開始できるように、開発環境の構築プロセスも自動化しています。これにより、個々の環境構築にかかる工数を削減し、全員が一貫した環境で開発を進められるようにしています。 Dockerコンテナの活用 開発環境をDockerコンテナで構築し、各エンジニアが同一の環境を再現可能にしています。これにより、「自分の環境では動作するが他の環境では動作しない」という問題を排除しています。 セットアップスクリプトの提供 必要な依存関係や設定をインストールするセットアップスクリプトを提供しています。新しいエンジニアがリポジトリをクローンした後、スクリプトを実行するだけで、必要なツールやライブラリが自動的にインストールされます。 これらの取り組みにより、エンジニアは環境構築に時間を取られることなく、すぐに本来の作業に集中できるようになります。 今後の取り組み 私たちのチームでは、エンジニアに限らず、マーケターやデザイナーを含めた多職種のメンバーが、より良いサービスを目指して日々議論を重ね、多様な施策を実行しています。 私自身もエンジニアとして、利用者を増やすためのアイデアを提案したり、エンジニアの視点からデザインにコメントをしたりと、チーム内で積極的にコミュニケーションを図っています。 その中で、私たちが今後取り組んでいきたいと考えている施策は以下の通りです。 求人数・求職者数の増加 サービスの成長のため、より多くの求人情報や求職者をプラットフォームに集めることが重要です。これにより、求職者に多様な選択肢を提供し、ユーザー満足度の向上を目指します。 精度の高いマッチングの実現 求人数や求職者数の増加に伴い、マッチング精度の向上がこれまで以上に重要となります。これを実現するため、検索アルゴリズムの強化や高度な検索機能の開発、求職者のユーザー体験（UX）の改善を図っています。これにより、システム全体の性能を向上させ、各ユーザーにとって最適な結果を提供できるよう進化を続けていきます。 求職者向け：希望条件に基づき、最適な求人の選択肢を提供します。これにより、求職者が自分に最も適したキャリアの選択ができるよう支援します。 採用担当者向け：企業の条件や組織風土に合致する求職者をレコメンドすることで、採用プロセスの効率化の向上を支援します。 パフォーマンスの向上 ユーザー数の増加に伴い、システム全体のパフォーマンス向上も重要な課題です。安定したサービス提供を維持し、快適な利用体験を保証するために、インフラやアーキテクチャの最適化を継続して行っていきます。 これらの課題に取り組むことで、サービスの価値をさらに高め、多くのユーザーに選ばれるプラットフォームを目指していきます。 さいごに 最後までお読みいただきありがとうございました。 キャリアチケット転職を通してより多くの求職者を支援することを目指して、これからの課題に取り組んでいきたいと思っております。 そして本記事を通じて、サービスの詳細をはじめ、技術選定や私たちの技術へのこだわりのイメージを持っていただけたなら幸いです。 現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ 採用サイト をご覧ください！
この記事を読んで分かること レバレジーズの機械学習エンジニアの今年1年の活動について分かります！ レバレジーズの生成AIを活用した取り組み状況について分かります！ この記事を読んで分かること はじめに 今年やったこと 生成AIへのリソース全振り 最初にぶつかった壁：そもそも社内で生成AIを使える状態にする CAIL(社内AIチャットツール)の開発 CAILの社内認知 社内用Difyの整備 社内QAボット その他具体的な内容は書けないが業務効率化したもの toC/toBサービスへの機能開発 来年やりたいこと CAILの機能強化 toC/toBサービスへの生成AI機能の組み込み 社内の業務効率化 生成AI以外の機械学習モデルのサービス組み込み、MLOps基盤の整備 社内での評価 最後に はじめに システム本部テクノロジー戦略室AI/MLエンジニアリンググループの稲垣です。 AI/MLエンジニアリンググループはいわゆる機械学習エンジニアが所属するチームになっており、現在は私含め3名が所属しています。 チームの主な役割としては以下があります。 データサイエンティストが作成した機械学習モデルのプロダクトへの組み込み、MLOps基盤の整備 生成AIを活用したプロダクト改善、機能追加、社内業務効率化 この記事では、今年1年の振り返りをすると共に、来年はどんなことをやっていきたいのかについても触れていきたいと思います。 また、上記を書いていく中で 「会社のためになると思うことは自由にチャレンジしてOK」 というレバレジーズのエンジニア文化が少しでも伝われば良いなと思っています。 レバレジーズの機械学習エンジニアの働き方について興味がある方にとって、有益な情報になれば嬉しいです。 今年やったこと 生成AIへのリソース全振り 結論から言うと、今年の我々のチームは生成AIに関することにリソースを全振りしよう、という形になりました。 背景としては、社内の機械学習モデル関連のタスクが一段落していた点と、みなさんもご存知の通り今年も昨年に引き続き生成AI関連技術の進歩が著しかったことがあります。 また、生成AIの特性上、モデルを1から作る必要は無くベンダーが提供するAPIを叩くだけで使用できるため、データサイエンティストの所属するチームではなく我々のチームの方が相性が良いだろう、という判断もあった点もあります。 最初にぶつかった壁：そもそも社内で生成AIを使える状態にする 今年の1月時点では、社内での生成AIの活用事例はほぼゼロでした。 また、社内で生成AIを使う上でのガイドラインなども存在しておらず、社内で生成AIを使ってよいのか良く分からない、誰も知らない、という状況でした。 そのため、例えばあるプロダクトに生成AIを使った機能を追加するアイディアがあっても、社内で生成AIが使えない状態であったり、社内における生成AIに対する認知/理解があまり無い状態のため前に進めることは困難でした。 このような状況であったため、チームとしてまずは 社内で生成AIを誰でも使える状態にすること（社内インフラと社内ルールの整備） 社内での生成AIの認知/理解を高めていくこと（社内での生成AI活用推進） を行っていこうという方針となりました。 また、今年のレバレジーズの全社スローガンが「次代を、創る。土台を、創る。」であったため、その内容にもマッチしていて良さそう、という背景もありました。 CAIL(社内AIチャットツール)の開発 CAILとは「Chat AI for Leverages」の略で、その名の通りレバレジーズ社内用のAIチャットツールです。 （補足：昔のwindowsにいた某イルカとの関連は全くありません!） CAILは簡単に言うと社内用ChatGPTのようなもので、上述の通り「社内の誰でも生成AIを安全かつ自由に使えるようにする」ことを目的に開発しました。 特に、社内限の情報を扱う際に情報漏洩のリスクが怖くて生成AIを使わないようにしている、という方が社内に多くいたため、その辺りの不安を解消することがCAIL開発を始めた大きなきっかけでした。 CAILの開発を始めるにあたり、フルスクラッチで開発する路線もありましたが、AWSが提供している「 BedrockClaudeChat 」という非常に素晴らしいAIチャットツールのOSSがあったため、そちらをベースにして開発しています。 （フルスクラッチで作っていたら多大な時間がかかっていたので、このOSSのコミッターの方々には足を向けて寝れません...） 社内ニーズがあるがOSS側では実装されていない機能（モデル追加、google認証、権限管理、コスト管理、PDF入力機能など）については社内で開発し、できる限り使い勝手が良いツールとなるよう努力しています。 CAILの社内認知 CAILを社内に展開し始めたのは今年の3-4月頃ですが、現在では約2000人（全社員の半分程度）のユーザーがおり、社内での一定の認知を獲得したツールに成長させることができました。 ただCAILの社内展開は最初から上手くいった訳ではなく、展開し始めた頃は社内で「生成AI＝得体の知れないもの」という雰囲気があり、ユーザー数の増加に苦労した時期もありました。 ユーザー数を増やすに当たっては 社内で生成AIへの感度が高い社員を探し出しCAILを使ってもらう/他の方にもオススメしてもらう 生成AIの業務への活用事例集を作る、CAILの使い方マニュアルを手厚めに作成し使い始めるハードルを低くする 社内の各組織の部長レイヤーの方にCAILを宣伝させてくれないか提案しにいく などの草の根活動を地道に行い、じわじわ社内認知を広めていく作戦を取っていました。 社内用Difyの整備 Dify とは、OSSで提供されている生成AIのノーコードツールです。 通常のチャットツールでは対応しにくい、生成AIの高度なユースケースへの社内ニーズがあったため導入することにしました。 こちらも全社員誰でも使えるように社内のクラウド環境でデプロイを行いました。 デプロイに際しては社内のSREが所属するチームと協力し、DifyをKubernetesクラスタ上に稼働させることで柔軟なインフラ構成を実現しています。 社内QAボット レバレジーズは年々社員数が増加しており、社内のバックオフィス系の問い合わせ対応工数もそれに伴い増加していました。 そこで問い合わせ工数削減のため、まずは情シス宛ての問い合わせ回答の一部自動化を目指し、生成AIを使ったQAボットを開発＆導入しました。 導入後は１日に大体10~15件程度の問い合わせを捌いており、かつ的を射た回答も一定数できているため、今後は情シス以外のバックオフィスへの拡大を検討している所です。 その他具体的な内容は書けないが業務効率化したもの これまで社内業務で手作業で実施していたもののうち、生成AIと相性が良いものに対してツールを開発し一部自動化を行いました。 結果、パートさん複数人分の工数が削減できる程度の効果があり、これまでリソースを割けていなかったタスクへの再配置、という改善を行うことができました。 toC/toBサービスへの機能開発 上記の活動が実を結んだのか、今年の後半ではtoB/toCプロダクトへの生成AIを利用した機能の開発の熱感が高まってきました。 現在進行中のものとしては NALYSYS のQAボット開発や、 レバテック への機能追加の検討が進行中です。 来年やりたいこと ここまで、AI/MLエンジニアリングチームで今年1年間で行ったことについて紹介しました。 以降は来年に向けてやっていきたいことについて書いていきます。 CAILの機能強化 より使い勝手を上げるべく、 Artifacts や Grounding , Agent などのより高度な機能の追加を行っていきたいと思っています。 また、現状CAILはChatGPTやClaude.aiのコピー版になっている節があるため、社内のBigQueryやGoogleDriveとの接続など社内チャットツール独自の機能の追加が出来ないかについても考えていきたいです。 toC/toBサービスへの生成AI機能の組み込み この領域に対しては来年特に力を入れて進めていきたいです。 具体的には、 現在検討を進めているプロダクトへの生成AI系機能追加を無事リリースする 生成AIをどうプロダクトの価値向上に活用できるか考え、提案していく 他の開発チームとのコラボレーションを進めていく あたりを頑張っていきたいと思っています。 社内の業務効率化 こちらは今年もいろいろ取り組みましたが、社内にはまだまだ人の手で実施されているタスクがあり、効率化の余地は残されているかと思います。 そのため、生成AIの力が上手く使えそうなものについてはツール/システムの開発を行い、業務効率化を進めていきたいと考えています。 生成AI以外の機械学習モデルのサービス組み込み、MLOps基盤の整備 今年はほぼリリースが回せなかった領域ですが、 来年は古くなった求人レコメンドシステム、APIサーバの刷新など、積極的に着手していきたいと思っています。 社内での評価 今年１年のAI/MLエンジニアリングチームの活動が評価され、今年の10月にベストエンジニア賞を頂くことができました。 今年我々のチームで行った動きは、上から司令として降ってきた訳ではなく、チーム内で話し合い目標を立てて始めたボトムアップ的な動きでした。 そのような中で結果として会社から評価された点は、「会社のためになると思うことは自由にチャレンジして良い」というレバレジーズの社風の影響を感じました。 最後に レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。（採用サイトは こちら ） AI/MLエンジニアリングチームでは、機械学習周りに強みを置きつつ、インフラ、バックエンド、フロントエンドまで広く携われる点、ユーザーのニーズの拾い上げからプロダクト開発まで一貫して経験できる点が魅力かと思います。 最後に、今年触れていた技術スタックについて参考までに記載します。 （今年は生成AIに染まっていたので普通のML系は少なめです） Infra:AWS,GoogleCloud IaC:AWSCDK,Terraform AI/ML:GoogleVertexAI,AmazonBedrock,AmazonSageMaker workflow:Airflow,GithubActions Backend:Python,FastAPI,LangChain Frontend:TypeScript,React ここまで読んでいただきありがとうございました。
はじめに レバレジーズ株式会社 レバウェル開発部の山口です。 2024年10月に開催されたDatadog主催のイベント「Datadog Summit Tokyo」に参加しました。 Datadogは監視ツールとしてだけでなく様々な活用方法がある ということを知り、とても勉強になるイベントでした！ その内容を皆さんに紹介したいと思います。 Datadog Summitの紹介 Datadogは、クラウドベースの監視（モニタリング）ツールです。システムやアプリケーションのパフォーマンスや動作状況をリアルタイムで可視化し、問題を早期に発見・解決するためのプラットフォームを提供してくれます。 そしてDatadog Summit Tokyoはオブザーバビリティの専門家やDatadogチームから直接学ぶことができる無料の１Day イベントです。 セッションでは他社のDatadogを活用した様々な取り組みを知ることができます。現場の生の声を聞く貴重な機会です。 www.datadoghq.com 参加の背景 Datadog使いこなせてないかも？ 総合転職サービス「レバウェル」のスカウトサービスでは監視ツールとしてDatadogを利用しています。しかし導入以来あまりメンテされておらず、新機能はおろか基本的な機能もフル活用できていないように見受けられました。 もっと活用したらサービスの品質を高い状態で維持したり、障害発生時の復旧速度を上げられるのでは？というモチベーションでチームとして知識向上に取り組み始めていました。 そんな時にDatadog Summit Tokyoの開催を知り、「これは行くしかない！」と他メンバーを誘って一緒に参加することを決めました。 カンファレンス支援制度 レバレジーズではエンジニアの支援制度の一つに 「カンファレンス支援制度」 というものがあります。これは 勉強会やカンファレンスの参加費の補助と、業務時間内での参加が可能になる制度 です。今までこの制度を利用したことがなかったので、「せっかくなら使える制度はどんどん活用してチームのモチベーションも上げていこうぜ！」ということで業務として参加させてもらうことにしました。 セッション イベントでは様々なセッションがありましたが、その中でも「Datadogってこんな使い方できるんだ！」という驚きがあったものを紹介したいと思います。 どのセッションも思わず聞き入ってしまうような内容だったので、ご興味ある方はぜひアーカイブ動画の視聴をお勧めします！ 【Datadogダッシュボードで見える化する、新たなビジネス価値創造のチャンス】NTT Docomo - 野部 大貴 様 アーカイブ動画 youtu.be こちらのセッションは大きく３つのテーマについて扱われました。 利用しているDatadogの機能 ビジネス価値向上への貢献事例 ダッシュボードとの向き合い方 この中でも特にダッシュボードに関するお話がとても勉強になりました。 全体的な内容をまとめつつ、 「こんな使い方があったんだ」といったDatadogを使いこなすヒント になる情報を紹介していきたいと思います。 利用しているDatadogの機能 紹介のあった機能と主な使い方は以下の通りです。 障害検知にMonitor Slackへの通知 普段と挙動が違うときに通知（Anomaly機能） 分析にAPM どこの通信、サーバーで問題が起きているのかを特定 網羅的な情報のモニタリングにダッシュボード 意味のあるデータが整理整頓されている 用途に応じたダッシュボードを作成 この中で私たちもぜひ活用したいと感じた機能が Anomaly機能 です。 AnomalyとはDatadogのMonitorの中の種類の一つであり、いわゆる異常検知モニターというものです。以下、公式サイトからの引用です。 引用元： https://docs.datadoghq.com/ja/monitors/types/anomaly/ 異常検知は、傾向や、季節的な曜日や時間帯のパターンを考慮しながらメトリクスの挙動が過去のものとは異なる期間を認識するアルゴリズム機能です。これは、しきい値ベースのアラート設定では監視することが困難な強い傾向や反復パターンを持つメトリクスに適しています。 docs.datadoghq.com 現在は主に閾値を用いた異常検知を行っていますが、アラートを鳴らす閾値を正しく設定するのが難しい場合もあります。例えば曜日によってアクセス数の傾向が大きく変わる場合などです。閾値が低すぎると偽陽性アラート（本当は問題がないのに問題があると通知する）が増えてしまいますし、逆に閾値が高すぎると異常を検知することができません。 Anomaly機能を利用すると過去のメトリクスをもとにパターンを学習し、そのパターンから外れた時にアラートを出してくれます。つまり「何かいつもと違う！」を検知することができます。より柔軟な監視設定をすることが可能になるため、ぜひレバウェルでも導入を検討したいです。 ビジネス価値向上を実現するためのダッシュボード作成 １つ前のテーマである「利用しているDatadogの機能紹介」でも触れられていましたが、情報の見える化・網羅的な情報のモニタリングにダッシュボードを活用しているというお話でした。 実際のビジネス価値向上事例 新機能であるd払いスタンプ機能をリリース モニタリングのためにダッシュボードを作成 モニタリングの結果、決済数は増加しているが宝箱開封率が低い、つまりお得さを届けきれていないお客様がいることが判明 宝箱開封を促すメッセージ機能の実装で開封率が32.3%向上し、KPI改善に貢献 システム担当が積極的にビジネス観点も見るようになった この事例の中ですごいと感じたのが、新機能をリリースして終わりではなく、 システム担当がしっかりモニタリングまで行っている点 です。 モニタリングをする際はシステム観点（問題なく使えているか）はもちろん、サービス観点（目的達成に貢献できているか）で計測することを意識しているとのこと。 具体的にはユーザーストーリー毎にエラー数やレイテンシを計測し問題なくスムーズに使えているかを確認したり、アクセス数を計測してどのくらい使われているかを確認しているそうです。 Datadogで確認した情報がきっかけで新たな検討に繋がり、ユーザーへより良い価値を届けられる という点が非常に素晴らしいですね。 ダッシュボードとの向き合い方 １つ前のテーマでもあった 「システム担当が積極的にビジネス観点も見るようになった」 という変化は、 ダッシュボードへの向き合い方 が変わってきたからこその結果と考えているとのこと。 具体的な内容は以下の通りです。 価値に繋がるデータは何か、どんな見方が良いのかを徹底的に考える 機能が目標通り使われているか？（リクエスト数） 目標達成の見込みを把握できる 起動時間はどれくらいかかるのか（レイテンシ） 改善が必要な処理を特定する 多く使われる動線はどちらか ニーズが高い動線を把握可能 今後の展望 ダッシュボードURLを発行して共有することで様々な人と議論できる ビジネス担当にも広げていきたい 一緒にデータを活用するという意識を高めた 同じデータを見ることでシステム改善の速度が向上する システム担当とビジネス担当が一体となっていきたい 前半の 「価値に繋がるデータは何か、どんな見方が良いのかを徹底的に考える」 はエンジニアにとって非常に重要な視点だと感じました。 私たちのチームでも日々様々な施策の開発を行っていますが、１つ１つの施策の目的をしっかり理解できているだろうか？と思わず自問自答してしまいました。 目的を理解していなければ、顧客へ届ける価値に紐づくデータがなんであるかも分かりません。ここはチームでも改めて考えてみたいと思います。 後半の「今後の展望」ではシステム担当とビジネス担当が同じデータを見てサービス価値向上に努めていきたいというお話がありました。 これはDatadogが掲げる 「Datadogを通じて同じデータを共有し、部門の壁を破壊する」 というコンセプトともマッチするものだと思います。 発表の中でも触れられていたダッシュボードの共有機能も今まで使ったことがありませんでしたが、とても便利な機能ですね！ この機能を使えばDatadogのアカウントを持っていないユーザーにも気軽にダッシュボードを共有することができます。 自分自身も部門や職種の壁を感じることは多く、ビジネスサイドがどのような数値を追っているのか明確には分からないというのが正直なところです。 開発サイドとビジネスサイドが同じデータを見て、同じ目標を追って施策を打てるように働きかけていきたい と思いました。 docs.datadoghq.com ワークショップ 午後はワークショップ「 APMと分散トレーシング - 高品質なソフトウェアの提供 」に参加しました。講義スタイルではなく、 Datadog Learning Center でワークショップ用のコースを1人で進めていき、分からないことがあれば個別に質問するスタイルでした。 Datadogを利用してオブザーバビリティを高めることで、いつどこで何が起こったのかを把握することができます。 ワークショップの内容に入る前に簡単にAPMとオブザーバビリティについて簡単に説明します。 APM（Application Performance Monitoring） APM は アプリケーションのパフォーマンス監視機能 のことです。アプリケーションのパフォーマンスと信頼性を監視、トラブルシューティング、最適化することが可能です。APMは、アプリケーション内の各リクエストの流れを詳細に追跡し、ボトルネックやエラーの特定、パフォーマンス向上に役立ちます。 より詳細な内容については公式を参照ください。 docs.datadoghq.com オブザーバビリティ（Observability） オブザーバビリティ（Observability） とはシステムやアプリケーションの内部状況を外部から観測可能にすることです。つまりアプリケーションの中で いつ・どこで・何が起こったのか把握 することを可能にします。 オブザーバビリティの実現には以下の三つを収集する必要があります。 ログ メトリクス トレース ログはアプリケーション内で発生したイベントの記録です。エラーログやアクセスログなどが該当します。 メトリクスはアプリケーションのパフォーマンスやリソース使用量を定量的に計測したものです。CPU使用率やエラーレートなどが該当します。 トレース（分散トレーシング）はリクエストがシステム全体でどのように処理されるかの流れを追跡するものです。リクエストに付与されたユニークなトレースIDを元に、処理時間などの情報を記録・収集します。 ワークショップの内容 ワークショップの内容は主に以下の通りです APMデータを収集するためにDatadog Agentを設定する RubyのアプリケーションにAPMを構成する PythonのアプリケーションにAPMを構成する Datadogを使ったアプリケーションのデバッグ ボトルネックを特定する 最適でないSQLクエリの検出する アラート設定を追加する 継続的プロファイリング ダイナミックインスツルメンテーションによるオブザーバビリティの向上 今まで知らなかった機能の中で「これいいな！」と思ったものがダイナミックインスツルメンテーションの プローブ機能 です。 プローブを使用すると、 プログラムの実行を停止することなく、コード内の特定のポイントからデータを収集する ことができます。イメージとしてはアプリケーションを止めずにデバッグできる感じです。またプローブの設定をするためにリリースする必要はないため、不具合調査のためにどうしてもこのポイントのデータをみたい！という時にコード内にログを仕込んでリリースする...などという手間がなくなります。 ただし現時点(2024/11/22現在)でダイナミックインスツルメンテーションのサポートはPython、Java、.NET、PHP で構築されたアプリケーションに限定されているなど、環境の制限があることに注意です。 docs.datadoghq.com 余談 ご飯 イベントではなんと朝昼夕の３食が提供されました！ 朝食はパンやハム、チーズに加えてフルーツも盛りだくさん 朝ごはん食べると頭がシャキッとしますね！ 夜は懇親会 他社の方とSRE文化についてお話したりと有意義な時間を過ごすことができました。 立食形式で他社の方と気軽に交流することができました Datadogのマスコットキャラクター「Bits」のチーズケーキ 可愛すぎて食べるのが勿体無い。。。(※３つ食べました) ワンコ好きにはたまらん可愛さ AWS GameDay お昼休みはAWS GameDayのスピードランに挑戦しました。 課題としてAWS LamdaとDatadogを連携したオンラインストアのアプリケーションが用意されており、設定のミスや問題点を見つけて修正していくという流れでした。 普段AWS Lamdaを使うことがないので解けるか心配でしたが、チームでも参加できましたしDatadogの方がサポートでついてくれていたので楽しく取り組むことができました！ Datadog認定プログラムを新たに資格取得支援制度の対象へ レバレジーズのスキルアップ支援制度の一つに 資格取得支援制度 があります。これは業務遂行に必要・有益な資格について、 受験費用や年間登録料、更新手数料を会社が補助してくれる制度 です。 Datadogの認定プログラムは元々支援対象に入っていませんでしたが、Datadog Summit Tokyoの中で認定プログラムの紹介があったこともあり、業務に有益であると考えて追加申請を行いました。その結果無事に支援対象に追加されたため、 Datadogのスキルアップの一環として認定プログラム受験がしやすくなりました！ まとめ Datadog Summit Tokyoは想像以上に色々な情報を得ることができて有意義なカンファレンスでした。Datadogって色々な機能があるけど全然使いこなせていないな、、、という意識から、 監視ツールとしての機能はもちろん、部門の壁を破壊するプラットフォーム としての役割を果たしてくれる協力なツールであるということに気がつきました。 特にダッシュボードを活用したデータの可視化は非常に有用であると感じたため、今後チームでも取り組もうと考えています。他にも今回は触れていませんがSRE文化の醸成に関するセッションなども非常に興味深く、どのセッションも学びのある有意義なものでした。ぜひ次回の開催にも参加したいです！ レバレジーズにはエンジニアのスキルアップを支援する様々な制度があり、またそれを活用して様々な挑戦を楽しむ開発メンバーがたくさんいます！ そういったメンバーと一緒に仕事をしたい方はぜひエントリーお願いします！ recruit.leverages.jp
8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベントのみならず、共催イベントの開催、イベント登壇と多様な関わり方で、合計6件のイベントに参加しました！ 主催・共催技術イベント TSKaigiサブイベント #1 フロントエンド 8/6に、弊社の拠点である渋谷一丁目支店のセミナールームで、TSKaigi運営チームが開催する定期イベントの開催をしました。「フロントエンド」をテーマとし、TSKaigi2024の選考委員でもある”うひょさん”にトークを行っていただきました。 SREの組織と文化 9/6に、コミューン社、 弁護士ドットコム社の方を招いて、「SRE組織と文化」がテーマのLTイベントを開催しました。各社のSREが、実際に業務でどのようにSRE文化の浸透と醸成を行ってきたのか、赤裸々にお話ししていただきました。 Tech-Debt Meetup ～技術的負債と向き合うLT Night～ 9/12に、渋谷スクランブルスクエアにある弊社の本社にて、「技術的負債との向き合い方」がテーマのLTイベントを開催しました。 OPTiM × レバテック ビジネス価値を追求する開発生産性 9/4に、OPTiM社とレバテックの共催でLTイベントを開催しました。OPTiMとレバテックでの 開発生産性の向上の具体的な取り組みについて発表しました。 イベント登壇 SRE MeetUp レバテック開発部の金澤が、SRE MeetUpにて登壇しました。 speakerdeck.com DevRel Guild Conference Mini レバテックのDevRelメンバーの山本が、DevRel Guild Conference Miniに登壇しました。 speakerdeck.com イベントスポンサー SRE NEXT 2024 シルバースポンサー 8/3に行われたSRE NEXT 2024にて、レバテック株式会社がシルバースポンサーとして協賛しました。 We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。
自己紹介 レバレジーズのテクノロジー戦略室、AI/MLチームで二週間の就業型サマーインターンシップに参加した、早稲田大学創造理工学部経営システム工学科3年の住井と、慶應義塾大学理工学部情報工学科3年の小山です。 インターンシップの内容 僕たちは、 NALYSYS というツールの問い合わせ機能を充実させるため、以下の二つのプロダクトを作成しました。 QAbot QAbotの精度評価基盤. 作業を二人で分担することにし、QAbotのアプリ面の開発を住井、内部のRAGの精度向上・評価、QAbotの精度評価基盤の作成を小山が担当しました。メンターの方からいくつかのテーマを提示していただき、その中から我々の興味と能力に合わせて選択しました。 一日の流れは、以下の通りでした。 Good&New チーム朝会 作業 ランチ 作業 1on1 Good&Newはチームを跨いだアイスブレイクのようなもので、他チームの方と接する機会の一つでした。また、毎日1on1を実施していただいたので、相談もしやすく、サクラステージ内にある別オフィスの見学だったり、スクランブルスクエア内の本社での作業日を設けるといったような気軽な要望もスピード感を持って取り入れてくださいました。 技術スタック 今回は以下の技術スタックを使用しました。 QAbot フロントエンド React(Typesript) バックエンド Python インフラ AWS UI TailwindCSS IaCツール Terraform 評価基盤 フロントエンド streamlit バックエンド Python インフラ AWS QAbotのアーキテクチャ図は以下の通りです。 難しかったこと 触れたことない技術 NALYSYSの既存の技術スタックに合わせるため、今まで触れたことのない技術をいくつか使うことになりました。具体的には、React、Terraform、AWS Kendra、AWS Amplifyなどです。 特にTerraformは複雑で、最初は理解するのに苦労しました。しかし、最後の追い上げでなんとか形にすることができました。 これらの技術はReactやTerraformをはじめ、どれも現在多くのアーキテクチャで採用されているものです。今回のインターンシップはこれらの技術を学び始めるとても良いきっかけになりました。 RAGの精度と応答時間 今回は、精度も重視していたため、HyDE（Hypothetical Document Embeddings)、RAG-Fusion、Rerank、といった手法で精度改善を比較検討しました。しかし、実際にRerankやクエリ拡張、クエリ変換を処理に挟むと応答時間が増えることでUXの低下が著しく、精度向上とのトレードオフに悩まされました。シビアにUXを考える体験は、個人開発との違いを大きく感じました。 精度評価 実際にプロダクトに組み込むにあたり、一定の精度を担保する必要があったため、精度評価と精度改善に取り組みました。しかし、課題に着手した時点でNALYSYSには、評価に使用できるようなQA集が存在しませんでした。そのため、質を担保しつつ、評価用のQAを新たに作成する必要が生じました。 この課題に対し、単に現状の問題を解決するだけでなく、将来的な展開も見据えた解決策として、今後の機能拡張時や他サービスでのQAbot導入時にも活用できる、自動で評価用データセットの作成からRAGの評価まで行うツールを開発しました。 また、QAbotの評価の仕方自体も前例が少なく、難しい点でした。今回のRAGでは、プロダクトのヘルプページの内容を参照するようにしていたので、この時、特定のソースからQAを生成することで、自動生成のQAにGround Truthを与え、検索性能を評価しました。また、RAGの出力が「正確な回答」「一部不正確」「回答できていない」「間違った情報を含む」、のどれに相当するかを複数のLLM（GPT-4o, Claude)で評価し、スコアをAveragingすることで回答生成の評価を行いました。 社内・AI/MLチームの雰囲気 インターンシップの期間中は毎日出社しました。メンターの方とのコミュニケーションを密に取りながら作業を進めることができ、会社全体やAI/MLチームの実際の雰囲気を直接体験することができました。エンジニアは、ストレスフリーな環境で、チームの方も和やかで、非常に質問しやすいオーラを放っていました。 テクノロジー戦略室の室長の竹下さんは常にバランスボールに乗って作業しているくらいには自由でした。エンジニアのフロアであっても、和気藹々とした雰囲気があり、居心地が良かったです。 こういった環境のおかげでインターンシップでの学びを最大化することができたと感じています。 ランチ ランチは、毎日別のチームの方に連れて行っていただき、渋谷のランチに詳しくなれた気がします。最終日ランチは宮下パークの筋肉食堂でした。フルリモートのインターンも多い中、出社してランチの機会があったことで会社の生の雰囲気が良く感じ取れた気がします。 AI/MLチームの社員の方は多種多様な企業から転職して来ており、前職のお話や、前職と今の違いだったりも聞く機会もありました。 一つのインターンシップで単なる技術的な学び以上の発見もあり、ランチタイムに感謝。 終わってみての感想 インターンシップ期間中に一定のまとまった成果物を完成させることができたのは、大きな自信につながりました。また、この10日間でいくつもの新たな技術に触れ、自分の技術スタックが増えるきっかけになりました。今回支えてくださった社員とメンターの方々、本当にありがとうございました！ レバレジーズのエンジニアがどういった働き方をしているのかだったり、実際の雰囲気を感じ取れるインターンシップでしたので、興味のある方はぜひ応募してみてください！！ レバレジーズ 2027卒新卒 エンジニアサマーインターン 応募フォーム recruit.leverages.jp
はじめに こんにちは、今年(2024年)の7月からレバレジーズにJoinした藤咲です。 私はこれまで「AgileでVUCAの時代をHappyに！」をモットーに、様々な開発チームにコーチングしてきました。 ですので、レバレジーズの「顧客の創造を通じて関係者全員の幸福を追求し、 各個人の成長を促す」という企業理念に非常に共感できました。 またグループ会社であるレバテックでは、 昨年設立されたCTO室 がAgile開発推進の役割も担うため、そこの所属となりました。 まだJoinしてから2ヶ月半というタイミングではありますが、レバレジーズでのAgile浸透へのFirst Stepについてご紹介します。 はじめに Agile CoP、はじめました。 Agile CoPを作ろう！と声をかけたら40人も集まったが、、、 Agile CoPをAgileに運営する なんちゃってAgile開発からの脱却を目指す今後の取り組み Agile CoP、はじめました。 レバレジーズではAgile開発に取り組んでいるものの、なかなか浸透しない上に効果がイマイチわからないという声が上がっていました。実際に各開発チームの進め方を見ていると、自信をもってスクラムをやっているチームと、なんとなく用語を使っているだけのチームが混在していました。 そこで、まずはAgile CoPというコミュニティを作ることで、組織内での知見を共有することから始めることにしました。 弊社におけるAgile CoP（CoP: Community of Practice）の位置付け Agile CoPを作ろう！と声をかけたら40人も集まったが、、、 まずは私自身が発起人となり、レバテックを含むレバレジーズグループの開発者全体に向けてAgile CoPを作ろうとをSlackで投げかけると、全体の約20%にあたる40名もの方が参加意思を示してくれました。 そしてKickOffを実施したところ、多くの方がAgile開発の実践経験者であることがわかりました。 ところが、皆さんの自己紹介を聞いていると、 「なんちゃってAgile開発」 「Agileっぽい開発」 「Agile開発と呼んでいた何か」 という表現が非常に多かったんです。 つまり、Agile開発を実践してはいるけれども、今自分たちがやっている開発を自信を持ってAgile開発だと言えない状況であるということがわかりました。 例えば、 スクラムで開発している（？）けれどもスクラムマスターはいない スプリント単位にインクリメントの価値を高められていない 事業部を巻き込めておらず開発チームだけで回している といったように。（まぁ、Agileあるあると言えばそうですが。） Agile CoPをAgileに運営する 現状は把握できたので、どうすればAgile CoPの活動を通して「自信を持ってAgile開発を実践している」と言える状態にできるか、を次に考える必要があります。 これは今や常套手段でもありますが、弊社ではコミュニティ活動自体をAgileに進める、という方法をとっています。 具体的には、最低限以下のルールで運営を開始しました。 週に1回30分のセッションを開催（1週間のイテレーション） テーマは悩みや相談ごとをメンバーが持ち寄り（バックログ） 各回の終わりに次回のテーマを1つのみ決める（WIP制限：1） 進め方自体の改善提案も常にWelcome（ふりかえり） みんなが主役！（マインドセット） 管理はAsanaボードで！（チケットドリブン） Agile CoPタスクボード（Asana） なんちゃってAgile開発からの脱却を目指す今後の取り組み まだまだ立ち上がったばかりでご覧の通りバックログも積み上がっていない状態ですが、千里の道も一歩から、ということでスモールにスタートを切っています。 各チームの悩みやうまくいかいない状況に対して、コミュニティでの活動を通して解決のヒントや糸口を掴み、自ら改善していく。そんなメンバーが集まるコミュニティを目指し今後も活動していきます。 一方で、コミュニティ内だけでは解決しきれない課題というのが既にいくつか散見されています。 具体的には、 スクラムマスターを目指せるキャリアパスやポジションがない 事業部を巻き込んだ形での推進体制が作れていない といった、組織の制度や体制に関わる問題です。 そこはCTO室として動かなければならない領域でもあるので、コミュニティと経営をつなぐ立場として、中長期的な対応にもチャレンジしていきます。 レバレジーズの開発メンバーのみんなは、より良い実践をしていきたいというマインドは既に十分に持っています！ そういった前向きなメンバーと一緒にチャレンジしたいという方、ぜひ私たちとHappyに働いてみませんか？ recruit.leverages.jp
はじめに こんにちは。今年の4月にレバレジーズ株式会社に入社しました古川修慈です。 本記事では 8/8(木) に開催されたテックフェスという社内イベントの様子をご紹介します。 BuySell Technologie社CTOの今村氏による基調講演や、レバレジーズグループが持つ技術的な課題とその解決方法を紹介するセッション、事業部の垣根を越えて楽しくゲームをする様子を紹介するので、ぜひ最後までご覧ください。 テックフェスとは レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われているイベントです。一日を通して、技術的な課題解決事例やノウハウを共有したり、トレンドの技術を解説することで、社内の全てのエンジニアの技術力を伸ばすことを目指します。 今年の夏は、「次代をつくる」という意味を込めて、「Let’s Hack Leverages 〜そして伝説へ〜」というテーマで開催しました。 基調講演 今回はBuySell Technologie社CTOの今村氏に「CTO視点で語る、これからの時代に活躍するエンジニア像について」というテーマでお話していただきました。 登壇者紹介 今村雅幸 氏 株式会社BuySell Technologies 取締役CTO 一般社団法人 日本CTO協会 理事 ファインディ株式会社 社外取締役 株式会社イベンターノート代表取締役 投資先 技術顧問 ヤフーに新卒エンジニアとして入社後、新規事業や特許取得に追従。独立しVASILYを起業後、取締役CTOとして200万人以上が利用するファッションアプリの開発をリードする。M&AでZOZOへ売却後は、ZOZO（旧ZOZOテクノロジーズ）に執行役員VPoEを経てCTOへ就任。ZOZOTOWNリプレイスや400人を超えるエンジニアの採用・教育、情報システム、セキュリティなど幅広くDXを推進する。その後、BuySell Technologiesの取締役CTO就任。全社のテクノロジー戦略や研究開発、エンジニアリング組織マネジメントなどテックカンパニー化を推進する。 コンテンツ 「素晴らしいエンジニア」の定義から始まり、それがどのような要素から構成されるかを公演していただきました。参加されていたみなさんは今村氏のお話に一気に引き込まれているようでした。 その後に、具体的にどう素晴らしいエンジニアになるかを語っていただきました。圧倒的なインプットというすぐ業務に活かせるものから、技術トレンドを抑えるというキャッチアップ的なものまで、さまざまなTipsを紹介してくださいました。 マクロな視点で個人的に印象に残った言葉が「結局事業貢献を作るためには、自分達が良いと思う文化を作っていく必要がある」です。もしそれができれば、事業貢献が生まれ、新たに良い文化が生まれるというサイクルが生まれる、という点も教えていただきました。 セッション 発表者のみなさん、ありがとうございました。 JestランタイムをHackしてCIの実行速度を3倍にした話 (レバレジーズ NALYSYSグループ 桐生 直輝さん) 「APIが遅い」という問題に対処するために、 Jestのソースコードを読み、原因を突き止める Jestの制約を掻い潜って高速化する の順序で発表をしてもらいました。 単純な事例だけでなく、Jestのソースコードを読むコツや、一見意味がわからないエラーの原因を突き止めるための方法も紹介していただきました。 生産性改善を徹底的に考え、実践してみた (レバレジーズ アジャイルエフェクトチーム 西 慎一郎さん) 自分のチームで実際に取り組んだ生産性改善の具体的なTipsとツールを紹介してもらいました。 具体的には、Miro、 Cursor、Gamma などを用いたメソッドを共有してくれました。 「0から作ることを極力やめる」という信念のもと、AIといった最新の技術から、USMやモププロなど一般的なプラクティスまで広く取り入れていた点が印象的でした。 LT 発表者のみなさんありがとうございました。 今回はNALSYSチームから多くの方が発表がありました。 5分という短い時間でしたが、課題から解決策までわかりやすくまとめた発表が多かったです。 以下全てのタイトルと発表者です。 大量ユーザーへのSlack通知を実現せよ (レバレジーズ NALYSYSグループ 岡本 侑樹さん) 競艇自動予想アプリつくってみた (レバレジーズ CXグループ 田上 達也さん) AgileでVUCAの時代をHappyに！ (レバレジーズ CTO室 藤咲 浩さん) FEテストの技術選定 (レバレジーズ NALYSYSグループ 松本 悠太郎さん) GCP小話 (レバレジーズ NALYSYSグループ 香川 淳さん) ムダヅモなきテスト戦略 (レバレジーズ NALYSYSグループ 下畑 剣一郎さん) テックバトル 参加されたみなさんありがとうございました。 テックバトルでは運営チームが作った技術用語の百人一首を行いました。経験度合いに左右されず楽しめる内容だったため、大いに盛り上がりました。 懇親会 写真を取ろうと思っていたのですが、盛り上がりすぎてうっかり忘れてしまいました。 技術のことからプライベートのことまで、事業を横断して幅広い交流が生まれていました。 最後に 今回の記事では、テックフェスのレポートを書かせていただきました。LTという短時間の発表とは思えないほど内容が濃く、セッションではまさに事業部のナレッジが凝縮されていました。基調講演では、エンジニアとしての生き方を考えることができました。 レバレジーズは、社内で技術ノウハウの共有を行なうイベントはもちろん、外部から著名な方をお呼びして貴重な話を聞く機会を積極的に設けています。 レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。 recruit.leverages.jp
7月中に、レバレジーズが関わった技術イベントのご紹介です。 今月は、イベントへのスポンサーと登壇をメインに7件ありました。 イベントブース出展 Developer eXperience Day 2024 CTO協会が主催しているイベントで、レバテックがゴールドスポンサーとして協賛しました。ブースも出店し、七夕が近かったので「レバテックに願いを」という、エンジニアの願いを短冊に書いてもらう企画も行いました。数多くの登壇者、参加者の方に書いて貰い、大盛況でした。お書きくださった皆様、ありがとうございます。 Platform Engineering Kaigi 2024 こちらもゴールドスポンサーとして協賛し、ブースの出展をしてきました。こちらも、「レバテックに願い」を実施し大盛況でした。 イベント登壇 Developer eXperience Day 2024: 経営層を開発者体験向上にコミットさせる方法論 ~ Developer eXperience Day 2024 ~ TiDB User Day 2024: TiDBは銀の弾丸になるのか？ ~ レバテックの課題と新たな挑戦 ~ TiDB User Day 2024 Platform Engineering Kaigi 2024: いつPlatform Engineeringを始めるべきか？〜レバテックのケーススタディ〜 Platform Engineering Kaigi 2024 Developers Summit 2024 Summer: 開発と事業を繋ぐ！SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~ D-Plus Tokyo #4: ~しくじり事例から学ぶ！開発生産性の取り組みLT会~ FourKeysだけで開発生産性 は測れないと気付くまでの話 おまけ 【レバテック開発部に聞いた】ITエンジニアにおすすめの本18選！ という記事も公開しています。良ければこちらの記事もお読みください。 We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、 こちらのページ からご応募ください。
はじめに レバレジーズシステム本部 NALYSYSグループ テックリードの桐生です。 NALYSYSとは、ピープルマネジメントを支援する「 NALYSYSモチベーション管理 」や労務業務を効率化する「 NALYSYS労務管理 」などの機能を多数持った、人事労務に関わる課題を解決するためのSaaSです。 そんなNALYSYSでは、 今年4月に新たに「NALYSYS従業員ライブラリ」をリリースいたしました 。こちらのプロダクトではマイクロサービスを跨いだ検索を実現する必要があったのですが、これにより今までにない設計上やパフォーマンス面の問題に直面し、また短い納期の中でこの問題を解決する必要がありました。 今回の記事では、これらの問題をNetflixの事例を参考に爆速で解決に導いた取り組みをご紹介いたします。 NALYSYS 従業員ライブラリについて 現在のNALYSYSは、「NALYSYS Admin」に登録された従業員の基本情報を中心として、それにぶら下がる形で「NALYSYSモチベーション管理」や「NALYSYS労務管理」などに追加の情報を保持しています。同じ従業員の情報であっても分野ごとに異なるプロダクトに保存されているため、これらのデータを活用するには複数のプロダクトを行き来する必要があり、ユーザーにとって不便な状態となっていました。 これを解決するために企画されたサービスが NALYSYS従業員ライブラリ です。 従業員ライブラリが新たにNALYSYSに加わることで、複数のプロダクトに分散している情報を集約して閲覧することができ、プロダクトをまたいだ従業員の検索も行うことができるようになります。 全プロダクトのデータを集約するという性質上、権限やパフォーマンスに関して今までにない課題に直面することとなりました。また、今回は企画立案〜リリースまでが3ヶ月という短いスケジュールだったため、その期間で実現可能な方法を選ぶ必要がありました。 本記事では、直面したさまざまな課題の中から「プロダクト横断検索」に関わる部分をピックアップしてお届けします。 マイクロサービス間検索における課題 NALYSYSのバックエンドではマイクロサービスアーキテクチャを採用しており、それぞれのマイクロサービスごとに独立したデータベースを持っています。（マイクロサービスアーキテクチャでは各サービスの独立デプロイ可能性を確保するためにデータベースを分離する必要があります）このため、マイクロサービスを跨いだ検索を行おうとすると、検索に利用したいデータが複数のデータベースに分散しているという点が問題となります。具体的には、愚直に検索を実装する場合、複数のマイクロサービスに対してそれぞれデータ取得操作を行なった後、それらを集約して検索結果を構築する必要があります。特に、特定のマイクロサービスに関する検索条件がゆるい場合には大量のデータをロード・転送しなければならないため、データ量に対してスケールしにくくなってしまいます。実際に既存のプロダクトでも在籍状況+プロダクト固有の情報で検索する場合などに同様の問題に直面し、パフォーマンスが低下していました。 今回は、この問題を根本的に解決するため、単一の検索用データベースに全てのサービスのデータを集約することとしました。具体的には、以下のNetflixの事例を参考に、マイクロサービス間に分散したデータをElasticsearchに集約してインデックス化し、横断的な検索を実現します。 netflixtechblog.com 検索システムの構成 構築した検索システムの概要を以下に示します。 先ほど紹介したNetflixの事例と同様、Elasticsearchの検索インデックスに各サービスからかき集めた従業員の情報を合成して登録していきます。実際にユーザーが検索リクエストを送った際には、従業員ライブラリのマイクロサービスがそれをElasticsearch用の検索クエリに変換して検索を実行します。検索処理は全てElasticsearch内で完結し、DBのスキャンが必要ないため高速な検索処理を実現することができました。 インデックスの更新方法について Elasticsearchに登録されている従業員データは元々のサービスからコピーされたものであるため、元のデータが更新された場合これを随時インデックスに反映していく必要があります。 先ほどのNetflixの事例では、各マイクロサービスが送出するデータ更新イベントをトリガーにしてElasticsearchへのデータ再登録を行うという手法をとっていました。Netflixのシステムでは元々Kafkaに変更イベントを送出する仕組みが整っていたため、このような手法を少ない労力で実装できたようです。 一方、NALYSYSにはNetflixで行われているような変更イベントを流す仕組みがありませんでした。マイクロサービス間を疎結合にするという観点で、Netflixと同様にメッセージベースのやり取りを実装するのが望ましくはあったのですが、開発期間が短い中でそのような仕組みを設計・構築する余裕がなかったため、今回は代わりにLogstashのJDBC Input Pluginを活用した変更検知を実装しています。 JDBC Input Pluginを用いると、データベースに対して定期的にクエリを発行し、データの差分を取り込むことができます。以下の公式ブログに詳しい実装方法が説明されています。 www.elastic.co この方法を用いる場合、Logstashのデプロイおよび必要な設定ファイルの作成を行うだけでインデックスの自動更新を実装することができるため、自前で更新のための仕組み(差分イベント送出・検知)を実装するのに比べて大きく工数を削減することができます。一方で、各サービスのデータベースの構造とLogstashの設定ファイルが密結合になるためメンテナンス性が低下するという問題も抱えています。今回は短納期を実現するために必要な負債としてこれを受け入れることとしました。 まとめ ここまで述べた取り組みによって、高速な横断検索機能を予定期間内に作り上げることができました。今回は従業員ライブラリに特化した仕組みとなってしまったので、今後は他のプロダクトにもこの仕組みを展開しつつ、メッセージベースの変更検知によってサービス間の結合度を下げる取り組みも行っていきたいと考えています。 レバレジーズでは、ソフトウェアの力で人事労務に関わる課題解決に挑戦する仲間を募集しています！ご興味のある方はぜひ 採用サイト をご覧ください！
6月中に、レバレジーズが関わった技術イベントのご紹介です。 自社開催から、共催、スポンサー、運営の手伝いと多様な関わり方で、合計5件のイベントに参加しています！ 主催・共催技術イベント イベントグループ「Tech Leverages」始動 イベント開催プラットフォームのconnpassにて、 Tech Leverages グループをリニューアルしました。今後弊社で開催するイベントはこちらで公開していきますので、興味がある方はグループ登録をお願いします。 渋谷一丁目支店・初技術イベント: Agile Effect MeetUp なんちゃってスクラム開発からの脱却 6/27に、弊社の新しい拠点である渋谷一丁目支店のセミナールームで、 Agile Effect MeetUp を開催しました。スクラムマスターの服部 翔太氏や、株式会社aby CTO 向後 澄哉氏にご参加いただき、パネルディスカッションを行いました。 イベントブース出展 AWS Summit 2024 ブース出展 & ミニセッション登壇 6/20,6/21に幕張メッセで開催された AWS Summit 2024 で、レバテックプラットフォームでのAmazon QuickSightの活用事例を紹介するブースを出展しました。 また、ミニステージにて、弊社エンジニアの塚原と内藤が、技術の詳細の発表も行って来ました。 イベント登壇 UX Design Conference 2024:『VoLT:レバテックのデザインシステム』電光石火の構築プロセスと目指す未来 弊社CTO室テックリードの河村とプロダクトとデザイン責任者の山本が、 UX Design Conference 2024で登壇 しました。 イベントスポンサー・手伝い 日本CTO協会 新卒合同研修 会場スポンサー 6/19に日本CTO協会様が実施されている合同新卒研修で、会場スポンサーとしてレバレジーズ本社のセミナールームを提供いたしました。今回の内容は「インテリアデザインを通したアジャイル開発の体験」で、グループワークを通してアジャイル開発がどのように進むかを疑似体験するというものでした。 ScalaMatsuri2024 運営スタッフとして手伝い 6/8,6/9に、国際交流館 プラザ平成で開催された ScalaMatsuri2024 に、弊社テクノロジー戦略室室長 竹下が運営スタッフとして開催を手伝ってきました。コロナ後初のフルリアル開催となり、日本中のScala使いが集結しました。 また、竹下が、酒を飲みながらLeetCodeを解くという「アルコーダー」の発表？を行ってきました。 We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、 こちらのページ からご応募ください。
はじめに こんにちは、レバレジーズ株式会社の檜垣・南です。本記事ではレバレジーズグループ全体のエンジニアが参加するテックフェスの様子をご紹介します。基調講演や、社員によるトークセッションなどについて書いていますので、ぜひ最後までご覧ください。 テックフェスとは レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われている技術の祭典です。エンジニアが新しい技術に興味を持ち、勉強をするきっかけを作ることを目的とし、グループ全体の技術力向上を目指します。2月14日に「速さと質の次へ～史上最速でコアコンピタンスを高める組織～」というテーマでテックフェス2024冬を開催しました。 AWS AWSソリューションアーキテクチャの苅野 秀和氏に「AWS を使って価値提供 に集中しよう」というテーマで特別セッションをしていただきました。AWSのサービスに限定せず、AISASフレームワークを使った戦略の考え方などを発表していただきました。また、求人検索のパーソナライズやBedrockを利用した営業活動支援の最適化など、人材業界でのユースケースも紹介していただきました。人材業界にサービスを多く展開するレバレジーズのエンジニアにとって、コアコンピタンスを見つけるきっかけになったのではないかと思います。 アジェンダ AWSを用いたデータ活用 High value & low riskの探索 Personalize Bedrock 人材業界でのユースケース 開発者とAWS セキュリティ CodeCatalyst 基調講演 徳丸浩氏に「今どきのウェブアプリでは脆弱性はどのように発現するのか?」という題名で、現在のアプリケーションにおいて脆弱性がどのように発現するのか、Teratail他のネットの記事のコードを参照しつつ解説していただきました。 登壇者紹介 徳丸浩 氏 EGセキュアソリューションズ株式会社 取締役CTO イー・ガーディアン株式会社 CISO 独立行政法人情報処理推進機構（IPA）非常勤研究員 技術士（情報工学部門） 著書: 「 体系的に学ぶ 安全なWebアプリケーションの作り方脆弱性が生まれる原理と対策の実践（ソフトバンククリエイティブ） 」 1985年京セラ株式会社に入社後、ソフトウェアの開発、企画に従事。1999年に携帯電話向け認証課金基盤の方式設計を担当したことをきっかけにWebアプリケーションのセキュリティに興味を持つ。2004年同分野を事業化。 2008年独立して、Webアプリケーションセキュリティを専門分野とするHASHコンサルティング株式会社（現EGセキュアソリューションズ株式会社）を設立。 脆弱性診断やコンサルティング業務のかたわら、ブログや勉強会などを通じてセキュリティの啓蒙活動をおこなっている。 2023年イー・ガーディアングループのCISOに就任。セキュリティレベル向上だけでなく、活動を通して得たノウハウをサービスやセミナーコンテンツにも還元し、広くセキュリティの啓蒙活動に邁進。 アジェンダ アプリケーションフレームワークと脆弱性対策 フレームワークとSQLインジェクション Teratailの質問から LaravelでSQLインジェクション脆弱にする フレームワークとクロスサイトスクリプティング(XSS) LaravelでXSSが発生するケース ReactのようなSPAフレームワークの場合 SPAとCORS(Cross-Origin Resource Sharing) フレームワークと認可制御 セッション 発表してくださった皆さんありがとうございました。 最優秀の発表について 大規模なORMバージョンアップ作業を乗り越えた話 (レバレジーズ NALYSYSグループ 桐生 直輝さん) speakerdeck.com 概要 大きめの破壊的アップデータがあったTypeORM 0.2 -> 0.3 移行について ts-morph を用いたコードの自動置き換え 移行用ライブラリによる漸進的な移行 自動テストを活用した影響調査 の順序でお話し頂きました。 自作の移行用ライブラリを作成し、徐々に0.2 から 0.3に変更を進めて、 1人月+レビュー工数でアップデート作業を終えられていました。 LT 発表一覧 発表してくださった皆さんありがとうございました。 最優秀の発表について 桃栗3年、レコメンドエンジン5年 (レバレジーズ データ戦略室 阪上 晃幸さん) speakerdeck.com 概要 レコメンドアルゴリズムのリプレイスについて 黎明期 データ戦略室の発足時から将来を見据えて着工 事業部長への提案〜アルゴリズム開発 挫折期 Covid-19がレコメンド プロジェクトを襲う やり直し期 全く新しい観点でアルゴリズムを開発 新体制 アルゴリズムに足りていなかった現場の意見を反映し、使えるものに 熟成期 可用性を高め、LTSF実装に繋げていく1年 離陸期 LTSFの内部でレコメンとAPIを使ってもらう の順序でお話し頂きました。 懇親会 テックフェス終了後は、懇親会も開催。ピザやお寿司、おにぎりを食べながら発表者へ話を聞きに行ったり、他チームの方と交流を深めている様子が見られました。 運営メンバー打ち上げ 後日、運営メンバーで打ち上げに行きました。写真を撮ろうと思っていたのですが、話が盛り上がりすぎてすっかり忘れてしまいました。 最後に 今回の記事では、テックフェスのレポートを書かせていただきました。徳丸浩さんの貴重なお話を聞けたり、社内のエンジニアから普段は聞けない話を聞けて非常に面白かったです。 社内で技術ノウハウの共有を行なうイベントがあったり、外部から著名な方をお呼びして貴重な話が聞ける環境のレバレジーズで皆さんも一緒に働いてみませんか？ レバレジーズに少しでも興味を持っていただけた方は、以下のリンクからエントリーをお願いします！ recruit.leverages.jp
レバレジーズ株式会社 レバテック開発部の堀内です。 2024/05/29に、PharmaX社、ANDPAD社、弊社の3社による共催イベント「Frontend Night: App Router本番運用企業が語る！Next.js新機能活用法」が開催されました。 Next.jsのApp Routerを実際に本番運用している会社が集まり、App Routerを利用した開発において良かったことや工夫したことを発表しました。 私は『App Routerの開発で気をつけたいこと3選』というテーマで発表しましたので、そのスライドを共有します。 App Routerを利用したプロジェクトを通して、ハマったところや失敗したところがいくつかあったため、気をつけたほうがいいこととして3つ紹介させていただきました。 speakerdeck.com We are hiring 現在レバレジーズでは一緒に働いてくれる仲間を募集しています。 ご興味のある方は、以下のリンクからご応募ください。 recruit.leverages.jp
はじめに レバレジーズ株式会社 テクノロジー戦略室 SREチームの中野です。レバレジーズでは「SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、Embedded SREメンバーと協力しながら、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。 この記事では、開発体験を向上させるための取り組みとして、社内標準となるIaCツールの選定、IaC化の負荷軽減への取り組みについてご紹介します。具体的には、社内標準ツールの選定では決定に至るまでのプロセスや方法をご紹介し、IaC化の作業負荷の軽減への取り組みでは、全体最適を狙った下記のライブラリ・テンプレートの作成についてご紹介します。 Terraform Modules GitHub Composite Actions GitHub Repository Template また、この記事を通して、弊社の開発体験の向上における取り組みを知って頂くと共に、全社最適を狙ったIaC化の推進について是非ともご参考頂ければ幸いです。それでは、以下で背景を挟みつつ具体的な取り組みについてご紹介します。 背景 サービス開発体制のSRE化を進めやすくするために、インフラ構築・管理の省力化でIaC化を進めています。しかし、実際にはAWS CDK、AWS CloudFormation、Terraform等の複数のツールが利用されており、開発チーム・SREチームの双方において作業負荷がかかってしまっています。 実際、ツールの乱立により、開発チームではIaCツールの理解度・習熟度がバラついており、開発チーム間でのナレッジ・ノウハウの共有が困難だったりします。SREチームでも、開発チーム毎に異なるサポートが必要となり、サポート負荷が高くなりがちです。 この様な状況を解消するためには、ツールの乱立を最小限に抑え、IaC化を低負荷・低工数で進められる様にする必要があると考え、社内標準となるIaCツールの選定と、IaCツールやCI/CDにおけるライブラリ・テンプレートの作成を進めることになりました。 社内標準となるIaCツールの選定 ツール比較 まずは、社内標準となるIaCツールの比較から始めました。ツールの認知度・利用度の高さを考えてTerraform・AWS CDK・Pulumi・CDKTF・OpenTofuから比較し、Terraform・OpenTofuが最良の選択肢として残りました。理由は下表の通りです。 比較観点 評価理由 成熟度・カバー範囲 殆どのパブリッククラウドに対応しており、SaaSでも対応範囲が広い。 ツールの学習負荷 HCLはJSONライクで学習しやすく、リソース設定が宣言的で見通しが良い。 構築・変更の負荷 リソース設定が宣言的なため、クラウドサービスの構築・更新でコード変更とズレの無い状態差分で期待通りに適用出来る。 状態変更の容易性 import・moved・removed等のブロック設定により、ツールで管理される状態の追加・変更・削除をコードベースで容易に実施出来る。 GenAIとの相性 リソース設定が宣言的なため、簡単なプロンプトで一定以上のクオリティでサンプルコードを生成出来る。 リスク調査 ツール比較でTerraform・OpenTofuが最良の選択肢として残りましたが、今後IaC化を問題無く推進していくためにツールの将来的なリスクも考えておく必要があり、ライセンス変更によるTerraformの利用制限の可能性について調査しました。 ライセンスに関する公式情報によれば、Terraformの利用範囲は従来通りでリスクはありませんでした。実際、HashiCorpの競合製品においてはHashiCorp製品が埋め込まれていれば利用制限が発生しますが、社内/個人によるHashiCorp製品の利用においては制限は無いとのことでした。 一方で、OpenTofuは今後のツールとしての安定性・充実性が現時点では見込めなさそうなため、Terraformの方がより安定的でリスクが低いツールであると判断しました。 www.hashicorp.com www.hashicorp.com www.hashicorp.com 選定結果・例外 以上の比較・調査の結果を踏まえ、Terraform を社内標準ツールとして採用しました。今後はTerraformでIaC化を推進していく予定です。しかし、Terraformの導入・移行における費用対効果が必ずしも高く無いパターンもあり、下表を例外として規定しました。これらを考慮しながらIaC化を進めていきます。 例外パターン 対応方針 Terraformへのツール移行 他ツールで管理されているパブリッククラウドやSaaSでは、移行コストと改善効果性のバランスを考え、Terraformへの移行を検討する。 Terraformによるサポートが弱い部分へのIaC化 Terraformのサポートが未対応、またはサポート範囲が狭い部分では他ツールの利用を認める。 外部サービスの仕組みにおけるTerraformの導入 パブリッククラウドやSaaSで提供される仕組みにおいて、Terraform以外の手段で構築されている場合は、その手段の使用を認める。 一時的な利用のシステムへのTerraformの導入 プロトタイプや実験的な環境等の、一時的な利用が確実に見込まれる様なシステムでは、TerraformによるIaC化は強制しない。 ライブラリ・テンプレートの作成 次に、IaC化を低負荷・低工数で推進するために、IaCの移植性・再利用性等を高める様なプラクティスの検討を進めました。Terraformを利用している開発チームにヒアリングしたところ、下記の課題感が出てきました。 実装の際にクラウドサービスの仕様把握が必要で、実装における作業負荷が高い 宣言的な設定のため、リソースが多くなると設定管理における認知負荷が高まる Git RepositoryやCI/CDにおける社内標準の構成が無く、設計・初期作業で時間がかかる これらを解決するためには、Terraformにおける社内標準のライブラリ・テンプレートを作成する必要があると考え、Terraform Modules・GitHub Composite Actions・GitHub Repository Templateを全社向けに開発することになりました。 管理方針 SREチームがライブラリ・テンプレートをメンテナンスしていく予定のため、テクノロジー戦略室向けのGitHub Organizationの配下でライブラリ・テンプレートを管理することにしました。また、ローカルやCI/CDでライブラリを利用する際に、PATをベースとしたアクセス認証でライブラリをダウンロードする様にしました。 作成方針 Terraform Modules 全社最適のパターンとして、個々に依存しない手段を用いて全社最適を図るか、または個別最適の手段を組み合わせて全社最適を図るかの2種類が考えられ、そこからTerraform Modulesにおける次の構成方針を洗い出しました。 (1) 社内のサービス・システムに合わせたTerraform Modules (2) クラウドサービスのリソースに対応するTerraform Modules 検討の結果、(2)の方針でTerraform Modulesの構成を考えることにしました。実際、(1)の方針ではサービス・システム毎に特化したTerraform Modulesのため、極力少ない設定でインフラ構築・運用が可能です。しかし、サービス毎のシステム構成の変更に追従してTerraform Modulesをメンテナンスしていく必要があり、メンテナンス面で課題がありました。 一方、(2)の方針では、サービス・システムの個別の設定・構成に依存せずに全社に展開出来るため、メンテナンス面の課題は小さめでした。また、社内要件やクラウドサービスにより推奨される設定をベースとして作り込めば、インフラ構築・運用における作業負荷を軽減可能だと考えました。結果として、メンテナンス性・利用者の負荷軽減のバランスの取れた(2)の方針が最良となりました。 とは言え、単にクラウドサービス毎にTerraform Modulesを作ってしまうと、汎用性やメンテナンス性は高められるがサービス・システム毎の最適化には繋がらないため、次の2種類のTerraform Modulesを作成することにしました。 種別 説明 用途例 Component Modules クラウドサービスの単体のインフラリソースに対応するTerraform Modules ELB・ECS・EC2・RDS等のリソース毎にModulesで作成する Catalog Modules クラウドサービスの複数のインフラリソースに対応するTerraform Modules ELB・ECS、CloudFront・WAF等のリソース群をModulesで作成する また、社内のサービス・システムの構成パターンを考えたところ、AWSを利用しているものが大半であり、かつCloudFront・WAF・ELB・ECS・RDS・ElastiCacheを用いた構成が多いため、この様なAWSインフラ構成におけるComponent/Catalog Modulesの開発を優先的に進めることになりました。 GitHub Composite Actions 社内におけるCI/CDツールの利用状況や、CI/CDツールにおけるGitHub向けの連携機能の充実さを考慮し、GitHub Actionsを利用してTerraform CI/CDのパッケージを作成することにしました。 GitHub Actionsの処理共通化を調べると、Custom Actions、Composite Actions、Reusable Workflowsのいずれかを用いれば良いことが分かり、処理共通化が容易かどうか、下記を満たす形で運用が可能かどうかを考え、Composite Actionsを採用しました。 テクノロジー戦略室のOrganization、開発チームのOrganizationは別々である ライブラリ・テンプレートのRepositoryは、テクノロジー戦略室のOrganization管理下である ライブラリ・テンプレートのRepository、開発チーム向けのRepositoryはPrivateである GitHub Repository Template 大半の社内サービス・システムでAWSが利用されているため、Terraform・AWS用のGitHub Repository Templateを優先して作ることにしました。また、開発チームのGitHub Repositoryで最適と思われるものを基準にして、GitHub Repository Templateの構成を考えました。 Repositoryの生成・設定については、テンプレート内のコード・資料等をスクリプトで書き換える様な仕組みを導入し、テンプレートからTerraform用のRepositoryを低工数で設定出来る様にしました。 更に、Terraformの管理基盤を構築する際に、Repositoryの設定だけでなく下記の作業も対応する必要があり、下記における設定手順の資料やTerraformの設定ファイルをテンプレートに含め、Terraformの導入における初期作業を全体的に低工数で済む様にしました。 Slack通知の初期設定 通知チャンネルの作成 Webhook連携の設定 Terraformの初期設定 Terraform Backendの構築 CI/CD用のIAMロールの作成 CI/CDの設定作成・有効化 クラウドサービスの初期設定 月額予算アラートの設定 監査ログ、セキュリティ検知の設定 アラート通知の仕組みの構築 今後の活動 以上の様に、社内標準のIaCツールの選定と、IaCツールのライブラリ・テンプレートの作成を進めてきました。しかし、現状ではライブラリ・テンプレートにおける開発のルール・フローや全社展開・要望吸い上げの体制が整い切れていないため、今後はこれらを整備してIaC化を推進していく予定です。 また、現在はAWSを対象にIaCツールのライブラリ・テンプレートを作成していますが、今後はGoogle Cloud、Datadog、GitHub等のAWS以外のクラウドサービスも検討し、ライブラリ・テンプレートの対象範囲を広げていきたいとも考えています。 最後に レバレジーズでは、全社のSRE導入に向けて、サービス改善の文化的土俵の構築や開発生産性の向上のための取り組みを手伝って頂けるエンジニアを募集しています。 SREの文化・体制に興味があったり創っていきたい方や、これからフルスタックエンジニアになっていきたい方は、是非ともご応募をお待ちしております。
レバレジーズ株式会社 システム本部の檜垣です。 レバレジーズでは、2024/05/11に中野セントラルパークカンファレンスで開催された TSKaigi 2024 で最上位のプラチナスポンサーとしてスポンサーブースを出展しました。 レバレジーズでは、TypeScriptをフロントエンド、バックエンドで幅広く使っていることもあって、日頃の感謝を込めてTypeScriptのコミュニティへの貢献のためにプラチナスポンサーとして支援させていただきました。また、私も微力ながら運営スタッフとして開催をお手伝いしました。 ブース内容 TSKaigiに参加した皆様に楽しんでいただくために、ブースでは、「 スクラム開発のための業務効率化支援ツールの Agile Effect のデモ 」や「 レバ社員を探せ！くじ 」などを行いました。 ブースの様子 くじ 楽しく談笑中 agile-effectのデモの様子 記念撮影 たくさんの人に訪れていただき大盛況でした。 agile-effectのデモでは、大変気に入っていただきその場で契約していただいた会社様もいました。 ブースに来てくださった皆様ありがとうございました。 We are hiring レバレジーズ株式会社ではTypeScript大好きなエンジニアも、それ以外のエンジニアも幅広く募集中です。 もしご興味を持っていただけたなら、 こちらのページ からご応募ください。 recruit.leverages.jp
はじめに TSKaigiプラチナスポンサーであるレバレジーズ株式会社のテクノロジー戦略室室長 & 一般社団法人TSKaigi Association 代表理事 & TSKaigi2024 Speakerの竹下です。 TypeScriptの言語カンファレンスであるTSKaigi2024が5月11日(土)に中野セントラルパークで開催されました。基調講演にはMicrosoftのTypeScript Product ManagerであるDaniel Rosenwasser様を迎え、37名の登壇者、会場での参加者約400名、オンライン参加約2000名の、大規模イベントになりました。 この記事では、私がTSKaigiを立ち上げた経緯と、登壇者として発表してきた 「Step by Stepで学ぶ、ADT(代数的データ型)、モナドからEffect-TSまで」 について、紹介したいと思います。 TSKaigi とは TSKaigi は、TypeScriptをテーマにした、技術カンファレンスです。俗に言語カンファレンスと呼ばれる、特定のプログラミング言語を扱ったカンファレンスで、有名なものではRubyKaigiやPyCon、PHP Conference、ScalaMatsuriなどがあります。(ちなみに私はScalaMatsuriの開催にも理事として関わっていたりします) 運営は、私を含む理事4人を中心に、総勢45名ものボランティアスタッフによって行われました。 ここがすごかったよTSKaigi 初開催でいきなり2400名規模！ 技術カンファレンスとしては、日本でも大規模に分類されるイベントです。会場には約400名、オンラインで約2000名の方にご参加いただきました。TypeScriptのイベントとしては現時点で日本一の規模だと思います。初開催でノウハウがない状態から、大きなトラブルもなく無事にイベントを開催できたのは素晴らしいことで、運営を手伝ってくださったスタッフの方々の頑張りの賜物です。感謝の気持ちでいっぱいです。 基調講演 はMicrosoft TypeScriptのProductManagerのDaniel Rosenwasserlさん！ 言語の開発者というものは普段あまり意識しないかもしれませんが、DanielさんはTypeScript自体を長年にわたって開発してくださっている方です。また、JavaScriptの標準仕様を策定する団体であるTC39にも関わっておられます。TypeScriptやJavaScriptを使うエンジニアにとっては、足を向けて寝られない方です。そのDanielさんが、TSKaigiの 基調講演 を行ってくれました。 レバレジーズ株式会社を始め38社が協賛！ レバレジーズも最上位のプラチナスポンサーとして協賛しましたが、プラチナスポンサー、ゴールドスポンサー、シルバースポンサー、ブロンズスポンサーをはじめ、コーヒー、ビール、リフレッシュメント、イベントツールなどの特殊スポンサーを含め、合計38社に協賛していただきました。スポンサー募集期限後に開催を知って協賛できなかった企業様も多数おられたので、来年は周知を徹底し、TypeScriptを盛り上げてくださる企業様を増やしていきたいです。 立ち上げ経緯 コミュニティの盛り上がりが、人気に比例していない TypeScriptの人気はコロナ禍中にもどんどん高まり、開発者の数も増え、使用範囲もフロントエンドに留まらず、バックエンド、インフラ、AI/ML、IoTと非常に幅広くなっています。しかし、私個人の感想にはなりますが、TypeScriptといえばこの人という存在や、日本発のOSSライブラリは、人気や開発者数に対して少ないと感じていました。また、コミュニティ活動も行われている方は数多くおられましたが、その方々が大々的に知られる機会もあまり無いと感じていました。 コミュニティの核となるイベントを作る TypeScriptの言語カンファレンスは、コロナ禍前にTSConf JPが開催されていましたが、その後中断してしまい、日本では大規模なイベントが開催されていない状態でした。コミュニティが盛り上がらない原因として、コロナ禍も影響し、中核となるイベントやコミュニティがなく、交流の輪が広がっていかないことが挙げられます。 そのような状況の中で、TSKaigiを開催することで、TypeScript開発者に成果を発表してもらう場を提供するとともに、TypeScriptコミュニティの皆さんにどんな人がいて、どんな使い方をされているかを知ってもらう場を提供できると考えました。また、TSKaigiに参加してもらうことで交流が生まれ、そこから交流が続くことでTypeScriptコミュニティ全体の活性化につながると考えました。 団体としてコミュニティの活性化を継続 また、単発イベントではなく継続開催することが、TypeScriptコミュニティの継続した発展に繋がると考え、同時期に同じことを考えていた他の理事と共同で一般社団法人TSKaigi Associationも設立しています。来年以降の開催や、サブイベントの開催も行っていこうと思っていますので、是非この記事をお読みの皆さんご参加下さい。 登壇内容 また、賑やかしのためにセッションの応募したら当選していたので発表も行ってきました。以下が発表スライドです。 スライド おまけ この発表では、Effectの導入する意義に焦点を当てて解説していますが、実際の運用では一歩踏み込み、Effectによる関数の細粒度化と副作用分離によるアーキテクチャーレベルの設計も行っています。機会があればそちらも発表したいと思います。 おまけのおまけ 代表理事として、開幕の挨拶もしたのですが、演台の前からはなれて動きながら喋ってたら演台にもどれって怒られました(笑) オープニングトーク P.S. 書いててレバレジーズ株式会社のエンジニアとしてなのか、TSKaigiの代表理事としてなのかよくわからなくなってきて、ちょっと混乱した文章になっていますがご容赦下さい。また、TSKaigiの代表理事としての思いなどは、改めて TSKaigiのブログ で書きたいと思います。 We are hiring!!! レバレジーズ株式会社では一緒にサービスを開発してくれるエンジニアを幅広く募集中です。 TypeScriptで開発するだけでなく、コミュニティ貢献もしていきたいという人もウェルカムですし、TypeScriptに触ってないけど興味あるよという人もウェルカムです。 もしご興味ありましたら、 こちらのページ からご応募ください。
レバレジーズ株式会社 レバウェル開発部 SREの中村です。 2024/03/13に、設計をテーマに合同勉強会を開催しました。 領域を絞らずに発表いただいたことで、設計について幅広く知見を得られた勉強会になりました。 また、弊社が東京の渋谷に物理出社がメインで、ビザスク社がフルリモートということで Zoomを使用してオンラインでの開催になりました。 この記事では、弊社のエンジニアの発表内容を簡単にご紹介したいと思います。 発表内容 弊社からは、二人が発表しました。 テクノロジー戦略室 室長 竹下 speakerdeck.com EffectというTypeScriptのライブラリを活用して、IOに関する副作用を分離した設計を実現する方法について発表されています。また、その際にEffectを導入する利点についても紹介されています。 レバテック開発部ITSプロダクト開発グループ PdM兼テックリード 古庄 speakerdeck.com レバテックにて、新たに構築中のデザインシステム「VoLT」について発表されています。構築プロセス、システム設計や実装例について紹介されています。 We are hiring レバレジーズ株式会社ではどの領域のエンジニアも幅広く募集中です。 もし今回の勉強会の発表を見てご興味を持っていただけたなら、 こちらのページ からご応募ください。 勉強会の開催も随時受け付け中です 今回は設計をテーマに合同勉強会を開催しましたが、工程を絞ったものだけでなく、フロントエンド、バックエンド、インフラ、機械学習といったように、様々なテーマで弊社と合同勉強会を開催してくれる企業様を募集中です。ご興味ある企業様がいらっしゃいましたらご連絡いただけると嬉しいです。
DALL·Eで生成したLangChainのイメージ画像 LangChainの動作確認済みバージョン(2024/3/26時点では最新) langchain: 0.1.13 langchain-community: 0.0.29 langchain-openai: 0.1.0 langchain-google-vertexai: 0.1.1 はじめに テクノロジー戦略室 AI/MLエンジニアリングチームの稲垣です。 AI/MLエンジニアリングチームでは、レコメンドエンジンの MLOps 基盤の構築や、AWS Personalize などの ML サービスや LLM など生成 AI 活用を、企画から構築まで進めています。 今回は、LangChain の最新バージョン(2024/3/26時点)を使った複数モデルの実装方法について紹介します。 このような実装ニーズは良くあるかと思いますが、案外記事がまだ落ちていないようでしたので記事にしてみました。 現在、社内で LLM を使ったツール開発を行っており、LLM は以下のような複数ベンダー＆複数モデルの API を使用しています。 GPT-3.5-turbo, GPT-4 (Azure OpenAI Service) Gemini Pro (Google Cloud VertexAI) Claude 2, Claude3 (AWS Bedrock) それぞれのモデルに対して別個に実装していくことももちろん可能ですが、 API 入力/出力のフォーマット、良くある前処理や後処理、ストリーミングによる出力などの実装方法がモデルごとに異なるケースが多く、 それらを別個に実装していく手間はモデルの数が増えるほど大きくなっていきます。 （実際、 anthropic-sdk-python による Claude モデル実装と、 google-cloud-aiplatform による Gemini モデル実装は根本的な箇所でいくつか大きな差異があります。） このようなモデルごとの実装の差異を吸収してくれるライブラリとして LangChain があり、 社内ツールの実装でも LangChain を利用しています。 LangChain： github.com また、LangChain について最近の動向としては、 2024/1/6 にバージョン 0.0.354 から 0.1.0 へのアップデートがあり、LangChain 初の安定バージョンとなった、というニュースがありました。 (これ以前は破壊的な変更が頻繁に起こったり、公式ドキュメントのクイックスタートの内容が見るたびに変わっていたりしました、、、) ただし、この 0.1 系へのアップデートにより、LangChain のパッケージの構成について大きな変更があったため、この点についても後半で補足しつつ説明をしていきたいと思います。 複数 LLM の切り替え実装 先に補足事項を記載します。 チャットツール等のユースケースではストリーミングによる出力を行うケースが多いかと思いますが、その場合は別途 CallBack 関数を渡す実装が必要になるケースがあるため、今回はストリーミングをオフにしています。 詳細が気になる方は こちらのリンク 等が参考になります。 下記のコード例では分かりやすさ重視のためシークレット情報をベタ書きしています。（実際の自社のコードではシークレット情報は AWS Secrets Manager で管理しています。） AzureChatOpenAI 環境変数 AZURE_OPENAI_ENDPOINT と OPENAI_API_KEY に対しては、 Azure OpenAI Service から取得した値を設定しています。（ 参考 ） import os from langchain_openai import AzureChatOpenAI os.environ[ "AZURE_OPENAI_ENDPOINT" ] = https://xxxxxxxxxxxxxx.openai.azure.com/ os.environ[ "OPENAI_API_KEY" ] = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx os.environ[ "OPENAI_API_VERSION" ] = "2023-05-15" chat_model = AzureChatOpenAI( streaming= False , deployment_name= "gpt-4" , # 必要であれば # temperature=0.9, # model_kwargs={ # "top_p": 0.9, # }, ) ChatVertexAI Google Cloud への認証は下記２種類の方法があります。（ 参考 ） gcloud や workload identity により実行環境に認証情報を紐づける方法 認証情報の json ファイルの格納パスを環境変数 GOOGLE_APPLICATION_CREDENTIALS に設定する方法 今回は後者の方法で実装を行いました。 認証情報の json ファイルの作成方法は こちらのリンク が参考になります。 import os from langchain_google_vertexai import ( ChatVertexAI, HarmBlockThreshold, HarmCategory, ) # 環境変数に認証情報が入った json ファイルのパスを設定 os.environ[ "GOOGLE_APPLICATION_CREDENTIALS" ] = "./credential_file_name.json" chat_model = ChatVertexAI( model_name= "gemini-1.0-pro" , streaming= False , # Geminiはシステムプロンプトに対応していないため、システムプロンプトを入れる場合はここをTrueにする convert_system_message_to_human= True , # 適宜要件に合わせて設定してください。今回はブロックが起こりにくい設定(BLOCK_ONLY_HIGH)にしています safety_settings={ HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, }, # 必要であれば # temperature=0.9, # top_k=0.9, # top_p=32, ) BedrockChat Amazon Bedrock へのアクセス権限を持つ IAM ロールが付与された環境で実行するか、 アクセスキー ID とシークレットアクセスキーを環境変数に設定して実行してください。 from boto3.session import Session from langchain_community.chat_models import BedrockChat BEDROCK_REGION = "ap-northeast-1" session = Session() bedrock_runtime = session.client( "bedrock-runtime" , region_name=BEDROCK_REGION) chat_model = BedrockChat( streaming= False , client=bedrock_runtime, model_id= "anthropic.claude-v2:1" , # 必要であれば # model_kwargs={"temperature": 0.1, "top_p": 0.9, "top_k": 250}, ) チャットモデルから出力を受け取る from langchain.schema import ( AIMessage, HumanMessage, SystemMessage, ) messages = [ SystemMessage( content= "あなたは江戸時代から続く老舗寿司屋の職人です。質問に対してぶっきらぼうに回答してください。" ), HumanMessage(content= "オススメの寿司ネタは？" ), AIMessage(content= "まぁ、季節によるな。今なら鯖が旨い。" ), HumanMessage(content= "その理由は？" ), ] response = chat_model.invoke(messages) print (response.content) # > 鯖はこの時期に脂がのって味が濃くなるんだよ。 やっていることとしては、 使用したい LLM が指定できるクラス AzureChatOpenAI , ChatVertexAI , BedrockChat をそれぞれ import し、それらのクラスのインスタンス化の際に必要な引数や環境変数を設定すれば OK です。 ここまで出来れば、後はモデルごとの実装方法の差異を LangChain がうまく隠蔽してくれるため、 API の入力/出力のフォーマット 良くある前処理や後処理 ストリーミング時の処理 などを共通化することができ、LangChain の恩恵を受けることができます。 また、パッケージのインストールについての補足事項としては、 LangChain のバージョン 0.1 系へのアップデートに従い、LLM の外部プロバイダーとの統合部分の処理は langchain パッケージから langchain_community パッケージもしくは独立した新パッケージに分離がなされました。 こちらは LangChain 公式の以下の記事でも紹介されています。 blog.langchain.dev Specifically we made two large architectural changes: separating out langchain-core and separating out partner packages (either into langchain-community or standalone partner packages) from langchain. (意訳)： 具体的には、大きな構造変更を二つ行いました：langchain-core パッケージの分離と、パートナーパッケージの langchain からの分離（langchain-community パッケージに組み込むか、独立したパートナーパッケージとして分離）です。 そのため、上記のコードでは、 AzureChatOpenAI : langchain_openai からインポート ChatVertexAI : langchain_google_vertexai からインポート BedrockChat : langchain_community からインポート としています。 ※ 補足： 0.1 系へのバージョンアップでは後方互換性が担保されているので、例えば ChatVertexAI であれば以下でも import が可能です。 from langchain.chat_models.vertexai import ChatVertexAI from langchain_community.chat_models.vertexai import ChatVertexAI ただし非推奨の warning が出るので、上述のとおり適切なパッケージからの import をおすすめします。 おまけ： AzureChatOpenAI , ChatVertexAI , BedrockChat とも BaseChatModel というクラスのサブクラスになっています。 そして BaseChatModel は langchain_core パッケージに実装されているため、 ここからも LangChain のコア機能は langchain や langchain_core で開発し、外部プロバイダーに依存する機能は langchain_community や独自パッケージで開発する、という意図が汲み取れます。 まとめ LangChain を使った複数 LLM の実装を紹介しました。 レバレジーズでは MLOps 基盤や ML 活用を企画から考え構築までやりたいエンジニアを募集しています！ ご興味のある方はぜひ 採用サイト をご覧ください！
はじめに レバレジーズ株式会社 レバウェル開発部 バックエンドチームサブリーダーの山口です。 総合転職サービス「レバウェル」は 転職アドバイザー（転職エージェント） スカウトサービス 求人サイト を1つのサービスで利用できるアプリケーションです。 2024年2月よりCMを放送することとなり、 このマス広告を打つために、広告効果によって増加するユーザーとその負荷に耐えることができるかの検討と対策を行いました。 本記事では、私たちがどのような視点で速度改善に取り組んだのか、そしてその結果として 特定のAPIの処理速度を82倍向上させた経緯 をご紹介します。 はじめに レバウェルについて 技術スタック 導入済みの性能対策 ISR(Incremental Static Regeneration) DataLoader 増加するユーザーとその負荷に耐えられるか 速度改善の必要性はどう判断する？ API実行頻度の見積もり 性能目標 どこを改善する？ 主要機能の分析 API実行量の観測 負荷テストによる速度調査 どうやって改善する？ どういったSQLが実行されているか Slow Queryはあるのか 改善方針決定 実装 100件のSQLを1つのSQLにまとめる 補足 nullハンドリング 設計方針 対策後の計測 API処理速度の検証 おわりに レバウェルについて はじめにレバウェルの基本情報と今回取り組む課題の背景について簡単にご説明します。 技術スタック 今回の内容に関係するレバウェルの技術スタックをご紹介します。 言語 TypeScript フレームワーク Next.js, NestJS ライブラリ Apollo Server インフラストラクチャ AWS(ECS, RDS) Vercel API規格 GraphQL 導入済みの性能対策 ISR(Incremental Static Regeneration) レバウェルでは初期リリース時に ISR(Incremental Static Regeneration) を採用しました。 対象はSEOの観点で重要かつリアルタイム性が高くないページです。 これによりアプリ全体を再ビルドすることなくデータの変化を定期的にページに反映することができます。 DataLoader GraphQLはクライアントが必要とするデータを必要な分だけ一度に取得できるという強みがあります。 しかしその一方で、データを取得する際にN+1問題というパフォーマンスに関する問題も抱えがちです。今回はN+1問題に関する詳細な説明は省略しますが、この問題を解決するためにDataLoaderを導入しています。 DataLoaderを用いて各リレーションごとのバッチ処理を行い、 SQLの実行回数を削減 しています。 増加するユーザーとその負荷に耐えられるか webアプリケーションにおいて表示速度は離脱率と密接な関係にあり、性能を評価する上で重要な指標となります。 どんなにコンテンツが素晴らしくとも、表示速度が遅いと見てもらうことすらできません。 参考： https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/ マス広告を打つということは、必然的にユーザー数が短期間で増加します。 この負荷によって性能が悪化すると、ユーザーにプロダクトの価値を提供することができなくなってしまいます。 そのような事態を防ぐべく、速度改善の必要性を判断し、必要な対策を講じることとしました。 速度改善の必要性はどう判断する？ 速度改善の必要性があるかどうかの判断基準として以下を定めました。 予想されるAPI実行頻度において性能目標を達成しているか これを判断するために、以下の２点を定義する必要があります。 予想されるAPI実行頻度 性能目標 これらの数値に基づいて負荷テストを行い、実行結果が性能目標を満たしていなければ速度改善の必要があると判断することができます。 API実行頻度の見積もり 今回はマス広告の効果によるリクエスト数の増加を考慮する必要があります。 実際の計算の流れは以下の通りです。 *1 とある集計期間における１分間あたりのリクエストレート（単位：RPM）が 5 RPM であった時について考える。 1時間あたりのリクエスト数は以下で表すことができる。 TotalRPH = RPM * 60 つまり 300 RPH となる。 また、集計期間におけるログインユーザー数が50人だった時、 ログインしていないユーザー数をX人とする。 このとき、一人当たりに発生する１時間のリクエスト数は RPH-per-person = TotalRPH / (50 + X) と表すことができる。 ただし、今回はより余裕を持った対策を行いたいため、ログインユーザーを分母としてリクエスト数を計算することとする。 つまり一人当たりに発生する１時間のリクエスト数は RPH-per-person = TotalRPH / 50 となり 6 RPH となる。 この時、広告の掲載によって大量のユーザー増加が見込まれる場合について考える。 TVCMを放映した場合、「CMを認知してもらう」という目的では個人全体視聴率でおよそ500GRPが目安とされている。 *2 GRP500の場合3000万人前後に視聴されるというシミュレーション結果があるため、本検証でもこの数値を使用する。 *3 次にCTRが仮に0.2%だとすると約6万人前後がTVCM放映期間中に流入することになる。 TVCM放映期間がスポットCMの契約最短期間である一週間と仮定すると、 1時間当たりの新規流入数 = 60000 / (24 x 7) ≒ 357 増加するリクエスト数(毎分) = (RPH-per-person * 357) / 60 と表すことができる。 この結果 35.7 RPM となる。 既存のリクエストレートと合算し、性能を担保をすべき最低限のリクエスト数は 41.7 RPM ≒ 0.7 RPS となる。 性能目標 今回レバウェルでは、以下のことから改善対象APIを p95 1秒以下でレスポンスする ことを性能目標として定めました。 主要機能を改善対象とする(後述) 本サイトにメディア的性質がある SEO要件からより速い描画速度が求められる API実行レートはTVCM配信後に波のようなスパイクが来ることを想定し、見積もりよりかなり余裕を持たせて 5 RPS でテストすることにします。 どこを改善する？ 主要機能の分析 さて、ここまでで速度改善の必要性を判断するための基準は準備できました。 次にやるべきことは、その基準に基づいて必要性の可否を判断することです。 速度改善の取り組みは時間がかかることが予想されるため、全ての機能について改善することは費用対効果的によろしくありません。 そこでレバウェルでは、まずAPIの実行量を観測し、速度改善に値するものを抽出することにしました。 API実行量の観測 今回は Apollo Studio のAPI統計情報から最も実行されているGraphQL Operationを探しました。 Insightsから統計情報を確認します。 リクエストレートを確認してみると、上位２つが多く実行されていることがわかります。 対応する画面を確認したところレバウェルの中核となる部分と対応しており、システム的にこれらの二つが主要機能と言えます。 本記事では最もレートが高かったリクエスト名をtarget(仮)、 それに対応するAPI名をgetTargetInfo(仮)として説明します。 負荷テストによる速度調査 特定した画面およびAPIについて速度改善の必要性があるかを判断します。 判断基準は決定しているため、そちらに従って負荷テストを行います。テストランナーはk6を使用します。 まず先ほど特定したリクエストレートの高いGraphQL Operationを使用している画面について試験を行います。 対象画面を含めた合計４つの画面に仮想ユーザー数100で繰り返しアクセスすることとします。 http_req_duration(p95)が12秒超という非常によろしくない結果です。 次にバックエンドサーバーに対し、画面で要求しているフィールドと全く同一な状態でAPIを実行します。 getTargetInfo(仮)を5 RPSで実行した結果 avg=7.44s min=430.08ms med=8.62s max=9.73s p(90)=9.47s p(95)=9.53s これはp95 1秒以下でレスポンスするという性能目標を満たしていないため、改善する必要があると判断しました。 どうやって改善する？ 基本的なwebアプリケーションであればSQLが最もボトルネックになりやすい箇所です。 そのためまずSQLに注目することにしました。 以下の流れに従って調査します。 1. ボトルネックとなっているSQLを見つける. 2. そのSQLが遅い原因を理解する. 3. 改善する. 4. 改善したSQLを測定する. どういったSQLが実行されているか 対象のAPIを実行した時、どのようなSQLが実行されるのかをチェックします。 ここで明らかな問題（N+1問題や初歩的なWHEREでの絞り忘れなど）があれば、まずはそれを解決できるからです。 今回は以下のようなテーブル構成とGraphQLのqueryを例とします。 query target($getTagetInfoId: Int!) { getTagetInfo(id: $getTagetInfoId) { id name status targetSkills { skillId level skill{ id name } } } } targetテーブルに連なるリレーションはTypeORMのLazy Relationsによって解決します。 この場合、要求されたリレーションのフィールド１つにつき１件のSQLが実行されます。 この例の場合、以下のように少なくとも3回実行されるイメージです。 1. 指定されたIDを持つターゲット情報を取得する。 これはgetTagetInfoフィールドに対応します。 SELECT * FROM target WHERE id = $ 1 ; 2. そのターゲットに関連するtargetSkillsを取得する。 これはtargetSkillsフィールドに対応します。 SELECT * FROM target_skills WHERE target_id = $ 1 ; 3. 各targetSkillsエントリに関連するskillを取得する。 これはskillフィールドに対応します。 targetSkillsの各エントリに対して1つのクエリが実行されるため、このステップでのクエリ数はtargetSkillsのエントリ数に依存します。 SELECT * FROM skills WHERE id = $ 1 ; 実際にレバウェルの該当ページを開いてGraphQLリクエストを発生させたところ、およそ100件を超えるSQLが実行されていました。 これ自体はGraphQLの設計思想上、「要求されたものだけを取得する」ということで間違っていません。また、前述(導入済みの性能対策)の通りDataLoaderを用いた各リレーションごとのバッチ処理は行っています。 しかし該当ページは描画要件の都合により、取得しなければならないフィールドが多く、DataLoaderによる性能改善には限界がありました。 約100テーブルに及ぶ膨大なリレーション情報が必要となると、データ解決手法によってはパフォーマンス問題が発生する恐れがあります。 またコネクションプールの枯渇、ネットワークコストの増加による負荷増の問題も考えられます。 Slow Queryはあるのか 次にSlow Queryがあるかを調査します。 仮に実行時間の大半を占めるようなSlow Queryがあり、それを解消すれば良いなら100件のSQLを実行する形のままでも目下の障害にはならないからです。 今回はpostgresのpg_stat_statementsモジュールを使って分析しました。 対象APIを呼ぶページを開き、以下のSQLでSlow Queryを抽出します SELECT * FROM pg_stat_statements order by total_time desc limit 100 ; 今回は個別のクエリは軽いようで、 一番かかっているもので26msほどでした。 これはindexや個別のSQL最適化が意味をなさず、 100件の分割されたクエリを何らかの方法でまとめなければならない ことを意味しています。 改善方針決定 次は100件のSQLを1つのSQLにまとめるなら、どのようにすれば良いのか考えます。 もちろん単純に100テーブルをJOINしてしまうと結果セットがデカルト積となり、爆発的な量となってしまうので実現不可能です。 そこで今回は以下の点に注目しました。 それぞれのSQLには複雑な条件がない。単純な外部キー結合がメイン 結果セットの多さが問題 ここから考えられる対処法には以下の２つがあると考えました。 1. テーブル設計を変える 2. SQL上のテクニックで結果セットの数を削減する 1の方法は最も高品質なものができる解決法ですが、今回対象となるテーブルはレバウェルの根本となっているため、リプレイスに近い形になってしまうことから見送りました。2の方法はあまり見ない方法ですが、今回のケースではJSONB_AGG集約関数とJSONB_BUILD_OBJECT関数を用いることで結果セットを減らせそうです。 一方でSQLが複雑なものとなり保守性が低下してしまうのがデメリットです。 今回はメリット・デメリットを総合的に判断し ２の方法を採用 することにしました。 実装 100件のSQLを1つのSQLにまとめる 結果セット数を抑えつつ100件のSQLを１つにまとめるために、大きく４つのSQLの文法を使用しました。 Common Table Expressions postgresではWITH ASの構文で表されます。一時的な名前付き結果セット、つまりサブクエリの結果を生成するために使用されます。主な利点は、複雑なクエリをより読みやすくかつ管理しやすくすることです。また、同じサブクエリを一度書いてそれを再利用することができます。 参考： https://www.postgresql.jp/docs/9.5/queries-with.html LATERAL LATERALを付与したサブクエリはそれより前のFROM項目を参照できるようになります。今回はLEFT JOIN LATERALの形で使用しました。これによってサブクエリが外部クエリの行に依存する場合に、それぞれの行に対して異なる結果セットを生成できます。そして、LEFT JOINの性質上サブクエリが結果を返さない場合、nullとして処理されます。 参考： https://www.postgresql.jp/document/9.6/html/queries-table-expressions.html JSONB_BUILD_OBJECT キーと値のペアからJSONBオブジェクトを作成するための関数です。この関数は任意の数の引数を取り、それらを交互にキーと値として扱います。行のデータをJSON形式で出力する必要がある場合など、データを柔軟に扱いたい時に便利です。 参考： https://www.postgresql.jp/document/13/html/functions-json.html JSONB_AGG 引数を受け取り、JSONB配列に集約する関数です。 参考： https://www.postgresql.jp/docs/9.5/functions-aggregate.html 詳細な内容はPostgreSQL公式をご参考ください。 実装SQLはこのような形になります。 WITH r_target AS ( SELECT * FROM target t WHERE t.id = $ 1 AND t.status = ' active ' ), s AS ( SELECT ts.target_id, JSONB_AGG( JSONB_BUILD_OBJECT( ' skill ' , s.obj, ' level ' , ts. level ) ) as target_skills_info FROM target_skills ts INNER JOIN LATERAL( SELECT JSONB_BUILD_OBJECT( ' id ' , s.id, ' name ' , s.name ) AS obj FROM skill s WHERE s.id = ts.skill_id ) s ON true WHERE ts.target_id = ( SELECT id FROM r_target) GROUP BY ts.target_id ) SELECT * FROM r_target LEFT JOIN s ON s.target_id = r_target.id 実行結果イメージ id name status target_id target_skills_info 1 hoge active 1 [{‘skill’: {‘id’: 1 ,‘name’: ‘skill1’}, ‘level’: 5}, … ] 実際には上記の対応を全てのリレーションに適用し、そのSQLを用いることで効果の検証を行います。 補足 nullハンドリング 上述のSQLでLATERALを使用した理由としてネストしたオブジェクトのnullハンドリングがあります。 例えば、 -- v.hogeは存在しない SELECT JSONB_BUILD_OBJECT( ' v_id ' , v.id, ' hoge ' , JSONB_BUILD_OBJECT( ' name ' , h.name) ) FROM v LEFT JOIN hoge h ON h.id = v.hoge_id この結果は{v_id: x, hoge: {name: null}} となります。 この時に、GraphQLで「v.hogeはnullableだが、hoge.nameはnot nullable」のような設定をしている場合は少々困ってしまいます。 そのため以下のようにしてnullハンドリングを行いました。 -- v.hogeは存在しない SELECT JSONB_BUILD_OBJECT( ' v_id ' , v.id, ' hoge ' , h.obj ) FROM v LEFT JOIN LATERAL( SELECT JSONB_BUILD_OBJECT( ' name ' , h.name) AS obj FROM hoge h WHERE h.id = v.hoge_id ) AS h ON true LATERALを使用することで、サブクエリが各vの行に対して独立して評価されます。そしてLEFT JOINであるため、 h.id = v.hoge_id を満たさない場合はobjがnullとして結合されます。 従って {v_id: x, hoge: null} となり、一般的にイメージされるnullableなオブジェクトになります。 設計方針 今回選択した手法はGraphQLの大きな強みである「不要なデータフェッチを防ぐ」にやや反するものとなっています。 つまりGraphQLとSQLが分離できておらず、オーバーフェッチが発生し得る設計となっています。 その上で本方針を選択した理由として以下があります。 該当APIの使用目的が限定されており、実際にはオーバーフェッチが発生しない 工数の都合によりEager Loading的な設計を選択せざるを得なかった プロダクト全体としてはLazy Loadingを使用し「クライアントが必要とするデータを必要な分だけ取得する」という設計方針で実装されています。 対策後の計測 API処理速度の検証 対策の効果を検証するため、上記のSQLを適用した新しいAPIに対して負荷テストを行います。 条件は前回と同様に5 RPS, 同一要求フィールド、同一のレコードです。 avg=59.98ms min=36.26ms med=50.89ms max=201.09ms p(90)=96.25ms p(95)=115.55ms 以前の結果 avg=7.44s min=430.08ms med=8.62s max=9.73s p(90)=9.47s p(95)=9.53s レスポンスタイム(p95)で約82倍の高速化に成功しており、かなり改善をすることができました。 おわりに 以上がレバウェルにおける速度改善の取り組みとなります。 このような性能改善の取り組みは、コストなどの兼ね合いから最も理想的な改善策を選択できないこともあると思います。 しかしながら、 状況に応じて最適な対策を打つことで高い効果を得ること ができます。 本記事が少しでも参考となれば幸いです！ 最後までお読みいただきありがとうございました。 現在、私たちと一緒に社会課題に挑戦するエンジニアを募集中です！ ご興味のある方はぜひ 採用サイト をご覧ください！ *1 : 実際に使用したリクエストレートなどの数値は計測値を使用しています。 今回は説明の都合上、仮の値を使用しています。 *2 : GRPとは「Gross Rating Point（グロス・レイティング・ポイント）」の略語 一定期間に放送されたテレビCMの視聴率を合計したもの≒何回視聴されるか *3 : 500GRPもしくは1,000GRPのCM出稿をしたら、何人に見られるのか？