はじめに こんにちは! BASE株式会社でバックエンドエンジニアをしている若菜( __wakanaction__ )です。 2026年6月25日に幕張メッセで開催された AWS Summit Japan 2026 にて、New Relic ブースのミニシアターで「SLOをサービス品質の共通言語にするために取り組んできたこと」というテーマで登壇してきました。 本記事では、発表の概要にくわえて、当日お伝えしきれなかったことの補足をお届けします。 登壇の概要 本発表は、私と同僚の小笠原の2名で内容を作成しました。 発表資料はこちらです。 speakerdeck.com 発表でお伝えした内容は、大きく2つあります。 1つめは、これまでの取り組みの詳細と、得られた手応えです。BASEでは「主要SLO」という指標を作り、事業部全体への展開とエンジニアによる運用の両軸で同時にスタートさせました。 これにより、サービスレベル活動への事業部全体の認知を獲得でき、これから本格展開していくための地盤を固めることができました。 2つめは、いま見えている課題とこれからの展開です。現状では、まだエンジニア以外の組織から能動的に意見をもらうまでには至っていません。そこでこれからは、カスタム属性をサービスレベル活動で使える基盤を作り、ビジネスサイドで追っているKPIを表現したサービスレベルを作れるようにしていきます。サービスレベルをより身近に感じてもらい、品質の可視化のメリットを体感してもらうことで、「能動的にSLOを作成したい」と思ってもらえることを目指しています。 なお、ここに至るまでの道のりは、当日は話す時間が限られていたためお話しできていませんが、過去の記事 BASEにおけるサービスレベルマネジメントのこれまでとこれから で詳しく紹介されています。こちらもぜひ合わせてご覧ください。 登壇内容の補足 当日は初めての外部登壇ということで緊張もあり、大事なメッセージをいくつか言いそびれてしまいました。この場を借りて補足させていただけたらと思います。 主要SLOに込めた意図 発表では、事業部全体で意識するものとして「主要SLO」という指標を設けたことをお話ししました。 そしてこれを設定するにあたり、事業部全体に向けて下記のようなメッセージを込めていました。 サービスの品質という曖昧なものに、具体的な定義と数値を与える 機能や体験の異なるさまざまなサービスを、数値をもって横並びに比較できるようにする 確たるデータをもとにした評価・改善のサイクルを回せるようにする 上記の思想を基に、主要SLOを「エンジニア以外の人にも数値をわかりやすく追ってもらえるように、エンジニアが運用するSLOを一段抽象化した概念」という形で展開しました。 エンジニアの運用と、事業部全体への周知・承認ルートの確保を同時に進めた意図 発表の中で、BASEでは、エンジニアによるSLO運用の開始と、事業部全体の定例での周知・承認ルートの確保を同時に進めた、というお話をしました。 この点の補足として、この進め方に込めた期待には次の3つがありました。 運用を開始するエンジニアたちに、サービスレベル活動がBASE事業部としても推進している活動であると認識してもらうこと エンジニア以外のメンバーがサービスレベル活動に興味を持ったときに、上長に話を通しやすくすること そして、エンジニアがエンジニア以外を巻き込んでサービスレベル活動を拡大していくときに、話がスムーズに進むようになること つまりこの同時進行は、サービスレベル活動をさらにスムーズに拡大させていくための布石でもありました。 初めての外部登壇を終えて 前述のとおり、今回が初めての外部登壇ということもあり、当日はとても緊張していました。 しかし、終わってみると「もっと上手くできた」「もっとこの点について語りたい」などの気持ちが湧き、これからのサービスレベル活動をますます頑張っていくための励みになりました。 そして、貴重な登壇の機会をいただき、準備の段階から当日まで手厚くサポートいただいたNew Relic社の皆様には大変感謝しております。 当日はキーノートセッションの裏の時間帯だったにもかかわらず、たくさんの方が発表を見に来てくださり、とても嬉しかったです。 今後も引き続きサービスレベル活動の推進に懸命に取り組んでいきたいと思います。 おわりに AWS Summit Japan 2026 の New Relic ブースでの登壇についてご紹介しました。 BASEでは、SLOをはじめとしたサービス品質への取り組みを一緒に進めていく仲間を募集しています。興味のある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

はじめに こんにちは、バックエンドエンジニアの小笠原（ @yukineko_819 ）です。 Checkout Reliabilityチームに所属し、負荷試験環境の構築や購入ロジックの最適化など、購入体験の信頼性向上に向けた取り組みをしています。 今回は、「どのショップでも、いつでも安定して購入できる」という購入体験を守るために、購入時のクレジットカード決済へ流量制御（以降、レートリミッタ）を導入した話をご紹介したいと思います。とくに、 特定のショップに購入が集中しても、ほかのショップでは決済ができる状態にする ために、アクセス集中の影響をできる限り抑え、全体の購入可用性を平準化する設計をどう考えたか、というところが中心になります。 あるショップにアクセスが集中している時、ほかのショップで購入ができない まずは、私たちが解きたかった問題からお話しさせてください。 一般的に、決済処理には安定稼働のために単位時間あたりに捌ける流量の上限が設定されており、これを決済流量制限（以降、決済レートリミット）と言います。平常時であればこの決済レートリミットを意識することはほとんどありません。しかし、大型の販売イベントや限定商品の販売といったケースで、特定のショップに対してごく短期間に購入が一気に集中している時、この決済レートリミットが問題になります。 このとき、購入が集中しているショップの決済で決済レートリミットに達すると、まったく無関係なほかのショップにも影響が及んで制限がかかり、購入できなくなってしまう可能性があります。 これは購入者から見れば、自分にもショップにも何の落ち度もないにもかかわらず購入できない、というマイナスの体験となってしまいます。ネットショップの買い物体験として、これほど避けたいものはないでしょう。 いつでも買えるカートを目指して そこで私たちが目指したのは、特定のショップに購入リクエストが集中している状況でも、ほかのショップではいつもどおり購入できる状態を保つことでした。これを実現するために、次の2つを満たすレートリミッタの設計を考えました。 1. 流量を自分たちで把握して制御する ひとつめは、流量を自分たちでカウントして能動的に制限をかけることです。決済レートリミットに到達しているか否かわからないまま決済を実行するのではなく、安定して捌ける範囲の上限を自社側で定義し、あえて能動的に流量を絞る方針を取りました。 2. その他のショップの取り分を「引き算」で残す ふたつめは、アクセス集中ショップとその他のショップを分けて管理することです。これまではアクセス集中ショップが流量を独り占めしてしまい、その他のショップの決済が通らなくなってしまう危険がありました。そこで、あえてアクセス集中ショップに本来の上限値よりも少しだけ低い上限を設定し、残った流量をその他のショップが使えるようにする、という方針を取りました。 この設計のポイントは、その他のショップ用の流量を予め確保しておくのではなく、アクセス集中ショップの上限値にキャップをかける形にしたことです。アクセス集中ショップといっても常に上限に張り付いているわけではありませんし、その他のショップでの購入がたまたま同時刻に重なってリクエスト数がはね上がる可能性もあります。この方針は、その他のショップ側の流量に不要な制限をかけてしまわないようにするという意図があります。 図1: アクセス集中の影響を抑え、その他のショップの取り分を「引き算」で残す どう作ったか ここからは、より具体的な処理フローの話に移りたいと思います。 決済を実行する直前に、1トークンを要求する レートリミッタをどこに挟むべきか検討した時、私たちは決済処理を実行する直前に挟むことにしました。 決済処理は、その実行前にレートリミッタへ「1トークンください」と要求します。このレートリミッタの実体は、専用のRedis上でアトミックに実行される Luaスクリプトで、古典的なトークンバケットとして振る舞います。 なぜLuaなのかというと、「トークンの回復 → トークン残量を確認する → トークンを消費する」という一連の判定をひとつのアトミックな操作にまとめたかったからです。こうしておけば、同時に大量のリクエストが来ても、競合することなく正しくカウントできます。 このレートリミッタは、トークンが残っていればトークンを消費してOKを返し、制限と判定されればNGを返します。レートリミッタを呼び出したアプリケーション側は、判定がOKであればそのまま外部APIを実行して決済に進みます。NGであれば外部APIを実行することなく、決済を諦めて処理をエラーで終了させます。 グローバルバケットとアクセス集中ショップ用バケットの2段構成にする ただ、総量を制御するだけでは足りません。先着順でトークンを奪い合うと、アクセス集中ショップが全てのトークンを独占してしまい、その他のショップが締め出されてしまうからです。これでは今までと何も変わりません。 そこで中核になるのがアクセス集中ショップ用に別途専用のトークンバケットを用意するという方法です。 全ショップが共通のグローバルバケットからトークンを消費する アクセス集中ショップだけアクセス集中ショップ用バケットからも追加で消費する アクセス集中ショップ用バケットの上限をグローバルバケットより小さく設定する ポイントは、アクセス集中ショップではないショップ向けのバケットを明示的に確保しているわけではない、というところです。あえてアクセス集中ショップ側を絞ることで、その差分がその他のショップの取り分として引き算で自動的に残るようにしています。 この設計には、 work-conserving （余力を遊ばせない）という嬉しい性質があります。アクセス集中ショップがなければグローバルバケットは誰でも使えるので、トークンが余ることはありません。アクセス集中ショップが現れて初めて、その分だけアクセス集中ショップ用バケットの制約が効き始める、というわけです。 判定のルールを整理すると、次のようになります。 アクセス集中ショップ ： グローバルバケットとアクセス集中ショップ用バケットの両方に空きがあってはじめて許可。 その他のショップ ：グローバルバケットに空きがあれば許可。 図2: その他のショップはグローバルバケットだけ、アクセス集中ショップは両方の空きが必要 なお、レートリミッタが制限と判定したときはトークンを消費しないようにしています。これは、弾いたリクエストでトークンを消費してしまうと本来なら通せたはずの後続のリクエストにまで影響が及んでしまうからです。 アクセス集中ショップをどう見分けるか アクセス集中ショップをどう判定するか、という点にも少し工夫が要りました。 素朴に閾値だけで判定すると、ショップの状態が閾値の前後で行ったり来たりしてしまい、挙動が安定しません。 そこで、ショップごとに単位時間あたりの決済リクエスト回数をカウントし、一定以上に達したらアクセス集中ショップと判定するようにしました。さらに、一度アクセス集中ショップと判定されたらしばらくはそのフラグを引き継ぐクールダウン期間を設けています。このクールダウン時間は、実際の過去のリクエストの状況を分析して決定しました。 Off → Observe → Enforce、3つのモードで段階的に出す 決済という事故が許されない経路に新しい制御、それも決済を能動的に遮断する機能を入れるわけですから、リリースの手順は慎重に検討しました。いきなり遮断するようなことはせず、フィーチャーフラグで3つのモードを切り替えられるようにして段階的にリリースできるように設計しました。具体的には、以下の3つのモードを管理画面から瞬時に切り替えられるような作りにしました。 Off ：完全な機能OFF状態。Redisにも通信しない、完全に無害な状態で本番に導入する。 Observe ：制限の判定はするが、制限はせずに全て許可する状態。「もし遮断していたら、いつ・どれだけ弾いていたか」を記録するだけにとどめる。このモードで誤って制限してしまうケースがないかを本番のデータで実測する。 Enforce ：制限の判定を行い、遮断も実行する状態。この状態で初めて本格的なレートリミッタの挙動がリリースされる。 万が一 Enforce で誤った遮断が起きても管理画面からフラグを即座にObserveへ戻すだけで、デプロイなしに誤遮断を解除することができます。さらに、この状態の計測自体は継続することで、何が起こったか後から分析できるように情報を残すこともできます。この「デプロイなしで止められる」「後から分析できるデータも残せる」という安心感は、本番に投入していくうえで大きく効いたと感じています。 レートリミッタで決済を止めないようにする 当然ですが、流量制御のために導入したレートリミッタ自身が新たな障害点になってしまっては本末転倒です。レートリミッタの不調で決済全体が止まってしまうのは、避けたい事態の中でも最悪の部類だといえます。 そこでRedisに異常があったときは判定をスキップして決済を通すfail-open方針にしました。「厳密に上限を守ること」よりも「決済を止めないこと」を優先する、という価値判断です。あわせて、判定にかけるタイムアウトはごく短期間に設定し、Redisが重くなったときも素早く安全側に倒れて、決済の本流の足を引っ張らないようにしています。 すべての判定を観測する 最後は観測の話です。すべての判定経路で、レートリミッタの呼び出し毎に1つのイベントを記録するようにしました。 記録しているのは、どのモードで動いていたか（Off / Observe / Enforce）、許可したのか制限したのか、制限判定の理由（グローバルバケットで弾いたのか、アクセス集中ショップ用バケットで弾いたのか）、処理にかかった所要時間、そしてfail-openが発生したかどうか、といった情報です。 特に Observe モードで記録した「もし遮断していたら弾いていたはずの量」は、Enforce へ昇格してよいかを判断するための一次データになります。また、レートリミッタが事前に遮断したものと、決済処理そのものが失敗したものとでは意味がまったく異なるので、ログには専用のタグを付けて、両者をはっきり区別できるようにしています。 おわりに 今回は、購入時のクレジットカード決済に流量制御を導入した話をご紹介しました。 やったことを一言でまとめると、 特定のアクセス集中ショップに購入が集中しても、その他のショップに影響が及ばないように、限られた決済の流量を能動的に制御することで受け止められるようにした 、ということになります。決済の流量を1つのグローバルカウンタで測って制御しつつ、アクセス集中ショップ用バケットによってアクセス集中ショップの流量に少しだけきつめの制限を設け、その他のショップの決済分を引き算で残す。そして3つのモードで安全に段階リリースし、万が一レートリミッタ自身が不調になってもfail-openで決済を止めない。 ひとつ補足しておきたいのは、これは「決済の処理能力がこれ以上伸ばせないから絞っている」という話ではない、ということです。実は、既存の実装を整理することで、レートリミッタを導入してもなお、単位時間あたりに捌ける決済の流量そのものはむしろ増えています。だからこそ今回、思い切ってアクセス集中ショップに制限を設けるという判断ができました。レートリミッタ導入前と比べても、アクセス集中ショップが単位時間あたりに購入できる流量はむしろ増えているのです。 そのうえで、限られたリソースのバランスを短期的に取るための手段として、レートリミッタによる制御を併用している、という位置づけです。一部のショップへのアクセス集中でシステム全体が不安定になれば、影響を受けるのはほかのショップだけでなく、アクセスが集中しているショップ自身も同じです。全体を安定して動かし続けることこそが、結果的にすべてのショップの購入機会を守ることにつながると考えています。 もちろん、ここで満足しているわけではありません。処理能力そのものの引き上げや、ほかの選択肢の検討も含めて、「どのショップでも、いつでも買いやすいカート」を目指して改善を続けていきます。 派手な機能ではありませんが、「どのショップでも、いつでも購入できる」という当たり前を裏側で支える仕組みとして、地味に効いてくれるものになったのではないかと思っています。今回のような改善はユーザーの目に直接見えるものではありませんが、快適な購入体験のために、Checkout Reliabilityチームではこういった細やかな改善を引き続き積み重ねていきます。 BASE では、「どのショップでも、いつでも購入できる」という当たり前を、こうした地道な設計と運用で支えていく仲間を募集しています。カートや決済まわりの信頼性に興味がある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

CTO の川口( id:dmnlk )です。 最近、社内で「とりあえず HTML にして置いておくね」という会話を当たり前のように耳にするようになりました。きっかけは、社内 HTML をホストするだけのささやかな環境をひとつ用意したことです。たったそれだけのことなのに、気づけばエンジニア以外のメンバーまで使い始め、社内の情報の流れそのものが変わっていきました。 この記事では、なぜそんな環境を作ったのか、どう作ったのか、そして実際に何が変わったのかを書きます。 きっかけ：AI が生むドキュメントは「流通するが、読まれない」 AI コーディングが日常になって、社内には実装計画 (plan) や設計メモのようなドキュメントが一気に増えました。Claude Code などに計画を立てさせると、その plan ファイルがそのまま成果物として共有されます。これ自体はとても良い変化でした。 ただ、困ったことがひとつありました。 流通はするのに、人間が読むのに適していない のです。 Markdown やテキストのまま Slack や Git に流れてくる とにかく長く、構造はあるはずなのにプレーンテキストだと頭に入ってこない リンクや図が活きず、コードブロックと地の文が地続きで視線が迷子になる 「内容は良いはずなのに、最後まで読む気にならない」。AI が書いたドキュメントが増えれば増えるほど、この摩擦が社内のあちこちで起きていました。 なぜ Notion ではなく HTML だったのか 「読みやすく共有したいだけなら Notion に貼ればいいのでは」とも考えました。実際、しばらくはそうしていました。けれど、どうもしっくりきませんでした。 自由度が足りない 。レイアウトや見せ方が Notion の枠に収まってしまう 凝った表現や、AI に「読みやすい形に整形して」と頼んだときのアウトプットを、そのまま再現できない 結果として「読みやすくしたいから貼り直す」手間が発生し、誰もやらなくなる 一方、AI に「この plan を読みやすい HTML にして」と頼むと、見出し・目次・強調・配色まで含めて、驚くほど読みやすい 1 枚の HTML を出してくれます。 HTML はそのまま渡せばそのまま表示できます 。この「変換を挟まない素直さ」が、Notion にはない強みでした。 足りないのは「その HTML を、社内の人だけがサッと見られる置き場所」だけです。それなら作ろう、と考えました。他社事例を多く見るタイミングでもあり、自作することに決めました。 最近、社内でHTMLで共有する事が多くなってきたので、空き時間にサクッと社内でHTMLを共有するサービスを作った。公開範囲を柔軟に設定できたり、Slackで簡単に共有できたり、esaやNotionに埋め込みで貼り付けれたり、かゆいところに手が届く感じで非常に便利。 Goodpatch社内のみです。 pic.twitter.com/iQPEXY5kT0 — 土屋尚史 / Goodpatch (@tsuchinao83) 2026年6月3日 ssss-app.com https://t.co/yBJmpJId6P — 鈴木慎吾 / TSUMIKI INC. (@shingo2000) 2026年6月15日 作ったもの：GCS + Cloud Run + IAP 構成はできるだけ薄く、運用に手がかからないことを最優先にしました。 保管: Google Cloud Storage (GCS) — HTML と付随アセットをそのまま置くだけです。バケットにアップロードすれば、それが 1 つのページになります。 配信: Cloud Run — GCS の中身を返すだけの薄いサーバーを 1 つ置きます。フルマネージドなので、アクセスがなければゼロまでスケールインし、コストもほぼかかりません。 認証: Identity-Aware Proxy (IAP) — この環境の肝です。Cloud Run の手前に IAP を噛ませ、社内の Google Workspace アカウントを持つ人だけがアクセスできるようにしました。社内の人はすでに Google にログインしているので、URL を開くだけで（追加ログインなしで）中身が見えます。逆に、社外の人にはそもそも到達できません。 昔は IAP を利用するには Load Balancer などが必要で大変でしたが、今は Cloud Run に IAP を直接設定できるため、低コストで実現できました。 ポイントは、 認証を自分たちで実装していない ことです。社内ドキュメントのホスティングで一番こわいのは「うっかり世界に公開してしまう」ことですが、そこを IAP に丸ごと預けられます。「Google にログインできる社内の人だけ」という、最初から欲しかったアクセス制御が、ほぼ設定だけで手に入りました。 あとは「HTML をアップロードしたら社内 URL が発行される」という体験さえ整えれば、書き手は中身に集中できます。 何が起きたか：エンジニアから、全職種へ 最初の使われ方は、ごく素朴なものでした。 エンジニアが plan を読みやすくするため だけに使っていたのです。AI が出した実装計画を HTML にして置き、URL を共有します。レビューする側も「これは読む気になる」と言ってくれます。それだけでも十分に元は取れていました。 変化が面白くなったのは、ここからです。 その URL を見たエンジニア以外のメンバーが、「自分の資料もこうやって置けるの?」と気づき始めました。やがて 財務・経理のメンバーが、自分たちの資料を HTML にして共有する ようになっていきました。スプレッドシートや長い文章ではなく、要点が整理された 1 枚の読みやすいページとしてです。 気づけば、社内の情報共有のデフォルトが少し変わっていました。 「資料を作る＝読みやすい 1 枚にまとめて、URL で渡す」が自然な選択肢になった 部署をまたいで「あの URL 見た?」という会話が増えた AI に整形を任せられるので、 読みやすい資料を作るコスト自体が下がった 「読みやすく共有する」ことのハードルが下がると、共有される情報の量と質が両方とも上がります。情報の流れが変わるとは、こういうことかと実感しました。 運用してわかったこと 薄く作って正解でした。 凝った CMS にせず「HTML を置くだけ」にしたことで、書き手は自由に表現でき、運用側もほぼメンテ不要です。 認証を IAP に寄せたのは精神的に大きいです。 社内ドキュメントを置くうえで「公開事故が構造的に起きにくい」という安心感が、気軽さを支えています。 置きっぱなしのドキュメントが肥大化しないよう、デフォルトでは 7 日で自動削除されるようにしました。 API を用意し、CI 環境からも受け付けられるようにして、パフォーマンスレポートなどを CI で更新できるようにしました。 MCP も簡易的に作り、Claude Code や Codex などから手軽にアップロードできるようにして、敷居を下げました。 重要なこと 社内で広く使われるようになった一因は、システムの名前だと思っています。キャッチーな名前にすると、社内の文脈に浸透しやすくなります。元々「ファイルをポンと置きたい」くらいの気持ちで始めたので、サービス名は「pon」にしました。すると社内では「資料を pon しました」といった形で話題に上がるようになり、一気に広まったように思います。社内ツールの名前は、想像以上に重要です。 まとめ 社内に HTML をホストする環境を作ったのは、「AI が生む読みづらいドキュメントを読みやすくしたい」という小さな動機からでした。GCS + Cloud Run + IAP という薄い構成で、認証は IAP に任せきりです。技術的には派手さのない仕組みです。 それでも、エンジニアの plan 共有から始まった使われ方がエンジニア以外の職種にまで広がり、社内の情報の流れそのものを少し変えていきました。「読みやすく共有するコストを下げる」だけで組織の情報の流れはこんなに変わるのか——というのが、作ってみての一番の発見です。 似たような「ドキュメントは増えたのに読まれない」課題を抱えている方の参考になれば嬉しいです。

はじめに こんにちは、BASE株式会社 Product Governance（通称：プロガバ）チームの緒方です。 突然ですが、皆さんは「IT統制」や「ガバナンス」と聞いてどんなイメージを持ちますか？ 「開発スピードが落ちそう」「お堅い事務作業」……そんな風に思われがちなこの領域ですが、我々は少し違います。 今回は、私たちがどのような思いで「守り」を「攻め」に変える仕組み作りをしているのか、その裏側をお話しします。転職を考えている方も、そうでない方も、新しいキャリアの形としてご一読いただければ幸いです。 3年半で激変した、BASEのIT統制を取り巻く環境 前回、 IT統制についてのブログ を投稿させていただいてから早くも3年半が経過しました。この間、BASEグループは目まぐるしい変化を遂げています。 2024年のwant.jp、2025年のEストアー、そして2026年のPortと、次々と新たな仲間がグループに加わりました。これだけでも大きな変化ですが、同時に「PAY.JP」や「YELL BANK」といった既存プロダクトも右肩上がりで業績を拡大しています。 （「 事業計画及び成長可能性に関する事項 」より抜粋） 事業が広がり、複雑さが増せば、当然ながらJ-SOX（内部統制報告制度）における評価対象範囲も年々広がっていきます。 「異なる文化やシステムを持つ組織でどこまで共通の整備を行っていくべきか？」 「急成長する決済・金融事業の信頼性をどう担保するか？」 BASEの行動指針である「Move Fast」を維持しながら、上場企業としての「信頼性」を鉄壁なものにする。この難易度の高いミッションに、かつてないほどやりがいと魅力を感じつつ、日々取り組んでいます。 結局、プロガバって何をする人？ 私たちの役割を一言で言えば、 「プロダクトの成長を支える、ガバナンスの設計者」 です。 大きく2つのミッションがあります。 開発現場と監査の「最高の通訳」になる 監査法人や内部監査室が求める「守り」の基準と、エンジニアが求める「開発の自由度」。この一見相反する両者の間に立ち、エンジニアリングの知識をフル活用して「これなら現場も納得できるし、統制も取れる」という最適解を導き出します。 ガバナンスを「仕組み」で解決する（Engineering for Governance） プロダクト開発のスピード、業務スピードを落とさないためにも「手作業でチェックして承認をもらう」ような面倒なプロセスは徹底的に排除します。以下は主な具体例です。 GitHub Actions / GAS / Slack App を駆使した証跡取得の自動化 AI（LLM） を活用したシステムログチェックの効率化 非エンジニア部門に対する内部監査室と連携した業務フローの再構築やシステム化の提案 「ルールを押し付けるのではなく、ルールを意識しなくて済む仕組みを作る」 ことを目指しています。 ここで働くからこそ得られる「プロガバの魅力」 IT×会計・監査のハイブリッドキャリア 技術スタック（AWS, GitHub, SQL等）を維持しながら、ビジネスの根幹である経理・法務・監査の深い知識が身につきます。この両方の言語を話せる人材は市場価値が極めて高く、エンジニアとしてのバックグラウンドを活かした「唯一無二の専門性」を築くことができます。 グループ全体を俯瞰する「鳥の目」が手に入る 特定の機能開発や一つのプロダクトにとどまらず、グループ各社の事業成長や組織構造を横断的に見渡すことができます。経営層に近い視点で「組織がどう動いているか」を肌で感じ、プロダクトを俯瞰して捉えられるのは、このポジションならではの醍醐味です。 AI時代だからこそ光る、代替不可能な「人間力」 昨今、多くの業務がAIに置き換わろうとしていますが、プロガバの仕事の核は「正解のない問いに、人間としての納得感を持って答えを出すこと」にあります。 ルールを自動化する仕組みはAIで作れるかもしれませんが、「このリスクをどう解釈し、開発現場の熱量を削がずにどう落とし込むか？」という高度な判断や、ステークホルダーとの泥臭い調整は、人間にしかできません。ここで得られる経験やビジネススキルは、AIには当面取って代わられない、一生モノの武器になると確信しています。 おわりに 現在、BASEグループではこの「Product Governance（プロガバ）」を一緒に作り上げていく仲間を強く求めています。 「ガバナンスの経験はないけれど、技術を使って組織を良くすることに興味がある」 「エンジニアとしての経験を、より経営に近い領域で活かしてみたい」 そんな思いをお持ちの方、まずは難しく考えず、カジュアルにお話ししてみませんか？ 👉 [Product Governance の求人詳細・応募はこちら] open.talentio.com また、プロガバ以外にも、BASEグループではさまざまな職種・ポジションで募集を行っています。 「BASEという会社そのものに興味が湧いた」 という方も、ぜひ一度採用ページを覗いてみてください。 👉 [BASE株式会社 採用サイト] binc.jp

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEがブロンズスポンサーとして協賛しているカンファレンス、 TSKaigi 2026 のご紹介となります。 2026.tskaigi.org TSKaigi 2026 概要 私たちは、誰かの発表を聞くだけでなく、他の誰かに向けて発表することもまた学びの一つだと考えています。 参加者、登壇者、スタッフ、スポンサーをはじめ、TSKaigi に関わるすべての人たちが互いに学び合い、新たな繋がりを生み出し、型にとらわれないエンジニアとして生き生きと活躍できる世界を目指します。 TSKaigi 2026 公式サイト TSKaigiは「TypeScript」をテーマとした日本最大級の技術カンファレンスです。 2026/5/22（金）- 5/23（土）の2日間、ベルサール羽田空港＆オンラインで開催されます。 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in TSKaigi 2026 協賛の背景 BASEでは複数のプロダクトでTypeScriptを採用しており、日々の開発において欠かせない技術のひとつになっています。 そうした背景もあり、TypeScriptに関する知見が集まるコミュニティや、その盛り上がりを支える取り組みを応援したいという思いから、今年もTSKaigiに協賛しています。 2025年から2年連続で協賛しており、今後もコミュニティとの関わりを大切にしていきたいと考えています。 おわりに 昨年同様、今年も参加予定のメンバーがいますので、後日イベントレポートをお届けできればと思っています。楽しみにお待ちください。 TSKaigi 2026で、みなさまにお会いできることを楽しみにしております！ よろしければ、ぜひ採用情報もご覧ください。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第3回の記事です。 先に第1回、第2回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ 継続的な負荷テスト環境をBASEに構築しました 〜 第2回: 負荷生成ツールの構築と運用 - BASEプロダクトチームブログ こちらは第1回から紹介しているBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、モックツールとして採用したWireMockの選定理由から、実際の構築・運用方法までを紹介します。 モックツールの選定 モックツールも要求事項は負荷生成ツールと基本的には同じでした。 以下は第2回の記事からの要求事項の引用です。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こちらもOSSの比較表を参考として整理しました。 ツール 分散実行可能 Web UI 学習コスト 実績が豊富 特徴 WireMock △（自前スクリプトが必要） △（標準UIなし） ○（機能が豊富） ◎ 業界標準。機能は強いが、UIと分散は独自実装が必要 MockServer △（状態は共有できない） ○ ○（機能が豊富） ○ UIあり・機能も豊富 Smocker △（分散は想定されていない） ○ ○（YAML/JSON定義が直感的） △ UI特化・軽量。個人/小規模チーム向け モックツールは他にも多数あるのですが、実績や保守性がWireMockとMockServerが突出しているように感じたため、まずこの2つを候補としました。 そして他のツールもWeb UIをそれぞれ実際に触ってみた結果、SmockerのUIが使いやすく思えたため候補に加えた形です。 しかし保守性を考えると実績の豊富なWireMockが良いと思っており、UIの課題と分散実行の部分をクリアできないかと調査を進めました。 継続的な負荷テストを実施するためには、複数のモックサーバーに対して、スタブの設定を容易かつ即時で変更できるUIが必要と考えていたためです。 WireMockのサードパーティのUIも探しましたが、複数のWireMockインスタンスに即時で反映できるようなUIはありませんでした。 そのため、個人的にWireMock HubというOSSを作ることにしました。 ykagano.github.io スタブの編集がUIから行え、複数のWireMockインスタンスに即時で反映できる機能をメインに実装しています。 WireMockと組み合わせることで、使い勝手の良い負荷テスト用のモックツールとなります。 wiremock.org WireMockの構築 ECSに構築しました。 下図では負荷テスト用にWireMockを2台起動しています。 Nginxは外部APIのRate-Limiter（流量制限）を再現するために使用しています。 ECSでのWireMockの構成 またその後ろにWireMock HubのAll-in-One版を起動しています。 1つのコンテナの中にNginx + WireMock Hub + WireMockを内包しています。 負荷テストのために、Web UIを持つWireMock Hubがスタブデータの管理とWireMockへの同期を行います。 負荷テスト用のWireMockは負荷テスト利用時にだけ起動していますが、WireMock Hubだけを日常的に起動しておくこともできます。 こうすることで負荷テスト以外の場面でも、外部APIの異常系のテストなどでWireMock Hubの内包するWireMockをUI付きで日常的に使用することができます。 今回負荷テスト環境を構築しましたが、副産物として、日常的にWireMockを使用できるようになったものとなります。 WireMock Hubの構成 WireMock HubはSQLiteのDBを持っています。 プロジェクトの配下にWireMockのインスタンスとスタブが紐付く構造にしています。 そのため、プロジェクトの持つスタブをインスタンスに対して入れ替えることも可能になっています。 プロジェクト ├─ インスタンス └─ スタブマッピング 実際にWireMock Hubに登録しているプロジェクトです。 WireMock Hubのプロジェクト画面 次はインスタンスです。 WireMock Hubのインスタンス画面 例えば、過去のプロジェクトで使用したスタブをもう一度使いたいという時に、プロジェクトの持つスタブを同期させて入れ替えることも、追記して他のプロジェクトで同期したスタブと同居することもできます。 このように、WireMock HubはWireMockを1台だけ利用したい場合にも便利に使えるようになっています。 WireMock Hubからのスタブ登録 WireMock Hubからのスタブの登録方法は以下の3種類があります。 UIでのスタブ編集（下図 Create Newボタンや編集アイコンボタン） スタブファイルのインポート機能（下図 Importボタン） プロキシ機能を使ったレコーディング機能（下図サイドメニューのRecording） WireMock Hubのスタブマッピング画面 このうち、負荷テスト環境の構築時は、主にレコーディング機能とインポート機能を使っていました。 レコーディング機能 レコーディング機能はWireMockが標準搭載している機能です。 まだ何もスタブに登録していない場合、レコーディング機能はとても役に立ちます。 WireMock Hubのレコーディング画面 レコーディング画面でTarget URLを指定して開始すると、WireMockが対象のURLに対するプロキシ（中継サーバ）になります。 この状態でBASEシステムと外部システムの間にWireMockを挟んで通常のリクエストを通すことができます。 図にするとこのように右上から通常の購入リクエストがBASEシステムに入ってきますが、 BASEシステムが左のWireMockに外部サービスへのリクエストを投げて、結果、外部サービスにリクエストが到達します。 WireMockがプロキシとして外部サービスに通信している図 こうすることで、WireMockに実リクエストが記録されます。 レコーディングを停止するとWireMockには記録された実リクエストがスタブとして登録されます。 WireMockのリクエストログにも記録されているため、リクエストログからWireMock Hubにスタブ登録することも可能です。 その後、汎用的なスタブにするための調整は必要ですが、レコーディング機能を使えば、スタブデータを手で書くことなく登録できます。 インポート機能 インポート機能はWireMock HubからWireMockのJSON形式とOpenAPI形式の両方がインポートできます。 WireMock形式のJSON例 { " mappings ": [ { " request ": { " method ": " GET ", " url ": " /test " } , " response ": { " status ": 200 , " headers ": { " Content-Type ": " application/json " } , " body ": " { \" message \" : \" success \" } ", " fixedDelayMilliseconds ": 2000 } , " priority ": 5 , " persistent ": true , " name ": " テストだよ ", " scenarioName ": " test ", " requiredScenarioState ": " Started ", " newScenarioState ": " Step_2 ", " metadata ": { " hub_isActive ": true } } ] , " meta ": { " total ": 1 } } 例えばレコーディング機能で記録したスタブを、WireMockのJSON形式でエクスポートしておけば、以降はClaude Codeで編集することができます。 例えばモニタリングツールに記録された外部APIの通信時間の平均をスタブの遅延時間（fixedDelayMilliseconds）に一律で設定するといったこともできますし、実際にこうしたスタブの設定調整をClaude Codeを通して行っています。 WireMock HubからWireMockへの自動同期 WireMock HubはWireMockとは疎結合なアプリケーションとして設計しています。 そのため、ECSでWireMockを再デプロイした場合、WireMock Hubに登録していたWireMockインスタンスのIPアドレスが変わってしまうことになります。 毎回、WireMockインスタンスのIPアドレスを調べて再登録せずに済むように、WireMock Hubにはインスタンスの再登録APIを用意しています。 下図が同期処理のシーケンス図となります。 LambdaのAPI経由でインスタンスIPリストを取得し、WireMock HubのAPIに渡すことで、インスタンスIPアドレスを更新し、WireMock Hubのプロジェクトに紐付くスタブをWireMockに自動同期します。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant gha as GitHub Actions participant tf as Terraform participant ecs as ECS Fargate<br/>(WireMock Worker) participant sd as Service Discovery<br/>(Cloud Map) participant lambda as Lambda<br/>(wiremock-sync) participant hub as WireMock Hub %% Phase 1: Terraform デプロイ Note over gha, ecs: Phase 1: Terraform デプロイ gha ->> tf : wiremock-hub apply activate tf tf ->> hub : WireMock Hub デプロイ activate hub tf -->> gha : apply 完了 deactivate tf gha ->> tf : wiremock apply activate tf tf ->> ecs : WireMock Worker デプロイ activate ecs ecs ->> sd : タスクIP自動登録（HEALTHY） note right of sd : wiremock-worker.cart-load-test.local<br>→ 172.20.10.x tf -->> gha : apply 完了 deactivate tf %% Phase 2: GitHub Actions による Lambda invoke Note over gha, lambda: Phase 2: Lambda invoke gha ->> lambda : aws lambda invoke activate lambda %% Phase 3: Lambda 処理 Note over lambda, sd: Phase 3: Service Discovery からインスタンス取得 lambda ->> sd : discover_instances（HEALTHY のみ） activate sd sd -->> lambda : インスタンスIPリスト返却 deactivate sd %% Phase 4: Hub API → スタブ配信 Note over lambda, hub: Phase 4: Hub API 呼び出し → スタブ配信 lambda ->> hub : POST /hub/api/projects/{id}/instances/bulk-update note right of hub : {"instances": [...], "syncStubs": true} hub ->> hub : インスタンスIP更新 hub ->> hub : プロジェクトのスタブ定義を取得 hub ->> ecs : POST /__admin/mappings（各 Worker） ecs -->> hub : スタブ登録完了 hub -->> lambda : 同期結果 lambda -->> gha : 完了 deactivate lambda deactivate ecs deactivate hub この仕組みによって、WireMock側の再デプロイをしても、負荷テストに必要なスタブは常に担保されます。 おわりに WireMockはノーコードでスタブが作れますので、開発中APIの代替や異常系の通信テストなどにも便利です。 今回作ったWireMock環境は、カート機能だけでなく、社内で誰でも使えるモックツールとして日常的に使っていければと思います。 全3回の記事を最後までお読みいただきありがとうございました！ モックを使ったテストに興味がありましたらぜひ採用情報をご覧ください！ binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ 2026/4/11（土）に開催されたPHPカンファレンス小田原2026にブース出店し、今年は「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施しました。 こちらの特設サイトからスタンプラリーをすることができます（5/11までの限定公開）。 odawara2026.thebase.in 当日のスタート地点となっていたUMECOのスタンプ獲得画像です。 UMECOでのスタンプ獲得 BASEをご利用のショップオーナーにご協力いただき、UMECO周辺の実店舗をスタンプラリーのチェックポイントとさせていただきました。 ご協力いただいたショップオーナーの皆さまありがとうございました！ スタンプラリーサイトの実績 早速ですが、スタンプラリーサイトの実績についてです。 4/11のアクセスユーザー数とスタンプ獲得数がこちらになります。 対象 件数 アクセスユーザー数 75 スタンプ獲得数 63 スタンプ種類数 6 今回のイベント参加者は150名ほどと伺っていたので、約半数の方にアクセスいただけて嬉しいです。 スタンプを全種類獲得された方はまだいませんが、ご自身のスマホでほとんどの方が最初のスタンプは取っていただけたようです。 当日は暑かったため、散歩するにはあまり向いていなかったと思います。それにも関わらずスタンプを獲得していただいた皆さまありがとうございました。 以降はスタンプラリーサイトの企画から実装についてお話ししていこうと思います。 スタンプラリーサイトの企画 私はこれまで何度かブーススタッフを担当してきましたが、企画段階から参加したのは今回の小田原イベントが初めてでした。 今回のスタンプラリーサイトの企画が、これまでと大きく方向性が変わったのは同僚の 02さん （@cocoeyes02）からの一言がきっかけだったと思います。 Slackでの02さんの投稿 こちらの発言の後、ブレインストーミングをして、アイデアを持ち寄った後、最多投票だったのがシンプルスタンプラリーでした。 Figmaの付箋 この段階ではまだどうやってやるかは決まっておらず、ボード型のマップにするのか、パンフレット型のマップにするのか色々と話し合った結果、今はバイブコーディング（AIへ会話的にコードを高速生成させる開発スタイル）もあるので、スタンプラリーサイトを作ってみようということになりました。 スタンプラリーサイトの実装 スタンプラリーサイトはClaude Codeを使って実装しました。 実装期間は合計で3日程度でした。 技術スタック 技術スタックは以下を使用しています。 レイヤー 技術 フロントエンド HTML / CSS / Vanilla JavaScript フロントエンドデプロイ S3 + CloudFront マップ Leaflet.js + OpenStreetMap バックエンド AWS Lambda (Node.js) フロントエンドはビルドのないシンプルな作りとなっており、バックエンドもサーバーレスです。 データの永続化 当初、LocalStorageにスタンプ獲得を記録するプロトタイプを作ったのですが、会社で同僚の パンダさん （@Panda_Program）に見せたところ、LocalStorageに値を入れて小田原にいないのにスタンプを獲得されてしまいました。 そのため、簡単に偽装ができないように、スタンプの獲得判定はバックエンドで行うようにしました。 デザイン WebサイトをAIで生成すると人間があまり選ばないようなデザインになる部分がありました（影を付けたり角丸にしたり濃い色を使ったり）。 この辺りは一つずつ確認した上で、なるべくシンプルなデザインになるように修正していきました。 工夫した点 チェックポイントを目立つように工夫しました。 チェックポイントの100m以内に近づくと光るようにしています。 100m以内にあるチェックポイント 50m以内に近づくとスタンプ獲得ボタンが表示されます（これも光ってます）。 50m以内にあるチェックポイント 本当はスタンプが獲得できるようになったらスマホを振動させることもしたかったのですが、 Vibration API  にSafariが対応していないことから実装は見送りました。 今回こうした普段作っているものと方向性の違うアプリケーションを作成するのは、色々と考えるところがあって面白かったです。 おわりに スタンプラリーサイトはまだ2週間近く公開予定ですので、小田原に行かれた際にはぜひご利用ください。 BASEではこのように技術イベント・カンファレンスへのスポンサー協賛活動に取り組んでいます。 ブース企画などにご興味がある方はぜひ採用情報をご覧ください！ binc.jp

はじめに 2026/4/11（土）、BASE株式会社も竹スポンサーとして協賛したPHPカンファレンス小田原2026が開催されました。今回は参加メンバーのコメント、会場やスポンサーブースの様子についてお届けします！ PHPカンファレンス小田原2026 概要 PHPカンファレンス小田原は「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 phpcon-odawara.jp スポンサーブース 今年はBASEらしさと小田原らしさの両方を感じてもらえる企画にしたいという思いから、「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施しました。 PHPカンファレンス小田原は、地元に寄り添ったカンファレンスで、一方、BASEはスモールチームをエンパワーメントするという思想を持っています。今回のスタンプラリー企画は、地域コミュニティを大切にするカンファレンスの思想と、スモールチームを応援するBASEの思想がうまく調和した企画になったと感じています。 ご参加いただいた方々からも好評の声をいただけて、とても嬉しかったです！ スタンプラリーサイトを制作したykaganoさんの記事も近日公開予定ですので、ぜひそちらもお楽しみに！ 本企画にあたり、ご協力いただいたショップオーナーのみなさまのおかげで、とても有意義な企画となりました。心より御礼申し上げます。また、スタンプラリーにご参加いただいた方や、感想をお寄せいただいたみなさまにも感謝申し上げます。 登壇者コメント プログラミングをするパンダ 参加してくださった皆様フィードバックありがとうございました！前半は皆さんに面白いと思ってもらえるかなと想像していたものの、後半は「みんなどこかで聞いた話だったり、Claude のバージョンアップで陳腐化した話かも」とちょっと不安だったんですが、AIを使った開発の失敗とその分析を共有してもらってよかったとあってホッとしました。全体的に楽しんでもらえたようで何よりです。 参加者の方、登壇者の方、スポンサーの方、スタッフの方皆様ありがとうございました。来年も小田原でお会いできるのを楽しみにしています！ speakerdeck.com 川口将貴 PHPカンファレンス小田原はコミュニティ色の強いPHPカンファレンスの中でも特に地域コミュニティ含めた温かさが感じられる好きなカンファレンスです。 なので自分の発表もなるべくそれに即したものを話すようにしていますが、受け入れていただけたようで何よりです。 参加者、運営の皆様ありがとうございました。 speakerdeck.com 現地で見たセッションの感想 @02 Past, Present, Future: The PHPUnit Story by Sebastian Bergmann 氏 PHPカンファレンス小田原2026のキーノートは、PHPUnitのメインメンテナであるSebastian Bergmann氏が、PHPUnitを軸に過去から未来までを個人的に振り返る内容でした。 特にエピソードも踏まえ、失敗から多くのことを学び続けてきた姿勢や、PHPUnitが多くの人に使われつづけてきたからこそ時にはNoを言う必要があるメンテナの苦悩など、興味深い話が多かったです。 PHPUnitがみんなに使われているからこそ、様々な需要が出る中で、どれをマージしたら誰がよりよくなって誰が負担増えてしまうのか、判断し続けるの大変よなあ・・・ コミッターの尊敬するところ #phpcon_odawara #kama — 02 (@cocoeyes02) 2026年4月11日 また、OSS開発を通じて世界中のPHPのテストコードに貢献し続けてきたSebastian Bergmann氏が、「重要なのは技術のスキルではなく、共感すること。これまで開発してきた人のコードに現時点で問題があったとしても、悪意を見出さず、敬意を示し、その時点で最善を尽くしていたのだと考えること」と語っていたのが、とても印象に残りました。 セバスチャンレベルのエンジニアが、ソフトウェア開発最も重要なものは技術のスキルではなく共感力って言ってくれるのとても心動かされるものがある #phpcon_odawara #kama — 02 (@cocoeyes02) 2026年4月11日 スライドはこちらに公開されています。是非ご覧ください。 phpunit.expert イベント全体の感想 @InoueTorata 自分は今年で2回目の参加ですが、前回に引き続き熱量のあるカンファレンスで、カンファレンス自体もそうですが、懇親会もとても豪華で賑やかで楽しまさせてもらいました！ 告知タイムの長蛇の列からも界隈の盛り上がりを感じますね ※ 画像はFutoshi Endo氏のX投稿より引用 告知タイムの列 、過去一多い気がする 素晴らしい〜🔥 #phpcon_odawara pic.twitter.com/lbMAixQYtk — Futoshi Endo 🎮 (@Fendo181) 2026年4月11日 こんな楽しいカンファレンスを作り上げて下さったスタッフの皆さん、スピーカーの皆さんにも大変感謝です！ @izuhara 私自身、小田原在住ということもあり、このカンファレンスには気づけば3年連続で参加しています。 普段はあまり言語コミュニティに積極的に関わるタイプではないのですが、このイベントは全体的にゆるくて、それでいてちゃんと熱量もあるのがいいところ。初めてでも居心地がよくて、コミュニティの温かさを感じられるのが印象的です。 特に印象に残ったのは、登壇後すぐに行われる1分間フィードバック。その場でリアルタイムに感想や気づきを共有できるのは、発表者にとっても聞き手にとってもすごくいい仕組みだと思います。聞きっぱなしにならず、その場でしっかり消化できる感じがあって、イベント全体の密度も上がっている気がしました。 @TakeuchiYusuke 昨年、PHP Conference Japanに参加して、今回小田原は初の参加となりました。私はエンジニアではないのですが、コミュニティの空気感やワイワイとしたお祭り感が好きで参加しています。 小田原は居住地からそれなりに近いところなので、ブースのお手伝いをしますよ！というノリで参加したのですが、イベント自体が地域に根付いたコンセプトになっており、Japanとは違った楽しさを感じることができました。 特に印象に残ったのは、有限会社アリウープの柏岡さんのスポンサーLTでした。技術的な話というよりもものづくりがビジネスとして昇華されることの難しさが生々しく語られた内容でした。プロダクトやサービスを生み出せても、それを価値に転換することには想像以上の壁が存在していて、改めて世の中のユーザーに使われているプロダクトやサービスには途方もない努力や時間、試行錯誤が積み重なっているのだなと感じました。 おわりに 協賛活動や社員のスピーカー参加を通じて、小田原という地域やPHPコミュニティの盛り上がりに少しでも関われていれば嬉しく思います。弊社としても、大変有意義な時間となりました。 スタッフのみなさまには、業務でお忙しい中にもかかわらず、多くの時間をイベント準備に割いていただいたことと思います。このような貴重な機会をいただいたことに、この場を借りて心より御礼申し上げます。 スポンサーLTやエレベーターピッチでもお伝えしたとおり、BASEではエンジニアを募集しております。よろしければ、採用情報もぜひご覧いただけますと幸いです。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第2回の記事です。 先に第1回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ こちらは第1回で紹介したBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、負荷テストツールとして採用したLocustの選定理由から、実際の構築・運用方法までを紹介します。 負荷生成ツールの選定 負荷テストのリクエスト元となる負荷生成ツールの選定を行いました。 選定の際は、まず今回の要件として以下の通りまとめました。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こうした観点から参考として整理したOSSの比較表が以下となります。 ツール名 分散実行可能 Web UI レポート品質 学習コスト 実績が豊富 特徴 Locust ◎（Master/Worker が標準） ◎ ○ Web UI 低 ○ OSSで最も簡単にクラスタ構成可能。Pythonでシナリオが柔軟。中規模負荷に強い。 Taurus ○（バックエンドの Locust/JMeter/k6 を分散実行管理） △ ○（バックエンド依存） 低〜中 △ CI/CDで分散テスト統合運用。YAMLでテストランナー統一。チーム利用に最適。 JMeter ○（分散実行あり、構成は複雑） △（要プラグイン） ◎ HTMLレポート 中 ◎ GUI派に最適。歴史が長く安定。大規模負荷にも実績豊富。 k6 OSS △（K8s/CIで水平スケール。自動クラスタなし） ✕ △（外部連携で補完） 低〜中 ○ K8sベースのスケール前提なら実質分散可能。軽量で高性能。 Gatling △（OSS版は限定的。分散は Gatling Enterprise 推奨） ✕ ◎ HTMLレポート 中〜高 ○ Scala/Java DSLで高精度なシナリオ記述。レポートが非常に詳細。高スループット計測に強い。 k6、JMeter、Locustは自身で使ったことがありました。 k6は軽量ですが、Web UIがなく、分散環境で実行した場合、サーバーごとに出力されるレポートの収集が必要なのが懸念でした。 JMeterはテストシナリオを作るための構成が独特で理解に時間がかかるため、学習コストが高いと感じていました。 LocustはWeb UIから容易に実行でき、Pythonでテストシナリオを書く体験が良かったので、今回もLocustを選定することにしました。 Locustの公式ドキュメントはこちらを参照ください。 https://locust.io/ Locustの構築と実行 ECSに構築しました。ECSはAWSのコンテナ管理サービスです。 LocustはMasterとWorkerのタスクに分かれて起動します。 MasterはWeb UIとWorkerの管理を行い、Workerが実際の負荷をリクエストします。 Workerの数を増やすことで、負荷リクエストの上限も増やすことができる構成です。 ECSでのLocustの構成 Classごとに実行が可能で、ProfileでGold環境とBronze環境を切り替えられるようにしています。 Locustの実行画面 実行結果はWeb UIからRPS、Response Times、User数がチャートで見れます。 Locustの実行結果 実際に負荷テストを実行する際は、急激な負荷増加によるスパイクを避けつつ安定状態を観測するため、30秒程度で全てのUserがRamp upするようにして5分間の負荷をかけています。 そして5分の間、応答速度が安定的であるかどうかチャートを見ながら確認しつつ負荷テストを行っています。 Terraformを用いたインフラのコード化 Locustを配置している負荷テスト環境のインフラは Terraform で管理しています。 Terraformはインフラの構成を「設定ファイル」として記述できるOSSです。 AWSコンソールから設定せず、Terraformを用いてコード管理することで以下のメリットがあります。 負荷テスト環境で使用しているリソースをコードから確認できる コードベースでAIに環境構築を依頼できるため、構築が早い 環境の起動と破棄がGitHub Actions（GHA）から実行できる これにより、負荷テスト環境を使用する時だけ起動し、使い終わったら破棄するといったこともできます。 しかし、負荷テスト環境の構築を始めた当初、チーム内にTerraformを使用したことのある知見がなかったため、メンバーから提案をいただき、まずAIにAWSの基礎知識を含めた学習用コンテンツを作ってもらうことから始めました。 AIは主にClaude Codeを使用しています。 こちらが学習コンテンツの一部ですが、このような資料を作っていました。 学習コンテンツ また環境構築自体も、Claude Codeに設計書を書いてもらい、チーム内でレビューをし、何度も修正を繰り返した上で、Claude CodeにTerraformのコードに落とし込んでもらうという形で進めました。 作成されたコードのレビューはチーム全員で行い、全員が負荷テスト環境について知識を揃えるようにしました。 また今回Terraformのフォルダ構成として、以下の通りcoreとruntimeという二つのフォルダに分けています。 core：常設リソースの配置場所で、destroy不可に設定して常設リソースを保護します runtime：一時的なリソースの配置場所で、destroy可能とすることでコストを削減します これにより、インフラの起動時間の短縮とコストの削減を両立させることができます。 今回はTerraformの構成についての知見も得ることができ、良い経験になりました。 負荷テストシナリオの作成 LocustではPythonでテストシナリオを書くことができます。 下記はClaude Codeに書いてもらったサンプルコードからの抜粋ですが、コードの組み立て方は実コードとあまり変わらないため、イメージしやすいかと思います。 """Locust による会員登録フローの負荷テストシナリオ""" import json import os import random import string from locust import HttpUser, between, task DEBUG = os.getenv( "DEBUG" ) == "1" def random_email (): """テスト用のユニークなメールアドレスを生成する""" rand = "" .join(random.choices(string.ascii_lowercase + string.digits, k= 10 )) return f "test_{rand}@example.com" def log_response (label, response): if not DEBUG: return code = response.status_code mark = "✓" if 200 <= code < 300 else "✗" print (f " {mark} [{code}] {label}" ) if code >= 400 : print (f " body: {response.text[:200]}" ) class UserRegistration (HttpUser): """新規会員登録フローのシナリオ""" wait_time = between( 1 , 3 ) @ task def register (self): email = random_email() # 1. 仮登録（メール送信リクエスト） with self.client.post( "/api/v1/signup" , json={ "email" : email}, catch_response= True , ) as r: log_response( "signup" , r) if r.status_code != 200 : r.failure(f "signup: {r.status_code}" ) return token = r.json().get( "confirmation_token" ) if not token: r.failure( "signup: token missing" ) return # この後の処理は省略 今回、テストシナリオを商品や決済方法毎にいくつか作成しました。 作成方法としては過去にk6のJavaScriptで書かれたテストシナリオを流用し、Claude CodeにPythonのコードに変換してもらいました。 変換後のコードが正しいかどうかを検証するために、Playwrightを使用しました。 Playwrightはブラウザを自動操作できるOSSのテストツールです。 Claude CodeをPlaywright MCP（MCPは外部ツールと連携するための共通規格）に接続して、開発環境での購入画面に実際にアクセスしながら、通信しているAPIを確認し、APIコールがテストシナリオのコードと一致しているか検証する形で行いました。 実際に指示したプロンプト Playwright MCPで下記URLにアクセスして、 購入フローをトレースしながらコールされているAPIが scenario/*****.py の シナリオに記載されている内容と一致しているかチェックしてください https://*****/items/12939562 こうしたClaude Codeを用いたテストシナリオの作成により、作業時間を大幅に短縮することができました。 Locustの週次での自動実行 GHAから自動実行する際は、ECSでLocustを起動した後、起動したLocustに対してLambda経由でLocustの負荷テスト実行APIを叩くようにしています。 そして負荷テストの完了結果はログ収集サービスであるCloudWatch Logsをポーリングして、結果ログを取得するようにしています。 以下がそのシーケンス図になります。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant GHA as GitHub Actions participant Lambda as Lambda<br/>(locust-control) participant CWL as CloudWatch Logs participant Master as Locust Master<br/>(ECS) participant Worker as Locust Worker<br/>(ECS x N) Note over GHA: Locust Master/Worker の<br/>デプロイ完了後 GHA->>Lambda: Lambda を非同期で呼び出す<br/>（ユーザー数・実行時間等を指定） Lambda-->>GHA: 即時応答（202） Note over GHA: CloudWatch Logs のポーリングを開始<br/>（30秒間隔で結果ログを監視） Lambda->>Master: Worker の接続状況を確認<br/>（10秒間隔・最大120秒） Master-->>Lambda: 接続済み Worker 一覧 Lambda->>Master: テスト開始を指示<br/>（POST /swarm） Master-->>Lambda: 開始成功 Master->>Worker: テストシナリオを配信 Note over Worker: 負荷テスト実行中... Note over Lambda: 指定時間が経過するまで待機 Lambda->>Master: テスト停止を指示<br/>（GET /stop） Master->>Worker: 停止指示 Master-->>Lambda: 停止完了 Lambda->>Master: テスト結果を取得<br/>（GET /stats/requests） Master-->>Lambda: 統計データ（JSON） Note over Lambda: サマリを抽出<br/>（全体集計 + POST /orders） Lambda->>CWL: サマリをログに出力 GHA->>CWL: サマリログを検索 CWL-->>GHA: テスト結果（JSON） GHA->>GHA: Slack に結果を通知 こうしてLocustを毎週、自動実行することで、Locustを継続的に使用できる状態を保てるようにしています。 おわりに LocustはWeb UIからすぐに負荷テストを開始できるのが非常に便利です。 複数のテストシナリオを組み合わせて実行することもできます。 今後、BASEの決済や販売方法のテストシナリオを拡充した上で、テストを並走させることで、本番をよりシミュレーションした負荷テストを実施していければと考えています。 こうした負荷テストの仕組みに興味がありましたら採用情報もぜひご覧ください。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ Checkout Reliabilityチームはカートの信頼性を向上させるためのチームです。 今回、BASEのカート機能を安定的に提供するために、継続的な負荷テスト環境を構築しましたので第1回として、本記事では全体像を紹介します。 全3回の記事を予定していますので、よろしくお願いします。 BASEの負荷テスト BASEではこれまで負荷テストは必要に応じて都度実施していました。 k6 というオープンソースソフトウェア（以降OSS）の負荷テストツールを使って、BASEのカートへの商品追加から購入完了までのシナリオの負荷テストを行い、負荷が高まっても機能的な問題がないことを確認していました。 しかし、この都度実施の負荷テストには以下の課題がありました。 負荷テストの課題 1. 以前作成したテストシナリオがシステムの仕様変更で動かない状態になっている k6のテストシナリオはJavaScriptで書けるのですが、例えば購入可能な状態にするために必要なAPIやパラメータが一つ増えていたりすると修正が必要になります。 2. 外部APIの仕様変更で、外部APIに見立てたモックのコード修正が必要になっている 商品を購入する際には、BASEから社外の決済APIを呼び出しているのですが、開発環境とはいえ、社外の決済APIに負荷をかけるわけにはいかないため、決済APIの応答に見立てたモックを用意しています。そのため、この社外APIの仕様が変更になるとモックの方もコード修正が必要となります。 3. 新機能を作成した後、改修の度に負荷テストを行っておらず、現在のキャパシティ（負荷に対する許容量）が分からない 当時行った負荷テストの記録は残っているのですが、仕様変更があった今も同じキャパシティを維持できているのかは負荷テストをしてみないと分かりません。しかし、再度負荷テストをするためには、前述のハードルがあります。 これらの課題を解決して、継続的に負荷テストを行えるようにしよう、というのが今回の取り組みです。 負荷テスト環境の要件 継続的な負荷テスト環境として求めた要件は以下となります。 1. 負荷テストを自動で定期実行し、結果をレポートできる 定期的に負荷テストを行うことで、仕様変更によるエラー等を早期に検知できることを求めました。 2. 負荷生成ツールもモックもスケールアウトできる k6のようなシステムに負荷を与えるためのツールを負荷生成ツールと呼びます。この負荷生成ツールとモックの両方を今後システム規模が大きくなっても追従して高負荷を与えられるように、負荷生成ツールやモックの台数を増やす機能を求めました。 3. モックがノーコードで更新できる これまで使っていたモックはPHPによる独自実装をしていました。これだと仕様が変わるとコードの変更が必要です。今回はOSSのモックツールを使用することで、コードの変更をせずにモックの仕様を更新できる機能を求めました。 ベストプラクティスの調査 これらの要件に加え、負荷テスト環境としてのベストプラクティスを調査したところ、下記の記事を見つけました。 引用： 負荷テストの全体像を理解しよう｜AWS（第1回/全3回） ベストプラクティスの部分を抜粋します。 実際のワークロードを使用して負荷テストを行い、自身のワークロードが本番環境でどう動作するのかを確認すること 本番環境同等のサイズの環境を利用して試験を行うこと。また、本番環境同等の量・バリエーションのデータを、本番環境データを匿名化したり模擬的に作成したりして用意すること ユーザーの実際の行動をリプレイ、もしくはプログラム的に再現することで、大規模にアーキテクチャ全体に対して負荷をかけること デリバリーパイプラインの一環として負荷テストを自動的に実行し、事前に定義した性能目標と比較して評価し、要求性能を満たせるかどうかを継続的に保証すること ベストプラクティスに書かれていることは、私が負荷テスト環境に求めた要件とほとんど同じですが、負荷テストの考え方が間違っていない裏付けとして非常に参考になりました。 負荷テストツールの選定 こうした考え方を元に、継続的な負荷テスト環境の要件を満たすための負荷テストツールを選定しました。 負荷生成ツールには Locust を選定しています。 また外部APIのリクエストを受けるために WireMock を選定しました。 それぞれの詳細については第2回以降の記事で説明したいと思います。 負荷テスト環境の構成 最終的に負荷テスト環境の構成は下図となっています。 左が負荷生成ツールとモックツールを使用する負荷テストツール。 右が既存のBASEシステムと同等の負荷検証システム（簡略）となります。 負荷テスト環境のシステム構成図 実際のリクエストと同様にインターネットを跨いでリクエストを処理するようにしています。 ここからは負荷テストの構築にあたり進めた内容についてお話しします。 キャパシティプランニング 負荷テスト環境を構築するために、キャパシティプランニングを行いました。 まず以下の2点を確認しました。 BASEのGMV（流通取引総額）がこの先どれぐらい増加する想定なのか 現時点での本番環境での最大負荷はいくつなのか 1に関しては事業計画を参照すれば分かりますが、2に関しては、どこの負荷を基準とするかを検討しました。 BASEのカート機能には注文APIがありますので、そのAPIに対する負荷を基準にすることにしました。 またBASEではこれまでrpm（requests per minute）を基準にしていましたが、今回は高負荷状態を基準にするため、rps（requests per second）を基準にすることにしました。 ここでは注文APIの過去の最大負荷を仮に1,000rpsとします。 また事業計画として2年後のGMVが仮に1.5倍になるとします。 そうすると、2年後にはrpsも1.5倍の1,500rpsが最大負荷として想定されます。 しかし、あくまで成り行きで増える見積もりとなるため、上ブレすることも考えて多めに見積もりを行いました。 増加分の500rpsを2倍にして上振れ含め1,000rpsになるため、 2,000rpsを目標値 とします。 このような考え方で、今回構築するシステムの負荷テスト可能なキャパシティとして設定しました。 負荷テスト環境の構築 キャパシティプランニングでは、注文APIの負荷を仮に2,000rpsと設定しましたが、2,000rpsはあくまで注文API単体の負荷となります。 今回購入のワークロードを対象としているため、そのワークロードでは20を超えるAPIを利用しており、全体としては数万rpsの負荷が想定されました。 こうした要素を加味して、負荷テスト環境のシステム要件を決めていきました。 Gold環境 本番と同等の負荷検証システムは、既に以前から使っているGoldという名前の環境があったため、それを今回も利用することにしました。 しかしこのGold環境は、本番と同等のDBを使用するため、本番相当のデータ量の準備に数時間かかるという課題がありました。 負荷テスト環境は最終的に負荷テストの定期実行までを見据えていました。 負荷テスト環境の起動後、負荷テストを実行し、負荷テスト環境の破棄まで行う想定です。 しかし、定期実行が準備だけで数時間かかるとなると、コンテンツのデリバリー途中でタイムアウトする可能性もあります（実際にこのデータ準備の処理が何度か止まっていることがありました）。 再実行が頻繁に必要になってくると定期実行に支障が出ます。 DBが巨大すぎるため、Gold環境での定期実行は難しいことが分かってきました。 巨大なDBは存在するだけで多大なコストがかかるため、定期的に数時間利用するだけでも多大なコストがかかります。 定期実行ではこの課題を解決する必要がありました。 Bronze環境 本番同等の環境で負荷テストを行うというベストプラクティスには反するのですが、Gold環境での定期実行の課題を解決するため、負荷テストを自動で定期実行し、結果をレポートするための環境として本番よりスペックの低い縮小環境も今回用意することにしました。 この縮小環境には Bronze と名付けました。 命名理由としてはすでにSilver環境を別用途で使っていたためです。 このBronze環境があれば、テストシナリオの修正と確認もBronze環境で容易に行えます。 最終確認としての負荷テストはあくまでGold環境を使用しますが、定常的に必要最小限のキャパシティを担保するには、Bronze環境でも十分要件を満たせると考えました。 Bronze環境では開発環境のデータベースをそのまま流用することにしました。システムの仕様としては、本番環境の構成を縮小した形で仕様を決めていきました。 Gold環境とBronze環境の比較 項目 Gold環境 Bronze環境 目的 本番想定の最終的な負荷検証 継続的な負荷テスト・定点観測 スペック 本番同等 本番より縮小 データ量 本番同等（大規模） 開発環境のデータを流用 起動時間 数時間（データ準備に時間がかかる） 比較的短時間 コスト 高い 低い 実行頻度 必要に応じて実施 定期実行（週次） 主な用途 最終確認・性能限界の検証 早期検知・継続的な品質担保 メリット 本番に近い精度の検証が可能 手軽に何度でも実行できる デメリット コスト・準備時間が大きい 本番との差異がある Bronze環境で継続的に異常検知を行い、最終的な性能検証はGold環境で行う、という役割分担にしています。 チームでの構築 今回、チームで負荷テスト環境の構築を進めていきました。 草案は私の方で作成しましたが、設計は全員で行いました。 その後、Bronze環境の構築、AWSインフラとLocust環境の構築、WireMock環境の構築と3つに分かれて構築を行いました。 私は主にBronze環境の構築を行ったのですが、BASEのテスト環境を1セット作成する作業のため、BASEのシステムに対する解像度を上げることができ、非常に良い経験を得られました。 Bronze環境での継続的負荷テスト 毎週月曜に以下のスケジュールで負荷テストを自動実行しています。 時刻 内容 AM3:00 アプリケーションの自動デプロイ AM7:00 負荷テストの自動実行 負荷テストの自動実行はGitHub Actionsのワークフローで行っています。 以下のジョブが40分程度で実行されます。 負荷テスト開始の通知 Bronze環境の起動 負荷テストツールの起動 負荷テストの実行（メインシナリオ1） 負荷テスト結果の通知 負荷テストの実行（メインシナリオ2） 負荷テスト結果の通知 負荷テストツールの停止 Bronze環境の停止 負荷テスト完了の通知 負荷テスト結果はSlackに投稿されます。 以下はレポート内容の例ですが、注文API（post_orders）に対するrpsとAPI全体（aggregated）のrpsを見れるようにしています。 post_orders: requests=2000 failures=0 avg_time=20ms avg_rps=8.0, aggregated: requests=80000 failures=400 avg_time=500ms avg_rps=300.0 これで毎週最新のアプリケーションでキャパシティの定点観測ができる状態になりました。 本番と同等の挙動ではないですが、もしパフォーマンスの低下があれば週次で検知できます。 また今後負荷テストを実施したい場合にも、すぐに使える環境があるため、負荷テスト実施のハードルも下がってくれるのではないかと期待しています。 Gold環境での本番想定の負荷テスト Gold環境での負荷テストは当初パフォーマンスが想定したよりも出ませんでした。 本番と同等の環境ではありますが、本番と仕様や設定が一部異なっていたため、それらを本番と揃える作業が必要でした。 また本番と挙動が異なる部分もありました。 これは外部APIの通信時間を細かく本番と合わせたり、外部APIが本来持っているRate Limit（一定時間内にリクエスト回数の上限を設ける機能）の機能を再現するための仕組みを入れることで徐々に解決していきました。 負荷テストは実行してパフォーマンスが出ない場合にどこが原因か調査しボトルネックを見つけることも大事ですが、パフォーマンスをもっと出すためにはどうすればいいかは、仮説を立てる必要があります。 そのため、負荷テストの実施前に負荷改善の仮説DBをNotionに作成し、この辺りを改善すればより早くなるのではないか、といった仮説をチーム内で思い付いたものがあれば、確度が低くても良いのでどんどんDBに入れていくことにしました。 今後はこの負荷テストの結果と仮説を元に、BASEのカートの安定性をより高めるための施策を実施していく予定です。 おわりに 今回の記事では、継続的な負荷テスト環境の全体像と設計方針について紹介しました。 第2回では負荷生成ツールの構築と運用について、第3回ではモックツールの構築と運用についてお話しする予定です。 順次公開しますので、ご期待いただければと思います。 このようなシステム環境で働きたいエンジニアの方はぜひ採用情報をご覧ください！ binc.jp

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEが竹スポンサーとして協賛しているカンファレンス、 PHPカンファレンス小田原2026 のご紹介となります。 phpcon-odawara.jp PHPカンファレンス小田原2026 概要 PHPカンファレンス小田原は「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 2026/4/11（土）、おだわら市民交流センター「UMECO」で開催されます。 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in 登壇メンバーのご紹介 BASEで活躍しているメンバーのうち、2名が登壇予定です。ぜひ聞きにいらしてください。 レガシーPHP転生 〜父がドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜 プログラミングをするパンダ （ @Panda_Program ） 会場：かま 14:45〜 fortee.jp スポンサーLT 川口将貴（ @dmnlk ） 会場：かま 15:35〜 ブースのご紹介 当日はBASE株式会社としてスポンサーブースの出展も行います。 今年は「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施予定です。 BASEをご利用のショップオーナーの中には、ネットショップだけでなく、並行して実店舗を運営されている方もいらっしゃいます。会場であるUMECO周辺にも実店舗を構えているショップがありますので、カンファレンスで小田原にお越しの際は、ぜひ足を運んでみてください。 BASEのブースでお会いできることを楽しみにしております。 おわりに PHPカンファレンス小田原 2026 のチケットはこの記事掲載時点ですでに完売しているそうです。後日こちらのブログでも参加レポートをお届けする予定です。楽しみにお待ちください。 PHPカンファレンス小田原 2026で、みなさまにお会いできることを楽しみにしております！ 発表を見てBASEで働くことに興味を持った方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに Architecture Design Grp で エンジニア をしている大塚です。 New Relic Advance: Tokyoというイベントに参加してきました。 New Relicのこれからについて、さまざまな発表がありましたので、簡単にまとめさせていただきました。 今回はCEOなどの登壇もあり、見応えのあるイベントでした！ TL;DR New Relicが日本リージョン（国内データセンター）を追加予定で、データ保管要件とレイテンシ面でメリット 生成AI（Analyzer + MCPなど）でアラート調査の初動を短縮し、運用定着を加速する事例が紹介された New Relic Lensで外部DBやDWHなどにクエリし、NRQLで既存データと結合して分析できる イベント概要 日程：2026/03/12 16:00 ~ 18:00 会場：八芳園 全体の所感 New RelicのCEOなどが登壇するようなイベントで、今まで参加したイベントとは雰囲気がだいぶ違いました。 生成AI時代なので、AIの活用を加速させる内容が多かったです。 AI for New RelicとしてAIアシスタントやSRE Agentなどの紹介があり、インシデントなどの対応フローの自動化などが大きなトピックでした。 New Relic for AIとしてMCPの紹介や、ほかプラットフォームとの統合についての紹介もありました。 基調講演でもAIとNew Relicのデータを用いてインシデントやアラート対応を効率化させるという話があったので、BASEでも取り込んでいこうと感じました。 セッション / トピック 1) 日本リージョン追加！ newrelic.com 日本にNew RelicのDCを設立するというお話です。 セキュリティやプライバシー要件的にNew Relicに保存できなかった（海外リージョンのため）データも日本国内にデータが保存されるようになることで、より幅広いデータを集約することが可能になります。 レイテンシなどのパフォーマンスにも寄与するような大きなトピックでした。 2) 生成AIで加速させるNew RelicのEnabling speakerdeck.com blog.kinto-technologies.com New Relicを組織に浸透させるための取り組みにAIを組み合わせて、活用を加速させるというお話でした。 勉強会やドキュメントなどのコンテンツをいくら揃えても、それぞれのエンジニアにはそれぞれのタスクがあるので、時間を使って活用してもらうのは難しいという課題が挙げられていました。 New Relicを用いて、計装→検知→調査→解消までのサイクルは回せるようになるが、結局は人の目や手で対応をする必要があるので非効率という課題が残ってしまっていました。 その課題に対してNew Relic Analyzerという仕組み（AIによる分析）を導入することで、初期調査の時間が大幅に短縮され、MCPを用いた対話型にすることで日常業務への定着も進んだとのことでした。 BASEではアラートはSentryで調査はNewRelicという構造になっているので、現状を維持しても良いがNew Relicを活用できていない部分も大きいと感じました。 インシデントやアラートの対応サイクルを改めて見直し、AIを導入した新しい仕組みづくりをしてみても良いかもしれない。。。 3) New Relic Lens docs.newrelic.com New Relic外のデータソースに対してクエリを実行することが可能になりました。 クエリ結果に対してNRQLでNRDBのデータとjoinして分析・可視化できるようです。 現状対応しているのは以下 クラウド データ ウェアハウス : Snowflake 、 Redshift 、 ClickHouse リレーショナルデータベース : PostgreSQL 、 MySQL 、 SQL Server ドキュメントデータベース : MongoDB 、 Elasticsearch スプレッドシート : Google Sheets データレイク : Iceberg メトリクスと監視 : Prometheus 、 AWS CloudWatch BASEでの活用の今後の展望 アラート対応やインシデント対応の実態調査 New Relic Analyzer的な機能の実装が可能かどうか New Relic Lensを利用してNew RelicからMySQLのデータをクエリできるようにする（可能か？の調査から） 最後に 生成AIの活用が進む中で、アプリケーション監視についてもこれらの技術を用いる必要性を感じました。 今回のイベントの内容はBASEでも活用できる内容が多かったので、積極的に取り入れることで社内のAI Observabilityを向上させていきたいと思います。 こうした生成AIを活用した取り組みは各社行っていると思いますが、BASEでも積極的に開発やサービスに取り入れています。 binc.jp

はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEがゴールドスポンサーとして協賛しているカンファレンス、 PHPerKaigi 2026 のご紹介となります。 phperkaigi.jp PHPerKaigi 2026 概要 PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 PHPerKaigi 2026 公式サイト 2026/3/20（金）- 3/22（日）の3日間、中野セントラルパークカンファレンス&ニコニコ生放送で、オフライン及びオンラインのハイブリッド開催となります。チケットは下記よりお買い求めいただけます。 チケットショップ | PHPerKaigi 2026 #phperkaigi - fortee.jp 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in 登壇メンバーのご紹介 BASEで活躍しているメンバーのうち、3名が登壇、1名がパンフレット記事掲載予定です。ぜひ聞きにいらしてください＆パンフレットもぜひご覧ください。 モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について 川島慧（ @nazonohito51 ） 3/21（土）Track C 15:35 登壇者メッセージ モジュラモノリスを題材にしていますが、主題は組織とアーキテクチャの力学の分析です。ただの苦労話や事例紹介ではなく、背後にある構造を読み解きます。 fortee.jp 大規模ECサイトのあるバッチのパフォーマンスを改善するために僕たちのチームがしてきたこと プログラミングをするパンダ（ @Panda_Program ） 3/22（日）Track C 11:00 fortee.jp なぜarray_firstとarray_lastは採用、array_value_firstとarray_value_lastは見送りだったか 02（ @cocoeyes02 ） 3/22（日）Track A 16:05 fortee.jp カンファレンスが終わったあとに meihei（ @app1e_s ） パンフレット掲載 fortee.jp PHPerトークン ここで、PHPerKaigiで行われる「PHPerチャレンジ」のPHPトークンをお知らせします。BASEからは3つのPHPerトークンを用意しました。今回はBASEのサービスに関する内容からピックアップしています。 #ネットでお店を開くならベイス♪ thebase.com 誰でもかんたんに使えて、自分だけのネットショップを開設できるネットショップ作成サービス「BASE（ベイス）」のCMで使用されているフレーズです。 はじめての方でもかんたんに自分だけのネットショップがすぐに作成でき、ネットショップに必要な決済手段も、多様な決済方法をスピーディーに導入可能。 #ECのカクシゴト www.youtube.com 「ECのカクシゴト」は「BASE」公式YouTubeチャンネルの1つ。“ひとり開業の裏側”をテーマに、個人やスモールチームでネットショップを運営するショップオーナーの開業ストーリーや人生、日々の暮らしに密着したドキュメンタリー形式の動画を配信しています。 実際にネットショップを運営する個人やスモールチームのオーナーたちに密着し、「なぜECという働き方を選んだのか」「副業から始まり、起業に至るまでの過程」「ものづくりと暮らしのバランス」など、表からは見えないさまざまな価値観や選択肢に光を当てていきます。 毎週金曜日に新しい動画が配信されていますので、ぜひご覧ください。 #好きが、買える。ペイアイディー payid.jp 「BASE」をご利用のショップと購入者をつなぐ、BASE唯一の購入者向けショッピングサービス「Pay ID（ペイ アイディー）」。「Pay IDアプリ」を通じて、ショップは集客・販促をおこない、購入者はお気に入りショップのフォローや商品通知など、スムーズな購入体験を得ることができます。 お気に入りショップでのお買い物をサポートする「ショッピングアプリ」、スムーズでクイックなお支払いを実現する「決済」の2つの領域でサービスを提供しています。 おわりに PHPerKaigi 2026で、みなさまにお会いできることを楽しみにしております！ 発表やパンフレットを見てBASEで働くことに興味を持った方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに こんにちは！ BASEでバックエンドエンジニアをしている、かがの（ @ykagano ）です。 昨年まではCartチームにいたのですが、今年から部署名が変わりまして、現在はCheckout Reliabilityチームにいます。 これはBASEのECカートの信頼性を守るためのチームです。 決済の安定性を高めるために日々活動をしていますが、それについてはまた別の記事で書かせてください。 さて、QRコード決済サービスとして日本で一番シェアの大きいPayPayといえば、皆さまもご存知かと思います。 今回は、2026年1月28日にサービスリリースしたこのPayPay導入についてお話しさせていただきます。 BASEはなぜ決済手段を増やすのか まずBASEがなぜ決済手段を増やすのかですが、そもそも決済手段が増えるとどういう良いことがあるのかからお話ししたいと思います。 ECにおいて購入体験の中で最も重要なポイントのひとつが「決済」です。 商品を見つけてカートに入れても、最後の支払いでつまずいてしまうと、その時点で購入は完了しません。 特に近年はクレジットカードだけでなく、QRコード決済や後払いなど、ユーザーごとに「普段使っている支払い方法」が多様化しています。 そのため、ショップ側が対応している決済手段が少ないと、それだけで購入機会を逃してしまう可能性があります。 SBペイメントサービス株式会社による「決済手段のEC利用実態調査結果」でも、「よく利用する決済手段がない場合、男女ともに約6割が購入せず離脱する」という結果になっています。 www.sbpayment.jp ECサイトで物品もしくはデジタルコンテンツ・サービスを支払う際に、よく利用する決済手段がない場合どうするかを尋ねたところ、男女ともに56.5％以上が、そのECサイトでは購入せず離脱する傾向にあることが分かりました。また、そのうち44.8％以上※2の人は他のECサイトもしくは実店舗で購入する意向があることから、購買意欲が高い人でも決済手段の不足が要因で離脱しており、ユーザーのニーズに応じた決済手段を取りそろえることは購買率を上げる重要な要素であると言えます。 つまり、決済手段を増やすことは単に「選択肢を増やす」というだけではなく、ユーザーが安心して購入を完了できる環境を整えることにつながります。 これはショップオーナーにとっては購入率の向上につながり、BASEにとってもより多くの取引を支える基盤を強化することになります。 今回PayPayがBASEに導入されたことは、こうした背景からも多くのショップ様にとって望まれていた機能追加だったと考えています。 BASEでのPayPay導入方法 PayPayは「BASEかんたん決済」に追加される形で提供されます。 PayPayを利用するには、この「BASEかんたん決済」の利用申請が必要です。 「BASEかんたん決済」の利用申請をもとに、PayPayで審査が行われます。 その後、可決された場合はPayPayを利用開始いただけます。 なお決済手数料は 4.6% + 40円 です（グロースプランの場合、決済手数料は 3.9% のみ）。 これは既存のAmazon Pay や PayPal決済と同じ決済手数料となります。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in BASEでの支払い方法 BASEのカート画面で支払い方法に「PayPay」を選択して、購入完了ボタンを押していただく形となります。 その後、「PayPay」の手続き画面に遷移しますので、「PayPay」アプリで認証・支払いすると、BASE側に自動で戻り、購入が完了します。 PayPayは現在、BASEのWebショップのみが利用可能となっていまして、Pay IDアプリには未対応となります。 またPayPayで支払いが可能な商品は通常商品のみとなっており、デジタルコンテンツや予約販売や抽選販売など、通常商品以外の商品には利用できないようになっていますのでご注意ください（取り扱いについては今後変更になる場合があります）。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in PayPay導入の開発について PayPayの導入はService Reliabilityチーム（以降SRチーム）にて開発いただいてます。 私自身はPayPay導入の開発に直接関わっていたわけではないのですが、導入後のカートシステムの運用を行う前提で設計や実装レビューに入らせていただきました。 今回BASEにPayPayが導入されることになり、システムの開発が始まったのが、2025年10月8日になります。この日に開発メンバーでキックオフを行い、設計を始めていきました。 実装にはPayPayのスマートペイメント機能を利用しています。 初回はユーザーの連携が必要ですが、2回目以降は同じ端末からの操作であれば再度連携せずに支払いをすることができます。 詳細はPayPayの公式ドキュメントをご参照ください。 developer.paypay.ne.jp PayPayはクレジットカード決済とは異なり、ユーザー操作後にBASEとは非同期で決済結果が確定するフローを含んでいます。 そのため「決済をいつ確定させるか」「どの状態をもって成功とみなすか」を慎重に設計する必要がありました。 今回は「注文が完了した時には決済も確定している」というBASEの体験を維持するために、PayPayの画面で決済をしたあと、BASEの画面に戻ってきた後にPayPayの決済結果が正常に完了していることを確認してからBASEに注文を作成するようにしました。 BASEでは複数の決済手段を扱っているため、特定の決済に依存しすぎない形での実装が求められます。 PayPayも既存の決済と同じインターフェースに乗せることで、カート・注文・発送といった関連機能への影響を最小限に抑えています。 私がレビューをしている中で特に意識したのは、「PayPay側で一時的な障害が発生しても、注文や決済状態が不整合を起こさないこと」です。 この辺りは特に注意してレビューをさせていただきました。 もし何らかの原因によって決済が失敗した場合も不整合が起こらない仕組みとなっておりますので、安心してご利用いただければと思います。 おわりに 開発期間としては約3ヶ月でリリースすることができたのですが、これほど早くリリースできたのもSRチームの皆さまの頑張りのおかげです。 本当にありがとうございました。 PayPay決済はまだBASEで開始したばかりですが、今後利用数、利用率ともに高くなるものと思いますので、より安定的に運用できるように改善を重ねていきます。 BASEではこうした決済の仕組みにも関わっていけますので、ご興味がありましたら採用情報をぜひご覧ください。 binc.jp

はじめに 先日、New Relic 社主催の New Relic Meet Up for Digital に弊社のメンバー 6 人が参加してきました。 以前も New Relic 社主催の FutureStack Tokyo 2023 でも Game Day がありましたが、今回はこちらに参加していないメンバーでの参加となりました。 前回 BASE で Game Day に参加したブログはこちら！ devblog.thebase.in コンテンツ この Meet Up では基調講演、GameDay Lite、懇親会という流れで進行されていました。 AI 時代の「オブザーバビリティ」戦略 AI時代には開発スピードがどんどん上がり、それに伴いコードの大規模化や不確実性などの課題が新たに生まれ、オブザーバビリティの重要性がもっと上がるというお話しでした。 New Relic パスポイントやセッションリプレイなど、まだ使えていない便利な機能を知れたのでどんどん使っていきたいです。 GameDay Lite 3~4人のシャッフルチームで、障害が発生した想定のWebアプリケーションに対して New Relic を使って解決していくゲームを行いました（回答式）。 高得点を叩き出した上位チームには景品が渡されていて、弊社の @takashi.nohara さんのチームが見事 3 位に入賞していました🎉 参加レポート @yunamiyaa Product dev Order Section Architecture Design の宮坂 @yunamiyaaです。 今回のミートアップでは、4人1組のチームでNew Relicを使ったトラブルシューティングに挑戦しました。 私たちのチームは、普段から業務でNew Relicを使い込んでいるメンバー3名と、ちょうど会社で導入が決まったばかりの未経験メンバー1名という構成でした。初心者のメンバーに「調査のコツ」や「画面の見方」を教えながら進めることで、自分たちにとっても基本に立ち返る良い機会になり、改めて「なぜこの手順で調査するのか」を言語化できました。 同じNew Relicというツールを使っていても、他社のエンジニアとディスカッションする中で、エラーを探す手順やダッシュボードの使い方が会社ごとに異なることに驚きました。それぞれの組織の文化やシステム構成に合わせた工夫があり、「うちではこうやっている」という情報交換がとても刺激的でした。 さらに、New Relic社の方から具体的なケースに対する追跡方法を直接教えていただけたことが大きな収穫でした。 「あ、そんな追い方があるんだ！」という発見が多く、普段の業務では気づけなかった機能の活用法や、より効率的な調査パターンを知ることができました。自社の中だけでは得られなかった新しい視点をたくさんもらえた、非常に有意義なミートアップでした。 @Torata BASE ProductDev / Item Section でエンジニアをやっているTorataです。 自分は直近で New Relic に触れる機会があり、今後も New Relic を継続して学んでいく必要があると感じていたタイミングで、今回の Game Day に参加しました。 初めて見る機能や、見たことはあるものの目的がよく分かっていなかった機能に、ゲーム感覚で触れられたのがとても楽しかったです。 また解説では、「どの意図を持って何を見るのか」という観点から、調査を深掘りしていくプロセスまで聞けたのが大きな学びになりました。 賞を勝ち取ることはできませんでしたが、今回学んだことを業務で活用し、賞を狙えるようになるくらい使いこなしていきたいです💪 @meihei BASE の Item Scalability Group でエンジニアをしている江間 @meihei です。 Item Scalability Group では、アプリケーションからインフラストラクチャ・データベースまで横断的に監視してボトルネックを探すため、日頃から New Relic を使っています。チョットワカルつもりで GameDay に参加しましたが、初めて触る機能や UI が結構ありました。 また、チームが３人だったこともあり、横に並んで New Relic を触っていました。はじめましての方もいる中、とても良い形で協力プレーが出来てとても楽しかったです。 最初の講演も GameDay Lite も非常に学びが多かったです。New Relic の設定でまだやっていない事がいくつか見つかったので、ここで得た知識を活用していきたいと思います。 GameDay中のチームWの様子。中央の一人がNew Relicの画面を触りながら、横二人が問題や資料を開き、限られた環境の中で効率化をしていた。 @Otsuka BASEのOrder Secの大塚です。 GameDay形式でのイベントへの参加は初めてでした。 New Relicは普段から触っており正直自信があったのですが、なかなか苦戦してしまいました。 その分普段活かしきれていない機能についての活用方法なども学ぶことができたので、今後に活かしていきたいと思います。 @wakana Product Dev/Checkout Section の @wakana です。 私は普段の業務中から New Relic を使用しており、主にAPM, Service Level, Dashboard, Browser, Logs などの機能を用いて、監視業務や可観測性の向上に取り組んでいます。 今回、New Relic Game Day への参加は初めてでしたが、事前にグループ分けされたほかの参加者の方と4人1組でチームを組み、クイズ形式の課題にNew Relicを活用して答えていく協力型の形式で、とても取り組みやすく感じました。 内容としても全て実践的で充実した内容となっており、参加前から知っていた・使ったことのある機能は4割ほどで、残りは初めて見るページなどが多かったため、とても刺激になりました。 一部、とても魅力的でありながらBASEでまだ導入ができていない機能などもあったため、今後よりオブザーバビリティの民主化を社内で進めていくうえでぜひ導入を進めていきたいと感じました。 @nohara BASEのCheckout Sectionのエンジニア、野原です。普段の業務では New Relic を利用しています。今回は理解を深めるために、New Relic の GameDay に参加しました。 今回が初めての参加だったのですが、想定とは少し違い、他社の方々とランダムに4人チームを組んで課題に挑戦する形式で、とても新鮮でした。特に、初対面のメンバーと短時間でチームワークを築いていく体験が印象に残っています。まず最初に、4人チームの中で誰が回答を記録・提出するかを決め、その後はそれぞれの知見を持ち寄りながら課題に取り組みました。 初めて目にする機能やUIも多くありましたが、メンバー同士で相談しながら進めることで、なんとか回答することができました。最初は順位をあまり意識していなかったのですが、第1ステージで2位だったのは意外でした。第2ステージでは一部、回答が間に合わなかった問題もあったため、最終順位が3位だったのは正直驚きでした。今回学んだ内容は、ぜひ今後の業務にも活かしていきたいと思います。 また、最初の発表もとても勉強になりました。これからはAIの時代ということで、今後はAIの活用も積極的に取り入れていきたいと感じています。業務の中でも、引き続き New Relic を活用していく予定です、これからもどんどん勉強します。 GameDayのチーム賞で見事二位に入賞。左から二人目がBASEメンバーのnohara。 おわりに AI時代でのオブザーバビリティへの向き合い方や、New Relicの機能に関する新たな知識を沢山学べた１日でした。 当日のイベント進行や準備をしていただいたNew Relic社の皆様、ありがとうございました！ これからもどんどん New Relic を使っていきたいと思います！

CTOの川口 ( id:dmnlk ) です。 これはBASE Advent Calendar25日目の記事です。 毎年ながら僕は立候補してないのに勝手に日程が組み込まれてました。 BASE社では2027年卒の学生を対象に新卒採用を始めました。 今まで基本的に行っていなかったことです。対象はエンジニア職、デザイナー職、ビジネス職です。 2025年中には就活を終えている大学生が多いということも知り、自分が新卒だった頃と比べててだいぶ進行が早いことに驚いています。 採用面接を行っていく中で必ず聞かれることとして「どうしてこのタイミングで新卒採用を始めたのか？」というものがあります。 特にエンジニア職においてはAIによるコーディングが大きな流れとなっており、インターン経験があれど実務経験が乏しい所謂ジュニアエンジニアをなぜこのタイミングで採用を始めるかというのは当然の疑問だと思いますし学生の方には不安も大きいのかもしれません。 もちろん面接中にそれを同じように答えているのですが来年以降の方も踏まえてここで明文化しておこうと思い記事にしています。 コロナ禍が起きた2020年以降、BASE社ではリモートワークを主としたハイブリッドワークを行ってきました。 ここでリモートワークの是非を言及するつもりはなく各社ごとに合わせた働き方や組織があるかと思います。 自分はBASEにかれこれ8年ほど在籍していますが、最近自社がどういう文化を持った組織かといったことを認識しづらくなったと感じています。 特にこの部分は中途面接でよく聞かれており、今のところ答えられている部分ではあるのですがどうしても文化面といった部分に希薄化を感じています。 もちろん文化が色濃ければ濃いほどいいというものではありませんが、開発組織のトップであるCTOたる自分がその組織について自分の言葉で話せなくなっていることには危機感があります。 中途採用したメンバーも定期的に入社していただいていますが、中途で入ってきたメンバーが文化を作っていくといった力学は働きづらいように思いますしそれを求めすぎるのは何か違うのではないかと思います。 自分が新卒で入った会社は大きなインターネット企業の子会社ですが、そこグループ全体で反対に企業文化が外から見ても中から見ても非常に強い会社です。 斜に構えた新卒であった自分はその空気感といったものに怪訝な気持ちでいたものですが、今思い返すと朱に交われば赤くなるといったように一定その会社のマインドや風土といったものに影響され今の考え方があります。 もちろんその企業もコロナ禍でリモートワークをやっていたようですし、内部では文化は変わったり薄まったりしたのかもしれませんが外から見る限りは未だに強い流れがあると思います。 思い返しその源泉はなんだったのだろうと考えると、もちろん社長や経営陣の強いリーダーシップもありますが新卒を毎年積極的に採用し全社がその採用に協力し入社した新卒を全社で育て早い段階から抜擢し伸ばしていたところにあったのではないかと考えています。 そのような点も踏まえ、BASEの開発組織として新卒を採用しボトムアップで文化醸成を図っていきたいというのが自分の考えとなります。 実務能力という点においてはあまり自分ではジュニアという括りで捉えてはいません。 インターン経験を一旦除いて考えると大規模Webサービスや数十人規模での組織での開発の仕方など経験が不足しているのは当然です。 ですが、それは単純な経験の差というだけであり1~2年もあれば優秀な方であれば容易に習得できうるものですし、事実自分もそうでした。 AIによるバフがあることによりジュニアエンジニアの能力向上のチャンスはより強くなっています。優秀な人物であればそのバフは数倍以上の効果を見せるはずです。 逆にいうとその変化を緩やかにしか利用できないシニアエンジニア達はすぐに追いつかれてしまうかもしれませんし、組織コミットも希薄になっている以上企業や組織としてどちらが重用されるかは明白です。 これからのジュニアエンジニアは、いかに変化に柔軟に適応できるかが重要なのではないかと思います。 受け入れる私たち企業側も、AIを前提とした開発が主流になっていくなかでどのように能力を引き上げていくかはまだ手探りの課題があるでしょう。 基礎となる技術が変わるわけではないのでその部分をしっかり理解したメンバーがきちんと何が重要でどこをAIに移譲していくか考慮した研修などを設計していく必要があります。 かのRuby on Railsの作者DHHもブログエントリで、「常にジュニアの開発者を採用し続ける」と明言しています。 We'll always need junior programmers AIを前提としていく開発業界の中で優秀な開発者の需要は否応なく上がり続けるのは自明であり、AIが開発者の全ての仕事を奪い廃業になっていく未来は見えません。 それはOpenAIやAnthorpicのようなモデルプロバイダーだけでなく、私たちWebサービスの開発でも同様です。 そうした中でBASE社として、ユーザーの経済活動を支え続けるプラットフォームを開発運用して成長していきたい新卒の方に期待を持って今後も新卒採用を続けていく予定です。 もちろん中途採用の方も募集していますので、気になる方はいつでもお声がけください。 採用情報 | BASE, Inc. では、皆様良いお年を。

この記事はBASEアドベントカレンダーの24日目の記事です。 はじめに こんにちは！BASEプロダクト開発チームにて責任者（エンジニアリングマネージャー）をしている 植田 です。アドベントカレンダーも残すところあと2日ですね。 今回は エンジニア組織の「組織デザイン」 をテーマに、BASEの開発組織でこれまで実際に行ってきた組織設計と、その変遷をご紹介します。 組織論やチームトポロジーに関する書籍や記事は数多くありますが、 理論としては理解できるが、自分の組織にどう当てはめればいいかわからない 他社の開発組織が、実際にどう悩み、どう変えてきたのかを知りたい と感じたことがある方も多いのではないでしょうか。 この記事では、「この形が正解です」という話ではなく、なぜその組織にして、どこに課題を感じ、次に何を選んだのかという意思決定の変遷をリアルに書いています。 想定読者 エンジニアリングマネージャー、開発組織の責任者の方 組織設計・組織デザインに興味があるエンジニアの方 前提：BASEの全社組織と、今回扱う範囲 まず前提として、BASEの全社組織の概要を簡単に説明します。 BASEでは事業部制を採用しており、各事業部の中にプロダクト開発・マーケティング・CSなどの機能が配置されています。一方で、SREや情シスなどの全社横断の技術組織は、事業部とは別の技術本部として存在します。こうすることで各事業部の開発組織は事業・プロダクトにおける機能開発や運用といったことに集中しやすい環境が整備されています。 この記事で扱うのは、BASE事業における「Product Dev（プロダクト開発組織）」 の組織設計です。 組織設計の観点とその難しさ 具体的な組織図の話に入る前に、そもそもなぜ組織設計が難しいのかを整理しておきます。 組織設計で考慮すべき論点は非常に多岐にわたります。 事業戦略・プロダクト戦略との整合性 開発組織としてのビジョン、方向性とのアライン 開発PJをパフォーマンス高く推進できるか 開発チームへのPJアサインをスムーズにできるか プロダクトマネージャー、デザイナーとの協業 現状の開発組織の課題を解消できるか 開発組織における各機能をどのように持たせるか 1チームあたりのメンバー人数は何名が適正か 採用と育成との相性 運用体制・フローをどうするか メンバー同士の相性 コードベースと組織境界の関係 専門領域と属人性の落とし所 ざっと挙げただけでもこのような観点が想定されます。1つずつ論点として取り上げ全体の整合性を設計する作業は多くの時間を要します。 しかも厄介なのは、 組織設計は試行回数を簡単に増やせない という点です。組織を変えても、その良し悪しが見えるまでには時間がかかります。頻繁に組織を変えれば現場は疲弊しますし、一方で変えなければ歪みは蓄積していきます。 この前提を踏まえたうえで、ここから実際の組織変遷を紹介します。 フェーズ1：事業戦略ミラーリング型（2022〜2023） 1つ目は「事業戦略ミラーリング型」です。 背景と狙い 当時採用していたのは、 事業戦略と開発組織をミラーリングする構成 でした。BASEは、スモールチーム向けのEC・決済という変化が激しく、事業戦略のスピードが求められる領域です。事業・プロダクトマネージャー・デザイナー・エンジニアが同じ方向を向き、同期的に動けることを重視していました。具体的には”Value Creation Sec”はテイクレート成長に責任を持つ戦略推進、”Core & Capacity Sec”はGMV成長に責任を持つ戦略推進というようにミッションが分かれていました。 得られたメリット 事業戦略の変更に追従しやすい チームごとの守備範囲が明確 特定領域の知見が溜まりやすい 見えてきた課題 一方で、次第に以下のような問題が顕在化しました。 事業戦略の変更に追従するために組織改編が頻発する チームの耐用年数が短く、チームビルディングが進まない サイロ化が進み、隣のチームへの関心が薄れる チームにおいて忙しさの濃淡が生まれる 実際にメンバーからは、「またすぐ組織が変わると思うと、チームを良くしようとするモチベーションが湧かない」という声も上がり、 「強いチームが良いプロダクトを作る」 という前提が揺らぎ始めました。 フェーズ2：Feature Dev型（2024〜2025） 次に選んだのが、 担当領域を固定しない Feature Dev チームを複数置く構成 です。 開発領域を持たない Feature Dev チーム リアーキテクチャを推進する Module Development チーム 狙い 事業戦略変更への耐性を高める PJの割当柔軟性を上げる メンバーの経験領域を広げる モジュラーモノリスへの移行（リアーキテクチャ）に継続投資する 実際どうだったか 一定の成果はありました。 機動力の向上 マンネリ化の軽減 チーム間の負荷は平準化 広くプロダクトを知る機会の創出 しかし2年ほど運用する中で、別の歪みも見えてきました。 誰がどの領域を「守る」のかが曖昧 特定領域を守る・成長させる・身につけるという力学が働かない リリース後の運用責任が分散する パフォーマンス改善など中長期テーマに継続投資し辛い メリットとデメリットは表裏一体ではありますが、2年程度の間にデメリットが少しずつ顕在化するようになってきました。またこの2年の間にリアーキテクチャが前進し、 新たなアーキテクチャ上でスピーディに開発していくことの重要性 が増してきました。 さらに、新機能開発だけでなく、 事業成長とともにサービスレベルを継続的に高めていく必要性 も高まり、専任チームを作る機運が高まってきました。 フェーズ3：ECコア機能領域型（2026〜） そして2026年からは、 ECのコア機能を軸にした組織設計 に踏み切ります。 Item / Order / Checkout はECのコア機能になりリアーキテクチャ境界に近い Feature Dev…当該Sectionにおける開発PJを担う Item Scalability…商品領域のパフォーマンス改善を担う Architecture Design…中期的なアーキテクチャ設計を担う Checkout Reliability…購入に関するスケーラビリティ向上を担う（高負荷対応） この形に込めた意思 耐用年数が長い領域を組織境界にする サービスレベル改善を「片手間」にしない 新たなアーキテクチャに取り組みやすい体制にする 期待するメリット 担当領域に詳しくなり責任を持つ文化の醸成 近い領域を重点的に開発することによるスピードアップ 機能開発以外の、サービスレベル改善の継続的な投資 もちろん、この形も完成形ではありません。サイロ化やマンネリ化のリスクは理解した上で、ローテーションや横断OKRなどで緩和する前提にしています。 まとめ 振り返って強く感じているのは、 組織設計に最終解はない ということです。事業・プロダクト・人が変われば、最適な組織も変わります。 大事なのは、 今の課題は何か 何を優先し、何を捨てるか 次に変える前提で、今をどう設計するか を言語化し続けることだと思っています。 この記事が、どこかの開発組織で「組織を考えるきっかけ」になれば嬉しいです。 BASE では、今後のプロダクト成長を支える技術戦略や開発基盤の構築をリードしていただけるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。 binc.jp

この記事はBASEアドベントカレンダー 2025 の 23 日目の記事です。 エンジニアの右京です。今年後半になって、主に Web ブラウザ上での AI との対話型 UI の利用シーンに、インタラクティブな UI を提供するという流れが注目されています。 この記事はそれを実現するために現在提案されている MCP Apps について簡単に紹介するものです。 対話型 UI の拡張 今年 10 月に OpenAI が Apps in ChatGPT として Apps SDK を発表しました。これは MCP のレスポンスとして ChatGPT の対話型 UI にアプリケーションを組み込むことができる SDK です。 これにより、ChatGPT の対話中に外部のアプリケーションを呼び出して、よりインタラクティブな体験を提供できることが期待されています。 https://developers.openai.com/apps-sdk/concepts/ui-guidelines より引用 developers.openai.com これまでテキストベースのみで行われていた対話に、HTML、CSS、JavaScript を用いたコンポーネントとしてアプリケーションを提供できるようになり、表現の幅が広がります。 さらに、MCP を用いて提供することで、それに対応するプラットフォームであれば恩恵を受けることができるようになります。 OpenAI の発表以前から MCP UI というものも存在していて、こちらも MCP を用いて対話型 UI を拡張するための仕組みです。 また、技術仕様は大きく異なりますが、同時期に OpenAI と Stripe から発表された Agentic Commerce も購買フローを対話的に完了することができ、対話型 UI を拡張する流れの一つだと言えるでしょう。 mcpui.dev www.agenticcommerce.dev 一方で Apps SDK や MCP UI の仕様はもちろん統一されているわけではなく、プラットフォームごとに互換性があるような状態にはなっていません。 そこで、この仕様を標準化できるようにと現在提案されているのが MCP Apps です。 MCP Apps blog.modelcontextprotocol.io github.com ここでは、Apps SDK の Quickstart でサンプルとして登場する Todo アプリを参考に、MCP Apps として実装する場合のイメージを紹介していきます。 サンプルコードと解説は @modelcontextprotocol/sdk と zod を用いた MCP サーバーの実装をある程度把握していることを前提に記述しています。 また、 Apps は提案段階で現時点では動作する実装は試験的なものに限られていることに注意してください。あくまで実装のイメージとして捉えていただけると幸いです。もし、なにかしら動くものが欲しい場合は Apps SDK を利用するのが現実的です。 MCP Apps (と Apps SDK / MCP UI) は以下の 3 つの要素を中心に構成されます: ui:// URI Scheme を利用した MCP Server への Resource 定義 サンドボックス化された iframe でのコンポーネント実行 postMessage を使った JSON-RPC での通信 MCP Apps では、まず MCP サーバーに対して ui:// URI Scheme で Resource を定義します。 @modelcontextprotocol/sdk を使う場合は server.registerResource を利用します。 server . registerResource ( "todo-widget" , "ui://example/todo" , { title : "Todo Widget" , mimeType : "text/html;profile=mcp-app" , } , async () => { return { contents : [ { uri : "ui://example/todo" , text : `<!DOCTYPE html><html>...Todoアプリの実装...</html>` , mimeType : "text/html;profile=mcp-app" , } , ] , } ; } ) ; mimeType が text/html;profile=mcp-app となっているのが特徴的ですね。ここで配信される HTML の全文は以下に折りたたんでいますが、全体を見なくとも雰囲気は掴めるかと思います。 Todoアプリの実装 <!DOCTYPE html> < html > < body > < input id = "input" placeholder = "Add task" > < button onclick=" addTodo ()" > Add </ button > < ul id = "list" ></ ul > < script > let tasks = [] ; window . addEventListener ( "message" , ( event ) => { if ( event . data . method === "ui/tool-result" ) { tasks = event . data . params ?. structuredContent ?. tasks || [] ; render () ; } }) ; function addTodo () { const title = document . getElementById ( "input" ) . value ; window . parent . postMessage ({ jsonrpc : "2.0" , method : "tools/call" , params : { name : "add_todo" , arguments : { title } } , id : Date . now () } , "*" ) ; } function render () { document . getElementById ( "list" ) . innerHTML = tasks . map ( t => `<li> ${ t . title } </li>` ) . join ( "" ) ; } </ script > </ body > </ html > 次にこの Resource を server.registerTool で _meta.ui.resourceUri として Tool に関連付けします。 server . registerTool ( "add_todo" , { title : "Add todo" , description : "Creates a todo item with the given title." , inputSchema : { title : z . string () . min ( 1 ) } , _meta : { ui : { resourceUri : "ui://example/todo" , } } , } , async ( args ) => { todos = [ ... todos , { id : uuid () , title : args . title , completed : false }] ; return { content : [{ type : "text" , text : `Added ${ args . title } ` }] , structuredContent : { tasks : todos } , } ; } , ) ; これで add_todo が呼び出されると、MCP は ui:// URI Scheme で定義されたリソースを取得し、iframe へロードします。この iframe がチャット UI の中に表示されることで、インタラクティブな UI が提供されることになります。そして、Tool の実行結果が ui/tool-result として postMessage で JSON-RPC 形式で iframe 内に送信されます。 window . addEventListener ( "message" , ( event ) => { if ( event . data . method === "ui/tool-result" ) { tasks = event . data . params ?. structuredContent ?. tasks || [] ; render () ; } }) ; この場合は add_todo で返された tasks がそのままメッセージに含まれているので、それを受け取って UI を更新しています。これで UI とチャットの内容が同期されるということですね。 アプリ側から Tool を呼び出すようなことも可能で、以下はタスクを追加するためのボタンをクリックすると Tool を呼び出す例です。 function addTodo () { const title = document . getElementById ( "input" ) . value ; window . parent . postMessage ({ jsonrpc : "2.0" , method : "tools/call" , params : { name : "add_todo" , arguments : { title } } , id : Date . now () } , "*" ) ; } method には専用のものがいくつか定義されており、リンクを開くよう要求したり、チャット UI へメッセージを返すことができるようです。 より詳しい現状の仕様は以下で確認できます: github.com また、今回は素の HTML でアプリを作成していますが、 React コンポーネントとして実装できるような仕組みも提供されています。 この辺りだったり、より詳しい日本語の情報として azukiazusa さんの記事が参考になるかと思います。この記事を書く際にも大変参考にさせていただきました。 azukiazusa.dev 所感 来年以降でこの辺りの整備が一気に進み、実用化されることでビジネスサイドからの注目度もより高まるのではないかと考えています。個人的には(少なくともCoding Agentの文脈の) MCP についてはコンテキストの圧迫やその費用対効果から少し懐疑的なのですが、チャット UI へのサービスの統合は一定のビジネスインパクトがあるだろうなとも感じています。特に Agentic Commerce は EC 領域において大きな影響を与えそうです。MCP が登場した当初から、「これからはチャットでタスクが完結するのでサービスごとのフロントエンドは不要(意訳)」というような意見もありましたが、それが少し現実味を帯びてきたのかもしれません。 ここまでに紹介したように MCP Apps や Apps in GPT は既存の Web 技術の上に成り立っています。これが将来的にどうなるかはわかりませんが、少なくとも数年の間は新しい Web フロントエンドの形として付き合っていく必要がありそうです。これまで一つのドメインに対して一貫性のあるデザインや操作を提供することが中心だった Web フロントエンド開発ですが、MCP Apps のような仕組みが普及することで、サービスの機能をコンポーネントとして切り出していく方向へシフトするかもしれません。サービスの利用方法の一つとして Remote MCP Server が提供されているのが当たり前になり、さらに複数の形で同一のサービスを提供することが一般的になる可能性もあります。 そのためには BFF のような役割を持つレイヤーの重要性が増しそうです。一方で UI Component や Design Token に関してはどの提供方法でも統一したかったりと、全体のアーキテクチャやコード管理の方法にも影響がありそうですし、API を整えたりということも必要でしょう。さらに未来に登場するであろう汎用プラットフォームに向けても対応できるような備えを、なんもわからんなりに考えておきたいですね！ おわりに ざっくりとした紹介になってしまいましたが、MCP Apps のイメージが伝われば幸いです。 今回のアドベントカレンダーでは前半でも記事を書いているのでよかったらそちらもご覧ください！ devblog.thebase.in devblog.thebase.in 明日は @UedaHayato です！お楽しみに！

この記事は BASE アドベントカレンダー22日目 の記事です。 いよいよ年の瀬も近くなってきました。マネージャーの松原( @simezi9 )です。 この時期になるとアドベントカレンダーとして大量のアウトプットが世に公開されるのもすっかり毎年の恒例となりました。 そこで改めて「出版バイアス」という現象とそれを起点とした情報との向き合い方を考えてみよう、というのが本エントリの趣旨となります。 出版バイアスとは何か？ 「出版バイアス」という単語は耳にしたことがあるでしょうか？ この概念は科学論文の世界、とくに医療関係の論文においてよく話題に登場するものです。 その意味とは、肯定的な結果を持つ研究や革新的で独創的であると主張する論文ばかりが世の中に公開される傾向にあり、 そうでない論文、つまり仮説に対してネガティブな結果に終わった研究やはっきりとした結論が出せない研究が世の中に出てこないというバイアスです。 これによって研究の成果が成功例ばかり報告されてしまい、本来よりも過大な評価をうけてしまうという現象が起こります。 これにたいして肯定的な結果を持つ論文しか出版されないことから「出版」バイアスという名前がついています。 これは「生存者バイアス」や「サンクコストの誤謬」といった概念とも相通ずる物があるかと思います。 このバイアスが生まれる理由はとても明快です。 研究者たちからすれば論文として成果を上げるプレッシャーにさらされている中で自分の功績として華々しく主張できない結果をいちいち論文として公表するような手間を取らないし、 読み手側としても刺激的な結果を求めるために否定的な論文は需要が少ないためです。 このバイアスに対抗するための手法というものも様々考案されているようで、統計的手法（ メタアナリシスにおけるファネルプロット など）を用いて、報告されている結果に不自然な偏りがないかをチェックしてみたり、 研究のプロトコルそのものを事前に信頼できる外部機関に登録（研究に際しての仮説、データの取り方や取ったデータの分析手法などを事前に決めておく）したうえで、 結果がどうであれ必ず公表することにする（＝研究の途中に発生するバイアスの除外）といったことが行われているようです。 ファンネルプロットの例 世の中にある出版バイアス この出版バイアスという現象から考えさせられることは多いと私は思っています。 つまり、科学の世界では論文の価値を高めることに非常に重点が置かれるため先述のようなバイアスを自覚し、それを極力排除するような取り組みが行われるわけですが、 そうでない自由な出版物に対してはその動機が存在しないためよりこのバイアスがひどくなるのではないか、と考えているためです。 出版物というのは論文や書籍に限らず、ブログのエントリであったり登壇スライドであったりSNSの投稿であったり、様々なアウトプットに当てはまります。 より具体的に言うと、「〇〇という仕組みを導入したらめちゃくちゃ成功した」という共有は行うにあたって非常にハードルが低いのに対して、「〇〇はダメ」と主張するのは非常に大変ですし（かつ炎上しがちでリスクが高い）、 「〇〇には効果があるのかなんともわからなかった」などという結論がぼんやりした投稿を行うことはさらに難しいです。 結果的に世の中には「〇〇は効果がある」という共有ばかりが残ってしまい、その価値が実態よりも過大に評価されていくという傾向があるように思います。 その〇〇とはもしかしたら例えば「React」だったり「マイクロサービス」だったり「Kubernetes」だったりはたまた「1on1」だったりするのかもしれません（実際にそれらがそうであるという話ではなく、あらゆるトピックが入りうるという例です）。 バイアスと向き合う このバイアスに対抗するというのは実際の問題としてかなり難しいもので、 耳目を集めるアウトプットを出したい著者と刺激的なコンテンツを求める読者、という構図がある限り世の中には自然とそうしたアウトプットが増えていくことになります。 実際にこの文章を書いているさなかでも、もっとかっこいいパンチの効いた主張ができないか、などと考えている自分がいます。 あるいは、アドベントカレンダーで特に動きが盛んになる企業のテックブログなどでは失敗を公表することにより組織のレピュテーションを汚す結果になることを恐れますし、そもそも失敗を認めたくないから書きたくないことも多いでしょう。 本当はもっと様々なアウトプットがまんべんなく公表されていく世の中が理想なのかも知れませんが、 残念ながらこうした出版バイアスというのは避けられずに存在しています。 あらゆる意見表明の場において「共有されずに終わった結果・意見が存在している」ということを意識の片隅に置いておくだけでも物事を冷静に捉える助けになるのではないかと思います。 最後に、出版バイアスの話をきちんと知りたい方は以下の書籍などに詳しいので関心があればぜひ年末年始の課題図書にいかがでしょうか Science Fictions　あなたが知らない科学の真実 作者: スチュアート・リッチー ダイヤモンド社 Amazon 明日は@yaakaitoによる記事です、お楽しみに！