はじめに こんにちは！BASE BANK Dept にいるフルサイクルエンジニアの02です。 今回はFull Cycle Developers Night #2 ～エンジニアはどこまでビジネスを知るべき？～というBASE株式会社(以下、BASE)、株式会社CARTA HOLDINGS(以下、CARTA)、MOSH株式会社(以下、MOSH)で共催したイベントについて、当日の様子をお届けします！ 開催したイベントについて base.connpass.com Full Cycle Developer(以下、フルサイクルエンジニア)とは、Netflixが2018年に提唱したエンジニアのあり方の一つです。フルサイクルエンジニアは、コードを書くだけでなく、設計から運用までソフトウェアプロダクトのライフサイクル全体に責任を持ちます。 Full Cycle Developers at Netflix — Operate What You Build devblog.thebase.in そんなフルサイクルエンジニアを主軸としたイベントが、Full Cycle Developers Nightです。今回は「エンジニアはどこまでビジネスを知るべき？」をテーマに、事業との向き合い方についてパネルディスカッションしました！ パネルディスカッションの様子 パネルディスカッションの前に、各パネラーから自社のビジネスモデルや組織形態について、スライドを用いて5分程度で解説してもらいました。 今回のテーマ「エンジニアはどこまでビジネスを知るべき？」では、ディスカッション中に各社のビジネスモデルや組織形態の話が出てくることが想定されました。そのため、事前に理解してもらった上でパネルディスカッションを始める流れにしました。 各パネリストとモデレーターの様子 パネルディスカッションでは、以下のようなテーマで話しました！ 「ビジネスサイド」具体的に誰を想像していますか？ どんな役割分担でどこまで意見をだしている？ どういった失敗から「ビジネスを知らねば」と思ったか？ フルサイクルエンジニアとして、企画をエンジニア発信で進めることはあるか？その場合、何を根拠に提案しているか？ コードを書く開発業務だけに集中したいエンジニアに、どうマインド変革を促せばよいか？ フルサイクルエンジニアの立場で、PdMにしてもらって嬉しかったこと・やりやすくなったことは何か？ 途中からは参加者からもXでテーマを募集し、盛り上がりを見せました！当日の盛り上がりは、Xのハッシュタグからもご覧いただけます！ #full_cycle_nightのタイムライン パネルディスカッション中の様子 おわりに Full Cycle Developers Night #3 も開催したいと思っています！フルサイクルエンジニアや事業との向き合い方に興味がある方は、ぜひFull Cycle Developers Night #3 でお会いしましょう！ BASE BANK Deptでは、事業をエンジニアリングするフルサイクルエンジニアを募集してます。 ご興味がある方は、ぜひ下記のURLから採用ページをご覧ください！ binc.jp

自己紹介 BASEでエンジニアインターンをしている吉川唯音です。趣味は音楽で、作曲や編曲をしています。この度10月9日をもって、インターンを無事に終えることになりました。約2ヶ月のBASEでのインターンを通して、感じたことや学んだことについて語っていこうと思います！ インターン入社の経緯 自分は普段から多様なクリエイターとの接点があり、周囲ではBASEを利用している方も多く、そのため以前からBASEという存在を知っていました。そうした背景もあり、サポーターズの1on1イベントに参加した際により強く興味を持ち、面談を経て応募に至りました。そして選考が進み、8月からインターンとして入社しました。初めてBASEを訪れた際には、大きなガラス張りのエレベーターとオフィスの開放感のある雰囲気に驚いたことを今でも覚えています。 BASEで実際にやったこと ショップ管理画面全体のデザインリニューアル開発 私はBASEで「ショップ管理画面全体のデザインリニューアル開発」にジョインし、フロントエンドの実装を担当しました。普段はReactを扱うことが多いのですが、BASEではVueを用いて開発を進めました。特に印象に残っているのは「デザインシステム」の考え方です。大規模なプロダクトであるからこそ、将来的な拡張性を意識し、一箇所の修正が全体に反映される仕組みや、新しい機能を追加しやすい設計が整えられていました。単なる見た目の調整ではなく、フロントエンドにおける本質的で重要な仕組みを体験できたと感じました。 ▲新管理画面 ▲旧管理画面 iOS 26 対策 2ヶ月目はiOS 26 対策にもジョインしました。iOS26のリリース前に、シミュレーターで検証や修正を進めました。プロダクトの規模が大きい分、前提知識や全体構造の理解が求められ、影響範囲を考慮しながらコードを書くことの難しさを強く実感しました。BASE独自に構築された仕組みや、フロントエンドの中枢にあたる部分に触れることは難しかったですが、実装していてとても面白いと感じました。 "プロダクト"とリリース体験 また、この経験を通じてAIエージェントに対する考え方も変わりました。AIは人間の意図や文脈を完全には理解できないからこそ、プロダクトの構造や本質を踏まえ、影響範囲を見据えた設計・実装を行うことがエンジニアにとって不可欠だと学びました。 インターン最終週には、自分が担当した実装箇所が無事にリリースされるのを見届けることができ、とても嬉しく感じました。実際にプロダクトとして動いている様子を見たときは、感動しました。長く続いていたプロジェクトに参加し、限られた期間の中でリリースの場面にも立ち会えたことは、本当に幸運であったと感じています。 インターンを通じて感じたこと 特に学びになったこと BASEでのインターンを通じて特に学びとなったのは、「 プロダクトに向き合う姿勢 」と「 実務としてのスクラム開発 」です。 入社してまず驚いたのは、プロダクトに対する考え方でした。「コードを記述する」ことにとどまらず、「なぜその機能を作るのか」「ユーザーはどのように利用するのか」といった背景までを深く考える文化があります。エンジニアだけでなく、デザイナーやPdMの方々と一緒に議論し、提案を交わしながらプロダクトを形にする。そこには「難しいことをシンプルにする」という思想が強く根付いており、これはプロダクト全体や日々の業務に反映されていると感じました。この経験を通して、エンジニアにはコードを書くことだけでなく、ドメインを理解し、本質的に価値のあるものを見極める視点が不可欠だと実感しました。 さらに、BASEのインターンで特に貴重だったのは、実際にエンジニアの方々と同じチームでスクラム開発に参加できたことです。レトロスペクティブやスプリントレビュー、デイリースクラムといったスクラムイベントに、開発メンバーの一員として加わりました。プロダクトのゴールに適切に向かえているか、チームの状況はどうかといった点について、日々活発に議論しながら開発を進める経験はとても刺激的でした。このように実務としてのスクラム開発を体験できたことは、他のインターンでは得られない、大きな学びとなりました。 こうした学びを自分なりにアウトプットし、自分が所属するコミュニティでの開発や自己開発にも取り入れるなど、より前向きにチャレンジできるようになりました。コミュニティ内部のインターンでは、フロントのデザインシステムによる共通化やレトロスペクティブのファシリテーション、開発するプロダクトに対して積極的に向き合っています！ BASEのすごいと思ったところ BASEに入社して最初に感じたことは、受け入れ体制がしっかり整っていることでした。入社前の面談では「今まで新卒を採用したことがなく、教育制度や受け入れ体制が十分ではない」と伝えられていましたが、実際には予想以上に丁寧に受け入れていただき、とても驚きました。インターン期間中はメンターとしてついていただいた先輩エンジニアに、開発業務から日々のサポートまで手厚くフォローしていただき、社会人経験の少ない私にとって非常に心強く感じました。 また、BASEの魅力を強く感じたのは「プロダクトに対する一貫した思想」と、充実した開発環境の両立です。ユーザー視点を大切にしながら「難しいことをシンプルにする」文化が根付いている一方で、Android実機をWebブラウザからリモート操作・管理できるツールがBASE内で用意されるなど、開発環境にはギークさもありました。こうした環境の中で、AIでは生み出せない価値やプロダクトへの愛着を肌で感じることができました。 インターンを考えている学生に向けて BASEでのインターンは、チームの一員として受け入れられ、実際の開発業務に携わることができます。そして他の企業では経験できない貴重な学びがあります。また、メンターランチでは費用補助があり、美味しいご飯を楽しみながら、インターン期間中に参加したPJ外の方と交流することができました。特にオムライスが美味しかったです。 さらに、BASEには1on1や全社集会、部活動といった制度が整っており、多くの社員の方々と関わる機会がありました。インターンとして参加する中で、さまざまな視点や刺激を得られる、とても恵まれた環境だったと感じています。 1on1では先輩エンジニアの方と技術的なお話をさせていただいただけでなく、人事・PdM・CSといった他職種の方々とも対話する機会をいただきました。将来のキャリアや就活についての相談から、BASEでの開発体制や技術に関する具体的なお話まで、幅広く学ぶことができました。 BASEで働くメンバーはとても親切で、多方面に優れていると感じました。だからこそ、エンジニアリングの実務だけでなく、カルチャー面でも多くの学びが得られるインターンだと強く感じました。ぜひBASEのインターンを通じて、その両方を体験していただきたいです！

はじめに BASEでソフトウェアエンジニアをしている Futoshi Endo（ @fendo181 ）といいます。 以前、同じチームの Kumar さんが以下のタイトルで記事を執筆されました。 「BASEでの開発体験を向上させるための取り組み」 devblog.thebase.in この記事では、生成AIの活用によって、メンバー全員がフロントエンドとバックエンドの両方を担当できるようになった、という挑戦について触れられていました。 今回のプロジェクトでは、メンバー全員がフロントエンドとバックエンドの両方を担当できるようにするということにチャレンジをしました。メンバーは以前から専門領域を広げたいという意欲を持っていましたが、学習コストやペアプログラミングにかかる時間的負担を考慮し、プロジェクトの進行を優先せざるを得ませんでした。 しかし今回、AIツールの活用によってこれが実現可能となりました。 自分はまさにこのプロジェクトのエンジニアメンバーの1人であり、AIツールの力を借りることで、バックエンドの領域から、フロントエンド開発に挑戦することができました。 この記事では、どのように生成AIを活用して学習・開発を進めたのか、具体的な体験をベースに紹介します。 AIを“頼れるエキスパート”として活用し、スキルを拡張する 今回のプロジェクトでは、主に React + TypeScript を用いた機能開発が中心でした。 プロジェクト初期は「フロントエンドもやってみたい」という気持ちはありつつも、ReactやTypeScriptの文法に不慣れな自分にとっては、 「何が分からないのかすら分からない」状態 で、不安の方が大きかったのを覚えています。 まず取り組んだのは、 Reactの公式ドキュメントのチュートリアル をベースにした写経です。 基本的な構文やライフサイクル、Hookの使い方などを手を動かしながら覚えていきました。 しかし、それだけでは実務のコードはなかなか読めるようにはなりません。 PRレビューにおいても、変更内容の意図が掴めずに苦労していたのが実情です。 そこで活用したのが、 ChatGPT や GitHub Copilot Chat といったAIツール です。 わからないコードの説明や、PR内容の要約、APIや型の補足など、質問を投げることでその場で壁打ちができる環境が構築できました。 その後は、技術書やサンプルコードを写経しながら実装力を強化し、壁にぶつかるたびにAIに質問を重ねることで、 学習のトライアンドエラーを高速に回すことができました。 特に印象に残っているのは、1ヶ月前は理解できなかったコードが、自分でAI Agentを活用し、出力されたコードの意図をすべて理解し、業務でも活用できるコードへと変わっていった実感です。 たとえば、最初はAIが生成したコードの正誤すら判断できませんでしたが、繰り返しのやり取りと経験の積み重ねによって、 「どの部分が怪しいか？なぜそうなるか？」を自然と説明できるようになっていた のです。 当初は「フロントエンドに関連する機能改善で20本ほどPRを出せたら十分」と考えていましたが、プロジェクト終盤には 60本以上のPRを提出 しており、予想以上の成果につながりました。 もちろん、新規ページ追加や、APIへリクエストを行う為のClient追加のような機能開発から、細かなUI調整や文言変更なども含まれていますが、ReactとTypeScriptの知識がほぼゼロの状態から始めた自分にとって、この実績は大きな自信になりました。 この経験から強く感じたのは、 生成AIは単なる効率化のツールではなく、学習の初動コストを下げ、スキル拡張を加速する存在である ということです。 今後、「生成AIでコードを書く」だけでなく、生成されたコードが正しいかを判断する能力＝レビュー力・設計力がますます重要になると考えています。 その意味で、AIとの理想的な関係性は以下のように整理できるのではないかと思っています。 得意な領域 → 生成AIを活用し、生産性を最大化する 不得意な領域 → 生成AIを“頼れるエキスパート”として活用し、学習のスピードを上げる AIと上手く付き合うコツは得意な領域では積極的に生成AIを活用し、生産性を上げ、不得意な領域では頼れるエキスパートとして活用し、学習をするのが良い近道なのではないかと思っています! まとめ 今回紹介したようにAIを活用することでこれまで専門外だったフロントエンド領域に挑戦することができました。一方で、AIを使う中で一貫して意識していたのが、 How（やり方）に偏りすぎないことの重要性 です。 Claude CodeやCodex CLIなど、AI Agentによるコードの自動生成は非常に便利ですし、私自身も Zennで記事 を書くほど積極的に活用しています。 しかし、ソフトウェアエンジニアとして本当に重要なのは、 「なぜその実装を選ぶのか？」「設計意図は何か？」というWhyの部分 です。 ユーザー体験、アーキテクチャ、保守性、チーム内の運用方針など、Whyを考慮することで、より本質的な開発ができると確信しています。 AIは間違いなく、これからのエンジニアにとって欠かせないパートナーになります。 だからこそ、自身の成長へつながる使い方と、上手く付き合っていくのがこれからのAI時代のエンジニアに求められるスキルセットだと思っています! 最後に宣伝で、BASEにおけるAI活用や開発スタイルにご興味を持っていただけた方がいれば、ぜひ採用ページもご覧ください！ binc.jp 今後も、プロジェクトで得た知見を継続的に発信していきます。 最後までお読みいただき、ありがとうございました! おわり!

はじめに こんにちは、BASE株式会社 上級執行役員 SVP of Development の藤川です。 今年、生成AIの活用は経営課題の一つとして大きな注目を集めています。 開発担当役員という立場としても、この変化を肌で感じる必要があると考え、何年ぶりかにソースコードと向き合い、実際にプルリクエストを出してみることにしました。 ソースコードから離れていた10年間 最後にBASEのソースコードを書いていたのは、2016年頃まで。 上場に向けて、採用活動や組織拡大がマネジメント課題として本格化し、マネージャ育成やエンジニア採用、IT内部統制、情報システム整備といった役割が増えていく中で、自然と現場のコードから離れていきました。 その後、システムは大きく進化していきました。 開発環境のDocker化、本番環境のコンテナ化、テスト導入、React/Vue.js採用、モジュラモノリス化、CakePHP依存度の低下、PHP5から7〜8への移行…。 自分が作った開発チームの人たちの手で、気付けば、今のコードやサーバ構成はすっかり「浦島太郎」状態になっていました。 CursorでBASEのコードをキャッチアップ 最初の壁は、この10年分の変化をどう取り戻すか。 以前からのBASEのシステム構造は頭に入っていたので、その知識をベースにAIを使いながらキャッチアップしていきました。 使ったのはAIエージェントアプリの「Cursor」です。 Dockerfileやドキュメントを一つひとつ読むには時間がかかりますが、これらの情報やソースコードを下地としてCursorに質問すると、必要な情報を整理してくれます。 合間の時間を活用しながら進め、ほぼ誰にも質問せずに1週間で開発環境を再現できました。 どうしてもわからない部分だけ、CTOにヒントをもらう程度で済みました。 特に驚いたのは、ソースコードだけを元に「BASE Apps」という概念をCursorが理解してくれたことです。 BASE Appsとは、抽選販売機能やTikTok Shop連携などの機能を、後からショップにインストールできる仕組みです。 使い始めのBASEはシンプルなまま、必要に応じて高い機能を追加できるようにすることで、お店の成長に合わせた柔軟な情報アーキテクチャを実現しています。 この構造をAIが説明してくれたとき、正直ちょっと感動しました。 実際にPRを出してみた 環境構築が終わり、手元のDocker環境でBASEの開発環境が動くようになったので、新入社員やインターンの人に割り当てられるオンボーディング用のチケットプールから、ちょっとした不具合修正のチケットを割り当ててもらいました。 チケットに書いてある要件をプロンプトとしてCursorに渡すと、修正案を生成してくれます。チケットに書いてある要件が適切かつ具体的であればあるほど、修正案の生成は精度が高くなります。 それを元にコードを書き換えてプルリクエストを出すことに成功しました。 コード自体は当社のエンジニアの仕事場ですから適当なコードは出せません。できるだけ丁寧に内容のチェックをしました。ここまではほぼほぼ短時間での作業なのですが気の使い所です。 エンジニアからは丁寧なレビューが返ってきましたが、振り返ると「必要以上に大きな修正だったかもしれない」と感じています。 理由は、フロントエンドとバックエンドが別リポジトリで管理されており、Cursorがそれぞれの中で最適解を導いた結果、全体としては少し大げさな修正になっていたためです。 今のCursorの管理単位はリポジトリ単位になるため、リポジトリ間の関係性については人間が俯瞰して補う必要があり、そこは甘かったなと痛感しました。また、その解像度でコードレビューをしてくれた当社エンジニアはマジですごいなと改めて思いました。 レビューを通じて感じたこと レビューの指摘自体は正しく、Webサービスの変更において最小限の修正が望まれるという考え方には納得です。 今回のケースではCursorが生成したコードは「動作的には正しい」ものでしたが、それが「チームとして最適なコード」であるとは限りません。 AIが導いた“技術的に正しい解”と、プロダクトとして“望ましい解”は必ずしも一致しない 。 このギャップは今回の大きな学びでした。 一方で、AIが生成したコードを人間が精緻にレビューするのは工数がかかります。 過剰にレビューするのは非効率にもつながり、今後は「どこまで人力で見極めるか」の基準づくりが重要になると感じました。 なお、今回のレビューは、上級執行役員からのプルリクエストということもあり、普段より丁寧に対応してくれた可能性があります（もしかすると警戒もあったかもしれません 笑）。普段のメンバー同士であれば、もう少し軽いレビューで済んだかもしれません。 なので、逆にこれほどの時間をつかってもらって申し訳ないなと思ったのが正直な感想で、アウトプットをCTOや開発チームに委ねていて、自分自身で責任を持ちきれない今の役割においては、気軽にプルリクは出せないなとも思いました。 生産性と責任のバランス AI活用で避けて通れないのが、「どこまで人間が最終責任を持つべきか」という課題です。 AIが出したコードが正しく動いているなら、そのまま通すべきか？ それとも品質を優先してさらに精緻化するべきか？ この答えは一つではなく、チームやプロジェクトによって変わります。 だからこそ、開発チーム全体でレビュー方針を共有し、最適なバランスを探ることが大切です。 そしてもう一つ、AI活用は Biz・PdM・エンジニアといった役割間の業務の「のりしろ」を増やす可能性 を秘めています。 MCPなどを活用してソースコードに直接アクセスし、コードを元データとして新規開発のプロトタイプを作ったり、企画検討や初期見積もりを高精度に進めたりする未来は、もう遠くありません。 役割を超えて協業するための「のりしろ」を増やすことが、AI時代の開発組織に求められる視点 だと感じています。 この「のりしろ」があることで、Biz・PdM・エンジニアが同じデータを共有し、より速く高精度な意思決定ができる未来が見えてきます。 将来的にはAIの処理性能が向上し、複数プロジェクトや複数Webサービスを横断してカバーできるようになるでしょう。 その時に備え、現時点での最適解を常に更新し続けるチームでありたいと考えています。 おわりに〜生成AIの可能性 今回、久しぶりにコードへ戻りPRを出す中で感じた一番の収穫は、現場を離れていたベテランエンジニアでも、AIを活用すれば短期間でキャッチアップできると実感できたことです。 採用やマネジメントに注力していたエンジニアリングマネージャにとっても、生成AIは「現場感を取り戻すための強力な手段」になり得ます。 小さな修正でも構いません。AIを足がかりにコードへ再び触れることで、意思決定の精度やチーム理解は大きく変わります。 ただ正直、今回は「PRを出すとレビューしてもらうのが申し訳なく、遠慮してしまう」気持ちもありました。 だからこそ、AIに任せきりにするのではなく、自分なりの意見を持つためにも、まずはコードに触れてみることが大切だと思います。 これはマネージャだけの話ではありません。 現場のメンバーも「今のやり方がベスト」と思い込まず、AIを取り入れることで新しい速度感や発想を手に入れられます。 AI活用への温度差は、やがて成果や成長速度の差に直結します。 AIは、現場とマネージャの距離を縮め、チーム全体を底上げするツールです。 重要なのは「使うかどうか」ではなく、 「どう使い、どう組織に取り込むか」 です。 半年後、一年後にチームとしてどこまでスピードと精度を高められるかは、いまどれだけ実践と学びを積み重ねられるかにかかっています。 AIをチームの戦力に変えるために、今のうちから試行錯誤を重ね、未来の開発組織の在り方を自分たちで形作っていくことが大切です。

CTOの川口 ( id:dmnlk ) です。 ブログタイトル通りイベントをやります。2025/08/06(水)19:00 〜 21:00です。 base.connpass.com BASEでは、サービス運営13年目を迎えた今だからこそ直面している技術的課題や、その乗り越え方について、現場のエンジニアが率直に語るイベントを開催します。 日々の開発に加えて、10年以上継続するサービスならではの知見や悩み、リアルなエピソードをお伝えする予定です。 参考までに、以下の記事で取り上げたようなトピックにも触れる予定です： devblog.thebase.in パネルディスカッションではあまり外部に出てこないプリンシパルテックリードと話します。 社内記事ではこういうのとか devblog.thebase.in 個人ではこういう記事とか書いてます。 yaakai.to 社内で一番Claude codeとかを触っているはずなんでそのあたりについても色々話を聞こうと思っています。 今回のイベントは採用活動の一環ですが、「今すぐ転職したい」という方だけでなく、 「ちょっと話を聞いてみたい」くらいの温度感の方も大歓迎です。 懇親会では技術的な雑談もできるので、ぜひ気軽にご参加ください。 なお、「connpassで登録すると転職活動がバレそうで不安…」という方は、XなどでDMいただければ個別に対応します。

CTOの川口 ( id:dmnlk ) です。 ブログタイトル通りイベントをやります。2025/08/06(水)19:00 〜 21:00です。 base.connpass.com BASEでは、サービス運営13年目を迎えた今だからこそ直面している技術的課題や、その乗り越え方について、現場のエンジニアが率直に語るイベントを開催します。 日々の開発に加えて、10年以上継続するサービスならではの知見や悩み、リアルなエピソードをお伝えする予定です。 参考までに、以下の記事で取り上げたようなトピックにも触れる予定です： devblog.thebase.in パネルディスカッションではあまり外部に出てこないプリンシパルテックリードと話します。 社内記事ではこういうのとか devblog.thebase.in 個人ではこういう記事とか書いてます。 yaakai.to 社内で一番Claude codeとかを触っているはずなんでそのあたりについても色々話を聞こうと思っています。 今回のイベントは採用活動の一環ですが、「今すぐ転職したい」という方だけでなく、 「ちょっと話を聞いてみたい」くらいの温度感の方も大歓迎です。 懇親会では技術的な雑談もできるので、ぜひ気軽にご参加ください。 なお、「connpassで登録すると転職活動がバレそうで不安…」という方は、XなどでDMいただければ個別に対応します。

はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 弊チームでは、従来の分析基盤を段階的に刷新する取り組みを進めており、その第一歩として、ECS上で動かしていたAirflowをAWS上のマネージドサービスである Amazon Managed Workflows for Apache Airflow（以下、MWAA）に移行しました。 もともとはインフラ管理の手間を減らすことが目的でしたが、結果としてバッチ処理時間が大幅に短縮されるという意外な効果も得られました。 この記事では、ECS上のAirflowからMWAAへの移行に至った背景や、工夫したポイント、得られた改善効果などを紹介していきます。 移行に至った背景 これまでBASEではECS上でApache Airflow v1を運用していましたが、運用負荷が高く、インフラ周りの管理には別チームの支援をお願いすることもありました。またECS用に稼働しているRDSのストレージ容量が逼迫しつつあったことも大きな課題の一つでした。 また、Airflow v1ではサポートされていないオペレーターや機能があり、ワークフローの設計・実装に制限が課されていました。従来の分析基盤を刷新していくにあたり、これらの制約は大きな障壁になると判断し、基盤の中核を担うオーケストレーションツールであるAirflowから着手することにしました。 その結果、Airflowのメジャーバージョンアップデートにあわせて、インフラ管理の負荷を軽減できるマネージドサービスであるMWAAへの移行を決断しました。 環境構築と移行準備 最初にMWAAの公式ドキュメントを参考にしながら環境構築を行いました。事前に必要なものとしては、バージョニングが有効化されたS3バケットのみで、それ以外のVPCやセキュリティグループ、IAMロールについてはMWAAのマネジメントコンソール上で作成しました。 参考: https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/get-started.html この環境構築の段階で工夫したことや躓いた点があったため、次にそれらについて触れていきます。 1. SSH鍵やAPIトークンなどの機密情報をSecrets Managerで管理する ECSで運用していた際は、Airflow上の環境変数やAirflow Variable, ConnectionにSSH鍵やAPIトークンなどを設定して管理してました。ただし、どこにどの情報を置くかの基準が曖昧になっており、管理が煩雑化していたため、移行に合わせて管理方法を見直しました。 MWAAでは S3にファイルとして配置して参照する方法 もありますが、以下の観点からSecrets Managerに統一しました。 セキュリティ管理の観点 情報更新時の作業負荷軽減と安全性向上 MWAAへの移行に伴い、機密性の高い情報は全てSecrets Managerに保存し、Airflowから直接参照する設計 に切り替えました。 MWAAのAirflow設定オプション MWAA環境構築時に、Airflow設定オプションで[カスタム設定を追加]を選択し、以下のキーと値のペアを追加します。 secrets . backend : airflow . providers . amazon . aws . secrets .secrets_manager. SecretsManagerBackend secrets .backend_kwargs: { " connections_prefix " : " airflow/connections ", " variables_prefix " : " airflow/variables " } MWAAからSecrets Managerへのアクセス設定 MWAAからSecrets Managerに安全にアクセスできるよう、IAMロールとポリシーを設定しました。セキュリティを考慮して、 airflow/* という名前の Secretsのみアクセスできるようにスコープを絞っています。 参考: https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/mwaa-create-role.html#mwaa-create-role-attach-json-policy { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : [ "secretsmanager:GetResourcePolicy" , "secretsmanager:GetSecretValue" , "secretsmanager:DescribeSecret" , "secretsmanager:ListSecretVersionIds" ], "Resource" : "arn:aws:secretsmanager:{リージョン}:{アカウントID}:secret:airflow/*" }, { "Effect" : "Allow" , "Action" : "secretsmanager:ListSecrets" , "Resource" : "*" } ] } Secrets Manager側の設定 Secrets Managerにて、以下のように名前を付けて情報を保存します。複数のパラメータをまとめたい場合はJSON形式にしておくと、Airflow側で分割して取得する必要がなく便利でした。 airflow/connections/SSH_CONNECTION { "conn_id" : "SSH_CONNECTION" , "conn_type" : "ssh" , "host" : "192.0.2.0" , "login" : "centos" , "port" : 22 , "extra" : { "private_key" : "-----BEGIN RSA PRIVATE KEY----- \n <秘密鍵の内容は伏せています> \n -----END RSA PRIVATE KEY-----" } } airflow/connections/GCP_CONNECTION { " conn_type ": " google_cloud_platform ", " extra ": { " project ": " sample-project ", " keyfile_dict ": { " type ": " service_account ", " project_id ": " sample-project ", " private_key_id ": " abc123def456 ", " private_key ": " -----BEGIN PRIVATE KEY----- \n <秘密鍵の内容は伏せています> \n -----END PRIVATE KEY----- \n ", " client_email ": " sample-sa@example.com ", " client_id ": " 1234567890 ", " auth_uri ": " https://accounts.google.com/o/oauth2/auth ", " token_uri ": " https://oauth2.googleapis.com/token ", " auth_provider_x509_cert_url ": " https://www.googleapis.com/oauth2/v1/certs ", " client_x509_cert_url ": " https://www.googleapis.com/robot/v1/metadata/x509/sample-sa%40sample-project.iam.gserviceaccount.com " } } } airflow/variables/API_TOKEN abcdefg1234567890 DAGからの利用例 その後、DAGファイル上で以下のようにコードを書くことでSSH鍵やAPI_TOKENを利用することが可能になります。 from airflow.providers.ssh.operators.ssh import SSHOperator from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator from airflow.models import Variable # Secrets Manager に保存された SSH Connection を利用 ssh_task = SSHOperator( task_id= 'ssh_task' , ssh_conn_id= 'SSH_CONNECTION' , command= "echo 'Hello MWAA!'" , dag=dag, ) bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= "select 'Hello MWAA!'" , use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , dag=dag, ) # Secrets Manager に保存された API トークンを取得 token = Variable.get( 'API_TOKEN' ) これにより、従来の環境変数やAirflow Connection、S3によるファイル管理と比較して、より明確かつ安全に機密情報を一元管理できるようになりました。 2. フォルダ構成の整理 MWAAではDAGファイル以外にも、以下のような共通リソースを利用するため、dagsフォルダ配下に用途ごとに整理しました。 dags/ ├── sample_dag1.py # DAGファイル ├── sample_dag2.py ├── plugins/ # カスタムオペレーター、フックなど │ └── custom_operator.py ├── sql/ # クエリファイル │ └── sample_query.sql └── common/ # 共通関数やユーティリティ └── utils.py MWAAのS3バケットでは、dagsフォルダ直下がPythonモジュールパスとして認識されるため、DAGファイルと同じ階層配下( dags/ )に共通リソースをすべてまとめています。 そのため、DAGファイル内では以下のようにシンプルにインポートできます。 from common.utils import some_function from plugins.custom_operator import CustomOperator SQLファイルの利用方法 Airflowで利用するクエリは以前から .sql ファイルで管理しており、この運用をMWAAでも継続しています。DAGのtemplate_searchpathにsqlフォルダを設定することでBigQueryExecuteQueryOperatorにファイル名を指定すればクエリを実行できます。 from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator # DAGオブジェクトの作成（詳細は省略、SQLファイルの検索パスのみ記載） dag = DAG( dag_id= 'base_dwh' , template_searchpath=[ '/usr/local/airflow/dags/sql' ], ) bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= 'sample_query.sql' , # sqlディレクトリ配下のファイル use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , dag=dag, ) もちろんJinjaテンプレートにも対応しており、DAG実行時に動的に値を埋め込むことも可能です。以下は、Airflowの組み込みマクロ( {{ ds }} )と、DAG側から params を使って渡した値の両方を SQLファイル内で利用する例です。 -- sample_query.sql SELECT column1, column2 FROM `sample_dataset.sample_table` WHERE DATE (column_date) = ' {{ ds }} ' AND category = ' {{ params.category }} ' DAG側では、 params に値を渡すことで、SQLファイル内のJinjaテンプレートが展開されます。 from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= 'sample_query.sql' , use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , params={ 'category' : 'category1' }, # params で category を指定する例 dag=dag, ) 3. GitHub Actions で MWAA への自動デプロイ ECS時代もCircleCIを使ってCI/CDによるデプロイを行っていましたが、MWAAではS3にファイルを配置する方式になるため、移行にあわせてGitHub Actionsに切り替え、デプロイ方法も見直しました。 構築した内容 GitHub Actionsによって以下を自動化しました。 mainブランチへのマージ時に、DAGファイル・plugins・共通処理・SQLファイルなどに変更があれば、S3にアップロードする。 以下はそのGitHub Actionsのサンプルです。 name : Deploy MWAA DAGs on : push : branches : - main paths : - 'dags/**' jobs : deploy : runs-on : ubuntu-latest steps : - name : Checkout repository uses : actions/checkout@v4 - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v2 with : aws-region : ap-northeast-1 # 使用している AWS リージョン aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key : ${{ secrets.AWS_SECRET_ACCESS_KEY }} - name : Sync DAGs to S3 run : aws s3 sync dags/ s3://sample-airflow-dag-bucket/dags/ --delete - name : List uploaded DAGs run : aws s3 ls s3://sample-airflow-dag-bucket/dags/ なお、 requirements.txt が更新された場合はMWAA環境の更新が必要です。現在は手動で対応しているものの、今後はGitHub Actionsによる自動反映も検討しています。 ただし環境更新中は一時的にMWAAが停止するため、バッチ処理への影響がないタイミングで実行する必要があり、このあたりは慎重に検討していきたいと考えています。 4. requirements.txt で発生した問題と対処 MWAAでも外部APIを利用するために、requirements.txtにライブラリを記載してインストールしています。ECS時代から利用していたgoogle-ads, facebook-businessなどの広告系API用ライブラリも引き続き使用していました。 発生した問題 MWAAでrequirements.txtを更新した際、次のような問題が発生しました。 一部のライブラリ(google-ads, facebook-businessなど)のインストール時にエラーが発生 MWAAはpip installが1つでも失敗した場合、全てのインストールが中断される(All or Nothing)仕様 そのため、全てのDAGで必須なapache-airflow-providers-*系ライブラリがインストールされず、DAGが動作しなくなる 原因 Airflow公式が提供しているconstraintsファイルと requirements.txt に記載したバージョン指定が衝突していました。たとえば、MWAA v2.8.1(Python 3.10)の場合、以下のconstraintsファイルが適用されます。 https://raw.githubusercontent.com/apache/airflow/constraints-2.8.1/constraints-3.10.txt このconstraintsファイルに含まれるバージョンと異なるバージョン(google-ads==22.0.0 など)を明示的に指定してしまうと、バージョン衝突によってインストールエラー → 全てのインストールが失敗ということになります。 参考: https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html#constraints-files 対応策 ローカル環境でAirflowのconstraintsを適用した状態で pip install を検証するようにしました。 # 仮想環境を作成 rm -rf venv python -m venv venv source venv/bin/activate # pip / setuptools / wheel を最新化 pip install --upgrade pip setuptools wheel # constraints を適用してインストール pip install -r requirements.txt \ -c https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.10.txt 特に以下に注意しています。 MWAAのバージョンごとに対応するconstraintsファイルを適用すること インストールしたいライブラリがconstraintsファイルで制約されているか確認すること 必ずローカルでインストールが成功することを確認してから、MWAAに反映すること MWAAへの移行作業 デプロイやSecrets管理などの仕組みが整ったので、実際の移行作業自体は比較的シンプルでした。 移行の進め方 DAGごとに独立していたため、全てを一度に切り替えるのではなく1つずつ順に移行・動作確認 TriggerDagRunOperatorを用いたDAGのみ、まとめて切り替え 影響範囲の小さいDAGから順に移行することでリスクを抑制 v1の時は実装上の都合からBigQueryのクエリ実行やSlack通知などで自作していたOperator / Hookを以下の観点からAirflow公式のProviderに置き換え 保守・メンテナンスコストの削減 Airflowバージョンアップ時の互換性確保 Providerごとに細かな改善・バグ修正が取り込まれている その他 MWAAの動作環境(PythonバージョンやAirflowバージョン)に合わせて、コードの微修正も行いました。 機密情報の管理やDAG配置場所の変更も事前に行っていたため、その部分のコードの微修正のみでDAG本体の移行作業自体はスムーズに完了しました。 移行によって得られた意外な効果 MWAAへの移行を進めた主目的は「インフラ管理の手間削減」でしたが、思わぬ性能改善という効果も得られました。 処理時間の改善 もともと日次バッチとして実行していたデータ連携処理では、1日あたり約14時間の処理時間がかかっていました。MWAAに移行した結果、約9時間で完了するようになり、4〜5時間ほど短縮されました。 詳細に見ていくと、ECS側では各タスクの開始間隔にも約30秒の遅延があり、日次バッチ全体では約500タスク × 30秒 = 約4.2時間の待機時間が発生していました。MWAAではこの待機時間がほぼなくなっており、これによって処理時間が改善されたと考えています。 原因の考察 さらに調査したところ、ECSの方ではExecuterがSequentialExecutor(逐次実行)になっていましたが、MWAAではデフォルトでCeleryExecutor(並列実行)が使用されていたためでした。 ECS時代はシンプルさを優先して SequentialExecutor を使用しており、タスクは1つずつ実行していました。一方、MWAAではCeleryExecutor(またはKubernetesExecutor)がデフォルトで、タスクが依存関係に応じて複数同時に実行される構成となっています。これにより、独立して動作可能なタスクは自動的に並列実行され、タスク間の待機時間も解消されたため、全体の処理時間が大幅に短縮されたと考えています。 なお、ECS時代でもExecutorの設定を変更すれば並列実行による改善は可能だったかもしれません。ただし、そうした調整やメンテナンスを自前で行うことなく、マネージド環境がデフォルトで最適な構成にしてくれるのも、MWAAを選んだ大きなメリットだと感じました。 影響範囲 タスクが並列実行されることによる影響がないか、以下の観点で確認しました。 元データベースへの影響について MWAAへの移行によって処理の並列化が進みましたが、ETLツールとしてメインで利用しているEmbulk自体は逐次的に実行されるようになっているため、元データベースへの負荷が並列実行で急増することはありませんでした。単純に待機時間が減ったのみで、移行後も元DBへの負荷増加を心配することなく、安定して運用できています。 並列実行によるタスク間の影響 同じテーブルや同じファイルへの出力などをDAGのタスク内で行なっておらず、タスクの依存関係(task1 >> task2)をDAG内で明示していたために同時実行がなされても問題にはなりませんでした。今後もExecutorに依存しない(並列実行されても問題ない)堅牢なDAG設計を継続していきます。 今後の改善点 1. DAGsフォルダ直下のファイル整理 現在、 dags フォルダ直下にDAGファイルだけでなく plugins/ , sql/ , common/ といった複数のフォルダが混在している状態です。 将来的には、DAGファイルと共通リソースをより分かりやすく整理し、管理・メンテナンスしやすい構成に改善したいと考えています。 2. Terraformによるインフラ構成管理 MWAA環境やSecrets Manager、S3バケットなどのAWSリソースをTerraformで管理することで、環境構築や変更の再現性を高め、運用負荷の軽減を図りたいです。 現状は手動で設定している部分も多いため、IaC化による標準化・自動化が望まれます。 おわりに Airflowの移行によって、運用負荷の軽減だけでなく、思わぬ性能改善も得ることができました。 今後も基盤全体の改善を進めながら、より安定したデータ連携基盤を目指していきます。 最後となりますが、弊社ではデータエンジニアを募集しています。上記で述べた課題以外にもBASEの分析基盤には多くの課題があって、とてもやりがいのある仕事かなと思っております。ご興味のある方は気軽にご応募ください！ open.talentio.com

AWS SUMMIT JAPANにあった社名を書くボード はじめに BASE BANK Dept で Engineering Program Manager をしている大津です。 BASEでは多くのプロダクトでAWSを使用しており、BASE BANK Deptでもフルサイクルエンジニアの思想のもと、AWSに触れる機会が多いです。そのため、AWSのキャッチアップはとても重要です。 なぜフルサイクルエンジニアを目指すのか / FullCycleDeveloperNight#1 - Speaker Deck 今回はAWSの最新情報を得るため、2025年6月25日（水）〜26日（木）に開催されたAWS Summit Japan 2025に参加してきましたので、その様子をお届けします！ ちなみに昨年の参加レポートブログもありますので、そちらもぜひご覧ください。 devblog.thebase.in 基調講演 基調講演は大盛況で、本会場はもちろん、サテライト会場もほぼ満員の状況でした！ AWSやAWSを利用しているパートナー企業の発表に加え、AIに関してはAnthropic社のプレゼンテーションなど、魅力的なトピックが目白押しでした！ サテライトだけどなんとか座れた！ 基調講演聴講します✌️ #AWSSummit pic.twitter.com/nYXHUW1h2J — 02 (@cocoeyes02) 2025年6月25日 おお！anthropic 日本オフィス開設 #AWSSummit pic.twitter.com/COh5DFCeYM — 02 (@cocoeyes02) 2025年6月25日 ブース 会場には様々な種類のブースが設置されており、AWSについて詳しく知ることができる「AWS Expo」や、各社のAWS活用事例を詳しく学べる「Partner Solution Expo」などがありました！ バーチャルデータセンターツアー面白かった！ 実際のAWSデータセンターをVRで見れる！空調とか発電機とか諸々実物見れるの面白い #AWSSummit pic.twitter.com/k9jBQ2LvAh — 02 (@cocoeyes02) 2025年6月25日 去年もブースみたchaos kitty! なんとwebアプリ機能ができた他、7 月中には AWS Samplesで公開予定とのこと！ 社内でやりたいなーーー #AWSSummit pic.twitter.com/QFS1snXt9h — 02 (@cocoeyes02) 2025年6月25日 ポーカーライクなゲームでAWSについて学べる#スマポ！ 会場では自分のスマホでプレイできるよ！ 体にパターンを叩き込む感じがあって反射でパターン出せるようになりそうで良い #AWSSummit pic.twitter.com/M1Qoldh7lK — 02 (@cocoeyes02) 2025年6月25日 ちいかわの隣にゴリゴリのAWSアーキテクチャ図あるのすき #AWSSummit pic.twitter.com/4W8Hh55fxh — 02 (@cocoeyes02) 2025年6月25日 GameDay ゲームのようにAWSを体験できるワークショップGameDayにも参加してきました！ aws.amazon.com 今回のGame Dayのテーマはgenerative AIで、AWSが提供している様々なAIサービスを中心とした内容となっていました！ あまりにもGameDay参加したい欲が強くて最前列取ってしまった #AWSSummit pic.twitter.com/RgryNMNEOO — 02 (@cocoeyes02) 2025年6月26日 GameDay参加していきます！！ #AWSSummit pic.twitter.com/GnZR4ZGV0x — 02 (@cocoeyes02) 2025年6月26日 惜しくも上位入賞はなりませんでしたが、個人的にはあまりキャッチアップできていなかった分野だったため、とても勉強になりました！ GameDay 8位/22チームでした！残念！ #AWSSummit pic.twitter.com/IGk1mlgqno — 02 (@cocoeyes02) 2025年6月26日 もらった公式ノベルティ また、先着配布のクッションやAWS認定ステッカーなど、魅力的なノベルティグッズも多数いただきました！ サテライトだけどなんとか座れた！ 基調講演聴講します✌️ #AWSSummit pic.twitter.com/nYXHUW1h2J — 02 (@cocoeyes02) 2025年6月25日 そういえばまだもらってなかったからAWS認定ステッカーもろた #AWSSummit pic.twitter.com/rs2GBx3s9z — 02 (@cocoeyes02) 2025年6月25日 Flight Tagもろた！ #AWSSummit pic.twitter.com/QdqKyHf2Pp — 02 (@cocoeyes02) 2025年6月25日 おわりに 他にもセッションに参加したり、コミュニティブースでのLTを聞いたりと、このブログで書ききれないほど様々なコンテンツを見て、学び、体験してきました！ やはりAWS Summitは、AWSについてキャッチアップするのに最適なイベントだと感じます。来年もぜひ参加したいです！ BASE BANK Deptでは、AWSにも触れるフルサイクルエンジニアを募集しています。 まずはカジュアル面談からどうぞ！ open.talentio.com open.talentio.com binc.jp

はじめに 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コミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。