大規模プロダクトの開発を、どう前に進めるか。Yahoo! JAPANアプリのDivision Leadが向き合う「責務最適化」と自律的な組織づくり
大規模なネイティブアプリ開発では、実装力だけでは解けない課題があります。iOS と Android が並走し、Web や BFF（Backend for Frontend）とも連携しながら機能を届ける。その一方で、品質、安定運用、保守、脆弱性対応、EOL 対応まで同時に進めなければならない。こうした環境では、単に機能開発を速くするだけでは、全体の改善は進みません。
必要になるのは、システム全体の責務をどう整理するか、運用上のボトルネックをどう可視化して解消するか、そして改善を継続できる体制をどう作るか、という視点です。
今回話を聞いたのは、Yahoo! JAPAN アプリのトップページ開発組織で Division Lead を務める松浦です。インタビューでは、大規模プロダクトにおける責務最適化の考え方、AI 活用を前提にした開発フローの見直し、そして強い個人に依存しない改善の進め方について聞きました。
大規模トップページ開発では、複数の制約を同時に扱う必要がある
─ まず、現在の業務について教えてください。
松浦：**いまは Yahoo! JAPAN トップページの開発組織を見ています。Yahoo! JAPAN アプリのクライアントや BFF 領域を中心に、ビジネス案件の開発、技術改善、チーム運営、メンバー支援、関係者との調整などを担当しています。
技術面で特に注力しているのは、トップページ開発の安定化と効率化、それからシステム全体の責務最適化です。組織面では、自律的に成果を出せるチームづくりと、マネージングアップを重視しています。
─ Yahoo! JAPAN トップページのようなプロダクトならではの難しさは、どこにありますか。**
松浦：**アプリ、Web、BFF など複数のレイヤーが関わっていて、しかも多くのユーザーが使う入口のプロダクトなので、変更の影響範囲が広いことです。新規施策だけでなく、保守、EOL 対応、脆弱性対応、事故予防も並行して進めないといけません。
そのため、開発速度だけを見ればいいわけではなくて、品質、安全性、安定運用も同時に成立させる必要があります。短期の機能開発と、中長期の改善を分けて考えられないところが、この領域の難しさだと思っています。
この話は、大規模プロダクトにおける技術課題が、実装そのものよりも「構造」と「運用」に強く結びついていることを示しています。どこか 1 か所だけを最適化しても、全体として改善するとは限らない。だからこそ、システム全体を見渡した判断が必要になります。
責務最適化は、変更しやすさと安全性を両立するための設計課題
─ ネイティブアプリ開発の構造的な課題として、どんなものを感じていますか。**
松浦：**大きいのは、プロダクトイテレーションの速度がアプリのリリースサイクルに縛られていることです。軽微な修正でも、iOS と Android それぞれで実装、レビュー、QA、申請、リリースが必要になります。
さらに、同じ機能を個別に実装することで、テストや不具合対応、仕様調整も二重化しやすい。OS 差分への対応も各所に散らばって、一貫性を保ちにくくなります。
─ その状況に対して、どう向き合っているのでしょうか。
松浦：大事なのは、システム全体として責務を整理することだと思っています。アプリ本体に残すべき責務と、サーバー側へ寄せられる責務を見極めることで、変更しやすさや運用しやすさはかなり変わってきます。
過去の部分最適化の積み重ねの中で、本来はサーバーサイドが持つべき責務をクライアントが持っているようなケースもあります。そうすると変更しづらくなりますし、品質面や全体のリードタイムにも影響が出ます。
ここで重要なのは、責務最適化が単なる設計美の話ではないことです。責務の置き場所がずれていると、変更コストが上がるだけでなく、レビューや QA（品質保証）、リリース運用にも波及します。つまり、設計上の不整合が、そのまま開発生産性や運用負荷の問題として現れるわけです。
─ その責務整理の文脈で、SDUI（Server-Driven UI）のような取り組みもあるのでしょうか。
松浦：そうですね。SDUI（Server-Driven UI）のような取り組みも選択肢のひとつではあります。ただ、主題は特定の技術を入れることではありません。どこに責務を持たせるのが全体としてよいのかを考えることが先にあって、その結果として手段を選ぶ、という順番です。
一気に全部変えるのではなくて、大きめの案件をきっかけにしながら、基盤をひとつずつ紐解いて改善していく進め方になりますね。
この「手段より先に責務を見る」という姿勢は、大規模な既存システムを扱ううえで本質的です。モダンな技術を採用すること自体ではなく、その技術がどの構造課題を解くのかが問われている、と言い換えてもよいでしょう。
AI 活用でも、ボトルネックは運用の中に残る
─ 開発生産性向上の取り組みについても教えてください。
松浦：最近は AI 駆動開発のワークフロー整備に取り組んでいます。設計、タスク分解、実装、テスト関連のスキルを整えたり、共有したりしながら、AI を使って効率を上げつつ、品質や安定性も上げていく取り組みです。
特に、実装に入ったあとのフェーズでは成果が出始めています。今期は、AI を完全利用または部分利用したプルリクエストが大部分を占める状態まで持っていく目標を置いていて、現時点でもかなり活用が進んでいます。
─ AI 活用が進むと、別のボトルネックも出てきそうです。
松浦：そうですね。コード生成が増えると、今度はレビューが詰まりやすくなります。そこに対しては、AI を活用したレビューとセルフレビューをしっかり行うことと、リードタイムを自動で可視化・通知する仕組みを組み合わせています。基準時間を超えたら分かるようにして、滞留を放置しない運用にしています。
以前から、どこで滞留しているかを可視化して、ボトルネックを定量的に見ることは重視していました。レビュー待ちが詰まっていると分かれば、モブプロを試す。改善を小さく試して、良ければ定着させる。だめなら別のやり方に切り替える。そういう進め方です。
ここで見えてくるのは、AI 導入によって実装速度が上がっても、開発フロー全体が自動的に速くなるわけではないという点です。実装の先にはレビューがあり、レビューの先には品質保証や運用があります。つまり、AI 活用は「個人の作業速度」を変える一方で、「チームの流れ」を改善するには別の設計が必要になります。
─ 技術導入そのものより、使い方や回し方を重視しているのですね。
松浦： はい。外から見えているプラクティスをそのまま持ち込むのではなく、なぜやるのか、どんな状態を実現したいのかを明確にすることが大事だと思っています。導入後に何を見るか、何をもって効果ありと判断するかも先に決めておく。そうしないと、やること自体が目的化してしまうので。
この進め方は、AIに限らず改善施策全般に当てはまります。まず課題を明確にし、次に計測の軸を置き、小さく試し、効果があれば定着させる。技術導入そのものではなく、改善のループ（PDCA サイクル）をどう回すかが重要だという考え方です。
改善を継続するには、役割と判断を分散させる必要がある
─ 組織づくりでは、どんなことを意識していますか。
松浦： ひとつは、DL（Division Lead：部門責任者）がボトルネックにならないことです。人数が増えてくると、判断も推進も全部ひとりに集めるのは無理があります。なので、役割と責任を分散できる体制を作っています。
具体的には、案件の実行推進、開発生産性、保守運用・安定性といった論点ごとに役割を分担し、それぞれを主導できる人を立てています。判断や推進が一箇所に集中しないようにしながら、改善を継続しやすい体制を作っています。
この役割設計が面白いのは、開発組織の課題を単に「マネジメント」で包まず、実行、アジリティ（俊敏性）、サステナビリティ（持続可能性）という論点に分けて扱っている点です。大規模組織では、技術課題も運用課題もひとりのリーダーに集約しがちですが、それでは改善の速度も質も頭打ちになります。責任を明確に分けること自体が、改善のための設計になっています。
─ 任せる時に、大事にしていることは何でしょうか。
松浦： 背景、目的、期待値は伝えますが、やり方まで細かく決めすぎないようにしています。チームが自分たちで考えて、判断して、学習できる余白を残したいからです。
もちろん、困っていることや障害は拾いますし、必要なら外側の調整やリソース確保もします。ただ、正解を渡すより、チームが自走できる状態を作ることの方が大事だと思っています。
─ その考え方は「マネージングアップ」にもつながっていますか。
松浦： そうですね。上司からの指示を待つのではなく、メンバーの側から課題やリスク、判断が必要なことを整理して共有してもらうことを重視しています。上司とメンバーが相互に働きかけ合える関係の方が、変化には強いですし、チームとしても成果を出しやすいと思っています。
問題が起きた時も、個人を責めるのではなくて、組織の学びに変えて、再発防止として仕組みに残していく。そういうフィードバックループ（改善サイクル）を回し続けることが、組織の強さにつながると考えています。
ここでも、松浦の関心は一貫しています。個人の頑張りに依存するのではなく、再現可能な仕組みに落とすこと。責務設計の話と同じく、組織運営においても「構造を変える」ことを重視しているのが分かります。
AI 活用が進むほど、設計や判断の重みは増していく
─ 技術選定や設計判断では、どんな軸を持っていますか。
松浦：流行っている技術だから入れる、という考え方はしません。プロダクトの課題やペインポイントに効くかどうかを基準にしています。
それと、今すぐ速く作ることと、後から変えにくいものをどう見極めるかのバランスは、常に意識しています。非機能要件（Non-functional Requirements）、アーキテクチャ、拡張性、性能、可用性みたいに、後から変えると大きなコストになるものは、最初にきちんと見ておく必要があります。
─ AI で実装が速くなる時代に、より重要になることはありますか。**
松浦：実装のスピードは上がっていくと思いますが、それだけでプロダクトが良くなるわけではないと思っています。何を作るべきかを見極めることや、変化に強く、品質を安定的に保てるコードベースにしていくことは、むしろより重要になるはずです。
また、価値につながっていない作業や、形骸化しているプロセス、使われていない機能を見直していくことも必要だと思っています。単に速く作るだけではなく、継続的に価値を届け続けられる状態をどう作るか、そこが問われるのだと思います。
この話は、AI 時代の開発において「実装速度の向上」と「プロダクトの改善」を分けて考える必要があることを示しています。速く書けることは重要ですが、何を残し、何を削り、どの構造を維持するのかという判断は、むしろ以前より重くなっているのかもしれません。
技術に強いまま、より広い責任を持つ面白さ
─ 松浦自身の強みは、どこにあると感じていますか。**
松浦：技術面では設計力だと思っています。複数レイヤーにまたがる開発の中で、短期的な実装のしやすさだけではなく、中長期の保守性や変更容易性も踏まえて、どこに責務を持たせるべきかを考えることです。
組織面では、現場の具体的な困りごとを拾いながら、課題を整理して、優先度をつけて、必要なら関係者を巻き込みながら Next Action まで落とし込むところだと思います。
─ Web、バックエンド、Android、iOS と複数領域を経験してきたことは、今の仕事にどう効いていますか。**
松浦：直近では iOS が一番深い専門性ですが、それ以前に Web やバックエンド、Android も見てきたことで、システム全体を見渡しやすくなっている実感があります。小さい範囲だけではなく、より大きな範囲で判断できることは、今のトップページ開発組織の DL（Division Lead）という役割にかなり効いていると思います。
─ 最後に、この組織にはどんな魅力があると思いますか。**
松浦：多くのユーザーに使われるアプリケーションの開発に携われること、世の中の人に役立つものを直接届けられることは大きいです。企画やデザイナーと連携しながら、要件定義から開発、リリースまで一貫して関われるので、自分の仕事が価値につながっている実感も持ちやすいと思います。
それに加えて、大規模アプリ特有の技術的に難しい課題に取り組めることも魅力です。品質と開発スピードを両立する、複雑な組織で責務を整理する、そうした簡単ではない問題に向き合いながら、自分の貢献をより広い範囲に効かせられる。そこに面白さがあると思います。
大規模開発では、責務設計と運用設計を同時に考える必要がある
松浦の話から見えてきたのは、大規模ネイティブアプリ開発における改善が、単発の技術導入では完結しないということでした。
どこに責務を置くか。
レビューや品質保証の流れをどう回すか。
改善を継続できる役割と判断の分散をどう作るか。
そして、AI 活用によって変わる部分と、変わらず設計が問われ続ける部分をどう見極めるか。
大規模な開発では、これらを別々の問題としてではなく、ひとつながりの構造として扱う必要があります。責務設計、運用設計、組織設計を同時に考えながら、システムとチームの両方を前に進めていく。その実践こそが、今回のインタビューから見えてきた技術的なテーマだったように思います。
原文を表示
大規模なネイティブアプリ開発では、実装力だけでは解けない課題があります。iOSとAndroidが並走し、WebやBFF（Backend for Frontend）とも連携しながら機能を届ける。その一方で、品質、安定運用、保守、脆弱性対応、EOL対応まで同時に進めなければならない。こうした環境では、単に機能開発を速くするだけでは、全体の改善は進みません。
必要になるのは、システム全体の責務をどう整理するか、運用上のボトルネックをどう可視化して解消するか、そして改善を継続できる体制をどう作るか、という視点です。
今回話を聞いたのは、Yahoo! JAPANアプリのトップページ開発組織でDivision Leadを務める松浦です。インタビューでは、大規模プロダクトにおける責務最適化の考え方、AI活用を前提にした開発フローの見直し、そして強い個人に依存しない改善の進め方について聞きました。
大規模トップページ開発では、複数の制約を同時に扱う必要がある
─ まず、現在の業務について教えてください。
松浦：**いまはYahoo! JAPANトップページの開発組織を見ています。Yahoo! JAPANアプリのクライアントやBFF領域を中心に、ビジネス案件の開発、技術改善、チーム運営、メンバー支援、関係者との調整などを担当しています。
技術面で特に注力しているのは、トップページ開発の安定化と効率化、それからシステム全体の責務最適化です。組織面では、自律的に成果を出せるチームづくりと、マネージングアップを重視しています。
─ Yahoo! JAPANトップページのようなプロダクトならではの難しさは、どこにありますか。**
松浦：**アプリ、Web、BFFなど複数のレイヤーが関わっていて、しかも多くのユーザーが使う入口のプロダクトなので、変更の影響範囲が広いことです。新規施策だけでなく、保守、EOL対応、脆弱性対応、事故予防も並行して進めないといけません。
そのため、開発速度だけを見ればいいわけではなくて、品質、安全性、安定運用も同時に成立させる必要があります。短期の機能開発と、中長期の改善を分けて考えられないところが、この領域の難しさだと思っています。
この話は、大規模プロダクトにおける技術課題が、実装そのものよりも「構造」と「運用」に強く結びついていることを示しています。どこか1か所だけを最適化しても、全体として改善するとは限らない。だからこそ、システム全体を見渡した判断が必要になります。
責務最適化は、変更しやすさと安全性を両立するための設計課題
─ ネイティブアプリ開発の構造的な課題として、どんなものを感じていますか。**
松浦：**大きいのは、プロダクトイテレーションの速度がアプリのリリースサイクルに縛られていることです。軽微な修正でも、iOSとAndroidそれぞれで実装、レビュー、QA、申請、リリースが必要になります。
さらに、同じ機能を個別に実装することで、テストや不具合対応、仕様調整も二重化しやすい。OS差分への対応も各所に散らばって、一貫性を保ちにくくなります。
─ その状況に対して、どう向き合っているのでしょうか。**
松浦：**大事なのは、システム全体として責務を整理することだと思っています。アプリ本体に残すべき責務と、サーバー側へ寄せられる責務を見極めることで、変更しやすさや運用しやすさはかなり変わってきます。
過去の部分最適化の積み重ねの中で、本来はサーバーサイドが持つべき責務をクライアントが持っているようなケースもあります。そうすると変更しづらくなりますし、品質面や全体のリードタイムにも影響が出ます。
ここで重要なのは、責務最適化が単なる設計美の話ではないことです。責務の置き場所がずれていると、変更コストが上がるだけでなく、レビューやQA、リリース運用にも波及します。つまり、設計上の不整合が、そのまま開発生産性や運用負荷の問題として現れるわけです。
─ その責務整理の文脈で、SDUI（Server-Driven UI）のような取り組みもあるのでしょうか。**
松浦：**そうですね。SDUIのような取り組みも選択肢のひとつではあります。ただ、主題は特定の技術を入れることではありません。どこに責務を持たせるのが全体としてよいのかを考えることが先にあって、その結果として手段を選ぶ、という順番です。
一気に全部変えるのではなくて、大きめの案件をきっかけにしながら、基盤をひとつずつ紐解いて改善していく進め方になりますね。
この「手段より先に責務を見る」という姿勢は、大規模な既存システムを扱ううえで本質的です。モダンな技術を採用すること自体ではなく、その技術がどの構造課題を解くのかが問われている、と言い換えてもよいでしょう。
AI活用でも、ボトルネックは運用の中に残る
─ 開発生産性向上の取り組みについても教えてください。**
松浦：**最近はAI駆動開発のワークフロー整備に取り組んでいます。設計、タスク分解、実装、テスト関連のスキルを整えたり、共有したりしながら、AIを使って効率を上げつつ、品質や安定性も上げていく取り組みです。
特に、実装に入ったあとのフェーズでは成果が出始めています。今期は、AIを完全利用または部分利用したプルリクエストが大部分を占める状態まで持っていく目標を置いていて、現時点でもかなり活用が進んでいます。
─ AI活用が進むと、別のボトルネックも出てきそうです。**
松浦：**そうですね。コード生成が増えると、今度はレビューが詰まりやすくなります。そこに対しては、AIを活用したレビューとセルフレビューをしっかり行うことと、リードタイムを自動で可視化・通知する仕組みを組み合わせています。基準時間を超えたら分かるようにして、滞留を放置しない運用にしています。
以前から、どこで滞留しているかを可視化して、ボトルネックを定量的に見ることは重視していました。レビュー待ちが詰まっていると分かれば、モブプロを試す。改善を小さく試して、良ければ定着させる。だめなら別のやり方に切り替える。そういう進め方です。
ここで見えてくるのは、AI導入によって実装速度が上がっても、開発フロー全体が自動的に速くなるわけではないという点です。実装の先にはレビューがあり、レビューの先には品質保証や運用があります。つまり、AI活用は「個人の作業速度」を変える一方で、「チームの流れ」を改善するには別の設計が必要になります。
─ 技術導入そのものより、使い方や回し方を重視しているのですね。**
松浦：**はい。外から見えているプラクティスをそのまま持ち込むのではなく、なぜやるのか、どんな状態を実現したいのかを明確にすることが大事だと思っています。導入後に何を見るか、何をもって効果ありと判断するかも先に決めておく。そうしないと、やること自体が目的化してしまうので。
この進め方は、AIに限らず改善施策全般に当てはまります。まず課題を明確にし、次に計測の軸を置き、小さく試し、効果があれば定着させる。技術導入そのものではなく、改善のループをどう回すかが重要だという考え方です。
改善を継続するには、役割と判断を分散させる必要がある
─ 組織づくりでは、どんなことを意識していますか。**
松浦：**ひとつは、DL（Division Lead）がボトルネックにならないことです。人数が増えてくると、判断も推進も全部ひとりに集めるのは無理があります。なので、役割と責任を分散できる体制を作っています。
具体的には、案件の実行推進、開発生産性、保守運用・安定性といった論点ごとに役割を分担し、それぞれを主導できる人を立てています。判断や推進が一箇所に集中しないようにしながら、改善を継続しやすい体制を作っています。
この役割設計が面白いのは、開発組織の課題を単に「マネジメント」で包まず、実行、アジリティ、サステナビリティという論点に分けて扱っている点です。大規模組織では、技術課題も運用課題もひとりのリーダーに集約しがちですが、それでは改善の速度も質も頭打ちになります。責任を明確に分けること自体が、改善のための設計になっています。
─ 任せる時に、大事にしていることは何でしょうか。**
松浦：**背景、目的、期待値は伝えますが、やり方まで細かく決めすぎないようにしています。チームが自分たちで考えて、判断して、学習できる余白を残したいからです。
もちろん、困っていることや障害は拾いますし、必要なら外側の調整やリソース確保もします。ただ、正解を渡すより、チームが自走できる状態を作ることの方が大事だと思っています。
─ その考え方は「マネージングアップ」にもつながっていますか。**
松浦：**そうですね。上司からの指示を待つのではなく、メンバーの側から課題やリスク、判断が必要なことを整理して共有してもらうことを重視しています。上司とメンバーが相互に働きかけ合える関係の方が、変化には強いですし、チームとしても成果を出しやすいと思っています。
問題が起きた時も、個人を責めるのではなくて、組織の学びに変えて、再発防止として仕組みに残していく。そういうフィードバックループを回し続けることが、組織の強さにつながると考えています。
ここでも、松浦の関心は一貫しています。個人の頑張りに依存するのではなく、再現可能な仕組みに落とすこと。責務設計の話と同じく、組織運営においても「構造を変える」ことを重視しているのが分かります。
AI活用が進むほど、設計や判断の重みは増していく
─ 技術選定や設計判断では、どんな軸を持っていますか。**
松浦：**流行っている技術だから入れる、という考え方はしません。プロダクトの課題やペインポイントに効くかどうかを基準にしています。
それと、今すぐ速く作ることと、後から変えにくいものをどう見極めるかのバランスは、常に意識しています。非機能要件、アーキテクチャ、拡張性、性能、可用性みたいに、後から変えると大きなコストになるものは、最初にきちんと見ておく必要があります。
─ AIで実装が速くなる時代に、より重要になることはありますか。**
松浦：**実装のスピードは上がっていくと思いますが、それだけでプロダクトが良くなるわけではないと思っています。何を作るべきかを見極めることや、変化に強く、品質を安定的に保てるコードベースにしていくことは、むしろより重要になるはずです。
また、価値につながっていない作業や、形骸化しているプロセス、使われていない機能を見直していくことも必要だと思っています。単に速く作るだけではなく、継続的に価値を届け続けられる状態をどう作るか、そこが問われるのだと思います。
この話は、AI時代の開発において「実装速度の向上」と「プロダクトの改善」を分けて考える必要があることを示しています。速く書けることは重要ですが、何を残し、何を削り、どの構造を維持するのかという判断は、むしろ以前より重くなっているのかもしれません。
技術に強いまま、より広い責任を持つ面白さ
─ 松浦自身の強みは、どこにあると感じていますか。**
松浦：**技術面では設計力だと思っています。複数レイヤーにまたがる開発の中で、短期的な実装のしやすさだけではなく、中長期の保守性や変更容易性も踏まえて、どこに責務を持たせるべきかを考えることです。
組織面では、現場の具体的な困りごとを拾いながら、課題を整理して、優先度をつけて、必要なら関係者を巻き込みながらNext Actionまで落とし込むところだと思います。
─ Web、バックエンド、Android、iOSと複数領域を経験してきたことは、今の仕事にどう効いていますか。**
松浦：**直近ではiOSが一番深い専門性ですが、それ以前にWebやバックエンド、Androidも見てきたことで、システム全体を見渡しやすくなっている実感があります。小さい範囲だけではなく、より大きな範囲で判断できることは、今のトップページ開発組織のDLという役割にかなり効いていると思います。
─ 最後に、この組織にはどんな魅力があると思いますか。**
松浦：
多くのユーザーに使われるアプリケーションの開発に携われること、世の中の人に役立つものを直接届けられることは大きいです。企画やデザイナーと連携しながら、要件定義から開発、リリースまで一貫して関われるので、自分の仕事が価値につながっている実感も持ちやすいと思います。
それに加えて、大規模アプリ特有の技術的に難しい課題に取り組めることも魅力です。品質と開発スピードを両立する、複雑な組織で責務を整理する、そうした簡単ではない問題に向き合いながら、自分の貢献をより広い範囲に効かせられる。そこに面白さがあると思います。
大規模開発では、責務設計と運用設計を同時に考える必要がある
松浦の話から見えてきたのは、大規模ネイティブアプリ開発における改善が、単発の技術導入では完結しないということでした。
責務をどこに置くか。
レビューや品質保証の流れをどう回すか。
改善を継続できる役割と判断の分散をどう作るか。
そして、AI活用によって変わる部分と、変わらず設計が問われ続ける部分をどう見極めるか。
大規模な開発では、これらを別々の問題としてではなく、ひとつながりの構造として扱う必要があります。責務設計、運用設計、組織設計を同時に考えながら、システムとチームの両方を前に進めていく。その実践こそが、今回のインタビューから見えてきた技術的なテーマだったように思います。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み