はじめに BASE の ProductDev でエンジニアをしているTorataです。 2025年6月28日（土）に開催された「PHP Conference Japan 2025」にBASEのエンジニアが登壇 & ゴールドスポンサーとして協賛したのでその様子をお届けします！ ちなみに今年は例年とは違いホットな夏開催でした！ BASEのスポンサーブースの紹介について 先日のブログ でも紹介した通りBASEのスポンサーブースでは「教えて！PHPerの皆さん」というテーマでのアンケート形式の企画を実施しました！ アンケートは3つのお題を用意しました PHPで成功した事 or 苦労した事を教えて！ AIツールをどのように活用しているか教えて！ お気に入りの関数 or フレームワーク教えて！ また、アンケートに答えてもらった or 気に入ったものにシールを貼ってくれた人には BASE でもショップを開設されている COZY COFEE さんのコーヒーパックを配布しました このショップさんはいつも季節に合わせたブレンドを作ってくれる素敵なショップさんなので気になる方はショップ覗いてみてください！！ 当日は想定していたよりもたくさんの方にアンケートに答えていただき、アンケートボードも埋まるくらいの大盛況でした。 中でもAIに関する質問には回答が集中していて、AIブームの盛り上がりを感じることができました！ 登壇の紹介 Capi ( @ysssssss98 ) BASEでWebアプリケーションエンジニアをしているCapi(かぴ)です。 今回は趣味で触ってる FrankenPHP を使いWebアプリケーションを動かす方法をLTで紹介させていただきました。仕事に直接活きる内容ではありませんが、PHPを取り巻く新しい技術を紹介できてよかったです。PaaSを利用して公開まで行えたのも個人的によかったです。もっと低レイアを深ぼり、次は深い話しができたら幸いです。 久しぶりに社外で登壇をして緊張しました。 speakerdeck.com プログラミングをするパンダ ( @Panda_Program ) 今回は PHPerKaigi 2025 のモジュラーモノリス 、 TSkaigi 2025 のクリーンアーキテクチャ の発表に続くオブジェクト指向設計の発表でした。スライドの中で「クリーンなコードとは認知負荷の低いコード」「Entity と Value Object の違い」や「コマンドメソッド・クエリメソッド・モディファイアメソッドを分けて書こう」などオブジェクト指向でコードを書くにあたり大切なことをお伝えしました。コード例も交えて紹介できたので、ここで得た知識を活用して日々の開発に活かしてもらえれば幸いです。 スライド作りで工夫した点は、markdownファイルをGoogle Slidesに連携してスライドを作るOSSの deck を使ったことです。各スライドの文字コンテンツをGoogle Slidesに反映できたので、転記の作業が大幅に省力化できました。また、今回サンプルコードはmarkdownファイルをClaude Codeに読み込ませて生成させたものをチェックし、採用しました。微調整をするだけで十分紹介できるコードを最初から出力してくれました。本スライドの最後に「このスライドをAIに読み込ませたらコード生成できる」と書いているのは、実際に自分が手元で試してうまくいったからです。 PHP Conference での登壇は2回目でした。今回はプロポーザルの段階でstar数が17、トラック4の会場は満員で立ち見が出るほどで嬉しい驚きでした（ネットにはアップしないものの、写真撮れば良かったと後悔しました笑）。オブジェクト設計は多くの方が関心のある内容なのだと実感したのと同時に、たくさんの方にこの内容を届けられたことが嬉しいです。 スライドにも書きましたが、自分一人がクリーンなコードを書いてもチーム開発においては不十分です。みんなが「この時はこう書くよね」という共通認識がないと独りよがりになってしまいます。このため、多くの方にこの内容が届けられたことは意義があると思います。 一方、この発表の内容は私の独創ではありません。 オブジェクト設計スタイルガイド という良書を参照しています。本書を使った読書会の進め方は、以前 ブログに書いている のでこちらもぜひご覧いただければと思います。ぜひチームでこの本の読書会をして、みんなでクリーンなコードを書きましょう！ speakerdeck.com 当日見たセッションの紹介 PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則 PHP8.4 で追加されるプロパティフックの紹介と後半は型システムの話も入れながらのプロパティフックが入ることにより何が変わるかの紹介でした。 個人的にプロパティフックがあることで今までと何が変わるの？書き方楽になるだけ？getter, setter じゃだめなの？と思っていたのでこれから使っていくぞ！と思えるような発表でした。 自動販売機を使った例えばとてもわかりやすかったです。 speakerdeck.com イベントストーミング図からコードへの変換手順 昨今のAIエージェントでコード生成が楽になるというのは身をもって体感していましたが、このセッションでは自分たちエンジニアがコードを書かなくなったらその時間を何に使うべきなのかを感じさせられるセッションでした。 ポリシーや外部システムとの連携など様々なパターンでの例があったのでイメージもしやすかったです。 イベントストーミングに賭けたくなりますね speakerdeck.com おわりに ブースに来ていただいたみなさま誠にありがとうございました！ また、登壇された方々やスタッフの方もカンファレンスを盛り上げるために尽力していただき本当にありがとうございます。 おかげでいつもカンファレンスを楽しむことができています。 BASEは今後もカンファレンスイベントへの参加や登壇を積極的に支援しています もしご興味ありましたら採用情報も確認してください！ binc.jp

はじめに BASE BANK Dept で Engineering Program Manager をしている大津です。 今回は、4月にリリースした最速振込とそれまでの歴史について簡単に触れつつ、どのようにプロジェクトのリードをしたのか書きます！ baseu.jp 振込申請の種類と歴史 最速振込は、BASEが提供する振込申請の一つの種類です。 振込申請とは、ショップオーナーさんがBASEでの売上金額を自身の銀行口座へ振り込むため申請する機能です。 BASEの振込申請には、様々な種類があります。表にまとめると下記のようになります。 種類 振込日目安 手数料 通常振込 10営業日後 振込手数料＋事務手数料のみ お急ぎ振込 翌営業日または翌々営業日 振込手数料＋事務手数料＋振込申請金額の1.5% 定期振込 当月末までの売上金全額を翌月25日に自動で振り込む 振込手数料＋事務手数料のみ 最速振込 最短10分（土日祝日含む） 振込手数料＋事務手数料＋振込申請金額の3.0% 1. 通常振込 BASEの基本的な振込方式として、当初から提供されている振込方法です。一般的な決済サービスでは月末締め翌月入金が多い中、10営業日での入金サイクルを実現し、早期入金を可能にしました。 手数料は、振込手数料＋事務手数料のみになります。 2. お急ぎ振込の導入（2020年2月） 個人やスモールチームが多いBASEショップのニーズに応えるため、より迅速な入金サイクルを実現する「お急ぎ振込」が導入されました。翌営業日または翌々営業日での入金を可能にし、キャッシュフロー改善に貢献しています。 手数料は、振込手数料＋事務手数料＋振込申請金額の1.5%になります。 3. 定期振込の導入（2022年7月） 申請の手間を軽減するため、当月末までの売上金全額を翌月25日に自動で銀行口座へと振り込まれる「定期振込」が導入されました。 手数料は通常振込と同じで、定期振込の設定はいつでも解除することができます。 4. 最速振込の導入（2025年4月） さらなる入金スピードを求めるショップのニーズに応えるため、お急ぎ振込よりもさらに早く早期入金を実現する「最速振込」が導入されました。主な特徴は下記のとおりです。 最短10分での入金が可能 土日祝日を含む365日対応 モアタイムシステム対応の金融機関であれば、当日中の振込が可能 手数料は、振込手数料＋事務手数料＋振込申請金額の3.0%になります。 どのようにプロジェクトのリードをしていったか まず前提として、私はEngineering Program Manager（以下EPM）というプロダクトのデリバリーとクオリティに責任を持つロールについています。 devblog.thebase.in 最速振込のプロジェクトでは、主に下記のようなリードをしていました。 最速振込の設計（アーキテクチャやDB・API利用などの基本設計、バッチの詳細設計、運用設計など）、実装、QAや本番テストの方針策定と実施 プロダクトマネージャーと連携して契約推進および関連ステークホルダーとの調整MTGの実施 スプリントやレトロスペクティブなどのチームイベントの運営 API調査からリリースまでの全体スケジュールのハンドリング リリース後の安定運用を目指した改修と保守 私個人としては中規模プロジェクトのリードは初めてでしたが、マネージャーと相談しながらいくつかの工夫を重ねてプロジェクトのリードをしていきました。 ロードマップをベースに、目標を示し続けてスケジュールをすり合わせする プロジェクトのリードをする人は、聞かれたらいつでも答えられなければならないことがたくさんあります。 現在のプロジェクトが順調に進んでいるかどうか どのマイルストーンやリリースターゲットを目指しているのか どのタスクの優先順位が最も高いか、タスクの漏れはないか 想定されるリスクは何か スケジュールが遅延している場合に、どのような具体的なリカバリー方法があるか これらの質問に答えられるよう、FigJamでロードマップを作成し、進捗管理を行っていました。 FigJamで作成したロードマップの図 ロードマップに記載する内容は、次のようなものです。 タスクの内容 担当者 見積もり（工数感） 作業ステータス タスクの依存関係（クリティカルパスがどこか） タスク開始と終了目安 などです。 このロードマップはプロジェクトハンドリングの基礎になります。 プロジェクトがどのくらいタスクが終わっている/終わっていないのか、今の状況を把握できる 漏れているタスクがないか客観的にわかる どのタスクを最優先にすべきか、スケジュールが遅れている場合どうリカバリするか考えやすい メンバーとのスケジュールのすり合わせも、このロードマップをベースに行うとスムーズに進む 作成するタイミングとしては、理想は一番最初です。それが難しい場合でも、なるべく早い段階で作成すると良いでしょう。 また、このロードマップは何度でも作成し直しても構いません。重要なのは、現時点でプロジェクトメンバーとスケジュールを通して、（リリース）目標とそのプロセスを示し続けられるか、そしてスケジュールのすり合わせができているかということです。 フェーズごとの終了条件を明確にする 今回の最速振込は、銀行と連携する外部連携を必須とする開発でした。しかし、どのような外部連携であっても「API調査」「設計」「実装」「QA」「リリース」といったフェーズが必要など、基本的な流れは共通しています。 ただ、各フェーズの終了条件を明確にしておかないと、そのフェーズで無限に時間を消費してしまいます。手戻りを減らしながらも開発を進めていくバランスを考え、適切な終了条件を設定する必要があります。 最速振込では、API調査と設計について下記のような終了条件を設定していました。 API調査：仮説ベースで最速振込にまつわる業務フロー図をたたき台として作成し、それが実現できるかどうかを調査。実現可能性が確認できた段階で、API調査を終えて設計へ移る 設計：全体の基本設計ドキュメントをベースに、それぞれのバッチなどの詳細設計が迷わず実装に着手できる（あるいは実装しながら詰めていく）ようになったら、バッチなどの詳細設計へ移り実装を始める 実際に動くものを一番に信じる なるべく不確実性をなくすには、実際に動くものをベースに考える必要があります。 外部連携は動かしてみないと分からないものが多いので、いかに早く動かせるか？本番リリース前に確かめられるか？を考える必要があります。 外部連携先の開発環境で正常に動作するか 最速振込では、できるだけ早く開発環境を入手できるよう契約関連を最優先タスクに設定しました。 また、開発環境で検証できる事項をあらかじめ整理し、検証できない項目は本番環境でのテストで確認することにしました。 本番環境で期待通りに動作するか 最速振込では、本番環境での実際の銀行振込テストを実施しました。本番環境でないと分からないことを放置したままリリースするのは非常に危険だからです。 このテストは実際に銀行口座へ入金が発生するため、事前に社内での稟議手続きやテスト実施ショップの準備なども丁寧に行いました。 プロジェクトのリードをする人の腕の見せ所 プロジェクトのリードを実際に経験して、特に腕の見せ所だと感じた点をいくつか紹介します。 いかに自分がボトルネックにならないプロセスを考えられるか vs いかに自分がクオリティに責任を持てるか 「自分がすべてを確認しなければ進められない」という姿勢は非現実的であるため、適切に権限委譲していくことが求められます。 ただし、忙しさを理由に単なる丸投げをしてはいけません。移譲のプロセスやissueチケットの書き方などを工夫する必要があります。また、継続的にissueチケットを作成・管理する「筋力」も必要です。 一方で、できるだけ多くのレビューを行う姿勢も大切です。プロジェクトのリードする人は品質に責任を持つ立場であり、レビューを怠ることがPJの進捗を止めることにもつながります。 とはいえ前述の通り、「自分がすべてを確認しなければ進められない」という姿勢は非現実的です。状況によっては、期間限定でレビューを他のメンバーに委ね、タスク消化に集中するという判断が必要な場合もあります。 この権限委譲の適切なバランスを見極めることが重要です。 スケジュールが遅れそうなときのリカバリ案がいくつ出せるか プロジェクトの開発を進めていると、スケジュールが遅れている状況もありうるでしょう。そうなった時に、すぐに「納期を伸ばす！」ではなく、どうリカバリするか、リカバリ案はいくつあるかを考えることが重要です。 例えば以下のようなリカバリ案があります。あくまで一例であり、プロジェクトの状況によってはさらに多くの選択肢があるでしょう。 タスクをさらに分解して、並行で作業ができる状態にしたり、クリティカルパスのタスクを進めやすくする 先んじて（特にクリティカルパスの中で）依存関係が多いタスクをこなし、タスクが終わるまでプロジェクト全体の進捗が止まる状態を防ぐ 依存関係のないタスクを用意しておき、いざというとき人員追加した際のタスクとして活用する このリカバリ案を出す能力は、実際に経験を積み、その経験を振り返りながら徐々に上達していくことで身につけられるものです。 リカバリが困難な場合、プロジェクトマネジメントの基本である「スコープ/リソース/納期」のどれを調整できるかという検討が必要になります。ただし、これは前述のリカバリ案の検討と実施を一通り行った上での最終手段と考えるべきです。 リソース すぐにチーム外にヘルプを求められるよう、タスクが適切に整理されているか プロジェクトの知識を効率的にインプットできる資料は用意されているか（ただしプロジェクト後半になるほど難しくなる） スコープ リリースに必要な機能や優先順位が明確についているか 納期 デリバリーの遅延が事業計画にどの程度の数字的影響を与えるか ステークホルダーはどう受け止めるか 越境するための関係値づくりやコミュニケーション力が問われる プロジェクトで開発する機能と業務は密接に関わっています。業務は想像以上に多くのステークホルダーが関与しており、これらのステークホルダーを考慮せずに開発を進めると、簡単に手戻りが発生してしまいます。 プロジェクトの最初の段階でステークホルダーを洗い出し、早めに相談を持ちかけることが重要です。 また、コミュニケーションにおいては、場の設計、ファシリテーション、対話、ドキュメント作成など様々なスキルが求められます。これらのスキルも、先述のスケジュールリカバリ案と同様に、実践と振り返りを繰り返すことで徐々に磨かれていくものです。 おわりに プロジェクトのリードをしてみると、する前とした後で、見えてくる景色には大きな違いがあると感じました。今後も積極的に経験を積んで上達し、プロジェクトのリードを通じて事業貢献できるエンジニアになっていきたいです！ BASE BANK Deptでは、プロジェクトの開発リードをする / したいエンジニアを募集しております。まずはカジュアル面談からお待ちしております！ open.talentio.com binc.jp

はじめに BASE BANK Department で エンジニア をしている池田聖示です。 入社して1年が経ちましたが、この間、アラートやお問い合わせの対応に積極的に取り組んできました。 今回は、その理由や意識していたことを振り返ってみようと思います。 アラート対応、ユーザーからのお問い合わせ対応の価値 主語を大きくしたくないですが、多くのエンジニアにとってアラート対応などは敬遠されがちだと思います。 確かに、集中して取り組んでいるタスクを中断しなければならないこともあり、スイッチコストもかかります。 しかし、私はアラート対応やユーザーからのお問い合わせ対応の業務に大きな価値があると考えています。理由は、以下のような形で自分自身の成長にもチームへの貢献にもつながるからです。 キャッチアップにつながる 問題解決能力の向上 ユーザーの声に直接触れる貴重な機会 キャッチアップにつながる 私が所属しているチームでは、主に4つのプロダクトや機能を担当しています。 積極的に開発しているプロダクト以外は、なかなか普段のタスクでシステムの詳細を追うことが難しいです。 アラート対応やお問い合わせ対応を行うことで、データ構造や該当処理のコードを追うことができてシステムへの理解が深まります。 また、このエラーを出さないためにはどんな設計にすれば良いのか、どんなハンドリングが適切か、などを考えることができてエンジニアとして技術力を上げる機会になると思います。 実際に、エラーハンドリングの修正PRを上げることや、プロダクトのドキュメントに記述を追加するなどのアウトプットを行い、チームの資産にすることもできたと思います。 問題解決能力の向上 アラート対応やお問い合わせ対応などを行う際に、エンジニアだけに閉じず、他職種の方と連携して解決することが必要な場合があります。 例えばお問合せをもらった際に、「このような意図であっているか」、「更にこういった情報が欲しい」といった連携をしたり、 「システム的にこんな状態になっているのでユーザーに伝えたいがどんな風に伝えるのが適切か」などの相談をしたりと、コンテキストを共有することや、問題解決までの道のりを一緒に描くなどの職種を超えた連携の力を育むことができます。 ユーザーの声に直接触れる貴重な機会 ユーザーからのお問合せを受けることで、どのように機能を使っているか、どんなことで困っているのか、という情報に直接触れることができます。 ユーザーと向き合っている実感が持てる貴重な機会だなと思うと共に、 こんな風にヘルプ情報出したら良いかも、こんなUIにしたら分かりやすくなるかも、という考える機会になるためエンジニアとしての視野を広げることができると思います。 実際にどのような流れで行っているか 実際には概ね下記のような流れで行っています。 お問い合わせの場合 お問い合わせ文を見て回答すべきことを確認する 回答の根拠となる、情報を集めに行く 対象のソースコード、DB、ヘルプページ、ドキュメントなど 情報の整理を行い、回答する アラート対応の場合 アラートが発生したらSlackの通知が飛ぶので、そこからSentryを見に行く 該当ユーザーのデータを確認しつつ、リカバリー必要の有無を判断して実施する リカバリーが必要であればクエリを書いたりなどの対応を行う 根本原因を調査 根本原因への対策を検討 EPMやPdMとすり合わせて優先度付けを行う 意識していること お問い合わせの回答をする際に、どの情報を、どのように伝えれば過不足なく理解してもらえるか 根本原因への対策が運用手順書に書いてあったとしても、「なんでこの優先度の意思決定になったのか」などを追うことで、自分自身の成長に繋がるためissueを追って見たりします 進め方や解決策に関して積極的にフィードバックをもらいにいくことで、本当に良かったか、もっと良くするための方法を吸収していく 参照：EPMとは devblog.thebase.in 具体的な得 冒頭の結論で書いた 「キャッチアップにつながる」、「問題解決能力の向上」、「ユーザーの声に直接触れる貴重な機会」 でも記載した内容と重複するところもありますがまとめると下記の3点だと思います。 エンジニアとしての技術力の向上 仕事の進め方が良くなる 目の前の問題を解決するだけではなく、「もっとスムーズに解決するためには」、「そもそも起きないようにするためには」などのことを思考することで上記のような成長に繋がると思っています。 大変なこととその対処法 一時的にマルチタスクになると思うので忙しい、スイッチコストがかかるなどの負担があると思います。 ただ、EPMやマネージャーなどに適切にエスカレーションを上げることで、忙しいという面は解消できていますし、この相談も仕事の進め方能力向上につながると思っています。 具体的には、下記のような流れでEPMやマネージャーとコミュニケーションをとっています 目の前のアラート対応やお問合せ対応の緊急度を判断（既知の原因でのものか、機会損失になるか、今後のユーザーに影響が出るかなど） 目の前のアラート対応やお問合せ対応の概算の工数を見積もり、今の自分のタスクにどの程度影響が出るかを判断（30分程度で終わりそうであれば、その場で対応して終了） 必要があればissueを作成して重要度と緊急度なども含めて概要をまとめる 差し込みで対応するべきかバックログに積むかを検討してEPMやマネージャーと相談 差し込みでの対応なら見積もりなども踏まえて、差し込み前に対応していたissueの期限などを調整 意識していることは、アラートのスレッドや、お問合せのスレッドなど細かく現状の報告をするようにしています（調査開始時や、調査が長引きそうな時の中間報告など） 温度感や難易度などの情報をEPM・マネージャーと共有するために必要だと思っています。 補足： 私が所属しているチームのEPM・マネージャーがデイリーなどで、良しなに調整してくれているケースが多いので、私自身あまり差し込みで逼迫した経験がない前提ではあります。 まとめ アラート対応や、お問合せ対応は、大変な側面もありますが、個人的には得られる経験値は膨大であると思っています。 入社後のキャッチアップスピードを上げる。エンジニアとして技術力を上げる。仕事の良い進め方を身につける。など、意識次第で成長角度を上げることができるチャンスだと思います。 おわりに 今まで書いてきたことは私のチームが、メンバーの成長をサポートするという土壌が豊かであるという前提のものです。 アラート対応やお問合せ対応から成長するためには、適切なフィードバックやアドバイスが不可欠です。 BASE、BASE BANKでは一緒に働く仲間を募集していますので気になった方はぜひ下記リンクを見ていただけると嬉しいです。 binc.jp

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