はじめに こんにちは！6月にレバテック開発部に中途で入社した宮下です。 まだ入社をして1ヶ月も経っていませんが、新参者だからこそクリアに見える会社のGoodな部分をあげていきたいな〜と思います🌟 良いところも悪いところも、長く居ると慣れて当たり前になってしまうので、当たり前になる前にアウトプットします。 1️⃣ 人との繋がり 人との繋がりが強いな！って思ってます。 この要素がGoodになるかどうかは人によりますが、私にとってはGoodでした。 人との繋がりって何やねんって感じですけど、"コミュニケーションの量と範囲"と捉えてもらえたらいいと思います。 具体的には以下の3つが大きな要因になっていると思っています。 Good&New 雑相会 週3出社以上 Good&New こちらは、24時間以内にあった「良かったこと（Good）」や「新しい発見（New）」を共有する会のことです。レバテック開

はじめに どうも、レバテックでCREを進めている住村です。 レバテック開発部では社内でテックブログ執筆を促進するためのキャンペーンをやってまして、前回の記事がなんと社内のテックブログ執筆のキャンペーンで賞品をいただけました！ 賞の連絡をくれた編集長が「何でもいいよ！」と言ってくれたので、遠慮なく犬用の服を選ばさせていただきましたが、それで実際買ってくれたので凄いですね。 賞品を着た愛犬。この数分後に芝生で転げ回り、早々に汚しました 今回の記事では、前々回の記事で少し触れた、業務の選択と集中について書いていきます。 想定読者 事業会社のエンジニア 規模に対して人員が不足気味で、タスクの調整や優先度の意思決定をするレイヤーが不足 なるべくコストをかけず、出来る範囲で該当レイヤーの負荷を減らしたい やったこと チームの状況 現在、レバテックのCREチームではシステム化対象の領域を可視化/計測し、

初めに レバテック開発部の今井です。 ソフトウェア開発において、データの状態管理は非常に重要です。注文の状態、ユーザーの認証状態、プロジェクトの進行状態など、多岐にわたる状況で、適切な状態管理が求められます。しかし、ビジネス要件の変化や新機能の追加に伴い、状態管理が複雑化し、保守が難しくなることがあります。 この記事では、データの状態管理を簡単にするためにMECEを初めとした方法で分析を提案します。これによって、柔軟で効率的なシステム設計が可能になることを目指します。 TL;DR MECEの原則を使ってenum型ステータスを分解する方法を解説する MECEによる分解から一次情報と二次情報という区分を提案し、分析の高度化を目指す 一次情報と二次情報の区分とシステム間のデータ連係の関係性について考察する 対象読者 システムの保守性・拡張性に興味関心のあるエンジニア enumをMECEに分解する

はじめに レバテック開発部の江間です。 この度、私が所属しているレバテック開発部にE2Eテスト自動化SaaSのAutifyを導入しました。 4月中旬より利用を開始して『Autify大臣』なるものをやらせていただき、導入推進を始めて2ヶ月ほど経過しました。 先日、開発チーム向けにオンボーディングをして、ひとやま超えたタイミングで導入経緯・導入準備などについて振り返ってみたいと思います。 導入経緯 レバテックでは下記のような様々な課題がありました。 1. E2E自動テストコード管理コストの増加 OSSツールによるE2E自動テストを実施しているチームでは、メンテナンスにコストの増加が問題になってました。 ライブラリ更新の手間、コードメンテナンスの手間、複雑化するコード、そして実行されずに残骸になるコード、、、というあるあるの現象です。 2. 手動による受け入れテストの手間 レバテックでは、マーケ

はじめに はじめまして！ レバテックでサービスサイトにおけるデザイン制作のディレクター兼デザイナーを担当しているカリヤです。 現在は日々の進行管理業務に加え、デザインシステム『VoLT』の構築と運用に取り組んでいます。 構築していく中でも、コンポーネント作成は特に大変でしたが多くの学びも得られました。 今回は、デザインシステムを構築していくにあたって、レバテックの各プロダクト共通で使用するfigmaのマスターコンポーネントの具体的な構築方法についてどのように進めたのかを共有します。 まずやったこと まずやったことやコンポーネント管理にどんな問題があったのかなど詳しいことに関しては、以下の記事で解説しているのでこちらもチェックしてみてください！✨ これまでのFigmaのコンポーネント構築にどんな問題があったか 『VoLT』ができる以前にもfigmaのUIライブラリは運用されていたが、作成・構

はじめに 業務委託の丹羽です。 レバテックフリーランス経由で、レバテック開発部のSREチームに業務委託で参画させていただいています。 業務委託の私でも、我が物顔でレバテック開発部のテックブログに寄稿して構わないとのことなので、今回は掲題の件について、振り返りながら記事にさせていただきます。 ざっくりこんな人 AWSの基盤となるクラウド部分と、EC2内部でOS・ミドルウェアをメインに、各パラメータを修正したり、それらをAnsibleに書き起こしてCodeCommitで管理しているくらいのIaC経験があるインフラの人でした。 そこからスキルアップと挑戦をしたいという思いで、フリーランスに転向してSREやDevOpsに興味を持ち始めた人です。 SLI/SLO...？ CICD...？ 何それ、美味しそう！ 話したいこと フリーランスってどんな仕事してるの？ レバテックフリーランスに興味のある方は

はじめに マイクロサービスを構築する大きな利点に独立デプロイ可能性という考え方があります。 独立デプロイが可能な状態とは他のシステムに依存することなくそのマイクロサービス単体でデプロイできる状態のことを指します。 マイクロサービスの運用では単一サービスを単一チームで運用することが理想とされています。 しかし、実際の開発現場では単一サービスを単一チームで運用することは難しく妥協点を見つけていく必要があると考えられます。 レバテックでは他のチームから独立してデプロイ可能なチームを編成したのでその背景とメリット・デメリットを考察します。 レバテックの状況 レバテックシステムの全体像 フリーランス向けのサービスに限定してもユーザーのサービス利用フェイズやシステムの利用者の違いによって複数のシステム/プロダクトを運用しており、以下のようなサービスがあります。 ユーザーのランディングページとなるオウン

それデイリーやない。レイニーや。 はじめに こんにちは。学園アイドルマスターにハマっているスクラムマスターの池永です。 レバテック開発部ITSプロダクト開発グループに所属しており、日々チームが強く、楽しくなれるように試行錯誤しております。 先日、以下の記事を投稿したのですが、他のスクラムイベントにもあるあるはあるよなと思い、デイリースクラムのあるあるも早く言いたくなりました。 こちらも何か参考になる情報がありましたら幸いです。 話すこと スクラムにおけるデイリースクラムのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと スクラムにおけるデイリースクラムの詳細な目的 デイリースクラムの具体的な進め方 では早速... 例に漏れずあるあるを早く言いたいので、挙げていこうと思います。 1. ただの進捗報告会になりがち スクラム導入間もないチームでは、デイ

Renovateとは ライブラリの依存関係を検出し、バージョンを自動更新してくれるツール。様々な言語やバージョン管理ツールに対応している。(公式サイト) 類似ツールはDependabot 導入背景 自分が担当しているシステムはyarn+Node構成でライブラリの定期メンテナンスはGithubActionsでyarnコマンドを駆使して頑張って自動化していましたが、yarnV4へのメジャーバージョンアップ対応でのコマンドの非互換や仕様変更によりGithubActionsが動かなくなってしまいました。 GithubActions内で使用するActionsやコマンド自体のメンテコストもあったため、もっと楽な方法はないか模索した結果Renovateを導入することにしました。 事前準備 PATを作成しておく GithubでRenoavte用にPAT(Personal Access Token)を作成し

はじめに 今朝、こんな記事を読みました。 ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されたという内容でしたが、にわかには信じがたい内容だったので研究結果の考察をしてみました。 違和感の正体 まず記事に目を通し、この記事の主張は下記だと読み取りました。 高品質のソフトウェアを予定通りに納品するためにImpact Engineeringの哲学を学ぶべきだ こちらを読んで私は、3点の違和感を感じました。 本当にソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高いのか？ 予定通りに納品するという成功の定義はアジャイルにも当てはめて良いのか？ そもそもアジャイルは価値観だが、Impact Engineeringは全く

はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画

はじめに はじめまして！ レバテックでプロダクトデザイナーをしている成田です。 現在は日々のプロダクトデザインの業務に加え、デザインシステム『VoLT』の構築と運用に取り組んでいます。 なんとか社外公開まで漕ぎ着けた『VoLT』ですが、プロジェクトが開始してすぐの頃は「無理だ」と弱音を吐きたくなるほど課題が散見されていました。実際、私は何度も「え〜無理なんだが」と声に出しながら作業を進めていました（笑） 本記事では、Figmaでのコンポーネント管理の話を中心に、抱えていた課題を解決するために生み出した 「インスタンスガイドライン」 というものについてお話しできればと思います。 ちなみに、デザインシステム構築の背景や目的が書かれた記事も公開されているので、気になる方はぜひチェックしてみてください👏 何が難しい？レバテックのデザインシステム デザインシステムは、定義すること自体は難しくありま

はじめに こんにちにんにん、 art です。 僕が所属するレバテック開発部では、最近デザインシステム『VoLT』が誕生しました。 レバテックでは複数のプロジェクトが運用されており、フロントエンドの技術スタックは Vue.js × Nuxt React x Next.js の２つが採用されています。 ですので、両方の技術スタックに対応したデザインシステムを作る必要があるわけですね。 あら大変。_(:3 」∠ )_ というわけでこの記事では、『VoLT』のUIコンポーネントライブラリを制作するにあたり、肝となったデザインシステムのマルチフレームワーク対応についてお話しします。 🔗そもそも『VoLT』とはなんぞや？構築の背景は？と気になった方は、こちらをご覧ください！ 想定読者 デザインシステムに興味のある方 これからデザインシステム関連の業務に携わる方 すでにデザインシステム関連の業務に携わ

はじめに はじめまして。レバテック開発部ITSプロダクト開発グループ所属の池永です。 私は現在スクラムマスターとしてチームに参画しており、日々チームが強く、楽しくなれるように試行錯誤しております。 かれこれ一年半ほどスクラムマスターを経験させていただいてきましたが、色んな壁にぶつかってきました。 特にスクラムにおける「ふりかえり（レトロスペクティブ）」において生じた壁について色んなエンジニアと話しているうちに、あるあるなんだなぁ〜と感じたため、この記事を書いております。 この記事では自身のぶつかってきた壁と、そこに対してどのようなアプローチを取ったか、そしてどうなったかを少しだけ共有しようと思います。 何かしらの参考になったら幸いです。 話すこと スクラムにおけるふりかえりのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと 色んなふりかえり手法に

はじめに どうも、認定スクラムマスターの瀬尾です。 弊社ではエンジニアの支援制度として認定スクラムマスター取得の補助があります。これを利用して Certified ScrumMaster （CSM） を取得したので、その研修で学んだスクラムの基礎をまとめ、更にふ〜んとなったことや疑問に思ったことについて書いていけたらと思います！ 私が受講したのは、Joe Justice 先生の認定スクラムマスター講座です。2日間の研修があったのち、Webテストを受けて合格しました。ちなみに合格すると合格証と下のバッジがもらえます。Linkedin にも資格を登録してもらえました。 受講の背景を簡単にまとめてみる 受講前の知識量は「開発部に参画してから1年くらいスクラムの開発メンバーとして働いた」程度のものだった 3ヶ月くらい、見様見真似でスクラムマスターのような動きをしてはいた スクラムがアジャイルの具体

『3カ月で改善！システム障害対応 実践ガイド』の著者 野村浩司さんに社内勉強会を開催していただきました！1 参加者として学んだことや感じたことをまとめていこうと思います。 登壇者 野村浩司さん（@nomurakuj） 株式会社インシデントテック代表。某大手SIerで金融システムの開発保守運用改善を12年担当。2023年9月19日に『3カ月で改善!システム障害対応 実践ガイド』を出版。 書籍は私も拝読しましたが、3ヶ月で障害対応の基盤を整える具体的な方法が書いており、実践しやすい内容でとてもおすすめです。 勉強会実施の背景 2月に開催されたDevelopers Summit 2024で弊社のかわうそ（syoryu89）さんと話をしたことがきっかけでした。 レバテック開発部内で障害対応やポストモーテムの進め方に課題を感じているチームが多かったこともあり、開催に至りました。 障害対応の改善ポイン

お疲れ様です。 レバテック開発部でDevRelを担当しているヤマモトヒロキです。 「月1本テックブログ執筆」を志しておりましたが、 GWの波に飲まれて4月執筆を逃してしまいました。人は怠惰な生き物です。 過去の記事はこちら。 やってみた 3行サマリ 仮説「開発生産性向上のキーファクターは、開発組織外にある」 「非エンジニア向けの開発生産性研修」をやってみた 研修設計の肝は①抽象概念インプット→②自社具体例→③理想行動の具体化 背景 現在私はDevRelやっておりますが、出自はマーケターで事業企画にキャリアの軸足を置いている、 ゴリゴリの非エンジニアです。 事業の責任者として事業を率いる立場と、 DevRelとしてイケてる開発組織を作り発信する立場の両方を経験したうえで、 「事業の継続的な成長と、開発生産性の維持向上の両立ほんと難しい～」 というあるあるな悩みと日々戦い続けている一人です。

はじめに はじめまして！レバテックでWebマーケティングをしている堀口です！ 普段はレバテックキャリア[1]におけるオウンドメディアの改善やシステムリニューアルPJのPM（プロジェクトマネージャー）に携わっています。 2023年度、レバテックキャリアは会員登録およびユーザーのスキル情報を回収する機能のUI・システムを大幅にリニューアルしました。このブログでは、私がこのプロジェクトのPMを担当する中で経験した数多くのしくじりの中から特に反省している5つのしくじりを厳選して紹介します。 自身への戒めと学びのため、また下記のような方に向けて少しでも参考になればと思い、恥をさらしていきます！笑 これからはじめてPMを担当する方 現在PMをする中でプロジェクトの進め方に悩んでいる方 いずれPMにチャレンジしてみたいと考えている方 TL;DR しくじり1 プロジェクトメンバーの責任範囲を明確にしなかっ

これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

TL;DR 改善のサイクルを設ける ふりかえりはふりかえりなのでふりかえる Actionはとりあえずやってみる。代わりに効果検証を忘れずに。 はじめに レバテックの多くのチームではスクラムに取り組んでいます。 今回は、自チームのレトロスペクティブのやり方とその設計背景についてまとめようと思います。 レトロスペクティブについて まず、レトロスペクティブについてスクラムガイドでは以下のように書かれています。 スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブには、以下の目的がある。 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 うまくいった項目や今後の改善が必要な項目を特定・整理する。 スクラムチームの作業の改善実施計画を作成する。 スクラムガイドに書かれているように、レトロスペクティブとはスプ