こんにちは！レバレジーズでリードエンジニアのゲンシュンと申します！ レバレジーズにデータエンジニアとして転職して、ちょうどまる2年が経ちました。今はデータエンジニアチームのリーダーとして、メンバーのマネジメント評価育成、全社横断のデータ分析基盤やETLの構築、データ系職種の組織づくりといったデータエンジニアのお仕事をしつつ、全社の技術力の底上げや文化醸成を担うリードエンジニアとして、アプリケーションエンジニアとDDD勉強会を開いたり、技術広報、社外イベントの企画・登壇、さらには社内エンジニアイベントの運営まで、かなり幅広いお仕事をしています。 社内にはリードエンジニアがあんまり多くないので、 レバレジーズのリードエンジニアってこんなことやってるよ！ の紹介も兼ねて、この2年目にチャレンジしたことを振り返ります。 データエンジニアとしてのお仕事 データ環境について レバレジーズはレバテック、レバウェル、キャリアチケットなどたくさんの事業を展開していて、日々大量のデータが生まれ、使われています。入社して最初に驚いたのが、 営業の方1000人以上が毎日各自でSQLを書いて勝手にデータを利活用していることです。 「データ利活用を推進しましょう！」みたいなフェーズはとっくに過ぎていて、現場で当たり前のようにデータで意思決定しているんですよね。 それ自体はすごく良いことなんですが、「みんなが自由にデータを触っている」からこその大変さもあります。データの品質担保やガバナンス、基盤の安定稼働やコスト削減など、利活用が進んでいるからこそやらなきゃいけないことがたくさんあります。 データ系組織については、大きく2つの組織に分かれています。自分が所属するシステム本部テクノロジー戦略室は、ETL処理の安定稼働などデータの生成側に近いエンジニア組織です。一方マーケティング部のデータ戦略室は、DWH以降のデータ整備やBI接続、分析・利活用など事業部に近い組織で、データアーキテクトと呼ばれるメンバーが在籍しています。エンジニアではなくマーケターなんですよね。 つまり、 レバレジーズのデータ系職種はエンジニアとマーケターの混合チームで構成されていて、全員がエンジニアではない。 これが後で話す技術選定や組織の話にも大きく関わってきます。この2つの組織が協業しながら、さらに各事業部とも日々やりとりしてデータ基盤を支えているので、関わる人が本当に多い環境です。直近やったことは 2025年のレバレジーズのデータ活用基盤 にまとまっているので、興味のある方はぜひ。 2年目でやったこと データ基盤周りのお仕事の概要だけざっくり紹介します。 Dataform Assertionの全事業導入 データ分析基盤のデータ品質が担保されていないという課題に対して、Dataformのassertion機能を使った品質チェックを全事業に導入しました。1事業について成功パターンを作り、データアーキテクトの皆さんの力を借りて全事業へ横展開できましたね！展開中、約半数のテーブルでエラーが検知されるという修羅場もありましたが。。。笑、AIを活用してエラー分析を効率化しながら全事業への導入を無事完遂！一緒に進めたメンバーが Dataformでのデータ品質担保の運用の工夫 を記事にしてくれています。 Salesforce周りのデータ連携 Salesforceの連携周りは、データエンジニアにとって悩みの種かと思います。2025年はデータ量とカラムの急増で、Cloud Run Jobsなどの性能限界を超えるリスクがあったんですが、Cloud ComposerのDeferrable機能を検証・導入したり、メモリ不足やタイムアウトを検知できる体制を整え、結果として大規模データ連携も安定稼働しております。Data Engineering Summitの前夜祭でこのあたりの話をしたので、気になる方は CloudComposerによる大規模ETL 「制御と実行の分離」の実践 をぜひ。 担当事業の課題解決に深入り 自分は全社横断に関するデータ分析基盤の設計に加えて、いくつか担当事業も持っております。データ系組織がすべての事業を見ているわけではなく、現場メンバーが各々で回してきた基盤を途中からデータ系組織が引き取り、事業担当として担うこともあります。 自分が引き継いだ基盤は、いつどこで何で更新されているのか誰も全体像を把握できておらず、見る場所によって数値が微妙に違う状態。クエリの精査と、1000行超えSQLの考古学を繰り返しながらデータモデリングを見直しつつ、新規にデータマートを作り直しました。巨大SQLの考古学については、自分なりに意識していることを 巨大SQLに対する解読術 でまとめたので、気になる方はぜひ・・、昨今だとAIに全部聞けば解決しちゃいそうですけど・・笑。 また考古学だけでなく、その部署の各職種の業務のお困りごとや何がしたいのか？何が出来ると嬉しいのか？を事業部長に毎週ヒアリングしながら、業務支援に繋がるStreamlitで作ったツールの提供などチームで課題解決に取り組んでいます。 他にも全社のクラウドコスト削減の旗振り役、全社マスターデータマネジメントの基盤立ち上げ、AI Readyな基盤作りに向けた方向性決めなど、データに関わることは大体なんでもやっていますね！！ 技術選定について データ分析基盤ではdbtやディメンショナルモデリングがデファクトになりつつありますが、レバレジーズでは意図的に今は採用していません。 さきほどデータ環境の紹介で書いた通り、レバレジーズのデータ基盤はデータエンジニアとデータアーキテクトが支えています。事業に入り込めているデータアーキテクトと、SQLを書ける現場という圧倒的な強みがあり、一足飛びの技術選定はこの強みを壊しかねないと思っています。 そもそも 「dbtを使ってない」「ディメンショナルモデリングを使ってない」こと自体が課題解決につながるわけではないんですよね。 じゃあ何が課題なのか。いろいろヒアリングした結果、開発環境が良くないことだったり、事業課題に向き合う時間がさけていなかったり、そっちの方が本質的な課題だったりします。dbtを採用することでしか解決できない課題で今苦しんでいるわけではない。技術はあくまでも手段なので、まずは手前の課題から段階的に解いて、「最強の戦略を採用できる状態」を目指している最中です。 この「最新技術を"今は選ばない"」という話は、 みんなの考えた最強のデータ基盤アーキテクチャ で 登壇 した際にも話しているので、詳しくはそちらをどうぞ。 組織のあり方について リードエンジニアというと「技術で引っ張る人」というイメージを持たれがちなんですが、組織設計にもかなり向き合いました。 さっき紹介した通りレバレジーズのデータ組織は、データエンジニア（システム本部）とデータアーキテクト（マーケティング部）という機能軸で分かれています。それぞれに強みがある一方で、組織の分業がそのまま開発体験に現れる、いわゆるコンウェイの法則も見えてきました。データエンジニアは事業から遠く、依頼を受けて作る受発注の関係になりがち。データアーキテクトは事業に入り込めている反面、エンジニアリングの支えがないと生産性が頭打ちになる。などなど。 機能軸の組織はそのままに、事業軸の動きを重ねることから始めました。データアーキテクトとエンジニアの壁打ち枠を作ったり、マーケティング部のプロジェクトにエンジニアが入る体制を作ったり、事業ドメインを軸にデータの入り口から出口まで一気通貫で見る動きを増やしたり。正確に言うと、もともと事業に入り込めているデータアーキテクトの側に、事業から遠かったデータエンジニアを引き込んでいった形です。 AIの登場で、この動きは更に重要になっていると感じています。今は 「AI Readyなデータ基盤」をテーマに、AIがデータを使える状態と、人がAIを使って分析できる状態の2軸で取り組みを進めています。 例えば、マーケターがClaudeからMCP経由で直接BigQueryを触れるようにするPoCでは、権限やコストのガードレールを設計した上で開放しました。AI向けに設計方針やドメイン知識を集約したリポジトリを整備してチームに配布したりも。 地道な人間関係づくり データエンジニアのお仕事って、依頼ベースのものがどうしても多いんですよね。「データが出ない」「ダッシュボード壊れた」「このデータ連携したいんだけど」みたいな要望が各事業部から日々やってきます。 前職は社員数が100人前後、自分の在籍期間も長かったので、人間関係のコンテキストが解像度高く働きやすかったんですよね。一方レバレジーズはオフィスは複数あるし、事業もたくさんあるし、社員数は4000人超え。データ系は俺に任せろぉ！と叫びたい所ですが「お前誰だよ」状態なんですね笑。 本当に地味なんですが、依頼をくれた人との関係をまず丁寧に広げていきました。定期的に本社や他のオフィスに足を運んで、依頼をかけてくれた人の座席に行っておしゃべりしたり、ランチ行ったあとに「俺に合いそうな人つなげてください！」と無茶振りしたり、一時期はこんな感じで「Gランチ募集！」と1〜2ヶ月でマーケティング部の人40人くらいとランチに行った時期もあります笑。 この画像貼りまくってランチ募集してました 他にも社内にはたくさんの部活動がありまして、ボードゲーム部などを通じて色々輪を広げたり。自分はお仕事で絡んだことある人とボドゲお誘いしたり、自己紹介ページなどで共通の趣味がありそうな人を見つけては声をかける、みたいなことを地道にやってましたね・・！ ボードゲーム部のクリスマス会 地道ですけどこうやって 「こいつに聞けば、誰かにつなげてもらえるかも」という認知をちょっとずつ獲得していって、現場の課題感を生の声で聞けるようになったり、自分が困った時に相談できる人が増えていきました。 さっき書いた「組織をどう動かすか」みたいなお仕事も後述する技術広報のお仕事も、色んな人にたくさん相談の上成り立っているので、この土台がなかったら絶対に出来ていないと思います。 組織内の技術の底上げ データ組織向けにも、事業横断のアプリケーションエンジニア向けにも、いろんな場を作ってきました！ ディメンショナルモデリング輪読会 アーキテクトと合同で、アジャイルデータモデリング本の輪読会をしました。一通り読み終えた後に参加者にヒアリングしたら「ある程度理解はしたけど、具体的にどう実務に活きるのかわからない」という声が多かったので、実際の事業のデータソースを使ってdim/factを実装する実践ワークショップを開催しました！詳しくは 記事にまとめています 。 VSCode × GitHub Copilotワークショップ データアーキテクトの皆さんは基本的にDataformをコンソール上で開発しております。非エンジニアでも開発出来るメリットはありつつも、AIが普及した今、コンソールでの開発は恩恵を受けられないので、開発効率が高くない状態でした。VSCodeエディタの導入からGitHub Copilotによるコード生成、ローカルからのDataformコンパイルまで、段階的に取り組めるワークショップを設計して、みんなで取り組みました。結果としてコンソールを使わずローカルで開発が完結する状態を体験してもらうところまで持っていけました！ アプリケーションのリファクタ予備校 AIでWebアプリやツールがサクッと作れる時代になりました。とはいえ、出てきたコードをちゃんと理解して、設計判断を自分の言葉で説明できる力は欲しいよね？ということで、TypeScriptでゼロからアプリを作るお題を自分で用意して、それを叩き台にコードの言語化を徹底的にやってもらう育成業務（通称「予備校」）をメンバー向けに開講しております。AI時代にとってこれが意味がない可能性もありますが。。笑 他にも最近はAIエージェントをみんなで作ってみる連載型ワークショップも走らせています！横串で色んな事業のエンジニアを巻き込んで、みんなのできることを少しずつ増やしていく。こうやって組織全体で土台を作っていくプロセスが大事だと思ってます！ DDD勉強会 レバレジーズには色んな開発部があるのですが、開発部横断で何か勉強会や技術の取り組みがそんなになくて、非常に勿体ないと感じてました。いろんな開発部でTypeScript採用しているので、TypeScriptを使った技術力底上げ施策を色々やりました。 その中でも一番濃かったのがDDD(ドメイン駆動設計)の勉強会です。なんでデータエンジニアがやってんのって話なんですが、前職アプリケーションエンジニアで、設計の議論に学びが多かったので、レバレジーズでもやりたいなと。 「自分の考える設計意図を、自分の言葉で相手に納得させる力をつける」をゴールに 、複数事業のエンジニアを集めて勉強会を主催しました。よくあるECサイトをお題として用意し、普段の業務では関わらない各事業のアプリケーションエンジニアと色んなディスカッションができました。 社内イベントから社外発信まで 社内エンジニアイベントの企画・運営 年に2回、全エンジニアが集まる「テックフェス」という社内イベントがあるのですが、それの運営委員として参加しました。 夏はAIハッカソンの企画をしたのですが、テーマ、評価項目、体験設計、当日の進行、とにかく細部までこだわった企画でした。そのおかげもあり非常に盛り上がったイベントとなり、満足度は驚異の96%！笑。 YouTubeでも動画化 されてます。 冬はセキュリティがテーマで、自分はハッキングされた体の広報サイトを企画しました。 当日の様子は テックフェス2025 夏レポート や テックフェス2026 冬レポート のレポートをどうぞ。 テックフェス運営委員会の皆さん 社外登壇・イベント企画・モデレーター 社外にもいろいろ出ております！レバテックLabやレバテックMeetupでは、モデレーターや登壇を平均すると月1回ぐらいやらせてもらいました。領域はデータエンジニアだけでなく、フロントエンド、React、AI駆動開発など多岐にわたるテーマに関わらせていただきました。登壇者選定もやらせてもらってます。特定の人だけが出るのではなく、色んな事業部、若手に登壇してほしいな〜と思って、色々声をかけていますね！ レバレジーズ外だと、データエンジニアコミュニティであるdatatech-jpという所で「みん強」というデータ系イベントを企画、運営しています。直近1年間の取り組みだと、オフィスをお借りしてオフラインイベントを開いたり、SnowflakeというAIデータクラウドの会社の日本支社オフィスをお借りしてコミュニティイベントを開いたり、データエンジニア界隈の盛り上げを様々な切り口でチャレンジしてます！ 技術広報 こうした社外活動が多かったこともあり、2026年からはレバレジーズ全体の技術広報も始めました！自分が掲げるミッションは 「発信を当たり前にする文化を作る」と「レバレジーズのエンジニア組織をもっと皆さんに知ってもらう」 の2つです。 自分だけじゃなくて色んなエンジニアをとにかく外に出すこと、登壇や執筆をお願いしたり、イベントの企画や運営を体験してもらったり、EMConf2026やTSKaigi 2026などのブース出展を手伝ってもらったり。ブース出展では、展示内容や導線などをみんなで議論しましたね。この辺りの活動は 技術活動レポート に四半期ごとにまとまっています。 今年のEMConfとTSKaigiは、agile effect事業部の皆さんと各事業部のエンジニア合同でブース出展しました。 agile effect事業部と合同でTSKaigiに参加 とはいえ、いきなり社外に登壇ってまぁまぁハードルは高いと思うので、まずは社内で気軽にアウトプットできる場を作りたいよね〜ということで社内テックブログ「ぷれぽす」を自作するプロジェクトに参加しました。自作でテックブログを作る取り組みで、設計から実装も自分たちでやっています。詳しくは この記事 。 アウトプットって特別なイベントじゃなくて日常であってほしいんですよね。 勉強会で話したことが記事になり、記事が登壇になり、登壇を見た誰かが入社してくれる。そういう「発信が当たり前」の文化を醸成していきたいなと思っています。いろんなイベントに出ていくので、見かけたらぜひ声かけてください！！ まとめ 改めて1年間振り返ったんですが、お仕事の幅が想像以上に広がった2年目でした！ リードエンジニアの役割は、技術実装だけでなく組織全体の技術力向上や事業横断での課題解決、社外発信など幅広い役割を担うポジションです。お仕事の幅が広がったのはこの肩書のおかげではなく、 色んな事業部のいろんな職種のメンバーがお互いに関心を持って関わり合っているからだと思ってます。 データ基盤も、チームも、組織の動き方も、社外への発信も、課題を見つけたら全部お仕事にできて、色んな人を巻き込める、毎日が刺激的な環境です。 データエンジニアとして転職して、データエンジニアだけじゃなかった2年でした。3年目はもっとおもしろくなりそうなので、これからも楽しくやっていきます！

はじめに この記事は、BASEテックブログ夏のブログリレー11日目の記事です。 BASE Dept. Product Divにてバックエンドエンジニアをしている オリバ です。 ショップオーナーの発送領域を担当しており、バックエンドを中心に、フロントエンドやNew Relicなども触っています。 2026年5月、担当する「送り状一括印刷 App」の一部機能をリリースしました。しかし、リリース後に分かったのは、想定していた使われ方をされていないということでした。機能自体は動いていますが、開発チームが想定していた操作と、ショップオーナーの実際の操作が違っていました。 Appの概要や使い方は以下をご覧ください。 送り状一括印刷 App（BASE Apps） apps.thebase.com 発送作業の時間を大幅削減！「送り状一括印刷 App」の使い方解説（BASE U） baseu.jp 本記事では、顧客の声を開発の意思決定に組み込むために実践した3つの取り組みと、その効果について共有します。 顧客中心主義とは 私は仕事の中で「顧客中心主義」という考え方を心掛けています。『みんなでアジャイル』で知った言葉です。 この本では、組織全体でアジャイルを実践するための原則として、次の3つが紹介されています。 「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」 引用：みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた｜O'Reilly Japan www.oreilly.co.jp もともと私はDDDやクリーンアーキテクチャが好きで、設計に関心がありました。これらは変更容易性を高めるための手段でもあり、いわばHOWにあたります。ただ、HOWをいくら磨いても、何を作るかというWHATとなぜ作るのかというWHYが定まっていなければ成果にはつながりません。自分にはこのWHATが足りていないと感じ、顧客中心主義を実践しようと思いました。 とはいえ、言葉として知っていることと、日々の開発で実践できているかは別です。 なぜ顧客の声を聞きに行ったのか 以下の3点が理由です。 1. 開発チームだけではユースケースの想像に限界がある 新機能の開発時、その機能が使われるユースケースを開発チームだけで想像していました。しかし、ショップオーナーが発送作業の際にどの画面を見て、何を基準に判断しているのかは把握できていませんでした。 2. チームが向かう方向を決めるきっかけにしたかった 私は送り状一括印刷App開発のPJMを務めており、チームが向かっていく方向づけも担っています。「この機能を今すぐ開発すべきなのか、本来の趣旨から外れているから後に回すべきか」といった判断を、顧客の実態をもとに行いたいと考えました。 3. AIの導入で実装スピードが上がり、PDCAを回したかった 開発にAIを導入したことで、実装スピードが上がりました。ただし、作るスピードが上がっても、何を作るかの精度が上がらなければ効果は限定的です。リリース後の反応を早く拾い、次の改善につなげるサイクルを回したいと考えました。 実践① ユーザーインタビューに同席する PdM・デザイナーが実施するショップオーナーへのユーザーインタビューに、3〜4回同席しました。聞くだけではなく、私からもいくつか質問をしています。 想定していた動線と実際の動線が異なっていた 送り状一括印刷 Appでは、お届け先住所の初期値に購入者がカートで入力した住所情報が、送り主情報の初期値にAppの設定画面で登録した住所情報が設定されます。個別に変更したい場合は、注文画面の送り状印刷アイコンからモーダルを開いて変更できます。 しかしインタビューでは、このモーダルの存在に気づいてもらえておらず、「お届け先住所と送り主情報の初期値は変更できない」と認知されていることが分かりました。 注文画面の送り状印刷アイコン（2026年9月時点） 送り状印刷アイコンから開く「送り状内容」モーダル（2026年9月時点） 発送通知の失敗が把握しづらく、独自運用で補われていた 発送通知に失敗しても、ショップ側で後から把握しづらい状態になっていました。そのため、注文メモなどを使った独自運用で補っているケースがありました。 エラーの有無だけでなく、対象の注文・失敗理由・次に取るべき行動を後から確認できる必要があると考えています。 注文画面が発送判断の中心的な画面になっている インタビューを通じて、注文画面がショップの梱包・発送を判断するための中心的な作業画面になっていることが分かりました。メンバーシップ特典など、発送判断に必要な情報は注文画面上で確認・検索できるとよいと考えています。 発送判断の中心となる注文画面（2026年9月時点） 細かな改善でも現場の制約を解消できる 問い合わせで挙がっていた要望をもとに、送り状一括印刷 Appで印刷位置を指定できるようにしました。その後のユーザーインタビューでは、この改善についてショップオーナーから感謝の声をいただきました。大きな機能追加ではなくても、現場の制約を解消する改善には実用的な価値があると感じました。 同席して分かったこと 開発者には自明なアイコンや操作でも、初めて使うショップには意図が伝わらない場合がある UIだけでなく、ツールチップや画像付きヘルプなども含めて使い方を伝える必要がある ショップオーナーの利用実態や反応を直接知ることが、開発の目的と価値の再認識につながる 実践② 問い合わせ内容を定期的に確認する BASEのショップ管理画面には問い合わせフォームがあります。このショップオーナーから寄せられた問い合わせを、定期的に確認するようにしました。 開発中・リリース直後の機能は週に数回確認する 開発中の機能やリリースしたばかりの機能については、週に数回確認しています。ユーザーインタビューと違って日程調整が不要なため、リリース直後の反応をすぐに拾えます。 SLI/SLO振り返り会のアジェンダに組み込む 個人が気の向いたときに見るだけでは、見る人と見ない人が分かれ、チームの判断材料になりません。そこで、Order Sectionで月1回実施しているサービスレベル（SLI/SLO）振り返り会のアジェンダに、顧客の声を確認する時間を組み込みました。 SLI/SLOの数値は、システムがどれだけ安定して動いているかを示します。しかし、その数値が顧客にとって十分かどうかは、数値だけでは分かりません。同じ場で顧客の声を扱うことで、指標と実態を突き合わせて話せることを狙っています。 見つけた声はSlackでチームに共有する 送り状一括印刷 Appについては、PdMと私が問い合わせ内容を見て、気になった声をSlackでチームメンバーに共有しています。現状はこの形で回っており、メンバー全員がDBを見に行く状態にはなっていません。 実践して分かったこと 送り状一括印刷 Appにおいて、想定した使い方がされていないことをすぐに認知でき、改修からリリースまでのサイクルを短く回せた。アジャイルの利点が出た部分だと感じている SLI/SLOのエラーバジェットの数値が安定していても、ショップオーナーの希望を満たせているとは限らないことが分かった 実践③ CXチームにヒアリングする CXチームは、ショップオーナーと継続的にコミュニケーションを取りながら、ショップ運営の課題解決や「BASE」の活用を支援するチームです。このCXチームにMTGの時間をもらい、ヒアリングをしました。 非機能要件の課題を見つける目的で声をかけた CXチームが担当するショップオーナーの中には、規模の大きいショップも多く含まれます。注文・発送領域のパフォーマンスなど、非機能要件の課題を見つけられるのではないかと考え、声をかけました。 実践①のユーザーインタビューや、実践②の問い合わせ内容で拾えるのは、使い方や機能に関する内容が中心です。一方で、表示速度のような非機能要件の話は、問い合わせとして上がってこないこともあります。 開発チームからは見えていなかった課題を把握できた ヒアリングを通じて、開発チームからは見えていなかった非機能要件の課題を把握できました。具体的な内容はここでは割愛しますが、実践②で書いたとおり、SLI/SLOを見ているだけでは気づけない内容でした。 単発のMTGから継続的なやり取りへ ヒアリングのMTG自体は一度だけですが、その後もCXチームとのやり取りは続いています。 実践して分かったこと 非機能要件の課題は、ショップオーナーと日常的に接しているチームのほうが実態を把握している場合がある エンジニアから他部署に声をかけることで、一度のヒアリングだけでなく継続的な相談先ができる 何が変わったか 改善タスクの起票数が増えた Order Sectionには複数チームがあり、私が所属するチームでは、注文画面や発送領域に関する改善タスクの起票数は、以下のように変化しました。 2〜6月：月2〜4件 7月以降：月7〜8件 7月ごろにユーザーインタビューを実施し、そこで得た内容をもとに課題の洗い出しから起票、実装、リリースまでを行いました。顧客の声を聞くことで、これまで見えていなかった課題が可視化され、タスクとして起票できるようになったことが大きいと考えています。 エンジニアから提案してタスク化する場面が増えた これまでは、Bizチームや顧客問い合わせの多さを鑑みて、別部署から依頼された案件をタスク化していくことが多かったです。顧客の声を直接知るようになってからは、エンジニアからPdMやデザイナーに提案し、タスク化して改善につなげる場面が増えました。 職種を越境して、主体的に改善タスクを推進できるようになったことが、今回の一番大きな変化だと感じています。顧客の声が、何を作るかを決める際の材料として開発の意思決定に入るようになった、とも言えます。 うまくいかなかったこと 課題が可視化され、AIによって実装も速くなっていたため、タスクを並列で進めようとしてしまいました。結果、自身が疲弊しました。 顧客の声を聞くと、改善すべきことは確実に増えます。実装スピードが上がったことで、「やれるはず」と思ってしまったのも原因だと考えています。声を集める仕組みだけでなく、集まったものを絞る側の判断も必要だと感じています。 これからやりたいこと BASEコミュニティ Meetupに参加する 弊社ではショップオーナー向けのコミュニティポータルを運営しており、その一つの取り組みとしてBASEコミュニティ Meetupを開催しています。 BASEコミュニティポータル community.thebase.com 前回はこちら：BASEコミュニティ Meetup vol.15 大阪（2026年8月開催） community.thebase.com 今後は運営側としてこの場に関わり、ショップオーナーの声を直接聞いて発送領域の改善につなげていきたいです。 非機能要件の課題をもっと洗い出す CXチームへのヒアリングで、非機能要件の課題は開発チームから見えにくいことが分かりました。機能要件だけでなく、非機能要件の課題を洗い出して改善していきたいと考えています。 おわりに 本記事では、顧客中心主義を開発の意思決定に組み込むために実践した3つの取り組みを紹介しました。 開発チームの中だけで顧客の使い方を想像していた状態から、顧客の実態をもとに改善を提案できる状態に変わりました。ただし、可視化できてきたのは機能要件に関する要望が中心です。非機能要件の課題はまだ隠れているものが多く、これをどう見つけていくかが今後の課題です。 弊社では、顧客の声をもとにプロダクトを改善していくことに関心のあるエンジニアを積極採用しています。興味を持っていただけたら、ぜひ下記からご応募ください！ binc.jp 明日は、BASEテックブログ夏のブログリレーのラストを飾る、rerenoteさんの記事です。お楽しみに！

「だいたい○○ケースくらいですかね」の正体 テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。 正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。 これで困るのは3つの場面。 初めての領域。 過去実績がないから「だいたい」が通用しない 説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない 精度のばらつき。 見積もる人によって2〜3倍の差が出る 結局、見積もりの「勘と経験」の中身を分解してみたら、ちゃんと数式