Feature Dev 3 Group にて Web アプリケーションエンジニア / プロジェクトマネージャーをしている kumar です。 本記事では、 Pay ID アプリの運用状況を可視化するページ を開発するにあたり、チーム運営やプロジェクトマネジメントの観点で行った取り組みとその成果についてご紹介します。 プロジェクトを円滑に進めるには、設計や実装そのものだけでなく、「チームがどう動くか」「どう学び合うか」といったプロセス設計も重要だと考えています。 今回は特に意識した3つの取り組み 「専門領域の越境・自走を促す情報設計・心理的安全性の構築」 についてお話しします。 フロントエンド、バックエンドの垣根を越えた開発体制 フルスタック的な動きができるチームには、メンバー依存によるボトルネックの解消や技術視点の共有がしやすくなるといったメリットがあります。 今回のプロジェクトでは、メンバー全員がフロントエンドとバックエンドの両方を担当できるようにするという事にチャレンジをしました。 メンバーは以前から専門領域を広げたいという意欲を持っていましたが、学習コストやペアプログラミングにかかる時間的負担を考慮し、プロジェクトの進行を優先せざるを得ませんでした。 しかし今回、AIツールの活用によってこれが実現可能となりました。 コード補完や技術解説、リファレンスの探索支援などにより、学習の初動コストが大きく下がり、必要最低限のペアプロだけでキャッチアップが可能になりました。 結果として、チームには 「専門外でも、まずは自分でトライしてみる」という意識が根付き、技術領域をまたいだ会話も活発化しました。 お互いの理解が深まったことで、役割に縛られないスムーズな連携が生まれました。 レトロでのメンバーの感想抜粋 Notion の活用で効率的に自走できるチームに 開発スピードを上げるには、メンバーが迷わず動ける状態をどう作るかが重要です。 今回のプロジェクトでは、情報の集約と構造化を担う仕組みとして Notion を積極的に活用しました。 具体的に何をしたか スプリント単位のタスクボードを整備 プロジェクト内外で発生する各会議体に沿った議事録とドキュメントの整備 相談の粒度を画一化できるようなテンプレートの用意 必要な情報に誰もが自由にアクセス・活用できる環境を整えたことで、メンバーは迷うことなく効率的にタスクを進められるようになりました。 これにより、チーム内の情報の透明性が高まり、認識のズレや手戻りを最小限に抑えつつ、各メンバーが自律的に動ける状態を実現できました。 結果として、 タスクの遂行スピードが向上し、チーム全体の開発効率の底上げ につながりました。 相談内容を整理してから相談できるテンプレート 心理的安全性を育む「密な連携」の仕組み プロジェクトとしては、デイリー・レビュー・レトロスペクティブなどの形式的なイベントを設けていましたが、本質的に重要なのは「本音で話せる空気」と「安心して意見を交わせる関係性」だと考えています。 こうした心理的安全性が、チームの連携やスピード、そして最終的な成果に大きく影響すると実感しています。 今回のプロジェクトでは、チーム内のコミュニケーションをより密にし、安心して相談・共有できる状態をつくるため、以下のような工夫を取り入れました。 具体的に何をしたか 仕様確認や相談には、可能な範囲で即レスを意識する(スタンプなどのリアクションでもOK) レトロに加えて、メンバー同士で感謝を伝え合う Win Session を設置 デイリー後に、必要に応じて気軽に集まれる「相談タイム」を設置 中でも相談タイムは特に好評で、「ちょっと話せる場」があるだけで、相談のタイミングが早まり、共有のスピードも上がるといった効果が見られました。 こうした取り組みは、小さな工夫の積み重ねではありますが、結果として チーム全体の心理的安全性の向上と、開発スピードの加速につながった と感じています。 レトロでのメンバーの感想抜粋 おわりに 今回のプロジェクトを通して感じたのは、プロジェクトマネージャーの役割はプロジェクトの「調整役」ではなく、チームが自律的に動けるための「環境づくり」だということです。 領域の垣根をなくしてメンバー依存のボトルネックを減らす ドキュメントを整えて自律的に動けるようにする 心理的な安心感と連携の密度を高める こうした工夫を積み重ねることで、チームに自走する文化が生まれ、結果としてより円滑な開発環境の構築が実現できました。 現在、BASEではこうした価値観を共有し、より良いチームづくりや開発体験向上に取り組んでくれる仲間を募集しています。 もし、少しでも興味を持っていただけた方がいれば、ぜひ採用情報をご覧ください。 binc.jp 今後も、プロジェクトを通じて得た知見を発信していきます。最後までお読みいただき、ありがとうございました！

Product Development Division の大塚です。 BASEは2025年6月28日(土)に開催されるPHP Conference Japan 2025にゴールドスポンサーとして協賛します。 PHP Conference Japan 2025について PHP Conference Japanは、PHPエンジニアのためのカンファレンスとして毎年開催されている日本最大級のPHPカンファレンスです。今年は6月28日(土)に大田区産業プラザPiOで開催されます。 夏の暑い時期に開催されるのは久しぶりらしいです！ スポンサーブースについて カンファレンス期間中、スポンサーブースを出展しています。 ブースでは「教えて！PHPerの皆さん！」をテーマに、PHPの活用事例やみなさんの経験談を付箋に書いていただき、共有ボードに掲示する参加型の企画を実施します。 企画にご参加いただいた方には、BASEをご利用中のショップ様のコーヒーパックをプレゼントいたします！ 皆さまのご参加をお待ちしています！ セッションの紹介 今年はBASEで活躍している2名のメンバーが登壇予定です。 設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち by プログラミングをするパンダ 15:25〜 トラック4 - 4F コンベンションホール 鶯 レギュラートーク(25分) fortee.jp FrankenPHPでLaravelを動かしてみよう by Capi(かぴ) 16:55〜 トラック1 - 1F 大展示 LT(5分) fortee.jp おわりに 6月ですがすでに真夏の気温になってますね。。。 楽しむためにも適度な水分補給を心がけましょう！ PHP Conference Japan 2025でみなさまにお会いできることを楽しみにしています！ BASEはカンファレンスやイベントへの参加や登壇を積極的に支援しています。 もしご興味がありましたら、採用情報もご確認いただけると幸いです。 binc.jp

はじめに こんにちは、 BASE Feature Dev1 Group で PHPer をしている @meihei です。 PHPカンファレンス新潟2025、お疲れさまでした！私は個人としてコアスタッフとして参加させていただきました。 今回参加した PHPカンファレンス新潟では、私の所属する BASE 株式会社はスポンサー企業ではありませんでした。ただ、私がスタッフとして活動することについて会社から理解と配慮をもらっていたこともあり、結果としてそのサポートがコミュニティへの貢献につながったと感じています。 この記事では、そうしたコアスタッフとしての体験を通じて、「スポンサーという形だけが企業のコミュニティへの貢献ではない」という気づきについて書いてみたいと思います。 PHPカンファレンス新潟2025 「繋がる楽しさを、新潟で。」のキャッチコピーのもと、新潟で初めて開催されたPHPカンファレンスです。 phpcon.niigata.jp このカンファレンスは、ボランティアスタッフによって主催・運営されていて、コアスタッフは2024年から開催のために準備をしておりました。 コアスタッフとは、スタッフを当日スタッフとコアスタッフの２種類に分けた時の名称で、当日の運営に関わるだけではなく、事前の企画立案から関わるスタッフのことです。 詳しくは長谷川さんの発表「カンファレンスのつくりかた」をご参考ください。 speakerdeck.com 自分はこのコアスタッフとしてPHPカンファレンス新潟2025の運営に関わりました。 コアスタッフのお仕事 自分のスタッフ業務としては、プログラムの設計や、スピーカーとのコンタクト、様々なコンテンツの企画を担当していました。 プログラムの設計 プロポーザルの募集、採択基準の策定、採択基準をもとに選考、タイムテーブルの作成、Ask the Speaker の配置、トークフィードバックの作成などをしました。 採択基準やタイムテーブルの作成では、PHPカンファレンス新潟の色が出るように実行委員長の意見をできるだけ入れて、現実的に実現可能なものとなるように調整して、今の形となりました。 スピーカーとのコンタクト 採択・非採択の通知、事前情報の共有、スピーカーからの質問への返信、トークフィードバックの送信など、スピーカーとの連絡をしました。 様々なコンテンツの企画 自己紹介コンテンツ、パネルディスカッション、上級者向けLTというコンテンツの企画を行っていました。 「PHPer が集まる空間の楽しさとPHPer の凄みを浴びてほしい」と「新潟の楽しさと魅力を全国から集まる皆様に知ってほしい」のコアバリューを参加者に提供するために、企画を考えました。 中でも自己紹介コンテンツはかなり好評でした。 会社からの理解 さて、フルタイムの会社員として働きながら、技術コミュニティのコアスタッフとしても活動するのは、想像以上に大変なことです。実際、会社員としての労働時間＋スタッフ業務の作業時間で１日の半分以上を占める日もありました。 さらに、一般的にコアスタッフの役割には、スピーカー、スポンサー、業者、会場担当者といった外部関係者との連絡対応が含まれます。これらの連絡は多くが日中に届き、迅速な対応が求められます。しかし、フルタイム勤務の中でそれらに応じるのは決して容易ではありません。 それでも私がコアスタッフとしての活動を続けられているのは、会社からの理解があるからです。 まず、BASE株式会社はこれまで技術コミュニティの恩恵を受けてきた背景があり、その発展に対する貢献として、カンファレンスへの協賛という形でサポートを続けてきました（今年は PHP 関連だけでも 4 件の協賛実績があります）。 また、BASE には「自分で考えて意思決定する」文化があります。与えられた仕事をこなすだけでなく、自ら課題を見つけて優先順位をつけ、必要だと判断したことに主体的に取り組む姿勢が求められています。その文化があるからこそ、私はプロダクト開発という主務にとどまらず、コミュニティ活動にも自分の意思で関わることができています。 もちろん、前提として本業でしっかりと成果を出していることは欠かせませんが、そのうえで、業務時間の調整や判断を任される環境があることで、業務外活動に対してもリソースを割くことが可能になっています。 なぜこのブログを公開するか カンファレンス運営には、多くの“陰の功労者”が存在します。私もその一人であり、私を支えている BASE もそうです。 BASE は今回のスポンサー企業ではないため、参加者がその名前を目にする機会はほとんどありませんでした。 そしてまた、私だけでなく、他のスタッフも本業やプライベートの時間を割いてボランティアとして活動しています。そしてそれはPHPカンファレンス新潟に限らず、その他のカンファレンスや技術コミュニティにも、同じように陰で支えている仲間たちがいます。 こうした活動が続けられるのは、企業の理解と後押しがあってこそです。裏方に立つスタッフを信頼し、支えてくれる会社の存在が、イベントの土台を支えています。そうした企業が増えることで、コミュニティはより持続的に、健全に発展していけると私は思います。 最後にこのブログで伝えたいのは、「ロゴが出ていなくても、確かにこのイベントを支えている会社があるよ！」ということです。 裏方で活動する社員を支えることは、企業として堂々と発信していい価値ある貢献です。そうした支援があって初めて、私たちのようなスタッフは安心してその役割を果たすことができるのです。 おわりに カンファレンスの成功は、参加者・スピーカー・スポンサー・スタッフ、誰か一人でも欠けていたら成し得ませんでした。表舞台に立つ人だけでなく、裏方として支えてくれたすべての人たちに、心からの感謝を伝えたいです。本当にありがとうございました。 そして今週末には、BASE で活躍されている 02 さんが実行委員長を務める PHP Conference Japan 2025 も控えています。実行委員長という立場は、コアスタッフの業務以上に多くの責任と調整が求められます。私たち BASE のメンバー一同、その成功を心より応援しています！ devblog.thebase.in BASEでは、エンジニアのコミュニティ活動も積極的に応援しています。ご興味を持っていただけた方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに Cartチームでバックエンドエンジニアをしている、かがの（ @ykagano ）です。 6/13(金)にBASE社内で第1回となるAI勉強会が開催されました。 10分間のLTが2つ行われまして、私はLTの1つを下記タイトルで発表しました。 「Copilot Agentを普段使いしてわかった、バックエンド開発で使えるTips」 発表内容の前にBASEでのAIの利用状況と取り組みについて簡単にお話ししたいと思います。 AIの利用状況と取り組み BASEでは開発する際のAIとしてCopilotを使用しています。 Copilot自体は以前から社内で使っていましたが、CopilotのAgent Modeは比較的最近使い始めたものとなります。 Copilotを含めた、AIの社内での活用を推進するために、BASEでは AIサポーターズ という取り組みを行っています。 AIサポーターズは、BASEが利用できるAIの社内活用を促進し、クリエイティブタイムの創出を目的に活動するチームです。 私が所属する Product Division でも活動を行っていまして、私もメンバーの一人となります。 AIサポーターズでは以下のような活動を行っています。 AIプロンプトのレシピ集を作る Chat GPTsでデータベース検索クエリを自動生成できるようにする Copilotの利用を推進し、より開発生産性が上がるようにする こうしたAIサポーターズの活動の一環として、普段からCopilot Agent Modeを使用していたため、今回バックエンド開発のTipsを紹介させていただきました。 発表内容 私の発表内容については下記スライドをご覧ください。 speakerdeck.com AI勉強会はMeetを利用したオンライン開催で、社内から30名ほどが参加していただけました。 発表では、主に私がCopilotをどう使っているかを話させていただきました。 またCustom Instructionsを使ったコーディングとユニットテストについて例を上げて説明しました。 発表の最後に現在backendリポジトリのCustom Instructionsを使っている方の挙手をお願いしたところ、一人だけ挙手いただけました。 参加者に後で聞いてみたところ、Custom Instructions自体を使っていなかったり、自分用のCustom Instructionsを育てている方もいるなど利用状況が異なっているようでした。 今後はリポジトリのCustom Instructionsも利用を広げていければと思います。 発表後に質問の時間が設けられており、「普段の開発にPHPStormを使っているのはなぜですか」と質問をいただきました。 回答としては、私がIntelliJ製品を使った開発に慣れていることと、PHPStormでもCopilotが使えるので並行作業するスタイルが自身に合っていたものとなります。 また参加者アンケートでは多くの方に回答いただき、ポジティブな反応をいただけたので良かったです。 Custom Instructionsについての補足 以前より、社内向けに「CopilotのCustom Instructionsの検証についてご協力のお願い」というページを作成して周知を行っています。 そのため、今回の発表はその内容をより広く周知する目的もありました。 社内向けに周知した内容は以下となります。 現在、リポジトリに配置しているCustom Instructionsは比較的汎用的な内容になっています。 そのため、Copilotにもっとこう書いてほしいといった内容がありましたら、Custom Instructionsファイルの更新PRをお願いします。 また別の名前のCustom Instructionsファイルも追加していただいて構いません（自分の使っているモジュールで使う用のファイルなど）。 自分たちしか使わないCustom Instructionsファイルであってもリポジトリに追加いただけると、他の方はこう書いているのかと知ることができ、より良い書き方を取り入れられるため助かります。 .github 配下の Custom Instructions ファイル .github ├── copilot-instructions.md // プロジェクト構成を与える指示書 └── instructions ├── coding.instructions.md // コーディング用指示書 ├── unittest.instructions.md // 単体テスト用指示書 └── codereview.instructions.md // コードレビュー用指示書 おわりに 今回、AI勉強会は第1回目の開催でしたが、2回目の開催も予定しています。 LTも毎回色んな方の話が聞けると思います。 このようにBASEでは、AIの活用を推進しています。 ご興味がありましたら採用情報をぜひご覧ください。 binc.jp

はじめに BASE FeatureDev3Group でWebアプリケーションエンジニア をしている Capi(かぴ) @ysssssss98 です。今回はBASEにプロダクトエンジニアとして入社される方向けに社内で用意しているプロダクトエンジニア向けオンボーディング改善の取り組みについて紹介します。 BASEでオンボーディング資料をどんなふうに運用しているのかを紹介することはもちろん「オンボーディング資料を作ったがどう改善していけば良いか悩んでいる方」や「オンボーディングの改善が行われず、形骸化してしまった方」へ何か1つでも参考になる情報を提供できたら幸いです。 前提 BASEでは以前からオンボーディングの改善を行っており新メンバーの受け入れ基盤を作ってきました。過去のブログでも紹介しています。 自分の役割は一度完成したオンボーディングの土台を運用し、利便性を向上させることです。 これまでのオンボーディングの課題 1. 資料が十分に整理されておらず情報過多になっていた すでにBASE社内で使っているナレッジ共有ツールにはたくさんのドキュメントがありました。 そのドキュメントの中から見ておいた方が良いものをピックアップしてつくられたのが最初のオンボーディングシートです。 膨大なドキュメントの中から選んだため内容が重複しているもの、不要なものも含まれていました。そのためオンボーディングシート運用初期は「情報が多いのはありがたいけれど似た情報が多くどれが正しいのかわからなくなってしまう」という意見が多くありました。 2. オンボーディング内容に差が出る 先ほど話した通り、オンボーディングシートにある情報が膨大です。そのため新入社員のメンターになる方が一度オンボーディングシートの情報を取捨選択する必要がありました。「オンボーディングシートだけ見ればそれで十分」という状態でなかったのです。 この取捨選択の時間がもったいないというのもありますが、今の状態ですとメンターが知っている情報量によってオンボーディングに差が生まれてしまうことがあります。わかりやすい資料をすでに知ってるメンターは簡単に説明できるが、知らないメンターは説明のために一から新しく資料を作ったり情報を探す事象が発生します。これは非常にもったいないです。 3. 社歴の長い人以外もメンターできるようにしたい これは顕在化した課題というより自分が予想した仮説です。 メンターのスキルにオンボーディングが依存してしまうとメンターが上手な人はずっとメンター業務をすることになります。これは他のメンバーがメンターに挑戦する機会を奪い、学習機会の損失になると思います。 今はまだ顕在化していないですが、これを事前に防止したいと自分は考えました。 上記課題を解決するため改善作業を行いました。 どんな改善作業をしたのか 1. ヒアリングの実施 実際にオンボーディングを実施した新入社員や新入社員のメンターはもちろん、マネージャー陣の方にも現オンボーディングの良いところ、改善点をヒアリングしました。 マネージャー陣へのヒアリングでは「どんなオンボーディングをしたいのか」、「オンボーディング後、新入社員がどんな状態になっているべきか」というオンボーディングの目指す方向性についてすり合わせることが多かったです。 方向性が定まらないとどんな情報をオンボーディングで新入社員へ提供するべきか判断に困ったため です。闇雲に情報を増やしたり減らすことを防ぐ目的もあります。 オンボーディングの目的についてヒアリングした時の議事録(一部) 新入社員と新入社員メンターへのヒアリングでは「オンボーディングの良い部分」、「オンボーディングをしていてつまずいたところ」、「メンターとしてオンボーディングを進めていて困ったこと、わかりにくかったところ」など オンボーディングシートを使ってみた正直な感想 を聞きました。 ヒアリングの実施頻度や所用時間は特に定めず、週一、隔週、月一実施のいずれかで1回15~30分で実施していました。 オンボーディング改善ヒアリングの協力依頼をした時のSlack 2. 不要項目の検討と削除 「極力コンテンツは増やさない。整理に力を入れる」 これを徹底しました。ヒアリングをそのまま鵜呑みにしたり「これも必要あれも必要」と考えるとコンテンツは無限に増やせます。情報が多いに越したことはないでしょう。しかしオンボーディングは新入社員さんが素早く活躍できる後押しをすることが目的です。一度に覚えることが多いと新入社員は大変です。最低限の情報でBASEのプロダクトエンジニアの定常業務を体験することに注力しました。 システム開発と一緒ですが、一度作ったらメンテナンスが始まります。運用コストを削減するためにもコンテンツを追加することよりも無駄なコンテンツを削除することを意識しました。 使いづらいものを作り続けることが1番もったいないです。ヒアリングで得た周りの意見を取り入れつつ自分が不要と判断したものは周りと相談し、可能であれば削除していきましょう。 3. 各オンボーディングのゴール記載、補足情報の追記 オンボーディングシートのいくつかはリンクを貼ってるだけのものがありました。 メンターをしている方から「リンクを貼ってあるのでこれをやれば良いと認識してるけれどこれを説明すれば良いの？シート読むだけならURLを共有すれば良いだけでいいのでは？」とご指摘受けました。エンジニア全員がオンボーディングにわざわざ多くの工数を割いていません。このご指摘はその通りです。 なので全ての項目にゴールを設けました。また、ゴールを達成できるのであれば方法は問わないという事前説明資料や参考にすると良い資料をまとめました。 全て既存資料で構成し、新しく資料は作りませんでした 。 メンター向け事前説明資料(一部) ゴールや補足情報の記載例です。 これで各項目の完了条件がわかります。自分のもとへ届く「何すれば良いの？」という質問は減りました。 4. オンボーディング改善担当者もメンターを経験する ドッグフーディングです。システム開発と一緒です。人に使ってもらうだけでなく自分も使いましょう。実際に使ってみると使いづらさを感じる機会が多かったです。利用者を意識した改善ができるようになりました。 自分がメンターしながら書いていたメモ 当事者になることでより良いものができると考えているのでオンボーディング改善担当者がオンボーディング実施者になることを強くオススメします。 5. メンター担当とオンボーディング改善担当、どちらも誰でもできる体制を作る メンターを引き受けてくださる方向けとオンボーディング改善を引き継いてくださる方向けの説明会資料を作成しました。 メンター向け説明資料のテンプレート オンボーディング改善担当者向け引き継ぎ資料テンプレート 最低限の情報をテンプレには記載し、質疑応答で不足を補う形にしています。まだ運用して日が浅いですがメンター向け事前説明資料は好評です。 改善の成果 1. オンボーディング改善担当へオンボーディングに関する問い合わせが減った 「オンボーディングにこれって必要ですか？必要じゃないですか？」や「資料のリンクってこれであっていますか？」という質問がほとんど来なくなりました。新入社員からもメンターからもです。 各オンボーディングタスクにゴールが明確に書いてあること は通常業務が忙しいメンターさんから非常に好評でした。 2. 誰でもメンターになれる環境ができた オンボーディング進行で困った時に使う補足資料を用意したのでオンボーディングの質に差がなくなりました。 そして社歴の長い方だけでなく社歴の浅い方もメンターができるようになりました。実際、入社半年でメンターを担当しオンボーディングを完了させた事例もあります。久しぶりにメンターをする方にも事前説明資料を共有することで安心してメンターを担当していただくこともできました。 メンター事前説明資料を共有した時のやりとり 3. 今後も改善を継続できる環境ができた オンボーディング改善者へのテンプレも作成したことで今後自分以外でも改善作業がいつでも再開できるようになりました。 個人的な感想 課題を見つけて自分なりの方法で解決していくのは楽しかったです。また、プロダクト開発と組織改善は対象が違えど似ていて応用できる部分があるなと思いました。 開発で培った経験を他に応用する能力は他でも活かせるはずなので今後も社内のいろんなことに首を突っ込んで挑戦していきます。 おわりに 今後もオンボーディング改善を続け、新入社員がすぐ新しい環境に慣れ活躍できるような環境を整えていきます。 また、BASEでは現在エンジニアを採用中です。エンジニアとして機能開発するのはもちろん、開発で培った知識や経験を組織改善に応用することに興味をお持ちの方は是非ご応募ください。 binc.jp

はじめに 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