2023/03/23(木) ~ 2023/03/25(土) の日程で開催される PHPerKaigi 2023 へプラチナスポンサーとして協賛する他、BASE 株式会社に所属する 3 名のエンジニアが登壇します。 PHPerKaigi 2023 とは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 https://phperkaigi.jp/2023/ 弊社はプラチナスポンサーとして、当カンファレンスに協賛しています。 プラチナスポンサー一覧の左下にBASE株式会社のロゴ PHPerKaigi 2023は、オンラインおよびオフラインでのハイブリット開催となります。 セッションの内容について 02 ( @cocoeyes02 ) 2023/02/03 に約3年ぶりのメジャーバージョンアップデートであるPHPUnit 10がリリースされました。 3年ぶりということもあって、PHPUnit 9からの変更はとても多いです。 例えばPHPのrequireが7.3->8.1へと大きく変わったり、大量のクラスやメソッド、オプションが削除されたりなど・・・ 今回のトークではPHPUnit 10で何が変わったのか、時間が許す限り解説していきたいと思います！ 永野 ( @glassmonekey ) 最近注目のWebAssembly皆さん使っていますか？私は仕事ではまだです!! Frontendでの活用を始めとして、バックエンド含めて活用のシーンが広がってきたように感じます。 そんな状況なのでPHPerの私含めて少しでもWebAssemblyと仲良くなれるきっかけを作れたらと考えています。 今回の発表では 以下の内容になります。乞うご期待。 WebAssemblyがどのような技術なのかの紹介 ブラウザ上でPHPを動かすデモ そのために必要なノウハウ Futoshi Endo ( @Fendo181 ) 遠藤です。PHPerKaigi 2023の3日目にLTで登壇します。 タイトルは「PsySHを使った効率的なデバッグ方法について」です。 PsySHはPHPで作られたREPL (Read-Eval-Print Loop) でインタラクティブに変数の中身やクラスのオブジェクト中身を見る事ができます。 bobthecow/psysh: A REPL for PHP 普段PHPでデバッグをする時には var_dump や echo などを使うと思いますが、 PsySH を使う事でより効率的にデバッグする事が可能です。その理由が伝わるようにこの発表では以下の内容でLTをする予定です。 PsySH について簡単な紹介 具体的なインストール方法と使い方について紹介 PsySH を使ったデバッグ方法についてTipsを紹介 最後に さて、ここまで読んでくださったみなさまのために、PHPerチャレンジ用のPHPerトークンを書きます。 PHPerチャレンジはPHPerトークンを探してスコアを獲得し、そのスコアの合計を競う全員参加型の企画です。詳細はPHPerKaigi内でのアナウンスを聞くか、パンフレットをご覧ください。 PHPerトークンは #payment_to_the_people_power_to_the_people になります。 少し長いトークン名になりますが、BASE株式会社のミッションである「Payment to the People, Power to the People.」をトークン名に採用させていただきました。 また、PHPerKaigi 2023 の当日のチケットは下記よりお申し込みいただけます。 https://www.eventbrite.com/e/phperkaigi-2023-tickets-454900217797 それでは、みなさまにお会いできることを楽しみにしております！

初めに こんにちは。フロントエンドエンジニアの竹本です。 入社してそろそろ4ヶ月が経とうとしています。だいぶBASEの開発にも慣れてきました。 この記事では私が社内の静的アセットを管理しているリポジトリ(以降は便宜上 static-repository と呼びます)のNode.jsのバージョンを12から16にあげたら、webpack dev serverの立ち上がりが約12分から約5秒に短縮できた話を紹介したいと思います。 この作業は業務の隙間時間でやったのですが、どのように取り組んでリリースまで持っていったかをお伝えできればと思います。 結論3行 webpack dev serverの立ち上がりが遅かったのはApple シリコン搭載のMacでNode.js 12を動かしていたから。 Apple シリコン搭載のMacでNode.js 15未満を動かすと、rosetta経由になり非常に遅くなる。 Node.jsのバージョンを上げようとしたら、それなりに大変だった。 話の始まり 事の発端は私がBASEに入社して約2ヶ月ほど経ったときの事でした。その頃私はBASE10周年プロジェクトにアサインされ、 10周記念特設サイト の開発・リリースを担当することになりました。と言ってもWebサイト自体の制作自体は別の方が担当されるので、やることといえば成果物に対して既存のビルド処理を通してコンポーネント等を差し込み、リリースに備えて準備を行う程度のものでした。 ※ 余談ですが 10周記念特設サイト はリリース後、 Web Design Clipさんにも取り上げられました。 とても素敵な仕上がりになっているので、よければ一度ご覧になってください。 特設ページは基本的に static-repository で管理されており、静的ページにビルド処理を通して独自のコンポーネントを差し込んだりmetaタグを追加することができるようになっています。 特設サイトのソースコードを受け取った私はそれを static-repository に移して、webpack dev server起動コマンドの yarn run dev を実行、、、しますがローカルサーバーが立ち上がりません。あれ？？？と思いながら何度か同じコマンドを叩きますが、どうやらローカルサーバーが立ち上がらないわけではなく、 立ち上がりが非常に遅くなっているようでした。 static-repository は静的アセットを管理するだけのリポジトリなので、メンテナンス頻度はあまり高くなく考えられる原因はいくつかありましたが、この時の私は納期が迫っていましたし、立ち上がりが遅いだけでエラー等は起こってなかったのでとりあえず作業を完了させることにしました。10周記念特設サイトは無事にリリースされ反響も大きく、プロジェクトは大成功でした。 それから2ヶ月ほど経って、BASEのフロントエンドエンジニアが有志で集まって負債解消に取り組む frontend-yatteiki という集まりに参加させていただくことになり、そこでずっと気になっていた static-repository 遅い問題に取り組ませてもらうことになりました。 やったこと まずは現状の調査から始めました。 yarn run dev を実行してからローカルサーバーが立ち上がるまでの時間を測定したところ平均して12分くらいかかっていました。遅くなっている原因をざっとコードを眺めて探ってみましたが、 .node-version で指定されていたNode.jsのバージョンが12.14.1と非常に低いことが気になりました。 なので雑にNode.jsのバージョンをLTSである16まで上げるところから始めることにしました。 .node-version を16.18.0に書き換えて yarn install を実行すると以下のようなエラーが出力されました。 1 warning and 1 error generated. make: *** [Release/obj.target/binding/src/binding.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/XXXXXX/XXX/XXXXXXX/XXXXXX/static-repository/node_modules/node-gyp/lib/build.js:262:23) gyp ERR! stack at ChildProcess.emit (node:events:513:28) gyp ERR! stack at Process.ChildProcess._handle.onexit (node:internal/child_process:293:12) gyp ERR! System Darwin 21.6.0 gyp ERR! command "/Users/XXXXXX/.nodenv/versions/16.18.0/bin/node" "/Users/XXXXXX/XXX/XXXXXX/XXXXXX/static-repository/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library=" gyp ERR! cwd /Users/XXXXXX/XXX/XXXXXX/XXXXXX/static-repository/node_modules/node-sass gyp ERR! node -v v16.18.0 node-sass のビルドでコケているようです。node-sassのバージョンは 実行環境のNode.jsのバージョンに大きく影響を受けます。 なるほど、これがNode.jsのバージョンを上げにくくなっていた原因かもと思いました。しかし static-repository は直接 node-sass に依存してなかったので yarn why node-sass でどのライブラリが node-sass に依存を持っているか調べます。 ❯ yarn why node-sass yarn why v1.22.19 [1/4] 🤔 Why do we have the module "node-sass"...? [2/4] 🚚 Initialising dependency graph... [3/4] 🔍 Finding dependency... [4/4] 🚡 Calculating file sizes... => Found "node-sass@4.12.0" info Reasons this module exists - "base-kit#gulp-sass" depends on it - Hoisted from "base-kit#gulp-sass#node-sass" base-kit が依存している gulp-sass が node-sass に依存しているようです。 base-kit はBASEの社内ライブラリのようですが、今まで見かけた記憶がありません。調べたところ base-kit はフロントエンド開発の便利ツールを集めたライブラリとして過去には存在していましたが、数年前にメジャーバージョンが上がる際に bbq としてUIライブラリに生まれ変わっていました。困ったことに static-repository は base-kit の依存がそこそこあり、その中には base-kit をアップデートして bbq にすると削除されてしまうモジュールもありました。 どうして... ということで、頑張って base-kit への依存を剥がしていきます。 base-kit をアップデートして bbq の最新版にし、 node-sass を使っているところは dart-sass に置き換えていきます。この移行はビルド設定ファイルの変更はほとんどありませんでしたが、webpackのビルド時にSCSSのコンパイルで新しくエラーが出るようになったので、そこも一通り対応していきます。 bbq にアップデートすると消えてしまうモジュールに関してはコード量がそこまで大きくなかったので、コピペでそのまま持ってきます。 その他、軽微な修正をいくつか行なって yarn install を実行するとNode.js 16でインストールに成功しました！ yarn install 自体もかなり速くなってました。そのまま続けて yarn run dev を実行するとwebpack dev serverが数秒で立ち上がり、表示崩れ等もない状態でした。 static-repository はdevelop・masterブランチに新しい変更が加わればCIでビルド処理を行なって、成果物を自動的にS3に上げることが役割なので、ビルドが通ることとビルドの成果物が期待通りの状態になっていれば問題ないという考えのもと、ステージング環境で再ビルドされたものを入念に動作確認をして本番リリースしました。 リリースから数日の間はCIでエラーにならないか気を配っていましたが、2回ほどCIが落ちることがありヒヤリとしました。しかし、いずれもNode.jsのバージョンを上げたことが直接の原因ではなく、すぐに安定稼働してくれるようになったのでそこでようやく一安心することができました。 なぜstatic-repositoryが遅くなっていたのか たまたまNode.jsのバージョンアップをしたら動作が爆速になったので、てっきりNode.jsのバージョンが古かったことが遅くなっている原因だと思っていました。しかし、PRを作り始めた時にCTOの川口さんから以下のようなコメントを頂きました。 なんと！思っていたこととちょっと違っていました。 私は業務でしかM1 Macを使っておらず、プライベートでは基本的に最新版のNode.jsしか使っていないため全く気付きませんでした。他の方がIntel Macで試してみたところ、Node.js 12でも快適に動作したとのことだったので static-repository が遅くなっていた直接の原因は Apple シリコン搭載のMacでNode.js 15未満を動かしていた からでした。 後になってから知ったのですが、元々BASEではM1 Macbookを導入する際にCTOや基盤チームの方がM1でも開発できるよう開発環境を整備して下さっていました。BASEの主要リポジトリはその時にNode.jsのバージョンが引き上げられていましたが、更新頻度の低い static-repository は取り残されていたというのがこの話のオチになります。 やってみて得られた知見やBASEのいいところ バージョンアップ対応は溜め込むと大変 今回の事例でいうと static-repository が base-kit に依存しており、 base-kit が node-sass に依存し、 node-sass がNode.jsのバージョンに依存しているという構造になっていました。そのため、Node.jsのバージョンを上げるためにはコードを読み解いて依存関係を理解しつつ、一つ一つエラーを潰していく作業が必要でした。ライブラリ等のバージョンアップをしないでいると古い依存関係の上に新しい依存が作られていくことになるので、改めて日頃から依存ソフトウェアのバージョンを上げていくことの大切さを実感しました。 やらないといけないことはやっていく必要がある Webサービスを提供している事業会社はどうしても新機能の開発や既存機能の改善をしていくことが優先されます。それはユーザーに新しい価値を届けるためにとても大切なことですが、一方でプロダクトをより堅牢に, より速く変えていけるようにすることも同じくらい重要です。ライブラリのバージョンアップはまさにそういった作業の第一歩だと思うので、積極的に上げていきたいなと思いました。 BASEは「いつかやらないといけないこと」にも取り組めている BASEは創業10周年を迎え、会社もサービスも大きくなりましたが同時にやり残し・積み残し作業も数多く存在しています。ですがBASEはサービスを成長させていくのと同時に「いつかやらないといけないこと」についても今取り組んでいこうという空気を強く感じていますし、実際かなり取り組めていると思います。 今回私が参加した frontend-yatteiki ではプレイヤーとしてのフロントエンドエンジニアの他にフロントエンド領域に明るいセクションマネージャーの方や基盤チームの方も参加されており、BASEの負債や開発上の課題について活発に議論が行われていたりプロジェクトとは関係のないPRが出されていたりしています。BASEで責任ある立場にいる方がこういう問題に積極的に取り組んでいることは、開発チームとしてとても良い状態だと思いますし、私自身も何かしら貢献がしたいと思えるようになりました。私が入社する前の事例を見ても入社歴が長くないフロントエンジニアの方がVue.jsのバージョンを上げたりビルドパイプラインを改善したりと自発的に課題解決に取り組んでいる様子がslackから伝わってきて、非常にいい刺激をもらいました。 終わりに 今回は社内リポジトリのNode.jsのバージョンを上げた事例を紹介させていただきました。依存ソフトウェアのバージョンを上げていくことはとても大切です。社内にはたくさんのリポジトリがあり、中にはあまり頻繁にはメンテナンスされていないものもありますが、自分が関わったリポジトリに関しては来た時より綺麗な状態にしていけるよう努めていきたいですね。

はじめまして、2023年1月4日に入社しました遠藤( @Fendo181 )と言います。 所属は Cart Dev というチームでバックエンドエンジニアを担当します。 Cart Dev チームはBASEの決済開発を担当しているチームになり、主にショップオーナー様や購入者の決済、カート機能周りの開発を担当しています。 入社してそろそろ1ヶ月経つタイミングですのでこの記事では初リリースまでに行った事や実際にBASEに入社してから経験した事をご紹介します。 初リリースできるまでに経験した作業内容について 自分がはじめてリリースした機能は、ある処理が完了した際のログを追加する軽微な変更でした。 以下に入社してからリリースするまでに行った具体的な作業内容を時系列順にご紹介します。 (1)GitHubやOneLoginなどの業務で使うアカウントを作成する (2)オンボーディング用のドキュメントを参考に作業内容を確認する (3)BASEでショップを開設しながらサービスの仕様を把握する (4)開発環境を構築する (5)具体的な作業内容をメンターの方と相談しながら実装する (6)PullRequestを作成してDevelopment環境にデプロイする (7)Development環境で検証後に問題なければメンターやチームメンバーにレビューをしてもらう (8)レビュー後にApprovedを貰ったらPullRequestをマージしてStaging環境にデプロイする (9)Staging環境で問題なければProduction環境にリリースする (10)Production環境に動作確認をして問題ないか確認する 上記で紹介した作業以外にも PhpStorm の設定や、アーキテクチャの方針や、ドメインモデル図の紹介だったり細かい作業もありました。 紹介した作業の中で自分が特に掘り下げて説明したい内容は以下の2つです。 (2)オンボーディング用のドキュメントを参考に今後の業務内容を確認する (3)BASEでショップを開設しながらサービスの仕様を把握する オンボーディング用のドキュメントがとにかく充実している オンボーディング用のドキュメントには組織図の紹介からチームメンバーのプロフィール、グループでの活動、開発に入るまでの準備等、作業内容が丁寧に記述されていました。 また、Slackでオンボーディング専用のチャンネルが出来ておりドキュメントを読んでも分からない事があったとしてもチャンネルで質問をなげるとすぐにメンターやチームメンバーからフォローが入り1人で悩むというのが無かったです。 また、オンボーディング期間中は上長と1週間に1回、1on1のMTGで作業の進捗具合を相談する機会があります。 この時に「30days入社モニタリングシート」というのを使って進捗を確認するのですがオンボーディングで想定している作業と実際に行っている作業で大きな差が生じないよう1つ1つ状況を確認しながら相談にのっていただいたのが良かったです。モニタリングシートを使ってのふりかえりを行う事で次の1週間の動きが明確になり安心して業務に集中する事ができました。 このようにオンボーディング用のドキュメントが丁寧にまとまっていたり、30days入社モニタリングシートが用意されている等、BASEでは リモート環境で入社してもすぐに会社の環境に慣れる配慮 がされているのが個人的に素晴らしいと感じました。 オンボーディングについては Owners Marketing チームの竹本 さんが書かれた記事もあるので是非こちらもご覧ください。 devblog.thebase.in BASEでショップを開設しながらサービスの仕様を把握する BASE社内ではこの研修の事を「プロダクト習熟トレーニング」と呼んでいます。 この研修の目的は「新入社員・中途入社・業務委託向けに、BASEのプロダクトに対する理解を深めてもらう。」というコンセプトで用意されています。 最初にBASEでアカウントを作って商品を登録したり、Appをインストールして実際にショップ作成を体験する研修になりますが、作業内容がとにかく細かく書かれております。 以下に実際の作業内容をご紹介します。 商品を登録する。 商品にカテゴリを設定する。 １つの商品ページ内で、種類（Sサイズ、Mサイズ、Lサイズ）を登録する。※サイズごとに値段の変更は不要 登録済みの商品を複製して、別の商品を登録する。 登録している商品を一括で非公開にする。 登録している商品を任意で選択し、同時に削除する。 登録している商品を全削除（一括削除）する。 CSVで複数の商品を同時に登録する。 CSVで複数の商品へカテゴリを同時に登録する。 ... これは一部分で他にも同様なステップが続きます。 自分は空き時間を活用しながら作業してたのですが2~3日程かけて終えました。 この研修の素晴らしい所はただショップを作成して終わりではなく作成しながら「改善したい所も書く」というのがあり研修を通じて サービス利用者側から当事者側への意識 に変わりました。 開発業務外で経験した事について 次に開発業務外でBASEに入社して良いと思った文化や制度についてご紹介します。 Uniposで褒め合う文化について BASEでは Unipos という従業員同士が感謝したい事やお礼を伝えたい時に少額のインセンティブを贈り合うことができるサービスを活用しています。 自分が機能を初リリースする際にもこのサービスを使ってメンバーからポイント貰い嬉しかったのですが、相手への感謝の気持ち気軽に伝えられるのが個人的には素敵な取り組みだと感じました。 メンターランチ制度を使って他部署の方と交流する メンターランチ制度とはBASEに入社された方がいち早く会社に馴染んでいただけるようランチ代の補助する制度になります。 詳細は BASE Book でもご紹介していますのでご覧ください。 basebook.binc.jp 普段仕事していると自分が所属しているチームメンバーとの交流がメインになるのですがこの制度を使う事で他部署のエンジニアやグループマネージャーの方と交流できるきっかけになり良かったです。 まとめ 自分がBASEに入社して初リリースするまでに経験した内容をご紹介しました。 オンボーディング用のドキュメントが充実している事やメンターランチ制度が揃っているなどBASEではリモートで入社してもすぐに組織に馴染んで開発に集中できる環境が整っていると感じました。 またこの記事では紹介できなかったのですが頻繁に社内で読書会が開催されたり、ブロク記事や勉強会への登壇を推し進めるチャンネルがあったり組織の中で活発にインプットとアウトプットに取り組んでいる事も素敵だと感じました。 この記事を読んでBASEに興味を持った方は Youtube 、 BASE Book でも事業内容や現在取り組んでいる内容についてご紹介していますのでご覧ください。 この記事を読んでBASEに少しでも興味を持っていただけると幸いです。 読んでいただきありがとうございました。 binc.jp

はじめに この記事は BASE Advent Calendar 2022 の25日目の記事です。 CTOの川口 ( id:dmnlk ) です。 毎年技術ブログチームに勝手に組み込まれています。 タイトルと画像が一致してないのはデザインテンプレに合わせづらかっただけなので気にしないでください。 BASEでのエンジニアリングマネージャーについて エンジニアリングマネージャー(以下EM)は各社によって定義が分かれていることと思います。 どこに責任を持ってもらうか、という点が異なっており下記エントリーがまとまっていてわかりやすいです。 yigarashi.hatenablog.com BASEにおいてはEMは主にピープルマネジメントとデリバリマネジメントに責任を持ってもらっています。 ピープルマネジメントには採用も含んでいたりするのではないでしょうか。自分のチームの補強はEM自らが主体で採用していくということですね。 テクノロジーマネジメントはテックリードとCTOの僕がマネジメントしている構造となっています。プロダクトマネジメントに関しては、VPoP率いるチームが持っています。 EMがエンジニアのキャリアとしてどう捉えられているか 最近ではようやくEMがエンジニアキャリアと1つとして道筋になってきていますが、どうしても技術を伸ばすことを諦めてしまうといった捉え方をされることを聞くことが多いです。 実際のところ、BASEのEMが最先端の技術を検証したりバリバリとプロジェクトのコードを書くということは行っていません。 そういう点を見聞きしてしまうとEMはエンジニアのキャリアから外れてしまうという印象が出てしまうということなのだと思います。 ですが自分はそうは思っていません。 自分は人や組織はシステムアーキテクチャの1つというか同じであると考えています。 人というコンポーネントをどのように配置し、どのように相互作用してアウトプットを増やして開発をスケールさせていくかを考える必要があります。 人間はとてもグローバル変数が大きいのでいつでも同じアウトプットが出るものではそこも考慮する必要があります。 これら複雑な要素をうまくコントロール、ハックし、BASEという1つの大きなシステムアーキテクチャを運用していくことは疑いようもなくエンジニアリングといえるでしょう。 組織をシステムアーキテクチャと捉えたときのEMの役割 上記の事を踏まえたとき、EMの役割は何になるかと言えば所謂テックリードやシステムアーキテクトになるのではないでしょうか。 チームをリードしアウトプットを改善していくことが求められます。 時にはメンバーにハードなコミュニケーションをしてでもアウトプットのブロッカーをなくしていく必要もあります。 従来のやり方だけでは問題がある場合には、今までチームで取り入れていない技術要素（例えばスクラムの導入など)に取り組むこともあるでしょう。 チームという単位のマイクロサービスのようなもの(あくまで比喩です）をEMが運営し相互作用しそれら全体の設計や流れをコントロールすることがCTOたる自分の重要な責務の1つであります。 おわりに これからのキャリアに悩んでいるエンジニアの方にはEMにあまりネガティブな印象を持ちすぎず、新しいエンジニアリングに取り組むという気概を持ってエンジニアリングマネジメントにチャレンジして欲しいと思っています。 そして改めてここでいうことではないですが、BASEのEMの皆様は自分達がシステムアーキテクト、テックリードとしてチームというシステムをよりよく運用していけるように頑張ってください、よろしくおねがいします。 今年もBASEアドベントカレンダーをご覧いただきありがとうございました。 2023年もこのブログを積極的に更新していく予定ですのでご覧いただければ幸いです。

はじめに この記事は BASE Advent Calendar 2022 の25日目の記事です。 devblog.thebase.in はじめまして、BASE株式会社で執行役員 VP of Productをしている神宮司 ( id:h7jin16 )と申します。 メリークリスマス！アドベントカレンダーも最終日です。皆さま仕事納めはできたでしょうか？ BASE株式会社は今年で10周年を迎えたアニバーサリーイヤーでした。自身もBASE株式会社で働き始めて9年経ちます。今回は9年間の社会人経験を経て大切だと思ったことを4つ紹介させてください。 個人的なものなのでお役に立てるかは分かりませんが読んでいただけると嬉しいです。 想像力は大切 ユーザーさんが抱える課題に対しての想像力だったり、誰かとコミュニケーションをするときの想像力だったり、何かを計画するときの想像力だったり。とにかく生きていくうえで想像力は一番大事だと感じています。 想像力の欠如によって誰かを傷つけてしまうことや不要なアクシデントを招くこともあり得ます。さまざまな人のことを想像して適切な行動ができる人になりたいです。 常に意識を向けて日々を過ごす 職業柄自身が体験したことに対して「いい体験」 or 「悪い体験」のラベルを脳内で貼って過ごしています。 例えば、電車に乗ったとき、タクシーに乗ったとき、食事をしたとき、歯を磨いたとき、ボタンを押したとき...etc。なぜ自分は「いい体験」だと感じたのか、なぜ「悪い体験」だと感じたのか。 誰かと同じものを見ていても意識を向けている事柄によって受け取れる情報は人それぞれ違います。 信頼関係を築く 信頼があるから期待され、その期待に応えることでさらに信頼をされる。そんなループによって新たな機会を得ることができます。 信頼は一朝一夕では築くことができませんが失うことは簡単です。日々の所作によって信頼を築くこともできれば失うこともできます。自身も完璧には程遠いですが少しでも信頼を築けるように過ごしていきたいです。 アウトプットが重要 情報化社会なのでインプットの機会は得やすいです。知らないことがあったらAmazon、Google、SNS、ChatGPTに聞けば知ることができます。すごく便利で有り難いですが、個人的なくせとして、アウトプットよりもインプットのほうが楽なのでインプットに逃げてしまいがちです。 アウトプットするのは本当に辛く、解決しなければいけない面倒なことがたくさん起こります。しかし、アウトプットをしなければ何も起こりません。インプットはアウトプットのためにあります。 アウトプットをしなければ得られないインプットもたくさんあり、それこそが重要だったりします。なので意識的にアウトプットの機会を増やしていきたいです。 おわりに 読んでいただきありがとうございます。 今年からBASE DESIGNERブログも始めています。デザインチームもいろんな情報を発信しているので覗いてみてください note.com 今後も個人・スモールチームの経済活動をエンパワーメントしていくために精進します。BASE株式会社は次の10年に向かってより進化していきます。一緒に次の10年を作れるかたを探しているのでご興味あればぜひご応募いただけると嬉しいです。 binc.jp 引き続きBASE株式会社をよろしくお願いします。良いお年を！

はじめに この記事は BASE Advent Calendar 2022 の24日目の記事です。 devblog.thebase.in はじめまして。岡部（ @rerenote ）と申します。2022年6月にエンジニアリングマネージャーとして入社し、8月からPay ID Dev Groupでマネージャーを務めています。今回は購入者向けショッピングサービス「Pay ID」の開発組織について、マネージャーとして私が考えていることも少し織り交ぜながら紹介していきます。実用性というよりはパッション多めの内容でお送りします。 「Pay ID」と「Pay ID Dev Group」 ショッピングアプリ「BASE」とID決済サービス「PAY ID」を統合・刷新して2021年11月30日に提供を開始した購入者向けショッピングサービスが「Pay ID」です。「ネットショッピングの体験をより良くする」ことをミッションに掲げ、購入者が好きなショップや好きなモノとつながり続けられる関係構築の支援、ストレスフリーな決済体験の両方を提供するべく企画、開発、運用を行っています。統合前の2つのサービスの歴史があるため会員数こそ多いものの、現在の形になってからは1年強と歴史は短く、サービスとしてはまだまだ作り込みが必要という段階にあります。 Pay IDの開発組織である「Pay ID Dev Group」はPay IDのミッションを技術で実現するための組織です。具体的にはPay IDのスマートフォンアプリ、決済サービス領域の開発、運用を行っています。iOSエンジニア、Androidエンジニア、バックエンドエンジニア、フロントエンドエンジニア、エンジニアリングマネージャーが所属しており現在は約20名という規模です。 Pay IDのプロダクト開発スタイル プロダクト開発は主にプロダクトマネージャー、デザイナー、エンジニアでチームを組んで進めています。これから事業を伸ばしていくぞという段階にあるため、きっちり分業しています！ということはやっておらず、それぞれの専門領域で素案をつくり、チームで議論をしながら仕様や設計を決めていくというやり方をとっています。 「スクラムです」とか「アジャイルです」というような表現を用いていないのは、プロダクトに合った開発スタイルを試行錯誤しながらチームで発見していくこともプロダクト開発の一部だと思っていること、また、次で述べる特徴もあり、全チームこのやり方で進めています、とすることはないのかなという私の考えに基づいています。 システム運用についても安心して使っていただけるように、どういう体制でどのように実現していくかを設計して実行していく必要があってまだまだ未着手のことが多い。本当にこれから育てていくプロダクトとチームなんだなぁと痛感することが多いです。 開発組織運営視点でのPay IDのおもしろさと難しさ Pay IDというサービスは性質の異なる要素を内包しているため、異なる要素同士がいい感じに協調して1つの事業としてまとまりを出すことを意識して組織設計や採用要件等を決めています。サービスに対する解像度をできる限り高めた上で要素分解し、共通すること、共通しないことに分けた上で複数のチームに分割し、チームごとに味付けを変えていくイメージです。性質の異なる要素については下記のようなものがあると考えています。 「購入者」と「ショップオーナー」 Pay IDは購入者向けのサービスですが、実はPay IDのユーザーは購入者だけではありません。Pay IDでお買い物ができるショップは、ネットショップ作成サービス「BASE」で作成された自社ECのショップであり、ショップオーナーもユーザーです。プロダクトに機能という形で新しい価値を追加していく際には「購入者」「ショップオーナー」という違う立場と視点を持っているユーザーの両方を想像しながら取り組む必要があります。BtoCとBtoBの2つのビジネスモデルが同居しているようなイメージです。 「ショッピングサービス」と「決済サービス」 決済サービスは「メリットがある、便利だからこれを使おう」という理由が主になってくるもの。ショッピングサービスは「こういう買い物ができるからここで買おう」という理由が必要になってくるもの。特にPay IDでは「好きなショップ、好きな商品とつながる」ことを大事にしており「楽しくショッピングしてほしい」という想いと、「ストレスフリーに決済できるようにしたい」という想いがあり、目的が違うものが同居しています。 「スマートフォンアプリ」と「システム」 私自身の過去のエンジニア時代の肌感覚によるものなのでふんわりとしており伝えるのが正直難しいですが、感じていることをそのまま書いてみます。スマートフォンアプリを開発する際は、複数の機能群を有しながら1つのまとまった世界観を表現するように作るような感覚。システムについては機能群そのものを表現しており、それ自体が1つの世界を表現する感覚というよりは、複数のものが1つの船に乗っていますという感じ。あくまで個人の感覚ではあるのですが、このような違いを感じています。 Pay ID開発組織の現状とマネージャーとして考えていること サービス・プロダクトもこれからだし開発組織もまだまだこれから成長するよ、という段階です。 ネットショッピングの体験をより良くするために改善、変化を積み上げながらアプリやシステムを育てていく ユーザーを取り巻く環境の変化にアンテナを張りながら、長く愛されるサービスになるようプロダクトをメンテナンスしながら育てていく 上記を継続的に実行していくために、仕組みやカルチャーを自分たちの手で作っていく過程にあります。開発スタイル同様、課題解決についても試行錯誤を繰り返しながら前に進み続けることをしている状況です。 マネージャーとしての個人的な想いとしては、サービスや事業が成長することはもちろんですが「作り手が楽しいと感じながら開発をしている」というのも大切にしたいというのがあります。楽しさを感じるポイントは人によって異なるので実現が難しいことではありますが、「持っている力を駆使しながらなんかいい感じにうまいことやる」のがマネージャーとして求められることなので、1つ1つ試行錯誤しながらチームもサービスも変化させていければと思っています。 また、Pay IDのプロダクトチームについても社内では比較的規模が小さく、開発組織同様これから成長させるぞー、とやっている状況です。このような記事もありますので、あわせて読んでいただけると嬉しいです。 devblog.thebase.in note.com さいごに ほんの一部ではあるのですが、私個人の考えていることも織り交ぜながら、Pay ID開発組織の紹介をさせていただきました。歴史が短い分、課題も多いですが、1つ1つ向き合いながらグループ自体もなんかいい感じになるようやっていくのでどうぞよろしくお願いします！ 今回紹介したPay ID Dev Groupでは現在エンジニア（iOS、Android、バックエンド）を募集中です！興味あるかも？と思った方はぜひ一度お話を聞きに来ていただけるととても嬉しいです！！ A-1.Pay ID_バックエンドエンジニア / BASE株式会社 募集一覧 / BASE株式会社 募集一覧 / BASE株式会社 明日はアドベントカレンダーの最終日です。 CTOの @dmnlk とVP of Productの @7jin16 の記事が登場する予定です。乞うご期待ください！

はじめに はじめまして．経営戦略室の林田（@Linda）と申します． こちらは BASEアドベントカレンダー の23日目の記事です. 本記事では、今年1月に立ち上がったCEO鶴岡（@yt）直下のチームである 経営戦略室（Corporate Strategy Unit；略してCSU）について、立ち上げ時からの活動と、進める中で意識していたポイントを紹介したいと思います！ 経営戦略室（CSU）とは 一般的には「経営企画」と呼ばれ、企業の中長期の経営戦略の策定や、新規事業の創出検討などを行う組織機能・職種に分類されますが、実際の業務分掌や組織上の位置づけは各社様々です． 立ち上げ当初、初期メンバーとして参画した岩田（@joe）や鶴岡とともに、「そもそも経営戦略室、何をしようか？？」の議論から始めました． 侃々諤々の議論を行い、 経営戦略室は、「BASEをみんなで"より速く”、"より遠く”」へ導く「CEOの拡張機能」 として、目指す方向を定めました． ＜出所: 経営戦略室作成＞ ”より速く”、”より遠く”へ向かう先≒CEO機能としてコミットするものは何か？ 色々なステークホルダーの方がいらっしゃり、沢山の観点がありますが、1つと言われれば 「ミッション」である「Payment to the People, Power to the People.」の実現 です． ＜出所： コーポレートサイト ＞ ミッションの実現が全てで、これ以外は極論全て手段です． この立場に立つと、極端なことを言えば事業もプロダクトも、KPI管理も組織も全てが手段です． その時々で、ミッション実現に向けて解決すべき優先度の高い経営イシューは何か？ これを中長期観点で考え抜き、アプローチ（打ち手）を検討します． この打ち手候補には、最善解なのであれば心持ちとしては全ての選択肢が含まれます． 極論、経営戦略室が開発をやるべきなら開発をする、営業活動が必要ならする、採用活動をすべきなら採用活動を率先して進める． 限られた経営資源を踏まえ、中長期的な観点も考えてミッション達成へ向けた最善手だと判断すれば、論理的にはこれらの手段も取り得ます． しかし、 BASEには、ミッションに共感する各領域のプロフェッショナル・スペシャリストの仲間がたくさんいます． 1つの組織機能でできることは物理的に限界がありスケールが難しく、経営戦略室単体で閉じる・依存する傾向にある打ち手候補が最善手になることは少なく、 「中長期的なスケーラビリティ」が判断軸 の1つに入ることがほとんどです． ミッションの実現に向けて、 マクロ環境や未来・将来を考えて、つまずきそうなものがあれば先回りしてその障壁を特定し、取り除きにかかる． その障壁を取り除くために、必要な経営機能の獲得や習慣のインストールに資する活動、それらがスケールする仕組み・ルールを考える． 最終的には、各経営機能が有機的に連携し、優先度の高い経営イシューを特定し、解決に向けて自発的に推進・協議され、数多くの打ち手候補の中から最善手が打たれるPDCAが回る状態を目指す． 経営戦略室の最終目的は「経営戦略室がなくなること」 だよね、と立ち上げたばかりではありましたがメンバー間でも話をしています． これが経営戦略室チームです． 今年1年の振り返り チームの方向性を決めた4月以降 高橋（@Nao.takahashi）や米田（@aipon）もチームに加わり、 今年一年で色々な取組・活動をしてきましたが、本記事ではその一例として3つ簡単に紹介します． 【① 各部門との協働検討推進】 まずは「仲間を知り、共に走る活動」から始めました．BASEの組織は、経営戦略室以外に ネットショップ作成サービス「BASE」を管掌するBASE事業に加え、 購入者向けプロダクト「Pay ID」や決済・金融領域のプロダクト「BASE BANK」・「PAY.JP」を担うNEW Div.、 全社のサービス情報セキュリティを担うIT Strategy Div. グループ全体のコーポレート機能を担うCorporate Div. が存在しています（22年10月時点）．各部門のマネージャー中心に議論を行い、その内容を元に各経営課題の抽出を行ったり、解決に向けたアプローチの検討案を一緒に考えたりしてきました． ＜出所： BASE会社紹介資料 ＞ 【② 経営会議のガイドライン設計】 経営会議は、全社の重要事項の意思決定機関の1つであり、まさに経営イシューが議論される重要な機能です． BASEでは、経営の意思決定のプロセスの可視化やその姿勢として議事録を原則公開しているのですが、 どうすればよりよい意思決定につながるか、会議の在り方自体を経営陣で議論し、ガイドラインを定めました． 例えば、資料は事前提出＆参加者は前もって資料を読んで会議に臨むこと、と記載されており、 まだまだ試行錯誤中ではありますが、これにより質が高まってきていると感じています． *内容イメージ; 推奨アジェンダや会議参加に関するスタンス等が記載されています． ＜出所：経営戦略室作成＞ 【③ 中長期経営戦略の検討推進】 CEO機能の最重要テーマといっても過言ではない中長期経営戦略の策定・具体化、にも足元取り組んでいます． 各種現状を踏まえて、 ミッション・行動指針のレベルから、改めて経営陣で意味解釈やマインドを揃える その上で、これからのマクロ環境に関する見立ても立てながら、ミッション実現に向けたBASEグループ全体の企業戦略を議論する 上記を踏まえて、各プロダクト戦略やその実現に必要な組織ケイパビリティ獲得に向けた方針を議論する といったようなプロセスを経ながら、経営陣を中心に議論を重ねて検討推進を行っています． 進める中でチームとして意識していたポイント 経営戦略室チームとして検討を進める中でメンバー間で、 "チームとしてのマインドは揃っているか？" については、とても意識していました． 「ミッション」・「経営課題」・「事業戦略」・「組織」など抽象的な論点になりやすいトピックであるからこそ、 検討を進める際に、判断軸・議論の軸がブレないように、 些細な疑問点も、その内容や考え方自体のマインドのすり合わせ を行うようにしていました． 「マインドをすり合わせるためのTips」 として2点取組を紹介します． 【① チームミッションに紐づいた年間ロードマップと足元のOKR *1 設計】 BASEでは、クオーターごとに設定するOKRを活用しながら組織運営を行っているのですが、 足元のOKRがチーム方針に沿っているか、年間の活動方針に照らしたときにどの位置づけになっているか のすり合わせを各クオーターで行うことで、 期中に想定内容や進捗にGapが生じた際も、大方針・目的から逸れないような軌道修正が行える ようにしていました． ＜出所：経営戦略室作成＞ 【② 備忘メモチャンネルを活用した情報共有】 "普段の生活・仕事の中で生まれる些細な気になる点にこそマインドを揃えるヒントが有る” との考えのもと、そのチャンスを逃さないように、Slackの専用チャンネルを作り、 チャンネルのレスポンス義務なしで（投稿ハードルを下げる） 気になったニュースや、「これ議論したいな」と思った事項を備忘として投稿し、 その内容を日々のMTGや定例などで一気に共有して消化 をしていました．ちょっとした工夫と運用であるのですが、マインドも揃うし情報共有もできるし、おすすめです． 終わりに；僕たちの信じる未来 下記グラフはクリエイターエコノミー市場規模の将来予測ですが、 これからますます個人の力が経済的にも大きくなっていくことが予測されています． ＜出所： 三菱UFJリサーチ&コンサルティング株式会社 ＞ 22年12月11日、 BASE株式会社は創業10周年 を迎えることができました． これからの10年も、ミッションである「Payment to the People, Power to the People.」の実現に向けて、 ひとりひとりに眠る、想いが、感性が、才能が。 世界中の、必要な人に届くように。 そこから生まれる、作品に、アイデアに、活動に。 正当な対価を、受け取れるように。 ペイメントを、世界中の人へ解放する。 世界のすべての人に、 自分の力を自由に価値へと変えて 生きていけるチャンスを。 あたらしい決済で、あなたらしい経済を。 そんな世界の実現を信じて、個人やスモールチームをエンパワーメントする存在で有り続けたいと思っています． 以上、チーム取組紹介でした！ 明日は、岡部（@rerenote）さんの記事が公開予定です！お楽しみに！ *1 : OKRは、Objectives and Key Resultsの略称で、GoogleやFacebookなどシリコンバレーの有名企業が取り入れたことで近年注目を集めていると言われている組織の目標の設定・管理方法のひとつです．

この記事は、 BASE Advent Calendar 2022 の22日目の記事です。 同日公開の @02 の記事もぜひご覧ください！ こんにちは！BASEグループの新規事業 Pay IDでプロダクトマネージャーをしている坪内 ( @tsubo ）と申します。 12月で入社半年になるのですが、今更ながら入社エントリーを兼ねて、入社半年でチームでプロダクトマネジメントをしていくために取り組んだこと・意識したことをまとめたいと思います。 この記事では、主に事業多角化・マルチプロダクトにおける新規事業や新規プロダクトのPM、またチームを推進する役割として、働かれている方が対象の内容になります。 ⁠入社エントリー 改めて、22年6月にBASE株式会社に転職しました。 Pay IDという新規事業で、Pay IDチームでは2人目のプロダクトマネージャー（PM）としてジョインしました。 入社の軸は、PMとしてこれまでの経験を活かしつつ、新しいチャレンジをしたいという思いで、 ①（前職同様）BtoBtoCの事業で、2サイドに向けて価値を届けるプロダクト ② クリエーター（つくり手）とファン（購入者・支援者）のコミュニティ・コマース ③ 立ち上げで、出来上がっていない・自分が価値を発揮しやすい組織規模 という環境が、 自分の経験が活かせそうだ・関心を持てそう と感じました。 また分散化していくインターネット全体がモール化していて、購入前後の体験がすべて地続きであり、適した体験を届けていく価値を実感していたこと、スモールチームや個人のエンパワーメントや購入者としてのファン体験がユーザー目線で大切にしたいなど、 価値観が近かったことが決め手として大きかったです。 ▶ そのあたりのインタビュー記事は こちら やってきたこと さて、入社後半年間で、色んなことにチャレンジさせてもらっています！ 1〜3ヶ月目キャッチアップ プロダクトビジョンやプロダクトロードマップの言語化・可視化 社内コミュニティ（コーヒー部）の立ち上げ（ 詳細はこちら ） 2ヶ月目〜決済施策のPM ビジネスオーナーの高橋と一緒にBNPLのPJ立ち上げ と決済プロダクトのキャッチアップ 決済という領域から、全社横断PJだったこともあり、ステークホルダーとの関係づくりや共通理解づくり、全社に方針共有などリードとキャッチアップを並行する 5ヶ月目〜 チーム体制強化のため、PMチームのマネージャーに昇格 プロダクト全体の戦略や優先順位の判断など担うことになる FY23に向けた来年のプランニングを含め、事業方針やプロダクトのコア・戦略部分の定義・共通言語づくりをマネージャー中心に取り組むなど チームジョインして意識したこと 今回、新天地でリスタートするにあたり、「温故知新」というテーマで、これまでの積み重ねにリスペクトしながら、新しいことをつくっていく、ということを意識してきました。 新規事業の場合、非連続で新しい風を期待されることが多く、その期待のまま新参者が、課題をあれこれ定義・言及し、新しいことを提案するだけでは、なかなか共通認識/理解を作りにくく、結果的に到達したいところにたどり着けない、というのは、私自身の過去の失敗経験を踏まえて、よくあるアンチパターンかと思っています。 非連続な成長を狙い、早期にチームで推進していくために、これまでの経緯にリスペクトし、未来への想像を含む、共通言語化をつくり・つなげていきながら、チームでチャレンジできる方向性にいくことが、優先と考えていました。 似たようなお悩みをお持ちの方にとって、少しでもヒントになれば嬉しいです。 温故知新の『温故』 新規事業は、0からの立ち上げである、と同時に既存アセットの活用やチームが事業部として独立することで、既存事業とのシナジーを作っていく、という狙いで立ち上げるケースもよくあります。 その観点でPay IDという事業・プロダクト・組織において、 旧Pay ID（PAY ID）と旧BASEアプリの2つのプロダクトが統合したもの BASEのカスタマー領域のチームが事業部として独立した組織 BASEショップでお買い物をした購入者のアセットを活かす事業 新Pay IDとして21年冬にリブランディングして2年目 など、過去の経緯を踏まえた上で、まだ立ち上げていくというのも、新しいものをつくっていく・取り入れていく上で、重要だと考えます。 意識していること それを立ち上げフェーズのカオスな状況で、走りながら考え、作りながら言語化・共通理解をつくっていく中で、ブロッカーになることがあります。特に、過去のコンテキストについて、上記の状況から断片的な情報が多く、暗黙知や人によって尺度・観点が異なる理解というのが、キャッチアップや推進していく上での課題ではありました。 BASEグループとして、次の10年を見据えた新規事業をブレずに立ち上げきるには、当初の思想や狙い、当時の仕様や制約などを理解していくことが大切です。 中には未来に実現したいことと不整合になりえるものも少なくはないですが、「課題」や「べき論」の押し付けや過去の否定をするのではなく、それらを決めた人・作ってきた人たちへの敬意を持って、ヒアリング・ディスカッションしていくのが重要だと思います。 現状地点をドキュメントやFigjamなどで整理・定義しつつ、プロダクトビジョンやロードマップへの落とし込みも、その経緯や実態を踏まえた上で、物事を組み立て、理解していくのが大切だなと意識しました。 温故知新の『知新』 上記の通り、コンテキストを理解した上で、新しいことにチャレンジしていく上で、以下のような取り組みを行いました。 ①プロダクトビジョン・ロードマップの言語化 入社後の事業責任者や1人目PMと一緒に、プロダクトビジョン・ロードマップの言語化をチャレンジしました。抽象的・流動的な内容で、暗黙知、認識ズレなど起きやすいこともあり、以下の観点で整理をしてみました。 誰にどんな価値を届けるため、どんな世界を実現するのか？ プロダクト・ブランドとして、今後どんな戦略があって、なぜ独自決済（BNPL）に力をいれていくのか？ どのマーケットにどんな成長戦略で、どのポジションで、どのくらいシェアをつくりにいくのか？ これらを定義・整理し、PM内での共通言語はつくれてきましたが、残念ながらPay IDチーム内への浸透や活用という形には至っていませんでした。 ②事業責任者やマネージャーを含むチームオフサイト チームへの共通理解・浸透をするため、改めて「全社のミッション、事業・プロダクトの方針が 繋がってる状態」を目指して、事業責任者やマネージャーとオフサイトを通じて、チームでの対話や言語化を行いました。 KPIと企画・仕様とスケジュールだけではなく、「プロダクト全体像を理解し、施策をWhyから考えられる プロダクトチームに」という状態をつくりたいので、意思をもって、異なる職種とも共通理解で話せるテーマとファシリテーションで、あらゆる観点で議論や言語化をしました。 FY23-27の事業方針・計画素案 プロダクトのコアコンセプト 購入者・ショップオーナーからみた価値や体験、コアバリュー プロダクトの今後のブランドの方向性、何を大事にしたいか 市場におけるポジショニングと理想の状態 購入者・ショップオーナーを含め、社内外でどう認知してほしいか チームの一員としてこれからどうしたい？どうありたい？ 参加メンバーは一定の共通言語がつくれてきています。まだまだ誰もが分かる状態に、落とし込みができていないので、オフサイト後もメンバーへの普及や浸透・活用できるドキュメント整備、社内外の発信などやっていきます。 ③購入者向けの⁠ユーザーインタビューの仕組み化 BASEは、これまでオーナー向けに、 UXリサーチ を含め、ユーザー理解に力を入れてきましたが、Pay IDをはじめとする購入者向けのUXリサーチは、会社として初めてでした。 PMとして、「まず顧客を知ることが重要」と考えているので、入社後進めたい気持ちでした。特になぜ作るか？何を作るべきではないのか？どんな状況を避けるべきか？をチームで共通理解をもつために、自社プロダクトやコアユーザー特有の実態を掴んだ上で、組み立てるのは絵に描いた餅やビルドトラップを避ける上で重要です。 チーム内で読書会「 LeanUX 」という書籍を通じて、リーン思考のユーザー体験設計プロセスでプロダクト開発をしていきたい、という思いがあり、まだまだ実行まで落とし込めていないのですが、これからチャレンジしていきたいです。 これまでのリサーチでは、コアユーザーの利用実態を知るきっかけとして、ユーザー理解や初期仮説の検証が少しずつ始まっており、チームでユーザー理解や仮説検証を促進していきたいです。 ④改善フローの仕組み化・プロダクトチーム定例でプロダクトアップデートの共有機会 プロダクトチームが、継続的にプロダクトを良くしていけるための取り組みとして、改善のフローを改めて定義し、仕組み化しました。主に起票〜リリースまでのフローを定義し、要件ごとに優先順位や細かな要件決めを行う形にしました。 Pay ID チームの横の連携を強化して、プロダクトづくりをしやすくする ことを目的に、チーム定例を実施しており、そこで改善を担当したPMやデザイナー、エンジニアが発信する機会を持ちます。 Slack チャンネルで、プロダクトアップデートを担当したメンバーへの称賛をわいわいしながら行うことで、チームの連帯感や自信がついてくることを期待しています。 ⑤採用イベントや社内イベントでの縦横斜めの相互理解や発信機会づくり BASEは、今年の PMconf でBASEが協賛をしたことをきっかけに、PMの採用イベントなど、PM起点の社外への発信に取り組む機会が増えました。 PMconf内ではスポンサードチャンネル内で、合計20名以上のPMやEM、Bizなど各プロダクトリーダーたちのトークセッションを企画・運営。また開催後も、 採用イベント やプロダクトリーダーたちの社内イベントを企画運営する中で、PMやデザイナーの発信機会につながりました。 職種ごとのマネージャー主体で進行することで、発信機会やファシリテーションによって「普段は話さない、みんなが知らないこと」を、事業部横断でプロダクトに関わる縦横斜めの相互理解が促進され、社外への情報発信をしていく機会も増えてきました。 まとめ プロダクトマネジメントは、PMだけが行うものではなく、チームで取り組むものだと思っています。 そのためには、対話ができる共通言語（プロトコル）や相互理解の継続的な取り組みが欠かせません。 新規事業は、短中期の非連続性を目指す性質上、短期的な意思決定・推進の速度だけではなく、チームで対話しながら、自律的なプロダクト開発ができるように、チームでプロダクトマネジメントをしていく必要があると考えています。まだまだ山の麓ですが、これからも挑戦していければとおもいます。 今回紹介したPay ID チームでは、現在PMやデザイナー、エンジニアを募集中です！ 興味あるかも？と思った方はぜひ一度お話を聞きに来ていただけるととても嬉しいです！ ▶ 詳細はこちら 明日は @FUJIIMichiro さんや @Linda さんのお話です。お楽しみに！

この記事は BASE Advent Calendar 2022 の22日目の記事です。 こんにちは！ BASEでエンジニアをやっている大津( @cocoeyes02 )です。 BASEではエンジニアが外部へとアウトプットする文化があり、その中の一つに技術イベント・カンファレンスへの登壇があります。 2022年もBASEから様々な技術イベント・カンファレンスへ登壇したので、今回の記事ではその振り返りをしたいと思います。 直近3年間の登壇サマリー まず2022年の技術イベント登壇を定量的に振り返ってみます。比較のため2020年と2021年のサマリーも用意するとこのようになりました。 年 2020年 2021年 2022年 登壇したイベント数 9 17 17 各イベントでの登壇回数の合計 16 35 41 →うち1番登壇が多かった人の合計登壇回数 8 7 5 →うち1人あたりの合計登壇回数の中央値 2 1 2 ユニーク登壇人数 8 20 17 →うち去年登壇した人の中で今年も登壇した人 4 3 11 登壇した回数は毎年増えており、良い傾向にあります。 数字から読み取れるのは、段々と年に2回以上登壇している人が増えてきていることと、2021年に登壇した人で2022年も登壇している人が半数以上いるということです。 これは登壇が1回限りではなく、日々のアウトプットの機会として登壇を選択している人が徐々に増えていきていることを示しています。 登壇を文化として根付かせる上では、登壇「したことある」人だけでなく、登壇「している」人が増えていることが重要になってきます。その点において言えば、好ましい結果になったと言えます。 ユニーク登壇人数は2021年と比べると人数が減ってしまったので、iikanji-conference-toudanチームのメンバーとしては来年の目標としても追っていきたいです。 ちなみにiikanji-conference-toudanチームの活動については、去年のアドベントカレンダーの記事をご覧ください。 devblog.thebase.in 2022年はどのような分野の登壇が多かったか 2022年はバックエンド、アジャイル、フロントエンド、SaaSツールなどをテーマにした技術イベント・カンファレンスの登壇がありました。 去年までと比べると、比較的フロントエンド分野の登壇が増えてきました。特定の分野だけではなく、多方面の分野でアウトプットしていく文化があるのはとても良いことですね。 いくつかフロントエンド分野における登壇のイベントレポート記事がございますので、よければご覧ください。 devblog.thebase.in devblog.thebase.in また、2022年は協賛や招待による技術イベントの登壇が増えました。 今年は例年よりも「一緒にイベント開催しませんか？」「イベント登壇しませんか？」と声をかけて頂いた回数が多かったように感じます。この場を借りてお礼申し上げます。 こちらに関しても登壇のイベントレポート記事がございますので、よければご覧ください。 devblog.thebase.in devblog.thebase.in devblog.thebase.in basebook.binc.jp 登壇によって変わったことがあったか 面接や面談の場で「登壇によるアウトプットを見た！」という声がだんだん増えてきました。 社内slackで「登壇によるアウトプットを見た！」というコメントを頂いた様子 他にも内定承諾のきっかけの一つに、登壇によるアウトプットを挙げていた方も現れました。 社内slackで内定承諾のきっかけの一つに、登壇によるアウトプットを挙げていた様子 登壇によるアウトプットが採用のアトラクトに貢献できていて、大変嬉しい限りです。 ブランディングにおいて最も重要なことは、とにかく継続することだと思っています。 今後も技術ブランディングの向上をしていく上で、BASE外に継続したアウトプットが出ているかが重要であると再確認ができました。 最後に とはいえプロポーザルを出したけど採択されなかった人が出てきたなどまだまだ課題はあります。 プロポーザルが採択される上で重要な観点を社内kibelaにまとめるなど、2023年も引き続きエンジニアの登壇をサポートしていきたいと思います。 ちなみに、今回紹介した記事以外にも登壇のイベントレポート記事がたくさんあります。 カテゴリ「イベントレポート・スポンサー・登壇」の一覧を見ると一通り読むことができますので、ぜひご覧ください！ カテゴリ：イベントレポート・スポンサー・登壇の記事一覧 明日は @FUJIIMichiro さんの『BASEのUXライティング／コピーライティングについて2022』と @Linda さんの『経営戦略室と僕たちが信じる未来』のお話です。お楽しみに。

この記事は BASE Advent Calendar 2022 の21日目の記事です。 Platformグループでグループマネージャー をしている 松田 （ @tadamatu ） です。 先日、エンジニア15名に AWS JumpStart（AWS研修プログラム） に参加してもらいました。 この記事では、参加の目的や感想、実際参加してどうだったのか、などを伝えさせていただこうと思います。 「AWS JumpStart（AWS研修プログラム）」とは？ AWSが 無償 で提供してくれている研修プログラムで、 AWS初学者のエンジニアを対象とした、実践的な2日間の研修プログラム です。 https://awsjumpstart221020.splashthat.com 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します 単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております 本イベントは、数時間の事前勉強会 (録画動画を事前配布)と2日間のワークショップ(参加必須)で構成されています 　 参加の目的 現在BASEでは、私達のグループが主導をして絶賛 リアーキテクチャ を進めています。 「モジュラモノリス」を中心 として、新しく環境を作り直そうとしているのですが、 インフラ環境としては今後もAWSを中心に構築 を予定しています。 「モジュラモノリス」を選んだ理由は様々あるのですが、理由の一つとして 「モジュールの独立性」 というものがあります。 BASEではエンジニアの数が多くなるにつれて、 現状のモノリシックな環境 では修正のたびに コード影響範囲の調査に時間が取られる 関係者が多いため意見も増えコンセンサスをとりづらくなる など、 多大なコストを支払わなければならない という状況が増えてきています。 これらを解決するために、 モジュールという単位で適切なコンテキスト分解 し、それぞれに コードオーナー（チーム単位）を設置 し、 責務の分離 を行う計画です。 責務の分離を行うことで、 よりスムーズな開発を促し、スケーラビリティも確保をしたい と考えています。 これにはチーム内で物事を考え、仕様を決定し、完結する力が求められることになります。 AWSでアーキテクチャを考えたり、試したり、インシデント調査したりするために、 アプリエンジニアのインフラ知識の底上げが課題 と考えていました。 そこで、まずは 初手として「AWS JumpStart」への参加 をしてもらったという流れです。 参加者はなんと15名！ 今回は各チームから1名ずつ 「エンジニアとしては中級〜上級だが、AWSの知識は初級〜中級」な15名 に参加してもらいました。 数回に分けるなどの案もありましたが、せっかくだからお祭り感も出たほうがよさそうといったノリで、全員一気に参加してもらうことになりました。 15名ｘ2日というのはなかなかの工数です。 しかし、ここはCTOが二つ返事でOKをくれました。ありがたい。 研修スペックを少しご紹介 研修内容は 公式ページ を見ていただきたいのですが、掲載されていない情報を載せておきます。 雰囲気 今回の研修には約130人のエンジニアが参加 Web、ゲームなど様々な業種からの参加 業種混同で34チームに分かれてアーキテクチャ検討などをを行う 参加者のレベル感は様々で、知識が豊富な方々から経験が浅い方々までといった感じでワイワイと進む 使用ツール Amazon Chime（zoomライクな動画ツール） Slack（申請をすると参加を促されます） Bluescape ハンズオン用のAWSアカウント 参加者の感想 参加者に感想をもらいましたので紹介させていただきます。 今後参加を検討されている方のために、 ポジティブな意見もネガテイブな意見も 包み隠さず書いておきます。 勉強になった どういう AWS サービスがあるのかを紹介するだけでなく、なぜそのようなアーキテクチャ設計にしたのか、非機能要件の評価基準も詳細に解説してくれてとても勉強になった。 AWSのサービスについて何か聞いたことがあるくらいでも安心して参加できる内容で、インフラ設計やその評価観点についても体系的に学べたのが良かった。 AWSとちょっとだけ仲良くなれそうだなと感じた2日間だった。 インフラに興味を持った これからが本番だぞ！と言う気持ちで色々調べたいなと思った。AWS詳しい人に向かっていく勇気がついた。 インフラは難しいという印象をずっと持っていたが、AWS Certified Solutions Architect の資格に興味を持った。 AWSのサービスやオプションが色々あり、まだまだアーキテクチャを構築する上で知らないといけないことは多いなと感じた。 ハンズオンが良かった 「ECSタスクの停止した場合の挙動」や「Aurora MySQLのフェールオーバー時の挙動」を実際にハンズオンで確認したけれどほとんど見る機会もないので少し感動した。 アーキテクチャを検討するにあたり、押さえるべきポイントを実例を踏まえて経験できたのは良かった。 やっぱり実際に手を動かすと理解が深まるなと思った。 AWSの進化に驚いた・新しい発見があった AWSサービスは日々進化しており、より使いやすくなっている。複雑なインフラ整備も、今となってはクリックだけで完結できるようになっていて驚いた。 主要なサービスを包括的に一覧する意味では大変有益だったと思います。事前学習動画は全社員見ておいた方が良いかも。 S3 の料金体系が様々あって下がっていってるのには驚いた。 他業種との交流が良かった Web系ではない業種の方からの質問が新鮮だった。 システムアーキテクトに相談できてよかった 予想が付くような質問に対しても、想定よりも多くの情報を頂けた。 AWSのテクニカルサポーターの方もナレッジが豊富で、さまざまなユーザーケースに対して適切なアドバイスを出してくれて、頼りに感じた。 AWSのSAならどうアーキテクチャを考えるかの思考プロセスが分かりやすかった。参考にしたい。 楽しかった 即席チームでのワーク、楽しく行えました。 ワイワイできて、非常に楽しかったです！ 時間が足りなかった 構成や負荷に対する懸念が出てきたが、二日間ではできなかった。残念。 アウトプットがアーキテクチャ図のみだったので、もっと細かい改善フィードバックを得たかった（発展編みたいな研修があれば参加したい） 疲れた 研修の中で一番タフだったのはアーキテクチャ検討でした。 ずっと思考している時間が続くので、一日の終わりには結構疲れがきます... その他 VPCを作るといった普段しない作業も合ったけれど、概ね知っている内容だったので、上級者の場合はただ手を動かすだけの作業になってしまう可能性があるかも。 アーキテクチャ検討のレベル感がやや高いと感じる場面があったので、人によっては大変な場合もありそう。 現在の業務に生かせそうか こちらもヒアリングしていますので、まとめておきます。 活かせそう 実はもう既に現在進行形で活かしている状況です！ SREチームが何をしているのか、また何を話しているのかの解像度が上がりそう。コミュニケーションロスは減らせそう。 インシデントなどでやり取りされている単語の意味がわかるようになった。 インフラ視点も考慮したシステム開発できるようになりそう。今後イチからインフラを構築するPJに参画する機会があれば大いに活かせそう。 今後の新規開発で考慮する点、考え方が少し分かった気がする（インフラも考慮に入れた提案などはできるかも） インフラに興味を持った。恐怖心がなくなった。 アプリケーションの後ろで何がどう動いてるかをイメージできるかどうかがとても重要だと感じた。 実際にインフラを構築しなくても、アプリケーションエンジニアとして開発を進めていく中、パフォーマンス向上・スケーラビリティなどの文脈でインフラ視点が大事になってくる場面も多いのでとても有意義であった。 微妙、活かせるか分からない 直接日々の業務にすぐに役立てられるというような類のものではなかったかなという印象です。 直近、インフラアーキテクチャを構築していく機会というのはなかなかないのでイメージがしづらい。 SREではないので、AWSのサービスを設定したりすることはないため直接的に活かすことは難しそう。 サービスのエンジニアだとゼロから構築することは稀で、既存のBASEのインフラ資産を活用する方向に行くことがほとんどなので微妙。 で、結局「AWS JumpStart」どうなの？ ちなみに私は提案者であり参加者ではありません。 参加後に研修レポートを書いてもらったものをまとめてこの記事を書いているのですが、 レポートには長文だったり、非常に臨場感あるものもあり、ハンズオン、検討会などが本当に楽しかったのだろうな ということがヒシヒシと伝わってきました。 次回は私も参加したいと思えるくらいに。 トータルしてプラスの意見が多く参加してもらって良かった なと感じています。 「微妙、活かせるか分からない」という意見もありましたが、実際のところアプリケーションの後ろで何がどう動いてるかをイメージできるようになったはずですし、 考え方の幅が広がったと思いますので、マイナスの意見を書いてるエンジニアでも全く無駄ではない と考えています。 また、 インフラの苦手意識の克服、耐性ができた のも非常に良かった点だと考えています。 最後に 「AWS JumpStart」について書いてきました。 SREを目指していない人でも、開発に活かせる内容ですし、後日談でAWSの方と話をしたときには「内容はさらにパワーアップさせるよう動いています」という話も聞いています。 しかし、 知識は使ってなんぼ 。 リアーキテクチャもまだまだれからが本番です。 今後も BASEエンジニア全体のナレッジ底上げを目的とした様々な施策を実施していきたい と考えています！ もしBASEにご興味を持っていただけたならば、カジュアル面談なども実施しておりますので、気軽にお話させていただければと思います！ 最後まで読んでいただきありがとうございました。 さて、明日は @02 @tsubo の記事が公開予定です！お楽しみに！

この記事は BASE Advent Calendar 2022 の21日目の記事です。 初めまして。 BASE株式会社Corporate Engineering CSEの緒方です。 CSE については こちら の記事をご参照ください。 ちなみに私はこの記事を読んだことがきっかけでBASEに入社しました。 上場して3年目 BASEは2019年10月25日に東証グロース（旧：東証マザーズ）に上場し、今年でちょうど3年目にあたります。 上場して3年目ということで、J-SOX法上の監査法人による「内部統制報告書」の監査の免除期間も終了し、2022年度から本格的な監査が始まりました。 このタイミングでエンジニアやプロジェクトマネージャー（以下、PM）を対象に、J-SOXのIT全般統制(ITGC)／IT業務処理統制(ITAC)に関する社内説明会を実施したので、そのエッセンスや統制整備する際に心掛けていることなどをお伝えできる範囲で、あまり専門的になりすぎずにお話しできればと思っています。 上場企業でJ-SOX対応やIT統制に拘られている方々の一助になれば幸いです。 そもそもJ-SOXとは 2006年6月に金融証券取引法が成立した際に、米国のSOX法をモデルに規定された制度です。 上場企業が自社内の業務の内部統制の有効性を評価し、 「うちの会社、誤りとか不正とかなく、ちゃんと正しくお金の勘定してますよ！」 という内部統制報告書を作成して、監査法人からお墨付きをいただく制度になります。 2000年代初頭、米国にてエンロン事件をはじめとする大規模な不正会計事件が相次ぎ、市場が混乱し、健全な株取引が行えなくなり、投資家たちの「なんとかしてくれ！」という声から生まれた法制度になります。 ですので、直接的には投資家や株主を保護するためのものです。 J-SOXにはそれに係る以下の統制の種類があります。 全社的な内部統制 決算・財務報告プロセスに係る内部統制 業務プロセスに係る内部統制 ITの統制 BASEとしてのIT統制の取り組み方 「上場したから」「制度だから」「法律だから」という後ろ向きな理由ではなく、むしろ本制度を活用し、統制を整備することで、よりスピード感のある開発を行っても事故を起こさないような安全装置の役割を目指しています。 具体的には、以下の仕組みを構築することで、日常業務上の不安を払拭したり、有事の際のリカバリコストの削減を図り、結果として従業員一人一人が安心安全に、かつスピード感をもって業務遂行できるようにすることを目指しています。 誤謬（意図しない誤り）や不正が起こりにくい仕組みの構築 万が一、誤謬や不正が起こった時に、検知しやすい仕組みの構築 「誤謬」と「不正」について 財務諸表において、 本来あるべき正しい形のものとは違うものを作ってしまう という点においては「誤謬（過失）」も「不正（故意）」も客観的な事実はほぼ同じで、取るべき対策も両者共通しています。 ですので、統制整備の際には 「誤謬を減らすため」に整備実施することに主眼を置き、その結果として 「不正防止のため」につながっている という形が取れるようにしています。 統制の目的として「不正防止」ばかりが先行してしまうと、一緒に働く仲間たちに不信感を抱いているようにも捉われてしまいかねない為、そうではなく、あくまで個々人が安心して日常業務に取り組んでいくための安全装置であることを理解していただけるよう心がけています。 統制のポイント では、 本来あるべき正しい形のものとは違うものを作ってしまう ことを無くしていくためにはどのようにすればよいか？そのためには財務諸表上、よりリスクの高いと思われるプロセスについては、 「複数人の目が入るチェックの仕組み」 を作る必要があります。 具体的には、以下２点が担保できるように心がけています。 Aさんが申請して、その内容をBさんが内容をチェックし、承認して、初めて行使できるしくみ。 上記、承認→申請の内容を第三者であるCさんが事後に客観的に確認できるしくみ。 要は 一人の担当者（あるいは管理者）が独断でなんでもかんでも出来てしまえないように する仕組みとなります。 ですので、一人一人に裁量権を与え、各人の判断でスピード感をもってゴリゴリ進めていくような自走的組織とは、そもそも相性があまり良くありません。 このジレンマが統制整備上の一番の悩みどころです。 統制「しすぎない」こと 統制により「やるべきこと」が増えてくると、業務のスピード感に支障を来します。 そうならないよう、開発エンジニアや各業務を遂行する各担当者たちとは密にコミュニケーションを取り、「スピード感（アクセル）」と「統制（ブレーキ）」のバランスは常に意識するようにしてます。 着眼点としては以下のようなところです。 チェック項目が多すぎないか？ 同じ内容について複数箇所でチェックしていないか？ チェック作業自体を簡略化できないか？ 財務諸表に影響のない部分にまで必要以上の統制を効かせていないか？etc. 最終的には 「統制のルールだから◯◯しないと！」みたいなことを出来るだけ意識させない統制の整備 が理想系だと考えます。 BASEのミッションとIT統制 当社のミッションである「Payment to the People, Power to the People.」を実現するべく、使っていただくショップオーナー様、購入者様をよりエンパワーメントするための機能を日々もりもり開発しております。 IT統制はそれらの開発をよりスピード感をもちつつ、かつ開発エンジニア各人が安心して開発を行えるようにするための必要不可欠かつ重要な機能だと捉えています。 そのためには、一度整備して終わりではなく、より安全かつスピード感を保てる統制を常に模索しつづけることが大切だと感じています。 明日は @cocoeyes02 さんの『BASE技術イベント登壇振り返り2022』と @mrhiro1112 さんの『PMconf 振り返り』のお話です。お楽しみに。

この記事は BASE アドベントカレンダー 2022 の20日目の記事です。 はじめに BASE BANKというチームで BASEカード というサービスの開発をしている大垣( @re_yuzuy )です。 本記事ではBASEカードで行ったキャッシュバックキャンペーンについて、システム的な設計という観点から書いていきます。 そもそもBASEカードとは何なのか BASEカードは BASE で作ったネットショップの売上を残高として全国のVisa加盟店(以下加盟店)で使うことができるプリペイドカードです。 BASEカードによって手数料をかけずに売上金を即時に使うことが可能になりました。 キャッシュバックキャンペーン BASEカードでは利用者増加を促進するためにキャッシュバックキャンペーンを実施してきました。 第1回目はリリース直後の去年(2021年)の9/28~12/26に行われました。 そして第2回目は今年(2022年)の12/1~12/26で記事投稿時現在も行われています。 カード決済の裏側 キャッシュバックキャンペーンの設計を説明するあたってそもそもカード決済がどのように処理されるのかも簡単に説明しなければなりません。 基本的な流れ 加盟店でBASEカードを使って決済を行う場合、まずVisaにリクエストが行き、その後提携会社を通じてBASEカードに通知が送られてきます。 最も基本的な形は 残高確認→決済成功→決済確定 という順で通知が送られてくるパターンです。 各通知の詳細についてはこの後説明します。 決済がキャンセルされると途中で 残高確認→決済成功→キャンセル 残高確認→決済成功→決済確定→キャンセル というようにキャンセルの通知が挟まったり、なんらかの理由によって途中で商品の値段が上がると以下のように増額の通知が挟まったりします。 残高確認→決済成功→増額→決済確定 残高確認→決済成功→決済確定→増額→決済確定 残高確認 先程BASEカードは売上を残高として使える プリペイドカード と説明しましたが、実際の使用感は デビットカード に近いです。 例えば1,000円の売上残高があったとして500円の商品を購入したい場合 というようにサイレントにチャージが行われています。 残高確認とはこの例で言うと提携会社からBASEカードに送られてくる「500円残高ある？ 」というところで、残高を確認する他にショップがBANされているか、カードがロックされているかなどの確認をしています。 1秒以内という速度要件があり、この要件を実現するためにした取り組みも面白いのでこれに関しても別でブログを書きたいと思っていますが、キャッシュバックにはあまり関係していないのであまり気にしなくても大丈夫です。 決済成功 残高確認を経て提携会社の向こう側であれこれやった結果、無事決済が成功すると送られてきます。 決済確定 加盟店(ネットショップなど)側で売上が確定すると送られてきます。 毎日特定の時間に送られてきます。 ネットショップだと商品を発送したときなどに送られてくることが多いです。 なので基本的に 決済成功してから決済確定までは数日間のラグがあります 。 ここで決済の詳細なデータ(加盟店や為替の情報など)がBASEカード側に送られてきます。 例えばBASEのショップで買い物をしていただくと、残高確認や決済成功の段階では加盟店名はBASEですが決済確定ではBASE*HOGE SHOPのようになります。 これはBASEカードに限ったことではないので自分のクレジットカードの利用履歴などを見て確認してみても面白いかもしれません。 キャンセル 決済がキャンセルされると送られてきます。 必ずしも全ての金額がキャンセルされるというわけでもなく、複数の商品のうち1つを返品するなどされた場合にはその商品の金額分だけキャンセルされます。 増額 上記の説明そのまんまなので割愛します。 キャッシュバックキャンペーンの設計 2021年 前述した通りBASEカードリリース直後で、もちろん初めてのキャッシュバックキャンペーンです。 BASEカードのキャッシュバックを設計するにあたって参考にできる記事等があまりなく、かつメインで設計した私が設計初心者だったこともあり苦労した印象があります。 仕様 2021年のキャッシュバックキャンペーンはざっくりと以下のような仕様でした。 キャンペーン期間中に来た決済が確定されたら特定の割合をキャッシュバックする。 キャッシュバックされた決済がキャンセルされたらキャッシュバックもキャンセルする。 本人確認の有無でキャッシュバックの割合・キャンペーン全体での上限金額を変更する。 本人確認済み: 5%・5,000円 それ以外: 1%・2,000円 決済毎の上限金額は500円。 ご利用履歴詳細でキャッシュバックされた金額を確認することができる。 DB設計 キャッシュバックキャンペーンの要素を保存するテーブルとして以下の3つを定義しました。 payment_transaction_logsに関しては決済に関する通知が蓄積されているとだけ考えていただければ大丈夫です。 cashback_campaigns キャッシュバックキャンペーンそのものを表すテーブルとしてキャッシュバックキャンペーンに関わる全てのテーブルの親となっています。 このテーブルが持つ重要な情報はIDとキャンペーンの開始・終了時刻くらいで、他の情報は別のテーブルが保持しています。 cashback_yields キャッシュバックの還元率や上限金額を保存するテーブルです。 targetというカラムを作りそれによって還元対象を判別できるようにしています。 2021年の場合は本人確認済と未確認の識別子を定義し、それぞれ還元率と上限金額が異なるレコードを用意しました。 cashback_logs キャッシュバック・キャッシュバックキャンセルの情報を保存するテーブルです。 キャッシュバックに紐づく決済の識別子やキャッシュバックが行われたときの還元率の情報を保存しています。 アプリケーション設計 2021年のキャッシュバックキャンペーンではバッチを毎日定期実行し、そこでキャッシュバック処理に関する全てのことを実行するようにしました。 処理としては 前回の実行以降に確定した(キャンセルされた)決済を引っ張ってきて、キャッシュバック(キャンセル)対象かつキャッシュバック上限未到達であればユーザーの本人確認状況によって適切な還元率を適応してcashback_logsにレコードを保存し、ショップの売上残高にキャッシュバック(キャンセル)する。 と、シンプルです。 よかった点・反省点 よかった点は結構キャッシュバックキャンペーン開始までスケジュールギリギリで設計・実装していたものの根本的には長生きできそうな設計にできた点です。 例えばリアルカードでの決済にだけキャッシュバックしたいというキャンペーンが生まれてもcashback_yieldsに適当な識別子を追加して、それに紐づく判別の処理を実装し当てはまればキャッシュバックをする、という感じです。 逆に反省点は前述した通り急いで実装するために(ただの言い訳ですが)一般化があまりなされておらず、実質的には今回のキャッシュバック専用の実装が出来上がってしまった点です。 ですが1年越しに見てみても悪くない設計にはなったのかなと思っています。 2022年 さて今年のキャッシュバックキャンペーンですが、前回のキャンペーンとところどころ仕様や実行方法が異なっています。 さらに キャンペーン期間中にBASEカードで1回以上決済をする(500円以上)と抽選で10,000円がキャッシュバックされる という特定の決済に紐付かないキャッシュバックも新たに登場しました。 しかし、これについては設計的に面白みがあまりないのでこの記事では書かないことにします。 仕様 今年のキャンペーンでは新規ユーザー獲得のため、キャッシュバック対象ユーザーが「キャンペーン中にBASEカードで初めて決済をしたユーザー」に 変わっています。 更に以下のような仕様が追加されました。 予算を超えたらキャッシュバックキャンペーンを終了する。 ご利用履歴画面で決済がキャッシュバックされる予定か確認できる。 このキャッシュバックされる予定(以下キャッシュバック予定)という概念が厄介で苦労しました。 DB設計 仕様を満たすためにテーブルや識別子を追加しました。 cashback_campaign_balances 予算を表すテーブルでキャッシュバック(キャンセル)が行われるたびに更新しています。 cashback_campaigns 2021年のキャッシュバックキャンペーンでは実施されているか否かを判断するためのカラムが開始・終了時刻しかありませんでしたが、今回は予算が消化されたら期間内であっても終了するという仕様が追加されたのでキャンペーンの実施可否が判断できるようにカラムを追加しました。 アプリケーション設計 前述したとおり決済成功と決済確定にはラグが存在しており、キャッシュバック予定を確認できるという仕様は正確に言えば、決済成功段階でその決済がキャッシュバックされる予定の金額などを確認できる、ということです。 これは日次バッチだけでは実現することができず、 決済成功が来たらキャッシュバック予定を保存し、日次バッチでは予定情報を見てその分売上残高にキャッシュバックする。 というように全体的に設計を変更することになりました。 キャンセル・増額の処理 2021年のキャッシュバックではバッチで処理していましたが、キャッシュバック予定の関係等でキャンセル・増額の通知が来たときに処理することにしました。 キャッシュバックが予定段階のときにキャンセル・増額された場合にはキャッシュバック予定・キャッシュバック予定キャンセルを追加で保存し、バッチでは決済IDに紐づく全てのキャッシュバック予定・予定キャンセルを足した値をキャッシュバックするようにしました。 キャッシュバック済みの決済が増額・キャンセルされた場合にはバッチで残高操作をせず、その場で残高操作まで行うようにしました。 日次バッチでキャンセル・増額のキャッシュバック処理をしない理由として、バッチ自体の実装を単純にしたかったことに加え、決済確定が毎日決まった時間に通知されるのと対照的にキャンセル・増額は決まった時間に通知されないという問題がありました。 これによってバッチで処理するようにするとキャンセルからバッチ実行までの間に余分にキャッシュバック可能額が狭められてしまい、本来キャッシュバックされるべき決済がキャッシュバックされない可能性が生まれてしまいます。 よかった点・反省点 よかった点は設計に関してちゃんと文書化できた点です。 これはキャッシュバックに限ったことではなく、BASEカードでは大抵の事柄(決済や本人確認など)について技術ドキュメントが書かれていて、カード決済というドメインそのものの複雑性と決済や本人確認などの複数のベンダーが関わっているという複雑性に立ち向かうためにこれらのドキュメントをとても重宝しています(もちろん前回のキャッシュバック設計時にも書きました)。 今回に関して言えばキャッシュバック予定という概念が新しく登場しましたが、きちんと文書化することで開発メンバー全員が新たな設計や概念に対して共通の認識を持つことができました。 反省点は前回と同じく、今回の仕様専用のような設計・実装になってしまった点です。 キャンセル・増額の処理のユースケースが巨大化してしまうなど、今年のキャッシュバックキャンペーンでは戦術的な設計になってしまった部分が多々ありました。 今後改善していきたいこと 今後もキャッシュバックキャンペーンは行われていくと思われるため、決済の実装からはできるだけ切り離すなど、より戦略的な設計にしていきたいです。 おわりに BASEカードにはキャッシュバックに限らず面白い課題がたくさんありますし、手をあげれば設計やデータ分析などやってみたいことに取り組める環境です！(2021年のキャッシュバックの設計をした当時私は17歳かつインターン生でしたが、興味本位でやりたいと言ってみたらメンバーのサポートもありやることができました) 一緒に開発していただけるメンバーを鋭意募集中ですので、この記事を読んでみて少しでも興味をもっていただけましたらぜひカジュアル面談だけでもよろしくお願いします！ open.talentio.com 明日は緒方さんと松田さんの記事です！お楽しみに！

この記事は BASE Advent Calendar 2022 の19日目の記事その2です。 こんにちは。BASE 株式会社 New Division BASE BANK Section にて、Engineering Program Managerをしている永野( @glassmonekey ) です。 私個人としては、今年のアドベントカレンダー2回目です。 前回は以下の記事で普段の仕事への取り組みざまを書いたのでそちらもよかったらご覧ください。 devblog.thebase.in 今回の記事の趣旨としては、私が主に担当しているYELL BANKというプロダクト開発で行った Python の改善ネタになります。 ちなみにYELL BANKについては同僚のyuniさんが熱く語ってくれたのでそちらもご覧ください。 devblog.thebase.in YELL BANKのプロダクトの裏側 YELL BANK では、過去の売上データを元に提供金額を算出し、 BASE加盟店さま の規模感に応じた資金調達体験を実現しています。 その際以下のフローで金額の提示を行います。 売上予測といった機械学習の内容を返却するAPIから金額算出のための情報を取得する 我々の事業状況に応じて 提供金額算出 API が提示する金額の計算を行う 計算した金額を BASE加盟店さま 向けの管理画面で提示する 資金提供APIを始めとして、我々の開発チームでは基本的に Go を扱うことが多いです。 しかし 提供金額算出 API に関しては、機械学習の仕組みも簡単に取り入れる選択肢がありえるだろうということで、 Python で書かれています。 実際に現在は異常検知のために、機械学習の仕組みが導入されていたりもしています。 ある日の課題 リリースして5年にもなるサービスなので、金額計算のロジックを始めとしたドメイン知識の複雑さも増える一方の状況でした。 とくに金銭を扱うコードなので、一歩間違えると事業上大きなリスクを背負うことにもなり、品質にも気をつける必要がありました。 そのため、金額計算のテストは厚めに書いていたものの、複雑なドメインロジックの認知負荷を下げることにはそこまで対処できていない状況でした。 特に型の整備は全然できておらず、 int , str といったプリミティブな型が基本的に使われるという状況でした。 特にYELL BANKにおいて、同じ金額という内容でも以下を区別しており、一言に int として扱うのは限界がありました。 * 提供金額 : 利用者に提供する金額 * 支払い総額 : 手数料を含めた金額 いわゆるLintの整備はある程度できていたものの、とりわけ mypy による型の静的解析の対応ができていませんでした。型の静的解析があれば早めに気づけたミスも、テストを実行してみて初めて気づくという状況が度々発生してしました。 全てのテストで数分レベルなので、致命的とまでは言わないですが開発者体験としてあまりいいものではありませんし、今後のテストの内容次第では開発のボトルネックになるのは目に見えていました。 段階的に型をつけていく そこで、全体的コード知識を整理すべく、以下を中心に型の追加・厳格化対応をしていきました。 dataclassの活用 NewTypeでプリミティブな型に意味付けをする mypyのstrict化の実施 それぞれ詳しく説明します。 dataclassの活用 ある程度のドメイン知識を表す表現に当初は TypedDict をメインで使っていましたが、単体だとメソッドをつけられず不便でした。 一方で class を使えばオブジェクトに振る舞いを持たすことは可能ですが、 testに失敗したときに以下のように差分が不明瞭といった課題感がありました。(スクリーンショットはPyCharmでテストを実行したものです） マジックメソッドの __eq__ や __repl__ を定義してなんとかやりくりしていましたが、クラスの構造に対する追従漏れが生じたりと、十全とは言えない状況でした。 そこで dataclass を積極的に活用するようにしました。 dataclass の詳細は PEP 557 で定義されているので一読するのをおすすめしますが、3.7から導入された機能になります。 3.6用のバックポート も存在しています 使い方はシンプルで、classに対して @dataclass のデコレータを使用するだけです。 frozen=Trueを使用すると生成されるオブジェクトのプロパティの再代入が禁止され、イミュータブルなオブジェクトに簡単にできるので大変便利です。 @ dataclass (frozen= True ) class Point : x: int y: int 上記のclassに対して、あえて失敗するテストコードを書いてみます。 def test_sample (self): assert Point( 1 , 1 ) == Point( 2 , 1 ) すると以下のように失敗したときの差分もわかりやすく表記してくれるので、開発効率は大幅に上がりました。 NewTypeでプリミティブな型に意味付けをする 前述した通り、YELL BANKでは様々な数値を扱うため全ての数値を int だけで表現することに限界があると述べました。 ではどのようにするといいのでしょうか? 前述した dataclass を使った表現も1つの方法としては考えられるでしょう。しかし、振る舞いをそこまで必要としない数値的な概念に対して全てに dataclass を定義することは過剰なように思えます。 そこで、考えた手としては NewType の活用でした。以下のように簡単コメントで説明を併記しておくことで、簡単なドメイン知識が集約されるようにもなりました。 FactoringAmount = NewType( 'FactoringAmount' , int ) # 債権の提供金額。 PurchaseCreditAmount = NewType( 'PurchaseCreditAmount' , int ) # 提供金額に手数料とたしたもの。 strict な mypyの導入 そもそも mypy とはPython用の静的型解析ツールです。 https://github.com/python/mypy 元々mypyそのものは導入されていましたが、まともに運用はしていない状況でした。 また、strictオプションを有効にした場合の変更差分が多い状況でした。 mypyのstrict化をしている間事業の更新を止めるわけにはいかないので、最初の方はstrictの設定をOFFにして、日々のスプリントの開発上で無理のない範囲でちょっとずつ対応していきました。 現在のmypyの設定情報は以下のような感じで現在運用しています。 ignore_missing_imports = True no_implicit_reexport = False strict = True 補足として no_implicit_reexport に関してはパッケージの引っ越し作業を行った影響で、明示的に残しています。（近いうちに削除予定です） ignore_missing_imports に関してはサードパーティのライブラリに型情報のファイル(拡張子が .pyi もの)が無いと、 `error: Skipping analyzing "{パッケージ名}": module is installed, but missing library stubs or py.typed marker というエラーが発生するので設定してます。本来は抑制は褒められた話ではないでしょうが、サードパーティのライブラリに個別に設定するのは現実的ではないでしょう。 対応してよかったこと 我々のチームでは外部libraryの更新に dependbot を利用しています。その対応時に問題があった際に、先にlintや型チェックで気付けたこともあり対応しててよかったなと感じました。 細かいところだと、安易なOptionalを利用している箇所があり、Optionalを外すために不要な複雑さを生んでいる箇所の発見にもつながったこともありました。おかげで、コードとしてシンプルさがあがったように思います。 また、一言にintといっても、金額なのか？どのような金額なのか?を対応前はコードジャンプして読み解く必要がありましたが、今は型を見れば済むので認知負荷の削減にもつながりました。 チームのナレッジ的にもPythonに詳しいメンバーがそこまで居ない状況だったので、型解析をはじめLintがおすすめするPythonのベストプラクティスに乗ることで特に困らず開発できているように感じています。 今後 現在我々のチームで扱っているPythonは3.9ですが、3.10, 3.11と型周りの力の入れようを感じているので、その恩恵に与れるように色々と追従はしていきたい所存です。 特に3.10で導入された TypeGuard はcastでごまかしている部分もあるので使っていきたいなと思っています。 3.11では大幅速度改善をしているようなので、近いうちにアップデートしてAPIとしての品質も高めていきたいとかんがえています。 我々の開発チームはPHP/Go/Python/Vueとフルスタック・フルサイクルに開発しているチームなので、もしきょうみがあるよって方がいましたらDMや下記のlinkからの応募お待ちしています。 一緒に最高の開発体験を作っていきましょう!! 以下の採用リンクからのエントリーお待ちしています。 open.talentio.com もしくは @glassmonekey までDMいただけると嬉しいです。 明日は同僚の @re_yuzuy さんによる、BASEカードの裏話と、デザイナーの @hoteco さんによる入社後の体験についての2本立てですです。楽しみですね!!

この記事は BASE Advent Calendar 2022 の19日目の記事です。 はじめに こんにちは、DataStrategyチームの竹内です。 今回はBASEで作成されたショップが扱っている商品のカテゴリを機械学習モデルを使って推論するための取り組みについてご紹介いたします。 はじめに TL;DR 商品カテゴリ データセットの作成 ラベルセットの検討 データのサンプリング AWS Ground Truthを利用したアノテーション アノテーション対象のフィルタリング モデルの学習とテスト BERTのファインチューニング モデルの性能評価 gokartを利用したパイプラインの構築 AWS Batchを利用したバッチ推論基盤 おわりに ※ 記事内のコードはサンプルとして簡略化しています。 TL;DR BASEで作成されたショップに登録されている商品のカテゴリ（ファッション、食料品など）を予測するモデルを作成しました 分類モデルにはBERTをファインチューニングしたものを使用しました（商品画像の利用は今後の課題です） アノテーションにはAWS Ground Truthを利用しました カテゴリ数分の2値分類モデルを作成し、8カテゴリ分をマルチラベルでラベル付けしています モデルの学習は社内オンプレGPUマシンを利用し、推論はAWS Batchを利用しています 商品カテゴリ 現在BASEで作成されたショップからはファッションアイテム、インテリア用品、食料品など毎日数万点もの様々な商品が登録され、販売されています。 しかしながら、それら1つ1つの商品がどういったカテゴリに属するかを把握することは容易ではなく、例えば「BASEを通じてどれぐらいファッション商品が販売されたのか」「不正決済が起きている商品の傾向はどういったものか」といった細かい分析を行う際は、人の手で商品を1つ1つ確認していくか、ショップ側で設定されたショップのカテゴリを利用することが多いのが現状です。 ところが、ショップのカテゴリが必ずしもそのショップで販売されている商品のカテゴリと一致するとは限らず、またショップカテゴリの設定は任意であるためカテゴリを設定していないショップも数多く存在します。 そのため、DataStrategyチームではその日にBASEのショップで登録された商品のカテゴリを、機械学習モデルを用いて自動的に推論するバッチ処理基盤を新しく作成しました。 データセットの作成 機械学習モデルを作成するためには学習およびテスト用のデータセットが必要となります。 着手段階では商品のカテゴリが正確にラベル付けされている一定の規模のデータセットが存在しなかったため、まずはそれらの作成から行いました。 ラベルセットの検討 データセットの作成にあたり、まず商品にどのようなラベルをつけていくかの検討を行いました。 基本的には既存のショップカテゴリをベースにしつつ、実際の商品群に目を通しながら、できるだけ漏れや重複が少なくなるよう大カテゴリ8種類（インテリア、ファッション、スポーツ、電子機器、コスメ、飲食物、サービス）と、その下の中カテゴリ約100種類（調理器具、Tシャツ、ゴルフ用品、お菓子など）に整理しました。 その上で一旦大カテゴリ8種類分に絞った分類モデルの作成を行うことにしました。 データのサンプリング BASEのショップで既に公開されている商品をランダムにサンプリングし、アノテーションを行うことで学習およびテスト用のデータセットを作成しました。 サンプリングする際は特定の季節の商品に偏らないように1年以上幅のある範囲から均等に抽出を行いました。 その上でアノテーションコストを抑えつつ8種類の大カテゴリ全てについて十分なサンプルサイズを確保できるよう、既に十分なサンプルサイズが得られたカテゴリに分類される商品をフィルタリングする処理を入れました。（後述） AWS Ground Truthを利用したアノテーション データセットのアノテーションには AWS Ground Truth のベンダーワークフォースを利用しました。 AWS Ground Truthを利用した理由としては普段からAWSを使用しているため学習コストが小さい点、S3と連携することでデータセットやワークフローの管理が容易である点、ベンダーワークフォースについてはAWSによって品質やセキュリティの手順が事前にスクリーニングされている点などが挙げられます。 アノテーションにはテキストと商品画像両方を判断材料としたかったのですが、Ground Truthで利用できるラベリングツールはテキスト、画像どちらか片方のみに対応したものであったため、あらかじめ商品画像に商品タイトルと商品説明文をキャプションとして付与した1枚の画像を作成し *1 、それを対象に1画像のマルチラベル *2 分類タスクとしてアノテーションのジョブを作成しました。 アノテーション用にキャプションが付与された画像（サンプル） ちなみにGround Truthのジョブ作成時、ワーカー数の設定部分がデフォルトで折り畳まれていますが、この部分はタスクの難易度や必要な精度などを考えて調整しておくことを推奨します。（この部分の初期値が3になっており、そのまま変更し忘れていた場合にデータセットのサイズの約3倍のコストと作業時間がかかってしまった、といったトラブルが起きる可能性があります。） Ground Truthのワーカー数設定 アノテーション対象のフィルタリング 単にランダムサンプリングを行なったデータをアノテーションすると、BASEの商品全体において多数を占めるファッションカテゴリの商品にアノテーションが集中することになります。 一方でファッション商品は比較的分類が簡単なカテゴリのためそこまでサンプルサイズは必要なく、逆に分類が難しい少数派のカテゴリのサンプルサイズを確保しようとすると大量のデータをアノテーションしなくてはならなくなり、コストパフォーマンスが悪くなります。 そのため十分なサンプルが確保できたカテゴリから順次分類モデルを作成していき、モデルのテスト性能が十分だった場合はそのモデルを利用し、以降のアノテーションで事前にそのカテゴリと予測された商品を除外する処理を入れました。 こうして得られた学習データのカテゴリ分布は実際のカテゴリの事前分布と大きく異なることになるため、学習時のミニバッチの作成部分でサンプルサイズの調整を行いました。 モデルの学習とテスト BERTのファインチューニング 分類モデルには事前学習済みのBERTをファインチューニングしたものを使用することにしました。 BERTをはじめとしたニューラルネットベースのモデルの利点としては テキストの文脈や単語の前後関係などを考慮できる点 凝った前処理が不要である点 kaggleなどのコンペで多用されており、分類タスクにおける性能の高さが担保されている点 使いやすいライブラリ（主にHugging FaceのTransformers）が存在し、ベースモデルやタスクの変更、モデルの改造なども柔軟に行える点 使いやすい日本語の事前学習済みモデルが存在する点 などが挙げられます。 また、今回は導入していませんが、いずれテキストだけでなく商品画像も利用したマルチモーダルなモデルにすることも視野に入れています。 *3 ラベルのついたデータセットをtrain/evalに分け *4 、商品のタイトルおよび説明文を結合したテキストデータを簡単に前処理し、PytorchのDataset化した後でtransformersのTrainerクラスにベースモデルと各種パラメータとともに渡します。 学習は社内のオンプレGPUマシン（RTX3090）を使用しました。 ファインチューニング部分の実装例 import pandas as pd from transformers import TrainingArguments, Trainer, AutoModelForSequenceClassification, AutoTokenizer, EarlyStoppingCallback, ProgressCallback class BertClassifier : def __init__ (self, target_label: str , model: str , tokenizer: str , num_labels: int ): self.model = AutoModelForSequenceClassification.from_pretrained(model, num_labels=num_labels) self.tokenizer = AutoTokenizer.from_pretrained(tokenizer) self.item_category_collator = ItemCategoryCollator(self.tokenizer) self.model.config.id2label = { 0 : f "not_{target_label}" , 1 : target_label} def fit (self, df_train: pd.DataFrame, df_eval: pd.DataFrame, early_stopping_patience: int , training_args: TrainingArguments) -> None : dataset_train = ItemCategoryDataset(df_train) dataset_eval = ItemCategoryDataset(df_eval) trainer = Trainer( model=self.model, args=training_args, compute_metrics=self.metrics, train_dataset=dataset_train, eval_dataset=dataset_eval, tokenizer=self.tokenizer, data_collator=self.item_category_collator, callbacks=[ EarlyStoppingCallback(early_stopping_patience=early_stopping_patience), ProgressCallback()], ) trainer.train(ignore_keys_for_eval=[ 'last_hidden_state' , 'hidden_states' , 'attentions' ]) def evaluate (self, df_test, batch_size): ... def inference (self, df_inference, batch_size): ... モデルの性能評価 作成したモデルの性能を検証するためのテストデータは学習データセットと同時期の商品群および比較的最近の商品群からのランダムサンプルの2種類を用意しました。 *5 複数の正解ラベルがついた1つの商品に対して8つの2値分類モデルで推論を行い、モデルの出力が閾値0.5を上回ったラベルと正解ラベルを比較する形で性能評価を行いました。 商品カテゴリの分類はマルチクラス・マルチラベルの分類タスクであり、ラベルは不均衡であるものの誤分類コストについては不正検知のようにそこまで非対称性があるわけではないという点を踏まえ、性能評価の指標としてはミクロ/マクロのf1スコアを重視しつつ、ミクロ/マクロの適合率（precision）、再現率（recall）やラベルごとの適合率、再現率なども参照しました *6 。 テスト結果の例 scores precision recall f1-score micro_avg 0.882 0.885 0.884 macro_avg 0.746 0.742 0.732 weighted_avg 0.884 0.885 0.882 数値に対応するイメージ ● 全体的に漏れなく検出されている（どの商品を見てもきちんとラベルが付いている） ● 全体的に誤分類が少ない（デタラメなラベルが少ない） ● 極端に検出漏れがあるクラスがない（特にラベルが付きにくいカテゴリが少ない） ● 極端に誤分類が多いクラスがない（特にデタラメなラベルがついているカテゴリが少ない） 全体の多くを占めるファッション系のスコアが高いためミクロf1スコアは高い一方、一部分類が難しい少数派のカテゴリのスコアが低くなったため、マクロf1スコアは比較的低い値となっています。ミクロf1スコアをキープしたまま分類が難しいカテゴリのモデルを改良し、マクロf1スコアを改善していくことが今後の課題となります。 gokartを利用したパイプラインの構築 今回は2値分類モデルを複数組み合わせることでマルチラベル分類モデルを作成しているため、全体として以下のように若干煩雑なワークフローとなっています。（実際には画像ベースのモデルの検証など間に色々と実験を挟んでいるのでよりカオスです。） モデル作成パイプライン こうしたワークフローをうまく整理し、他のメンバーが手元で作業を再現しやすくする目的で、画像などの生データのバージョン管理に Data Version Control を利用し、ワークフローの実装にはエムスリーさんが開発されているオープンソースのパイプラインツールである Gokart を利用させていただきました。 gokartはS3との連携も容易なため、学習したモデルのチェックポイントをそのまま推論基盤から利用することでモデルのデプロイやバージョン管理もスムーズに行うことができました。 AWS Batchを利用したバッチ推論基盤 DataStrategyチームではバッチ処理は基本的にFargateを使用していますが、今回は処理にGPUインスタンスが必要となり、残念ながらFargateはまだGPUに対応していないため、今回はAWS Batch+EC2のGPUインスタンス（g4dn）を利用しました。 常時推論対象となる商品をSQSに保存していき、1日に1回AWS BatchからGPUインスタンスを複数台起動しバッチ処理を行なっています。 推論部分に関してはtransformersの TextClassificationPipeline を使用するとかなりすっきりと実装することができます。 推論部分の実装例 import pandas as pd from torch.utils.data import Dataset from transformers import TextClassificationPipeline from transformers.modeling_utils import PreTrainedModel from transformers.pipelines.pt_utils import KeyDataset from transformers.tokenization_utils import PreTrainedTokenizer def inference ( df_inference_target: pd.DataFrame, model: PreTrainedModel, tokenizer: PreTrainedTokenizer, target_label: str , batch_size: int = 16 , device: int = 0 , ) -> pd.Series: result = [] classifier = TextClassificationPipeline( model=model, tokenizer=tokenizer, framework= "pt" , task= "item_category" , batch_size=batch_size, device=device, num_workers= 2 ) dataset = ItemCategoryDataset(df_inference_target) tokenizer_kwargs = { "padding" : True , "truncation" : True , "max_length" : tokenizer.model_max_length, } for out in classifier( KeyDataset(dataset, "text" ), batch_size=batch_size, **tokenizer_kwargs ): if out[ "label" ] == target_label: score = out[ "score" ] else : score = 1.0 - out[ "score" ] result.append(score) return pd.Series(result) 推論された結果は社内のデータウェアハウスに保存され、他のデータと合わせた分析や、Lookerを使用したダッシュボード化などに利用することができます。 おわりに 今回は機械学習モデルを利用した商品カテゴリの推論基盤に関する取り組みについてご紹介させていただきました。 今後に向けて より詳細なカテゴリの分類 データセットの拡大（精度の向上） 商品画像の利用（マルチモーダル化） モデルの精度監視と継続的アップデート Out of Distributionの検知 などなど色々と課題は残っていますが、ひとまず今まで把握できていなかった商品単位の粒度まで解像度を上げた分析が可能となり、既存の別の機械学習モデルの特徴量として使用したり、検索や推薦の精度を上げたり、カテゴリが設定されていないショップのジャンルを推論したりと色々な用途で活用が見込めそうです。 さて、DataStrategyチームでは機械学習エンジニアとして一緒に働いてくださる方を積極採用中です。カジュアル面談も実施しているのでぜひお気軽にご連絡ください。 募集一覧 / BASE株式会社 明日は @yuzuy @ayako-hotehama の記事が公開予定です、ぜひご覧ください。 *1 : こちらの記事を参考にさせていただきました。 https://qiita.com/mo256man/items/b6e17b5a66d1ea13b5e3 *2 : セット商品やスポーツウェアなど、複数のカテゴリにまたがって属する商品も存在するためマルチラベルとしました。 *3 : timm のモデルの出力を正規化してconcatするなどナイーブな手法は色々試したものの、BERT単体のモデルを上回らない結果となりました。悲しい。 *4 : 同じショップがtrain/evalに分かれないようショップのIDでGroupFoldしています。性能検証で使用したテストデータにも学習時に使用したショップが含まれないようにしています。 *5 : 登録時期によるデータドリフトの影響も見たかったため。実際はそこまで影響はなかったので最終的に1つのテストデータにまとめてしまいました。 *6 : 各種スコアの定義は sklearnのdocment が参考になります。

この記事は、 BASE Advent Calendar 2022 の18日目の記事(その2)です。 SRE Group の ngsw です。 先日ネットショップ作成サービス「BASE」は10周年を迎えました。 「BASE」サービスリリース10周年 ～「好きが、売れる。」をコアメッセージに特設Webサイトの公開とクーポンキャンペーンを開始～ | BASE, Inc. 10th Anniversaryクーポンキャンペーン は現在すでに終了しています 好きが、売れる。BASE・10周年特設サイト せっかくの10周年です。ちなんだ記事を書けたら面白いかなとSRE関連のIssuesを振り返っていたのがこの記事のはじまりでした。 BASEの10年分のシステムの課題を読者の皆さんと共有できたならば面白いかな、というのが(後付けの)動機です。 SRE関連のIssuesはGitHub移行後の2016年より存在し、2022.12現在で4108個存在していました。2016年から7年弱分のIssuesからBASEの課題の移り変わりなど当時の状況を踏まえつつピックアップして紹介いたします。 1 誤解を与えてしまうといけないので補足しますが、この記事内で「BASEでは」と記述されている場合、意味するのはサービス「BASE」のシステムまわりの話題であり、それを担当し責任をもつSREや開発陣の話題となっています。 組織であるBASEには、Data StrategyグループやBASE BANKセクションも存在し、それぞれが別のシステムを担当し管理しています。ある点においてサービス「BASE」のシステムよりもモダンな構成であったりしますので、事前に補足いたします。 AWS関連について BASEは当初短い期間のオンプレミス時代以降、ずっとAWSで運用されてきました。いくつかのAWSアカウントが存在しますが、その中で最古のAWSアカウントの請求書日付をみてみると、2013年03月となっています。時間を追って費用をみていくと本格的に利用がはじまったのが2013年08月であろうと思われます。 VPC移行期(2016〜2017) BASEはオンプレミスからAWSへの移行からしばらく、Classic環境で稼働していました。 そこからVPCへの移行計画がはじまります。 VPCに本番RDS移行 VPC移行ステップ VPC移行 VPC移行第一ステップ VPC移行にあたりアプリケーションエンジニアにDBのホスト変更を依頼する VPC移行にあたりアプリケーションエンジニアにredisのホスト名を変更してもらう VPCにMySQLを移行する[スナップショット版] VPC移行 / 当日 ClassicとVPCとの違いは以下をご確認ください。 EC2-Classic - Amazon Elastic Compute Cloud ここにある様々な制約の解決を目的とした移行計画となっており、おおよそ1年間をかけ対応が行われました。 切替作業当日は深夜メンテを行い、サービス停止のもと無事移行が完了しました。 リソース整理Issuesの登場(2017〜) VPC移行という仕事を終え余裕ができたからかわかりませんが、AWSリソースを整理する目的のIssuesがたちはじめました。 開発アカウントのIAM整理 AWS本番環境のACM整理 使用していないセキュリティグループの削除 セキュリティグループ - 無制限アクセス IAM Access Key 不要なものは無効化/削除 開発速度を優先した結果、性善説に基づく牧歌的運用のつけをここから自覚しはじめる時期という、ある種あるあるな話題が、例にもれずBASEにも立ちはだかった瞬間でした。ここから2022年の今日においても、運用を続ける以上無視することができない一生ものの課題となっています。 2019年ごろには Trusted Adviser を、2021年には AWS Well-Architected を利用して、単純な整理だけでなくセキュリティ強度と開発速度の向上などの相乗効果なども視野に入れ活動をしています。後述しますがIaCなどはこの点を強く意識したものです。 うっかり対応期(2020〜） この頃になると、後手にまわって対応が遅れてしまったな、というIssuesがいくつかみられるようになりました。 [SES]v3署名非推奨のためv4署名への切替 [VPN]AWS Client VPNの調査 SubnetのIP枯渇問題の解消 v4署名切り替えに関しては、AWSからの周知メールにより発覚しました。 AWS Client VPNの調査が必要となったのは、2019年02月コロナ禍におけるリモートワーク全面切り替えのために対応する必要がありました。SubnetのIP枯渇問題は、コロナ禍における想定以上の急成長の対応で、増設を行ってきた結果黄色信号となったため対応した形でした。 ぎりぎりで回避できた点は不幸中の幸いですが、このような不必要な成功体験が積み重なっていくことは不幸中の不幸と言えるでしょう。 Linuxまわりについて ntpの設定 CentOS7のcoreでカーネルパラメータを追加 /proc/sys/net/ipv4/tcp_max_syn_backlogの値を変更 カーネルパラメータチューニング chrony導入 kernel_parameter EC2における単位時間あたりの名前解決制限対応 EC2における単位時間あたりの名前解決制限の対応 - BASEプロダクトチームブログ で対応内容を解説しています こちらについても前項で最後に先述したことと同じことが言えるでしょう。Issuesを追う限りは問題がでるまで設定が抜けていたんだな、という感想を持ちます。 この手の問題で難しいところは 決め打ちである程度まとめて事前に入れちゃう派 問題が起きてから入れる派 の二通りがあって、ngswはどちらかというと前者、BASEはどちらかというと後者であるという形です。 ただこれも結果論のところがあり、事前に設定しておくことで暗黙的に処理されることが果たして嬉しいのかどうか、という交換ではあると思います。 EC2デプロイまわりについて BASEは少なくとも2016年ごろより、当時の担当者である @srockstyle によるIaCが進められていました。EC2まわりのほとんどがChefで記述、管理されており、2017年ごろには Provisioning や Deployment を chat-bot 経由で行えるよう整理されていきました。 作り込みが相当に入っており、自前のB/G DeploymentやRollback機能や、単純な増設機能を有しています。 自動デプロイメント改善案をつくる 2 Mackerelを自動退役する デプロイした時のPRリストを取得＆Slack通知する デプロイおよびアーキテクチャの改善プロジェクトを発足する プロビジョニングとデプロイの切り離し ここでシステムの説明をしましょう。 chat-bot(Hubot) api server(Rails) aws-sdk DB (MySQL) chef-server(Chef) Slackからchat-botへ投稿されたリクエスト文言を元に、api serverへさまざまな実行指示が飛びます。 api server はAMIのもととなるEC2へデプロイ用のレシピを実行するchef-clientを投げ終了を待ちます。 api server は終了を検知したのちaws-sdkを利用してAMI取得指示を出します。 api server はaws-sdkを利用して3で作成したAMIをもとにB/Gデプロイメントを行います。 api server は3〜4の間で、Insntace idやAMIの世代IDなど必要な情報をDBに書き込み管理のために利用します。AMIの世代IDがあるため、rollbackが可能となっています。 ほぼほぼの機能が2018年の段階で固まっており、2020年ごろより改修をいれ続け現在も現役で利用されています。その一方で様々な限界も見えつつあるのが現状であり、EC2からECSなどの乗り換えとあわせてデプロイ周りの見直しなどが必要なのではないか、というのが2022年現時点での課題であります。 ただ単純にEC2をECSにうつし、デプロイ周りを別機構にすればそれでOKという未来でもないよう考えており、開発陣からみた利便性と、システム全体のパフォーマンスとを比較勘案する必要があるでしょう。 当システムのB/Gデプロイメントの実現についてはここで解説されています。 Chefとnginxで作るPHPアプリケーションのReliable Blue Green Deployment - Speaker Deck IaCについて chefの話題がでましたね。ついでなのでBASEにおける IaC 化対応について、どのような歴史があるのかご紹介したいと思います。 Chef期(2016〜) Chefのレシピ；Webサーバ関連：簡単な変更のみ Chefレシピ：Fluend導入周り Chefレシピ作成：deploy_branch（デプロイするレシピ） Chefのレシピ：基本部分 2016年のこの時点でChefまわりはほぼ固まっております。2022年現在でもChefは利用され、細かなリファクタリングなどを繰り返し整理運用されています。課題感については先述したデプロイまわりと重複するので割愛します。 AWS リソースまわりもIaC化したい(2019〜) [pj_lottery]SQSキュー、SNSトピック作成依頼 売上データダウンロードAppsに関してのAWSリソースの追加依頼 [売上データダウンロードApps]S3 bucket追加と設定 [売上データダウンロードApps]sqsの追加と設定 [#base-apps-google_shopping_ads]SQSキュー、SNSトピック作成依頼 [SNS, SQS作成依頼]顧客管理で使用するSNS, SQSのstg/prdでの設定 [SNS, SQS作成依頼]リマインドSMS送信で使用するSNS, SQSのstg/prdでの設定 というような感じでS3やSQS、SNSなどのリソース作成依頼が、開発チームより続いたことがありました。2019年頃まではそもそも作業対応者によって構築方法がばらばらで、Web Consoleによる都度作成が行われていました。ここから作業手順の確立の意味をこめてaws-cliを利用したワンライナー構築が行われていきました。 賢明なる読者の皆さんはいま同じ感想をもっているはずです。 「他人の書いたaws-cli使い回すのやだなあ」 そうですね、そうなっていくのが自然です。自分の書いたaws-cliだって読み直すのは手間です。 ですので現在は EC2まわりはChefで AWSリソース周りはterraformで という形にして後者を進めている形です。話題は変わりますが先述しているAWS Well-Architectedもこの判断に少なからず影響しています。 terraform 移行期(2021〜) Terraform Cloud / Team & Governance Plan の稟議を出す GHAでTerraformのplan/applyを実施できるようにする 既存リソースのimportとmoduleの作成を並行してすすめていく中で、2021年当初はterraform cloudをSREメンバーでのみ利用していました。しかしながら使い勝手の部分でGitHub Actionsのほうが勝るよう判断ができたので、2022年12月現在はGHAに寄せている状態です。社内のリポジトリにGHAのお手本がいくつか存在していたことなども、この判断の後押ししたのかもしれません。 terraform化に向けての具体的な行動は、この記事からはじまったと言ってもいいかもしれません。 Terraform導入への第一歩 - BASEプロダクトチームブログ monitoring について mackerel導入期(2017〜) mackerel監視項目追加 mackerel監視設定まわりの整理(2019〜) [mackerel]service,roleの整理 [mackerel]監視項目の整理 [mackerel]internal-api-batchのmackerel-agentインストールのリファクタ [mackerel]通知グループの整理 [mackerel] アカウント周りの整理 [mackerel][監視]Apache Server-StatusにてBusyWorkersの数値を閾値にして監視アラートあげたい [mackerel]監視対象候補の洗い出し [mackerel]service*roleを整理する [mackerel]監視項目の拡充(EC2) [Mackerel]サービス影響のあるクリティカルな取得リソース、監視項目の精査及び組み込み [Mackerel][nginx]プロセス監視 BASEにおいて監視周りはmackerelに強く依存している部分がありました。ある時期から特定時間帯に負荷高騰のアラートが鳴る状態が続いており、社内でみな敏感になっていました。最終的にはその敏感さが「いま重くない？」という会話を生むようになっていました。 携わるプロダクトのシステムに、メンバー全員が関心を持つことはとてもよいことですが、 「重いなあ/重くない？/そんなことないよ？」という個々の体感に基づいた、客観軸のない会話が多発することはよくないことと言えるでしょう。そのための対策が次項になります。 「ユーザからみてサービスが重い」とはどういうことか(2020〜) 「サービスが重い」の指標となる外形監視の見直し [BASE]Mackerel + Twilioによる特定アラート時の自動架電 Twilioを利用した障害時の自動連絡網システムについて - BASEプロダクトチームブログ 外形監視を設定し、メトリクスをもつことでどのように重いのか、ユーザと近いかたちで常に同一の基準軸で「重い/重くない」の判断をつけられるようになりました。またあわせて「重い」と判断できるときにはプロダクトにとって重要な問題であると判断し、連携して架電発報するようしました。 気をつけないといけないのは、ここでのアラート対応は「重いという状態の定義ができ、それを越えたらアラートが出せるようになったね」というだけであって、「もっと速くできるんじゃないか？」ということに関しては無関心であるということです。たとえば常にレスポンスタイムが閾値98%のサービスは、アラート発報はしないが手放しで喜べるような状態ではありません。 New Relic(再)導入期(2020〜) [New Relic]chefの .name を appname に採用する [NewRelic]Apacheを利用しないPHP稼働インスタンスに対して [NewRelic]internal-api-workerだけ暫定無効化する [New Relic][operation-controller]deploy marker用のAPIを設定する New Relic AWSインテグレーションでDSアカウントのメトリクスを取得できるようにする 先述した「もっと速くできるんじゃないか？」という課題感と、「それらのアクションをより開発陣主導で行うことができないだろうか」という組織的なストレッチ目標が New Relic (再)導入という意思決定を生みました。 Issues群は主にAPM初期導入設定時のいろいろな修正です。具体的な事例は本ブログの過去記事よりご覧いただけます。 はじめてのNew Relic - 社内オンボーディングを開催いただきました - BASEプロダクトチームブログ New Relic User Group Vol.0で登壇しました #NRUG - BASEプロダクトチームブログ BASEの顧客管理はどのようにして実現されたか - BASEプロダクトチームブログ New Relic OneでDevOpsのキーメトリクス デプロイ頻度をグラフ化する - BASEプロダクトチームブログ NRUG (New Relic User Group) Vol.1に参加してきました - BASEプロダクトチームブログ レスポンス改善プロジェクトでやったこと - BASEプロダクトチームブログ 今BASEに入社してやることあるの？という疑問に答えるよ - BASEプロダクトチームブログ 商品在庫絞り込み機能のリリース振り返りと、New Relicを活用した観測について - BASEプロダクトチームブログ DBまわりについて Aurora移行(2017〜2018) 開発環境のRDSをAuroraにする 11月メンテ作業(Aurora移行) BASEのメインDBをAurora(MySQL)に移行しました - BASEプロダクトチームブログ クエリ効率化などは定期的に(2018〜) レプリカ向けるSQL SQLチューニング2019年2月 DBまわりについては2017年にRDS for MySQL時代からAurora v1(MySQL)へ移行しています。 またそれ以前からDBAを中心に細かい運用改善が繰り返し行われていました。 特にRDS時代にはストレージの残量について、意識を割かなければいけない状態だったことも強く関連していると思います。 コロナ禍の想定外の急成長(2020) 負荷問題の課題について 「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 - BASEプロダクトチームブログ この時期の話題をCTOの川口さんに振ると、決まって「記憶がないんだよね」と返ってきます。「何を言ってんだ、こういうことがあったじゃないですか」と問いかけてみるけれど、そういうわたし自身も時系列がぐちゃぐちゃであったりします。つまり我々にはこのときの記憶があまりないです。これは冗談半分であり事実半分であるのが怖いところです。Issues振り返ってみても結局よくわからないんですよね。 そんなあやふやな中でも「Aurora DB Clusterへの新規接続時の問題、これが課題だよね」というのは、確実に共通している部分でありました。 RDS Proxy導入(2022) [#pj-rds-proxy]Subnet Group / Security Groupそれぞれ [#pj-rds-proxy]ph0, ph1 [#pj-rds-proxy]RDS Proxy導入後のReader台数削減 Amazon RDS Proxy が BASE にもたらした期待以上の導入メリット - BASEプロダクトチームブログ 「満を持して」という言葉がこれほど当てはまるシチュエーションは、人生を生きるなかでそうそうないでしょう。われわれは解決方法を手に入れたのです。さらに気持ちがよかったのはRDS Proxyを導入した後に、Readerの台数を削減できたことです。 個人的には「BASEシステム改善における2022年今年一番の大仕事」と考えています。メインを担当した @tadamatu には感謝しかありません。 Costについて インフラコスト意識のたかまり(2018〜) 開発環境のAWSリソース整理と削除 Data Transferの増加について RIの方針決め 商品画像で利用しているS3のドメイン分離 Lambda makeThumbnail の廃止対応 SavingPlan算出（2021/BASE） 2021年のRI/SavingPlan纏め 2018年当時に開発環境の整備の一環で、野放図になっていたAWSリソースの削除などが行われました。先述したリソース管理の意識の萌芽とはいったいなんだったのか。やはりこの手の問題は常に付きまとうものと思うほかありません。 主にこの手の意識を高くもってシステムを見守ってくれているのが浜谷さんです。 現在はSREチームを離れて他のチームに所属していますが、予算面についてはいまも担当してくれています。 過去にはこのような記事も書いています。 TerraformでNGTのポータブル環境を作った - BASEプロダクトチームブログ コスト削減の具体事例(2022) S3ストレージタイプ移行機能検証 [S3]商品画像領域にlifecycleルール適用しINTELLIGENT_TIERINGにする 浜谷さんの過去の指摘内容であった、コスト削減案のひとつを今年完遂できたことは嬉しい話題です。 BASEではショップオーナー様が商品画像を登録する際に、本領域と解析のための別領域をS3 Bucket上に両方もっています。このうち削除可能な領域があり、この領域上のオブジェクト削除が課題となっていました。 当初は当該領域のオブジェクト削除においてaws-cliを用いることを想定して対応を進めていましたが、そもそものリスト出力ができないという状態で、しばらく手つかずの状態が続いていました。 ここで打開策として採用したのが、後付のlifecycleルールの設定で自動削除を待つというものです。削除領域が特定キー配下ということだけは確定していたので、一番手軽な方法であるという判断でした。これで相当なオブジェクト数を削除し、S3使用容量を大幅に削減できました。 しかしこのままでは結局時間稼ぎでしかないため、AWSの皆様や浜谷さんからのアドバイスを受け、INTELLIGENT_TIERINGの導入を行った次第です。 話は変わりますがわたしは前職、前々職で動画配信サービスのインフラを担当しており「頻繁にアクセスされる動画が存在し、その反面まったくアクセスされない動画がそれ以上に存在する」ということを肌感覚で知っていました。「おそらくBASEのような大小さまざまなショップへのリクエストも似たような形であろう」という点からINTELLIGENT_TIERINGの可能性を感じました。 その上で性能面で懸念があったため、INTELLIGENT_TIERINGそのもの検証とレスポンス速度の確認を行い、さらにAWSサポートより「性能差はない」「ただしオブジェクト監視の費用がかかる」という回答もいただいたことで導入を行った形です。 独自ドメインApp と Nginx について 独自ドメインApp HTTPS化対応期(2016〜2018) Certbotを試す 独自ドメインSSL基盤サーバのChef 独自ドメインSSL： ngx_mruby対応 独自ドメインSSLサーバのcore 独自ドメインSSL：の取得サーバのnginx 独自ドメインSSL：デプロイレシピ 独自ドメインSSL:rsyncサーバの実装 独自ドメインSSLサーバのchefレシピ 独自ドメインSSL CentOS7対応 / Core 独自ドメインSSL CentOS 7対応 / Rubyインストール 独自ドメインSSL CentOS7対応 / reverse-proxy対応 独自ドメインSSLのCentOS7化にむけて、coreの編集。 独自ドメインSSL CentOS7対応 / デプロイ global reverse proxyと独自ドメインSSLのwwwユーザのIDは同じでなければならないことをChefに記述する certbotのインストールをyumで yumでcertbotコマンドをインストールするようにした 独自ドメインSSL残課題 独自ドメインApps の証明書切れを事前に検知できるようにする Let's Encryptの活用により、オーナー様が持ち込んだ独自ドメイン名に対して、証明書を発行できるようになりました。もちろん証明書の発行だけでなくWebサーバで証明書を認識できなくてはなりません。その手のシステムを開発したのが先ほども登場した @srockstyle です。 詳しくは本ブログ内の以下エントリがわかりやすいかもしれません。 独自ドメインのショップでhttpsでアクセスできるようになりました - BASEプロダクトチームブログ 対応当時のリリースはこちらです。 「BASE」が独自ドメインのSSL証明書の無料発行・自動管理を開始 ‐常時SSLで安心安全なネットショップ運営を‐ | BASE, Inc. この機能がもしなかったと仮定した場合、「ショップ開設を行おう」「このまま引き続きBASEを使っていこう」というショップごとそれぞれの意思決定が、どれだけの数YesからNoになっていたことでしょうか。ショップにとって独自ドメイン名の持ち込みは、サービスにロックインしないための最後の砦とも言えるので、その手段を安全に提供できていることをわれわれはもっと誇っていいのかもしれません。 さらにはその誇りを実現してくれているのはLet's Encryptの存在であるという気持ちを、忘れてはいけません。スポンサーになろう。 Let's Encrypt 対応期(2019〜2020) [domainssl] Let'sEncrypt 2020.02.29 CAA Rechecking Bug [domainssl]2020.09末期限 / Let's Encrypt延命のために必要なこと Let's Encrypt 周りに関して、運用不要というわけではありません。小さな悩みごと、対応しなければならないことにいくつかぶち当たる場面がありました。 CAA Rechecking Bug 2020.02.29 CAA Rechecking Bug - Incidents - Let's Encrypt Community Support 認証局のルート証明書の切り替え問題 外部のブログ記事でいうと songmu さんのブログエントリがわかりやすいです Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々 Let's Encryptの証明書切替周りその後 | おそらくはそれさえも平凡な日々 このあたりは既に懐かしく思えますね。 CertbotからLegoへ(2021) [EOL][domainssl]certbot-autoが1.11.0で非推奨になる [domainssl]certbot->lego置き換えのリリース計画 先述した個別の対応とは別に、Certbotまわりのバージョン管理などで億劫に思えることが多くなりました。具体的にはCertbotとPythonのバージョンとの話題です。BASEではCentOSを利用している背景があり、Pythonのバージョンを云々するのがちょっとめんどうな点があります。 上記にいつまで悩まされるか、ということを損失と捉え、ここでLegoに乗り換えることにしました。 ここで誤算がありました。「Certbotはかなり親切にディレクトリを切ってくれるつくりだったんだな」というところです。このLet's Encryptを利用した独自ドメインAppのシステムは、Certbotのディレクトリ構成に強く依存しているつくりになっていました。 ですのでLego導入時にCertbotのディレクトリ構成を再現させる補助となるShell Scriptをあわせて配置して、Railsに実行させるようにするなどの工夫が必要となりました。 Nginxのアップデート(2020〜2022) IP個別に単位時間あたりのリクエスト数を制限する 1.15.x -> 1.19.x http_limit_req_module 導入時に limit_req_dry_run を利用したかったため nginx 1.19.6 -> 1.21.5 にアップデートするまでの道のり nginx-buildとngx_mrubyの対応のため 証明書が配置され、ショップの正面玄関として重要な存在となったNginxですが、現行のバージョンと乖離した状態になっていました。またそもそもの動機として limit_req_dry_run を採用したいためアップデートが必要となってきました。nginx-buildとngx_mruby、またpcre、OpenSSL、zlib、ngx_dynamic_upstreamとそれぞれのバージョンで整合性を持たないといけないため、buildを行っているchefレシピの修正を行いました。この修正で1.19.xおよびOpenSSLのバージョンを最新のものにアップデートすることができ、目的となる http_limit_req_module および limit_req_dry_run の導入に成功しました。 また1.19.6利用時にpcre問題が発生しました。こちらの catatsuy さんのエントリが問題発生当時の状況を把握する参考になります。 nginxとPCREについて 最終的にはわれわれはpcre2を採用する、つまりNginxのアップデートをし、CHANGES を睨んで確認事項を洗い出し必要なディレクティブやパラメータの変更を行うよう対応しました。 また副次的な恩恵として、OpenSSLアップデート対応をカジュアルに行えるようになったことがあげられるでしょう。 結びに 10年間のうち7年弱のIssuesを振り返ってみました。ここに書ききれなかった日々の小さな対応や、ログ基盤や新カートまわりの話題などもあったわけですが、SREの活動を振り返るには充分であろうと自負があります。 ここには見栄も背伸びもありませんので、読者のみなさんの「このあたりの施策が足りないんじゃないか」「俺だったらこうやってもっとうまくやったな」などの感想は妥当かもしれません。ですのでもしよかったらBASEで一緒に実現していただけると嬉しい気持ちです :-) <ﾎﾝﾄﾀﾞﾖ A-1.BASE_SRE - BASE株式会社 A-1.BASE_SRE※マネージャー候補 - BASE株式会社 明日19日は @glassmonekey 、 @take61___0 のお二人のエントリです。 BASEアドベントカレンダー2022を引き続きお楽しみいただければ幸いです。 ほんとうに記事の書きやすさを優先してかなり恣意的に間引いているので、関連するIssuesは実際にもっとあります。ご了承を。 ↩ ちなみにこれが Issues ID 1 です。多忙な開発主要メンバーからデプロイ業務をうまくはがす必要があったそうです ↩

この記事は、 BASE Advent Calendar 2022 18日目の記事です。 今日担当するのはバックエンドエンジニアの cureseven です。 2022、チャレンジし続けたスクラム phpcon沖縄2022のスポンサーセッションで、「 Gather × Code With Me × ペアプロのお誘い で最高です 」という発表をさせていただきました。 本記事は後日談のような内容です。どのように開発を進めているのかの補足として発表資料を見ていただけると良いと思います。 また、アドベントカレンダー9日目では私たちのチームがどんな雰囲気のチームかを覗くことができます。合わせてご覧ください。 https://devblog.thebase.in/entry/2022/12/09/110000 さて、私のチームは、phpcon沖縄2022発表当時のプロジェクトを終え、新しい機能開発に着手し始めました。 今回のプロジェクトは開発規模も大きいため、以前とは違い2チーム合同でのプロジェクトになっています。 登壇時うまくいっていたことも2チーム合同となるとうまくいかないことも多く、その中でチャレンジしていることについて触れたいと思います。 2チーム合同になり問題になったこと コミュニケーションコストが増えた 1チームは5-6人で構成されているのですが、2チーム合同となるとAmazonでいうところの ピザ2枚ルール には当てはまらなくなってきたと感じました。人数としてはピザ2枚の範囲内かもしれませんが、開発してきた背景の違う2チームが合流したので人数関係なくコミュニケーションコストが発生するようになりました。 2チーム全体で合意・意思決定を行うことは、小さいチームより時間がかかります。さまざまな意見が出て良いこともある反面、スクラムのスピード感にはマッチしないと感じました。 作業内容が被り、コンフリクトが発生した 仕様が定まっていないところから始まったプロジェクトでした。その段階でリファインメントし、開発にちょっとずつ着手していこうという状態で、作業できる箇所が小さかったのでコードもストーリーも近しいものに着手することになってしまいました。作業を並列化するのも難しく、コードのコンフリクトも起こりました。 コーディングルールが2チーム間で異なり、レビューが前に進まなくなった これまで積んできた経験が異なる2チームが同時にレビューすることで、設計思想のすり合わせのコストがかかるようになりました。 工夫していること 私たちのスクラムは、1チームでのスクラムを無理やり拡張させたものではなく、2チーム合同でLarge-Scale Scrum(LeSS)だと改めて認識できました。大規模スクラムのエッセンスを取り入れながら、経験を元に作業効率を上げるための取り組み（プラクティス）を行っています。 チームごとに、全く違うテーマに取り組む 現状はプロジェクトのプロダクトバックログにラベリングし、各ラベリングされたセクションごとに作業チームが別れている状態です。 プロジェクトとして一番優先して作りたい機能はあるものの、複数チーム合同で着手すると時間がかかったという経験から、次の優先度のラベルの機能開発に着手することで全体としての作業効率が上がってきています。 お互いのチームを信頼して任せられるようになりました。 ラベリングの1つとして、フロントエンドが先行してUI実装していくものがあります。このおかげで、課題の発見を早めることができています。また、バックエンドが着手するタイミングで機能要件が明瞭な状態にしておくこともできます。 トラベラーやってみた LeSSのエッセンスとして、トラベラーというものがあります。 https://less.works/jp/less/framework/coordination-and-integration 開発経験・知識がある人がチームを跨いでアイテムに取り組んだり意見を言う役割を負う人のことです。 私は１スプリントだけトラベラーに挑戦してみたのですが、タスクの引き継ぎに有効でした。また、作業メンバーが両チーム奇数人だった場合、トラベラーを一人派遣することで偶数人ずつになりペアプロのレーンが増えると言う副作用も享受できました。 デイリースクラムでは、トラベラーを行っている期間自分のチームへのコミットが薄くなった場合、議論に参加しにくくなってしまいました。その時はトラベル先のチームのデイリーにのみ参加するのが良いかなと思いました。 今は、アプリケーションにおけるクラス設計の意思決定をする有志チームがあり、継続してトラベラーのような役割を果たしてくれています。 作業に集中できる時間を少しでも多くする 2チーム合同でプロジェクトを進めていくために、チーム合同での振り返りとトライを決める「オーバーオールレトロスペクティブ」、プロジェクトとして何を達成したいかをすり合わせる「オーバーオールプロダクトバックログリファインメント」が各スプリントにセットされていますが、エンジニアの参加者は各チームランダムな代表者数名としています。決まったことはデイリースクラムやslackで非同期に共有、気になったら閲覧できるようなミーティングの録画を共有しておくことで対応しています。 2チーム合同になったことで増えがちなミーティング時間も、慣れてきた段階で代表者制にすることで節約できるようになっていきました。 最後に 2022では、BASE全体としてスクラムの導入が積極的に行われていくようになってきました。 スクラムは、経験を大事にします。ナレッジを共有しながら、チームに合わせたスクラムの在り方を模索していきたいです。まだまだ生産性を上げていきたいので、デイリースクラムやレトロスペクティブで議論していきたいです。

この記事は BASE Advent Calendar 2022 の17日目の記事です はじめに こんにちは！Pay ID 決済 バックエンドエンジニアのzan( @zan__gi ) です。 今回は、BASEに入社して「Speak Openly」っていいよね！と思った経験を綴ります。 BASEでの働き方や開発組織の雰囲気を少しでも伝えることができたら幸いです！ そもそも Speak Openly とは Speak Openly とは BASEのプロダクト作りと3つの行動指針のひとつで、 「 素直に話すこと。より良い結論を得るために、その場で意思を伝えよう。 」です！ BASE株式会社 会社紹介資料 も見ていただくとよりわかりやすいです。 Speak Openly の良いところ3選 現在携わっているプロジェクトでは実はフロントエンドを担当しています。 （現在進行中なので、プロジェクトの詳細は割愛させてください！） BASEに入社してプロダクト開発（しかも入社後初プロジェクト＆フロントエンド！）を通じて 「Speak Openly」っていいよね！と思ったので、今回はその中で3選、紹介します！ #ダサいぞ Speak Openly なSlackチャンネルのひとつとして、#ダサいぞ があります。 #ダサいぞ は「ユーザーとの接点全てにおいて、ダサいところを報告して直していく！Speak Openly！」をトピックとしたチャンネルです。 フロントエンド開発への恩恵として、ダサいパターンが蓄積されているので、センスを磨けた気がします。 また、実際に「ダサいぞ」といっているところを見ると、「私もいいプロダクトを作るために素直に話そう！」と前向きになることができます。 （↓2019年から多くの「ダサいぞ」が報告され、改善されている。） 暗黙知に触れやすい 開発以外にも共通して言えることですが、プロダクト開発を進めていると、暗黙知を知ることができると嬉しい場合があると思います。 BASEではpublicなSlackチャンネルが多く、Speak Openlyにコミュニケーションしているので、過去のプロジェクトのチャンネルを探ることで暗黙知に触れることができ、プロダクト開発にも活かしやすいと感じています。 また、プロジェクト参画者の発言を追うこともできるので、一方的に既視感を得ることができ、初めてコミュニケーションを取る際の心理的なハードルも少し下がります。 （↓privateなコミュニケーションチャネルばかりだと、コードやドキュメント等の成果物以外の情報を辿りにくい） 心理的安全性 現在、PdM、デザイナーやエンジニアと共にフロントエンド開発を一緒に進めていますが、 議論やレビューなどの際、「Speak Openly」という共通の行動指針は、 コミュニケーション相手も「Speak Openly」で行動してくる、という心構えでいれるので、ある種の心理的な安心感があります。（もし議論が白熱してヘコんでも、そこはBe Hopefulな気持ちで！） また、バックエンドを担当してきて、コードの美しさ、みたいなところの議論が多かったですが、 フロントエンドでUI、UXがイケてない、みたいな議論や検討ができているのは新鮮です。 文化的行動様式に近い話ですが、組織文化に裏打ちされたコミュニケーション基盤はやはり強い、と実感しています。 （↓多くの人が Speak Openly な行動をしているので、自分も Speak Openly になりやすい） 最後に 冒頭にも書きましたが「Speak Openly」っていいよね！と思った経験でした！ シンプルな哲学と行動指針なので、組織文化としてしっかり根付いていて、プロダクト作りに活かせていると感じています。 さて、明日は @chihiro さんの記事が公開予定です！お楽しみに！

はじめに この記事は BASE Advent Calendar 2022 の15日目の記事です。 こんにちは！船坂（ @takumi_funasaka ）です。BASEでプロダクトマネージャーをやっています。 先日、所属しているプロジェクトチームで「チームの能力を自己評価し、チームとしての今後の成長方針を決める」ワークショップをやってみました。 これが結構良かったので、ご紹介させてください。 ざっと目を通していただくと、チームの課題を抽出したり、いいチームのどこがいいのかを知るためのヒントになるかもしれません。 チームがいい感じ、な気がする 最近、自分が所属しているプロジェクトチームがとてもいい感じだなぁと思っています。 やるぞ！感もあるし、アウトプットも良い。苦難や衝突もたくさんありますが、それを踏まえても、良いチームになってきていると感じていました。 ただ、 チームの何がいい感じなのか、よく分からない のです。 現在、BASEではプロダクト領域ごとに組織をわけており、僕たちのチームもプロジェクトが終わったらすぐ解散ではなく、しばらく続いていく予定となっています。 そのため、現状の理解のままではなく、チームがいいと感じる要因を明らかにし、同時に課題も認識することで、中長期的なチームの成長方針をたてたいと考えました。 チームについて考える まずは、チームについて疑問があったので、調べながら自分の一旦の考えをまとめてみました。 「チームってなんなんだろうか。人の集まり？」 → チームとは、 ただ人が集まっただけではなく、目的を達成するために密に協働する人の集まり である 「じゃあいいチームってどういうチームだろう？」 → いいチームとは、 チームの存在理由である「成果」を上げることができ、そして評価されるようなチーム である 「いいチームかどうかを知るには、どうしたらいいんだろう？」 → いいチームにはいいチームワークが存在している。チームワーク能力を測ることがチームの機能性を知ることに繋がる。 このあたりの前提に立つために、いくつか研究を参考にさせていただきました。（後述） チームワークを評価するワークショップを実施してみた さて、ようやく本題ですが、自分たちがどういうチームなのかを明らかにするため、チームワークの機能性を評価するワークショップを設計してみました。 ワークショップの流れ ワークショップはチームのメンバー全員で行いました。 僕たちの場合は、 プロダクトマネージャー×1 デザイナー ×1 エンジニア ×5 QA ×1 の計8人で実施しています。 ワークショップの流れは以下になります。 チームワークについてみんなで学ぶ 事前に用意したチームワークの要素※1ごとに、その要素に関連する具体的な行動やコミュニケーション、できていないことなどをPositive / Negativeで振り分けて書き出す 全てのチームワーク要素について書き出し、全員で読む 各要素について、今の自分達のチームは何点になるか、1〜5点で投票する 意見が割れたところに関して、メンバー同士で意見交換をする 議論後、チームとしてのスコアを決定 チームとして不足している能力や今後獲得していきたい能力について、話し合う ※① チームワークの要素として、こちらの論文（ 山口裕幸（2007）、チーム・コンピテンシーと個人のチームワーク能力 ）に記載されていたもの利用させていただきました。 結果：チームの今を知る やってみた結果、僕たちのチームのスコアは下記のようになりました。（各5点満点。各要素の詳細な解説は省きますが、後述する資料を是非ご覧になっていただければと思います。） チーム指向性 職務指向性 4 対人指向性 5 チーム・リーダーシップ 適切な指示 3 対人的配慮 3.5 チームプロセス モニタリングと相互調整 4 職務の分割と明確化 3 フィードバック 4 知識と情報の共有 3 このように スコアを定量化・可視化したことで、チームについて俯瞰することが容易になり、メンバー同士の議論もしやすくなった と感じました。 メンバーの肌感ともほぼ一致した数値感になり、非常に参考になりました。 ディスカッション：チームについて話し合う このスコアを元に、更にチームで感想や今後チームとして獲得していきたい能力について、ディスカッションを行いました。 結果を見ながら、僕たちのチームは今後の方針として チーム・リーダーシップに課題があるので、今後注力して伸ばしていく チーム指向性が高いことを今後も大事にしていく チームプロセスもまだ改善途上であり、継続的に向上させていく ということをメンバーで合意できました。 これはとても大きな意味があったと感じています。 ワークショップの感想 実感としては非常によい機会になったなと思っています。 個人的に感じたことや、メンバーからあがっていた感想・意見を紹介します。 チーム指向性が比較的高いのはとても良いと感じていて、自信になった。普段から目的の意識付けやそこにコミットする姿勢を全員で共有できていることを再実感できた。 リーダーシップを取るということに対して、メンバーが課題に感じていることが明らかになった。現状は満点でなくても、全員で伸ばしていくという意識付けができたことはとても良かったと思っており、これが今回のワークショップの一番の成果だと感じている。 チームワークというチームを主語にした能力をトピックとして取り扱ったので、個人の能力に言及することなく、課題について議論できた。心理的安全性を保ちながら、オープンに今後について話せた実感がある。 「適切な指示」について考える中で、タスクを全部自分で巻きとろうとしてしまう癖に気づいた。これからは適切にメンバーを頼り、チームとしてもっと効率的・持続的にタスクをこなしていけるようにしたいと思った 特定のメンバーがチームワークという点で大きな役割を果たしているということが明示的になったのが良かった。課題ではあるが、認識できたので、他のメンバーも今後意識的に経験を積みながらチームを改善していけると思う。 チーム力は悪くはないことがわかったが、個人でみると偏りがあることも明らかになった。これからは偏りを分散させることを意識しながら、チームのいいところを高めていきたい。 ⁠ワークショップ後のFigjam（雰囲気だけ） 最後に 今回はふわっとした「チームがなんかいい感じ」の要因を明らかにするために、チームワークの機能性を知るワークショップを実施してみました。 チームワークの機能性をスコアとしてプロットしたことは、メンバー全員で今を見つめ、今後進むべき方向性のすり合わせをすることを容易にした感覚があり、重要なキーだったと思っています。 また、実は僕たちのチームは来年から少し構成が変わる予定があったため、状況が変わってもパフォーマンスを出し続けていくために、やるべきことを考えたいという目的もありました。 これは、ワークショップのstep2において具体的なコミュニケーションをベースに書き出す設計にしていたことで、チーム構成の変動後、どのようにチームワークが変わりうるかを予想することもでき、良かったと思っています。 さて、明日は @gimupop の記事が公開予定です！お楽しみに！ Appendix: 参考にした情報と、学んだこと おまけとして、今回このワークショップを設計するにあたって調べた情報と、学んだことを書いておこうと思います。 Google re:Work『効果的なチームとは何か』 学んだこと： "チーム: メンバーは相互に強く依存しながら、特定のプロジェクトを遂行するために、作業内容を計画し、問題を解決し、意思決定を下し、進捗状況を確認します。チームのメンバーは、作業を行うために互いを必要とします。" 効果的なチームに必要な要素は５つ 心理的安全性 相互信頼 構造と明確さ 仕事の意味 インパクト チームの効果性には「誰がチームのメンバーであるか」よりも「チームがどのように協力しているか」のほうが重要である チームワークの教科書 学んだこと： チームの成果を左右するコミュニケーションの要素は コミュニケーションの「熱量」 チーム全体への「関与」 外の世界へと向かう「探索」 チームメンバー同士が長い期間固定されていると、パフォーマンスが向上する しかし、同質化が進み、新たな学習を妨げることがある チームに『異端者』がいると、議論が活発化し、パフォーマンスが向上する 他にも色々学べました 山口裕幸（2007）、チーム・コンピテンシーと個人のチームワーク能力 学んだこと： チームワークの要素とモデル（ワークショップで利用） チームワークの測定項目群（ワークショップで利用） チームワークは個人のチームワーク能力にも影響を受けるが、メンバー同士の相互作用により、個々の能力を超える大きな影響を受けることが少なからずある

はじめに この記事は BASE Advent Calendar 2022 の14日目の記事です こんにちは。BASEの資金調達サービス「YELL BANK」チームでPMM（プロダクト・マーケティング・マネージャー）を担当している神納（＠yuni）です。 9月に入社をして3ヶ月間、中からプロダクトを見てみて、ぜひ皆さんにも知ってもらいたいなと思ったYELL BANKの推しポイントをご紹介させてください。 そもそも、YELL BANKってなに？ YELL BANK（エールバンク）とは、BASE加盟店が利用できる「資金調達サービス」のことです。一言で表してしまうと 「未来の売上を前借りしているようなイメージ」 です。 まとめて仕入れを行う時や、新商品の開発、機材の導入などで資金繰りに不安を感じた際にご利用いただくことを想定して、サービスを提供しています。 現在は、BASE加盟店の一部のショップオーナーさまに限定してご利用いただけるサービスで、 調達できる金額は、BASEの売上実績に紐づいており、ショップによって金額規模も変わってきます。 YELL BANKの知ってほしいところ3選✨ 一般的な金融与信とは切り離された「独自の与信審査」 「すぐに欲しい」に応えた即日性 売れた時だけ支払えるから、売上が安定していなくてもリスクが低い それぞれ順にご説明します。 1. 一般的な金融与信とは切り離された「独自の与信審査」 そもそも与信とは、取引相手のことを信用して、資金などを貸与することです。 一般的な金融与信は、利用者の「返済能力（Capacity)」「返済資質（Character）」「返済担保（Capital）」で評価されています。 投資会社側も、融資先が倒産などの理由で返済が出来ない状態（=貸倒）になってしまうと、企業にとっての損失になるため、 安心安全に取引ができる相手なのかを判断する ために、事前に審査を行います。これが「与信審査」です。 金融機関の融資以外でも、クレジットカードを作成するときなどに、耳にしたことがある言葉かなと思います。 金融機関の与信審査であれば、年収、勤務情報、金融資産、借入、住居などの情報を元に評価がされます。 一般的には、窓口に出向きヒアリングが必要だったり、本人確認書類や決算書、事業計画書などの書類の提出が必要だったりします。 YELL BANKも金融サービスになるので、同様の与信審査は必要です。 ただ、YELL BANKで行われる与信審査はたった一つ 「BASEでの運営実績」のみ です。書類提出などの必要は一切なく、 今までのBASEショップ運営の頑張りを評価 します。 このようにYELL BANKは独自の与信審査をしているため、既に複数の借入をしていて追加での借入が難しい方や、個人事業主であるため金融機関での融資に通らない方でもご利用いただけます。 2. 「すぐに欲しい」に応えた即日性 YELL BANKでは「BASEショップの運営状況」をシステム上で常に評価しているので、「今申し込みたい！」と思ったタイミングですぐに調達ができます。予測不能なアクシデントが起きた場合でも、即日対応できるのは強みの一つです。 また、クレジットカードやQRコード決済だと、現金着金が翌月に持ち越してしまうという、キャッシュレス化が進むことでの弊害もあります。売上は安定しているものの、一時的にキャッシュフローに詰まってしまったなという場合でも、YELL BANKで予備資金を作っておくという対処もできます。 利用したい時にすぐ取り出せる自分のお財布のように、YELL BANKを利用してもらえたらいいな と思っています。 3. 売れた時だけ支払えるから、売上が安定していなくてもリスクが低い 金融機関などでは、毎月固定金額の支払いが必要な場合が多いのですが、YELL BANKはBASEショップで商品が売れたら、その売上からn%支払う、というサービススキームです。売上が落ち込む月でも、収入より支出が大きくなる心配はないので安心設計です。 また、支払い期日がないので、「長期的に挑戦したいことがあるから、まとまった資金が必要。だけど、いつ売れるかわからない...」場合でもご利用いただけるので、新しいことに挑戦したいタイミングで活用しやすいサービスかと思います。 おわりに 今回は、ぜひ知って欲しいYELL BANKのサービスのことをシェアさせていただきました。 YELL BANKチームでは、どうやったらショップ運営を続ける中で感じる資金課題や、不安をいち早く解決できるかを考えて、日々機能改善に関する対応を行っています。 もっといいプロダクト、体験を提供できるように尽力しておりますので、今後のYELL BANKのアップデートを楽しみにしていただけると嬉しいです。 また、YELL BANKでは一緒にプロダクトを盛り上げてくださる方を積極採用中です！カジュアル面談も対応しているので、お気軽にご連絡ください。 採用情報は こちら 明日は ＠funasaka ＠zan の記事が公開予定です、ぜひご覧ください。

はじめに この記事は BASE Advent Calendar 2022 の13日目の記事です。 はじめまして、BASEでエンジニアリングマネージャーをしている渋谷と申します。 今回は、textlintを導入したところレビュー工数が90%削減できたので技術的にどのようなアプローチをしたかについて紹介させていただきます。 背景 弊社にはUXライターが在籍しており、BASEプロダクト全般におけるテキストの品質を向上させる、UXライティングを行っています。 テキスト版デザインシステムとして「運用ガイドライン」「用語リスト」を作成し、あらゆるタッチポイントにおいて、日々テキストコミュニケーションの最適化を図っています。 UXライターが文言を作成するケースもありますが、UXライターでない方が文言を作成するケースが多く、その場合UXライターがレビューすることで品質を担保しています。 そのような取り組みの中で見えてきた2つの課題がありました。 ことばのトンマナ（トーン＆マナー：デザインやスタイルに一貫性を持たせること）をひたすら磨く作業が、現状のテキストデザイン作業の大半を占めていること 運用ガイドラインがあっても、品質の担保は、最終的にはどうしても属人的にならざるを得ないこと つまり、表面的にはトンマナが統一されていることによって、一定のテキスト品質は担保されている一方、UXライティングの本来の役割である「体験をデザインすること」という本質に時間を割けていなかったのです。 そこでtextlintを導入し、トンマナを機械的に統一させようという試みがスタートしました。 （具体的な背景についてはUXライターの藤井が執筆した こちらの記事 に詳しく記載されているので、ぜひ御覧ください） textlintとは textlint は JSer.info などでおなじみの azuさん が開発されているOSSで、テキストファイルやMarkdownのための文章校正ツールです。 .textlintrcにルールを記述するとそのルールに従い校正が実行されます。 アプローチについて 大きく分けて2つのことを行いました。 textlintのためのルール設定 誰でも使える環境の構築 textlintのためのルール設定 ルール設定までの経緯について UXライターはもちろん非エンジニアであり、textlintの使い方に慣れていなかったため、エンジニアである私がサポートしながら進めることになりました。 設定したい校正ルールをUXライターの方にリスト化してもらい、そのリストに対してエンジニアの私がどのtextlintルールを適用できるか一つ一つ検討し、今回導入するパッケージを決定していきました。 設定したルールについて 弊社では下記パッケージを導入しています。 textlint-rule-preset-ja-technical-writing textlint-rule-period-in-list-item textlint-rule-preset-JTF-style textlint-rule-proofdict 特に今回役立ったのはproofdictです。 proofdictは表記揺れやtypoなどを検知するための辞書管理ツールです。 弊社では単語の表記揺れ対策はもちろん、 下記のようなBASE独自ルールについてもproofdictを活用しました。 （）かっこは半角を使用しない ・・・は……（全角三点リーダを2回繰り返す）にする 金額表記は¥（全角）＋半角スペースで表記する 誰でも使える環境の構築 textlintは文章校正がメインの機能になっており、利用する場合にどのエディタを使うかは利用者側に委ねられています。エンジニアの方はローカル環境にtextlintを npm install した上で、VSCodeなどのエディタ経由で利用することが多いと思います。しかし、今回の要件では非エンジニアの方がtextlintを利用するため、ローカル環境の構築はハードルが高く現実的ではありません。 そこで textlint/editor です。 chrome拡張を使ってブラウザ上で文章校正を行うことができます。独自設定をインストールすることで独自の.textlintrcを反映させることもできます。 その結果わずか2ステップで導入することができました。 ステップ1：chrome拡張のインストール ステップ2：BASE独自設定のインストール ただし、このchrome拡張は2022年11月時点でtextareaタグのみに反応する仕様となっており、弊社で利用しているドキュメントツールであるKibelaやGoogleDocsでは利用することができませんでした。 そこで、textareaを有しテキスト内容をローカルストレージに自動保存する簡易なWebエディタを自作しそちらを使ってもらう運用にしました。 （この記事もそのエディタを利用して執筆しています） 導入した結果 UXライターの方いわく、「レビュー前のテキストの品質は、『トンマナ』という文脈においてはとんでもなく担保された！　トンマナレビュー工数、体感で約90％削減！」とのことでした。 本来の役割である「体験をデザインすること」という本質に時間を割けるようになったそうです。 私としてもそのような結果は大変うれしく思いますし、なによりazuさんには感謝の気持ちでいっぱいです。 おわりに 本記事では、弊社でtextlintをどのように運用しているかについて説明しました。読んでいただいた方の助けに少しでもなれば幸いです。 明日はmatzzさん、yuniさんの記事が公開予定です、ぜひご覧ください。