この記事は、Money Forward Engineers Advent Calendar 2025の12月15日の記事です。

English versionglobal.moneyforward-dev.jp

マネーフォワード クラウド会社設立のプロダクト開発チームでリーダーをしている廣瀬です。

私たちの開発チームは、メンバーの7割以上がマネーフォワード ベトナムに所属する非日本語話者です。私は今年3月、チーム初の日本人エンジニアとしてジョインしました。国籍という意味ではマイノリティーであるこの環境を楽しんでいます。最近はベトナム語をチームメンバーから教わっています。日本人にとっては発音がめちゃくちゃ難しいのですが、そこが結構面白いところです。

直近約9ヶ月間、私はチームの生産性向上とより大きな価値創造を目指し、コミュニケーションのあり方に変化を加えてきました。その結果、この半年でチームは劇的に進化しました。

半年でリリース頻度3倍、ベロシティ2〜3倍、リリース起因のクリティカルな不具合0件を達成

今回は、私たちが直面した課題、「情報の非対称性」を解消するために加えたプロセス、そしてその結果について振り返ります。

AS-IS

私たちのチームは、非日本語話者エンジニアと、日本語話者のプロダクトマネージャー（PdM）/デザイナーでプロダクトを運営するという構成を長年続けてきました。

私がジョインする以前のチーム構成は以下の図の通りです。

Note: 矢印はメインのコミュニケーションルートを示しています。矢印のない部分についても、一部必要な時に翻訳ツールやAcceleratorの活動によってやり取りされていました。また、普段からエンジニアリングマネージャーは適切なタイミングで各ステークホルダーとコミュニケーションをとりますが、矢印の数が増えてしまい、図が複雑になるため本記事では意図的に省略します。

当時、チームには、日本語話者と非日本語話者間の言語の壁を取り払う役割として「Accelerator」という役割の方がアサインされていました。Acceleratorはエンジニアリングのバックグラウンドはないものの、その通訳・促進スキルによってチームの連携を強力にサポートしていました。

言語の壁ではなく「情報の非対称性」

弊社は2021年頃に開発組織の英語化目標を掲げ、推進してきました。私自身、新卒入社当時（2022年）は英語の読み書きもままならない状態でした。今でも、完璧にニュアンスを使い分けたり、流暢に英語を話したりはできません。もちろん、相手の話が聞き取れないケースは発生します。チームメイトも同様で、ネイティブ英語話者は一人もいません。

現在弊社が目指すのは「英語化・国際化」ではなく「グローバル化」です。つまり、完璧な英語を求めるのではなく、多くの制約や多様な文化・考え方の違いを理解した上で、不完全でもお互い正しく意思疎通しながら物事を達成することを重視しています。（参考）

相手の使う言語をマスターしていない場合、期待と結果の差分が生じると、「言語の壁」が原因だと捉えがちです。私自身もそう感じていました。

お互い同じ言語のネイティブ話者を使っていたら問題なく進められていたはずだ。

しかし、不完全でも伝わるコミュニケーションをしなければならない環境において、本質的な課題は翻訳の正確さではありません。真の課題はコンテキスト（背景情報）の不足です。この記事では、この日本語話者側と非日本語話者側で発生している、プロダクトの背景や意思決定プロセスに関する知識の偏りを「情報の非対称性」と表現します。

• 相手と自分の「当たり前」の違い
• 知っていること・意識・優先順位の差

これらのコンテキストが揃っていないことで、期待する合意や前進が生まれないケースがほとんどでした。

私がジョインする前、開発チームは通訳手段は持っていたものの、日本側組織の内部情報や開発依頼に至るプロセスの詳細など、広範囲かつ詳細なコンテキストを見渡すことは困難でした。

情報の非対称性により、AS-ISの体制では以下のような課題を抱えていました。

• エンジニアの責任範囲の狭さ エンジニアは2〜3年間にわたりPdMから与えられた詳細仕様を文字通り受け取る環境にあったため、ユーザーの利用背景や仕様の意思決定背景への解像度が低い状態でした。
• 仕様のブラックボックス化: 初回リリースから7〜8年が経過し、仕様書や背景情報が十分に整理されておらず、実装コードを見ないとプロダクトの動きを網羅的に理解することが困難でした。
• PdMへの負荷集中:エンジニアが仕様の意思決定背景への解像度が低く、開発側の技術負債を抑えるための提案が PdMになされないため、PdMが詳細仕様の検討から開発依頼まで一手に担うことになり、PdMの負荷が集中していました。
• バグの発生: 結果として、プロダクト開発チームは隠れた仕様を見落としたリリースによりバグを発生させ、「詳細な仕様を与えられたのにリリースできない」「作ったらバグが出た」と、両者（PdMとエンジニア）が共通の困難に直面している状態でした。

チームの中で最も広い範囲を見渡し、日本側組織の解像度を詳細まで向上させ、全エンジニアの「見える範囲」を意図的に広げることをミッションとして特定し、改善に取り組んできました。

Connectorとしての挑戦

上記の課題感を踏まえ、ジョイン後数ヶ月間の私は「Connector」のあるべき姿を検討しました。プロダクトを取り巻く全組織から均一に情報を収集すること、課題・優先度の設定、そして「Connectorが不要な世界」を作る計画の推進まで、一連の流れ全てにオーナーシップを持ちました。

受動的なチームから「WhatからHow」を一貫して担うチームへ

Connectorという役割を持ってジョインして数ヶ月、まず取り組んだのは、長期間続いた「エンジニアへの限定的な情報提供」の状態を解消することでした。PdMには詳細仕様を書かないことを依頼し、十分な背景情報と明確な期待値、詳細なユースケースの共有を徹底しました。

その結果、開発チームは抽象的な要件を与えられても、自分たちで仕様を検討し、PdMと認識合わせをしながらリリースできるようになり、かつリリース時の不具合も見られなくなりました。これにより、チームは「What（何を）の検討から、How（どのように）の実装、そしてリリースに至るまで一貫した責任を持つ」体制へと進化したのです。

Connectorの負荷集中とスケーラビリティの限界

当初の自分は、チームのスコープを広げ、抽象的な課題解決を繰り返すことでチームの成長を期待していました。一方、Connectorへの負荷集中は凄まじいものでした。プロダクトの要求定義からリリースまでの全てのステップで、Connectorは確認依頼や相談を受けており、スケールは期待できない体制でした。また、Connectorが誤って理解した際のインパクトも大きいです。加えて、本来私が期待されていた日本語の仕様読解が要求される政府APIを取り巻く機能開発のプロジェクトマネジメント、テクニカルリード、メンバーのマネジメントなど、チームとプロダクトさらにスケールするための役割に手が回らなくなってしまいました。

Fairな組織を作りたい

マネーフォワードは、国籍、背景によらず、メンバーに均一に機会が提供される「フェアな組織」を目指しています。

Connectorに依存し、その人がいないとプロダクトを前に進められない環境は、真にフェアな組織とは言えないと思っています。優秀なグローバルメンバーが、Connectorがいないと独立した意思決定ができない。その結果本来の能力に見合った機会を得ることが難しくなってしまう。そんな状態を解消したいと思いました。

目指すべき姿は、グローバルメンバーがあらゆる日本組織の情報に直接アクセスし、Connectorに依存せず自ら意思決定を行い、プロダクトを推進できる組織です。私は、Connectorとしての自分がいなくなったほうが、メンバー全員が自立し、成長できる。ハッピーになれると考えています。

半年経った今、チームはこの図のような状態へとシフトしました。

Note: 組織によってコミュニケーションの頻度は異なります。

この新しい構造における重要な成果は、情報のアクセスと言語能力の切り離しに成功したことです。言語的な翻訳の必要性そのものは残っていますが、Connectorが集中して負っていた言語的・文脈的な仲介の重荷は、システム全体に分散され、大半が自動化されました。

コミュニケーションのサポートは主に以下の要素によって担われています。

• AIや要求フォームを活用した情報の構造化（戦略2と3。詳細は後述）
• 翻訳ツール、バイリンガルメンバーの能力を活用したコミュニケーション促進（戦略3と4。詳細は後述）

「言語の壁」が完全に消えたわけではありませんが、それが生み出していたボトルネックは解消に向かっています。私たちは、一人の人間による集中型の仲介に頼る体制から、分散型サポートと構造化された曖昧さのないコンテキスト共有システムを活用する体制へと移行したのです。

エンジニアに近い組織ほどコンテキストの共有は進み、メンバー各自がそれぞれの責任範囲にオーナーシップを持ち、Connectorという役割を必要とせず、意思決定できる環境へとシフトしています。コミュニケーションのサポートは概ね不要になり、Connectorという役割を持たない、リーダーの役割を持つ自分が本人の意思決定をサポートする形に変わっています。この状態は、同じ国籍の人が、同じ国籍の人をトレーニングする形と変わりません。

開発チーム全体の負荷が適切に分散された結果、開発者が与えられたものの実装に終始するのではなく、プロダクトナレッジのシェアなどチーム間の情報共有のための時間を作ったり、技術負債やチーム課題について議論したりと、自律的に改善を進められるチームへと変化しました。

Fairな組織を作るための戦略：情報圧縮の回避と自律性の獲得

Fairな組織への道のりは困難でした。上司や外部チームからの協力、そしてPdMやデザイナーを含むプロダクト開発チームのメンバーの努力によってシフトできています。特に、日英バイリンガルスクラムマスターと日本語話者のベトナム国籍エンジニアをチームに迎えられたことは、大きな推進力となりました。

私たちは、情報の非対称性を根本的に解消し、自律的な意思決定を可能にするため、以下の4つの主要戦略に取り組みました。

1. ネイティブ同士の「情報圧縮」の回避

職種間のコミュニケーションにおいて、ネイティブ日本語話者であるPdMと私の間で、短時間で大量の情報交換が成立していました。しかし、この際に情報が圧縮され、PdMが持つ「アイデア」や「背景条件」といった重要なコンテキストが省略されて非日本語話者のエンジニアに伝わってしまうことで、非日本語話者のエンジニアのプロダクト理解が限定的になるという問題が発生していました。

私自身もこの情報の圧縮に気づくことができませんでしたが、バイリンガルスクラムマスターが私たちのコミュニケーションを観察し、教えてくれたことで初めてこの構造的な課題が明らかになりました。私のようなConnectorが情報を圧縮してしまう構造こそが、エンジニアの理解を限定的なものにしていました。

この課題に対し、私たちは早期にネイティブ間の情報圧縮を回避するプロセスへ変更し、Connectorを経由せず、エンジニアにコンテキストを直接共有する仕組みを作りました。

2. AIによる要求要件の標準化とコンテキストの完全伝達

PdMがConnectorのサポートなしに、非日本語話者のエンジニアにもコンテキストを完全に伝達できる基盤を整備しました。

PdMが利用する要求定義のAIテンプレートを整備し、以下の要素を必ず構造化して含めるようにしました。

• 背景
• ユーザーストーリー（明確なペルソナ付き）
• 受け入れ条件（GIVEN, WHEN, THEN形式）

AIテンプレートによって生成された構造化された要件の例（仮のプロダクトを使った例で、内容に意味はありません）

### 背景現在の健康診断予約プロセスは、営業時間内の電話対応が必要であり、待ち時間が長いため、ユーザーの40%が予約を断念している。初めて利用するユーザーは、多くの紙のフォームを記入するために直接クリニックを訪問する必要があり、予防医療へのアクセス障壁となっている。...### ユーザストーリー健康意識の高い個人として、私は自分の健康診断履歴を記憶し、パーソナライズされた推奨事項と予約オプションを提供するオンライン予約システムを望んでいます。それにより、登録プロセスを繰り返したり、重要なフォローアップ検診を見逃したりすることなく、適切な健診を簡単に予約できるようになります。### 受け入れ条件（実際は表形式）ID: 1タイトル: 初回ユーザ登録GIVEN: 新規ユーザ（未登録）が健康診断サービスに初回アクセスするWHEN: 予約するをクリックするTHEN: システムが、個人情報、病歴、希望のクリニック所在地、保険詳細を収集する包括的な登録フォームと、明確なプライバシーポリシーへの同意を表示するID: 2タイトル: ユーザの再訪...

構造化された要求がセットでエンジニアに渡ることは非常に重要で、非ネイティブ英語話者でも理解しやすいものです。また、元々エンジニアの範囲外のコンテキストが不足しているエンジニアにとっても、理解しやすいものとなります。

実際に私自身も、このテンプレートを使って生成された別プロダクトの要求定義を読んだのですが、まったく背景知識がなくても、簡単にユーザーとプロダクトの動きがイメージできました。

構造化された要求により、非ネイティブ英語話者であるエンジニア全員が、一度読んだだけで概ね要件を完全に理解できるようになり、Refinementの効率が大幅に向上しました。開発開始後のPdM、Connectorへのコミュニケーションが減り、QAエンジニアがPdMのレビューが不要なレベルの精緻なテスト計画を作成できるなど、効果は絶大でした。

3. 開発チーム外からの依頼フロー標準化

外部依頼（問い合わせ、マーケティングチームからのプロダクト改善要求など）も、PdMが窓口となる一元的な情報経路という構造によって発生する情報圧縮がボトルネックとなっていました。

以前のフローが抱えていた構造的な制約

• 問い合わせ対応におけるコンテキストのロス: PdMが窓口として一次対応をする構造上、顧客からの詳細な問い合わせ情報が、解釈や相互のやり取りによって、生の情報（Raw Data）として開発チームへ伝わりにくくなっていました。結果として、調査に必要なコンテキストの不足や分散、非日本語話者メンバーによる問題特定の時間や解決までのリードタイムが長期化する一因となっていました。
• 外部機能要求における初期連携の遅延: マーケティングチームからの機能要求がPdMを通じて詳細仕様として定義・確定した後に開発チームへ渡されるフローが主でした。このフローでは、エンジニアが要求の初期段階で技術的な視点から効率的なアプローチを提案する機会が制限されていました。

整備したツールと効果

情報圧縮を防ぎ、PdMの負荷を軽減し、エンジニアの自律性を高めるため、以下のツールを整備しました。外部チームがPdMを経由せずに、可能な限りエンジニアに構造化された情報を直接提供できる体制にシフトしました。

• 要求依頼フォーム・問い合わせ依頼フォーム（Slack ワークフロー）の導入
• 翻訳ツール（Slackbot）の駆使
• 自動タスク起票（Jira/Asana連携）

構造化された依頼フォームとタスクボードが連携することで、日本語で問題なく依頼が行われ、PdMのヘルプや補足、解釈なしに、開発者間で直接調査・解決を進める体制へと進化しました。この変化は、PdMの負荷軽減だけでなく、開発チームの自律的な貢献を可能にしました。

4. バイリンガルミーティングの推進

同期的な交流の機会を増やし、情報格差を埋めるための取り組みとして、バイリンガルミーティングを徐々に増やしています。非英語話者（デザイナー）と非日本語話者（エンジニア）が、翻訳ツールやチーム内の日英両方の言語が利用できるメンバーの力を借りて、同じミーティングに参加します。Zoomの自動翻訳やNotionの文字起こしなども同時利用しています。

同期的な交流が増えたことで、日本語がわかるエンジニアとそうではないエンジニア間の情報格差は確実に解消に向かっています。自分よりはるかに会社設立プロダクトの経験が長いベトナム居住のメンバーが、より良いデザインや体験について提案できている環境を作ることができたのは、すごく嬉しいことです。

これから

直近半年間で獲得した急成長を次のフェーズでは安定させ、より高い品質を目指します。日本語というアドバンテージを持っているかどうかに関わらず、次世代のグローバルリーダーのもとで、チームが物事を強く前進させられるように、プロダクト開発組織全体をまた一段進化させようとしています。

まだまだ課題は山積みです。今回話したトピックに関連して認識している課題を一つ紹介します。

チーム内における情報圧縮の課題は解消に向かっていますが、バイリンガル組織同士のコミュニケーション連携が必要になった時、事態は再び複雑になります。この記事では、チーム内の日本人同士の「情報の圧縮」に焦点を当てましたが、この問題は、チームを超えた先の日本人とも発生します。英語話者と英語話者間、バイリンガル間でも発生します。

すでに弊社で提供されているように、複数サービスの連携機能があります。例えばサービスを跨ぐ複雑なドメインを要する要件と、別チームが管理する基盤マイクロサービスが同時に関わるような問い合わせ対応などが具体例として挙げられるように思います。同じように、関係者全員が最新かつ正確な知識を獲得しながら自律的に意思決定し、課題解決に向かっていける仕組みを今の組織をベースとして作ることはできるのでしょうか。楽しくなってきましたね。

私たちの周りには、一緒に変化を乗り越えてくれた優秀なメンバーと、計り知れないほどのサポートや相互理解に協力いただいたマネージャーや外部チームに溢れています。

どんな課題でも、認識できれば基本解決に運べると捉えています。国籍や役割は関係なく、プロダクトの成長に貢献したい人がプロダクトについて自由に提案し合い、さまざまな観点でプロダクトがより良いものになる。そしてユーザに更なる価値を提供できる、そんな真にフェアな組織を引き続き目指していきます。