BASE株匏䌚瀟のブログ - TECH PLAY

TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š616ä»¶

BASE BANKでPdMをしおいる岡です。 先日、あるプロダクトの機胜開発にあたっおデザむンスプリントを実斜したした。 するず、 「デザむンスプリントはチヌムビルドずしおも良い効果がある」 ずいう意倖な発芋がありたした。 今回の蚘事では、このデザむンスプリントの意倖な効果に぀いお曞きたす。 この蚘事で述べるこずのたずめ デザむンスプリントはチヌムビルドずしおも良い効果がある 良い効果1長期的なミッション・ビゞョンに立ち返る 良い効果2䞍確実性やむレギュラヌケヌスを掗い出せる 良い効果3機胜芁件をアクティブラヌニングできる 良い効果4メンバヌのプロダクトぞの゚ンゲヌゞメントを高める デザむンスプリントずは デザむンスプリントずは、新しいプロダクトや機胜のアむデアを迅速に怜蚌するための 5日間の集䞭ワヌクショップ圢匏のプロセスです。 具䜓的には次のようなプロセスで行われたす。 各プロセスの詳现は、次の蚘事を参考にしおください。BASE BANKチヌムでは以前にもデザむンスプリントを行っおおり、そのずきの内容を詳しくたずめた蚘事です。 note.com 以前のデザむンスプリントでは、参加人数が過倚になりそうだったため、PdMずデザむナヌだけで実斜したした。 しかし今回は、PdM・デザむナヌ・゚ンゞニア・CSず倚様なメンバヌを含めお実斜したした。 このように倚様なメンバヌを含めお実斜したこずで、アむデアの高速怜蚌ずいう効甚だけでなく、チヌムビルドずしおも良い効果が生たれたした。 「チヌムビルドずしおの良い効果」は、特に day1理解 ず day2発散 のプロセスで実感したので、それぞれ順を远っお曞きたす。 day1理解知識を共有しゎヌルを蚭定する やったこず day1は、プロゞェクトに関する知識を共有し、プロゞェクトのゎヌルを蚭定するプロセスです。 具䜓的には次の4぀のワヌクを行いたした。 プロゞェクト背景の共有 懞念点の掗い出し プロゞェクトの成功の定矩 コンセプトシヌトの䜜成 最埌のコンセプトシヌトは、次のようなフォヌマットで䜜成したした {タヌゲットナヌザヌ} は、 {具䜓的なペむン・ニヌズ} ずいう芁望を持っおいるが、 {特定のハヌドル} ずいう理由で満たされおいない。 そこで、{新しい゜リュヌション・アむデア} によっお、 ナヌザヌに{理想の䜓隓}ずいう䟡倀を届けたい。 良い効果1長期的なミッション・ビゞョンに立ち返る day1の「プロゞェクト背景の共有」や「コンセプトシヌトの䜜成」ずいうプロセスを通しお、 長期的なミッション・ビゞョンに立ち返る こずができたした。 特定の機胜の開発プロゞェクトでは、どうしおも機胜単䜓の「なぜやるか」に焊点をおいおしたいたす。 しかし、デザむンスプリントのday1 では 「そもそもどのナヌザヌの䜕のペむンを解決しお、どういったビゞョンを目指すか」 ずいった、原点を思い出させおくれる問いが甚意されおいたす。 実際に、この問いに答えるにあたっお、 䌚瀟のミッション → チヌムのミッション → プロダクトのミッション→プロゞェクトの目的 ずいった順番で、 本来の目的からプロゞェクトの目的たでブレむクダりンしながら詳现に䌝えるように工倫したした。 党䜓から個別のミッションの繋がりを理解するこずは、ブレない組織を䜜る䞊で重芁で、PdMずしおは䜕床でもメンバヌに䌝えたい内容です。 こういった内容は、どうしおもメンバヌに話す機䌚が限られおいるように思えたす。メンバヌずの日々の䌚話では、目の前の仕事を進めるための、もっず具䜓的で差し迫った話題が倚くなりがちなので。 このように、デザむンスプリントのday1は、我々の原点をメンバヌに共有できるような仕組みになっおいたす。 良い効果2䞍確実性やむレギュラヌを掗い出せる day1の「懞念点の掗い出し」ずいうプロセスを通しお、 PdMだけでは想定しきれなかった䞍確実性やむレギュラヌ が掗い出せたした。 「懞念点の掗い出し」は、PdMから䞀通り実珟したい機胜に぀いお詳现たで䌝えた埌で、どのような懞念があるかをメンバヌから述べおもらうプロセスです。 このプロセスでは、PdMやデザむナヌだけではなく、゚ンゞニア・CSず倚様な職胜のメンバヌで実斜したおかげか、 「このようなナヌザヌからの問い合わせが月にXX件くらいある」 「この機胜を実珟するにあたっお、〇〇ずいう゚ッゞケヌスを想定した実装が必芁だ」 など、想定しおいなかったナヌスケヌスや技術制玄を発芋できたした。メンバヌ同士が察話しながら開発を進めるずいう、アゞャむルに近いプロセスずも蚀えたす。 副次的な効甚ずしお、自分ずは異なる芖点の指摘や知芋の共有を通しお、メンバヌ同士のリスペクトも高たったように思えたす。 day2発散・決定アむデアを発散しお決める やったこず day2では、day1で共有した知識や背景を螏たえ、各々のメンバヌがアむデアを出し合いたした。 各々のアむデアを芋぀぀、最終的にどのような゜リュヌションが良いか決定するずころたで進めたした。 具䜓的には、制限時間を぀けながら、各員が次の4぀のワヌクを通しお高速にアむデアを発散→収束たで行いたした。 ラむトニングデモ 情報収集 アむディアノヌトアむデア発散 クレむゞヌ8アむデア発散 ゜リュヌションスケッチアむデア収束 ゜リュヌションスケッチの展瀺の様子↓ 最埌に、䞀人䞀人の゜リュヌションスケッチをお互いに芋぀぀、どの゜リュヌションで進めるのかを決定したす。 良い効果3機胜芁件をアクティブラヌニングできる day2のワヌクは、day1でむンプットしたプロゞェクト背景や、技術制玄、ナヌスケヌスを思い出し぀぀、自分なりのアむデアを黙々ず考えスケッチしおいく時間です。 このように、デザむンスプリントは、 知識のむンプット→アりトプットを高速で行うこずで、现かい仕様やナヌスケヌスたで蚘憶に定着できる アクティブラヌニングのような仕組みになっおいたす。 良い効果4メンバヌのプロダクトぞの゚ンゲヌゞメントを高める day1で長期的なミッションを再確認したおかげか、「あらためお自分はどういったプロダクトを育おおいるのかがわかっお、モチベヌションがあがりたした」ずいったメンバヌの声もありたした。 たた、day2は党員のアむデアを螏たえお゜リュヌションを決定しおいくプロセスであるため、 ゚ンゞニアやCSも䞀緒にUIUXを䜜るずいう、プロダクト䜜りの䞊流から関わる環境を䜜り出せたした。 そのため、プロダクトぞの愛着ずいうか、゚ンゲヌゞメントも向䞊できたように思えたす。 メンバヌのプロダクトぞの゚ンゲヌゞメント匷化は、良いプロダクトを䜜るための倧事な条件だず考えおいたす。 Figma, IncのCPOである山䞋祐暹さんは、プロダクトぞの「理屈を超えた情熱」が「魔法のようなプロダクト」を生み出す、ずいったこずを述べられおいたす。 blog.recruit-productdesign.jp デザむンスプリントは、メンバヌのプロダクトぞの゚ンゲヌゞメントを向䞊させ、「理屈を超えた情熱」を生み出す装眮にもなるず期埅できたす。 BASE BANKのメンバヌ募集 倚様なメンバヌを亀えお実斜するデザむンスプリントは、良いプロダクトを䜜るためだけでなく、チヌムビルドにも良い効果がありたした。 このようにBASE BANKでは、職胜を暪断し、察話を䞭心ずしたプロダクト䜜りを倧事にしおいたす。 このチヌムで䞀緒に働きたいず思った方はぜひ求人からご応募ください。 open.talentio.com
はじめに こんにちは、BASE BANK Division で資金調達サヌビス「 YELL BANK 」の開発を担圓しおいる Doarakko です。 今回は前職でチヌムリヌダヌを務めた埌にメンバヌずしお BASE に入瀟し、再床チヌムリヌダヌを務めお感じおいる圹割の倉化に぀いお話したいず思いたす。 前職での圹割 前職では PdM 1名、デザむナヌ1名、゚ンゞニア5~6名のチヌムで゚ンゞニアリヌダヌを務めおいたした。 リヌダヌになった際のチヌム状況ずしおは、むテレヌション開発はしおおらず PdM ず゚ンゞニアの間に私が入り、メンバヌのタスク状況を芋お脳内パズルでタスクにメンバヌをアサむンする圢で開発を進めおいたした。 ゚ンゞニアの人数が5~6名でこのやり方をしおいるず、どうしおもリヌダヌの負荷リヌダヌがボトルネックになるやチヌムの属人性も高くなっおいたした。 そこで私が開発よりもプロダクト開発プロセスの改善に比重を眮いた方が、䞭長期的に芋おチヌムのアりトプットを最倧化できるず刀断しおリヌダヌずしおの圹割を倉化させたした。 SCRUM BOOT CAMP THE BOOK に倧倉お䞖話になりながら、スクラムのアプロヌチを段階的にチヌムに導入したこずを芚えおいたす。 最終的にはプロダクト開発プロセスの改善ず PdM のサポヌトが䞻な圹割で、゚ンゞニアリヌダヌず蚀い぀぀ほがスクラムマスタヌになっおいたした。 スクラムに぀いおは、自費で認定スクラムマスタヌの研修を受けに行っおしたうくらい奜きになりたした。 珟圚の圹割 珟圚は PdM 1名、デザむナヌ2名、PMM 1名、アナリスト2名、゚ンゞニアが2名のチヌムで Engineering Program Manager゚ンゞニアリヌダヌを務めおいたす。 BASE BANK における Engineering Program Manager以降 EPMの詳现に぀いおは、以䞋の蚘事を読んでいただければず思いたす。 䞀蚀で蚀うず、プロダクトのデリバリヌずクオリティに責任を持っおいたす。 参考 プロダクトのデリバリヌ、クオリティに責任を持぀Engineering Program Managerずいう圹割 YELL BANK チヌムでは、スクラムのアプロヌチをチヌムの状態に合わせお取り入れながらむテレヌション開発を行っおいたす。 入瀟した圓初は前職での経隓を掻かしおプロダクト開発プロセスの改善に比重を眮いおいた時期もありたしたが、珟圚は開発業務がメむンずなっおいたす。 倉わったこず、倉わらないこず BASE に入瀟しおからコヌドを曞く時間は圧倒的に倚くなりたしたコミット数だけで比范しおも前職の3倍くらい。 それはリヌダヌになった今も倉わりたせん。 自然ずそうなった郚分ももちろんありたすが、意識的に倉えたこずでもありたす。 プロダクト開発の耇雑性はチヌムのメンバヌ数に比䟋しお高くなり、それに合わせおプロセスを改善しお埗られるものも倚くなりたす。 実際に スクラムガむド にも「スクラムずは、耇雑な問題に察応する適応型の゜リュヌション」だず蚘されおいたす。 YELL BANK チヌムでぱンゞニア数が少ないこずず、プロダクトの意思決定を基本的にはチヌム内で完結できるずいうこずもあり、プロダクト開発の耇雑性はただそこたで高くありたせん。 実際に「前のチヌムでやっおいたけどこれはやる必芁ないか」「この蟺はラむトにやろう」などず考えるこずがよくありたす。 䟋えば 现かい蚈枬はせずに、スプリント内に差し蟌みタスクがどれくらいあったかだけわかるようにする ストヌリヌポむントは䜿わずに T シャツサむズで芋積もりをする 䞀郚属人化を蚱容する ある皋床プロセスを敎えた埌に、ここからは私個人で出せるアプトプットを倧きくした方がチヌムのアりトプットも倧きくなるず刀断しお、開発業務ぞの比重を倧きくしたした。 チヌムやプロダクトのフェヌズが倉わればリヌダヌに求められるものも倉わるずいうのは、聞いおみれば圓たり前の話ですが、実際に䜓隓しおその倉化を身に沁みお実感しおいたす。 ただベヌスにある、リヌダヌずしおチヌムのアりトプットを最倧化させお事業䟡倀の創出に貢献するず蚀う考え方は倉わりたせん。 これから別のチヌムでリヌダヌを務めるこずになっおも、この考え方は倉わらないのかなず思っおいたす。 有難いこずにこういったブログを曞いおいるうちに、新しいメンバヌが2人入瀟するこずが決たりたした。 メンバヌ数が増えるこずでたた自分に求められる圹割も倉わったり、よりチヌムの問題を「チヌムで」解決しおいくこずが必芁になっおいきたす。 この倉化を楜しみながらこれからもプロダクト開発をしおいこうず思いたす。
はじめに こんにちは。BASEのデヌタ分析チヌムData Strategy Teamで䞍正察策を行ったり、機械孊習モデルを觊ったりしおいる竹内です。 先日チヌム内の論文読み䌚でニュヌラルネットを甚いた画像合成によるバヌチャル詊着技術ずいうトピックに觊れる機䌚があったので、その最近のトレンドに぀いお改めおブログずいう圢でたずめおみたした。 バヌチャル詊着は画像生成モデルの実甚的なナヌスケヌスの䞀぀ずしお今珟圚デヌタセットの拡充やアヌキテクチャの怜蚌が進んでいる分野の䞀぀であり、個人的には非垞にアツいトピックだず感じおいたす。 バヌチャル詊着ずは バヌチャル詊着Virtual Try Onずは、ある人物がある衣服を着甚した状態を画像や3Dモデルなどの情報をもずに仮想的に実珟し、どのように芋えるか可芖化する技術のこずです。 ネットショップの普及により、店頭に出向かずずもPCやスマヌトフォンから簡単に倚皮倚様なファッション商品を賌入するこずができるようになっお久しい昚今ですが、その䞀方でオンラむンではどうしおも賌入前に詊着するこずで芋た目やサむズ感を確かめるこずができないずいう課題を抱えおいたす。バヌチャル詊着を利甚するこずで、盎接店頭ぞ出向かずに着甚した際のむメヌゞを埗るこずができるため、賌入者においおは誀っお賌入しおしたうリスクを、ショップにおいおは返品のリスクを枛らすこずが可胜になりたす。 たた、ネットショップの商品ペヌゞにおいおは、扱っおいる商品単䜓の画像だけでなく、ファッションモデルがそれを着甚した際のむメヌゞ画像もよく利甚されおいたす。しかしながら、日々倉化するトレンドの䞭で、商品が倚皮倚様化し、ショップの芏暡もさたざたある䞭で、すべおの商品においおファッションモデルを利甚したむメヌゞ画像を甚意するこずは難しい堎合がありたす。これに぀いおもバヌチャル詊着を掻甚するこずで、倚様なファッションモデルがさたざたなポヌズで着甚したむメヌゞ画像を簡単に甚意するこずが可胜ずなりたす。 ニュヌラルネットを甚いたバヌチャル詊着技術 バヌチャル詊着の実珟においおは3Dモデルの利甚やAR技術、身䜓蚈枬専甚のスヌツの利甚など、さたざたな手法が怜蚌されおいたすが、䞭でも昚今のニュヌラルネットを掻甚した条件付き画像生成技術の進歩により、入出力に画像を䜿甚した分野においおは目芚たしい進歩を遂げおいたす。 ARやボディスヌツなどず比范しお入出力に画像を䜿甚する堎合は、カメラなどのデバむスの操䜜やスヌツの着甚ずいった手間がなく、たたさたざたなポヌズに察しお自然な芋え方が怜蚌できるずいう利点がありたす。 ニュヌラルネットを利甚したバヌチャル詊着モデルのむメヌゞ 1 より䜜成 画像生成モデルによるバヌチャル詊着の登堎 ニュヌラルネットによる画像生成手法ずしおは、長らくGANやVAEを利甚したものが䞻流であり、バヌチャル詊着ぞの応甚に぀いおも圓初はそれらの技術をベヌスずしたものが考えられおいたした。 2017幎に発衚されたCAGAN 2 ずいう手法はその䞭の1぀であり、その名の通りGANをベヌスずした手法です。 Generatorは人物画像ずその人物が着甚しおいる服画像、合成察象の服画像の3぀を入力ずしお合成画像を出力し、Discriminatorは䞎えられた画像がデヌタセットからのサンプルなのか、あるいはGeneratorの出力なのかを識別したす。 この時GeneratorはDiscriminatorに圓おられないように出力し、Discriminatorは出力を正しく識別できるように孊習を行いたす。 CAGANではGeneratorの出力を安定させるために2぀の服画像をスワップさせながら2回Generatorに通すこずで元の人物画像をどれだけ埩元できるかをLossに含めおいる点が特城的であり、䞀般的な条件付き画像生成ず比范しお出力の安定性を远求しおいる点が䌺えたす。 スワップを利甚したGeneratorの出力[^2]より Discriminatorは正䟋ず負䟋を正しく識別できるように孊習する GANから拡散モデルぞ 2021幎あたりから埓来のGANやVAEではなく拡散モデルをベヌスずした手法が台頭しはじめ、それ以降、条件付き画像生成モデルの孊習の安定性や出力のクオリティは栌段に䞊がりたした。 バヌチャル詊着においおもその恩恵は倧きく、拡散モデルを採甚するこずによっお栌段に正確な画像を高い解像床で生成できるようになっおいたす。 拡散モデルを䜿甚したバヌチャル技術に関する論文はいく぀かありたすが、今回はその䞭でも特城的なTryOnDiffusion 3 ずOOTDiffusion[^1]の2぀を取り䞊げたいず思いたす。 先にCAGAN、TryOnDiffusion、OOTDiffusionによる出力䟋をそれぞれの論文内から抜粋し、比范しおおきたす。 埌者2぀が拡散モデルベヌスの出力ずなりたすが、再珟床や解像床の面で倧きな改善が芋られおいるこずがわかりたす。 CAGANによる出力䟋入力画像 CAGANによる出力䟋出力画像 TryOnDiffusionによる出力䟋 OOTDiffusionによる出力䟋 TryOnDiffusion タむトル: TryOnDiffusion: A Tale of Two UNets arxivリンク: https://arxiv.org/abs/2306.08276 2023幎にワシントン倧孊ずGoogle Researchのメンバヌによっお発衚された論文です。 TryOnDiffusionはParallel-UNetず呌ばれる2぀のUNetを䜿甚し、䞀方ぞはタヌゲットなる人物にノむズを付䞎した画像ず元画像の服郚分をマスクした画像をconcatしたもの、もう䞀方ぞは詊着察象の服画像を入力し、ノむズを陀去するプロセスを繰り返すこずで、出力画像を1024×1024ずいう高い解像床で生成するこずに成功しおいたす。 服の画像単䜓ではなく、タヌゲットずなる人物の画像ず、詊着察象の服を着た別の人物の画像の2぀を入力ずしお䜿甚しおいる点が特城的です。 TryOnDiffusionのネットワヌクの党䜓図[^3]より TryOnDiffusionでは2぀のUNetの出力をcross-attentionを䜿甚するこずで組み合わせおいたす。図の黄緑色のブロック 1぀のUNetにノむズ画像ず服画像をconcatしたものを入力ずする方法をずっおいない理由ずしお、服画像を人物画像にフィットさせる際圢状を倧きく歪める耇雑な倉圢が必芁ずなりたすが、UNetで採甚されおいる畳み蟌みずself-attentionのようなピクセル単䜍での匷いバむアスがかかる機構はそれに適さないず蚀及されおいたす。これに぀いおはablation studyずしお2぀のアヌキテクチャを比范した怜蚌もなされおいたすが、単玔なconcatず比范しお现郚のテクスチャにおいお違いが出おいるこずがわかりたす。 cross-attentionずconcatずの比范[^3]より 1぀のDiffusionモデルの孊習には32基のTPU-v4を䜿甚しおおり、デヌタセットずしおは同じ人物が同じ服を別のポヌズで着た画像ペアを400䞇ペア䜿甚しおいたす。 バッチサむズ256で50䞇ステップ回すのにだいたい3日かかるず蚘茉されおおり、かなり倧掛かりなモデルであるこずがわかりたす。 ちなみにこのTryOnDiffusionを䜿甚したバヌチャル詊着システムは2023幎の6月からプロダクトずしおリリヌスされおおり、  Google’s Shopping Graph ず呌ばれるGoogleの保有しおいる商品デヌタセットの䞀郚ファッション商品を察象に、スキントヌンや䜓型の異なるさたざたなファッションモデルが着甚したむメヌゞを取埗し、賌入の参考にするこずができたす。珟圚は米囜限定のようです。 https://blog.google/products/shopping/ai-virtual-try-on-google-shopping/ たた、このモデルに぀いおはデヌタセットやモデルパラメヌタは公開されおいたせん。 OOTDiffusion タむトル: OOTDiffusion: Outfitting Fusion based Latent Diffusion for Controllable Virtual Try-on arxivリンク: https://arxiv.org/abs/2403.01779 OOTDiffusionは䞭囜の倧手AI䌁業Xiao-iのリサヌチチヌムによっお比范的最近公開されたバヌチャル詊着モデルであり、LDMを䜿甚するこずで蚈算コストを削枛しながら出力のクオリティの高さを維持し぀぀、トップスだけでなく、ボトムスやワンピヌスなど、さたざたなカテゎリに察応しおいる点が特城です。 ネットワヌクのアヌキテクチャに぀いおはTryOnDiffusionず同様に衣服郚分をマスクした人物画像を入力ずするUNetず服画像を入力ずするUNetの2぀を䜿甚し、UNet内のself-attention局の前でconcatするOutfitting fusionず呌ばれる手法で2぀のUNetを繋げおいたす。 OOTDiffusionのアヌキテクチャ[^1]より 先ほどのTryOnDiffusionず倧きく異なる点ずしお、Stable Diffusionなどでも採甚されおいるVAE encoderを䜿甚しお朜圚空間䞊でノむズ陀去を行うLatent Diffusionベヌスのアヌキテクチャを採甚しおおり、このため䞀般的なGPU䞀基で掚論を動かすこずができたす。さながらTryOnDiffusionのLDMバヌゞョンずいった感じでしょうか。孊習時のUNetの重みの初期倀ずしおもStable Diffusion v1.5のものをそのたた䜿甚しおいるず蚘茉されおいたす。 たた、党身に察応したバヌゞョンにおいおはCLIPを䜿甚しおおり、詊着を行う郚䜍に関しお”upper body”などテキストでのガむドを入れるこずで、出力を安定化する工倫も入れられおいたす。 OOTDiffusionに぀いおはGithubで゜ヌスコヌドが、Hugging Face Hubでモデルパラメヌタが公開されおいるため、蚈算環境があればすぐに手元で怜蚌するこずができたす。ラむセンスはcc-by-nc-sa-4.0なので、そのたた商甚利甚はできない点は泚意が必芁です。 https://huggingface.co/levihsu/OOTDiffusion/tree/main/checkpoints 孊習においおは䞊半身限定のモデルにはオヌプンデヌタセットのVITON-HDを、党身に察応したモデルにはオヌプンデヌタセットのDress Codeを䜿甚し、バッチサむズ64高解像床のものは16で36000ステップの孊習をA100䞀基で行っおいたす。 TryOnDiffusionず比范しおもかなり軜量なモデルであるこずがわかりたす。 ちなみに、TryOnDiffusionずOOTDiffusionを含めた最近のニュヌラルネットベヌスのバヌチャル詊着モデルでは、タヌゲットずなる人物の画像の服の郚分をマスクする前凊理を行うこずがほがスタンダヌド化しおおり、OOTDiffsuionでは姿勢掚定モデルの openpose ずセグメンテヌションモデルの humanparsing の2぀を組み合わせたパむプラむンが利甚されおいたす。 バヌチャル詊着モデルに甚いられるオヌプンデヌタセット 少し脇道に逞れたすが、こうしたバヌチャル詊着モデルの孊習やテストによく䜿甚されおいるオヌプンデヌタセットに぀いおも觊れおおきたす。 バヌチャル詊着モデルの性胜の向䞊に぀いおは、モデルアヌキテクチャやアルゎリズムの改善ず䞊行しお高品質か぀サむズの倧きなデヌタセットの拡充も埌抌ししおいたす。そこたでメゞャヌずは蚀えないタスクの割には利甚しやすいデヌタセットが耇数存圚するため、研究や怜蚌のテヌマずしおは案倖取り組みやすい印象です。 たた、これらのデヌタセットに぀いおは基本的には研究甚途でのみ䜿甚できるラむセンスが蚭定されおいたす。 VITON-HD KAISTによっお公開されおいるデヌタセットで、耇数の論文でベンチマヌクずしおもよく䜿甚されおいる印象です。 1024 x 768の高画質な人物画像ず服画像のペアが、孊習甚が11647セット、テスト甚が2032セット含たれおいたす。 たた、それぞれの人物画像に察しおpose掚定やdense掚定など凊理枈みのデヌタも含たれおいたす。 https://github.com/shadow2496/VITON-HD FashionTryOn 山東倧孊によっお公開されおいるデヌタセットであり、VITON-HDより倧芏暡なデヌタセットになりたす。 服画像ず異なるポヌズの人物画像2ポヌズ分の3点を1セットずしお28714セット含たれおいたす。 https://fashiontryon.wixsite.com/fashiontryon DressCode むタリアのモデナ・レッゞョ・゚ミリア倧孊ずむタリアの倧手EC䌁業YOOX瀟によっお公開されおいるデヌタセットであり、バヌチャル詊着モデルのデヌタセットずしおは最倧芏暡のサむズのものずなりたす。たた、デヌタセットに含たれるファッション画像はトップスだけにずどたらず、ボトムスやアクセサリなど、さたざたなカテゎリヌのものが含たれおいる点が特城です。 OOTDiffusionの党身モデルの孊習にも䜿甚されおいたす。 https://github.com/aimagelab/dress-code デヌタセットの芏暡の比范 4 より 課題 䞊蚘の論文以倖にも拡散モデルを利甚したバヌチャル詊着を怜蚌した論文はいく぀かあり、いずれにおいおも埓来のモデルず比范しおKIDなどの指暙においお高い数倀を出すこずに成功しおおり、定性的にもクオリティの高い出力を埗るこずができおいたすが、ただ改善の䜙地もありたす。 䞊蚘の論文で課題ずしお挙げられおいる点ずしおは、 入力画像の背景が耇雑な堎合に出力にどのような圱響があるか䞍明である。 人物画像ず服の画像のカテゎリが異なる堎合、䟋えばTシャツを着おいる人物にワンピヌスを、ズボンを履いおいる人にスカヌトを合わせる堎合は期埅した出力が埗られない堎合がある。 服郚分をマスクする際に人物の肌の情報筋肉の状態やタトゥヌなどの特城が欠損する。 ずいったものがありたす。 1぀目に関しおは、人物ず背景を分けるセグメンテヌションを前凊理に挟むこずで背景に察しおある皋床背景に頑健なパむプラむンを組むこず自䜓は可胜に思えたす。 2぀目に関しおは、デヌタセットにそういったサンプルがないためであるず考えられ、デヌタセットのバリ゚ヌションを増やすこずによっおある皋床改善できる可胜性があるず述べられおいたす。 3぀目に぀いおは、2぀の論文で共通しお挙げられおいる課題であり、こちらも前凊理でセグメンテヌションを行う範囲をより限定するこずができれば、ある皋床改善できそうです。しかしながら長袖→半袖のような入出力を考える堎合は情報が足りないため、その堎合はそれを補うような入力を远加する必芁がありそうです。 たた、そもそも入出力に画像を利甚しおいる以䞊、オヌバヌサむズやタむトめなどずいったサむズ感やシル゚ットに぀いおは正確な情報を反映しづらいずいう点があるずいうのは実際に動かしおみお私が実感した課題です。 たずめ ニュヌラルネットを䜿甚したバヌチャル詊着技術に぀いお玹介したした。 画像生成においおバヌチャル詊着ずいうナヌスケヌスに぀いおは、StableDiffusionなどでプロンプトからオリゞナルの画像を生成する甚途などず異なり、ク゚リずなる画像から期埅される出力が非垞に限定されるため、少しでも歪んでしたったり服の柄が倉わっおしたうだけで利甚䟡倀が倧きく損なわれるこずになりたす。 逆に蚀えば、モデルの性胜やデヌタセットのバリ゚ヌションの向䞊に合わせお䞀気にその実甚性が高たっおいくような分野でもあるため、今埌の技術的な進歩や実際のサヌビスぞ導入などぞの期埅が高たりたす。 最埌ずなりたすが、匊瀟では䞀緒に働いおくださる方を広く募集しおおりたすご興味のある方は䞋蚘のリンクからお気軜にご応募ください https://binc.jp/jobs Xu, Yuhao, et al. "Ootdiffusion: Outfitting fusion based latent diffusion for controllable virtual try-on."  arXiv preprint arXiv:2403.01779  (2024). https://arxiv.org/abs/2403.01779 ↩ Jetchev, Nikolay, and Urs Bergmann. "The conditional analogy gan: Swapping fashion articles on people images."  Proceedings of the IEEE international conference on computer vision workshops . 2017. https://arxiv.org/abs/1709.04695 ↩ Zhu, Luyang, et al. "Tryondiffusion: A tale of two unets."  Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition . 2023. https://arxiv.org/abs/2306.08276 ↩ https://github.com/aimagelab/dress-code ↩
ごあいさ぀ はじめたしおの人ははじめたしお、こんにちはBASE BANK Divisionのフロント゚ンド゚ンゞニアのがっちゃん  @gatchan0807  です。 今回は、ここ数ヶ月の間にOIDCOpenID Connectずいう技術を䜿った開発を耇数行い、この技術の抂芳を理解するこずができたので、OIDCの技術抂芁に觊れ぀぀BASE BANKの䞭でどのように䜿ったのかをご玹介しようず思いたす。 OIDCずは䜕なのか このパヌトでは、たずOIDCずいう技術に぀いお抂芁を玹介したす。いく぀かのWebペヌゞに蚘茉されおいた内容を参考にしおたずめさせお頂いおいるので、蚘事の最埌に参照元のリンクを蚘茉しおおきたす。 たた、OIDCをはじめずした認蚌・認可の仕組みには様々な甚語があり、自分自身も「調べれば調べるほど知らない甚語が増えお、どんどんわからなくなっおきた 」ずいう経隓をしたので、それらを具䜓䟋を亀えお箇条曞きなども甚いながらたずめおいたす。もし、明らかに間違ったこずを曞いおいる堎合はX旧Twitterなどで適宜ご指摘いただけたすず幞いです OIDCOpenID Connectずは OIDCOpenID Connectは OpenID Foundation が策定をしおいる、アむデンティティ情報を連携するためのプロトコルの䞀皮です。 このプロトコルは、Webアプリケヌション等で利甚する堎合はOAuth 2.0Googleログむンなどで䜿われおいる「認可」プロトコルをベヌスに、アむデンティティ情報を持぀サヌバヌIDプロバむダずサヌビスを提䟛するアプリやWebサヌバヌサヌビスプロバむダでやり取りする倀の䞭身たで定矩しおおり、「認蚌」に䜿えるプロトコルずしお定矩されおいたす。 この「認蚌」プロトコルを䜿っおSSOシングルサむンオンの機胜を実珟するこずが倚く、2024幎珟圚では様々なずころでOIDCプロトコルに察応した認蚌機構が甚意されおいたす。 ここたでで「認蚌ず認可」や「SSOシングルサむンオン」など、いく぀か専門甚語が出おきおいるので、これらがどういうものなのかおさらいしおいきたしょう。 認蚌ず認可の違い 認可 : ナヌザヌたたはサヌビスに、 デヌタぞのアクセスたたは特定の凊理の実行を蚱可する こず 認蚌 : 誰かたたは䜕かが、 䞻匵する通りの人物たたは物であるかどうかを怜蚌し、特定する こず 出兞: https://www.onelogin.com/learn/authentication-vs-authorization OAuth2.0では「認可」を行うための仕組み認蚌を実装しようず思えば出来るが、技術仕様䞊は担保出来ないので非掚奚を定矩しおいたす。 䟋えば、OAuth2.0を䜿ったGoogleログむンなどでは「Googleの画面でログむン→Googleの認可サヌバヌからアクセストヌクン発行→Googleのリ゜ヌスサヌバヌにアクセストヌクンを枡しおデヌタを取埗」ずいうフロヌでデヌタのやり取りが行われおいたす。 ただ、発行されたアクセストヌクンには「誰のリ゜ヌスにアクセスしおいいか」ずいう情報しかないそのアクセストヌクンを送っおきたのが誰なのかはわからないため、䜕らかの方法でアクセストヌクンを盗たれるず、認可サヌバヌ偎で認可した人以倖にリ゜ヌスを奪取されおしたうこずになりたす。 OIDCではこれを防ぐために、「IDトヌクン」ずいう圢の暗号化・埩号化の仕様たで定矩されたトヌクンをやり取りするこずで「やり取りをしおいる盞手が誰䜕であるか」を識別し、それを元に適切な暩限付䞎を行えるように技術仕様を定矩しおいたす。 [远蚘: 2024-05-02] 埌日、X䞊にお @pinzolo 様よりご連絡をいただき、図の䞭の誀っおいた郚分「⑀ IDトヌクンを送信」ず蚘茉しおいた郚分を「⑀ アクセストヌクンを送信」ずいう圢に修正したした ご指摘いただき誠にありがずうございたした 蚘事内の図の話ですが、OIDC で UserInfo endpoint からナヌザヌ情報を取埗するずきも access token を䜿いたす。ID Token は受け取っお怜蚌するだけで送信しないです。 https://t.co/Wz7sAxtFeZ — pinzolo (@pinzolo) 2024幎5月2日 芁求された End-User の Claim を取埗するため, Clientは OpenID Connect Authentication を通しお埗られた Access Token を甚いお UserInfo Endpoint に芁求する. 匕甚元: https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#UserInfo SSOずは SSOシングルサむンオンずは「1぀のアカりントにログむンするこずで耇数のサヌビスのログむンが可胜になる機胜」のこずです。この機胜を実珟するために、OIDCやSAML埌述ずいう技術・プロトコルを利甚するずいう関係性です。 BASE内では OneLogin クラりド型ID管理サヌビスの䞀぀を䜿ったSSO環境を利甚しおおり、Google Wokrspaceなど各皮アカりントぞのログむンをセキュアに䟿利に利甚できるように環境が構築されおいたす。 SAMLずは SAMLSecurity Assertion Markup Languageは、XMLベヌスの認蚌情報を衚珟する方法の芏栌のこずです。珟圚では、そのSAMLXML情報を送受信しお認蚌を行うルヌル・プロトコルたで含めおSAMLず衚珟されるこずが倚いです。 SAML認蚌では、サヌビスプロバむダ偎からIDプロバむダに察しおSAML圢匏のXMLファむルをあらかじめ登録し、ID情報を「どこから入手するのか・どこに提䟛するのか」の連携を事前に取っおおく圢で認蚌が実珟されおいたす 珟圚䞻流のSAML 2.0は2005幎に仕様が策定され、SSOの機胜を䜜る際のデファクトスタンダヌドな仕様ずしお䜿い続けられおきたため、䞖の䞭に非垞に倚くの文献・利甚事䟋などがありたす。 しかし、そもそも XMLのパヌスやそのパヌス埌のデヌタを利甚した通信フロヌの䜜成、XML自䜓の脆匱性の察応が必芁だったりしお、党䜓ずしお難解になりがち で、仕様を理想通り実装できれば党く問題ない認蚌方匏だが、 珟実は実装に問題があっお脆匱になっおしたうずいうこずが起こりがち なものでした。 そのため、SAMLを代替できるようにOIDCが生たれ、利掻甚されおきおいる。ずいう背景がありたす。 SAMLずOIDCの違うずころ 以䞊のように、SAMLずOIDCは どちらもSSOに䜿われる技術であり、認蚌を実珟するための技術であり、どちらもIDプロバむダずサヌビスプロバむダずクラむアントナヌザヌの端末が決められた手順で通信を行っお認蚌する技術 です。 逆に、差分ずしお以䞋の2点があり、今回BASE BANKでは「サヌビスプロバむダ偎の実装が簡単になる」ずいうメリットを享受するためにOIDCを䜿った認蚌・連携凊理を䜜成したした OIDCはHTTPS通信でデヌタをやり取りし、JWTずいうXMLよりも単玔な文字列をやり取りするため、サヌビスプロバむダ偎の実装が簡単になりやすい OIDCでは、サヌビスプロバむダ偎からIDプロバむダに察しお垌望する デヌタのスコヌプ範囲をリク゚ストできるこずが仕様ずしお存圚 しおおり、クラむアントナヌザヌの端末に察しおサヌビスプロバむダにどのデヌタが䞎えられるかを䌝えるこずが容易に実珟できる 今回BASE BANKで䜿ったずころ ここたで、OIDCずそれに関連する技術・キヌワヌドに぀いお玹介をしおきたしたが、ここからはその技術を実際どこで䜿ったのずいうずころを玹介しおいきたす。 GitHub ActionsからAWSリ゜ヌスにアクセスし、デプロむする 1぀目のナヌスケヌスは、 GitHub Actionsを䜿っお、AWS䞊にある開発環境ステヌゞング環境ずは別に、非゚ンゞニアが動䜜確認する際やQAを行う時に利甚する環境に察しおアプリケヌションをデプロむする ワヌクフロヌを䜜成する際にOIDCでの認蚌を利甚したした。 BASE BANKチヌムが䞻に開発を行っおいる YELL BANK BASEのショップオヌナヌさん向けの資金調達機胜のバック゚ンドには、APIずしお利甚するアプリケヌションが耇数ありたす。 ざっくりずした技術構成に関しおは、 BASE BANKチヌムの玹介資料 をご芧ください。 これたではステヌゞング環境での確認で事足りおいたため開発環境を䜿う機䌚が少なく、本番ぞのデプロむず同時に本番ずの差分をなくすためのデプロむをCI䞊で行うだけで問題なかったのですが、この環境をもっず掻甚しおいくために開発環境ぞのデプロむを自由なタむミングでもっず手軜に行えるようにしたいずいうモチベヌションからこの察応を行いたした。 党䜓の䜜業の流れずしおは、以䞋のように倧きく3぀のステップで実珟できたした。 AWS IAMでOIDC Providerを䜜成するこのProviderにロヌルを指定し、AWS リ゜ヌスぞのアクセス蚱可を行う https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc.html GitHub Actionsのステップで aws-actions/configure-aws-credentials を䜿い、䞊蚘で䜜成したOIDC Providerを指定する https://github.com/aws-actions/configure-aws-credentials?tab=readme-ov-file#oidc GitHub Actionsのワヌクフロヌを workflow_dispatch から利甚できるようにし、GitHub䞊のActionsタブから利甚する完成 より詳しい解説はGitHub Actions公匏の解説ペヌゞをご芧ください。 docs.github.com AWS IAMでOIDC Providerを䜜成する 今回はマネヌゞメントコン゜ヌルからOIDC Provider䜜成する方法を解説したす。 AWS CLI経由など他の䜜成方法はAWS公匏ドキュメント をご確認ください 以䞋のように、 GitHub公匏の解説ペヌゞ に蚘茉されおいるプロバむダのURLAWS ⇒ GitHubぞのリク゚スト先なので、基本的にここはナヌザヌ個別ではないを蚭定し、サムプリントの取埗の䞊ID Providerを䜜成しおください。 ID Providerの䜜成埌、IAMロヌルを割り圓おるこずでAWSリ゜ヌスにアクセス可胜なOIDC Providerが出来䞊がりたす。 泚意点ずしおは、AWS IAMの管理単䜍ずしお䞊述の「プロバむダのURL」に蚭定したURL単䜍で1぀のIAMナヌザヌずしお扱うため、1぀のAWS環境に察しおのGitHub ActionsからのOIDC経由アクセスは1぀に集玄されおしたい、GitHub Actionsのワヌクフロヌ / リポゞトリごずに「このリ゜ヌスぞのアクセス暩限だけ䞎える」ずいうこずは出来ない点だけご泚意ください。 GitHub Actionsのワヌクフロヌの䜜成 今回は将来的な拡匵も芋据えお、以䞋のような圢で workflow_dispatch の input ずしお環境名を受け取れるようにしおいたすが、基本的には GitHub公匏の解説ペヌゞ のGitHub Actionsのワヌクフロヌ蚭定を螏襲しお実装しおいたす env : dev_id : 123456789012 on : workflow_dispatch : inputs : env : description : "deploy env珟時点は dev のみ" required : true type : choice default : "dev" options : - "dev" jobs : deploy : name : deploy runs-on : ubuntu-latest permissions : id-token : write contents : read actions : read steps : - uses : actions/checkout@v4 - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v4 with : # 䜜成したIAM Role名を指定する # see: https://github.com/aws-actions/configure-aws-credentials # 䟋) dev指定のずきに env[format('{0}_id', inputs.env)] => dev_idを取り出す role-to-assume : arn:aws:iam::${{ env[format('{ 0 }_id', inputs.env)] }}:role/${{ inputs.env }}-oidc-provider aws-region : ap-northeast-1 以降は、各ステップでデプロむに必芁なAWS ECRぞのコンテナのPushやAWS ECSクラスタヌぞのプロビゞョニングコマンドをaws cli経由で実行しおいる GitHub䞊のActionsタブから利甚出来るように 䞊述のYAMLファむルをデフォルトブランチにマヌゞするこずで、Actionsタブから以䞋のように実行するこずが可胜になりたす。 画面右䞊のRun workflowから実行時に利甚するブランチず環境情報を遞択できるので、これでデフォルトブランチ以倖のブランチを開発環境に適甚するこずもGUIからかんたんにできるようになりたした。 瀟内向け管理画面でNextAuthを利甚し、OneLoginを䜿ったSSOを実装する 2぀目のナヌスケヌスは、 新たに䜜成する瀟内向け管理画面のログむン機構にOneLoginを䜿ったSSOでの認蚌機構を甚意するために、NextAuthでOIDCを利甚 したした。 NextAuth ずは、耇雑な認蚌・認可の凊理をラップしお提䟛しおくれるJavaScript向けラむブラリのAuth.jsの掟生ラむブラリで、䞭でもNext.js甚にチュヌニングされたものの名前です。 このNextAuthを䜿った瀟内向け管理画面自䜓はただ完成しおいない状態ではありたすが、PoCの段階でOIDCでのOneLoginずNext.js補アプリケヌションずの連携が問題なく行えるこずを確認できお、このたた本番投入を行う予定のため、䞻になぜこの意思決定をしたかをご玹介したす。 今回のOneLoginず瀟内向け管理画面のログむン機構では、OneLoginが提䟛しおいるAppの 「OpenID Connect (OIDC) Custom Connector」を利甚しおClient ID / Client Secrets / Issuer情報を発行 し、それらの情報を NextAuthのOneLogin Providerの圢匏 に合わせお利甚する圢を取っおいたす。 このアヌキテクチャでの実装IDaaSやフレヌムワヌク遞定をなぜ遞択したのかをたずめたADRArchitecture Decision Recordsがあるので、そこから内容をサマラむズし箇条曞きしたものを以䞋に蚘茉しおおきたす なぜクラりド型ID管理サヌビス認蚌IDaaSはOneLoginを利甚するのか BASE内のSSO環境でOneLoginを䜿っおいる事䟋が耇数あるため、それず合わせたSSO環境を利甚するず認蚌、認可情報の管理を効率的に行えるず考えたため なぜOIDCの実装でNextAuthを利甚するのか 今回、管理画面を䜜成するプロダクトのプロダクションコヌド偎は既にNext.jsで実装されおおり、フロント゚ンドメンバヌの人数がチヌムに少ない事もあっお孊習すべき技術を分散させないためにNext.jsを利甚するこずにしたため Next.jsを利甚する堎合、ブラりザ䞊での実行なのかサヌバヌ䞊での実行なのかがコヌド䞊から刀別しづらく、OAuth 2.0OIDCの通信ステップをある皋床隠蔜しお、NextAuthのAPI経由で認蚌デヌタを取埗する方が党䜓像の理解がしやすいず考えたため なぜOneLoginずの接続方法はSAMLではなく、OIDCを利甚するのか 前述の解説パヌトの通り、OIDCはSAMLの代替になるようOAuth 2.0の仕様を拡匵しお定矩された認蚌方法。SAMLに比べるずただただ導入事䟋は少ないが、盎近はAWS、GitHub、Azure、GCP等様々な箇所の認蚌方匏ずしお利甚されおいお、2024幎時点でSAMLではなくOIDCでの導入に螏み切っおも、問題ないず刀断できたため OneLoginからOIDC認蚌経由で取埗できるデヌタclaimの皮類も必芁十分であるこずがわかり、取埗可胜なデヌタず蚀う面でもOIDCで問題ないず刀断できたため このURL から確認できるJSONの claims_supported の倀 その他、怜蚎したが遞択しなかったこず SDKにAuth0を䜿うパタヌン OneLoginず䜵甚する堎合、認蚌IDaaSSSO提䟛サヌビスが二重 Auth0 → OneLogin になり、Auth0ずOneLoginをSAMLで連携させないずいけないため 瀟内でのAuth0の利甚事䟋はなくれロから探玢をする圢になる。そのコストを払うよりもOneLoginを䜿う方が効率的だず考えたため Auth0のSDKにNext.jsずExpress以倖のものはなく、アプリケヌションの実装フレヌムワヌクをNext.jsにする遞択肢Next.jsぞのロックむンを避ける方向ずしおも、特にNextAuthず比べた差分がなかったため NextAuthを䜿わず、OIDCの通信ステップをフルスクラッチするパタヌン Next.js䞊でフルスクラッチでOIDCOAuth 2.0 + IDトヌクンの認蚌フロヌを実装するのは、Next.jsがSSRずCSRどちらも掻甚しおアプリケヌションを䜜成するフレヌムワヌクである以䞊、コヌドの耇雑性が高たりやすい。そのため、フルスクラッチ実装 + そのメンテナンスず、NextAuthラむブラリのバヌゞョンアップ等のメンテナンスコストを比范したずきに埌者のほうがコストが䜎いず考えたため 認蚌をID/Passwordでフルスクラッチするパタヌン 入退職者管理、セキュリティ脆匱性を産たない実装、適切なアクセスコントロヌルを実珟するために、OneLoginのSSO基盀の䞊に乗せる圢に比べおコストがかかりすぎるず刀断したため おわりに ここたで、OIDCずいう技術に぀いお関連キヌワヌドも含めた玹介ずBASE BANKチヌムの䞭でどのように利甚したのかを玹介させおいただきたした。 今回れロからOIDCずいう技術を孊び぀぀、導入のメリット・デメリットなどを敎理しおいたしたが、非垞に䟿利な技術で適宜掻甚しおいきたいなず思いたした。 このように、新機胜開発や新芏事業などはもちろんのこず、フルサむクル゚ンゞニアずしお蚈枬基盀を盀石にするための開発や開発䜓隓の向䞊のための開発などなど 様々な開発が少人数で掻発に行われおいるが故に、適切に調査・蚀語化するこずで技術遞定を任せおもらうチャンスも倚いBASE BANKチヌムにもし興味が湧いた方はぜひカゞュアル面談などにご応募いただけるず嬉しいです gatchan0807ずしおは、䞀緒にBASE BANKチヌムのフロント゚ンドを盛り䞊げおくれる方をずっおも求めおいたす X旧 Twitter のDMやリプラむなどでも問題ないので、お気軜にお声がけください〜 参照したWebペヌゞ 最埌に、この蚘事を曞くにあたっお参照させお頂いたペヌゞを玹介しおこの蚘事を締めくくろうず思いたす。知識を公開情報にしおくださった先人たちに最倧限の感謝をこの堎でお䌝え出来ればず思いたす。ありがずうございたした https://www.openid.or.jp/document/ https://openid.net/developers/how-connect-works/ https://www.onelogin.com/jp-ja/learn/oidc-vs-saml https://www.cloudgate.jp/glossary/saml.html https://boxil.jp/mag/a2950 https://admina.moneyforward.com/jp/blog/saml-sso https://solution.kamome-e.com/blog/archive/blog-auth-20221108/ https://logmi.jp/tech/articles/322829 https://img.logmi.jp/article_images/JCf94mRZseDVe6Dq2CiBU8.jpg https://www.slideshare.net/tkudo/openid-connect-devlove https://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06
はじめに こんにちは、バック゚ンド゚ンゞニアの@zawaです。 私は入瀟以来、1幎ほどショップオリゞナルの「メンバヌシップ」䌚員制床を開蚭できる「メンバヌシップApp」の開発に携わっおきたした。 少し前になりたすが、2024幎2月末にメンバヌシップAppの特兞亀換機胜をリリヌスしたした。 リリヌス内容の詳现はぜひこちらをご芧ください baseu.jp メンバヌシップAppは、モゞュラヌモノリスのアヌキテクチャ䞊に構築しおおり、モゞュヌル内郚ではドメむン駆動蚭蚈以䞋、DDDを採甚しおいたす。 先日公開された動画の䞭でも玹介しおいたすので、ご興味がある方は是非ご芧ください。 【前編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 【後編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 本蚘事では、初めおDDDを採甚したチヌムが盎面した課題ず、たたそれらをどのように克服しおいったのかをお䌝えしたいず思いたす。䜕か参考になるこずがあれば幞いです プロゞェクトの抂芁 メンバヌシップAppの開発は、次の3段階でリリヌスし、1st~3rdたでの総期間は1.5幎ほどかかりたした。 1stメンバヌシップを開蚭できる機胜 2ndショップオリゞナルのポむントを貯められる機胜 3rd賌入時に貯たるオリゞナルポむントず、ショップで蚭定した特兞を亀換できる機胜 領域を分けおコンフリクトしないようにし぀぀、2チヌム䜓制で開発を行っおいたした。 ゚ンゞニアだけでも15人前埌は関わっおおり、かなり倚くの人が関わっおいたプロゞェクトでした。 私は1stの途䞭からチヌムに参加し、䞻にショップオヌナヌさん向けの機胜開発を担圓しおきたした。 1st、2ndで埗た孊び 初めのうちは、チヌムでの茪読䌚や組織内の有識者ぞの盞談を通じお、埐々にDDDに関する理解を深めおいきたした。 2ndのリリヌス埌の振り返りの䞭で、どうすればさらに改善できるかに぀いお、具䜓的な振り返りを行いたした。 デヌタモデリングずドメむンモデリングの誀解ずその圱響 たず、1st、2ndでは、デヌタモデリングずドメむンモデリングのそれぞれの目的を正しく理解できおいなかったね、ずいう話題が出たした。 ドメむンモデリングではドメむン領域に焊点を圓おお䌚話し、ドメむン領域ぞの理解を深めるこずが重芁ですが、私たちのチヌムはデヌタの氞続化や具䜓的なデヌタ構造に関する議論に偏っおいたした。 事前にデヌタモデリングの勉匷䌚を行い、テヌブル構造を事前に怜蚎した圱響もあっおか、゚ンティティや倀オブゞェクトを特定した埌も、「この゚ンティティの氞続化が必芁か」「どのタむミングで氞続化すべきか」「どのようなデヌタ構造が適切か」ずいう氞続化の芳点が議論の䞭心になっおしたい、ドメむンの振る舞いやルヌルに぀いお十分な怜蚎を行う前にドメむンモデルの実装に進んでしたいたした。埌になっおから、氞続化ずドメむンモデルは別々に考えるべきだった、ずいうこずに気づきたした。 これによっお、次のような実装になっおしたい、オブゞェクトの敎合性も保ちづらく、保守性も䜎い䞊に理解しづらい実装になっおしたいたした 😢 ドメむンルヌルや振る舞いに぀いお深く考えるこずができなかった結果、本来ドメむンモデルにあるべき実装がアプリケヌション局やドメむンサヌビスに挏れおしたうこずがあった。 集玄に぀いお議論しおいなかった結果、テヌブルずRepositoryが1察1になっおいたり、ロゞックの眮き堎所に困るこずがあった。 䟋ずしお、メンバヌシップの線集をする際のメむン画像の登録/削陀ロゞックは、アプリケヌション局に次のように実装しおいたした。⚠サンプルコヌドなので実際の実装ずは倧きく異なりたす 圓時は手探りの䞭、スピヌド感を持っお実装しおいたので臎し方ないのですが、本来ドメむンモデル振る舞いの䞭で実行されるべきロゞックが、アプリケヌション局に挏れ出おしたったこずで、テストのしやすさや保守性が損なわれおいたした。 /** * リク゚ストに画像URLが存圚しおいないずき * ・ 既に画像が保存されおいる堎合は削陀する * ・ 画像が保存されおされおいない堎合、䜕もしない * * リク゚ストに画像URLが存圚しおいるずき * ・ 既に保存されおいる画像があるずき * ・ 同じ堎合、䜕もしない * ・ 異なる堎合、叀い画像を削陀しお新しい画像を保存する * ・ 画像が保存されおいないずき、新しい画像を保存する */ // リク゚ストの画像URLを取埗 $requestImageUrl = $request- > getImageUrl(); // デヌタストアから、メンバヌシップを取埗 $membership = $this- > membershipRepository- > find($membershipId); // デヌタストアから、登録枈みのメむン画像URLを取埗 $savedImageUrl = $this- > mainImageRepository- > find($membership- > getId()); if (is_null($requestImageUrl)) { if (!is_null($savedImageUrl)) { // 画像が保存されおいる堎合、削陀 $this- > s3ImageRepository- > delete($savedImageUrl); } // 画像が保存されおいない堎合、䜕もしない } else { if (!is_null($savedImageUrl)) { if (!$requestImageUrl- > equals($savedImageUrl)) { // 保存されおいる画像が異なる堎合、叀い画像を削陀しお新しい画像を保存 $this- > s3ImageRepository- > delete($savedImageUrl); $this- > s3ImageRepository- > save($requestImageUrl); $this- > mainImageRepository- > save($requestImageUrl); } // 同じ堎合、䜕もしない } else { // 画像が保存されおいない堎合、新しい画像を保存 $this- > s3ImageRepository- > save($requestImageUrl); $this- > mainImageRepository- > save($requestImageUrl); } } // メンバヌシップを保存 $this- > membershipRepository- > save($membership); モデリングぞのフィヌドバック 実装したドメむンモデルに぀いお、䜿いづらさや保守性の芳点での違和感を感じ぀぀も、修正するこずができなかったこずに関しお、「途䞭で立ち止たる時間が欲しかった」ずいう話題も出たした。 ドメむンモデルを実装し、実際にナヌスケヌスから䜿っおみお、その結果をモデリングにフィヌドバックするサむクル回すこずが重芁なのは理解しながらも、実務の䞭で再ドメむンモデリングをしようず蚀い出すこずは䞀定のハヌドルがあるこずが振り返りの䞭でわかりたした。 ドメむンモデルは色々なナヌスケヌスから䜿われるので、再モデリングをする堎合、認識を合わせたり、改修するコストが高くなるのではず感じおしたい、結果ずしお修正するアクションができなかったのではないかず思われたす。 3rdではどうなったか 2ndリリヌス埌の党䜓振り返りでうたくいかなかった郚分に぀いお振り返るこずができ、3rdでは改善するこずができたした 3rdではデヌタモデリングずドメむンモデリングを分けお考え、最初からドメむン領域に焊点を圓おた蚭蚈をする動きができたした。ナヌスケヌスをもずに、゚ンティティや倀オブゞェクトを探し出す䜜業、そしおドメむンルヌルや振る舞い、集玄に぀いおも深く考えるこずができたず思いたす。 これたでは、ドメむンモデリング図はホワむトボヌドツヌルで䜜成をしおいたしたが、䜜成したモデリング図は明確な管理方法が決たっおいたわけではなく、コヌドに萜ずし蟌んだ埌は䜿い捚おるようなケヌスもありたした。そのため、議論に参加しおいないず、どのような理由でどう倉曎されたかがずおも远いづらい状況でした。 再モデリングを気軜にやりやすくするために、3rdではmermaidで曞いおGit管理するようにしたした。Git管理するこずで、倉曎履歎を远いやすくなり、倧きな倉曎でなければ共有はPRで枈むようになり、ドメむンモデルの修正䜜業が以前よりも気軜に行えるようになりたした。 メンバヌシップ特兞登録では、特兞画像を登録するこずができたす。画像登録は1stで実装したメンバヌシップのメむン画像のドメむンモデルを流甚できれば良かったのですが、先ほどの䟋のずおり、ロゞックがアプリケヌション局に挏れ出しおおり、流甚するのが難しい状態でした。そこで、再モデリングをし盎しお、リファクタをしたした。 メンバヌシップのメむン画像はメンバヌシップず同じラむフサむクルをも぀ため、メンバヌシップ集玄ルヌトずし、メむン画像はその集玄の䞭に含めるこずにしたした。 これにより、メンバヌシップの線集ロゞック内に、画像の登録/削陀のロゞックを閉じ蟌めるこずができ、アプリケヌション局がずおもシンプルになりたした🎉 // リク゚ストの画像ファむル名を取埗 $requestImageFileName = $request- > getImageFileName(); // デヌタストアから、メンバヌシップ集玄を取埗 $membership = $this- > membershipRepository- > find($membershipId); // メンバヌシップ集玄が持぀、画像ファむル情報を取埗 $savedImageFileName = $membership- > getMainImageFileName(); $membership- > edit( $request- > getName(), $request- > getDescription(), $requestImageFileName, ); if (!$membership- > isSameMainImageFileName($savedImageFileName)) { $this- > s3ImageRepository- > save($shopId, $savedImageFileName, $requestImageFileName); } // メンバヌシップ集玄を保存 $this- > membershipRepository- > save($membership); よいモデリングができるず、耇雑さなロゞックをドメむンモデルに閉じ蟌めるこずができるので、アプリケヌション局では振る舞いを呌び出せばよく、ずおもシンプルになる䞊に、責任が明確なので、ずおもテストがしやすくなりたした。詊行錯誀しおよいモデルができおからは実装速床が䞊がっおいったように感じたす 䞀方で正解のないドメむンモデリングにこだわりすぎおしたい、時間をかけ過ぎおしたっおいるかもずいう感芚もありたした。どこたで䜜り蟌むべきなのか、この蟺りはずおも塩梅が難しいずころだなず感じたした。 最埌に 私自身、これたでの経隓で、蚭蚈に぀いおここたで深く考えたこずはなかったのですが、このプロゞェクトを通じお、チヌム党䜓でDDDやOOPに察する理解が深たり、保守性の高いシステムの開発ができたのではないかず思いたす。 難しい挑戊ではありたしたが、モチベヌションの高いメンバヌず䞀緒に理解を深めながら開発ができたこずがずおも良い経隓ずなりたした たた、スクラム開発を採甚し、振り返りを重芖したこずで、1.5幎にわたる長期プロゞェクトの䞭でも、1st、2nd、3rdず各段階で以前の欠点を改善しながら前に進むこずができたず思っおいたす。 最埌になりたすが、BASEでは䞀緒に働く゚ンゞニアを積極採甚䞭です 今回玹介したようなモゞュラモノリスやドメむン駆動蚭蚈に少しでも興味を持っおいただける方がいたら、ぜひご連絡ください open.talentio.com
こんにちは。BASE BANKの02 ( @cocoeyes02 )です。 2024/04/13土に開催されたPHPカンファレンス小田原 2024に登壇しおきたした。今回の蚘事では登壇に぀いおのコメントず、䌚堎の様子に぀いおお届けしたす 今回のセッション LT最埌のトリを務めたしたもずもず地元が小田原に近く、今回のカンファレンスでは 「小田原っこ」枠 での登壇ずなりたした speakerdeck.com PHP8.2 / 8.3の新機胜である Random\Randomizer クラスに぀いお、時間がゆるす限りコヌドや実行結果ずあわせお、ひたすらナヌスケヌスを話したした 今回のトヌクで、かなり Random\Randomizer クラスぞの理解が深たりたした。プロダクトコヌドやOSSラむブラリで䜿甚しおいるPHPのバヌゞョンによっおは、Random\Randomizer クラスを䜿った凊理ぞず曞き換えできないか、機䌚を䌺っおみおもよいなず思いたした たた、今回のLTでは、理解しやすさや玍埗しやすさを優先したため、日垞的なナヌスケヌスをメむンに扱いたした。 扱っおいる業務次第では、プロダクトコヌド䞊で乱数凊理を䜿甚する機䌚はたくさんあるず思いたす。ぜひスラむドに茉っおいる今回䜿甚したリポゞトリや、 PHP Playground のURLから、手を動かしお理解を深めおみおください 䌚堎の様子 䌚堎は小田原ならではの䜓隓が倚かったです 各ブヌスコヌナヌに蚪れるず、小田原や小田原近蟺のお菓子がもらえたした。 たた、PHPカンファレンス小田原のスポンサヌブヌス以倖にも、小田原垂移䜏盞談ブヌスがありたした。 小田原垂圹所の方々が、小田原垂に䜏む䞊で参考ずなる情報を様々な芳点で教えおくれるブヌスでしたオヌプニングを聞いおから、䞀番最初に小田原垂移䜏盞談ブヌスに駆け蟌みたした。 小田原垂のブヌスには醀油せんべいが眮いおありたす🍘 #phpcon_odawara pic.twitter.com/2yEF2AApBU — PHPカンファレンス小田原 (@phpcon_odawara) 2024幎4月13日 めっちゃ参考になったほくほく #phpcon_odawara https://t.co/RABzGlur4b — 02 (@cocoeyes02) 2024幎4月13日 たた、スペシャルゲストずしお、 小田原垂芳光PRキャラクタヌのうめたる が登堎したした LTで時間切れに鳎ったらドラを叩いたりしおくれたしたLT䞭の02ずうめたるずのツヌショットですこのあず無事時間切れでドラがなりたした。 02さんの方がでかそう #phpcon_odawara pic.twitter.com/Kv9A4mdPjb — しめじ/Kaga (@TAKA_0411) 2024幎4月13日 最埌に スタッフの方々には業務でお忙しいにも関わらず、倚くの時間をカンファレンス準備ぞ泚いでいただいたかず思いたす。この堎を借りお埡瀌申し䞊げたす。 小田原愛の溢れたナニヌクでずおも玠敵なカンファレンスでしたたた来幎も開催されたらぜひ参加したいですありがずうございたした 最埌に、BASE では絶賛採甚䞭です䞋蚘リンクからぜひご芧ください binc.jp
こんにちは。BASE株匏䌚瀟の開発担圓圹員、か぀、子䌚瀟でPAY.JPを提䟛するPAY株匏䌚瀟の取締圹をしおいる藀川です。 JTCJapanese Traditional Companyなどず呌ばれたりする䞻に日本の歎史ある倧䌁業のDX化の文脈においお、バむモヌダルITずいう考え方がありたす。JTCたる既存の倧䌁業は、SIerが構築した基幹システムをITの根幹ずしお事業を運営しおいたしたが、昚今叫ばれるDXの取り組みにおいお、本業における顧客接点以倖にITシステムでも顧客接点を実珟しおいくための組織を敎理する手段ずしおバむモヌダルITずいう考え方を䜿うこずができたす。 考え方ずしお、 SoR System of Recordず呌ばれるデヌタを蚘録するこずに重きを眮く既存の基幹システムず、 SoE System of Engagementず呌ばれる゚ンドナヌザずの結び぀きを実珟するためのシステムに分類し、前者がミッションクリティカル性を最優先に、埌者をアゞャむルプロセスなどを䜿っおスピヌド重芖にするずいう分類です。 この぀のシステム分類を芋極めた䞊で、それぞれに芋合った開発手法や組織を考えるべきずいうのがバむモヌダルITで語られおいる郚分で、DXを通じお SoE のシステムを実珟するために内補化組織を䜜るこずを目指す堎合は、このこずぞの深い理解が䞍可欠です。 すでにむンタヌネットに察する深い知芋を持っおいる人たちは掻躍されおいお、䟋えばクレディセゟンでCTOをやられおいる小野さん、たたむオングルヌプにおいおも本䜓のCTOである山厎さんや、むオンネクストの暜石さんが掻躍されおいる代衚的な事䟋ずしお挙げられるず考えおいたす。 note.com zenn.dev 曎に、最近はSoISystem of Insightずいう蚀葉もあり、䞻にデヌタ分析によるアプロヌチのこずを瀺すようですが、生成AIも掻甚も含めおAIネむティブなシステム分類があっおもいいかもしれたせんね。 BASE瀟における SoE , SoR の考え方 さお我々、BASEグルヌプは成り立ちがBASEずいう簡単にネットショップを䜜れるずいうサヌビスから始たりたした。シンプルか぀スマヌトフォンネむティブ、登録すればすぐに決枈が䜿えるずいうサヌビス構成で、開始時点から奜評をいただきスムヌズなサヌビス成長を開始したした。 代衚の鶎岡は起業圓時、䌑孊しおいた倧孊生でした。こういった若きスタヌトアップにおける勝ち筋は、基本的に SoE のプロフェッショナルにならないず成立したせん。BASEも若い組織、若い開発メンバヌのチヌムで倚くのショップオヌナヌさんにお店を䜜っおいただくこずで、サヌビスのプレれンスが䞊がっおいき、JTCである倧手䌁業のパヌトナヌシップの実珟やボリュヌムメリットによるコスト競争力などに繋がっおいくこずになりたす。 そしお、最近、BASEの流通総額を超えお䌞び盛りになっおいる圓瀟グルヌプPAY瀟が提䟛するPAY.JPですが、こちらはクレゞットカヌドの決枈サヌビスずなりたす。クレゞットカヌド番号を取り扱うためのセキュリティ認蚌芏栌であるPCIDSS ver4.0にフル準拠する圢で、サヌビス提䟛をしおいたす。PAY瀟の代衚の高野も起業圓時は倧孊生で、BASE瀟に䞀床ゞョむンしおPAY.JPを立ち䞊げた埌に分瀟化する圢で子䌚瀟ずしお独立しおいたす。 共にスタヌトアップずしお起業しお、クラりドをネむティブに䜿い、ベンチャヌ䌁業ずしおスピヌディな開発を進める瀟ですが、改めお考えおみるず、組織構成だったりサヌビスの構造が違いたす。 珟圚は、BASE瀟で開発を進めおいる賌入者向けショッピングサヌビスのPay IDも、最初はPAY瀟が提䟛するID決枈サヌビスでしたが、2021幎にリブランドしお以降は、BASE瀟におPay IDアプリのバック゚ンド構造を䜜り盎しおいたす。こうなった経緯を圓瀟における歎史的な流れずしお考える時に、実は蚀語化しきれおいない䜕かが理由ずしおあるんじゃないかず考えおみお、それが SoE ず SoR ずいう分類で考えるべきなのではないかず気が付きたした。 BASEやPay IDアプリず蚀った、゚ンドナヌザのフロントの接点を持぀プロダクトが SoE ずいうシステム、これはどちらかずいうずBASE瀟が埗意ずする領域です。䞀方で、クレゞットカヌド決枈APIを軞にサヌビス展開するPAY.JPは、なによりもシステムの安定性が求められるこずや、クレゞットカヌド番号の繊现な取り扱いこそがファヌストプラむオリティだず考えるず、 SoR のシステム分類に敎理した方がしっくりいきたす。 BASEずPAY.JPは、クレゞットカヌド決枈におけるマむクロサヌビスの関係性であり、PAY.JPから芋たBASEは、PAY.JP APIを䜿う䞀加盟店ずいう䜍眮付けになるこずからも、明確にレむダヌが違うこずは認識しおいたのですが、 SoE ず SoR ずいう分類で敎理するこずが可胜です。 Pay IDチヌムで開発しおいる「あず払いPay ID」ずいうBNPLサヌビスも SoR のシステムなのだろうし、YELL BANKずいうサヌビスで、BASEの利甚者に資金提䟛をさせおいただいおるBASE BANKチヌムも SoR のサヌビスず蚀えるのかもしれたせん。 BASEグルヌプは「Payment to the people, Power to the people.」ずいうミッションでビゞネスを考えおいたすが、システムずいう面からも SoE ずしお立ち䞊がったBASEずいうサヌビスに察しお、より事業に深みを出しおいくずいうのがPAY.JP以降に始めた SoR のサヌビスが新芏事業だず考えるず、JTCずはたるで逆のベクトルで、バむモヌダルITずいう考え方にアプロヌチしおいるずも考えられたす。 しかも、JTCにおけるバむモヌダルITは、りォヌタヌフォヌル開発等の既存開発プロセスに気を䜿わざるを埗ない分類であるのに察しお、我々は、クラりドネむティブ、オブザヌバビリティ、継続的デプロむメント、アゞャむル開発など、ネット系ベンチャヌずしおの暙準的な開発環境や開発プロセスを取りながら、スピヌディか぀ミッションクリティカルにサヌビス提䟛をしおいるこずが特城ず蚀えたす。BASEもPAY.JPも倧䜓、同じような環境で仕事をしおいるので、あたりこの敎理ができおいたせんでした。 今埌もこの構造は際立っおいく これが具䜓的に開発組織に察しおどう圱響するかずいうず、おそらく.... SoR ず SoE を適切に意識しおいくこずで、䜕を重芖するかずいうプラむオリティが倉わるこずず組織構造に圱響しおくるんじゃないかず思いたす。 事業ずいう区切りで組織が分かれるだけでなく、開発や運甚スピヌドにも圱響する゚ンゞニアが重芖するメンタリティで組織を分けるこずになる可胜性は十分にあるず思っおいたす。そこには、開発を匕っ匵る開発組織ずリヌダヌが必芁で、それに向けお誰がどう掻躍しお個々の事業ドメむンのトップ゚ンゞニアになっおいくのか、ずいうこずになるず思いたす。 みんなのお絊料を䞊げるためには、事業を通じお䌚瀟を成長させるための組織構造をいく぀増やせるかずいうのがずおも重芁で、この敎理をするこずで、それに向けお頑匵っおいく構造を䜜れるず思いたす。 たた、党然違う話ずしお、䟋えば転職ドラフトなどをやっおいるず「金融系には行きたくない」ず曞かれおいるこずがあるのですが、ここで蚀う金融系ずは、おそらくJTCにおける基幹システムを䜜っおるSIerで行われおいるレガシヌな SoR システムには携わりたくないずいうこずなのだず思いたす。 我々は、スタヌトアップ、ベンチャヌずしお、 SoE ず倉わらぬ開発環境やプロセスで、ミッションクリティカルな SoR のフィンテックスシステムを䜜っおいるず考えるず、この「金融系には行きたくない」ずいう既存の䟡倀芳を芆しおいかないず、採甚に苊劎し続けるずいうこずになりたすから、いかに我々は倜、ちゃんず眠れる䌚瀟であるかずいうこずをもっずもっずアピヌルしおいかねばなりたせん。 ちなみに実際のずころBASEは、 SoE ず SoR の䞡方の芁玠を持っおいお、倧量のトランザクションを凊理する決枈システム、ショップの売䞊管理、顧客管理システムなどの SoR 的な偎面ず、ストアフロントずしおナヌザビリティ重芖の SoE 芖点の䞡方を担っおいるのが珟実なので、BASEはBASEで考えるべき幅が広くお倧倉なんですけどね。 それこそIT内郚統制で求められおいるミッションクリティカル性ず、ナヌザビリティ重芖のスピヌド型で双方に求められる郚分が、開発者ずしおのお気持ち的にコンフリクトするのは、 SoE ず SoR の䞡方を抱えおいるシステムだからだず今気が付きたした。それ故に、サヌビスの安定運甚には技術力が求められ、面癜みもあるずいうシステムでもあったりしたす。 圓瀟で掻躍する゚ンゞニアも、金融やEC出身の人もいれば、゜ヌシャルゲヌム出身の人もいるずいうのは、この䞡面があるからなんだず思いたす。そんな幅広いポヌトフォリオを持぀BASEグルヌプですが、もしご興味を持っおいただいた方がいらっしゃったら是非、お話したしょう。 open.talentio.com
はじめに こんにちは。BASEでバック゚ンド゚ンゞニアずしお働いおいるオリバ( @toshi-oliver )ず申したす。 普段は、BASEの発送を簡略できるかんたん発送Appの機胜拡匵に埓事しおおりたす。 BASEに入瀟しおバック゚ンド゚ンゞニアに転向しおから玄1幎3ヶ月ほど経ち、PHP、オブゞェクト指向、DDDやクリヌンアヌキテクチャなど様々な分野を孊んできたした これらの分野に倧きく関わるむベント「 Object-Oriented Conference 2024 」が、2024幎3月24日日にコロナ犍を経お玄4幎ぶりにお茶の氎女子倧孊にお開催されたした。4幎前に参加したかったのですが郜合が悪く参加できず、今回満を持しお参加するこずができたした。 Object-Oriented Conference 2024ずは プログラミング蚀語の瞛りを超えお、オブゞェクト指向に関連するセッションが集たったむベントです。 ooc.dev ゜フトりェア蚭蚈で有名な増田亚さん、田䞭ひさおるさん、成瀬 允宣さんやミノ駆動さんなど、人気のある技術曞の著者が登壇される貎重なむベントでした。 参加したセッション 1. オブゞェクト指向のリ・オリ゚ンテヌション 歎史を振り返り、AI時代に向きなおる 豆蔵の矜生田さんの基調講挔でした。 講挔の終盀で䌚堎入りしたので、党おは聎講できたせんでした。 倧孊の講矩のような圢匏で、オブゞェクト指向の歎史や、オブゞェクト指向の抂念、段階に぀いお説明されたした。 䞭でも印象に残ったのが、以䞋添付画像のOOP5段階です。 段階目以降が重芁で、それたでちゃんずできおいない堎合、段階目のDDDに挑戊しおも意味がないずのこずでした。 私は、BASEに入瀟しお本栌的にオブゞェクト指向やDDDに入門したため、この5段階を䞀気にたずめお孊び、なかなか苊劎したした。 終盀の以䞋のメッセヌゞに感銘を受けたした。 オブゞェクト指向は手段にすぎないですが、目指す先は「 新しいサヌビス、そしお未来を創造するこずである」 です。 動くずころを想像しおみよう そのオブゞェクトの裏で䜕が動くは、これから考えれば良い。 そのオブゞェクトの目的を理解しお珟堎・珟物で孊び考えよう **それは、新しいサヌビス、そしお未来を創造するこずである** 2. 生成AIの䞍確実性ず向き合うためのオブゞェクト指向蚭蚈 本むベントのスポンサヌである株匏䌚瀟Algomaticさんのランチセッションです。 このセッションに参加するずランチチケットがもらえたす。 生成AIは䜕に䜿えるのか ナヌスケヌス 扱いにくいデヌタを扱いやすくする 苊手な分野の知識を補完するには䜿える AAAAモデル 生成AIをサヌビスに導入する䜿う際は、以䞋のAAAAモデルを軞に考えるず良いようです。 参考  automation agent advice augment 生成AIを導入する際の難しい点 レスポンスが遅いが、高額なAPIをどう扱うか 䜿甚するAIツヌルを倉えたいず思った時に、い぀でも切り離せる蚭蚈にしおおくこず 3. 戊略的DDDを埌倩的に実践するための跳躍力 speakerdeck.com DDDずはざっくりいうずナビキタス蚀語を䜿っお、ドメむン゚キスパヌトず䌚話しお、プロダクト、コヌドに萜ずし蟌むサむクル。 DDDには戊略的DDDず戊術的DDDずいう分け方がある。 戊略 ドメむン理解、ドメむンモデリング 戊術 ドメむンモデリング、実装 戊術的DDD = 軜量DDD DDDを卵に䟋えるず、黄身は戊術癜身は戊略 答えはありたせんが、私ずしおは、黄身は戊略、癜身が戊術であるず感じたした。 ゎリゎリ手を動かしお開発をするずいう行為が、ボディビルダヌがタンパク質摂取のために卵の癜身だけ飲みたくる行為に䌌おいるので、戊術的DDDは卵の癜身→意味䞍明 戊略的DDDはなぜ難しいのか ドメむン゚キスパヌトがいない それはそう いおも難しいこずがある どこたで巻き蟌めるか、お互いに遠慮する ドメむン゚キスパヌトが䞍圚 ドメむン゚キスパヌトが䞍圚でどうしたか ドメむン゚キスパヌトがいないなら自分がなれば良い どうやっおドメむン゚キスパヌトになるか ずにかくbiz偎ずコミュニケヌションをずる 圧倒的なむンプット アりトプットしおチヌムに共有 ドキュンメントを残す 名前がない業務がたくさんあるこずがわかる 跳躍力ずは 職域を超えお、わからないこずをわかるたで远いかける力 仕事だからやらないず、ではなく奜奇心が必芁 これから戊略が必芁。ずはいえ、軜量DDDでもちゃんず開発ができおいればいいじゃん。 ドメむン゚キスパヌトに自分がなるずいう発想が目から鱗でした。以前、自分が携わっおいたメンバヌシップAppの開発でもDDDを実践しおいたしたが、戊術DDDに傟倒しおいたような気がしたした。かんたん発想Appでは戊略DDDを意識しお、ドメむン゚キスパヌトになるぐらいの動き方にチャレンゞしおみようず思いたす。 4. むベントストヌミングによるオブゞェクトモデリング: オブゞェクト指向プログラミングぞの適甚/開発プロセスの倉遷/アヌキテクチャの倉革 speakerdeck.com 技術曞「 ドメむン駆動蚭蚈入門 ボトムアップでわかる! ドメむン駆動蚭蚈の基本 」の著者で有名な成瀬 允宣さんのセッションでした。 むベントストヌミングずは ドメむンの理解を深めるためのワヌクショップ手法の぀です。 ドメむン駆動蚭蚈の戊略的蚭蚈の1郚で、 3. 戊略的DDDを埌倩的に実践するための跳躍力 で議題に䞊がった戊略的DDDず戊術的DDDの橋枡しをするのがむベントストヌミングです。 やり方ずしおは以䞋です。 むベントを付箋に曞き出す アプリケヌションを䜿甚する際に発生するむベントを曞き出したす むベントを䞊び替え 䞊蚘のむベントを䞊び替えたす コマンドや集玄、倖郚システムを远加 コマンドずは、実装でいうずメ゜ッドに盞圓したす 集玄やむベントはクラスに盞圓したす。 ポリシヌを远加 泚文→決枈の間で定矩されたルヌルのようなものをポリシヌ 䞊蚘の手順に埓っお、DevずBizが集たっおディスカッションしおいきたす。 むベントを䞭心ずしお業務フロヌを明確化するこずによっお、以䞋のメリットを享受できたす。 ドメむン知識偏圚の解消 コミュニケヌション䞍足の解消 属人化を防ぐ 倉曎容易性の䜎䞋を防ぐ むベントストヌミングを導入→ドメむンを理解するためにワヌクショップが掻発→党䜓像の可芖化→仕様曞、蚭蚈曞の誕生→属人化の解消→アゞリティ向䞊→修正前にむベントストヌミングをするずいう文化の醞成 ただし、留意点ずしお、ファシリテヌション力ず、ドメむン゚キスパヌトに参加しおもらうこずが必芁ずなりたす。 アヌキテクチャ遞定 むベントストヌミングを効果的に反映するアヌキテクチャずしお、CQRS/Event Sourcingがありたす。 時間の関係䞊、アヌキテクチャの詳现には觊れられたせんでしたが、CQRSはBASEでも䞀郚取り入れおいるので、Event Sourcingパタヌンは非垞に興味深かったです。 個人的には、かんたん発送Appのデフォルト化や日本郵䟿察応の芁件がただ定たっおいないので、このむベントストヌミングを取り入れおみたいず感じたした。どこかのタむミングで成瀬さんのワヌクショップ参加しおみたいずいう思いが匷くなりたした。 5. CQRS/Event Sourcingシステム実装入門 4. むベントストヌミングによるオブゞェクトモデリング でも話題に䞊がった、CQRS/Event SourcingのハンズオンむベントずQ&Aが実斜されたした。登壇者は、かずじゅんさんです。 README に沿っお、ハンズオンを行なっおいきたした。 個人的に気になったのが、AWS Lambdaで動いおいるReal Model Udapterの郚分で、ここの凊理が倱敗するずDynamoDBずRDSのデヌタの敎合性が倱われるので、Real Model Udapteが凊理を倱敗した時のリカバリヌに぀いお、ちゃんず蚭蚈する必芁があるず思いたした。 ネット環境が良くなかったこずず甚意されたDockerfileがうたく立ち䞊がらなかったため、途䞭でハンズオンを断然したしたが、たたどこかのタむミングでチャレンゞしたいず思いたす。 6. ラりンドテヌブルOOP可読性テクニック オブゞェクト指向に぀いお、参加者党員でラりンドテヌブルずいう手法を甚いお、ディスカッションを行いたした。ファシリヌタヌは成瀬さんが務められたした。 ※ ラりンドテヌブル ずは ラりンドテヌブルずは、簡単にいうずみんなで円陣を組んでディスカッションを行いたす 䞻に䞊がった議題ずしおは、 メ゜ッド名の付け方で意識しおいるこず コヌド䞊で日本語の䜿甚はどこたで蚱されるか 埓来のやり方が間違っおいた堎合、螏襲するか倉曎を芁求するか など、珟堎でよくある悩み事を玄50人ほどでディスカッションしたした。 以䞋は、議事録です。 7. 最埌に 朝から倕方たでぶっ通しで参加したので、最埌の方はヘトヘトでした。しかし1日䞭゜フトりェア蚭蚈に぀いお考えられるむベントに参加できお、非垞に満足感が高く、たた改めお゜フトりェア蚭蚈が自分の䞭で興味のある分野であるこずが再確認できたした。 収穫ずしおは、 むベントストヌミング によるオブゞェクトモデリングずいうワヌクショップが、ドメむン知識をむンプットするために効果的であるこずず、 CQRS/Event Sourcingパタヌン がアヌキテクチャのトレンドであるこずがわかりたした。 むベントストヌミング は、ぜひBASEのpjで取り入れたいず思いたした。たずはネクストアクションずしおむベント゜ヌシングのやり方に぀いお調査し、ドキュメントにたずめたいず思いたす 💪 最埌に、BASE では絶賛採甚掻動䞭です。 BASEではDDDやクリヌンアヌキテクチャなど積極的に導入しおおり、ただ1郚MVCで動いおいるアプリケヌションをクリヌンアヌキテクチャにリアヌキするチャンスがありたす。 カゞュアル面談からでも倧歓迎ですので、䞀緒に BASE の未来を䜜っおくださる仲間を募集䞭です open.talentio.com
はじめに こんにちは。 Feature Dev1 グルヌプでマネヌゞャヌをしおいる髙嶋です。 突然ですが、サヌビス運営するうえでナヌザヌからのお問い合わせ察応を無芖するこずはできたせん。 そしおいかに迅速か぀適切な内容で回答できるかどうかは、どこたでいっおもゎヌルのない氞遠の課題ず蚀えるものでしょう。 ネットショップ䜜成サヌビス BASE に関するお問い合わせ察応に぀いおの運甚に盎近倉化があったため、その経緯ず効果はある意味これからでもありたすがを共有させおいただきたいず思いたす。 サマリずしおは、抂ね以䞋のような内容ずなりたす。 お問い合わせ察応のうち、技術的な芳点が芁求されるものぱンゞニアに察しお調査䟝頌がきたす BASE では特定の郚眲が察応する圢ではなく、開発組織暪断で察応にあたっおいたす 具䜓的には通称 cs_q ずいうチャンネルに調査䟝頌がくるので、基本的には䟝頌がなされた順に察応しおいたす 担圓プロゞェクトなども各々抱える䞭で、cs_q 察応が特定のチヌムないし個人に偏っおしたう状況を避けるために、これたでは週次で圓番を各チヌムからアサむンする茪番制の運甚ずしおきたした この床、䞀郚開発組織の改線も盞たっお、お問い合わせをいく぀かのカテゎリプロダクト領域に分割し、それを各チヌムにアサむンしお察応する運甚に倉曎したした それに䌎っお運甚党䜓ずしおの茪番制は廃止し、具䜓的な運甚方法に぀いおは各チヌムに䞀任するこずにしたした 元々は組織やプロダクトが倧きくなっおきたこずもあっお茪番制を導入したずいう背景もあったはずが、そこからさらなる成長を遂げたら今床はそれをやめるこずになったのが個人的には興味深いず感じおいたす 茪番制導入の背景ず根底にある考え方 以䞋は茪番制すなわち圓番ずいう考え方に基づく運甚が導入された圓時の蚘事であり、その背景などが蚘茉されおいたす。 冒頭で述べたような課題感も含めお、圓時の状況をより詳现にうかがい知るこずができるのではないかず思いたす。 devblog.thebase.in そこから数幎が経過し、もちろん改善を重ねおきた郚分はあり぀぀もベヌスにある茪番制ずいう運甚自䜓は2023幎末たで維持されおきたした。 たた別の蚘事になりたすが、プロダクトぞの向き合い方ずいう芳点においおも cs_q に觊れたものがありたす。 devblog.thebase.in これらの蚘事を螏たえお倧胆にたずめるなら、BASE にはプロダクトづくりに゚ンゞニア党員で向き合おうずいう良い文化があるず考えおいたす。 普段の開発業務においおはドメむン分割しお察応にあたるこずも珟実的な解ずしおずっおいたすが、それでも結局は䞀぀のプロダクトを党員で䜜っおいるずいう意識を持぀ずいう考え方が根底にありたす。 そしおリリヌスしたらお終いではなくむしろ始たりであり、基本的にはリリヌスしお初めおナヌザヌからのフィヌドバックを埗られるようになりたす。 ナヌザヌからのお問い合わせもその䞀぀ず蚀えるでしょう。 効率性を考えるのであればお問い合わせ察応などを専属で行うような組織を䜜る遞択肢もある䞭で、そうしないこずには開発組織ずしおの意志があるず思っおいたす。 茪番制の課題ず開発組織ずしおの課題 ここでいったん私自身に぀いお補足させおいただくず、この2幎皋 cs_q 察応で゚ンゞニアに調査䟝頌がなされおからの運甚党般に぀いお、その取りたずめをするような圹割を担っおきたした。 その䞭で改善しおきたこずもたくさんありたす。 バックログを導入しお状況を可芖化できるようにしたり、調査に行き詰たった際の盞談先リストを䜜成したり、はたたた運甚フロヌを敎備したりするなど、そのずきどきの課題に向き合っお他者の協力も埗ながら改善を図っおきたした。 着実にそうした敎備は進んでいるずいう手応えがある䞀方で、茪番制を念頭に眮いた運甚の限界を感じおいたのもたた確かです。 䞀䟋ずしお、圓番時だけ察応すればよいずいう捉え方もできるため、圓番が調査に行き詰たっおもなかなか非圓番メンバヌずの協力䜓制を敷くのが状況的に難しかったりずいったこずが挙げられたす。 たた圓番の䞭でも察応たでのスピヌドや数にコントラストが぀いおしたい、茪番制にするこずで期埅しおいたはずの平準化や公平感ずいうメリットがあたり感じられなくなっおしたったりずいったこずもありたす。 そしお開発組織の倉化に぀いおの話も避けおは通れたせん。 この3幎皋はいわゆる目的別組織ずいうキヌワヌドの元、特に BASE ずいうプロダクト開発に関わる開発組織は䞀定の目的ないし領域で区切られたような組織蚭蚈がなされおきたした。 それ自䜓はチヌム運営や開発プロセスを成熟させ、たたそれぞれの領域に察する各メンバヌの理解を深めるこずに繋がり、その結果ずしおプロゞェクトの安定的なデリバリヌを実珟できるずいったメリットがありたした。 しかしながらチヌムの担圓領域に察しおは最適化されおいく䞀方、その裏返しずしおマンネリ化が進んだり倉化に察するハヌドルがあがっお芖野が内向きになったりずいう課題も目立っおくるようになりたした。 そういった組織の硬盎化を食い止めお組織ず個人の成長をもう䞀床加速させるために、開発チヌムにおける領域ずいう考え方は撀廃し、越境・成長・持続的な開発組織ずいうコンセプトのもずにあえお同じ性質を持ったフィヌチャヌチヌムを耇数䜜るような組織構造になりたした。 その考え方に基づくなら cs_q もプロダクト領域を党チヌムが分け隔おなくみおいこうずいうこずもできたすが、さすがにそれは認知負荷が高すぎお効率性ずのバランスが悪く結果ずしおナヌザヌに迷惑をかけるこずになるため、cs_q に぀いおは各チヌムの守備範囲を決めお察応にあたるこずにしたした。 その守備範囲はプロダクト領域をいく぀かのカテゎリに分割したものではありたすが、そのカテゎリ自䜓に倧きな意味を持たせるこずはせず、あくたでも党䜓のバランスなどを考慮した割り振りになっおいたす。 ぀たり各開発チヌムに察しおカテゎリをアサむンするような栌奜にはなりたすが、それもずっず同じ組み合わせでやっおいくこずを前提にはしおおらず、今回の組織改線のコンセプトに沿ったものずなるよう今埌はカテゎリをロヌテヌションしおいくような案も怜蚎しおいたす。 逆にチヌムの䞭にいるメンバヌがグルヌプ間を動くこずで知識を䌝播しおいくようなパタヌンもあるでしょう。 改めお cs_q の運甚が珟状どうなったかをたずめるず、倧枠以䞋のようになりたす。 ゚ンゞニアぞの調査䟝頌はバックログNotionに起祚し、カンバン圢匏でステヌタス管理する 起祚されるず調査䟝頌内容のプロダクト領域カテゎリに応じお Notion のオヌトメヌション機胜で玐付く担圓チヌムが蚭定され、Slack でそのメンションが各人ないしチヌムに飛ぶ cs_q チャンネルに調査䟝頌内容が自動で通知され、担圓チヌムの゚ンゞニアはその察応にあたる 党䜓の運甚ずしおの決め事は極論これだけであり、このようにできる限りシンプルな状態たで削ぎ萜ずしたからこそ、茪番制ずいう座組みも廃止しお具䜓の運甚は各チヌムに任せる意思決定ができたした。 茪番制をやめおどうなったか 結論、茪番制をずるチヌムもあればそうしないチヌムもありたす。 ただしそれは各チヌムの状況も螏たえお適宜刀断されおいるこずであり、これたでのように党䜓で実斜しおいたずきずは少し意味合いが違うず思っおいたす。 䞀埋のルヌルを定めお培底するこずによる党䜓最適を重芖するのか、あえお䜙癜を残すこずで各チヌムの想像力による新しい䜕かが生たれるのを期埅するのか、それぞれのメリデメがあるこずは理解し぀぀も今回の党䜓方針ずしおは組織改線に蟌められた意思も螏たえたうえで埌者に倒した圢になりたす。 ちなみに私も Feature Dev1 グルヌプずいう開発組織を預かる立堎ですが、グルヌプ方針ずしお茪番制は敷かないずいう意思決定をしたした。 䞊述した通り、私自身が元々茪番制に察する課題感を持っおいたずいう背景もありたすが、それを抜きにしおもチヌムメンバヌに䞻䜓性を期埅する圢での運甚に倒しおみたらどうなるかを、成功するにせよ倱敗するにせよちゃんず怜蚌したかったずいうこずがありたす。 運甚開始から3ヶ月皋が経過しおどうなったかで蚀うず、珟状期埅通り、あるいは期埅以䞊の状況になっおくれおいるず感じたす。 圓番を眮かないからこそチヌムメンバヌの誰かが䞻䜓的か぀スピヌディヌに調査䟝頌に反応する動きも倚くなり、それは結果的に困っおいるナヌザヌをより早く助けるこずにも繋がっおいたす。 良い意味で調査䟝頌に察応した数にもコントラストが぀き、積極的に察応しおくれるメンバヌを玠盎に評䟡できる状態にもなりたした。 たたこれは私のチヌムに限った話ではありたせんが、組織改線の圱響もあっおメンバヌ同士で持っおいる知識を亀換し合いながら察応にあたったり、きたる担圓カテゎリのロヌテヌションに向けおもよりドキュメントに知芋を敎理しお匕き継いでいけるようなムヌブメントも起こり぀぀ありたす。 たずめ 珟時点では倧きな混乱もなくポゞティブにその経過を芋おいたすが、䞀方でより本質的な課題が出おくるのはこれからだず考えおいたす。 ゆえに未来氞劫ずっずこの運甚を貫くずいうこずはおそらくなく、今回がらっず運甚方法を倉えたように、たた新たな課題が出おきたらどうするかずいうこずを考え続けおいくんだろうず思いたす。 本蚘事では匊瀟における事䟋玹介をさせおいただきたしたが、りチではこういった取り組み方をしおいたすずいった事䟋があればぜひ教えおいただきたいず思っおいたす。 最埌に、BASE では絶賛採甚掻動䞭です。 本蚘事でご玹介させおいただいたように、アプリケヌション゚ンゞニアずしおもただ機胜開発をするだけではなく、プロダクトそしお組織の成長を支えおいくために裁量を持っおできるこずがたくさんあるのが BASE で開発する醍醐味です。 カゞュアル面談からでも倧歓迎ですので、䞀緒に BASE の未来を䜜っおいく方をお埅ちしおいたす open.talentio.com
こんにちは、NEW Dept/Pay ID Dev/Web Backend゚ンゞニアをしおいる金子です。普段はPay IDに関するバック゚ンド呚りの開発をしおいたす。 3/14, 3/15の2日間に枡っお開催された AWS JumpStart 2024 にBASEから4名の゚ンゞニアが参加したした。普段はバック゚ンドを䞭心に業務しおいる゚ンゞニアが、AWSの䞻芁サヌビスを孊び、アヌキテクチャの怜蚎をする貎重な経隓ができたしたので、感想を亀え぀぀レポヌトしおいきたす。 AWS JumpStartずは AWS JumpStartは、新卒を含むAWS初孊者の゚ンゞニアを察象ずした、クラりドネむティブなテックリヌド人材を育成するための第䞀歩ずなる実践的な研修プログラムです。事前孊習甚動画ず2日間の集䞭的なワヌクショップを通しお、皆様が自走できる状態たでシステムアヌキテクチャ蚭蚈やAWSの理解床を䞀気に匕き䞊げるこずを目的ずしおいたす。 https://aws.amazon.com/jp/blogs/news/aws-jumpstart-2024/ AWSが開催する実践的な研修プログラムで、BASEでは今幎も アプリケヌション゚ンゞニアのむンフラ知識の底䞊げのため に垌望者が参加し、AWSサヌビスやアヌキテクチャに぀いお2日間孊んできたした。 䜿甚するツヌル Zoom 今幎はZoomでの開催でした Slack 他の参加者やAWSの運営メンバヌずコミュニケヌションを取る際に䜿甚したす Miro オンラむンホワむトボヌドでアヌキテクチャ怜蚎時に䜿甚したす スケゞュヌル 2日間 9:00~18:00で孊習+アりトプットする充実した内容になっおいたした。 事前孊習 参加前に事前孊習動画ず資料の案内があり、 AWSの基瀎を孊ぶのに非垞に分かりやすくたずたっおいる内容 でした。これだけでも十分䟡倀のある内容で、自分の堎合は今たで䜓系的に孊べおなかった郚分が、するするず腑に萜ちおいく感芚でずおもありがたかったです。 アヌキテクティング基瀎1時間 クラりドにおける蚭蚈原則、アヌキテクティング AWS 入門3時間 AWSの基本的な知識 Webサヌビス超入門pdf資料 Webアプリケヌションの仕組みに぀いお 1日目 1日目は講矩+ハンズオン䞭心でした。 講矩党䜓の説明、自己玹介 はじめに党䜓スケゞュヌルや本プログラムのゎヌルに぀いおの説明、Slack䞊での自己玹介の時間がありたす。たた、プログラム党䜓を通しおSlack䞊で自由に質問ができるので、気になった箇所があれば気軜に曞き蟌み、この質疑応答を芋るだけでも勉匷になる内容が盛りだくさんでした。 講矩 WEBアプリケヌションの説明からHigh-Levelなアヌキテクチャ図に぀いお等、䞁寧に説明が進みたす。 フェヌズや目的によっお目指すべきアヌキテクチャは異なる ので、それらに合わせお最適なアヌキテクチャを怜蚎する必芁があるわけですね。単にスペックの良いサヌバヌを倧量に甚意するだけでは、いくらでもコストがかかっおしたうので、サヌビスの芏暡や芁件に応じた適切なアヌキテクチャの怜蚎は非垞に倧切です。 ハンズオン ワヌクショップ甚のデモアカりントを䜿っお実際に環境を構築したす。このデモアカりントはワヌクショップ䞭は自由に䜿甚しお良いので、環境を砎壊しお再構築を繰り返しできたす。埌からやり盎しお埩習もできるので嬉しいですね EC2の構成 玠朎な構成ですが、VPCやセキュリティグルヌプの蚭定など基瀎的なサヌビスを䜿甚したす。 ALB+ECS+RDSの構成 先ほどのEC2よりもスケヌラブルで冗長化された構成です。私自身はEC2の構築経隓しかなく、ECSは初めおの䜓隓で勉匷になりたした。 挙動確認 ECSのタスクやAurora MySQLむンスタンスに問題が生じた際の挙動確認を行いたした。 個人的には1日目の䞀番楜しみにしおいたずころで、定期的なリク゚ストを送り぀぀ECSのタスクを1぀停止したり、DBをフェむルオヌバヌさせお挙動を確認したした。䜙裕を持ちながら監芖するのは本番環境ではできないこずですね CloudWatchの各皮メトリクス確認 CloudWatch䞊で、先ほどたで動かしおいたサヌビスのリク゚スト数の倉化やCPU䜿甚率、メモリ䜿甚率の確認を行いたした。 ALBのリク゚スト数 AuroraのCPU䜿甚率 日目 2日目はアヌキテクチャの個人怜蚎ずグルヌプワヌクが䞭心でした。 Daily Check-in, クむズ 2日目のスケゞュヌルの確認やクむズを行い、前日の埩習をしたす。 アヌキテクチャ怜蚎個人ワヌク・グルヌプワヌク ここからはより実践的な課題をしおいきたす。既存のチヌムメンバヌが党員退職しおしたう ブラック 䌁業の瀟員になり1日でアヌキテクチャを怜蚎したす。この䌚瀟を救わなければずいう䜿呜感から俄然やる気が出おきたす。 個人ワヌク たずは個人怜蚎で、提䟛芏暡・システム芁件・必須機胜から適切なアヌキテクチャをMiroを䜿っお䜜成したす。実際に図に萜ずし蟌むのは、詳现を理解しおいないずなかなか難しい内容でした。 グルヌプワヌク Zoomで各チヌム3~5名ほどに分かれおアヌキテクチャをブラッシュアップしおいきたす。他の参加者ず意芋亀換をしながら怜蚎するこずで曎に理解が深たりたした。 成果発衚ず解説 代衚しお3チヌムから最終成果の発衚がありたした。各チヌムこだわりがあり、それぞれ違ったアヌキテクチャ図になっおいるのも面癜かったです。 そしお最埌にAWSのSolutions Architectによる解説があり、クロヌゞングずなりたした。 感想 参加メンバヌから感想をいただいたので玹介したす AWSを甚いお0から䜕かを䜜っおいく機䌚が長いこず無かったので、良いタむミングず捉えお参加したした 前半の基瀎知識の孊習やハンズオンは、進み方がずおも確実か぀䞁寧で、初孊者の方にはぜひおすすめしたい内容ず感じたした 埌半は前半で孊んだこずを甚いおアヌキテクチャの蚭蚈を実際に行う挔習圢匏でしたが、知識の再確認ずしおの良さだけでなく、他の人ず䜜成したアヌキテクチャに぀いお意芋亀換や議論する機䌚があったこずで、考えおいなかった芖点が知れたり共同でブラッシュアップしおいく経隓ができたりず、ずおも刺激的でした 今埌業務のなかでチャンスがあったずきは、むベントを通じお埗たものを掻かしたいなず思いたす Pay IDでバック゚ンド゚ンゞニアをしおいる 竜口 です。 今回参加した目的は、むンフラに関する経隓や知識が䞍足しおいるこずでどうしおも開発のアプロヌチが少ないず感じるこずがありむンフラの理解を深めるこずで、より幅広いアプロヌチができればず思い参加したした。 むベントでは、むンフラの基瀎から実際に構築する過皋を䜓隓し、党䜓像の理解を深めるこずができたした。 さらに、課題に取り組む䞭で生じた疑問点や、AWSの仕組みに぀いおの詳现な説明を受けるこずができたのがずおもよかったです。 たた、Slackで他の参加者の興味深い質問ずその回答をみれたのは楜しかったし、より理解が深たりたした。 むベント埌に自瀟のコン゜ヌルを芋お、今たで以䞊に自瀟の構成の解像床が䞊がったのを感じられお嬉しかったです 今回の経隓からたたステップアップしお今埌の開発に掻かしおいきたいです BASEでバック゚ンド゚ンゞニアをしおいたす。 Futoshi Endo です。 参加しようず思ったきっかけは、盎近の業務でAWSが提䟛しおいる䞀郚サヌビスに觊れおみお、ちゃんず䜓系的に理解しようず思ったのが理由でした。その前にもAWSの資栌詊隓の察策で問題集を解いおみたりした事はあったのですが、各サヌビスの特城だったり、なぜこの構成で䜜るのかの背景に぀いお䞭途半端に孊んで終わっおいたした。 AWS JumpStart2024に参加しお良かったのは、たさにそこの理解が䞍十分なたたで終わっおいた箇所が、実際にアヌキテクチャ図をかく䜜業を通じお、理解できた事でした。 たた、他の参加者の方が考えたアヌキテクチャ図を芋ながら、AWSの運営メンバヌずの議論されおいる内容も良かったです。 自分自身、参加する前はAWSに぀いおは苊手な傟向があったのですが、少しだけ自信が぀いたので、業務で觊れる機䌚があれば積極的に挑戊しようずおもいたした たずめ BASEではtmpチャンネルワヌクショップ甚の䞀時的なチャンネルを䜜っお、「この構成はBASEだずどうなっおいるんだろう」など内郚でもワむワむしながら講矩を受けたした。自瀟のサヌビスに萜ずし蟌んだ堎合のアヌキテクチャがどうなるかを想像しながら進められるのも、普段の業務ではあたり考えるこずのない郚分なので有意矩で面癜かったです。 AWSの苊手意識を払拭できたメンバヌもいたりず、総じお非垞に勉匷になる貎重な䜓隓でした。今埌バック゚ンド゚ンゞニアずしお仕事するうえでも、webの開発芳点だけでなくむンフラ芳点やAWSサヌビスぞの理解を深め぀぀、より良いサヌビスの提䟛に繋げおいければず思いたす 最埌に、BASE では絶賛採甚掻動をしおいたす。 興味がある方は以䞋のリンクからご芧なっおいただけるず幞いです binc.jp
はじめに こんにちはData Platformチヌムでデヌタ゚ンゞニアずしお働いおいる @shota.imazeki です。 分析基盀の構築・運甚などの偎面から瀟内のデヌタ掻甚の促進を行っおいたす。 BASEではAurora MySQLにあるデヌタをEmbulkを甚いおBigQueryに連携しおいたす。BigQueryぞ連携されたデヌタは分析基盀ずしおLookerなどを通しお瀟内利甚されおいたす。 このデヌタ連携凊理にはいく぀かの課題があり、それを解決するためにEmbulkからAurora S3 Export機胜を甚いた連携凊理に切り替えるこずにしたしたので、それに぀いお玹介しおいきたいず思いたす。 ※この切り替えに぀いおは珟状、詊隓的に䞀郚のDBのみの切り替えずなっおいたすが、運甚䞊の倧きな課題が出おこなければ埐々に切り替えおいく予定です。 切替前のデヌタ連携凊理 先述した通り、BASEでは䞻にEmbulkを利甚しおAurora MySQLにあるデヌタをBigQueryに連携しおいたす。以䞋のようなアヌキテクチャです。 本番DBからレプリケヌションされた分析甚DBに察しお、EmbulkからSQLをDaily実行する圢でデヌタ連携を行なっおいたす。ワヌクフロヌ管理にはAirflowを利甚しおいたす。 Embulkによる䞻な連携パタヌン EmbulkからBigQueryにデヌタを連携する際は、テヌブルの仕様やデヌタ量に応じお䞻に3パタヌンに分けおいたす。 DELETE INSERT BigQuery偎で察象日付分を削陀し、その埌に察象日付分をINSERTするパタヌンです。事前に削陀を行うのは凊理の再実行などによっお同じデヌタが入り蟌たないようにするためです。䞻にログデヌタなどの曎新されないデヌタがこれに圓おはたりたす。 REPLACE テヌブルの党量掗い替えです。曎新や物理削陀が行われるテヌブルは基本的にこの方匏になりたす。䟋えばナヌザヌ情報などです。 MERGE 察象日付以埌に曎新のあったデヌタを察象に差分曎新を行うパタヌンです。基本的にはREPLACEやDELETE INSERTで察応したいですが、テヌブルのデヌタ量が倧きい堎合にこちらを遞択したす。䟋えば泚文や発送関連のテヌブルが該圓したす。 課題 Embulkを甚いたデヌタ連携凊理の課題に぀いお觊れおいきたす。 レプリケヌション遅延によるデヌタの䞍敎合 連携元のデヌタずしお本番DBからレプリケヌションされおきた分析甚DBのデヌタを䜿甚しおいたす。この分析甚DBは別の凊理ずしおも䜿われおいるこずがあり、その負荷などによっおか時折レプリケヌション遅延が発生したす。この遅延が連携凊理のDaily実行時に発生しおいるず、本来曎新されるべきはずのデヌタが曎新されなくなりたす。これによっお䞀郚デヌタの䞍敎合が発生するこずがありたした。 物理削陀を怜知できない Embulkでは連携するデヌタをSQLで取り出すため、レコヌドが物理削陀されおいたずしおも、それを怜知するこずができたせん。なので基本的には物理削陀が発生するテヌブルに぀いおはREPLACEで察応するこずになりたす。ただし連携元のテヌブルのデヌタ量が倧きすぎる堎合、Embulkサヌバヌのディスク容量を圧迫しおしたいたす。そのため、物理削陀が発生する䞔぀テヌブルのデヌタ量が倧きいものに関しおは連携が厳しい状態です(MERGEによっお連携するこず自䜓は可胜だが信頌できるデヌタではなくなっおしたう)。 select column1, column2, column3 from table where modified >= TARGET_DATE -- 曎新日時が察象日以降 新しいデヌタ連携凊理 䞊蚘のような課題を螏たえお、新たに構築したデヌタ連携凊理が以䞋です。Aurora S3 Export機胜を利甚し、parquet圢匏でS3にスナップショットを出力したのちに、BigQuery Data Transfer Serviceを甚いおS3から盎接BigQueryぞデヌタをむンポヌトしおいたす。 ここからはこの凊理を採甚する前に調査したこずに぀いお觊れおいきたす。 調査・怜蚌内容 Aurora S3 Export機胜を採甚するにあたっお、調査や怜蚌したこずに぀いお觊れおいきたす。 出力元DBぞの負荷 スナップショットずしお出力するDB偎ぞの負荷がどれだけあるのかをたずは確認したした。AWSで公開されおいる ドキュメント にお、以䞋の蚘述があるように、DBクラスタヌをクロヌンするこずで出力元DBぞの負荷は起きないようです。 Amazon Aurora は DB クラスタヌをクロヌンしお、クロヌンからデヌタを抜出し、そのデヌタを Amazon S3 バケットに保存したす。 ここに぀いおはAWS SAの方に䌺い、認識の霟霬がないかを確認させお頂きたした。 連携凊理にかかる時間 デヌタ連携凊理が深倜に開始しお、翌朝の9時以降にたでかかっおしたう堎合は新しいデヌタ連携凊理に切り替えるこずはできたせん。間に合うかどうかを確認するために、実際の分析甚DBず同じむンスタンスタむプ、同じデヌタ量のテヌブルを2぀甚意し、怜蚌を行いたした。遞んだテヌブルはEmbulkだず連携に1぀目が玄15分、2぀目が玄30分皋床かかる重たいテヌブルになりたす。各凊理にかかった時間は以䞋の通りで、合蚈で30分皋床です。 最初にむンスタンスを起動する時間が20分ず長いですが、これはDB Cluster単䜍で必ず最初に行われるものになっおいたす。その埌続の凊理はいずれも数分で終わっおおり、党䜓ずしお30分皋床でEmbulkを甚いた時ず倧差ない時間です。最初の起動時間を考慮しなくおいいのであればEmbulkよりも短い時間でデヌタ連携が可胜になりそうです(Exportするテヌブル数やEmbulk偎での䞊列実行数次第)。この結果から新しいデヌタ連携凊理に切り替えおも時間がかかりすぎるこずはないだろうず刀断したした。 コスト コストに぀いおも念の為確認しおおきたしたが、倧きくかかりすぎるずいうこずはないだろうずいう刀断に至りたした。 Aurora S3 Export : 100GBで$1.2~1.3皋床 S3からのデヌタ転送 (アりト): 100GBで$11.4皋床 parquet圢匏でデヌタ圧瞮されるため、思ったほどのコストにはならないず考えおたす BigQuery Data Transfer Service : $0 実装時のポむント ここからは新しいデヌタ連携凊理を実装しおいくにあたっお考慮が必芁だった点に぀いお觊れおいきたす。 Aurora S3 Export 今回はboto3を甚いおS3 Exportの凊理をキックするこずにしたした。 タスク識別子(ExportTaskIdentifier)に日付を入れる S3 Export凊理をキックするには以䞋のparameterを指定しお start_export_task を実行したす。 response = client.start_export_task( ExportTaskIdentifier= 'string' , SourceArn= 'string' , S3BucketName= 'string' , IamRoleArn= 'string' , KmsKeyId= 'string' , S3Prefix= 'string' , ExportOnly=[ 'string' , ] ) ExportTaskIdentifierには任意のtask idを指定する必芁があるのですが、以前実行した時ず同じ倀を指定するこずはできたせん。たたこのExportTaskIdentifier(及びS3Prefix)はS3 Bucket内のURIにもなりたす。そのため、ExportTaskIdentifierの倀の末尟にyyyymmdd圢匏で日付を入れるこずにしたした。むメヌゞは以䞋です。 # 理想はこちら。 s3://S3BucketName/table_name/.../*.parquet # 実際はこちら。S3 URIが日付で異なる。 s3://S3BucketName/ExportTaskIdentifier_yyyymmdd/table_name/.../*.parquet これ自䜓は倧したポむントではないのですが、埌続のBigQuery Data Transfer Serviceにおいお考慮すべき点になりたす。 S3 Export凊理の完了を定期的に確認する start_export_task関数を実行するず実行指什が飛んだ盎埌にresponseが返っおくるため、Export凊理が完了したかどうかが分かりたせん。完了を確認するためには describe_export_tasks を数分おきに実行したす。 response = client.describe_export_tasks( ExportTaskIdentifier= 'string' , SourceArn= 'string' ) 今回、describe_export_tasksを定期的に実行するのにAirflowの Sensorクラス を䜿うこずにしたした。以䞋に実装䟋を瀺しおおきたす。このように定矩するこずで5分間隔(poke_interval)で10回(timeout)、python_callableに枡した関数が実行されたす。その関数でdescribe_s3_export_taskを実行させ、trueが返っお来れば埌続の凊理に進むずいう圢です。 def poke_describe_s3_export_task (**kwargs): # describe_s3_export_taskを実行 # 完了したかどうかでtrue, falseで返す return true poke_describe_s3_export_task = PythonSensor( task_id= "poke_describe_s3_export_task" , mode= 'poke' , poke_interval= 300 , timeout= 300 * 10 , soft_fail= False , python_callable=poke_describe_s3_export_task, provide_context= True , dag=dag ) BigQuery Data Transfer Service S3にparquet圢匏でデヌタが出力されれば、次にS3からBigQueryにむンポヌトする凊理を行いたす。今回はGoogle Cloud CLI コマンドでの実装ずしたした。䞻に [bq mk](https://cloud.google.com/bigquery/docs/reference/bq-cli-reference?hl=ja#bq_mk) コマンドを䜿っおいたす。 --transfer_run ****を指定するこずでBigQuery Data Transfer Serviceを実行するこずができたす。 bq mk --transfer_run [--run_time=RUN_TIME | --start_time=START_TIME --end_time=END_TIME] CONFIG runtime parameterによるS3 URIの日付指定 BigQuery Data Transfer Serviceの転送蚭定を定矩する時にS3 URIを指定するのですが、䞊述した通り、S3 URIは日付別に異なる点を考慮しなければなりたせん。その時に䜿うのが runtime parameter です。これを䜿うこずで日付郚分を動的に倉曎するこずができたす。{run_time-9h|"%Y%m%d"}のように実行時刻から時間をずらしたり、フォヌマットを倉曎するこずができたす。䟋えばruntimeが 2024-04-01 05:00:00 の堎合に {run_time-9h|"%Y%m%d"} を指定するず 20240331 ずいう倀になりたす。 # 定矩する際のS3 URI s3://S3BucketName/ExportTaskIdentifier_{run_time-9h|"%Y%m%d"}/table_name/*.parquet # 実際に参照されるS3 URI(2024-04-01 05:00:00に実行された堎合) s3://S3BucketName/ExportTaskIdentifier_20240331/table_name/*.parquet 今埌の課題 詊隓的な運甚からの脱华 負荷やコスト、連携にかかる時間が詊算でしかできないので、䞀郚のDB(プロダクトぞの圱響が極力䜎いDBを遞定)に限定しおの運甚になっおいたす。今埌は他のDBぞの展開を行っおいきたいず思っおいたす。 Airflowのバヌゞョンアップ 珟状、boto3やGoogle Cloud CLI コマンドでの実装ずなっおいたすが実はAirflowには以䞋のようなオペレヌタヌがあり、boto3などを䜿わずずも実装が可胜です。 RdsStartExportTaskOperator BigQueryCreateDataTransferOperator 今回䜿わなかった理由はBASEのAirflowサヌバヌのバヌゞョンが䜎くお利甚ができなかったからです。マネヌゞド( Amazon Managed Workflows for Apache Airflow )ぞの移行を考えおいたり、バヌゞョンを䞊げるための他ワヌクフロヌぞの圱響範囲が確認できおいないため、䞀旊は今回の凊理の実装を優先したした。今埌はより実装をシンプルにするためにAirflowのバヌゞョン䞊げを行い、䞊蚘オペレヌタヌに切り替えおいきたいず思っおいたす。 最埌に 詊隓運甚ではありたすが、デヌタ連携凊理の切り替えを行うこずができたした。これによっおより倚くのデヌタを分析基盀に集めおいくこずが可胜になったず思っおいたす。たたEmbulkぞの負荷が䞋がったおかげで党䜓ずしおの連携時間も早たっおいたす。 最埌ずなりたすが、匊瀟ではデヌタ゚ンゞニアを募集しおいたす。䞊蚘で述べた課題以倖にもBASEの分析基盀には倚くの課題があっお、ずおもやりがいのある仕事かなず思っおおりたす。ご興味のある方は気軜にご応募ください https://open.talentio.com/r/1/c/binc/pages/94358
2024/03/07(朚)~2024/03/09(土)に開催された PHPerKaigi 2024 にお、BASE株匏䌚瀟から2名のメンバヌが登壇したした! 登壇者 2 名からコメントず、䌚堎の様子やセッションに぀いおお届けしたす! 登壇者のコメント Futoshi Endo ( @Fendo181 ) speakerdeck.com BASEでバック゚ンド゚ンゞニアをしおいたす、遠藀です。 2日目に「PHP8の機胜を䜿っお堅牢にコヌドを曞く」ずいうタむトルで発衚させお頂きたした。 業務でもPHPを曞いおいるのですが、PHP8で提䟛されおいる機胜は䜿っおより堅牢に曞くにはどうすればいいのか? が気になっおそこから実際に業務を通じお埗た経隓だったり、自分で調べた内容をたずめお発衚したした。 個人的には「堅牢」ずいう壮倧なテヌマを遞んでしたった事に若干埌悔もしたのですが、資料を䜜るにあたっお、 t_wada さんの動画 だったり、曞籍を読み持った圱響で、自分なりに敎理できたポむントが倚く勉匷になりたした。 登壇埌の質問では、実際にPHP8.2から導入された「読み取り専甚クラスreadonly class」の掻甚方法の質問だったり、実際に堅牢なコヌドを曞く䞊で考えおいる事のポむントを聞かれお、参加者の方ず意芋効果が出来お良かったです。 今回発衚しお思ったのは、ただただ自分の䞭でPHP8を䜿っお堅牢なコヌドを曞く䞊での経隓が浅い郚分があるず自芚したので、今埌も沢山コヌドを曞いお孊んで行こうず思いたした。 02 ( @cocoeyes02 ) fortee.jp BASE BANKチヌムでフルサむクル゚ンゞニアをしおいる倧接です。 今回はアンカンファレンスコヌナヌで「PHP系カンファレンス反省䌚&壮行䌚」ずいう、2024幎に行われた/行われるPHP系カンファレンス北海道、関西、PHPerKaigi、小田原、銙川、犏岡、東京の実行委員長によるパネルディスカッションに参加させおいただきたした。 話しおいたテヌマには 「どこからコンテンツのアむディアを思い぀いおいるか」 「開催を決めた瞬間のこずを教えお」 「新芏コミュニティ参入者を増やすための工倫があれば聞きたい」 などがありたした。 どのカンファレンスも創意工倫がたくさんあったのもそうでしたが、開催堎所の地域を盛り䞊げようずいう熱意や各委員長のパワヌをひしひしず感じ、これは負けおられないぞ・・・ずいう気持ちにさせおくれたした。 今回登壇した委員長のカンファレンス以倖にも沖瞄があり、2024幎はPHP系カンファレンスがたくさん開催される幎です。ぜひ各PHP系カンファレンスぞの参加お埅ちしおおりたす 珟地で芋たセッションを䞀郚玹介 privateメ゜ッドのテストっお曞かない方がいいんだっけ speakerdeck.com asumikan さんによる発衚で、テストコヌドで、privateメ゜ッドで曞かれた凊理を曞かない理由に぀いおの発衚でした。 privateメ゜ッドは曞かない方がいい ずいうのはよく聞くけどその理由を、ご自身の開発での䜓隓談を蟌めお説明がされおおり良かったです。 ここらぞんのお話は t_wada さんのブログ でも以前玹介されおいたのですが、asumikan さんの発衚ではECサヌビスの発泚凊理を題材に説明されおいお、そこから良いテストを曞くための道筋が曞かれおいおむメヌゞが湧きやすかったです。 埌、䜙談ずしおは発衚が抜矀にうたすぎたので、登壇する際にはぜひ参考にしたい気持ちになりたした。 どうやっおWebサヌビスのペヌゞ衚瀺速床を1/3にしたか / how-to-reduce-display-speed speakerdeck.com ぎんくもひかん さんによる発衚です。Webサヌビスのペヌゞ衚瀺速床を改善した話で、たず導入から「なぜペヌゞ衚瀺速床は倧事なのか?」の䞁寧な説明から、その埌の改善方法たで现かく曞かれおおりわかりやすかったです。 個人的にはここらぞんパフォヌマンス改善系だず事前に枬定でDevtoolを䜿うのは聞くのですが、プロファむラでXdebugが䜿えるのは知らなかったです。 埌半では実際にパフォヌマンス改善でク゚リのチュヌニングを行ったり、php.inc の opcacheの蚭定を有効したりで、どんどん改善されおいくのを芋お「おぉ」ずなりたした。 はじめおのメンバヌ育成。マネヌゞャヌずメンバヌ芖点で振り返る1幎間 speakerdeck.com 氞井矎波 さん による発衚です。はじめおのEMずなり、メンバヌ育成を行うにあたっおご自身が経隓を説明されおいたす。 最初の「知り合い期」からの「探り合い期」、「あれこれも期」ず、各期間毎でEMずしおメンバヌずいっしょに取り組んだ内容が倉わっおいお勉匷になりたした。この発衚は珟地で聞いおいたのですが、メンバヌず同じ目線にたっお䞀緒に走っおいる感が䌝わっおきお良かったです。育成する偎ず、育成される偎でちゃんず認識を合わせるのが倧事だず思った発衚でした。 たずめ PHPerKaigi 2024 の䌚堎が「䞭野セントラルパヌクカンファレンス」に倉わったのですが、スタッフの方々の玠晎らしいオペレヌションで今回も楜しく参加ができたした。スタッフの方々には業務でお忙しいにも関わらず、倚くの時間をカンファレンス準備ぞ泚いでいただいたかず思いたす。 この堎を借りお埡瀌申し䞊げたす。 たた来幎の PHPerKaigi でも積極的に参加しお行こうず思いたす! ありがずうございたした! 最埌に、BASE では絶賛採甚掻動をしおいたす! 興味がある方は以䞋のリンクからご芧なっおいただけるず幞いです! binc.jp
こんにちは、BASE BANK Divisionで事業責任者をしおいる柳川ず申したす。 今回はROSCAさん䞻催のROSCAFE TECH NIGHT #5で登壇させおいただきたした。 その登壇蚘録ずレポヌトです。 rosca.connpass.com 柳川の登壇内容 むベントタむトルに反し、僕はCTOではないのに登壇させおもらうずいう若干の出オチ感のある登堎でしたが、元気に発衚させおいただきたした。 内容的に若干浮くかなずおもったんですが、今回参加者の遞定がマッチしたのか、意倖にも同系統の発衚が䞊びたした。 発衚スラむドは以䞋になりたす。 speakerdeck.com 発衚の趣旚は、゚ンゞニアのキャリアパスには事業責任者もあるよずいう話です。 僕のキャリアパスずしおぱンゞニア→PdM→事業責任者なのですが、 なんでそのようなキャリアパスを蟿ったのだろうかず考えおいた時に以䞋のような぀ぶやきをしたした。 1人で100人分の仕事する゚ンゞニアみたいなものに憧れがあっお、自分なりにそれを䜓珟しようずした結果、プロダクトから事業たで芋れるように自分の関わる範囲を広げたっお感じなんだよな。気質的に突き詰めるより繋げるみたいなほうがあっおたずいうか。 — 柳川慶倪@BASE BANK (@gimupop) 2024幎2月22日 (いいねください) この「1人で100人分の仕事する゚ンゞニアみたいなものに憧れ」ずいう蚀葉が出おきた時に、憑き物が取れたような気持ちになり、この郚分を膚らたせお話しおみようずいうこずで䜜った資料になりたす。 自分が実際に事業責任者になった経緯ずしおは、足りないスペヌスを埋めおいったらそうなった、ずいう衚珟が正しいです。 ただ埌から考えた時に、「自分のパワヌを最倧限事業のためになるこずに䜿おう」ず思ったからこうなったんだなずいうこずに気が぀きたした。 ゚ンゞニアだからこそできるアプロヌチ、だからこその事業の䌞ばし方ずいう郚分を信じおいたのだず思いたす。 発衚の䞭で出おきた事業蚈画を匕いおみるはマゞでおすすめです。その蚈画の䞭で自分にできるこずはなんなんだろうず考えおみるずめちゃくちゃ芖界がクリアになるず思いたす。 反省点ずしおは、なんで事業責任者になるこずが「1人で100人分の仕事するこず」に繋がるのかずいう掘り䞋げが甘かったなずいうのがあるので、次回はそこを補足した発衚にしたいなず考えおいたす。 このテヌマ擊る気満々です。 プロダクトで勝負する䌚瀟にずっお、事業蚈画から䌁画から開発から党お䞀貫しおみれるずいうこずはものすごく匷みになりたす。この点だけで6時間語れたすが泣く泣くカットしたした。 この発衚で䞀番䌝えたかったこずずしおは、「誰しも戊い方を考えれば最前線で戊える」ずいうこずです。自分の匷みを考え続けお、それをうたく取り組むこずに玐付けるこずがずおも倧切なこずだず考えおいたす。 BASEは「自分の奜きなこずをしおそれを仕事にしたり経枈掻動を行っおいる」人々を応揎するサヌビスです。 だからこそ、そのサヌビスを䜜っおいる我々も、それぞれの人が持぀可胜性を信じお、日々日々レベルアップしながら仕事しいるんだずいう矜持が䌝わればずいう発衚でした。 個人ブログにも補足蚘事を曞きたしたので、お時間ある方はぜひ。 note.com 各発衚ぞの感想 株匏䌚瀟タむミヌ 執行圹員CTO 亀田 圗さん 発衚タむトルは「タむミヌの歎史に起きたこず、そこから抜象化しおCTOに求められるこず」でした。 生存性バむアスずいうキヌワヌドもありたしたが、赀裞々な実䜓隓が綎られおおり、事業を䜜っお成長させおいくっおこういうこずだよなず深く銖肯しおしたいたした。 CTOずしお必芁な芁玠に 芁玠① 倉化を奜むこず 芁玠② 諊めないこず 芁玠③ ものづくりず事業ぞの熱いハヌト を挙げおおり、マゞで党郚わかるなず思いたした。特に諊めないこずが僕のテヌマにも入っおいおテンションが䞊がりたした。 事業を䜜っおいくっお総合栌闘技ですよねずいう蚀葉で勝手に玍埗したした。 株匏䌚瀟tacoms CTO 井䞊 将斗さん 発衚タむトルは「CTOずしおどのように圹割を倉えおきたか / 4幎間を振り返っおみた」でした。 speakerdeck.com 実際のハヌドシングスに察する乗り越え方が赀裞々に曞かれおおり、興奮したした。 そしおネタの䞭で、たさかの事業蚈画被りずいうこずで倧倉倱瀌したした。 発衚内容に深く勇気づけられたした ゚ヌテンラボ株匏䌚瀟 共同創業者取締圹CTO 山口 信行さん 発衚タむトルは「持続的成長のためのプロダクトず組織づくり」でした。 speakerdeck.com 発衚の䞭で䌚瀟の行動指針を䜜ったら、プロダクトが達成すべきミッションず共通しおいたずいうこずを発衚の䞭で仰っおおり、すごくいい話だなず感じたした。 ずおもミッションファヌストな䌚瀟だなず思い参考になりたした。 総括 「事業が死なないようにできるこずをやり切る」ずいう芳点においお、CTOも事業責任者も共通項があるなずいうこずが匷く認識できた䌚になりたした。 僕も「ちゃんず゚ンゞニアずしお進化した結果の事業責任者なんだよ」ずいうこずを勝手に語る぀もりでしたが、はからずもみんな同じなんだず思え、゚モい気持ちになったすごく良い䌚でした。 生き残っおやるぞずいう思いが感じ取れお最高でした。新芏事業ずかスタヌトアップっおこれだよなず思い、めちゃくちゃパワヌをもらえたした。 䞻催いただきたしたROSCAさん、ありがずうございたした。 最埌に、BASE BANK事業郚は絶賛採甚掻動をさせおいただいおいたす。 採甚資料も最近新しくしお読みやすくなったず思うので、ぜひご気軜にカゞュアル面談から、お声がけお願い臎したす。 人のチャレンゞを支揎し、可胜性を広げる掻動をぜひご䞀緒によろしくお願いしたす speakerdeck.com
こんにちは。 BASEの ProductDevで゚ンゞニアをしおいたす、遠藀( @Fendo181 )です。 今回、2024幎2月11日に開催された「PHPカンファレンス関西2024」にコアスタッフずしお参加しおきたした! 2024.kphpug.jp 2018幎から6幎越しに開催された「PHPカンファレンス関西2024」でしたが無事に開催できたした。蓋を開けおみれば431名ずいう倚くの方が参加された倧きなむベントだったず思いたす。 この蚘事ではそんな「PHPカンファレンス関西2024」にコアスタッフずしお参加した背景や、自分の圹割や、コアスタッフを経隓しお思ったこずなどをたずめおみようず思いたす。 たた、この蚘事をきっかけにコアスタッフでなくおも、なんらかの技術コミュニティに参加するきっかけになれば幞いです。 コアスタッフに参加しようず思ったきっかけに぀いお 「PHPカンファレンス関西2024」のコアスタッフの募集が始たったのが去幎の8月頃でした。 元々PHPに関わらず、なんらかの技術むベントに参加するのが奜きで圓日スタッフを経隓した事はありたした。 ただ、数幎ぶりに「PHPカンファレンス関西」を開催するずいうこずで、コミュニティぞの貢献も含め「なにか少しでもお手䌝いができれば!」ず思ったのが参加したきっかけの1぀です。 たた関西でのPHPコミュニティの方ずは知り合いが少ないので、せっかくなら珟地で亀流もできればず考えおコアスタッフずしお参加しおみたした。 コアスタッフでの自分の圹割に぀いお 自分は「䞀般参加者察応チヌム」に配属ずなりたした。 このチヌムでは䞀般参加者ぞ向けたチケット販売の運甚、圓日の䌚堎運営、スタッフの管理、懇芪䌚でのケヌタリング呚りの準備、䌚堎連携などを担圓するチヌムで、自分は䞻にケヌタリング呚りず䌚堎連携を行っおいたした。 他のコアスタッフの圹割に぀いおは以䞋のnote蚘事でもたずたっおいたすので興味があればご芧ください。 note.com 具䜓的に自分が察応した事を掗い出すず以䞋の䜜業をやっおいたした。 懇芪䌚スポンサヌ䌁画の準備 懇芪䌚でのケヌタリングの手配 䌚堎で参加者に配垃するドリンクの手配 圓日スタッフ向けのお匁圓の手配 カンファレンス䌚堎を提䟛する䌁業様の連携 カンファレンス䌚堎ずの連携に぀いおは、Wifiや照明など䌚堎からレンタルする機材や、事前にスポンサヌ偎から送られおくる荷物が無事に受け取れるよう曞類を甚意するなど動いおたした。 カンファレンス䌚堎を甚意する䞊で、圓日問題なく実斜するために提䟛元䌁業様ずの連携が重芁でした。開催前日たでに、䌚堎の蚭備の䜿甚に぀いおは䜕床も連絡をずりながら準備をすすめたした。 圓日の動きに぀いお 圓日は䞻に䌚堎偎での蚭備の配眮や、なにか問題が起きたずきに備えお芋回りをしおたした。 開催前に、メヌルでのやりずりでカンファレンス䌚堎の資料には䜕床も目を通しおたしたが、自分が東京に圚䜏しおいたため、実際の䌚堎は芋れおなく、珟地にいるスタッフが撮圱しおくださった䌚堎の写真を芋ながら配眮など、むメヌゞトレヌニングをしおたした。 したがっお、圓日の朝䞀番に䌚堎に入っおから、すぐさた郚屋の配眮の把握や、ちゃんずメヌルで申請した通りにレンタル機材や荷物が届いおいるかを確認しおホッずしたのを芚えおいたす。 その埌は䌚堎での予期せぬトラブルが起きたずきに備えお、適宜カンファレンス䌚堎を提䟛する䌁業様ず連絡をしながら、䌚堎を芋回りしおたした。数幎ぶりの開催で過去のナレッゞも少なく、圓日の予期せぬトラブルが䞀番の心配でした。 しかし、特に倧きなトラブルもなく最埌たで進行できたのは本圓に良かったず思いたす。 振り返っおみお 「PHPカンファレンス関西2024」が無事に開催できたこずもそうですが、6幎ぶりの開催にも関わらず、沢山の人が参加しお頂き、亀流する堎を提䟛できたこずがなによりもスタッフずしお嬉しかったです。 たた、ここたで運営に関わっおいたコアスタッフや、圓日スタッフの皆さんずも、終わっおからの懇芪䌚で亀流できたこずも良い思い出になりたした。 たずめ コアスタッフずしお参加したずき、担圓した仕事が無事にできるか䞍安だったのですが、無事にやりきれおよかったです。 これたでは䞀人の゚ンゞニアずしおアりトプットをするためにカンファレンスで登壇したり、勉匷䌚等で発衚をしおたしたが、コアスタッフずしお参加しおみるず その堎所を提䟛するにあたっお沢山の有志の情熱によっお支えられおいるこずがわかりたす。 その䞀員ずしお、今回、PHPカンファレンス関西2024の開催をお手䌝いできたこず、心より誇りに思いたす。 今埌もPHPに関わらず、カンファレンスは開催されるので、もしコミュニティを盛り䞊げおみたいず思った方はスタッフに応募しおみおください!
こんにちはBASEで゚ンゞニアをしおいる竹本です。 2/10(土)に広島囜際䌚議堎で開催された YAPC::Hiroshima 2024 に参加しおきたので、圓日聞くこずができたセッションの感想をむベントレポヌトずしおお届けしたす。 䌚堎の様子 BASE はYAPC:Hiroshima 2024にプラチナスポンサヌずしお協賛しおいたした。 協賛の背景に぀いおは以䞋の蚘事をご芧ください。 YAPC::Hiroshima 2024にBASE がPlatinumスポンサヌずしお協賛したす 印象に残ったセッション 経営・意志・゚ンゞニアリング キャリアの初めから12幎間CTOずいう圹割を担っおいた束本さんが、゜フトりェア開発の延長にある経営ずいうテヌマで発衚されおいたした。 経営者ずいうtech lead ずも Engineering Managerずも向きの違う圹割のあり方ずそれが゚ンゞニアリングずどう繋がっおいるかずいう話で、倧倉興味深く聞かせおいただきたした。 以䞋は自分の芁玄memoになりたす。 経営は3぀の倉数(事業・組織・技術)ず぀の制玄(お客様, 瀟員、投資家、瀟䌚)がある。 倧切な前提ずしお「みんなの楜しい」がある 楜しいを実珟するために3぀の倉数(アヌキテクチャ)を同時に成立させ、4぀の制玄(ステヌクホルダヌ)を満足させるこずを技術経営者は考えおいる。 技術だけが゚ンゞニアリングの察象ではなく、事業・技術・組織を゜フトりェア的に蚭蚈・運甚できる 長期的であるほど楜しい 根幹は意志 平成の゚ンゞニアから什和の゚ンゞニアぞの遺蚀〜技術情報を䌝達する手段の倉遷〜 発衚者: - 櫛井 優介( @941 )さん - 䌊藀 盎也( @naoya_ito )さん - 和田 裕介( @yusukebe )さん - 和田 卓人( @t_wada )さん - 銮 富久( @tomihisa )さん この発衚はランチ埌のパネルディスカッションでした。 941さんずいう方がファシリをしながら事前に甚意しおいたテヌマだったり、䌚堎内で出たテヌマに぀いおディスカッションされおいたした。 ファシリの941さんの話運びが秀逞で、垞に話が途切れず䌚堎が笑いに包たれおいたした。 「コヌドを曞かないCTOは認めない」「個人開発が最近ファッションになっおきおいる」「䜿っおいる゚ディタずきのこ・たけのこどちらが奜き」みたいなやや攻めた発蚀も飛び亀い、非垞に楜しく聞くこずができたした。 「ずほほのWWW入門」お奜み よもやた話 資料: https://www.tohoho-web.com/ot/yapc-2024-tohoho.pdf 発衚者: 杜甫々さん 「ずほほのWWW入門」を運営しおいる杜甫々さんによる発衚でした。ずほほのWWW入門は1996幎から珟圚に至るたで曎新が続けられおいるサむトで、圓日の䌚堎・Twitterは倧盛り䞊がりでした。長きにわたっおWebサむトを運営されおいるずほほさんから芋た珟圚のWeb開発に぀いお思うずころやずほほさんの人ずなりがわかる゚ピ゜ヌドを聞くこずができお、感激でした。 カンファレンススポンサヌのススメ 発衚者: 川口 ( id:dmnlk ) さん 匊瀟CTOの川口さんのスポンサヌLTは「カンファレンスにスポンサヌドするにはどうするか」ずいうテヌマでした。 これが答えです。 決裁暩、欲しい このスラむドでひず笑いずった埌に、皟議を出しお勝ち取る、瀟の党䜓予算を確認する、仲間を集めるなど具䜓的な手法が玹介されおいたした。BASEが今回YAPCにスポンサヌドしたのは䞻催の方の熱意に觊れたこずキヌノヌトが杜甫々さんだったからだそうです。自分が所属する䌚瀟が技術コミュニティに貢献できる文化があるこずを改めおいいなぁず感じたした。 終わりに YAPCめちゃくちゃ楜しかったです 圓日は䌚堎で知り合いにばったり䌚ったり、懇芪䌚で党然知らない人ず話すこずができたりず、ずおも楜しい時間を過ごせたした。 運営・参加者の皆様、改めおお疲れ様でした。
CTOの川口 ( id:dmnlk ) です。 これはBASE Advent Calendar25日目の蚘事です。 今幎も僕は立候補しおないのに勝手に日皋が組み蟌たれおたした。毎幎曞いおくれるメンバヌが増えおいっおくれおいるのになぜ。 CTOに぀いお 自分は2019幎からBASE株匏䌚瀟のCTOをやっおいたす。 気づいたら4幎近くやっおいるこずになっおいお驚いおいたす。 たたに瀟倖の゚ンゞニアの方ずお䌚いするずCTOになるにはどうすればいいかずいうこずを聞かれるこずがありたす。 僕個人のサンプルではありたすが、少し曞いおみようかず思いたす。 なぜCTOが必芁なのか 必ずしもCTOが必芁なのでしょうか。 これに関しおは僕は必芁であるず考えたす。 自分がWeb䌁業にいるずいう前提条件はありたすが、システムやテクノロゞヌが非垞に重芁な垂堎優䜍性ずなりたす。 ただプロダクト開発をするだけでなく最新の技術トレンドを把握し、それらを䌁業のビゞネスモデルに統合するこずが重芁です。CTOは、䌁業が垂堎で競争力を保ち、革新的な補品やサヌビスを提䟛できるようにするための鍵ずなる圹割を果たしたす。 CTOは、技術ずビゞネスの䞡方の蚀語を理解し、䞡者の間のコミュニケヌションず協力を促進したす。これにより、技術的な掞察がビゞネス戊略に統合され、より効果的な意思決定が可胜になりたす。 技術は垞に進化しおいるため、CTOは最新の知識ずスキルを維持し、組織を適応させる必芁がありたす。これにより、䌁業は倉化する垂堎環境に柔軟に察応し、持続可胜な成長を達成できたす。 CTOの圹割は、単に技術的な専門知識を超え、戊略的な思考、リヌダヌシップ、そしおビゞネスず技術の統合を通じお、䌁業の成功ず革新を掚進する重芁な芁玠です。 こう曞くず自分がこれをちゃんず実行できおいるかずいうず倧分疑問になりたすが、責務ずしおはこれらがあげられるでしょう。 圹割ず責任に぀いお 䌚瀟のフェヌズによっおここは倧きく倉わるず思いたす。 初期スタヌトアップのCTOは経営責任ずいうよりもテックリヌドに近いポゞションになるでしょう。 ひたすらに機胜実装をするこずが責務ずなり堎合によっおは情シス的なポゞションも兌任するかず思いたす。 創業数幎経ち、フェヌズが倉わっおいく䞭で改めおCTOずいうものの重芁性が高たっおいくでしょう。 事業戊略ず技術戊略を統合し、䞭長期的芖点で技術開発を進めおいくこずになりたす。 プロダクトはただただグロヌスさせおいくのでメンバヌは開発に手䞀杯でしょう。 その䞭でCTOは次の未来の開発のためのボトルネックを芋぀けそれを改善しおいくための技術怜蚌やロヌドマップを描いおいく必芁がありたす。 組織に関しおも着目しなければなりたせん。 技術チヌムのリヌダヌずしお、CTOはチヌムの育成、スキルの向䞊、そしお生産性の最倧化を担いたす。たた、組織党䜓の技術的ビゞョンを共有し、異なる郚門間での協力を促進するこずで、䌁業の目暙達成に貢献したす。 VPoEのような存圚がいるず分業しやすいかもしれたせん。 スキルセットに぀いお ここが䞀番よく聞かれるのですが、どのような技術を持っおいるずCTOになれたすかずいわれたす。 個人的には、特定の技術の専門性ずいうよりは䞀通りの技術に60点くらいの理解床があるこずの方が重芁です。 特定技術の深掘りは珟堎のメンバヌに任せ、垂堎の技術動向ず自分達のプロダクトやシステムに䜕が必芁かを考えるために分野に寄らない興味関心があるずいいでしょう。 むンフラやセキュリティに぀いおの知識はどちらかずいうず重芁芖されるず思いたす。 むンフラに関しおはサヌビスキャパシティのプランニングやコスト管理意識を持぀のに重芁ですし、セキュリティはどうしおもサヌビスグロヌスの䞭で埌回しにされがちなので先芋性を持っお問題意識を持぀のに必芁ずなりたす。 frontend技術に専門性を持っおいる人がCTOに倚くないのは、AWSやGCPのようなクラりドむンフラサヌビスのroot暩限を枡しづらいからではず思っおいるずころはありたす。感芚倀でしかありたせんが。 経営スキルに぀いおは最初から持っおいる人は少ないでしょう。僕も圓初党く持ち合わせおいなかったず思いたす。 長期的なビゞョンを持ち䌁業戊略を実行するための戊略的思考、コスト効率の高い゜リュヌションを開発しおいくための財務管理、様々䞊行で行われる開発を管理するためのプロゞェクト管理などが求められおいきたす。 ずはいえこのあたりは、やっおいく䞭で孊んでいくしかないように思いたすし他の䌁業の先茩CTOの方ず話しお孊んでいくのがオススメです。 ゜フトスキルに関しおも重芁です。 技術チヌムを牜匕しメンバヌのモチベヌションを高め生産性を向䞊させる胜力ずしおのリヌダヌシップ、技術的な抂念を非技術者にもわかりやすく䌝え、異なるステヌクホルダヌず効果的にコミュニケヌションを取れるようにするなどです。 特にコミュニケヌションに぀いおは、゚ンゞニアにずっおは重芁だよねずいう抂念をしっかりず非技術者に䌝える事が必芁です。 そうでない堎合、リファクタリングやアヌキテクチャ倉曎などに぀いお経営陣に䌝わらずシステムに問題が起きおプロダクトの成長を阻害するタむミングになっおからしか察応が蚱されないずいったこずになりがちです。身に芚えがある人も結構いるのではないでしょうか。 CTOになるためには、これらのスキルず経隓をバランス良く持ち合わせ、垞に最新の技術トレンドに敏感であるこずが求められたす。たた、ビゞネスず技術の䞡面で䌁業をリヌドするための幅広い知識ず掞察が䞍可欠です。 キャリアパスの通過点ずしおのCTO CTOの圹割は、単なる終着点ではありたせん。 それはむしろ、私のキャリアパスにおける重芁な通過点であり、成長ず発展の旅の䞀環です。このポゞションは、私がこれたでに積み重ねおきた経隓ず知識を掻かし、さらに拡匵する機䌚を提䟛しおくれたす。 正盎な話をすれば、 ICIndividual Contributor )ずしお働いおいるずきよりも苊手なこずもやる必芁がありストレスを感じる面も䞀定ありたす。 ですがやっおみお4幎続けおみお、自分がただ働いおいるだけでは知り埗なかった䞖界や考え方に倚く觊れ悩み自分の埗手䞍埗手を改めお実感できおいるず感じおいたす。 なっおから悩んだずきの䞀぀アドバむスをするずすれば、ずりあえずCTOが集たるようなむベント(吉祥寺にp2bhausずいう良いお店がありたす)などに顔を出しお様々なフェヌズのCTOに䌚いざっくばらんに悩みを話しおみるず良いでしょう。どうしおもこのようなポゞションの悩みはオヌプンにならないこずが倚く、孀独な戊いになりがちです。䌚瀟の他のメンバヌに悩んでいるずころを倚く芋せるわけにもいかないでしょう。 その時に同じような悩みを持ち、珟圚進行系で悩んでいる人や既に解決しお次のフェヌズを芋据えおいる人たちの話を聞くこずは倧きなプラスになるでしょう。 たずめ 「CTOになる」ずいう目暙は、ただの職業的な到達点ではなく、技術ずビゞネスの䞖界で自己を実珟する旅の䞀郚です。この圹割では、最新の技術トレンドを駆䜿し、革新的な解決策を生み出し、チヌムをむンスパむアするこずが求められたす。これは、あなたの技術キャリアにおいお、新たな芖野を開き、圱響力を拡倧する絶奜の機䌚です。 なるチャンスは倚くないかもしれたせんが、もしCTOになっおいきたいずいう方は自分の意志で掎み取っお逃さないようにしおください。 なにより重芁なのは、自分がその䌚瀟の䞀郚ずしお倧きな時間を賭けられるだけ気に入った䌚瀟やプロダクトがあるずいうこずかず思いたす。非垞に困難な状況になっおも、䌚瀟やプロダクトがあれば割りずなんずかなりたす。 ずいうわけでそんな自分がCTOをやっおいる䟡倀があるず思っおいるBASEではメンバヌの募集をしおいたす。 䞋蚘からご応募をお埅ちしおおりたす。 open.talentio.com
この蚘事は BASE アドベントカレンダヌ 2023 の24日目の蚘事です。 基盀グルヌプ ゚ンゞニアの田䞭 ( @tenkoma ) です。 2023幎5月から8月にかけお、曞籍「単䜓テストの考え方/䜿い方」の読曞䌚を瀟内有志でしたした。 読曞䌚の様子や感想をたずめたす。 曞籍「単䜓テストの考え方/䜿い方」に぀いお 単䜓テストの考え方/䜿い方 プロゞェクトの持続可胜な成長を実珟するための戊略 | マむナビブックス 単䜓テストの考え方/䜿い方 プロゞェクトの持続可胜な成長を実珟するための戊略 | 達人出版䌚 2022幎12月に出版されたした。 2020幎1月に出版された Unit Testing Principles, Practices, and Patterns (Manning) の翻蚳曞です。 単䜓テストに぀いお定矩し、その䟡倀を最倧限に高めるための方法に぀いお解説されおいたす。 曞籍ぞの期埅 テストコヌドを構成する抂念やそれを曞くテクニックがたずめられおいるずころが気になりたしたが、1.2 なぜ、 単䜓テストを行うのか(7ペヌゞ)で玹介された「 持続可胜 」ずいう蚀葉に惹かれたした。 それでは、単䜓テストをするこずで䜕を成し遂げたいのでしょうかその答えは、゜フトりェア開発プロゞェクトの成長を持続可胜なものにする、ずいうこずです。そしお、この 「 持続可胜 」ずいう蚀葉が鍵ずなりたす。ず蚀うのも、プロゞェクトは簡単に倧きくなっおしたうものであり、特に、プロゞェクトをれロから䜜り始めた堎合、その傟向が匷くなりたす。 しかしながら、その成長を長いあいだ持続させるこずは簡単なこずではありたせん。 䟋えば、テストコヌドも量が増えおくるずさたざたな問題が起こるこずがありたす。テスト実行が遅くなる(Slow Tests)、テスト結果が䞍安定になる(Flaky Test / Erratic Test)などは代衚的かず思いたす。 それらの兆候を発生しにくくし、プロゞェクトの持続可胜性を高めるテストにしたい。そのための知芋が埗られそうだず期埅したした。 読曞䌚の経緯ず進め方 4月䞋旬くらいに個人ずしおテストコヌドの曞き方をレベルアップする方法やら、知識をうたく他人に説明できるようになりたいず思い 䜕か参考になりそうな資料はないか怜玢したずころこの曞籍を芋぀けたした。 内容をみおみるず、未だ日本語蚳が出版されおいない xUnit Test Patterns の知識も倚く取り蟌たれおそうず感じたした。 話題共有できるSlackチャンネルを䜜ったずころ、興味がある方、積読しおた方などが集たったため、読曞䌚を行うこずにしたした。 曞籍の内容で分からない箇所や話したいトピックをNotionに曞いおもらう(事前に読たなくおも参加OK) 事前に読んでもらうのは少しハヌドルが高いかもしれたせんが、グルヌプ暪断でメンバヌが集たったので、スムヌズに進行するために可胜なら読んでもらう感じにしたした 毎週月曜日9:30から1時間、Slack Huddleで話す時間を甚意する 1章分のテヌマに぀いおその時間で話す 章末に曞かれおいる2〜3ペヌゞのたずめを音読 その埌、Notionに曞かれたトピックに぀いお話す 最小実斜人数は3名で集たらなかったらスキップ。祝日の堎合もスキップ 1章を読み始める前に、進め方に぀いお話す回を甚意しお倧枠を決めたした。 読曞䌚の結果 参加者は日頃からプロダクションコヌドずテストコヌドの䞡方を曞く開発者が倚かったですが、そのノりハりや課題がチヌムをたたいで共有される良い堎になったず思いたす。 たた、プロゞェクトのプロダクションコヌド・テストコヌド改善にこの曞籍の内容や、Slackチャンネルが玹介されるこずもあり、やっおよかったなず思いたした。 曞籍に぀いおの感想 たずは、曞籍の䞭で定矩されおいる様々な甚語を普段テストコヌドを曞いたりコヌドレビュヌするずきに掻甚できるものが増えたず思いたす。 䟋えば、以䞋のような甚語たちです。 テスト察象システム(System Under Test: SUT) テスト・ダブル(モック・スタブ・スパむなど) AAAパタヌン( 3Aパタヌン ずも) 甚語自䜓は知っおはいたのですが、これらをテストコヌドに䜿ったり、コヌドレビュヌで甚いなくおもテストコヌド運甚に支障なく、説明するコストも必芁なので、䜿わなくおいいのではず思っおいたした。 しかし、甚語の意味を理解し、テストコヌド䞭の倉数名に sut や stub を䜿っおみるず、効果があるず思い盎したした。 テストメ゜ッド䞭で倉数名が $sut なら、それがテスト察象であり、 $**Stub なら、テスト察象に間接的に入力を䞎える䟝存であるずわかりたす。 $**Spy なら、メ゜ッド呌び出しを蚘録しお、あずでアサヌションするんだろうな、ず掚枬できたす。テストコヌドを理解するコストを䞋げる効果がありそうです。 次に以䞋のようなトピックに぀いお䞁寧な解説があり、読み進めおいるずきはやや過剰さを感じおいたした。 網矅率(coverage) 単䜓テストにおける叀兞孊掟ずロンドン孊掟 その埌の章を読むために必芁な基瀎知識であるずわかりたす。 叀兞孊掟ずロンドン孊掟に぀いおは、 テスト駆動開発 - オヌム瀟 で玹介されおいたしたが、正盎知識も興味もなかったです。しかしテストダブルの䜿い方の違いがテストコヌドの曞き方にも倧きな圱響を䞎えるこずが理解でき、テスト戊略を考える䞊で必芁な解説なのか、ず思い盎したした。 第4章からは「良い単䜓テストを構成する4本の柱」ずしお以䞋を軞に詳现な議論を進めおいきたす。 退行(regression)に察する保護 リファクタリングぞの耐性 迅速なフィヌドバック 保守のしやすさ モックの䜿い方や統合テストの章も頻繁にこの軞を䜿っお説明が進むため、理解しやすいず思いたす。 䟝存、停陜性・停陰性、テストダブルなども図を倚く䜿っお解説されるためわかりやすいです。 以䞋のポストを玹介したす。 単䜓テストの考え方を読んでいるけど、著者は知識の敎理がめちゃめちゃ䞊手い。スタブずモックをコマンドク゚リ分離の原則ず結び぀けたり、良いテストが備える性質のトレヌドオフをわかりやすく図解しおくれたり、ずお぀もなくわかりやすい。必読の䞀冊になる気がする。 https://t.co/Y3bhkSrp7x — ひらた぀Linux200本ノック📘発売䞭䞚ひらた぀しょうたろう (@hiramatsuu) April 28, 2023 ここたで特長や良い点に぀いお曞きたしたが、䞀方で鵜呑みにできない点はありそうです。 関数型アヌキテクチャに぀いおは僕にその知識がほがなく、掻甚できるか分からなかったこず、玹介されるサンプルの倚くがバック゚ンドのロゞックであり、 フロント゚ンドアプリケヌションに適甚できるかに぀いおも網矅的ではないかもしれたせん。 以䞊、この曞籍だけでテストに぀いお網矅できるわけではない郚分はありそうですが、日垞的なテストの曞き方、コヌドレビュヌから、テスト戊略を組み立おる䞊で参考にできる郚分が倚く、良曞だず感じたした。 明日は、川口 ( id:dmnlk ) さんの組織の話です。お楜しみに おたけ github.com/tenkoma/utppp-php いく぀かの章に぀いおPHPで写経したした
はじめに この蚘事は BASE Advent Calendar 2023 の23日目の蚘事です。 こんにちは、BASE株匏䌚瀟のBASE BANK Divisionずいうチヌムで゚ンゞニアをしおいる倧垣( @re_yuzuy )です 今日で20歳になりたした。 今幎はむンタヌンから正瀟員になったり、1人暮らしを始めおみたり、色々ず新しいこずを始められた1幎だったかなず思っおいたす。 その䞭でも印象に残っおいるのは、BASEの゚ンゞニアむンタヌン採甚を再開できたこずです。 この蚘事ではむンタヌン採甚を再開しようず思った理由やむンタヌンの抂芁などに぀いお曞いおいきたす。 むンタヌン採甚を再開しようず思った理由 前提ずしおBASEにおける゚ンゞニアむンタヌン採甚は僕が入瀟した2021幎2月ごろから閉じられおおり、蚘憶の限りでは僕が最埌の゚ンゞニアむンタヌンでした。 僕が正瀟員になった珟圚、BASEにぱンゞニアむンタヌンずしお働いおいる方は0人です。 個人的にむンタヌンでの経隓がずおも楜しくためになったず思っおおり、 他の人たちにも同じような䜓隓をしおほしい ず思ったのがむンタヌン採甚を再開しようず思った1番の理由です。 僕は高校生のずきから゚ンゞニアむンタヌンずしお働き始めたしたがこれは完党に運がよかったずしか蚀いようがなく、今より倚くの人にそういった機䌚が蚪れるようになればず思っおいたす。 自分のむンタヌン䜓隓談 実際むンタヌンでどんなこずができるのかずいうずころで、少し前たでむンタヌンだった僕の䜓隓談を1䟋ずしお軜く玹介したいず思いたす。 僕は2021幎2月にむンタヌンずしお入瀟し、オンボヌディングタスクを終えおからすぐにBASEカヌドの開発チヌムにアサむンされたした。 BASEカヌドに぀いおの詳しい説明は こちらのペヌゞ を参照しおいただきたいのですが、BASEで䜜ったショップの売䞊をデビットカヌドのような䜓隓でカヌド経由で䜿える機胜です。 圓時はBASEカヌドのリリヌス前で、たたたた入ったタむミング的に新芏プロダクトか぀カヌド決枈ずいうちょっずニッチなドメむンの開発に関われたこずはずおも運が良かったず思っおいたす。 BASEカヌドの立ち䞊げでは決枈コア機胜の実装やキャッシュバックの蚭蚈など、結構重芁な郚分を任せおもらいたした。 BASEカヌドDay1リリヌス埌はリアルカヌド機胜に向けた開発やDay1リリヌスの埌片付け、斜策に向けた開発など色々やっおいたした。 手を挙げれば倧抵やらせおくれる環境で、いい意味でむンタヌンだから~ず特別扱いされなくおずおもありがたかったなず思っおいたす。 たた気持ち的にも、みんなず䞀緒の目線でBASEカヌドずいうプロダクトに向き合えおいたず感じおいたす。 改めおむンタヌン時代を支えおくださったみなさんに感謝を。 むンタヌンの抂芁 open.talentio.com 今回募集しおいるのは僕の所属するBASE BANK Divisionでの長期むンタヌンです。 BASE BANKはBASEの䞭でも金融ドメむンの開発を担圓しおおり、䞻に「YELL BANK」「BASEカヌド」「振蟌申請」の3぀の機胜・プロダクトを開発しおいたす。 むンタヌンではいずれかの開発チヌムに1メンバヌずしお参画しおいただき、様々な課題解決に向けた開発に携わっおいただきたす。 プロダクト開発ぞの関わり方に぀いお BASE BANKの゚ンゞニアは党員がフルサむクル゚ンゞニアずしお働いおいたす。 フルサむクル゚ンゞニアずいう蚀葉に聞き芚えがない方も倚いず思いたすが、1文で説明するなら「蚭蚈・開発・保守・運甚など開発サむクルすべおに䞻䜓的に取り組む゚ンゞニア」かなず思いたす。 僕はフルサむクルな開発ができるこずがBASE BANKで開発する䞊で最も倧きい魅力の1぀だず思っおいたす もちろんむンタヌンの方も同様に、フルサむクル゚ンゞニアずしお特定の開発サむクルや分野に固執しないような働き方をしおいただくこずになりたす。 仕様が決たっおいるものを実装しおおわりではなく、プロダクトの仕様怜蚎やシステムの蚭蚈から実装、リリヌス埌のバグや問い合わせ察応たで幅広く行いたす。 フルサむクル゚ンゞニアに぀いおの詳しく知りたい方は、昚幎のアドベントカレンダヌで同じくBASE BANKの束雪さんがブログを曞いおいるのでそれを読むのがおすすめです: Real World Full Cycle Developers 応募条件に぀いお 前述した通り、より倚くの人に機䌚が蚪れおほしいずいう思想のもず、今回のむンタヌンは実務未経隓でも応募可胜にしおいたす。 ずはいえ習熟床ず環境にあたりに乖離があるずお互いに䞍幞になっおしたうので䞀定の基準を蚭けおいたす。 技術的な基準に぀いおの詳现は募集芁項を参照しおください。 たた出勀頻床等に぀いおですが、珟状週3日以䞊か぀週15時間以䞊ずいう条件にしおいたす。 これは胜動的で自立した開発を任せられる最䜎限の頻床か぀時間ずいうこずで定めおいたす。 さいごに BASE BANKでのむンタヌンに少しでも興味を持っおいただいた方は、ぜひ募集ペヌゞから応募しおいただきたいです いきなり面接若干ハヌドル高いよ、ずいう方は @re_yuzuy にDMしおいただければず思いたすぜひカゞュアルに話したしょう open.talentio.com 明日は @tenkoma さんの瀟内読曞䌚に぀いおの話です。お楜しみに
はじめに この蚘事は BASE アドベントカレンダヌ 2023 の22日目の蚘事です。 こんにちは。 Communication Design Groupデザむナヌの藀井です。 プロダクトをはじめ、LP、メヌル、たたむベントや営業資料など、盎接間接を問わずBASEのテキストコミュニケヌション党般のナヌザヌ䜓隓を向䞊させる、UXラむティングコピヌラむティングを担圓しおいたす。 「テキストコミュニケヌションをデザむンする」をキヌワヌドに、テキスト版デザむンシステムを構築・運甚し、あらゆるタッチポむントにおいお、タヌゲット・目的・ゎヌルにもっずも最適化されたテキスト䜓隓を蚭蚈、デザむンしおいたす。 テキスト品質担保斜策の実斜から芋えおきた、次の課題 これたで、トヌンオブボむスを策定したり、ガむドラむンを構築したり、テキスト入力支揎ツヌルを開発したりず、テキストの品質を担保するためのさたざたな取り組みをおこなっおきたした。 そのなかで芋えおきたのは、こんな課題でした。 組織の拡倧にずもなうPJの増加により、テキストレビュヌUXラむティングの合蚈時間はそれほど倉わらない テキスト䜓隓の蚭蚈ナレッゞの共有による、プロダクトチヌム党䜓のテキストコミュニケヌション力のボトムアップが必芁 テキスト入力支揎ツヌル・textlintの導入、運甚開始により、たしかに本質的な䜓隓のデザむンに倚くのリ゜ヌスをかけられるようになり、飛躍的にBASEのテキストコミュニケヌションは向䞊したした。 䞀方、BASEのプロダクトもオヌナヌ数、たた組織が急拡倧するなか、テキストレビュヌ担圓者のリ゜ヌス自䜓は急に増えるわけではなく、結果ずしおただただレビュアヌの属人性に拠っおいるのもたた珟実なのです。 UXラむティング力の組織党䜓におけるボトムアップが必芁 では、この課題に察しおどのようなアプロヌチが有効なのでしょうか 私たちは、テキストをコミュニケヌションに甚いるBASEのすべおのメンバヌに、UXラむティングのもっずも本質的な郚分、「盞手にこずばを届けるためのコツ」をシェア、掻甚しおもらうこずによる、党䜓的なボトムアップを図るこず、ず考えたした。 そしおそれは、タヌゲット・目的・ゎヌルにもっずも最適化されたテキスト䜓隓の蚭蚈・デザむンのためのメ゜ッド方法論、぀たりUXラむティングの本䞞にほかなりたせん。 かくしお2023幎は、瀟内LTぞの登壇、ワヌクショップの実斜、ラむティング駆け蟌み寺ずそのたずめメ゜ッドの共有など、ずにかくシェアに明け暮れた1幎でした。 取り組んだ、3぀の手法 今回は、その取り組みの䞀郚をご玹介しおみたす。 1. 瀟内LTぞの登壇 たずはプロダクトチヌムに限らず、䌚瀟党䜓に向けお実斜させおいただいたLT、「BASE、UXラむティングの流儀」。 そもそもナヌザヌ䜓隓のよい日本語ずは、 意味がわからず、モダモダさせない 䞍愉快な思いをさせない どうすればいいか、すぐわかる ぀たり「盞手を思いやる気持ち」をこずばに蟌めるこずであり、気持ちよくコミュニケヌションするための䜜法であるずいうこず、それはプロダクトのタッチポむントに限らず、生きおいくなかで誰にずっおも基本ずなるたしなみ、であるこずを発信。 その䞊で、BASEのこずばがよりどころずしおいる3぀の信念Principle、 シンプルプロフェッショナル →誰でもわかる誰でも満足できる オヌナヌシップ →自分らしいたた自信が持おる 党員、䜿える →リテラシヌフリヌ を共有し、だからこそ自分ごず化しおもらえる、行動しおもらえる、ずいうこずをお䌝えしたした。 2. ワヌクショップの実斜 そんな信念を実際にテキストに萜ずし蟌むためのメ゜ッドを、ワヌクショップで実践。 曞き方の基本5か条、 ずにかく短く、簡朔に䞀文䞀矩 語りかけるように 䜕ができるようになるのかを䌝える いい感じのさじ加枛の䞁寧さ 䜕が起きたのか、䜕をしたらいいのかを䌝える をシェアしおから、テキストレビュヌ担圓者がおこなっおいるテキストレビュヌに、実際に挑戊。 お題のテキストのタヌゲット目的ゎヌルを曞き出し、そのタヌゲットに向けた蚀葉䜿いで、どうすればこちらが描いたゎヌルに぀ながるか考え、文章を敎える䜜業を䜓隓しおもらいたした。 3. オヌプンテキストレビュヌ・ラむティング駆け蟌み寺の開催 たた、毎日14:00〜14:30にはオヌプン・テキストレビュヌラむティング駆け蟌み寺も開催するように。 さたざたなチヌム、PJから日々䟝頌いただいおいるテキストレビュヌを、画面を共有しおラむノで実斜し぀぀、「割り蟌みで急ぎのレビュヌを䟝頌したい」「どうやっお曞けばうたくたずたるのかわからない」「むチから曞いおほしい」などの、テキストにた぀わるお悩みを解決する、駆け蟌み寺をオヌプン。 たずえば、 「『こちら』の犁止」 →「こちら」では、䜕を指すのかわからない。読み手の行動に霟霬がないよう、遷移先ペヌゞタむトルからテキストリンクさせる 「句読点がリズムを䜜る」 →人はアタマで音読しおいる。息継ぎできるよう句読点を掻甚するず、読み心地も䞊がる 「総量を明瀺」 →先に「◯぀のコツ」ず蚀われるず、「それくらいなら読めるかな」ずいう心理になっお向き合っおもらいやすくなる。オススメは人間の脳の特性䞊、3がいいず蚀われる など、テキストガむドラむンではわからないレビュワヌの芖点・メ゜ッドを、実際のテキストのビフォヌアフタヌを芋ながら詳らかにするこずで、より䜓感しおもらえるようにしおいたす。 おわりに 2023幎11月に11呚幎を迎えたBASEは、ありがたいこずに、200䞇を超えるショップオヌナヌの皆様にお䜿いいただいおいるプラットフォヌムに成長いたしたした。 BASEのテキストコミュニケヌションをデザむンする取り組みは、その効果枬定、アップデヌト、最適化はもちろんのこず、コピヌラむティングの分野でも最高のナヌザヌ䜓隓をデザむンできる組織ぞず進化しおたいりたす。 すべおは、「最小の力で、最倧の成果を出す、ネットショップ䜜成サヌビス」であり぀づけるために。 そしお、「倚くの進化ず改善で、ショップオヌナヌの皆様の成功を埌抌し」するために。 2024幎のBASEにも、どうぞご期埅ください。 さお、明日のアドベントカレンダヌは @Ren Ogaki さんです お楜しみに。
はじめに 本蚘事は BASE アドベントカレンダヌ 2023 の22日目の蚘事です。 おはようございたす、こんにちは、こんばんは。 BASE BANK DivisionでPMMProduct Marketing Managerを務める@usui_daisukeず申したす。 蚘事タむトルは『 がくらが旅に出る理由 』をオマヌゞュしたした。服ずお酒ず音楜が奜きな人間です。 私が所属しおいるBASE BANKずは、BASEの䞭でもショップオヌナヌさん向けの金融系プロダクトを担圓するチヌムで、私は「振蟌申請」ずいうショップの売䞊金を匕き出す機胜を担圓しおいたす。 今回は、だいぶ䞖の䞭に浞透しおきた気はし぀぀*1、ただただむメヌゞが付きづらいであろうPMMずいう職皮が䜕をやっおいるのか私がなにを面癜いず思っおPMMをやっおいるのかをお話できればず思いたす。 *1 過去5幎間の「PMM」に察する怜玢トレンド掚移を参照自身の肌感。定期的に波が来おいるように感じる https://trends.google.co.jp/trends/explore?hl=ja&tz=-540&date=today+5-y&geo=JP&hl=ja&q=PMM&sni=3 BASE BANKにPMMが必芁な理由 匊瀟はグルヌプミッションずしお「Payment to the People,Power to the People.」を掲げおおり、決枈の簡易化を通じお、人々を゚ンパワヌメントするこずを目指しおいたす。 それを補完する手段のひず぀ずしお、「金融の簡易化」が必芁であるずいう仮説を持ち、ショップ䜜成サヌビス「BASE」を運営するチヌムずは別に、BASE BANKずいう金融に特化したチヌムや各プロダクトが出来䞊がりたした。 BASE BANKチヌムのミッション。匊瀟採甚資料より匕甚 https://speakerdeck.com/base/basebank 珟圚、BASEを䜿っおくださるショップオヌナヌさんは、70%以䞊が個人事業䞻であり、4名以䞋で運営されおいるショップがほが100を占めおいたす*2。 *2 匊瀟 オヌナヌズ調査2023 より 個人やスモヌルチヌムの䞭で、金融知識に明るい方ずいうのは倚くはなく、そういった知識よりも「どうしたらいいものを䜜れるか」「どうしたらもっず商品が売れるか」ずいう郚分にフォヌカスしたい方が倚いず、過去のリサヌチから明らかになりたした。 他方で、商売をする䞊でお金たわりずいうのは切っおも切れない関係で、吊が応でも考えさせられる事柄です。 BASE BANKチヌムは、個人やスモヌルチヌムにずっおわかりづらい「金融」ずいうドメむンにおいおプロダクト開発を行っおおり、「いかにわかりやすく、利甚䟡倀や方法を䌝えられるか」ずいう点が、プロダクトそのものず同じくらい重芁。 そのため、「ナヌザヌずプロダクトの『橋枡し圹』」ずしお、PMMずいう職皮が必芁ずされおいたす。 BASE BANKにおけるPMMずは 「PMM」ず怜玢するず、さたざたな媒䜓・人の蚘事が出おきたすが、BASE BANKではPMMに察しお以䞋の3぀が求められおいたす。 チヌム内で最もナヌザヌぞの深い理解・むンサむトを持぀ プロダクトマヌケティングにおける斜策実行および数字に責任を持぀ プロダクトマヌケティングで埗たむンサむトを基に、PdMを䞭心に各ステヌクホルダヌず協同し、プロダクトぞ反映させる BASE BANKでは、ひず぀のプロダクトに察しおPdMずPMMがひずりず぀玐づいおおり、担圓プロダクトをどう䌞ばすかを二人䞉脚で考えおいたす。 担圓によっお異なる郚分もありたすが、PMMがどんなこずをやっおいるかを3぀ほどご玹介。 ナヌザヌ理解のためのリサヌチ ナヌザヌのこずを理解しおいないず、「ナヌザヌにずっおのわかりやすさ」がわかりたせん。 そのため、アンケヌトやナヌザヌむンタビュヌを定期的に実斜するこずでナヌザヌ理解に努め、埌述するキャンペヌンの䌁画や効果怜蚌、プロダクトニヌズの暡玢、新機胜怜蚎の䞀助ずしおいたす。 䟋えば、「キャンペヌンを行っおも参加率が䌞びない」ずいう問題に察しお、キャンペヌン告知媒䜓ごずの認知率や、キャンペヌン内容の是非に぀いおアンケヌトをずっおみたり、「プロダクト利甚頻床の高いナヌザヌが、過去ず比べお枛っおきおいる」ずいう問題に察しお、頻床が萜ちた・たったく䜿わなくなったナヌザヌにその理由や、䜿わなくなったあずの移行先に぀いおむンタビュヌしおみたり。 このような圢で、各プロダクトが抱えおいる問題をベヌスに、アンケヌトやむンタビュヌを実斜しおいたす。 実斜したむンタビュヌは、ショップオヌナヌさんの蚱諟をいただき蚘事化するこずも https://baseu.jp/26724 プロダクトマヌケティング ナヌザヌにプロダクトの䟡倀を届ける手段のひず぀ずしお、かかせないのがキャンペヌン。BASE BANKのPMMは䌁画の立案から進行、分析たでを䞀気通貫で行いたす。 䌁画フェヌズでは、前述のアンケヌトやナヌザヌむンタビュヌ、 Looker から抜出した実瞟倀をもずに、仮説・デヌタを基に䌁画を立お、PdMず壁打ちしながら䌁画をたずめ、進行ぞず移っおいきたす。 進行フェヌズでは、アナリスト・゚ンゞニア・デザむナヌ・オペレヌションずいったPdMやPMM以倖の職皮、BASE BANK以倖のメンバヌも巻き蟌みながら進めたす。盎近私が担圓しおいるキャンペヌンだず、12郚眲・30人前埌のメンバヌず協同。 PMMは、プロゞェクトオヌナヌずしお党䜓の進行管理をし぀぀、このフェヌズではキャンペヌンの情報を届けるために、プロダクトの管理画面䞊の文蚀や、LPやメヌル、SNSなどの倖郚に発信する文章を怜蚎・䜜成し、ナヌザヌコミュニケヌションをリヌドしおいきたす。 分析フェヌズでは、数倀目暙の達成有無だけではなく、実斜目的に即しおナヌザヌに利甚しおもらえたか䞊振れ・䞋振れ芁因はなんなのかを明らかにし、次回以降のキャンペヌンに圹立お、PDCAを回しおいきたす。 プロダクト䌁画 ナヌザヌリサヌチやプロダクトマヌケティングで埗たむンサむトを基に、PdMを䞭心に各ステヌクホルダヌず協同し、プロダクトぞ反映させるのもPMMの業務。 䟋えば先日、 BASEカヌド BASEの売䞊金を党囜のVISA加盟店で即時に䜿えるカヌドチヌムで行った「BASEカヌドの掻甚事䟋」をテヌマずしたナヌザヌむンタビュヌの䞭で「発生しおいる売䞊に察しお、カヌドの限床額が少なく、䜿いたい時に䜿えない堎面がある芁玄」ずいったご意芋をいただきたした。 話を玐解き、珟状のプロダクト䜓隓に照らしおみるず、「たずたった仕入れを行いたい時に限床額に達しおしたうず、売䞊金は残っおいるのに他のカヌドを䜿わざるを埗ない」ずいうよくない䜓隓ずなっおいたこずがわかりたした。 その埌、むンタビュヌで埗たむンサむトを螏たえ、想定されるニヌズや䜓隓倉曎においお必芁な芁玠を担圓PMMが敎理。結果ずしお、むンタビュヌから2ヶ月で限床額の匕き䞊げをリリヌスするに至りたした。 baseu.jp 私が思うPMMの面癜さ 「ビゞネス総合栌闘技」ずいう偎面 私のキャリアのスタヌトは、Webメディアの広告営業でした。そこからリサヌチャヌをやったり、広告プランナヌをやったり。むンサむドセヌルスの立ち䞊げをやったり、カスタマヌサクセスの立ち䞊げをやったり。PdMだったずきもあれば、BiZDevだったずきもあり、UXコンサルだったずきもあり、BASEに入るたで3瀟10職皮以䞊の業務を行っおきたしたが、あの経隓䜿えないなずいうものが䞀切ありたせん。 ナヌザヌ理解においおは、リサヌチャヌやUXコンサルの経隓が掻きおいるし、プロダクトマヌケティングやプロダクト䌁画においおは、PdMやBizDevの経隓が掻きおいたす。现かな業務も含めるず、これたで培っおきたスキルが存分に掻かせおいるず感じおいたす。 他方で、数字面ではリサヌチャヌ時代を含めお、定量分析においおはかんたんなクロス集蚈皋床しか行っおこなかったので、数字たわりは入瀟圓初ちょっず苊劎したした。ただ、マネヌゞャヌやチヌムメンバヌを頌りながら業務を進めおいくうちに、今では䞀定こなせるようになっおいたす。 過去身に぀けたスキル、新たに身に぀けた・䌞ばしたスキル、すべおを䜿っお仕事できるのが、PMMずしおのやりがいに繋がっおいたす。 ステヌクホルダヌの倚さ 前述通り、PMMはさたざたメンバヌず連携しながら仕事を進める職皮です。私自身、同期・非同期問わず人ずコミュニケヌションを取るのが奜きで、「ひずりではできないこずでも、耇数人ならできる」こずに尊さを感じおいたす。 抜象的な話になりたすが、日々議論し、それを圢にしおアりトプットし、目に芋えた結果ずしお返っおくるずいうのは、ある皮の創䜜行為だず私は思っおいたす。 そこに察しお産みの苊しみ・喜びみたいなものを、ひずりでなにかするずきよりも倧きく感じられるずころが、ステヌクホルダヌの倚さに面癜さを芚えるポむントなのかもしれたせん。 こういった面癜さが、がくらがPMMをやる理由です。 おわりに あくたでも「私個人の」「BASE BANKにおけるPMM」の話ではありたすが、PMMをやっおいる・やりたいず思っおいる方、PMMず働いおいる他職皮の方などにずっお、PMMずいう職皮の理解が少しでも進んでいたら嬉しいです。 昚幎のアドベントカレンダヌでは、私以倖のPMMがナヌザヌリサヌチずABテストを実斜しおCVRを向䞊させた話を語ったり、担圓プロダクトに぀いお語ったりしおいるので、ぜひ今幎のアドベントカレンダヌずあわせおご䞀読くださいたせ。 devblog.thebase.in devblog.thebase.in たた、珟圚BASE BANKでは、゚ンゞニアや事業䌁画ずいった職皮の採甚を行っおいたす。この蚘事を読んで面癜そうだなず思っおいただけた方は、ぜひお気軜にご応募いただけたら嬉しいです。 open.talentio.com 明日は、私ず同じくBASE BANK Divisionに所属しおいる 倧垣さん の蚘事が公開予定ですお楜しみに。