こんにちは！BASE PRODUCT TEAM BLOG 編集部です。みなさまそろそろ年の瀬ですが、いかがお過ごしでしょうか。 今年も恒例のBASEメンバーによるアドベントカレンダーを開催します！ 毎年公開しているアドベントカレンダーも今年で7回目を迎えます。 過去の様子 2023年のアドベントカレンダー 2022年のアドベントカレンダー 2021年のアドベントカレンダー 2020年のアドベントカレンダー 2019年のアドベントカレンダー 2018年のアドベントカレンダー 今年も1日1記事に限定せずたくさんのバラエティ豊かな記事を公開する予定です。 公開され次第以下のカレンダーも随時更新していきますので、ぜひお楽しみに！ 日付 執筆者 タイトル 12/1 @fshin2000 プロダクトの開発生産性について考える 12/2 ＠Panda_Program 「読書会のジレンマ」を克服する: 成果を生むアクティブラーニング勉強会の実践法 12/3 @zan_sakurai Terraform Provider for HatenaBlog Members を使ってみました。 12/4 @ikechen 若手エンジニアが BASE 入社 6 ヶ月目で感じていること 12/5 @ohiro88 【入社エントリー】BASE に入社して 2 ヶ月を振り返る 12/6 asakoya 妊娠・出産・育休を経て Hopeful に働いている話 12/7 Torata 整理整頓のメソッドでお問い合わせ業務の改善をした話 12/8 @yuna_miyaa チーム開発を進めるために意識していること 12/9 @kondo プロジェクトを成功させるための工夫 12/10 @ykagano カート開発を加速させる！効率的なドキュメント管理術 12/11 @gatchan0807 技術目線でみた、PAY.JP YELL BANKのおもしろいところをご紹介！ 12/12 @kitamuran Pay IDメンバーの個性がひかる お仕事環境紹介 12/12 @yusuke.saito 私のキャリアチェンジ：データ分析者からプロダクトマネージャーへ 12/13 @roothybrid7 Pay IDシステム移管プロジェクトの技術スタックの紹介 12/14 tac_tanden SLI/SLOの設定を進めるその前に、アラート品質の改善に取り組んだ話 12/14 @toshi-oliver 輪読会「ドメイン駆動設計をはじめよう」をプロジェクトチームで開催した話 12/15 @miyachin_87 Notion FormとAutomationを使って定型タスクの自動生成ツールを作ってみた 12/16 uenoka レポートシステムの安定稼働に向けた取り組み 12/16 @ysssssss98 ペアプログラミングの体験がすごく良かったので布教したい 12/17 @eijenson Jetpack Compose上でのconstraintLayoutの利用事例紹介 12/18 @meihei PhpStorm で PHPUnit をずっと実行している話 12/18 gonzaresu108 INFORMATION_SCHEMAを用いたBigQueryデータ監視 12/19 @ichi アジャイル組織のデザイナーがやってきたチームビルディングの話 12/19 kaneko20 Pay ID 3回あと払いの開発をきっかけに知る住所の味わい深さ 12/20 @gimupop 登壇やアウトプットを後押しするnote 12/20 noji_ma Next.jsのServer Actionとreact-hook-formでフォームを実装した 12/21 basems (仮)エンジニアと非エンジニアで足並み揃える PJ 進行 12/21 kuma プロダクトマネージャーは 「面白がり力」があると良い 12/22 bun タイトル未定 12/22 @zan_sakurai 今年の記事をふりかえってみた 12/23 @endu PHP Conference Japan 2024 に参加しました! 12/23 shotakeuchi 不均衡データにおけるROC曲線とPR曲線について 12/24 @simezi9 今、リモートワークについて思うこと 12/24 @u_hayato13 統括マネージャー(EM of EM)の仕事7選 12/25 dmnlk タイトル未定

はじめに こんにちは、Pay IDのフロントエンドエンジニアのnojiです。 普段はPay ID あと払いやPay IDのアカウント周りのフロントエンド開発を担当しています。 10月に Pay IDのアカウント編集画面 （ こちら ）をリニューアルしました。この記事では、そのリニューアルプロジェクトでNext.jsのApp Router / Server Actionを活用し、便利だと感じた点をご紹介します。 使用技術 Next.js 14（リリース当時のもの。現在は15になっています） React 18（リリース当時のもの。現在は19になっています） リニューアルの背景 今回のリニューアルは、PAY社が保有する「Pay ID」のデータおよびシステムをBASE社へ移管・再構築するプロジェクトの一環でした。 単なる移管に留まらず、デザインリニューアルを伴うため、PAY社で使用されていたVue.jsのコードは再利用せず、Next.jsでゼロから構築しました。 Next.jsを選定した理由： BASE社内での採用実績があり、安心して使用できること。 BASE以外でも採用事例が多かったり、近年のfrontendのトレンドをリードしていること また、新規アプリケーションの構築であることから、Next.jsのApp Routerを採用しました。（開発着手当初はNext.jsバージョン13でした） App Routerの活用 App Routerはディレクトリ構造がそのままURLパスとして反映されるほか、ファイル名によって役割が明確になる点が特徴です。 /app/〇〇 └ layout.tsx // pageをラップした共通画面(画面遷移で再レンダリングされない) └ template.tsx // pageをラップした共通画面(画面遷移で再レンダリングされる) └ error.tsx // エラー時の画面 └ loading.tsx // ローディング中の画面 └ not-found.tsx // notFound()がthrowされたときの画面 └ page.tsx // 実際のURLに対応するページ これをもとに以下のようなツリー構造で描画が行われます <Layout> < Template > < ErrorBoundary fallback = { < Error /> } > < Suspense fallback = { < Loading /> } > < ErrorBoundary fallback = { < NotFound /> } > < Page /> </ ErrorBoundary > </ Suspense > </ ErrorBoundary > </ Template > </Layout> 親ディレクトリのLayoutを子ページが自動的に引き継ぐため、レイアウト部分を共通化しやすいのが便利でした。 https://nextjs.org/docs/app/building-your-application/routing Route Groups 一方で、「URL階層は親子関係があるがレイアウトを切り替えたい」というケースでは、 Route Groups を活用しました。 Route Groupsはディレクトリ名を () で括ることで利用できます。 (a) └ hoge └ layout.tsx ← レイアウトA └ page.tsx (b) └ hoge └ layout.tsx ← レイアウトB └ fuga └ page.tsx /hoge ではレイアウトAを利用 /hoge/fuga ではレイアウトBを利用 このように適切にレイアウトを切り替えられるのが便利でした。 https://nextjs.org/docs/app/building-your-application/routing/route-groups Parallel Route 管理画面では、ダッシュボードのように 複数の情報を1ページに集約して表示 することが多く、特定のページで Parallel Routes を利用しました。 app └ @parallel └ hoge └ page.tsx // A情報 └ default.tsx └ default.tsx └ hoge └ page.tsx // B情報 @ で始まるディレクトリがslotとなり、同じ階層にある layout.tsx でpropsとして受け取ります。 default.tsxは初期読み込み時やページ全体の再読込中に一致しないスロットのフォールバックとしてレンダリングするファイルを定義しています。 何も表示させない場合はnullを返却するように定義しておきます。 // layout.tsx export default async function Layout ( { children , parallel , } : { children : React.ReactNode ; parallel : React.ReactNode ; } ) { return ( <> { parallel } // A情報 { children } // B情報 </> ); } この仕組みを利用し、A情報とB情報をそれぞれ別のページとして描画し、以下のように表示しました： /app/@parallel/hoge/page.tsx → A情報を表示 /app/hoge/page.tsx → B情報を表示 Parallel Routesの利用により、slotに分割されていることで各ページでの処理が少なくなったり、コードの可読性が上がるように感じました。 Parallel routeでもloading.tsxやerror.tsxを配置しておくだけでローディング処理やErrorBoundaryを利用できるので便利に感じました。片方エラーだったときのハンドリング等しやすい印象を受けました。 しかし、soft navigation時に前のParallelRouteのページが表示されたままの状態になることがあり、Client Componentでラップして、pathを見て出し分けするようにし、意図せず表示が残ってしまうことを防いでいます。 // MatchPathRenderer.tsx 'use client' ; export default function MatchPathnameRenderer ( { matches , children } : Props ) { const pathname = usePathname(); if (!matches || !matches. includes (pathname)) { return null ; } return <> { children } </> ; } // layout.tsx ... < MatchPathnameRenderer matches = { [ '/hoge' ] } > { parallel } </ MatchPathnameRenderer > { children } ... https://nextjs.org/docs/app/building-your-application/routing/parallel-routes Server Component / Server Actionの活用 Server側でのデータ処理周り 各Server Componentからサーバー側で非同期にデータフェッチが可能となり、データ管理が効率的に行えるようになりました。また、同じデータのフェッチ処理は自動的にキャッシュされるため、パフォーマンスへの影響も最小限に抑えられます。 さらに、App Routerの Suspense 処理(loading.tsx)を活用することで、サーバーから先にHTMLを返却し、高いユーザー体験を簡単に実現できるようになりました。 サーバー側で動作するため、機密情報やセキュリティに関わるデータも安全に取り扱うことが可能です。 クライアントからサーバーへのリクエスト周り 従来、クライアントからNext.jsのサーバーへリクエストを送る際には、 API Route を定義し、それを通じてAPIを実行する必要がありましたが、 Server Action を使用することで、クライアント側から直接サーバー側の関数を呼び出せるようになり、非常に便利に感じました。 // server action処理 'use server' ; export const action = async ( prevState : any , formData : FormData ) => { // server側処理 } // フォームコンポーネント 'use client' ; export default function Form () { const [ state , formAction ] = useFormState(action); return ( < form action = { formAction } > ... </ form > ) } https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations リダイレクト周り アカウント管理画面では、認証が必須のため、各URLで適切なリダイレクト処理が必要だったのですが、 Server Component や Server Action 内で redirect を利用することができます。 Server Component内でのリダイレクトはPage RouterでのgetServerSidePropsと似たような処理が実現できます。Server Component内にリダイレクト処理が書けるようになった部分は少し可読性が上がったように感じました。 // Server Component内 export default async function Page () { const session = await getSession(); // セッション取得処理 if (!session) { return redirect( '/login' ); } const { response , error } = getData(session); // データ取得処理 if (error. status === 401 ) { return redirect( '/login' ); } ... } Server Action内のリダイレクト処理については以前だとAPI Routeでクライアントにレスポンスを返してからその結果を見てページ遷移を行っていましたが、サーバー側で処理を完結させることができるため、リダイレクト先のページ表示が高速化されました。 // Server Action内 'use server' ; export const action = ( formData : FormData ) => { const session = await getSession(); // セッション取得処理 if (!session) { return redirect( '/login' ); } // API callなどサーバー処理 return { message : '成功しました' } ; } ; https://nextjs.org/docs/app/building-your-application/routing/redirecting キャッシュ周り Server Action でサーバーサイドの処理を実行した後、クライアントの情報（キャッシュ含む）を更新する際に revalidatePath を利用しました。クライアント側でレスポンスを受け取り、値に基づいてUIを更新したり、 router.push や router.refresh で明示的にページを遷移させる必要がなくなりました。 'use server' ; export const action = ( formData : FormData ) => { // API callなどサーバー処理 revalidatePath( '/hoge' ); return { message : '成功しました' } ; } ; https://nextjs.org/docs/app/building-your-application/caching#revalidatepath おわりに システムリニューアル時にNext.jsのapp router / server actionsを触ってみて便利だった部分を紹介させていただきました。 これからNext.jsを利用するプロジェクトの参考になれば幸いです 現在Pay IDではエンジニアを募集しているので、興味のある方は気軽にご応募ください。

はじめに こんにちは。BASE株式会社 Pay IDでiOSアプリエンジニアをしている kakkki です。 iOS版のPay ID ショッピングアプリ の開発を担当しています。 iOS版Pay IDアプリ(以下Pay IDアプリ)はリリースされてから9年以上、新機能開発を行いながら継続的に運用されています。普段の業務では機能開発を進める一方で、マルチモジュール化やStrict Concurrency対応、SwiftUIへの移行など継続的に技術的な改善に取り組んでいます。 Pay IDアプリ内に古くから存在する画面の多くはUIKitベースで実装されていますが、最近はSwiftUIで実装された画面が増えていくようになりました。そこで本記事では、 SwiftUIを導入する過程で直面した課題や取り組みについて 、約2年前から今日に至るまでの画面実装方針の変遷を3つのフェーズに分けながら紹介していきます。 特に長期間運用されているUIKitベースのアプリにSwiftUIを導入したいと考えているiOSエンジニアの皆様にとって、少しでも参考になれば幸いです。 フェーズ1 (2022年10月頃): Compositional Layouts × Diffable Data Source この時点では、複雑なレイアウトやデータ管理を効率化するためにiOS13から導入されたCompositional LayoutsとDiffable Data Sourceを採用していました。Compositional Layoutsにより、複雑なレイアウトでもセクションごとに設定できるようになりレイアウト実装の柔軟性が高まりました。また、Diffable Data Sourceによりデータの変更を即座にUIに反映できるようになり、データとUIの統一的な管理が可能となりました。 しかし、この時点ではSwiftUIは全く導入しておらずUIKitのみでの開発でした。UIKitは今でもバリバリ現役ですが、SwiftUIと比べてUI実装の速度が劣るケースもあり、後々開発効率などの観点からSwiftUIを導入していきたいという気持ちが強くなっていきました。 フェーズ2 (2023年10月頃): Compositional Layouts × Diffable Data Source × SwiftUI（UIHostingConfiguration） 次のステップとして、SwiftUIを小さくコンポーネント実装に留める形で導入していくことを試みました。 この時点では以下の図のようなイメージです。 具体的には、 UICollectionViewCell 内でSwiftUIを利用する方法です。以下のような UICollectionViewCell の共通実装を用意して、iOS16以上では UIHostingConfiguration 、iOS15では UIHostingController 経由でセル内のUIをSwiftUIで実装していくようになりました。 /// HostingCellの中身となるViewが準拠するプロトコル public protocol HostingCellContent : View { associatedtype Dependency init (_ dependency : Dependency ) } open class HostingCell < Content : HostingCellContent >: UICollectionViewCell { // TODO : iOS15サポートを切ったら削除する private let hostingController = UIHostingController < Content? > (rootView : nil ) override public init (frame : CGRect ) { super . init (frame : frame ) // TODO : iOS15サポートを切ったら削除する hostingController.view.backgroundColor = .clear hostingController.view.translatesAutoresizingMaskIntoConstraints = false } @available ( * , unavailable ) public required init ?(coder : NSCoder ) { fatalError( "init(coder:) has not been implemented" ) } public func configure (_ dependency : Content.Dependency , parent : UIViewController? = nil ) { if #available(iOS 16.0 , * ) { configureWithHostingConfiguration(dependency) } else { configureWithHostingVC(dependency, parent : parent ) } } /// iOS16以上ではUIHostingConfigurationを使う func configureWithHostingConfiguration (_ dependency : Content.Dependency ) { if #available(iOS 16.0 , * ) { contentConfiguration = UIHostingConfiguration { Content(dependency) } // デフォルトでマージンが設定されているので0にする .margins(.all, 0 ) } } // TODO : iOS15サポートを切ったら削除する /// iOS15以下ではUIHostingControllerを使う func configureWithHostingVC (_ dependency : Content.Dependency , parent : UIViewController? ) { guard let parent else { return } hostingController.rootView = Content(dependency) hostingController.view.invalidateIntrinsicContentSize() guard hostingController.parent == nil else { return } parent.addChild(hostingController) contentView.addSubview(hostingController.view) NSLayoutConstraint.activate([ hostingController.view.leadingAnchor.constraint(equalTo : contentView.leadingAnchor ), hostingController.view.topAnchor.constraint(equalTo : contentView.topAnchor ), hostingController.view.trailingAnchor.constraint(equalTo : contentView.trailingAnchor ), hostingController.view.bottomAnchor.constraint(equalTo : contentView.bottomAnchor ), ]) hostingController.didMove(toParent : parent ) } } セルの呼び出し側はセルの中身がどのように実装されてるかを知る必要はなく、従来の UICollectionViewCell を用いた開発と同様に実装することができました。この取り組みにより、セル内のUIをSwiftUIで宣言的に記述できるようになり、UI構築の開発速度が向上しました。 フェーズ2のSwiftUI導入時に直面した課題 しかし、フェーズ2の UICollectionViewCell 内にSwiftUIを埋め込む実装の方法だと、いくつかの課題に直面しました。 特に以下の要件を満たすために、実装が複雑化しやすいことが分かりました。 お気に入り状態を更新する際に、APIの結果を待たずに一時的にUIに反映したい ユーザーによるデータ更新操作およびUIへの反映処理が頻繁にある これらの要件を実現する過程で、次のような問題が浮かび上がりました。 @State による状態管理が可能なケースが限定される UIHostingConfiguration 内でSwiftUIビューを使用する際、 @State プロパティを外部から初期化すると問題が発生していました。具体的には、外部から渡された値で @State を初期化すると、セルの再利用時に状態がリセットされず、データの不整合が発生することがありました。 以下は簡略化したコード例です。 struct ItemView : View { @State private var isFavorite : Bool init (_ isFavorite : Bool ) { // 外部から渡された値で@Stateを初期化 _isFavorite = State(initialValue : isFavorite ) } var body : some View { // ... } } UICollectionViewCell 内でこの ItemView を使用すると、セルの再利用時に ItemView の init が再度呼ばれますが、 @State の値は初期化されず以前の状態を保持します。そのため、表示とデータの不整合が生じ、意図しないUIの挙動になります。 また、以下のようにSwiftUI内部で isFavorite を更新した際も、同様にUIに正しいデータが反映されないことがありました。 struct ItemView : View { @State private var isFavorite : Bool init (_ isFavorite : Bool ) { // 外部から渡された値で@Stateを初期化 _isFavorite = State(initialValue : isFavorite ) } var body : some View { Button(action : { // お気に入り更新APIを呼ぶ前に、スムーズにUIが更新できるように一時的に更新する isFavorite.toggle() // お気に入り更新APIをコール }) { // ... } } } これらの問題の原因は、 @State がSwiftUIのビューのライフサイクルに基づいて状態を管理するため、外部からの初期化と相性が悪いことにあります 。WWDC22にある Use SwiftUI with UIKit のセッションでは、以下のようにSwiftUIの外で保持されるデータを使用する際は @State , @StateObject といったプロパティラッパーは使うべきでないという言及がされています。 To store data that is created and owned by a SwiftUI view, SwiftUI provides the @State and @StateObject property wrappers. Since we're focused on data owned outside of SwiftUI, these property wrappers aren't the right choice. 引用: Use SwiftUI with UIKit (値を利用する箇所がSwiftUIの中に閉じているケースでは、 UIHostingConfiguration の中のSwiftUIで @State を利用しても期待通り動きます。) 当時、Pay IDアプリ内の多くの画面はMVPアーキテクチャで構成されていました。Presenterを知っているのは UIViewController のみです。つまりSwiftUIの外でデータを保持する構成にしていた以上、大半のケースでは @State を使用することはできませんでした。 SwiftUIビュー内で発生したイベント伝搬とデータ更新伝達の複雑化 セル内のSwiftUIビューでユーザーアクションが発生すると、それをPresenterに伝える必要があります。するとコールバックやデリゲートなど、なんらかの形でUIViewControllerを経由しないといけません。 // イメージ図(諸々簡略化して書いています) アプリユーザー ↓ ユーザーアクション(お気に入りボタンをタップなど) SwiftUI.View ( in UICollectionViewCell) ↓ ユーザーアクションの伝達 UIViewController ↓ ユーザーアクションの伝達 Presenter ↓ APIリクエストなどのハンドリング さらに、Presenterの処理の結果何かしらSwiftUI.Viewの中の表示を変える場合、Presenterの結果をまたSwiftUIビューに伝えないといけません。当然Presenterは直接SwiftUIビューを知ることはありません。そこで以下のようなフローでデータ更新を伝搬することになります。 // イメージ図 Presenter ↓ データ更新の伝達 UIViewController ↓ データ更新の伝達 SwiftUI.View ( in UICollectionViewCell) ↓ UIを更新 つなげるとこのようなフローになります。 // イメージ図 アプリユーザー ↓ ユーザーアクション(お気に入りボタンをタップなど) SwiftUI.View ( in UICollectionViewCell) ↓ ユーザーアクションの伝達 UIViewController ↓ ユーザーアクションの伝達 Presenter ↓ APIリクエストなどのハンドリング ↓ データ更新の伝達 UIViewController ↓ データ更新の伝達 SwiftUI.View ( in UICollectionViewCell) ↓ UIを更新 もちろんこのフローでもアプリを要件通り実装することは可能です。ですが、SwiftUIでUIを書いているとSwiftUIで実現しやすいデータバインディングの機構を取り入れて、上記のようなフローをよりシンプルにしたいと思うようになっていきました。 フェーズ3 (2024年7月頃): SwiftUI × Observationフレームワーク フェーズ2の UICollectionViewCell 内に埋め込む形でSwiftUIを導入した際に出てきた課題を解決するため、よりSwiftUIベースな実装方針を目指すことを決めました。ここでの構成が、現在新しい画面を実装する時に積極的に取り入れている形です。 SwiftUIとUIKit間の責務分離と整理 まず、状態管理とビジネスロジックをSwiftUI内部で完結させる実装方針に転換しました。また、レイアウトも今まではUIKit(Compositional Layouts)で実装していましたが、この部分もSwiftUIで実装するように変更しました。 UIKitは主に画面遷移を担当します。ナビゲーションバーなど一部UIを担当することもありますが、API通信などのデータ取得もSwiftUI内部(ViewもしくはViewが保持するViewModel)からRepositoryを参照するようになり、SwiftUIとUIKit間のデリゲート処理もかなり減りました。それによりビュー内で発生したイベント伝搬・データ更新の複雑だったフローの見通しも改善されました。 View+コンポーネントは、言わずもがなSwiftUIです。View+画面遷移の部分は、引き続きUIKit(UINavigationController)で行います。View+レイアウトについては、UIHostingControllerを利用してUIViewControllerにSwiftUIで書いたレイアウト実装を埋め込んでいます。 そしてView+ロジック・状態管理については、Swift5.9, iOS17以上で利用できるObservationフレームワークを導入することにしました。 PerceptionによるObservationフレームワークの導入 しかし、Pay IDアプリはまだiOS16.2以上をサポートしています。そこで Point-Free が公開してくれている、Observation相当のバックポート実装を提供してくれる swift-perception を利用します。swift-perception(以下Perception)ライブラリはiOS17以上であればObservationフレームワークのAPI(withObservationTracking)を呼び出し、iOS17未満ならObservationフレームワークの挙動を模倣した実装が呼ばれます。 SwiftUI上の状態管理において、Perception経由でObservationを導入するか、Combine製のObservableObjectプロトコルを利用するか悩みましたが、ObservableObjectよりもObservationの方が以下の点から使い勝手が良いと判断しました。 子ビューの差分更新において不要に親ビューの差分更新が走らない 値(クラス)を入れ子にした場合、ネストしたクラスの値の変更を検知できる Perceptionを利用する場合、追跡したい値を保持するオブジェクトを @Perceptible クラスとして宣言します。そして @Perceptible クラスへのアクセスを持つViewを WithPerceptionTracking Viewでラップします。 import Perception struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { // WithPerceptionTrackingで囲む必要がある // TODO : iOS16切ったらWithPerceptionTrackingラップを外すだけでいい WithPerceptionTracking { VStack { Text(viewModel.count) Button( "Increment" ) { viewModel.increment() } // ... } } } } @Perceptible // TODO : iOS16切ったら@Observableに変更する @MainActor final class HogeViewModel { var count = 0 func increment () { count += 1 } // ... } // UIHostingControllerでSwiftUI.ViewをUIViewControllerの中身として埋め込む final class HogeViewController : UIViewController { override func viewDidLoad () { super .viewDidLoad() let vc = UIHostingController(rootView : HogeScreen ()) self .addChild(vc) self .view.addSubview(vc.view) vc.didMove(toParent : self ) vc.view.translatesAutoresizingMaskIntoConstraints = false vc.view.topAnchor.constraint(equalTo : view.topAnchor , constant : 0 ).isActive = true vc.view.leftAnchor.constraint(equalTo : view.leftAnchor , constant : 0 ).isActive = true vc.view.rightAnchor.constraint(equalTo : view.rightAnchor , constant : 0 ).isActive = true vc.view.bottomAnchor.constraint(equalTo : view.bottomAnchor , constant : 0 ).isActive = true // ... } } このようにSwiftUI上のデータバインディングが可能になったおかげで、データの変更が発生した際に @Perceptible クラスの値を更新するだけで済み、UIへの反映がとても楽になりました。 Perception利用時の注意点 Perceptionを使う上で特に重要な注意点の一つとして、 ForEach などViewを返すクロージャーの中で @Perceptible な値を参照する場合は、クロージャーの中でも別途 WithPerceptionTracking で囲む必要があります。囲っていないと、値の更新があってもクロージャー内のViewには反映されません。 struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { WithPerceptionTracking { ForEach(Array(hogeViewModel.items.enumerated()), id : \\.offset) { index, item in // WithPerceptionTracking { // ❌ hogeViewModel.itemsの一部のnameが更新されても変更を追跡できていない Text(item.name) // } } } } } @Perceptible final class HogeViewModel { /* ... */ } その理由は、 ForEach のクロージャーがViewのbody本体と同じタイミングで呼び出されるわけでなく、Viewのbody本体が呼び出された後に ForEach クロージャーが呼ばれることにあります。そのため ForEach 自体を囲った WithPerceptionTracking の中には ForEach クロージャーの中身のViewは含まれていないので、 @Perceptible のプロパティを追跡するためのViewの登録処理が動いていないのです。 以下のように、ForEachクロージャーの中もWithPerceptionTracking囲っていれば追跡可能です。 struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { WithPerceptionTracking { ForEach(Array(hogeViewModel.items.enumerated()), id : \\.offset) { index, item in // ForEachのクロージャーの中もWithPerceptionTrackingで囲ってるので、 // 値の変更を追跡できてる // ⭕️ WithPerceptionTracking { Text(item.name) } } } } } @Perceptible final class HogeViewModel { /* ... */ } また、自作のViewにViewBuilderを渡す際も注意が必要です。 以下のコードだと、CustomContainerに渡すViewBuilderの中身が WithPerceptionTracking で囲まれていません。body本体が呼び出されるタイミングではViewBuilderの中はまだ呼び出されてないので、 Text(hogeViewModel.count) の箇所はbody直下の WithPerceptionTracking の範囲外になってしまいます。 // ViewBuilderを渡す側 struct ContentView : View { let hogeViewModel = HogeViewModel() var body : some View { WithPerceptionTracking { CustomContainer(title : "Custom Container" ) { // ViewBuilderの中身 Text(hogeViewModel.count) } } } } // ViewBuilderを受け取る側 struct CustomContainer < Content : View >: View { let title : String let content : () -> Content init (title : String , @ViewBuilder content : @escaping () -> Content ) { self .title = title self .content = content } var body : some View { VStack() { Text(title) content() .padding() } } } @Perceptible final class HogeViewModel { /* ... */ } なので先ほどと同様に、ViewBuilderの中身もWithPerceptionTrackingで囲む必要があります。 // ViewBuilderを渡す親View struct ContentView : View { let hogeViewModel : HogeViewModel var body : some View { WithPerceptionTracking { CustomContainer(title : "Custom Container" ) { // ViewBuilderの中身をWithPerceptionTrackingで囲む WithPerceptionTracking { Text(hogeVieModel.count) } } } } } おわりに 本記事では、古くからあるUIKitベースのiOSアプリにおいてSwiftUIを導入する過程で直面した課題や取り組みについて紹介させていただきました。 前述した通り現在のPay IDアプリのサポートバージョンはiOS 16.2以上であり、次回のサポートバージョン整理のタイミングでiOS17以上のサポートとする可能性があります。その時はPerceptionから純粋なObservationへの移行もあるので、その取り組みの中で新たな気づきがあればまたどこかで紹介させていただければと思います。 また、新規実装はもちろんのこと、古いUIKitベースの画面に対してSwiftUIベースな実装方針に基づいてリアーキテクチャなどもチームで進めていきたいと思います。 最後になりますが、Pay IDでは随時メンバーを募集しています。ご興味のある方は気軽にご応募ください！ open.talentio.com

はじめに はじめましての人ははじめまして、こんにちは！ 先週木曜日ぶり です！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回は 11/23（土） に開催された 「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」にスポンサリング・スポンサートークをしました！というご報告記事になります！ スポンサリングしたイベントについて 今回スポンサリングしたイベントは「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」というイベントで、スナック・ドリンクスポンサーの枠でスポンサリング・参加しました🙋 また、合わせてスポンサートークもさせていただきました！（詳細は後述） devx.jp DevX / Raycast Community Japan さんと 一般社団法人シンギュラリティ・ソサエティ さんの共催のイベントで、Fullstack AI Devの名前も冠している通り、AIを使った生産性向上、価値のあるプロダクトの提供に関心が強い方々の発表をたくさん聞くことができました！ また、Raycast Summitの名前も冠している通り、Raycastを使った便利な機能をはじめ、Raycast Proで使えるAI機能の紹介などなど「えっ、明日からRaycastもっと使いこなしたい！」となる発表や知見をたくさんお聞きすることができました！ スタッフの皆さん、登壇者の皆さんをはじめ、たくさんの方のご尽力のおかげでこのイベントが実施できたのだと感じています。このような素敵なイベントにスポンサーという形で関わらせていただきまして、本当にありがとうございました！ この場を借りて感謝をお伝えできればと思います！ スポンサートークでお話しした内容について 今回のスポンサートークでは、SLM（Small Language Model）の一つ、Gemini NanoがChromeブラウザに搭載されるようになり、どんなことに使えるのかについて、お話をさせていただきました！ 久しぶりのオフライン登壇で緊張しながら発表していた時の図 オンラインでも配信されており、100数十名に見ていただいていた時の図 登壇資料に関してはDocswellにて公開していますので、ぜひ合わせてご覧いただけますと幸いです！ www.docswell.com おわりに 以上、BASE BANKチームとして、「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」に協賛させていただきました！というご報告でした！ 今回のイベントはBASE BANKチームとして「エンジニアイベントに協賛させてください！」という発信を見てお声がけいただいたものでして、引き続きBASE BANKチームとしては規模に関わらずエンジニアイベント・コミュニティイベントにスポンサーとしてご協力させていただきたいと思っております！ 詳細は以下の記事にまとまっていますので、もしご興味あればぜひご覧ください！ devblog.thebase.in （私個人としてはスポンサートークの他、どんどん登壇もやっていきたいので、もし この辺りに書かれている発表内容 にピンとくるものがあればぜひご連絡ください！という宣伝もこっそりと…） また、BASE BANKチームはエンジニアをはじめ、各職種を大募集中ですので、もしご興味あればお気軽にカジュアル面談やXなどでお声がけください！ binc.jp

はじめに はじめましての人ははじめまして、こんにちは！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回はBANKチームの中で職種横断で行っている「月次会」というLT会について紹介させてください！ この月次会（LT会）を毎月実施していることで、チームにとってどんなメリットがあるのか？や、実施における工夫を知っていただき、皆さんのチームでもスモールスタートで実施してみていただけるととっても嬉しいなと思っています！ また、今回は記事のタイトルの通り、その月次会で半年間（実際には2月~10月の計8回）、毎月様々なお題でLTをしたので、ついでにその内容とそこから得た知見もすこし紹介させてください！ もし、開催予定の技術イベントのテーマで合致しそうなタイトルがあれば X などで気軽にお声がけいただけると嬉しいです！ そもそも月次会とは？ 2022年11月からBANKチームで開始され、開始当時から以下のような想いと目的で実施されきたものです。 （この時期は僕はまだBANKチームにはおらず、BASE側のCRM機能の改善をしていたりしました） 社内のNotionには以下のように月次会についてまとまったポータルが誰でも見られる場所に設置されており、事業責任者の柳川（ @gimupop ）さんが目的を言語化して書いてくれていたり、ここに資料へのリンクがまとまったNotion DBが設置されていたりします。 この会に関しての情報がまとまったNotionページのキャプチャの一部 （BANKチームでのこの取り組みの前進になった「Product BEER BASH」という社内イベントとそれに対する柳川さんのアツい思いは以下のnoteにまとまって公開されているので、ぜひこちらもご覧ください。 👉 https://note.com/gimupop/n/nb950488d8de8 ） 月次会自体は上記Notionにも書かれているように 「自己開示」と「アウトプットをすることによるPDCAの体現」 を目的として実施されています。 そのため、発表する内容は仕事に関係していなくてもよく、フォーマットも自由（スライドを作ってもいいし、Lookerダッシュボードを見せながらでもいいし、Notionを上から説明していく形でも良い）なので、それぞれ5~10分間でかなり自由に発表しています。 今年からは会の運用を 「ローテーションのメイン枠（発表10分+感想・質問5分）× 4~6人」 「任意発表者枠（発表5分のみ）× 1~3人」 という2部構成に変えたので、発表の頻度としてはだいたい3ヶ月に1回、自分の番が来るぐらいのスパンで回っています。 実際に過去にあった発表だと以下のようなものがあります タイトル: 古着の話 古着の分類方法などの基礎知識や、古着屋さんがECに対してどんな課題感を持っているか？という知見の共有など タイトル: 今、恐竜が熱い お子さんがハマり、そこから参加したイベントや恐竜博物館の紹介、直近恐竜のこれまでの常識が変わってきている！という話、さらにはECでこんな商品を出そうかなと考えているアイデアの紹介など タイトル: もっとチームの皆さんとBANKプロダクトユーザーをみていきたい ユーザーインタビューの概要 & ユーザーインタビューとは？の共有など 発表は基本オフラインでみんな聞きながら、Figjamボードに付箋や絵文字、リアクションを貼ってワイワイしています。 発表者側としてはここに感想がたくさん集まっているのを後で見て嬉しい気持ちになれるし、ファシリテーターは非同期に質問や感想が集まっていくので発表後のタイミングで拾ったりしやすいというメリットがあります 🙌 gatchan0807がこの会を見てきて感じたこと BANKチームではこんな感じの会を毎月実施しており、2023年11月（ちょうど1年前）に異動して毎月参加してきて感じたことをざっくり書いておきます。 今の組織フェーズには月次会をやることでコミュニケーションが円滑になるなどメリットがたくさんあるなと感じています 🙋 発表起点で「こんなことやりたい」などを 異なる職種（アナリスト）の人に相談するきっかけになってよかった チームメンバーのパーソナリティを知る機会としてとても活用できる 入社時の自己紹介をしっかりできる場所 があるのはとても良い。どうしても仕事の中、ランチ・飲み会などで自己紹介できる量には限界があるし、話の流れが合致しないこともあるので… 後から入った人も、 長くいる人のパーソナリティを知る 機会になっている Lookerダッシュボードの場所を知れたり、Slackのどこでやり取りされているのか？のような「そんな情報がそこに眠っていたのか！」という気づきや「そうやってみればいいのね！」という 知識のインデックスが貼れる 発表方式にもPDCAが回っていて、最近はCanvaを使っていい感じのスライドをさくさく作って発表する人も出てきてとても良い 大体発表が3ヶ月に1回ぐらいなので、（任意発表で毎回やるとかしなければ）意外と話すネタは見つけやすい 逆に毎月発表はネタ探しとスライド作り大変だった（自業自得） こんなLTをしました ここからは記事タイトルの回収で、月次会で私がどんなLTをしていたかを紹介させてください。 もし、読者の皆さまのなかで何か琴線に触れるものがあれば、ぜひお話ししましょう！お気軽に X （ @gatchan0807 ）までお声がけください〜！🙌 2024年2月: Chrome DevToolsのススメ 実際に使った「Chrome DevToolsのススメ」のスライドの抜粋 フロントエンドエンジニア必携のChrome DevToolsの便利機能をベースに紹介 プロダクトマネージャー、デザイナーの確認作業を楽にする機能や、ネットワークが遅い場合、色覚特性の場合もかんたんに確認できる機能などを紹介 エンジニア以外の職種の方に「実は悪い人たちはこうやって使ってたりする」というのをイメージしてもらい、セキュリティ意識を高める事例も紹介 例えば、Chrome DevToolsを使うことで画面には出ていないこんなデータが見られる 例えば、Chrome DevToolsを使うことで画面を簡単に書き換えてキャプチャが撮れる 2024年3月: 戦略的自己学習のススメ 実際に使った「戦略的自己学習のススメ」のスライドの抜粋 前月にチームメンバーが「戦略的他者交流のススメ」というタイトルで発表をされていたので、それに関連させて話した内容 自分がどんな目的・考え方で調べ物（自己学習）をしているのかを話す自己開示の発表 コミュニケーションを円滑にするために事前に調べ物をしていること 考え事や調べ物のショートカットや、説明をうまくするために調べ物をしていること 2024年4月: （チーム全体でストレングスファインダーを実施する会になったのでおやすみ） ストレングスファインダーの会について、詳しくはこちらの記事をご覧ください basebook.binc.jp 2024年5月: ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ 実際に使った「ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ」のスライドの抜粋 4月のストレングスファインダーの結果に「収集心」という性格特性がTOP5に入っていることから話すことにしたもの 3月の発表で自己学習の話をしていたので、そこで得た知識をどう蓄えているか？というところにフォーカスした内容 Notion、Google Keepなどを使った知識集積プラットフォーム構築を行った後、最終的にSlackに落ち着いている状態 2024年6月: ここがスゴいよ！JavaScript！ 実際に使った「ここがスゴいよ！JavaScript！」のスライドの抜粋 Arcadeというプロダクトを知り、そのプロダクトがChrome拡張 + Webアプリケーションで完結してプロダクトの価値を作っているのを見て、これを実現するためにはJavaScriptの力をふんだんに使う必要があるんだよ！という話 合わせて、JavaScriptを使ってできることを伝え、エンジニア以外のメンバーにもプログラミングや業務効率改善に興味を持ってもらえるように話した発表 2024年7月: もうすぐ来るオンデバイスLLM（SLM）の未来 実際に使った「もうすぐ来るオンデバイスLLM（SLM）の未来」のスライドの抜粋 2024年11月23日に開催されるイベント（ Fullstack AI Dev & Raycast Summit ）のスポンサーLTの内容の元になった発表 個人的にPWAの頃からChromeブラウザに興味が強いので、Google I/OでGemini nano in Chromeを知ったことから実際に触ってみて、得た知識を話したもの 合わせてGemini nanoがAndroidスマホに、Apple IntelligenceがiPhoneに入ることが話題になっていたので、それらも合わせて言及 これもエンジニア以外にもわかってもらえるようにイメージしやすい言葉を最大限使って発表 2024年8月: あなたの知らない.new ドメインの.世界 実際に使った「あなたの知らない.new ドメインの.世界」のスライドの抜粋 Googleが管理するgTLDの 「.new ドメイン」についての知見共有のための発表 https://docs.new でGoogle Docsの新規ページが作成できることなどを業務Tipsとして話したり 自分たちのサービスで作るならこういうドメインがいいかな？という候補を出したり おまけでNew gTLDで語呂合わせドメインが取れることを話したり、BrandTLDについても共有 2024年9月: Webの未来 / Web「ポータル」の未来 実際に使った「Webの未来 / Web「ポータル」の未来」のスライドの抜粋 expand.aiというプロダクトがY Combinatorから調達し、話題になっているのを社内で見つけ、それについて調べた知識を共有した発表 このプロダクトを調べている時にWeb上の情報ポータルサイトの未来を案じたので「こんな変化が必要な世界になりそう」という私見から話したもの expand.aiがどのように使えるのか？という知識に、前職の経験も組み合わせてポータルのポジションが危うくなりそう…という危機感がメイン サービスを継続提供するためにどんな解決策があるか、どんな価値提供が必要かを（ほぼ妄想ベースで）語ったりしました 2024年10月: 今日から始める生成AI 実際に使った「今日から始める生成AI」の未来」のスライドの抜粋 チームの生成AIの活用度合いをもっと上げたいと思い、生成AIに対してのスタンスを共有し、「ハードルをできる限り下げて使い始めてみよう。」というメッセージの発表 イメージしてもらいやすいように「ドラえもんだと思って使おう」というメッセージを伝えている のび太くんがドラえもんに泣きつくように、どんなことだって一旦相談してみてもいい ドラえもんのように失敗することもあるので、温かい目で失敗を教えてあげよう（完璧を求めすぎない） そこから派生して、ロールプレイプロンプトを使った利用時のテンションの上げ方や、JSONでやりとりする形での精度の改善などのちょっとしたテクニックも紹介 gatchan0807がこれだけ発表してきて思ったこと 月並みな表現にはなってしまうのですが、何より アウトプットを起点にした学習は定着が早いし、モチベーションの維持がとてもしやすいので良い なと思いました…！ また、生成AIに対して個人的な興味は強かったものの、プロダクトとして関わったり仕事として関わる見込みはほぼありませんでした。 ですが、積極的に発信していたことで生成AI関連のイベント（後述）へのスポンサリング + スポンサーLT担当をさせてもらう話が進んだり、実際に生成AIをプロダクトに組み込む方法を考え始めたりと（まだまだ構想・妄想段階）、もともとやりたいと思っていた仕事をやらせてもらえていたのですが、そこに追加して新たに生成AI関連のお仕事が増え、仕事をさらに楽しむ要因にもなりました 👏 チームに対しての知見共有も「わかりやすい！」や「学びがあった！」といったフィードバックや感謝を受け取れてとてもテンションが上がりますし、非常に勝手ながらBANKチームでこの会を一番うまく活用している人間なんじゃないかなと思っていたりします 😎 おわりに 今回はBANKチームの「月次会」という月に1回社内で行っているLT発表会の取り組みを紹介させていただきました。 もし、このような取り組みを行っているBASE / BASE BANKチームにご興味を持っていただけたのであれば、ぜひお気軽にカジュアル面談や X でのお声がけなどをしていただけますととても嬉しいです！ まだまだBASE BANKチームとしては作りたいもの、提供したい価値がたくさんあって、それらを一緒に実現していける仲間を募集しています。ぜひBANKチームにお力をお貸しください 🙇‍♂️🙇‍♂️🙇‍♂️ binc.jp また、合わせて gatchan0807 が半年間、毎月発表した内容も紹介させていただきました。 BANKチームとして、中小規模のエンジニアイベントへの会場提供・飲食スポンサーをやっていく動きもあるので、エンジニアイベントの主催、スタッフの皆さまの中で、もしこういった話にご興味ある方がいらっしゃればお気軽に X などでお声がけいただけますと幸いです！ もしくは、こちらの記事を X などでシェアしていただくのもとってもとっても嬉しいです！ devblog.thebase.in 最後に、記事内でも少し触れましたが 2024年11月23日（土）に実施される以下のイベントにBASE BANKチームがスポンサーをさせていただき、LTもさせていただきますのでぜひオフラインでご参加 or オンラインでご覧いただけると幸いです！ devx.jp

<この記事はHatena-Blog-Workflows-Boilerplateによって作成されました> こんにちは！ BASE株式会社 Pay ID の @zan_sakurai と申します。 BASE PRODUCT TEAM BLOG 編集局メンバーも務めています。(実は今年の編集長です。) 今回は、Hatena-Blog-Workflows-Boilerplateを使ってとあるSaaSのリンクを一括置換した話をします。 Hatena-Blog-Workflows-Boilerplate Hatena-Blog-Workflows-Boilerplateとは、 株式会社はてなさんが公式で公開している、はてなブログの記事を書くためのワークフローのボイラープレートでして、GitHub 上で下書きや記事の公開等を行うことができるものです。 github.com 弊社では昨年 @applepine1125 さんが書いた Hatena-Blog-Workflows-Boilerplateつかって BASEのブログ書いてみた も見ていただけると幸いです。 Hatena-Blog-Workflows-Boilerplate を使って 一括置換してみた 先に結論です。一括置換するまでは3ステップで完了しました! 総記事数約450件のうち、置換対象のリンクが含まれている記事は約100件、差分は約130行ほどでした。(目視で確認&置換していたらゾッとしますね...!) 良い感じに取り込んで(pull from hatenablog) 良い感じに置換して！ 良い感じにpush! 以上です! リンク置換作業の経緯 さすがに少し味気ないので、もう少し詳しく経緯もお伝えしようと思います。 ことのきっかけは、これまで利用していたとあるSaaSを別のSaaSに切り替えることになり、社内ではそのリンクの置換作業が行われている最中でした。 BASE PRODUCT TEAM BLOG に掲載している記事にも多くのそのSaaSのリンクが含まれており、置換作業が必要でした。 (ブログというコンテンツの特性上、過去の記事は更新しない、という判断もありえましたが、読者の皆様の体験を損なわないことを優先し、全て切り替えることとしました。) 最初は「全部記事目視で地道にやってみるか...。」と思っていましたが、量も量でしたし、「なんとかならないかな...。」とぼんやり考えていました。 ぼんやり考えているときと、ふとしたときに前述の @applepine1125 さんが書いた記事を思い出しました。 Hatena-Blog-Workflows-Boilerplate はブログの記事を書くためのワークフローを提供するものですが、 hatena blog上に掲載している記事をpullすることができるので、 それを使って、記事の取り込み(pull) -> 置換 -> push という流れで、リンクの置換作業を行うことができるのではないかと思いました。 ちょっと実験がてらやってみたところ、前述のとおり簡単にリンクの置き換えができました。 使ってみた感想 特定の文字列を一括置換という慣れ親しんだ(?)作業をおこなうだけでしたので、本当に簡単でした。 ブログの執筆の一連のフローを Hatena-Blog-Workflows-Boilerplate のワークフローに移行したいな、と社内でもぼやいていたのですが、 執筆のフローだけでなく、ブログのメンテナンスにも使えることがわかり、ますます今後活用したいと思っています。 また、今回触ってみて感じましたが、執筆だけでなく、メンテナンスや記事を一気に見る、といったことにも活用できるので、企業ではてなブログで技術ブログ等を運営されている方にはぜひ一度お試しいただきたいです。 おわりに Hatena-Blog-Workflows-Boilerplate めちゃくちゃ便利です...!!! open.talentio.com

BASE も Aurora MySQL v3 となりました SRE Groupの ngsw です。 2024/10/14〜10/15の深夜メンテナンスにて、BASEで利用しているAmazon Aurora MySQLのバージョンは、v2系からv3系となりました。 アップグレードの前提条件で大きなつまずきがありましたが、 gh-ost を利用することで、乗り越えることができました。 この記事では当該アップグレードの中で gh-ost をどのように利用し、どういう恩恵を受けたかについて述べていきます。 おさらい : v3 対応しないとどうなるの？ Aurora MySQL v2は標準サポート終了が発表されており、v3への移行を終えていないDBクラスターには自動的に有償の延長サポートが適用される流れです。 Amazon RDS 延長サポートの使用 - Amazon Aurora 2024/10/31 に自動で延長サポート入り 2024/12/01 より延長サポート料金の自動請求が適用される 費用はこちらをご確認ください。そこまで安くありません。 料金 - Amazon Aurora | AWS 有償サポート提供によりある程度の時間猶予が与えられたとはいえ、アップグレードを先延ばしにするメリットはほとんどありません。 たとえば、このアップグレードよりも企業にとって利益のある施策やサービスの開発/改修があればまた別の意思決定が働くでしょうが、そんな施策はそうそうないでしょう。 簡単にアップグレードできない問題 Aurora MySQL v2→v3アップグレード検証段階で問題が見つかりました。 BASEでは本番環境のデータにマスキングをほどこしたものを、開発環境で利用できるようにしています。 このマスキングしたDB Clusterで、以下にあるようなインプレースアップグレードの検証を行いましたが、エラーのためアップグレード処理は停止してしまいました。 Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード | Amazon Web Services ブログ 停止理由は upgrade-prechecks.log をみることで確認ができます。 原因となる問題は大きく二つありました。 mysql . event に関するアップグレード時の不整合エラー 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー mysql . event に関するアップグレード時の不整合エラー AWS サポートにより対応いただけました。 こちらは数日程度で解決でき、検証作業をブロックするほどの問題ではありませんでした。 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー 問題はこちらのエラーです。 MySQL :: MySQL 8.0: Removing support for old temporal datatypes 解決方法が「当該カラムを持つテーブルを新しく再作成する」ということになり、 Dump & Restoreする ALTER TABLE {table_name} FORCE; というような、つまりv2上で CREATE TABLE 相当のことを行う必要がありました。 おそらくはMySQL5.6以前のAWSのRDSで稼働し、そのままAuroraに引き継がれてきたテーブルで、かつ datetime 型カラムを含むものがこの対象となるのでしょう。 Aurora からサービスを開始したプロダクトなどでは見ることがないエラーなのかもしれません。 どのような困難が伴うか このあとに控える困難を想像し頭を抱えてしまった理由、今回の datetime 型カラム再作成対象となった2つのDB Cluster、XとYについて説明します。 X はショップの情報や商品の情報などを持ちます。 Y は各種履歴などが蓄積されています。 以下に規模感を記載します。 対象テーブル数とその合計サイズ テーブル数 容量 X全体 976tables 約7.5TB 対象テーブル 268tables 600GiB 対象テーブルはDB Clusterのデータサイズにして全体の約8% 4テーブルあれば、うち1つが対象という形。 テーブル数 容量 Y全体 236tables 約5.3TB 対象テーブル 37tables 615GiB 対象テーブルはDB Cluster のデータサイズにして全体の約11% 10テーブルあれば、うち1つか2つが対象という形。 結論としてこれだけのテーブルに対して、 なるべくサービス無停止でALTER文を発行しきる必要があります。 前提として、 当該アップグレードのメンテナンスは1回の深夜メンテナンスで行う 全断して行う予定であるが、メンテナンス時間は5〜6時間程度しかとれない というのがありました。 当初はメンテナンス時間の中で当該テーブルに対してdump&restoreするなども考えましたが、 実行時間的に無理だということがわかりました。 1 オンラインスキーマチェンジ/オンラインスキーママイグレーションツール メンテ当日にALTER TABLE or Dump/Restore + upgrade すべてを行うことは(当然に)無理、ということがわかりました。 それならばメンテ当日までに事前に下準備として行う方法を考えました。 下準備として、ということから暗黙的に無停止でなければなりません。 サービス無停止でALTER TABLE発行というところから、オンラインスキーマチェンジ/オンラインスキーママイグレーションツールに行き着くでしょう。 わたしはこの手のツールの利用経験がなかったため、ひとまず以下を候補にあげました。 2 pt-online-schema-change — Percona Toolkit Documentation github/gh-ost: GitHub's Online Schema-migration Tool for MySQL 結果として、われわれは gh-ost をはじめに検証し、目的に際し十分であると考え、そのまま今回の作業遂行ツールとして採用しました。 以下の理由から gh-ost の検証を優先し、結果的にわれわれの要件的には gh-ost で十分ということがわかったため、pt-osc の検証自体をスキップしました。 pt-oscよりgh-ostを優先して検証候補にした理由は以下になります。 pt-oscを選ばなかった : pt-osc では元テーブルと新テーブルの同期にトリガーが採用されており、トリガー利用による負荷が、サービス提供にどのように影響を与えるのか懸念し、検証優先度を下げた gh-ostを選んだ : 処理時間は長くなりそうではあるが、DB負荷自体は軽そうに思えたため gh-ostを選んだ : 一番の懸念であったDB Cluster Xでbinlog replicationをすでに運用していたため、gh-ost利用適正が高いだろうと思えたため そもそも pt-osc は完了までの処理速度を、gh-ost は小さな負荷での実行(つまりサービス影響の最小化)を重視しているよう思え、今回は後者の哲学を支持したため gh-ost 簡単にgh-ostの特徴および利用しての実感を書きます。 特徴については gh-ost/README.md at master · github/gh-ost を読むとわかりやすいです。 複数方式があるが、replication側からbinlogを取得するパターンが推奨されている 別名テーブルに元テーブルからデータを抽出して挿入する、更新分はbinlogで対応する 負荷が高くなると自動でthrottlingする 指定ファイルをtouchすれば、手動でthrottlingさせることもできる なにかしらのエラーが発生して処理途中で落ちた場合、また作業途中であった別名テーブルを削除して、最初から実行する必要がある 1テーブルにあたり、とてもゆっくり動くので対象テーブルデータ量によっては業務時間内に1テーブル終わるかわからないくらい 別名テーブルと元テーブルを切り替える処理をcut-overというが、この時間を指定することもできる(夜中に切り替えたい、昼間に切り替えたくない場合などに有効) cut-over という単語が出てきましたが gh-ostでは「ALTER TABLE用の別名テーブルを対象テーブルに変名し本番運用へと切り替える」ことをいいます。 gh-ost/doc/cut-over.md at master · github/gh-ost 利用していた実感では cut-over に至るまではまったく問題が起きませんでした。 明示的な問題として1回だけ発生したのは cut-over タイミングと更新タイミングが噛み合ったときに、 cut-over が止まってしまうという現象でした。 一度gh-ostの処理をとめ、新たにやり直すだけで解消するので、 cut-over 間近のタイミングだけ気にしておけばよい、という形で以後の作業もすすめることができました。 gh-ost の好きなところ 個人的に gh-ost で気に入ったところも書いておきましょう。 sock fileを経由することで対話式にコマンド実行が可能 gh-ost/doc/interactive-commands.md at master · github/gh-ost 進捗ステータスが確認できる コマンド実行中にパラメータを動的に変更できる 特定ファイルの設置で処理を暫定停止することができる 処理が遅いのだけが欠点、実運用への副作用がまったくといっていいほどない という感じです。 最終的にはほとんど放置して、一日の終わりに進捗状況を確認する程度になりました。 運用作業者(ひいてはサービス)に優しいツールだなと感じました。 参考 : 実際の作業スケジュール 当初は本番作業時にどのような影響がでるかわからなかったため、開発陣に対象テーブルのリストとALTER TABLE実行スケジュールを共有するようしました。 うまくいっても08月上旬から09月末くらいかかるのではないかと不安でしたが、gh-ostのおかげで08/08〜08/26という想定よりも短い期間で終えることができました。 データ総量が作業時間を左右する傾向がみられたため、見積もりのため以下のようなクエリでテーブルごとのデータの一覧を出しています。 total_size を主に見て実行時間の見積もりを行っていました。 SELECT table_schema, table_name, data_length AS `data_size`, index_length AS `index_size`, (data_length + index_length) AS `total_size`, table_comment AS ` comment ` FROM information_schema.TABLES WHERE table_schema != ' sys ' AND table_schema != ' information_schema ' AND table_schema != ' performance_schema ' GROUP BY table_schema, TABLE_NAME ORDER BY total_size DESC ; 注意点1 今回Aurora v2 -> v3 へのアップグレードだったため、gh-ost のバージョンは v1.1.5 を採用しています。 注意点2 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp には以下のような記述があります。 ユニークキーの追加 gh-ostを使用して、ユニークキーを追加することは可能です。 しかし、ユニークキーを追加するカラムの値が事前にユニークな値になっていることを確認してから実行しないと、 データがなくなってしまう恐れがあります。 われわれの今回の作業においては関係がなかったものですが、この記事より興味をもって利用される方においては、用途によっては気にしていただきたい内容であるため、ここに引用しました 参考URL 今回のタスクでは以下のDocumentを参考にしました MySQL 全般について MySQL :: MySQL 8.0: Removing support for old temporal datatypes gh-ost について gh-ost/README.md at master · github/gh-ost 第138回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その1］ | gihyo.jp 第139回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その2］ | gihyo.jp 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp 【MySQL】gh-ostを調べる - 地方エンジニアの学習日記 【MySQL】gh-ostでオンラインマイグレーション #Docker - Qiita Runtime error when trying to ALTER a table without PRIMARY KEY / UNIQUE KEY · Issue #332 · github/gh-ost pt-osc について pt-online-schema-change — Percona Toolkit Documentation pt-online-schema-changeの導入時に検討したこと、およびRailsアプリとの併用について - freee Developers Hub Percona社のgh-ostベンチマークなど Using gh-ost with Amazon Aurora for MySQL Gh-ost benchmark against pt-online-schema-change performance spirit というツールもあったが、v2(5.7系)だと利用が難しそうだった MySQL オンラインスキーマ変更ツールの spirit と gh-ost - Please Sleep BASEでは随時メンバーを募集しています。 2024.10現在、私の所属するSRE Groupの募集はないようですが、興味を持たれた読者諸氏におかれましては、以下リンク先をご覧いただければ幸いです。 採用情報 | BASE, Inc. - BASE, Inc. 検証ではdumpだけで想定メンテナンス時間をすべて消費してしまうことがわかりました ↩ チーム内にこれらツールの検証目的の過去Issuesが立っていたため ↩

新しい方を受け入れる側のマインドセットです。 はじめに BASE の Product Dev Division でシニアエンジニアをしているプログラミングをするパンダ（ @Panda_Program ）です。 入社されて3ヶ月目で同じチームで働いている Torata さんが「 入社して感じたBASEのいいなと思うところ 」という入社エントリを書いてくれたので、新入社員を受け入れる側からのアンサー記事です。 以下はBASE社内の人なら誰でも読むことができる文書で、特にこれからメンターになる人には読んで貰っているものです。自分が受け入れ側として数ヶ月間特に意識しており、手応えがあったことを書き残しています。 ここ数ヶ月の間、マネージャーと共にオンボーディングの体験や資料の全面的な見直しを行い、新入社員とメンターのオンボーディング体験を改善しました。この文章自体も前からあるものではなく、これからメンターはこういうことを心がけていこうねと新しく作ったものです。 以下の内容はBASE社での受け入れを想定していますが、他の会社でも（エンジニアという職種以外でも）活かせる内容だと思います。これから新しい方を受け入れるにあたってどう接したらいいのかわからないという方が、この文章を通して何かを掴めたら幸いです。 相手を知ろう これは一番重要です。現在、BASEで採用しているエンジニアは実務経験者の方がメインだからです。 よくある間違いは、相手が何も知らないと勘違いして一から全部教えようとすることです。相手も経験者なので一から教えてもらう必要はありません。では何を教えればいいのでしょうか。それは新入社員の人が持っている知識のうち、メンターから見て不足している部分だけです。 メンターがまずやるべきことは、新しく入社される方のこれまでの経験を深く知ることです。メンターはチームメンバーの誰よりも新しく入社される方のバックグラウンドを理解しましょう。 前職ではどのような業務を担当していたのか、前職の会社の雰囲気はどのようなものであったのか、どのようなことに興味を持っていて、どのようなことが苦手なのか。これらのことを知っていると自然と相手への向き合い方も変わります。相手の良いところや自分にない部分を知ることは相手へのリスペクトにつながります。 BASEではこうだと押し付けるのではいけません。相手の過去の経験を知り、BASEとの共通点や相違点を提示しましょう。すると相手は一から全部知るコストを払う必要はなく、共通点や差分を学ぶだけで済みます。メンターが「ウチではこうだ」と押し付けるのではなく、転職者が自分の過去の経験に基づいて、新しい会社と今までの会社との共通点や相違点にフォーカスする方がスムーズです。結果的に組織やカルチャーへの適応も早くなるでしょう。 自分を開示しよう 新しく入社される方はたくさんの質問を受けることでしょう。しかし、相手のことを聞くばかりではいけません。自分はどういう人間か、会社やチームで働いている人はどういう人たちなのかを伝えることも重要です。 自分の経験を相手に伝えましょう。自分は何が得意で、なぜこの会社で働いているのか。オンボーディング期間は、普段会社ではあまり話すことのない、自分が大切にしている価値観について話すいいタイミングです。ここを逃すとなかなかそれを話すタイミングはありません。 メンターとメンティーの一対一に限らず、新入社員の方が所属するチームのみんなで自分たちの大事にしている価値観について改めて話す機会を設けることにより、メンバーの知らなかった一面も見れるかもしれません。そうすれば、チームの結束はさらに強まるでしょう。 オンボーディングという機会を活用して既存のチームを再ビルディングすると、メンバー同士が今よりもっと互いにリスペクトを送り合えるより強いチームになります。 ドキュメントは渡すだけではなく、相手の理解度に合わせて適宜一緒に読もう。口頭で解説・補足をしよう オンボーディングで最初にやることの一つは、自分たちが開発しているプロダクトを実際に触ってみることです。その際、メンターは新入社員を一人きりにしないであげてください。 一般的に、何かウェブサイトやソフトウェアを触るときにこの裏側はどうなっているんだろうと気になるというのがエンジニアの性（さが）です。新しく入った方は、これから自分が開発していくことになるプロダクトに自然と興味と疑問を持ちます。 興味から出た感想や疑問に対してメンターがシステムの裏側を解説したり、ここはちょっといけてないところなんだよねと共感したりとタイムリーに答えることで、メンティーの知識の定着度は俄然アップします。人は疑問を持った時が一番知識を吸収できるからです。また、このように相手に寄り添った行動の積み重ねがお互いの信頼関係を構築することに繋がります。 ソフトウェアに限らずドキュメントも同様です。一人でただ読むだけでは理解できないことも、メンターと一緒に読みながら適宜口頭で補足や解説を交えてもらうとメンティーは深く理解することができます。 この時、自分で解説を始めたりBASEの事情を一方的に伝えるだけではなく、「この中でどの部分がわからないですか」「あなたの前の会社ではどうでしたか」とまず質問をして話を聞いてあげましょう。そこからうちの会社ではここは違いますね、ここは同じですねという会話を広げていきましょう。 「相手を知る」チャンスはどこにでも転がっています。 おわりに 少し大袈裟ですが、メンターとなるあなたの印象がBASEの社員全体の印象を決めると言っても過言ではありません。もし相手が年下だったり自分より経験が浅くても、相手へのリスペクトを忘れず真摯に向き合いましょう。 なお、手前味噌ですが私の配信しているラジオコンテンツもお聞きいただけると、オンボーディングに対してさらにイメージが湧くかなと思います。 こちらは、オンボーディングしてもらう側特有の焦りからくる失敗などについて話しています。オンボーディングされる側の気持ちを少しでも思い出すきっかけになるかと思います。 BASEではソフトウェアエンジニアを募集しています。ぜひ採用情報ページをご覧ください。 採用情報 | BASE, Inc. - BASE, Inc.

はじめに BASE BANK Division で エンジニア をしている岩本と申します！ YELL BANK の開発を担当しています。 2024年5月にBASEへjoinして早いもので5ヶ月ほどが経ちました。 joinしてからいくつかのプロジェクトを担当してきました。 改めて考えるとオンボーディングがとても充実していたおかげで円滑にプロジェクトに入っていけたのだなぁと感じます。 そこで、オンボーディングを中心にこれまでの5ヶ月を振り返りつつ、チームが新規メンバーのキャッチアップに向けて、どのような取り組みを行っているかを紹介させて頂こうと思います！！ 前置き 本題に入る前に前置きです。 私の普段の業務をイメージしやすいように体制や役割、各種環境についてお伝えします！ 体制 まずは体制です。 私の担当する YELL BANK ですが、joinした5月時点では以下のような3名体制で開発していました。 EPM（Engineering Program Managerのことです。 こちら をご参考ください。） エンジニア2名（内1人が私） 7月以降は以下の体制に移行しています。 EPM エンジニア1名（私） 役割 次に役割です。 私はエンジニアですが、BASE BANKでは「フルサイクルエンジニア」という役割が求められます。 フルサイクルエンジニアについての記事は過去にGroup Managerの松雪さん( @applepine1125 )が書いた こちら をご参考ください。 そのため、企画・要件定義〜保守運用・データ分析支援等まで幅広く対応することが必要になります。 それにより、開発チームだけでなく、PdM、デザイナー、PMMといった職能のメンバーとも頻繁にコミュニケーションが発生します。 体感的には開発チーム：7、PdM・PMM・デザイナー：3くらいの割合でコミュニケーションしています。 出社頻度 コミュニケーションに関連した話ですが、現状、BASE BANKの開発チームでは週1（毎週木曜）に出社日を設け、その他はリモートワークです。 開発環境 最後にアーキテクチャ周りのお話です。 私の担当する YELL BANK の開発業務においては以下の図の上側にあるBASEのサービスと下側にあるBASE BANKのサービス群を実装しております。 ご覧の通り、フロントエンドはTypescript（Vue.js）、バックエンドはPHP、Go、Pythonという形で複数の言語で開発しています。 また、インフラは主にAWSを使用しており、IaCではterraformを使用しています。 本題 前置きが少々長くなりましたが、ここから本題です。 私が効果を感じた取り組みなどを5つ紹介させて頂きます！！ その1　オンボーディングクエスト BASE BANKチームではオンボーディングクエストを用意しています。 以下はNotionで作成したオンボーディングクエストのTOPページになります！ 新規メンバーはまずクエストに沿って開発環境構築等の各種セットアップをしていきます。 さらに開発環境構築だけでなく、プロダクトの説明を受けたり、実際に触ったりといった研修も行います。 オンボーディング中はメンターが1人付きますが、クエストの中でPdMやデザイナーといった他の職能のメンバーとも接します。 フルサイクルエンジニアとしてはコードが書けるというだけでは不十分です。 そのため、プロダクトの研修があったり、他の職能のメンバーとコミュニケーションできる機会があったのは業務を進めるのに大変助かりました！ また、クエストではオンボーディングタスクというものを用意しています。 簡単かつ業務を1サイクル回せるといった最初のキャッチアップにちょうどよいタスクのことです。 私の場合、if文を少し修正すればOKな簡単なコード修正と、それをデプロイするというタスクでした。 これにより一通りの開発の流れを把握できました。 クエストはオンボーディングが終了するたびに振り返りをして改善を重ねています。 その2　オンボーディング期間中は毎日出社 オンボーディング期間は1〜2週間です。 その間、基本的には新規メンバーもメンターも毎日出社します。 そのため、すぐにメンターや他のメンバーに質問することができます。 対面なので、解決も早いです。 それ以上にメンバーとの信頼関係をかなり早く構築できるというメリットを感じます。 リモートの場合、コミュニケーション量が少なくなる傾向があるため、出社による対面のコミュニケーションでレクチャーを受けられたことでシステム、プロダクトのインプット量・質も上がりました。 今振り返ってみても最初に出社していたことでオンボーディング後の業務を円滑に進めることができました。 また、入社前・直後にコミュニケーションに不安を感じる方は多いとは思いますが、BASEでは早期にそのような不安を解消することができました！ デメリットとして通勤の負荷はありましたが、それを超えるメリットを享受できたと感じています！ 前置きでも記載した通り、オンボーディング終了後は週1（毎週木曜）で出社しています。 その3　ドキュメント文化 オンボーディング終了後、いざ本格的な業務に入るわけですが、まだまだ分からないことはたくさんあります。 BASE BANKにはドキュメントを残す文化があります。 分からないことがあればNotionやREADMEを見れば答えに辿り着くことも多いですし、あるいはなにかしらのヒントがあることが多いです。 業務していると大抵、どのメンバーも同じことで困るパターンも多いので、そんなときのためにトラブルシューティングをまとめたドキュメントも存在します。 個人的にはオンボーディング直後はこのドキュメントに大変助けられました。 以下はそのトラブルシューティングのドキュメントを一部抜粋したものです。 その4　メンターランチ BASEにはメンターランチという制度があります。 入社後、主に業務で関わるメンバーとランチするというものです。 費用は会社負担です。 この制度により、自分で機会を設けずとも仕組みでコミュニケーションの機会を設けることができます。 プロジェクト開始前にエンジニア以外の職能のメンバーともお話できたことで、いざプロジェクトを進めるというときにやりやすかったのを覚えています。 その5　振り返り文化 BASE BANKではスプリントごとにも振り返りしますが、それぞれのプロジェクト後にも振り返りをする文化があります。 プロジェクトの振り返りは職能横断的にそのプロジェクトに関わったメンバー全員が参加します。 私個人としては振り返りの場はプロダクトを知る機会でもあり、人を知る機会でもあります。 その人の職能、経験によって色々な意見が出ます。 そして自分も意見を出します。 意見を出すということはプロジェクトやプロダクトについて、常に能動的に考えている必要があります。 振り返り文化のおかげで自然とそのような考えになっているように感じます。 つまり、自然と「早くキャッチアップしなきゃ」という気持ちになります。 まとめ 改めてこれまでの4ヶ月を振り返ってみました。 振り返ってみると円滑なコミュニケーションというところにBASE BANKの強みがあるのだと感じます。 そして、それによるチームプレイに強みがあるのだと感じます。 私自身はまだまだ全般的に知識が不足しているので、チーム力向上に寄与できるように邁進します。 おわりに BASE BANKではいっしょに働く仲間を大募集しております！ フルサイクルエンジニアという役割に興味があるという方はまずはカジュアル面談からでもご応募頂けるとうれしいです！ ↓の採用ページの募集職種一覧から、BASE BANKチームで6.金融サービス（BASE BANKチーム）を選択頂いてカジュアル面談にご応募できます！ binc.jp

こんにちは！ BASE BANKです。 最近は大きなカンファレンスだけでなく様々なコミュニティのオフラインイベントも増え、かつて以上の活気で溢れているなと感じています。 我々BASE社も大小さまざまなカンファレンス、イベントにスポンサーをさせていただいておりますが、今回はBASE BANKとしてももっとスポンサーの頻度をあげていくぞ！スポンサーさせてください！という内容の記事です。 BASE BANKって? スポンサーの理由やイベントとのマッチングのために、まずは軽くBASE BANKについて自己紹介させてください。 BASE BANKはBASE社の1事業部です。 「銀行をかんたんにし、全ての人が挑戦できる世の中に」というミッションを掲げ、個人やスモールチームの資金繰りに関する課題解決を行っています。 https://speakerdeck.com/base/basebank 現在、「BASE」のショップオーナー向けには、「YELL BANK」、「BASEカード」、「お急ぎ振込(振込申請)」の3つを提供しており、グループ会社のPAY.JPと協業し「PAY.JP YELL BANK」として「BASE」以外のプラットフォームへも広く価値提供をし始めたところです！ 8月に公開したIR資料からもわかるように、ありがたいことに「YELL BANK」を筆頭に各プロダクトがめちゃくちゃ順調にグロースしています。 しかし、もっとBASEグループ全体をリードできるような事業部へと成長していくために、現事業のグロースと新規事業の創出の2軸をフルアクセルで推進しています。 https://contents.xj-storage.jp/xcontents/AS08546/360b2858/87ab/484c/9da2/062c0fb17663/140120240806563776.pdf 現在、エンジニアとBizdev、事業企画のポジションをオープンしていますが、特にエンジニアを積極大募集中です！ https://open.talentio.com/r/1/c/binc/homes/4380?group_ids=9203 なんでスポンサーしたいの? スポンサーをしていきたい理由の１つは事業部の認知度向上のためです。 BASE社としては、ありがたいことにこれまでのスポンサーの積み重ねやCMなどを通じて認知してくださっている方が多くいらっしゃいます。 しかしBASE BANKという事業部としてはまだまだ認知度に伸びしろがあり、”BASEってECだけじゃないんですね！”とスカウトやイベントなどで初めて知っていただく機会がまだまだ多いです。 上にも書いたように、さらなる提供価値や提供顧客の拡大のために現在フルアクセルで事業と組織の増強をおこなっているところですが、まだまだ仲間が足りません。 めちゃくちゃおもしろいことやってる事業部があるよ！やっていきたいことのためにまだまだ仲間が必要だよ！というアピールの場を増やしていきたいと考えているのが1つ目の理由です。 理由の2つ目として、コミュニティの発展をサポートしていきたいという思いがあります。 コミュニティやイベントの存在が日々のトレンドキャッチアップやアウトプットの起点にもなり、さらにそれを通じた”ゆるいつながり”が生まれることで会社の組織文化を見直すよい機会にもつながったりします。 我々もこういったコミュニティの恩恵を受けてきたこともあり、会社としても昔から様々なコミュニティへスポンサーとして微力ながら応援をさせていただいていました。 これまではPHP ConferenceやGo Conferenceなど、比較的大きなイベント、コミュニティへのスポンサーがメインでしたが、より細かく継続的にBASE BANKを知ってもらえる機会を増やしたい、コミュニティの裾野を広げるお手伝いをもっとやっていきたいという思いもあり、今回スポンサー立候補をするに至りました。 一緒に組んでいきたいイベント、コミュニティ BASE BANKとしても、事業や組織のあり方、技術スタックと親和性の高いコミュニティ、イベントとタッグを組んでいきたいと考えています。 具体的なジャンルとしては以下を想定しています。 事業領域 Fintech EC 開発プロセス スクラム アジャイル プログラミング言語 PHP Go TypeScript(React, Vue) 規模としては~100人規模を想定しています。 あくまで現時点での想定なので、上に書いた以外でも理念に強く共感させていただいたり、親和性の高さを感じたコミュニティやイベントとのご縁があればぜひお手伝いさせていただきたいです！ BASE BANKとしてご提供できるもの 会場スポンサー 東京都港区六本木三丁目2番1号 住友不動産六本木グランドタワー 37F 最大50名程度収容可能(椅子、テーブルありの場合) レイアウト例 (約40名規模のイベント) https://devblog.thebase.in/entry/welcome_fintech2 発表用の演台があり、その左右にプロジェクタを使って投影することができます。 飲食スポンサー 予算は10万程度までを想定しております。 一旦10万以下とさせていただいておりますが多少調整は効くので、予算と提供するドリンクや食事については都度ご相談させてください！ イベント時にさせていただきたいこと イベントの何処かのタイミングでBASE, BASE BANKの会社紹介をさせてください！ 3分程度お時間を頂戴します。 ご連絡先 とりあえず話を聞いてみたい！というだけでも構いません。以下フォームからぜひお問い合わせください！ https://binc.jp/contacts/jobs 会場や予算の確認のため、イベント開催の1ヶ月前にはお声がけいただけると幸いです。 おわりに 今回ブログとして告知を出させていただきましたが、こちらからも積極的に直接お声がけさせていただきます。 また、事業を一緒に作っていく仲間も大募集中です! https://open.talentio.com/r/1/c/binc/homes/4380?group_ids=9203 少しでもご興味ある方は是非お話しましょう！

はじめに BASEのProduct Dev / Feature Dev1 GroupでアプリケーションエンジニアをしているTorataです。 BASEに入社して早くも3ヶ月がたちました。 少しづつBASEの仕事や環境、文化にも慣れてきたので振り返りを兼ねて入社エントリーを書こうと思います。 BASEに興味を持っている方の参考になれば嬉しいです！ 入社の経緯 前職では、新卒から約5年間、バックエンドエンジニアとして働いていました。 周りには信頼できる素晴らしい方々が多く、幅広い経験をすることができました。 ただ自身のキャリアを考えたときに、より大きなチームで大規模なシステムを扱う経験を積みたい、その中でさらにエンジニアとしての専門性を高めていきたいと思い転職を決意しました。 BASEに入社した理由は、ビジョンに共感し、成長できる環境が整っていると感じたからです。BASEのプロダクトは「個人やスモールチームをエンパワーメントする」ことにフォーカスしており、誰もが大きな組織に頼らずとも活躍できる時代に非常にマッチしたサービスだと感じました。 また、私の身近な人もBASEを利用していたこともあり、彼らのような人々を支えたいという強い思いが芽生えました。 さらに、BASEのエンジニア組織ではカンファレンスでの登壇や、現在私が書いているテックブログのような発信活動が盛んに行われており、そうした環境で自分が成長できる姿をイメージできたことも、入社を決めた大きな理由です。 BASEのいいなと思うとこ 1. チーム外のメンバーと交流できる機会がたくさんある BASEでは、入社後8回までチーム内外のメンバーとランチに行ける「メンターランチ」や、3ヶ月に1度オフィスで開催される「締め会」、午後7時以降にオフィス内のバーカウンターでアルコールを含む各種ドリンクを楽しむことができるなど、社員同士が交流できる機会が多く設けられています。 私も入社してからチーム内外の多くの方々と交流することができました。 私は前職は毎日オフィス出社の会社だったのでハイブリットワークを実施しているBASEでのコミュニケーションの取り方に不安があったのですが、なんなら前職よりも他の方と話す機会が多いんじゃないかと思うくらいにコミュニケーションを取れる機会が多く設けられています。 コミュニケーションを通してどういう人か分かっている方が業務もスムーズに進められるし、こういう機会を通して普段業務では関わりのない人とも交流を持つことができるので大変助けられています。 2. 「Move Fast」で支え合う文化がある チャットで困りごとや疑問を呟くと、すぐに多くのメンバーが助けてくれます。 特にオンボーディング期間中は、新しい環境に対する不安や疑問が多かったのですが、何度も助けてもらいました。 実際、自分のオンボーディングチャンネルに「ここってどうなっているんだろう？」とか「これ詰まっちゃったなー」みたいな困りごとを雑に投げても誰かしらがそれを拾ってくれて説明したり解決まで持っていってくれます。 細かな疑問やちょっとした悩みにも迅速に反応してもらえることで、何かあった時には誰かが助けてくれるという安心感と、もし困っている人を見かけたら自分も同じように助けてあげたいといういい循環ができているなと感じています。 BASEにはMove Fast以外にも行動指針があって、これらの”BASEらしさ”を個人的には魅力に感じています。 3. モダンとレガシー2つの環境を経験できる BASEは10年以上続いているサービスであり、長年使われてきたリポジトリと、リプレイス先の新しいリポジトリの2つが存在しています。 新しいリポジトリではモジュラモノリスが採用されており、現代の水準に合ったクリーンなコードに触れることができます。 一方で、古いリポジトリも改善が進められており、レガシーコードにどう立ち向かっていくかを経験できます。 エンジニアとしては常にモダンな環境で開発をする方が楽しいかもしれませんが、現実的にはレガシーコードとも向き合うことが避けられないと個人的には考えています。 モダンとレガシー2つの環境を経験することでエンジニアとして大きく成長できるんじゃないかと今からワクワクしています。 今後やりたいこと 私の周りには、非常に優れた、尊敬できるエンジニアが多くいます。まずはそのレベルに追いつくことを目標に、日々努力しています。 現在は多くを学びながら、チームのサポートを受けている段階ですが、将来的には「自分だからこそできる」貢献を模索し、チームや組織に新たな価値を提供できるエンジニアを目指したいと考えています。 おわりに 以上で私のBASEの入社の経緯や入社していいなと思うところを紹介しました。 この記事を読んで少しでもBASEに興味を持ってもらえたら嬉しいです。 BASEは現在エンジニア積極採用中なので興味があれば採用情報ぜひご覧ください！ BASEで一緒に働きましょう！ binc.jp

はじめに こんにちは。Product Management Group で プロダクトマネジメント をしている坂東（ @7auto ）です。 リソース的な問題で「やるべきことがたくさんあって、小さめの改善やPJに手が回らない」そんなお悩みを持つ方はたくさんいらっしゃるのではないでしょうか。 サービスが大きくなるとPJの規模も大きくなっていきます。その結果、小さめのPJや改善の優先度が下がりがちになります。 一方で、小さめのPJや改善はサービス利用者の声から生まれることも多く、これを放置し続けることはサービス体験の悪化に繋がります。 そこで大きなPJと並行して、こうした小さめのPJや改善に対し「最小のコミュニケーションコストで機能リリースする」というコンセプトで立ち上げからリリースを行いました。 「全員集まったのはキックオフと振り返りだけ」そんな定例もDailyも無いPJを通して、低コストなだけでなく個人の成長にもつながるメリットがあるように感じられました。 本稿ではそこから得られたことを共有できればと思います。 低コストをコンセプトにした背景 当時、自分は本件の他に3PJ（そのうち開発が2件）を同時進行していました。 他のPJではアジャイルな開発方式を取っており、毎週スプリントイベントDailyMTGを実施しながら漸進的に進めていました。 アジャイルな開発方式を取ることで不確実性への対処は容易になる一方、コミュニケーションに割く時間が大きくなります。 そのため、３開発をアジャイルにすると時間的な面で自分がボトルネックになる懸念を感じました。 そこで、開発規模が一番小さかった本件のPJはアジャイルにとらわれず、できるだけコミュニケーションコストを下げるようPJを設計しました。 メンバー構成・削ったこと・スケジュール感 このPJメンバー構成はプロダクトマネージャー（自分）、デザイナー、バックエンドエンジニア、フロントエンドエンジニア、プロセスエンジニア、直接手は動かさないプロジェクトマネージャーの６名で、それぞれが別のPJも兼務していました。 プロダクトマネージャー、デザイナー、エンジニアは一緒に仕事するのが初めてのメンバー同士でした。 また、各メンバーが別のPJを兼務している都合上、全員が揃うのを待つことはせず、各工程をFIXさせて次の工程に進めるウォーターフォールに近い形になりました。 実際のリリースまでのスケジュールはざっくりと以下のような流れになりました。 2週間：PdMが企画・ドキュメント化 2週間：デザイナーがUI/UXを確定 4週間：エンジニアが開発 2週間：PEがQA リリース コミュニケーションを削れるだけ削ったため、リリースするまでに全メンバーが顔を合わせたのはキックオフだけで、アドホックなMTGも数えるほどでした。 PdMとして気をつけていたこと コミュニケーションを削るということは、デザイナーやエンジニアはドキュメントから必要十分な情報を引き出せる必要があることを意味します。 なので企画の段階で体験やお問い合わせ時の対応なども考慮し、要件・体験・実装を意識したPRDを作成していきました。 それでもいくつか質問を受けるケースがありましたが、質問を受けた際は2分以内で答えるくらいの気持ちでやりました。 *1 結果的に特に大きなトラブルもなくスムーズにリリースできました。 このPJを通して得られたこと 低コストで大きな手戻りもなかったので、全体的にスピーディーに無駄なく価値提供できました。 今回のような方針でPJを設計することで、手が回りにくい小さめのPJも並行して動かせると感じました。 また、リリースを通して客観的に自身を見直す機会を得られたことも非常にポジティブにとらえています。 ウォーターフォールに近い開発スタイルとなったことで以下を意識する必要があったため、（仕事をする上で当たり前でありますが）普段の仕事の姿勢を改めて考える良い機会になりました。 自身で作成したスケジュールに責任を持つ 情報伝達の内容に責任を持つ 状況変化に対する報連相の意識が高める 特にこのPJではDailyもないので「明日共有すればいいや」という気持ちにならなかったことが大きいと感じました。 また、自身のドキュメンテーションの質を客観的に見直す良い機会となりました。 PdMとしてはドキュメントで必要十分な情報を伝えなければならなかったことで、以下を改めて意識することになったためです。 不明瞭さを残さない 無駄なことを書かない 読み手のコンテキストを意識する 最後に、今回は小さいPJかつ初めてのメンバーとの仕事だったので、PJ運用でトライしたかったことを小さく試すことができました。 PJ規模が大きくなると、PJ運用のスケジュールへの影響も無視できないため、積極的なトライがしにくくなります。 そのため、こうした方式のPJは実験、息抜き、マンネリの解消といった意味も持たせることができるように感じました。 おわりに 小規模なPJであれば、コミュニケーションを削ぎ落としてPJの並列数を増やすことができました。また、副次的に仕事の質やプロセスを見直すという価値も持たせることができました。 小規模の開発に割くリソースがない方、時間がないとお悩みの方、いつものやり方にマンネリを覚えている方は、勇気を持ってどこまで軽量にリリースできるかを楽しんで見てはいかがでしょうか？ 最後に宣伝です。BASE ではプロダクトマネジメントをするメンバーを募集しています。 興味がある方は下記の紹介資料や、採用情報もぜひご覧ください。 binc.jp *1 : リリース後の振り返りでエンジニアからFBを頂いたのですが、すぐに返答することがDaily（強制的に集まって問題を確認する場）を設けずに済んだ要素になっていたようです。

はじめに はじめましての人ははじめまして、こんにちは！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