はじめに こんにちは。 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 のテーマを月別の代表例として抜粋しています。

メルペイ インターンでの挑戦と学び：EGP Cardsと向き合った3ヶ月間 こんにちは。メルペイのGrowth Platformでフロントエンド・エンジニアとしてインターンをしている @Yusaku （宮田 優作）です。 この記事は、 Merpay & Mercoin Advent Calendar 2025 の25日目の記事です。 私は2025年10月からインターンを開始し、今月で3ヶ月目になりました（図1）。 この記事では、インターン期間中に取り組んだタスクと得た学びについて紹介します。 図１：オフィスで撮影した私の写真 チームについて 私が所属する Growth Platform Frontend チームは、Engagement Platform（通称EGP）という社内向けマーケティングツールを開発しています。 このツールを使うことで、マーケターや プロジェクトマネージャーは、ポイントやクーポンなどのインセンティブ配布、ランディングページ（LP）の作成・公開、キャンペーン作成といった CRM業務をコーディング不要で簡単に行うことができます（図2）。 図2：EGPのノーコードエディタ（EGP Content） 今回のインターンではEGP Cardsという機能の向上に取り組みました。EGP Cardsは、Web・iOS・Androidのクロスプラットフォームで利用できるカード型のコンポーネントを作成・公開する機能です。 EGP Cardsは、いわゆるWebページのエディタ機能（EGP Pages）とは異なり、サーバがUIの構造を返却するというServer Driven UIアーキテクチャを採用しています。エディタ上で作成されたコンポーネントのコンテンツはJSONファイルとして保存され、各プラットフォームで共通のUIとして描画されます（図3）。 Server Driven UIとEGP Cardsのアーキテクチャについては、同じくGrowth Platformチームの@togamiさん、@Stefanさんの記事をそれぞれご覧ください。 WYSIWYGウェブページビルダーを支える技術とServer Driven UIへの拡張 Supercharging User Engagement: How Mercari is Using Server-Driven UI to Reduce Time-to-Market 図3：EGP Cardsの編集画面 タスク1 – Dry Run for EGP Cards タスク概要：Dry Runとは？ Dry Runとは、変数を設定し、そこにデータを挿入することで、状態をエミュレートできる機能のことです。これにより、API呼び出しを記述したり実機で動作確認を行ったりする前に、コンテンツの挙動を確認することができます。 このタスクでは、EGP CardsでDry Run機能を利用できるようにする実装を行いました（図4）。 図4：今回実装した、EGP CardsのDry Run機能 動作の仕組み Dry Run機能は、以下の流れで動作します。 利用者がDry Runを有効化し、フィールドにモックデータを入力する エディタが構造ツリーを再帰的に走査し、動的にJavaScriptのコードを評価して変数を値に置換する 置換された値がキャンバス上に表示される 実装の流れ 以下の流れで実装を進めました。 EGP Pagesに既に実装されていたDry Run機能について、コードリーディングやロギングを行い、実装ロジックを理解する EGP Cards特有の仕様を理解した上で、同様に利用できるDry Run機能を実装する コーディングの際には、EGP PagesとEGP Cardsで共通利用できそうな処理を探し、適度にファイルを切り出すことで、可読性・保守性を意識した実装を心がけました。 タスク2 – Content Agent Improvement for EGP Card 背景：Content Agentの課題 EGPのノーコードエディタ（EGP Content）は、CardsのほかにもPagesやE-mailsなど、複数の種類のコンテンツを扱うことができます。 また、EGP ContentにはAIエージェント（通称 Content Agent）が導入されており、対話を通じてコンテンツの要約や書き換えを行うことができます（図5）。 一方で、当時のContent Agentは、コンテンツ種別ごとのエディタ仕様を十分に理解していないという課題がありました。その結果、UIが崩れたコンテンツを生成してしまい、利用者の期待通りのアウトプットを提供できない可能性がありました。 図5：Content Agentの会話処理パイプライン 実装の流れ この課題を解決するため、以下の流れで実装を進めました。 EGP Cardsの仕様やデータ構造を記述したプロンプトを作成する 作成したプロンプトを、Content AgentのAgent Layerで条件付きで注入する EGP Cardsには、メディアクエリに対応していないことや、すべての要素がFlexで構成されていることなど、いくつかの制約があります。これらの制約や期待される出力をプロンプトに明示することで、Content AgentがCardsに適したコンテンツを生成できるようにしました（図6）。 図6：EGP CardsでContent Agentを利用する様子 学んだこと チーム開発におけるアウトプットの出し方を学んだこと Dry Run 機能の実装を通じて、チーム開発におけるアウトプットの出し方について多くの学びがありました。実装の正しさや機能の完成度だけでなく、Pull Request（PR）の切り方やレビューの受け方が、チーム全体の開発効率や生産性に大きく影響することを実感しました。 具体的には、バグ修正やリファクタリングであっても、PRのサイズが大きくなりすぎる場合やタスクのスコープ外に及ぶ場合には、別のPRとして切り出すことでレビューコストを抑えられることを学びました。また、コードやPRコメントには、なぜその実装にしたのか、どのような選択肢があり、何をしない判断をしたのかといった実装意図を明示することが重要です。これにより、レビュワーとの認識齟齬を防ぎ、建設的なレビューにつながると感じました。 レビューを受けた際にも、指摘内容をすぐに修正として反映するのではなく、まずはレビュワーの意図を正しく理解することが重要です。場合によっては背景や前提条件をすり合わせた上で議論することで、より良い設計や実装にたどり着けることを学びました。これらの経験を通じて、個人としてコードを書く力だけでなく、チームで価値を届けるためのコミュニケーションや姿勢の重要性を強く認識しました。 メルカリカルチャーを実体験として理解できたこと メルカリでは、情報の透明性やフラットな意思疎通によって、個人に大きな裁量が与えられていると言われることが多いです。実際にインターンを通じて、その点を強く実感しました。一方で、個人的に特に印象に残ったのは、英語を前提としたグローバルな開発環境です。 これまで参加してきたインターンはすべて日本語環境だったため、ドキュメントやコミュニケーション、議論の場がすべて英語になる経験は非常に新鮮でした。グローバルなチームである以上、英語でのスムーズな意思疎通が求められることは理解していましたが、実際に業務の中でそれを実践し、議論や開発を進められたことに大きなやりがいを感じました。 実際の業務では、英語で書かれたREADMEや仕様書を読み込んだ上でPull Requestを作成し、設計意図や懸念点を英語で説明・議論しました。認識の齟齬を防ぐため、必要に応じて日本語での補足も行いながら、主体的にコミュニケーションを取ることを意識しました。この経験を通じて、メルカリのカルチャーは単なるスローガンではなく、日々の業務に根付いたものだと感じました。 技術的挑戦を通じて、学びの広がりを再認識できたこと これまで私は、フロントエンドを主な技術領域として、インターンや個人開発に取り組んできました。そのため、フロントエンド領域における学びは、徐々に頭打ちになりつつあるのではないかと感じていました。 しかし、EGPというツールに触れたことで、その考えは大きく変わりました。EGPは非常にインタラクティブでリッチなUIを持つだけでなく、その裏側では、ノーコードによるコンテンツの作成・配信の仕組みや、安全かつ効率的にAI Agentとやりとりを行うための設計など、複雑で奥深いロジックが支えられていることを知りました。 タスクでは、ある程度抽象度のある状態で要件を受け取り、自分で具体的な実装タスクへ分解した上で設計・実装を進めました。また、EGPの使い方をキャッチアップしている最中に、イメージのプレビュー機能があることで利用者体験が向上するのではないかといった改善提案も行いました。 さらに、Content Agentの改善では、今回のCards向け実装に閉じることなく、将来的にPagesやE-mailsなど他のContent typeにも展開しやすいよう、Typeごとにプロンプトを切り出す設計とし、可読性や拡張性を意識しました。エンジニアがプロダクトの将来を見据えて設計・実装することが、利用者体験の向上や業務効率化につながり、結果として事業価値に直結する点は、メルカリならではの魅力だと感じています。 おわりに 今回のインターンでは、EGP Cardsという機能の向上に取り組みました。インターンを通じて、技術的なスキルだけでなく、プロダクトの価値やチームとの関わり方を含めてエンジニアリングに向き合う姿勢を学ぶことができました。 実務を通して得たこれらの学びを、今後の開発や自身の成長につなげていきたいと考えています。最後までお読みいただきありがとうございました。

はじめに こんにちは。KINTOテクノロジーズ株式会社（以下、KTC）でフロントエンド開発をしている佐藤です。 この記事では私が属しているKINTO中古車サイト開発チームについて紹介させていただきます。 主に開発の進め方や体制などをお伝えできればと思います。 最近日傘デビューしました。佐藤について詳しくは こちら KINTO中古車サイト開発チームって？ 通常KINTOで契約すると新車でサブスク開始となり その後契約終了するとその車両が返却されます。 返却された車両を中古車のKINTOとして 再びEC販売する「 KINTO 中古車 」のプロダクトを 開発、運用をメインとしているチームです。 「KINTO 新車」と大きく違うポイントとして、 中古車は基本的に早い物勝ちの一点物商品となりますので 日々在庫変動があるECサイトとなります。 在庫の見せ方、おすすめコーナーなど ECサイトならではの施策や打ち出し方がやりがいの一つでもあります。 チーム内体制(2025年11月時点） プロダクトマネージャー 1名 プロデューサー 1名 フロントエンドエンジニア 5名 バックエンドエンジニア 8名 チームの雰囲気 チームの様子 フロントエンド(FE)、バックエンド(BE)チーム、業務委託のパートナーさんとも 垣根なく気軽に会話コミュニケーション、意見が言い合える雰囲気です。 また中古車のビジネスチームとも距離が近く、 意見を言ったり一緒に中古車サイトを育てていこう！という気持ちで 皆同じ方向を向いていると思います。 たまに他部署の方がビジネス定例会議に参加される事があるのですが、 「非常に雰囲気の良い会議ですね」のようなありがたいお言葉を 耳にすることもあり嬉しい限りです。 **チームメンバーを一部ご紹介！** 中古車フロントエンドのチームメンバーが執筆した記事もありますので ぜひこちらもチェックしてみてください！ NAKAHARA Yuki サッカーの応援が大好き 自作キーボードで作業効率UP！ NAKAHARA Yukiさんの記事↓↓ Lambda@Edge & Next.jsによるサイト画像最適化  Ren.M - バスケ部部長！ポイントガードで輝いています - iPhoneはハイエンド機種に限る！ - Ren.Mさんの記事↓↓ - [TypeScript入門](/posts/2024-04-10-TypeScript入門/) - [社内部活動紹介-バスケ部編-](/posts/2024-09-26-社内部活動紹介-バスケ部編/) 体制 中古車サイトは様々なステークホルダーと 関わりながら運用されています。 チーム 役割 所属 中古車ビジネスチーム ビジネスオーナー 株式会社KINTO 中古車サイト開発チーム 開発全般を担当 株式会社KINTOテクノロジーズ クリエイティブチーム ディレクションやサイトデザインを担当 株式会社KINTOテクノロジーズ 分析チーム アクセス数やCVRなどを管理 株式会社KINTOテクノロジーズ :::message 豆知識「KINTOテクノロジーズ(KTC)の役割」 ::: KTCはトヨタグループ各社が展開するモビリティサービスをテクノロジーとクリエイティビティでリードするために創設されたテックカンパニーです。KINTOもトヨタモビリティサービスの一つとして、KTCが内製開発を担っています。 KINTO(KINTOの運営領域)、KTC(KINTOの開発領域)と 専門領域を分担し協業することによって強みを活かしております。 開発の進め方 中古車サイトの開発ではビジネス定例を軸としてやることを決めていき、 HCDという開発手法を元にPDCAのサイクルでECサイトをグロースハックしています。 ビジネスチームを中心とした4チームで進めており、 皆で意見を出し合いながら主体性を持って開発しております。 HCDとは ユーザーテストの様子 人間中心設計(Human Centered Designの略称)のことを指し、 ユーザーのニーズを理解し、 どうやって製品に反映させるかを中心に設計する手法となります。 中古車チームでは 具体的に実際にアンケートやユーザーテストを行い、 サイトの改善点、ユーザーの欲求などを整理して改善に繋げています。 ユーザーテストは何を思って操作しているかなど、 コミュニケーションをとりながら実施するので 予想外な気づきがあったり 開発者としても非常によい経験となっております。 進め方の例 PDCAサイクル 内容 担当チーム Plan（計画） 分析チームのレポートやお客様の声、 ビジネスとして実現した事などを元に目標、 改善案などを設定 皆で意見出し合い、構成、デザインなどを決めていく (fixするまで何度か繰り返す) ・中古車ビジネス ・中古車開発 ・クリエイティブ ・分析 Do（実行） 開発〜リリース ・開発 Check（評価） 数値をチェック 結果の議論 ・中古車ビジネス ・中古車開発 ・クリエイティブ ・分析 Action（改善） 評価を元に必要であれば次の計画へ ・中古車ビジネス ・中古車開発 ・クリエイティブ ・分析 ビジネス定例 ビジネス定例の様子 週次ミーティングで中古車ビジネスチームと情報共有をしつつ、 改善の相談やサービス拡大の対応を検討しています。 中古車ビジネスチーム、クリエイティブチーム、分析チームがあり ミーティングではそれぞれの立場で参加しています。 中古車ビジネスチーム北畑さんのファシリテートが私は好きで アイスブレイクなど形式張ったコーナーはないのですが 終始とても良い雰囲気で進行してくださります。 北畑さんについては こちら 定例はこのようなアジェンダ構成になります。 各チーム共有 中古車ビジネス 中古車開発 分析 クリエイティブ トピックス 問い合わせがあった内容をもとに改善策を皆で考える やりたい事の相談 施策の結果など 開発チームでの取り組み 開発に伴い、さまざまな取り組みを実施しています。 最近ではAIを使った開発や 外部サービスのFindy Team+を活用した開発プロセスの改善など を積極的に取り入れています。 項目 詳細 AI関係 ・Devin 　・軽微な修正や、資料作成など ・Copilot 　・ソースコードレビュー 　・実装の補佐 ・RCA(Root Cause Analysis) 　・AIによるクリティカルアラート原因分析 開発内部定例 ・スクラムイベント ・勉強会 ・ペアプロ 開発プロセス改善 ・Findy Team+ ・コードレビュー周りのプロセス改善 インタビュー 私、佐藤が関係者にインタビューしてみました。  開発FEリーダー佐藤 「野辺さん入社して3ヶ月ほど経ちましたが中古車サイト開発チームについて感じた事などありますか？」  開発P野辺 「各開発定例に参加させていただき、皆発言していて意見が言いやすい環境なんだなと特に印象的に感じました」 「そしてすぐ意見を取り入れ皆でよくしていこうという気持ちが伝わってきましたね」  開発FEリーダー佐藤 「ありがとうございます。野辺さんからも早速ご意見いただいたり、改善の提案をたくさんいただいているので非常に感謝しています」 「BEチームの最近はいかがでしょうか？金田さん」  開発BE(リーダー)金田 「そうですね、BEチームも生産性アップの試みや勉強会なども開催し、チームメンバーのスキル底上げをしていますね」 「最近だとドメイン駆動開発に注力しています」  開発FEリーダー佐藤 「ありがとうございます。いつもBEチームの取り組みや成功事例などご共有していただきFEチームの改善にも参考になっております」 「FE、BE問わずチーム全体としてよりよくしていきたいですね」 「中古車ビジネスチーム北畑さんともお話ししてみましょう。中古車サイトの開発体制についていかがでしょうか？」  中古車ビジネスチーム北畑 「いつもテンポよく新しい機能などがリリースされ日々改善されていく事を実感しています。まずやってみてPDCAを回すスタイルは我々にとって非常にマッチしたやり方だと感じています」 「職責や役職に関係なく、誰が何を言ってもよいのがこのチームの良いところです。ビジネス側で思いもつかなかったことを開発側が提案してくれることも多く、皆でビジネスをしている感覚です」  開発FEリーダー佐藤 「ありがとうございます。それぞれのチームが一丸となって開発、運用ができていると私自身も感じております」 「引き続きKINTOのファンを一人でも増やしていきたいですね」 「最後にPDM水内さんに質問です。開発チームに期待していることはどんな事ですか？」  開発PDM水内 「開発だけやっていればいいわけではなく、サービスが成長することを念頭にサイトをどう改善していくかをミーティングで会話している。そのためメンバーにも発言してもらってより良いサイトにしていきたい」 「理想の働き方として、あなたの業務はこれですと決めるつもりはないので各自出来ること、気づいたことを自発的にやってもらいたいです」 「技術はやりたいことを叶えるための手段なので技術ファーストではなく、サービスファーストで開発できるメンバーであってほしいです。その観点でメンバーを採用しています」  開発FEリーダー佐藤 「サービスファーストであり、自発的に開発できる方が理想なのですね」 「私も自社サービスを育てていくという意味で重要な視点だと思いました。ありがとうございます」 さいごに 少しでも中古車サイトの開発の進め方や雰囲気が伝われば幸いです。 また他にもチームの雰囲気や進め方などこちらでもご紹介しております！ ご興味のある方はぜひ一度読んでいただけると幸いです。 “とりあえずやってみる”から始まる開発文化。KINTO 中古車チームが語る、推進力と柔軟性の裏側