Vol.13 Bill Oneで実践する日本×セブのグローバル開発体制強化

この記事は、Bill One開発Unit ブログリレー2025の第13弾になります！

（数日早いですが）メリークリスマス🎅
技術本部Bill One Engineering Unitでソフトウェアエンジニアをしている田坂です。

私が所属するPO (Purchase Order) グループは、請求書・発注書の照合を行う機能開発を担っております。合計4チームで構成されるグループですが、日本は1チームのみで、フィリピンのセブ島を拠点とするSGDC（Sansan Global Development Center）の3チームを中心とする組織です。
2025年10月末、数ヶ月以上の開発期間を経て「AI自動照合」機能をリリースしました。これは、発注データとBill Oneに登録されている請求書を、総額や明細単位で自動照合する機能です。
参考: https://jp.corp-sansan.com/news/2025/1127.html

このリリースに向けて、各チームが協力し合いながら開発を進めてきました。しかし、グループ全体で一堂に会する機会はこれまで全くなく、業務の大半はオンラインで行われてきました。

プロジェクト開始から共に働いてきたにも関わらず、画面越しのコミュニケーションが中心であったため、SGDCメンバーの強みやスキルセットを十分に把握できておらず、それぞれの個性を活かしきれていない可能性がありました。
今後も追加開発が控えている中、メンバー同士の理解と結束を深め、グループ全体をエンパワーメントすることを目的として、POグループの日本メンバー全員（エンジニア、プロダクトマネジャー、デザイナーを含む）がセブ島に出張することになりました。
この背景を踏まえ、今回の出張では、来期に向けたプロダクトマネジャー主導のキックオフを皮切りに、チームビルディングや技術交流など、メンバー間の関係性強化を意識したプログラムを多数実施しました。本エントリでは、日本・SGDCチームで行ったグローバル開発体制強化の取り組みの一部をご紹介します。

AIワークショップ

以前より、SGDCのマネジャーから「日本チームでどのようにAIを活用しているのか、ぜひ事例を共有してほしい」との相談を受けていました。SGDCメンバー内でもAI活用に向けた試行錯誤が続いており、コーディングに限らず、より幅広い活用のヒントを得たいという背景がありました。
今回の出張は、その要望に応える絶好の機会です。日本チームでは今年の夏からOKRの一つとしてAI活用を掲げ、実践を積み重ねてきました。この経験を共有することで、POグループとしてAI活用をさらに進められると考えました。

そこで、日本チーム主催でAIワークショップを実施しました。コーディングへのAI活用はネット上にも多くの事例があるため、今回はより実践的な「Notion AIによるドメイン知識の共有と探索」と「Codingエージェントを使った効率的なコード探索」をテーマに設定し、ハンズオンを交えながら実践的なノウハウを共有しました。

1. Notion AI によるドメイン知識の共有と探索

Sansanの開発プロセスにおいて、Notionは単なるドキュメントツール以上の存在です。PBI（Product Backlog Item）、仕様書、カスタマーサクセスが参照する資料など、多様なナレッジが集約されたデータベースとして機能しています。

しかし、ここには非日本語話者の観点で課題がありました。多くの情報が日本語で書かれているため、従来型の全文検索では英語を主言語とするSGDCメンバーが必要な情報に辿り着けないという問題です。本来共有されているはずのドメイン知識が言語の壁によって分断されています。

日本チームはこの問題を重要視しており、その解決策としてLLMに注目しました。日本語の情報に対して英語で質問しても、回答が得られるLLMの特性を活かせば、翻訳の手間をかけずに情報の非対称性を緩和できるはずです。

この仮説のもと、日本チームではここ1ヶ月ほど、Notion AIがアクセスしやすいように「Purchasing Area AI Portal」と名付けたポータルページを作成し、POエリアに関する情報を整備してきました。このポータルをコンテキストにした場合、AIに信頼できる情報のみを参照させるようにプロンプトを調整して回答の精度を担保する工夫を凝らしています。
ワークショップでは、こうした背景やポータルの仕組み、実際の利用方法をデモを交えて説明した後、10分程度のハンズオンを行いました。参加者が実際にAIポータルにアクセスし、英語で質問を投げかけたところ、「日本語で書かれた複雑な仕様に対し、英語で質問をして即座に回答を得られる」という体験を通じて、これまで感じていた情報アクセスのストレスが解消される可能性を多くのSGDCメンバーに実感してもらうことができました。

▲AIワークショップの一コマ

今後、このAIの利用が進んでいくに従い、新たなフィードバックが得られると思います。サービス開発と同様に、こちらも日々改善していきたいと思っています！

2. Codingエージェントを用いた複数リポジトリのコード探索

前述の「Purchasing Area AI Portal」は非常に便利ですが、あくまで整備されたドキュメントやテキスト情報に依存しています。そのため、詳細な実装レベルの質問には回答できないケースも当然あります。既存の仕様に関してドキュメントから回答が得られない場合、私たちはSource of Truthであるコードにあたる必要があります。

しかし、ここにも問題があります。確認したい仕様や機能が複雑な場合、調査は複数のリポジトリを横断しなければならないことが多々あります。「あるAPIのリクエストがどういうフローで、最終的にどのロジックで処理されているのか？」みたいなことを、リポジトリを跨いでコードを追うのは時間がかかりますし、特にドメイン知識が浅いメンバーや新しく参画したメンバーは、全体像をイメージしながらコードを読み進める際に高い認知負荷がかかります。こういったケースへのソリューションとして、ワークショップではCodingエージェントを利用して効率的に複数リポジトリを探索する方法を紹介しました。

簡単にデモの構成を説明します。多くのCodingエージェント（Claude Code, Cursorなど）は、ワークスペースとして開いたディレクトリ配下をスコープとして動作します。この制約を回避するため、仕様調査用のディレクトリを作成し、その配下にbackend, frontend などの関連リポジトリへのシンボリックリンクを配置します。

spec_investigation/
  ├── backend_repo/    <- symbolic link
  └── frontend_repo/   <- symbolic link

このspec_investigation をワークスペースにすることにより、物理的に分かれている複数のリポジトリを探索スコープに含めることができます。（※Claude Codeなどでは /add-directory コマンドで同様のことができますが、この方法なら都度コマンドを打つ必要がなく、構成を永続化できるメリットがあります。）

デモではこの環境を使い、「Notion AIでは答えられなかった仕様」および「フロントエンドのクリックイベントからバックエンドのDB保存までの処理フロー」をAIに解説させる実演を行い、AIが必要に応じてリポジトリの境界を越え、一気通貫でロジックを読み解く様子を示しました。

その後のハンズオンでは、「プロンプトを工夫して探索範囲を絞ればもっと高速化できるのでは？」「全体像の把握にフローチャートを出力させると分かりやすい」といった具体的なフィードバックが飛び交いました。デモの構成は「シンボリックリンクを作るだけ」という非常にシンプルなものでしたが、実践している参加者は意外と多くありませんでした。ちょっとした工夫でCodingエージェントの能力を引き出せる手軽さと効果の高さに、多くのメンバーが関心を持ってくれたようです。なお、この手法は単なる調査に留まりません。CursorやClaude CodeのPlanモードと組み合わせれば、複数リポジトリに影響する新機能の実装計画や設計にも有効です。参加メンバーもそういった応用の可能性に気づいてくれたようで、チーム内でのAI活用の幅が今後さらに広がっていくことを期待しています。

3. 各チームからのAI活用事例共有

ワークショップの最後に、参加した各チームから、現在のAI活用事例について共有する時間を設けました。それぞれのチームが開発プロセスの異なるフェーズでAIを実用的に組み込んでいる点が印象的でした。

データ分析と意思決定への活用

トラフィックや負荷の傾向をChatGPTに分析させ、その結果を新機能の設計や、既存のシステム制限を拡張すべきかの検討材料として使用したそうです。要件定義やアーキテクチャ検討の前段階でAIを壁打ち相手として活用している例です。

ドキュメンテーションの自動化

Pull Request作成の効率化への取り組み。コードの変更内容をAIに渡すことで、PRのDescriptionを自動生成させています。作成の手間を減らすだけでなく、レビュアーにとって分かりやすい要約を作成するようにしているとのことでした。

実装品質の向上とエッジケース探索

コーディング時、より良い実装パターンの提案を求めたり、人間だけでは見落としがちなエッジケースのシナリオを洗い出してもらうことで、バグの未然防止とコード品質の向上に役立てているとのことでした。

今回のワークショップを通し、AIが開発者の強力なパートナーになり得ることを再確認しました。特に、実装や調査の効率化だけでなく、SGDCメンバーが抱える言語の壁をAIというテクノロジーが取り払ってくれる可能性を強く感じています。
今後もこうしたナレッジシェアを続け、グループ全体で生産性を高めていきたいと思います。

Risk Storming

AI自動照合のリリースに伴い、我々のサービスでは一部アーキテクチャの刷新や新たな外部システム連携が加わるなど、大きな変化がありました。この新しい構成の中でどんなリスクが潜んでいるのかをグループ全体で把握し、共通認識を持っておくことは重要です。

また、本取り組みは各チームの TL（Tech Lead）のスキルアップにも寄与することを目的としています。ソフトウェアエンジニアとしてステップアップしていくためには、サービス全体のアーキテクチャを俯瞰し、自ら設計を組み上げたり、既存の構成を書き起こして議論の場に載せたりする力が求められます。こうした目的のもと、アーキテクチャを構造化して捉え、リスクを言語化して共有する経験を養う機会とすべく Risk Storming（参照: https://riskstorming.com）を実施しました。
Risk Stormingとは、チーム全員でアーキテクチャ図を囲み、システムのリスクを視覚的に洗い出すワークショップ手法です。進め方はシンプルで、まずシステム構成図を用意し、各自が懸念するリスク（単一障害点や技術的不安など）を付箋に書き出して図の該当箇所に貼り付けます。この際、重要なのがリスクの定量化です。以下の図のように各リスクを発生確率（Probability）と影響度（Impact）の掛け合わせで評価し、優先度が高い順に「赤・黄・緑」と付箋を色分けします。これにより、システム上の「どこに危険が集中しているか」がヒートマップのように可視化されます。属人化しがちなリスク分析を複数人で行うことで見落としを防ぎ、優先順位（発生確率×影響度）の合意形成を短時間に進められるのが特徴です。

出典：https://riskstorming.com/

実践にあたっては、公式サイト（riskstorming.com）が提唱する標準的なフローをベースに進めました。今回はコラボレーションツールとしてMiroを採用し、あらかじめMiro上に描画したアーキテクチャ図に対して、参加者全員でリアルタイムに付箋を貼っていきました。

▲Miro上での作業画面。各メンバーが付箋をこのように貼り付けていきました

▲ワークショップの一コマ

付箋を貼り付けた後は、個々のリスクに関して貼り付けた人が説明し、それに対してディスカッションを行い、最終的にリスク度を調整していきました。

個人的な振り返りになりますが、私は半年前に入社し、AI自動照合プロジェクトでは特定コンポーネントに集中して開発を行っていました。そのため、どうしても自分が関わっていない他の領域については理解が及んでいない部分があります。

今回、各領域を担当するTLが集まり、それぞれの視点でリスクを議論する場を持つことができました。障害発生時ではなく平時にリスクやその背景を把握できたことは非常に有益でした。自分の関わっていなかった領域のリスクに関しては、どうしても障害発生時や何らかのトラブルシューティング時に認識することになりがちです。しかし、今回は落ち着いた状態で潜在的なリスクやその背景をTL間で共有できたことで、今後の開発連携もよりスムーズになると確信しています。
今回のワークショップはリスクを見つけて終わりではありません。洗い出されたリスクはプロダクトバックログに追加し、他のアイテムとの優先順位を調整して計画的に対応を進めていく予定です。

オフラインならではの交流

ここまで堅めの技術的な話題が続きましたが、今回は現地に足を運んだからこそ実現した交流についても触れたいと思います。
日本チームにはセブ拠点のQAメンバーが1名所属しています。今回の出張中、初めてチーム全員が揃ってスタンドアップを行いました。普段は画面越しにしか話ができないリモートメンバーと、こうして輪になり、同じ空間で顔を合わせて進捗を共有する。たったそれだけのことですが、チームの一体感が一気に高まった気がします。

▲全チームメンバーがオフラインで揃って行ったスタンドアップ

SGDCのマネジャーが私たち日本メンバーをもてなすために主催してくれた「PO Group Dinner」。今回の出張は実質2日間という限られた日程だったため、日中はみっちりと各種プログラムを詰め込んでいました。今後のプロジェクトのことや技術的な議論で疲れた後に、グループのメンバーが一堂に会して仕事以外の話題で盛り上がれるのは、現地に行ったからこそ味わえる醍醐味です。ディナーの席では、セブ島の代表的な郷土料理であるレチョン（豚の丸焼き）などが振る舞われ、異文化体験としても楽しむことができました。

▲レチョンを切り分けるマネジャー

▲お酒も入り、会話が盛り上がっている様子

美味しい料理を囲みながら、普段のオンラインミーティングだけでは見えにくいメンバーの意外な一面や人柄に触れることで、メンバー間の心理的な距離はぐっと縮まったと思います。当たり前のことですが、相手の人となりを知っているだけで、日々の仕事の頼みやすさやコミュニケーションの質は大きく変わります。業務外の時間を使ってこうした信頼関係の土台作りができたことも、今回の出張の大きな成果の一つです。

まとめ

今回の出張では、ワークショップや対面での議論といった業務上の連携に加え、食事やオフィスでの何気ない会話などを通じて、SGDCチームとの心理的な距離を大きく縮めることができました。これまで画面越しでしか接点のなかったメンバー同士が、お互いの人となりや熱量を肌で感じられたことは得がたい経験となりました。ここで得た相互理解は、今後のコミュニケーションをより円滑にしてくれるはずです。メンバー間の結束を深め、グループ全体をエンパワーメントするという目的は十分に達成できました。

今回の出張で築いた信頼関係を活かし、今後控えている追加案件に対しても、これまで以上にグループ一丸となって挑んでいきたいと思います！

P.S.
唯一の心残りは、弾丸日程だったため、せっかく南国のセブ島に行ったのに美しい海を拝むことができなかったことです。また訪れる機会があれば、是非アイランドホッピングなどの時間を確保したいです😅