こんにちは。メルペイ Growth Platform チームでエンジニアリングマネージャーをしている @yo-gawa です。この記事は Merpay & Mercoin Tech Openness Month 2026 の 19 日目の記事です。 私は 2018 年にメルペイに入社し、メルペイクーポンや決済に応じたポイント還元の仕組みなど、メルペイのキャンペーンを支える基盤の開発・運用に携わってきました。 【書き起こし】メルペイのキャンペーンの舞台裏 〜Growthを支える仕組み〜 – 小川 芳樹【Merpay Tech Fest 2021】 | メルカリエンジニアリング 現在は、メルカリグループ全体のグロース基盤のエンジニアリングを統括しています。 本記事では、私の視点からメルカリグループのグロース基盤の歴史と、どのようにチームが拡大してきたのかをお伝えします。 Growth Platform の立ち上げ メルカリグループでは、ポイントやクーポンを用いたマーケティング／キャンペーンが非常に活発に行われています。既存のお客さま向けの施策に加え、メルカリハロやメルカリモバイルといった新規事業のグロースにも活用されています。また、お客さまとのコミュニケーションチャネルとして、アプリ内バナー、メール、Push 通知、「あなたへのお知らせ」等も併せて使われています。Growth Platform チームは、こうしたグロース活動を支える基盤・仕組みづくりを担うチームとして機能しています。 「Growth Platform」というチーム名称が生まれたのは、ちょうど 5 年前の 2021 年 7 月でした。 「Growth UXチーム」が「Growth Platformチーム」に名称変更！　組織改編で見えたPMの役割やチームの変化 | mercan (メルカン) 上記の記事にもある通り、「共通する機能・基盤を横断的に見て、システム開発や運用の観点から下支えする」というミッションのもと、さまざまな取り組みを進めてきました。 Growth Platform というチームが生まれる前、2019 年のメルペイサービス開始直後は、より多くのお客さまにメルペイを使っていただくため、決済に絡めたクーポンやポイント還元キャンペーン施策を次々と打ち出していました。そのスピード感を支えるべく、独自にキャンペーン基盤を開発してきました。 一方で、マーケットプレイス事業にも同様にキャンペーンや Customer Relationship Management（CRM）を実行する基盤が存在していましたが、長いメルカリの歴史の中で生み出されてきた PHP 製ツールには多くの負債があり、メンテナンス性の観点からも、オペレーション事故が起きやすい構造になっていました。メルペイ側でも、それらのツールを利用することにリスクを感じていました。 そこで、メルカリとメルペイのエンジニア間で実務的なコラボレーションをスタートし、古いツールを廃止して、新たに Engagement Platform (EGP) という内製マーケティングエンジンを共同開発する方向性で合意しました。 その後、2023 年 1 月よりメルペイ内に統合組織を作り、「JR (Japan Region) Growth Platform」として、一丸となった開発体制をスタートさせました。詳細は当時のエンジニアリング統括であった keigoand の記事にまとまっています。 Merging Teams for a Growth Platform | Mercari Engineering 記事にもありますが、当初はそれぞれのチームで開発の進め方が大きく異なりました。メルペイが比較的小規模で立ち上げを進めた背景もあり、独自のオペレーションツールやミドルウェアがあり、エンジニアリングカルチャーも異なっていました。また、メルペイは金融事業を担っていることもあり、システム品質の担保も重要です。リリースプロセスの厳格化や、QAなどの各種基準への準拠などについて認識を合わせながら開発を進めることは苦労も伴いましたが、チームのケイパビリティは格段に向上しました。 グループの拡大とともに 先述した通り、Growth Platform チームはメルペイに所属しながらも、メルカリグループ全体を支えるチームです。 この数年、メルカリでは複数の新規事業が立ち上がりました。 メルカリShops メルコイン メルカリNFT メルカリハロ メルカリモバイル 越境ビジネス メルカリグローバルアプリ etc これらのビジネスやプロダクトの Product-Market Fit を支えるべく、Growth Platform ではさまざまな開発を行ってきました。例えば、新しいサービス画面上でのキャンペーンバナー表示や訴求、新規のお客さまへのクーポン／ポイント進呈、利用実績に応じたロイヤリティプログラムなどは、一見共通でありつつも、それぞれのサービスのデータを基盤に統合し、マーケティングチームが柔軟かつ高速にキャンペーンを打ち出せる仕組みが必要です。また、グローバル展開においては、各地域の言語や、クーポンにおける通貨の違いへの対応などもスコープになります。 さらに（一部例外はありますが）、メルカリのサービスは 1 つのメルカリアプリ上で動いています。起動直後に表示される「ホーム画面」や、マーケットプレイスにおける「商品詳細画面」「取引画面」でのキャンペーン訴求は、お客さまにサービス認知を獲得するうえで非常に重要です。そのような訴求エリアが限られる中で、どのサービスがそれぞれのお客さまにとって有用なキャンペーンであるのか、コミュニケーションチャネルがノイジーになりすぎないのか、といった最適化にも Machine Learning チームが取り組んでいます。 組織の拡大 事業の拡大に対応するため、Growth Platform 組織も拡大を続けてきました。 2022 年 6 月にインド・ベンガルールに開発拠点として Mercari India を設立して以降、設立当初から一緒に開発を進めています。当初はクーポンドメインを共同で開発するところからスタートしました。新たなビジネスに対応したクーポン機能の開発を進めながら、mercari-api という PHP 製モノリスからマイクロサービスへのマイグレーションという大規模プロジェクトも自律的に推進しています。 Migrating Coupons from Monolith to Microservice – Mercari India 近年ではクーポンドメインだけでなく CRM ドメインでも開発体制を拡大し、Backend、Frontend、Mobileのエンジニアが一体となってインド拠点のみで機能開発を完結するような事例も出てきています。 現在は日本とインドのエンジニアが約2:1の割合で協働しています。また、日本とインドのエンジニアリングマネージャー同士、密に連携しながら開発を推進しています。 Growth Platform の全体ミーティングでは、知見共有を含めた交流をエンジニア同士で積極的に行っています。加えて、定期的にインドオフィスへ出張したり、インドのエンジニアが東京オフィスを訪問するタイミングに合わせて交流を深めたりしています。 (インドオフィスに設置されているオブジェへのサイン) 一方で、使用言語の壁は依然として課題です。メルペイは従来、日本語中心でコミュニケーションしてきましたが、元マーケットプレイスのメンバーやインドオフィスのメンバーは英語中心です。Growth Platform チームの全体ミーティングは英語で行う一方、メルペイ全体のミーティングは日本語で実施しているといった状況下で、GOT（通訳）チームのサポートも借りながら、日本語話者・英語話者の双方が歩み寄ってコミュニケーションを進めています。 次なるチャレンジへ Growth Platform チームの成熟は、メルカリグループのグロースとともにありました。 EGP は、さまざまな機能開発を経て大きな進化を遂げています。 EGP – Mercari’s CRM Platform: Built Once, Powering Many | mercari GEARS 2025 AI と作る HTML ベースの LP エディタ EGP Code を内製した理由 | メルカリエンジニアリング また、メルペイに特化した基盤である Santa サービスも進化を続けています。 メルペイのキャンペーン基盤をルールベース汎用システムに書き直し、Otoku Revolutionするまでの話 | メルカリエンジニアリング 基盤開発フェーズは一巡したと捉えていますが、ビジネスを支える基盤としてはまだ道半ばにあります。特に、ビジネスの要求に対するアジリティとシステムの信頼性向上は継続的な課題です。 そこで今後は、グループそれぞれのビジネスグロースをより直接的に支えつつ、守りも固められる開発体制をつくるために、Growth Platform 体制としては一区切りとし、組織を CRMチーム と Incentiveチーム に分け、それぞれのミッションを担っていきます。 CRM チームは、マーケットプレイスをはじめとする各事業の成長を後押しするため、プロダクトと密に連携しながら、EGP を活用したお客さま向けコミュニケーション機能の開発・改善を進めていきます。 Incentive チームは、メルペイ Payment & Customer Platform の一員として、インセンティブを汎用的かつ安全に取り扱える仕組みづくりを推進していきます。 チームは分かれますが、メルカリグループ全体で活用される共通 Foundation として、連携は継続していきます。 まとめ ここまで、Growth Platform のプロダクトやチームの拡大について簡単にご紹介しました。プロダクトや技術の詳細は、本エンジニアリングブログやカンファレンスでメンバーが紹介していますので、そちらもぜひご覧ください。 これからもメルカリグループの可能性を広げるための仕組みづくりを追求していきます。 次の記事は abcdefujiさん と becosukeさんです。引き続きお楽しみください。

前回の Week in Review に、2026 年、お客様との AI-Driven Development Lifecycle (AI-DLC) ワークショップに多くの時間を費やしたことを書きました。これらのセッションに共通するテーマは、コストの可視性を高める必要があるということです。チームは AI の導入を急速に進めていますが、実験段階から本番環境に移行するにつれ、財務部門と経営陣は、誰がどのリソースをどの程度のコストで使用しているかを把握する必要があります。だからこそ 2026 年 4 月 13 日週、 Amazon Bedrock による IAM ユーザーとロール別のコスト配分のサポートの開始 を知って、とてもワクワクしました。これにより、IAM プリンシパルにチームやコストセンターなどの属性をタグ付けし、それらのタグを請求およびコスト管理コンソールでアクティブにすることができます。結果のコストデータは AWS Cost Explorer と詳細なコストと使用状況レポートに送信されるため、モデル推論の支出を明確に把握できます。チーム間でエージェントをスケールする場合でも、部門ごとに基盤モデルの使用状況を追跡する場合でも、 Claude Code on Amazon Bedrock のようなツールを実行する場合でも、この新機能は AI 投資の追跡と管理に大きな変革をもたらします。この設定に関する詳細は、 IAM プリンシパルコスト配分ドキュメント に記載されています。 それでは、2026 年 4 月 13 日週の AWS ニュースを見ていきましょう。 ヘッドライン Amazon Bedrock が Claude Mythos Preview の提供を開始 これまでで最も洗練された Anthropic の AI モデルを、Project Glasswing を通じてゲート付きリサーチプレビューとして Amazon Bedrock で利用できるようになりました。Claude Mythos は、サイバーセキュリティに焦点を当てた新しいモデルクラスを提供します。これにより、ソフトウェアの高度なセキュリティ脆弱性を特定し、大規模なコードベースを分析して、サイバーセキュリティ、コーディング、複雑な推論タスク全体で最先端のパフォーマンスを実現できます。セキュリティチームはこれを利用して、脅威が出現する前に重要なソフトウェアの脆弱性を発見して対処することが可能になります。現在、アクセスは許可リストに登録されている組織に限定されており、Anthropic と AWS はインターネットクリティカルな企業やオープンソースのメンテナーを優先しています。 エージェントの検出とガバナンスを一元化するための AWS Agent Registry (現在プレビュー中) AWS は Amazon Bedrock AgentCore を通じて Agent Registry を立ち上げました。AI エージェント、ツール、スキル、MCP サーバー、カスタムリソースを発見して管理するためのプライベートカタログを組織に提供しています。レジストリは、セマンティック検索、キーワード検索、承認ワークフロー、CloudTrail 監査証跡により、チームが既存の機能を重複することなく見つけるのを支援します。AgentCore Console、AWS CLI、SDK からアクセスできます。また、IDE からクエリ可能な MCP サーバーとしてアクセスすることも可能です。 2026 年 4 月 6 日週のリリース 2026 年 4 月 6 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 S3 バケットをファイルシステムとしてアクセス可能にする Amazon S3 Files の発表 – Amazon S3 Files は S3 バケットを、任意の AWS コンピューティングリソースと S3 データを直接接続する共有ファイルシステムに変換します。Amazon EFS テクノロジーに基づいて構築されているため、低レイテンシーのパフォーマンスで完全なファイルシステムセマンティクスを提供し、使用頻度の高いデータをキャッシュして、1 秒あたり数テラバイトの総読み取りスループットを実現します。アプリケーションは、コードを変更したりデータを移行したりすることなく、ファイルシステムと S3 API の両方から同時に S3 データにアクセスできます。 Amazon OpenSearch Service が Managed Prometheus とエージェントトレースのサポートを開始 – Amazon OpenSearch Service は、メトリクス、ログ、トレース、AI エージェントトレースを 1 つのインターフェイスに統合した、統合型オブザーバビリティプラットフォームの提供を開始しました。このアップデートには、Prometheus のネイティブ統合と PromQLクエリの直接サポート、RED メトリクスのモニタリング、LLM 実行の可視化を実現する OpenTelemetry GenAI セマンティック規約サポートが含まれています。運用チームはツールを切り替えることなく、スロートレースをログに関連付け、ダッシュボードに Prometheus メトリクスをオーバーレイすることができます。 Amazon WorkSpaces Advisor が AI を活用したトラブルシューティングで利用可能に – AWS は Amazon WorkSpaces Advisor を立ち上げました。これは、生成 AI を使用して IT 管理者が Amazon WorkSpaces パーソナルデプロイのトラブルシューティングを行うのに役立つ、AI を活用した管理ツールです。WorkSpace の設定を分析し、問題を自動的に検出して、サービスの復旧とパフォーマンスの最適化に役立つ推奨事項を提示します。 Amazon Braket が Rigetti の 108 量子ビット Cepheus QPU のサポートを追加 – AmazonBraket は、プラットフォーム上の最初の 100 量子ビット以上の超伝導量子プロセッサである Rigetti の Cepheus-1-108Q デバイスへのアクセス提供を開始しました。モジュラー設計は、位相誤差に対する耐性が強化された CZ ゲートを備えた、12 個の 9 量子ビットチップレットを備えています。Braket SDK、Qiskit、CUDA-Q、Pennylane などの複数のフレームワークをサポートしており、研究者向けのパルスレベル制御も可能です。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Amazo S3を使用した自動 AWS リージョン可用性チェックの構築 – Amazon S3をコアインフラストラクチャとして使用し、AWS リージョン全体でサービスの可用性を監視する自動化システムの実装に関するストレージブログ記事です。 Amazon Bedrock モデルのライフサイクルの理解 – 機械学習のブログ記事では、Bedrock の基盤モデルが入手可能になったり廃止されたりするまでの段階について説明しています。これは、チームがモデルのアップデートを計画したり、本番環境でのバージョン依存関係を管理したりするのに役立ちます。 AWS Lambda Managed Instances を使用したメモリ集約型アプリの構築 – コンピューティングのブログ記事では、Lambda マネージドインスタンスがプラットフォームを軽量ワークロード以上に拡張し、サーバーレスのメリットを維持しながらメモリを大量に消費するアプリケーションをサポートする方法について説明しています。 OpenClaw を AWS でデプロイ: お客様の AI ワークロードに適したオプションを選択 – Builder Center ガイドでは、OpenClaw の 4 つの AWS デプロイオプションを比較しています。4 つのオプションとは、個々のデベロッパー向けの Amazon Lightsail、より深い AWS 統合を必要とするスタートアップ向けの Amazon EC2、サーバーレスのマルチユーザーシナリオ向けの Amazon Bedrock AgentCore、VM レベルの分離と高度なオーケストレーションを必要とするエンタープライズ向けの Amazon EKS です。 Kiro スタートアップクレジットプログラム復活のお知らせ – Kiro はスタートアップクレジットの取り組みを再開します。対象となる初期段階の企業は、Kiro Pro+ を最大 1 年間無料で利用できるようになります。3 段階のプログラム (Starter、Growth、Scale) は、チームの規模に応じて 2〜30人のユーザーを対象としています。また、ローリングアプリケーションは世界中で受け付けています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS の次のイベント (4 月 28 日、バーチャル) 午前 9 時 (太平洋標準時) に配信されるこのライブストリームに参加して、エージェンティック AI がビジネスの運営方法をどのように変えているかについて率直に議論しましょう。AWS CEO の Matt Garman、SVP の Colleen Aubrey、OpenAI のリーダーが、新しいエージェント機能、Amazon 社内での経験、新しいエージェンティックソリューションとプラットフォーム機能について語ります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 4 月 13 日週のニュースは以上です。2026 年 4 月 27 日週にお届けする次回の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

はじめに こんにちは。 my route 開発部でバックエンドチームのリーダーをしている yf です。 my route 開発部では、昨年 7 月に組織体制が変わり、新しい形で開発を進めています。 その変化に備えて、6 月から少しずつ進めてきた取り組みが、 半年たった今、チームの空気や仕事の進め方に確かな変化をもたらしています。 この半年で扱ったテーマは約 40。 一つひとつは小さな改善ですが、積み重ねることで 「開発の役割」や「プロダクトとの向き合い方」が大きく変わってきました。 本記事では、私たちがどんなステップを踏み、 なぜその変化が起きたのかを、時系列[^1]で振り返ります。 この記事はこんな人向け 開発が「実装担当」に閉じてしまっていることに違和感がある方 仕様やスケジュールが決まった状態で渡ってきて、Why を理解しづらいと感じている方 プロダクト思考を持ちたいが、日々の開発で手応えを持てていない方 組織改善をしたいが、何から手を付ければいいかわからないリーダー・サブリーダー 「誰かを責める」のではなく、「構造を変える」アプローチを探している方 私たちが半年間かけて試行錯誤してきた取り組みが、 同じような悩みを持つチームのヒントになれば幸いです。 当時の状況と、なぜそうなっていたのか 取り組みを始める前、開発部には次のような状況がありました。 要件や仕様が、開発フェーズの後半で共有されることが多かった 開発期間が限られ、品質改善や振り返りに十分な時間を取れなかった スケジュールや設計の背景（Why）が、開発側に伝わりにくかった 結果として、実装を中心に進めざるを得ない進め方になっていた これは、特定の誰かの判断ミスというよりも、 "役割分担とプロセスの構造がそうさせていた状態" だったと振り返っています。 プロデューサーはプロダクトを良くしようとする責任感から、 設計やスケジュールをできるだけ具体化しようとしていました。 一方で、その分、開発に共有されるタイミングが遅くなり、 開発側には「How（どう作るか）」を中心とした情報が渡る構造になっていました。 その結果、 "なぜこの機能を作るのか（Why）を理解した上で改善提案を行う余地が少なくなり、" 開発が実装中心の役割に閉じてしまっていたのです。 この状況を変えるために、 私たちは "開発組織から、プロダクト組織へ" という 大きな方向転換に踏み出しました。 半年間の全体像 目的定義 → プロセス設計 → 運用定着 → 連携強化 → 品質と戦略 → 組織文化として定着 まず、私たちが向き合っていた「仕事の流れ」の変化を、Before / After で示します。 ■ 6 月 —— “目的と役割の再定義” 組織変革の起点 まず取り組んだのは、 “私たちはどこに向かうのか“ “チームリーダーは何を担うのか“ という意図合わせでした。 開発に関わる関係チームのリーダー全員（PDM・QA・バックエンド・モバイル）で、理想像の輪郭を描き直しました。 主なテーマ 独立プロダクト組織としての目的定義 リーダー役割の再整理 過渡期の案件対応 仕事の流れ図（AS-IS）の棚卸し チーム役割の再設計 会議体・Slack などコミュニケーション設計 この段階で、別の部である Engineering Office にも参画してもらいました。 開発部の中だけでは前提になっていた考えや、 見落としていたプロセスの歪みを、 第三者の視点から言語化・整理してもらえたことは、 その後の設計を進めるうえで大きな支えになりました。 6 月 あらためてひとこと - “まず揃えないと、何も始まらない” この時点では、具体的な施策よりも "前提が揃っていないまま進むことの危険性" を強く感じていました。 早く手を動かしたい気持ちを抑え、 あえて立ち止まって目的と役割を言語化したのは、 後戻りしないための投資だったと思っています。 ■ 7 月 —— “仕組みの再設計に着手” 新しい仕事の流れの原型ができた 6 月に定義した理想を、実際のプロセスに落とし込んだ月です。 スプリント導入（計画・中間・レビュー・レトロスペクティブ） チーム間連携会の常設 Jira運用ルールの再構築 ストーリーチケット作成基準の統一 Git ブランチ戦略の見直し リリースフロー整備 成果物レビューの仕組み化 問い合わせ・障害の暫定ルール化 “会議体・プロセスがゼロから設計されていくスピード感“ があり、 部全体の透明性が大きく向上しました。 7 月 あらためてひとこと - “理想を、現実の流れに落とす” 6月に描いた理想は、そのままでは机上の空論でした。 リーダとして意識したのは「誰がやっても迷わない仕組み」になっているか。 プロセスを設計することは、メンバーの思考コストを下げることだと実感した月でした。 ■ 8 月 —— “新プロセスの定着と運用強化” Jiraと仕事の流れが形になってきた 新プロセスの試験運用 新規案件でのトライアル導入 UI 定例、Slack などコミュニケーション基準化 問い合わせ・ツール改修フローの改善 ロードマップレビューの開始 プロセスが回り始めたことで、 “現場から自然と改善提案が出る状態“ が生まれはじめました。 8 月 あらためてひとこと - “仕組みは、使われて初めて意味を持つ” 新しいプロセスは、導入しただけでは根付きません。 この月は「守らせる」よりも "使ってみてどうだったかを聞く" ことに注力しました。 現場から改善案が出始めたとき、組織が一段階変わった感覚がありました。 ■ 9 月 —— “プロダクト思考と横断連携の強化” チーム間連携が日常化 ストーリー分割ワーク 役割を越えたアイデア提案の促進 リソースアサイン管理の透明化 AI 活用案件の相談 リリース承認ルートの改善 リーダー陣の視点が “「自分の領域」から「プロダクト全体」“へ 大きくシフトした月でした。 9 月あらためてひとこと - “役割を越えることを、許可する” プロダクト全体の話をするとき、役割を理由に遠慮が生まれる場面がありました。 リーダとして意識したのは、「それはあなたの領域じゃない」という空気を消すこと。 横断連携は、仕組みだけでなく心理的安全性があって初めて機能すると学びました。 ■ 10 月 —— “運用・リスク管理の高度化” 問い合わせ・障害・運用プロセスが進化 問い合わせ・障害フローの再整備 運用体制の検討 目的起点の進め方ワーク アジャイルトレーニング準備 他部門との連携強化 “リスクを未然に防ぐ動き” が自然と発生する組織へと変化しました。 10 月 あらためてひとこと - “問題が起きる前提で、組織をつくる” 問い合わせや障害は、ゼロにはできません。 だからこそ "起きたときにどう振る舞えるか" を考えるフェーズに入りました。 個人の頑張りに依存せず、組織として耐性を持つことを意識し始めた月です。 ■ 11 月 —— “品質・戦略・成長のフェーズへ” 技術とビジネスがつながり始めた スプリントへの QA 導入方針の確定 セキュリティ監査オーナーの役割整理 ポストモーテム文化の定着 UI/UX 改善の進め方刷新 フィールドワーク成果の共有 “案件をこなす組織” から “プロダクトを成長させる組織” へと進化。 11 月 あらためてひとこと - “技術は、ビジネスとつながってこそ価値になる” 品質やUXの議論が増えたことで、技術がプロダクト価値にどう貢献するかを 言葉にする機会が増えました。 リーダとしては、技術的な正しさと、事業としての判断をつなぐ役割を より強く意識するようになりました。 ■ 12 月 —— “半年の蓄積が組織文化に変わり始めた” 目的起点で動ける組織に UI/UX 改善の長期方針の確立 QA 導入プロセスの実運用 ロードマップレビューの定着 工程ごとのリードタイム測定開始 6 月に掲げた “自律したプロダクト組織になる” という目標が、実際の動きとして現れてきました。 半年で生まれた “4 つの変化” ① 情報の透明性 プロダクト全体の状態が誰にでも見えるようになった。 ② 早期リスク検知 問い合わせ・障害・運用課題が芽のうちに見つかるようになった。 ③ 横断連携の活性化 PDM・QA・バックエンド・モバイルが互いに提案しあう文化が育った。 ④ 再現性のあるプロセス “誰がやっても前に進む” 仕組みが整った。 12 月 あらためてひとこと - “文化は、後から気づくもの” 何か劇的なイベントがあったわけではありません。 ただ振り返ってみると、目的から考え、自然と連携し、改善を回す "当たり前の動き" が定着していました。 組織文化は、作ろうとして作るものではなく、 積み重ねの結果として生まれるのだと感じています。 もともとの課題は、どこまで変わったか 取り組みを始めた当初、私たちは 「開発が実装中心の役割に閉じてしまっている」という課題を抱えていました。 半年間の取り組みによって、 Why を共有したうえで議論できる場が増え スケジュールや設計の背景を前提に、改善提案が出るようになり 開発が「決められたものを作る」だけの立場ではなくなってきた といった変化が確かに生まれました。 一方で、 すべてが理想通りに解消されたわけではありません。 プロダクト全体の意思決定への関与や、 戦略レイヤーでの議論は、まだ発展途上です。 それでも、 「なぜやるのかを考えながら作る」ことが当たり前になり始めた という点で、 当初感じていた課題は、確実に別のフェーズへ進んだと感じています。 次の半年へ これからは、 “プロダクトをつくる組織“から“プロダクトを成長させる組織“ へさらに進化していきます。 グロースハック文化の定着 権限移譲と育成の体系化 プロダクト戦略の内製化 インシデント学習ループ強化 開発体制の継続アップデート 内部だけで議論すると主観に偏り、問題の本質を見誤ることがあります。 そのため今回は、部を横断して取り組めたことも私たちにとって大きな追い風となりました。 半年で大きく変化した組織が、次の半年でどこまで成長できるのか。 私自身、とても楽しみにしています。 さいごに my route 開発部では、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！ [^1]: 半年で扱った 40 のテーマを月別の代表例として抜粋しています。