はじめに BASE FeatureDev3Group でWebアプリケーションエンジニア をしている Capi(かぴ) @ysssssss98 です。 2025/05/23(金)と24(土)にベルサール神田で TSKaigi2025 が開催されました。 BASE株式会社はシルバースポンサーとしてTSKaigi2025へ協賛し、BASEのエンジニアが登壇しました。 今回の記事では登壇者のコメントや現地参加したメンバーの感想をお届けします！ 現地参加メンバー 登壇者コメント プログラミングをするパンダ（ @Panda_Program ） 今回は「ボブおじさん」のクリーンアーキテクチャについてお話ししてきました。プロポーザルを採択いただき、貴重な機会をいただけたこと感謝しています。 speakerdeck.com これまでにも何度か登壇した経験はありましたが、今回はこれまででいちばん大きな会場で、たくさんの方にお話を届けることができ、嬉しかったです。 スライドはちょっと多めだったのですが、全体としてはいい流れで進められて、デモも成功して、自分としてもかなり満足のいく発表になりました。 会場の雰囲気はとても温かくて、差し込んだお笑いネタにもちゃんと反応していただけて（笑）、本当に話しやすかったです。発表後には「分かりやすかったです」「よかったです」と声をかけてくださる方もいて、少しでも誰かの参考になったなら何よりだなと思いました。 今回の発表は、自分の中では3部作の第2部という位置づけでした。 第1部： モジュラーモノリスについて （各モジュールはクリーンアーキテクチャ） 第2部（今回）：クリーンアーキテクチャ 第3部（次回）：クリーンアーキテクチャで、ドメイン層とユースーケース層のコードをどう書くか 続きとなる第3部は、来月開催されるPHP Conference 2025でお話しする予定です。こちらも準備中です。 また、当日使用したスライドには、後半に付録もつけてあります。 当日会場でご覧いただいた方も、見逃してしまった方も、よければスライドを見返してもらえると嬉しいです！ 現地で見たセッションを一部紹介 当日イベントに参加したFutoshi Endoさん、gatchan0807さん、Mashu Kushibikiさんに現地で見たセッションのうち特に気になったセッションのレポートをいただきました！ Rust製JavaScript/TypeScript Linterにおけるプラグイン実装の裏側 by unvalley さん @Capi 2025.tskaigi.org BiomeのCoreメンバーであるunvalleyさんによるLinterの話です。TypeScriptの話しというより言語を支える技術の話です。 ESLintの話から始まり、Biomeが今後どこへ向かっているのかを知れました。他のLinterとの差分も説明いただけたのもよかったです。 難しい箇所はわかりやすく噛み砕いて説明いただけたのでツールチェインやRust、Linterのアルゴリズムに詳しくない自分でも話しに置いていかれることはほとんどありませんでした。 登壇を聞いてツールチェインとJavaScriptランタイムの関係性などJavaScripy/TypeScriptの深い領域に触れることができました。 Pragmatic Functional Programming in TypeScript by yasaichi さん by @Futoshi Endo 2025.tskaigi.org 関数型プログラミングにおける「5つの原則」を紹介しながら、その原則を実際にTypeScriptを例に統合し、活用できるスライドでした。 関数プログラミングにはあまり詳しくないのですが、サンプルコードを使った具体的な例があったので、個人的にもとても理解しやすい発表でした。 特に「Make illegal states unrepresentable」のルールは「型」で縛る、TypeScriptと相性が良いなと思いました。発表では全部のルールを厳密に適用するのではなく、これらの原則を部分的に適用することで効果が得られると語られていましたし、自分も実践したくなりました。 「TS特化Clineプログラミング」 by mizchi さん @Futoshi Endo 2025.tskaigi.org mizchiさんの発表でTypeScriptを中心に、効果的なプロンプトの紹介と、実際に活用してみてうまく行った事、うまくいかなかった事を整理した上で本当に実践で活用できるTipsを紹介されてました。 現在、自分は社内でAIツールを導入したり、サポートする立場になっているので、「コード生成にスキルを寄せる」というのはとても刺さりましたし、まだまだやれる事があるなと思いました。 この発表を聞くまで自分の中では、AIをまだ"副操縦士"として扱っているというか、操縦士の席を譲る覚悟がなかったような気がします。 ただ、これからはコーディングの速度や生産量でいえば圧倒的にAIの方が発達していくのは目に見えているので、これからは"AIも操縦士"として扱ってスキルを学んで行こうと思いました。 AI Coding Agents Enablement in TypeScript by Yuku Kotani さん @gatchan0807 2025.tskaigi.org UbieのYukuさんのこちらの発表が非常に印象に残りました！ まず冒頭で触れられた「解空間」の話は、生成AIを使った開発をする上で開発者間の共通認識として持つべき重要な概念だと改めて感じました。AIがコードを生成する際の可能性の範囲と、それをいかに適切に制約していくかという視点は、今後のAIとの協調において不可欠だと思っています。 特に学びがあったのは、解空間を適切に絞り込むためのツールやルールの重要性、そしてその実行速度がAgent時代における開発サイクルの速さに直結するというお話です。 AI Agentの高速なフィードバックループで真価を発揮するために型情報の扱いやLinterルールをAIに作らせるアイデアはAIの自律性を高める具体的な道筋として非常に興味深く、自分たちの環境にもいち早く取り組みたいポイントだなと思いました。 少し未来には当たり前になりそうなAIと共存する開発スタイルについての解像度が高まるとても素晴らしい発表でした。 技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術 by azu さん @Mashu Kushibiki 2025.tskaigi.org JS のオンライン技術書である JavaScript Primer を執筆・運営されている Azu さんの発表です。 JavaScript の仕様が変化するためが速いため、書籍もその変化に対応できるように作っているとのことでした。まず、段落や章ごとの依存関係を整理し、「既知から未知」の順に説明するしくみになっています。 この考え方は、ソフトウェア開発でいう部品の分け方や依存関係の管理と似ている、という説明でした。 つまり、技術書の執筆とメンテナンスをソフトウェア開発と同じ手法で進めているというのが今回の発表の趣旨でした。Ask the Speaker では、Azuさんがどうやってこうした発想にたどり着いたのかを直接聞けて、とても参考になりました（ この部分については個人ブログで感想を書きました ）。 オンライン版ではコード実行ボタンが何回押されたかを Google アナリティクスで計測するなど、デジタルならではの工夫も紹介され、非常に示唆に富む発表でした。 現地ブース 会場では各スポンサー企業のブースがありました。各社個性的なブースばかりでTSKaigiに向けてアンケート企画を作っていたりTSKaigi用にサービスを用意していました。 自分はダイニーさんのブースでアンケートに回答するともらえるレシート(自分の回答に値段がついていて合計金額が印字されている)、キーホルダー、扇子をいただきました。 ダイニーさんのブースでいただいたもの おわりに 社員の登壇参加、協賛活動を通してTypeScriptコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。 BASEは現在エンジニア積極採用中です！興味がある方は採用情報もぜひご覧ください！ binc.jp

はじめに BASE BANK Departmentで開発責任者をしている斉藤です。 BASE BANK Departmentは金融領域の事業を担当しています。 Departmentに在籍しているエンジニアは10名ほどです。 私たちは全員がフルサイクルエンジニアを目指しており、この記事ではその理由を紹介します。 フルサイクルエンジニアとは 私たちが考えるフルサイクルエンジニアとは、ソフトウェアライフサイクルの全域に責任を持ち、ユーザーに価値を届けることにフォーカスするエンジニアのことです。 先日、同僚のDoarakkoが書いた「 フルサイクルエンジニアとしてどう事業に貢献するか 」に記載のあった表現もまさにそのとおりだと思っています。 エンジニアリングに軸足を置きつつ、事業に貢献するために必要なことをなんでもやるエンジニア フルサイクルエンジニアはNetflixのTech Blogで公開された「 Full Cycle Developers 」に由来するものです。 今回の内容に関するところを要約すると、以下のような内容になります。 ソフトウェアライフサイクルとは、アイデアを顧客向けの製品やサービスに効果的に変換するための開発と運用の全体・全責任を指す ソフトウェアライフサイクルの目的は、time to value（価値を生み出すまでの時間）を最適化すること Full Cycle Developerとは、ソフトウェアライフサイクル全体に責任を持つ開発チームのメンバー Full Cycle Developerは、ソフトウェアライフサイクル全体を通して専門知識を活用し、自動化や効率化を推進し、直接的なフィードバックループを通じて学習と改善に貢献する 元記事はDevOps文脈の具体例も多いですが、上記のことを踏まえると目的は同じだとおもっています。 私たちはエンジニアが企画から要件定義、設計、開発、テスト、QA、運用、ふりかえりを含めた全域で活躍することを期待しています。 なぜ目指すのか 1. 部分最適ではなく、全体最適するため 私たちのゴールはユーザーの課題を解決し、価値を届けることです。 狭義の開発だけでは価値を届けるところまで見えづらいと考えています。 その中でのボトルネック解消、最適化は部分最適になりかねません。 ソフトウェアライフサイクル全体に関わりながら、全体を俯瞰することで、本当のボトルネックはなんなのか、課題がななんなのかが見えてきます。 そのボトルネックや課題をチームで解決することで、届けられる価値を増やせたり、届けるスピードをあげていくことできるはずです。 Netflixの言葉を借りれば、私たちも「time to valueの最適化」のためにフルサイクルエンジニアを目指しています。 2. 少人数で新規事業の仮説検証を高速に実現するため 私たちは0→1の新規事業立ち上げを行っています。 昨年はPAY.JP YELL BANKを立ち上げ、今年もいくつかの企画が進んでおり、今後もそういう機会は多いでしょう。 当たり前ですが、新規事業でもソフトウェアライフサイクルを回していき、プロダクトをより良いものにしていきます。 この時に多くのエンジニアがいなければソフトウェアライフサイクルを回せない、改善できない状態は新規事業の立ち上げにとって大きなコストになります。 その分だけ立ち上げが難しくなってしまうでしょう。 一人一人のエンジニアがソフトウェアライフサイクル全体で活躍し、PdMやデザイナーなどのメンバーと協力しながら、少人数でサイクルを素早く回せることができれば、コストを抑えられます。 その結果して、コストパフォーマンスよく、仮説検証をたくさん行えることで、事業の立ち上げ成功の確率を上げられます。 新規事業を成功に導けるチームを目指すうえで、フルサイクルな関わり方は不可欠です。 フルサイクルエンジニアの活躍で事業を成功に導きます。 3. 成長しながら、開発を楽しむため 施策としての成否はもちろん、設計や実装の成否も実際にリリースしてみないとわかりません。 ユーザーの反応を受け取ったり、プロダクトが伸びることで、よかった点や改善点が見えてきます。 だからこそ、なぜつくるのかを考え、設計、実装し、リリースし、フィードバックを受け取る。さらにフィードバックから改善する。 この一連の流れにすべてに関わることが、エンジニアとしての成長につながると私たちは感じています。 自分たちが実装するものの背景はなにで、リリースした結果どうだったのか、それらを深く理解することで、開発がより創造的で、おもしろくなっていくと私たちは信じています。 フルサイクルエンジニアが集まるとどうなるか 越境が当たり前になる フルサイクルで開発を進めるには、職域や職能の壁を越えることが不可欠です。 「誰の仕事か」ではなく「プロダクトを前に進めるために何が必要か」に目を向けて動けくことが求められ、 「ここから先は他のメンバーの担当」「これは自分の仕事ではない」と線を引かず、 プロダクトを前に進めるために必要だと思ったことには自ら行動するという姿勢がチームに自然と広がっていきます。 そうなると、職能を超える越境が当たり前になり、連携が生まれ、チーム全体で価値を届ける動きが加速します。 オーナーシップが生まれる ソフトウェアライフサイクル全域で活躍し、自ら意思決定し、実装し、リリースし、運用し、ふりかえり、改善する。 このような動きを繰り返していくことで、エンジニアの中に「自分がプロダクトを伸ばす」という意識が育ちます。 そして、職能に関係なくチーム全員がフルサイクルに動き、プロダクトを伸ばす意識を持てると、それぞれがより良く回すための意思決定と行動ができるようになります。 その結果として、ユーザーに価値が届くまでの時間（time to value）も短くなり、スピードと質を両立できる強いにチームになっていきます。 おわりに ここまで書いてきたことは、もしかすると当たり前に感じるかもしれません。 実際、私たち自身もフルサイクルで関わるのが自然と思っています。 ただ、その当たり前をチーム全体で継続し、組織の文化として根づかせていくのは簡単ではありません。 私たちのチームも、まだ理想には届いていません。目指し続けている最中です。 「一緒に目指してみたい！」と思ってくれる方がいれば、とても嬉しいです！ binc.jp

はじめに こんにちは！ BASE BANK で、BASE を利用するショップオーナーさんが簡単に資金調達できるサービス「 YELL BANK 」の開発を担当している  Doarakko  です。 今回は BASE BANK が掲げているフルサイクルエンジニアという働き方の中で、YELL BANK の開発チームが実際にどのようなことを行なっているのかいくつか紹介します。 フルサイクルエンジニアとは これまでソフトウェアライフサイクルの各段階を分業、専門化していた状態から、よりスピーディにプロダクトアウトプットし続けるために一連の段階を価値提供に関わるエンジニア、チームが責任を持ち、実行できるようにしようというスタンスです。 Real World Full Cycle Developers から抜粋させていただきました。 私はフルサイクルエンジニアを、エンジニアリングに軸足を置きつつ、事業に貢献するために必要なことを何でもやるエンジニアと解釈しています。 何でもやるとは言いつつ、プロダクトを形にしてユーザーに届けることがエンジニアの一番の仕事です。 今回は形にすることとは少し離れたところで、フルサイクルエンジニアとして行っていることを紹介します。 実際に行っていること 事業影響の大きい数値の監視とその対応 事業責任者・事業企画・PdM・PMM・アナリスト・オペレーション・デザイナー・エンジニアと、職種ごとに責務は異なります。 見ている数字は基本的にどんどんブレイクダウンしていき、それぞれの領域で事業影響の大きい数値に責任を持つ必要があります。 そこで実際に YELL BANK の開発チームで監視しているものを2つ紹介します。 機械学習の推論結果の監視 YELL BANK ではショップごとの売上を元に資金調達可能な金額を算出しています。 売上が大きければ大きいほど、資金調達可能な金額も大きくなります。 金額の算出には機械学習を使用しています。 また YELL BANK は全てのショップが利用できるわけではありません。 ショップごとに審査を行なっており、その中でも機械学習が使用されています。 資金調達可能な金額はショップオーナーさんの資金繰りの不安を解消し、次の挑戦を支えることができるのかという点、ショップごとの審査結果は利用可能なショップ数に影響を与えるという点で、非常に重要な数値です。 機械学習を用いたシステムが通常のシステムと異なるのは、エラーにはなっていなくても問題が起きているケースがあるということです。 例えば アルゴリズムの変更により、金額が意図せず大きく変化している データの変化により、審査に通っているショップ数が少なくなっている 機械学習の推論結果は毎日変化するため、バッチでショップごとの推論結果を S3 に保存し、そちらを BigQuery に連携しています。 そこから Looker とそのアラート機能を用いて、一定の変化があると Slack にアラートを飛ばすようにしています。 実際に数値に変化があった際は、アナリストと連携して対応を行なっています。 YELL BANK の支払関連の数値の監視 YELL BANK のビジネスモデル上、ショップオーナーさんが資金調達しただけでは私たちの売上にはなりません。 資金調達後にショップオーナーさんが支払いを完了して初めて、私たちの売上になります。 支払いはショップの商品が売れた（正確には売上が計上される商品が発送された）時に、商品の売上金額を元に YELL BANK への支払金額が決まります。 ショップの売上が少ないときに、なるべく YELL BANK の支払いが負担にならないような仕組みです。 https://yellbank-lp.thebase.com/ YELL BANK の支払い金額は、商品の代金から様々な手数料が差し引かれた後の売上から計算されます。 そのため YELL BANK の支払い処理は、発送や手数料が関連する様々なプロジェクトの影響を受けます。 基本的にはプロジェクトチームと連携しながら対応を行いますが、考慮漏れやデータ量の増加による影響で、YELL BANK の支払いが正常に行えていないことがあります。 支払いに関するいくつかの数値を監視し、異常があった際には修正や他チームとの連携をとって対応を行なっています。 オペレーションチームと協力して運用業務を効率化 BASE BANK のオペレーションチームはショップオーナーさんからの問い合わせ対応だけではなく、利用可否の最終チェックや資金調達後のフォローなど様々な業務を行っています。 ユーザー数の増加に比例して日々の運用業務にかかる工数も大きくなっていました。 そこでオペレーションチームとエンジニアが協力しての、運用業務効率化プロジェクトが始まりました。 始まったきっかけは BASE BANK で月に1回行っている全職種合同の LT 会です。 オペレーションチームのメンバーから日々どのような業務を行っているのか発表があり、その中で日々の運用業務にかかる工数が大きくなっていることを知りました。 運用業務を効率化するためには、まずはエンジニア自身が実際の業務を体験しないとということで、オペレーションチーム主導で運用業務の体験会を開催していただきました。 実際にエンジニアが業務を体験することで、どの作業に負担がかかっているのか、どこがボトルネックになっているのか、オペレーションチームの生の声を聞きながら理解を深めることができました。 体験会後にエンジニアが運用業務の内容を Figjam に整理し、それを元にオペレーションチームと効率化の方針を議論、アウトプットイメージをすり合わせました。 開発がスタートした後も細かい頻度でシステムに触っていただくことで、FB のサイクルを何回も回し、手戻りを抑えながらスピーディーに開発を進めました。 リリース後にはうれしい FB をたくさんいただきました。 その後も追加の効率化案をオペレーションチームから提案していただき、現在も継続して開発を行っています。 オペレーションチームの情報発信をきっかけにエンジニアが形にして始まったこの取り組みを、チームとして今後も継続していければと思います。 AWS のコスト削減 BASE BANK では毎月の AWS の金額の増減をウォッチして、変化があった際には調査・対応を行なっています。 一部ではアラートも設定して、金額の急激な変化にもすぐに気づけるようにしています。 ただそもそもの現在のコストに対して、コスト削減できるところがないかというところは見れていませんでした。 そこで昨年末に、AWS のどのサービスにどれくらいお金がかかっているのかをチームで確認。 金額が大きいものから順にコスト削減できるところがないかを調べていきました。 その中で使用している ElastiCache がオーバースペックであることや、不要なリソースが存在していることがわかりました。 不要なリソースについては削除、Elasticache についてはシステムの数値を監視しながら段階的にスペックを落としていき、最終的には年間約110万円のコスト削減に成功しました。 サービスをグロースして売上を立てるのは変数も多く不確実性も高いですが、インフラコストの削減は（基本的には）自分たちのシステムときちんと向き合えば実現可能です。 AWS のコスト削減については、まだチーム内の知見が少なく、小さな対応しかできていないため、伸びしろがあると考えています。 社内の他チームと知見を共有しながら、引き続きやっていければと思います。 おわりに 今回紹介させていただいたのはあくまで一例で、事業に貢献するためにやれることは他にもたくさんあると思います。 この記事を読まれた方が、自分たちの組織ではエンジニアがこんなことをやっていますということを発信していただけるととてもうれしいです。 （フルサイクルエンジニアを掲げていなくても） また BASE BANK はこういったことがやり尽くされている組織ではありません。 現在複数の既存事業のグロースと新規事業の立ち上げを行なっており、やれることはたくさん転がっています。 転がっていることに気づいていないこともたくさんあると思います。 少しでも興味を持っていただけたら、気軽にカジュアル面談に来ていただきたいです！ 採用情報 | BASE, Inc. - BASE, Inc.

はじめに BASE FeatureDev3Group でWebアプリケーションエンジニア をしている Capi です。 2025/3/21（金）- 3/23（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2025 が開催されました。今回はPHPerKaigi 2025に参加したメンバーのコメントや感想をお届けします！ 現地参加メンバー PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年はゴールドスポンサーとして協賛しました。 登壇者コメント Saki Takamachi 高町咲衣 @takamachi1saki BASEにてバックエンドエンジニアをしています、さきち(高町咲衣)です！ PHP Foundationのコア開発者(専門領域 PDO、BCMath)、そしてPHP 8.4のRelease Managerをやらせていただいています。 今回の登壇では、PHP 8.4で大幅にパフォーマンスアップしたBCMathについてお話させていただきました。 BCMathはPHP8.4での変更箇所が本当に多く、40分に収めるために敢えて取り上げなかった箇所もありましたが、大きな変更点はなんとか全てお伝えできたかと思います。 speakerdeck.com C言語でかなり低レイヤ寄りの内容となりましたが、たくさんのフィードバックをいただけて励みになりました！ php-srcの中身についての話だったので興味を持ってもらえるかという不安があったのですが、本当にたくさんの方々が来てくださり、この内容で登壇させていただいて良かったと思っています。 たくさんの国がある中、間違いなく日本のPHPコミュニティは、PHPを支える主要なコミュニティのひとつだと実感した登壇となりました。 プログラミングをするパンダ（ @Panda_Program ） BASE にて Advanced Engineer をしておりますプログラミングをするパンダです。去年末までその肩書きだったのと通りがいいので社外ではシニアエンジニアと名乗っています。社内での正式な肩書は Advanced Engineer です。ややこしいのでシニアエンジニアって思ってもらって大丈夫です。 さて、今回はBASEのリアーキテクチャの中心地であるモジュラーモノリスについて紹介しました。PHP界隈ではまだBASEはレガシーなアプリケーション上で開発していると思われているのかもと感じていたため、そうではなくてクリーンなアーキテクチャで日々開発しているんだということを伝えたかったためです。 モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま speakerdeck.com 本発表は、テックリードである kawashima さんのPHPerKaigi 2022の発表の続編となることを意識して作りました。 BASE大規模リアーキテクチャリング speakerdeck.com 自分の方はモジュラーモノリスの概要説明にとどまりましたが、技術的な深い話はいつかどこかで kawashima さんや熱意のあるメンバーがしてくれると思います。 PHPerKaigi 2025は登壇もセッションへの参加も本当に楽しませて頂きました。スタッフの方々、参加された方々、みなさんありがとうございました！ 02 ( @cocoeyes02 ) BASE BANKにてフルサイクルエンジニアをしています、02です。 今回は登壇と1つアンカンファレンスに登壇しました。 PHP8.4におけるJITフレームワークIRと中間表現について理解を深める speakerdeck.com 当セッションでは、PHP8.3までのPHPのコンパイルについて簡単に説明しつつ、PHP8.4で導入されたJITコンパイラ内の中間表現および中間表現フレームワークIRについて概要の解説をしました。 40分というのはあっという間で、いくつか概要や表面的なところに留めた内容になったところもありました。特に最適化の部分はアルゴリズムについてガッツリ解説するのではなく、PHPのコードを例にしてどういうことをやっているのか雰囲気を感じとれるようにする流れにしました。 印象的だったのは、中間表現の前にそもそもJITについての質問がいくつかあったことが記憶に残っています。スライドにも書いてある通り、範囲を絞ってもそれだけで1トピックの発表になる分野なので、JITはJITで話しても良いかもしれませんね。 また、アルゴリズムについてガッツリ解説パートも何らかの形でアウトプットしたいなと個人的には思っております。 meihei ( @meihei ) speakerdeck.com BASE で PHPer をしています、meihei です。 PHPerコードバトル準々決勝・準決勝に出させていただき、「List とは何か？」というタイトルで LT を発表させていただきました。 PHPerコードバトルは、簡単なPHPのコードを制限時間内でより短く書いた方が勝ちというバトルでした。 普段の業務であれば絶対に使わないようなコードの書き方をふんだんに使い、より短い書き方を選択し続けました。とても楽しかったです。 <?php echo $ s = ( $ _ = "str_repeat" )( '*' , $ w = fgets ( STDIN )) . " " ; foreach ([ ... range ( 1 , $ w / 2 ) , ... range ( $ w / 2 - 1 , 1 )] as $ i ) echo $ _ ( ' ' , $ i ) . '* ' ; echo $ s ?> ↑準々決勝で会場を沸かせたコード。標準入力から渡された整数からΣの形に * を出力するという問題でした。 「List とは何か？」という発表では、PHP 8.1 から追加された array_is_list という関数の RFC を読み解いて、仕様・静的解析・内部実装の視点から解説しました。普段から何気なくリストを使っているかと思いますが、新たな気づきを得るきっかけとなってもらえると幸いです。 現地で見たセッションを一部紹介 当日イベントに参加したCapiさん、Hiroki Otsukaさんに、現地で見たセッションのうち特に気になったセッションのレポートをいただきました！ コードバトル @OtsukaHiroki 今回初開催となるコードバトルのmeiheiさんが参加された準々決勝・準決勝を観戦しました。 元々コードゴルフという競技を知らず、どのような対戦をするのかワクワクしながら観戦を始めました。 いかにコードを短く書くかが重要なので、普段のコーディングでは絶対に使わないような記述や関数が大量に出てきて、とても勉強になりました。 どのようなコードが出てきたかはmeiheiさんが記載していただいているので割愛します。 OpenTelemetryを活用したObservability入門 @OtsukaHiroki OpenTelemetryを活用したObservability入門 by 清家史郎 | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp OpenTelemetryというツールを利用したObservabilityを向上させるための仕組みなどを解説されているセッションでした。 OpenTelemetryでの計装を切り口にObservabilityの利点や実際の分析方法を改めて理解することができました。 弊社ではNew Relicを利用しておりOpenTelemetryは利用していないのですが、特定のベンダーに依存しないOpenTelemetryの利点なども詳細にご説明いただき、OpenTelemetryにも興味が湧いてくる内容でした。 技術的負債を正しく理解し、正しく付き合う @OtsukaHiroki 技術的負債を正しく理解し、正しく付き合う by 河瀨 翔吾 | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp 技術的負債とは何か、正しく付き合うためにはどのように考えれば良いのかなどを解説されたセッションでした。 技術的負債については開発者としては切っても切れない問題だと思っています。 私自身も今まで何度も向き合ってきたのですが、「技術的負債は適切にコントロールする」や「腐敗防止層」「リファクタリングを日常のルーティンにする」など、技術的負債との付き合い方の色々な考え方を新たに知ることができました。 すぐに始められる内容もあったので、早速取り入れてみたいと思う内容でした。 ※安全に倒し切るリリースをするために: 15年来レガシーシステムのフルリプレイス挑戦記 @Capi 安全に倒し切るリリースをするために：15年来レガシーシステムのフルリプレイス挑戦記 by さくらい | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp さくらい さんの「 15年間継ぎ足し継ぎ足しで開発してきたECサイトのコア機能を刷新。また、リリース後の障害発生を0に抑えた 」という内容の登壇でした。 ペンギンテストという手法を自分は初めて知りました。ペンギンテストを使うことでバグを発生させないリリースはもちろん、過去の負債を返済するというところが非常によかったです。 登壇の中でペンギンテストの 注意点とその対応例 もお聞きすることもできました。リプレイスプロジェクトに取り組む機会があれば取り入れたいなと思うので自分の頭の引き出しに入れておきます。 ソフトウェア開発におけるインターフェイスという考え方 by 小山健一郎 @Capi ソフトウェア開発におけるインターフェイスという考え方 by 小山健一郎 | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp 小山健一郎 さんの「 身近に存在するインターフェイスを観察しながらソフトウェアおけるインターフェイスを抽出してみよう 」という内容の登壇でした。 世の中にあるインターフェイスの説明から始まり、PHP, Goのコードを例に出しながらプログラミングのインターフェイスについてご意見聞けました。 インターフェイスは提供するものと利用するものの取り決め、つまり契約とも言える。 という部分は面白かったです。また、APIやデータベーススキーマも提供者と利用者がいてその間にある契約と言えるのではないかという話しも面白かったです。 最後のQAタイムで「インターフェイスを認知するためにはどうしたら良いですか？」という質問があり、「まず触れてみてください」という回答がありました。実務はもちろん実務外でもインターフェイスを使った実装をしてみようと思います。 世の中は想像以上にインターフェイスで溢れてる かもしれません。 PHP実行環境の歴史 PHP-FPMからFrankenPHPの誕生へ @Capi PHP実行環境の歴史 PHP-FPMからFrankenPHPの誕生へ by ma_me | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp ma_me さんの「 PHPってどうやって動いてるんだっけ？その歴史は？に答える内容 」の登壇でした。 Apache + CGI + PHP で動いていた時代から始まり Go製のWebサーバーCaddyにPHPを統合したFrankenPHP誕生までの流れを図を用いて説明していただきました。 自分は前職でもPHPを触っておりdocker-composeを書く機会もありました。その時に自分自身が思っていたことが登壇の内容で触れられて嬉しかったです。 新しいものの方が優れている というのではなく 昔の構成も今は進化している という話しや 最近出てきた技術にもメリットデメリットがあって新しいものを実戦に投入することが必ずしも正解ではない という話しが聞けて良かったです。 再演: The PHPer’s Guide to Daemon Crafting, Taming and Summoning @Panda_Program 再演: The PHPer’s Guide to Daemon Crafting, Taming and Summoning by uzulla | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp uzulla さんがPHPで Daemon（デーモン）のプログラムを作ったというセッションでした。 難しそうな内容もさることながら uzulla さんの会場の盛り上げ方が上手いの何の。そこで紹介されていたPHPで非同期処理を書くための amphp というライブラリも初めて知って、ああ、テックカンファレンスに来たなと思いました。またスライド見返して復習したいと思います。デモ動画も最高でした！ パスキーでのログインを実装してみよう！ @Panda_Program パスキーでのログインを実装してみよう！ by ヒビキ | トーク | PHPerKaigi 2025 #phperkaigi - fortee.jp hibiki_cube さんがパスキーの仕組みを解説するセッションでした。去年が初登壇だったとのことですが、話の構成やスライドがとてもわかりやすかったです。 パスキーの仕組みや特徴がパスワードとの比較でわかりやすく解説されていました。またその場でパスキーログインを試せるデモサイトが用意されていて、参加者がパスキーでログインをすると書き込みができる掲示板のようなサイトでした。 Q&Aで「古い端末の場合はどうするのか」という難しそうな質問でも、ブラウザが対応していればQRコードが出てくる仕組みがあるなど的確に答えられているのが印象的でした。とても安心感があり、同じスピーカーとして見習いたいなと思いました。 おわりに 協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。

はじめに BASEのProductDevでエンジニアをしているTorataです。 2025年4月12日に開催されたPHPカンファレンス小田原2025に松スポンサーとして協賛し、BASEのエンジニアも5人登壇しました 今回の記事では登壇スライドの紹介とカンファレンス内の様子をお届けします！ 登壇の紹介 今回のカンファレンスではなんとBASEのエンジニアが5人も登壇しました。 PHP8.4のリリースマネージャを務めた takamachi saki さんを始め、BASEのCTO dmnlk さん、 meihei さん、 02 さん、 endo さんが登壇しました。 1つのカンファレンスに5人も同じ会社のエンジニアが登壇するというのは中々珍しいのではないでしょうか？ PHPカンファレンス小田原を大いに盛り上げた、BASEからの登壇者の発表スライドをそれぞれ乗せますので、見逃した方は見てみてください〜！ takamachi saki さん speakerdeck.com meihei さん speakerdeck.com 02 さん speakerdeck.com dmnlk さん speakerdeck.com endo さん speakerdeck.com ブース企画 PHP 8.4から、 takamachi saki さんの貢献により、BCMath拡張モジュールにおいて大幅なパフォーマンス向上が実現されました。 そこで今回は、その性能差を体感してもらうために「BCMath 8.4 vs BCMath 8.3 vs 人間」という企画を実施しました！ 企画内容 BCMathのパフォーマンスを、PHP 8.3・PHP 8.4・人間の脳で競わせるというもので、 勝負は以下の条件で行いました： - BCMathは60桁の数値同士の四則演算を600万回実行 - 参加者の方には2桁の数値同士の四則演算4問 - よーいどんで初めてどれが速いかの勝負 実行したプログラムのポイント $a = '123456789012345678901234567890123456789012345678901234567890'; $b = '987654321098765432109876543210987654321098765432109876543210'; for ($i = 1; $i <= $iterations; $i++) { bcadd($a, $b); bcsub($a, $b); bcmul($a, $b); bcdiv($a, $b); } このように、60桁の長大な数値に対して、BCMath関数で四則演算をひたすら繰り返します。 この内容で実行してみると - PHP 8.3： 約14秒 - PHP 8.4： 約4秒 となりました。約14秒は人間がギリギリ勝てるかどうかの時間です！ 直接 takamachi saki さんにもアドバイスをもらっていたお陰もあり、わかりやすくパフォーマンス向上を感じてもらえるようなプログラムを作ることができました！ この高速化のためにどんな改善を行ったのか？については、php-srcのプルリクエストから見ることが出来ます！ https://github.com/php/php-src/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aclosed+label%3A%22Extension%3A+bcmath%22+author%3ASakiTakamachi オススメのプルリクエストは乗算のパフォーマンス改善をした php/php-src#14213 です。 結果は…? 一部の参加者は、なんとBCMath 8.3に勝った方も！どれだけBCMathの処理速度が向上したか、肌で感じていただけたのではないでしょうか。 中にはBCMath 8.4に勝った猛者も…!? 対決形式ということもあり、ブースは大いに盛り上がりました。ご参加いただいた皆さま、ありがとうございました！ カンファレンスの様子 PHPカンファレンス小田原は、他の技術系カンファレンスとはひと味違う、地域密着型の温かさと工夫にあふれたイベントでした。 まず印象的だったのは、地元・小田原のマスコットキャラクター「梅丸くん」の登場。来場者を出迎えてくれるその姿に、会場全体が和やかな雰囲気に包まれていました。 そして何より、会場で流れていた梅丸くんのテーマソングがとにかく印象的で、イベントが終わった今でも頭から離れません。 www.youtube.com さらに、地元の飲食店とコラボした「ランチコラボ」では、カンファレンス限定の特典が提供されるなど、小田原ならではのこだわりが光っていました。 また、会場内には小田原市の協力による「移住相談ブース」も設置されており、ただの技術イベントにとどまらない、地域との深いつながりが感じられる空間に。 地域の魅力と技術の楽しさが見事に融合した、まさに“ここだけ”の体験が詰まったカンファレンスだったと思います。 また、小田原大合戦というチーム同士でスコアを競うイベントも大いに盛り上がりました。弊社のメンバー（ @Panda_Program ）のチームが2位になり、運営の方から景品のカードゲーム SQLビルダー を頂きました。社内で遊ばせて貰います。ありがとうございました！ おわりに 自分自身PHPカンファレンス小田原に参加したのは今回が初めてだったのですが、とても印象的なカンファレンスでした。 お忙しいにも関わらず開催の準備などをしていただいたスタッフの方々や登壇してくださった皆様ありがとうございました！ 来年は開催されないとのことですが、もしまた開催されたらぜひ参加したいですね！ BASE は現在エンジニア積極採用中なので興味があれば採用情報もぜひご覧ください! binc.jp

はじめに 2025/4/12（土）、おだわら市民交流センター「UMECO」で PHPカンファレンス小田原 2025が開催されます。 BASE株式会社は松スポンサーとしてPHPカンファレンス小田原 2025へ協賛しています。 PHPカンファレンス小田原 とは 「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 phpcon-odawara.jp PHPカンファレンス小田原のnoteでは深掘り情報も発信されています。 note.com 登壇メンバーのご紹介 PHPカンファレンス小田原 2025では、BASEで活躍している5名のメンバーが登壇予定です。 高町咲衣さん「 OSSコントリビュートをphp-srcメンテナの立場から語る 」 meiheiさん「 改めて学ぶ Trait の使い方 」 02さん「 新しいPHP拡張モジュールインストール方法『PHP Installer for Extensions (PIE)』を使ってみよう！ 」 川口 将貴さん「 PHPバージョンアップから始めるOSSコントリビュート 」 Futoshi Endoさん「 New RelicのAPMを活用したECサービスにおけるメール遅延解消の舞台裏 」 ブースのご紹介 当日はBASE株式会社としてスポンサーブースの出展も行います。ブースでは来場者の方に楽しんでいただけるような参加型の企画を用意しています！参加される方はぜひBASEのスポンサーブースにもお立ち寄りください。 おわりに PHPカンファレンス小田原 2025 本編のチケットは4月9日時点で完売しているようなのですが、後日こちらのブログでも参加レポートをお届けする予定です。楽しみにお待ちください。 PHPカンファレンス小田原 2025で、みなさまにお会いできることを楽しみにしております！

はじめに こんにちは、BASEのエンジニアの田中大貴です。普段はお客様の安心安全な購入やショップ運営を実現するためのデータ分析や機械学習モデルの開発運用を行っています。今回は、グラフデータベースであるAmazon Neptuneのバージョン更新のため、公式のブルーグリーンデプロイメントガイドに従って作業をしたところ、いくつかはまりポイントがあったのでどなたかの参考になればということで共有させていただきます。 Amazon Neptuneとは AWSが提供するマネージド型グラフデータベースです。リレーショナルデータベースと比較して、グラフ構造のデータに対して高速にクエリすることができ、複雑な関係分析を必要とするユースケースに適しています。例えばeコマースプラットフォームでは注文データをグラフ構造で保持し、推薦や不正決済検知に利用することが一般的なユースケースとなるでしょう。 Amazon Neptuneのバージョン更新 データベースのアップグレードは、アプリケーションの可用性維持と必要な更新の適用の間でトレードオフを伴います。ブルーグリーンデプロイメントでは、現環境(ブルー)と新環境(グリーン)という2つの別個の環境を維持することでこの課題に対処し、本番トラフィックを移行する前に変更を安全に実装してテストすることができます。新環境での検証が完了した後、新環境にトラフィックを移行することでダウンタイムを最小化し安全にバージョンの更新ができます。 AWSのNeptuneバージョン更新のガイドとして、 ブルーグリーンデプロイメント が案内されています。ガイドでは、新環境を現環境の複製として作成し、現環境への更新オペレーションを継続的に新環境にレプリケーションするリソースを作成するCloudFormationスタックを実行します。後述しますが、私たちの環境では、配布されているCloudFormationテンプレートを実行した際にエラーが発生したため、テンプレートを修正した上で実行を行いました。CloudFormationテンプレートは以下のリンクで配布されており、ダウンロードが可能です： https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml 事前準備として、レプリケーションのためには、Neptune streamsの設定をクラスターパラメーターグループで有効化し、反映のためにクラスターの再起動をしておく必要があります。また、新環境のクラスターを配置するVPCにはDynamo DBに対してVPCエンドポイントを作成しておく必要があります。 現在のバージョンから次どのバージョンに更新するべきかという情報は Engine releasesページ に記載されています。こちらを参照し更新先のバージョンを特定してください。バージョンの主要な変更点や、クライアントライブラリのバージョン制約についても記載があるので、事前にチェックしておいてください。 課題と解決策 ここからは、AWSによって配布されているブルーグリーンデプロイメント用CloudFormationテンプレートを実行する際に発生したエラーと解決策について記載します。 DeploymentIDは新クラスターの名前に利用されるのでNeptuneクラスターの命名規則に沿わなければならない エラーの内容を見ればそのまま分かりますが、CloudFormationスタックのパラメータで指定する DeploymentID は、新クラスターの名前にそのまま利用されるため、DeploymentIDはNeptuneクラスターの命名規則に従ってください。私たちは _ を使おうとしてエラーが発生しました。 命名規則は Identifiers must either be an ARN or begin with a letter; must contain only ASCII letters, digits, and hyphens; and must not end with a hyphen or contain two consecutive hyphens. です。 CloudFormationスタックを実行するEC2インスタンスにはpublic ipアドレスが付与されていなければならない テンプレートでは、EC2インスタンスを起動しインスタンス内でダウンロードしたPythonスクリプトを実行します。インスタンス内では、curlを用いてPythonスクリプトをダウンロードしているので、EC2インスタンスがインターネットと通信できることが必要です。VPCの設定でEC2インスタンスにパブリックIPアドレスを自動的に付与しない場合には、パブリックIPアドレスを明示的に付与してください。 CloudFormationテンプレート上では、以下のように修正しました。 EC2Instance: Type: AWS::EC2::Instance Properties: InstanceType: !Ref InstanceType - SecurityGroupIds: [!Ref InstanceSecurityGroup] IamInstanceProfile: !Ref EC2InstanceProfile UserData: Fn::Base64: !Sub | #!/bin/bash cd /home/ec2-user/ yum update -y yum -y install tmux screen curl https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.zip --output bg.zip unzip bg.zip chmod 700 bg.py pip3 install schedule boto3 aws_requests_auth requests uuid watchtower urllib3==1.26 echo $PWD python3 bg.py -s ${NeptuneSourceClusterId} -t ${NeptuneTargetClusterVersion} -d ${DeploymentID} -g ${GraphQueryType} -m ${DeploymentMode} ImageId: !Ref LatestAmiId - SubnetId: !Ref SubnetId Tags: - Key: Name Value: !Ref DeploymentID - Key: CloudformationStackName Value: !Ref 'AWS::StackName' - Key: Application Value: "BlueGreenDeployment" + NetworkInterfaces: + - DeviceIndex: 0 + AssociatePublicIpAddress: true + SubnetId: !Ref SubnetId + GroupSet: + - !Ref InstanceSecurityGroup EC2インスタンスの権限不足 CloudFormationスタックでは、現環境から新環境へ継続的なレプリケーションを行うために内部的にLambda関数やStep Functionsワークフローを作成します。実際には、EC2インスタンスで実行するPythonスクリプトの中から更に入れ子で別のCloudFormationスタックを実行しているのですが、子スタックで作成するリソースで以下のようなエラーが発生しました。 Resource handler returned message: "Encountered a permissions error performing a tagging operation, please add required tag permissions. See https://repost.aws/knowledge-center/cloudformation-tagging-permission-error for how to resolve. Resource handler returned message: "User: arn:aws:sts::XXXXXXXXXXX:assumed-role/neptune-bg-deployment-stack-EC2InstanceRole-XXXX is not authorized to perform: iam:TagRole on resource: arn:aws:iam::XXXXXXXXXXX:role/neptune-bg-deploy-NeptuneStreamPollerExecut-XXX because no identity-based policy allows the iam:TagRole action (Service: Iam, Status Code: 403, Request ID: XXXXX) エラーの内容の通り、 iam:TagRole アクションをEC2インスタンスのIAMロールに許可する必要があります。 Policies: - PolicyName: NeptuneBGCustomPolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - 'iam:CreateRole' - 'iam:CreatePolicy' - 'iam:DeleteRole' - 'iam:DeleteRolePolicy' - 'iam:PutRolePolicy' - 'iam:GetRole' - 'iam:GetRolePolicy' - 'iam:AttachRolePolicy' - 'iam:PutRolePolicy' + - 'iam:TagRole' Resource: '*' - Effect: Allow Action: - 'iam:PassRole' Resource: - 'arn:aws:iam::*:role/*' - Effect: Allow Action: - 'cloudformation:DescribeStacks' - 'cloudformation:CreateStack' Resource: '*' その他の注意点 Neptuneクラスターのオートスケーリング設定は新環境には引き継がれないので、手動で新環境に設定し直す必要があります。また、移行が完了した際には旧環境のオートスケーリング設定を削除しておくと良いでしょう。 Neptuneでのオートスケーリングの設定は以下を参照してください。 https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html 参考ページ 上記でも紹介しましたが、ブルーグリーンデプロイメントの際に有用なページを以下に置いておきます。 Using the Neptune Blue/Green solution to perform blue-green updates Neptuneブルーグリーンデプロイメントの公式ガイドです。どのような流れで新環境を作成するか、事前準備、ベストプラクティスについて紹介されています。 Engine releases for Amazon Neptune Neptuneのエンジンバージョンについて、アップグレードパスや変更点がまとめられています。 Setting up Neptune-to-Neptune replication ブルーグリーンデプロイメント用のCloudFormationスタックで内部的に呼び出すNeptune-to-NeptuneレプリケーションやCloudFormationスタックについてのドキュメントです。細かなデバッグが必要な場合には参照するとよさそうです。 おわりに 今回はグラフデータベースであるAmazon Neptuneのバージョン更新のため、ブルーグリーンデプロイメントを実施する中で実際に発生したエラーを解決策と共に紹介しました。Neptuneを利用している方の参考になれば嬉しいです。 BASEではメンバーを採用中です！ご興味のある方は是非以下をご覧ください。 binc.jp

はじめに はじめましての人ははじめまして、こんにちは！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です！ 今回は、GitHub Copilot Chatを使った開発の中で実際に試してみたことと、そこから得られた気づきについて共有していきたいと思います。 （この作業を実施したのが2025年1月中頃の話なので、GitHub Copilot Agentモードが出る前の話である点だけご了承ください。2025年4月の今ならAgentモードでサクサク作らせていたと思いますし、直近はAgentモードで作ってPRを出したりしています🙏） やってみたこと 今回やってみたことはシンプルで、 MarkdownでAPI仕様書をリポジトリ内に置いてみた Mock API実装をGitHub Copilot Chatに依頼してみた レイヤー分割を意識したGitHub Copilot Chatによるコーディングを実施してみた という3つになります！ シンプル && ステップ分割できる作業においてはGitHub Copilot Chatを使うことで、一定の開発効率向上できてるな！というのを感じたので今回紹介しようと思った次第です🙋 もし今回の記事を読んでいただき、参考にできそうなポイントがあればぜひ真似してみてください！また、こういう使い方をするとよりよく使えるよ！というポイントなどあれば X（旧Twitter）などで教えていただけると嬉しいです！ では、具体的にどんなことをやってみたのか見ていってください！ 1. MarkdownでAPI仕様書をリポジトリ内に置いてみた 今回は自分が担当している PAY.JP YELL BANK 関連の新機能の開発時に使ってみました。 PAY.JP YELL BANK自体は、PAY.JPの加盟店に向けて提供している将来債権ファクタリングというスキームの資金調達サービスです。 今回はこれに関連する金融サービスの追加機能のお話で、複数人での開発であったため、認識揃えのためにAPI仕様書を書きつつ開発していました。 APIの仕様（スキーマ）は適宜メンバー間で相談し、以下のような形でFigJamとNotion上にAPI Design Documentとしてまとめていました。 （チームではADRというものを活用しています！めっちゃいいんです！！） もう少しだけ今回の作業の背景を紹介すると、私が所属しているBASE BANKチーム（YELL BANKやPAY.JP YELL BANKなどのサービスを担当しているチーム）では、以前より ADR（Architecture Decision Records）という形で仕様整理も含めた設計時の意思決定をドキュメントに起こす文化 があります。 このADRをまとめる際に設計の抜け漏れの確認とメンバー間での認識揃えができるだけでなく、あとから当時の意思決定の理由や「検討したが選択しなかったこと」や「仕様変更がある前の前提知識」などを知ることができるので現在のシステムに対する解像度が一段上がりやすくなります。 ADRを書くことによるメリットや背景などは本題ではないので今回は省きますが、こちらのページ（ https://adr.github.io/ ）が端的でわかりやすいので、合わせて参照いただけるとよりイメージしていただけるかと思いますのでよければご覧ください。 そして、今回はこの API Design DocumentをNotionから出力してリポジトリ内に置く 。という作業を行いました。 ちょっとした工夫として、Markdownファイルは リポジトリ内に tools/.copilot/ という名前で「開発に使えるAI Copilot（副操縦士）用のファイル置き場」ぐらいの粒度の 専用ディレクトリを作成して、 .gitignore でGitの管理下からは外す ようにしています。 これは、2025年1月当時の状況として 「 .cursorrules などが話題にはなり出してはいるけど、何がどこまで覇権を握るかもわからないし、PJ全体として管理する前にそもそも個人ごとに使い分けが起こるだろうし、一旦気軽な場所が必要だ…」と思っていたので抽象化して場所を作っておいたという流れがあったりします。 このディレクトリがあるおかげで、VSCode経由のGitHub Copilot Chatであれば必要に応じてファイル指定を行うこともできるし、プロンプトに「このディレクトリ内から検索して…」などの追加指示を行えるので、一定の精度向上が見られました。（あくまで個人の感覚値） 今後は、README.mdのような人間向けに作りつつもAI Agent側の参考にもなるリポジトリ内ドキュメントを整えつつ、 .cursorrules などのようなAI Copilot / AI Agentに最適化されたルール定義ファイルも駆使していければなと考えています🙋 2. Mock API実装をGitHub Copilot Chatに依頼してみた 今回の開発では、PAY.JP側のエンジニアと協力してAPIスキーマを決めていきました。 APIスキーマは両者の責任分界点となるため、開発環境で先行してMock APIとして実装することで、PAY.JP側での動作確認とAPI利用に関するフィードバックを受けやすくする狙いがありました。 この実装にあたり、「Mock APIなら生成AIで効率的に作れるかも…！」と考え、GitHub Copilot Chatを活用して開発を進めることにしました。 具体的な流れとしてはこんな感じです。 tools/.copilot/ai-docs というディレクトリにAPI Design DocumentをMarkdownで配置する そのファイルと、その中の特定の見出しを指して「このAPIを作りたいので、まずはMock処理としてHandler層でレスポンスするようにして」のように指定して、Mock APIの実装を依頼する ⇒ （レスポンスとしては良いが、他の既存のAPIの書き方とかなり異なっていて、必要なプライベートメソッドが実装されていなかったりしてコンパイルも通らないレベルで失敗） 同じ層の別のAPIのファイルを指定して「このHandlerを参考に書いて」と指示を出す ⇒ （微妙に書き方が違うものの、コンパイルは通るようになったので一旦許容） 3で作ったAPIのHandler層を指定してテストコードの作成を依頼する ⇒ (これもコンパイルが通らないレベルで失敗) 同じ層の別のテストファイルも合わせて指定して「このテストを参考に書いて」と指示を出す ⇒ （無事テストが通り、Handler層のテストが実行できるようになる） Handler層のコード・ドキュメント・既存のテストを同時に指定し、テストケースを増やす必要があるか検討し、追加してもらう 3, 5の実装をそれぞれ同じ層の既存ファイルを複数同時に指定し、「これらのファイルと書き方が違っていない？もし違うなら合わせて欲しい」と指示する ⇒ （素直にリファクタリングを実行してくれる） HTTP Clientファイル を作ってAPIの動作が意図通りか確認する テストとコンパイルと動作確認ができたので、最後に人間の目で見て全体のコードに違和感がないか確認し、適宜修正を依頼する PAY.JP YELL BANKのコードはクリーンアーキテクチャを参考にしたレイヤードアーキテクチャで構成されています。 なので各処理レイヤーのインプット / アウトプットと責務を意識して実装依頼を行うことで、成果物の品質を高めることができました。これに関しては、次の項で詳しく紹介します。 補足）キャプチャ込みでやり取りを紹介 各ステップでどのような指示とやり取りをしていたか、実際のキャプチャも含めて軽くご紹介します。 2のステップでは、以下のようにざっくばらんな指示を出してみました。 すると、コンパイルエラーになる形で作成をしてきたので、3のステップでは同じレイヤーのコードと比較しつつ、参考にしながら書いてもらう指示を行いました。 4のステップでは、テストコードの作成を依頼していて、この時に初回の指示のようにAPI Design Documentのファイルと見出しを指定してテストコードを書いてもらいました（が、いまいちコンパイル通らない形での実装をしてきたので、ステップ3と同じように同レイヤーのテストコードと比較しながら修正してもらいました） また、APIレスポンスのモックファイルの一括作成も同時に依頼して、パターンの洗い出しとJSONファイルの作成を代行してもらいました。 その後は、以下の画像のように細かいリファクタリングを指示しながら作業を進めていきました 3. レイヤー分割を意識したGitHub Copilot Chatによるコーディングを実施してみた 前の項でも軽く触れましたが、PAY.JP YELL BANKのAPI処理の実装はレイヤードアーキテクチャの構成になっています。 そのため、Usecase層、Handler層、Model層、データアクセス層など、それぞれの層に分けていて層ごとにテストを書いています。 このレイヤー分割を意識して、GitHub Copilot Chatに実装依頼を行うことで、以下のようなメリットがありました。 GitHub Copilot Chatへの指示・提供するファイルのサイズが小さくなるため、必要なコンテキストウィンドウが小さくなり、指示を忘れることが少なくなる 取り扱うファイル数やコードの量が増えると指示を忘れて意図しないコードを出力してくることがよく発生してしまっていたのでGood 🙌 GitHub Copilot が出力したテストコードを見るだけで人間側が意図を理解しやすくなる 最終的には人間のレビューが必要なので、まず In / Out を確認するだけで処理の振る舞いが理解できるテストコードは重要です 👀 エンドポイントの指定 × レイヤーの指定という形で組み合わせるので、小さい単位で切れ目を作れてコミットサイズ・PRサイズを小さく管理しやすい 細かい単位でコミット・PRを作ることで他のメンバーのレビューを受ける際にもレビューしやすくなるので、GitHub Copilot Chatを使う場合でも意識しておくと良さそうだなと思いました🙋（AIに書いてもらうとかんたんに作れてしまう分、長大なPRになりがち） 学んだこと 実際にこのような流れで開発をしてみて、GitHub Copilot Chatをはじめとした、生成AIコーディングツールを使う上での気づきやコツみたいなものを掴むことができました。 これらをまとめてご紹介し、この記事を読んでくださった皆さまに何か得るものがあれば嬉しいなと思います🙋 1. リポジトリ内に開発に必要な情報をできる限り置く・置けるようにする コードには開発情報や仕様が含まれてはいますが、 実際の開発時に必要な情報 は ドキュメント、デザイン、API仕様書など様々な場所に分散している のではないでしょうか？ 今回の作業を行なっている中で、GitHub Copilot Chatを使う場合にもそれらの情報に 人間が開発する時と同じようにアクセスできるようにしておくことで精度の向上が見込めそうだ…👀  というのを肌身に感じました。 VSCodeのGitHub Copilot Chatでは、ファイル検索や参照が容易なため、開発に必要な情報はリポジトリ内にファイルとして置いておく方が良いなと思っています。 この流れは、GitHub Copilot Chatに限らず、CursorやClineをはじめとしたAI Agentを使う場合でも同じような流れですし、 .cursorrules のようなファイルを作るのが推奨されているのとかは特に顕著ですね。 また、このようなプロジェクト全体で共通化しておくファイルを置くのとは別に、今回実施した tools/.copilot/ のようなGit管理しない個人用のファイル置き場を作っておくのも、自分用に適宜カスタマイズしてAIエディタの開発支援を行えて効率的な開発につながるなと思いました。 2. 人間・AIともに認知負荷を下げる AIの性能面では、タスクの精度を高めるために共通ルールなどのコンテキストを小さくする方が望ましく、 認知負荷を下げることで精度が向上 します。 また、生成AIのコードは人間がレビューして説明責任を持つ必要があるため、 認知負荷を下げることでレビュー効率が向上 します。 直近はVibe Coding（バイブコーディング）というものが話題になっているものの、チームで開発を行う場合は 生成AIで書いたコードに対して、人間側が説明責任を持てることが求められます 。 そのため、 AIの成果物をレビューする際は人間の認知負荷を下げることが重要 です。これは自分とチームメンバー双方のために意識的に工夫すべき点です。 ここに関しては X（旧Twitter）でも日々言われている「人間がボトルネックだ…」という話を今回の作業をしている中でひしひし感じていたので、今後より良い方法を模索しつつ、より良いツールやワークフローが生まれてくることに期待したいなと思いました🙋 3. テストコードや動作確認ツールを活用する テストコードとHTTP Clientの活用で、AIが生成したコードの動作確認を効率的に行えます 。これは生成AI特有の話ではなく、一般的な開発プラクティスですが、特に重要です。 これまでの開発者の努力によって市場として成熟している各種テストツールを活用することで、エラーや意図しない挙動の検出と修正が容易になります。この自動化された高速なフィードバックループが、プログラミングと生成AIの相性の良さを支えていると私は考えています。 これがない場合、お手々でのビルドと実行、エラー時のAIへの再確認という遅いサイクルを繰り返すことになってしまいますからね…🤔 このように、今回の検証によって、迅速なテストとフィードバックループは生成AI活用の重要な要素だと感じました。 そのため、動作確認ツールとテストコード環境の整備が、Webアプリ開発における生成AI活用を推進する第一歩となるのかなと感じています🙋 おわりに 以上が、GitHub Copilot Chatを使った開発の中で実際に試してみたことと、そこから得られた気づきについてのまとめでした！ GitHub Copilot以外にも、CursorやClineなどのAIエディタやAIエージェントが出てきている中で、これらを使うことで開発効率が上がるのか？という点については、今後も引き続き検証していきたいなと思っていますし、これを調査してうまく使えるようになることがこれからのエンジニアキャリアを作る上でも重要な要素になってくるのかなぁと思っているので引き続き頑張っていきたいと思います！ もし、こちらの記事を読んでAIを使った開発に興味が出てきた方がいらっしゃればぜひお声がけください！ざっくばらんにお話ししましょう🙋 カジュアル面談プラットフォームのPittaやX（旧Twitter）などでお話しできる機会があれば嬉しいです！ https://pitta.me/matches/PDWMyhvOjUOy https://x.com/gatchan0807 また、PAY.JP YELL BANKを開発しているBASE BANKチームではエンジニアを募集していますので、興味がある方はぜひこちらもご覧ください！ 🙌 binc.jp 最後まで読んでいただき、ありがとうございました！

はじめに こんにちは、BASE BANK Departmentで開発責任者をしている斉藤です。 今回はBASE BANKの開発チームで実施した「設計・プロジェクト推進のふりかえりをする勉強会」について紹介します。 設計・プロジェクト推進のふりかえりをする勉強会を開催しました この勉強会では実際にプロジェクトをリードしたメンバー(今回は私)が、設計の工夫やプロジェクト推進をふりかえり、それらをチームに共有する形式で行いました。 今回は、 PAY.JP YELL BANKにおける初回調達のサービス利用料無料施策 を題材に開催しました。 この施策はPAY.JP YELL BANKを初めて利用する方が、 サービス利用料0円で資金調達を行える ようにするもので、より多くの事業者がこのプロダクトに触れるきっかけをつくる目的がありました。 未来の売上がすぐに使える 審査不要の資金調達サービス PAY.JP YELL BANK なぜこの勉強会を開催したのか BASE BANKのエンジニア組織として、よりプロダクトを成長させられるチームになっていくぞ！というのが根本にあり、 プロジェクトをリードする、なにかを決めるといった経験やスキルにチームとして伸びしろがあると感じていました。 2025年はこの部分を強化すべく、適切にリードの役割をアサインし、機会を増やしています。 とはいえ、リードの役割を担うことは貴重なため「やってみました」で終わってしまうのはチームとしてもったいないと思っていました。 そのため、 実際にリードした経験を、さらに深く学びに変える 他のメンバーにもその学びを共有し、チーム全体のレベルアップにつなげる これらのことを目的として、この勉強会を実施しました。 勉強会の内容 勉強会では、以下のような内容を発表しました。 現状のプロダクト課題 プロジェクトの目的 背景と制約 プロジェクトの進め方と開発ロードマップの設計 技術設計の意思決定 リファクタリングの判断基準 コミットに現れにくい実装上の工夫やTips これらの内容とあわせて、FigJam上でリアルタイムにコメントや質問をもらいながら、それに対してレスポンスしていく形式で進行しました。 参加メンバーからのフィードバック 参加メンバーからは、以下のようなフィードバックがありました。 他の人のロードマップやガントチャートの作り方を聞いたのは初めてだったので参考になった タスク単位の工数と予実をもとに要因を振り返っているのが良い リファクタリングをいつどうやるかのケースバイケースの判断が参考になる 自身が別のプロダクトでキャンペーンに取り組んだときはこうした 自分も同じようなコーディングをしていたので共感した フィードバックコメントの一部 発表してみて ロードマップやガントチャートのつくり方を言語化したことで、自分自身の中でも整理できましたし、 メンバーからはそれぞれのつくり方や気をつけていることが聞けて、次にロードマップ、ガントチャートをつくるときはより良いものにできそうです！ 設計における汎用性をどこまで考えるかはケースバイケースなため、他のプロジェクトの事例や意思決定をフィードバックで聞けるのはとても良い体験でした。 自身の感覚やフィードバックという定性面ですが、目的に近づける内容で開催できたのかと思います！ 今後の展望と課題 今後もこの勉強会は継続して開催していきたいと考えています。 何回か重ねていき、当初の開催目的である 実際にリードした経験を、さらに深く学びに変える 他のメンバーにもその学びを共有し、チーム全体のレベルアップにつなげる これらの達成に近づけているのか、さらにより良い方法はないのかを模索していく予定です。 また、参加メンバーからは以下のようなコメントももらいました。 実装に関する具体的なTipsをもっと聞きたい PdMや事業責任者とのやり取りや意思決定の背景を知りたい 設計判断において、選ばれなかった他の選択肢についても知りたい プロジェクトで工夫した点とその効果について詳しく知りたい うまくいかなかったことやしくじりポイントを共有してほしい スケジュールが厳しくなった時のリカバリー方法や、関係者との調整の仕方を知りたい 今後のテーマ設定やフォーマットを改善していくときに、反映できればと思います！ 最後に BASE BANKでは、こうした勉強会を通じて、プロダクトを成長させる力をチーム全体で伸ばしていきます！ 各職種、採用を行っておりますので、ぜひぜひご応募ください！ open.talentio.com まずは勉強会の具体的な内容や普段の働き方などを聞いてみたいという方は、ぜひカジュアル面談でお話ししましょう！！ こんな勉強会を開催している、こんなプロジェクトリードをやっているという話もお聞きしたいです！ X等で気軽にご連絡ください！ https://twitter.com/hiroki_saito_

はじめに こんにちは！ BASEのカートチームでバックエンドエンジニアをしている、かがの（ @ykagano ）です！ みなさん、ECカートでよく見るこのバッジをご存知ですか？（右上の赤丸部分です） これはカートに商品がいくつ入っているかを示すカートバッジです。 このカートバッジはPay IDアプリではすでに表示されていますが、これまでBASEのWebショップには表示されていませんでした。 今回はこのカートバッジをWebのショップにリリースしましたので、そのお話をしたいと思います。 カートバッジの実装方法 カートバッジは以前、Webのショップでも一時期表示されていました。 しかし、表示の都度、DBへの負荷を高めてしまうという課題が当時あり、過去に取り下げられた経緯があります。 当時の課題 BASEのショップ画面と、カート画面は別のアプリケーションになっており、当時はこのショップ画面とカート画面のドメインが異なっているという課題がまずありました。 そのため、ショップ画面に表示されるカートバッジは、ドメインの異なるカートアプリケーションにアクセスして商品数を表示する必要がありました。 ショップ画面にiframeを表示して、表示されたiframeからカートドメインにアクセスすることでカート内の商品数を表示するという実装でした。 しかしその実装では、ユーザーがショップにアクセスする度、iframeからカートのバックエンドにリクエストが発生する状態でした。 表示の都度発生するDBアクセスにより負荷を高めてしまうため、カートバッジは取り下げられることになりました。 当時のカートバッジの表示フロー import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram actor user as 購入者のブラウザ participant front as ショップ participant cart as カート participant db as DB user ->> front: Webショップにアクセス front -->> user: ショップ画面を表示 user -->> cart: ショップ画面内のiframeでカートドメインにアクセス cart ->> db: カート内の商品数の取得を要求 db -->> cart: 取得した商品数をカートバッジに表示 現在では、ショップとカートのドメインが一致するようになったため、iframeで実装する必要がなくなりました。 そのため、今回は Local Storage を使用してブラウザにカートの商品数を記録することにしました。 カート画面での各種イベント発生時に、Local Storageの商品数を更新し、ショップ画面に商品数を反映したカートバッジを表示するものとなります。 これならバックエンドに負荷はかかりません。 今回のカートバッジの表示フロー sequenceDiagram actor user as 購入者のブラウザ participant front as ショップ participant cart as カート user ->> front: Webショップにアクセス front -->> user: ショップ画面を表示 user ->> cart: ショップ画面で商品を追加（カート画面に移動） cart -->> user: Local Storageの商品数を更新 user ->> cart: 商品数量を変更 cart -->> user: Local Storageの商品数を更新 user ->> front: ショップに戻る front -->> user: ショップ画面を表示 user ->> user: 商品数をブラウザのLocal Storageから取得 user ->> user: カートバッジに商品数を表示 各デザインテーマにリリース BASEではショップオーナーがショップのデザインを簡単にカスタマイズできるテンプレートをデザインテーマとして用意しています。 コードを書かなくてもショップの見た目を整えられる無料・有料のデザインテーマには、大きく分けて以下の3種類があります。 オフィシャルテーマ：BASEの提供する無料テーマ デザイナーズテーマ：提携クリエイターによって作成された有料テーマ カスタムテーマ：『HTML編集App』によってショップが自由にカスタマイズした無料テーマ 今回この全てのデザインテーマにカートバッジを表示できるようにリリースしました。 テーマの違いについての詳細は以下のサイトをご参照ください。 baseu.jp それぞれ以下の日程にカートバッジをリリースしています。 既存のカスタムテーマと有料のデザイナーズテーマにカートバッジを表示する場合は、それぞれショップオーナー様、テーマ作者様での追加対応が必要となります。 対象 リリース日 備考 無料のオフィシャルテーマ 2024/10/25 カートバッジが自動反映されて表示されます 無料のカスタムテーマ （『HTML編集App』で編集したテーマ） 2025/2/5 新規作成時はカートバッジが追加されています 既存の作成済みカスタムテーマは作者のショップオーナー様によるHTML編集が必要です 有料のデザイナーズテーマ 2025/2/5 テーマ作者様での追加対応が必要です 既存のカスタムテーマやデザイナーズテーマはなぜ対応が必要なのか カスタムテーマとデザイナーズテーマのデザイン自体はBASEで管理されていませんが、BASE側で共通のタグに対してコードを埋め込むことは可能です。 当初はカスタムテーマ、デザイナーズテーマにも、オフィシャルテーマと同様に汎用的なカートバッジを表示する想定で開発を進めていました。 こちらのページにBASEのDevelopersページでのTemplate仕様が記載されています。 <body>仕様 · Developers 上記ページに記載の通り、既存のBASEメニューのタグがすでに埋め込まれています。 {BASEMenuTag} 今回もこちらを修正してカートバッジのHTML要素を埋め込んでいます。 BASEメニュータグは下記のように出力されます（カートバッジは非表示状態です）。 < div id = "baseMenu" > < ul class = "clearfix" > < li class = "base" > < a target = "_blank" href = "https://thebase.in?from=ショップID & p=shop" > < img src = "/img/shop/base.png" alt = "ネットショップを開設するならBASE" title = "BASE" height = "30" > </ a > </ li > < li class = "cart" > < a href = "https://c.thebase.in/order/cart/ショップID" > < img src = "/img/shop/cart.png" alt = "shopping cart" height = "30" > < div class = "cart-badge" style = "display: none;" > < div class = "cart-qty" style = "display: none;" ></ div > </ div > </ a > </ li > </ ul > </ div > 汎用的なカートバッジを表示するために、約100件あるデザイナーズテーマの全てでテストを行う予定でしたが、結果としてテストは実施途中で打ち切りました。 カスタムテーマ、デザイナーズテーマはそれぞれショップの雰囲気に合わせて細かくカスタマイズされたテーマになります。 そこに汎用のカートバッジを一律で表示するのは難しいと判断したためです。 そのため、アプローチ方法を変えて、既存のカスタムテーマやデザイナーズテーマにはテーマ作者様に組み込んでいただく方法を取りました。 具体的には下記CSSを組み込んでいただく形となります。位置やサイズ等は個別にカスタマイズください。 .cart { position : relative ; } .cart-badge { display : block !important ; } .cart-qty { position : absolute ; top : 4px ; right : 5px ; padding : 0 1px ; min-width : 14px ; background : #fa5171 ; border-radius : 50% ; color : #fff ; font-size : 10px ; font-weight : 700 ; line-height : 16px ; text-align : center ; } カートバッジの組み込み方法の詳細はこちらのページをご参照ください。 <body>仕様 · Developers デザイナーズテーマはカートバッジの表示にどれぐらい対応しているのか デザイナーズテーマはテーマ作者様の修正後にBASEへの申請を行っていただき、BASEで審査を行います。 今回、カートバッジについては私の方で審査を行わせていただきました。 結果、2/5のリリースから2週間で約22%のデザイナーズテーマがカートバッジを表示してくれるようになりました！ リリース後にお知らせを通知したのが、2/12のため、実際にはお知らせから1週間でテーマ申請されたものがほとんどになります。 リリース後にお知らせをすると、一部のテーマ作者様はすぐに対応して申請いただけることが分かりました。 テーマの作者様はどのような実装がされていたのかですが、まず上記CSSの通り実装すると下記のカートバッジが表示されます。 カスタムテーマの新規作成時に表示されるカートバッジ デザイナーズテーマの作者様は各々のデザインに合わせて色やサイズや位置を細かく調整されていました。 以下にその例として、テーマごとのカートバッジを3つご紹介します。 Euforia（ユーフォリア） OULU Retail Pro Dolce Vivace 様にて作成 GRAYEL Inc. 様にて作成 ymtk 様にて作成 テーマの詳細を見る テーマの詳細を見る テーマの詳細を見る 個別にカスタマイズいただいたことで、より良い形でカートバッジが表示できるようになったと思います。 おわりに Webでのカートバッジの表示はBASE社内ではずっと取り組みたかった案件となります。 今回、カートチームで対応を行いましたが、これまであまり関わりのなかったショップのデザインテーマやそれに付随した審査などにも関わることができ、非常に良い経験ができました。 このようにBASEでは、広い領域での開発を経験することができます。 興味のあるエンジニアはぜひ弊社にご応募ください！ binc.jp

2025/3/21（金）- 3/23（日）の3日間、中野セントラルパークカンファレンス & ニコニコ生放送で PHPerKaigi 2025が開催されます。 BASE株式会社はゴールドスポンサーとしてPHPerKaigi 2025へ協賛しています。 phperkaigi.jp PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 2025年は中野セントラルパークカンファレンス & ニコニコ生放送で、オフライン及びオンラインのハイブリッド開催となります。チケットは下記よりお申し込みいただけます。 https://fortee.jp/phperkaigi-2025/ticket-shop/index 登壇メンバーのご紹介 PHPerKaigi 2025では、BASEで活躍している4名のメンバーが登壇予定です。ぜひ聞きにいらしてください。 3/22（土） day1 11:10- 高町咲衣さん「BCMathを高速化した一部始終をC言語でガチ目に解説する」 3/23（日） day2 10:30- プログラミングをするパンダさん「モジュラーモノリスでスケーラブルなシステムを設計・開発する」 13:35- 02さん「PHP8.4におけるJITフレームワークIRと中間表現について理解を深める」 15:40- meiheiさん「List とは何か？」 おわりに ここまで読んでくださった方のために、PHPerKaigiで行われる「PHPerチャレンジ」のPHPトークンをお知らせします。 PHPerチャレンジは見つけたトークンの数で各種企画への参加権を得られる全員参加型の企画です。詳細はPHPerKaigi内でのアナウンスやパンフレットをご覧ください。 #be_hopeful #move_fast #speak_openly 今年はBASEのプロダクトづくりのための行動指針である「Be Hopeful」「Move Fast」「Speak Openly」の3つをトークンとさせていただきました。 行動指針の意味については採用情報に載っていますので、こちらもぜひご覧ください。 binc.jp PHPerKaigi 2025で、みなさまにお会いできることを楽しみにしております！

はじめに BASE BANK Division で フルサイクルエンジニア をしている02 （ @cocoeyes02 ）です。 2025/02/22（土）に開催されたPHPカンファレンス名古屋 2025に登壇し、BASE社としてもブロンズスポンサーとして協賛しました。 今回の記事では登壇についてのコメントと、会場の様子についてお届けします！ 今回のセッションと協賛について 今回はLTでの登壇です。 speakerdeck.com LT始まりました！！！ #phpcon_nagoya pic.twitter.com/0DUiNYIYy4 — PHPカンファレンス名古屋 (@phpcon_nagoya) 2025年2月22日 過去にも話した PHPUnit 10 、 PHPUnit 11 に続いてPHPUnit 12の話です。制限時間5分で無理やり、PHPUnit 12でRemoveとなった機能の対応方法について話しました！ 対応方法といいつつも、「そもそもテストやテスト対象自体の設計を見直すべき」となるケースが多かったのが印象的でした。PHPUnit10~12を通して、変更箇所について全てではないにしろ、多くの変更について話してきました。皆さんのPHPUnitバージョンアップ作業に役立ててれば幸いです。 また、今回の協賛は「 BASE BANK, 中小規模のエンジニアイベントにも会場&飲食スポンサーします！ 」の記事を見て、運営の皆さまからご連絡をいただき、実現いたしました。ありがとうございました！ 会場スポンサー、飲食スポンサーを引き続き実施しておりますので、お気軽にご連絡ください。 ⋱📣スポンサー様のご紹介📣⋰ PHPカンファレンス名古屋2025に協賛いただいているスポンサー企業様のご紹介です！ BASE株式会社（BASE BANKチーム）様（ @binc_jp ）、誠にありがとうございます！🍤 スポンサーページはこちら👇 https://t.co/mONG7dtmeR #phpcon_nagoya pic.twitter.com/0lfi9Ja97G — PHPカンファレンス名古屋 (@phpcon_nagoya) 2025年2月21日 現地の様子 ここからは、現地の様子を一部お届けします！ オープニングの様子 オープニングは、平野綾さんのナレーションで始まり、名古屋の観光地の光景、食べ物などが映し出されました！ ⋱🎥オープニング・エンディングムービー大公開！⋰ カンファレンス当日に上映したオープニングムービー・エンディングムービーを「 #平野綾 さんのボイス入りで」YouTubeに公開しました！🎉🎉🎉 オープニング： https://t.co/DiRcQtbr6z エンディング： https://t.co/TKpdhPGkGf #phpcon_nagoya — PHPカンファレンス名古屋 (@phpcon_nagoya) 2025年2月24日 その後、各社スポンサーについて、紹介がありました。 スポンサー紹介でBASEロゴと共に読み上げられた様子 スポンサーブースの様子 スポンサーブースのエリアも賑わっていました！ブース以外にも、ジョブボード、ネームカードの作成コーナー、謎解き、ネイル、コーヒーブースなど、たくさんのコンテンツがありました！ スポンサーブースエリアの様子 ジョブボード ネームカード ランチについても、複数人でグループを組んで名古屋ならではのランチをみんなで行くアンチぼっちランチがあり、ホスピタリティを感じました！ アンチぼっちランチの進捗です🍤 名古屋のエビフライ食べてます🦐 #phpcon_nagoya pic.twitter.com/pP4q0cNzpe — PHPカンファレンス名古屋 (@phpcon_nagoya) 2025年2月22日 おわりに スタッフの方々にはお忙しいにも関わらず、多くの時間を準備に費やしていただいたと思います。この場を借りて御礼申し上げます。 名古屋の魅力を存分にアピールしていたとても素敵なカンファレンスでした。また開催されたら是非参加したいですね！ BASE / BASE BANKでは、絶賛PHPerを採用中です。下記の採用情報やカジュアル面談リンクからぜひご覧ください！ binc.jp open.talentio.com

はじめに BASE の Product Dev Division で Advanced Engineer のプログラミングをするパンダ（ @Panda_Program ）です。2年半間 Senior Engineer をやって、今は Advanced Engineer になりました。 今回ご縁を頂きまして Developers Summit（デブサミ）2025 に参加・登壇しました。登壇内容はスライドを公開しておりますのでこちらをご覧ください。 バックエンドエンジニアのためのフロントエンド入門 speakerdeck.com スライドの公開後にはてブのトレンド入りをしたり、スライドのPVが7,000 view に迫ったりと好評だったようで胸を撫で下ろしました。また、同内容は記事として CodeZine 様でも連載中ですので、よければこちらもご覧ください。 codezine.jp 本記事では自分が参加したセッションのまとめと感想を書いていきます。自分が参加したセッションの中から、各日ともに現場で役立つテーマのセッションを3つずつピックアップしています。なお、各セッションの資料は 「Developers Summit 2025」講演スライド・参加ブログまとめ よりご覧ください。なお、自分が登壇した感想は別の記事で書く予定です。 初日のセッション 自動テストの世界に、この5年間で起きたこと Autify の末村さんのセッションです。直近5年間で自動テストを取り巻く環境が変わったことを紹介されています。 発表によると、ツールと開発者のマインドセットに大きな変化がありました。CypressやPlaywright、Testing Libraryといった便利なツールを利用することでテストのハードルが下がりました。また、ソフトウェアの品質が高いと開発スピードが上がるという考え方が浸透した結果、自動テストは当たり前になりました。 自動テストが普及してきた世の中で次なる課題は「E2Eのカバレッジを増やしたい」「どんなテストがあれば障害の予防ができるのか」などのテスト設計です。これらは定型化できなかったのですが、LLMのおかげで仕様書からテストを設計するなど、非定型的なテスト設計のコストが下がるであろうとのことでした。 顧客のニーズは変化するものの、常にテストを行うことでさまざまなニーズに迅速に対応し、高速なリリースを実現できることが強調されていました。 BASE ではバックエンドのテストは単体テスト、結合テストともに当たり前に書いています。一方、フロントエンドについてはしっかり守られている部分とそうでない部分があります。例えばカートという決済に関するコア機能ではE2Eテストがしっかり書かれていたり、主要な機能で Mabl を使ったE2Eテストが定期実行されているのですが、ショップオーナー向けの管理画面ではコンポーネントテストやユニットテストがちらほら書かれ始めてきたという印象なので、この流れを推し進められたらなと思います。 エンジニアキャリア図鑑　～エンジニアリングマネージャー VS テックリード～ カケハシの小田中さん、ログラスの塩谷さん、村本さんのディスカッションでした。小田中さんがエンジニアキャリア図鑑という取り組みで、エンジニアが自分のロールモデルを見つけて、キャリア形成のヒントを得る機会を作るのを目指されているとのこと。 そこで、ログラスでエンジニアリングマネージャーとテックリードをされているお二人に話を聞くというのが本セッションです。 マネージャーとテックリードの違いとして、マネージャーはメンバーのキャリアを支援し、彼らのやりたいことを見つける手助けをする役割がある一方で、テックリードは、チームが会社全体の方向性に沿っているかを確認し、事業に貢献できる道筋を引くことの重要性が語られていました。 キャリアを広げるためには事業の視点を持ち、視座を高く持って自分の責任範囲を広げることが肝心だと理解しました。 なお、BASEではEM（People軸）とテックリード（Tech軸）以外にEPM（Engineering Program Manager。PJ軸）という役職、ラダーが設定されており、技術か人かの二者択一ではなく、サービス志向というキャリアも歩むことができます。 業務理解の深化と実践～ドメインモデリングで基幹システムを捉える MonotaRO の CTO-Office シニアアーキテクト の尾髙さんによる発表です。BASE社ではモノリスからモジュラーモノリスへのリアーキテクチャが進んでいるため、初日のセッションの中では自分にとって一番学びが大きかったセッションでした。 まず複雑性には2つあるのだと語られました。競合他社と差別化を図るためには、本質的な複雑性に集中的に取り組み、偶有的な複雑性を排除することが重要であるとのことです。事業自体は複雑なものなので、ソフトウェアが本質的な複雑性を持つことは免れません。しかし、偶有的な複雑性が増すことにより、ソフトウェアの変更が容易ではなくなるため、これは排除しなければならないという話に共感していた方も多く見られました。なお、本質的/偶有的 は essential/accidental の訳語なので必須の複雑性/付随的な複雑性ということもできます（参考: 必須／付随分割 (Essential/Accidental Split) ）。 また、事業や業務を理解するために、ドメイン全体と業務領域、流れと構造のマトリクスで分類した4種類の手法を採用しているとのこと。それぞれビッグピクチャ、コンテキストマップ、プロセスモデル、ドメインモデルというモデリング手法です（詳細はスライドをご覧ください）。コンテキストマップやドメインモデルは知っていたり実践していたのですが、これが事業を理解する活動のどこに位置づけられるのかわかって学びになりました。 これらは一度実施するだけではダメで、継続的に開催する必要があるということも印象に残りました。確かに会社は人の入れ替わりもありますし、事業も変化し続けます。大規模なイベントストーミングは１日かかることもあるそうですが、エンジニアのみならず職種を超えてみんなで認識を合わせることで、その後のコミュニケーションやソフトウェア設計、コーディングがスムーズになるのであれば払うべきコストだ、むしろ健全な投資だと思いました。 2日目のセッション 開発スピードは上がっている…品質はどうする？ ～スピードと品質を両立させるためのプロダクト開発の進め方とは～ Graatの鈴木さん、SReEE の安達さん、10X/B-Testing の風間さん（ブロッコリーさん）によるパネルディスカッションです。 ソフトウェアの品質はプロセス品質、内部品質、外部品質、利用時の品質の4つあると冒頭で語られました。 スピードと品質を両立させるためには、適切な設計とテストプロセスが必要であるということが語られていました。アジャイル開発では、外部品質の維持だけでなく、内部品質の向上が利用時の品質向上に繋がるため、プロセスや構造の改善が重要であるとのことです。 また、アジャイル開発では、QAエンジニアが早い段階から開発チームに参加して、段階的なテスト活動を行うことのメリットがあるとのこと。プロダクトオーナーと開発者がテストの受け入れ基準を作る際に、コードや仕様について詳しく知っていないことを逆に強みとしているQAエンジニアと話すことで、実装前に視点の抜け漏れに気づくことができる。結果的に、テストのシフトレフトが実現できるのだということでした。 なお、チームにQAエンジニアがいない場合は、「今日はあなたがテストの視点を持つ人」というように順番にロールプレイをしても効果があると紹介されていました。 自分が今所属しているチームではQAエンジニアの方が、プロジェクト組成時点から参加しています。しかし、大体こういうものを作るという共有はしているのですが、テストの観点はスプリントレビューで作って動くところから考え始めてもらうという流れになっていました。 このため、仕様決めの段階でうまく頼れなかったな、もっと密に関わってもらう方法があるのではと思いながら参加したため、まさに受け入れ基準を一緒に作っていくという点で関わって貰えばいいんだという答えを教えてもらった気持ちになったセッションでした。 ソフトウェア開発プロセス全体で、AIがモチベーション高く働くために必要なものは「バレンタインデーのチョコ」ではなく「GitLabによる一貫したコンテクスト」だったという話 GitLab の佐々木さんによる発表です。 AIをフル活用するためには、一貫したコンテクストを提供することが重要であり、GitLab ではフルリモートワークを実現するために徹底したドキュメンテーションが行われていた。また、GitLab を使うとコードの管理だけでなくチケット管理やCI/CDなどが可能。開発にまつわる幅広いコンテキストを GitLab 上に集めていると、GiaLab の AI が経験豊富で、横断的なコンテキストを知っているメンバーとして働いてくれるとのことです。 会場では、CIが失敗した時のエラーメッセージを GitLab の AI が読み取って、どんなコミットでエラーになったか、どうやったら修正できるのかを回答するデモが実施されていました。前職では2年半 GitLab を使っていたことがあるのですが、コンテキストが分断されない統合プラットフォームの強みがAIによってさらに強化されていることを感じました。 弊社では GitHub Copilot はもちろん、Notion AI も活用しています。Notion AI は仕様、Copilot はコードというように用途を分けて使っているので、GitLab の AI のようにこれらのコンテキストが統合できるAIがあるとより開発速度が上がるのだろうなと思ってセッションを見ていました。 トヨタ×モブ×AI：ハードウェア開発でのモブ活用と、AI時代のソフトウェア「チーム開発」 トヨタ自動車の竹内さん、名古屋大学の森崎さん、GitHub Japanの服部さんのディスカッションでした（司会はYesNoButの川口さんと翔泳社の小玉さん）。 トヨタの竹内さんから主に顧客のニーズの変化に対応するために、ハードウェア開発でもアジャイル開発を導入したこと、モブワークを導入することで全員参加の共同作業が促進され、待ち時間がなくなって作業の効率が向上したことが語られました。また、社内にいる「達人」たちのようにAIを達人に育てるためには、暗黙知を形式知に変換し、過去のトラブルなど必要なデータをインプットすることが重要だと話されていました。 他にもいくつか話題がありましたが、特にモブ作業、モブプログラミングでの心理的安全性の重要性は勉強になりました。謙虚さとは一人では何もできないと認めることであると定義されていたり、成長のステップを humility（謙虚になる） → Respect & Collaboration（リスペクトを持ち協働する） → Growth（成長する） → Fearless（恐れずに挑戦する）に分解されていたり学ぶところが多かったです。特に開発プロセスや心理的安全性のような人口に膾炙した概念と改めて向き合い、深掘りし、定義する姿勢にトヨタ社のカルチャーを垣間見た気がしました。 BASEではペアプロもモブプロもチームごとに取り入れたり取り入れなかったり、自由に選択することができます。経験上、プロジェクトの立ち上がりフェーズや複雑な箇所の開発の時にスポットでペアプロを取り入れている印象です。お互いに意思疎通ができた結果、思った通りのコードが出てくるようになる開発の終盤では発展的解消という形でペアプロをしなくなるケースも多々あります。開発者自身がペアプロの利点を意識してそれが最大になる場面で自発的に取り入れています。 おわりに 本参加レポートでは自分が参加したセッションをいくつかピックアップして、それぞれまとめて見てみました。しかし、現地で朝からイベントに参加して、テーマが共通している複数のセッションを聞いているとそのテーマに対してさらに深いインサイトを得られました。その話についてはまたどこかで書こうと思います。 改めましてデブサミ2025に登壇された方、運営の方、参加された方、皆様ありがとうございました&お疲れ様でした。 BASE では Web アプリケーションエンジニアを募集しています。もし興味があれば採用ページから応募をお願いします。 binc.jp

はじめに BASE BANK Department で開発責任者をしている斉藤です。 2025/2/22(土)に開催される PHPカンファレンス名古屋 2025にBASE BANKのエンジニアの02さんが登壇します。 加えて、BASE社としてもブロンズスポンサーとして協賛します。 phpcon.nagoya PHPカンファレンス名古屋2025 セッションの紹介 fortee.jp 2025/2/7に PHPUnit 12 がリリースされました！ 今回のアップデートでは、25箇所以上の変更が行われました。 いくつかのメソッドやオプション、Attributeも削除されており、既存のテストコードに影響が出る可能性が高いです。 そのような削除予定の機能について、どう変更 / 対応したらよいかをLTで発表します！ 02さんのセッションは「ルーム カルテット」で17:00から開催されるLTセッションのトップバッターになります！ ぜひ足を運んでください！ 02さんは懇親会にも参加しますので、発表で気になった点やBASEのことで気になっている点などお気軽に声をかけてください！ スポンサーについて 今回の協賛は「 BASE BANK, 中小規模のエンジニアイベントにも会場&飲食スポンサーします！ 」の記事を見て、運営の皆さまからご連絡をいただき、実現いたしました。 ありがとうございます！ 会場スポンサー、飲食スポンサーを引き続き実施しておりますので、お気軽にご連絡ください。 おわりに 名古屋でのPHPカンファレンスが初開催されることを心より応援しております！ 2025年2月12日現在、PHPカンファレンス名古屋 2025の当日のチケットは、以下のリンクよりお申し込みいただけます。 fortee.jp それでは皆様、PHPカンファレンス名古屋とBASEをどうぞよろしくお願いいたします！

はじめに 初めまして。BASEのエンジニアの田中大貴です。お客様の安心安全な購入を実現するためデータ分析や不正決済検知モデルの開発・運用を頑張っています。 今回は、チームのより良い開発環境を作るために行ってきた施策の事例をご紹介します。(機械学習に特有の問題ではない施策が多いです。) 開発フロー BASEでは、ショップの開設から購入に至るまで、様々なシーンで機械学習モデルが運用されています。私が所属するData Strategyというチーム(以下弊チーム)ではこのような機械学習モデルの開発運用をしています。 機械学習モデルによる推論は、APIによるリアルタイム推論もしくはワーカーによるバッチ推論によって提供します。弊チームではAPI・バッチをECSやLambdaを使って実装していることが多いです。典型的な推論部の開発の流れは以下の通りです。例としてECS上で動いているAPIに何かしらの変更を行うケースを示しています。 機械学習チームが採用しているデプロイフロー APIのコードとIaC(Terraform)のコードは別のレポジトリで管理しており、APIコード変更とTerraformコード変更の2段階によって本番環境への変更を行います。 開発環境改善の取り組み このような開発フローのもと、開発環境の改善のために以下のような取り組みを行ってきました。 APIコード変更レビュー・Terraformコード変更レビュー (手間★☆☆・効果★★☆) 以前は、以下のような課題がありました： branch protection ruleが一部のレポジトリにのみ導入されていた 意図しないmainブランチへのpushが発生する可能性があった(ブランチを切るのを忘れてmainにpushしかけてヒヤッとした経験は誰しもあるはず…笑) mainブランチのコードがフォーマットチェックやユニットテストを通過していない場合でもマージされてしまう可能性があり、コード品質の低下に繋がるリスクがあった プルリクエスト作成時に、レビュワーの指定を逐次行う必要があった レビュー依頼漏れやレビュワーの選定に時間がかかる場合があった これらの課題を解決するために、以下の施策を実施しました。 Branch Protection Ruleの設定 全てのレポジトリに対して、「Require a pull request before merging」と「Require status checks to pass before merging」を有効化 Code Ownerの設定 .github/CODEOWNERS ファイルを作成し、チームをCode Ownerとして指定 branch protection ruleに「Require review from Code Owners」を設定 これにより、以下の利点が得られました。 意図しないmainブランチへのpushを防ぐことができるようになり、コード管理の安全性が向上 mainブランチのコードがフォーマットチェックやユニットテストを通過していることを保証できるため、コード品質を保つことができる プルリクエストが完成すると、自動でチームにレビュー依頼が飛ぶ仕組みを作ることで、レビュー依頼漏れや手間を削減 ECRへのイメージプッシュ自動化 (手間★★☆・効果★★★) 以前は、コード変更のapprove後、開発者のローカルPCでlatestタグをつけて手動でビルドを行い、ローカルPCからECRへイメージプッシュを行っていました。 このプロセスには以下のような課題がありました。 イメージプッシュのし忘れの可能性があった 最新バージョンのコードがECRにプッシュされているかが開発者に依存しており、チーム内で最新のイメージが使用されているか不明確な状況があった 本番環境で稼働しているコードのバージョンを直ちに把握できなかった ローカルPCの環境差異によって、プッシュしたコードが動かない場合があった(特にIntel製CPUからApple製CPUへの移行期において問題が顕著でした) ビルドプロセスが煩雑になると、オンボーディングコストも高くなった これらの課題を解決するために、以下の施策を実施しました。 Github Actionsによる自動化 mainブランチへのマージをトリガーに、Github Actions上でイメージをビルドし、ECRへ自動でプッシュする仕組みを導入 Gitコミットハッシュを用いたタグ付け ECRへプッシュするイメージには latest タグに加え、Gitのコミットハッシュをタグとして付与することで、バージョン追跡性を向上 これにより、以下の利点が得られました。 ビルドプロセスをCIに集約することで、属人的な作業を削減し、手間やミスを防止 最新バージョンのコードが常にECRにプッシュされている状態を保証 本番環境で稼働しているコードのバージョンを即座に把握できるようになり、トラブル時の調査効率を向上 ローカルPCの環境依存による問題を排除し、安定したビルド環境を提供 監視 サービスを安定的に運用するためにはサービスの状態を監視することが重要です。ここからは監視の改善について取り組んだことをご紹介します。 環境・ログレベル別のアラーム管理 (手間★★★・効果★★★) 以前は、以下のような課題がありました。 1つのSlackチャンネルに重要度高~低の様々なアラームが混在していた 重要なアラームが見過ごされる可能性があり、インシデント対応が遅れるリスクがあった 不要なアラームが多く、必要十分なアラーム設定ができていなかった これらの課題を解決するために、以下の施策を実施しました。 アラーム通知先の整理 全社向けのアラートチャンネル運用指針(緊急度高・中・低の3段階で環境別にチャンネルを作成)に従い、アラーム通知先を整理 アラームのレビューと整理 現状設定されているアラームを1つずつレビューし、必要なアラームは新たに作成したアラートチャンネルへ通知するよう設定 特に緊急度の高いアラームについては、発砲後に何のアクションも取られていないアラームは廃止 これにより、以下の利点が得られました。 緊急度の高い重要なアラームが集約され見過ごしリスクが低下 アラームが緊急度別に適切なチャンネルに通知されることで、認識負荷の軽減 不要なアラームを削除することで、運用負荷の軽減 アラームは放置していると基本的にはどんどん増え続けていくものです。定期的にレビューし、メンテナンスを行うことが重要です。 ECSサーキットブレーカーの設定 (手間★☆☆・効果★☆☆) こちらは個別の設定になってしまいますが、ECSを利用している方の参考になればと思い紹介します。 ECSをローリングアップデートで更新する場合に、デプロイが何らかの原因で失敗した際に、ECSはデプロイを繰り返します。そのため、デプロイしたと思っていた変更が実はデプロイ出来ていなかった…という事態が発生する可能性がありました。 ECSサーキットブレーカー はそのようなデプロイ失敗を自動で検知し、一定回数のリトライ後にデプロイを中断・ロールバックする機能です。ECSタスク定義でフラグをtrueにするだけで、導入はとても簡単です。 弊チームでは、サーキットブレーカーを導入した上で、EventBridgeでサーキットブレーカー発動イベントを拾い、Slackに通知を行っています。これにより、開発者はデプロイ後AWSコンソールに張り付いていなくても、デプロイ失敗に気がつくことができるようになりました。 (参考までに、EventBridgeのイベントパターンは以下のように設定しています) { " source ": [ " aws.ecs " ] , " detail-type ": [ " ECS Deployment State Change " ] , " detail ": { " eventName ": [ " SERVICE_DEPLOYMENT_FAILED " ] } } おわりに BASEの機械学習チームでより良い開発環境の実現のために取り組んできたことを紹介しました。もう少し機械学習っぽい中身にできれば良かったのですが、いわゆるMLOps的な内容はまた別の機会にご紹介できればと思います。 このような施策は地味なものが多いですが、誰かが一度設定すればチーム全員が恩恵を受けることができるので、レバレッジ効果が大きいです。また、潜在的なインシデントを減らしたり、時間的・金銭的コストカットにも繋がったりするものも多いです。時間ができた時にぜひ諸々の設定や開発フローを見返してみてください。 BASEではメンバーを採用中です！ご興味のある方は是非以下をご覧ください。 binc.jp

はじめに BASE Dept. Product Devにてバックエンドエンジニアをしている オリバ です。 2024年末、弊社のソフトウェアエンジニア（以下、SWE）でSREに興味を持つメンバーを募り、「SREをはじめよう」を題材にした輪読会を実施しました。本記事では、各部・各章の要点を整理し、実践に役立つ知見を共有します。 ※引用元: O'Reilly Japan SREをはじめよう 第1部 SRE入門 この部では、SREの定義やSREの文化のような、SREの概論に触れています。 SREの定義 書籍では、SREを以下で定義しています。 サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において 適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。 工学の分野の１つと認識されていますが、情報系の学部出身の弊社社員の中で、工学分野としてのSREという言葉を耳にしたことがある方はいませんでした。もしかすると、将来的に大学の講義でもSREが取り上げられるかもしれません。 また、SREを理解するのに最適な１枚のスライドが紹介されています。 ※引用元: Keys to SRE このスライドはSREの始祖とも言われているBen Treynor Slossが、2014年5月31日のSREconの基調講演で紹介されたスライドです。 私が特に疑問に思ったのは、上から6つ目の Excess Ops work overflows to DEV team です。和訳すると、「余計な運用作業は開発チームにオーバーフローさせる」という意味になり、なぜ運用作業を開発チームにオーバーフローさせるのか輪読会で話し合い、以下の内容で解釈しました。 余計な運用作業があることを意図的に開発チームに気づかせるようにする SREの運用作業は過剰になりがちで、より重要な業務に注力するために、開発チームに一部を委譲する インシデントが起きたときに、SREの中で閉じないようにする DevOpsとSREの関係性 DevOps コードを本番環境にリリースするために何が必要か考えます。 SRE 本番環境を起点に、信頼できる運用を実現するには何をすべきか考えます。 ※引用元: SREの探求 SREの心構え 本書で特に重要とされるSREの心構えとして、以下の4点が挙げられます。 1. フィードバックループを重ねる 信頼性向上の中心となるのは、継続的な改善を可能にするフィードバックループの構築です。 2. 共同作業を重視する SREは、さまざまな分野の同僚と協力しながらシステムの信頼性を向上させます。また、顧客とも信頼性に関する共同作業を行う姿勢が重要です。 3. オーナーシップを持つ 運用するサービスに対して責任を持ち、主体的に取り組みます。 4. 失敗から学ぶ システムのエラーを学習機会と捉え、そこから改善のアイデアを得ます。 SREの文化を醸成する 本書で紹介されているSRE文化を醸成するための取り組みの中で、組織に取り入れやすいと思われるアイデアを以下にまとめました。 1. トイル削減を祝う文化を作る トイル（以下の特徴を持つ繰り返し作業）を削減した取り組みを組織全体で祝う文化を作ります。 手作業である 繰り返される 自動化可能 長期的価値を持たない サービスの成長に比例して増える（O(n)） 2. 「ポストモーテム会」や「デザインドキュメント会」の開催 ポストモーテムとは、インシデント発生後の事後検証プロセスです。インシデントレポートをチーム全体で共有する文化や、振り返りの場を定期的に設けることで、組織的な学びを深められる可能性があります。 3. チーム間のローテーション SWEが一定期間SREチームに参加する「交換留学」を実施することで、SRE文化が組織全体に広がります。弊社でも2025年からこの取り組みを開始する予定です。 SREを提唱する SREを提唱できる力は、組織内外でその存在意義を説明する場面で重要です。例えば、組織のステークホルダーにSREの存在意義を伝え、SREという組織を存在させる場面でも必要ですし、採用活動や転職時には、SREの役割や文化を候補者や採用側と共有し、ギャップを認識することが求められます。 また、他者の経験やストーリーを学ぶことも重要です。本書では、イベントや勉強会への参加が強く推奨されています。私もさっそく、2025年1月26日に開催される SRE Kaigi 2025 への参加申し込みを行いました。 第2部 個人がSREをはじめるには この部では、個人がSREを始めるために必要なスキルや考え方について説明します。 SREになるための準備 SREになるために必要なスキルとして、本書では以下を挙げています。 1. コーディングスキル コーディングスキルはSREにとって不可欠です。システムの構造を深く理解し、潜在的な故障を予測・防止する能力を備えるには、このスキルが求められます。 2. 計算機科学の学位 計算機科学の学位は必須ではありませんが、コーディング経験を通じて同等の知識を習得する必要があります。 3. モノリス、分散システムへの理解 OSやネットワークの仕組みを理解することは、大規模でスケーラブルなシステムの構築に不可欠です。また、近年ではマイクロサービスやマルチリージョン対応などの分散システムを扱うケースが増えています。 4. 統計とデータの可視化 SLI（Service Level Indicator）やSLO（Service Level Objective）で使用されるパーセンタイルの理解には統計学の知識が必要です。輪読会では マンガでわかる統計学 （Ohmsha） という書籍が推薦されていました。 その他、ストーリーテリング、NALSD（非抽象的な大規模システム設計）、レジリエンス工学、性能工学、AI/MLの知識も重要とされています。 肩書きだけの変更はNG 本書では、学生やSWEがSREに転向する方法が述べられていますが、システム管理者やDevOpsメンバー全員の肩書きを単に「SRE」に変更することへの警告も含まれています。 文化的・戦略的・組織的な変革を伴わない肩書きの変更では、SREの本質的なメリットを享受できません コラボレーションモード SREは「あくなき共同作業」によって成り立つと本書では強調されています。 具体例として、SLI/SLOの策定や実施が挙げられます。また、監視業務を通じて顧客の声に耳を傾け、顧客との共同作業も実現しています。 弊社では隔週で「定点観測会」を開催し、BASEのコア機能を洗い出し、SLI/SLOの見直しを行っています。 トイルとの関係を築く SREは、「SREの文化を醸成する」で触れたトイルに継続的に向き合う必要があります。本書では、その理由として以下の3つを挙げています。 1. 美学 トイルは非効率で美しさを欠き、最適化の障害となります。 2. お金 高度なエンジニアをトイルに費やすのではなく、価値を生む仕事に集中させることで、組織のコスト削減に繋がります。 3. 時間の使い方/仕事の満足度 エンジニアはトイルではなく開発業務に時間を使いたいと考えます。過剰なトイルは生産性と満足度を低下させます。 弊社では毎週、有志メンバーによるトリアージ会を開催しています。この会では、SentryやNewRelicのアラートを確認し、解決すべきIssueをタスクとして起票しています。 また、OKRを活用し、目標を達成するためのトイル解消に取り組んでいます。 ※ 参考: OKRを設定する( https://rework.withgoogle.com/jp/guides/set-goals-with-okrs ) 失敗から学ぶ 本書では、失敗から学ぶ方法として、インシデント後のレビューが重要であるとされています。 インシデント後のレビューでは、単なる文書や報告書、アクションリストの作成に留まらず、以下の点を重視することが求められます。 時系列での詳細な記録 インシデントの前後で何が起きたのかを明確に記載します。 プロセスの記述 どのような資料を参照したのか、解決までのプロセスを詳細に説明し、単なる事象の振り返りにとどまらず、将来の予防策や信頼性向上のための具体的な知見を得られます。 また、インシデント後のレビューを行う際には、以下の行動を避けることが重要です。 犯人探し 問題の原因を特定の人物に帰結させることは、生産的な学びや改善にはつながりません。 ヒューマンエラーへの責任転嫁 人間のミスに焦点を当てるだけでは、システム全体の信頼性向上を妨げます。 成功点の無視 問題解決においてうまく機能した点も学びの一部であり、見落とさないことが重要です。 インシデント後のレビューは、失敗からの学びをシステムの改善やプロセスの洗練に結びつけるための重要な手段です。これを適切に活用することで、組織全体の信頼性を向上させることができます。 なぜなぜ分析はアンチパターン 「なぜなぜ分析」は、トヨタグループの創始者である豊田佐吉が考案した手法です。この手法では、事象に対して「なぜ」を繰り返し問い続けることで、根本原因を突き詰めていきます。一般的に、5回「なぜ」を繰り返すと根本的な原因に到達できるとされています。 本書では、「なぜなぜ分析」は特定の事象を深掘りして原因を発見するのには適しているものの、インシデントを理解し、そこから学びを得るためには不十分であると指摘されています。その理由は以下の通りです。 重要な情報を見逃す可能性が高い システム全体の理解を阻害し、部分的な要因に偏りがちになる そのため、「なぜなぜ分析」はインシデント分析においてはアンチパターンとされています。 「なぜ」を繰り返す前に、まずは「何が起こったのか」を詳細に確認し、全体像を把握することが重要です。インシデントのプロセスや影響を全て洗い出すことで、包括的な学びと改善につながります。 第3部 組織がSREをはじめるには この部では、組織がSREの導入に成功するための要因を探っています。 Dickersonの信頼性の階層構造 既存の組織がSREを開始するためのわかりやすいロードマップとして、Dickersonの信頼性の階層構造があります。 これは、元Google社員のMikey Dickersonが、マズローの欲求階段説を引用したものです。 ※引用元: O'Reilly Japan SREをはじめよう p.198 マズローの階層構造と同様に、階層の一番下からはじめて、下の階層が強固になった時点で初めて上の階層に進みます。 1段目の監視/オブザーバビリティに関して、監視ツールやオブザーバビリティプラットフォームを導入している組織がほとんどだとは思いますが、意外とSLI/SLOまでしっかり実践している組織は少ないかもしれません。 SREを組織に組み込む 本書では、SREを0からスケールアップする（本書ではSRE0と呼ぶ）ために必要なものは、建築工学や土木工学など資格を持った人がいないとはじめられないものではなく、サービスやシステムに対する好奇心と、SLI/SLOを始めるための機会であると述べています。 また、SREが既に組織に統合されているモデルとして、以下の3種類を定義しています。 1. 中央集権型/パートナー型モデル Googleが最初に導入し普及させたもので、独立した組織として、採用プロセスや、人員、ジョブラダーを持ちます。例えばGoogleでは、GoogleマップのSREチーム、GmailのSREチーム、広告のSREチームが存在します。 2. 分散型/埋め込み型モデル Metaで導入されているモデルで、SREが開発チームに参加します。詳細は、 SREの探求 の第13章に記載されています。 3. ハイブリット型モデル 上記2つのモデルを混ぜて導入したもので、中央集権的な組織で働くSREと、個々の事業部門で個別に雇用されているSREがいます。 弊社が提供するサービスには、ECストアフロントを提供する「BASE」のほか、ID決済機能とショッピングアプリ機能を提供する「PayID」、金融サービスを提供する「BASE BANK」などがあります。（その他のサービスについてはここでは割愛します） これらを上記の3種類のモデルに当てはめると、「BASE」は中央集権型/パートナー型モデルに、「PayID」と「BASE BANK」は分散型/埋め込み型モデルに該当すると考えられます。 このことから、弊社全体としてはハイブリッド型モデルを採用していると言えるでしょう。 SRE組織の進化段階 SREチームの進化に関する概念的な枠組みとして、本書では、SREcon Asia 2018で元LinkedInのBenjamin Purgason氏が行った講演内容を引用しています。この進化段階は5つのステージに分かれていますが、必ずしも順序通りに進む必要はなく、ステージを飛ばして進化することも可能です。 段階1: 消防士 多くのSREチームがこのステージからスタートします。主な役割は障害対応などの「火消し」ですが、重要なのは火災と火災の間に何を行うかです。例えば、この時間を活用して、Dickersonの信頼性の階層構造でいう最初の2つの階層（監視/オブザーバビリティとインシデントレスポンス）の構築や、トイル（繰り返し作業）を撲滅するための自動化（本書では「自動消火装置」と表現）に取り組むことが推奨されています。 段階2: ゲートキーパー（門番） この段階では、SREが「ゲートキーパー」の役割を果たし、システムに関するすべての決定がSREを通過しなければならない状態になります。しかし、ゲートキーパー的な振る舞いは、他の開発者や組織内のメンバーに不快感を与える可能性があります。本書では具体例として、空港の税関職員をイメージした説明がなされています。 段階3: 提唱者 この段階では、SREと他のメンバーの関係がより協力的になります。SREは、設計やアーキテクチャの議論など、ソフトウェアライフサイクルの初期段階から積極的に関与します。これにより、全員が協力して本番環境を構築し、信頼性を高めることを目指します。 段階4: パートナー 段階3の発展形であり、SREとSWEがパートナーとして対等に協力する状態です。具体的には、計画やロードマップの作成を共同で行い、チーム間の連携がより強化されます。 段階5: エンジニア この最終段階では、SREとその他のエンジニアの役割の境界線が曖昧になります。全員がシステムのライフサイクル全体に関与し、信頼性向上を目的とした活動に取り組みます。SREの活動がチーム全体に自然に組み込まれ、信頼性が組織全体の文化として根付いた状態です。 今後の展望 本記事で取り上げた「SREをはじめよう」の内容や輪読会での議論を通じて、SRE文化の醸成や実践への理解が深まりました。今後、弊社では以下のような取り組みが可能ではないかと、輪読会で議論しました。 1.トイル削減を祝う文化の醸成 トリアージ会やOKRを活用したトイル削減活動を継続し、削減したトイルの成果を社内で共有し、モチベーションを高める文化を醸成します。 2. 知識共有の強化 外部イベントやカンファレンスへの参加、登壇を行い、自分なりのSREの定義を語れるようにします。 3. 失敗からの学びを最大化 ポストモーテム会を定期的に開催し、インシデント後の学びを組織全体に共有します おわりに 弊社では、SREの方だけではなく、サイトリライアビリティエンジニアリングに興味を持たれているSWEの方も積極採用しています。興味を持っていただいたら、ぜひ下記からご応募ください！ binc.jp

はじめに こんにちは！BASE株式会社でPay IDチーム プロダクトマネージャーをしているbunです。 Pay IDは、BASEで作られたショップでのお買いものを楽しむためのショッピングサービスとクイックでスムーズな決済機能を提供しています。 去年1年を振り返ると、多くの失敗や思うようにいかないことが重なり、そのたびに内省をする時間を持つことが多かったです。その過程で強く大事だと感じたことは、 プロダクトマネジメントで突き詰めるべきは「誰がなぜ幸せになるのか」を見失わないこと です。 これまで数値と論理を武器にキャリアを積んできましたが、プロダクトづくりにおいてはそれらが最優先事項ではないシーンが多いことを痛感しました。この記事では「数値や論理」をプロダクトづくりの軸とすることの功罪を再確認し、どのように活かすのかを自分なりに整理してみたいと思います。 数値 定量分析とはAかBのどちらが優位かを明確に示し、チーム全体の意思決定に納得・正しさ・早さを持たせることができます。膨大な情報の中から「見るべきポイント」を定義し、そこにフォーカスを当てることで関係者全員が判断基準を共有できることが数値の役割なのではないかと考えています。 しかし、この「明確化」の裏側には、「見ないことを決める」ということでもあります。つまり、明確な基準を設けて特定の指標を追うということは、それ以外の要素に注意を払わない、あるいは軽視することと表裏一体です。結果として、数値ベースの分析に特化しすぎると気づかないうちに視野が狭まってしまうことが往々にしてあります。 事例：キャンペーンクーポン 売上を短期的に押し上げるために「クーポン利用率」という指標を作ったと仮定します。定量的な目標を設定し、クーポンがどれだけダウンロードされ、何％の利用率に達したかをトラッキングすることで、クーポン取得数や利用数を着実に増やすことができ、売上も一時的に上昇し、データ上は「成功」と言える状態が生まれます。一方で「クーポン利用率」という特定の数値指標に照準を合わせることで、定量化しにくいが本質的に重要な要素が視界から消えてしまいます。 ブランドイメージ ：クーポンの乱発により、「安売りして当たり前」というイメージが定着し、長期的なブランド価値が下がる可能性がある。 顧客ロイヤリティ ：クーポンがなくなった瞬間に離反する顧客が増え、価格以外の価値が見えづらくなってしまう。 あくまで一例ですが数値分析の強みである「わかりやすさ」と「意思決定の明確化」は、同時に「多様な観点の切り捨て」をもたらしていることになります。 数値目標の達成には成功したとしても、“そこには映らない本質”を見落としている可能性があります。定量指標が示す「正しさ」はあくまで条件付きのものであり、広い視野を持たないとプロダクトが壊れてしまう難しさがあります。 見たいものだけみて、数値ベースで施策や行動をすべきと言っている場合はかなり危うい状況なのではないかなと思います。 論理 論理は既に知っている材料や情報を元に、筋道を立てて再配置するための枠組みのことだと考えています。一見すると失敗のリスクを低減してプロセスを合意形成しやすくする一方で、「既存のゲームルールの上を歩むだけ」という側面でもあります。 そのため、顧客の想像を超えない機能は驚きや感動のような心を動かすようなことはできず、大きな結果は生み出せない可能性が高いのではないかと考えています。 誰もが納得する形に落とし込もうとするとどうしても「定量的インパクト」「成功確率」といった言葉で企画やアイデアを語りがちになり、結果的に競合他社との「差別化」も難しくなります。 説得力を高めるための“客観的な説明”を重ねれば重ねるほど、いつの間にかユーザーの顔や感情が薄れていきます。 論理的整合性を高めることは大切ですが、プロダクトを使うのは「人」であり、彼らがどのような喜びや悩みを抱いているかを深く理解することこそが核心ではないかと考えています。 補助線を引くための道具 プロダクト開発でまず問うべきは 「誰がなぜ幸せになるのか」から始まるべきであり、数値や論理はこの問いに答えるうえでの「補助線」にすぎない のではないかなと考えています。施策の検証結果や仮説を得たり帰納的に考えることに限定すべきだと思います。また、 企画段階での施策の正しさは数値と論理ではなく顧客が持つイシューの解像度の深さと実行結果で判断すべき なのではないかなと考えています。 道具の扱い方 数値に左右されすぎない： 数値は短期的成果を測る指標にすぎない。視野を広く持ち、定量化できない部分にも目を向ける。 論理で固めすぎない： 試作や実験のフェーズでは、“熱量”や“直感”も大切にし、顧客の感情や想定外の行動に目を向ける。 哲学・ビジョンを明確に持つ： 「誰が、なぜ幸せになるのか」を常に問い続けることで、数値と論理に翻弄されない軸を持つ。 最後に 数値や論理はもちろん大切ですが、そこに顧客に憑依して“自分たちが本当に欲しい未来”を実装するバイアスが入っていなければありふれた機能しか生まれないのではないかと考えています。たとえよくある機能でもちょっとした気遣いがあるかどうかに差が現れてくると思います。 また、顧客のインサイト(本人が気づいていない隠れた欲望)に仮説を立てて不確実性の高いプロダクト開発をするには試行錯誤しながら素早く検証していくことが欠かせないと痛感しました。 今年は強い熱量や“バイアス”に引っ張られることをポジティブに捉えながら、実際に手を動かし、早くライトに実験し、失敗し、そこで得た学びを積み重ねながらプロダクトマネジメントをやっていきたいと思っています。 binc.jp

本記事は BASEアドベントカレンダー2024 の24日目の記事です。 はじめに CTOの川口 ( id:dmnlk ) です。 昨日の記事は下記です、それぞれいい記事なんで読んでね。 今、リモートワークについて思うこと 統括マネージャー(EM of EM)の仕事7選 BASE社では現在もエンジニア採用を行っています。 その中でよく質問を頂くのは「BASEに今から入社した場合にやることはあるのか？」というものです。 ここまで読んだBASE開発ブログファンの方はお気づきかもしれませんが、こんな内容の記事を以前書きました。 今BASEに入社してやることあるの？という疑問に答えるよ この記事から3年経った今、現在のBASE社の現状を踏まえた必要とされていることを書いていこうと思います。 サーバーサイドアプリケーションのリアーキテクチャ BASEのメインアプリケーションはCakePHP2系で書かれています。 このアプリケーションのFW移行、リアーキテクチャを数年続けています。 重要機能であるカート部分はリアーキテクチャが完了し現在はCakePHP4系で動いています。 このアプリケーションはCakePHP4系をベースに作られていますが、FWに極端に依存することを避けモジュラモノリスとクリーンアーキテクチャを ベースとしたアーキテクチャを採用しています。 詳細に関しては弊社テックリードが発表したこの資料を参照していただければと思います。 BASE大規模リアーキテクチャリング その後もリアーキテクチャの開発は進んでおり、新機能などは可能な限りこのアプリケーション上に構築するようになっています。 もちろん例外はありますが、その際もなぜ旧リポジトリで開発する必要があるかというのをプロポーザルを書くようになっています。 とはいえBASEの大規模なアプリケーション群はまだまだ移行しなければならないのでこちらの移行開発をスループット高く移行開発する必要があります。 このあたりの基盤開発やレガシーアプリケーションのマイグレーションなどを行いたい方のご応募をお待ちしています。 不正検知 BASE社はPAY株式会社を子会社に持ち、PAY.JPというオンライン決済サービスを有しています。 よって、EC取引から決済処理に至るまで、横断的かつ包括的な不正検知の仕組みを構築できるユニークな立場にあります。 これまでに不正検知システムを構築し、一定の成果を上げてきました。しかし、急速に進化するサイバー犯罪や不正な決済に対応し続けるため、さらなる強化が必要です。この取り組みは、BASEやPAY.JPを利用する顧客や加盟店の安全性を確保し、信頼されるサービスを提供するために欠かせないものです。 決済のトランザクション処理やECの購買データなどを利用し、横断的により効果的な不正検知システムを構築していける方を募集しています。 レコメンド これは Pay ID チームが主体となりますが、Pay IDでは多くのショップの商品を有しており多種多様な顧客ニーズに応えています。 しかし、商品の多様性が豊富である一方、膨大な商品データから顧客が適切な商品を見つけるのは容易ではありません。この課題を解決するために、レコメンドシステムは不可欠な役割を果たします。 膨大な商品データをリアルタイムに処理していくには計算リソースの管理と効率的なアルゴリズムが求められます。 このようなレコメンドシステムを構築していくにあたりデータサイエンスや機械学習のスキルだけでなく効率的でハイスループットなインフラストラクチャを構築していかなければいけません。 レコメンドシステムのさらなる進化を共に追求し、新たな購買体験を創り出しした方をお待ちしています。 グループ間連携と技術ガバナンス 先日、BASEは越境EC事業を展開するwant.jpの株式を取得し子会社化しました。 子会社化したからといってすぐさまBASE社がすべてを管理していくということにはなりませんが、これから密接な連携を行う予定です。 その上でグループ間でのアプリケーション連携や開発組織を構築していく必要があり、技術水準やセキュリティ水準も合わせていくことになります。 このような経験を行ったことは自分自身がないため、知見を持っている方をお待ちしております。 グローバルプロダクト 越境EC事業を行っている会社を子会社化していることからも分かる通りBASE社はグローバルなプロダクトへの道筋を模索しはじめています。 BASEそのものをグローバルプロダクトにしていくかは現状不透明ですが、世界を見据えたプロダクト開発が必要になっていくことはわかっているため 開発組織の大幅な変更や、グローバルに展開するプロダクトに必要な技術開発をご経験された方をお待ちしております。 SLI/SLO BASEでは決済取引の信頼性、ページの高速なレスポンス、そして常時アクセス可能なサービスの提供が、ビジネス成功の鍵を握っています。特に、売上に直結する「サービスの品質」は、私たちにとって最優先課題です。 そこで私たちは、システムの信頼性を数値で明確に示し、適切な目標を定めるために、SLI（サービスレベル指標）/SLO（サービスレベル目標） の策定に取り組み始めました。この取り組みを通じて、例えば「カートページのレスポンスタイムはXms以内」や「決済処理の成功率はX%以上」(あくまで例です)といった具体的な目標を設定し、サービス品質を改善していきます。 SLI/SLOの策定は、単なる技術的な改善ではありません。それは、「ユーザーにどんな体験を届けたいか」をチーム全体で考え抜く作業でもあります。ECプラットフォームという特性上、ユーザーは少しの遅延やエラーでも離脱する可能性があります。だからこそ、私たちはシステム全体の動きをデータに基づいて把握し、予防的に問題を解決することで、ユーザー体験を最適化したいと考えています。 この活動には主にNewRelicを利用しています。 この活動を行うのは特別なロールというよりは開発エンジニアそれぞれが取り組んでいくべきことです。 今後、SLI/SLOを基盤に、より信頼性の高いシステムを構築し、チーム全員が共通のゴールを目指せる環境を整えていきます。この挑戦に参加し、私たちと一緒に「より良いECプラットフォーム」を作り上げてくれる方を募集しています。 セキュリティ こちらも前回の記事で書いていましたが、セキュリティの重要性は年々増しています。 他社事例にはなってしまいますが、セキュリティインシデントによる事業停止のリスクは非常に大きくなっていますし攻撃は高度化しています。 BASEアプリケーションだけでなく社内システムや従業員教育なども必要になっており、CISO担当と共に行動していただくことになると思っています。 セキュリティと開発体験などはトレードオフとされがちですが、セキュリティのために開発のスループットを落とさずセキュアにハイスピードで開発できるようにしていくことを目指しています。 AWSインフラのコスト最適化およびモダン化 BASEを支えるAWSインフラのコスト最適化およびモダン化に積極的に取り組んでいます。これらの施策は、効率的な運用とスケーラビリティの向上を図りながら、より優れたユーザー体験を提供するために欠かせないものです。 ECプラットフォームにおいて、トラフィックの増加や利用者ニーズの多様化に伴い、インフラコストが上昇することは避けられません。 加えて昨今の円安事情によりコスト最適化は継続して行うイシューという意識となっています。 しかし、単にコストを削減するだけではなく、システムの信頼性やスピード、柔軟性を維持しながら最適化することが求められます。また、新しい技術を導入し、技術的負債を解消することで、将来の拡張性や運用効率を確保しています。 コスト最適化においてはインスタンスなどのリソース利用の動的な変更やモニタリングの強化、画像配信のネットワーク最適化などを取り組んでいます。 モダン化においてはコンテナ化やIaC、効率的でないインフラ構築手順の簡素化などを取り組んでいます。 SREチームが主に取り組んでいますが、開発者それぞれが取り組んでいくべき課題と捉えていますのでアプリケーションインフラを積極的に触れていきたい方をお待ちしています。 おわりに これらだけでなくまだまだ多くの課題や未来への開発をBASE社は抱えています。 技術はあくまで手段ですが、私達の開発組織を構成するエンジニアとして積極的に技術研鑽をして事業とプロダクトにコミットしていくことを求めています。 やることない、なんてことは全くないのでカジュアル面談からでもよいのでBASEに興味を持っていただければと思います。

本記事は BASEアドベントカレンダー2024 の24日目の記事です。 はじめに こんにちは！BASE事業エンジニアチームにて責任者（エンジニアリングマネージャー）をしている 植田 です。いよいよアドベントカレンダーも今日を含めてラスト2日となりました。今日や明日クリスマスを楽しむ方も多いのではないでしょうか。 さて、私は今回、”統括マネージャー(EM of EM)”とはどういう仕事か、日々どんなことを考えて仕事をしているかをお届けしたくアドベントカレンダーを執筆しました。 想定読者は以下の方々になります。 現在エンジニアリングマネージャー(以下EM)をしていて今後EM of EMを目指していきたい方 統括マネージャーとはどんな仕事なのか興味のある方 私の組織を簡単にご紹介 まず私の組織と私の立場をご紹介します。 はじめに組織構成ですが、Product Dev DivisionがBASE事業の開発チームになっておりDivisionの配下に複数の開発チームが存在していて、開発チームにはEMがつきマネジメントしています。 続いて、開発組織のミッションは大きく分けて3つあります。 BASE事業におけるフィーチャー(機能)をデリバリーしていくこと 既存機能を運用・保守していくこと 技術課題を解決していくこと 私のミッションはこの組織全体のパフォーマンスを最大化し、安心安全なプラットフォームを構築していくことになります。今日は私の立場を”統括マネージャー”と表現し、普段の仕事について紹介していきたいと思います。 統括マネージャーの仕事7選 全てではありませんが自分が重要であると考えている仕事を7つ書き出してみました。 組織の方向性を打ち出し、組織のベクトルを揃える 未来を見通し、先手を打つ EMを通して組織を動かす 開発組織として何に投資するかの意思決定 組織作り 隣接組織とのハブ役 現場メンバーとのコミュニケーション なお1人の人間はそこまで万能ではないので、これらを1人きりでやっているということではなく、頼れるEM陣と日々協力しながら実行しています。それではそれぞれの仕事を細かく紹介していきます。 1. 組織の方向性を打ち出し、組織のベクトルを揃える 私が統括マネージャーの任用を打診されたときに始めに考えたアクションはこちらでした。私の組織は数十人のエンジニアが在籍しているのですが、何もせずとも開発は自然と進んでいく、しかし果たしてその推進力は最大化できているだろうか、と。どんなに優秀なエンジニアが在籍していてもバラバラの方向を向いていてはその力は最大限発揮することはできない、きちんとビジョンや方向性を打ち出すことで、パフォーマンスが最大化できるのではないかと考えたことがきっかけでした。方向性は打ち出して終わりではなく、それに対して理解を深めたり浸透させていくことが大事です。これは時間がかかる話しなので現在進行系ですが、ビジョンや方向性を打ち出すことで、統括マネージャーとしての考えや行動に1本筋が通り良かったと考えています。 方向性を打ち出したことの細かい話は以下の記事でも触れているので、そちらも合わせて読んでいただけたら幸いです。 https://basebook.binc.jp/entry/2024/10/04/132904 2. 未来を見通し、先手を打つ 組織の中では立場や役割によって、どの程度先を見据えてプロダクトや組織を考えるかが変わってきます。現場のメンバーであれば現在〜3ヶ月先、チームを任せられているEMであれば半年〜1年くらい、統括マネージャーであれば1〜3年くらい先を見通せるのが理想的かもしれません。統括マネージャーの立場であるのに現場とまったく同じ目線で仕事をしていては、少し先の未来に想定していないことが起きた時、組織ごと沈没してしまいますし、すべてが後手後手に回ってしまいます。未来を見通し舵取りしていくからこそ組織はよどみなく成長していくものだと考えています。よって可能な限り未来を見通し計画を立てていくのが重要なのですが、私も3年先のことを解像度高く考えられているかというとこれは容易ではなく修行が必要だと考えています。 3. EMを通して組織を動かす 統括マネージャーになることの1番大きな変化は、直接的にメンバーをマネジメントしなくなる、ということかもしれません。メンバーと直接接点があれば、PJに対するアドバイスもリアルタイムでできるし、メンバーのキャリアや成長に対するアドバイスもやろうと思えば毎週できます。メンバーと直接定期的に会話するのでメンバーや現場のことに対する解像度も高く維持できます。ですが純粋な統括マネージャーはメンバーとの接点は減ってしまうのでその利点を失うことになります。そうなった時に重要なのが自分の配下のEMと会話し意思疎通し、または自分の考えを伝え、それを広げていくことです。また立場的に役員の方々と直接会議したり会話することも増え、それだけ重要な意思決定や情報に触れているわけでもあります。そういった一次情報に触れているわけなので可能な限りEMにも連携し情報格差をなくし同じ視野で組織運営できる状態を整える、それも統括マネージャーの重要な仕事だと考えています。 4. 開発組織として何に投資するかの意思決定 前提として、事業成長のために開発を行っているわけなので、開発組織のみで何をしていくかを考えているのではなく、基本は事業における優先度に則り必要な開発をしています。という基本的な考えがある中で、目先の事業成長だけを考えていると、少し先の未来に起こり得るシステムのパフォーマンス問題やセキュリティリスクといったものは見過ごされがちになってしまいます。BASEではQごとに計画や目標を立てるサイクルになっていますが、計画や目標を考えることはつまり何に投資するかの意思決定であると考えています。事業成長のためにどんな開発をしていくのか、プラスアルファで開発組織としてやるべきことはなにか？を常に考えて行動しています。 5. 組織作り 組織作りは、組織構造を考えること、メンバーを育成すること、採用を通して新たな仲間を見つけてくること、組織の文化形成などがあげられます。統括マネージャーという立場であれば、単一チームを超えたより広い視点で組織を考えていくことが求められます。事業をさらに加速していくためにはどんなチームが必要か、どんな人材がどれだけ必要か、誰をどこに配置すべきか、開発をさらに加速させるために必要な文化とは何かを計画し、育成、採用、文化形成それぞれの手段をミックスさせながら組織作りをしていきます。 6. 隣接組織とのハブ役 BASE事業においては、BizDev Division、Marketing Division、Owners Success Divisionなどが組織を構成し事業を支えています。そのような隣接組織と互いの期待値を調整をしたり、具体的な業務を依頼したり依頼されたりといったコミュニケーションが日々発生します。ある程度現場チームに紐づく業務は自分が介入せずに済むことも多いですが、いわゆるチームの間に落ちるボールや、突発的な案件などは直接相談が舞い込むことも多く、なるべくなめらかに互いの組織の業務が進むようにハブとなるのも大事な仕事です。組織の顔として動くことにもなるため一定の緊張感を持って臨んでいます。 7. 現場メンバーとのコミュニケーション さきほどEMを通して組織を動かすということを紹介しましたが、とはいえメンバーと直接会話する機会を作ることも大事です。現在は3ヶ月に1度の頻度でメンバーとの1on1の時間を設けています。いわゆるスキップレベルミーティングですね。メンバーから声がかかるのを待つのではなく能動的に自分からコミュニケーションの場を作っています。メンバーと直接会話し現在はどんな様子なのか、組織に対して課題に思っていることはないかなどをヒアリングしています。会話をすることでメンバーに対する解像度が高くなりメンバーに対する持論を持つこともできます。自分のポリシーとしてメンバーと話した内容はEMの方にも共有するようにしています。EMの立場から見て自身の見えないところで、メンバーと上長が会話しているというのはソワソワするものです。よってメンバーに許可を取った上でメモは共有するようにしています。またメンバーとEMの信頼関係を超えて自分が不必要にメンバーと蜜月にならないようにもしています。それはチームとメンバーをマネジメントしているEMという立場を尊重しているからです。 おわりに 本日は統括マネージャー(EM of EM)の仕事を7つ紹介しました。1つでも参考になる話があれば幸いです。BASEではWebアプリケーションエンジニア、エンジニアリングマネージャー、テックリードそれぞれ積極的に採用中です。ご興味ある方はお気軽にお声がけください。 さて、明日はアドベントカレンダー最終日です、毎年恒例弊社 CTO の記事ですのでお楽しみに。 binc.jp

本記事は BASE アドベントカレンダー 2024 の 24 日目の記事です。 こんにちは、エンジニアリングマネージャーの松原( @simezi9 )です。 新型コロナウイルスの流行に端を発する世の中の変動からもうじき5年が経過しようとしています。 当時の感染対策の流れで多くの企業がリモートワーク制度の導入を進めました。この記事を読んでいる方の中にもそのタイミングではじめてリモートワークに取り組んだ方も多いのではないでしょうか。 私もその当時に、BASE株式会社のリモートワークへの取り組みをエントリとして公開したことがありました。 参考： エンジニアのリモートワーク in BASE このエントリを書いてから4年。その間、マネージャーという立場からリモートワークの制度を運用してきた経験を踏まえて、私がいまリモートワークというシステムに対して思っていることを率直に書いてみたいと思います。 この文章が、リモートワークの導入・廃止で悩む管理者や、それらの決定がどういう経緯のもとで進んでいるのか納得できないメンバーの方々の理解の助けになればいいなと思っています。 （エクスキューズ）BASEではリモートワークの運用はチームに任されている部分が多く取り組み方も千差万別なので、前述のエントリとは違ってこの記事は会社全体の取り組みとは一切関係がなく、一人の中間管理職としての私見を述べたものであることは事前にご認識いただければと思います。 世の中のリモートワークに対する反動 まず、この4年ではっきりしてきた流れはリモートワーク制度への反動であると思います。 コロナウイルスの世界的な流行をきっかけに普及したということは、その制度は言い換えれば外的な動機によって駆動されていたものであり、内的な動機に支えられたものではなかったと言えるかと思います。 そしてその制度にチャレンジした結果として、「組織の結束力が弱まる」「イノベーションが生まれなくなる」といった理由で制度の縮小・撤廃をしていく企業がどんどん現れているように思います。 これは日本企業のみならずアメリカのビッグテックであっても同様、というよりむしろ顕著であって、Google,Apple,OpenAIといった世界を代表する企業であってもリモートワークに否定的なスタンスを取り、出社にかじを切り直そうとしている事例はいくらでもでてきます。 SNSなどを眺めていても、出社のルールを設定したい会社とそれに抗う社員という構図はよく見かける光景になったと思います。 あらためて、その功罪について自分の考えを述べてみたいと思います。ここでは一般論として言われていることは前提として省いて、あくまで私自身が強く感じるメリット・デメリットのことを書いていきたいと思っています。 リモートワークのメリット メリットについては正直、世間一般で言われていることがすべてという感じで、改めて書くようなことも少ないのですが、とりわけ大きいなと思うことだけにとどめて書きます。 ワークライフバランスの取りやすさ 育児の最中、あるいは持病を抱えている方、家族の介護を抱えている方にとっては通勤による拘束時間が短くなって勤務中にもちょっとした割り込みタスクを捌ける、生活と両立ができるというのは大きなメリットとして存在しています。仕事の存在によって日々のスケジュールが圧迫されて大変だと思う瞬間は減ったように思います。 通勤時間の節約 特に不動産価格の高騰が続く首都圏にあっては顕著ですが、片道1時間の郊外からの通勤時間が不要になるというのは大きいメリットです。会社としても交通費用の手当が不要になり、社員側も毎日長い通勤時間の拘束が減り、満員電車で疲弊してしまうという事態も避けられます。 リモートワークのデメリット こちらは組織を運営する立場の人間として、思うことが多かったので分量としては大きくなります。デメリットというべきではなく、賛否がある考えも多く含まれています。 組織力の低下 「社員の総業務委託化」 表現としては少し過激ですがリモートワークが標準の組織にあっては、オフィスで働いていた頃ほどの人間関係を結ぶのは相当に厳しいものであると感じています。 普段のコミュニケーションの輪はどうしてもチームの外には広がっていきませんし、淡白な働き方にならざるを得ない部分はあるかと思います。 これは組織のサイロ化として、リモートワークの欠点として挙げられていることが多いように思います。 実際に、会社が何を考えているのかわからなくなった、他のチームが何をしているのかよくわからない、という話をしている光景を目にする機会は体感として増えているような感触は受けます。 また、スキルのポータビリティが高く、転職が容易な技術職にあっては、傭兵のように働き、飽きたら次の現場にさっと移ってしまうという動きも増えたように感じています。 リモートワークが標準になることで転職のハードルも大きく下がりました。場所も知らないあちこちのオフィスに何度も訪問して面接をする、という大変な過程が減り、とりあえずZoomやMeetで最初の面接をするという流れに変わったことは大きいと思います。 少数の社員で役職の垣根を超えて密なコミュニケーションで理不尽や不条理を乗り切らないといけないフェーズの会社ではこれは非常に苦しい状態であるかと思います。 あるいは、リモートで身体感覚を伴わず入社してきた方が、広い人間関係を構築することなくリモートでふらっと次の職場に移っていく光景もよく見かけました。 そしてそれを阻止するべくオンボーディングのプロセスを丁寧に行う、ということもよく行われていたように思います。ただオンボーディングだけで組織への愛着を醸成するのは難しいことでもありそうです。（第一歩としては重要だと思います） ウェットな人間関係を仕事に持ち込むことに対して否定的な考えもありますし、それはそれで尊重されることだと思います。なので、制度を考える側は自分の組織がどういう形であってほしいのか、というのを考えて選択する必要があります。 わたし自身はオフィスで働いていた頃に比べると、リモートワークは「刺激に乏しく退屈である」という印象をもっているのは偽らざるところです。 これについては特にマネージャーとメンバーの間で感覚の分断が大きい領域であると感じていてます。責務を与えてくれればこなします、それでなにか不足はありますか、というメンバーからの指摘と、明確な形にはしづらいが組織体の強化において出社は重要であると考えるマネージャーの間の分断は少なくとも自分が社内外で話を聞いたところでは一定起きているような気がします オンラインミーティングの難しさ ここについては特に個人の感想という部分が大きいのですが、対面で行われるミーティングに比べて、オンラインミーティングはとても難しいと感じています。 それはボディランゲージの情報量がガクッと落ちてしまったり、会話の間がつかみにくくやり取りが盛り上がらないことであったり、原因は様々考えられます。以前なにかの記事では対面と比べてオンラインだと伝わる情報量が7−8割落ちるなんて話も見た覚えがあります。 私自身もオンラインミーティングは画面に集中するのが難しく、つい他のウインドウを見に行ってしまったり、会話に参加し続けるのが難しいと感じる瞬間がよくあります。 また、オンラインミーティングは会議室という物理的制約を受けないため、無駄に何人も参加者を増やしてしまっても成立してしまう、という特徴があります。結果として、15人参加しているけれど10人は画面もマイクもオフで残りの5人が会話してるだけ、という超絶に不毛な時間が生まれたりすることがあります。会議室で行うミーティングではこういうことはなかなか起こりません。 オンラインミーティングの主催者は人数を絞り、議題を明確にし、参加者の集中力を切らさないようにするために、対面のミーティングよりもはるかに気を配る必要があります。 一度始めると廃止のハードルが高い リモートワークの話に戻りましょう。 一般論として、一度獲得した権利を奪われる、ということに対して人は強い抵抗を示します。 そしてその理由というものは、通勤が嫌だ、というようなちょっとした目の前に見える問題に対する拒否反応であったり、地方に家を買ってしまったからそんな簡単に出社をベースにできないといった大きな問題まで様々です。 リモートワークの制度を縮小する可能性が少しでもあるならば、この制度はあくまで現時点のものであり永続的に保証されているものではない、というのを事前に確認しておくべきです。場合によっては労使契約でちゃんと確認していく必要もあるでしょう。 でないと制度を変えたときに一挙に離職が発生するリスクにもなりますし、会社にとっても労働者にとっても不幸な結果になってしまいやすいです。 特に、フルリモートで働けます、というのをウリ文句にして求人を出している会社は世の中にも少なからずありますが、その制度の将来性というのはなるべく開示するべきだと思います。またその一方で労働者の側も、リモートワークの制度が長く保証されているケースは少ないということを認識しておくべきことであると思います。 少なくともある程度の広さのオフィスを構えている会社はいつオフィス回帰という判断を下してもおかしくはない、というのがわたしの印象です。 リモートワークという制度を導入するのはそれほど難しくない（情報セキュリティやワークフローの構築といった実務の問題は当然あります）のに比べると、その規模を縮小したり廃止するというのは会社をひっくり返すような騒ぎになりかねません。 制度を運用する側はその点を非常に重く考えて制度を設計するべきであると考えています。 リモートワークの性質 メリット、デメリットではなくリモートワークってこういうことがありがちだよね、というのを列挙してみます。 アウトプットに評価の比重が大きく偏る リモートワークにおいて、普段の業務態度、ふるまいなどは視界に入りにくくなります。 そのため、「その人が何をしたか」という形に残るアウトプットにのみ評価の根拠が置かれる極端な成果主義になりやすいと感じます。 腕に自身がある人にとってはそれで十分だと思うでしょうし、対面でのソフトスキルに自分の価値があると思う人は苦戦を強いられることもあるかもしれません。 特にオンラインで入社してきた人は否が応でも自分の価値を具体的な作業で主張する必要があり、職場への適応に苦労することも多いのではないかと思います。 ハイブリッドワークは本当にちょうどいいのか オフィスへの出社とリモートワークを使い分けるハイブリッドワークという単語も世の中ではよく使われるようになったと思います。 単に「出社してもいいよ」から「最低でもこの日は出社してください」というパターンまで濃淡は様々見受けられます。 これはリモートワークとオフィスワークのいいとこ取りをしようという動きのようでいて、実際のところはリモートワークの欠点を補うために少しでもオフィスワークを取り入れよう、というコンテキストから増えてきた動きである、という感覚のほうが近いような気はしています。 しかしながら、このハイブリッドワークの取り組みはオフィスワークとリモートワークの悪いところどりにもなりかねない一番難しい取り組みなのではないかと感じています。 出社日を決めないパターンでは結局オフィスに来ない人が徐々に増えていってあまり機能しない状態に陥りやすいですし、出社日を設定するパターンであっても出社日の決め方や、オフィスならではのコミュニケーションがちゃんと発生するような仕掛け、そういった配慮がないと、「単にオフィスに呼び出されて嫌々出社するだけの日」に陥りやすい気はしています。 現実のオフィスとそこで行うチームワークをいかに魅力的にするか、管理者の力量が非常に求められるところであると感じています。そこにコストをかけないのであればおそらくハイブリッドワークはうまくいきません。 形骸化しやすい「出社日」 前項での話に近いのですが、出社日というものに効力をもたせるには一定の規律が必要です。 せっかく出社日をつくったところで「今日は頭痛いので家でやります」（そんな移動できないほど頭痛いなら出社しないとかではなく休暇を取って休んでほしい）といったことがカジュアルに行われるようになるとその意味は薄れていきます。 「やむにやまれぬ事情」の基準は人によって千差万別でありどこまで配慮するべきか大変に難しい問題となります。 そして誰かがオフィスにいない場合、会議もオンラインで実施する必要があり、オフィス組と自宅組の分断が生まれたりして、「なんだかいろいろやりづらい」という状況を招きます。これは特に出社体験を良くするための仕組みを色々用意していればいるほど起こりやすい状況であると思います。その状況では１人でもリモートワークの人がいるとチーム全体の出社体験が悪化す る、という認識を全員が持っておく必要があるかな、と思います。 本当に出社日を設定するなら安易に例外を作らない、という強い気持ちが管理者の側に要求されるように思います。とりあえず出社日を作ればいろいろうまくいくはず、というのはあまり現実的ではないと感じています。 フリーアドレスの功罪 これはリモートワークの話からは少しそれるのですが、リモートワークを導入してオフィスの稼働率が減っていく中、採用によって人員が増えると固定席を割り当てる意義が低下していきます。 オフィスにこない人員のデスクのためにオフィスを増床したりレイアウト変更するコストを払う必要はない、ということでオフィス側でフリーアドレスを導入する企業もちらほらと見かけます。 表面的には非常に合理的な手法なのですが、これはこれで用心する必要があると思っています。というのも、フリーアドレスにすることで自分の愛着の持てるデスクがなくなり、毎回行ってみないとデスク環境がわからない、というところでオフィスをますます敬遠する結果になりかねないからです。 またフリーアドレスということでチームのメンバーで会話する機会が机が離れて物理的に分断されることで奪われてしまう可能性もあります。 フリーアドレスも慎重に行わないと、「家がメインでオフィスはたまに行く場所」という認識を定着させかねないものであるということは留意しておく必要があるように思います。 生産性は向上するのか 昨今ではとりわけ「生産性」というワードが注目を集めているように感じます。 リモートワークにまつわる議論でも、「リモートワークではサボるから生産性がさがる」「家で働くほうが落ち着いて取り組めるので生産性が高い」、といった素朴なところからはじまり様々な声を見かけます。 この議論についてはおそらく結論が出ることはないだろうと見ています。 そもそもの生産性という言葉が何を指しているのかの定義が非常に難しいですし、職場や組織の条件次第であまりに変数が多く価値のある統計データを導き出すことも難しいように感じているからです。 例えば、オフィスのレイアウトをオープンにするほうがいいか、ちゃんと仕切りを作ってクローズドな環境を作ったほうがいいか、というような話題も未だに決着がでているようには見えません。 それを思えばそれ以上に変数の多いリモートワークの生産性について一般的な結論が出ることを期待するべきではないでしょう。 結果として、「生産性のためにリモートワークを廃止する・維持する」という議論は双方が納得することなく不毛に終わることがほとんどであるように思います。 SNSでも「リモートワークがうまくいくと思っている人はレベルが低い」「リモートワークで生産性が落ちる職場のレベルが低い」というような根拠のないレッテル貼りや煽り合いに終止してしまっている光景をよく見ます。 組織の制度を決定する権限を持っている人は、この生産性という概念を議論に持ち込まないほうが意思決定の根拠を揺らがずに決めることができるのではないだろうかと思っています。 最後に：管理者として揺れ動く中で ここまでデメリットやネガティブな話の比重がかなり多くなってしまいました。これは、私自身が心の何処かでリモートワークはあまり良くないものだ、と考えている結果なのかもしれません。 リモートワークはメリット・デメリットで天秤にかけるものではなく事業の利益には相反する福利厚生なのであると割り切って考えるべきなのかもしれません。その場合は事業へのダメージをなるべく減らしながらリモートワークを行う、という考え方になるのだろうと思います。 結局のところ、リモートワークを成立させるのは諸々の前提が必要であり、組織の上から下までその難しさを認識して取り組んでいく必要があるものだと思っています。 その最たる例がGitLab社であると思います。同社はリモートワークで働くために必要な非同期コミュニケーションを徹底的に整え、 ガイドラインを公開しています が、逆に言えばそれだけのコストをかける覚悟が必要であるという証左でもあると思います。 私自身は、リモートワークの難しさに立ち向かう手間と予算を払う覚悟がなければ、オフィスで仕事をしたほうが最終的に会社の利益にはつながるのであろうと思っています。 一方で管理職といえど従業員の立場であることは変わらないのであって、リモートワークから得られる利益を捨てる決断をしがたいのも事実であります。 この部分の決断は中間管理職や現場の判断ではなく、リモートワーク継続にせよ廃止にせよ、経営者やそれに準ずる立場の人間がバシッと決めてルールにしてしまうことが必要なのだろうと思います。各位に裁量を渡した状態では組織が全体として引き締まることは難しいように感じています。 それで組織を去る人もいれば、そういう組織を求めている方もいる、というのは実感としてあるので組織を作る基盤としてしっかり意思を示していくことが大事であると感じています。 リモートワークにまつわる議論は広範に行われていて、私自身も綺麗に文章として整理し切ることができず、このエントリを書くのにも非常に苦労しました。その割に綺麗にまとめきれず大変悔しいところではありますが、皆様の労働がより楽しく充実したものになれば、と思っています。 明日はいよいよアドベントカレンダー最終日、弊社CTOの @dmnlk による記事です。お楽しみに！