はじめに

こんにちは。my route 開発部でバックエンドチームのリーダーをしている yf です。
my route 開発部では、昨年 7 月に組織体制が変わり、新しい形で開発を進めています。

その変化に備えて、6 月から少しずつ進めてきた取り組みが、
半年たった今、チームの空気や仕事の進め方に確かな変化をもたらしています。

この半年で扱ったテーマは約 40。
一つひとつは小さな改善ですが、積み重ねることで
「開発の役割」や「プロダクトとの向き合い方」が大きく変わってきました。

本記事では、私たちがどんなステップを踏み、
なぜその変化が起きたのかを、時系列^[1]で振り返ります。

この記事はこんな人向け

• 開発が「実装担当」に閉じてしまっていることに違和感がある方
• 仕様やスケジュールが決まった状態で渡ってきて、Why を理解しづらいと感じている方
• プロダクト思考を持ちたいが、日々の開発で手応えを持てていない方
• 組織改善をしたいが、何から手を付ければいいかわからないリーダー・サブリーダー
• 「誰かを責める」のではなく、「構造を変える」アプローチを探している方

私たちが半年間かけて試行錯誤してきた取り組みが、
同じような悩みを持つチームのヒントになれば幸いです。

当時の状況と、なぜそうなっていたのか

取り組みを始める前、開発部には次のような状況がありました。

• 要件や仕様が、開発フェーズの後半で共有されることが多かった
• 開発期間が限られ、品質改善や振り返りに十分な時間を取れなかった
• スケジュールや設計の背景（Why）が、開発側に伝わりにくかった
• 結果として、実装を中心に進めざるを得ない進め方になっていた

これは、特定の誰かの判断ミスというよりも、
"役割分担とプロセスの構造がそうさせていた状態" だったと振り返っています。

プロデューサーはプロダクトを良くしようとする責任感から、
設計やスケジュールをできるだけ具体化しようとしていました。

一方で、その分、開発に共有されるタイミングが遅くなり、
開発側には「How（どう作るか）」を中心とした情報が渡る構造になっていました。

その結果、
"なぜこの機能を作るのか（Why）を理解した上で改善提案を行う余地が少なくなり、"
開発が実装中心の役割に閉じてしまっていたのです。

この状況を変えるために、
私たちは "開発組織から、プロダクト組織へ" という
大きな方向転換に踏み出しました。

半年間の全体像

目的定義 → プロセス設計 → 運用定着 → 連携強化 → 品質と戦略 → 組織文化として定着

まず、私たちが向き合っていた「仕事の流れ」の変化を、Before / After で示します。

■ 6 月 —— “目的と役割の再定義”

組織変革の起点

まず取り組んだのは、

• “私たちはどこに向かうのか“
• “チームリーダーは何を担うのか“

という意図合わせでした。
開発に関わる関係チームのリーダー全員（PDM・QA・バックエンド・モバイル）で、理想像の輪郭を描き直しました。

主なテーマ

1. 独立プロダクト組織としての目的定義
2. リーダー役割の再整理
3. 過渡期の案件対応
4. 仕事の流れ図（AS-IS）の棚卸し
5. チーム役割の再設計
6. 会議体・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 開発部では、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！
詳しくはこちらからご確認ください！