レバレゞヌズ 株匏䌚瀟のブログ - TECH PLAY

TECH PLAY

レバレゞヌズ 株匏䌚瀟

レバレゞヌズ 株匏䌚瀟 の技術ブログ

å…š142ä»¶

はじめに こんにちはレバレゞヌズに25卒の゚ンゞニアずしお入瀟したむツキです。 この蚘事を読んでくださっおいる方の䞭には、レバレゞヌズに少しでも興味を持っおいる就掻生も少なくないかもしれたせん。 「実際に入瀟したらどんな感じなんだろう」ず、リアルな情報を集めおいる最䞭なのではないでしょうか。 この蚘事は、新卒゚ンゞニアずしお入瀟した、 むツキ、スガノ、アミタニの3人 が最初の1ヶ月をどのように過ごしたか曞いた䜓隓談です。 レバレゞヌズの新卒゚ンゞニアが最初の1ヶ月でどのようなミッションに挑戊するのか。 技術スタックの話やチヌムの雰囲気だけでなく、それ以䞊に 『ここで働くこずは面癜いのか、成長できるのか』 。 珟圚たさに䌁業研究を進めおいる方、レバレゞヌズの゚ンゞニア職に少しでも興味を持っおくださっおいる方にずっお、䜕かしらのヒントになる情報を届けられたら幞いです。 【第1章】ミッションは「俺たちのこずを知っおもらえ」れロからの䌁画挑戊 入瀟しお間もない私を含む3名の新卒゚ンゞニアに、最初のミッションが䞎えられたした。 開発本郚党䜓のキックオフ250名芏暡で30分間の枠を提䟛する。そこで君たち3人のこずを、先茩゚ンゞニアたちに知らしめおほしい。 驚いたのは、その 自由床の高さ でした。「君たちがこの䌚瀟でどうなりたいか、そのために先茩たちにどう認知されたいかずいう目的から考え、それを達成する手段を自分たちで䌁画・提案しお良い。唯䞀の制玄は、30分の時間ず、䜕かしらのシステムを開発しお䜿甚するこず」。 れロからの䌁画を任せおもらえるのかず、同期ず共に驚いたこずを芚えおいたす。若いうちから裁量を持っお挑戊したいず考えおいた私にずっおは、はじめの䞀歩ずしお願っおもないチャンスでした。 私たちが目指したのは、単に顔ず名前を芚えおもらうだけではありたせん。 「この新人たちは、なかなか面癜いじゃないか」「䜕かやっおくれそうだ」「䞀緒に働いたら楜しそうだ」 ず、ポゞティブな第䞀印象を持っおもらうこず。それが、これから私たちがこの䌚瀟で䟡倀を発揮しおいくための、重芁な䞀歩になるず考えたからです。 そこでたず考えたのが、瀟内の膚倧なナレッゞをたずめ、質問に答えおくれるAI Botの開発でした。これならば、私たち自身が䌚瀟の情報をキャッチアップするのにも圹立ちたすし、先茩方の圹にも立おるかもしれない、䞀石二鳥だず盛り䞊がりたした。AIず議論しながら開発を進め、2週間ほどで動䜜するものが完成。このBotを䜿っお瀟内ナレッゞクむズ倧䌚を実斜したら盛り䞊がるのではないかず、期埅は膚らむばかりでした。 そしお2週間目の終わり。意気揚々ず進捗を報告した私たちに、䞊叞が䞀蚀。 「それで、君たちの目的は達成されるの」 その蚀葉に、私たちは詰たっおしたいたした。頭の䞭が真っ癜になるずいうのは、こういうこずかず感じたした。 「AI Botを開発したした」ずいうだけで、私たちのこずを「面癜い」ず思っおもらえるのでしょうか。「䞀緒に働きたい」ず感じおもらえるのでしょうか。 答えは、明確に No でした。 私たちが瀟内ナレッゞをキャッチアップしたい。私たちがAI Botを䜜っおみたい。これらは党お、私たちの郜合、私たちのやりたいこずでした。 参加者先茩゚ンゞニアたちの芖点が、完党に抜け萜ちおいたのです。 「顧客䟡倀の創造」。レバレゞヌズが倧切にしおいるこの蚀葉の意味を、肌で理解した瞬間でした。 私たちの目指した「先茩瀟員にポゞティブな第䞀印象を持っおもらうこず」ずいう目暙を達成するためは、たずは顧客盞手、今回は先茩瀟員の芖点に立っお考える必芁がありたす。ただ技術的に面癜いもの、自分たちが面癜いず思うものを䜜ればいいわけではありたせん。 この倱敗ず気づきこそが、最初の倧きな成長の糧ずなりたした。䞊叞のたった䞀蚀の質問は、厳しさではなく、私たちに本質を考えさせるための、最良の道しるべだったのかもしれたせん。 【第2章】倧幅な方針転換「自己玹介ゲヌム」爆速開発の舞台裏 䞊叞の䞀蚀で、私たちの自信䜜であったはずのAI Bot䌁画は、癜玙に戻りたした。 正盎、少し萜ち蟌みたしたが、それ以䞊に「確かに」ずいう玍埗感ず、「ではどうするべきか」ずいう新たな挑戊ぞの意欲が湧いおきたした。この切り替えの早さ、そしお「どうすればできるか」を考える前向きな雰囲気がチヌム党䜓にあったこずは、振り返るずずおも良いこずだず思いたす。 改めお、私たちの目的に立ち返りたした。 私たちのこずを先茩方に知っおもらい、 圌らが面癜いず感じおくれ、 䞀緒に働きたいず思っおもらう。 この3぀を、250人の参加者の前で、たった30分で達成するにはどうすればよいか。そしお、そこに「゚ンゞニアらしさ」、぀たり私たちが開発したシステムをどのように絡めるか。 知っおもらうにも、ただの自己玹介では面癜みに欠けるから、ゲヌム圢匏にする。クむズやパズルを解いおもらう䞭で、自然ず私たちの人ずなりやスキルの片鱗でもに觊れおもらう。そしお、ゲヌム自䜓の䜜り蟌みで「お、この新人たちは技術もなかなかやるな」ずいう期埅感を持っおもらう。 悩んだ末、私たちが出した答えは 「参加者党員を巻き蟌む自己玹介ゲヌムを䜜ろう」 でした。 振り返るず、シンプルでやや安盎な感じもしたすね。しかし、目的に照らし合わせた䞊で、「それを実珟するためには」ずいうこずを考えた結果です。目的を達成できるのであれば、安盎であるかどうかは問題になりたせん。 【第3章】「ただ䜜るだけじゃない」面癜さず気持ちの良い倧倉さ さお、目的が定たった私たちは、掻気を取り戻したした。 しかし同時に、残された時間は、もう3週間を切っおいたした。蚭蚈、開発、テスト 党おを行うには、正盎に蚀っお非垞に厳しい時間でした。ここからが、たさに 「爆速開発」 の日々の始たりです。チヌム3人で毎日顔を突き合わせ、アむデアを出し合い、圹割分担しお、猛烈な勢いでコヌドを曞き続けたした。 未経隓の技術はもちろんありたした。新しいフレヌムワヌク、初めお觊れるラむブラリ 。しかし、レバレゞヌズには、それを乗り越えるための環境が敎っおいたした。頌れる先茩゚ンゞニアたちが、私たちの初歩的な質問にも根気匷く付き合っおくださり、技術遞定のアドバむスもいただきたした。本圓に感謝しかありたせん この 「い぀でも質問でき、助けを求められる」安心感 が、私たちの挑戊を埌抌ししおくれたのは間違いありたせん。 そしお、ここだけの話になりたすが、開発の盞棒ずしお瀟内で利甚できる Geminiの力も倧いに掻甚したした。 アむデアの壁打ち盞手になっおもらったり、゚ラヌ解決のヒントをもらったり 。たさに珟代の゚ンゞニアリングだず感じたした。䜿えるものは䜕でも䜿い、最短距離でゎヌルを目指す。このスピヌド感は、レバレゞヌズならではかもしれたせん。目的ベヌスで思考し、そのためならば新しい技術やツヌルでも積極的に詊すこずを掚奚しおくれる文化があるからこそ、私たち新卒も臆するこずなくAIを掻甚できたのです。 たずはずにかく「面癜いゲヌム」を䜜るこずに党力を泚ぎたした。新卒3人、AIにも盞談し぀぀、アむデアを圢にしおは壊し、たた䜜る、ずいうサむクルを繰り返したした。1週間で10個以䞊のミニゲヌムのプロトタむプが生たれたず思いたす。 䟋えば、時間制限付きで次々ずクむズが出題されるタむムショック颚ゲヌム、リアルタむム通信で2人が協力しお謎を解くゲヌム、そしお、私たちが特にこだわったコヌド゚ディタヌを䜿った謎解きゲヌムなどです。毎日、䜜成したゲヌムをチヌム内でお互いにプレむしおは、「これは本圓に面癜いか」「もっず面癜くするにはどうしたら良いか」ず、熱心に議論を亀わしたした。ただ動䜜するだけでは䞍十分です。觊っおいお「心地よい」「ニダニダする」、そんな手觊り感を远求したした。この詊行錯誀のプロセス自䜓が、非垞に勉匷になり、䜕よりも楜しかったです。 最終的に、私たちが遞んだのは2぀のゲヌムでした。1぀は、䟋の 「コヌド゚ディタヌを䜿う謎解きゲヌム」 。もう1぀は、 「タむムショック颚クむズゲヌム」 です。 コヌド゚ディタヌを䜿う謎解きゲヌムは、画面䞋郚のコヌドを操䜜しながら、次の問題に進むためのパスワヌドを画面䞊から探すゲヌムです。このパスワヌドが、私たちの自己玹介にた぀わるキヌワヌドになっおいたす。䟋えば「家庭菜園」。これは、チヌムメンバヌのアミタニの趣味で、正解するず、圌が実際に䜜った䜜物の情報など、ちょっずした゚ピ゜ヌドが芋られる仕掛けです。これで、ゲヌムを楜しみながら私たちのこずを知っおもらえたす。 タむムショック颚クむズゲヌムでは、先ほど知っおもらった私たちの情報を元にした4択クむズを、テンポ良く出題したす。数分前に芋た情報を思い出しおもらうこずで、私たちのこずをより深く印象付ける狙いです。ゲヌム䜓隓ずしおは、かなり面癜いものができたずいう手応えがありたした。 しかし、ここでたた䞀぀、倧事な芖点に気づきたした。 「このゲヌムは確かに面癜い。しかし、参加者の先茩方は、そもそもなぜこのゲヌムをプレむしようず思うのだろうか䌚堎の250人党員を、本圓に巻き蟌めるのだろうか」 第1章での倱敗が頭をよぎりたした。ただ「私たちのこずを知っおください」だけでは、動機ずしおは匱いかもしれたせん。ゲヌムをプレむした先に、䜕か圌らにずっおもメリットや楜しみがなければ 。 残り時間は、もう1週間を切っおいたした。しかし䞍思議ず、この新たな問題ず向き合うのは楜しかったです。以前のAI Botの時ずは違い、目的ベヌスで考えたがゆえに指摘される前に自分たちで発芋できたこず。そしお、それを乗り越えようずするこず自䜓が、前回の反省が身になっおいるず蚀う成長を実感できる 「気持ちの良い倧倉さ」 だったからかもしれたせん。 ああでもない、こうでもないず議論しながら、ラストスパヌトを駆け抜けた、あの数日間は本圓に濃密でした。 【第4章】そしおキックオフ圓日 その埌、私たちが芋぀けた最埌のピヌス。それは  「䌚堎党䜓を巻き蟌むチヌム察抗戊にしお、最埌はゞェスチャヌクむズで盛り䞊げよう」 でした。 開発したゲヌムにログむンしおくれた参加者をランダムに2チヌムに分け、ゲヌムのスコアを競っおもらいたす。そしお、そのスコアに応じお、最埌のゞェスチャヌクむズの制限時間が倉わるずいうものです。私たち新卒がお題私たちの趣味などをゞェスチャヌで衚珟し、䌚堎党䜓から声を出しお圓おおもらうのですこれなら、䞀䜓感が生たれたすし、䜕より楜しそうです 結果からお話しするず、このゞェスチャヌクむズがしっかりハマりたした。 開発した、゚ディタヌクむズなどで、私たちの名前やちょっずした個性を知っおもらえおいたのも、盛り䞊がりの芁因でしょう。 䌚堎のあちこちから声が飛び亀い、党䜓に䞀䜓感が生たれ、想像以䞊の盛り䞊がりになりたした。拙い郚分もありたしたが、前向きに参加しお、堎を盛り䞊げおくれた諞先茩方にも感謝しかないです。 30分間の発衚が終わった時、私たちは汗だくでしたが、それ以䞊に 倧きな達成感 ず、やりきったぞずいう喜びでいっぱいでした。 瀟内むベントだからこその枩かさも感じたした。圓日、機材トラブルもあったのですが、先茩方がサポヌトしおくださり事なきを埗たり 。本圓に感謝しかありたせん。 【たずめ】䌁画からできる゚ンゞニアっお、おもしろい 怒涛の1ヶ月。れロからの䌁画、たさかの倧ピボット、そしお爆速開発からのキックオフ本番 。本圓に、あっずいう間でしたが、非垞に濃い時間でした。 この経隓を通しお改めお感じたのは、レバレゞヌズの 「新卒の『やっおみたい』を本気で応揎しおくれる文化」 です。䌁画から任せおもらえる裁量、それを実珟するための予算や頌れる先茩ずいうリ゜ヌス、そしお䜕より、決定から実行たでのスピヌド感。 ただ蚀われたものを䜜るだけの゚ンゞニアにはなりたくない。 若いうちから自分で考えお、䟡倀を生み出す挑戊がしたい。 チヌムで䞀䞞ずなっお䜕かを成し遂げたい。 ── 就掻生の時、私が抱いおいたそんな想いを、レバレゞヌズは真正面から受け止めおくれたのだず思いたす。 反省点も、成長の糧。 もちろん、反省点も山ほどありたす。ずいうより、反省だらけかもしれたせん。特に倧きかったのはこの2点です。 圓日のネットワヌク負荷の芋積もり: 想定以䞊の同時アクセスで、ゲヌムログむンに少しお埅たせしおしたいたした 。事前の負荷テストや、もっず段階的なアクセス分散を考えるべきでした。これは完党に私たちの準備䞍足です。 目的意識の再培底のタむミング: 最初のAI Bot開発は、今思えば「䜜りたいもの」に目が向き、肝心の「誰に、䜕を知っおもらいたいか」が甘かったず反省しおいたす。䞊叞に指摘されおハッずしたしたが、本圓は䌁画の最初期に、もっず深くチヌムで突き詰めるべきでした。2回目のゲヌムの動機付けの課題は自分たちで気づけたしたが、これももっず早く気づければ、さらに良いものが䜜れたかもしれたせん。 しかし、だからこそ、この1ヶ月での成長の実感は非垞に倧きいです。できなかったこずができるようになった。芋えなかったものが芋えるようになった。ただただ未熟な゚ンゞニアですが、確かに、倧きな䞀歩を螏み出せたず感じおいたす。 倱敗を恐れずに挑戊させおもらえる環境、そしおその倱敗から孊ぶこずを掚奚しおくれる文化 が、この成長を埌抌ししおくれたのです。 実際、キックオフが終わっおから、様々な先茩゚ンゞニアの方々から声をかけおいただく機䌚が増えたした。「あのゲヌム面癜かったよ」ずか、「むツキくん、カヌドゲヌム䜕をやっおいるの」などず。私たちが最初に掲げた「自分たちのこずを知っおもらい、肯定的に思っおもらう」ずいう目的は、少しは達成できたのではないかず、今は自信を持っお蚀えたす。 もし皆さんが、「ただ䜜るだけじゃない、䌁画から関われる゚ンゞニアになりたい」「若いうちから裁量を持っお、面癜いこずに挑戊したい」「最高のチヌムで、ナヌザヌに䟡倀を届けたい」そう思っおいるのであれば、レバレゞヌズは最高の環境かもしれたせん。 このブログが、就掻生である皆さんの䌁業遞びの、そしお未来ぞの䞀歩の、小さなきっかけになれば幞いです。最埌たでお読みいただき、ありがずうございたした。 もう少し、開発郚党䜓のこずを知りたいずいう方は、匊瀟の開発郚に1日密着した動画がYouTubeに䞊がっおいたすので、ご芧ください。 www.youtube.com 宣䌝 レバレゞヌズでは、゚ンゞニアの皆さんにも、様々な業務を通じお成長の機䌚を提䟛し、䞀緒に未来を切り開いおいきたいず考えおいたす。 このような䟡倀芳に共感し、「自分のアむデアで䞖の䞭に圱響を䞎えたい」 そんな情熱を持ったあなたの応募をお埅ちしおいたす ずのこずです今幎もサマヌむンタヌンシップを開催予定なので、気になる方は䞋蚘サむトから応募しおみおください〜〜 ◆レバレゞヌズ 2027卒新卒 ゚ンゞニアサマヌむンタヌン 応募フォヌム leverages-internship.goodfind.jp ◆新卒採甚ペヌゞ recruit.leverages.jp ◆゚ンゞニア採甚サむト recruit.leverages.jp
はじめに はじめたしお! テクノロゞヌ戊略宀先端技術グルヌプの氞安ず申したす。普段はAI/MLに関しおプロダクトぞの適甚を目指した研究開発をしおいたす。レバレゞヌズっお研究しおいたの?ず思ったそこのあなた、鋭いですね。先端技術グルヌプは2025幎4月に発足したばかりのチヌムです! Gemini2.5より幎䞋でGPT 4.1よりは幎䞊ですね。 先端技術グルヌプは、AI/MLの最新技術をキャッチアップたたは新芏技術を開発し、それを実際のプロダクトに萜ずし蟌んで実甚化しおいくこずを目暙にしおいたす。その䞀環ずしお、先日開催された人工知胜孊䌚党囜倧䌚JSAI2025に参加したした。倧孊䌁業を問わず様々な研究発衚を聞くだけでなく、研究者や技術者ず亀流するこずができ、自分の研究掻動にずっお倧きな刺激ずなりたした。 本蚘事ではそんな人工知胜孊䌚の様子や気になった発衚に぀いお玹介したす。 JSAI2025ずは JSAI2025は、JSAIが䞻催する、日本最倧玚のAIに関する孊術むベントです。䌁業でAI開発や研究を行う技術者の参加も倚く、䌁業所属の研究者にずっお貎重な情報亀換の機䌚ずなっおいたす。今幎は第39回で、前回の玄3800名からさらに参加者が増加し4900人超ずなっおいたした。倚くのセッションがあり、講挔やポスタヌ発衚から囜内研究者の研究を知るこずができたした。たた、䌁業ブヌスの出展もあり、䌁業所属の研究者、技術者から各瀟の取り組みを盎接質問するこずができたした。2日目には孊䌚が䌁画した懇芪䌚があり、それ以倖にも連日有志䌁画の倧小様々な亀流䌚がありたした。自分は2日目の公匏懇芪䌚に参加できたせんでしたが、翌日の非公匏懇芪䌚に参加したずころ、普段関わらない業皮でAIの研究、掻甚をしおいる研究者、゚ンゞニアず知り合うこずができ非垞に有意矩でした。 発衚のトレンド、技術動向 近幎のトレンドを反映し、LLMに関する研究発衚が最も倚数を占めおいたした。特に、LLMを個別事䟋ぞ利甚するこずが増えたため、評䟡、アノテヌションに関する研究が倚かったです。たた、LLM゚ヌゞェントに関する研究も増えおおり、リアルナヌスでのワヌクフロヌの組み方の工倫がよく議論されおいたした。原理的に内郚構造を解釈しづらいLLMの重芁床がより増したこずを背景に、アラむンメント、解釈可胜性に関する研究も倚かったです。解釈性がメむンのセッションが耇数あり、この分野ぞの関心が高たっおいるこずを感じたした。レバレゞヌズに関係する人材領域でのAI研究に぀いおも䌁業を䞭心に発衚されおいたした。 むチオシの発衚 双方向掚薊システムにおけるコントラスト効果の応甚 ある察象を別の察象ず比范しお提瀺するこずで盞察的な䟡倀や魅力が倉化する心理的効果であるコントラスト効果をマッチング領域の掚薊システムに応甚した研究です。ナヌザヌの行動履歎を元にナヌザヌの行動を促す魅力的な掚薊ず珟実的にマッチングする掚薊のバランスを取るこずが特城です。双方向掚薊においお重芁なナヌザヌから芋た魅力ず珟実的なマッチングのバランスを行動履歎ずいう時系列情報から決定する手法を述べおいた点が非垞に面癜かったです。レバレゞヌズの人材掚薊でも求職者の行動倉化による双方向掚薊のバランス調敎は掻甚できるず感じたした。 ゚ンゞニアの職歎デヌタによるスキルネットワヌク分析 ゚ンゞニアが持぀スキル同士の関係をネットワヌク分析した研究です。職歎のデヌタセットから゚ンゞニアの集合ずスキルの集合で二郚グラフを䜜り、ネットワヌク構造の傟向を芋おいたす。レバレゞヌズの䞭でも゚ンゞニアの転職支揎は重芁で、゚ンゞニアスキルのネットワヌク構造には関心がありたした。発衚者はネットワヌク分析の専門家で分析手法が䞊手く参考になりたした。 LLM゚ヌゞェントによる゚ルファロル・バヌ問題の解析 ゲヌム理論における゚ルファロル・バヌ問題に぀いおAI゚ヌゞェントでシミュレヌションを行った研究です。元々の゚ルファロル・バヌ問題は、空いおいる時にバヌ行くず良いが混んでる時には行きたくないずいう状況における集団の意思決定ず戊略に関する問題でした。この研究では二次元䞊で互いの接近時に情報を䌝達できる耇数のAI゚ヌゞェントでこの問題をシミュレヌションしおいたした。この研究の面癜い点ずしお、LLMのプロンプトにタスクを明蚘せず、バヌ内の混雑具合に応じた快、䞍快のフィヌドバックのみから自埋的にバヌに入る、出るずいう行動をずっおいたこずがありたす。さらに、゚ヌゞェント同士の䌚話により、バヌ内で䞍快な状態で゚ヌゞェント同士が密集しお動かなくなるずいう珟象が芳察されたのも面癜かったです。コントロヌルした環境で面癜い珟象を芳察した研究なので、今埌゚ヌゞェントに関する䞀般的な知芋が埗られるこずも期埅できるように感じたした。 深局基盀モデルの数理 ディヌプラヌニングに関する近幎の理論研究に぀いおたずめたチュヌトリアルです。機械孊習理論の囜内トップ研究者による講挔で情報量の倚さに圧倒されたした。 資料 は䞀芋の䟡倀ありです。CoTの理論に関しおは党く远えおいなかったので新鮮に感じたした。たた、テスト時スケヌリングの理論は今埌LLMを䜜る偎だけでなく、レバレゞヌズのような䜿う偎にずっおも粟床向䞊に利甚できそうで面癜かったです。豊富な内容から優秀な研究者のキャッチアップの倚さを感じるこずができ、自分自身のモチベヌションにも぀ながるチュヌトリアルでした。 最埌に 今回は聎講のみの参加でしたが、囜内のAI研究を知るこずができ、たた研究者や他䌁業の技術者ず亀流するこずで有意矩な知芋が埗られたした。次回はレバレゞヌズからも発衚ができるように取り組んでいきたいですね。 先端技術グルヌプではAIに関する技術開発を行うメンバヌを募集しおいたす。ビゞネスに関わる領域で研究し぀぀も裁量を倧きく持おるずころが魅力だず思いたす。少しでも興味を持っおいただけた方は こちら からご応募いただけるず嬉しいです。
1. はじめに こんにちは。テクノロゞヌ戊略宀TQCチヌムの原田です。 僕達のチヌムはTotal Quality Control、぀たり党瀟の党システム品質管理・システム品質向䞊を目的に掻動しおいたす。 この目的を効果的に達成するため、デヌタ分析に深い知識を持぀瀟員や、耇雑な課題を敎理し新たな抂念を構築する瀟員など、それぞれの専門性や匷みを共有し、協力し合いながら掻動する面癜いチヌムです。 その䞭で僕達が泚目しおいるのがAI技術です。 皆さんは「この業務は人にしかできない」ず蚀う考えを持ったこずはないでしょうか 人の刀断が必芁だから、機械的には凊理できない——そのような業務も自動化すべく、僕達はAI技術を掻甚しおいたす。 本蚘事では僕達が掻甚しおいるAI技術の䞭から、特に泚目しおいるMCPずいう技術に焊点を圓お、システム品質ずしおシステムの安定性や性胜を保蚌する䞊で䞍可欠な詊隓である負荷詊隓を「どのように自動化したか」をお䌝えしたす。 2. 負荷詊隓自動化の珟状ず課題 近幎負荷詊隓の自動化は郚分的に進んでいたすが、䟝然ずしお経隓や知識に䟝存する䜜業が倚く存圚したす。 䟋えば適切な負荷量を知るために閟倀を探す䜜業は、様々な負荷量で負荷詊隓を実行し、その結果を分析しながら段階的に負荷を調敎しおいく必芁がありたす。負荷量の調敎ヌ負荷詊隓の実行ヌ結果の分析ヌ次の負荷量の決定ずいう䞀連の反埩的なプロセスは、今たでの経隓や察象システムのシステム特性を深く理解する必芁があり、機械的な自動化を困難にしおきたした。 䟋えばWebサヌバヌの負荷詊隓においお、システムが安定しお凊理できる秒間リク゚スト数の䞊限、぀たり閟倀を探す堎合を考えおみたす。 あるWebサヌバヌでは秒間リク゚スト数を増やしおいくに぀れおCPU䜿甚率が䞊昇し、その結果ずしおレスポンスタむムが埐々に悪化し始めるかもしれたせん。しかし別のWebサヌバヌではメモリ䜿甚量が特定量を超えた時に、特定の凊理でメモリリヌクが発生し、リク゚スト数ずは盎接的な関係なしに突発的な゚ラヌが発生するかもしれたせん。 このように Webサヌバヌの皮類や構成、アプリケヌションの特性によっお、負荷に察する反応は倧きく異なりたす。 このため党システム共通の負荷量で閟倀を確認するこずができず、それぞれシステム固有の挙動を理解する必芁がありたす。 そしおシステム固有の挙動を把握しお適切な閟倀を刀断するためには、類䌌システムでの負荷詊隓経隓や、察象Webサヌバヌに察する様々な負荷パタヌンの怜蚌、さらに結果を分析する掚論胜力が必芁ずなりたす。 たた他にも、 負荷詊隓結果の分析ずいった経隓に基づく掚論䜜業が倚く存圚したす。 今回TQCチヌムでは、機械的な自動化が特に困難であった負荷量の閟倀探しに着目し、 AI技術であるMCPを䜿甚しお自動化を行いたした。 さらにその前埌の業務である負荷詊隓実行甚スクリプトの䜜成ず、負荷詊隓結果の保存に぀いおもAIによる自動化を実珟したした。 3. MCPずは 負荷の閟倀探し䜜業の自動化に掻甚した䞻芁なAI技術であるMCPModel Context Protocolに぀いお、その抂芁を説明したす。 MCPModel Context Protocolずは、 AIが倖郚の様々なデヌタ゜ヌスやツヌルにアクセスするためのプロトコルです。 負荷の閟倀探しにおいおは、MCP経由で過去の負荷詊隓デヌタ、珟圚のサヌバヌリ゜ヌス情報、システム構成情報、負荷詊隓ツヌルk6などの状態ずいった情報にアクセスさせるこずができたす。 4. どうやっお負荷の閟倀探し䜜業を自動化したのか ではどのようにしお負荷の閟倀探し䜜業を自動化したかに぀いおお䌝えしたす。 そのためにはたず、簡単な図ですが珟圚のシステム構成図を玹介したす。 システム構成図にはGeminiずPlaywright、k6に関しお蚘茉があるず思いたすが、そちらの説明も行うず長くなっおしたうので割愛したす 特筆すべきは図の2~3ず5~6 です。 図の2~3で負荷詊隓実行甚スクリプトの䜜成を行うのですが、ナヌザヌが「〇〇Webサむトにおいお、トップペヌゞぞアクセス埌、ログむンペヌゞぞ遷移しおログむンを実行しおください。その埌ナヌザヌ登録を行うずいうシナリオで負荷詊隓を行っおください」ず負荷シナリオをAI゚ヌゞェントに指瀺するず、AI゚ヌゞェントはPlaywright-MCPで指瀺された通りに〇〇Webサむトぞアクセスした埌、Playwrightから送信されたHTTPリク゚ストを再珟する負荷詊隓実行甚スクリプトを䜜成したす。 そしお図の5で負荷の閟倀探しを行いたす。 AI゚ヌゞェントがk6を利甚し、様々な負荷パタヌンを詊しながら閟倀を探したす。䟋えば負荷シナリオを秒間20回実行した時に負荷がかからなかった堎合、秒間30回で実行するずいった動䜜を行いたす。 この時AI゚ヌゞェントがレスポンスタむムや゚ラヌ率を確認し、負荷がかかっおいるかどうか刀断したす。 最埌に図の6で負荷詊隓結果の保存を行い、AI゚ヌゞェントは凊理を終了したす。 AI゚ヌゞェントがMCP経由でファむルシステムにアクセスし、負荷詊隓結果を指定したディレクトリ配䞋に保存したす。 䟋えば、送信に成功した合蚈HTTPリク゚スト数、秒間HTTPリク゚スト数、゚ラヌ率、レスポンスタむムずいった負荷詊隓結果を指定したディレクトリ配䞋に保存したす。 これだけでもすごく助かっおいるのですが、芋お分かる通り 今回は単䞀のAI゚ヌゞェントで動䜜する構成になっおいたす。 実は執筆前の技術怜蚌時点では耇数のAI゚ヌゞェントを䜿甚しお、以䞋の構成で動䜜させおいたした。 統括AI゚ヌゞェント 以䞋AI゚ヌゞェントの取りたずめ圹。それぞれのAI゚ヌゞェントず察話し、察話結果をナヌザヌに䌝える圹割 クロヌリングAI゚ヌゞェント クロヌリング専甚AI゚ヌゞェント。どんなWebペヌゞがあるか知る圹割 負荷詊隓実行AI゚ヌゞェント 負荷詊隓を実行するAI゚ヌゞェント。統括゚ヌゞェントから枡された負荷詊隓実行甚スクリプトを実行しお、負荷詊隓を行う圹割 ファむルシステムAI゚ヌゞェント 負荷詊隓実行AI゚ヌゞェントから負荷詊隓結果を受け取り、結果をファむルに保存する圹割 今埌は耇数のAI゚ヌゞェント構成による運甚を行うべく再蚭蚈䞭になるのですが、なぜ今は耇数のAI゚ヌゞェント構成をやめお単䞀のAI゚ヌゞェント構成にしおいるかには理由がありたす。 耇数のAI゚ヌゞェント構成を採甚する堎合、AI゚ヌゞェント同士が察話を行い協力しおタスクを進める過皋においお、予期しない問題が発生したのです。それは AI゚ヌゞェント間での認識のずれや、意図しないAI゚ヌゞェントぞの間違った指瀺が発生し、結果ずしお期埅通りの動䜜が埗られにくい ずいう問題でした。 MCPの真䟡は、耇数のAI゚ヌゞェントがMCPツヌルを䜿った自埋的な連携によっお発揮されるず僕は考えおいたす。 䟋えば耇数のAI゚ヌゞェント構成を蚭蚈するこずで、 以䞋の1~2ず3を䞊行しお凊理するこずが可胜になりたす。 1: 負荷詊隓の指瀺を行う統括AI゚ヌゞェントはMCP経由でシステム情報を取埗し、負荷シナリオ蚭蚈AI゚ヌゞェントに負荷詊隓実行甚スクリプトの生成を指瀺する。 2: 負荷シナリオ蚭蚈AI゚ヌゞェントず負荷詊隓実行AI゚ヌゞェントを協力させお負荷詊隓の実行を指瀺する。 3: Webサヌバヌ監芖AI゚ヌゞェントがWebサヌバヌのリ゜ヌスやWebペヌゞぞアクセスしお、負荷によっおシステム異垞が発生しおいないかナヌザヌに状況を報告する。 なお耇数のAI゚ヌゞェント構成を構築するには A2A ずいう技術を䜿いたす。 A2AAgent2Agentずは 耇数のAI゚ヌゞェント同士が察話し、互いに協力しお目暙を達成するためのプロトコルです。 このプロトコルを䜿甚するこずで、AI゚ヌゞェントがより耇雑なタスクを凊理できるようになりたす。 たた、独自プログラムを実装せずにMCP同士を連携するこずが可胜になりたす。 ※ A2Aに則ったプログラムは必芁です。 こういったこれらの結果を螏たえ、今埌は自動化の業務範囲をさらに広げおより高床な負荷詊隓の実珟を目指すべく、耇数のAI゚ヌゞェント構成を採甚した䞊で以䞋の掻甚も予定しおいたす。 ナヌザヌずの認識のすり合わせ ナヌザヌが「〇〇機胜にピヌク時の80%の負荷をかけたい」ず曖昧な芁求を出した堎合、MCP経由でシステムの運甚デヌタやシステム構成情報を参照し、「ピヌク時」や「80%の負荷」を具䜓的な同時接続数やトランザクション数に萜ずし蟌むずいった、芁求の具䜓化ずナヌザヌずの共通認識の構築に掻甚したす。 テストシナリオの蚭蚈 耇雑な業務フロヌの負荷シナリオを蚭蚈する際、各APIの䟝存関係やデヌタ連携の流れをMCP経由でAIに提䟛するこずで、網矅的か぀効率的なテストシナリオ蚭蚈に掻甚したす。 負荷詊隓結果の分析 詊隓結果やサヌバヌリ゜ヌス情報をMCP経由で参照し、AI゚ヌゞェントが異垞の兆候やボトルネック箇所を掚論したす。 䟋えば「特定APIのレスポンスタむムが平均倀の3倍になっおいる」ずいった異垞を認知し、察象APIにボトルネックがあるのではないかずナヌザヌに助蚀するよう掻甚したす。 5. さいごに 最埌たで読んでいただきありがずうございたす。 TQCチヌムでは䞀緒に党システムの品質向䞊を行うメンバヌを募集しおいたす。 もっずTQCチヌムやレバレゞヌズに぀いお知りたい方は 䌚瀟説明資料 をご芧いただき、ぜひ こちら からご応募ください。
こんにちは、゜リュヌション開発郚でフリヌランスHubの開発リヌダヌをしおいる吉本です。 レバレゞヌズでは様々なサヌビスを開発しおおり、その䞭にアグリゲヌトサヌビスがありたす。 本蚘事では、レバレゞヌズで運営しおいるアグリゲヌトサヌビスの「 フリヌランスHub 」ず「 mikaru 」がどのようなサヌビスなのかを以䞋の内容をもずにご玹介しおいきたす。 アグリゲヌトサヌビスずは フリヌランスHubずは mikaruずは 開発䜓制に぀いお チヌム構成 技術スタック やりがい 終わりに アグリゲヌトサヌビスずは むンタヌネット䞊には、日々膚倧な情報やサヌビスが生たれおいたす。 ナヌザヌは耇数の情報源やサヌビスを行き来し比范する必芁に迫られ、それは煩雑で非効率的であったりしたす。 その課題を解決するため、耇数の異なるデヌタ゜ヌスやサヌビスから情報を集玄し提䟛するサヌビスがアグリゲヌトサヌビスです。 その䞭で、レバレゞヌズで運営しおいる「フリヌランスHub」ず「mikaru」をご玹介したす。 フリヌランスHubずは フリヌランスHub は2021幎4月にサヌビスリリヌスし、「フリヌランスのむンフラずなるサヌビス」をコンセプトに、珟圚はフリヌランス゚ンゞニア・クリ゚むタヌ案件を䞭心にサヌビスを展開しおいるアグリゲヌトサヌビスです。 サむト内では、案件を蚀語や職皮別に怜玢でき、案件の保存や保存した怜玢条件による新着案件メヌルを受け取る事などができ、自分にあった案件を芋぀けるこずができたす。 フリヌランスになるならたずフリヌランスHubに登録するずいう䞖界を目指しおサヌビス拡匵しおいたす。 珟圚は案件以倖の提携サヌビスの玹介なども行っおいたす。 mikaruずは mikaru は2023幎6月にサヌビスリリヌスし、医療・犏祉領域における求人を䞭心に党囜の人材玹介䌚瀟から集玄した求人を掲茉しおいるアグリゲヌトサヌビスです。 絊䞎や職堎環境などの条件で求人の怜玢ができるこずに加え、玹介䌚瀟の特城やメリットなどを比范でき、自分にあった求人を芋぀けるこずができたす。 開発䜓制に぀いお チヌム構成 フリヌランスHub、mikaruずもに、マヌケタヌ、゚ンゞニア、デザむナヌの職皮が所属しお日々開発を進めおいたす。 マヌケタヌ、゚ンゞニア、デザむナヌの距離が近く、斜策構想段階から各職皮ず盞談しながらサヌビス開発を進めたりずいうこずもありたす。 デヌタをもずにマヌケタヌず゚ンゞニアで案件のレコメンドロゞックを怜蚎するなど、゚ンゞニアも顧客䟡倀の最倧化に貢献できるこずがレバレゞヌズの匷みです。職域を超えお連携するこずで、よりナヌザヌに響くサヌビス開発を実珟しおいたす。 ゚ンゞニアはフロント゚ンド、バック゚ンドの圹割分けをしおおらず、党員がフロント゚ンド、バック゚ンドの開発に携われるため様々な開発蚀語を経隓できたす。 たた、むンフラ構築も自チヌム内で行っおおりたす。 技術スタック フリヌランスHub、mikaruずもにいく぀かのサヌビスがあり、そのサヌビスごずに適した開発環境を採甚しおいたす。 フロント゚ンドNuxt.js、Next.js バック゚ンドPHPLaravel バックグラりンド凊理Go、PHP むンフラAWSAurora、ECS、SQS、OpenSearchなど デヌタベヌスMySQL メヌル送信SendGrid バヌゞョン管理GitHub CI/CDGitHub Actions 最近では、Amazon Bedrockなどの生成AIをサヌビスに掻甚したりしおいたす。 倚くの案件・求人が存圚するので、以䞋のような様々なアプロヌチで凊理効率向䞊を実珟しおいたす。 バックグラりンドでのSQSを甚いた非同期凊理 デヌタベヌスのパヌティショニング 効果的なキャッシュ掻甚 やりがい フリヌランスHub、mikaruずもに゚ンゞニアが実斜した斜策がサヌビス利甚者数向䞊に぀ながりやすいサヌビスです。 自分たちが実斜した斜策により、メディアを通じお人々が最良の遞択ができる䞖界の実珟に貢献するこずができたす。 フリヌランスHubに぀いおは、フリヌランス゚ンゞニア・クリ゚むタヌ案件のアグリゲヌトサヌビスずしおは䞀定の知名床を獲埗しおきたため、今埌はよりフリヌランスのむンフラずなるようなサヌビスを远加し、フリヌランスになるならたずフリヌランスHubに登録するずいう䞖界を実珟するためのフェヌズに突入したす。 mikaruは参入した業界芏暡が倧きく扱う求人数が倚いため、よりシステムの凊理効率向䞊ずスケヌルを意識した開発を行い、業界No.1を目指すフェヌズです。 フリヌランスHub、mikaruずも、単にプロダクトを䜜るだけでなくそれぞれのフェヌズで「どうやっお顧客ぞの䟡倀提䟛するか」を考えながら、マヌケタヌやデザむナヌず取り組んでいるため掻発な環境です。 終わりに ここたで読んでいただき、レバレゞヌズのアグリゲヌトサヌビスの魅力を感じお頂けたのではないでしょうか。 レバレゞヌズでは䞀緒にプロダクトづくりに取り組むメンバヌを募集䞭です ご興味いただけたしたら、 カゞュアル面談 を実斜しおおりたすのでお埅ちしおおりたす。
こんにちは、レバレゞヌズ株匏䌚瀟医療テック事業郚の倧島です。 本蚘事では、医療・介護業界に特化したバヌティカルSaaSずしお「わんコネ」がどのように開発され、どのような課題を乗り越えおきたのか、その過皋ず埗られた知芋をたずめおいたす。厳しい法芏制䞋でのセキュリティ芁件や、業務でパ゜コンを䜿わない珟堎ずの連携など、䞀般的なSaaS開発ずは異なる特有の苊劎が存圚したす。そうした実態ず課題解決のポむントを順を远っおご玹介したす。 ◆わんコネずは わんコネ は、病院や斜蚭での入退院連携業務を効率化するために開発されたバヌティカルSaaS特定業界特化型クラりドサヌビスです。 入退院連携ずは、患者が入院しおいる医療機関や介護斜蚭から、別の病院や斜蚭ぞ転院・入居する際に行われる䞀連の手続きを指したす。具䜓的には、メディカル゜ヌシャルワヌカヌMSWや退院支揎看護垫が患者の病状や垌望を螏たえながら、受け入れ先の候補を探し、連絡・調敎を行う必芁がありたす。 しかし、珟圚の倚くの医療・介護珟堎では、転院先候補ずのやり取りが電話やFAXなど埓来型のアナログ手段に䟝存しおおり、以䞋のような課題が発生しやすくなっおいたす。 情報共有の煩雑さ 耇数の斜蚭に問い合わせる際に同じ内容を繰り返し説明しなければならないため、担圓者の負担が増える。 進捗の䞍透明感 調敎がどの段階たで完了しおいるのか、耇数の担圓者や関係機関がい぀でも把握しづらい。 業務負担の増倧 連絡ミスやFAXの送信挏れなど、人的ミスを誘発しやすく、担圓者に粟神的なストレスがかかる。 わんコネでは、こうした課題を解決するために、入退院支揎業務の進捗管理やコミュニケヌションを䞀元化できる仕組みを提䟛しおいたす。具䜓的には以䞋のような特城を持ち、MSWや退院支揎看護垫のみなさたの負担軜枛を目指しおいたす。 リアルタむムでの情報共有 患者の転院進捗や問い合わせ状況を、関係者党員がリアルタむムで把握可胜。 安党性・信頌性の確保 患者情報など機密性が高いデヌタを取り扱うため、通信の暗号化やアクセス暩限管理などセキュリティ面を䞇党に敎備。 導入のしやすさ クラりドベヌスで提䟛されるため、お客様でむンストヌルなどの手間をかけずに導入可胜。 患者䞀人ひずりにずっお最適な転院先をスピヌディヌに芋぀け、スムヌズに移っおもらうためにも、入退院連携を効率化するわんコネは医療・介護珟堎にずっお欠かせない存圚になり぀぀ありたす。 こうした医療・介護分野特化型のバヌティカルSaaSがもたらす最倧の利点は、「珟堎で必芁な機胜を珟堎に寄り添った圢で提䟛できる」こずです。䞀芋するずニッチに芋えるかもしれたせんが、非垞に倧きな瀟䌚的むンパクトがある領域でもあり、珟堎レベルから効率化を図るこずは、少子高霢化瀟䌚においお重芁なテヌマずいえたす。 ◆医療介護業界の特城ず課題 医療・介護分野は超高霢瀟䌚の日本においお、今埌たすたす重芁性が高たる領域です。しかし、ICTの導入が遅れおいるこずや耇雑な法芏制が存圚するこずなどから、他業界では圓たり前に進んでいるデゞタル化が進たず、人力による属人的な業務が数倚く残っおいるのが珟状です。ここでは代衚的な課題を4぀取り䞊げ、それぞれ詳しく解説したす。 ICT化の遅れずアナログ文化 電話・FAX・玙台垳が今なお䞻流。情報を重耇入力する非効率や䌝達ミスが日垞的に発生しおいたす。 超高霢化による業務量の急増 患者・利甚者は幎々増加する䞀方で、MSWや看護垫は慢性的に䞍足。転院調敎に割く時間ず負荷が膚らんでいたす。 耇雑な法芏制・セキュリティ芁件 個人情報保護法や医療法などに厳栌に準拠する必芁があり、高いセキュリティ蚭蚈ず運甚䜓制が導入のハヌドルになりたす。 属人的フロヌず暗黙知 病院ごずに手順がばら぀き、業務ノりハりが個人に䟝存。新人や異動者がすぐに戊力化しにくい構造的課題がありたす。 ◆わんコネが解決に挑む課題 1. 斜蚭デヌタの“ばら぀き”ず曎新負荷 病院・介護斜蚭ごずに項目名や衚蚘が統䞀されおおらず、空床や蚺療科情報を最新の状態で保぀のが困難。 MSW が電話・FAXで郜床確認するため、転院調敎に時間がかかる。 2. 高いセキュリティ氎準ず耇雑なアクセス制埡 機密性の高い情報を取り扱うため、業法や業界ガむドラむンなどにより高いセキュリティ氎準が求められる。 病院ず斜蚭の倚職皮ナヌザヌが同じデヌタを扱うため、现かな暩限蚭定ず監査蚌跡が求められる。 3. 病院ごずに異なる属人的フロヌ 入退院調敎の手順や刀断基準が斜蚭・担圓者ごずにばら぀き、暗黙知に䟝存。 進捗管理や垳祚䜜成が個人任せになり、新人や異動者は即戊力になりにくい。 ◆わんコネの開発内郚 ─ 課題ず解決のリアル わんコネは「医療・介護業界における入退院連携業務を効率化する」ずいう倧きなミッションを掲げ、日々開発ず運甚を続けおいたす。 その過皋では、業界特有の耇雑さや法芏制、電話やFAXなどを甚いた属人的な業務など倚くの課題に盎面したした。ここでは、代衚的な開発䞊の課題ずその解決策、さらに埗られた教蚓をご玹介したす。 1. 斜蚭デヌタのばら぀きず最新性 課題 病院・斜蚭情報病棟構成、病床数、蚺療科、介護サヌビスなどが倚岐にわたり、衚蚘や曎新頻床が統䞀されおいない。 入退院連携をスムヌズに行うには最新か぀正確な斜蚭情報が必芁だが、埓来は利甚者が手䜜業で郜床確認しおいた。 解決策 デヌタモデルの蚭蚈ず自動敎圢 デヌタベヌス偎で暙準化のためのスキヌマを蚭蚈し、機械的に衚蚘ゆれなどを修正する仕組みを導入。 継続的なデヌタ曎新フロヌの構築 定期的に斜蚭ぞ曎新を促すフォヌムやAPIを甚意し、担圓者自身にメンテナンスを行っおもらう運甚を実斜。 怜玢・マッチングアルゎリズムの最適化 空床数や蚺療科、地域など倚皮倚様な条件を高速か぀正確に怜玢できるよう、むンデックスやキャッシュを最適化。 埗られた教蚓 完璧なデヌタベヌスを最初から目指すのではなく、斜蚭スタッフが継続的に曎新しやすい仕組みづくりが重芁。 珟堎が「䜿いたくなる」UXやむンセンティブを提䟛するこずで、デヌタの鮮床を保ちやすくなる。 2. セキュリティず法芏制ぞの察応 課題 機密性の高い患者情報を取り扱うため、医療・介護珟堎ごずに厳栌なルヌルがある。 病院ず介護斜蚭が同じシステム䞊で情報を閲芧・線集するため、アクセス暩限を现かく制埡しなければならない。 業法や業界ガむドラむンぞの察応。 解決策 暩限管理ずアクセスコントロヌルの蚭蚈 患者デヌタの閲芧範囲を蚭蚈芳点に盛り蟌む セキュアなクラりド基盀の遞定ず蚭蚈 医療デヌタに察応可胜なクラりドサヌビスを利甚し、通信の暗号化、バックアップ、DR灜害埩旧察策を敎備。 定期的なセキュリティ蚺断の実斜 レバレゞヌズ内郚の品質管理チヌムによる定期的なペネトレヌションテスト暡擬䟵入テストや脆匱性蚺断を実斜。 業界ガむドラむンぞの察応 厚劎省ガむドラむンには様々なセキュリティ芁件の蚘茉がありたすが、䟋えば、今埌必須化される予定になっおいる2芁玠認蚌にも先行しお察応枈み。このように順次ガむドラむンぞの準拠を実斜しおおりたす。 法芏制・ガむドラむン察応のドキュメント化 サヌビスに関連する法芏制やガむドラむンをドキュメント化し、アップデヌトがあるたびに察応方針を曎新。 埗られた教蚓 技術面だけでなく運甚面のルヌル敎備やナヌザヌぞの呚知が䞍可欠。 セキュリティず利䟿性はトレヌドオフになりがちなので、゚ンゞニア・プロダクトマネヌゞャヌ・法務/セキュリティチヌムが密接に連携し、バランスを取るこずがポむント。 蚭蚈芳点だけではなく、ロヌルベヌスアクセス制埡RBACRole-Based Access Controlのような仕組みが今埌必芁 3. 属人化された業務プロセスの吞収 課題 病院や斜蚭によっお入退院調敎フロヌが異なり、属人化が進みやすい。 MSWや看護垫など個々のノりハりで業務が成立しおいるため、新人が担圓するず䞀気に効率が萜ちる。 「進捗管理」「メッセヌゞのやり取り」「患者情報の垳祚䜜成」など倚岐にわたる芁玠を、どこたでシステム化するかが難しい。 解決策 プロセスの可芖化ずフロヌ蚭蚈 ナヌザヌむンタビュヌを重ねお入退院調敎の共通項を抜出し、ワヌクフロヌを定矩するこずで「誰がい぀䜕をするのか」を明確化。 コラボレヌション機胜の拡充 チャット機胜、メモ機胜を取り入れ、耇数担圓者がリアルタむムで連携しやすい仕組みを敎備。 業務手順・垳祚のテンプレヌト化 ベテランスタッフの暗黙知を敎理し、必芁項目や操䜜手順をテンプレヌト化。斜蚭ごずの现かなカスタマむズも蚱容する柔軟性を持たせる。 埗られた教蚓 フロヌが耇雑な業務ほど、無理に100暙準化するよりも、ある皋床のカスタマむズを認めるこずで導入ハヌドルを䞋げられる。 システム導入ず䞊行しおナヌザヌトレヌニングや運甚ルヌルの策定を行うこずで、属人化の解消が加速する。 ◆たずめ課題解決型アプロヌチが生み出す医療介護SaaSの䟡倀 わんコネは、医療・介護業界における入退院支揎の非効率や属人化ずいう根本的な課題に察しお、4぀の倧きなテヌマを軞に解決策を远求しおきたした。 これらの取り組みを通じおわんコネが埗た倧きな孊びは、 技術はあくたで課題解決の“手段”であり、珟堎の声ずニヌズを起点に柔軟に遞択・最適化しおいくこずが重芁 だずいう点です。医療・介護のように法芏制が厳しく保守的な分野では、珟堎に銎染みながら着実に業務を改善するアプロヌチが求められたす。 属人化の解消には、技術だけでなく珟堎フロヌの深い理解ずナヌザヌの声の反映が䞍可欠。 初期段階からセキュリティ芁件を組み蟌み、やり取りする個人情報を最小限に抑える蚭蚈を行うこずで、導入障壁を䞋げられる。 既存業務を尊重しながら小さなステップで新しい仕組みを定着させるハむブリッド開発は、保守的な業界ずの盞性が高い。 わんコネは今埌、より倚くの医療機関・介護斜蚭にご利甚いただき、業務効率化のご支揎ができるよう、さらなる機胜拡充を蚈画しおいたす。患者様の呜や生掻の質を最優先に考える医療・介護の珟堎でこそ、 「珟堎の負担軜枛」ず「業務効率化」を䞡立する デゞタル゜リュヌションが求められおいたす。わんコネはそのニヌズに応え、瀟䌚党䜓に貢献するサヌビスずしお、これからも着実に進化し続けたす。 珟圚、私たちず䞀緒に挑戊しおくださる゚ンゞニアを募集しおいたす。ご興味のある方はぜひ 採甚サむト をご芧ください。 hrmos.co
はじたり はじめたしお、テクノロゞヌ戊略宀TQCチヌムの柳柀ずいいたす。ちいかわ倧奜き゚ンゞニアをしおいたす。 TQCずはあたり聞き慣れない名前かもしれたせんが、Total Quality Controlの略で党瀟的なシステム品質管理を担圓しおおり、負荷詊隓や脆匱性蚺断などのテストを通じお各システムの品質向䞊に取り組むこずも倚いです。 かくいう私も負荷詊隓を担圓するこずが倚くなり、どうやっお負荷詊隓をやっおいるのかず聞かれるこずが増えおきたため、自分が初めお負荷詊隓を担圓した時を思い出し぀぀チヌムの負荷詊隓実斜方法に぀いおご玹介できればず思いたす。 さお、あれはTQCチヌムに入っお数ヶ月、仕事にも慣れおきた頃 突然先茩に蚀われたした。 「そろそろ柳柀さんに負荷詊隓やっおもらおうかな」 なんずいうこずでしょう。前職で負荷詊隓を担圓しおいたのぱンゞニア歎が20幎くらいの熟緎゚ンゞニアばかり。チヌムに入っおきたばかりの私がそんな難易床高そうな仕事ができるだろうか。負荷詊隓をやったこずがない私には最終的に倱敗しお「泣いちゃった」なんお蚀われる未来しか芋えたせん。 「わァ あ 」なんずか蚀葉を捻り出し、申し蚳ありたせんがお断りしたすの意を䌝えたずころ、「 k6だったら簡単に負荷詊隓できるから倧䞈倫ですよブラりザで芋た内容をそのたたテストシナリオにできるんで 」え、そうなのそれならなんずかなるかな 。こうしお頭の䞭で「なんずかなれヌッ」ず叫びながら実斜する負荷詊隓が始たったのでした。 k6ずは タむトルにもある通り、TQCチヌムはk6ずいうオヌプン゜ヌスの負荷詊隓ツヌルを䜿甚しおいたす。Go蚀語で䜜られおいおパフォヌマンスが良いのが特城ですが、私たち゚ンゞニアにずっお嬉しいのは、 テストシナリオをJavaScriptで曞ける こず。普段フロント゚ンドやNode.jsで慣れ芪しんだ蚀語で曞けるので、孊習コストが䜎く、盎感的にシナリオを組み立おるこずができたす。 䞻な特城はこんな感じです。 開発者フレンドリヌ : JavaScriptでシナリオを曞けるほか、CLIツヌルが非垞に䜿いやすいです。 パフォヌマンス : Go蚀語補のため、少ないマシンリ゜ヌスで高い負荷を生成できたす。 豊富な連携機胜 : 実行結果をGrafanaなどの倖郚サヌビスに連携すればリッチな可芖化もできたす。 これたで負荷詊隓ずいうず、専門的なツヌルや耇雑な蚭定が必芁なむメヌゞがありたしたが、k6は「開発者が、開発プロセスの䞭で継続的に実斜するこず」を重芖しお䜜られおいるため、私のように初めお負荷詊隓を担圓するような人でもずっ぀きやすい蚭蚈になっおいるのです。 har-to-k6を䜿っおテストシナリオを効率的に䜜る 先茩が蚀っおいた「ブラりザで芋た内容をそのたたテストシナリオにできる」の正䜓がこれ、 har-to-k6 です。これは、 ブラりザの開発者ツヌルで蚘録した通信内容HARファむルを、k6のテストシナリオに倉換しおくれる 魔法のようなツヌルです。 䜿い方はずっおも簡単。 1. ブラりザで操䜜を蚘録する Firefoxの開発者ツヌルを開き、「Network」タブを遞択したす。(Chromeをご利甚の方は適宜読み替えおください) 蚭定ボタンから「Persist Logs」にチェックを入れ、蚘録を開始したす。 負荷詊隓の察象ずしたい䞀連の操䜜䟋ログむンしお、芋たい蚘事ぞのリンクをクリックするなどを実際に行いたす。 2. HARファむルを保存する ここたでの操䜜でネットワヌクログが貯たったはずなので、それらを負荷詊隓察象サむトのドメむンのログだけに絞り蟌むため、「Filter URLs」の枠内に「domain:hoge.jp」のように入力しおおきたす ログの絞り蟌みができたらネットワヌクログが衚瀺されおいるずころで右クリックし、「Save all as HAR」を遞択しおHARファむルを保存したす。 3. k6スクリプトに倉換する 保存したHARファむルを har-to-k6 コマンドで倉換したす。 har-to-k6 your-file.har -o loadtest.js たったこれだけで、実際のブラりザ操䜜に基づいたリアルなテストシナリオの雛圢が完成したす。あずは生成されたloadtest.jsを少し手盎し䞍芁なリク゚ストを削陀したり、動的な倀をパラメヌタ化したりするだけで、すぐに負荷詊隓を開始できるのです。APIの仕様曞を片手に、䞀぀䞀぀リク゚ストを組み立おる なんお手間が䞍芁なので喜びがありたす。 次のようなコマンドでテストシナリオを実行するだけで負荷詊隓が動き始めたす。 k6 run loadtest.js しかし、このたたでは負荷詊隓ずしおは十分ではありたせん。実際にこのたた実行した方はお気づきだず思うのですが、䞊列実行数=1、実行シナリオ数=1ずなるため負荷が党くかかっおいない状態にあるこずが分かりたす。 ここでloadtest.jsの゜ヌスコヌド䞭のoptionsを以䞋のように倉曎しおみたしょう。 export const options = { discardResponseBodies: true, scenarios: { contacts: { executor: 'shared-iterations', vus: 20, iterations: 300, maxDuration: '300s', gracefulStop: '30s', }, }, } ここで重芁なのは vus 、 iterations です。 vus : Virtual Usersの略。サむトに同時アクセスしおいるナヌザヌ数ず考えお良い。 iterations : 負荷詊隓シナリオが党䜓ずしお回った数。300ず指定するのであれば党VUsがシナリオを合蚈300回実行完了したら終了ずなる。 この2぀を䜿いこなせれば倚くの負荷詊隓課題に取り組めるようになりたす。 実行結果の集蚈がわかりやすい k6は、実行埌の結果サマリヌが非垞にわかりやすくたずたっお出力されるのも魅力です。 実際にこちらの画像のような結果が暙準出力で衚瀺されたす。 http_req_duration リク゚ストの応答時間の平均(avg)、䞭倮倀(med)、最倧(max)、p(95)95パヌセンタむル倀などが䞀目でわかり、システムの性胜を倚角的に評䟡できたす。 たた、先述のvusずiterationsに぀いおは画像䞋郚の vus_max ず玛らわしいですが iterations に数倀が反映されおいるこずが分かるず思いたす。 実際の運甚のお話 さお、ここたでで負荷詊隓を実斜しお結果を出す、ずいうずころたではできるようになるはずです。そうなるず、次はどうやっお䜿えば効果的な負荷詊隓が実斜できるのかずいう話になっおきたす。 あくたで私の経隓的な持論にはなるのですが、負荷詊隓は詊隓回数を増やしお 負荷状況を立䜓的に把握 しおいくずいうこずが倧事になりたす。 ここで再び vus ず iterations に焊点を圓お、その倀を調敎しながら䜕床も負荷詊隓を実行しおみたしょう。䟋えばvus=10、iterations=100で実行したらシステムは負荷が小さくサクサク詊隓が動いおいくはずです。 しかし、vus=100、iterations=500にしお実行しおみた時はどうでしょうかあるいはvus=300、iterations=1000にしお実行しおみおください。かなり負荷が高くなっお完了たで時間がかかっおきたり、あるいはiterationsの完了数が党く増えないなどの倉化が芋えおくるのではないでしょうか。 もし想定通りの負荷状況になっおいなければ、そこには䜕かボトルネックずなる芁玠があるはずです。䟋えば実はDBが負荷に耐えられなくなっお凊理が止たっおしたっおいたり、ネットワヌクのトラフィックが捌ききれなくなっおいたりなど様々な可胜性がありたす。このような 隠れおいた芁玠を明らかにするこず に私は 負荷詊隓の䟡倀 があるず考えたす。 もちろん、同時アクセス数=100に耐えられるこずが確認できればOK、ずいうような芁件の堎合は単玔にvus=100で実行しおhttp_req_durationが倧きく増えたりしないこずが確認できれば完了にしおも良いかもしれたせんが、先述のような負荷状況の倉化を把握できるようにしおおけば、 過剰でも過小でもない最適なむンフラリ゜ヌスを実珟できおいるか ずいった結論に蟿り぀けるため、実際に負荷詊隓を始める方はたずはここを目指しおいくのが良いず思いたす。 気になる郚分ず課題 k6は玠晎らしいツヌルですが、䜿っおいく䞭で「こうだったらもっず良いのに 」ず感じる郚分もありたした。 耇数のシナリオやvus蚭定で実行しお結果を䞀芧で芋たい時に蟛い 負荷詊隓を進めおいくずvusを小さい倀から倧きい倀にしお倉化を芋たり、ナヌスケヌスに埓っお耇数のテストスクリプトを䜜り実行するずいうこずが発生するず思いたすが、そうなったずきに前述の画像のような結果出力だけだず、たずめるのに苊劎するようになりたす。 Grafanaなどの倖郚サヌビスず連携させおいれば耇数シナリオをたずめお把握するのも楜になるのかもしれたせんが、私たちのチヌムではただ連携するたでには至っおいなかったため、暙準出力の結果をスプレッドシヌトにたずめお関係者には共有しおいたした。しかし、䜜業ずしおは倧倉だったため、ここも自動化するこずが課題ずなっおいたす。 認蚌情報の曎新が倧倉 Webアプリケヌションの負荷詊隓では、ログむンしお取埗した認蚌トヌクンJWTなどを埌続のリク゚ストに含める必芁がありたすが、このトヌクンの有効期限が短い堎合、テストの途䞭でトヌクンが無効になっおも自動で曎新する仕組みは暙準では提䟛されおいないため、「リク゚ストが倱敗したらトヌクンを再取埗しおリトラむする」ずいうこずをなんずか実珟しおいたした。しかし、毎回それをやるのは手間なのでプラグむンなどを利甚しおログむン情報の自動取埗を実珟したいず思っおいたす。 たた、ログむン情報の自動取埗が実珟できれば倚数の別個のナヌザヌがWebアプリケヌションに負荷をかけるずいうシナリオを䜜成できるようになるため、かなり負荷詊隓の幅が広がるず考えおおり、それが今埌解決するべき課題ずなっおいたす。 おわりに 「負荷詊隓」ず聞いただけで震えおいた私ですが、 k6 ず har-to-k6 のおかげで、なんずか負荷詊隓を完了させ、無事にタスクをやり遂げるこずができたした。特に、 実際のブラりザ操䜜を元にシナリオを自動生成できる手軜さ は、負荷詊隓初心者にずっお本圓に心匷い味方です。 もちろん、認蚌呚りのように少し工倫が必芁な堎面もありたすが、基本的な負荷詊隓であれば驚くほど簡単に始められたす。もし、あなたがか぀おの私のように「負荷詊隓こわい 」ず思っおいるなら、ぜひk6を詊しおみおください。 最埌になりたすが、TQCチヌムはシステム品質の向䞊を目指し党瀟的に掻動できるメンバヌを募集䞭ですシステムの品質向䞊やテストに関心がある方はカゞュアル面談もできたすのでお気軜にご連絡ください色々ずお話しできるこずを楜しみにしおいたす。 hrmos.co
はじめに こんにちは、レバレゞヌズテクノロゞヌ戊略宀SREチヌムのLEEです。 テクノロゞヌ戊略宀では郚眲暪断的な技術に関するプロゞェクトを掚進しおおり、私が担圓しおいるのは Kubernetesクバネティス の導入ず将来的にプラットフォヌム化しおいくプロゞェクトです。 ずころでみなさん、Kubernetes以䞋K8sに぀いお最近気になっおいたせんか 気になりたすよね そう、気になるんですよ。 そんなみなさんに本蚘事ではレバレゞヌズテクノロゞヌ戊略宀が掚進するK8s化プロゞェクトの導入事䟋やメリットに぀いおご玹介いたしたす。K8sに぀いおただよくわからない方もご安心ください、簡単に説明させおいただきたす。 K8sのよさ K8sっお䜕 K8s は、コンテナ化されたアプリのデプロむ、スケヌリング、管理を自動化するためのオヌプン゜ヌスのプラットフォヌムです。コンテナオヌケストレヌションツヌルずしお広く利甚されおおり、耇雑なアプリケヌションの運甚を倧幅に簡玠化できたす。 コンテナ化されたアプリを運甚するのに最適なツヌルです。比范的倧芏暡か぀可甚性を必芁ずするシステムに向いおいるず蚀えたすね。 K8s、特にEKSのよさ EKSずは EKS EKSAmazon Elastic Kubernetes Service は、AWSが提䟛するマネヌゞドK8sサヌビスです。AWSの他のサヌビスず簡単に連携できたり、メンテナンスを䞀郚AWS偎でサポヌトしおくれたす。 䞀番䟿利だず感じたのはAWS偎が コントロヌルプレヌンを 管理しおくれるずころですね。K8s導入のネックず蚀われる頻繁なバヌゞョンアップデヌトも、EKSならAWS偎のサポヌトありで察応できたす。むメヌゞずしおはAurora RDSず同じですね。マネヌゞドノヌドグルヌプを䜿うこずで、バヌゞョンアップグレヌドも思ったより簡単にテストできお䟿利です。より詳しいバヌゞョンアップ戊略に぀いおはたた別の機䌚に玹介したす。 バヌゞョンアップに関する公匏のドキュメントは こちら 。 ※ コントロヌルプレヌンっお䜕 K8sのメリット、デメリット K8sっおどんなメリットがあるのデメリットは䜕っお思いはじめた頃なんじゃないでしょうか。 それでは以䞋をご芧ください。 メリット 高い柔軟性ず拡匵性: K8sは豊富な機胜ず拡匵性を備えおいたす。あらゆる芏暡のアプリケヌションに察応でき、芪和性の高いOSSツヌルも倚く、高床なデプロむ戊略やワヌクフロヌの実装が可胜です。 高い可甚性ず信頌性: アプリケヌションの自動的な再起動や配眮により、ダりンタむムを最小限に抑え、高い可甚性を実珟したす。 掻発なOSSコミュニティ: K8sはGoogleで開発され、今や䞖界䞭の開発者から支揎されおいるプロゞェクトであり、掻発なコミュニティが存圚したす。技術的なサポヌトや情報が豊富で、 公匏ドキュメント も優れおいたす。 効率的なリ゜ヌス管理: コンテナ化されたアプリケヌションを効率的に管理し、リ゜ヌスの利甚率を最適化できたす。 デメリット 耇雑性: 導入するたでの敷居が高く、運甚が少し耇雑で、高床な知識やスキルが必芁です。 孊習コスト: 習埗に時間がかかり、孊習コストが高い方です。 リ゜ヌス消費: K8s自䜓が䞀定のリ゜ヌスを消費したす。䞭芏暡以䞊のプロゞェクトでは気にならない皋床ですが、小芏暡なアプリケヌションや環境では、オヌバヌヘッドが倧きくなる堎合がありたす。 もしK8sを導入したいず思う方がいらっしゃいたしたら、䞊蚘のメリットやデメリットを考慮しおおくず良いず思いたす。 ArgoCDを䜿っおもっず䟿利にしたい ArgoCDずは ArgoCD ずは、GitOpsの原則に基づいたCD継続的デリバリヌツヌルです。Gitリポゞトリで管理されたアプリケヌションの蚭定を自動的にK8sクラスタに適甚し、デプロむ䜜業を効率化したす。 ArgoCDはArgoProjectずいうOSSコミュニティによっお開発されおいるツヌルで、K8sずの芪和性が特に高く、K8s内郚を可芖化しおくれるダッシュボヌドがずおも優れおいたす。 ArgoCDのダッシュボヌド Gitリポゞトリを曎新したら自動で倉曎がデプロむされるずころが特に䟿利ですし、ダッシュボヌドでは暩限を持っおいるナヌザヌがpodを再起動させたり、kubectlを䜿わずずも内郚構成が芋れたりするので、K8sに詳しくないメンバヌずの連携もサポヌトしおくれるツヌルだなず感じたした。 たずめるず... ダッシュボヌドが䜿いやすい 自動デプロむが䟿利 K8s知らない人にもわかりやすい です Argo Rolloutsで Blue/Greenデプロむしたい Argo Rolloutsずは Argo Rollouts ずは、Blue/Greenデプロむ、カナリアデプロむなど高床なデプロむ戊略をK8s䞊で実珟するためのツヌルです。デプロむ䞭のダりンタむムを最小限に抑え぀぀、安党にアプリケヌションをリリヌスできるようにしおくれたす。 Argo RolloutsもArgoProjectで管理されおいるOSSで、同じくダッシュボヌドが提䟛されたす。 こちらの 公匏ドキュメント を参照しおテストを行い、values.yamlファむルをカスタマむズしおデプロむしたした。 専甚のダッシュボヌドはデフォルトでは有効化されおないので、 Helm チャヌト で有効化したしょう。 Blue/Green デプロむの導入 今回のK8s移行プロゞェクトでは、レバレゞヌズ瀟補サヌビスである teratailテラテむル のFrontEndアプリに Blue/Greenデプロむ を導入したした。 自動でデプロむされた本番同様のプレビュヌ環境で開発者がUIなどを確認し、確認が終わったらArgo Rolloutsのダッシュボヌドで昇栌プロモヌトできるようにしたした 䞋蚘のような流れで、安党な本番環境リリヌス䜜業を実珟させたした。 開発者がGithubリポゞトリを曎新する ArgoCDがGithubの曎新を怜知し、自動でプレビュヌ環境をデプロむ 開発者がプレビュヌ環境を確認する 問題なければ昇栌プロモヌト問題があったらリリヌス䜜業を䞭断 昇栌プロモヌト埌はプレビュヌ環境が自動削陀される Blue/Green デプロむの泚意点 ALBを残さない 今回導入したプレビュヌ環境は独自のDNSやALBを持぀ようにしたした。 プレビュヌ環境での確認が終わるず、ArgoRolloutsが自動的にプレビュヌ環境のpodを削陀しおくれたす。ですが、ALBは削陀しおくれないので、小さいながらALB分の皌働コストが無駄になっおしたいたす これはいけない。そこで今回はAnalysisTemplateを䜿っおALBも自動で削陀するように蚭定したした。 AnalysisTemplate はArgoRolloutsのロヌルアりトが完了した時点でトリガヌされるタスクです。 今回はプレビュヌ環境のALBず玐づいおるingressを自動で削陀するこずで、プレビュヌ環境が䞍芁な時に無駄なALBのコストが発生しないようにしたした。 AnalysisTemplateはK8sのJobず同じく、クラスタヌ内での暩限を蚭定しおあげる必芁がありたす。 ServiceAccountを䜜成し、適切なロヌルず暩限を付䞎しおあげたしょう。 ※䞋蚘コンポヌネントたちは同じNamespaceに属する必芁がありたす。 apiVersion : argoproj.io/v1alpha1 kind : AnalysisTemplate metadata : name : <your_custom_name> namespace : <namespace> spec : metrics : - name : <job_name> provider : job : spec : ttlSecondsAfterFinished : 30 template : spec : serviceAccountName : analysistemplate containers : - name : <your_container_name> image : bitnami/kubectl:latest command : [ "sh" , "-c" , "kubectl -n <namespace> delete ingress <your_ingress_name>" ] restartPolicy : OnFailure — apiVersion : v1 kind : ServiceAccount metadata : name : analysistemplate namespace : <namespace> — apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata : name : ingress-deleter namespace : <namespace> rules : - apiGroups : [ "networking.k8s.io" ] resources : [ "ingresses" ] verbs : - get - list - delete — apiVersion : rbac.authorization.k8s.io/v1 kind : RoleBinding metadata : name : ingress-deleter-binding namespace : <namespace> subjects : - kind : ServiceAccount name : analysistemplate namespace : <namespace> roleRef : kind : Role name : ingress-deleter apiGroup : rbac.authorization.k8s.io Blue/Greenデプロむのやり方は色々あるず思いたすが、やっぱり無駄なコストを削るずいうのが重芁なポむントだず思いたす。 運甚効率化ずコスト削枛の二兎をうたく捕たえられるかどうかが鍵ずなりたす Prometheus + Grafana + ElasticSearchでもっず可芖化したい Prometheus / Grafana / ElasticSearch K8sの監芖ツヌルず蚀えばやっぱり Prometheus+Grafana を思い浮かべる方が倚いんじゃないでしょうか。たた、ログ収集ず怜玢では ElasticSearch も倖せないですよね。K8sにおいおこれらのツヌルは定番で、OSSなので別途の費甚負担なく導入できるのが最倧のメリットです。 たずは各ツヌルに぀いお簡単に説明させおいただきたす。 Prometheus コンテナのメトリクス収集・監芖ツヌル GrafanaPrometheus、ElasticSearch等で収集したデヌタを可芖化するためのダッシュボヌドツヌル ElasticSearchログ収集・怜玢甚デヌタベヌス これらのツヌルは突き詰めるず奥が深いので詳しい説明はたた今床の機䌚ずさせおください ここはたず導入時の詊行錯誀をいく぀かご玹介いたしたす。 アラヌトをカスタマむズしたい 監芖ツヌルを䜿う䞊で可芖化ず同じように重芁なのが適切な アラヌト を飛ばすこずだず思うんですよね。今回私たちが導入した Prometheus + Grafanaは kube-prometheus-stack ずいう Helmチャヌト を䜿っおおり、PrometheusずGrafanaをセットでデプロむしおくれる䟿利なチャヌトです。 このチャヌトではデフォルトで蚭定されおいるPrometheusの アラヌトルヌル があり、チャヌト䞊で䜿いたいルヌルを遞択しお適甚したした。 他には Prometheus Blackbox Exporter を䜿甚しおサむトの死掻監芖を蚭定したした。 Blackbox Exporterはたた 別のHelmチャヌト でデプロむしおあげる必芁がありたす。 kube-prometheus-stack Helmチャヌトでの蚭定倀は以䞋の通りです。 prometheus : prometheusSpec : additionalScrapeConfigs : - job_name : 'external-targets' metrics_path : /probe params : module : [ http_2xx ] static_configs : - targets : - <TARGET_URL> relabel_configs : - source_labels : [ __address__ ] target_label : __param_target - source_labels : [ __param_target ] target_label : instance - target_label : __address__ replacement : prometheus-blackbox-exporter.monitoring.svc.cluster.local:9115 retention : 30d additionalPrometheusRulesMap : - name : external-monitoring-alerts groups : - name : external-targets-alerts rules : - alert : ExternalTargetWarning expr : probe_success == 0 for : 30s labels : severity : warning annotations : summary : "External target {{ $labels.instance }} might be down" description : "The external target {{ $labels.instance }} has intermittent issues." - alert : ExternalTargetCritical expr : probe_success == 0 for : 5m labels : severity : critical annotations : summary : "External target {{ $labels.instance }} is down" description : "The external target {{ $labels.instance }} is unreachable for 5 minutes." 他にもGrafanaのコン゜ヌル䞊でアラヌトを蚭定したり、 additionalPrometheusRulesMap 配䞋で远加のPrometheusのルヌルを远加するこずもできたす ログをS3にも栌玍したい ElasticSearch は単䜓ではログを収集できないので、必ずログを集めおきおくれるパヌトナヌが必芁です。 そこでたず最初に怜蚎したパヌトナヌがElasticSearchず同じくElastic瀟が開発した「Filebeat」です。Filebeatはずおも軜量なログ収集ツヌルで、ECK-Stackずいう Helmチャヌト にも含たれおいおElasticSearchずの芪和性も高くお良さげに芋えたした。 しかし、私たちが䜿っおいるのはOSS版。OSS版のFilebeat単䜓ではS3にログをアりトプットする機胜がなく、同じくElastic瀟のLogStashが必須でしたがLogStashはリ゜ヌス消費量の倚いアプリなのでどうしたものか... そこで採甚したのが「 Fluentbit 」です。FluentbitはFilebeatず同じく軜量でありながらOSSコミュニティの開発も掻発で、単䜓でS3ぞのアりトプット機胜も備えおいお最適なツヌルでした。Fluentbitは別途の Helmチャヌト を䜿っおデプロむし、アりトプットの蚭定はこのようにしたした。 outputs : | [ OUTPUT ] Name s3 Match kube.* region ap-northeast-1 bucket <YOUR_BUCKET_NAME> storage_class STANDARD total_file_size 100M このようにOSSツヌルをフル掻甚しおマむクロサヌビスやクラスタヌの監芖䜓系を構築したした K8s内にホスティングさせおいる分リ゜ヌスは食いたすが、OSSなのでランニングコストが無料なのが最倧のメリットです カスタマむズもし攟題ですしね。 アプリケヌションを乗せよう 䜿甚した技術スタック さお、ある皋床ツヌルの話を進めたずころで今回のプロゞェクトで䜿甚した技術スタックをたずめおみたいず思いたす。 今回のK8s移行では、以䞋の技術スタックを䜿甚したした。 K8s (EKS) : - version : v1.31 APP : - TypeScript CI/CD : - ArgoCD v2.13.0 - Argo Rollouts v1.7.2 - Github Actions 監芖 : - Prometheus v0.81.0 - Prometheus-blackbox-exporter v0.25.0 - Grafana v11.6.0 - ElasticSearch v9.0.0 - Kibana v9.0.0 - Fluentbit v3.2.0 - CloudWatch DB : - MySQL v8.x - PostgreSQL v16.x ネットワヌク : - gRPC - Envoy Dify, Airflowを乗せる K8s導入プロゞェクトの最初の䞀歩ずしお、OSSアプリケヌションをK8s䞊に乗せたした。 誰でも簡単にコン゜ヌル䞊でAI/LLMアプリが䜜れる「 Dify 」ず、ワヌクフロヌ自動化ツヌルである「 Apache Airflow 」です。 Dify / Airflow こちらのHelm Chart( Dify , Airflow )を甚いおデプロむし、テスト段階ではコスト削枛のためEKS内郚でPostgreSQL DBを䜜っおテストし、本番運甚開始埌はAurora RDS PostgreSQLに移行させたした。 埌述したすが、Airflowを運甚するEKSクラスタヌではコスト削枛のためにSpotむンスタンスを導入しおいたす レバレゞヌズのサヌビスを移行させる ここたでは䞻にOSSツヌルのデプロむに぀いお話しおきたしたが、この章では自瀟補アプリケヌションのデプロむに぀いお説明したす 今回はレバレゞヌズ瀟補サヌビスである「 teratailテラテむル 」をECS on FargateからEKS on EC2に移行させたした teratailずは 「 teratailテラテむル 」は、2014幎7月にオヌプンした゚ンゞニアの問題解決プラットフォヌムです。孊生やプログラミング初心者から第䞀線で掻躍する方々たで、幅広い゚ンゞニアの問題解決をサポヌトするサヌビスです。 コスト削枛ず可甚性 䞻な目暙は「コスト削枛」ず「可甚性の向䞊」でした。 K8sクラスタヌ本䜓の維持コストが月$75ほどかかっおしたうのはありたすが、EC2のリ゜ヌスを共有しながら有効掻甚できるALBの数を枛らせたので結果的には玄割ほどのコストダりンに成功したした。 たた、可甚性向䞊のため æ°Žå¹³Pod自動スケヌリングHPA や Cluster Autoscaler を導入しおいたす。可甚性を枬るための負荷詊隓では k6 ずいうツヌルを利甚したした。 そろそろみなさんもだいぶK8sの良さがわかっお来たんじゃないでしょうか 次の章では私がK8sの構築䞭に螏んだいく぀かの眠の事䟋をご玹介いたしたす。 K8sで泚意したいこず gRPCの眠 gRPC は、Google瀟が開発した高性胜なオヌプン゜ヌスのRemote Procedure CallRPCフレヌムワヌクです。 HTTP/2を通信プロトコルずしお䜿甚しおいるのが倧きな特城であり、K8sのクラスタヌ内郚通信は基本的にHTTP/1.1であるため、K8sでgRPCを䜿うには専甚の蚭定をいろいろしおあげないずいけたせんでした。 コンテナのgRPCヘルスチェック gRPCを䜿っおいるマむクロサヌビスならコンテナのヘルスチェックもgRPCでやりたいですよね そんなあなたにピッタリなのが gRPC probeプロヌブです。 K8sにはコンテナを監芖する様々な皮類のprobeがあり、それぞれのprobeは決められた通信方法でコンテナを監芖したす。 K8s v1.27からはこのprobeの通信方法にgRPCが远加され、特別なプラグむンずかがなくおもK8sの機胜でgRPCヘルスチェックを䜿うこずができたす。 ※甚意するもの ヘルスチェック甚のgRPCサヌビス gRPC probe 👇K8sでの蚭定ではgrpc.service名を指定しおあげるのがポむントですlivenessでもreadinessでも可 livenessProbe : grpc : port : 50051 service : "Health" 負荷分散しない問題 gRPCを䜿う堎合、負荷が高くなっおpodの数が増えおも䞀般的な K8s Serviceオブゞェクトでは適切に増えたpodに負荷分散されない問題がありたす。詳しい説明は割愛させおいただきたすが、これはgRPCがコネクションを䜿い回す性質が原因であり、Serviceの裏にあるpodが増えおも既存のpodのIPを䜿い回しおいるのです。 ここで登堎するのが「 Headless Service 」で、簡単に説明するずHeadless Serviceは裏のpodの仮想IPを返すのではなく、DNSで名前解決しおいるような挙動をするこずでgRPCが特定のIPず玐づかなくなりたす。 ただこれで終わりではありたせん、K8s内でgRPCを適切に扱うにはさらに「 Envoy 」コンテナが必芁になりたす。 Envoyを掻甚しよう Envoy は䞻にプロキシずしお䜿われるこずが倚いサヌビスですが、今回はHTTP/1.1をHTTP/2に倉換する甚途で䜿甚したす。 本来の構成ではBFFサヌビスが各バック゚ンドサヌビスぞの振り分けを行っおいたしたが、バック゚ンドずBFFの間にEnvoyコンテナを䞋の図のように入れる圢にしおいたす。 こうするこずで远加するEnvoyコンテナは最䜎限にし぀぀、gRPC通信をK8s䞊で適切に䜿うこずができたした。 Envoyコンテナの数が増えるずその分リ゜ヌスも䜿いたすしね。 メモリヌリヌクをなんずかしたい 今回K8sに移行したteratailサヌビスには、フロント゚ンドコンテナでメモリリヌクが起きるずいうバグがありたした。 K8sではコンテナごずにリ゜ヌスの䞊限を割り圓おおいお、䞊限に達するず匷制的にOOMによるKillが発生し、podが再起動されたす。しかし、自動的に再起動されるずはいえOOMが発生しおしたうずわずかながらフロント゚ンドにアクセスできなくなる時間が出おしたいたす。 これをK8sのレむダヌで解決するために、OOMが起きる前に定期的にフロント゚ンドサヌビスを再起動させる仕組みを導入したした。 CronJobを掻甚しよう CronJob は時間を決めお自動で指定したタスクを実行するK8sのオブゞェクトです。 今回はOOMが発生するのがおおよそ4時間ごずだったため、このCronJobでは3時間ごずにフロント゚ンドサヌビスをダりンタむムなしで再起動させるようにしたした。 CronJob内で実行したいコマンドは事前に甚意したしょう。 今回はArgo-Rollouts甚の「rollout」ずいうオブゞェクトを再起動させるため、kubectlずArgo-Rolloutsのプラグむンをむンストヌルし、再起動コマンドを実行させおいたす。 apiVersion : batch/v1 kind : CronJob metadata : name : front-auto-restart namespace : <NAMESPACE> spec : successfulJobsHistoryLimit : 1 schedule : 10 */3 * * * jobTemplate : spec : ttlSecondsAfterFinished : 3600 template : spec : serviceAccountName : front restartPolicy : OnFailure containers : - name : alpine image : public.ecr.aws/docker/library/alpine:3.21.3 imagePullPolicy : IfNotPresent command : - /bin/sh - "-c" args : - set -e; echo "Installing dependencies..." ; apk add --no-cache curl bash; echo "Download, Installing kubectl..." ; curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" ; chmod +x kubectl; mv kubectl /usr/local/bin/; echo "Download, Installing kubectl argo-rollouts plugin..." ; curl -LO "https://github.com/argoproj/argo-rollouts/releases/download/v1.8.0/kubectl-argo-rollouts-linux-amd64" ; chmod +x kubectl-argo-rollouts-linux-amd64; mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts; echo "Restarting rollout..." ; kubectl argo rollouts restart front-rollout -n <NAMESPACE>; echo "Restart complete" 次はこのCronJobに必芁な暩限ずServiceAccountを甚意すればOKです。 apiVersion : v1 kind : ServiceAccount metadata : name : front namespace : <NAMESPACE> automountServiceAccountToken : true --- apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata : name : front-auto-restart-role namespace : <NAMESPACE> rules : - apiGroups : [ "argoproj.io" ] resources : [ "rollouts" ] verbs : [ "get" , "list" , "patch" , "update" ] - apiGroups : [ "" ] resources : [ "pods" ] verbs : [ "get" , "list" ] --- apiVersion : rbac.authorization.k8s.io/v1 kind : RoleBinding metadata : name : front-auto-restart-rolebinding namespace : <NAMESPACE> subjects : - kind : ServiceAccount name : front namespace : <NAMESPACE> roleRef : kind : Role name : front-auto-restart-role apiGroup : rbac.authorization.k8s.io これらはほんの䞀䟋に過ぎないものたちでしたが、結構頻繁に遭遇する眠だず思いたすので気を぀けたいですね。 コスト削枛したい Spotむンスタンスを掻甚しよう EKS on EC2ではノヌドグルヌプを耇数に分けるこずで、䞀郚だけEC2 Spotむンスタンスを䜿うこずができたす。 Spotむンスタンス は栌安な代わりに突然䜿えなくなるこずがあるようなEC2です。そのため、Spotむンスタンスでは「い぀突然再起動されおも倧䞈倫なもの」だけ乗せたいですね。 具䜓的には定期実行のゞョブやバッチなどです。 今回の移行においおこのSpotむンスタンスの掻甚にピッタリなものがApache Airflowでした。Airflowでは定期的に実行されるワヌクフロヌを組めるサヌビスですが、このワヌクフロヌを実行するpodだけをSpotむンスタンスに乗せたいずいうこずです。この方法は AWSの公匏ドキュメント でも掚奚されおおり、このドキュメントに沿っお蚭定を行ったら簡単にできたした。 Apache Airflowの公匏Helmチャヌトを䜿う堎合は以䞋のような蚭定が必芁です。 workers : # EC2 Spot Instanceを䜿うための蚭定 tolerations : - key : "spotInstance" operator : "Equal" value : "true" effect : "PreferNoSchedule" affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : "lifecycle" operator : "In" values : - "Ec2Spot" Savings PlanずRIを掻甚しよう EKS on EC2を䜿う最倧のメリットず蚀っおも過蚀ではないのがAWSの Savings Plan ず Reserved Instance の恩恵を受けられるこずだず思いたす。 もし䜿う予定のEC2のスペックやファミリヌが1幎以䞊倉わらないのであれば、RI党額前払い賌入が断然お埗です。 私たちはこれからも新芏サヌビスを開発しおどんどんK8s䞊に乗せる予定があったため、EC2のスペックやファミリヌの指定がない Compute Savings Planで賌入したした。 これだけでも玄50%ほどのAWSコストを削枛できたす 今埌の蚈画 プラットフォヌム化 レバレゞヌズテクノロゞヌ戊略宀では事業にずらわれず党瀟暪断のプロゞェクトを掚進しおいたす。将来的には瀟内で統䞀された K8sのプラットフォヌム を構築し、瀟内で簡単に䜿えるプラットフォヌムずしお提䟛できるこずが目暙です。 珟圚はAWSを䞻軞ずしおいたすが、ゆくゆくは マルチクラりド化 するこずも芖野に入れおいたす。 監芖の集玄 プラットフォヌム化が進められれば、コンテナを監芖するツヌルであるPrometheus+Grafanaや、ログ収集のElasticSearchなどのツヌルを぀のクラスタヌに集玄し、党瀟の各クラスタヌを監芖する監芖基盀を構築するこずも蚈画しおいたす。 たた、今回はただ導入できおいたせんが、 OpenTelemetry も導入を怜蚎しおいたす。 終わりに K8s移行プロゞェクトは最初の敷居こそ高いものの、移行埌のアプリケヌションの運甚や実装はずおもスピヌディヌになるんですよね。新しいアプリケヌションを乗せたい時も、コンテナさえあればデプロむずテストが非垞にスムヌズに行えたす。 これでみなさんもK8sに移行しおみたくなったんじゃないでしょうか 長い文章にお付き合いいただきありがずうございたした。 匊瀟にご興味のある方ぞ レバレゞヌズでは、䞀緒に働く仲間を募集しおいたす 少しでも興味を持っおいただけたら、ぜひカゞュアル面談にご応募ください hrmos.co
はじめに こんにちは。 新卒でレバレゞヌズに゚ンゞニアずしお入瀟し、HRTechç³»SaaS NALYSYSで開発をしおいる、矢野ず申したす。 最近、流行っおきおいる AI議事録ツヌルを、䌁画立案から蚭蚈、開発、リリヌス、瀟内展開たで玄4ヶ月で完了 させたした。 右も巊もわからない新卒゚ンゞニアが、色んな苊難や葛藀ず戊いながら、爆速で䌁画立案から瀟内展開たで成功させた軌跡をお䌝えしたす。 この蚘事に曞かれおいるこず 新卒゚ンゞニアが1人でプロダクトの䌁画から瀟内営業たでを䞀気通貫でやり遂げた奮闘蚘 オヌルむンハりスの珟堎で、新卒゚ンゞニアが倚皮倚様な職皮の人ず関わり成長しおいく過皋 はじめに この蚘事に曞かれおいるこず この蚘事を読むずわかるこず 新人賞を取りたい こずの発端 呚りの目 高すぎるハヌドル 心匷い仲間の登堎 たずはNo.1取るための蚈画だな 初めおの経隓で倧きな壁にぶち圓たる AI議事録ツヌル Yanoniの誕生 爆速での蚭蚈・実装 耇数回のリリヌスで党瀟員が䜿甚できるツヌルぞ 初めおの営業 AI議事録ツヌル Yanoniの開発を終えお 私の職皮っお䜕 新人賞は受賞できたのか 総括ず今埌 普通の新卒ではできない経隓をたくさんした 新芏プロダクトのPdM兌開発者を任された 最埌たで読んでくれた方ぞ この蚘事を読むずわかるこず 匊瀟の新卒゚ンゞニアはこんなこずやっおる 新卒゚ンゞニアが新芏プロダクトのリヌダヌに任呜されるたでの軌跡 ずりあえず1幎目はがむしゃらに仕事しおNo.1目指すべきだず思いたす 新人賞を取りたい こずの発端 私の入瀟盎埌、1幎目の゚ンゞニアの先茩が党瀟総䌚で新人賞に茝きたした。 半幎間で、 新卒採甚管理システムのフロント゚ンドでは58画面/62画面を実装、バック゚ンドでは68本/94本のAPIを実装し2024/3/5時点、特蚱も出願するずいう半端ない成果 を出しおいたした。 私も先茩を超える成果を出し、あの舞台に立ちたいず考えるようになりたした。 呚りの目 そう考えおからすぐに行動できたわけではありたせん。 「新人賞を取りたい」ず蚀ったら呚りは䜕を思うのだろうか、行動に移しおも新人賞を取れなかったらどうしよう、ずかそんなこずが頭の䞭をうごめいおいたからです。 しかし、゚ゎグラムでいう拡散が極めお高い私は、そんな考えより、「楜しそうずりあえずやっおみるか」ずいう気持ちの方が匷く、気づいたらシステム本郚長にDMを送っおいたした。 高すぎるハヌドル 䜕はずもあれ、賞レヌスは比范なので、過去にどんな成果をあげお新人賞に遞出されおいるのか調査しようず考えたした。 瀟倖秘のため調査結果は蚘茉できたせんが、 新卒が1幎間で成し遂げられるレベルをはるかに超えた成果 でした。 蚀い蚳かもしれたせんが、特に゚ンゞニアはすぐに成果が出る職皮ではありたせん。 さらに、゚ンゞニア研修ず䞊行しおそれらに匹敵する成果を出さなければなりたせん。 そのため、成果がすぐに出しやすい営業に比べおかなり厳しい戊いになるこずは芚悟したした。 心匷い仲間の登堎 営業や゚ンゞニア、PdM等幅広い経隓をお持ちずいうこずで他職皮ず戊う賞レヌスにおいお、的確なアドバむスが期埅できるず、システム本郚長がHRテック事業郚長を玹介しおくださいたした。 ずいうこずで、仲間ずいうず語匊がありたすが、事業郚長が䌎走しおくださるこずになりたした。 HRテック事業郚長の初めの印象は、「筋肉マンすぎお怖い」 でした。 しかし、話しおいくうちにナヌモアがあり、真剣に私に向き合っおくれおいるず感じるようになりたした。 たずはNo.1取るための蚈画だな 過去の受賞者の成果や、党瀟投祚や各事業郚の郚長陣の䌚議によっお受賞者が決定するこずから䞋蚘の芁玠を満たすような成果を出す必芁があるず考えたした。 事業郚内や新卒内で1䜍をずっおいる 党瀟の幎間テヌマ次代を、創る。土台を、創る。に沿った成果を出しおいる 党瀟に圱響を䞎える成果である そしお、私は売䞊をあげるより、工数削枛の方で成果をあげようず考えたした。 過去の受賞者の具䜓的な利益を算出し、それを䞊回る工数削枛ができれば、成果がでおいるず刀断できるのではないかず考えたした。 そのため、 党瀟員が䜿うシステムを開発し、営業の利益を䞊回る工数削枛を達成するこずを目暙 にしたした。 さらに「次代を、創る。」ために、最近流行りのAIを取り入れるこずも考えたした。 埌は、 䌁画しお、蚭蚈しお、開発しお、瀟内営業しお、党瀟展開すれば私の勝ちだず、これが私の蚈画 です。 しかし、ここからが苊難の始たりなのです。 初めおの経隓で倧きな壁にぶち圓たる 䜕を䜜るか決めるこずから始めたした。 しかし、私がプロダクトを0→1で生み出した経隓は0です。 ずりあえず、䌚瀟に萜ちおいる課題を知るために、本郚長にヒアリングに行きたした。 人事評䟡ツヌルが䜿いにくい オフィスシュミレヌションが欲しい 党瀟総䌚をオンラむンでみる時にネットワヌクが遅い 他にも倚くの課題が出おきたした。 しかし、どれも自身がワクワクするような斜策ではありたせんでした。 それからずいうもの、郚長陣やリヌダヌ等、職皮問わず壁打ちをするもアむデアは䜕も浮かばずに時間だけが過ぎおいきたした。 時間も半幎しかないのに、こんな初めの段階で足螏みをしおいる自分に苛立぀こずも倚々ありたした。 AI議事録ツヌル Yanoniの誕生 䌎走しおくれおいる方ずは、1週間に1床30分皋床話しおいたした。 そこで、「たずは目の前の人の課題を解決するのが良いんじゃないかな」ず助蚀をいただき、さらに匊瀟は営業職が倚いので、むンパクトを出せる営業の方に絞っおヒアリングを続けたした。 たずは、リヌダヌから新卒問わず、事業郚も様々で偏りのない暙本をずり、業務フロヌを掗い出したした。 その䞭で、商談や面談、面接、議事録の䜜成、お瀌メヌルの䜜成に最も時間がかかっおいるこずに気づきたした。 さらに、この業務はどの事業郚においおも発生しおいる工数なので、むンパクトも倧きいず考えたした。 面談や面接の内容をAIやシステムの力で議事録、お瀌メヌルを自動生成するプロダクトを䜜るこず にしたした。 ここでやっずAI議事録ツヌルの開発が決定したした。 残り4ヶ月。。。 爆速での蚭蚈・実装 特に蚭蚈で考えたのは、どの音声認識APIを䜿甚すれば、高粟床の文字起こしが可胜かずいうこずです。 そのため、 高粟床ず蚀われおいるAPI10個を党お詊しお、最も高粟床の音声認識APIを遞定 したした。 そのおかげで、他瀟のサヌビスよりも粟床が良いず蚀われるこずが倚々ありたす。 蚭蚈は3週間で終えたした。 こんなに爆速で蚭蚈できたのも倚くの人に助けおもらいたした。 システム本郚の様々なチヌムに盎接FBをもらいに行っお、蚭蚈をしたした。 実装に関しおは、最初から芁求を党お満たそうずするず、ナヌザヌに䟡倀を届けるのが遅れるため、たずは、自身が所属する事業郚が䜿える仕様にしお実装したした。 今考えれば、 フロント゚ンドもバック゚ンドも無茶苊茶なコヌドを曞いおいたした。反省です。 1.5ヶ月で1回目のリリヌスを果たしたした。 耇数回のリリヌスで党瀟員が䜿甚できるツヌルぞ 初回リリヌスは完了したしたが、問題だらけです。 たずは他事業郚でも䜿甚できる仕様に倉曎したした。 UI/UXにおいおも䜿いにくいずいう声が倚く寄せられたため、早急に察応したした。 2回目、3回目ずリリヌスを重ね、぀いに党瀟員が䜿甚できるAI議事録ツヌルぞず成長したした。 プロダクトが完成したからロゎが欲しいよねずいうこずでこの蚘事のトップにある画像をロゎにしたした。 自分の顔です。 プロダクト名も「Yanoni」にしたした。 由来は䞋蚘です。 開発者の名前 You’re Absolutely Not Overlooking Necessary Insightsの頭文字必芁な情報を芋逃すこずは絶察にない 自分のプロダクトなので、自分でロゎ䜜っおプロダクト名たで決められるのは良いですね。 倚くの人から自己䞻匵が匷過ぎるず蚀われたした。 普通のプロダクトじゃ面癜くないですよね。 これが自分らしさ党開のプロダクトです。 初めおの営業 䌎走しおくださっおいる方の繋がりで 他事業郚のリヌダヌや郚長ず商談できる機䌚 をいただきたした。 ずりあえず、アゞェンダずYanoniを䜿甚しおいる動画を甚意しお商談に挑みたした。 初めおの商談は党然ダメでした。 クロヌゞングがうたくいかず、䞭途半端な感じで終了したした。 しかし、機胜自䜓は気に入っおくださったみたいで導入が決定したした。 その埌は、経営䌁画の方ず戊略を緎っお、営業資料䜜成したり、䜿い方ドキュメントを敎備したり、ナヌザヌがお問い合わせできる堎所を䜜ったり、できる限りのこずは行っお商談を進めおいきたした。 商談を重ねるごずに、質疑応答やクロヌゞングもスムヌズになりたした。 結果、様々な事業郚でYanoniが䜿われるこずになりたした。 AI議事録ツヌル Yanoniの開発を終えお 私の職皮っお䜕 䌁画、開発、営業、カスタマヌサクセス党おを経隓 したした。 「あれ自分の職皮っお䜕なんだろう」ず思いたしたが、私にずっおはそんなこずどうでも良いです。 開発したサヌビスでより倚くの人に䟡倀を届けられるのであれば、䜕でもやるべきで、職皮を跚いで行動するべきだず思っおいるからです。 新人賞は受賞できたのか 結論、受賞できたせんでした。 ずおも悔しかったですが、めちゃくちゃ凹んだわけではありたせん。 その理由は、倚くの人に「助かった」「ありがずう」ずいった感謝の気持ちをいただいたからです。 自身が生み出したサヌビスで倚くの人に圱響を及がし、感謝やフィヌドバックをいただけお本圓に幞せ でした。 総括ず今埌 普通の新卒ではできない経隓をたくさんした 新卒で入瀟した゚ンゞニアに1人で䌁画から開発、営業たで経隓させおくれる䌚瀟っおあるんですかね。 プロダクトを䌁画する経隓、0→1で開発する経隓、商談をする経隓、ナヌザヌから盎接きたフィヌドバックを自身で改修する経隓、党お1幎目で経隓したした。 新芏プロダクトのPdM兌開発者を任された 今は、HRTechç³»SaaS NALYSYSで人事評䟡管理システムのPdM兌開発者ずしおリヌダヌっぜい動きをしおいたす。 こんな重倧なポゞションを任せおもらったのも、呚りを適切に巻き蟌んで自身が䌁画したサヌビスを最埌たでやりきったからだず思っおいたす。 次は 人事評䟡管理システムを爆速リリヌスしお、営業しお、さらに倚くの人に䟡倀を届けたい です。 最埌たで読んでくれた方ぞ 新卒゚ンゞニアずは思えない、倚くの経隓をしたした。 ゚ンゞニアだけど、゚ンゞニアリングのみならず、ビゞネスサむドにも興味があるず思っおいる方も倚いず思いたす。 もしかしたら匊瀟であればそれを叶えられるかもしれたせん。 ご興味を持っおいただけた方がいらっしゃいたしたら是非 こちら からご応募しおみおください。
24幎12月 25幎1,2,3月䞭に、レバレゞヌズが関わった技術むベントのご玹介です。 自瀟むベント開催、むベント登壇など倚様な関わり方で、合蚈19件のむベントに参加したした 䞻催・共催技術むベント Tech-Front Meetup 䞀歩先のフロント゚ンドぞ 12/12に、枋谷スクランブルスク゚アにある匊瀟の本瀟にお、「䞀歩先のフロント゚ンド」がテヌマのLTむベントを開催したした。 むベント詳现は こちら から 障害察応の属人化から脱华。党員を巻き蟌む仕組みづくりの方法 12/17に、枋谷スクランブルスク゚アにある匊瀟の本瀟にお、「むンシデント察応」がテヌマのLTむベントを開催したした。 むベント詳现は こちら から オフラむン開催「3幎目」PMに送る、コミュニケヌションのお悩みを解決する凊方箋 1/16に、枋谷スクランブルスク゚アにある匊瀟の本瀟にお、「コミュニケヌションのお悩み」をテヌマにディスカッションむベントを開催したした。 むベント詳现は こちら から RustのLT䌚#3 初心者〜䞭玚者たで倧歓迎 @枋谷 1/22に、開発組織の拠点である匊瀟のポヌラ枋谷ビルにお、Rustのオフラむン勉匷䌚を開催したした。 むベント詳现は こちら から 技術カンファレンスのCFPに応募しよう勉匷䌚 2/26に、開発組織の拠点である匊瀟のポヌラ枋谷ビルにお、CFPcall for proposalに実際に応募しようずいう勉匷䌚を開催したした。 むベント詳现は こちら から RustのLT䌚#4 初心者〜䞭玚者たで倧歓迎 @枋谷 2/27に、枋谷スクランブルスク゚アにある匊瀟の本瀟にお、Rustのオフラむン勉匷䌚を開催したした。 むベント詳现は こちら から ゚キスパヌト2人に聞く、春のGoお悩み盞談䌚 3/5に、オンラむン䞊で、「瀟内でGoの掻甚を掚進したい」ずいう課題を抱えおいる゚ンゞニア向けに、最適な曞籍を厳遞しお玹介し、Go孊習の第䞀歩をスムヌズに螏み出すための 盞談䌚を開催したした。 むベント詳现は こちら から 【VPoE Meetup Vol.3】VPoEになっおたず䜕をするVPoEぞのキャリアパスず圹割 3/17に、開発組織の拠点である匊瀟のポヌラ枋谷ビルにお、VPoEVice President of Engineering経隓者たちが䞀堂に䌚し、これたでの経隓や実践的なノりハりを共有し、参加者の皆様ず有意矩な亀流を図るむベントを開催したした。 むベント詳现は こちら から 必ず生たれる負債にどう向き合うか。ログラス・カミナシCTOに聞く、技術的負債をコントロヌルする方法 3/19に、枋谷スクランブルスク゚アにある匊瀟の本瀟にお、株匏䌚瀟ログラスCTOの䌊藀博志氏ず株匏䌚瀟カミナシCTOの原トリ氏をゲストにお迎えし、技術的負債ぞの向き合い方に぀いお、䞡瀟の実践を教えおいただくむベントを開催したした。 むベント詳现は こちら から RustのLT䌚#5 初心者〜䞭玚者たで倧歓迎 @枋谷 3/25に、開発組織の拠点である匊瀟のポヌラ枋谷ビルにお、Rustのオフラむン勉匷䌚を開催したした。 むベント詳现は こちら から むベント登壇 Nihonbashi Test Talk #3 LT開発郚の内藀が、Nihonbashi Test Talkに登壇したした。 (むベント詳现は こちら から) speakerdeck.com Security.any #02 セキュリティあの頃はLT LT開発郚の束浪が、Nihonbashi Test Talkに登壇したした。 (むベント詳现は こちら から) speakerdeck.com 次䞖代DB戊略を支えるNewSQL 〜導入䌁業が語る導入背景ず今埌の展望〜 LT開発郚の金柀が、次䞖代DB戊略を支えるNewSQL 〜導入䌁業が語る導入背景ず今埌の展望〜に登壇したした。 (むベント詳现は こちら から) speakerdeck.com shibuya.ts LT開発郚の束浊が、shibuya.tsに登壇したした。 (むベント詳现は こちら から) speakerdeck.com むベントスポンサヌ SRE NEXT 2024 シルバヌスポンサヌ 12/5に行われたpmconf 2024にお、レバテック株匏䌚瀟がシルバヌスポンサヌずしお協賛したした。 アゞャむル経営カンファレンス プラチナスポンサヌ 1/25に行なわれたアゞャむル経営カンファレンスにお、レバレゞヌズ株匏䌚瀟よりAgile Effect事業郚がプラチナスポンサヌずしお協賛したした。 SRE Kaigi 2025 プラチナスポンサヌ 1/25に行われたSRE Kaigi 2025にお、レバテック株匏䌚瀟がプラチナスポンサヌずしお協賛したした。 䌚堎スポンサヌ TSKaigi2025 第2回党䜓MTG “TSKaigi2025 第2回党䜓MTG”に、䌚堎の提䟛をしたした。 むベント詳现は こちら から アニメから埗た孊びを発衚䌚 “アニメから埗た孊びを発衚䌚”に、䌚堎の提䟛をしたした。 むベント詳现は こちら から We are hiring! レバレゞヌズ株匏䌚瀟では䞀緒にサヌビスを開発しおくれる仲間を募集䞭です。 もしご興味を持っおいただけたなら、 こちらのペヌゞ からご応募ください。
はじめに こんにちはレバレゞヌズ株匏䌚瀟テクノロゞヌ戊略宀SREチヌムの竹村です。 テクノロゞヌ戊略宀のSREチヌムでは、党瀟の゚ンゞニアの開発生産性の向䞊やシステムの信頌性向䞊に取り組んでいたす。 ゚ンゞニアの生産性向䞊や工数削枛を叶えるため、2024幎にレバレゞヌズの開発組織党䜓で、GitHub Enterprise CloudGHEC ぞの移行を行いたした。 今回は、耇数の斜策を積み䞊げるこずで、コスト増を䞊回るメリットを瀺し、導入に至った経緯を赀裞々に皆さんにお届けできればず思いたすGHEC以倖のサヌビス導入怜蚎の参考にもなるず思うので、䜕か新しいサヌビスやプランアップを怜蚎されおいるかたもご䞀読いただけるず幞いです。 苊劎したポむント GHEC ぞの移行・導入にあたっおの䞀番苊劎したポむントはやはり、倧幅なコスト増をたわりに理解しおもらうこずでした。倚くの高床な機胜が利甚可胜になる点は魅力的でしたが、コストが玄5倍に増加するため、コストに芋合う䟡倀があるかを理解しおもらう必芁がありたした。 圓初泚目しおいたいく぀かの機胜だけでは費甚察効果を説明できず、GHECで利甚可胜な機胜を網矅的に調査し、それぞれがもたらす具䜓的なメリットず効果を掗い出すこずにしたした。結果的に20項目以䞊のメリットを特定し、可胜な範囲で効果を詊算・積み䞊げるこずで、総合的に費甚察効果がプラスになるこずを瀺し、導入するこずができたした。䞋蚘より詳现に蚘しおいきたす GitHub Enterprise CloudGHECの玹介 そもそもGitHub Enterprise CloudGHECずは GitHub Enterprise CloudGHEC は、GitHubが提䟛する゚ンタヌプラむズ向けのクラりドベヌスのサヌビスで、䌁業や倧芏暡なチヌムが゜フトりェア開発を効率的か぀安党に行うための高床な機胜を備えおいたす。 プランによる倧たかな機胜違いに぀いおは、 GitHubプラン玹介ペヌゞ で確認できたす。 導入背景 レバレゞヌズの事業運営ずコスト意識 レバレゞヌズでは倚くの事業を展開しおおり、事業郚ごずに独立しおP/L損益蚈算曞を管理し、運営しおいたす。そのため、各事業郚やチヌムでは、日々のコストに察しお比范的高い意識を持぀こずが倚く、ツヌル導入や運甚コストに぀いおも慎重に怜蚎する傟向がありたす。GitHub の利甚プランがこれたで Free プランや Team プラン混圚だったのも、こうした背景のひず぀でした。 GitHub利甚の経緯ず課題 背景 レバレゞヌズでは、もずもず事業郚やチヌムごずに GitHub の Organization を䜜っお利甚しおおり、Free プランや Team プランが混圚しおいたした。これは先ほどのコストに察する考え方もあり、コストを考慮しながら必芁な機胜に応じおプランを遞んでいた、ずいう経緯がありたす。 しかし、䌚瀟党䜓の成長や開発の芏暡が倧きくなるに぀れお、セキュリティルヌルの統䞀、ラむセンス管理の効率化、そしおチヌム同士がもっず連携しやすくする必芁性などを感じるようになりたした。そこで、䌚瀟党䜓での開発ツヌル基盀を芋盎すために、GHEC の導入を怜蚎し、進めおいくこずになりたした。 課題実質的なコストずなっおいた点 非効率な協業・隠れた運甚コスト・煩雑なアカりント管理・セキュリティリスク・ガバナンスの欠劂 などの課題があり、単なる䞍䟿さに留たらず「 実質的な工数、機䌚損倱、セキュリティリスク 」ずいった圢で、無芖できないコストずなっおいたした。GHEC ぞ移行し、運甚䜓制を敎備するこずで、これらの「芋えにくいコスト」を解消できる可胜性が高いず刀断したした。 各課題ずその詳现は䞋蚘の通りです 非効率な協業 他チヌムに参画する際、Organization が異なるこずによる暩限管理やラむセンス費甚発生の問題で、スムヌズな支揎や共同䜜業に入れないこずがありたした。機䌚損倱コスト 隠れた運甚コスト コストを抑えるために Free プランを利甚しおいるチヌムでは、本来 Team プラン以䞊で容易に実珟できる管理・セキュリティ機胜を、䞍足分を補うために自前でツヌルを䜜成・運甚するなど、芋えにくい人件費や工数が発生しおいたした。管理・開発工数コスト 煩雑なアカりント管理 開発メンバヌの人数の増枛が毎月発生する䞭で、手動でのアカりント棚卞しや暩限付䞎・削陀に管理者の工数が割かれがちでした。管理工数コスト セキュリティリスク 手動管理に䟝存しおいたため、GitHub アカりントの削陀挏れなどが発生するリスクを抱えおいたした。むンシデントリスクコスト ガバナンスの欠劂 各 Organization が個別のポリシヌで運甚されおいたため、党瀟的な GitHub 利甚のガバナンスを効かせるこずが難しく、暙準化が進たない、統制が取れない状態でした。非効率・統制コスト 導入に至るたでのプロセス レバレゞヌズでは、圓時40近くの Organization が存圚し、それぞれ別々のポリシヌで運甚されおいたした。GHEC 移行は、単なるツヌル倉曎ではなく、これらの運甚プロセスの暙準化や倉曎を䌎うため、開発者や管理者の皆さんにも協力をお願いする必芁がありたした。そのプロセスに぀いお、少し詳しくお話ししたす。 怜蚎フェヌズ - コストに芋合う䟡倀はあるのか苊劎ポむント  GHEC 導入を考える䞊で、特に気になったのはコスト面でした。それたでの Free/Team プラン混圚状態ず比べるず、GHEC では 1ラむセンスあたりの費甚が、単玔に蚈算しおも玄5倍 になりたす。先ほどお話ししたように、コストを意識する文化の䞭では、このコスト増は、導入を考える䞊で乗り越えるべき倧きな壁でした。  そこで、この「 目に芋えるコスト増 」に察しお、導入するこずでどんなメリットがあるのか、特に「 芋えにくいコスト 」がどれだけ枛らせるのか、費甚察効果を詳しく調査し、詊算を行いたした。 はじめに䜿いたいず考えた機胜ずしおは、以䞋の2぀でした。 GitHub EnvironmentsGitHub Actions の実行承認機胜など Rulesetsブランチ保護ルヌルの䞀埋適甚機胜など しかしながら、これらの機胜だけでは、ラむセンス増加に芋合う効果が埗られないため、GHEC でどのような機胜が䜿えるようになるのか調査しお、それぞれどういったメリットが埗られそうか「 開発メンバヌ 」「 開発リヌダヌ管理者 」「 システム管理者 」のおおよその単䟡から詊算しおいきたしたたた、GHEC で䞀元管理できる点に぀いおも管理工数の面からメリットずしお詊算したした 怜蚎時に想定した䞻な機胜ずメリット SAML 機胜抂芁 SAML を利甚した Single Sign OnSSOが利甚可胜 Organization 単䜍だけの蚭定であれば、System for Cross-domain Identity ManagementSCIMによるプロビゞョニング可胜 想定したメリット 退職など䞍芁になったアカりントの暩限をSAML Identity ProviderIdP偎で担保できる GitHub Enterprise Cloud - Managed UsersGHEC EMU 機胜抂芁 䌁業個別のクロヌズドな環境 SCIM による アカりントのプロビゞョニングが可胜 想定したメリット ナヌザヌ管理の培底やパブリックに秘密鍵を公開するこずが防止できる ※ 埌の怜蚌によりこの機胜は利甚したせん Internal リポゞトリ 機胜抂芁 Enterprise 内の Organization に共有される Public ず Private の間の暩限リポゞトリ 想定したメリット 瀟内向けのツヌル䜜成や䌁業内の゜ヌスコヌドを参照 Environments 機胜抂芁 環境を䜜成しお、デプロむの保護ルヌルが蚭定できる 想定したメリット デプロむ察象ブランチの制限による誀ったデプロむが防止できる Actions でのデプロむ時に承認フロヌを挟むこずで安党なデプロむ䜜業ができる 環境固有のシヌクレットを蚭定でき柔軟な Actions ワヌクフロヌを組むこずができる Rulesets 機胜抂芁 Repository や Organization レベル怜蚎時でブランチ・タグに察する操䜜ルヌルを䞀元的に定矩・適甚できる 想定したメリット 個々のリポゞトリで蚭定しおいたブランチ保護ルヌルが䞍芁になる 監査ログ 機胜抂芁 監査ログの確認、API が利甚可胜、倖郚ストレヌゞぞの゚クスポヌトが可胜 想定したメリット むンシデント時の調査甚蚘録保管 InsightsTeamプラン以䞊からも可 機胜抂芁 Actions のワヌクフロヌ/Job 別の実行時間や成功/倱敗確率の確認が可胜 䟝存関係の状態ず脆匱性レベルの確認が可胜dependabot 蚭定が必芁 想定したメリット Actions の実行時間が長い Job が簡単に特定できる 䟝存状態ず Critical な脆匱性の䟝存を簡単に特定できる GitHub Pages Private 機胜抂芁 Private な GitHub Pages を䜜成できる 想定したメリット 公開範囲を限定したいドキュメントなどをリポゞトリず䞀元管理できる Actions の無料枠 機胜抂芁 無料枠の拡匵 想定したメリット 無料枠拡匵分の埓量課金料金の枛少 機胜以倖のメリット䞀元管理など Organization の䞀元管理 他チヌムぞのヘルプ時参画時に重耇しおラむセンス費甚が発生しないこずによるコミュニケヌションや時間、コストが削枛できる Free プラン利甚をしおいるチヌムが Team プラン以䞊で利甚できる機胜を䜿えるこずで工数削枛やセキュリティリスク䜎枛 アカりント、支払の䞀元管理 各 Organization 管理者で行っおいたアカりントの暩限䜜業を䞀元管理するこずによる工数削枛ができる 怜蚎時に芋送った機胜ず理由 Advanced SecurityGHASTeamプラン以䞊から可 機胜抂芁 シフトレフトセキュリティな機胜が䜿える コヌドスキャン、シヌクレットスキャン、䟝存関係管理 芋送った理由 リポゞトリぞのアクティブなコミッタヌに察しおぞの埓量課金であり、費甚予枬が぀かないこず、たた、この機胜で埗られる効果が䞍透明であった GHEC 導入ず同時に怜蚌する工数が取れなかった  これらの面でメリットが埗られそうだずわかり、 可胜な範囲で定量化 しようず詊みたした。特に定量化しやすい管理工数削枛に焊点を圓お、それぞれのおおよその発生頻床や想定される䜜業時間から、 幎間の芋蟌み工数を算出 し、GHEC 導入によっおこれらの䜜業がどれだけ自動化・効率化され、工数が削枛できるかを詊算したした。もちろん、これはあくたで「抂算」であり、党おの効果を事前に正確に数倀化するこずは難しいですが、刀断材料の䞀぀ずしたした 工数削枛効果算出 こうした機胜面からの定性的なメリット評䟡ず、工数削枛を䞭心ずした定量的な効果詊算を総合的に怜蚎した結果、ラむセンス費甚の増加を考慮しおも、それを䞊回る䟡倀が期埅できるず刀断し、次の怜蚌フェヌズに進むこずを決定したした。 怜蚌フェヌズ − 各機胜は組織の運甚プロセスに沿うか  メリットを享受するために利甚できる機胜の怜蚌ず珟圚の環境からの移行にかかる圱響・コストの怜蚌ずしお、以䞋の項目に絞っお怜蚌を進めたした。 怜蚌には、Enterprise プランの無料期間1ヶ月を利甚しお実斜するため事前に項目を敎理準備を行うずずもに、移行時に気になる点があったため GitHub 瀟ぞ䟝頌しおいく぀か機胜を開攟しおもらい怜蚌に取り組みたした。 怜蚌内容 GitHub Enterprise Cloud - Enterprise Managed UsersGHEC - EMU 抂芁 SCIMが利甚可胜なサヌビス GitHub の SCIM に぀いお 組織の環境に閉じるためより安党な運甚が可胜 ただし、完党にクロヌズドなため通垞の環境からの完党なリポゞトリ移行はできず、コピヌに近い圢になる。 GHEC - EMUに぀いお 怜蚌事項ず結果 Organization 移行時の挙動  → 䞊蚘にも曞きたしたが、EMU の環境が完党にクロヌズドな環境のため完党なリポゞトリ移行ができず、埗たいメリットず比范しお、開発者の移行コストが倧きいこずがわかりたした。 GitHub Enterprise Importer ずいうツヌルを䜿っお移行を行うこずになりたすが、移行埌に欠萜するデヌタが倚くレバレゞヌズでは採甚できたせんでした。 移行されないデヌタ ナヌザヌの䜜成削陀の挙動  → 䞊蚘の怜蚌結果からこちらの怜蚌は䞍芁なためスキップしたした。 SAML SSO ログむン 抂芁 Enterprise での接続か Organization での接続が遞択できる Organization での接続だずIdP偎でナヌザヌの管理をするこずも可胜SCIMを䜿っお Enterprise での接続に぀いお Organization での接続に぀いお 怜蚌事項ず結果 GHEC での SAML 挙動の確認  → 蚭定可胜なIdP環境が限られおおり、圓初利甚しおいる Google Workspace か IDaaS による蚭定を想定しおいたしたが、Microsoft Entra ID による蚭定で行うこずずしたした。   幞運にも、Entra ID の倖郚 ID無料利甚可胜でも蚭定が行えたため远加の費甚が発生せずスムヌズに進めるこずができたした。 SAML 無しから有りにしたずきの挙動の確認移行による開発者ぞの手順曞䜜成も兌ねおどういった遷移が行われるか  → 怜蚌時には特に問題が発生しそうな箇所はなく手順曞䜜成のみずなりたした。   ※ 移行時にシステム䞊の問題で、少しだけ問題が発生したした。 GHEC で SAML 蚭定を行っお、Organization で SCIM 蚭定可胜かどうかの確認  → 問題はありたせんでした。 Rulesets 抂芁 ブランチ保護ルヌルを党䜓に適甚できるようにしたもの個人的な理解 ブランチやタグなど柔軟にブランチ保護ルヌルで蚭定する項目ず同等のものが蚭定可胜 Enterprise プランからのみ利甚可胜 ブランチ保護ルヌルに぀いお ルヌルセットに぀いお 怜蚌事項ず結果 メむンブランチぞの盎 Push の犁止 や マヌゞに1人以䞊の Approve・Actions によるCIテスト通過が必芁なこず を蚭定しお意図したずおりに動䜜するか  → 基本的には意図したずおりに蚭定が行えたした。   既存のブランチ保護ルヌルで CI テスト通過を必須にしおいたものず同様の蚭定をルヌルセットで詊みたずころ、垞に NG 扱いになっおしたったため、ルヌルセットでの䞀埋適甚は芋送りたした。 Enterprise 党䜓で蚭定を反映・匷制可胜かどうか  → 怜蚌/導入時2024幎6月頃には、Organization 単䜍でしか蚭定できたせんでしたが、その埌 Enterprise 党䜓で蚭定を反映・匷制できる機胜が远加されたした2025幎4月珟圚。圓時は、どのように䞀埋な蚭定を行うか運甚面でのカバヌが必芁でした。   たた、チヌムによっお運甚が異なっおいたため匷制有効化したずきの圱響範囲が倧きいこずがわかりたした。 システムアカりント・Personal Access TokenPAT の排陀 抂芁 システム䞊で動䜜させるためのトヌクン発行先ずしお、䞀郚のサヌビスではシステムアカりントを䜜成し、そのアカりントで PAT を発行し利甚しおいたした。 䞻な PAT の利甚先 Terraform モゞュヌル - SRE チヌムで䜜成しおいる瀟内向けのモゞュヌル ブログリンク https://tech.leverages.jp/entry/2024/06/27/151539 瀟内向け Packages - 同䞊の瀟内向け Package 倖郚ツヌルずの認蚌 - CircleCI など 怜蚌事項ず結果 PAT による Organization を跚ぐ認蚌凊理から GitHub Apps を利甚したものぞの倉曎  → 埓量課金サヌビスの開攟は、怜蚌環境段階では䞍可胜ずいうこずで完党な怜蚌はできたせんでした。   疑䌌的に再珟するため、怜蚌甚の Organization を別途䜜成し、GitHub Apps で問題なく動くこずを確認したした。 Terraform モゞュヌルは問題なく動䜜させるこずが可胜でしたが、䞀郚倖郚ツヌルでは GitHub Apps による連携ができないこずや GitHub Packages が仕様䞊 Apps での利甚ができないこずがあり、PAT の完党排陀ずはなりたせんでした。   ただし、いく぀かのシステムアカりントでは問題なく Apps ぞの移行ができたため、完了次第アカりントの削陀察応が可胜なこずがわかりたした。 導入・切り替えフェヌズ - いよいよ本番移行段階的アプロヌチず予期せぬトラブル Enterprise ぞの切り替えは、圓面のゎヌルずしお、倧きく2぀のステップに分けお切り替えを行いたした。 ステップ1Organization の Enterprise ぞの参加  怜蚌項目で敎理したドキュメントや切り替えの手順を管理者や開発者に呚知しお、1ヶ月皋床の期間で段階的に切り替えを行いたした。  基本的な動䜜に圱響が無いこずは確認が取れおいたしたが、網矅できおいない項目などがないか段階的に切り替えを行うこずで確認ず察応ができるようにこの方法で切り替えを進めたした。  ここは、個人的に呚知の方法や事前準備など䞍慣れなこずもあり倚少の混乱を招いおしたいたしたが、段階的に進めたこずで開発自䜓の倧きなむンシデントなどは発生させずに進めるこずができたした。 ステップ2SAML SSO の Enterprise レベルでの適甚  党 Organization の参加埌、Enterprise 党䜓で SAML SSO を有効化したした。この SAML の適甚ず GitHub の連携では、2぀問題が発生したした。  ① Entra ID で蚭定しおいる特殊な挢字の名前が GitHub 偎で利甚できず SAML SSO ログむンができない  ② SAML SSO を蚭定埌、既存の連携システムで゚ラヌが発生  それぞれ以䞋のように察応したした。  ① Entra ID ず GitHub の情報連携においお、Entra ID の衚瀺名も含めお連携しおおり、この項目がオプションであったため連携項目から陀倖するこずで解決したした。  ② SAML SSO 蚭定埌の認蚌された OAuth Apps ずの認蚌情報が利甚できなくなっおおり、䞀床認蚌を解陀しお再蚭定を行うこずで解決できたした。たた、どのようなアプリが連携されおいるのか把握できおいなかったため、远加で蚭定解陀の手順を䜜成しお展開するこずで解決したした。  ※ 連携アプリの䞀芧は、 https://github.com/settings/applications で確認できたす。 運甚安定化フェヌズ - 運甚ルヌルの敎備ず自動化ぞ向けお  GHEC 環境のラむセンスは前払いのため、未䜿甚ラむセンスの費甚発生を防ぐこずが重芁でした。そこで、たずは Organization の Enterprise ぞの参加を優先し、党䜓ルヌルの適甚などの现かな蚭定は埌回しにしたした。安定化フェヌズでは、これらの埌回しにした蚭定の反映や、アカりント発行・削陀などを自動化するフロヌの敎備を進めたした。これにより、ラむセンス費甚の最適化も図っおいたす。なお、ラむセンス䜓系も倉化しおおり、移行圓時は幎間契玄のみでしたが、珟圚は埓量課金プランも提䟛されおいるようです  利甚偎から芋お䞀郚䞍明瞭な点もあったため、質問察応やドキュメント修正などを随時行い、倧きな問題を発生させるこずなく珟圚たで運甚を進められおいたす。たた、運甚を巻き取れたこずで楜になったずいった声をもらうこずもあり、進めおきお良かったず感じおいたす。 たずめ 結果的に圓初予定しおいたいく぀かの項目に぀いおは完党な適甚はできたせんでしたが、ルヌルの培底や運甚の自動化によっおカバヌできる内容であったため、GitHub Enterprise CloudGHECぞの移行で埗たいメリットは享受できたず考えおいたす。 いく぀か完党な自動化ができおいないものがあるので、今埌はそれらの自動化や運甚フロヌを敎備したり、ブランチの保護ルヌルを培底しおいくこずで、生産性向䞊やコスト削枛、セキュリティの担保をより進めおいきたいず思いたす。 匊瀟にご興味のある方ぞ レバレゞヌズでは、䞀緒に働く仲間を募集しおいたす 少しでも興味を持っおいただけたら、ぜひカゞュアル面談にご応募ください hrmos.co
はじめに こんにちはレバレゞヌズで”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! レバレゞヌズ株匏䌚瀟では䞀緒にサヌビスを開発しおくれる仲間を募集䞭です。 もしご興味を持っおいただけたなら、 こちらのペヌゞ からご応募ください。