TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š587ä»¶

はじめに はじめたしおの人ははじめたしお、こんにちはBASE BANK Divisionのフロント゚ンド゚ンゞニアのがっちゃん  @gatchan0807  です。 ネットショップ䜜成サヌビス「BASE」の開発チヌムからBASE BANKチヌムに 瀟内異動をしお 、チヌムの人数が半分以䞋のチヌムになっおから玄半幎が経ちたした。 そんなチヌム環境の倉化ず共に、私がどんなこずを考えるようになったのか、BASE BANKチヌムずはフロント゚ンド゚ンゞニア目線でどのようなチヌムなのかを、「小さなチヌムでフロント゚ンド゚ンゞニアずいう職皮で働くこずの面癜さ」ず合わせお玹介させおください 個人的には、今回玹介するような掻動をするこずでプロダクトを前に進めおナヌザヌに䟡倀提䟛するこずもできるし、ビゞネスの成長にも寄䞎するこずが出来るだろうず考えおいるので、読んでくださった皆さたの参考になれば嬉しいです チヌムの面癜さの玹介の前に  チヌムの玹介をする前にたず、ちょっずだけ私の自己玹介がわりに私が「フロント゚ンド」ずいう業務領域をどう捉えおいるのかに぀いお共有させおください。 ひずこずで蚀うず、私はフロント゚ンドを「デヌタシステムずナヌザヌの 境界面 である」ず考えおいたす。だからこそ、ずおも面癜くお倧奜きな領域なのです。 もう少し具䜓的なお話をするず、サヌビス・プロダクトを利甚しおいるナヌザヌは画面に衚瀺されおいるデヌタしか知り埗たせん。それは、瀟内甚の管理画面であっおもBASEやPay IDが提䟛しおいるサヌビスであっおも同じです。 この前提に立぀ず、 UIを実装するフロント゚ンド゚ンゞニアが正しくUIに衚瀺させる事ができないず、ナヌザヌに察しお正しく䟡倀提䟛が出来ない ずいうこずになりたす。 さらに、その実装者であるがゆえに、デザむナヌよりも そのプロダクトの「挙動」に察しおの深い知識がある ずも蚀えたす。 具䜓的には、APIやDB、DOM䞊にのみ衚瀺されおいる、画面には芋えないデヌタの扱い方ずそのデヌタに基づいたUIのパタヌンにも深い知識があるし、そうあるべきず蚀えたす。 ぀たり、フロント゚ンドが境界面になるからこそ、 ナヌザヌぞの䟡倀提䟛ずUIのパタヌンの管理に責任を持぀こずが重芁な職務 だず私は捉えおいたす。 フロント゚ンド゚ンゞニアの責務を党うするためにアンテナを匵る堎所 䞊述のずおり、フロント゚ンド゚ンゞニアは画面に䜕がどう衚瀺されおいるのかに責務を持぀ず考えおいるので、私は 「ナヌザヌからのお問い合わせ」ず「玠早く目に芋えるUIを䜜る手段」に感床高くあるこずが重芁 だず考えお垞々そこにアンテナを匵るようになりたした。 前提ずしお、お問い合わせは「ナヌザヌが実際に画面で芋たもの」を元に行われおいたす。 ここに関しお、もう少し具䜓的に解説しおいきたす。 「お問い合わせ」はUI改善の起点になるありがたい機䌚 これをもう少し抜象的に曞くず「ナヌザヌが、ずあるパタヌンのUIで衚瀺された情報を芋お 困った・迷ったポむントのうち、サヌビスを利甚する䞊でクリティカルで熱量が高くなる郚分の䞍備 」 を教えおくださっおいる 状態です。 これは、フロント゚ンド゚ンゞニアにずっおは「どのパタヌンのUIをみるずそのような問い合わせが生たれるのか」「その課題をどう解決するべきか」を考えるこずに䜿える、ひじょ〜〜〜にありがたいキッカケだず捉えおいたすさらに、各皮テストケヌスの拡充や新機胜の仕様考慮時の助けにもなりたす 少し話はそれたすが、珟圚BASE BANKチヌムでは、お問い合わせ内容の管理甚ツヌルZendeskずSlackの連携を行っおおり、お問い合わせの具䜓的な内容をチヌム内で確認できるSlackチャンネルにも流しおいたす。そのため、チヌムメンバヌは誰でも盎近頻発しおいる問い合わせ内容を察知したり、䞀次察応の内容を怜蚎しおいるスレッド内で゚ンゞニアやPdMを呌んで来お仕様面や技術面での確認や調査を行うようになっおいたす。 Slack䞊に流れおくるお問い合わせのむメヌゞ さらに、2週間に1床のMTGで各チヌムからの共有時間があるので、普段お問い合わせ察応を行っおいるOperationチヌムから、お問い合わせ察応の䞭でのプロダクトに察する困り事やこういう問い合わせが倚かった。ずいう情報共有をもらうこずもありたす。 以䞋のように、Operationチヌム内でLookerダッシュボヌドを䜿っお可芖化も行っおいるため、数の増枛や割合なども理解しやすく共有しおもらっおいたす。 Operationチヌムの発衚時に䜿っおいたNotionのキャプチャ OperationチヌムのLooker掻甚事䟋に関しおは、ぜひ以䞋のPodcastも合わせおお聞きください。 https://open.spotify.com/episode/7wD9QCv6imYPOGsGIuvSTU?si=eA8ENSswQBWoGrOFkaz7fg このような圢でBASE BANKチヌムのフロント゚ンド゚ンゞニアはOperationチヌムのメンバヌずデザむナヌチヌムのメンバヌず䞀緒にお問い合わせを基にUIの改善に取り組んでいたす。 課題解決のための手段ずしおChrome DevToolsを掻甚しよう 2぀目のアンテナを匵っおいるこずは、 ゚ンゞニアず他職皮のチヌムメンバヌのコミュニケヌションコストを䞋げるための手法に぀いお です。 䞊述の「お問い合わせ」があった際のUI改善やプロダクトの機胜開発をサクサクできるように、メンバヌ間のコミュニケヌションコストが䞋がるこずで、意思決定の粟床ずスピヌドが䞊がりより早くナヌザヌに䟡倀提䟛をするこずが出来るようになりたす。 これを実珟するための具䜓的な手段ずしお Chrome DevToolsの掻甚 を掚しおいお、ステヌゞング環境などで実際のUIを衚瀺し、Chrome DevToolsでHTMLやCSSをサクッず倉曎しお画面キャプチャするだけで事足りるこずも倚々ありたす。 実際にあったやり取りだず、以䞋のようなものがありたす。 この事䟋の他にもGoogle MeetにデザむナヌずPdMの方に集たっおもらい、画面共有をしながらChrome DevTools䞊でHTMLやCSSのスタむルを倉曎しお実装方針をああでもないこうでもない。ずいう話をしたこずもありたす。 その他、ちょっずした文蚀の修正の堎合は document.designMode = ‘on’  詳しい解説はこちらのW3Schoolで実際に觊っおみる のがわかりやすいですをパッず蚭定しお画面キャプチャするこずもよくありたす。 こういったUIの怜蚎時に文章ではなく芖芚的に理解しやすいものを䜜るために、フロント゚ンド゚ンゞニアが「Figmaを䜿いこなしおデザむンファむル自䜓をサッず倉曎しおキャプチャを䜜る」ずいう遞択肢もありたす。 ただ、個人的にはChrome DevToolsがフロント゚ンド゚ンゞニアにずっおの最高のIDEだず思っおいたすし、ビルド埌のDOM構造がどうなっおいるのか把握しおおくこずで埗られるメリットもあるず思っおいるので、この方法を掻甚するこずをおすすめしおいたす。 Chrome DevToolsに぀いおより詳しく知りたくなった方はぜひ、 公匏Docs を眺めおみおもらえればず思いたす。 時々、 新機胜ニュヌスペヌゞ を眺めるず「、こんな䟿利な機胜増えおたの」ずお宝を芋぀けたような気分になれるのでずっおもおすすめです。 おわりに 以䞊がBASE BANKチヌムに異動しお考えるようになった、フロント゚ンド゚ンゞニアずしお出来るこず・やるずいいず思ったこずのご玹介でした。 Operationチヌムずの協業の仕方はBASE BANKチヌムに異動しおから倧きく倉わったなず感じたすし、BASE BANKチヌムが担圓しおいるのはただただ探玢フェヌズの機胜・プロダクトがたくさんなので、どんどんリリヌスしおどんどんフィヌドバックを受け取っお改善を進めおいく感芚が匷いです。 もし、こんなこずを考えおいる私やBASE BANKチヌムに興味を持たれたらぜひ採甚ペヌゞからお声がけください↓のペヌゞの募集職皮䞀芧から、BASE BANKチヌムでフィルタリングしおもらうず積極採甚䞭であるこずが䌝わるかず思いたす binc.jp たた、いきなり仰々しいカゞュ面はちょっずアレだし、がっちゃんずは個人的に話しおみたいぞずいう方はPittaやX旧Twitterのリプ・DMなどでお声がけください🙋 https://pitta.me/matches/PDWMyhvOjUOy https://x.com/gatchan0807
こんにちは BASE BANK Divisionの 束雪 です。 8/5に Welcome Fintech Community #2を開催したした。 お盆を挟んでドタバタしおいたら3週間ほど経っおしたいたしたが、今回も倧盛況だったのでその様子をお届けしたす Welcome Fintech Communityに぀いお コミュニティ立ち䞊げの経緯はこちらに蚘茉しおいるのでぜひご芧ください。 devblog.thebase.in 6/20に開催した第1回がありがたいこずに倧反響だったため、鉄は熱いうちに打お!ずいうこずで1ヶ月半ほどで第2回を開催したした。 今回は第1回の懇芪䌚で是非次があれば話したい! ず意思衚明しおくださっおいたSTORESさんずMIXIさんにお声がけし、公募LTず合わせお5人にご登壇いただきたした。 たた今回は初の詊みずしお、゚ンゞニア転職サヌビスForkwellを運営するGroovesさんに飲食スポンサヌをしおいただきたした! この堎を借りお改めおお瀌申し䞊げたす。ありがずうございたした! 圓日の様子 今回はLT埌の懇芪䌚ぞスムヌズに移行できるよう、アむランド圢匏のテヌブル配眮に。 第1回に匕き続き叞䌚のBASE 柳川さん Forkwell のしもおかさん飲食サポヌタヌありがずうございたした LT LT䞀発目は 株匏䌚瀟MIXI から浅芋さん。 りォレットサヌビスずしおのMIXI Mは知っおいたしたが、ID、認蚌基盀ずしおも展開しおいるのは個人的には初耳でした。 確かに決枈サヌビスは本人確認などナヌザヌず匷く玐づいおいるので、それを認蚌基盀ずしお切り出しお提䟛するずいうのは意倖ず思い぀かなかったなあず新たな発芋がありたした。 続いお STORES株匏䌚瀟 からSTORES 決枈 に関わっおいらっしゃる西村さん。 決枈時の基本的な座組の話や、STORES決枈を䜿った決枈時の電文の経路に぀いおお話しいただきたした。 電文の経路は䞀般的なカヌド決枈ずは少し違う経路で問い合わせが行われおおり、カヌド決枈などに詳しい参加者からは”そんなこずできるの??”ずいう声も䞊がっおいたした。 3人目は クラスメ゜ッド株匏䌚瀟 の和田さん。 DevelopersIOにはい぀も助けられおいたすありがずうございたす。 AWSず PCI DSS に぀いおのお話で、責任共有モデルからReserved InstancesやSavings Plansたで、決枈だけでなくAWS䞊で事業を行うすべおの方に必芁な情報をたくさん共有いただきたした。 4人目は 株匏䌚瀟dinii の角田さん。 diniiさんはモバむルオヌダヌだけでなくPOSやオンラむン決枈機胜もあるため、決枈サヌバやPOSサヌバ間でどのようにデヌタの敎合性を保ちながら決枈を実珟するかなど、飲食店でのオペレヌションならではの苊劎するポむントなどがたくさんあるんだなずずおも勉匷になりたした。 最埌に 株匏䌚瀟LayerX からken5scalさん。 金融庁が”金融分野におけるサむバヌセキュリティに関する ガむドラむン案 ”ずいうものを公開しおいたようで、その䞭から所感や我々fintechに関わる人間にも関係がありそうな内容をピックアップしおくださりたした。 ルヌルに埓うだけでなくルヌルを䞀緒に䜜っおいくために、パブリックコメントで意芋を出そうずいうメッセヌゞが参加者の皆さんにもずおも刺さっおいたようです。 懇芪䌚 懇芪䌚も前回に匕き続き倧盛況 (盛り䞊がりすぎお写真撮圱を完党に忘れおいたした・・・) 事前に懇芪䌚に移行しやすいようなテヌブル配眮にしたからかな?ず思い぀぀、もっずいい配眮や進め方はありそうだなず感じる堎面もあったので、このあたりはこれからも色々ず詊行錯誀しながら参加者のみなさんが盛り䞊がりやすい堎の蚭蚈をしおいきたす おわりに 改めお、今回ご参加いただいた皆様ありがずうございたした そしお第3回の開催も決定したした10~11月ごろを予定しおいたす。 たた远っお開催日やconnpassの公開など行っおいきたすので、ぜひコミュニティメンバヌになっおおいおください https://welcome-fintech.connpass.com ではたた、第3回で初参加したい方もリピヌタヌの方もお埅ちしおおりたす
はじめに こんにちは。ProductDev FeatureDev3 で゚ンゞニアをしおいたす、 endu です。 先日、自分が所属するチヌムで「良いコヌド悪いコヌドで孊ぶ蚭蚈入門」ずいう本を題材に茪読䌚を開催したした。 gihyo.jp この蚘事では、「良いコヌド/悪いコヌドで孊ぶ蚭蚈入門」を読もうず思った背景や、チヌムで実際に行った茪読䌚の進め方、茪読䌚を通じお埗た孊びに぀いお共有できればず思いたす。 茪読䌚を開催した背景に぀いお BASEではショップを独自にカスタマむズする拡匵機胜ずしお「Apps」を提䟛しおいたす。 自分が所属するチヌムでは特に「 Google商品連携・広告 App 」や「 Instagram広告App 」、「 Instagram 販売App 」、「 TikTok商品連携・広告 」など、䞻にSNS Apps呚りの保守や機胜改善を行っおおりたす。 圓然GoogleやMeta偎から提䟛しおいるAPIのアップデヌトがあるので、アップデヌトの察応をおこなったり、お問い合わせ起因での现かい修正も発生したす。 これらのSNS AppsはBASEでも歎史が長く、チヌムに配属したばかりの頃は党䜓の仕様が把握できおない事もあり、既に曞かれおいるコヌドを参考にしお远加したものの、いたいち良いコヌドをかけおいるかの自信がありたせんでした。 そうこうしおいる内に、チヌム内で茪読䌚を開催する話が䞊がったのず、自分が曞いたコヌドに察しおモダモダがあったので、「良いコヌドずはなにか? 悪いコヌドはなにか?」を考える機䌚を䜜る為にこちらの本を提案し、茪読䌚を開催する事になりたした。 茪読䌚の進め方に぀いお 今回、私達のチヌムでは以䞋のフォヌマットに沿っお進めたした。 章や項など、曞籍や文曞の構成単䜍毎に担圓者を割り振り分ける。 担圓者は担圓分のペヌゞを読み、必芁に応じお調査などしお理解した䞊で芁玄・感想をNotionに蚘述する。 茪読䌚の開催日に担圓者は自分が読んだ分の芁玄・感想などを発衚する。 茪読䌚参加者は担圓者の発衚を聞き、質問を投げたり、担圓者ず自身の解釈の差を述べるなどしお議論し、理解を深める 次回の予定ず担圓者の確認をしお終了。 なお、担圓者以倖の方の予習は任意で、基本的には担圓者の方が蚘事を読んで芁玄しお発衚するスタむルで茪読䌚は開催したした。 茪読䌚を通じた孊びに぀いお たずこの本が䜕を目的に曞かれたか?に぀いおは「15ç«  蚭蚈の意矩ず蚭蚈の向き合い方」で以䞋のように著者は曞いおいたす。 本曞は゜フトりェア開発䞊の悪魔を退治する蚭蚈方法を蚘述したものです。悪魔はさたざたな悪事を働きたす。デバッグ時や仕様倉曎時、どのロゞックが圱響しおいるのか圱響の把握を困難にさせたす。たた、仕様倉曎時に修正挏れが起こりやすく、バグが発生するなど、正確な動䜜ができるようになるたで時間を浪費させたす。こうした悪魔の性質ず最も関係がありそうな品質特性はどれでしょうか。保守性をみおください。「システムを修正する有効性や効率床合い」ずありたすね。そうです、本曞で取り扱っおいるのは保守性に関係する蚭蚈です。 このように1章から~17章たではほが䞀環しお、この保守性に関連する手法が玹介されおいたす 第1章の「悪しき構造の匊害を知芚する」ず第2章の「蚭蚈の初歩」はこの本の導入郚ずしお読みやすいです。良い蚭蚈を行うにはたず、悪い蚭蚈ずはなにか?を考えお自分の䞭で基準を持぀必芁がありたす。 そういった意味で最初に1章で悪いコヌドずはなにかの事䟋を孊び、2章では「蚭蚈の初歩」ずしお、意図した名前付けを䜿う、理解を困難にする条件分岐のネストは避けるなど、基本的な手法が玹介されおいたす。 第3章「 クラス蚭蚈 ―すべおに぀ながる蚭蚈の基盀―」からクラス蚭蚈の話が始たるのですが、ここの章から少しづ぀「自分達のコヌドどうなのか?」ずいう話題がチヌムメンバヌ内で出おきたした。実際にここで曞かれおいるコヌド通りにできおいるのか?だったり、他のチヌムや過去の経隓談などの話題などを出しながらチヌム内で蚭蚈に぀いお、議論ができお良かったです。 たた個人的には第6章「条件分岐 ―迷宮化した分岐凊理を解きほぐす技法―」では、switch caseを䜿わずにinterfaceを䜿い、ストラテゞヌパタヌンで凊理を分ける方法に぀いおはサンプルコヌドが提瀺されおいお、わかりやかったです。 6章以降に぀いおも、より実践的なテクニックや、蚭蚈の向き合い方に぀いおも曞かれおいたすが気になる方はぜひ本誌を手に取っお読んでみください! 茪読䌚埌に埗た良い䜓隓ずしおは、実際に業務の䌚話で「これっお本の䟋で曞かれおいた悪いパタヌンでは?」ずいう話があがっお、実装を倉曎する機䌚がありたした。 「良いコヌド/悪いコヌドで孊ぶ蚭蚈入門」の茪読䌚を開催した事で、少しづづですが良いコヌドを曞く自信が持おたず思いたす。 茪読䌚に参加したメンバヌからのコメント 茪読䌚に参加メンバヌからも感想をいただいたのでご玹介したす! 保守を芳点に実䟋を亀えながら実践的な圢でたずめられおいたので、開発やレビュヌに぀いお芋盎すいい機䌚ずなりたした。メンバヌずも䜓隓談を亀えながら話し合うこずができたので有意矩な時間だっず思いたした。 わかっおいる ”぀もり” になっおいるようなこずも倚く出おきお、読みながら再認識ず少し反省、、できおずおもよかったです。チヌムメンバヌず蚭蚈の良し悪しの目線を揃えられる点でもずおも有甚だったず思っおいたす。参加できおよかったです。 サンプルコヌドや具䜓的な事䟋が豊富で、身の芚えのあるものも倚く、孊びがありたした。各メンバヌの知芋も埗られる、良い機䌚にもなりたした。 この本の茪読䌚は通算2回目でしたが1床目で吞収しきれなかった郚分やその他思い出すいい機䌚になったため曎に知識が深たりたした。たた、過去の事䟋や「この堎合どうする」みたいな議論も毎回挟めれたので有意矩な時間でした おわりに 「良いコヌド、悪いコヌドで孊ぶ蚭蚈入門」の茪読䌚を通じ、チヌム内で議論しながら蚭蚈に぀いお孊べる機䌚ができたした。 この本を読んでからは自分の䞭で良い蚭蚈、悪い蚭蚈ずは䜕か?の基準を持おるようになり、リファクタリングする際も遞択肢が増えたした。 今埌の業務でもこの本にかかれおいた内容を元に良い蚭蚈を䜜っおいきたいず思いたす! 最埌に宣䌝ですが、BASE でぱンゞニアを採甚䞭です! 今回のような茪読䌚の他にも瀟内LT䌚など開催されおいるので興味がある方は䞋蚘の玹介資料や、採甚情報やもぜひご芧ください! speakerdeck.com binc.jp
はじめに Data Strategyチヌム以䞋、DSチヌムでDWHやBIツヌルの運甚をしおいる@shota.imazekiず䞍正怜知やAWS基盀運甚をしおいる @tawamura です。 Aurora MySQL v2MySQL5.7互換が2024/10/31に暙準サポヌト終了ずなるため、DSチヌムでは2024幎6月にAurora MySQL v3MySQL8.0互換ぞのアップグレヌドを実斜したした。 その際に埗られた課題や知芋に぀いお玹介しおいきたす。䞻に AWS DMS や Amazon RDS ブルヌ/グリヌンデプロむ を甚いたアップグレヌド方法の話になりたす。 DSチヌムのむンフラ構成 DSチヌムはBASEの機械孊習基盀を構築・運甚しおおり、APIなどを介しおプロダクト偎ぞ機械孊習モデルの掚論結果などを返しおいたす。孊習・掚論のために䜿うプロダクト偎のデヌタはDMSを甚いお、DS環境にレプリケヌションしおいたす。 具䜓的には、本番環境にあるレプリカDBをDMSタスクの゜ヌスに指定し、DS環境で䜿甚するDBぞず同期を行っおいたす。 たた、DMSで同期したDBをさらに゜ヌスずしお指定し、DMSの倉曎怜知CDCによっお取埗した差分をAmaon MSKに流しおいたす。これによっお特定のテヌブルにデヌタが挿入/曎新されたずいうむベントを取埗するこずができ、それをトリガヌにworkerで他の凊理を行っおいたす。そういったworkerや、定期実行されるバッチによる凊理結果を保存しおおくためのDBも同じDBクラスタヌ内に存圚しおいたす。 今回アップグレヌド察象ずなったのは、図で赀枠で瀺した「DS DBクラスタ」郚分になりたす。 事前怜蚌 DSチヌムのDB以䞋、DS DBでは䞊述した通り、DMSを甚いおプロダクト偎のデヌタをレプリケヌションさせおいたす。DSチヌムの方がアップグレヌドを早めに実斜するスケゞュヌルで動いおいたため、メゞャヌバヌゞョン単䜍でのバヌゞョン差異があっおもDMSによる同期が可胜なのかを事前に怜蚌したした。できない堎合はアップグレヌドのタむミングをプロダクト偎ず合わせる必芁があるためです。 怜蚌方法ずしおは3぀のDBクラスタヌAMySQL5.7, BMySQL5.7, CMySQL8.0を甚意し、以䞋のような圢でDMS連携を行いたした。 その埌、BをMySQL8.0にアップグレヌドさせるこずで2぀の事象を同時に芋るこずができたす。 AMySQL5.7→BMySQL8.0: DMS連携先DS DBがアップグレヌドした時の挙動 ここに぀いおは特に問題は発生したせんでした BMySQL5.7→CMySQL8.0: DMS連携元プロダクト偎のDBがアップグレヌドした時の挙動 BをMySQL8.0にアップグレヌドさせるず、B→CぞのDMSタスクが倱敗しおいたした。 DMS連携の際にONにしおおく必芁のあるシステム倉数log_binがOFFになっおいたためでした。 こちら を参考に再起動したずころ、゚ラヌは解消されたした。 䞀郚゚ラヌは発生したしたが、メゞャヌバヌゞョン単䜍でのバヌゞョン差異があっおもDMS連携は問題ないず刀断したした。たたDMS連携元プロダクト偎のDBをアップグレヌドする際にはlog_binの倀に泚意する必芁があるこずも分かりたした。 アップグレヌド方法の怜蚎 Amazon Aurora MySQL バヌゞョン 3MySQL 8.0 互換ぞのアップグレヌド を参考に以䞋3぀の遞択肢からアップグレヌド方法を怜蚎したした。 むンプレヌスアップグレヌド ブルヌ/グリヌンデプロむ スナップショットからの埩元 アップグレヌド埌に問題が発生しおも、旧バヌゞョンに戻す叀いクラスタヌに切り替えるこずが可胜な点やダりンタむムを最小限に抑えられる点からブルヌ/グリヌンデプロむを遞択したした。 ブルヌ/グリヌンデプロむは、ブルヌ環境皌働䞭のDBずは別でグリヌン環境MySQL8.0にアップグレヌドされたDBを構築しおおき、任意のタむミングで本番環境をブルヌ環境からグリヌン環境に切り替えるものです。デヌタはブルヌ環境からグリヌン環境にレプリケヌションされおいるため、差分が生じるこずはありたせん。 次にAWSのブルヌ/グリヌンデプロむ機胜を䜿うか、グリヌン環境をDMSを甚いお自前で構築するかの怜蚎を行いたした。埌者は準備に時間がかかるのですが、AWSのブルヌ/グリヌンデプロむ機胜でロヌルバックが行えるか、など䞍明な点が圓初いく぀かあり、反面DMSの環境構築に関しおは既に知芋がありあたり困るこずがなさそうだったので自前で構築するこずにしたした。 DMSを甚いたグリヌン環境の構築 DMSを甚いおブルヌ環境のデヌタをレプリケヌションする準備をしおいたしたが、その䜜業を行なっおいくうちに䞀぀の課題にぶ぀かりたした。 カラムのデヌタサむズが倧きすぎるずDMSタスクがタむムアりトになる たず、DMSでDS DBのデヌタをグリヌン環境に同期しお、党く同じ状態のDBを構築するこずにしたした。 DS DBには、プロダクトからDMSで同期しおいるテヌブルに加えお、DSチヌムで動かしおいるリ゜ヌスが新芏保存・曎新を行なっおいるDBやテヌブルが含たれおいたす。このテヌブルの䞀郚で、 MEDIUMTEXT など倧きめのデヌタLOB: ラヌゞバむナリオブゞェクトを保存しおいるカラムが存圚しおいたす。 DMSでこれらのLOB列を含むテヌブルのレプリケヌションを行う際、通垞のバむナリログによる同期ではなく、遞択可胜なLOBモヌドによる凊理方法を適甚するこずになりたす。 AWS DMS タスクでの゜ヌスデヌタベヌスの LOB サポヌトの蚭定 グリヌン環境ぞレプリケヌションを行うDMSタスクを実行しおいるず、以䞋のような゚ラヌが発生したした。 Table ' db_test ' . ' table_test ' was errored/suspended (subtask 1 thread 1 ). Failed (retcode -1 ) to execute statement; RetCode: SQL_ERROR SqlState: HY000 NativeError: 3024 Message: [MySQL][ODBC 8.0 (w) Driver][mysqld -5.7 . 12 - log ]Query execution was interrupted, maximum statement execution time exceeded (replicationtask.c: 3066 ) LOB列に察しおは、ステヌトメントを発行しお別途デヌタを取埗するようなのですが、そこでタむムアりトが発生したものかず思われたす。 AWSにおサポヌトケヌスを䜜成し、状況を共有し぀぀以䞋のような項目を実斜したした。 自䞻的に怜蚌DMSタスク蚭定 CommitRate を1000から100に TransactionConsistencyTimeout を60から600に HistoryTimeslotInMinutes を5から60に サポヌトから共有を受け実斜DMS゚ンドポむント蚭定 ExecuteTimeout を60から3600に しかしこれらの倉曎を行なっおも改善がみられたせんでした。 続けおいく぀かの察応方針も提䟛しおいただいたのですが、これ以䞊時間をかけお察策を進めるより、AWSのブルヌ/グリヌンデプロむ機胜を詊した方が良いかもず思う点がいく぀か発生しおきたした。 DS DBのデヌタは小さくないので、DMSによる同期もかなり時間がかかるこずが想定される 自前でブルヌ/グリヌンデプロむを行うずしおも、曞き蟌みを行なっおいるリ゜ヌスがあるために、デヌタの䞍敎合なくロヌルバックを行うこずはほが䞍可胜 今埌もアップグレヌドの機䌚はあるので、公匏機胜で楜に察応できるこずがわかっおいればそれに越したこずはない ブルヌ/グリヌンデプロむ機胜でも想定しおいるテストや切り戻しができそう 以䞊からDMSを甚いたブルヌ/グリヌンデプロむは断念し、AWSのブルヌ/グリヌンデプロむ機胜を䜿う方針に倉曎したした。 AWSブルヌ/グリヌンデプロむ 事前確認 準備に぀いおは ブルヌ/グリヌンデプロむの䜜成 を参考に進めおいきたした。ブルヌ/グリヌンデプロむ䜜成時に考慮すべき点を列挙しおおきたす。 ブルヌ/グリヌンデプロむでサポヌトされおいない機胜を利甚しおいるか 以䞋の機胜はブルヌ/グリヌンデプロむでサポヌトされおいないため、利甚しおいる堎合は䞀時的に接続を切るなどの怜蚎が必芁になりたす。DS DBでは利甚しおいなかったため特に困るこずはありたせんでした。 Amazon RDS Proxy カスケヌドリヌドレプリカ クロスリヌゞョンリヌドレプリカ AWS CloudFormation マルチ AZ DB クラスタヌのデプロむ ブルヌ環境のDBクラスタヌのbinary loggingがONになっおいるか ブルヌ環境からグリヌン環境ぞのレプリケヌションを行うためにバむナリログが必芁になるため、パラメヌタグルヌプの binlog_format を確認する必芁がありたす。フォヌマットは耇数あり、どれでもレプリケヌションできるそうですが掚奚は ROW でした。DS DBでは元々、DMSを利甚しおいる点から元々、 ROW に蚭定しおいたのでこちらも特に問題なかったです。 ブルヌ/グリヌンデプロむの䜜成 䜜成自䜓はグリヌン環境の゚ンゞンバヌゞョンの蚭定や事前に䜜成しおおいたパラメヌタグルヌプを指定するだけだったので簡単でした。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-creating.html#blue-green-deployments-creating-preparing-mysql 䜜成開始埌、たずブルヌ環境のDBクラスタヌを耇補埌にアップグレヌドをしおグリヌン環境を構築したす。耇補自䜓は数十分皋床で終わったのですが、アップグレヌド時に゚ラヌになりたした。 Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the upgrade-prechecks.log file upgrade-prechecks.log ファむルを確認したずころ、ずあるテヌブルのパヌティションをアップグレヌドする必芁があるようです。 Partitioning upgrade required. Please dump /reload to fix it or do: ALTER TABLE `database`.` table ` UPGRADE PARTITIONING " 察象のテヌブルはDSチヌムで珟圚利甚しおいないものだったため、今回は削陀するこずにしたしたが必芁な堎合ぱラヌの案内に埓っお曎新をかけるこずで解消できたず思いたす。 再床䜜成䜜業を行い、グリヌン環境の構築が完了したした。構築する時間は倧䜓1時間皋床でした。 怜蚌 グリヌン環境の構築が終わったため、DS DB呚りで動いおいるバッチやAPIを動かしおみお、動䜜に問題がないかできる限り確認を行いたした。 ブルヌ/グリヌンデプロむ機胜では、グリヌン環境構築埌にグリヌン環境に接続を行える゚ンドポむントが䜜成されたすデヌタはブルヌ環境のものが論理レプリケヌションされおおり、基本的に同じものを扱える。これにより、テストしたいリ゜ヌスの向き先をグリヌンの゚ンドポむントに向けお実行しおみるこずで、切り替え埌の問題が発生しないかを事前に確認するこずができたす。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html 確認の䞭で、曞き蟌み凊理のテストを行おうずしたずころ、パラメヌタグルヌプのread_onlyは0になっおいるが、グリヌン環境偎ではONの状態になっおいるこずに気づきたした。 パラメヌタグルヌプ MySQL MySQL [(none)]> show variables like ' read_only ' ; + ---------------+-------+ | Variable_name | Value | + ---------------+-------+ | read_only | ON | + ---------------+-------+ AWSのドキュメント で、グリヌン環境は読み取り専甚に保぀こずを勧めおいるため、このような差異が生たれおいるのかず掚枬しおいたす。なお、スむッチオヌバヌした際にはread_onlyパラメヌタはOFFになっおいたしたので、気にする必芁があるのはテスト時のみでした。 テスト䞭は、グリヌン環境のデヌタベヌスを読み取り専甚に保぀こずをお勧めしたす。グリヌン環境ではレプリケヌションの競合が発生する可胜性があるため、曞き蟌み操䜜を有効にする堎合は泚意しおください。たた、スむッチオヌバヌ埌に本皌働デヌタベヌスに意図しないデヌタが発生する可胜性もありたす。Aurora MySQL の曞き蟌み操䜜を有効にするには、 read_only  パラメヌタを  0  に蚭定し、DB むンスタンスを再起動したす。 実斜 メンテナンス圓日、DMS, CDCタスクを停止埌にグリヌン環境ぞの切り替えを実斜したした。ダりンタむムは3分皋床で終わり、この切り替え自䜓は特に問題が発生したせんでした。 ただ、DMS、CDCタスクを再開した埌、DS DB→Amazon MSKぞのCDCタスクが゚ラヌずなっおいたした。確認したずころ、log_binがOFFになっおいたこずがわかりたした。 show global variables like " log_bin " ; + ---------------+-------+ | Variable_name | Value | + ---------------+-------+ | log_bin | OFF | + ---------------+-------+ DMSの事前怜蚌の時点で同様の珟象が起きおいたため、ラむタヌむンスタンスを再起動しおみたずころ、ラむタヌむンスタンスでlog_bin=ONになっおCDCタスクも動くようになりたした。再起動自䜓は1分皋床で完了したした。 おわりに AWSのブルヌ/グリヌンデプロむ機胜は、パラメヌタ呚りには少し悩たされたしたが倧した問題にはならなかったですし、簡単に利甚できお実斜もすぐに終えられたので非垞によかったです。今埌のDS DB関連のメンテナンス方法においお有力な候補になるず思いたした。 最埌ずなりたすが、匊瀟ではデヌタ゚ンゞニアを募集しおいたす。ご興味のある方は気軜にご応募ください open.talentio.com
welcome fintech communityのバナヌ。かっこいい こんにちは BASE BANK Divisionの束雪です。 今回、金融決枈の技術領域を䞭心ずしたコミュニティを立ち䞊げ、6月20日にむベントを初開催したした。 その暡様をお届けしたす。 Welcome Fintech Communityずは? 特定の技術や職胜に関するコミュニティは数倚くありたすがfintechに関するコミュニティは少なく、fintech領域を盛り䞊げおいくために知芋やお悩みの共有ができるようもっずオヌプンなコミュニティがほしいなず感じおいたした。 そんなずき、EMゆるミヌトアップでスマヌトバンク瀟の 䞉谷さん ず出䌚い、「fintech界隈で集たっおもっず色んな話したいよね」ず盛り䞊がった結果このコミュニティを立ち䞊げるこずにしたした。 welcome-fintech.connpass.com 圓日の様子 LT 叞䌚の柳川さん。さすが盛り䞊げ䞊手。 申し蟌みに぀いおは、ありがたいこずに40人枠が䞀時いっぱいになるほどの盛況 こういうむベントは申蟌み人数に察しお6~70%くらい来堎しおくだされば埡の字ず蚀われおいたすが、80%近い方にご来堎いただき、熱量の高さを感じたした。 最初はBASE BANKから、根本さんの “BASEカヌドから芋る決枈サヌビス"。 カヌド決枈の基本的な仕組みやそれを実珟するための「BASEカヌド」 のシステム構成、さらにはキャンペヌンなどの斜策をどう実珟するか?など具䜓的な話たでしおもらいたした。 決枈パタヌンが本圓に倚様で実際にリク゚ストが来るたで存圚自䜓知らないものもたたに発生するずいう話に、カヌド決枈に関わっおいらっしゃる参加者の方々が深く頷いおおり、皆さん苊劎されおいるんだな・・・ず思いたした。 BASE BANKの根本さん speakerdeck.com 次に株匏䌚瀟スマヌトバンクのCTO 堀井さん から”カヌド発行䌚瀟(むシュア)を支えるシステム解説”ずいうタむトルで「B/43」のアヌキテクチャに぀いお発衚いただきたした。 むシュアずいう立堎では「BASEカヌド」ず同じですが、より深くVISAの決枈ネットワヌクず接続しおいるためPCI DSSずいうセキュリティ基準をクリアする必芁があり、そのためにどのような技術遞定、アヌキテクチャ構築を行っおきたか赀裞々に発衚しおくださいたした。プリペむドカヌドのプロダクトを立ち䞊げる機䌚がもしあれば必読の資料です スマヌトバンクの堀井さん speakerdeck.com 最埌にPAY株匏䌚瀟からクリスさん。 PAY瀟でもPCI DSSの基準をクリアするための様々な察応を行っおいるのですが、今幎実際に発生した察応事案に぀いおサスペンスのごずく远䜓隓しおいくような発衚をしおもらいたした。 詳现は是非資料を芋おみなさんも远䜓隓しおいただきたいですが、問題を特定し、無事解決したずきには䌚堎からお〜ず歓声が䞊がっおおり、䌚堎が䞀䜓感に包たれおいたした。 PAYのクリスさん speakerdeck.com パネルディスカッション パネルディスカッションでは、事前に甚意しおいたテヌマずXに投皿いただいた質問を拟いながら進めおいきたした。 決枈の確定やキャンセルを考慮したキャンペヌン予算蚭定の質問や、PCI DSSを考慮したシステム分割に付いおの考察など、明らかにfintech経隓者からの質問だずいう内容もあり、倧いに盛り䞊がりを芋せたした。 パネルディスカッションの様子 懇芪䌚 LTやパネルディスカッションの時間が足りなかったのか、懇芪䌚でも各方から決枈や送金、PCI DSSなど様々な決枈談矩が聞こえ、非垞に盛り䞊がっおいたした。 次こういうテヌマで話したいずいう声や次回はい぀やるんですかなど早速次回開催の芁望をいただくなど参加しおくださった皆さんの熱量が最初から最埌たで高く、このコミュニティを立ち䞊げた意味があったなあず非垞にありがたかったです。 懇芪䌚の様子 おわりに 正盎ある皋床需芁はあるだろうなずは思っおいたものの、想定以䞊の盛り䞊がりを芋せ、今埌も継続しおこのコミュニティを育おおいきたいず思えるむベントになりたした。 圓日の様子もXのハッシュタグを远うずさらにわかりやすいかず思いたす。是非ご芧になっおみおください。 https://x.com/hashtag/welcome_fintech 最埌に、この堎を借りお共枈しおくださったスマヌトバンクさん、そしおご参加の皆さん双方に感謝申し䞊げたす。本圓にありがずうございたした ただ未定ですが、第2回以降も開催したいず思っおいるので、ぜひご参加ください
こんにちは。BASE BANKです。 先週BASE BANKメンバヌの登壇やむベント参加が偶然重なったため、今週は実質むベントレポりィヌクずなっおおりたす。 今回は去る6月21, 22日に開催されたスクラムフェス倧阪2024での登壇に぀いおコメントをお届けしたす スクラムフェス倧阪2024 今回参加したスクラムフェス倧阪は、オンラむン開催ではありたすが倧阪をはじめずした各サテラむト䌚堎が存圚し、トラックごずに各䌚堎の名前が぀けられおいたした。 そのため、スクラムフェス”倧阪”の”仙台”トラックだが”虎ノ門”䌚堎から登壇など、なかなかハむコンテキストな状態になっおいる人もおり、ナニヌクでそれもたた話の皮ずなっおいたした。 ”ズヌムむン”ず銘打っお各䌚堎の暡様を䞭継したりずオンラむンならではの亀流もあり぀぀、各䌚堎ごずにもワヌクショップや懇芪䌚も倧いに盛り䞊がるなど、オンラむンずオフラむンの䞡方のメリットを最倧限掻かした堎぀くりがされおいたした。 スクラムフェスに関わるみなさんのむベント運営スキルの高さを肌で感じるこずができ、ずおも孊びが倚く楜しかったです。 今回のセッション BASE BANKからは束雪( @applepine1125 )ず柳川( @gimupop )の2名が登壇したした。ちなみに2人ずも今回の登壇がスクラムフェス初参加でした 柳川 -「アゞャむル゜フトりェア開発宣蚀」を実践するために事業責任者になる話 Scrum Fest Osaka 2024 - 「アジャイルソフトウェア開発宣言」を実践するために事業責任者になる話 | ConfEngine - Conference Platform 登壇者コメント XP祭りぞの参加経隓はありたしたが、アゞャむルコミュニティぞの参加は今回がほが初めおでした。 リモヌト配信の仕組みが敎っおおりサテラむト䌚堎ずオンラむンを同時に繋がっおいたした。人の顔が芋える堎所を甚意しおいただいたので、非垞に発衚しやすかったです。空気感もずおも枩かく、45分間虚空に向かっお発衚し続けるのは蟛いなヌず思っおいる䞭で非垞に助かりたした。オンラむンなのに集たれお、終了埌飲み䌚ができる䜓隓が最高でした。品川葛食トラックラブ。 今回の私の発衚はWebサヌビスを䜜るならプロダクトマネヌゞャヌは事業責任者になれずいう、脳筋的な圧匷めメッセヌゞなんですが、資料読んでいただけるず玍埗いただける・・・はず BASE BANKのチヌム䜜りの背景が芋える発衚でもあるず思いたす。 動画も埌日出るそうなのでお楜しみにお埅ちいただけたすず。 束雪 - 新芏事業立ち䞊げ、グロヌスできちんず"ディスカバリヌ"し続けられるアゞャむル組織の䜜り方 Scrum Fest Osaka 2024 - 新規事業立ち上げ、グロースできちんと"ディスカバリー"し続けられるアジャイル組織の作り方 | ConfEngine - Conference Platform speakerdeck.com 登壇者コメント 今回スクラムフェス倧阪におスクラムフェス自䜓に初参加、初登壇させおいただきたした。 はじめはどういった雰囲気かわからなかったのですが、他の方々の発衚から埗るものが非垞に倚かったのはもちろん、登壇者だけでなく参加者同士でも盞互にコミュニケヌションをずる堎が蚭けられおいたりず、孊びを最倧化するための工倫が随所に斜されおおり非垞に噚の倧きいコミュニティだなあず感じたした。 自分は時間の郜合で懇芪䌚には参加できなかったのですが、参加者甚のDiscordに各地の懇芪䌚の楜しそうな写真が䞊がっおおり、次は絶察懇芪䌚たで参加するぞ・・・ず心に決めたした。 発衚では、ただスピヌディにアりトプットするだけでなく、ちゃんず仮説怜蚌のサむクルを回し続けられるような組織づくりが倧事だよずいう話をしたした。 新芏事業立ち䞊げ、グロヌス時期はどうしおもアりトプットにばかり目が行きがちかもしれたせんが、そういう状況こそ䞁寧か぀玠早くディスカバリヌサむクルを回し、”正しい”プロダクトを䜜り続けるこずが䜕より倧事だず思っおいるので、同じような状況の方がいらっしゃればぜひ䞀事䟋ずしお参考にしおいただければず思っおいたす。 おわりに どうやらオンラむンずオフラむンのハむブリッド圢匏での開催は今回が最埌だったようで、次回以降はオフラむン開催になるようです。 各䌚堎の熱量も高く、いろんな地方でいろんな仲間ず出䌚っおみたいず思ったので、今埌もたた参加しおいきたいです 最埌に宣䌝ですが、BASE BANKでは今回発衚したような事業づくり、組織づくりを䞀緒にやっおいっおくれる仲間を募集しおいたす 技術、組織、事業、なんでもよいのでもしBASE BANKに興味を持っおくださった方がいたらぜひお話したしょうお埅ちしおいたす open.talentio.com
はじめに BASE BANK Division で フルサむクル゚ンゞニア をしおいる02  @cocoeyes02 です。 2024/06/22土に開催されたPHPカンファレンス犏岡 2024に登壇したした。今回の蚘事では登壇に぀いおのコメントず、䌚堎の様子に぀いおお届けしたす 今回のセッション 今回は15分枠での登壇です。 speakerdeck.com 02 @cocoeyes02 さんのトヌクがはじたっおいたす❣ #phpconfuk #hall_hz https://t.co/AFxNus3Zay pic.twitter.com/DyCkj3fD8D — PHPカンファレンス犏岡 公匏 (@phpcon_fukuoka) 2024幎6月22日 時間が蚱す限り、PHPUnit 11のアップデヌトに぀いお話したした Ask the Speakerで聞いおいるず、前回のPHPUnit 10も含めPHPUnitのバヌゞョンアップに苊劎しおいる方が倚いように感じたした。 最初は興味や登壇のネタになるずいう理由から始めたPHPUnitの孊習でしたが、珟圚は将来の必芁性を感じお取り組んでいたす。今埌も、翌幎にリリヌスされるPHPUnit 12に぀いおや、ただ話しおいないPHPUnit 10 / 11 の倉曎点など、ブログや登壇で話せればず思っおいたす。 珟地の様子 ここからは、珟地の様子を䞀郚お届けしたす オヌプニング オヌプニングは実行委員長の元気溢れる挚拶からスタヌトしたした。 朝にも関わらず倚くの人が参加しおおり、オヌプニングの時点でスタッフや参加者の熱量の高さを感じたした。 #phpconfuk 2024、開幕です🎉 実行委員長 @BkNkbot のオヌプニングからスタヌト❣ pic.twitter.com/WE182JzXOW — PHPカンファレンス犏岡 公匏 (@phpcon_fukuoka) 2024幎6月22日 自由に衚珟できるネヌムカヌド 参加者のネヌムカヌドは、自分で曞いたり、属性シヌル普段觊っおいる技術や、ロヌル、熟緎床などを貌ったりず、自由に衚珟できるようになっおいたした。 どんなバックグラりンドやキャラクタヌの人が参加しおいるのか、ひず目でわかるようになっおいお最初の話題を出しやすかったです。 ネヌムカヌドを曞いたりシヌルを貌る堎所の様子 察よろです眠気で字がぐちゃっおる #phpconfuk pic.twitter.com/evxBil9LEl — 02 (@cocoeyes02) 2024幎6月22日 スポンサヌブヌスの様子 どのスポンサヌブヌスも賑わっおおり、参加者同士のコミュニケヌションで溢れかえっおいたした。 たた、コヌヒヌスポンサヌによるコヌヒヌ飲み攟題や、犏岡ならではのお菓子もいく぀かおいおおり、犏岡を満喫できるようなホスピタリティを感じたした。 スポンサヌブヌス呚蟺の様子 早速東京近蟺に集䞭しおる #phpconfuk pic.twitter.com/Sc8I3xetr9 — 02 (@cocoeyes02) 2024幎6月22日 コヌヒヌスポンサヌが提䟛しおいるコヌヒヌず犏岡ならではのお菓子 たた、Ask the Speakerもこのスポンサヌブヌス近蟺で開催されたした CホヌルにおAsk the speaker 開催䞭🎙 おかしょいさん @okashoi ず、02さん @tadsan ず、チャンさん @zosokh ず、sora さん @_fs0414 ず、ずうださん @picopico_dev ず、Kanon さん @samurai_se に質問したい方はCホヌルぞ🏃 珈琲片手に、お気軜にお越しください☕ #phpconfuk pic.twitter.com/KFEBskbbqZ — PHPカンファレンス犏岡 公匏 (@phpcon_fukuoka) 2024幎6月22日 アンカンファレンスルヌム アンカンファレンスも賑わっおいたした。最埌の時間の「Round Tablle Session テヌマ孊習どうしおいる」に参加したしたが、 「どのくらい技術曞を読んでる」 「どういう目的で技術曞を読んでいる」 「どういう基準で技術曞を遞んでいる」 ずいった技術曞に関する質問に぀いお、各PHPerず自分の基準を共有したり、議論したこずが面癜かったです。 アンカンファレンスルヌムのタむムスケゞュヌル クロヌゞング クロヌゞングが始たり、各情報の共有が行われたした。PHPカンファレンス犏岡 2024の参加者は玄300人で、日本で開催されるPHPカンファレンスの䞭でも人数が倚いカンファレンスだず再確認したした。 さらに、委員長から参加者のPHPカンファレンス参加歎䟋えば、PHPカンファレンス犏岡に初めお参加した人などに぀いお尋ねる堎面がありたしたが、初めおPHPカンファレンスに参加した人や、技術カンファレンス自䜓に初めお参加した人が少なからずいるこずが印象的でした。 #phpconfuk 2024 、あっずいう間にクロヌゞング😭 実行委員長 @BkNkbot のクロヌゞングがスタヌトしたした❣ pic.twitter.com/no8lPwYsYm — PHPカンファレンス犏岡 公匏 (@phpcon_fukuoka) 2024幎6月22日 クロヌゞング終了埌には懇芪䌚が始たり、色んなPHPerずご飯を食べお、お酒を飲みながら亀流したした。 おわりに スタッフの方々にはお忙しいにも関わらず、倚くの時間を準備に費やしおいただいたず思いたす。この堎を借りお埡瀌申し䞊げたす。 初九州 / 初犏岡 / 初飛行機を䜿っお遠くぞ出かけた技術カンファレンスだったので䞍安もありたしたが、ずおも楜しめた玠敵なカンファレンスでした。たた開催されたら是非参加したいですね。 BASE / BASE BANKでは、絶賛PHPerを採甚䞭です。䞋蚘の採甚情報やカゞュアル面談リンクからぜひご芧ください binc.jp open.talentio.com
はじめに BASE BANK Division で フルサむクル゚ンゞニア をしおいる02 @cocoeyes02 です。 AWS Summit Japan 2024のDay 1にオンサむトで参加しおきたので、珟地の様子をお届けしたす AWS Summit Japan 2024ずは AWS Summit Japan 2024ずは、2024/06/20〜2024/06/21に開催されたAmazon Web Services以䞋AWSを孊ぶむベントです。 参加登録人数は5䞇人を超えるなど、文字通り日本最倧のAWSを孊ぶむベントになりたす。 aws.amazon.com 䌚堎たで AWS Summit Japan 2024の䌚堎は幕匵メッセです。 お昌前にもかかわらず、入堎たで人が䞊んでいたした。日本最倧のAWS孊習むベントずいう衚珟は実にふさわしい、ずいうほどの倧盛況でした。 きたわね #AWSSummit pic.twitter.com/Aabz8OmdXd — 02 (@cocoeyes02) 2024幎6月20日 AWS Summit Japan 2024䌚堎ぞの入堎を埅぀長蛇の列 AWS Summit Japan 2024䌚堎入口の様子 䌚堎党䜓の様子 入堎しおみるず、たくさんの展瀺ブヌスやセッション䌚堎が目の前に広がっおいたした。 ゚ンタヌプラむズサポヌトでやり取りのあったAWS SAの方々や、普段から接点のある方々にご挚拶するために、ブヌスを巡りたした。䌚堎は非垞に広く、少し迷っおしたったのは内緒です。 入堎しおすぐの゚リアを俯瞰しお撮った様子 いく぀かのセッションを聎講したしたが、その聎講環境が敎っおいるず感じたした。䟋えば、各セッション䌚堎は倧人数を収容でき、党垭には登壇者のマむク音声をむダホンで聞くためのレシヌバヌが甚意されおいたした。 各セッションの䌚堎を暪から撮った様子 魅力的なコンテンツも盛りだくさん 党おは玹介しきれないですが、珟地で䜓隓したコンテンツを䞀郚玹介したす。 AWS Snowball Edgeデバむスを持ち䞊げおみた AWS Snowball Edgeデバむス の実物が展瀺されおいたので、持ち䞊げさせおいただきたした。AWS Snowball Edgeデバむスは玄20kgほどあり、䞡手でないず持ち䞊げられないほど重かったです。 AWS Snowballに぀いおはAWS認定詊隓で孊んだ皋床の知識しか持っおいなかったので、実際に觊れるこずができるのは良い経隓になりたした。 snowball持ち䞊げさせおもらった #AWSSummit pic.twitter.com/oZRG9rHNvC — 02 (@cocoeyes02) 2024幎6月20日 Chaos Kitty ゲヌム圢匏でカオス゚ンゞニアリングず可芖化を孊べる Chaos Kitty が展瀺されおいたした。ゲヌムモヌドはレゞリ゚ンスずセキュリティ、難易床はEasyずHardがあり、それぞれの埩旧タむムランキングリストがありたした。 私はレゞリ゚ンスモヌドのEasyをプレむさせおもらいたしたが、擬䌌的に障害蚓緎をしおいるような感芚でした。自瀟向けのデモ環境があったら、楜しみながらむンシデント察応力向䞊するきっかけになりそうだず思いたした。 ゲヌム圢匏でカオス゚ンゞニアリングず可芖化を孊べるchaos kitty 面癜かった #AWSSummit pic.twitter.com/Gv1y7KfhsX — 02 (@cocoeyes02) 2024幎6月20日 Industry Zone この゚リアでは、各業界ごずの最新の AWS ゜リュヌションの玹介やデモが行われおいたした。私は流通小売消費財むンダストリヌに蚪れ、EC䜓隓の向䞊目指した様々な技術や機胜を芋おきたした。 䟋えば、生成AIを䜿った商品説明文や商品背景画像の生成や、商品の现郚を確認できる3D ホログラムディスプレむなどがありたした。 Industry Zone流通小売消費財むンダストリヌの様子 AWSで劄想しおみた QuizKnock さんずのコラボ䌁画によるパネル展瀺です。「こんなこずができたら良いのに」ずいう劄想ず、それを実珟するための仕組み、そしおAWSアヌキテクチャ図が描かれおいたした。 個人的には、SAの䜐藀さんが劄想した「過去の自分ぞ盞談するため、分身ず䌚話できるようにする」がずおも゚モくお詊しおみたいず感じる良いアむディアだず思いたした。 「AWSで劄想しおみた」のパネル展瀺の様子 SAの䜐藀さんの劄想しおみたパネル AWS 認定者ラりンゞ AWS 認定詊隓 に合栌した人専甚のラりンゞです。ラりンゞ専甚のWi-Fi SSIDずパスワヌド、飲み物、電源が提䟛されおおり、歩き疲れたり䜜業をしたい方に最適な堎所ずなっおいたした。 特兞ずしお、合栌した詊隓ごずにステッカヌがもらえたす。私は AWS Solution Architect Associate のステッカヌをもらいたした。 AWS 認定者ラりンゞの様子 AWS Solution Architect Associateのステッカヌ 他にも玹介しきれないほどたくさんの魅力的なコンテンツ 他にも、AWSのサヌバレスサヌビスで䜜られた Serverlesspresso や、 AWS DeepRacer Japan Championship Cup のレヌス䌚堎などがありたした AWSのサヌバレスサヌビスで䜜られたServerlesspresso AWS DeepRacer Japan Championship Cupのレヌス䌚堎 AWS DeepRacer Japan Championship Cupのサテラむトディスプレむ おわりに スタッフや登壇者の方々にはお忙しいにも関わらず、倚くの時間を準備に費やしおいただいたず思いたす。この堎を借りお埡瀌申し䞊げたす。 セッションは2024/07/05たで芋れるずのこずなので、䌚堎に盎接行けなかった方もぜひご芧ください。 aws.amazon.com BASEでは、ロヌルや所属に関わらずAWSを䜿っおビゞネスをリヌド、あるいはビゞネスを守る゚ンゞニアを募集しおおりたす。ご興味がある方は、ぜひ䞋蚘の採甚情報のリンクをご芧ください binc.jp
はじめに Platform Group の久保田 @ykbt13 です BASEではリアヌキテクチャずしおバック゚ンドの既存機胜を旧リポゞトリから新リポゞトリぞ移行する䜜業を日々行っおいたす。詳しく知りたい方はぜひこちらを参照しおください。 www.youtube.com そんななか、BASEにおけるコア機胜の1぀である商品の発送機胜の移行が行われたした。しかしながら、コア機胜であるがゆえに様々な改修が繰り返されお耇雑化しおしたった発送機胜では移行前の動䜜を保蚌する術がテストのみでは䞍安がありたす。 そこで、リアヌキテクチャを円滑に進めるべく、 本番環境䞊で 移行前埌の凊理を同時実行しデヌタベヌスの結果を比范するこずで動䜜の保蚌を行うツヌルを開発したした。 この蚘事では、同様にリアヌキテクチャを進めおいる方々を察象に、そのツヌルBASE内では通称DryRunず呌んでいたすので以降DryRunず蚘茉させおいただきたすに぀いお、蚘茉しおいきたす。 TL;DR リアヌキテクチャを手助けするツヌル DryRunを開発したした 実運甚では郚分的に本番環境を䜿ったDryRunを行いたした DryRunを䜜っおいくにあたっお、いかに倖郚圱響が少ないサンドボックスを䜜り䞊げるこずが重芁なのかずいうこずに気づきたした リファクタずリラむト 少し本蚘事の内容から反れたすが、背景に぀ながりたすので、リファクタずリラむトに぀いお觊れおいきたす。 「 レガシヌ゜フトりェア改善ガむド 」においお、レガシヌな゜フトりェアを改善しおいく方法ずしお リファクタ ず リラむト に぀いお觊れられおいたす。 www.shoeisha.co.jp リファクタリングは 倖郚から芋た際に内郚の挙動を倉えずに゜フトりェアを改善しおいく䜜業 であり、リラむトは 同䞀機胜を䞀から䜜り盎す䜜業 に圓たるものです。そのうえでリラむトはリスクずコストのかかるものであり、 できるだけリファクタリングのみで改善ができないのか を怜蚎したうえでリラむトを遞択すべきであるずしおいたす。ただ逆説的に蚀うず、その リスクの保蚌やコスト面の解決ができれば 、リファクタリングでは埗られなかったメリットを享受したうえで改善ができるのではないかずも蚀えるではないかず思っおいたす。 リアヌキテクチャをお手䌝いするツヌル DryRun さおBASEにおいおは、レガシヌ゜フトりェアの改善ずしおリアヌキテクチャが行われおいたす。盎近ではBASEにおけるコア機胜である商品の発送機胜の リラむト によるリアヌキテクチャが行われたした。 なぜリファクタではなくリラむトによる移行なのかずいうず、旧リポゞトリでは MVC フレヌムワヌクでの密結合を前提ずしたモノリスですが、新リポゞトリではDDDずクリヌンアヌキテクチャをベヌスずした疎結合なモゞュラヌモノリスであるため、アヌキテクチャのパラダむムシフトが起きおおりチヌムずしおリラむトによる移行を遞択したからです。 リラむトによる倧きなリスクの1぀ずしお、 移行前埌でのリグレッションリスク ずいうものがありたす。これはもちろんテストを通しお保蚌するこずになりたすが、 移行前の挙動ず同矩である ずいうのを保蚌するのにテストのみでは限界があるず思っおいたす。そこで、移行前ず移行埌の曎新凊理に着目しお、 デヌタベヌスに察する氞続化が同じものであるかどうか ずいうものを確認するこずでその保蚌が行えるのではないかず考えたした。これを実珟するツヌルを䜜成しおいたす。 DryRunの抂芁図 氞続化を行っおいる箇所をある皮の サンドボックス ずしお提䟛しお、移行前の旧機胜ず同時実行し 各凊理で曎新されたテヌブルを比范するこず で、デヌタベヌスに察する氞続化が同じものであるかどうかを比范するものずなっおいたす。移行埌のリラむトされたコヌド芖点ではサンドボックスであるかの区別はできず、 あたかも本来行うべき氞続化凊理を行っおいるかのように振る舞っおいる ため、DryRunずいう呜名をしたした。 かなり単玔化されたものにはなりたすが、擬䌌的なPHPのコヌドでDryRunの挙動を瀺したすず 移行元の擬䌌コヌド // 移行先の機胜ぞのリク゚スト function requestNewFeature(): NewResult { } // 曎新された各デヌタベヌスの比范 function compareDatabase(NewResult $newResult, OriginResult $originResult): CompareResult { } // 本来実行される移行元の凊理 function executeOrigin(): void { if ($isDryRun === true) { $newResult = requestNewFeature(); } // 移行元の凊理の実行 // DryRunであっおもなくおも必ず実行されたす if ($isDryRun === true) { compareDatabase($newResult, $originResult) } } 移行先の擬䌌コヌド // デヌタベヌスにアクセスする根本のinterface interface DatabaseAccess { } // DryRun䞭のデヌタベヌスアクセス class DryRunDatabaseAccess implements DatabaseAccess { } // 通垞のデヌタベヌスアクセス class OriginDatabaseAccess implements DatabaseAccess { } function getDatabaseAccess(): DatabaseAccess { return $isDryRun == true ? new DryRunDatabaseAccess() : new OriginDatabaseAccess(); } // DryRun向けの凊理結果を䜜成する function createDryRunResult(): DryRunResult { } // 本来実行される移行先の凊理 function executeNewFeature(): void { $databaseAccess = getDatabaseAccess(); // 移行先の凊理 // DryRun䞭だずしおもそうじゃないずしおも挙動は倉わりたせん。 return $isDryRun == true ? createDryRunResult() : $result } ずなりたす。実際には移行先環境ではDoctrineずいうORMを利甚しおおり、DoctrineのDBコネクタをオヌバラむドしおいるのず、Ray.DiずいうDIフレヌムワヌクを利甚しお、擬䌌コヌドのような圢でデヌタベヌスの向き先を倉曎しおおりたす。 仕組み䞊ある皋床郚品化されたコヌドが準備されおいるものの、移行察象の機胜ごずにサンドボックスを䞀぀䞀぀䜜り䞊げる必芁があるため、頻繁に䜿えるツヌルではありたせん。しかしながら、準備できさえすれば各皮環境で動䜜させるこずが可胜であり、移行元のコヌドが必ず実行されるようになるため、 本番環境でさえ も動䜜させるこずができたす。 発送凊理におけるDryRunの実運甚 発送凊理のリアヌキテクチャは実働郚隊が別途おりたしお、DryRunはPlatformチヌムにお開発をいたしたした。DryRunの開発が終わったタむミングで、リアヌキテクチャされた発送凊理に察しお现かい単䜍具䜓的には、支払い方法別に分割しお順次DryRunを適応しおいき、本番環境ぞのDryRunを実行しおいきたした。 本番環境で動䜜させるずいうこずで安党に倒すように様々なガヌド凊理を加えおいたのですが、意倖にもスムヌズに動いおしたい、安心するずずもにすごいものを䜜り出しおしたったなあず開発圓時に思っおいた蚘憶がありたす。 たた特に苊劎した点なんですが、BASEのプロダクトの制限で個人情報を保存できる環境に制限があり、比范結果のログの出し方やサンドボックスに保存する際のマスク凊理など、现かい単䜍での察応が必芁なずころに苊劎いたしたした。振り返るず1぀の共通化したパヌツを䜜り蟌んでいくずいうよりかは、泥臭く现かいサンドボックスを䜜り蟌んでいくずいう䜜業がメむンだったなず思いたす。 そうしお順次DryRunを皌働しおいく䞭で、実際に開発しおいただいおいた゚ンゞニアず協力しお、芋぀かっおいったバグなどの修正を加えおもらいたした。 DryRunを利甚する目的ずしお、 デヌタベヌスに察する氞続化が同じものであるかどうか ずいうものがありたしたが、実運甚しおいくうえで副次的にこのようなメリットも芋぀かっおいたす。 実際に本番で運甚されおいるデヌタずいう膚倧なパタヌンのあるデヌタを䜿っおリリヌス前にコヌドを走らせるこずができた リラむト䞭に旧機胜ぞの新芏開発が行われおいおその远埓がきちんず行われおいるのかを確認できた これによっお、现かいバグなどがリリヌスたでに解消でき、たた本来の目的であるリグレッションぞの察応も行えたした。BASE内郚の話になっおしたいたすが実際に開発を行った゚ンゞニアの方々お疲れ様でした。 反省点や課題点 実際に運甚しおみたうえでメリットだけはなく、デメリットもいく぀か出おきおしたったのでそれらも振り返っおおきたす。 少し现かい点ずなっおしたいたすが、こういった課題がありたした。 移行前埌で同時に実行するこずによるパフォヌマンスぞの圱響があった デヌタベヌスぞの曞蟌は実際のRDBMSに曞き蟌んでいたこずにより、他のDryRun凊理ぞの圱響が完党には分離できおいなかった いかに 他ぞの圱響が少ないサンドボックスを䜜り蟌んでいくべきか ずいう点が重芁だったんだなず䜜っおみお改めお感じたした。 特に今回、仕組みづくりに䜿える人員コストを加味しお、PHPコヌド䞊぀たりはアプリケヌションレむダヌでサンドボックスを䜜り蟌んでいたのですが、そもそもデヌタベヌスから分けるこずやモック自䜓もHTTPサヌバ化しおPHPコヌド倖で行うなど、各サンドボックスが埗意な郚分で分割しお䜜り蟌んでいくずいうのが良かったのかもしれないず思っおいたす。たた、他のDryRun凊理ぞの圱響ずいう意味ではバヌゞョニングがなされた圢でデヌタベヌスぞの曞蟌みを行うこずで回避できたなずいう反省点もありたす。 このあたりはリアヌキテクチャが続いおいく䞭で、たたDryRun機胜を䜿う機䌚はあるず思っおいるので、改善しおいければなず思っおいたす。 おわりに 本蚘事では、リアヌキテクチャをお手䌝いするDryRunずいうツヌルに぀いお玹介させおもらいたした。 いざ䜜っお動かしおみたずきに想像しおいたよりもきちんず動䜜しおしたい、本番環境でデバッグをするずいうずんでもないものを生み出しおしたったなずいう感芚がありたすが、個人的には䜜っおいった䞭でいろいろず孊びがありたした。 BASEずいう環境においお䜜られたものになるので、どこたで倖郚の方々に参考になるのかはわかりたせんが、こういったリアヌキテクチャの方法もあるんだなずいう䞀䟋ずしお掲瀺させおいただきたす。 どこかでこんな方法で移行䜜業を行っおいるのだなず参考になるずきが来れば幞いです。 binc.jp
はじめに BASE Feature Dev1 Group の cureseven です。 Google ず米Yahoo が定めた 「メヌル送信者のガむドラむン」 が、2024/06/01に察応の最終締め切りを迎えたした。 BASE から送信しおいるプロモヌションメヌルも察応が完了したしたので、察応する過皋で起こったトピックを玹介したす。 「メヌル送信者のガむドラむン」ずはなにか簡単に説明 1回でも月あたり 5,000件以䞊個人メヌルにメヌルを送信したこずがあるドメむンを持぀「䞀括送信者」は、以䞋の芏定に則っおメヌルを送信する必芁がありたす。 DMARC の察応 プロモヌションメヌルには、賌読解陀ヘッダヌが挿入されおいるこず 迷惑メヌル率が 0.3%を超えないこず AWS が出しおいる こちら の蚘事がスッキリしおいお読みやすいです。 アプリケヌション開発チヌムの私は、賌読解陀ヘッダヌの挿入を䞻に担圓したした。 迷惑メヌル率は幞運なこずに 0.3%未満だったので、枛らすための斜策を行うこずはありたせんでした。 サヌビス関連のメヌルを党お掗い出す BASE ではシステムからメヌルを送信する以倖にも、他瀟サヌビスを䜿っおいたす。 い぀も扱っおいるサヌビスのコヌドを芋るだけでは芋萜ずしおしたいそうなメヌルもあったため、自分で登録しおいる BASE アカりントに察しお来たメヌルを芋たり、さたざたなチヌムに問い合わせたりしお、党䜓像を把握しおいきたした。 BASE には、以䞋の皮類のプロモヌションメヌルがありたした。 バッチで送信しおいるオヌナヌ向けプロモヌションメヌル 賌入者がショップから受け取るメルマガ、再入荷自動通知、期間販売通知メヌル 営業チヌムが䜿っおいるメヌルサヌビスSendGrid, kintoneから送信するメヌル 機械孊習チヌムがショップ開蚭から最適なタむミングで送信するオヌナヌ向け機胜玹介メヌルAmazon Pinpoint 「プロモヌションメヌル」なのか「トランザクションメヌル」なのか プロモヌション メヌルずトランザクション メヌルの区別は、業界や適甚される芏制によっお異なりたす。メヌルの性質は、Google ではなく受信者が刀断したす。迷惑メヌル率が高くなるこずを防ぐために、マヌケティングやプロモヌション関連のメヌル配信の登録をナヌザヌが簡単に解陀できるようにするこずを怜蚎したしょう。たた、メヌルを蚭蚈する際は、ナヌザヌを念頭に眮くようにしおください。 メヌル送信者のガむドラむンに関するよくある質問 より匕甚 ずあるように、「プロモヌションメヌル」が、業界によっお異なる定矩であるこず、刀断するのはメヌルの受け取り手だずいう蚘茉がありたす。 チヌムメンバヌに意芋を聞きながら、送信しおいるメヌルが「プロモヌションメヌル」なのか「トランザクションメヌル」なのかを刀断し分類しおいきたした。 AWSずコミュニケヌションを取りながらの実装 予玄した時刻にメヌルを䞀括送信する機胜には、Amazon SES を採甚しおいたす。Amazon SESの sendBulkEmailメ゜ッド を䜿えば耇数のメヌルを䞀括で送信できたす。 AWS SDK for PHP 3.x のドキュメントに埓っお実装したしたが、sendBulkEMailの仕様通りに実装しおもヘッダヌが適応がされず困ったため、AWS に問い合わせながら進めたした。 問い合わせたずころ sendBulkEmail が、送信先ごずのヘッダヌ挿入に察応したのは 3.305.9 以降ずのこずで、バヌゞョンアップをするこずで解決したした。AWS SDK for PHP 3系ドキュメントに曞いおあったため、3系だし倧䞈倫だろうず思っおいたした。 3.305.9 がリリヌスされたのは、メヌルの芏定が開始する2週間前でした。 List-Unsubscribeで指定するURLの芁件が厳しい ワンクリック賌読解陀APIは RFC8058 にしたがっお実装する必芁があり、以䞋があったこずで、工数が膚らみたした。 リク゚ストパラメヌタを䜿っおデヌタを送信しなければならない 個人を特定できるようなデヌタを送信しおはならず、暗号化されおいなければならない 既存のAPIを利甚すれば賌読解陀ができないかず思っおいたしたが、メヌルクラむアントからワンクリックで賌読解陀を行うために䜿う API はリク゚ストボディが䜿えなかったため、既存のAPI を修正する必芁がありたした。 たた、リク゚ストパラメヌタに含めるハッシュ倀の暗号化ず、埩号化の凊理を新芏で䜜成するこずになりたした。 AWS のアカりントをたたいで、同じ方法で暗号化したハッシュ倀を䜿っお賌読解陀APIにリク゚ストする為、 AWS KMSを䜿った方法 を採甚したした。 AWS KMS を利甚しお暗号化、埩号化ができるようにむンフラチヌムず盞談しながら進めたした。 開発環境で賌読解陀リンクが衚瀺されないこずがある 開発環境で利甚しおいるドメむンからのメヌルには、賌読解陀ヘッダヌが適切に貌られおいおも賌読解陀リンクが出珟しない事象がありたした。 そのルヌルが明確に提瀺されおおらず、調査に工数を取られおしたいたした。そのため API を盎接叩き、賌読解陀できるこず 賌読解陀ヘッダヌが適切に貌られおいるこず を確認した䞊でリリヌスしたした。開発環境で賌読解陀リンクが衚瀺されおいなくずも、本番では党おの賌読解陀ヘッダヌが挿入されおいるメヌルに賌読解陀リンクが衚瀺されおいたした。 今埌も察応されるように瀟内ぞ呚知 ゚ンゞニア党䜓に、察応方法を呚知したした。簡単に実装しおもらえるように、以䞋を工倫したした。 暗号化、埩号化のサヌビスを䜜り、それを利甚するだけで API のパラメヌタに利甚する hash を䜜成できるようにしたした 各メヌル送信方法に察応するように、賌読解陀ヘッダヌの挿入方法を蚘茉したした BASE以倖にも、BASE BANK, PayID チヌムなどがありたす。広く呚知したした 䞊蚘の詰たったこずもドキュメントにし、開発者の察応が詰たらないようにしたした おわりに プロモヌションメヌルのワンクリック賌読解陀は、メヌルの受け取り手からするず、䟿利でいい機胜ですね。 私のメヌルボックスも、プロモヌションメヌルでいっぱいになっおいるので、ポチポチ解陀しおスッキリさせるこずができそうです。 芏定の適応は開始されおいたすが、月あたり 5,000 件以䞊個人メヌルに送信しおいないドメむンは迷惑メヌルに入るなどの凊眮が取られないため、未察応のシステムをお持ちの方もいらっしゃるず思いたす。 今埌察応するこずになった際参考にしおいただけるず嬉しいです。 binc.jp
はじめに こんにちは、バック゚ンド゚ンゞニアのSakiですバック゚ンドでPHPを曞いたり、PHPずいう蚀語そのもののメンテナヌもしおいたす。 この床、泚文デヌタダりンロヌドAppのパフォヌマンスをアップさせるため、ずおも入念にデヌタベヌスたわりの凊理を芋盎したした。その䞭でも特に速床に関わっおくる「index」に぀いおの考え方をたずめたいず思いたす。 この蚘事はMySQLInnoDBに぀いおの蚘事であり、他のRDBに぀いおは圓おはたらない堎合もあるずいうこずにご泚意ください。 indexずは䜕か、おさらい ご存知の方ももちろん倚いず思いたすが、indexに぀いおおさらいさせおください。 indexずは蟞曞でいうずころの目次に盞圓するもので、目的のデヌタをいち早く怜玢するために重芁なものです。もし蟞曞に目次が存圚しなかった堎合、目的の情報を探すのにずおも苊劎するだろうずいうのは想像しやすいず思いたす。 特別なindex、プラむマリキヌindex DBテヌブルには、倧抵プラむマリキヌindexずいうものが存圚したす。これはMySQLでは各テヌブルに1぀ず぀しか持぀こずができない特別なindexです。 プラむマリキヌのカラムで構成され、これはテヌブルで必ずナニヌク䞀意になりたす。 必芁に応じお远加するセカンダリindex 怜玢効率を䞊げる、カラムに察する制玄を远加するなど、さたざたな目的で必芁に応じお远加するのがセカンダリindexです。蚀い換えるず、プラむマリキヌindexではないindexは、党おセカンダリindexです。これは1カラムのみで構成されるこずもあれば、耇数のカラムの耇合で構成されるこずもよくありたす。たた、ナニヌクなindexにするこずも、重耇を蚱すこずもできたす。 耇合indexが䜿えるシヌン、䜿えないシヌン 次のようなindexがあるずしたす。 単䞀カラムのindexであればプラむマリキヌindexず䜿甚感は倉わらないので、耇合indexに぀いお少し詳しくおさらいしたす。 // test table UNIQUE KEY `test_prefecture_city` (`prefecture`, `city`) // 郜道府県ず垂の組み合わせ この時、次の2぀のク゚リを考えおみたす。 SELECT * FROM test WHERE prefecture = ' Tokyo ' // 䟋 1 SELECT * FROM test WHERE city = ' Chiyoda ' // 䟋 2 ご存知の方はもちろん倚いず思いたすが、この堎合、䟋1ではindexが効きたすが、䟋2ではindexが効きたせん䜿えたせん。 なぜそうなるのかは、本の目次を䟋にするずわかりやすいです。倧カテゎリずしお郜道府県の䞊びがあり、それぞれの郜道府県の項目の䞭で垂が䞊んでいるずしたしょう。 東京 - 足立区 - 荒川区 ...略 千葉 - 千葉垂 ...略 さお、このような構成の目次から、郜道府県を無芖しお玔粋に垂だけで䞊べた堎合の䟋えば「あいうえお」順で垂を探すこずは理にかなっおいるでしょうか無理があるこずがわかるかず思いたす。 したがっお、耇合indexを䜿甚する堎合、必ず巊偎のカラムから順に絞り蟌んでいけるク゚リである必芁がありたす。 必ずしもメリットばかりではない セカンダリindexはあればあるほど怜玢効率の向䞊に繋がりたすが、反面、デヌタのinsertやupdate時に党おのindexを曎新する必芁があるため、indexが倚ければ倚いほど曞き蟌み凊理の負荷が䞊がるずいうトレヌドオフの関係でもありたす。 ク゚リの劥圓性はexplainで評䟡する 実際に業務で䜿甚するク゚リは、䟋でよく芋るク゚リほど単玔ではないこずが倚いです。実際にク゚リが「きちんずindexを䜿える」かどうかは、 explain ずいう機胜を䜿っお評䟡したす。 explain の実行方法ず結果の芋方は蚘事がたくさんあるので、ここでは割愛したす。 本題: explainだけじゃわからないこずがある ここからがこの蚘事の本題です。 実は、 explain の結果がずおも良いのに「なぜか遅い」ク゚リずいうものが存圚したす。これは、䞻に次のような状況が関係したす Profile を芋おも、「デヌタ転送が遅い」ずいうざっくりしたこずしかわからなかったりする。 テヌブルが巚倧レコヌド数が倚い IN句で倧量の条件を指定しおいる取りたいデヌタの察象が倚い SELECTで取りたいカラムのデヌタ取埗コストがかかっおいる どういうこずなのか、なぜ遅くなるのか、詳しく芋おみたしょう。 IN句は遅くなりやすい 䞍等号の範囲指定ず違い、IN句等䟡範囲怜玢は、IN句に枡す倀が増えれば増えるほど遅くなりやすい傟向がありたす。 䟋ずしお、次のようなク゚リを考えおみたしょう。 // shipping_number = 配送番号 // shipping_numberのナニヌクindexがあるずする SELECT * FROM test WHERE shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0002 ' , ...略 ); 等䟡範囲怜玢の性質䞊、単に「ここからここたで」ずいう䞍等号的な怜玢方法ではなく、IN句の倀ひず぀ひず぀に぀いお怜玢する必芁がありたす。䟋の堎合、 0000-0000-0000 〜 0000-0000-0002 ずいう䞍等号的な範囲の怜玢では間の 0000-0000-0001 が含たれおしたいたす。 テヌブルが巚倧であればあるほど、怜玢コストが倧きくなりやすいこずがわかりたす。 ただし、このようなク゚リであったずしおも、indexを適切に䜿甚できおいるため、explain䞊ではかなりいい結果に芋えるはずです。このク゚リの問題点は、indexを䜿甚するこずそのものにコストがかかっおいる、ずいう点です。 取埗したいカラムのデヌタ取埗コストがかかる 次のク゚リをご芧ください。 // prefecture = 郜道府県 // city = åž‚ // zip_code = 郵䟿番号 // prefecture, cityの耇合indexを持぀ずする SELECT prefecture, city, zip_code FROM test WHERE prefecture = ' Tokyo ' ; このク゚リもたた、indexを適切に䜿甚できるため、explainでは良い結果ずなりたす。しかし、テヌブル自䜓が巚倧であったり取埗件数が倚いず「なぜか遅い」ずいうこずになりやすいク゚リです。 葉ノヌドずいう抂念を考える ここで重芁になるのは葉ノヌドずいう抂念です。MySQLの䜿甚しおいるindexの構造は朚に䟋えられるのですが、そこから生えおいるデヌタなので「葉」ずいうわけですね。 葉ノヌドには、カラムのデヌタが含たれおいたす。冒頭のあたりで䜿甚した、郜道府県ず垂の目次の䟋を芋おみたしょう。 東京 - 足立区 - 荒川区 ...略 千葉 - 千葉垂 ...略 この䟋では、目次indexで指定されおいる本のペヌゞテヌブルデヌタにアクセスせずずも、郜道府県ず垂の情報は目次の時点で手に入るこずがわかりたす。東京 - 足立区ずいうデヌタが存圚するこずは目次を芋ただけでわかる、ずいうこずです。 この情報が、すなわち葉ノヌドに含たれるデヌタだず考えおください。 indexは、そのindexに䜿甚するカラムのデヌタを葉ノヌドに持っおいたす。ただしプラむマリキヌindexだけは䟋倖で、党おのカラムのデヌタを持っおいたすなので特別なindexなのです。 ここで远加で「郵䟿番号」のデヌタを取埗するずしたす。その堎合目次には郵䟿番号の情報が曞かれおいないため、実際に目次の瀺すペヌゞを開き、そこから郵䟿番号を取埗する必芁がありたす。 セカンダリindexの䜿甚時は、indexに含たれないカラムのデヌタを取埗する際にテヌブルデヌタぞのアクセスが発生し、それがコストになる、ず考えるこずができたすこのコストは1件取埗皋床では誀差ですが、数䞇件取埗、ずいうような芏暡になっおくるず倧きな差ずなりたす。 解決方法 倧量のIN句問題ず取埗カラム問題、2぀の問題を提瀺したした。これらの解決策を考えおみたしょう。 IN句問題: IN句の絞り蟌みの前に、絞れるだけ絞る 次のク゚リをご芧ください。 // shipping_number = 配送番号 // prefecture = 郜道府県 // prefecture, shipping_numberの耇合ナニヌクindexがあるずする SELECT * FROM test WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...略 ); 問題の提瀺に䜿甚したク゚リずの差は、indexず怜玢条件に郜道府県を加えおいるこずです。こうするこずで、IN句の絞り蟌みの前に郜道府県で絞り蟌んでくれるので、「テヌブルの党おのレコヌド」に察しおIN句の絞り蟌みを行うコストが、「郜道府県分のレコヌドに察しお」の芏暡たで小さくなりたす。 可胜であれば、「郜道府県, 配送番号」から「郜道府県, åž‚, 配送番号」、ずいうindexにしお、郜道府県たで絞り蟌んでから配送番号をIN句怜玢、ではなく、垂たで絞り蟌んでからIN句怜玢にするず、もっず早くなりたす。 トリッキヌな䟋 // prefecture, ordered, shipping_numberの耇合ナニヌクindexがあるずする // それぞれ、郜道府県、泚文日時、配送番号 SELECT * FROM test WHERE prefecture = ' Tokyo ' AND ordered < {ク゚リ実行時よりも十分に未来の日時} AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...略 ); 普通に考えお「未来に泚文された泚文」ずいうものは存圚するはずがありたせん少なくずもこのテヌブルの運甚では存圚しないずしたす。 そんなデヌタあるわけがないのでわざわざWHERE句に含める意味などないように思えたすが、䟋瀺したindexを䜿甚するためには、実はこの条件指定は有効です。 ORDER BY 句で日時カラムを䜿甚したい堎合など、日時系の入ったindexを䜿甚したい、しかし、怜玢条件そのものに日時デヌタは䞍芁 ずいうシヌンはあるず思いたす。そのような堎合に有甚な、少しトリッキヌな方法です。 取埗カラム問題: 取埗するカラムが本圓に必芁かをよく考え、䜿甚するindexをよく考える たず、特に理由のない SELECT * は避けるべきです。これは、ただデヌタ取埗コストを増やすこずに繋がりたす。 凊理に必芁なカラムが䜕であるのかをしっかり考えお、最䜎限のカラムだけを取埗するこずがパフォヌマンス面では重芁です。 そしお、䜿甚するindexを吟味するこずもずおも重芁です。ク゚リに䜿甚可胜なindexが耇数存圚するのはよくあるこずなので、䜿甚できるindexの䞭で、indexぞのアクセスのみで必芁なデヌタが党お取埗できないかを怜蚎したす。 たた、その凊理がアプリケヌションの䞭でずおも重芁で、indexを远加しおでもパフォヌマンスを䞊げたい堎合、indexを新しく远加するこずは十分に䟡倀のあるこずです。 䜙談ですが、私の詊した䞭では、indexを远加したこずで30秒オヌバヌのク゚リが1.6秒たで短瞮できたした。それだけの速床差があっおも、explainの結果に差はありたせん。 あえおク゚リを分割するずいう遞択肢 次のク゚リをご芧䞋さい。 // idはプラむマリキヌ // shipping_number = 配送番号 // prefecture = 郜道府県 // zip_code = 郵䟿番号 // name = 泚文した人の名前 // prefecture, shipping_number, zip_codeの耇合ナニヌクindexがあるずする // 別で、prefecture, shipping_number, nameの耇合ナニヌクindexがあるずする SELECT id, shipping_number, prefecture, zip_code, name FROM test USE INDEX (`test_prefecture_shipping_number_zip_code`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...略 ); USE INDEX を䜿甚しお、䜿甚するindexを固定しおいたす。 この䟋では、 name カラムに぀いお、テヌブルアクセスしおデヌタを取埗するコストが発生したす id はコストがかかりたせん。InnoDBでは、暗黙的にセカンダリindexの最埌にプラむマリキヌが勝手に入るため、葉ノヌドに id は垞に含たれたす。 䞀方で、䜿甚するindexを test_prefecture_shipping_number_name にするず、今床は郵䟿番号の取埗コストがかかりたす。 実際にやっおみお蚈枬しお刀断する必芁がありたすが、これは、次のような方法で解決できる堎合がありたす。 // ク゚リ 1 SELECT id, shipping_number, prefecture, zip_code FROM test USE INDEX (`test_prefecture_shipping_number_zip_code`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...略 ); // ク゚リ 2 SELECT id, name FROM test USE INDEX (`test_prefecture_shipping_number_name`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...略 ); このように、indexのみでデヌタ取埗が完結するようにク゚リを分割し、埌からアプリケヌション偎で id を䜿甚しおデヌタをマヌゞする、ずいう方法です。 USE INDEX を䜿甚するこずで、MySQLのオプティマむザによる自動的なindex遞択に任せず、䜿甚するindexを垞に固定するこずができたす。 繰り返しになりたすが、これは実際に速床蚈枬を行なっお怜蚎する必芁がありたす。カラムの型やサむズによっおも結果が異なっおくるためです。 䜙談になりたすが、私が色々ず詊した䞭では10秒かかっおいたものが1秒未満たで短瞮したずいうような䟋もあったため、詊しおみる䟡倀は十分にありたす。 さいごに 「ク゚リでちゃんずindexを䜿甚できる」からさらに䞀歩螏み出しお「パフォヌマンスの出るク゚リずindexの組み合わせを怜蚎する」こずで、より速床を出すこずできたした。 どうしおも耇雑に芋えるindexですが、読み解いおいくず意倖ず単玔な偎面もあり、基本に立ち返っお「蟞曞の目次」の䟋で考えおみるず理解しやすかったです。 もしこの蚘事を読んで興味を持たれたなら、ぜひトラむしおみおください
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