はじめに 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 による記事です。お楽しみに！

はじめに BASEのProductDev でエンジニア をしています endu です。 本記事は BASE アドベントカレンダー 2024 の 23 日目の記事です! 昨日は @zan_sakurai さんで 「 今年の記事をふりかえってみた 」でした! 記事の中で「イベントレポート・スポンサー・登壇に関する記事が多かった」とありましたが、この記事もイベントレポート記事になります! 2024年を締めくくるイベントという事で2024/12/22（日）に開催された 「PHP Conference Japan 2024」の参加レポート記事をご紹介します! BASEのスポンサーブースの紹介につて 前回のテックブログ でも書いたようにBASEはゴールドスポンサーで協賛しました! 今回も参加者の方に楽しんでもらえる企画として「PHPerあるある」と言うアンケート形式の付箋ボードを用意しました! 付箋ボードには事前に3つのお題を用意してあります。 PHPerあるある PHP系カンファレンスあるある 言語、OS、FWあるある 参加者には好きなお題を選んで頂き、付箋で解答を書いてもらったり、同意する解答が既にあればシールを貼ってもらう形で企画に参加してもらいました。最初企画を用意したときはボードが埋まるか心配だったのですが、当日は想定していたよりも沢山の来場者に参加していただき、企画を考えたBASEスタッフ一同、嬉しく思います! また、企画に参加していただいた来場者にはBASE制のオリジナルノベルティとして、簡単な小物が入る特性の巾着袋と、「BASE」をご利用いただいている COZY COFFEE さんのコーヒーパックを配布しました! 巾着袋に関しては来場者から「かわいい」、「普段から使えそう!」というコメントを頂き、良かったです! 当日見たセッションについて PHP RMは何をする？コア開発者と兼任するメリット fortee.jp PHP8.4でRelease Managerになった Saki Takamach iさんによるコア開発者だからこそ語れる登壇内容で面白かったです! 自分はこの発表を聞く前まではPHPのコア開発者用のSlackがある事や、ベテラン1人と、ルーキ2人の3人体制でリリース体制を行っている事を全く知らなく、思ってた以上に色んな国の方がコミュニケーションを取って開発をされているだなと学びました。 個人的に英語でのコミュニケーションでの謎翻訳の紹介がすごくて笑ってしまったのですが、気になる人は是非、Youtubeでも公開されているのでご覧になってください! www.youtube.com そーだいさんに聞く！コミュニティとともに在るエンジニアの良いキャリアの歩み方 by 大倉 潤也 fortee.jp 個人的にこの発表で印象に残っているワードとして「キャリアアンカーとキャリアドリフト」という言葉があります。キャリアは必ずしも計画通りに進むわけではなく、偶然の出会いや出来事が大きな影響を与えるこという話の中で、そーだいさんは「自分の軸（キャリア・アンカー）」を持つ重要性も強調されてました。その上でカンファレンスで登壇したり、コミュニティに入って社外の方と関係性を持つ事が新しい環境を作り、学びが得られるんだなと話を聞いていて思いました。 speakerdeck.com おわりに 昨年に引き続き今年もスポンサーの協賛を通して PHP コミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました! 登壇された方や、スタッフの方々も業務でお忙しいにも関わらず、多くの時間をカンファレンス準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。 また来年の開催を楽しみにしています! ありがとうございました! BASE は現在エンジニア積極採用中なので興味があれば採用情報もぜひご覧ください! binc.jp

はじめに こんにちは。BASEのDataStrategyチームで機械学習を触っている竹内です。 機械学習といえばLLMやDiffusionモデルなど生成モデルの発展が目覚ましい昨今ですが、その一方で構造化データに対して特徴量エンジニアリングを行い、CVを切って、LightGBMなどの便利な決定木ベースのフレームワークに投げて、できたモデルの出力を吟味し、時には致命的なリークに気付き頭を抱えるといった王道のアプローチは相変わらず現役で、実務に関していえば当分お世話になる機会が減ることはないかなという気がしています。 今回はそういったクラス分類モデルにおける性能の評価指標の1つである、ROC曲線やAUC、PR曲線といった概念について振り返りつつ、実務上しばしば見られる不均衡データに適用する際の注意点などについて、軽いシミュレーションも交えつつ掘り下げてみようと思います。 ROC曲線 2クラス分類器の性能を評価する際によく使用されるツールとしてROC Operating Characteristic)曲線が挙げられます。 ROC曲線は縦軸に再現率(Recall)、横軸に偽陽性率(False Positive Rate)をとり、それぞれの検出閾値に対する再現率、偽陽性率をプロットすることで得られる曲線です。ROC曲線の下側の領域の面積をAUC(Area Under the Curve)と呼び、その面積の大きさによって分類器の性能の高さ、つまりその分類器がどの程度うまく正例と負例を分離できているかを評価することができます。 同じデータセットにおける異なる2つのモデルの性能を比較する際や、再現率と偽陽性率のトレードオフを考慮した適切な閾値を決定する際にROC曲線のプロットは有効な選択肢の1つとなります。 model_1よりmodel_2の方がAUCが高いため、model_2の方が性能が高いと判断できる。 不均衡データにおいてROC曲線を扱う際の注意点 実務において2クラス分類器を適用する例はいろいろありますが、例えば「ある工場の部品生産ラインにおいて、ごく稀に発生する不良品を検知する」といった不良品検知や異常検知、不正検知などの文脈においては、正例に対して負例のサイズが極端に大きい、いわゆる不均衡データを扱うことがしばしばあります。 そうした極端に不均衡なデータにおいては、ROC曲線におけるAUCの指標がうまく機能しないことがあります。 具体的にはROC曲線は適合率(Precision)の指標を含んでいないため、「正しく検出できた正例に対して、巻き込んで検出してしまった負例がどれだけ多いか」という点が考慮されず、結果として非常に多くの偽陽性が発生してしまっていてもAUCは高い値を示してしまうことがあります。 先ほどの工場の不良品検知の例で言えば「AUCの値はほぼ1であるにも関わらず、稼働させてみたら不良品の見逃しは少ないものの、大量の偽陽性が発生してしまうことで、後続の目視チェックの工程をパンクさせてしまう。」といった問題を生じさせてしまう可能性があります。 また、しばしばそうした不均衡データにおいてはある程度の性能であればどのモデルのAUCもほぼ1に近い値を取るようなROC曲線がプロットされてしまい、異なるモデルを比較することが難しいこともあります。 PR曲線 ROC曲線と同様な概念としてしばしば用いられることがあるPR(Precision-Recall)曲線は、縦軸に再現率(Recall)、横軸に適合率(Precision)をとったものです。こちらはROC曲線とは異なり、横軸に適合率を採用しているため「正しく検出できた正例に対して、巻き込んで検出してしまった負例がどれだけ多いか」を反映することができます。 そのため、ROC曲線における高いAUCが観測できていても、データに不均衡性がみられる場合はPR曲線もプロットしてみることでモデルの性能に関する示唆を得られる可能性があります。また、ROC曲線におけるAUCについては差がほとんど見られない2つのモデルの性能を比較する場合においても、PR曲線における改善がみられるケースもあります。 データに不均衡性がみられる場合はROC曲線だけでなくPR曲線のプロットも見ておくと良いかもしれません。 実験 簡単なシミュレーションを行うことで、不均衡データにおけるROC曲線とPR曲線の性質について軽く検証してみます。 まず、正例は平均3、負例は平均1で分散は共に1の正規分布にしたがう特徴量Xもつことを既知とした上で、Xが閾値以上のものを正例、閾値以下のものを負例として分類するモデルを考えます。 その上で、正例のデータは1000件に固定し、負例の方は正例の件数の1倍、10倍、100倍、1000倍の4つのパターンで生成し、このモデルの性能を評価することを考えます。 上図は生成されたデータのヒストグラムであり、負例が多くなると潰れて見えなくなっていますが、正例のデータは4パターンで全て同じものを使用しています。 緑色の点線は閾値を示しており、モデルはこれより右側のものを正例、左側のものを負例として識別することになります。 図では閾値1.5の例を示していますが、ROC曲線やPR曲線をプロットする際はこの緑色の点線を左端から右端へ移動させた際の各指標を計算することになります。 # コード例 import numpy as np import matplotlib.pyplot as plt # 正規分布に従う乱数を生成 ratios = [ 1 , 10 , 100 , 1000 ] sample_size_positives = 1000 positives = np.random.normal( 3 , 1 , sample_size_positives) dataset = {} for r in ratios: sample_size_negatives = sample_size_positives * r negatives = np.random.normal( 0 , 1 , sample_size_negatives) dataset[r] = (sample_size_negatives, positives, negatives) # ratio=1の場合 ratio = 1 _, positives, negatives = dataset[ratio] fig, ax = plt.subplots() ax.hist(positives, bins= 100 , color= "r" , alpha= 0.5 , label= "positives" ) ax.hist(negatives, bins= 100 , color= "b" , alpha= 0.5 , label= "negatives" ) ax.axvline(x=threshold_example, color= "g" , linestyle= "--" , label=f "{threshold_example=}" ) ax.legend(loc= "upper right" ) ax.title.set_text(f "{ratio=}" ) ちなみに、グラフにおける各指標のイメージは以下のようなものとなります。 再現率(Recall) = (点線右側の赤色部分の面積) / (赤色部分全体の面積) 偽陽性率(False Positive Rate) = (点線右側の青色部分の面積) / (青色部分全体の面積) 適合率(Precision) = (点線右側の赤色部分の面積) / {(点線右側の赤色部分の面積) + (点線右側の青色部分の面積)} まず、4つのパターンについて、ROC曲線をプロットしてみます。 ROC曲線はどのパターンについてもほぼ同じで、左上に張り付くような形をとっており、AUCはほぼ1に近い値を取っていることがわかります。つまり、ROC曲線はデータの不均衡性の影響をほぼ反映していないことがわかります。 上図の赤い点はそれぞれの曲線上での閾値1.5における点を示したもの # コード例 # ROC curve threshols = np.linspace(- 5 , 5 , 1000 ) threshold_example = 1.5 fig, ax = plt.subplots() ax.plot([ 0 , 1 ], [ 0 , 1 ], linestyle= "--" , color= "g" , label= "random" ) for i, r in enumerate (ratios): recalls = [] fprs = [] sample_size_negatives, positives, negatives = dataset[r] for j in range ( len (threshols)): recalls.append(np.sum(positives > threshols[j]) / sample_size_positives) fprs.append(np.sum(negatives > threshols[j]) / (sample_size_negatives)) ax.scatter(fprs, recalls, color=plot_colors[i], label=f "ratio={r}" , s= 3 ) # 閾値threshold_exampleの時のrecallとfpr ax.scatter( [np.sum(negatives > threshold_example) / sample_size_negatives], [np.sum(positives > threshold_example) / sample_size_positives], color= "r" , s= 15 ) ax.legend(loc= "lower right" ) plt.xlabel( "FPR" ) plt.ylabel( "Recall" ) 次に4つのパターンについてPR曲線をプロットしてみます。 PR曲線についてはROC曲線とは異なり、4つのパターンそれぞれで全く異なる曲線がプロットされており、ROC曲線と比較してデータの不均衡性の影響を反映しやすいことがわかります。 図の赤い点における同じ閾値1.5で見てみると再現率は全てのパターンで同じ値を取っていますが、適合率においてはデータが不均衡になるにつれて低い値を取ることがわかります。 上図の赤い点はそれぞれの曲線上での閾値1.5における点を示したもの # コード例 # PR curve fig, ax = plt.subplots() for i, r in enumerate (ratios): recalls = [] precisions = [] sample_size_negatives, positives, negatives = dataset[r] for j in range ( len (threshols)): recalls.append(np.sum(positives > threshols[j]) / sample_size_positives) precisions.append(np.sum(positives > threshols[j]) / (np.sum(positives > threshols[j]) + np.sum(negatives > threshols[j]))) ax.scatter(precisions, recalls, color=plot_colors[i], label=f "ratio={r}" , s= 3 ) # 閾値1の時の適合率と再現率 plt.scatter( [np.sum(positives > threshold_example) / (np.sum(positives > threshold_example) + np.sum(negatives > 1.5 ))], [np.sum(positives > threshold_example) / sample_size_positives], color= "r" , s= 15 ) ax.legend(loc= "lower right" ) plt.xlabel( "Precision" ) plt.ylabel( "Recall" ) 最後に 今回は2クラス分類における、データの不均衡性とROC曲線およびPR曲線の関係性について掘り下げてみました。 一般的にはモデルの性能評価にはROC曲線を用いることが多い気がしますが、PR曲線の存在も頭に入れておくと、不均衡なデータを扱う際に役に立つかもしれません。 一応適合率を扱う際の注意点を挙げておくと、検証用データにおける負例が本番のデータからダウンサンプリングされている場合、算出される適合率がそのサンプリング比率に依存してしまう点があります。 例えば負例が本番のデータから1/rの件数だけランダムサンプリングされている場合、実際の適合率へ補正する計算式としては、検証用データにおける偽陽性(False Positives)の件数をN(FP)などとして といった形が考えられます。負例が圧倒的に多いケースでは、状況に応じて分母のN(TP)を0に近似してしまって、検証用データにおける適合率に1/rをかけた値を真の適合率としてしまっても良いかもしれません。 また、実務においては偽陽性や偽陰性の数だけで評価するのではなく、その質や誤分類コストの非対称性などにも注意を払うことが重要です。不良品検知の例でいえば、偽陰性の中に深刻な欠陥を見逃している例がないか、不正決済の検知であれば大きな損害をもたらす決済を見逃している例がないか、といったサンプルごとに異なる誤分類コストについても十分吟味する必要があります。 最後となりますが、DataStragetyチームではBASEにおけるデータ分析基盤の改善を一緒に行っていくメンバーを募集しています。ご興味のある方は気軽にご応募ください！ A-1.Tech_データエンジニア / BASE株式会社 明日のBASEアドベントカレンダーは @h7jin16 さんと @u_hayato13 さんの記事です。お楽しみに！ 参考資料 Wikipedia,Receiver operating characteristic https://en.wikipedia.org/wiki/Receiver_operating_characteristic scikit-learn,precision_recall_curve https://scikit-learn.org/1.5/modules/generated/sklearn.metrics.precision_recall_curve.html Google,Machine Learning Crash Course,roc-and-auc https://developers.google.com/machine-learning/crash-course/classification/roc-and-auc?hl=en

本記事は BASE アドベントカレンダー 2024 の 22 日目の記事です。 はじめに こんにちは！ BASE 株式会社 Pay ID 兼 BASE PRODUCT TEAM BLOG 編集局メンバー の @zan_sakurai です。 今年も残すところあとわずかとなりました。今年も多くの方に BASE PRODUCT TEAM BLOG ご覧いただき、ありがとうございました！ 1 年間 BASE PRODUCT TEAM BLOG 編集局としていろいろな記事のレビューに関わらせていただきました。 この機会に改めて今年の記事を全て読み返したので、せっかくなので、今年の記事を振り返ってみたいと思います。 今年の記事を振り返ってみます 今年の投稿数は残りのアドベントカレンダーを含めると約 70 記事となりそうです。 BASE PRODUCT TEAM BLOG は、2016 年にスタートしていますが、 投稿数としては 2019 年の 93, 2021 年の 87 に次ぐ、3 番目に投稿数の多い年となりそうです。 有り難いことに執筆いただける方も増えており、技術に限らない、プロダクトマネジメント、マネジメント、採用、イベントレポートなど、幅広いジャンルの記事をお届けできたかと思います 今年の第一号は？ 今年の記事は、竹本さんの YAPC:Hiroshima 2024 に参加しました から始まりました。 弊社 CTO の川口さんのスポンサー LT をはじめ、印象に残ったセッションをご紹介いただいており、幸先の良いスタートとなりました。 今年特にはてなブックマークをいただいた記事 今年特にはてなブックマークを頂いた上位 3 記事は以下となりました。 技術に限らない幅広いジャンルの記事をお届けした 1 年でしたが、特にはてなブックマークをいただいた記事は技術系の記事でした。 とてもわかりやすい記事ですので、まだお読みになっていない方はぜひご覧ください！ explain だけじゃわからない！MySQL の index の考え方 OIDC って何なんだー？から、実際に使うまで AWS の DMS やブルー/グリーンデプロイを使って MySQL8.0 へ移行した話 イベントレポート・スポンサー・登壇に関する記事が多かった イベントレポート・スポンサー・登壇に関する記事が多かったように見受けられました。 さまざまなイベントに参加し、登壇やスポンサーをさせていただいたかと思います。 余談ですが、投稿いただいた記事以外にも社内での技術交流イベントもこれまで以上に活発に行われていたように感じた１年でした！ Fullstack AI Dev & Raycast Summit にスポンサーしました！ 社内 LT 会で半年間、毎月登壇をし続けた話 〜実際の登壇内容も添えて〜 BASE BANK, 中小規模のエンジニアイベントにも会場&飲食スポンサーします！ Welcome Fintech Community #2 〜Fintech ドメインを深掘る LT 会〜を開催しました！ Welcome Fintech Community #1 を開催しました！ スクラムフェス大阪 2024 で BASE BANK のメンバーが 2 名登壇しました! PHP カンファレンス福岡 2024 に BASE BANK のエンジニアが登壇しました AWS Summit Japan 2024 に参加しました PHP カンファレンス小田原 2024 に BASE のエンジニアが登壇しました Object-Oriented Conference 2024 に参加しました PHPerKaigi 2024 に 2 名のメンバーが登壇しました PHP カンファレンス関西 2024 にコアスタッフとして参加しました YAPC:Hiroshima 2024 に参加しました 最後に ここでは紹介しきれないくらい多くの記事がありますので、まだお読みになっていない方はぜひ読んでいただきたいです...!!! 今年も多くの方にご愛読いただき、誠にありがとうございました。 また、来年も引き続き多くの方に読んでいただけるよう、記事の品質向上に努めてまいりますので、引き続きよろしくお願いいたします！ また、BASE は現在エンジニア積極採用中なので興味があれば採用情報ぜひご覧ください！ binc.jp 次回は kikuchi1201 さんの「PHP カンファレンス 2024 のスポンサーしました」が公開予定です。お楽しみに！

この投稿は BASEアドベントカレンダー2024 の21日目の記事です。 はじめに SRE Group でエンジニア？をしている@basemsです。 まだ入社して5ヶ月の若輩者です。 「エンジニア？」 という表現は、私の現状は技術そのものではなくチーム運営だったり業務改善といった方向に注力しているので、まだ 「BASEのエンジニアです！」 と自信を持って名乗る程ではないという心理の表れです。 本記事はエンジニアとしてというより、過去の経験からくるプロジェクトマネジメントの面が強い内容になっております。 この記事って何 私自身、BASE以前に何社か渡り歩いていますが、 PJ進行においてエンジニアと非エンジニア間の軋轢だったり衝突は大なり小なり発生しない方が稀 だと感じています。（部署の違うエンジニア間でもあったりする） が、その改善方法や心構えのブログ記事とかはネット上に存在はしてますが、体系立てて学ぶような研修やレクチャーといったものをやる会社はあまり聞かず、PMは元より関わるメンバーそれぞれが 実際に経験して身につけていってねといった傾向がある と感じています。 そこで「自身の頭の中を整理の為にアウトプットする」目的も兼ねて、まずは エンジニアと非エンジニアで同じ方向を向いてPJ進行する為の心構え 的な事を記事にしようと思った次第です。 堅苦しいタイトルになっていますが、 「この辺りを意識してお互い会話してみようよ」 といった内容なので、気軽に読んでいただけると嬉しいです。 当記事の内容は私の経験則なので、当然ながら異論・反論はあるものだと思います。 私自身がエンジニアなので逆の立場からすると 「いや、それは違うだろ」 といったご意見はあって然るべきだと思いますが、 それらをぶつけて改善し後進の為の教材作りができればいいな的に考えていますので歓迎します！ (なのでタイトルも 仮 をつけています) ※ちなみに当記事の非エンジニアという括りは、だいたいディレクターやPM・PDMといった方を指しています。 役割が違うだけで上下はないという気持ち まずはざっくりと心構えの話です。 エンジニアと非エンジニア（ディレクターやPM・PDM）の関係性は会社によって違いがあるかと思いますが、上手くいっていないパターンは大体以下のどっちかだと感じます。 エンジニアが強過ぎて、非エンジニアが物申しづらい 非エンジニアが強過ぎて、エンジニアは従わざるを得ない 完全なパワーバランスというのは理想論だと思いますが、それでも 「役割が違うだけで対等な立場である」 という事を今一度心に留めましょう！ 相手の意見や要望を”頭から”否定しない 「相手の意見を”頭から”否定しない」 ブレストなんかでは基本ルールだったりしますが、PJ進行においても心がけても良い事だと思います。 “頭から”というのは、まぁ無理なものは無理という状況は現実としてあり得るのですが、 その決断を出す前に 相手がその意見・要望を出した背景や根拠をはっきりしましょう・させましょう！ 突っぱねたくなる無茶振りされた経験は大抵誰でもあるかと思います。 それに対して、 「期限的にムリだからできません」 「決まっている事だからやってください・間に合わせてください」 というスタンスだと意地の張り合いみたいな状況になってしまいますが、お互いの置かれている背景を知る事で何らかの糸口なりアプローチが見えてきたり、 エンジニア・非エンジニアというそれぞれの役割の中だけでは得られなかった、思わぬ気付きがあったりします。 すでに今までの経験で「言ってもダメだろう」的な諦めが入っている方もいるかもしれませんが、 こちらも前項と同じく改めて心に留めてみてください！ やることの具体化と明確化 ここまでは心構えの話でしたが、ここからは具体的な進行の話です。 身も蓋もない言い方をするなら、プロジェクト進行は無期限じゃないのが普通な以上、 100%の理想を追いつつ関係者全員が飲み込める落とし所を見つける事の繰り返し だと思っています。 その為に 「やることの具体化と明確化」 という、 絶対に達成するべきライン(PJでやる事)をはっきりさせて意志統一をする 作業を行います。 エレベーターピッチがあれば、それを要件定義できるように要素を分解していくイメージです。 記事のテーマに沿って役割別の観点を加えるなら、 非エンジニア：PJをやる意義・やりたい事の具体化と明確化 エンジニア：やる事の輪郭（規模感）を掴む、実現性の「あたり」をつける こういった感じでしょうか。 これはエンジニア・非エンジニア問わず関係者全員が協力してやる事が重要で、 どちらかの観点がないと、大なり小なり 「顧客が本当に必要だったもの」 という有名なあのパターンにハマります。 はじめの一歩：最初に整理するべき項目 整理する項目をあげていきます。 誰が（発案か） 誰の為に 何をやりたいか(させたいか) いつまでに 何を（会社）得られるのか これらはPMやPDM・ディレクターの方は理解しているとは思いますが、 エンジニア側が知る事で、より良い要件定義や設計ができるはずです。 （断言） 項目毎に説明してきます [誰が（発案か）] プロジェクトの発端が 「誰・どこ」から出てきたものか を明確にします 。 この「誰・どこが」によって、他の情報が持つ意味合いが変わってくる事もあります。 「いつまでに」 という項目も、身も蓋も無い言い例を挙げると 不特定多数のユーザーからの要望　→ 　 背景を確認しつつ、なるはやで進めるべき 重要クライアント　→ 　 期限は動かせない前提で考える 社内発案の施策　→ ある程度の調整はききそう と、この様に温度感が変わってきますし、エンジニアの考え方・動き方も相応に変わるはずです。 （あくまで例なので、社内発案の施策が常に温度感高くないとかじゃ無いです！） また、ここで 「要件や仕様の承認あるいは最終判断をできるのは誰か」 もはっきりしておきましょう。 プロジェクトに対して誰と誰が裁量を持っているかを全員が知る事で、エンジニア・非エンジニアだけでなく部署間の連携もやりやすくなるはずです。 ※プロジェクトの責任の所在がどうこうでは無いので注意 [誰の為に] このプロジェクトのターゲットをはっきりさせましょう + それを可能な限り詳細に掘り下げましょう。 例えば「ショップオーナーさん」をターゲットにしたBASEの新しい機能の提供を考えるとします。 単なる「ショップオーナーさん」だけでは不十分 で、そこから 既存機能を使い慣れている人向け 新規に開設する人にも積極的に使ってもらいたい このどちらであるかを明確にする事で、考慮するべき内容 （エンジニア視点だと特にUI、UX) は大きく変わるはずです。 特に b の要素があるのに取りこぼすと 本当に使ってもらいたい人に使ってもらえないという悲しい結果になります。 [何をやりたいか(させたいか)] 今回のプロジェクトで 達成したい事・ターゲットに何を提供したいかを明確にして、関係者全員の認識を合わせましょう。 そして、それを実現する為に何が必要かを詰めていきましょう。 エンジニアは漠然と 今の手持ち（開発環境やシステム・インフラ等々）での実現性を考えます。 足りない要素があれば整理し、必要であれば課題提起しておきましょう。 （新規か改修か？ 社外が絡む要素はあるか？ 人以外のコストが発生するのか？ 等々・・・） 例えば「AIを使って何かやりたい」という要望があったりしますが、 「そのAIはどこから持ってくるの？」とか「AIに学習させるデータや素材は？」とかが白紙だったりするので、 エンジニアはそういった点を提起しプロジェクトの課題として明確にします。 非エンジニアの方は、こういったエンジニアの指摘は細かいなぁと思われるかもしれませんが、 プロジェクト完遂の為に避けて通れない課題を早めに把握しておく為 と思ってお付き合いください。 [いつまでに] 具体的な日程だけではなく、 その性質をはっきりさせましょう。 ざっと思いつくレベルですが、以下は明確にしておくべきだと思います。 絶対にずらせない or 調整が効くのか 絶対にずらせない場合は、その理由 社外との連携はあるのか 間に合わない場合にどういう不利益を被るのか エンジニア視点だと、前項までの情報から明らかにスケジュールに無理があると判断できるパターンがあったりするかと思います。 そういった時は 非エンジニアの方にも無理な要因を理解してもらい、共通認識を持ってもらう必要があります。 私の場合ですが、以下のように3つの方針で情報整理しています。 プロジェクトを100%達成し、かつスケジュールに収める為に必要な事 お金とか増員とかでなんとかなるならという前提 お金はともかく、 人を”いきなり”倍に増やしても工期は半分にはならない ( 重要) 無理なら無理な理由を徹底的に整理する プロジェクトの100%達成を優先する場合に、絶対必要なスケジュール スケジュールに収める事を優先する場合に、犠牲にしなければならない事（要件や機能） PMの領域に踏み込んでる気もしますが、実装の規模感を知っているのはエンジニアだと思うので、この辺りは PMと協力して考えてみるべきだと思います。 [それにより何を（会社が）得られるのか] 売上だったりユーザー獲得だったりといった、 このプロジェクトが成功すると何を得られるのかをはっきりさせましょう。 直接的な利益ではなくとも サービスの安定性・信頼性の向上も得られるもの として捉えます。 エンジニア視点ではこの要素も重要で、 特に設計においては一つの指標となります。 ユーザーの獲得が目的なのに、スケジュールの都合で 快適性を損なうUIやUXで実装したり 、 売上が出ることを見込めたとしても、 それを帳消しにするようなランニングコストが発生します というのは本末転倒です。 プロジェクトの成果がどう出るのかは全員のモチベーションとなると思うので、これも認識を合わせておきましょう。 おわりに 長々と書いてきましたが、この内容はスタートラインです！ 書ける事はまだまだあるので、機会があれば続きを書ければ良いなぁと思っています。 BASEでは幅広い職種で新しいメンバーを募集しております。 興味持たれた方は、カジュアル面談からでもぜひご応募ください！ 採用情報 | BASE, Inc. - BASE, Inc. 明日は @zan_sakurai さんの記事です！ お楽しみに！