こんにちは。株式会社エス・エム・エスの人材紹介開発グループの藤井と申します。 以前、看護師向け人材紹介サービス「ナース専科　転職」のWEBエンジニアとして取り組んだスクラムの改善についてご紹介しました。 現在は、複数のWEB開発チームを横断して伴走する「イネイブリングチーム」の立ち上げと推進を担っています。 本稿でご紹介するのは、このイネイブリングチームの立ち上げから現在までの半年間です。この半年で、私たちは自分たちのスコープを一度大きく変えました。何を考えて始め、何をきっかけに、どう変えたのか。まだ道半ばの取り組みですが、考えたことを残しておきたいと思います。 ※本稿では、WEB開発を担当するエンジニアのチームを「開発チーム」、主には集客に責任を持ちつつ事業成長をミッションとするマーケティング組織を「マーケ」と呼ばせていただきます。 イネイブリングチームを立ち上げるまで 当社には、医療・介護などの分野で職種ごとに複数の人材紹介サービスがあり、それぞれにWEB開発のチームがあります。 各チームは、担当するサービスの事情に合わせて運用を磨き込んできました。マーケが施策を立案し、開発がそれを確実に形にする。役割が明確なぶん速く回せる進め方で、これまでの成果はその積み重ねの上にあります。 受け取って作る、から、一緒に事業を伸ばす へ 一方で、依頼を受けて実装するところに軸足が置かれていると、開発側が施策の「なぜやるのか（Why）」に踏み込む機会は限られていきます。見方を変えれば、次のような伸びしろがありました。 施策の背景や期待する成果を、着手する前にもっと深く握れる 作ったあとの効果を見届け、そこで得た学びを次の施策に活かせる 各チームが積み上げた工夫を、他のチームへ流していける 長く取り組んできた開発基盤の整備が一段落し、これまでより速いペースで改善を重ねられる土台が整ってきたタイミングでもありました。そこで次の段階として、 開発組織も事業責任を担い、マーケと一緒にサービスを改善して事業を成長させる状態 を目指すことにしました。 進め方の言葉にすると、変えたいのはここです。 これまで これから Why（なぜやるのか） マーケが定め、開発は依頼として受け取る マーケと開発で一緒に考える What（何を作る・試すか） 依頼の内容として決まっている 優先度も成果指標も一緒に決める How（どう作るか） 開発が担う 開発がリードする（ここは変わらない） WhyとWhatに開発が入っていくぶん、マーケにとっても技術観点からの提案を受け取りやすくなり、結果を一緒にふりかえりやすくなります。どちらか一方のための変更ではなく、双方に利のある形にしたいと考えていました。 立ち上げ時に置いた2つの方向性 以上を踏まえ、立ち上げ時の方向性は大きく2つとしました。 各 WEBチームの接続を強める — 違いを整理して見える状態にし、学びを橋渡しする マーケと一緒に Why から考えていける組織をつくる — 開発も事業成果に責任を持つ前提で、Whyから並走する 「イネイブリングチーム」という名前はどこから来たか この2つを進める役割として立ち上げたのが、イネイブリングチームです。名前も考え方も、 『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター） をもとにしています。 同書では、組織のチームを4つの基本タイプで捉えます。私たちの状況に当てはめると、各サービスのWEB開発チームは、ユーザーとビジネスへの価値提供に責任を持つ ストリームアラインドチーム にあたります。そして イネイブリングチーム は、ストリームアラインドチームが自律的に動けるよう、特定の領域で能力のギャップを埋める役割を担うチームです。 ここで最初に握っておいたのは、 代わりにやってあげるチームではない ということでした。同書でも、イネイブリングチームは支援する相手の作業を肩代わりするのではなく、相手が自分でできるようになることを目的とし、その関わり方も恒久的なものではないとされています。 この前提を先に置いたことが、後々まで判断の支えになりました。実際、チーム指針には「やらないことリスト」を用意し、その先頭に「各チームの代わりに、要件定義やバックログ整理を全部代行する」を置いています。成果は「自分たちで作った量」ではなく「各チームが自走できるようになったか」で測る、とも決めました。 こうして、決める立場ではなく各チームの隣で一緒に走る存在として、少人数のチームで活動を始めました。 なお、このあとご紹介するスコープの変更を経て、現在の私たちの実態は同書の定義そのままではなくなっています。その点は後半で改めて触れます。 最初の半年でやったこと ここからは、各チームへの働きかけとして実際に手を動かしたことを3つご紹介します。 1. まず「知ること」から始める いきなり共通化に進まず、各チームのリーダーへのヒアリングと定例への参加から始めました。あわせて、開発メンバー向けの説明会とマーケの皆さんとの対話会も実施し、目標・運用・強み・困っていることをフラットに聞かせてもらいました。 ヒアリングを重ねて分かったのは、チームごとに置かれた状況がかなり違うということでした。連携が成熟しているチーム、短期の目標がきびしいチーム、組織の再編が進行中のチーム。同じ型を同じ速度で当てはめてもうまくいかないことは明らかでした。 そこで、進め方の原則を3つ決めました。 どこまで踏み込むかの線は、暫定版から磨く — 机上で書き切らず、現場を見ながら更新していく前提で置く 抽象的な線引きより、1件の事例を先につくる — 実際にうまくいった例のほうが、話が早い 対象を絞って厚く入る — 全チーム同時展開はしない。成功確率の高いところに集中する 型から入らず、まず聞くことに時間を使ったからこそ、どこにどう入っていくかを、机上の想定ではなく各チームの実態に合わせて決められました。 2. 課題管理のフォーマットを揃える チームごとに起票の粒度や指標の定義が異なると、他チームの取り組みから学ぶことが難しくなります。そこで、管理のためではなく「お互いの工夫から学べるようにするため」という目的で、課題管理のフォーマットを共通化しました。 課題種別（機能開発／仮説検証／技術改善／調査／保守運用／不具合対応）を定義する サイズ・ターゲット・期待される効果の大きさ・緊急度などを、数値型ではなく選択リストで持つ 起票時にWhyを必ず言語化する運用に揃える 「そもそも何を課題として起票するか」の基準も言語化する（1行の修正まで起票するのか、など） 全チーム一斉ではなく、準備の整ったチームで先行導入して検証する 自由入力ではなく選択リストにしたのは、あとから比べられるようにするためです。自由に書けるほど記述は豊かになりますが、その代わり集計の段階で揃わなくなります。 もうひとつ、フォーマットを配っただけでは良い課題が自然に起票されるわけではない、という指摘がチーム内から出ました。起票の質は、書き手の慣れやそのときの時間の余裕に左右されます。そこで、導入したチームのリファインメントへ一緒に入って伴走しつつ、初稿づくりや一次レビューへAIを組み込む運用も試しています。人の指摘に頼らず一定の水準へ引き上げられれば、書き手の負担も、指摘する側の気疲れも減らせると考えました。 「比べられる状態」ができたことで、他チームの施策や学びを参照しやすくなりました。共通化するのは土台だけで、各サービスの戦略や専門性はそのまま維持しています。 3. 登録した先まで、ユーザーの体験を通して見られるようにする 私たちが担当している人材紹介サービスは、求職者がWEBサイトから登録したあと、キャリアパートナーが求人のご紹介や選考のサポートを行い、入職して働き始めるところまでがひと続きの体験になっています。WEBサイトはその入り口であり、登録は通過点にすぎません。ユーザーにとって本当に大事なのは、納得できる職場と出会えたか、入職して働き続けられているかです。 ところがデータの上では、登録の前と後が分かれていました。WEB側で見えるのは登録までの動きで、その先で何が起きたのかは別の場所にあります。これでは施策の評価が「登録がいくつ増えたか」に寄り、良い出会いにつながったのかどうかは見えません。 そこで取り組んでいるのが、 登録の前後を串刺しにして、ひと続きの体験として分析できる状態をつくること です。これが一本の線でつながると、「登録を増やす」ではなく「良い出会いにつながる登録を増やす」ほうに目標を置き直せます。あわせて、サービスごとに数え方の異なる指標の定義を揃えることも進めています。 この取り組みで大きかったのは、 データ基盤を担当するチームと組んで進められたこと です。同じ時期に近い領域の設計が両側で進んでおり、そのままではつながらないものが2つできるところでした。早い段階で合流し、こちらから叩き台を持ち込む形で、受け持つ範囲とデータの受け渡し方を一緒に決めていきました。 現在は、まず1つのチームで実装を進めているところです。ここが終わった段階で狙いどおりの状態になったかを検証し、他サービスへの横展開を検討します。 1つの基盤を一緒に設計したことで、データ基盤チームとの間に、細かいことでも聞き合える関係ができました。横断で取りにいく価値は、成果物そのものだけではありませんでした。 転機：『TRANSFORMED』の読書会 こうした取り組みを進めていた頃、プロダクト開発に関わる組織が向かう先として、 プロダクトオペレーティングモデルへの転換 という方向性が示されました。その考え方のもとになっているのが、 『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（マーティ・ケーガン 著／横道稔 訳、日本能率協会マネジメントセンター） です。 そこで、人材紹介開発グループでも『TRANSFORMED』の読書会を行いました。 読書会を通じて私たちが受け止めたのは、 エンパワーされたチームは「文脈 × 能力」で成り立つ という考え方です。能力だけを引き上げても、向かう先が共有されていなければ「上手に、けれど違う方向へ進むチーム」になりかねません。逆に言えば、「なぜこの課題を解くのか」が届いて初めて、現場は「何をやらないか」を自分で判断できるようになります。 この観点で自分たちの半年をふりかえると、私たちが手厚く支援していたのは 能力の側 でした。フォーマットを揃える、リファインメントに伴走する、分析の土台を整える。どれも必要なことですが、文脈の側には十分に手が届いていませんでした。 スコープを、より上位レイヤーへ この半年で変わったことのひとつに、入ってくる情報があります。 横断で動くようになったことで、各チームのリーダーやマーケ、データ基盤のチームと話す機会が増えました。それに加えて事業やプロダクトの方針を決める意思決定者とのやりとりの頻度も上がり、これまで自分たちのところまで届いていなかった、より上のレイヤーで何が議論されているのかが見えるようになりました。 両側が見えるようになって、はっきりしてきたことがあります。 戦略は確かに存在している。ただ、それがメンバーの手元に届いて、日々の判断の材料になっているとは言いにくい状態だった ということです。 意思決定者が持っている検討の背景や根拠は、現場には決まった結論の形で届きます。その手前にある「なぜこれを選んだのか」までは共有されにくく、メンバーが自分の言葉で語れるところまでは届きません。 半年の活動を通して見えてきたボトルネックは、ここでした。 上位レイヤーで考えた戦略がメンバーの手元まで適切に降り、メンバー自身で成果へコミットできる体制になっていないこと 。いくら進め方の型を整えても、ここが埋まらないかぎりは近づきません。私たちが最初に置いた「各チームの進め方を支える」というスコープは、このつなぎ目そのものには届いていませんでした。 そこで、イネイブリングチームのスコープをより上位レイヤーへ変えることにしました。「翻訳」の役割を強め、意思決定者との方針すり合わせを密に行いながら、組織にとっての最善を判断して行動する、という立ち位置です。 これまで これから 主に見る層 各チームの進め方・運用 戦略と現場の意思決定のつなぎ目 果たす役割 型と仕組みを整えて伴走する 戦略を翻訳し、現場の意思決定に接続する 意思決定者との関わり 決まった方針を現場に届ける 方針そのものをすり合わせ、組織にとっての最善を判断する 方向を変えたというより、 どのレイヤーに手を入れるかを変えた という感覚に近いです。能力側の支援をやめたわけではなく、まだ誰も手をつけていなかった文脈側を、空白として引き受けることにしました。 「イネイブリングチーム」の定義から離れている点について 前半でご紹介したとおり、私たちのチーム名と出発点は『チームトポロジー』のイネイブリングチームにあります。ただ、スコープを上位レイヤーへ変えたことで、 同書の定義をそのまま当てはめると、実態はかなり違うものになってきています 。 同書のイネイブリングチームは、特定の領域における能力のギャップを埋めることに焦点があり、支援する相手や期間を区切って関わり、役目を終えたら離れていくことが前提とされています。一方で今の私たちは、戦略の翻訳や意思決定者との方針すり合わせ、プロダクトビジョンの言語化、体制の設計といったより上位の層に軸足を移しています。特定の能力を一定期間で引き上げて離れる、という形からは離れ、担い手のいない役割を恒常的に引き受けている状態に近いです。 そのため、本稿を「『チームトポロジー』のイネイブリングチームの実践例」としてお読みいただくと、定義とのずれを感じる部分があるかもしれません。 一方で、同書から受け取った核の部分 — 代わりにやってあげない 、成果は 各チームが自走できるようになったかで測る — は、スコープが変わっても変えていません。名前に実態を合わせにいくのではなく、組織にとって今必要なことに形を合わせた結果として、こうなっています。このこと自体が、この半年の学びの1つでもありました。 今、取り組んでいること プロダクトビジョン・プロダクト戦略を言葉にする 「なぜこの課題を解くのか」という文脈が開発メンバーに届き、各メンバーが根拠を理解した上で意思決定できる状態をつくることを狙っています。個別のサービスやWEBサイトの最適化に視点が閉じないよう、事業全体を1つのプロダクトと捉えるところから始めました。 ただし、実際に着手してみて、進め方そのものを組み替えることにしました。決め手になったのは、ビジョンは書けば届くというものではない、ということでした。どれだけ言葉を磨いても、受け取る側との間に「一緒に事業の成果に責任を持つ」関係ができていなければ、掲げただけで終わってしまいます。 だとすれば、先に必要なのはそちらです。そう考えて、ビジョンの言語化よりもパイロットを先行させることにしました。 パイロットチームで、マーケとの協業の形を探る どこまでを誰が持つのか。その線を抽象的に引こうとすると議論はいくらでも続けられてしまうので、取り組みやすい1チームを選び、 課題を決めるところから成果を見届けるところまでを一緒に一周する パイロットを準備しています。 ここで置いている見立ては、 戦略を言語化して共有し計測するだけでは、「背景をよく理解したうえで、渡されたものを作るチーム」で止まってしまう ということです。関係を変えるには、解く課題を決めるところから一緒にいる必要があります。 そのため、作るものを決める前に、次のようなことを先に置いてから始めるつもりです。 どんな課題を扱い、ユーザーのどんな行動が変われば前進と言えるのか 何を優先するかを、誰がどこまで決めるのか どのタイミングで、何を見て、続ける・変える・やめるを判断するのか ユーザーの実際の声や行動を、どこから確かめにいくのか ふりかえりで見たいのは、次のようなことです。 ユーザーの行動が実際に変わったか それが事業の成果につながると説明できるか それはこの進め方だからこそ出せた結果と言えるか もっとも、どういう形が私たちにとって良い協業なのかは、やってみて分かることのほうが多いはずです。今はその最初の一周を回そうとしているところです。 ふりかえって思うこと 半年やってみて、強く感じていることが3つあります。 1. 横断で動くと、入ってくる情報が変わる 横断で動くことの価値は、チーム間で学びを橋渡しすることだと思って始めました。ただ実際に効いたのは、整えた仕組みや型よりも、 事業の方針がどういう背景で決まっているのかを知れるようになったこと でした。 1つのチームの中にいると、方針は結論の形で受け取ることになります。横断の立場になると、その結論に至る前の議論や判断の材料にも触れる機会が増えます。そうなると、「たぶんこちらのほうが良さそうだ」ではなく「この背景があるから、いまはこちらを取る」と言えるようになる。今の状況で取れる最善を自分たちで考えられるようになったのは、始める前には見えていなかった変化でした。 2. 自分たちのスコープ自体も、検査と適応の対象だった スクラムでいう「検査と適応」は、個々のチームの進め方だけでなく、横断チームの存在意義そのものにも当てはまります。机上で正しい形を決めてから動き出していたら、戦略と現場のつなぎ目がボトルネックだとは特定できなかったはずです。動いたからこそ、手を打つべき場所が見えてきました。 半年でスコープを変えられたのは、仕組みよりもメンバーのマインドによるところが大きいと思っています。一度決めた形に固執せず、今の状態に合う形へ変えていこうとする姿勢があったからこそ、「自分たちのやってきたことは、本当に効くところに当たっているのか」と率直に問い合えました。当初思い描いた形からは変わりましたが、遠回りだったとは考えていません。課題を特定し、そこに手を打てる状態になったこと自体が、この半年の成果です。 3. 横断チームこそ、広げる前に1つ通す 横断で動く立場だと、全チームに同時に手を入れたくなります。ただ、少人数でそれをやると、どこも中途半端になります。 実際にやってみると、課題管理のフォーマットも、データを串刺しにする取り組みも、マーケとの協業もすべて「準備の整った1つ」から始める形になりました。1つ通すと、型が手に入るだけでなく、「これはうまくいった」という実例が残ります。他のチームに広げていく場面で効いてくるのは、正しさの説明よりも、その実例のほうだと思っています。 最後に 最後までご覧いただきありがとうございました。 イネイブリングチームの立ち上げから、スコープを上位レイヤーへ変えるまでの半年をご紹介しました。取り組みはどれもまだ途中ですが、「戦略と現場の間にある翻訳の余白は、誰かが引き受けるべきだ」という手応えを確かに得ています。 引き続き、各チームやマーケの皆さんと一緒に、プロダクトの力で事業の成果に貢献できる組織づくりを進めていきたいと思います。 参考文献 マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター、2021年） マーティ・ケーガン 著／横道稔 訳『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（日本能率協会マネジメントセンター、2024年）

こんにちは！Insight Edgeでサービスデザインを担当している廣瀬です。 今回は、2026年8月2日に女子美術大学 杉並キャンパスで開催された「Service Design Camp 2026」に参加してきましたので、その熱気あふれる様子や実践的な学びをレポートします。 会場の女子美術大学 Service Design Camp 2026とは？ 平均的ペルソナからの脱却（AMセッション） サービスデザイナーのための量的エスノグラフィ：データの捉え方を探る実験ワークショップ（PMセッション） 当社メンバーもライトニングトークに登壇！ おわりに Service Design Camp 2026とは？ Service Design Campは、Service Design Network 日本支部が主催するサービスデザインのお祭りです。今年で4回目の開催となる本イベントのテーマは「初心者から実践者までみんなが楽しめるサービスデザインフェス！」。 https://servicedesigncamp.com/2026 今回は、私が実際に体験した2つのワークショップでの気づきと、当社からの登壇についてご紹介します。 平均的ペルソナからの脱却（AMセッション） 午前中に参加したのは、サービスデザインナレッジ研究会による「平均的ペルソナからの脱却」というワークショップです。 「A New Era of Service Design: Designing for Diversity」という論文を手がかりに、多様性が交差する上でのサービスデザインのあり方を考えました。 Cards for HumanityというWebツールを用いて、特徴をもったペルソナをランダムに設定し、大手カフェチェーンにおける利用体験の課題を考えました。 https://cardsforhumanity.frog.co/ 平均的ペルソナからの脱却 あえて「平均」から視点を外してみると、店舗内で歩く動作が多いことや、誰に言われたわけでもないのにスムーズな注文を暗に求められている感覚など、平均的なペルソナからは見えてこない課題に気づくことができました。 このワークショップでは、ステレオタイプなユーザー像から抜け出し、より具体的でリアルな「一人の人間」の文脈や非日常のコンテキストをいかに捉えるかという視点を改めて学ぶことができました。 サービスデザイナーのための量的エスノグラフィ：データの捉え方を探る実験ワークショップ（PMセッション） 午後は、量的エスノグラフィ読書会によるセッションに参加しました。 量的エスノグラフィ（Quantitative Ethnography, QE）とは、質的なデータ（言語、行動、文脈など）を統計的・定量的手法で分析し、エスノグラフィー（民族誌・文化人類学的な参与観察や記述）の深みと大規模データの科学的妥当性を両立させる最先端の研究方法論です。 定性的なユーザーリサーチのインサイトと、定量的なデータをどのように結びつけ、意味のある解釈を導き出すかという実験的なアプローチを体験しました。「量的エスノグラフィ（QE）」のためのツールを用いて、定性的なインタビュー結果を、データ化していくプロセスを実践しました。 サービスデザイナーのための量的エスノグラフィ 「エスノグラフィなのに量的？」という疑問をきっかけに参加してみましたが、定性分析だけでは拾いきれない行動や特徴の結びつき、関係性が可視化され、実務へ応用できる可能性を感じました。 当社メンバーもライトニングトークに登壇！ ランチタイムのライトニングトークセッションでは、Insight Edgeサービスデザイナーの高橋が登壇しました！ 「住友商事のデジタルAI CoEのサービスデザイナーの仕事」をテーマに、当社のデザイン組織のリアルな取り組みについてお話しさせていただきました。詳細は下記のお知らせ記事もご覧ください。 ▼「Service Design Network Camp 2026」にスポンサー協賛および登壇しました - Insight Edge https://insightedge.jp/9322/ おわりに 今回の2つのワークショップを通じて、多様な切り口からユーザーの「一人の人間としての文脈」を掘り下げ、それを定性・定量の両面から可視化する重要性を強く実感しました。 この学びを活かし、Insight Edgeでの日々のデザイン業務においても、従来の枠にとらわれないサービスデザインの実践をこれからも積み重ねていきたいです。 全てのセッション終了後には、参加者の方々との懇親会がありました。 サービスデザインに様々な立場で関わる方々と、それぞれの興味関心や日々の業務についてフランクにお話しすることができ、とても有意義な時間となりました。 Insight Edgeでは、このように社外のイベントにも積極的に参加・協賛しながら、最新の知見をインプットし、日々のプロダクト開発やサービスデザインに活かしています。よりよい体験や社会を創っていくために、これからもこうした熱いコミュニティで学び続け、社内外へ還元していきたいと思います！

こんにちは！レバレジーズでリードエンジニアのゲンシュンと申します！ レバレジーズにデータエンジニアとして転職して、ちょうどまる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年目はもっとおもしろくなりそうなので、これからも楽しくやっていきます！