はじめに こんにちは、レバレジーズテクノロジー戦略室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

はじめに こんにちは！レバレジーズで”NALYSYS年末調整”という年末調整クラウドのPdMを担当している稲村です。 はじめに この記事に書かれていること この記事を読むとわかること PdMになって起きたこと 予期せぬ事態と怒涛のキャッチアップ コミュニケーションの大切さを痛感 「なんちゃってスクラム」からの脱却 QAで発覚した問題とチームの力 PMFへの不安と営業活動への挑戦 リリース直後の障害発生と冷静な対応 想定外の事態とコミュニケーション責任 まとめ 弊社にご興味のある方へ この記事に書かれていること 未経験からPdMに挑戦し、1年間でどのような経験をしたのか 予期せぬトラブルや困難にどのように対応してきたのか チームメンバーと協力して、どのようにプロダクトをリリースまで導いたのか PdMとして働く上で重要だと感じたスキルとは何か この記事を読むとわかること PdMの仕事内容や役割について PdMとして成長するために必要なスキルやマインドセット チームビルディングやコミュニケーションの重要性 困難な状況を乗り越えるための考え方 元々フロントエンドエンジニアとして働いていましたが、日々の業務にマンネリを感じ始めていました。「このまま同じ仕事を続けていて良いのだろうか？」という漠然とした不安を抱えていた矢先、社内でPdMの募集が始まり、上司から「PdMとしてやってみないか？」と声をかけていただきました。元々、新しいことに挑戦するのが好きで、好奇心旺盛な性格の私にとって、PdMという未知の領域への挑戦はまさに渡りに船。少しだけ考えましたが二つ返事で引き受けることにしました。 PdMになって起きたこと 予期せぬ事態と怒涛のキャッチアップ PdMとしてのキャリアは、シニアPdMの指導の下、育成枠として半年から1年かけてじっくり学ぶという計画でした。しかし、そのシニアPdMが突然退職することに…。引き継ぎ期間は、なんと1ヶ月。「1ヶ月でキャッチアップしてくれ」と言われ、目の前が真っ暗になる思いでした。右も左も分からない状態でのスタートに、不安と焦りで押しつぶされそうになりました。 幸い、前職でディレクター経験があったおかげで、業務の全体像や進め方についてはある程度の知識がありました。また、エンジニアとして培ってきた技術的知識や、持ち前のコミュニケーション能力も大きな武器となりました。実際にPdM業務を始めてみると、これが想像以上に楽しい！チームを動かし、ものづくりの中心にいるという実感を得ることができ、不安はすぐに楽しさへと変わりました。自分がチームを動かし、プロダクトを形作っていくというダイナミックな仕事に、すっかり魅了されました。 コミュニケーションの大切さを痛感 順調に進んでいると思っていた矢先、思わぬ落とし穴が。何気ない一言で、チームメンバーのモチベーションを下げてしまうというコミュニケーションミスを起こしてしまいました。メンバー全員が責任感を持って仕事に取り組んでいるからこそ、相手の立場に立った丁寧なコミュニケーションが不可欠だと痛感しました。すぐにメンバーに謝罪し、個別に話を聞くことで、信頼関係を再構築することができました。この経験を通して、言葉の重みを改めて認識し、コミュニケーションの重要性を深く心に刻みました。 「なんちゃってスクラム」からの脱却 チーム体制にも課題を感じていました。なんとなくスクラムを回している「なんちゃってスクラム」の状態であり、チーム全体としてプロダクトの完成度や現状の進捗状況を正確に把握できていないように感じていました。「どうすればもっと良いチームになるのか？」と悩んでいた時に、会社の福利厚生で認定スクラムマスターの講座を受講できることを知りました。PdMとスクラムマスターの役割は違いますが、チーム改善への強い思いから受講を決意。資格取得後、チーム体制を抜本的に見直すことにしました。 本来世間的にはPdMとスクラムマスターは相反する職なので、兼任することは好まれていません。しかし人員不足といった現実的な問題などから兼任せざるを得ない状況も多数あると思っています。私の場合も同様でした。 具体的には、スプリント内でリリースした機能を全員でテストし、Goodポイント/改善ポイント/不具合を洗い出すレビュー会を導入。レトロスペクティブには「感謝のコーナー」を設け、日頃伝えられない感謝の気持ちを共有することで、チームの心理的安全性を高めました。KPTでは作業効率や生産性の向上に焦点を当て、具体的な改善策を検討。例えば「仕様の認識ずれ」という問題に対しては、朝会後に仕様確認MTGを10分追加する、デザインレビューはテキストではなくモブワークで30分以内にまとめて行うなど、試行錯誤を繰り返しながら、チームにとって最適な方法を探し続けました。 QAで発覚した問題とチームの力 開発はスケジュール通りに進んでいると思っていましたが、QA開始後に予期せぬ問題が発生。「バグの発生速度が想定より速く、このままではリリースに間に合わない」とQAチームから報告を受け、頭が真っ白になりました。スクラム開発でレビュー会を実施し、クリティカルなバグは都度修正していたので、想定外の事態でした。 すぐにバグの状況把握とスケジュール見直しに着手。場合によってはスコープ変更も検討しましたが、開発メンバーと協力してバグの整理と詳細確認を行い、改修作業も並行して取り組みました。チームメンバーの献身的な努力のおかげで、なんとかスケジュール通りに開発を進めることができました。この時ほど、チームの力を感じたことはありません。 PMFへの不安と営業活動への挑戦 9月頃、PdMとしての自分の現状に疑問を抱くようになりました。PMF（プロダクトマーケットフィット）やKPI/KGIといった目標達成に向けた行動ができていないと感じたのです。年末調整というプロダクトの性質上、PDCAサイクルを回せるのは基本的に年に1回。少ない機会の中で効果的な仮説検証を積み重ね、顧客ニーズを深く理解する必要がありました。 そこで、営業チームと連携し、自ら電話営業を実施することにしました。慣れない電話営業に戸惑いながらも、営業チームと共に電話営業スクリプトを作成し、効果的な訴求方法を検証。また、商談にも同席し、顧客の生の声を聞き、競合との差別化ポイントを分析しました。これらの活動を通して、机上の空論ではなく、顧客の真のニーズを把握することができ、「本当に売れるのか？」という不安を払拭することができました。 リリース直後の障害発生と冷静な対応 満を持してリリース！…しかし、開始30分で障害が発生。「まさか…」という思いが頭をよぎりました。社員数4,000人規模の導入というプレッシャーの中でのリリースだっただけに、焦りは隠せません。「動作が重い」という報告が多数寄せられ、DBのスケーリングに問題があることが判明。幸い、事前にチームメンバーの提案で「不具合対応シミュレーション」を実施していたおかげで、冷静さを保ち、迅速に問題に対処することができました。チームメンバーの先見の明に、心から感謝しました。 想定外の事態とコミュニケーション責任 リリース後も、想定外の指摘や質問が多数寄せられました。全てに対応することは不可能なので、ミッション・ビジョンと工数を考慮し、重要度と緊急度の軸で対応の優先順位を決定。対応できないものについては、PdMとしての責任を持って丁寧に説明を行いました。この過程で、様々なユーザーの利用状況やニーズを改めて認識することができ、今後のプロダクト開発に活かせる貴重な学びを得ることができました。 まとめ この1年は、まさに怒涛の1年でした。シニアPdMの退職、予期せぬ障害、次々と発生する課題…。精神的にも肉体的にも辛い時期もありましたが、チームメンバーの支えがあったからこそ、乗り越えることができました。チームで協力し、困難を乗り越えていく中で、チームとしての結束力も高まり、大きな達成感を共有することができました。この経験は、私にとってかけがえのない財産となるでしょう。 また、レバレジーズでPdMとして働く上で、下記の点が非常に良かったと感じています。 温かいサポート : 周囲のメンバーは皆優しく、失敗に対しても寛容です。もちろん、失敗しないように最善を尽くすべきですが、どうしても発生してしまう障害に対して、部長や事業部長が前向きに一緒に対応してくれたことは本当に心強かったです。リリース前の不安を相談した際には、「最悪一緒に土下座しに行くよ。土下座は得意。」と言っていただき、気持ちがかなり楽になりました。 チャレンジを推奨する文化 : 必要なことであれば、割と何でもやらせてくれる環境です。もちろん費用対効果は考慮する必要がありますが、顧客ニーズを深く理解するために、PdM自ら電話営業を実施したいと提案した際も、最初は「PdMがやる必要ある？」という反応でしたが、自分なりのロジックを説明することで、最終的に承認を得ることができました。 優秀な開発チーム : 開発チームには優秀なエンジニアが多く、障害発生時も迅速に原因を特定し、対応策を提示してくれます。メンバー全員が協力的で、高い技術力とチームワークで、困難な状況も乗り越えることができました。 この経験を通して、PdMとして働く上で特に重要だと感じたスキルを3つ紹介します。もちろん、PdMに必要なスキルは多岐に渡りますが、私自身の経験から、これらは特に重要だと感じています。 コミュニケーション能力 : PdMは、開発チーム、営業チーム、マーケティングチーム、そして顧客など、様々なステークホルダーと関わりながら必ず説明責任を求められます。そのため、それぞれの立場を理解し、円滑なコミュニケーションを取ることが不可欠です。相手の意図を正確に汲み取り、自分の考えを分かりやすく伝える能力、そして時には厳しいフィードバックを伝えながらも、良好な関係性を維持していく能力が求められます。 調査能力 : 市場動向、競合分析、ユーザーニーズ調査など、PdMは常に情報を収集し、分析する必要があります。データを読み解く分析力はもちろんのこと、ユーザーインタビューなどを通して、データには表れない潜在的なニーズを汲み取る洞察力も重要です。これらの情報を元に、プロダクトの価値を最大化するための戦略を立案していく必要があります。 チームビルディング/リーダーシップ : PdMは、開発チームをまとめ、プロダクト開発を推進していくリーダーシップが求められます。メンバーのモチベーションを高く維持し、チーム全体のパフォーマンスを最大化するためには、それぞれの個性や強みを理解し、適切な役割分担や目標設定を行う必要があります。また、困難な状況に直面した際に、チームを鼓舞し、前進させる力も重要です。 PdMという仕事は、常に変化と挑戦の連続です。しかし、それ以上にやりがいのある、魅力的な仕事だと感じています。これからも成長を続け、より良いプロダクトを生み出していきたいと思っています。 弊社にご興味のある方へ レバレジーズでは、一緒に働く仲間を募集しています！ 少しでも興味を持っていただけたら、ぜひカジュアル面談にご応募ください！ カジュアル面談はこちらから hrmos.co 採用サイト では、より詳しい情報をご覧いただけます。 recruit.leverages.jp

はじめに こんにちは。NALYSYS開発部の部長を務めている山下と申します。 本記事では、私たちが開発している NALYSYS （ナリシス）というプロダクトと、それを支える開発部の様子や魅力をお伝えします。 はじめに 対象読者 この記事を読むとわかること NALYSYSとは？ 日本が抱える社会問題 NALYSYS（ナリシス）とは NALYSYSのプロダクトラインナップと今後の展望 NALYSYS開発チームに迫る 技術スタック 開発手法 チーム構成・開発体制 製販一体の開発 ワークスタイル・雰囲気 キャリアパス やりがい 終わりに 対象読者 レバレジーズの開発組織に興味のある方 HRテック領域のプロダクト開発に関心がある方 事業会社でのSaaS開発に携わりたい方 この記事を読むとわかること NALYSYSの魅力 プロダクトの特徴 事業フェーズの面白さ NALYSYS開発部の魅力 職能横断的な開発 多様なキャリアパス NALYSYSとは？ 日本が抱える社会問題 日本の労働人口は、1995年頃の8,000万人をピークに減少し続けており、2070年には5,000万人にまで減少すると予測されています。 *1 この労働力の減少に対する解決策の一つとして、労働生産性の向上が求められています。 NALYSYS（ナリシス）とは NALYSYSは、「従業員一人当たりの生産性向上」という課題に対し、個々のELTV（従業員生涯価値）を最大化することで生産性向上に貢献します。 ELTVの最大化は、従業員の定着率向上、早期戦力化、パフォーマンス向上に繋がり、結果として生産性向上を実現します。 具体的には、従業員のライフサイクル全体で体験価値を向上させ、より長く活躍できる環境を提供します。 例えば、 離職リスクの高い社員を検知し、適切なフォローを行うことで優秀な人材の流出を防ぐ 最適な組織配置をサポートし、スキルや適性に応じた配置を実現することでパフォーマンスを最大化 人材のモチベーションを可視化し、エンゲージメントを高めることで定着率向上 労務手続きの効率化による負担軽減で生産性向上 NALYSYSのプロダクトラインナップと今後の展望 現時点では以下のプロダクトラインナップとなっています。 NALYSYS モチベーション管理 NALYSYS 従業員ライブラリ NALYSYS 適性検査 NALYSYS 労務管理 NALYSYS 年末調整 NALYSYS Admin 昨年ローンチし、現在顧客拡大中です。並行して新たなプロダクト開発も進行中で、0→1、1→10といったさまざまなフェーズを経験できる、非常に面白いタイミングです。 今後は、前述の世界観実現に向けてさらなるプロダクト開発や機能強化を積極的に進めていきます。 NALYSYS開発チームに迫る 技術スタック NALYSYSのWebアプリケーション開発では、フロントエンド・バックエンドをTypeScriptで統一し、スイッチングコストを最小化したモダンな開発環境を採用しています。 フロントエンド：TypeScript（Next.js） バックエンド：TypeScript（Nest.js+GraphQL） インフラ：Google Cloud（Cloud Run、Compute Engine、Cloud SQLなど） データベース：PostgreSQL アーキテクチャ：マイクロサービスアーキテクチャ テスト:Jest、Cypress, Playwright CI/CD：Cloud Build 構成管理：Terraform 監視ツール：Datadog バージョン管理：Github メール送信：SendGrid 認証・認可：Auth0 開発支援：Storybook、Figma/Figjam 直近では、各プロダクトごとに、職能を超えた協力のもとでDDD(ドメイン駆動設計）の考え方に基づいたプロダクト開発を進めています。また、AIツール（v0、Devinなど）の活用による開発効率向上にも取り組んでいます。 開発手法 基本的にはスクラムを採用していますが、プロジェクトの状況に応じてスピード感を意識したカンバン方式や工程を事前にしっかり決めて進めるウォーターフォールを適用することもあります。 チーム構成・開発体制 開発体制は約50名の組織で、営業、CS、PdM、デザイナー、エンジニア、QA、EMなど、多様な職種のメンバーが在籍し、クロスファンクショナルなチームで開発を進めています。 Bizチーム、ProductManagement(Prd)チーム、Devチームとそれぞれ以下のような責務とミッションを持って日々開発に取り組んでいます。 責務 ミッション Biz 顧客の創造 売上の最大化 Prd 顧客への価値提供 プロダクトの成功 Dev 価値の具現化 大きな価値を迅速かつ継続的に創出 製販一体の開発 開発チームは、営業やCSと連携しながら、顧客の声を直接プロダクトに反映する「製販一体」の開発を実践しています。 具体的には各プロダクトごとに独立した開発チームを持ち、それぞれがPdM、デザイナー、エンジニアで構成されています。 さらに、SREやQA、EMなどの横断組織が全プロダクトを支え、品質や運用の最適化を推進しています。 また、営業・CSを通じて顧客の声をダイレクトに開発へ反映するほか、PdMが直接顧客ヒアリングを行うことで、より良いプロダクトづくりを実現しています。 ワークスタイル・雰囲気 NALYSYS開発部では、モチベーション管理というプロダクトを開発しているため、チームメンバー自身もモチベーションの重要性を理解しており、お互いを尊重し合う雰囲気があります。個々人が心理的安全性の担保を意識しており、とても働きやすい環境です。 例えば、新しい技術に挑戦した際に失敗してしまったメンバーがいましたが、チーム全体でその経験から学び、次に繋げる雰囲気がありました。 心理的安全性が担保されているといっても、単なる仲良し集団ではなく、お互いを意識しながら建設的な議論を交わせる組織です。例えば、上がってきたプロダクト企画について「この企画必要？別の企画のほうが今優先すべきなのでは？」、「ユーザーのことを考えるとXXのような要求も必要では？」など、営業、PdM、デザイナー、開発者、様々な職種、様々な意見を尊重しながら、より良い方向へ進むための議論が繰り広げられています。 私たちの部署の働き方や雰囲気は、 こちら の動画を見るとよりイメージが湧くかと思います。動画では、チームメンバーのインタビューや日々の開発風景を通して、活気あるチームの様子をご覧いただけます。 www.youtube.com また、以下の記事からも私たちのチームの雰囲気が感じられると思います。 未経験のフルマラソンにチームで挑む 〜仕事も趣味も全力なエンジニアって素敵やん？ 〜 └ 仕事以外でもチームワークを発揮し、お互いを応援し合う文化が感じられる記事です。 tech.leverages.jp 楽しく開発合宿をしてみたらたくさん予算をもらえる事になった話 └チームで楽しく成果を出すための工夫や、会社が社員の自主的な活動を支援する姿勢が分かる記事です。 tech.leverages.jp キャリアパス NALYSYS開発部、ひいてはレバレジーズ全体で、個人のWillを尊重したマネジメントが実施されています。個人がやりたいことを楽しく取り組める状態＝モチベーションが高い＝生産性が高い、という考えのもと、一人ひとりのキャリア形成を支援しています。 キャリアパスの例として、以下のようなものがあります。 営業→開発 バックエンド開発者→フロントエンド開発者 バックエンド/フロントエンド開発者→SREエンジニア バックエンド/フロントエンド開発者→PdM PdM→事業責任者 フロントエンド開発者からPdMへ転身したOさんからのコメントを紹介します。 弊社では上司や先輩とのキャリア相談も自然とよく行われており、自身のキャリアを見つめ直したり再発見しやすいと思います。また、実際に周囲で職種転換をした人が多いため、心理的なハードルが低い点でも自分の時は支えになりました。また、キャリアチェンジ後の大変な時期は周囲の方も積極的にサポートしてくれる雰囲気があり、安心して新しい役割に挑戦できる環境に感じています。 やりがい NALYSYSは、日本の社会課題にアプローチできる非常に面白いプロダクトです。事業フェーズの変遷を経験することで、自分の成長を通じて事業に貢献することができます。 また、単にプロダクトを作るだけではなく、「顧客のアウトカムを最大化するにはどうするか？」を常に考えながら製販一体で取り組んでいるため、エネルギッシュで刺激的な環境です。 終わりに ここまで読んでいただき、NALYSYSおよびNALYSYS開発部の魅力を感じていただけたのではないでしょうか？ NALYSYS開発部では、一緒にプロダクトづくりに取り組むメンバーを募集中です！ もっとNALYSYSやレバレジーズについて知りたい方は、 会社説明資料 をご覧いただき、ぜひ こちら からご応募ください！（カジュアル面談も実施中！） *1 : 国立社会保障・人口問題研究所　日本の将来推計人口（令和5年推計）

はじめに こんにちは、レバレジーズ株式会社の林です。 本記事ではレバレジーズグループ全体のエンジニアが参加するテックフェスの様子を紹介します。杜甫々氏による基調講演、社員によるトークセッション、その他コンテンツについて書いていますので、ぜひ最後までご覧ください。 テックフェスとは レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われる技術の祭典です。 エンジニアが新しい技術に興味を持ち、勉強するきっかけを作ることを目的とし、組織全体の技術力向上を目指します。 2月5日に行われたテックフェス2025Winterでは、「Be a Wizard 〜高き頂へ〜」というテーマで開催されました。 基調講演 概要 今回は杜甫々氏に「「とほほのWWW入門」を29年間継続してきた秘訣とは」という題名で、技術の歴史と当時のトレンドを絡めつつお話ししていただきました。 登壇者紹介 杜甫々 氏 「とほほのWWW入門」管理者 著書：「すぐひける・よくわかる HTMLハンドブック（インプレス）」 　　　「CGI＆Perl 究極のレシピ 350（技術評論者）」 学び、感想 大きく二つに分けてお話ししていただきました。 一つは、杜甫々氏の人生に IT がどのように関わっていたかでした。 マイコンに触れる幼少期を過ごし、社会人になり、ネットワークに精通するなど、コンピュータ黎明期での経験を説明されました。 二つは、杜甫々氏がライター「とほほ」に至った背景と、その秘訣でした。 初心者でも学べる学習リソースがないことに危機感を感じ、入門記事を執筆され、今に至るまでの29年間、多種多様な記事を描き続けられる秘訣を教えていただきました。 それは、「 好きになること 」だそうです。 個人的には、「 好きではないことでも、好きになったと自分を騙してやってみる 」という考え方に深く感銘を受けました。 セッション セッションには、7名の方に登壇していただきました。 発表者の皆さん、ありがとうございました。 Dimensional Modelingによるデータモデリング改善 （レバレジーズ テクノロジー戦略室 于原駿さん） アクターモデルによる効率的な分散システム設計 （レバレジーズ レバテック開発部 山川太一さん） Terraformによる運用効率化の取り組みと最新のテストアプローチの紹介 （レバレジーズ テクノロジー戦略室 中野竜之介さん） OpenFGAで拓く次世代の認可制御 （レバレジーズ NALYSYS開発部 桐生直輝さん） リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力 （レバレジーズ レバテック開発部 前原宗太朗さん） 作ってわかる！非同期処理ランタイム （レバレジーズ メディアシステム部 野中柊さん） 竹下さんやらかし歴 （レバレジーズ テクノロジー戦略室 竹下義晃さん） ＊機密情報を含むためタイトルのみとさせていただきます。 LT セッションには、4名の方に登壇していただきました。 発表者の皆さん、ありがとうございました。 以下にタイトルと発表者をご紹介します。 クライアント/サーバー状態に関する他の考え方、HTMXの紹介 （レバレジーズ ソリューション開発部 フランク・カラバージョさん） 強化学習の入り口：MAB問題について （レバレジーズ システム本部 坂本眞太郎さん） 改めて「型」について考えてみよう （レバレジーズ レバテック開発部 瀬尾光希さん） コンテナと仲良くしたい人生だった （レバレジーズ ソリューション開発部 青野圭哲さん） Code Quest 参加してくださった皆さん、ありがとうございました。 今回は参加者の皆さんにプログラミングで競っていただきました。 点差が出るようにと、問題数をかなり多めに設定していたのですが、皆さんレベルが高くあまり点差の出ない熾烈な戦いが繰り広げられていました。 また、皆さんに前向きに取り組んでいただくことができ、良い雰囲気の中、開催することができました。 懇親会 テックフェス終了後には、懇親会も開催。 乾杯の音頭は、基調講演登壇者の杜甫々氏が行ってくださいました。 さらに、レバレジーズ株式会社技術顧問の加藤潤一さんも参加してくださいました。 2名のスペシャルゲストを交え食事をし、事業部の垣根を越えた交流が生まれていました。 最後に 最後まで読んでいただきありがとうございます。 今回の記事では、テックフェスのレポートを書かせていただきました。 エンジニア界のWizardである杜甫々氏、弊社のWizard達のハイレベルなトークセッションは、技術面での圧倒的な差を感じさせられると共に、今後の自己変容の大きな足掛かりになったと感じました。 レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。 レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。 leverages.jp

こんにちは。 レバレジーズのシステム人事戦略室に所属している井上です。普段は新卒採用や採用広報に関わっています。 システム人事戦略室についてはこちら（ ↗︎ ） レバレジーズでは2026年入社のエンジニアを対象にサマーインターンシップを開催しました！毎年開催しているビジネス職向けのインターンシップは、選考通過率が1％前後ですが、今回はそのエンジニアバージョンです。 レバレジーズのサマーインターンは、単なるエンジニア体験ではなく、ビジネス全体に関わる刺激的な機会です。実際の開発だけでなく、課題設定やデータ分析にも触れられ、社会や人の課題解決に貢献するレバレジーズの事業を肌で感じることができます。 インターンの様子を一部公開しますので、レバレジーズのエンジニアサマーインターンについて興味がある方がいればぜひご覧ください！！！ サマーインターンの概要 メンター紹介 メンター 一部紹介 レバレジーズのインターンに参加するメリット 自分のアイデアが実際のプロダクトに反映されるかも？！ ユーザー視点でのプロダクト作りが経験できる サマーインターン プログラム紹介 1日目：プロダクト理解と課題設定 2日目：機能開発 3日目：発表と振り返り 懇親会 参加者の声 企画から実装まで、実務に近い体験ができた メンターからの手厚いサポート 現場に近いリアルな課題に取り組めた 組織の文化や仕事への姿勢に触れることができた 最後に We Are Hiring! サマーインターンの概要 開催日程：9月27~29日 開催場所：東京 渋谷本社 参加学生人数：9名 メンター人数：6名 グループ数：3グループ グループ内訳：学生3名・企画メンター1名・技術メンター1名 テーマは、 「スカウトサービスの価値を最大化する機能を企画・開発せよ」 で実施しました。 メンター紹介 ベストルーキ賞を受賞した社員 事業責任者 PdM PM テックリード など、 現場の最前線で活躍するメンバーが直接フィードバックを行い、濃密な学びの機会を提供しています！ 参考記事（ ベストルーキー賞受賞社員 ・ HRテック事業部 事業責任者 ） メンター 一部紹介 レバレジーズのインターンに参加するメリット 自分のアイデアが実際のプロダクトに反映されるかも？！ 提案したアイデアは、 実際のプロダクトに採用される可能性があります。 インターン終了後は皆さんのアイデアが開発チームに共有されるため、自分の考えがリアルなサービスに影響を与える経験を積めます。 「自分のアイデアが世の中に届くかもしれない」 そんなリアルな経験を、レバレジーズのサマーインターンでは体験することができます！！ ユーザー視点でのプロダクト作りが経験できる レバレジーズのエンジニアは、 コードを書くだけ 言われたものと作るだけ ではなく、何を、なぜ、どのようにして作るのかをユーザー視点で課題を捉え、最適な解決策を考えるのが特徴です。 そのため、エンジニアは開発だけでなく、 マーケティング ユーザーヒアリング デザインディレクション など、幅広く事業全体に関わります。 マーケター、デザイナー、セールスなどの他職種との連携を密にすることで、顧客の声をダイレクトにサービスに反映できるのが、弊社のエンジニアの面白みです。 インターンでは、ユーザー属性ごとのデータを分析して課題を特定するところから始めるため、レバレジーズのエンジニアだからこその 「ユーザー中心のプロダクト作り」 を経験できる絶好の機会です。 サマーインターン プログラム紹介 1日目：プロダクト理解と課題設定 1日目のスケジュールは下記の通りです。 サービス・プロダクト理解 ペルソナ理解 データ分析 課題解決のアイデア出し 機能企画 実際にスカウトアプリの管理画面を操作し、ユーザー属性ごとの開封率や利用状況などのデータを分析しました。 エンジニアリングだけでなく、ユーザー行動データをもとに仮説を立て、ビジネスインパクトを考慮しながら重要な問題を見極めるプロセスを体験することができます！ 「ただ作るだけ」で終わらない、データに基づく意思決定の重要性を学べるのが、このインターンの大きな特徴です。 2日目：機能開発 1日目に設定した課題に対する解決策を形にするために、開発に集中してもらいました。 弊社の技術メンターがサポートに入り、ペアプログラミングを通じて実際にコーディングを行います。 エンジニアとして技術的な課題に向き合うだけでなく、チームメンバーと共に問題を解決するプロセスを体験することで、開発の現場をより深く理解することができました。 3日目：発表と振り返り 2日目に開発した機能をチーム内で発表し、フィードバックをもらいます。 審査基準は下記の3つです： ニーズの質 事業へのインパクトの大きさ プロダクトの質 最終的には、 開発部長 PdM VPoE この3名の審査員によって、最終的な評価が行われました。 経営視点からのフィードバックを直接受けることで、ビジネス感覚も身につけられる貴重な体験です。 ワーク終了後は、各チームのメンターと1on1の振り返りを実施し、学んだことや改善点を共有しました。 サマーインターンの様子 懇親会 プログラム終了後の懇親会では、学生たちと社員がリラックスした雰囲気の中で交流しました。 3日間という限られた時間の中で、企画〜開発まで一貫して対応するという厳しい条件だったこともあり、メンターと学生が互いに「一緒に困難を乗り越えた仲間」という関係が築けていました。 開発の裏側や業務のリアルな話題に加え、互いのプライベートの話などもして大いに盛り上がるなど終了後には「もっと話したかった！」という声も多く、双方にとって学びのある時間となりました。 参加者の声 今年のインターンシップでは、学生たちに実際のプロダクト開発に取り組みながら、レバレジーズのエンジニアとして必要なスキルを身につける体験をしてもらいました。参加者からは、さまざまなポジティブな感想をいただきました！！ ここでは、その中でも特に好評だった点をいくつかご紹介します。 企画から実装まで、実務に近い体験ができた 「データをしっかり分析した上で次の手を打つということの大切さを学ぶことができた。」 「どのようなユーザーを対象にして、どんな課題を持っているのかと言うところを実践を通して学べて、自分のこれからの開発に貢献できると思う。また、プロダクト開発において、どのように道筋をたたて、思考して行くのかと言う部分が少しでも身につけられて、これからも実践していきたいと思った。」 メンターからの手厚いサポート 「超ハイレベルな技術力とビジネス力を持った方々と、自分との差分を感じることができた。」 「今まで参加したインターンの中では一番濃密だったし、サポートも手厚かった。心理的安全性が担保されていて、リラックスして臨めた。」 現場に近いリアルな課題に取り組めた 「実際に運用されているサービスの問題点を洗い出すことは新規事業を考えることとはまた別の面白さがあり、非常に学びがありました。」 「実際にプロダクトで使用している技術やコードを見ることができて、自分のこれから書くコードに反映できそうだと思いました。」 組織の文化や仕事への姿勢に触れることができた 「レバレジーズの仕事への姿勢に感銘を受けました。社員同士が本気で取り組んでいて、こんな環境で成長できるのはとても魅力的だと思いました。」 「ベンチャー気質でありながら、利他性のある人が多いのはイメージと違って好印象だった。人材ビジネスが大きな柱ではあるが、それ以外にもたくさんのチームがありそれぞれがプロダクトを持っているので、「人材系の会社」という第一印象が薄まった。」 最後に レバレジーズのエンジニア組織は今後さらに強化・拡大を続けていきます。 そのため、課題の本質に向き合い、考え抜ける「未来の組織の核」となる人材を求めています。 また、今回のサマーインターンを通じて、参加者の中から実際に内定者が誕生しました！！！ インターンを通じて、レバレジーズでのキャリアをスタートさせる仲間ができたことは、このインターンシップを運営して本当に良かったと思える瞬間でした。 エンジニアリングはサービスの価値を形作る基盤であり、ビジネスを成功させるために欠かせない要素です。 「開発」だけで終わらず、その先の未来を創り出すレバレジーズのエンジニアリングチーム。インハウスの強みを活かし、他職種の仲間と共に事業を創造、改善、検証していける環境は、新卒エンジニアにとって大きな魅力だと考えています。 We Are Hiring! 新卒エンジニアの皆さんにも、様々な業務を通じて成長の機会を提供し、一緒に未来を切り開いていきたいと考えています。 このような価値観に共感し、「自分のアイデアで世の中に影響を与えたい」 そんな情熱を持ったあなたの応募をお待ちしています！ 今年もサマーインターンシップを開催予定ですので、気になる方は下記サイトから応募してみてください〜〜！ ◆ レバレジーズ 2027卒新卒 エンジニアサマーインターン 応募フォーム ◆ 新卒採用ページ ◆ エンジニア採用サイト

ごあいさつ レバレジーズ株式会社 アジャイルエフェクトチームの田代です。 我々アジャイルエフェクトチームは、 スクラムにおける様々なプロセスを可視化し、生産性改善に繋げるためのSaaSプロダクト「 Agile Effect 」 を開発しています。 当プロダクトは、 とあるPMの社員が社長に直接事業企画を提案したことがきっかけで誕生しました。 昨年4月に事業が正式に立ち上がり、そこからわずか1年後の今年4月に正式リリースを迎えることができました。（レバレジーズは、アイデアを積極的に取り入れられる風土があり、意思決定の速さと挑戦を歓迎するカルチャーが色濃く根付いています！） アジャイルエフェクトチームの特徴は 「どのチームよりアジャイルを体現した組織」 であることです。「スクラム改善のプロダクトを開発する上でアジャイルを体現し効率的にプロジェクトを進められるチームであることは大前提」というプライドの下、5名で事業をリードしています。 それぞれの得意分野や主な役割こそありますが、明確な役割分担はありません。 日々の業務の中で、POが開発や設計に関わることもありますし、開発メンバーが企画・営業・マーケに関わることもあります。また、Agile Effectを活用することで全メンバーが主体となって改善サイクルを高速で回すことができています。 これにより高いアジリティを発揮し、 「定常的な週2〜3回ペースでのリリース」 「ユーザーから要望があった機能の1週間以内リリース」 などが実現できています。 我々がプロデュースする 「Agile Effect」 には、社内外でご利用いただいているスクラムチームの知見が詰め込まれており、今後も要望を取り入れながら、プロダクトを漸次的にアップデートし続けていきますので、ぜひ無料でご試用ください。 皆様のご利用をお待ちしております！ はじめに 早速ですが、エンジニアの皆様。 「フロントエンド開発」やっていますか？ 「CSS」書いてますか？ 当記事では、TypeScriptベースのスタイリングライブラリである 「Panda CSS」 のご紹介と、実運用で得た知見を共有いたします。 これらの問いに対して「YES」と回答した方であれば、学びに繋がる内容となっていますのでぜひご一読ください。 対象読者 アプリケーションのフロントエンド開発に携わるエンジニア 特に、スタイリングに関する内部品質で悩んでいる方 Reactで新しくアプリケーションを作ろうとしている方 Panda CSSの実運用事例について詳しく知りたい方 記事を通して得られること TypeScriptベースのCSSライブラリ「Panda CSS」について 他のスタイリング手法（CSS Modules/SCSS/Tailwindなど）とPanda CSSの比較 型安全なCSSやデザインシステム構築に役立つPanda CSSの基本知識 実際のプロダクトで運用する際に生じる課題と対処方法 Panda CSSを使った際の開発効率向上や保守性アップの具体的なイメージ 以上の内容をカバーすることで、読者の皆様がPanda CSSの導入メリットを把握し、プロダクトのスタイリング設計をより快適に進められるようになることを目指しています。今後のフロントエンド開発に、少しでもお役に立てれば幸いです。 どう幸せになったのか まず結論をお伝えすると、Panda CSSを採用したことで以下のような改善が実現し、開発体験が劇的に向上しました： 型安全なCSS ：TypeScriptによるスタイリングで開発速度と保守性が向上。 宣言的かつ画一的なスタイリング ：動的な値に基づくスタイリングが宣言的かつ1箇所に集約され、保守性/可読性が向上。 DOMとスタイリングの責務分離 ：「Typography」「Flex」など、スタイリング用のコンポーネントがDOMに影響してしまう悩みからの解放。 デザインシステムの踏襲 ：デザイントークンを型レベルで組み込み、デザインとの乖離を排除。 ご存じのとおり、Reactのスタイリングには「Sass/SCSS」「CSS Modules」「Styled Components」「Tailwind CSS」「Emotion」「StyleX」など様々な選択肢があります。それぞれ一長一短があるため、どれを採用するのか悩ましいところですが、今回紹介するPanda CSSは、 これらの手段の“いいとこ取り”を叶えてくれる存在 だと感じています。 実運用を通じても開発体験の良さを実感しており、個人的にはPanda CSSが 「Reactのスタイリング手法における最適解」 だと思っています。 ここで挙げた以外にもPanda CSSを使うことで得られる恩恵は様々であり、記事全体を通してご紹介出来ればと思います。 目次 ごあいさつ はじめに 対象読者 記事を通して得られること どう幸せになったのか 目次 導入背景 Panda CSSの特徴と、他のスタイリング手法との比較 Panda CSSを使った基本のスタイリング 基本のスタイリング構文 スタイル生成の流れ まとめ Panda CSSで「書きやすさ」と「最適化」を両立 ※記事全体で分量が多くなってしまったため、記事を3つに分けて順次公開していきます。 今回はPart1となります。 Part1：Panda CSSとの出会いとその魅力 導入背景 Panda CSSの特徴と、他のスタイリング手法との比較 Panda CSSを使った基本のスタイリング Part2：実践！Panda CSSの使い方（Coming soon） Part3：Panda CSSの課題と未来への展望（Coming soon） Part1では、Panda CSSの採用に至った背景とその魅力についてお話しします。 後日公開するPart2/Part3では、実際にどのようにプロダクトで運用しているかを、設計事例とともに紹介する予定です。 導入背景 「Agile Effect」では、Reactを用いてフロントエンドを開発しています。 立ち上げから約1年間はCSS Modulesを使っていましたが、次第に以下のような課題が出てきました： 静的型付けが効かない 単純に開発体験の悪さを感じ、エラー発生やコミュニケーション面など、将来的な開発スピードへの影響が懸念されました。 デザインシステムの作成開始 デザイン自体がまだプロトタイプの状態でしたが、本格的なデザインシステム制作がスタート。スタイリング設計を見直す大きな要因に。 汎用スタイルコンポーネントの責務拡大 「Typography」「Flex」など、スタイル適用のためのコンポーネントが肥大化し、SRP原則から逸脱しはじめていました。 デザイントークンの取扱い 基本的なスタイリングはCSS Modulesで行いましたが、デザイントークンに限ってはTypescriptの定数を経由し、Inline Styleで管理していました。この影響で、スタイルの記述が.module.cssと.tsxの双方に散在していました。 これらを踏まえ、スタイリング設計をゼロから見直すことに。 調査と比較検討の末、我々が採用したのが Panda CSS でした。 Panda CSSの特徴と、他のスタイリング手法との比較 CSSは、TypeScriptベースの“ゼロランタイム”CSS-in-JSライブラリです（セットアップなどの基本知識はここでは割愛します）。公式ドキュメントの「なぜPandaを選ぶのか？」にあるとおり、主に以下のような特徴が挙げられます。 静的解析 ： ビルド時にスタイルを解析・分析し、フレームワークに依存しない純粋なCSSファイルを出力します。 PostCSS ： 静的解析の後、PandaはPostCSSプラグインのセットを使用して、ビルド時に解析されたデータをアトミックCSSに変換します。これにより、PandaはPostCSSをサポートする任意のフレームワークと互換性があります。 Codegen ： ブラウザ実行時にスタイルを注入せず、ビルド時に軽量なランタイムJSコードを生成。結果としてランタイム負荷が低くなります。 型安全性 ： Pandaは、cssプロパティとデザイントークンの型安全性を提供するために、csstypeと自動生成された型付けを組み合わせます。 パフォーマンス ： 必要なアトミックCSSのみを最適化して出力。不要なCSSが入らずバンドルサイズが抑えられます。 開発者エクスペリエンス ： Pandaは、レシピ、パターン、デザイントークン、JSXスタイルプロップなどの豊富な機能により、優れた開発者体験を提供します。 モダンCSS ： カスケードレイヤー、CSS変数、:where/:is等、最新のCSS仕様に対応。 また、私なりに他のスタイリング手法とのおおまかな比較表も作成してみました。 項目 静的型解析 実行タイミング パフォーマンス 型安全DesignTokenサポート 動的スタイリング Sass/SCSS （Pure CSS） × ビルド時 ⚪︎ （肥大化しやすい） × △ （JSが必要） CSS Modules △ （型生成を支援するライブラリ使用で一部可） ビルド時 ⚪︎ （肥大化しやすい） × △ （JSが必要） Styled Components / Emotion △ （プロパティレベルの解析不可） ランタイム時 × △ （型レベルの厳密性は薄い） ◎ Tailwind CSS △ （プロパティレベルの解析不可） ビルド時 ◎ △ （型レベルの厳密性は薄い） ⚪︎ Panda CSS ◎ ビルド時 ◎ ◎ ⚪︎ 表から分かる通り、 Panda CSSにはこれといった大きなデメリットが見当たらず、静的解析や型安全性、ゼロランタイムなどの特色はどれも非常に魅力的でした。 もちろんプロジェクトとの相性等はあるかと思いますが、我々の場合は移行負荷も低く大きな懸念が無かったため、全面的にPanda CSSへ移行することにしました。 Panda CSSを使った基本のスタイリング ここからは、Panda CSSにおけるスタイリングの一連の流れを見ていきます。 公式ドキュメントにあるように、Panda CSSは「TypeScriptベースのコード定義をビルド時に解析し、最終的に純粋なCSSファイルを出力する」フローが大きな特徴です。 ポイント: Panda CSSでは、最新のカスケードレイヤーが活用されているのも大きな特徴の一つです。 CSSレイヤーを活用することで、複数のレイヤーにまたがるスタイルの優先順位が明確化され、アトミックCSSやデザイントークンとの相性がより良くなっています。詳しくは、公式ドキュメントのカスケードレイヤーのページをご確認ください。この仕組みを前提に、次章からはPanda CSSでどのようにスタイルを定義し、ビルドしているのかをご紹介していきます。 基本のスタイリング構文 Panda CSSのスタイリングは、styled-system/css が提供する css() や cva() などの関数を用いて定義します。まずはもっともシンプルなcss()を使った例を見てみましょう。 こちらが最も基本的な定義の例です。 import { css } from '../styled-system/css' const styles = css( { backgroundColor : 'gainsboro' , borderRadius : '9999px' , fontSize : '13px' , padding : '10px 15px' } ) // 生成されるクラス名: // --> bg_gainsboro rounded_9999px fs_13px p_10px_15px < div className = { styles } > < p > Hello World </ p > </ div > この定義を基にビルドした結果、CSS出力は次のようになります。 @layer utilities { .bg_gainsboro { background-color : gainsboro ; } .rounded_9999px { border-radius : 9999px ; } .fs_13px { font-size : 13px ; } .p_10px_15px { padding : 10px 15px ; } } 上記のように、TypeScriptのオブジェクト構文でCSSプロパティを記述するだけでOKです（プロパティ名や値は型安全性が効きます）。実行時ではなくビルド時にCSSに変換され、ブラウザに読み込まれるころには純粋なCSSファイルとして提供されます。 ポイント: css()以外にも、バリエーションを定義するためのcva()や、汎用レイアウトなどをRecipeとしてまとめるdefineRecipe()など、複数のアプローチがあります。 どれも「TypeScriptでCSSを記述する → ビルド時に最適化されたCSSが生成される」という点は共通です。（参考） スタイル生成の流れ Panda CSSを利用すると、TypeScriptで記述したスタイルがビルド時に最適化され、最終的には純粋なCSSファイルとして出力されます。ここでは、その一連の流れを順に確認していきます。 1.「型付きのスタイル定義」を記述する まず、開発者が行うのはTypeScriptによるスタイル定義です。 css() や cva() に渡すオブジェクトや変数には 型安全性が適用されるため、プロパティ名や値の誤りが早期に検知できます。 2.ビルド時に「原子化」と「不要なものの排除」 ビルドプロセスでは、Panda CSSがソースコードを走査し、同じプロパティや重複する宣言をまとめて Atomic CSSへ変換します。 Atomic CSS: CSSプロパティ単位でクラスを生成する考え方です（例: .p_8px_16px, .rounded_4px など）。 使われていないクラスは自動的に削除され、必要最小限のCSSだけがビルド成果物として残ります。 3.純粋なCSSファイルとしてブラウザへ 最終的な変換結果は、特定のJSライブラリに依存しない 純粋なCSSファイルとして出力されます。 つまり、ランタイムでスタイルを注入する必要はありません。ページ読み込み時には、既に最適化されたCSSが供給されているため、 “ゼロランタイム”を実現できます。 ポイント ・型安全にCSSが書ける ・バンドルサイズが肥大化しにくい ・実行時のオーバーヘッドが少ない ・クラス名の競合を最小限に抑えられる このように、 型安全性と最適化済みのCSS出力を同時に得られるところが、Panda CSSの大きな特長です。 まとめ Panda CSSで「書きやすさ」と「最適化」を両立 書きやすさ TypeScriptでのオブジェクト記述なので、補完や型チェックが効き、スタイル記述のミスを減らせます。 最適化 ビルド時にスタイルを集約・最適化して出力するため、ランタイムで注入する仕組みよりもパフォーマンス面のメリットがあります。 Part2以降では、これらの基盤を活かしてデザインシステムをどのように型安全に落とし込んでいくか、さらに踏み込んだ使い方を紹介します。 今回紹介した「基本のスタイリング」の部分だけでも十分恩恵がありますが、 Panda CSSには、Design TokenやRecipe機能など、より高度なスタイリングパターンをサポートする仕組みが豊富に用意されています。 　これらを組み合わせることで「デザインシステムと型安全性の融合」を実現し、プロダクト全体のスタイリングを一貫性のあるものへと導いてくれます。 次章ではさらに踏み込んで、Panda CSSが提供する「Recipe（CVA）」や」Config Recipe」を活用した共通スタイルの定義や、デザイントークンを組み込んだデザインシステム構築など、 より実践的な活用事例を紹介していきます。 加えて、テスト環境やStorybookでスタイルが反映されない際のトラブルシューティングなど、 リアルな運用Tipsについても触れます ので、ぜひご期待ください。 ご一読いただき、ありがとうございました！

はじめに こんにちは。システム本部メディアシステム部iPLチームの大井です。 本記事では、私が所属しているiPLチームについて紹介します。 レバレジーズという多くの事業を展開し、急成長を遂げている会社であるが故の課題に対してシステムで解決すべく、どのように取り組んでいくのかお伝えできればと思います。 はじめに iPLチームとは 業務内容 新卒採用管理システム(ATS) 配賦処理システム 統合法人データベース 類似度判定システム 従業員管理システム M&A 使用している技術について やりがい 働き方(一例) 最後に iPLチームとは iPLはinternal Product Lab.の略で、「社内プロダクトの研究室」をテーマにした他の事業部とは異なったテイストのチームになっています。 平均年齢は27〜28歳、営業、マーケティング部からの出身者、新卒から中途まで様々なバックグラウンドを持った社員が所属しています。 このチームは2024年4月に発足しており、できて1年経っていないような新しいチームです。 設立の背景としては、年商1000億を突破し急拡大するレバレジーズグループの経営資源、いわゆる「ヒト・モノ・カネ・情報」の管理を見直してより効率的に経営判断ができるようなシステムを構築できるようにしようというところから始まっています。 まさに今年度の弊社テーマである「次代を、創る。土台を、創る。」の根幹を担うようなチームとなることを目指して日々仕事をしています。 業務内容 上記で紹介したようにiPLチームではレバレジーズグループの経営に直結する複数のシステム構築や管理を担っています。 その一部を紹介いたします。 新卒採用管理システム(ATS) レバレジーズグループは新卒の採用を年々拡大しています。 2024年4月にはおよそ700名の新卒が入社しており、次年度以降も採用数を伸ばしていく見込みです。 弊社では外部の採用管理システムを長年使用しておりましたが、年々変化していく採用の体制を見込んだ拡張性や、データの利活用という点で大きなメリットがある自社開発を行なっております。 配賦処理システム レバレジーズグループは40以上もの事業を展開している会社です。 各事業ごとの予算や目標が存在していますが、社員の中には複数の事業に貢献している社員がいたり、光熱費や備品、オフィスの賃料などの費用は各部署に跨っていることもあります。 そこで必要なのが配賦(はいふ)です。 配賦とは、ある費用を複数の事業や部署に割り当てることを指します。 様々な部署で跨って発生している費用を按分し、より正確な予算立てや目標設定をするためのシステムを開発しています。 統合法人データベース 各事業ごとに営業支援システム(SFA)を持っていますが、そこで得た情報を統合しグループ全体で活用するDBを開発しています。機能としては法人の名寄せや各事業での取引有無、コンプライアンスチェックなどを盛り込んでいます。 類似度判定システム 法人データの重複が発生してしまうと、営業活動の重複や顧客情報の散乱、分析精度の低下、コンプライアンス違反など多くのリスクを抱えることになります。 類似度判定システムは、類似する法人データを示すことで、担当者によるデータ統合・修正作業を促し、正確な法人データの維持を支援します。 現状は法人名といったテキストデータを中心に類似度判定を行っていますが、今後は、テキストデータだけでなく、画像データ（ロゴマークなど）や音声データなどより汎用的な類似度判定を実現するマルチモーダルなシステムを目指します。 従業員管理システム 約3000名の従業員が働くレバレジーズにおいて、適切な人員配置も経営において重要なことです。その人がどういった経歴を持っており、どういった適性があるのかなどを確認できるようなシステムを構築しています。 M&A レバレジーズグループでM&Aを担当しているM&Aアドバイザリー事業部のシステム関連の効率化を行なっています。企業様どうしのマッチング精度を向上させたり単純作業の自動化などが挙げられます。 お客様への良質なご支援はもちろんのこと、将来的にはレバレジーズグループが実行するM&Aにおいてもノウハウが活かせるようにしていくことを目指しています。 使用している技術について iPLチームではWEBアプリケーションとして開発されるものもあれば、API単体の開発をすることもあります。基本的にはTypeScript/JavaScriptを採用しますが、機能によってはPythonを採用しています。 開発するシステムも速度や精度を追求するものや、WEBアプリケーションとしてUI/UXにこだわるものなど、様々です。それに応じて柔軟にアーキテクチャも変えているので、幅広い知識も身につけることができます。 一例として、新卒採用管理システム「通称:Atsys(アトシス)」のアーキテクチャを紹介します。 フロントエンド：TypeScript（Remix） バックエンド：TypeScript（NestJS） BFF：TypeScript（fastify） インフラ：GoogleCloud（CloudRun&Docker、CloudSQL（PostgreSQL） etc...） Atsysはフロントエンド、BFF、バックエンドの3層で、TypeScriptを利用しています。 TypeScriptにした背景としては、複数領域に跨って開発・レビューする際に言語の差異による認知を軽減することや領域ごとに型情報を共有できることがメリットだからです。 フロントエンド フロントエンドはRemixを利用しています。 RemixはWeb標準に忠実に従おうという思想を持ったフレームワークであり、従来のReactで直面するであろう状態管理の煩雑さから解放され、開発者体験はとても良いです。 特にremix-validated-formというライブラリでは、クライアントとサーバサイドで同じスキーマを使ってバリデーションを適用でき、フォームの実装を簡単かつ一貫性を持って実装できます。 バックエンド バックエンドはNestJSを採用しています。 フレームワーク側でアーキテクチャが比較的固まっていて一貫性を保ちやすいこと、機能が豊富で大規模な開発がしやすいこと、モジュール間での依存関係を解決しやすいことがメリットです。 また、クリーンアーキテクチャを導入し4層で責務を切り分けていること、APIはRestの原則に忠実に従って設計していることにより、特定の箇所の責務が肥大化することを回避しています。 BFF(Backend For Flontend) 当初はバックエンドとフロントエンドのみで、BFFは存在していませんでした。 ただ、バックエンドがRestAPIとなっており、あるページの描画のために複数のAPIにアクセスして結合する必要がありました。 その結果、ロジックの複雑化、ソースコードの肥大化が問題となっていました。 そこで、APIとフロントエンドの仲介をしてデータ整形を行うBFFを導入しました。 BFFではシンプルな処理を記述するだけなので軽量なfastifyを採用しています。 インフラ Google Cloudを採用しています。 FE、BE、BFFはいずれもDockerコンテナ上で動作させており、Cloud Runにホスティングしています。 Cloud Runはコールドスタートが非常に早いので使わない時はインスタンスを落としても問題なく、コストを抑えやすい特徴があります。 また、Google CloudにはIdentity Aware Proxyという機能があり、弊社社員のGoogleアカウントを使って簡単に権限管理を行うことができるメリットもあります。 やりがい iPLチームの魅力はたくさんありますが、その中でも主に3つ紹介します。 ・会社のミッション達成に直結する基幹となるシステムを創る 弊社は年商1000億円を突破し、経営における土台を再構築するタイミングになっています。そういった経営に関わる重要なシステムの構築に携わり、これから1兆円を目指していく弊社の重要な歯車として働けるのは大きなやりがいがあります。 また、会社を経営するためにはどんな情報が必要で、どういった形が健全なのか理解できることも魅力の一つだと思います。 ・自分で仕様を決めて、設計して少人数で開発できる 社内の経営企画室や各事業部の幹部と連携を取りながら、仕様決め→設計→実装を一貫して行います。我々のチームは少人数で多くのシステム開発を行なっています。メンバーそれぞれがシステムにおける重要な意思決定を行います。特に仕様の部分は個人に大きな裁量があり、理想を叶えるためであれば自由です。言語やFW、インフラ構成なども自身で決めます。これによって、開発プロセスを一通り経験できるのはもちろんのこと、様々な関係者の知識や考えをどうシステムに取り入れていくのか考える思考力を身につけることができます。 ・自分で事業を生み出してみることも...！ また、将来的な話ではありますが、開発しているシステムが社内で有効活用されたのちに外販していくことも考えています。iPLチームは社内プロダクトの開発を目的とするチームですが、その枠組みに囚われず事業創造までも成し遂げる野望を抱いています。 働き方(一例) 最後に エンジニアとして経営に関わりたい、会社を大きくしたいという野望を持つ方とぜひ一緒に仕事をしたいです！ 少しでも本記事を見て興味が湧いた方は、弊社へエントリーいただけますと幸いです！ エントリーはこちら→ https://recruit.leverages.jp/recruit/engineer/ お待ちしてまっっっっっっっす！

はじめに こんにちは。 レバレジーズでHRTech系SaaS NALYSYSの開発チームでEMをやっております、下畑と申します。 1月の第二週に、あけましておめでとう合宿と題し、 任意でメンバーを募集し、旅費が自腹のプライベート開発合宿 を行いました。 取り組みとしてうまくいったので報告いたします。 この記事に書かれていること 自腹での開発合宿は今後の合宿予算を取るための布石として行なったのですが、 目論見を超えた大きな話になったこと 実際の合宿の様子 参加してくれたメンバーたちが楽しかった思い出として見返せるように はじめに この記事に書かれていること この記事を読むとわかること 開発合宿をやるぞ！ ことの発端 高いハードル 提案と反応 準備編 いつどこに泊まろう？ 何をやろう？(結果も) 何を開発しよう？ 仲間を求めて 合宿はこんな感じ スケジュール 集合 買い出し 宿についてまずやったこと 開発スタート ごはんは大事 飲酒開発 ランニング チェックアウト 合宿を終えて 本番環境へのデプロイ回数 機能開発 GIGAZINE企画 総括と今後 メンバーのおかげで成果を出せた オールインハウスの強み 開発合宿おすすめです PoCとしての成功 最後まで読んでくれた方へ この記事を読むとわかること 弊社エンジニアの自律性とチームワークが凄い 開発合宿は自腹でもやる価値ある 開発合宿はそれなりの成果と楽しい思い出を作れる 予算取りの一例としての自腹開発合宿、ありだと思います 開発合宿をやるぞ！ ことの発端 昨年のシステム本部キックオフにて、本部長が開発合宿をやりたい人はぜひ提案して欲しいという話をしていました。 その後、私が所属しているチームでは「 なんだか楽しそうだから合宿してみたいなぁ 」という機運が高まりました。 新しい企画が生まれるごとに、「これ、合宿でつくっちゃう？」といった冗談めいた会話が起こるようになりました。 高いハードル そんなこんなで合宿やりたいという熱がどんどん高まり、現実的に会社のお金を使って合宿を行うにはどういう調整が必要なのかをPdMと考え始めました。 合宿をやりたいとおっしゃっていた本部長に話を聞いてみたところ、以下の答えが返ってきました。 「GIGAZINEに載るような面白いことをして欲しい。」 GIGAZINEさんはIT系の真面目なニュースからクスッと笑えるニュースまで掲載される歴史あるサイトです。 そこに載るって ハードル高くないか？ と。 他社でも開発合宿を行っているところは多数あるため、ただ合宿をやるだけじゃだめだと。 でも合宿はしたい！！ 会社のお金を使って合宿を行うために我々が出来る現実的な調整としては、 プライベートで合宿をしてみて、その成果を社内外にアピールをしてみることではないか と結論を出しました。 つまり、今回行った開発合宿は、弊社で 今後の開発合宿開催予算を取るためのPoC みたいなものになります。 提案と反応 プライベートで開発合宿を行うには、メンバーに宿泊費はもちろん貴重な休日を、半分仕事として消化してもらう必要がありました。 任意参加としてメンバーを募るにしても、人が集まらないと開発はできないため、ある程度のメンバーを集める必要がありました。 ただ、事前に開発合宿をやりたい機運がチーム全体で高まっていたこともあり、 すんなり人は集まってしまいました 。あっけない。 地方に在住のデザイナーの方も参加していただけたりと、開発するには十分なメンバーが集まりました。 以前チームでフルマラソンに参加した経験もあり、メンバーたちのフットワークの軽さに関しては認識していたものの（以下の記事参照）、 今回も弊社エンジニア達の人柄に対して企画する側としては感謝しかなかったです。 tech.leverages.jp 準備編 いつどこに泊まろう？ これは私の性格なのですが、やると決まったら待ちきれないタイプの人間でございまして、 一ヶ月後ぐらいの日程でみんなが暇そうな日をおさえました。 場所の案出しをお願いしたところ、グアムなど遊ぶ気満々の候補地も出ましたが、 自腹のことも考えると 予算も無理のない範囲で行きたかったので最終的に湯河原 にしました。 候補地検討 こちらの記事も参考にしました。 www.yugawara.or.jp 確かに 湯河原は開発に集中できる環境だった と思います。 宿は大人数で 安く泊まりたかったのでAirbnbを利用 しました。 業務委託のデザイナーの方がたくさん候補を出してくれたのですが、 露天風呂付き、サウナ付き というとても面白い宿を予約することが出来ました。 最終的に、交通費と1泊2日の宿代を合わせて一人当たりの 予算を2万円弱に抑えることが出来ました 。 何をやろう？(結果も) 本部長から言われた「GIGAZINEに載れ」が頭から離れず、とりあえず 面白い開発を合宿中にやってみよう という話になりました。 宿も平屋の貸切だったため思い切ったこともできるということで、合宿で以下の検証をしてみることにしました。 露天風呂での開発は捗るのか？ サウナで整った頭で開発すると捗るのか？ 酒飲んで開発すると捗るのか？ オールナイト開発はパフォーマンスを出せるのか？ ランニング直後に開発すると捗るのか？ 結論を書きますと、 みんなのテンションを上げたり エンターテイメントとしてやりごたえはあった のですが、 開発生産性にどう影響が出たのかはよくわかりませんでした。 露天風呂開発に関して具体的な言及をいたしますと、 腰への負担が座って開発するより少ないのと、外気温が低くのぼせる心配もあまりなかったので 意外に長時間開発に適していると感じました。 ただ、高価なマイPCを水没させてしまうリスクも孕んだ開発となるためおすすめはしません。 湯煙に隠れるディスプレイ 何を開発しよう？ 現在開発しているNALYSYSはHRテック系SaaSですが、 HRテックがタッチするドメイン領域は非常に幅広く、我々が共感できる課題を改めて探索するフェイズでした。 ちょうど昨年末は、弊社の人事部に話を伺いながら共感できそうな課題を探していた時期であったため、 何を作ればいいかを合宿直前まで悩みました。 開発の弾を4つやろうという結論が出たものの、チームメンバーだけだと終わらせられるか心配になりました。 仲間を求めて 開発する機能ラインナップに対して人が足りないことに気付いたのは合宿の前々日でした。 こんな直前に声掛けをしても、なにかしらのメリットがないと人も集まらない気がしたので、 宿泊費はチームメンバーで持つから無料で合宿に参加しない？ と声掛けをしました。 今回の宿は宿泊費が固定だったため、人数が増えてもメンバー一人当たりの宿泊費が変わらなかったことが幸運でした。 最終的にはその作戦で追加で5人あつまりました。 内訳としては、 同じ事業部の別チームに所属する開発者が2人、PMMが1人、 調子に乗って人数多い方が楽しいからと声をかけてみた別事業部の営業の方と人事の方1人ずつです。 集まれ〜 合宿はこんな感じ スケジュール こちらは事前に用意しておいた合宿のしおりに書いたスケジュールです。 露天風呂開発やサウナ開発など色々やりたいことがあったため少しユニークな予定も入ってます。 1日目 13:00 湯河原集合 13:30 飯食う 14:00 買い出しとか 15:00 宿チェックイン 15:10 風呂をすぐにわかしてサウナをON 15:30 開発開始 20:00 夕飯 21:00 酒飲み開発開始 2日目 4:00 開発終了 & 就眠 7:00 マラソン勢は起床し、峠を走る 8:00 走らない人達が起床 8:30 朝飯 9:00 開発開始 11:00 開発終了&チェックアウト 集合 総勢11人での合宿だったのでちゃんとみんなが時間通りに集まるかが少し不安でしたが、ほぼ集合時間に集まりました。すごいぞ。 湯河原駅前には撮影用の大きな風呂桶があるので記念撮影を撮りました。 買い出し スーパーで買い出しをしたのですが、店に着いた直後やれ鍋が食べたいだのお好み焼きを作りたいだの、各々が買いたいものを買いに散らばっていきました。 人が多いって賑やかでいいなぁと思いました 。 多分統率取りたいとかって思ってしまうとストレスになるかもしれないなと思いましたけれど、 別に仕事じゃないですし、みんなが各々好きにやってるのをみて笑ってるくらいがちょうどいいんだと思いました。 宿についてまずやったこと 誰がどの機能をつくるかと、GIGAZINE企画のやること一覧を大きな紙に書いて貼りました。 みんながこれを見てくれたのかは知りません。ただこういうことをやってみたかったのです。 個人的には合宿感が高まりました 開発スタート ブリーフィングとして、開発を始める前に各チームに対してやりたいことを伝えていき、自分も開発をスタートさせました。 とても驚いたのは自分からやったインプットはそれくらいで、あとは各メンバーが自律的に各々の開発をうまく進めていってくれたことです。 合宿という限られた時間内にアウトプットを出すためにスコープをよしなに切ってくれたり、 新卒1年目の方も周りの先輩をうまく頼りながら開発を進めたり。 各チームがバッグブリーフィングを適切にしてくれたのでこちらも心配なく作業を任せることが出来ました 。 メンバーの1人が小型のプロジェクターを持ってきてくれていたのですが、会社以外でチーム開発をするときはとても便利ですね。 レビュー会が開きやすい。 ディスプレイを持ち歩くよりコンパクトですし、専用の設備がない宿で開発合宿を行うのであれば必需品だと思いました。 ごはんは大事 これも驚いたことなのですが、手の空いた方達が自律的に炊事や食器の後片付けをしてくれました。 ヘビーな開発をしている連中が開発に集中できるように大きなサポートになったと思います。ありがとうございました。 開発合宿でアヒージョが食べられるとは思わなかったです。 とてもおいしかった いい景色 飲酒開発 夕食を終えてからはお酒を飲んで開発を行いました。 すぐ眠くなる方がいたり、テンションが上がってウキウキで開発する方もいたり面白いものが見れました。 自身の開発を終えたメンバーから就寝していきました。 ランニング 翌朝マラソンするメンバーは箱根に向かう十国峠をランニングしました。 普段走っていないPdMも走りましたが、登り降りで往復6kmを完走。 これからも一緒に走りましょうね。 翌日の筋肉痛が大変だったらしい チェックアウト 無事開発合宿を完走し、みんなで後片付けをしてチェックアウトしました。寂しかったなぁ。 被写体に叫んでもらうといい感じの写真が撮れるとのこと 合宿を終えて 本番環境へのデプロイ回数 8回 たくさんデプロイできたと思います。 機能開発 開発予定だった 4機能中、3機能は本番リリース完了 まで漕ぎ着けました。 残りの機能に関しても、翌週の業務で開発を終えて本番リリースすることが出来ました。 GIGAZINE企画 サウナに入ったら眠くなってしまったので、サウナ整い開発に関しては検証できませんでしたが、他は色々試すことが出来て楽しかったです。 ただ開発するだけではなく、普段できない開発をやってみることで 開発合宿に深みが出た なと自己満足しています。 総括と今後 メンバーのおかげで成果を出せた チームメンバーにも恵まれていますが、フットワーク軽く誘いに乗ってくれたゲストの方々がいたおかげで、 想像以上の成果をあげることが出来た開発合宿だった と思います。 オールインハウスの強み 弊社は開発営業マーケティング部門を網羅的に揃えているオールインハウスの会社です。 NALYSYSは社内でも利用しているサービスであり、 社内顧客からのFBも参考にしながら開発を進めています 。 今回は事業部外の方にもご参加いただき仲良くなれたので、FBをもらえるパイプを増やすことが出来ました。 今後製品開発を進めていく上でよい状況が作れた と思います。 開発合宿おすすめです 開発に集中できるように食事付きの宿にすべきだったことや開発要件の計画性の無さからくる場当たり的な人員調整等、反省する点は多々ありました。 ただ、いろいろな調整がめんどくさいからという理由で やるか迷っている方はとりあえず自費でやってみることをお勧め します。 PoCとしての成功 この合宿の結果を事業部長が社長に見せてくれたおかげで、 正式に合宿の予算が取れることになった ようで、PoCとして大成功でした。 事業部長が話を更に大きくしてくれて、 事業部全体で開催する運びになった そうです。 事業部長と社長の距離が近く、そういった調整がスムーズに口頭で進む点も弊社の面白いところなのかなと改めて思いました。 最後まで読んでくれた方へ これからも開発合宿は継続的に行われていくと思います。 どうせ開発職として働くのであれば開発って楽しいなと思いながら働きたいと思っている方も多いと思います。 もしかしたら弊社であればそれを叶えられるかもしれません。 ご興味を持っていただけた方がいらっしゃいましたら是非以下の採用サイトからご応募してみてください。 recruit.leverages.jp 我々の普段の開発の雰囲気はこちらのYouTubeをご覧ください。 youtu.be 我々の作っているSaaSはこちらになります。 nalysys.jp

はじめに こんにちは。 25卒でLeveragesに新卒エンジニアとして入社予定の、いつきと申します。 エンジニアとして内定をいただいたものの、元々はマーケ職志望で、プログラミング経験は皆無です。 そのため、今は内定者インターンで、同期に先んじてエンジニアのイロハを叩き込まれているところです。 この記事は、そんな私から、今Leveragesを候補に入れて就活を頑張っている方に向けて送る記事になっています。 こんな方は読んでほしい Leveragesを候補に入れて就活中の方 今までエンジニア職という選択肢を考えたことがない方 何を考えて就活していたのか マーケ職希望なのになぜエンジニアになったのか Leveragesって、実際どうなのか 未経験でエンジニアはやっていけそうか などなど。 参考になるところもあれば、まったく参考にならないところもあると思いますが、 就活を頑張っているあなたのお役に立てれば幸いです。 軽く自己紹介 現在、大学4年生です。 化学に魅せられて理系へ ⇨ まわりが強すぎて研究者は断念 ⇨ 就職を考え経済学部へ ⇨ モラトリアムを延長するため休学 ⇨ 休学 ⇨ 休学 ⇨ 休学 という経歴をしてます。 休学中は、フリーランスの動画編集者をやりながら2週間ごとに住む場所を変えて全国を巡ったり。 オンラインの動画編集スクールで教鞭を取ったり。 ゲームの社会人サークルを立ち上げて、週1で1年間ほどオフラインの大会を開いたり。 そんなこんなで1年ほど前に、そろそろ落ち着くかということで就活を始めた人間です。 就活、何考えてた？（前編） さて、就活をする！となると、まず考えることは「どこを目指すか」ですよね。 今悩んでる方も多いのではないでしょうか？ 私が就活で会社を選んだ大きな軸は2つです。 ・領域が多岐にわたる事業会社であるか ・できることなら若手のうちから裁量権が欲しい よくある話ですね。 4年間のモラトリアムを経てなお、この分野！というものが決めきれなかった私からすると、色々な領域への挑戦が奨励される会社の方が、魅力的に映りました。 そして、せっかくなら自分がやろうと思ったことは、積極的にやらせてもらえる会社がいいと思ったのです。 この時点では、いわゆるベンチャー企業を広く見ていました。 就活、何考えてた？（後編） その上で、ベンチャー企業をさらに絞り込むときに見たのは ・規模による自由 ・会社自体の自由 の２つです。 まずは規模について。 例えば、従業員10名前後のスタートアップは入社すればなんでもやれるでしょう。 しかしそれは、「やりたい！挑戦したい！」と思ったことをやるというより、「（ヒトやカネが足りないから）やらざるを得ない」という文脈が強いと思ったのです。 裁量権はあっても、使えるリソースが少ないのであれば、やりたいと思ったことに挑戦はしにくいのかもしれない。 であれば、規模はある程度大きい方が良いはず。そういった観点から、ベンチャーの中でもメガベンチャーに焦点が定まりました。 しかし、規模が大きくなると次の問題があります。 それが会社自体の自由、つまり権利者による制約です。上場企業となると、会社の意思決定は社内だけではできません。社外の株主が、意思決定に絡むことになります。 こうなると、「やりたい！挑戦したい！」と思ったことについて、「社内」では積極的に後押しする文化があったとしても、「会社の外の人」によってNGが出る可能性があります。 前述の規模による自由の方が大事ですが、やりたいことに挑戦するためにはできれば未上場の方がいいのです。 規模は大きくて、上場はしていないメガベンチャーの事業会社。 この検索条件で残ったのはLeveragesだけでした。 そんなわけでLeveragesメインで就活を始めます。 職種は特にこれといった志望はなかったので、適性検査の結果を見て営業・マーケへ。 プログラミング経験なんてないので当然と言えば当然ですが、この時点ではエンジニアという選択肢は考えにありませんでした。 Leveragesへの就活（前編） さあ、いざ就活本番です。 途中の面接はトントン拍子に進んだものの、最終面接で役員の藤本さんから衝撃の一言。 「君はマーケティング向いてない」 事前に人事の方から「君マーケティング向いてそうだね〜」と言われてすっかりその気になってたこともあって結構ショック。最終面接フツーに落ちました。 …落ちたのですが、続いてさらに衝撃の提案が。 「気質的にエンジニアに向いてると思うんだよね。エンジニアとして働いてみる気はない？」 いや、そんなことある？？？ 「自分、プログラミング経験ないですがいいんですか？」 当然の確認ですが、 「エンジニア側でまた面接受けてもらう必要はあるけど、要件としては大丈夫だよ」 とのこと。まじですかそれ。 しかし、マーケティング志望で不合格だったからエンジニアになる、というのも短絡的すぎる。そもそも自分はエンジニアとして働きたいのか？そして働けるのか？ ということで、Leveragesでエンジニアとして働くということについて立ち止まって考えてみることにしました。 Leveragesへの就活（後編） まず、そもそも自分はエンジニアとして働きたいのか？ 確かに、エンジニアのスキルは事業会社でやっていく上で大きな武器になります。 もし将来的に企画や営業に移るとしても、開発側の視点を持っていれば、チームワークもスムーズになるはず。 何より、エンジニアとしてサービスを作れるようになるということは、「ものづくりによる社会貢献」そのもの、つまり事業会社の根幹を支えることです。 やったことがないから選択肢には入れていなかったものの、いざ考えてみると自分にとって魅力的な職業に思えます。 次に、働けるのか？ 繰り返しになりますが、未経験です。周回遅れのスタートになります。 しかし先ほど考えて、やる気はあるとわかりました。 学ぶ意欲はあります。 であれば、やるだけです。幸いにも、勉強には多少の自信があります。 こうして改めて、エンジニア職の選考を受けることに決めました。 そして、エンジニアへ 1ヶ月後… エンジニア部長との面接に臨みました。志望した経緯は正直に伝えた上で、エンジニアという仕事を通じて実現したいこと、そしてエンジニアとしてどのように成長していきたいかを具体的に話しました。技術的な知識はなくても、ものづくりへの情熱と学ぶ意欲、そして何より、Leveragesで働きたいという意思が伝えられたこともあってか、内定をいただくことができました！ いざ、内定者インターン さて、見事内定をいただいたわけですが… 当然ながら、内定をもらったからといってプログラミングはできるようになりません。コードは読めないままです、どうしましょう。 とりあえず入社までに、少しでも勉強するかと思っていたら、 なんと、内定者向けのインターンがあるそうじゃないですか。行くしかない。 そんなわけで、人事から提案のあった内定者インターンを2つ返事で承諾し、9月から レバレジーズのHRTech系SaaS NALYSYS の開発チーム でインターンをすることになりました。 最初の1週間は開発で使うTypeScriptの基礎を学習。 その後は早速、実際の業務の中でトレーニングを行うOJT形式で実践的なスキルを磨くことに。 ここは複数の事業を展開しているメガベンチャーのいいところかもしれません。 やることがたくさんあります。難しいことも、簡単なことも。
 難易度が異なる様々なタスクが豊富にあるため、初心者でも無理なくステップアップできる環境が整っていました。 今は主に、バックエンド開発でApolloGraphQLを使い、Web向けのクエリ言語であるGraphQLのAPIクエリを実装して、フロントエンド開発で実装したAPIを用いて値を取得し、Reactフレームワークで作った画面に繋ぎ込んだりしています。 プログラミングなんてやったことがないと何を言ってるかわからないと思いますが、 なんとなく、「4ヶ月で開発に合流できるくらいにはなったんだ。」と思ってもらえれば大丈夫です。 実際どう？未経験でもエンジニアとして働けそう？ 結論から言うと、働けそうです！ 先輩エンジニアからの丁寧な指導はもちろん、実際の開発業務を通して学んだことを発揮できるので、着実に成長を実感できているのが嬉しいですね。 先ほども言った通り、難しいことでも簡単なことでも、やれることがたくさんあるので 今の自分のレベルでも、会社に貢献できることがあることが働く上では楽しさを感じられます 特に印象的だったのは、自分が開発に携わった機能が実際にリリースされた時です。ユーザーのフィードバックを受け取り、自分の仕事がサービスの成長に繋がっていることを実感した瞬間は、やはりやりがいを強く感じます。 もちろん、まだまだ勉強することは山積みです。 ただこの会社であれば、自分の学ぶ意欲・成長しようとする意思があれば、なんでもできそうだと思っています。 インターンしてみて感じた、Leveragesという会社 今、Leveragesを受けようと思っている方からすると、一番気になるところかもしれませんね。 自分の受けた印象を一言でまとめると、イメージしていた通りの会社...でしょうか。 ・社内リソースが多く、裁量権が大きいので意思決定が早い。 ・『やるからにはNo.1を目指す』 ・声を上げれば、聞いてもらえる。手を上げれば、やらせてもらえる。 ・社員全員が向上心をもち、高めあうことができる。 こういった紹介は、正直、どの会社も言うことではありますが、 実際にそれが行動として伴っているのは、Leveragesの大きな魅力だと思います。 だから、説明会を聞き、人事や現場社員との交流を経て「この会社楽しそう...！」「自分もここで働きたい...！」と思ったのなら、きっと楽しく働けると思います。 （逆に、そこまで頑張るモチベは湧かないかも...と思った方は、合わないのかも。） 終わりに ここまで読んでくれた方の中には、（ちょっとエンジニア面白そうだな...）と思った方もいるかもしれません。 ぜひ一歩を踏み出していただければ、筆者冥利に尽きます。 Leveragesも新卒のエンジニアは、 経験未経験を問わず募集 しているそうなので、一歩踏み出してみてはいかがでしょうか？（特大宣伝） 最後に、実際のエンジニア現場の雰囲気がわかる動画が、最近Youtubeに上がったので、興味を持った方はみてみてください。 www.youtube.com

はじめに こんにちは、レバレジーズ システム本部のVPoEの田中です。 この度、エンジニア組織をエンハンスすることを目的とした人事戦略チームを発足しました。 今回は、エンジニアの採用・教育・評価や組織のエンジニアリングに興味を持つ皆さんに向けて、私たちの取り組みやミッションについてお伝えさせてください。 ミッション エンジニア特化の人事戦略チームのミッションは、「 エンジニアが顧客への価値提供・価値創出に集中できるようにする 」ことです。 私たちは、エンジニア一人ひとりが最大限のパフォーマンスを発揮できるよう、人材開発、組織開発、制度・環境の整備に邁進しています。 上記ミッションに基づいて、エンジニアリング組織の持続的な成長を支えるために、以下の業務に従事しています。 業務内容 エンジニア採用の強化 広報活動 環境・制度の整備 人材開発・組織開発の強化 社内外との接続点の構築 エンジニア特化の人事戦略チームが発足しました 自己紹介 レバレジーズ システム本部に所属しているVPoEの田中です。 2022年9月に中途入社でHRテック事業部にジョインし、エンジニアリングマネージャーとしてNALYSYSの開発に従事していました。今からちょうど1年前に事業部横断でのエンジニア組織マネジメントを行ってみないかというお話をいただき、VPoEとしてエンジニアの人材開発・組織開発に従事しています。 チーム発足の略歴 最初は、2024年1月ごろから私1人で動き始めました。 当初は、エンジニア組織全体として新卒採用のPDCAをしっかり回せていなかったこともあり、新卒採用全体の指揮を取ることから始まりました。また、オフィス移転の話が上がっていたので、ファシリティマネジメント（オフィス設計）も並行して行っていました。エンジニアのバックグラウンドしかなかった私にも新卒採用の全体指揮や200〜300人規模のファシリティマネジメントを任せていただけたのは弊社ならではなのかなと今では思います！ その後、2024年4月に1名ジョインし、チームとして発足しまして、この時は元々進めていた事を遂行しつつ、チームとしてどのように本質的問題に取り組んだり価値提供をして組織に貢献できるかを試行錯誤していました。 チームとして発足して3ヶ月後にさらにもう1名がジョインしてくれまして、現在は3名体制で業務に取り組んでいます。チームとして発足して半年が経過したので、この機にどんな方向性でどんな事をしているのか紹介いたします！ 具体的な業務内容 当初は1人だったが故に出来ることも限られていましたが、現在では3人に増えているため業務幅も広がっています。 改めて、現在におけるチームとしての具体的な業務内容を紹介いたします。 エンジニア採用の強化 新卒採用： 戦略策定、インターンやイベントの企画と実行、面談・面接など、新卒採用の全ての工程に関わっています。 また、入社後にいち早く活躍してもらえるように活躍プラン（いわゆるサクセッションプラン）の策定にも携わらせて頂いております。 中途採用 現場マネージャー・現場リーダー・人事と連携をとりながら採用戦略の策定、面談・面接、などに携わっています。 採用サイトLP等を企画〜開発まで行っています。 広報活動 テックブログ、YouTube、カンファレンススポンサー、会場スポンサーなど、各チャネルを通して、弊社の技術力や雰囲気や文化を発信しています。 環境・制度の整備 エンジニア支援制度やオフィス環境の最適化などを通して、エンジニアが価値貢献をしやすい環境づくりを推進しています。 人材開発・組織開発の強化 エンジニアの成長をサポートする制度や評価の整備を行っています。 評価制度システムは一部内製しているため、システム開発も行っています。 社内外との接続点の構築 他職種や他事業部、さらには社外のコミュニティとの連携を深めています。 参考記事 tech.leverages.jp tech.leverages.jp どの業務も一つ一つが大きなプロジェクトであり、エンジニア人事戦略チームだけでは推進しきれていないため、基本的には、各開発部署メンバーと一緒に上記業務に取り組んでいます！ レバレジーズについて少し紹介 複数の領域にて様々なプロダクトを通して事業を展開しています。 創業〜拡大まで、様々なフェーズの事業があります。 また、オールインハウスでの事業開発・プロダクト開発／運用を行っており、職能を越境して業務に携わることができます。 さらに、エンジニアが成長するためのサポートおよび制度を一部紹介します。 資格や技術書や研修などの自己研鑽に励んでもらうための制度は豊富に用意しており、チーム横断での情報交換やナレッジ共有の機会も多く提供しています。 そもそもなぜ発足したのか 当初は専任として、現在はチームとして、現在に至った背景といたしまして、以下の3点が大きな理由です。 エンジニア採用の強化 IT業界の急速な発展に伴い、優秀なエンジニアの需要はますます高まっています。 私たちの組織も例外ではなく、事業拡大や新規プロジェクトの立ち上げに伴い、エンジニアの増員が急務となっています。 新卒採用では、未来の可能性を秘めた若い才能を発掘し、長期的に企業と共に成長できる人材を求めていますし、中途採用では、即戦力となる経験豊富なエンジニアを迎え入れ、多様な視点とスキルを組織に必要としています！ そのためエンジニア採用の強化が必要不可欠でした。 人材開発・組織開発の強化 エンジニアが自身の能力を最大限に発揮し、組織全体がシナジーを生み出すためには、人材開発と組織開発が不可欠です。個々のキャリアパスを明確にし成長を支援する制度や環境を提供していますが、それらの運用はもちろん継続的な改善も重要となります。 また、組織としての学習文化を醸成し、知識の共有やフィードバックを積極的に行うことで、継続的な人材力・組織力の向上を目指しています。 このように人材開発・組織開発を常に行いつづけることで一人一人の競争優位が高く、組織としても業界No.1を築いていく力を養っていく必要性があります。 社内外との接続点 弊社はレバテックやレバウェルなどの認知度の高いサービスから、レバクリやNALYSYSなどこれからよりグロースしていくプロダクトなど、複数の事業を展開しています。 そのため、弊社に所属しているだけで、創業期〜拡大期の様々な事業フェーズに携わる機会があり、さらにはオールインハウスの体制であることから自身のキャリアパスを自由に創っていけるメリットがあります。 これらのメリットを個人としても組織としても最大限に活用してもらうため社内の接続点を多く設けることが重要と考えています。 また、オープンイノベーションの時代において、技術広報活動やイベントを通じて、他企業のエンジニアやコミュニティとの交流を深め、新しい知見や技術を積極的に取り入れていくためにも社内外との接続点の形成が必要になってきます。 これらの理由より、専任で働きかけるチームが必要と考え、メンバーを募ってチームとして発足させました！ これからどんなチーム・組織にしていきたいか エンジニアが顧客への価値提供・価値創出に集中できるようにするために 私たちは今まで、”エンジニアが本質的な業務に集中できるように”という目的のもと、 時にはリクルーティングに関する知識やスキルを持って、エンジニアの可能性を一緒に探して最大化するサポートをし、 時にはエンジニアリングの知識やスキルを持って、サイトやシステムの保守運用・改善を行い、 時にはマーケティングの知識やスキルを持って、広報活動を通して情報発信に注力してきました。 私たちのチームは、様々な知識やスキルを身につける必要があり、多方面の協力が必要不可欠なためコミュニケーション能力や求心力を持っていく必要がありますが、 第一線で戦っているエンジニアはより専門的でより高度な知識とスキルを磨いて継続的な価値の最大化を図っているので、 全員が自由かつ有意に働けるチーム・組織にしていきたいと思います。 さいごに 改めて、レバレジーズ システム本部の人事戦略チームは、エンジニアが最大限の力を発揮できる環境を作るために、日々取り組んでいます。 私たちは、まだまだ多くの課題に直面していますが、それらを乗り越えることで組織全体が成長すると信じています。 ◆We are hiring! 組織開発やエンジニアリングに情熱を持ち、課題解決に積極的に取り組みたい方、そして新しい環境で自分の可能性を広げたい方をお待ちしています。 詳細な情報や採用に関するお問い合わせは、 エンジニア採用サイト をご覧ください。 私たちと一緒に、未来のエンジニアリング組織を創り上げていきましょう。

8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベントのみならず、共催イベントの開催、イベント登壇と多様な関わり方で、合計7件のイベントに参加しました！ ◆主催・共催技術イベント 【VPoE Meetup Vol.1】VPoE経験者が語る VPoEに求められる役割徹底解剖 弊社の開発拠点であるMiyashita Branchのセミナールームで、VPoE等が一堂に会し、これまでの経験や実践的なノウハウを共有するイベントシリーズを開催しました。50人を超える参加者と共に弊社、株式会社メドレー、株式会社ココナラのVPoEの方々が登壇しました。 （イベント詳細は こちら から） 【VPoE Meetup Vol.2】 VPoE経験者たちに聞くVPoEキャリアへのマイルストーン VPoE Meetup Vol.1に引き続き Vol.2 も弊社の開発拠点であるMiyashita Branchのセミナールームで開催しました。Vol.2 でもVol.1と同じく50人を超える参加者が集まり、株式会社SODA、株式会社Legalscape、ファインディ株式会社、株式会社スペースマーケットのVPoEの方々が登壇してくださいました。 （イベント詳細は こちら から） レバテック×イオン ~事業会社を支える開発組織のBizDevOps戦略~ レバテックとイオンが共同して、弊社の本社であるスクランブルスクエア25Fのセミナールームで開催しました。 （イベント詳細は こちら から） speakerdeck.com 成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る レバテックとsansanが共同して、「成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る」というタイトルでオンラインイベントを開催しました。（イベント詳細は こちら から） ◆イベント登壇 Product Engineer Night #6 プロダクトエンジニアを育む仕組み・施策 メディアシステム部IPLグループの金が、Product Engineer Nightに登壇しました。（イベント詳細は こちら から） speakerdeck.com ◆イベントスポンサー TSKaigi2025 キックオフ 10/9に行われたTSKaigi2025 キックオフにて、レバレジーズのエンジニア拠点であるMiyashita branchのセミナールームを提供しました。（イベント詳細は こちら から） Security.any #01 セキュリティあるあるLT 11/19に行われたSecurity.any #01 セキュリティあるあるLTにて、レバレジーズのエンジニア拠点であるMiyashita branchのセミナールームを提供しました。またレバテック開発部の松浪が登壇しました。（イベント詳細は こちら から） speakerdeck.com ◆We are hiring! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、 こちらのページ からご応募ください。

はじめに システム本部レバウェル開発部部長の高木です。 レバレジーズでは、企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、各個人の成長を促す」ことを掲げており、社内で様々な学習支援制度を設けています。 開発組織でも、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! レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。