BASE株式会社 の技術ブログ
全576件
BASE BANKでPdMをしている岡です。 先日、あるプロダクトの機能開発にあたってデザインスプリントを実施しました。 すると、 「デザインスプリントはチームビルドとしても良い効果がある」 という意外な発見がありました。 今回の記事では、このデザインスプリントの意外な効果について書きます。 この記事で述べることのまとめ デザインスプリントはチームビルドとしても良い効果がある 良い効果1：長期的なミッション・ビジョンに立ち返る 良い効果2：不確実性やイレギュラーケースを洗い出せる 良い効果3：機能要件をアクティブラーニングできる 良い効果4：メンバーのプロダクトへのエンゲージメントを高める デザインスプリントとは デザインスプリントとは、新しいプロダクトや機能のアイデアを迅速に検証するための 5日間の集中ワークショップ形式のプロセスです。 具体的には次のようなプロセスで行われます。 各プロセスの詳細は、次の記事を参考にしてください。BASE BANKチームでは以前にもデザインスプリントを行っており、そのときの内容を詳しくまとめた記事です。 note.com 以前のデザインスプリントでは、参加人数が過多になりそうだったため、PdMとデザイナーだけで実施しました。 しかし今回は、PdM・デザイナー・エンジニア・CSと多様なメンバーを含めて実施しました。 このように多様なメンバーを含めて実施したことで、アイデアの高速検証という効用だけでなく、チームビルドとしても良い効果が生まれました。 「チームビルドとしての良い効果」は、特に day1：理解 と day2：発散 のプロセスで実感したので、それぞれ順を追って書きます。 day1：理解（知識を共有しゴールを設定する） やったこと day1は、プロジェクトに関する知識を共有し、プロジェクトのゴールを設定するプロセスです。 具体的には次の4つのワークを行いました。 プロジェクト背景の共有 懸念点の洗い出し プロジェクトの成功の定義 コンセプトシートの作成 最後のコンセプトシートは、次のようなフォーマットで作成しました {ターゲットユーザー} は、 {具体的なペイン・ニーズ} という要望を持っているが、 {特定のハードル} という理由で満たされていない。 そこで、{新しいソリューション・アイデア} によって、 ユーザーに{理想の体験}という価値を届けたい。 良い効果1：長期的なミッション・ビジョンに立ち返る day1の「プロジェクト背景の共有」や「コンセプトシートの作成」というプロセスを通して、 長期的なミッション・ビジョンに立ち返る ことができました。 特定の機能の開発プロジェクトでは、どうしても機能単体の「なぜやるか」に焦点をおいてしまいます。 しかし、デザインスプリントのday1 では 「そもそもどのユーザーの何のペインを解決して、どういったビジョンを目指すか」 といった、原点を思い出させてくれる問いが用意されています。 実際に、この問いに答えるにあたって、 会社のミッション → チームのミッション → プロダクトのミッション→プロジェクトの目的 といった順番で、 本来の目的からプロジェクトの目的までブレイクダウンしながら詳細に伝えるように工夫しました。 全体から個別のミッションの繋がりを理解することは、ブレない組織を作る上で重要で、PdMとしては何度でもメンバーに伝えたい内容です。 こういった内容は、どうしてもメンバーに話す機会が限られているように思えます。メンバーとの日々の会話では、目の前の仕事を進めるための、もっと具体的で差し迫った話題が多くなりがちなので。 このように、デザインスプリントのday1は、我々の原点をメンバーに共有できるような仕組みになっています。 良い効果2：不確実性やイレギュラーを洗い出せる day1の「懸念点の洗い出し」というプロセスを通して、 PdMだけでは想定しきれなかった不確実性やイレギュラー が洗い出せました。 「懸念点の洗い出し」は、PdMから一通り実現したい機能について詳細まで伝えた後で、どのような懸念があるかをメンバーから述べてもらうプロセスです。 このプロセスでは、PdMやデザイナーだけではなく、エンジニア・CSと多様な職能のメンバーで実施したおかげか、 「このようなユーザーからの問い合わせが月にXX件くらいある」 「この機能を実現するにあたって、〇〇というエッジケースを想定した実装が必要だ」 など、想定していなかったユースケースや技術制約を発見できました。メンバー同士が対話しながら開発を進めるという、アジャイルに近いプロセスとも言えます。 副次的な効用として、自分とは異なる視点の指摘や知見の共有を通して、メンバー同士のリスペクトも高まったように思えます。 day2：発散・決定（アイデアを発散して決める） やったこと day2では、day1で共有した知識や背景を踏まえ、各々のメンバーがアイデアを出し合いました。 各々のアイデアを見つつ、最終的にどのようなソリューションが良いか決定するところまで進めました。 具体的には、制限時間をつけながら、各員が次の4つのワークを通して高速にアイデアを発散→収束まで行いました。 ライトニングデモ（ 情報収集） アイディアノート（アイデア発散） クレイジー8（アイデア発散） ソリューションスケッチ（アイデア収束） ソリューションスケッチの展示の様子↓ 最後に、一人一人のソリューションスケッチをお互いに見つつ、どのソリューションで進めるのかを決定します。 良い効果3：機能要件をアクティブラーニングできる day2のワークは、day1でインプットしたプロジェクト背景や、技術制約、ユースケースを思い出しつつ、自分なりのアイデアを黙々と考えスケッチしていく時間です。 このように、デザインスプリントは、 知識のインプット→アウトプットを高速で行うことで、細かい仕様やユースケースまで記憶に定着できる アクティブラーニングのような仕組みになっています。 良い効果4：メンバーのプロダクトへのエンゲージメントを高める day1で長期的なミッションを再確認したおかげか、「あらためて自分はどういったプロダクトを育てているのかがわかって、モチベーションがあがりました」といったメンバーの声もありました。 また、day2は全員のアイデアを踏まえてソリューションを決定していくプロセスであるため、 エンジニアやCSも一緒にUIUXを作るという、プロダクト作りの上流から関わる環境を作り出せました。 そのため、プロダクトへの愛着というか、エンゲージメントも向上できたように思えます。 メンバーのプロダクトへのエンゲージメント強化は、良いプロダクトを作るための大事な条件だと考えています。 Figma, IncのCPOである山下祐樹さんは、プロダクトへの「理屈を超えた情熱」が「魔法のようなプロダクト」を生み出す、といったことを述べられています。 blog.recruit-productdesign.jp デザインスプリントは、メンバーのプロダクトへのエンゲージメントを向上させ、「理屈を超えた情熱」を生み出す装置にもなると期待できます。 BASE BANKのメンバー募集 多様なメンバーを交えて実施するデザインスプリントは、良いプロダクトを作るためだけでなく、チームビルドにも良い効果がありました。 このようにBASE BANKでは、職能を横断し、対話を中心としたプロダクト作りを大事にしています。 このチームで一緒に働きたい！と思った方はぜひ求人からご応募ください。 open.talentio.com
はじめに こんにちは、BASE BANK Division で資金調達サービス「 YELL BANK 」の開発を担当している Doarakko です。 今回は前職でチームリーダーを務めた後にメンバーとして BASE に入社し、再度チームリーダーを務めて感じている役割の変化について話したいと思います。 前職での役割 前職では PdM 1名、デザイナー1名、エンジニア5~6名のチームでエンジニアリーダーを務めていました。 リーダーになった際のチーム状況としては、イテレーション開発はしておらず PdM とエンジニアの間に私が入り、メンバーのタスク状況を見て脳内パズルでタスクにメンバーをアサインする形で開発を進めていました。 エンジニアの人数が5~6名でこのやり方をしていると、どうしてもリーダーの負荷（リーダーがボトルネックになる）やチームの属人性も高くなっていました。 そこで私が開発よりもプロダクト開発プロセスの改善に比重を置いた方が、中長期的に見てチームのアウトプットを最大化できると判断してリーダーとしての役割を変化させました。 SCRUM BOOT CAMP THE BOOK に大変お世話になりながら、スクラムのアプローチを段階的にチームに導入したことを覚えています。 最終的にはプロダクト開発プロセスの改善と PdM のサポートが主な役割で、エンジニアリーダーと言いつつほぼスクラムマスターになっていました。 スクラムについては、自費で認定スクラムマスターの研修を受けに行ってしまうくらい好きになりました。 現在の役割 現在は PdM 1名、デザイナー2名、PMM 1名、アナリスト2名、エンジニアが2名のチームで Engineering Program Manager（エンジニアリーダー）を務めています。 BASE BANK における Engineering Program Manager（以降 EPM）の詳細については、以下の記事を読んでいただければと思います。 一言で言うと、プロダクトのデリバリーとクオリティに責任を持っています。 参考： プロダクトのデリバリー、クオリティに責任を持つEngineering Program Managerという役割 YELL BANK チームでは、スクラムのアプローチをチームの状態に合わせて取り入れながらイテレーション開発を行っています。 入社した当初は前職での経験を活かしてプロダクト開発プロセスの改善に比重を置いていた時期もありましたが、現在は開発業務がメインとなっています。 変わったこと、変わらないこと BASE に入社してからコードを書く時間は圧倒的に多くなりました（コミット数だけで比較しても前職の3倍くらい）。 それはリーダーになった今も変わりません。 自然とそうなった部分ももちろんありますが、意識的に変えたことでもあります。 プロダクト開発の複雑性はチームのメンバー数に比例して高くなり、それに合わせてプロセスを改善して得られるものも多くなります。 実際に スクラムガイド にも「スクラムとは、複雑な問題に対応する適応型のソリューション」だと記されています。 YELL BANK チームではエンジニア数が少ないことと、プロダクトの意思決定を基本的にはチーム内で完結できるということもあり、プロダクト開発の複雑性はまだそこまで高くありません。 実際に「前のチームでやっていたけどこれはやる必要ないか」「この辺はライトにやろう」などと考えることがよくあります。 例えば 細かい計測はせずに、スプリント内に差し込みタスクがどれくらいあったかだけわかるようにする ストーリーポイントは使わずに T シャツサイズで見積もりをする 一部属人化を許容する ある程度プロセスを整えた後に、ここからは私個人で出せるアプトプットを大きくした方がチームのアウトプットも大きくなると判断して、開発業務への比重を大きくしました。 チームやプロダクトのフェーズが変わればリーダーに求められるものも変わるというのは、聞いてみれば当たり前の話ですが、実際に体験してその変化を身に沁みて実感しています。 ただベースにある、リーダーとしてチームのアウトプットを最大化させて事業価値の創出に貢献すると言う考え方は変わりません。 これから別のチームでリーダーを務めることになっても、この考え方は変わらないのかなと思っています。 有難いことにこういったブログを書いているうちに、新しいメンバーが2人入社することが決まりました。 メンバー数が増えることでまた自分に求められる役割も変わったり、よりチームの問題を「チームで」解決していくことが必要になっていきます。 この変化を楽しみながらこれからもプロダクト開発をしていこうと思います。
はじめに こんにちは。BASEのデータ分析チーム（Data Strategy Team）で不正対策を行ったり、機械学習モデルを触ったりしている竹内です。 先日チーム内の論文読み会でニューラルネットを用いた画像合成によるバーチャル試着技術というトピックに触れる機会があったので、その最近のトレンドについて改めてブログという形でまとめてみました。 バーチャル試着は画像生成モデルの実用的なユースケースの一つとして今現在データセットの拡充やアーキテクチャの検証が進んでいる分野の一つであり、個人的には非常にアツいトピックだと感じています。 バーチャル試着とは バーチャル試着（Virtual Try On）とは、ある人物がある衣服を着用した状態を画像や3Dモデルなどの情報をもとに仮想的に実現し、どのように見えるか可視化する技術のことです。 ネットショップの普及により、店頭に出向かずともPCやスマートフォンから簡単に多種多様なファッション商品を購入することができるようになって久しい昨今ですが、その一方でオンラインではどうしても購入前に試着することで見た目やサイズ感を確かめることができないという課題を抱えています。バーチャル試着を利用することで、直接店頭へ出向かずに着用した際のイメージを得ることができるため、購入者においては誤って購入してしまうリスクを、ショップにおいては返品のリスクを減らすことが可能になります。 また、ネットショップの商品ページにおいては、扱っている商品単体の画像だけでなく、ファッションモデルがそれを着用した際のイメージ画像もよく利用されています。しかしながら、日々変化するトレンドの中で、商品が多種多様化し、ショップの規模もさまざまある中で、すべての商品においてファッションモデルを利用したイメージ画像を用意することは難しい場合があります。これについてもバーチャル試着を活用することで、多様なファッションモデルがさまざまなポーズで着用したイメージ画像を簡単に用意することが可能となります。 ニューラルネットを用いたバーチャル試着技術 バーチャル試着の実現においては3Dモデルの利用やAR技術、身体計測専用のスーツの利用など、さまざまな手法が検証されていますが、中でも昨今のニューラルネットを活用した条件付き画像生成技術の進歩により、入出力に画像を使用した分野においては目覚ましい進歩を遂げています。 ARやボディスーツなどと比較して入出力に画像を使用する場合は、カメラなどのデバイスの操作やスーツの着用といった手間がなく、またさまざまなポーズに対して自然な見え方が検証できるという利点があります。 ニューラルネットを利用したバーチャル試着モデルのイメージ（ 1 より作成） 画像生成モデルによるバーチャル試着の登場 ニューラルネットによる画像生成手法としては、長らくGANやVAEを利用したものが主流であり、バーチャル試着への応用についても当初はそれらの技術をベースとしたものが考えられていました。 2017年に発表されたCAGAN 2 という手法はその中の1つであり、その名の通りGANをベースとした手法です。 Generatorは人物画像とその人物が着用している服画像、合成対象の服画像の3つを入力として合成画像を出力し、Discriminatorは与えられた画像がデータセットからのサンプルなのか、あるいはGeneratorの出力なのかを識別します。 この時GeneratorはDiscriminatorに当てられないように出力し、Discriminatorは出力を正しく識別できるように学習を行います。 CAGANではGeneratorの出力を安定させるために2つの服画像をスワップさせながら2回Generatorに通すことで元の人物画像をどれだけ復元できるかをLossに含めている点が特徴的であり、一般的な条件付き画像生成と比較して出力の安定性を追求している点が伺えます。 スワップを利用したGeneratorの出力（[^2]より） Discriminatorは正例と負例を正しく識別できるように学習する GANから拡散モデルへ 2021年あたりから従来のGANやVAEではなく拡散モデルをベースとした手法が台頭しはじめ、それ以降、条件付き画像生成モデルの学習の安定性や出力のクオリティは格段に上がりました。 バーチャル試着においてもその恩恵は大きく、拡散モデルを採用することによって格段に正確な画像を高い解像度で生成できるようになっています。 拡散モデルを使用したバーチャル技術に関する論文はいくつかありますが、今回はその中でも特徴的なTryOnDiffusion 3 とOOTDiffusion[^1]の2つを取り上げたいと思います。 先にCAGAN、TryOnDiffusion、OOTDiffusionによる出力例をそれぞれの論文内から抜粋し、比較しておきます。 後者2つが拡散モデルベースの出力となりますが、再現度や解像度の面で大きな改善が見られていることがわかります。 CAGANによる出力例（入力画像） CAGANによる出力例（出力画像） TryOnDiffusionによる出力例 OOTDiffusionによる出力例 TryOnDiffusion タイトル: TryOnDiffusion: A Tale of Two UNets arxivリンク: https://arxiv.org/abs/2306.08276 2023年にワシントン大学とGoogle Researchのメンバーによって発表された論文です。 TryOnDiffusionはParallel-UNetと呼ばれる2つのUNetを使用し、一方へはターゲットなる人物にノイズを付与した画像と元画像の服部分をマスクした画像をconcatしたもの、もう一方へは試着対象の服画像を入力し、ノイズを除去するプロセスを繰り返すことで、出力画像を1024×1024という高い解像度で生成することに成功しています。 服の画像単体ではなく、ターゲットとなる人物の画像と、試着対象の服を着た別の人物の画像の2つを入力として使用している点が特徴的です。 TryOnDiffusionのネットワークの全体図（[^3]より） TryOnDiffusionでは2つのUNetの出力をcross-attentionを使用することで組み合わせています。（図の黄緑色のブロック） 1つのUNetにノイズ画像と服画像をconcatしたものを入力とする方法をとっていない理由として、服画像を人物画像にフィットさせる際形状を大きく歪める複雑な変形が必要となりますが、UNetで採用されている畳み込みとself-attentionのようなピクセル単位での強いバイアスがかかる機構はそれに適さないと言及されています。これについてはablation studyとして2つのアーキテクチャを比較した検証もなされていますが、単純なconcatと比較して細部のテクスチャにおいて違いが出ていることがわかります。 cross-attentionとconcatとの比較（[^3]より） 1つのDiffusionモデルの学習には32基のTPU-v4を使用しており、データセットとしては同じ人物が同じ服を別のポーズで着た画像ペアを400万ペア使用しています。 バッチサイズ256で50万ステップ回すのにだいたい3日かかると記載されており、かなり大掛かりなモデルであることがわかります。 ちなみにこのTryOnDiffusionを使用したバーチャル試着システムは2023年の6月からプロダクトとしてリリースされており、 Google’s Shopping Graph と呼ばれるGoogleの保有している商品データセットの一部ファッション商品を対象に、スキントーンや体型の異なるさまざまなファッションモデルが着用したイメージを取得し、購入の参考にすることができます。（現在は米国限定のようです。） https://blog.google/products/shopping/ai-virtual-try-on-google-shopping/ また、このモデルについてはデータセットやモデルパラメータは公開されていません。 OOTDiffusion タイトル: OOTDiffusion: Outfitting Fusion based Latent Diffusion for Controllable Virtual Try-on arxivリンク: https://arxiv.org/abs/2403.01779 OOTDiffusionは中国の大手AI企業Xiao-iのリサーチチームによって比較的最近公開されたバーチャル試着モデルであり、LDMを使用することで計算コストを削減しながら出力のクオリティの高さを維持しつつ、トップスだけでなく、ボトムスやワンピースなど、さまざまなカテゴリに対応している点が特徴です。 ネットワークのアーキテクチャについてはTryOnDiffusionと同様に衣服部分をマスクした人物画像を入力とするUNetと服画像を入力とするUNetの2つを使用し、UNet内のself-attention層の前でconcatするOutfitting fusionと呼ばれる手法で2つのUNetを繋げています。 OOTDiffusionのアーキテクチャ（[^1]より） 先ほどのTryOnDiffusionと大きく異なる点として、Stable Diffusionなどでも採用されているVAE encoderを使用して潜在空間上でノイズ除去を行うLatent Diffusionベースのアーキテクチャを採用しており、このため一般的なGPU一基で推論を動かすことができます。（さながらTryOnDiffusionのLDMバージョンといった感じでしょうか。）学習時のUNetの重みの初期値としてもStable Diffusion v1.5のものをそのまま使用していると記載されています。 また、全身に対応したバージョンにおいてはCLIPを使用しており、試着を行う部位に関して（”upper body”など）テキストでのガイドを入れることで、出力を安定化する工夫も入れられています。 OOTDiffusionについてはGithubでソースコードが、Hugging Face Hubでモデルパラメータが公開されているため、計算環境があればすぐに手元で検証することができます。（ライセンスはcc-by-nc-sa-4.0なので、そのまま商用利用はできない点は注意が必要です。） https://huggingface.co/levihsu/OOTDiffusion/tree/main/checkpoints 学習においては上半身限定のモデルにはオープンデータセットのVITON-HDを、全身に対応したモデルにはオープンデータセットのDress Codeを使用し、バッチサイズ64（高解像度のものは16）で36000ステップの学習をA100一基で行っています。 TryOnDiffusionと比較してもかなり軽量なモデルであることがわかります。 ちなみに、TryOnDiffusionとOOTDiffusionを含めた最近のニューラルネットベースのバーチャル試着モデルでは、ターゲットとなる人物の画像の服の部分をマスクする前処理を行うことがほぼスタンダード化しており、OOTDiffsuionでは姿勢推定モデルの openpose とセグメンテーションモデルの humanparsing の2つを組み合わせたパイプラインが利用されています。 バーチャル試着モデルに用いられるオープンデータセット 少し脇道に逸れますが、こうしたバーチャル試着モデルの学習やテストによく使用されているオープンデータセットについても触れておきます。 バーチャル試着モデルの性能の向上については、モデルアーキテクチャやアルゴリズムの改善と並行して高品質かつサイズの大きなデータセットの拡充も後押ししています。（そこまでメジャーとは言えないタスクの割には利用しやすいデータセットが複数存在するため、研究や検証のテーマとしては案外取り組みやすい印象です。） また、これらのデータセットについては基本的には研究用途でのみ使用できるライセンスが設定されています。 VITON-HD KAISTによって公開されているデータセットで、複数の論文でベンチマークとしてもよく使用されている印象です。 1024 x 768の高画質な人物画像と服画像のペアが、学習用が11647セット、テスト用が2032セット含まれています。 また、それぞれの人物画像に対してpose推定やdense推定など処理済みのデータも含まれています。 https://github.com/shadow2496/VITON-HD FashionTryOn 山東大学によって公開されているデータセットであり、VITON-HDより大規模なデータセットになります。 服画像と異なるポーズの人物画像2ポーズ分の3点を1セットとして28714セット含まれています。 https://fashiontryon.wixsite.com/fashiontryon DressCode イタリアのモデナ・レッジョ・エミリア大学とイタリアの大手EC企業YOOX社によって公開されているデータセットであり、バーチャル試着モデルのデータセットとしては最大規模のサイズのものとなります。また、データセットに含まれるファッション画像はトップスだけにとどまらず、ボトムスやアクセサリなど、さまざまなカテゴリーのものが含まれている点が特徴です。 OOTDiffusionの全身モデルの学習にも使用されています。 https://github.com/aimagelab/dress-code データセットの規模の比較（ 4 より） 課題 上記の論文以外にも拡散モデルを利用したバーチャル試着を検証した論文はいくつかあり、いずれにおいても従来のモデルと比較してKIDなどの指標において高い数値を出すことに成功しており、定性的にもクオリティの高い出力を得ることができていますが、まだ改善の余地もあります。 上記の論文で課題として挙げられている点としては、 入力画像の背景が複雑な場合に出力にどのような影響があるか不明である。 人物画像と服の画像のカテゴリが異なる場合、例えばTシャツを着ている人物にワンピースを、ズボンを履いている人にスカートを合わせる場合は期待した出力が得られない場合がある。 服部分をマスクする際に人物の肌の情報（筋肉の状態やタトゥーなどの特徴）が欠損する。 といったものがあります。 1つ目に関しては、人物と背景を分けるセグメンテーションを前処理に挟むことで背景に対してある程度背景に頑健なパイプラインを組むこと自体は可能に思えます。 2つ目に関しては、データセットにそういったサンプルがないためであると考えられ、データセットのバリエーションを増やすことによってある程度改善できる可能性があると述べられています。 3つ目については、2つの論文で共通して挙げられている課題であり、こちらも前処理でセグメンテーションを行う範囲をより限定することができれば、ある程度改善できそうです。しかしながら長袖→半袖のような入出力を考える場合は情報が足りないため、その場合はそれを補うような入力を追加する必要がありそうです。 また、そもそも入出力に画像を利用している以上、オーバーサイズやタイトめなどといったサイズ感やシルエットについては正確な情報を反映しづらいという点があるというのは実際に動かしてみて私が実感した課題です。 まとめ ニューラルネットを使用したバーチャル試着技術について紹介しました。 画像生成においてバーチャル試着というユースケースについては、StableDiffusionなどでプロンプトからオリジナルの画像を生成する用途などと異なり、クエリとなる画像から期待される出力が非常に限定されるため、少しでも歪んでしまったり服の柄が変わってしまうだけで利用価値が大きく損なわれることになります。 逆に言えば、モデルの性能やデータセットのバリエーションの向上に合わせて一気にその実用性が高まっていくような分野でもあるため、今後の技術的な進歩や実際のサービスへ導入などへの期待が高まります。 最後となりますが、弊社では一緒に働いてくださる方を広く募集しております！ご興味のある方は下記のリンクからお気軽にご応募ください！ https://binc.jp/jobs Xu, Yuhao, et al. "Ootdiffusion: Outfitting fusion based latent diffusion for controllable virtual try-on." arXiv preprint arXiv:2403.01779 (2024). https://arxiv.org/abs/2403.01779 ↩ Jetchev, Nikolay, and Urs Bergmann. "The conditional analogy gan: Swapping fashion articles on people images." Proceedings of the IEEE international conference on computer vision workshops . 2017. https://arxiv.org/abs/1709.04695 ↩ Zhu, Luyang, et al. "Tryondiffusion: A tale of two unets." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition . 2023. https://arxiv.org/abs/2306.08276 ↩ https://github.com/aimagelab/dress-code ↩
ごあいさつ はじめましての人ははじめまして、こんにちは！BASE BANK Divisionのフロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です。 今回は、ここ数ヶ月の間にOIDC（OpenID Connect）という技術を使った開発を複数行い、この技術の概観を理解することができたので、OIDCの技術概要に触れつつBASE BANKの中でどのように使ったのかをご紹介しようと思います。 OIDCとは何なのか このパートでは、まずOIDCという技術について概要を紹介します。いくつかのWebページに記載されていた内容を参考にしてまとめさせて頂いているので、記事の最後に参照元のリンクを記載しておきます。 また、OIDCをはじめとした認証・認可の仕組みには様々な用語があり、自分自身も「調べれば調べるほど知らない用語が増えて、どんどんわからなくなってきた…」という経験をしたので、それらを具体例を交えて箇条書きなども用いながらまとめています。もし、明らかに間違ったことを書いている場合はX（旧Twitter）などで適宜ご指摘いただけますと幸いです！ OIDC（OpenID Connect）とは？ OIDC（OpenID Connect）は OpenID Foundation が策定をしている、アイデンティティ情報を連携するためのプロトコルの一種です。 このプロトコルは、Webアプリケーション等で利用する場合はOAuth 2.0（Googleログインなどで使われている「認可」プロトコル）をベースに、アイデンティティ情報を持つサーバー（IDプロバイダ）とサービスを提供するアプリやWebサーバー（サービスプロバイダ）でやり取りする値の中身まで定義しており、「認証」に使えるプロトコルとして定義されています。 この「認証」プロトコルを使ってSSO（シングルサインオン）の機能を実現することが多く、2024年現在では様々なところでOIDCプロトコルに対応した認証機構が用意されています。 ここまでで「認証と認可」や「SSO（シングルサインオン）」など、いくつか専門用語が出てきているので、これらがどういうものなのかおさらいしていきましょう。 認証と認可の違い 認可 : ユーザーまたはサービスに、 データへのアクセスまたは特定の処理の実行を許可する こと 認証 : 誰かまたは何かが、 主張する通りの人物または物であるかどうかを検証し、特定する こと 出典: https://www.onelogin.com/learn/authentication-vs-authorization OAuth2.0では「認可」を行うための仕組み（認証を実装しようと思えば出来るが、技術仕様上は担保出来ないので非推奨）を定義しています。 例えば、OAuth2.0を使ったGoogleログインなどでは「Googleの画面でログイン→Googleの認可サーバーからアクセストークン発行→Googleのリソースサーバーにアクセストークンを渡してデータを取得」というフローでデータのやり取りが行われています。 ただ、発行されたアクセストークンには「誰のリソースにアクセスしていいか？」という情報しかない（そのアクセストークンを送ってきたのが誰なのかはわからない）ため、何らかの方法でアクセストークンを盗まれると、認可サーバー側で認可した人以外にリソースを奪取されてしまうことになります。 OIDCではこれを防ぐために、「IDトークン」という形の（暗号化・復号化の仕様まで定義された）トークンをやり取りすることで「やり取りをしている相手が誰（何）であるか」を識別し、それを元に適切な権限付与を行えるように技術仕様を定義しています。 [追記: 2024-05-02] 後日、X上にて @pinzolo 様よりご連絡をいただき、図の中の誤っていた部分（「⑤ IDトークンを送信」と記載していた部分）を「⑤ アクセストークンを送信」という形に修正しました！ ご指摘いただき誠にありがとうございました！ 記事内の図の話ですが、OIDC で UserInfo endpoint からユーザー情報を取得するときも access token を使います。ID Token は受け取って検証するだけで送信しないです。 https://t.co/Wz7sAxtFeZ — pinzolo (@pinzolo) 2024年5月2日 要求された End-User の Claim を取得するため, Clientは OpenID Connect Authentication を通して得られた Access Token を用いて UserInfo Endpoint に要求する. 引用元: https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#UserInfo SSOとは SSO（シングルサインオン）とは「1つのアカウントにログインすることで複数のサービスのログインが可能になる機能」のことです。この機能を実現するために、OIDCやSAML（後述）という技術・プロトコルを利用するという関係性です。 BASE内では OneLogin （クラウド型ID管理サービスの一つ）を使ったSSO環境を利用しており、Google Wokrspaceなど各種アカウントへのログインをセキュアに便利に利用できるように環境が構築されています。 SAMLとは SAML（Security Assertion Markup Language）は、XMLベースの認証情報を表現する方法の規格のことです。現在では、そのSAML（XML情報）を送受信して認証を行うルール・プロトコルまで含めてSAMLと表現されることが多いです。 SAML認証では、サービスプロバイダ側からIDプロバイダに対してSAML形式のXMLファイルをあらかじめ登録し、ID情報を「どこから入手するのか・どこに提供するのか」の連携を事前に取っておく形で認証が実現されています 現在主流のSAML 2.0は2005年に仕様が策定され、SSOの機能を作る際のデファクトスタンダードな仕様として使い続けられてきたため、世の中に非常に多くの文献・利用事例などがあります。 しかし、そもそも XMLのパースやそのパース後のデータを利用した通信フローの作成、XML自体の脆弱性の対応が必要だったりして、全体として難解になりがち で、仕様を理想通り実装できれば全く問題ない認証方式だが、 現実は実装に問題があって脆弱になってしまうということが起こりがち なものでした。 そのため、SAMLを代替できるようにOIDCが生まれ、利活用されてきている。という背景があります。 SAMLとOIDCの違うところ 以上のように、SAMLとOIDCは どちらもSSOに使われる技術であり、認証を実現するための技術であり、どちらもIDプロバイダとサービスプロバイダとクライアント（ユーザーの端末）が決められた手順で通信を行って認証する技術 です。 逆に、差分として以下の2点があり、今回BASE BANKでは「サービスプロバイダ側の実装が簡単になる」というメリットを享受するためにOIDCを使った認証・連携処理を作成しました OIDCはHTTPS通信でデータをやり取りし、JWTという（XMLよりも）単純な文字列をやり取りするため、サービスプロバイダ側の実装が簡単になりやすい OIDCでは、サービスプロバイダ側からIDプロバイダに対して希望する データのスコープ（範囲）をリクエストできることが仕様として存在 しており、クライアント（ユーザーの端末）に対してサービスプロバイダにどのデータが与えられるかを伝えることが容易に実現できる 今回BASE BANKで使ったところ ここまで、OIDCとそれに関連する技術・キーワードについて紹介をしてきましたが、ここからはその技術を実際どこで使ったの？というところを紹介していきます。 GitHub ActionsからAWSリソースにアクセスし、デプロイする 1つ目のユースケースは、 GitHub Actionsを使って、AWS上にある開発環境（ステージング環境とは別に、非エンジニアが動作確認する際やQAを行う時に利用する環境）に対してアプリケーションをデプロイする ワークフローを作成する際にOIDCでの認証を利用しました。 BASE BANKチームが主に開発を行っている YELL BANK （BASEのショップオーナーさん向けの資金調達機能）のバックエンドには、APIとして利用するアプリケーションが複数あります。 ざっくりとした技術構成に関しては、 BASE BANKチームの紹介資料 をご覧ください。 これまではステージング環境での確認で事足りていたため開発環境を使う機会が少なく、本番へのデプロイと同時に（本番との差分をなくすためのデプロイを）CI上で行うだけで問題なかったのですが、この環境をもっと活用していくために開発環境へのデプロイを自由なタイミングでもっと手軽に行えるようにしたい！というモチベーションからこの対応を行いました。 全体の作業の流れとしては、以下のように大きく3つのステップで実現できました。 AWS IAMでOIDC Providerを作成する（このProviderにロールを指定し、AWS リソースへのアクセス許可を行う） https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc.html GitHub Actionsのステップで aws-actions/configure-aws-credentials を使い、上記で作成したOIDC Providerを指定する https://github.com/aws-actions/configure-aws-credentials?tab=readme-ov-file#oidc GitHub Actionsのワークフローを workflow_dispatch から利用できるようにし、GitHub上のActionsタブから利用する（完成！） より詳しい解説はGitHub Actions公式の解説ページをご覧ください。 docs.github.com AWS IAMでOIDC Providerを作成する 今回はマネージメントコンソールからOIDC Provider作成する方法を解説します。（ AWS CLI経由など他の作成方法はAWS公式ドキュメント をご確認ください） 以下のように、 GitHub公式の解説ページ に記載されているプロバイダのURL（AWS ⇒ GitHubへのリクエスト先なので、基本的にここはユーザー個別ではない）を設定し、サムプリントの取得の上ID Providerを作成してください。 ID Providerの作成後、IAMロールを割り当てることでAWSリソースにアクセス可能なOIDC Providerが出来上がります。 注意点としては、AWS IAMの管理単位として上述の「プロバイダのURL」に設定したURL単位で1つのIAMユーザーとして扱うため、1つのAWS環境に対してのGitHub ActionsからのOIDC経由アクセスは1つに集約されてしまい、GitHub Actionsのワークフロー / リポジトリごとに「このリソースへのアクセス権限だけ与える」ということは出来ない点だけご注意ください。 GitHub Actionsのワークフローの作成 今回は将来的な拡張も見据えて、以下のような形で workflow_dispatch の input として環境名を受け取れるようにしていますが、基本的には GitHub公式の解説ページ のGitHub Actionsのワークフロー設定を踏襲して実装しています env : dev_id : 123456789012 on : workflow_dispatch : inputs : env : description : "deploy env（現時点は dev のみ）" required : true type : choice default : "dev" options : - "dev" jobs : deploy : name : deploy runs-on : ubuntu-latest permissions : id-token : write contents : read actions : read steps : - uses : actions/checkout@v4 - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v4 with : # 作成したIAM Role名を指定する # see: https://github.com/aws-actions/configure-aws-credentials # 例) dev指定のときに env[format('{0}_id', inputs.env)] => dev_idを取り出す role-to-assume : arn:aws:iam::${{ env[format('{ 0 }_id', inputs.env)] }}:role/${{ inputs.env }}-oidc-provider aws-region : ap-northeast-1 （以降は、各ステップでデプロイに必要なAWS ECRへのコンテナのPushやAWS ECSクラスターへのプロビジョニングコマンドをaws cli経由で実行している） GitHub上のActionsタブから利用出来るように 上述のYAMLファイルをデフォルトブランチにマージすることで、Actionsタブから以下のように実行することが可能になります。 画面右上のRun workflowから実行時に利用するブランチと環境情報を選択できるので、これでデフォルトブランチ以外のブランチを開発環境に適用することもGUIからかんたんにできるようになりました。 社内向け管理画面でNextAuthを利用し、OneLoginを使ったSSOを実装する 2つ目のユースケースは、 新たに作成する社内向け管理画面のログイン機構にOneLoginを使ったSSOでの認証機構を用意するために、NextAuthでOIDCを利用 しました。 NextAuth とは、複雑な認証・認可の処理をラップして提供してくれるJavaScript向けライブラリのAuth.jsの派生ライブラリで、中でもNext.js用にチューニングされたものの名前です。 このNextAuthを使った社内向け管理画面自体はまだ完成していない状態ではありますが、PoCの段階でOIDCでのOneLoginとNext.js製アプリケーションとの連携が問題なく行えることを確認できて、このまま本番投入を行う予定のため、主になぜこの意思決定をしたかをご紹介します。 今回のOneLoginと社内向け管理画面のログイン機構では、OneLoginが提供しているAppの 「OpenID Connect (OIDC) Custom Connector」を利用してClient ID / Client Secrets / Issuer情報を発行 し、それらの情報を NextAuthのOneLogin Providerの形式 に合わせて利用する形を取っています。 このアーキテクチャでの実装（IDaaSやフレームワーク選定）をなぜ選択したのか？をまとめたADR（Architecture Decision Records）があるので、そこから内容をサマライズし箇条書きしたものを以下に記載しておきます なぜクラウド型ID管理サービス（認証IDaaS）はOneLoginを利用するのか？ BASE内のSSO環境でOneLoginを使っている事例が複数あるため、それと合わせたSSO環境を利用すると認証、認可情報の管理を効率的に行えると考えたため なぜOIDCの実装でNextAuthを利用するのか？ 今回、管理画面を作成するプロダクトのプロダクションコード側は既にNext.jsで実装されており、（フロントエンドメンバーの人数がチームに少ない事もあって）学習すべき技術を分散させないためにNext.jsを利用することにしたため Next.jsを利用する場合、ブラウザ上での実行なのかサーバー上での実行なのかがコード上から判別しづらく、OAuth 2.0（OIDC）の通信ステップをある程度隠蔽して、NextAuthのAPI経由で認証データを取得する方が全体像の理解がしやすいと考えたため なぜOneLoginとの接続方法はSAMLではなく、OIDCを利用するのか？ 前述の解説パートの通り、OIDCはSAMLの代替になるようOAuth 2.0の仕様を拡張して定義された認証方法。SAMLに比べるとまだまだ導入事例は少ないが、直近はAWS、GitHub、Azure、GCP等様々な箇所の認証方式として利用されていて、2024年時点でSAMLではなくOIDCでの導入に踏み切っても、問題ないと判断できたため OneLoginからOIDC認証経由で取得できるデータ（claim）の種類も必要十分であることがわかり、取得可能なデータと言う面でもOIDCで問題ないと判断できたため このURL から確認できるJSONの claims_supported の値 その他、検討したが選択しなかったこと SDKにAuth0を使うパターン OneLoginと併用する場合、認証IDaaS（SSO提供サービス）が二重（ Auth0 → OneLogin ）になり、Auth0とOneLoginをSAMLで連携させないといけないため 社内でのAuth0の利用事例はなくゼロから探索をする形になる。そのコストを払うよりもOneLoginを使う方が効率的だと考えたため Auth0のSDKにNext.jsとExpress以外のものはなく、アプリケーションの実装フレームワークをNext.jsにする選択肢（Next.jsへのロックインを避ける方向）としても、特にNextAuthと比べた差分がなかったため NextAuthを使わず、OIDCの通信ステップをフルスクラッチするパターン Next.js上でフルスクラッチでOIDC（OAuth 2.0 + IDトークン）の認証フローを実装するのは、Next.jsがSSRとCSRどちらも活用してアプリケーションを作成するフレームワークである以上、コードの複雑性が高まりやすい。そのため、フルスクラッチ実装 + そのメンテナンスと、NextAuthライブラリのバージョンアップ等のメンテナンスコストを比較したときに後者のほうがコストが低いと考えたため 認証をID/Passwordでフルスクラッチするパターン 入退職者管理、セキュリティ脆弱性を産まない実装、適切なアクセスコントロールを実現するために、OneLoginのSSO基盤の上に乗せる形に比べてコストがかかりすぎると判断したため おわりに ここまで、OIDCという技術について関連キーワードも含めた紹介とBASE BANKチームの中でどのように利用したのかを紹介させていただきました。 今回ゼロからOIDCという技術を学びつつ、導入のメリット・デメリットなどを整理していましたが、非常に便利な技術で適宜活用していきたいなと思いました。 このように、新機能開発や新規事業などはもちろんのこと、フルサイクルエンジニアとして計測基盤を盤石にするための開発や開発体験の向上のための開発などなど…様々な開発が少人数で活発に行われているが故に、適切に調査・言語化することで技術選定を任せてもらうチャンスも多いBASE BANKチームにもし興味が湧いた方はぜひカジュアル面談などにご応募いただけると嬉しいです！ gatchan0807としては、一緒にBASE BANKチームのフロントエンドを盛り上げてくれる方をとっても求めています！ X（旧 Twitter） のDMやリプライなどでも問題ないので、お気軽にお声がけください〜！ 参照したWebページ 最後に、この記事を書くにあたって参照させて頂いたページを紹介してこの記事を締めくくろうと思います。知識を公開情報にしてくださった先人たちに最大限の感謝をこの場でお伝え出来ればと思います。ありがとうございました！ https://www.openid.or.jp/document/ https://openid.net/developers/how-connect-works/ https://www.onelogin.com/jp-ja/learn/oidc-vs-saml https://www.cloudgate.jp/glossary/saml.html https://boxil.jp/mag/a2950 https://admina.moneyforward.com/jp/blog/saml-sso https://solution.kamome-e.com/blog/archive/blog-auth-20221108/ https://logmi.jp/tech/articles/322829 https://img.logmi.jp/article_images/JCf94mRZseDVe6Dq2CiBU8.jpg https://www.slideshare.net/tkudo/openid-connect-devlove https://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06
はじめに こんにちは、バックエンドエンジニアの@zawaです。 私は入社以来、1年ほどショップオリジナルの「メンバーシップ」（会員制度）を開設できる「メンバーシップApp」の開発に携わってきました。 少し前になりますが、2024年2月末にメンバーシップAppの特典交換機能をリリースしました。 リリース内容の詳細はぜひこちらをご覧ください！ baseu.jp メンバーシップAppは、モジュラーモノリスのアーキテクチャ上に構築しており、モジュール内部ではドメイン駆動設計（以下、DDD）を採用しています。 先日公開された動画の中でも紹介していますので、ご興味がある方は是非ご覧ください。 【前編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 【後編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 本記事では、初めてDDDを採用したチームが直面した課題と、またそれらをどのように克服していったのかをお伝えしたいと思います。何か参考になることがあれば幸いです！ プロジェクトの概要 メンバーシップAppの開発は、次の3段階でリリースし、1st~3rdまでの総期間は1.5年ほどかかりました。 1st：メンバーシップを開設できる機能 2nd：ショップオリジナルのポイントを貯められる機能 3rd：購入時に貯まるオリジナルポイントと、ショップで設定した特典を交換できる機能 領域を分けてコンフリクトしないようにしつつ、2チーム体制で開発を行っていました。 エンジニアだけでも15人前後は関わっており、かなり多くの人が関わっていたプロジェクトでした。 私は1stの途中からチームに参加し、主にショップオーナーさん向けの機能開発を担当してきました。 1st、2ndで得た学び 初めのうちは、チームでの輪読会や組織内の有識者への相談を通じて、徐々にDDDに関する理解を深めていきました。 2ndのリリース後の振り返りの中で、どうすればさらに改善できるかについて、具体的な振り返りを行いました。 データモデリングとドメインモデリングの誤解とその影響 まず、1st、2ndでは、データモデリングとドメインモデリングのそれぞれの目的を正しく理解できていなかったね、という話題が出ました。 ドメインモデリングではドメイン領域に焦点を当てて会話し、ドメイン領域への理解を深めることが重要ですが、私たちのチームはデータの永続化や具体的なデータ構造に関する議論に偏っていました。 事前にデータモデリングの勉強会を行い、テーブル構造を事前に検討した影響もあってか、エンティティや値オブジェクトを特定した後も、「このエンティティの永続化が必要か」「どのタイミングで永続化すべきか」「どのようなデータ構造が適切か」という永続化の観点が議論の中心になってしまい、ドメインの振る舞いやルールについて十分な検討を行う前にドメインモデルの実装に進んでしまいました。後になってから、永続化とドメインモデルは別々に考えるべきだった、ということに気づきました。 これによって、次のような実装になってしまい、オブジェクトの整合性も保ちづらく、保守性も低い上に理解しづらい実装になってしまいました…😢 ドメインルールや振る舞いについて深く考えることができなかった結果、本来ドメインモデルにあるべき実装がアプリケーション層やドメインサービスに漏れてしまうことがあった。 集約について議論していなかった結果、テーブルとRepositoryが1対1になっていたり、ロジックの置き場所に困ることがあった。 例として、メンバーシップの編集をする際のメイン画像の登録/削除ロジックは、アプリケーション層に次のように実装していました。（⚠️サンプルコードなので実際の実装とは大きく異なります） 当時は手探りの中、スピード感を持って実装していたので致し方ないのですが、本来ドメインモデル振る舞いの中で実行されるべきロジックが、アプリケーション層に漏れ出てしまったことで、テストのしやすさや保守性が損なわれていました。 /** * リクエストに画像URLが存在していないとき * ・ 既に画像が保存されている場合は削除する * ・ 画像が保存されてされていない場合、何もしない * * リクエストに画像URLが存在しているとき * ・ 既に保存されている画像があるとき * ・ 同じ場合、何もしない * ・ 異なる場合、古い画像を削除して新しい画像を保存する * ・ 画像が保存されていないとき、新しい画像を保存する */ // リクエストの画像URLを取得 $requestImageUrl = $request- > getImageUrl(); // データストアから、メンバーシップを取得 $membership = $this- > membershipRepository- > find($membershipId); // データストアから、登録済みのメイン画像URLを取得 $savedImageUrl = $this- > mainImageRepository- > find($membership- > getId()); if (is_null($requestImageUrl)) { if (!is_null($savedImageUrl)) { // 画像が保存されている場合、削除 $this- > s3ImageRepository- > delete($savedImageUrl); } // 画像が保存されていない場合、何もしない } else { if (!is_null($savedImageUrl)) { if (!$requestImageUrl- > equals($savedImageUrl)) { // 保存されている画像が異なる場合、古い画像を削除して新しい画像を保存 $this- > s3ImageRepository- > delete($savedImageUrl); $this- > s3ImageRepository- > save($requestImageUrl); $this- > mainImageRepository- > save($requestImageUrl); } // 同じ場合、何もしない } else { // 画像が保存されていない場合、新しい画像を保存 $this- > s3ImageRepository- > save($requestImageUrl); $this- > mainImageRepository- > save($requestImageUrl); } } // メンバーシップを保存 $this- > membershipRepository- > save($membership); モデリングへのフィードバック 実装したドメインモデルについて、使いづらさや保守性の観点での違和感を感じつつも、修正することができなかったことに関して、「途中で立ち止まる時間が欲しかった」という話題も出ました。 ドメインモデルを実装し、実際にユースケースから使ってみて、その結果をモデリングにフィードバックするサイクル回すことが重要なのは理解しながらも、実務の中で再ドメインモデリングをしようと言い出すことは一定のハードルがあることが振り返りの中でわかりました。 ドメインモデルは色々なユースケースから使われるので、再モデリングをする場合、認識を合わせたり、改修するコストが高くなるのではと感じてしまい、結果として修正するアクションができなかったのではないかと思われます。 3rdではどうなったか 2ndリリース後の全体振り返りでうまくいかなかった部分について振り返ることができ、3rdでは改善することができました！ 3rdではデータモデリングとドメインモデリングを分けて考え、最初からドメイン領域に焦点を当てた設計をする動きができました。ユースケースをもとに、エンティティや値オブジェクトを探し出す作業、そしてドメインルールや振る舞い、集約についても深く考えることができたと思います。 これまでは、ドメインモデリング図はホワイトボードツールで作成をしていましたが、作成したモデリング図は明確な管理方法が決まっていたわけではなく、コードに落とし込んだ後は使い捨てるようなケースもありました。そのため、議論に参加していないと、どのような理由でどう変更されたかがとても追いづらい状況でした。 再モデリングを気軽にやりやすくするために、3rdではmermaidで書いてGit管理するようにしました。Git管理することで、変更履歴を追いやすくなり、大きな変更でなければ共有はPRで済むようになり、ドメインモデルの修正作業が以前よりも気軽に行えるようになりました。 メンバーシップ特典登録では、特典画像を登録することができます。画像登録は1stで実装したメンバーシップのメイン画像のドメインモデルを流用できれば良かったのですが、先ほどの例のとおり、ロジックがアプリケーション層に漏れ出しており、流用するのが難しい状態でした。そこで、再モデリングをし直して、リファクタをしました。 メンバーシップのメイン画像はメンバーシップと同じライフサイクルをもつため、メンバーシップ集約ルートとし、メイン画像はその集約の中に含めることにしました。 これにより、メンバーシップの編集ロジック内に、画像の登録/削除のロジックを閉じ込めることができ、アプリケーション層がとてもシンプルになりました🎉 // リクエストの画像ファイル名を取得 $requestImageFileName = $request- > getImageFileName(); // データストアから、メンバーシップ集約を取得 $membership = $this- > membershipRepository- > find($membershipId); // メンバーシップ集約が持つ、画像ファイル情報を取得 $savedImageFileName = $membership- > getMainImageFileName(); $membership- > edit( $request- > getName(), $request- > getDescription(), $requestImageFileName, ); if (!$membership- > isSameMainImageFileName($savedImageFileName)) { $this- > s3ImageRepository- > save($shopId, $savedImageFileName, $requestImageFileName); } // メンバーシップ集約を保存 $this- > membershipRepository- > save($membership); よいモデリングができると、複雑さなロジックをドメインモデルに閉じ込めることができるので、アプリケーション層では振る舞いを呼び出せばよく、とてもシンプルになる上に、責任が明確なので、とてもテストがしやすくなりました。試行錯誤してよいモデルができてからは実装速度が上がっていったように感じます！ 一方で正解のないドメインモデリングにこだわりすぎてしまい、時間をかけ過ぎてしまっているかも？という感覚もありました。どこまで作り込むべきなのか、この辺りはとても塩梅が難しいところだなと感じました。 最後に 私自身、これまでの経験で、設計についてここまで深く考えたことはなかったのですが、このプロジェクトを通じて、チーム全体でDDDやOOPに対する理解が深まり、保守性の高いシステムの開発ができたのではないかと思います。 難しい挑戦ではありましたが、モチベーションの高いメンバーと一緒に理解を深めながら開発ができたことがとても良い経験となりました！ また、スクラム開発を採用し、振り返りを重視したことで、1.5年にわたる長期プロジェクトの中でも、1st、2nd、3rdと各段階で以前の欠点を改善しながら前に進むことができたと思っています。 最後になりますが、BASEでは一緒に働くエンジニアを積極採用中です！ 今回紹介したようなモジュラモノリスやドメイン駆動設計に少しでも興味を持っていただける方がいたら、ぜひご連絡ください！ open.talentio.com
こんにちは。BASE BANKの02 ( @cocoeyes02 )です。 2024/04/13（土）に開催されたPHPカンファレンス小田原 2024に登壇してきました。今回の記事では登壇についてのコメントと、会場の様子についてお届けします！ 今回のセッション LT最後のトリを務めました！もともと地元が小田原に近く、今回のカンファレンスでは 「小田原っこ」枠 での登壇となりました！ speakerdeck.com PHP8.2 / 8.3の新機能である Random\Randomizer クラスについて、時間がゆるす限りコードや実行結果とあわせて、ひたすらユースケースを話しました！ 今回のトークで、かなり Random\Randomizer クラスへの理解が深まりました。プロダクトコードやOSSライブラリで使用しているPHPのバージョンによっては、Random\Randomizer クラスを使った処理へと書き換えできないか、機会を伺ってみてもよいなと思いました！ また、今回のLTでは、理解しやすさや納得しやすさを優先したため、日常的なユースケースをメインに扱いました。 扱っている業務次第では、プロダクトコード上で乱数処理を使用する機会はたくさんあると思います。ぜひスライドに載っている今回使用したリポジトリや、 PHP Playground のURLから、手を動かして理解を深めてみてください！ 会場の様子 会場は小田原ならではの体験が多かったです！ 各ブースコーナーに訪れると、小田原や小田原近辺のお菓子がもらえました。 また、PHPカンファレンス小田原のスポンサーブース以外にも、小田原市移住相談ブースがありました。 小田原市役所の方々が、小田原市に住む上で参考となる情報を様々な観点で教えてくれるブースでした！オープニングを聞いてから、一番最初に小田原市移住相談ブースに駆け込みました。 小田原市のブースには醤油せんべいが置いてあります🍘 #phpcon_odawara pic.twitter.com/2yEF2AApBU — PHPカンファレンス小田原 (@phpcon_odawara) 2024年4月13日 めっちゃ参考になった（ほくほく） #phpcon_odawara https://t.co/RABzGlur4b — 02 (@cocoeyes02) 2024年4月13日 また、スペシャルゲストとして、 小田原市観光PRキャラクターのうめまる が登場しました！ LTで時間切れに鳴ったらドラを叩いたりしてくれました！LT中の02とうめまるとのツーショットです（このあと無事（？）時間切れでドラがなりました）。 02さんの方がでかそう #phpcon_odawara pic.twitter.com/Kv9A4mdPjb — しめじ/Kaga (@TAKA_0411) 2024年4月13日 最後に スタッフの方々には業務でお忙しいにも関わらず、多くの時間をカンファレンス準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。 小田原愛の溢れたユニークでとても素敵なカンファレンスでした！また来年も開催されたらぜひ参加したいです！ありがとうございました！ 最後に、BASE では絶賛採用中です！下記リンクからぜひご覧ください！ binc.jp
こんにちは。BASE株式会社の開発担当役員、かつ、子会社でPAY.JPを提供するPAY株式会社の取締役をしている藤川です。 JTC（Japanese Traditional Company）などと呼ばれたりする主に日本の歴史ある大企業のDX化の文脈において、バイモーダルITという考え方があります。JTCたる既存の大企業は、SIerが構築した基幹システムをITの根幹として事業を運営していましたが、昨今叫ばれるDXの取り組みにおいて、本業における顧客接点以外にITシステムでも顧客接点を実現していくための組織を整理する手段としてバイモーダルITという考え方を使うことができます。 考え方として、 SoR （System of Record）と呼ばれるデータを記録することに重きを置く既存の基幹システムと、 SoE （System of Engagement）と呼ばれるエンドユーザとの結びつきを実現するためのシステムに分類し、前者がミッションクリティカル性を最優先に、後者をアジャイルプロセスなどを使ってスピード重視にするという分類です。 この２つのシステム分類を見極めた上で、それぞれに見合った開発手法や組織を考えるべきというのがバイモーダルITで語られている部分で、DXを通じて SoE のシステムを実現するために内製化組織を作ることを目指す場合は、このことへの深い理解が不可欠です。 すでにインターネットに対する深い知見を持っている人たちは活躍されていて、例えばクレディセゾンでCTOをやられている小野さん、またイオングループにおいても本体のCTOである山崎さんや、イオンネクストの樽石さんが活躍されている代表的な事例として挙げられると考えています。 note.com zenn.dev 更に、最近はSoI（System of Insight）という言葉もあり、主にデータ分析によるアプローチのことを示すようですが、生成AIも活用も含めてAIネイティブなシステム分類があってもいいかもしれませんね。 BASE社における SoE , SoR の考え方 さて我々、BASEグループは成り立ちがBASEという簡単にネットショップを作れるというサービスから始まりました。シンプルかつスマートフォンネイティブ、登録すればすぐに決済が使えるというサービス構成で、開始時点から好評をいただきスムーズなサービス成長を開始しました。 代表の鶴岡は起業当時、休学していた大学生でした。こういった若きスタートアップにおける勝ち筋は、基本的に SoE のプロフェッショナルにならないと成立しません。BASEも若い組織、若い開発メンバーのチームで多くのショップオーナーさんにお店を作っていただくことで、サービスのプレゼンスが上がっていき、JTCである大手企業のパートナーシップの実現やボリュームメリットによるコスト競争力などに繋がっていくことになります。 そして、最近、BASEの流通総額を超えて伸び盛りになっている当社グループPAY社が提供するPAY.JPですが、こちらはクレジットカードの決済サービスとなります。クレジットカード番号を取り扱うためのセキュリティ認証規格であるPCIDSS ver4.0にフル準拠する形で、サービス提供をしています。PAY社の代表の高野も起業当時は大学生で、BASE社に一度ジョインしてPAY.JPを立ち上げた後に分社化する形で子会社として独立しています。 共にスタートアップとして起業して、クラウドをネイティブに使い、ベンチャー企業としてスピーディな開発を進める２社ですが、改めて考えてみると、組織構成だったりサービスの構造が違います。 現在は、BASE社で開発を進めている購入者向けショッピングサービスのPay IDも、最初はPAY社が提供するID決済サービスでしたが、2021年にリブランドして以降は、BASE社にてPay IDアプリのバックエンド構造を作り直しています。こうなった経緯を当社における歴史的な流れとして考える時に、実は言語化しきれていない何かが理由としてあるんじゃないかと考えてみて、それが SoE と SoR という分類で考えるべきなのではないかと気が付きました。 BASEやPay IDアプリと言った、エンドユーザのフロントの接点を持つプロダクトが SoE というシステム、これはどちらかというとBASE社が得意とする領域です。一方で、クレジットカード決済APIを軸にサービス展開するPAY.JPは、なによりもシステムの安定性が求められることや、クレジットカード番号の繊細な取り扱いこそがファーストプライオリティだと考えると、 SoR のシステム分類に整理した方がしっくりいきます。 BASEとPAY.JPは、クレジットカード決済におけるマイクロサービスの関係性であり、PAY.JPから見たBASEは、PAY.JP APIを使う一加盟店という位置付けになることからも、明確にレイヤーが違うことは認識していたのですが、 SoE と SoR という分類で整理することが可能です。 Pay IDチームで開発している「あと払い（Pay ID）」というBNPLサービスも SoR のシステムなのだろうし、YELL BANKというサービスで、BASEの利用者に資金提供をさせていただいてるBASE BANKチームも SoR のサービスと言えるのかもしれません。 BASEグループは「Payment to the people, Power to the people.」というミッションでビジネスを考えていますが、システムという面からも SoE として立ち上がったBASEというサービスに対して、より事業に深みを出していくというのがPAY.JP以降に始めた SoR のサービスが新規事業だと考えると、JTCとはまるで逆のベクトルで、バイモーダルITという考え方にアプローチしているとも考えられます。 しかも、JTCにおけるバイモーダルITは、ウォーターフォール開発等の既存開発プロセスに気を使わざるを得ない分類であるのに対して、我々は、クラウドネイティブ、オブザーバビリティ、継続的デプロイメント、アジャイル開発など、ネット系ベンチャーとしての標準的な開発環境や開発プロセスを取りながら、スピーディかつミッションクリティカルにサービス提供をしていることが特徴と言えます。BASEもPAY.JPも大体、同じような環境で仕事をしているので、あまりこの整理ができていませんでした。 今後もこの構造は際立っていく これが具体的に開発組織に対してどう影響するかというと、おそらく.... SoR と SoE を適切に意識していくことで、何を重視するかというプライオリティが変わることと組織構造に影響してくるんじゃないかと思います。 事業という区切りで組織が分かれるだけでなく、開発や運用スピードにも影響するエンジニアが重視するメンタリティで組織を分けることになる可能性は十分にあると思っています。そこには、開発を引っ張る開発組織とリーダーが必要で、それに向けて誰がどう活躍して個々の事業ドメインのトップエンジニアになっていくのか、ということになると思います。 みんなのお給料を上げるためには、事業を通じて会社を成長させるための組織構造をいくつ増やせるかというのがとても重要で、この整理をすることで、それに向けて頑張っていく構造を作れると思います。 また、全然違う話として、例えば転職ドラフトなどをやっていると「金融系には行きたくない」と書かれていることがあるのですが、ここで言う金融系とは、おそらくJTCにおける基幹システムを作ってるSIerで行われているレガシーな SoR システムには携わりたくないということなのだと思います。 我々は、スタートアップ、ベンチャーとして、 SoE と変わらぬ開発環境やプロセスで、ミッションクリティカルな SoR のフィンテックスシステムを作っていると考えると、この「金融系には行きたくない」という既存の価値観を覆していかないと、採用に苦労し続けるということになりますから、いかに我々は夜、ちゃんと眠れる会社であるか？ということをもっともっとアピールしていかねばなりません。 ちなみに実際のところBASEは、 SoE と SoR の両方の要素を持っていて、大量のトランザクションを処理する決済システム、ショップの売上管理、顧客管理システムなどの SoR 的な側面と、ストアフロントとしてユーザビリティ重視の SoE 視点の両方を担っているのが現実なので、BASEはBASEで考えるべき幅が広くて大変なんですけどね。 それこそIT内部統制で求められているミッションクリティカル性と、ユーザビリティ重視のスピード型で双方に求められる部分が、開発者としてのお気持ち的にコンフリクトするのは、 SoE と SoR の両方を抱えているシステムだからだと今気が付きました。それ故に、サービスの安定運用には技術力が求められ、面白みもあるというシステムでもあったりします。 当社で活躍するエンジニアも、金融やEC出身の人もいれば、ソーシャルゲーム出身の人もいるというのは、この両面があるからなんだと思います。そんな幅広いポートフォリオを持つBASEグループですが、もしご興味を持っていただいた方がいらっしゃったら是非、お話しましょう。 open.talentio.com
はじめに こんにちは。BASEでバックエンドエンジニアとして働いているオリバ( @toshi-oliver )と申します。 普段は、BASEの発送を簡略できるかんたん発送Appの機能拡張に従事しております。 BASEに入社してバックエンドエンジニアに転向してから約1年3ヶ月ほど経ち、PHP、オブジェクト指向、DDDやクリーンアーキテクチャなど様々な分野を学んできました これらの分野に大きく関わるイベント「 Object-Oriented Conference 2024 」が、2024年3月24日（日）にコロナ禍を経て約4年ぶりにお茶の水女子大学にて開催されました。4年前に参加したかったのですが都合が悪く参加できず、今回満を持して参加することができました。 Object-Oriented Conference 2024とは プログラミング言語の縛りを超えて、オブジェクト指向に関連するセッションが集まったイベントです。 ooc.dev ソフトウェア設計で有名な増田亨さん、田中ひさてるさん、成瀬 允宣さんやミノ駆動さんなど、人気のある技術書の著者が登壇される貴重なイベントでした。 参加したセッション 1. オブジェクト指向のリ・オリエンテーション ～歴史を振り返り、AI時代に向きなおる 豆蔵の羽生田さんの基調講演でした。 講演の終盤で会場入りしたので、全ては聴講できませんでした。 大学の講義のような形式で、オブジェクト指向の歴史や、オブジェクト指向の概念、段階について説明されました。 中でも印象に残ったのが、以下添付画像のOOP5段階です。 ４段階目以降が重要で、それまでちゃんとできていない場合、５段階目のDDDに挑戦しても意味がないとのことでした。 私は、BASEに入社して本格的にオブジェクト指向やDDDに入門したため、この5段階を一気にまとめて学び、なかなか苦労しました。 終盤の以下のメッセージに感銘を受けました。 オブジェクト指向は手段にすぎないですが、目指す先は「 新しいサービス、そして未来を創造することである」 です。 動くところを想像してみよう そのオブジェクトの裏で何が動くは、これから考えれば良い。 そのオブジェクトの目的を理解して現場・現物で学び考えよう **それは、新しいサービス、そして未来を創造することである** 2. 生成AIの不確実性と向き合うためのオブジェクト指向設計 本イベントのスポンサーである株式会社Algomaticさんのランチセッションです。 このセッションに参加するとランチチケットがもらえます。 生成AIは何に使えるのか ユースケース 扱いにくいデータを扱いやすくする 苦手な分野の知識を補完するには使える AAAAモデル 生成AIをサービスに導入する使う際は、以下のAAAAモデルを軸に考えると良いようです。（ 参考 ） automation agent advice augment 生成AIを導入する際の難しい点 レスポンスが遅いが、高額なAPIをどう扱うか 使用するAIツールを変えたいと思った時に、いつでも切り離せる設計にしておくこと 3. 戦略的DDDを後天的に実践するための跳躍力 speakerdeck.com DDDとはざっくりいうとユビキタス言語を使って、ドメインエキスパートと会話して、プロダクト、コードに落とし込むサイクル。 DDDには戦略的DDDと戦術的DDDという分け方がある。 戦略 ドメイン理解、ドメインモデリング 戦術 ドメインモデリング、実装 （戦術的DDD = 軽量DDD） DDDを卵に例えると、黄身は戦術？白身は戦略？？ 答えはありませんが、私としては、黄身は戦略、白身が戦術であると感じました。 ゴリゴリ手を動かして開発をするという行為が、ボディビルダーがタンパク質摂取のために卵の白身だけ飲みまくる行為に似ているので、戦術的DDDは卵の白身→意味不明 戦略的DDDはなぜ難しいのか ドメインエキスパートがいない それはそう いても難しいことがある どこまで巻き込めるか、お互いに遠慮する ドメインエキスパートが不在 ドメインエキスパートが不在でどうしたか ドメインエキスパートがいないなら自分がなれば良い どうやってドメインエキスパートになるか とにかくbiz側とコミュニケーションをとる 圧倒的なインプット アウトプットしてチームに共有 ドキュンメントを残す 名前がない業務がたくさんあることがわかる 跳躍力とは 職域を超えて、わからないことをわかるまで追いかける力 仕事だからやらないと、ではなく好奇心が必要 これから戦略が必要。とはいえ、軽量DDDでもちゃんと開発ができていればいいじゃん。 ドメインエキスパートに自分がなるという発想が目から鱗でした。以前、自分が携わっていたメンバーシップAppの開発でもDDDを実践していましたが、戦術DDDに傾倒していたような気がしました。かんたん発想Appでは戦略DDDを意識して、ドメインエキスパートになるぐらいの動き方にチャレンジしてみようと思います。 4. イベントストーミングによるオブジェクトモデリング: オブジェクト指向プログラミングへの適用/開発プロセスの変遷/アーキテクチャの変革 speakerdeck.com 技術書「 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 」の著者で有名な成瀬 允宣さんのセッションでした。 イベントストーミングとは ドメインの理解を深めるためのワークショップ手法の１つです。 ドメイン駆動設計の戦略的設計の1部で、 3. 戦略的DDDを後天的に実践するための跳躍力 で議題に上がった戦略的DDDと戦術的DDDの橋渡しをするのがイベントストーミングです。 やり方としては以下です。 イベントを付箋に書き出す アプリケーションを使用する際に発生するイベントを書き出します イベントを並び替え 上記のイベントを並び替えます コマンドや集約、外部システムを追加 コマンドとは、実装でいうとメソッドに相当します 集約やイベントはクラスに相当します。 ポリシーを追加 注文→決済の間で定義されたルールのようなものをポリシー 上記の手順に従って、DevとBizが集まってディスカッションしていきます。 イベントを中心として業務フローを明確化することによって、以下のメリットを享受できます。 ドメイン知識偏在の解消 コミュニケーション不足の解消 属人化を防ぐ 変更容易性の低下を防ぐ イベントストーミングを導入→ドメインを理解するためにワークショップが活発→全体像の可視化→仕様書、設計書の誕生→属人化の解消→アジリティ向上→修正前にイベントストーミングをするという文化の醸成 ただし、留意点として、ファシリテーション力と、ドメインエキスパートに参加してもらうことが必要となります。 アーキテクチャ選定 イベントストーミングを効果的に反映するアーキテクチャとして、CQRS/Event Sourcingがあります。 時間の関係上、アーキテクチャの詳細には触れられませんでしたが、CQRSはBASEでも一部取り入れているので、Event Sourcingパターンは非常に興味深かったです。 個人的には、かんたん発送Appのデフォルト化や日本郵便対応の要件がまだ定まっていないので、このイベントストーミングを取り入れてみたいと感じました。どこかのタイミングで成瀬さんのワークショップ参加してみたいという思いが強くなりました。 5. CQRS/Event Sourcingシステム実装入門 4. イベントストーミングによるオブジェクトモデリング でも話題に上がった、CQRS/Event SourcingのハンズオンイベントとQ&Aが実施されました。登壇者は、かとじゅんさんです。 README に沿って、ハンズオンを行なっていきました。 個人的に気になったのが、AWS Lambdaで動いているReal Model Udapterの部分で、ここの処理が失敗するとDynamoDBとRDSのデータの整合性が失われるので、Real Model Udapteが処理を失敗した時のリカバリーについて、ちゃんと設計する必要があると思いました。 ネット環境が良くなかったことと用意されたDockerfileがうまく立ち上がらなかったため、途中でハンズオンを断然しましたが、またどこかのタイミングでチャレンジしたいと思います。 6. ラウンドテーブル：OOP可読性テクニック オブジェクト指向について、参加者全員でラウンドテーブルという手法を用いて、ディスカッションを行いました。ファシリーターは成瀬さんが務められました。 （※ ラウンドテーブル とは） ラウンドテーブルとは、簡単にいうとみんなで円陣を組んでディスカッションを行います 主に上がった議題としては、 メソッド名の付け方で意識していること コード上で日本語の使用はどこまで許されるか 従来のやり方が間違っていた場合、踏襲するか変更を要求するか など、現場でよくある悩み事を約50人ほどでディスカッションしました。 以下は、議事録です。 7. 最後に 朝から夕方までぶっ通しで参加したので、最後の方はヘトヘトでした。しかし1日中ソフトウェア設計について考えられるイベントに参加できて、非常に満足感が高く、また改めてソフトウェア設計が自分の中で興味のある分野であることが再確認できました。 収穫としては、 イベントストーミング によるオブジェクトモデリングというワークショップが、ドメイン知識をインプットするために効果的であることと、 CQRS/Event Sourcingパターン がアーキテクチャのトレンドであることがわかりました。 イベントストーミング は、ぜひBASEのpjで取り入れたいと思いました。まずはネクストアクションとしてイベントソーシングのやり方について調査し、ドキュメントにまとめたいと思います 💪 最後に、BASE では絶賛採用活動中です。 BASEではDDDやクリーンアーキテクチャなど積極的に導入しており、まだ1部MVCで動いているアプリケーションをクリーンアーキテクチャにリアーキするチャンスがあります。 カジュアル面談からでも大歓迎ですので、一緒に BASE の未来を作ってくださる仲間を募集中です！ open.talentio.com
はじめに こんにちは。 Feature Dev1 グループでマネージャーをしている髙嶋です。 突然ですが、サービス運営するうえでユーザーからのお問い合わせ対応を無視することはできません。 そしていかに迅速かつ適切な内容で回答できるかどうかは、どこまでいってもゴールのない永遠の課題と言えるものでしょう。 ネットショップ作成サービス BASE に関するお問い合わせ対応についての運用に直近変化があったため、その経緯と効果（はある意味これからでもありますが）を共有させていただきたいと思います。 サマリとしては、概ね以下のような内容となります。 お問い合わせ対応のうち、技術的な観点が要求されるものはエンジニアに対して調査依頼がきます BASE では特定の部署が対応する形ではなく、開発組織横断で対応にあたっています 具体的には通称 cs_q というチャンネルに調査依頼がくるので、基本的には依頼がなされた順に対応しています 担当プロジェクトなども各々抱える中で、cs_q 対応が特定のチームないし個人に偏ってしまう状況を避けるために、これまでは週次で当番を各チームからアサインする輪番制の運用としてきました この度、一部開発組織の改編も相まって、お問い合わせをいくつかのカテゴリ（プロダクト領域）に分割し、それを各チームにアサインして対応する運用に変更しました それに伴って運用全体としての輪番制は廃止し、具体的な運用方法については各チームに一任することにしました 元々は組織やプロダクトが大きくなってきたこともあって輪番制を導入したという背景もあったはずが、そこからさらなる成長を遂げたら今度はそれをやめることになったのが個人的には興味深いと感じています 輪番制導入の背景と根底にある考え方 以下は輪番制すなわち当番という考え方に基づく運用が導入された当時の記事であり、その背景などが記載されています。 冒頭で述べたような課題感も含めて、当時の状況をより詳細にうかがい知ることができるのではないかと思います。 devblog.thebase.in そこから数年が経過し、もちろん改善を重ねてきた部分はありつつもベースにある輪番制という運用自体は2023年末まで維持されてきました。 また別の記事になりますが、プロダクトへの向き合い方という観点においても cs_q に触れたものがあります。 devblog.thebase.in これらの記事を踏まえて大胆にまとめるなら、BASE にはプロダクトづくりにエンジニア全員で向き合おうという良い文化があると考えています。 普段の開発業務においてはドメイン分割して対応にあたることも現実的な解としてとっていますが、それでも結局は一つのプロダクトを全員で作っているという意識を持つという考え方が根底にあります。 そしてリリースしたらお終いではなくむしろ始まりであり、基本的にはリリースして初めてユーザーからのフィードバックを得られるようになります。 ユーザーからのお問い合わせもその一つと言えるでしょう。 効率性を考えるのであればお問い合わせ対応などを専属で行うような組織を作る選択肢もある中で、そうしないことには開発組織としての意志があると思っています。 輪番制の課題と開発組織としての課題 ここでいったん私自身について補足させていただくと、この2年程 cs_q 対応でエンジニアに調査依頼がなされてからの運用全般について、その取りまとめをするような役割を担ってきました。 その中で改善してきたこともたくさんあります。 バックログを導入して状況を可視化できるようにしたり、調査に行き詰まった際の相談先リストを作成したり、はたまた運用フローを整備したりするなど、そのときどきの課題に向き合って他者の協力も得ながら改善を図ってきました。 着実にそうした整備は進んでいるという手応えがある一方で、輪番制を念頭に置いた運用の限界を感じていたのもまた確かです。 一例として、当番時だけ対応すればよいという捉え方もできるため、当番が調査に行き詰まってもなかなか非当番メンバーとの協力体制を敷くのが状況的に難しかったりといったことが挙げられます。 また当番の中でも対応までのスピードや数にコントラストがついてしまい、輪番制にすることで期待していたはずの平準化や公平感というメリットがあまり感じられなくなってしまったりといったこともあります。 そして開発組織の変化についての話も避けては通れません。 この3年程はいわゆる目的別組織というキーワードの元、特に BASE というプロダクト開発に関わる開発組織は一定の目的ないし領域で区切られたような組織設計がなされてきました。 それ自体はチーム運営や開発プロセスを成熟させ、またそれぞれの領域に対する各メンバーの理解を深めることに繋がり、その結果としてプロジェクトの安定的なデリバリーを実現できるといったメリットがありました。 しかしながらチームの担当領域に対しては最適化されていく一方、その裏返しとしてマンネリ化が進んだり変化に対するハードルがあがって視野が内向きになったりという課題も目立ってくるようになりました。 そういった組織の硬直化を食い止めて組織と個人の成長をもう一度加速させるために、開発チームにおける領域という考え方は撤廃し、越境・成長・持続的な開発組織というコンセプトのもとにあえて同じ性質を持ったフィーチャーチームを複数作るような組織構造になりました。 その考え方に基づくなら cs_q もプロダクト領域を全チームが分け隔てなくみていこうということもできますが、さすがにそれは認知負荷が高すぎて効率性とのバランスが悪く結果としてユーザーに迷惑をかけることになるため、cs_q については各チームの守備範囲を決めて対応にあたることにしました。 その守備範囲はプロダクト領域をいくつかのカテゴリに分割したものではありますが、そのカテゴリ自体に大きな意味を持たせることはせず、あくまでも全体のバランスなどを考慮した割り振りになっています。 つまり各開発チームに対してカテゴリをアサインするような格好にはなりますが、それもずっと同じ組み合わせでやっていくことを前提にはしておらず、今回の組織改編のコンセプトに沿ったものとなるよう今後はカテゴリをローテーションしていくような案も検討しています。 逆にチームの中にいるメンバーがグループ間を動くことで知識を伝播していくようなパターンもあるでしょう。 改めて cs_q の運用が現状どうなったかをまとめると、大枠以下のようになります。 エンジニアへの調査依頼はバックログ（Notion）に起票し、カンバン形式でステータス管理する 起票されると調査依頼内容のプロダクト領域（カテゴリ）に応じて Notion のオートメーション機能で紐付く担当チームが設定され、Slack でそのメンションが各人ないしチームに飛ぶ cs_q チャンネルに調査依頼内容が自動で通知され、担当チームのエンジニアはその対応にあたる 全体の運用としての決め事は極論これだけであり、このようにできる限りシンプルな状態まで削ぎ落としたからこそ、輪番制という座組みも廃止して具体の運用は各チームに任せる意思決定ができました。 輪番制をやめてどうなったか 結論、輪番制をとるチームもあればそうしないチームもあります。 ただしそれは各チームの状況も踏まえて適宜判断されていることであり、これまでのように全体で実施していたときとは少し意味合いが違うと思っています。 一律のルールを定めて徹底することによる全体最適を重視するのか、あえて余白を残すことで各チームの想像力による新しい何かが生まれるのを期待するのか、それぞれのメリデメがあることは理解しつつも今回の全体方針としては組織改編に込められた意思も踏まえたうえで後者に倒した形になります。 ちなみに私も Feature Dev1 グループという開発組織を預かる立場ですが、グループ方針として輪番制は敷かないという意思決定をしました。 上述した通り、私自身が元々輪番制に対する課題感を持っていたという背景もありますが、それを抜きにしてもチームメンバーに主体性を期待する形での運用に倒してみたらどうなるかを、成功するにせよ失敗するにせよちゃんと検証したかったということがあります。 運用開始から3ヶ月程が経過してどうなったかで言うと、現状期待通り、あるいは期待以上の状況になってくれていると感じます。 当番を置かないからこそチームメンバーの誰かが主体的かつスピーディーに調査依頼に反応する動きも多くなり、それは結果的に困っているユーザーをより早く助けることにも繋がっています。 良い意味で調査依頼に対応した数にもコントラストがつき、積極的に対応してくれるメンバーを素直に評価できる状態にもなりました。 またこれは私のチームに限った話ではありませんが、組織改編の影響もあってメンバー同士で持っている知識を交換し合いながら対応にあたったり、きたる担当カテゴリのローテーションに向けてもよりドキュメントに知見を整理して引き継いでいけるようなムーブメントも起こりつつあります。 まとめ 現時点では大きな混乱もなくポジティブにその経過を見ていますが、一方でより本質的な課題が出てくるのはこれからだと考えています。 ゆえに未来永劫ずっとこの運用を貫くということはおそらくなく、今回がらっと運用方法を変えたように、また新たな課題が出てきたらどうするかということを考え続けていくんだろうと思います。 本記事では弊社における事例紹介をさせていただきましたが、ウチではこういった取り組み方をしていますといった事例があればぜひ教えていただきたいと思っています。 最後に、BASE では絶賛採用活動中です。 本記事でご紹介させていただいたように、アプリケーションエンジニアとしてもただ機能開発をするだけではなく、プロダクトそして組織の成長を支えていくために裁量を持ってできることがたくさんあるのが BASE で開発する醍醐味です。 カジュアル面談からでも大歓迎ですので、一緒に BASE の未来を作っていく方をお待ちしています！ open.talentio.com
こんにちは、NEW Dept/Pay ID Dev/Web Backendエンジニアをしている金子です。普段はPay IDに関するバックエンド周りの開発をしています。 3/14, 3/15の2日間に渡って開催された AWS JumpStart 2024 にBASEから4名のエンジニアが参加しました。普段はバックエンドを中心に業務しているエンジニアが、AWSの主要サービスを学び、アーキテクチャの検討をする貴重な経験ができましたので、感想を交えつつレポートしていきます。 AWS JumpStartとは AWS JumpStartは、新卒を含むAWS初学者のエンジニアを対象とした、クラウドネイティブなテックリード人材を育成するための第一歩となる実践的な研修プログラムです。事前学習用動画と2日間の集中的なワークショップを通して、皆様が自走できる状態までシステムアーキテクチャ設計やAWSの理解度を一気に引き上げることを目的としています。 https://aws.amazon.com/jp/blogs/news/aws-jumpstart-2024/ AWSが開催する実践的な研修プログラムで、BASEでは今年も アプリケーションエンジニアのインフラ知識の底上げのため に希望者が参加し、AWSサービスやアーキテクチャについて2日間学んできました。 使用するツール Zoom 今年はZoomでの開催でした Slack 他の参加者やAWSの運営メンバーとコミュニケーションを取る際に使用します Miro オンラインホワイトボードでアーキテクチャ検討時に使用します スケジュール 2日間 9:00~18:00で学習+アウトプットする充実した内容になっていました。 事前学習 参加前に事前学習動画と資料の案内があり、 AWSの基礎を学ぶのに非常に分かりやすくまとまっている内容 でした。これだけでも十分価値のある内容で、自分の場合は今まで体系的に学べてなかった部分が、するすると腑に落ちていく感覚でとてもありがたかったです。 アーキテクティング基礎（1時間） クラウドにおける設計原則、アーキテクティング AWS 入門（3時間） AWSの基本的な知識 Webサービス超入門（pdf資料） Webアプリケーションの仕組みについて 1日目 1日目は講義+ハンズオン中心でした。 講義全体の説明、自己紹介 はじめに全体スケジュールや本プログラムのゴールについての説明、Slack上での自己紹介の時間があります。また、プログラム全体を通してSlack上で自由に質問ができるので、気になった箇所があれば気軽に書き込み、この質疑応答を見るだけでも勉強になる内容が盛りだくさんでした。 講義 WEBアプリケーションの説明からHigh-Levelなアーキテクチャ図について等、丁寧に説明が進みます。 フェーズや目的によって目指すべきアーキテクチャは異なる ので、それらに合わせて最適なアーキテクチャを検討する必要があるわけですね。単にスペックの良いサーバーを大量に用意するだけでは、いくらでもコストがかかってしまうので、サービスの規模や要件に応じた適切なアーキテクチャの検討は非常に大切です。 ハンズオン ワークショップ用のデモアカウントを使って実際に環境を構築します。このデモアカウントはワークショップ中は自由に使用して良いので、環境を破壊して再構築を繰り返しできます。後からやり直して復習もできるので嬉しいですね！ EC2の構成 素朴な構成ですが、VPCやセキュリティグループの設定など基礎的なサービスを使用します。 ALB+ECS+RDSの構成 先ほどのEC2よりもスケーラブルで冗長化された構成です。私自身はEC2の構築経験しかなく、ECSは初めての体験で勉強になりました。 挙動確認 ECSのタスクやAurora MySQLインスタンスに問題が生じた際の挙動確認を行いました。 個人的には1日目の一番楽しみにしていたところで、定期的なリクエストを送りつつECSのタスクを1つ停止したり、DBをフェイルオーバーさせて挙動を確認しました。余裕を持ちながら監視するのは本番環境ではできないことですね！ CloudWatchの各種メトリクス確認 CloudWatch上で、先ほどまで動かしていたサービスのリクエスト数の変化やCPU使用率、メモリ使用率の確認を行いました。 ALBのリクエスト数 AuroraのCPU使用率 ２日目 2日目はアーキテクチャの個人検討とグループワークが中心でした。 Daily Check-in, クイズ 2日目のスケジュールの確認やクイズを行い、前日の復習をします。 アーキテクチャ検討（個人ワーク・グループワーク） ここからはより実践的な課題をしていきます。既存のチームメンバーが全員退職してしまう ブラック 企業の社員になり1日でアーキテクチャを検討します。この会社を救わなければ！という使命感から俄然やる気が出てきます。 個人ワーク まずは個人検討で、提供規模・システム要件・必須機能から適切なアーキテクチャをMiroを使って作成します。実際に図に落とし込むのは、詳細を理解していないとなかなか難しい内容でした。 グループワーク Zoomで各チーム3~5名ほどに分かれてアーキテクチャをブラッシュアップしていきます。他の参加者と意見交換をしながら検討することで更に理解が深まりました。 成果発表と解説 代表して3チームから最終成果の発表がありました。各チームこだわりがあり、それぞれ違ったアーキテクチャ図になっているのも面白かったです。 そして最後にAWSのSolutions Architectによる解説があり、クロージングとなりました。 感想 参加メンバーから感想をいただいたので紹介します！ AWSを用いて0から何かを作っていく機会が長いこと無かったので、良いタイミングと捉えて参加しました！ 前半の基礎知識の学習やハンズオンは、進み方がとても確実かつ丁寧で、初学者の方にはぜひおすすめしたい内容と感じました！ 後半は前半で学んだことを用いてアーキテクチャの設計を実際に行う演習形式でしたが、知識の再確認としての良さだけでなく、他の人と作成したアーキテクチャについて意見交換や議論する機会があったことで、考えていなかった視点が知れたり共同でブラッシュアップしていく経験ができたりと、とても刺激的でした！ 今後業務のなかでチャンスがあったときは、イベントを通じて得たものを活かしたいなと思います！ Pay IDでバックエンドエンジニアをしている 竜口 です。 今回参加した目的は、インフラに関する経験や知識が不足していることでどうしても開発のアプローチが少ないと感じることがありインフラの理解を深めることで、より幅広いアプローチができればと思い参加しました。 イベントでは、インフラの基礎から実際に構築する過程を体験し、全体像の理解を深めることができました。 さらに、課題に取り組む中で生じた疑問点や、AWSの仕組みについての詳細な説明を受けることができたのがとてもよかったです。 また、Slackで他の参加者の興味深い質問とその回答をみれたのは楽しかったし、より理解が深まりました。 イベント後に自社のコンソールを見て、今まで以上に自社の構成の解像度が上がったのを感じられて嬉しかったです！ 今回の経験からまたステップアップして今後の開発に活かしていきたいです！ BASEでバックエンドエンジニアをしています。 Futoshi Endo です。 参加しようと思ったきっかけは、直近の業務でAWSが提供している一部サービスに触れてみて、ちゃんと体系的に理解しようと思ったのが理由でした。その前にもAWSの資格試験の対策で問題集を解いてみたりした事はあったのですが、各サービスの特徴だったり、なぜこの構成で作るのかの背景について中途半端に学んで終わっていました。 AWS JumpStart2024に参加して良かったのは、まさにそこの理解が不十分なままで終わっていた箇所が、実際にアーキテクチャ図をかく作業を通じて、理解できた事でした。 また、他の参加者の方が考えたアーキテクチャ図を見ながら、AWSの運営メンバーとの議論されている内容も良かったです。 自分自身、参加する前はAWSについては苦手な傾向があったのですが、少しだけ自信がついたので、業務で触れる機会があれば積極的に挑戦しようとおもいました！ まとめ BASEではtmpチャンネル（ワークショップ用の一時的なチャンネル）を作って、「この構成はBASEだとどうなっているんだろう」など内部でもワイワイしながら講義を受けました。自社のサービスに落とし込んだ場合のアーキテクチャがどうなるかを想像しながら進められるのも、普段の業務ではあまり考えることのない部分なので有意義で面白かったです。 AWSの苦手意識を払拭できたメンバーもいたりと、総じて非常に勉強になる貴重な体験でした。今後バックエンドエンジニアとして仕事するうえでも、webの開発観点だけでなくインフラ観点やAWSサービスへの理解を深めつつ、より良いサービスの提供に繋げていければと思います！ 最後に、BASE では絶賛採用活動をしています。 興味がある方は以下のリンクからご覧なっていただけると幸いです！ binc.jp
はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 分析基盤の構築・運用などの側面から社内のデータ活用の促進を行っています。 BASEではAurora MySQLにあるデータをEmbulkを用いてBigQueryに連携しています。BigQueryへ連携されたデータは分析基盤としてLookerなどを通して社内利用されています。 このデータ連携処理にはいくつかの課題があり、それを解決するためにEmbulkからAurora S3 Export機能を用いた連携処理に切り替えることにしましたので、それについて紹介していきたいと思います。 ※この切り替えについては現状、試験的に一部のDBのみの切り替えとなっていますが、運用上の大きな課題が出てこなければ徐々に切り替えていく予定です。 切替前のデータ連携処理 先述した通り、BASEでは主にEmbulkを利用してAurora MySQLにあるデータをBigQueryに連携しています。以下のようなアーキテクチャです。 本番DBからレプリケーションされた分析用DBに対して、EmbulkからSQLをDaily実行する形でデータ連携を行なっています。ワークフロー管理にはAirflowを利用しています。 Embulkによる主な連携パターン EmbulkからBigQueryにデータを連携する際は、テーブルの仕様やデータ量に応じて主に3パターンに分けています。 DELETE INSERT BigQuery側で対象日付分を削除し、その後に対象日付分をINSERTするパターンです。事前に削除を行うのは処理の再実行などによって同じデータが入り込まないようにするためです。主にログデータなどの更新されないデータがこれに当てはまります。 REPLACE テーブルの全量洗い替えです。更新や物理削除が行われるテーブルは基本的にこの方式になります。例えばユーザー情報などです。 MERGE 対象日付以後に更新のあったデータを対象に差分更新を行うパターンです。基本的にはREPLACEやDELETE INSERTで対応したいですが、テーブルのデータ量が大きい場合にこちらを選択します。例えば注文や発送関連のテーブルが該当します。 課題 Embulkを用いたデータ連携処理の課題について触れていきます。 レプリケーション遅延によるデータの不整合 連携元のデータとして本番DBからレプリケーションされてきた分析用DBのデータを使用しています。この分析用DBは別の処理としても使われていることがあり、その負荷などによってか時折レプリケーション遅延が発生します。この遅延が連携処理のDaily実行時に発生していると、本来更新されるべきはずのデータが更新されなくなります。これによって一部データの不整合が発生することがありました。 物理削除を検知できない Embulkでは連携するデータをSQLで取り出すため、レコードが物理削除されていたとしても、それを検知することができません。なので基本的には物理削除が発生するテーブルについてはREPLACEで対応することになります。ただし連携元のテーブルのデータ量が大きすぎる場合、Embulkサーバーのディスク容量を圧迫してしまいます。そのため、物理削除が発生する且つテーブルのデータ量が大きいものに関しては連携が厳しい状態です(MERGEによって連携すること自体は可能だが信頼できるデータではなくなってしまう)。 select column1, column2, column3 from table where modified >= TARGET_DATE -- 更新日時が対象日以降 新しいデータ連携処理 上記のような課題を踏まえて、新たに構築したデータ連携処理が以下です。Aurora S3 Export機能を利用し、parquet形式でS3にスナップショットを出力したのちに、BigQuery Data Transfer Serviceを用いてS3から直接BigQueryへデータをインポートしています。 ここからはこの処理を採用する前に調査したことについて触れていきます。 調査・検証内容 Aurora S3 Export機能を採用するにあたって、調査や検証したことについて触れていきます。 出力元DBへの負荷 スナップショットとして出力するDB側への負荷がどれだけあるのかをまずは確認しました。AWSで公開されている ドキュメント にて、以下の記述があるように、DBクラスターをクローンすることで出力元DBへの負荷は起きないようです。 Amazon Aurora は DB クラスターをクローンして、クローンからデータを抽出し、そのデータを Amazon S3 バケットに保存します。 ここについてはAWS SAの方に伺い、認識の齟齬がないかを確認させて頂きました。 連携処理にかかる時間 データ連携処理が深夜に開始して、翌朝の9時以降にまでかかってしまう場合は新しいデータ連携処理に切り替えることはできません。間に合うかどうかを確認するために、実際の分析用DBと同じインスタンスタイプ、同じデータ量のテーブルを2つ用意し、検証を行いました。選んだテーブルはEmbulkだと連携に1つ目が約15分、2つ目が約30分程度かかる重たいテーブルになります。各処理にかかった時間は以下の通りで、合計で30分程度です。 最初にインスタンスを起動する時間が20分と長いですが、これはDB Cluster単位で必ず最初に行われるものになっています。その後続の処理はいずれも数分で終わっており、全体として30分程度でEmbulkを用いた時と大差ない時間です。最初の起動時間を考慮しなくていいのであればEmbulkよりも短い時間でデータ連携が可能になりそうです(Exportするテーブル数やEmbulk側での並列実行数次第)。この結果から新しいデータ連携処理に切り替えても時間がかかりすぎることはないだろうと判断しました。 コスト コストについても念の為確認しておきましたが、大きくかかりすぎるということはないだろうという判断に至りました。 Aurora S3 Export : 100GBで$1.2~1.3程度 S3からのデータ転送 (アウト): 100GBで$11.4程度 parquet形式でデータ圧縮されるため、思ったほどのコストにはならないと考えてます BigQuery Data Transfer Service : $0 実装時のポイント ここからは新しいデータ連携処理を実装していくにあたって考慮が必要だった点について触れていきます。 Aurora S3 Export 今回はboto3を用いてS3 Exportの処理をキックすることにしました。 タスク識別子(ExportTaskIdentifier)に日付を入れる S3 Export処理をキックするには以下のparameterを指定して start_export_task を実行します。 response = client.start_export_task( ExportTaskIdentifier= 'string' , SourceArn= 'string' , S3BucketName= 'string' , IamRoleArn= 'string' , KmsKeyId= 'string' , S3Prefix= 'string' , ExportOnly=[ 'string' , ] ) ExportTaskIdentifierには任意のtask idを指定する必要があるのですが、以前実行した時と同じ値を指定することはできません。またこのExportTaskIdentifier(及びS3Prefix)はS3 Bucket内のURIにもなります。そのため、ExportTaskIdentifierの値の末尾にyyyymmdd形式で日付を入れることにしました。イメージは以下です。 # 理想はこちら。 s3://S3BucketName/table_name/.../*.parquet # 実際はこちら。S3 URIが日付で異なる。 s3://S3BucketName/ExportTaskIdentifier_yyyymmdd/table_name/.../*.parquet これ自体は大したポイントではないのですが、後続のBigQuery Data Transfer Serviceにおいて考慮すべき点になります。 S3 Export処理の完了を定期的に確認する start_export_task関数を実行すると実行指令が飛んだ直後にresponseが返ってくるため、Export処理が完了したかどうかが分かりません。完了を確認するためには describe_export_tasks を数分おきに実行します。 response = client.describe_export_tasks( ExportTaskIdentifier= 'string' , SourceArn= 'string' ) 今回、describe_export_tasksを定期的に実行するのにAirflowの Sensorクラス を使うことにしました。以下に実装例を示しておきます。このように定義することで5分間隔(poke_interval)で10回(timeout)、python_callableに渡した関数が実行されます。その関数でdescribe_s3_export_taskを実行させ、trueが返って来れば後続の処理に進むという形です。 def poke_describe_s3_export_task (**kwargs): # describe_s3_export_taskを実行 # 完了したかどうかでtrue, falseで返す return true poke_describe_s3_export_task = PythonSensor( task_id= "poke_describe_s3_export_task" , mode= 'poke' , poke_interval= 300 , timeout= 300 * 10 , soft_fail= False , python_callable=poke_describe_s3_export_task, provide_context= True , dag=dag ) BigQuery Data Transfer Service S3にparquet形式でデータが出力されれば、次にS3からBigQueryにインポートする処理を行います。今回はGoogle Cloud CLI コマンドでの実装としました。主に [bq mk](https://cloud.google.com/bigquery/docs/reference/bq-cli-reference?hl=ja#bq_mk) コマンドを使っています。 --transfer_run ****を指定することでBigQuery Data Transfer Serviceを実行することができます。 bq mk --transfer_run [--run_time=RUN_TIME | --start_time=START_TIME --end_time=END_TIME] CONFIG runtime parameterによるS3 URIの日付指定 BigQuery Data Transfer Serviceの転送設定を定義する時にS3 URIを指定するのですが、上述した通り、S3 URIは日付別に異なる点を考慮しなければなりません。その時に使うのが runtime parameter です。これを使うことで日付部分を動的に変更することができます。{run_time-9h|"%Y%m%d"}のように実行時刻から時間をずらしたり、フォーマットを変更することができます。例えばruntimeが 2024-04-01 05:00:00 の場合に {run_time-9h|"%Y%m%d"} を指定すると 20240331 という値になります。 # 定義する際のS3 URI s3://S3BucketName/ExportTaskIdentifier_{run_time-9h|"%Y%m%d"}/table_name/*.parquet # 実際に参照されるS3 URI(2024-04-01 05:00:00に実行された場合) s3://S3BucketName/ExportTaskIdentifier_20240331/table_name/*.parquet 今後の課題 試験的な運用からの脱却 負荷やコスト、連携にかかる時間が試算でしかできないので、一部のDB(プロダクトへの影響が極力低いDBを選定)に限定しての運用になっています。今後は他のDBへの展開を行っていきたいと思っています。 Airflowのバージョンアップ 現状、boto3やGoogle Cloud CLI コマンドでの実装となっていますが実はAirflowには以下のようなオペレーターがあり、boto3などを使わずとも実装が可能です。 RdsStartExportTaskOperator BigQueryCreateDataTransferOperator 今回使わなかった理由はBASEのAirflowサーバーのバージョンが低くて利用ができなかったからです。マネージド( Amazon Managed Workflows for Apache Airflow )への移行を考えていたり、バージョンを上げるための他ワークフローへの影響範囲が確認できていないため、一旦は今回の処理の実装を優先しました。今後はより実装をシンプルにするためにAirflowのバージョン上げを行い、上記オペレーターに切り替えていきたいと思っています。 最後に 試験運用ではありますが、データ連携処理の切り替えを行うことができました。これによってより多くのデータを分析基盤に集めていくことが可能になったと思っています。またEmbulkへの負荷が下がったおかげで全体としての連携時間も早まっています。 最後となりますが、弊社ではデータエンジニアを募集しています。上記で述べた課題以外にもBASEの分析基盤には多くの課題があって、とてもやりがいのある仕事かなと思っております。ご興味のある方は気軽にご応募ください！ https://open.talentio.com/r/1/c/binc/pages/94358
2024/03/07(木)~2024/03/09(土)に開催された PHPerKaigi 2024 にて、BASE株式会社から2名のメンバーが登壇しました! 登壇者 2 名からコメントと、会場の様子やセッションについてお届けします! 登壇者のコメント Futoshi Endo ( @Fendo181 ) speakerdeck.com BASEでバックエンドエンジニアをしています、遠藤です。 2日目に「PHP8の機能を使って堅牢にコードを書く」というタイトルで発表させて頂きました。 業務でもPHPを書いているのですが、PHP8で提供されている機能は使ってより堅牢に書くにはどうすればいいのか? が気になってそこから実際に業務を通じて得た経験だったり、自分で調べた内容をまとめて発表しました。 個人的には「堅牢」という壮大なテーマを選んでしまった事に若干後悔もしたのですが、資料を作るにあたって、 t_wada さんの動画 だったり、書籍を読み漁った影響で、自分なりに整理できたポイントが多く勉強になりました。 登壇後の質問では、実際にPHP8.2から導入された「読み取り専用クラス（readonly class）」の活用方法の質問だったり、実際に堅牢なコードを書く上で考えている事のポイントを聞かれて、参加者の方と意見効果が出来て良かったです。 今回発表して思ったのは、まだまだ自分の中でPHP8を使って堅牢なコードを書く上での経験が浅い部分があると自覚したので、今後も沢山コードを書いて学んで行こうと思いました。 02 ( @cocoeyes02 ) fortee.jp BASE BANKチームでフルサイクルエンジニアをしている大津です。 今回はアンカンファレンスコーナーで「PHP系カンファレンス反省会&壮行会」という、2024年に行われた/行われるPHP系カンファレンス（北海道、関西、PHPerKaigi、小田原、香川、福岡、東京）の実行委員長によるパネルディスカッションに参加させていただきました。 話していたテーマには 「どこからコンテンツのアイディアを思いついているか？」 「開催を決めた瞬間のことを教えて？」 「新規コミュニティ参入者を増やすための工夫があれば聞きたい！」 などがありました。 どのカンファレンスも創意工夫がたくさんあったのもそうでしたが、開催場所の地域を盛り上げようという熱意や各委員長のパワーをひしひしと感じ、これは負けてられないぞ・・・！という気持ちにさせてくれました。 今回登壇した委員長のカンファレンス以外にも沖縄があり、2024年はPHP系カンファレンスがたくさん開催される年です。ぜひ各PHP系カンファレンスへの参加お待ちしております！ 現地で見たセッションを一部紹介 privateメソッドのテストって書かない方がいいんだっけ？ speakerdeck.com asumikan さんによる発表で、テストコードで、privateメソッドで書かれた処理を書かない理由についての発表でした。 privateメソッドは書かない方がいい…というのはよく聞くけどその理由を、ご自身の開発での体験談を込めて説明がされており良かったです。 ここらへんのお話は t_wada さんのブログ でも以前紹介されていたのですが、asumikan さんの発表ではECサービスの発注処理を題材に説明されていて、そこから良いテストを書くための道筋が書かれていてイメージが湧きやすかったです。 後、余談としては発表が抜群にうますぎたので、登壇する際にはぜひ参考にしたい気持ちになりました。 どうやってWebサービスのページ表示速度を1/3にしたか / how-to-reduce-display-speed speakerdeck.com ぴんくもひかん さんによる発表です。Webサービスのページ表示速度を改善した話で、まず導入から「なぜページ表示速度は大事なのか?」の丁寧な説明から、その後の改善方法まで細かく書かれておりわかりやすかったです。 個人的にはここらへんパフォーマンス改善系だと事前に測定でDevtoolを使うのは聞くのですが、プロファイラでXdebugが使えるのは知らなかったです。 後半では実際にパフォーマンス改善でクエリのチューニングを行ったり、php.inc の opcacheの設定を有効したりで、どんどん改善されていくのを見て「おぉ！」となりました。 はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間 speakerdeck.com 永井美波 さん による発表です。はじめてのEMとなり、メンバー育成を行うにあたってご自身が経験を説明されています。 最初の「知り合い期」からの「探り合い期」、「あれこれも期」と、各期間毎でEMとしてメンバーといっしょに取り組んだ内容が変わっていて勉強になりました。この発表は現地で聞いていたのですが、メンバーと同じ目線にたって一緒に走っている感が伝わってきて良かったです。育成する側と、育成される側でちゃんと認識を合わせるのが大事だと思った発表でした。 まとめ PHPerKaigi 2024 の会場が「中野セントラルパークカンファレンス」に変わったのですが、スタッフの方々の素晴らしいオペレーションで今回も楽しく参加ができました。スタッフの方々には業務でお忙しいにも関わらず、多くの時間をカンファレンス準備へ注いでいただいたかと思います。 この場を借りて御礼申し上げます。 また来年の PHPerKaigi でも積極的に参加して行こうと思います! ありがとうございました! 最後に、BASE では絶賛採用活動をしています! 興味がある方は以下のリンクからご覧なっていただけると幸いです! binc.jp
こんにちは、BASE BANK Divisionで事業責任者をしている柳川と申します。 今回はROSCAさん主催のROSCAFE TECH NIGHT #5で登壇させていただきました。 その登壇記録とレポートです。 rosca.connpass.com 柳川の登壇内容 イベントタイトルに反し、僕はCTOではないのに登壇させてもらうという若干の出オチ感のある登場でしたが、元気に発表させていただきました。 内容的に若干浮くかなとおもったんですが、今回参加者の選定がマッチしたのか、意外にも同系統の発表が並びました。 発表スライドは以下になります。 speakerdeck.com 発表の趣旨は、エンジニアのキャリアパスには事業責任者もあるよという話です。 僕のキャリアパスとしてはエンジニア→PdM→事業責任者なのですが、 なんでそのようなキャリアパスを辿ったのだろうかと考えていた時に以下のようなつぶやきをしました。 1人で100人分の仕事するエンジニアみたいなものに憧れがあって、自分なりにそれを体現しようとした結果、プロダクトから事業まで見れるように自分の関わる範囲を広げたって感じなんだよな。気質的に突き詰めるより繋げるみたいなほうがあってたというか。 — 柳川慶太@BASE BANK (@gimupop) 2024年2月22日 (いいねください) この「1人で100人分の仕事するエンジニアみたいなものに憧れ」という言葉が出てきた時に、憑き物が取れたような気持ちになり、この部分を膨らませて話してみようということで作った資料になります。 自分が実際に事業責任者になった経緯としては、足りないスペースを埋めていったらそうなった、という表現が正しいです。 ただ後から考えた時に、「自分のパワーを最大限事業のためになることに使おう」と思ったからこうなったんだなということに気がつきました。 エンジニアだからこそできるアプローチ、だからこその事業の伸ばし方という部分を信じていたのだと思います。 発表の中で出てきた事業計画を引いてみるはマジでおすすめです。その計画の中で自分にできることはなんなんだろうと考えてみるとめちゃくちゃ視界がクリアになると思います。 反省点としては、なんで事業責任者になることが「1人で100人分の仕事すること」に繋がるのかという掘り下げが甘かったなというのがあるので、次回はそこを補足した発表にしたいなと考えています。 このテーマ擦る気満々です。 プロダクトで勝負する会社にとって、事業計画から企画から開発から全て一貫してみれるということはものすごく強みになります。この点だけで6時間語れますが泣く泣くカットしました。 この発表で一番伝えたかったこととしては、「誰しも戦い方を考えれば最前線で戦える」ということです。自分の強みを考え続けて、それをうまく取り組むことに紐付けることがとても大切なことだと考えています。 BASEは「自分の好きなことをしてそれを仕事にしたり経済活動を行っている」人々を応援するサービスです。 だからこそ、そのサービスを作っている我々も、それぞれの人が持つ可能性を信じて、日々日々レベルアップしながら仕事しいるんだという矜持が伝わればという発表でした。 個人ブログにも補足記事を書きましたので、お時間ある方はぜひ。 note.com 各発表への感想 株式会社タイミー 執行役員CTO 亀田 彗さん 発表タイトルは「タイミーの歴史に起きたこと、そこから抽象化してCTOに求められること」でした。 生存性バイアスというキーワードもありましたが、赤裸々な実体験が綴られており、事業を作って成長させていくってこういうことだよなと深く首肯してしまいました。 CTOとして必要な要素に 要素① 変化を好むこと 要素② 諦めないこと 要素③ ものづくりと事業への熱いハート を挙げており、マジで全部わかるなと思いました。特に諦めないことが僕のテーマにも入っていてテンションが上がりました。 事業を作っていくって総合格闘技ですよねという言葉で勝手に納得しました。 株式会社tacoms CTO 井上 将斗さん 発表タイトルは「CTOとしてどのように役割を変えてきたか / 4年間を振り返ってみた」でした。 speakerdeck.com 実際のハードシングスに対する乗り越え方が赤裸々に書かれており、興奮しました。 そしてネタの中で、まさかの事業計画被りということで大変失礼しました。 発表内容に深く勇気づけられました エーテンラボ株式会社 共同創業者＆取締役CTO 山口 信行さん 発表タイトルは「持続的成長のためのプロダクトと組織づくり」でした。 speakerdeck.com 発表の中で会社の行動指針を作ったら、プロダクトが達成すべきミッションと共通していたということを発表の中で仰っており、すごくいい話だなと感じました。 とてもミッションファーストな会社だなと思い参考になりました。 総括 「事業が死なないようにできることをやり切る」という観点において、CTOも事業責任者も共通項があるなということが強く認識できた会になりました。 僕も「ちゃんとエンジニアとして進化した結果の事業責任者なんだよ」ということを勝手に語るつもりでしたが、はからずもみんな同じなんだと思え、エモい気持ちになったすごく良い会でした。 生き残ってやるぞという思いが感じ取れて最高でした。新規事業とかスタートアップってこれだよなと思い、めちゃくちゃパワーをもらえました。 主催いただきましたROSCAさん、ありがとうございました。 最後に、BASE BANK事業部は絶賛採用活動をさせていただいています。 採用資料も最近新しくして読みやすくなったと思うので、ぜひご気軽にカジュアル面談から、お声がけお願い致します。 人のチャレンジを支援し、可能性を広げる活動をぜひご一緒に！よろしくお願いします！ speakerdeck.com
こんにちは。 BASEの ProductDevでエンジニアをしています、遠藤( @Fendo181 )です。 今回、2024年2月11日に開催された「PHPカンファレンス関西2024」にコアスタッフとして参加してきました! 2024.kphpug.jp 2018年から6年越しに開催された「PHPカンファレンス関西2024」でしたが無事に開催できました。蓋を開けてみれば431名という多くの方が参加された大きなイベントだったと思います。 この記事ではそんな「PHPカンファレンス関西2024」にコアスタッフとして参加した背景や、自分の役割や、コアスタッフを経験して思ったことなどをまとめてみようと思います。 また、この記事をきっかけにコアスタッフでなくても、なんらかの技術コミュニティに参加するきっかけになれば幸いです。 コアスタッフに参加しようと思ったきっかけについて 「PHPカンファレンス関西2024」のコアスタッフの募集が始まったのが去年の8月頃でした。 元々PHPに関わらず、なんらかの技術イベントに参加するのが好きで当日スタッフを経験した事はありました。 ただ、数年ぶりに「PHPカンファレンス関西」を開催するということで、コミュニティへの貢献も含め「なにか少しでもお手伝いができれば!」と思ったのが参加したきっかけの1つです。 また関西でのPHPコミュニティの方とは知り合いが少ないので、せっかくなら現地で交流もできればと考えてコアスタッフとして参加してみました。 コアスタッフでの自分の役割について 自分は「一般参加者対応チーム」に配属となりました。 このチームでは一般参加者へ向けたチケット販売の運用、当日の会場運営、スタッフの管理、懇親会でのケータリング周りの準備、会場連携などを担当するチームで、自分は主にケータリング周りと会場連携を行っていました。 他のコアスタッフの役割については以下のnote記事でもまとまっていますので興味があればご覧ください。 note.com 具体的に自分が対応した事を洗い出すと以下の作業をやっていました。 懇親会スポンサー企画の準備 懇親会でのケータリングの手配 会場で参加者に配布するドリンクの手配 当日スタッフ向けのお弁当の手配 カンファレンス会場を提供する企業様の連携 カンファレンス会場との連携については、Wifiや照明など会場からレンタルする機材や、事前にスポンサー側から送られてくる荷物が無事に受け取れるよう書類を用意するなど動いてました。 カンファレンス会場を用意する上で、当日問題なく実施するために提供元企業様との連携が重要でした。開催前日までに、会場の設備の使用については何度も連絡をとりながら準備をすすめました。 当日の動きについて 当日は主に会場側での設備の配置や、なにか問題が起きたときに備えて見回りをしてました。 開催前に、メールでのやりとりでカンファレンス会場の資料には何度も目を通してましたが、自分が東京に在住していたため、実際の会場は見れてなく、現地にいるスタッフが撮影してくださった会場の写真を見ながら配置など、イメージトレーニングをしてました。 したがって、当日の朝一番に会場に入ってから、すぐさま部屋の配置の把握や、ちゃんとメールで申請した通りにレンタル機材や荷物が届いているかを確認してホッとしたのを覚えています。 その後は会場での予期せぬトラブルが起きたときに備えて、適宜カンファレンス会場を提供する企業様と連絡をしながら、会場を見回りしてました。数年ぶりの開催で過去のナレッジも少なく、当日の予期せぬトラブルが一番の心配でした。 しかし、特に大きなトラブルもなく最後まで進行できたのは本当に良かったと思います。 振り返ってみて 「PHPカンファレンス関西2024」が無事に開催できたこともそうですが、6年ぶりの開催にも関わらず、沢山の人が参加して頂き、交流する場を提供できたことがなによりもスタッフとして嬉しかったです。 また、ここまで運営に関わっていたコアスタッフや、当日スタッフの皆さんとも、終わってからの懇親会で交流できたことも良い思い出になりました。 まとめ コアスタッフとして参加したとき、担当した仕事が無事にできるか不安だったのですが、無事にやりきれてよかったです。 これまでは一人のエンジニアとしてアウトプットをするためにカンファレンスで登壇したり、勉強会等で発表をしてましたが、コアスタッフとして参加してみると その場所を提供するにあたって沢山の有志の情熱によって支えられていることがわかります。 その一員として、今回、PHPカンファレンス関西2024の開催をお手伝いできたこと、心より誇りに思います。 今後もPHPに関わらず、カンファレンスは開催されるので、もしコミュニティを盛り上げてみたいと思った方はスタッフに応募してみてください!
こんにちは！BASEでエンジニアをしている竹本です。 2/10(土)に広島国際会議場で開催された YAPC::Hiroshima 2024 に参加してきたので、当日聞くことができたセッションの感想をイベントレポートとしてお届けします。 会場の様子 BASE はYAPC:Hiroshima 2024にプラチナスポンサーとして協賛していました。 協賛の背景については以下の記事をご覧ください。 YAPC::Hiroshima 2024にBASE がPlatinumスポンサーとして協賛します 印象に残ったセッション 経営・意志・エンジニアリング キャリアの初めから12年間CTOという役割を担っていた松本さんが、ソフトウェア開発の延長にある経営というテーマで発表されていました。 経営者というtech lead とも Engineering Managerとも向きの違う役割のあり方とそれがエンジニアリングとどう繋がっているかという話で、大変興味深く聞かせていただきました。 以下は自分の要約memoになります。 経営は3つの変数(事業・組織・技術)と４つの制約(お客様, 社員、投資家、社会)がある。 大切な前提として「みんなの楽しい」がある 楽しいを実現するために3つの変数(アーキテクチャ)を同時に成立させ、4つの制約(ステークホルダー)を満足させることを技術経営者は考えている。 技術だけがエンジニアリングの対象ではなく、事業・技術・組織をソフトウェア的に設計・運用できる 長期的であるほど楽しい 根幹は意志 平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜 発表者: - 櫛井 優介( @941 )さん - 伊藤 直也( @naoya_ito )さん - 和田 裕介( @yusukebe )さん - 和田 卓人( @t_wada )さん - 馮 富久( @tomihisa )さん この発表はランチ後のパネルディスカッションでした。 941さんという方がファシリをしながら事前に用意していたテーマだったり、会場内で出たテーマについてディスカッションされていました。 ファシリの941さんの話運びが秀逸で、常に話が途切れず会場が笑いに包まれていました。 「コードを書かないCTOは認めない」「個人開発が最近ファッションになってきている」「使っているエディタときのこ・たけのこどちらが好き？」みたいなやや攻めた発言も飛び交い、非常に楽しく聞くことができました。 「とほほのWWW入門」お好み よもやま話 資料: https://www.tohoho-web.com/ot/yapc-2024-tohoho.pdf 発表者: 杜甫々さん 「とほほのWWW入門」を運営している杜甫々さんによる発表でした。とほほのWWW入門は1996年から現在に至るまで更新が続けられているサイトで、当日の会場・Twitterは大盛り上がりでした。長きにわたってWebサイトを運営されているとほほさんから見た現在のWeb開発について思うところやとほほさんの人となりがわかるエピソードを聞くことができて、感激でした。 カンファレンススポンサーのススメ 発表者: 川口 ( id:dmnlk ) さん 弊社CTOの川口さんのスポンサーLTは「カンファレンスにスポンサードするにはどうするか」というテーマでした。 これが答えです。 決裁権、欲しい！ このスライドでひと笑いとった後に、稟議を出して勝ち取る、社の全体予算を確認する、仲間を集めるなど具体的な手法が紹介されていました。BASEが今回YAPCにスポンサードしたのは主催の方の熱意に触れたこと＋キーノートが杜甫々さんだったからだそうです。自分が所属する会社が技術コミュニティに貢献できる文化があることを改めていいなぁと感じました。 終わりに YAPCめちゃくちゃ楽しかったです！ 当日は会場で知り合いにばったり会ったり、懇親会で全然知らない人と話すことができたりと、とても楽しい時間を過ごせました。 運営・参加者の皆様、改めてお疲れ様でした。
CTOの川口 ( id:dmnlk ) です。 これはBASE Advent Calendar25日目の記事です。 今年も僕は立候補してないのに勝手に日程が組み込まれてました。毎年書いてくれるメンバーが増えていってくれているのになぜ。 CTOについて 自分は2019年からBASE株式会社のCTOをやっています。 気づいたら4年近くやっていることになっていて驚いています。 たまに社外のエンジニアの方とお会いするとCTOになるにはどうすればいいかということを聞かれることがあります。 僕個人のサンプルではありますが、少し書いてみようかと思います。 なぜCTOが必要なのか 必ずしもCTOが必要なのでしょうか。 これに関しては僕は必要であると考えます。 自分がWeb企業にいるという前提条件はありますが、システムやテクノロジーが非常に重要な市場優位性となります。 ただプロダクト開発をするだけでなく最新の技術トレンドを把握し、それらを企業のビジネスモデルに統合することが重要です。CTOは、企業が市場で競争力を保ち、革新的な製品やサービスを提供できるようにするための鍵となる役割を果たします。 CTOは、技術とビジネスの両方の言語を理解し、両者の間のコミュニケーションと協力を促進します。これにより、技術的な洞察がビジネス戦略に統合され、より効果的な意思決定が可能になります。 技術は常に進化しているため、CTOは最新の知識とスキルを維持し、組織を適応させる必要があります。これにより、企業は変化する市場環境に柔軟に対応し、持続可能な成長を達成できます。 CTOの役割は、単に技術的な専門知識を超え、戦略的な思考、リーダーシップ、そしてビジネスと技術の統合を通じて、企業の成功と革新を推進する重要な要素です。 こう書くと自分がこれをちゃんと実行できているかというと大分疑問になりますが、責務としてはこれらがあげられるでしょう。 役割と責任について 会社のフェーズによってここは大きく変わると思います。 初期スタートアップのCTOは経営責任というよりもテックリードに近いポジションになるでしょう。 ひたすらに機能実装をすることが責務となり場合によっては情シス的なポジションも兼任するかと思います。 創業数年経ち、フェーズが変わっていく中で改めてCTOというものの重要性が高まっていくでしょう。 事業戦略と技術戦略を統合し、中長期的視点で技術開発を進めていくことになります。 プロダクトはまだまだグロースさせていくのでメンバーは開発に手一杯でしょう。 その中でCTOは次の未来の開発のためのボトルネックを見つけそれを改善していくための技術検証やロードマップを描いていく必要があります。 組織に関しても着目しなければなりません。 技術チームのリーダーとして、CTOはチームの育成、スキルの向上、そして生産性の最大化を担います。また、組織全体の技術的ビジョンを共有し、異なる部門間での協力を促進することで、企業の目標達成に貢献します。 VPoEのような存在がいると分業しやすいかもしれません。 スキルセットについて ここが一番よく聞かれるのですが、どのような技術を持っているとCTOになれますかといわれます。 個人的には、特定の技術の専門性というよりは一通りの技術に60点くらいの理解度があることの方が重要です。 特定技術の深掘りは現場のメンバーに任せ、市場の技術動向と自分達のプロダクトやシステムに何が必要かを考えるために分野に寄らない興味関心があるといいでしょう。 インフラやセキュリティについての知識はどちらかというと重要視されると思います。 インフラに関してはサービスキャパシティのプランニングやコスト管理意識を持つのに重要ですし、セキュリティはどうしてもサービスグロースの中で後回しにされがちなので先見性を持って問題意識を持つのに必要となります。 frontend技術に専門性を持っている人がCTOに多くないのは、AWSやGCPのようなクラウドインフラサービスのroot権限を渡しづらいからではと思っているところはあります。感覚値でしかありませんが。 経営スキルについては最初から持っている人は少ないでしょう。僕も当初全く持ち合わせていなかったと思います。 長期的なビジョンを持ち企業戦略を実行するための戦略的思考、コスト効率の高いソリューションを開発していくための財務管理、様々並行で行われる開発を管理するためのプロジェクト管理などが求められていきます。 とはいえこのあたりは、やっていく中で学んでいくしかないように思いますし他の企業の先輩CTOの方と話して学んでいくのがオススメです。 ソフトスキルに関しても重要です。 技術チームを牽引しメンバーのモチベーションを高め生産性を向上させる能力としてのリーダーシップ、技術的な概念を非技術者にもわかりやすく伝え、異なるステークホルダーと効果的にコミュニケーションを取れるようにするなどです。 特にコミュニケーションについては、エンジニアにとっては重要だよねという概念をしっかりと非技術者に伝える事が必要です。 そうでない場合、リファクタリングやアーキテクチャ変更などについて経営陣に伝わらずシステムに問題が起きてプロダクトの成長を阻害するタイミングになってからしか対応が許されないといったことになりがちです。身に覚えがある人も結構いるのではないでしょうか。 CTOになるためには、これらのスキルと経験をバランス良く持ち合わせ、常に最新の技術トレンドに敏感であることが求められます。また、ビジネスと技術の両面で企業をリードするための幅広い知識と洞察が不可欠です。 キャリアパスの通過点としてのCTO CTOの役割は、単なる終着点ではありません。 それはむしろ、私のキャリアパスにおける重要な通過点であり、成長と発展の旅の一環です。このポジションは、私がこれまでに積み重ねてきた経験と知識を活かし、さらに拡張する機会を提供してくれます。 正直な話をすれば、 IC（Individual Contributor )として働いているときよりも苦手なこともやる必要がありストレスを感じる面も一定あります。 ですがやってみて4年続けてみて、自分がただ働いているだけでは知り得なかった世界や考え方に多く触れ悩み自分の得手不得手を改めて実感できていると感じています。 なってから悩んだときの一つアドバイスをするとすれば、とりあえずCTOが集まるようなイベント(吉祥寺にp2bhausという良いお店があります)などに顔を出して様々なフェーズのCTOに会いざっくばらんに悩みを話してみると良いでしょう。どうしてもこのようなポジションの悩みはオープンにならないことが多く、孤独な戦いになりがちです。会社の他のメンバーに悩んでいるところを多く見せるわけにもいかないでしょう。 その時に同じような悩みを持ち、現在進行系で悩んでいる人や既に解決して次のフェーズを見据えている人たちの話を聞くことは大きなプラスになるでしょう。 まとめ 「CTOになる」という目標は、ただの職業的な到達点ではなく、技術とビジネスの世界で自己を実現する旅の一部です。この役割では、最新の技術トレンドを駆使し、革新的な解決策を生み出し、チームをインスパイアすることが求められます。これは、あなたの技術キャリアにおいて、新たな視野を開き、影響力を拡大する絶好の機会です。 なるチャンスは多くないかもしれませんが、もしCTOになっていきたいという方は自分の意志で掴み取って逃さないようにしてください。 なにより重要なのは、自分がその会社の一部として大きな時間を賭けられるだけ気に入った会社やプロダクトがあるということかと思います。非常に困難な状況になっても、会社やプロダクトがあれば割りとなんとかなります。 というわけでそんな自分がCTOをやっている価値があると思っているBASEではメンバーの募集をしています。 下記からご応募をお待ちしております。 open.talentio.com
この記事は BASE アドベントカレンダー 2023 の24日目の記事です。 基盤グループ エンジニアの田中 ( @tenkoma ) です。 2023年5月から8月にかけて、書籍「単体テストの考え方/使い方」の読書会を社内有志でしました。 読書会の様子や感想をまとめます。 書籍「単体テストの考え方/使い方」について 単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 | マイナビブックス 単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 | 達人出版会 2022年12月に出版されました。 2020年1月に出版された Unit Testing Principles, Practices, and Patterns (Manning) の翻訳書です。 単体テストについて定義し、その価値を最大限に高めるための方法について解説されています。 書籍への期待 テストコードを構成する概念やそれを書くテクニックがまとめられているところが気になりましたが、1.2 なぜ、 単体テストを行うのか？(7ページ)で紹介された「 持続可能 」という言葉に惹かれました。 それでは、単体テストをすることで何を成し遂げたいのでしょうか？その答えは、ソフトウェア開発プロジェクトの成長を持続可能なものにする、ということです。そして、この 「 持続可能 」という言葉が鍵となります。と言うのも、プロジェクトは簡単に大きくなってしまうものであり、特に、プロジェクトをゼロから作り始めた場合、その傾向が強くなります。 しかしながら、その成長を長いあいだ持続させることは簡単なことではありません。 例えば、テストコードも量が増えてくるとさまざまな問題が起こることがあります。テスト実行が遅くなる(Slow Tests)、テスト結果が不安定になる(Flaky Test / Erratic Test)などは代表的かと思います。 それらの兆候を発生しにくくし、プロジェクトの持続可能性を高めるテストにしたい。そのための知見が得られそうだと期待しました。 読書会の経緯と進め方 4月下旬くらいに個人としてテストコードの書き方をレベルアップする方法やら、知識をうまく他人に説明できるようになりたいと思い 何か参考になりそうな資料はないか検索したところこの書籍を見つけました。 内容をみてみると、未だ日本語訳が出版されていない xUnit Test Patterns の知識も多く取り込まれてそうと感じました。 話題共有できるSlackチャンネルを作ったところ、興味がある方、積読してた方などが集まったため、読書会を行うことにしました。 書籍の内容で分からない箇所や話したいトピックをNotionに書いてもらう(事前に読まなくても参加OK) 事前に読んでもらうのは少しハードルが高いかもしれませんが、グループ横断でメンバーが集まったので、スムーズに進行するために可能なら読んでもらう感じにしました 毎週月曜日9:30から1時間、Slack Huddleで話す時間を用意する 1章分のテーマについてその時間で話す 章末に書かれている2〜3ページのまとめを音読 その後、Notionに書かれたトピックについて話す 最小実施人数は3名で集まらなかったらスキップ。祝日の場合もスキップ 1章を読み始める前に、進め方について話す回を用意して大枠を決めました。 読書会の結果 参加者は日頃からプロダクションコードとテストコードの両方を書く開発者が多かったですが、そのノウハウや課題がチームをまたいで共有される良い場になったと思います。 また、プロジェクトのプロダクションコード・テストコード改善にこの書籍の内容や、Slackチャンネルが紹介されることもあり、やってよかったなと思いました。 書籍についての感想 まずは、書籍の中で定義されている様々な用語を普段テストコードを書いたりコードレビューするときに活用できるものが増えたと思います。 例えば、以下のような用語たちです。 テスト対象システム(System Under Test: SUT) テスト・ダブル(モック・スタブ・スパイなど) AAAパターン( 3Aパターン とも) 用語自体は知ってはいたのですが、これらをテストコードに使ったり、コードレビューで用いなくてもテストコード運用に支障なく、説明するコストも必要なので、使わなくていいのでは？と思っていました。 しかし、用語の意味を理解し、テストコード中の変数名に sut や stub を使ってみると、効果があると思い直しました。 テストメソッド中で変数名が $sut なら、それがテスト対象であり、 $**Stub なら、テスト対象に間接的に入力を与える依存であるとわかります。 $**Spy なら、メソッド呼び出しを記録して、あとでアサーションするんだろうな、と推測できます。テストコードを理解するコストを下げる効果がありそうです。 次に以下のようなトピックについて丁寧な解説があり、読み進めているときはやや過剰さを感じていました。 網羅率(coverage) 単体テストにおける古典学派とロンドン学派 その後の章を読むために必要な基礎知識であるとわかります。 古典学派とロンドン学派については、 テスト駆動開発 - オーム社 で紹介されていましたが、正直知識も興味もなかったです。しかしテストダブルの使い方の違いがテストコードの書き方にも大きな影響を与えることが理解でき、テスト戦略を考える上で必要な解説なのか、と思い直しました。 第4章からは「良い単体テストを構成する4本の柱」として以下を軸に詳細な議論を進めていきます。 退行(regression)に対する保護 リファクタリングへの耐性 迅速なフィードバック 保守のしやすさ モックの使い方や統合テストの章も頻繁にこの軸を使って説明が進むため、理解しやすいと思います。 依存、偽陽性・偽陰性、テストダブルなども図を多く使って解説されるためわかりやすいです。 以下のポストを紹介します。 単体テストの考え方を読んでいるけど、著者は知識の整理がめちゃめちゃ上手い。スタブとモックをコマンドクエリ分離の原則と結びつけたり、良いテストが備える性質のトレードオフをわかりやすく図解してくれたり、とてつもなくわかりやすい。必読の一冊になる気がする。 https://t.co/Y3bhkSrp7x — ひらまつ＠Linux200本ノック📘発売中丨ひらまつしょうたろう (@hiramatsuu) April 28, 2023 ここまで特長や良い点について書きましたが、一方で鵜呑みにできない点はありそうです。 関数型アーキテクチャについては僕にその知識がほぼなく、活用できるか分からなかったこと、紹介されるサンプルの多くがバックエンドのロジックであり、 フロントエンドアプリケーションに適用できるかについても網羅的ではないかもしれません。 以上、この書籍だけでテストについて網羅できるわけではない部分はありそうですが、日常的なテストの書き方、コードレビューから、テスト戦略を組み立てる上で参考にできる部分が多く、良書だと感じました。 明日は、川口 ( id:dmnlk ) さんの組織の話です。お楽しみに！ おまけ github.com/tenkoma/utppp-php いくつかの章についてPHPで写経しました
はじめに この記事は BASE Advent Calendar 2023 の23日目の記事です。 こんにちは、BASE株式会社のBASE BANK Divisionというチームでエンジニアをしている大垣( @re_yuzuy )です！ 今日で20歳になりました。 今年はインターンから正社員になったり、1人暮らしを始めてみたり、色々と新しいことを始められた1年だったかなと思っています。 その中でも印象に残っているのは、BASEのエンジニアインターン採用を再開できたことです。 この記事ではインターン採用を再開しようと思った理由やインターンの概要などについて書いていきます。 インターン採用を再開しようと思った理由 前提としてBASEにおけるエンジニアインターン採用は僕が入社した2021年2月ごろから閉じられており、記憶の限りでは僕が最後のエンジニアインターンでした。 僕が正社員になった現在、BASEにはエンジニアインターンとして働いている方は0人です。 個人的にインターンでの経験がとても楽しくためになったと思っており、 他の人たちにも同じような体験をしてほしい と思ったのがインターン採用を再開しようと思った1番の理由です。 僕は高校生のときからエンジニアインターンとして働き始めましたがこれは完全に運がよかったとしか言いようがなく、今より多くの人にそういった機会が訪れるようになればと思っています。 自分のインターン体験談 実際インターンでどんなことができるのかというところで、少し前までインターンだった僕の体験談を1例として軽く紹介したいと思います。 僕は2021年2月にインターンとして入社し、オンボーディングタスクを終えてからすぐにBASEカードの開発チームにアサインされました。 BASEカードについての詳しい説明は こちらのページ を参照していただきたいのですが、BASEで作ったショップの売上をデビットカードのような体験でカード経由で使える機能です。 当時はBASEカードのリリース前で、たまたま入ったタイミング的に新規プロダクトかつカード決済というちょっとニッチなドメインの開発に関われたことはとても運が良かったと思っています。 BASEカードの立ち上げでは決済コア機能の実装やキャッシュバックの設計など、結構重要な部分を任せてもらいました。 BASEカードDay1リリース後はリアルカード機能に向けた開発やDay1リリースの後片付け、施策に向けた開発など色々やっていました。 手を挙げれば大抵やらせてくれる環境で、いい意味でインターンだから~と特別扱いされなくてとてもありがたかったなと思っています。 また気持ち的にも、みんなと一緒の目線でBASEカードというプロダクトに向き合えていたと感じています。 改めてインターン時代を支えてくださったみなさんに感謝を。 インターンの概要 open.talentio.com 今回募集しているのは僕の所属するBASE BANK Divisionでの長期インターンです。 BASE BANKはBASEの中でも金融ドメインの開発を担当しており、主に「YELL BANK」「BASEカード」「振込申請」の3つの機能・プロダクトを開発しています。 インターンではいずれかの開発チームに1メンバーとして参画していただき、様々な課題解決に向けた開発に携わっていただきます。 プロダクト開発への関わり方について BASE BANKのエンジニアは全員がフルサイクルエンジニアとして働いています。 フルサイクルエンジニアという言葉に聞き覚えがない方も多いと思いますが、1文で説明するなら「設計・開発・保守・運用など開発サイクルすべてに主体的に取り組むエンジニア」かなと思います。 僕はフルサイクルな開発ができることがBASE BANKで開発する上で最も大きい魅力の1つだと思っています！ もちろんインターンの方も同様に、フルサイクルエンジニアとして特定の開発サイクルや分野に固執しないような働き方をしていただくことになります。 仕様が決まっているものを実装しておわり！ではなく、プロダクトの仕様検討やシステムの設計から実装、リリース後のバグや問い合わせ対応まで幅広く行います。 フルサイクルエンジニアについての詳しく知りたい方は、昨年のアドベントカレンダーで同じくBASE BANKの松雪さんがブログを書いているのでそれを読むのがおすすめです: Real World Full Cycle Developers 応募条件について 前述した通り、より多くの人に機会が訪れてほしいという思想のもと、今回のインターンは実務未経験でも応募可能にしています。 とはいえ習熟度と環境にあまりに乖離があるとお互いに不幸になってしまうので一定の基準を設けています。 技術的な基準についての詳細は募集要項を参照してください。 また出勤頻度等についてですが、現状週3日以上かつ週15時間以上という条件にしています。 これは能動的で自立した開発を任せられる最低限の頻度かつ時間ということで定めています。 さいごに BASE BANKでのインターンに少しでも興味を持っていただいた方は、ぜひ募集ページから応募していただきたいです！ いきなり面接若干ハードル高いよ、という方は @re_yuzuy にDMしていただければと思います！ぜひカジュアルに話しましょう！ open.talentio.com 明日は @tenkoma さんの社内読書会についての話です。お楽しみに！
はじめに この記事は BASE アドベントカレンダー 2023 の22日目の記事です。 こんにちは。 Communication Design Groupデザイナーの藤井です。 プロダクトをはじめ、LP、メール、またイベントや営業資料など、直接間接を問わずBASEのテキストコミュニケーション全般のユーザー体験を向上させる、UXライティング／コピーライティングを担当しています。 「テキストコミュニケーションをデザインする」をキーワードに、テキスト版デザインシステムを構築・運用し、あらゆるタッチポイントにおいて、ターゲット・目的・ゴールにもっとも最適化されたテキスト体験を設計、デザインしています。 テキスト品質担保施策の実施から見えてきた、次の課題 これまで、トーンオブボイスを策定したり、ガイドラインを構築したり、テキスト入力支援ツールを開発したりと、テキストの品質を担保するためのさまざまな取り組みをおこなってきました。 そのなかで見えてきたのは、こんな課題でした。 組織の拡大にともなうPJの増加により、テキストレビュー／UXライティングの合計時間はそれほど変わらない テキスト体験の設計ナレッジの共有による、プロダクトチーム全体のテキストコミュニケーション力のボトムアップが必要 テキスト入力支援ツール・textlintの導入、運用開始により、たしかに本質的な体験のデザインに多くのリソースをかけられるようになり、飛躍的にBASEのテキストコミュニケーションは向上しました。 一方、BASEのプロダクトもオーナー数、また組織が急拡大するなか、テキストレビュー担当者のリソース自体は急に増えるわけではなく、結果としてまだまだレビュアーの属人性に拠っているのもまた現実なのです。 UXライティング力の組織全体におけるボトムアップが必要 では、この課題に対してどのようなアプローチが有効なのでしょうか？ 私たちは、テキストをコミュニケーションに用いるBASEのすべてのメンバーに、UXライティングのもっとも本質的な部分、「相手にことばを届けるためのコツ」をシェア、活用してもらうことによる、全体的なボトムアップを図ること、と考えました。 そしてそれは、ターゲット・目的・ゴールにもっとも最適化されたテキスト体験の設計・デザインのためのメソッド（方法論）、つまりUXライティングの本丸にほかなりません。 かくして2023年は、社内LTへの登壇、ワークショップの実施、ライティング駆け込み寺とそのまとめメソッドの共有など、とにかくシェアに明け暮れた1年でした。 取り組んだ、3つの手法 今回は、その取り組みの一部をご紹介してみます。 1. 社内LTへの登壇 まずはプロダクトチームに限らず、会社全体に向けて実施させていただいたLT、「BASE、UXライティングの流儀」。 そもそもユーザー体験のよい日本語とは、 意味がわからず、モヤモヤさせない 不愉快な思いをさせない どうすればいいか、すぐわかる つまり「相手を思いやる気持ち」をことばに込めることであり、気持ちよくコミュニケーションするための作法であるということ、それはプロダクトのタッチポイントに限らず、生きていくなかで誰にとっても基本となるたしなみ、であることを発信。 その上で、BASEのことばがよりどころとしている3つの信念（Principle）、 シンプル＆プロフェッショナル →誰でもわかる／誰でも満足できる オーナーシップ →自分らしいまま自信が持てる 全員、使える →リテラシーフリー を共有し、だからこそ自分ごと化してもらえる、行動してもらえる、ということをお伝えしました。 2. ワークショップの実施 そんな信念を実際にテキストに落とし込むためのメソッドを、ワークショップで実践。 書き方の基本5か条、 とにかく短く、簡潔に（一文一義） 語りかけるように 何ができるようになるのかを伝える いい感じのさじ加減の丁寧さ 何が起きたのか、何をしたらいいのかを伝える をシェアしてから、テキストレビュー担当者がおこなっているテキストレビューに、実際に挑戦。 お題のテキストのターゲット／目的／ゴールを書き出し、そのターゲットに向けた言葉使いで、どうすればこちらが描いたゴールにつながるか考え、文章を整える作業を体験してもらいました。 3. オープンテキストレビュー・ライティング駆け込み寺の開催 また、毎日14:00〜14:30にはオープン・テキストレビュー／ライティング駆け込み寺も開催するように。 さまざまなチーム、PJから日々依頼いただいているテキストレビューを、画面を共有してライヴで実施しつつ、「割り込みで急ぎのレビューを依頼したい」「どうやって書けばうまくまとまるのかわからない」「イチから書いてほしい」などの、テキストにまつわるお悩みを解決する、駆け込み寺をオープン。 たとえば、 「『こちら』の禁止」 →「こちら」では、何を指すのかわからない。読み手の行動に齟齬がないよう、遷移先ページタイトルからテキストリンクさせる 「句読点がリズムを作る」 →人はアタマで音読している。息継ぎできるよう句読点を活用すると、読み心地も上がる 「総量を明示」 →先に「◯つのコツ」と言われると、「それくらいなら読めるかな」という心理になって向き合ってもらいやすくなる。オススメは人間の脳の特性上、3がいいと言われる など、テキストガイドラインではわからないレビュワーの視点・メソッドを、実際のテキストのビフォーアフターを見ながら詳らかにすることで、より体感してもらえるようにしています。 おわりに 2023年11月に11周年を迎えたBASEは、ありがたいことに、200万を超えるショップオーナーの皆様にお使いいただいているプラットフォームに成長いたしました。 BASEのテキストコミュニケーションをデザインする取り組みは、その効果測定、アップデート、最適化はもちろんのこと、コピーライティングの分野でも最高のユーザー体験をデザインできる組織へと進化してまいります。 すべては、「最小の力で、最大の成果を出す、ネットショップ作成サービス」でありつづけるために。 そして、「多くの進化と改善で、ショップオーナーの皆様の成功を後押し」するために。 2024年のBASEにも、どうぞご期待ください。 さて、明日のアドベントカレンダーは @Ren Ogaki さんです！ お楽しみに。
はじめに 本記事は BASE アドベントカレンダー 2023 の22日目の記事です。 おはようございます、こんにちは、こんばんは。 BASE BANK DivisionでPMM（Product Marketing Manager）を務める@usui_daisukeと申します。 記事タイトルは『 ぼくらが旅に出る理由 』をオマージュしました。服とお酒と音楽が好きな人間です。 私が所属しているBASE BANKとは、BASEの中でもショップオーナーさん向けの金融系プロダクトを担当するチームで、私は「振込申請」というショップの売上金を引き出す機能を担当しています。 今回は、だいぶ世の中に浸透してきた気はしつつ*1、まだまだイメージが付きづらいであろうPMMという職種が何をやっているのか？私がなにを面白いと思ってPMMをやっているのか？をお話できればと思います。 *1 過去5年間の「PMM」に対する検索トレンド推移を参照＆自身の肌感。定期的に波が来ているように感じる https://trends.google.co.jp/trends/explore?hl=ja&tz=-540&date=today+5-y&geo=JP&hl=ja&q=PMM&sni=3 BASE BANKにPMMが必要な理由 弊社はグループミッションとして「Payment to the People,Power to the People.」を掲げており、決済の簡易化を通じて、人々をエンパワーメントすることを目指しています。 それを補完する手段のひとつとして、「金融の簡易化」が必要であるという仮説を持ち、ショップ作成サービス「BASE」を運営するチームとは別に、BASE BANKという金融に特化したチームや各プロダクトが出来上がりました。 BASE BANKチームのミッション。弊社採用資料より引用 https://speakerdeck.com/base/basebank 現在、BASEを使ってくださるショップオーナーさんは、70%以上が個人事業主であり、4名以下で運営されているショップがほぼ100％を占めています*2。 *2 弊社 オーナーズ調査2023 より 個人やスモールチームの中で、金融知識に明るい方というのは多くはなく、そういった知識よりも「どうしたらいいものを作れるか？」「どうしたらもっと商品が売れるか？」という部分にフォーカスしたい方が多いと、過去のリサーチから明らかになりました。 他方で、商売をする上でお金まわりというのは切っても切れない関係で、否が応でも考えさせられる事柄です。 BASE BANKチームは、個人やスモールチームにとってわかりづらい「金融」というドメインにおいてプロダクト開発を行っており、「いかにわかりやすく、利用価値や方法を伝えられるか？」という点が、プロダクトそのものと同じくらい重要。 そのため、「ユーザーとプロダクトの『橋渡し役』」として、PMMという職種が必要とされています。 BASE BANKにおけるPMMとは 「PMM」と検索すると、さまざまな媒体・人の記事が出てきますが、BASE BANKではPMMに対して以下の3つが求められています。 チーム内で最もユーザーへの深い理解・インサイトを持つ プロダクトマーケティングにおける施策実行および数字に責任を持つ プロダクトマーケティングで得たインサイトを基に、PdMを中心に各ステークホルダーと協同し、プロダクトへ反映させる BASE BANKでは、ひとつのプロダクトに対してPdMとPMMがひとりずつ紐づいており、担当プロダクトをどう伸ばすか？を二人三脚で考えています。 担当によって異なる部分もありますが、PMMがどんなことをやっているか？を3つほどご紹介。 ユーザー理解のためのリサーチ ユーザーのことを理解していないと、「ユーザーにとってのわかりやすさ」がわかりません。 そのため、アンケートやユーザーインタビューを定期的に実施することでユーザー理解に努め、後述するキャンペーンの企画や効果検証、プロダクトニーズの模索、新機能検討の一助としています。 例えば、「キャンペーンを行っても参加率が伸びない」という問題に対して、キャンペーン告知媒体ごとの認知率や、キャンペーン内容の是非についてアンケートをとってみたり、「プロダクト利用頻度の高いユーザーが、過去と比べて減ってきている」という問題に対して、頻度が落ちた・まったく使わなくなったユーザーにその理由や、使わなくなったあとの移行先についてインタビューしてみたり。 このような形で、各プロダクトが抱えている問題をベースに、アンケートやインタビューを実施しています。 実施したインタビューは、ショップオーナーさんの許諾をいただき記事化することも https://baseu.jp/26724 プロダクトマーケティング ユーザーにプロダクトの価値を届ける手段のひとつとして、かかせないのがキャンペーン。BASE BANKのPMMは企画の立案から進行、分析までを一気通貫で行います。 企画フェーズでは、前述のアンケートやユーザーインタビュー、 Looker から抽出した実績値をもとに、仮説・データを基に企画を立て、PdMと壁打ちしながら企画をまとめ、進行へと移っていきます。 進行フェーズでは、アナリスト・エンジニア・デザイナー・オペレーションといったPdMやPMM以外の職種、BASE BANK以外のメンバーも巻き込みながら進めます。直近私が担当しているキャンペーンだと、12部署・30人前後のメンバーと協同。 PMMは、プロジェクトオーナーとして全体の進行管理をしつつ、このフェーズではキャンペーンの情報を届けるために、プロダクトの管理画面上の文言や、LPやメール、SNSなどの外部に発信する文章を検討・作成し、ユーザーコミュニケーションをリードしていきます。 分析フェーズでは、数値目標の達成有無だけではなく、実施目的に即してユーザーに利用してもらえたか？上振れ・下振れ要因はなんなのか？を明らかにし、次回以降のキャンペーンに役立て、PDCAを回していきます。 プロダクト企画 ユーザーリサーチやプロダクトマーケティングで得たインサイトを基に、PdMを中心に各ステークホルダーと協同し、プロダクトへ反映させるのもPMMの業務。 例えば先日、 BASEカード （BASEの売上金を全国のVISA加盟店で即時に使えるカード）チームで行った「BASEカードの活用事例」をテーマとしたユーザーインタビューの中で「発生している売上に対して、カードの限度額が少なく、使いたい時に使えない場面がある（要約）」といったご意見をいただきました。 話を紐解き、現状のプロダクト体験に照らしてみると、「まとまった仕入れを行いたい時に限度額に達してしまうと、売上金は残っているのに他のカードを使わざるを得ない」というよくない体験となっていたことがわかりました。 その後、インタビューで得たインサイトを踏まえ、想定されるニーズや体験変更において必要な要素を担当PMMが整理。結果として、インタビューから2ヶ月で限度額の引き上げをリリースするに至りました。 baseu.jp 私が思うPMMの面白さ 「ビジネス総合格闘技」という側面 私のキャリアのスタートは、Webメディアの広告営業でした。そこからリサーチャーをやったり、広告プランナーをやったり。インサイドセールスの立ち上げをやったり、カスタマーサクセスの立ち上げをやったり。PdMだったときもあれば、BiZDevだったときもあり、UXコンサルだったときもあり、BASEに入るまで3社10職種以上の業務を行ってきましたが、あの経験使えないな～というものが一切ありません。 ユーザー理解においては、リサーチャーやUXコンサルの経験が活きているし、プロダクトマーケティングやプロダクト企画においては、PdMやBizDevの経験が活きています。細かな業務も含めると、これまで培ってきたスキルが存分に活かせていると感じています。 他方で、数字面ではリサーチャー時代を含めて、定量分析においてはかんたんなクロス集計程度しか行ってこなかったので、数字まわりは入社当初ちょっと苦労しました。ただ、マネージャーやチームメンバーを頼りながら業務を進めていくうちに、今では一定こなせるようになっています。 過去身につけたスキル、新たに身につけた・伸ばしたスキル、すべてを使って仕事できるのが、PMMとしてのやりがいに繋がっています。 ステークホルダーの多さ 前述通り、PMMはさまざまメンバーと連携しながら仕事を進める職種です。私自身、同期・非同期問わず人とコミュニケーションを取るのが好きで、「ひとりではできないことでも、複数人ならできる」ことに尊さを感じています。 抽象的な話になりますが、日々議論し、それを形にしてアウトプットし、目に見えた結果として返ってくるというのは、ある種の創作行為だと私は思っています。 そこに対して産みの苦しみ・喜びみたいなものを、ひとりでなにかするときよりも大きく感じられるところが、ステークホルダーの多さに面白さを覚えるポイントなのかもしれません。 こういった面白さが、ぼく（ら）がPMMをやる理由です。 おわりに あくまでも「私個人の」「BASE BANKにおけるPMM」の話ではありますが、PMMをやっている・やりたいと思っている方、PMMと働いている他職種の方などにとって、PMMという職種の理解が少しでも進んでいたら嬉しいです。 昨年のアドベントカレンダーでは、私以外のPMMがユーザーリサーチとABテストを実施してCVRを向上させた話を語ったり、担当プロダクトについて語ったりしているので、ぜひ今年のアドベントカレンダーとあわせてご一読くださいませ。 devblog.thebase.in devblog.thebase.in また、現在BASE BANKでは、エンジニアや事業企画といった職種の採用を行っています。この記事を読んで面白そうだなと思っていただけた方は、ぜひお気軽にご応募いただけたら嬉しいです。 open.talentio.com 明日は、私と同じくBASE BANK Divisionに所属している 大垣さん の記事が公開予定です！お楽しみに。