Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複数拠点・複数チームにおけるデリバリのボトルネックと解消方法について
Search
Money Forward, Inc.
February 01, 2024
Technology
0
390
複数拠点・複数チームにおけるデリバリのボトルネックと解消方法について
2024/01/31 に開催された先駆者に学ぶソフトウェアデリバリー術 Findy Team+ Award 受賞企業から学ぶソフトウェアデリバリー の株式会社クラビス 宮前嘉夫さんの登壇資料です。
Money Forward, Inc.
February 01, 2024
Tweet
Share
More Decks by Money Forward, Inc.
See All by Money Forward, Inc.
SREを知らずに SREマネージャーになった話 / How I Became an SRE Manager Without Knowing What SRE Is
moneyforward
0
1.1k
Looker、”単なるBIツール”としての認識を超えて 〜現場で発見した活用へのヒント〜
moneyforward
0
110
Cursor、エンジニアのスイスアーミーナイフ / Cursor, an engineers swiss army knife
moneyforward
0
75
マネーフォワード QA Night 〜海外拠点と共に成長する組織の取り組み〜 / MoneyForward QA Night -Growth with Other People-
moneyforward
0
410
QA@MF Vietnam: Driving Quality, Innovation, and Growth
moneyforward
1
420
スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.
moneyforward
0
860
MEet Flutter Add-to-App: Unlocking Our Productivity
moneyforward
0
440
マネーフォワードが取り組む グローバルテックカンパニーへの挑戦 / Money Forward’s Challenge to Become a Global Tech Company
moneyforward
0
520
マネーフォワードのエンジニアリング進化論 / The Evolution of Engineering at Money Forward
moneyforward
0
940
Other Decks in Technology
See All in Technology
Railsの話をしよう
yahonda
0
150
生成AI時代のセキュアコーディングとDevSecOps
yuriemori
0
110
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
170
AWSでAgentic AIを開発するための前提知識の整理
nasuvitz
2
170
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.6k
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
350
Geospatialの世界最前線を探る [2025年版]
dayjournal
1
220
能登半島地震において デジタルができたこと・できなかったこと
ditccsugii
0
220
AWS Top Engineer、浮いてませんか? / As an AWS Top Engineer, Are You Out of Place?
yuj1osm
2
220
LLMアプリの地上戦開発計画と運用実践 / 2025.10.15 GPU UNITE 2025
smiyawaki0820
1
580
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
10
4.9k
Featured
See All Featured
Docker and Python
trallard
46
3.6k
We Have a Design System, Now What?
morganepeng
53
7.8k
Making Projects Easy
brettharned
120
6.4k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Cost Of JavaScript in 2023
addyosmani
55
9k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
Site-Speed That Sticks
csswizardry
12
900
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Context Engineering - Making Every Token Count
addyosmani
6
260
Transcript
複数拠点・複数チームにおけるデリバリの ボトルネックとその解消方法について
自己紹介 宮前嘉夫 / Yoshio Miyamae (Josh) • 2022年5月にKlavisに入社 • クラビスではマネーフォワード
クラウドインボイス [受領]の開発 をしている • 5人の子供がいる(4歳〜12歳 男女男男女) • Factorioなどの工場運営系のゲームが好き • X: @yoshiomiyamae
今日の発表でお伝えしたい事 • 開発生産性が上がらなかった理由 ◦ 複数チームで開発することの難しさ • どのように開発生産性を高めたのか ◦ チームメンバーが無理をせず(むしろ楽になりながら)開発生産性が上 がった理由
クラビスの紹介 • 社名: 株式会社クラビス • 設立: 2012年12月 • 事業: クラウド記帳サービス『STREAMED』
請求書受領サービス『マネーフォワード クラウドインボイス』 • 住所: 東京都港区芝浦3-1-21 msb Tamachi 田町ステーションタワーS 20階・21階 • 株主: 株式会社マネーフォワード(100%) • 従業員数: 61名(2024年1月1日時点)
クラビスの大まかなシステム構成 Dock 証憑のデータ化を担当 クラウド記帳サービス 請求書受領サービス データ化を依頼 データ化結果を返却 データ化結果を返却
今日お話しする範囲 Dock 証憑のデータ化を担当 クラウド記帳サービス 請求書受領サービス データ化を依頼 データ化結果を返却 データ化結果を返却
はじめに • クラビスのクラウドインボイス[受領]開発 チーム(以降インボイスチーム)がFindy Team+ Award 2023を受賞しました🎉 • 開発生産性スコアが優れた組織に表彰 されるとの事で光栄に思っています。
受賞中の弊社CTO(ふるはまさん)の図 とても嬉しそうですね!
Findy Team + is 何 • 端的に言うと、Four Keysをはじめとした開 発のスタッツを可視化 するツールです。
• 個人毎のスタッツも可 視化できます。
開発生産性スコアとは • アウトプットスコア ◦ デプロイ頻度などのアウトプットに関するスタッツをベースとしている ◦ 組織・チームの稼働人数や稼働日数が考慮されている • リードタイムスコア ◦
変更のリードタイムなどのリードタイムに関するスタッツをベースとしている ◦ 対象期間の中央値に基づいて計算されている • 開発生産性スコア ◦ アウトプットスコア、リードタイムスコアを基にした総合的な生産性指標
インボイスチームの立ち位置 • グラフが見辛いが、ゴールド・シルバー・ブロンズの区分があり、アウトプットスコア・ リードタイムスコアの交点より右上に位置すると、開発生産性が高いということ。 Findy Team + の画面 インボイスチームのスコア
開発チームに起こっていたこと • クラウドインボイス[受領]の開発は、KlavisとMoney Forward Vietnam (以降MFV) が共同で行なっており、同じリポジトリを2社(Klavis・MFV)・2拠点(日本・ベトナム) ・2言語(日本語・英語)で触っている • KlavisとMFVのタスクはエピックごとに分けられている
• KlavisとMFVでスプリントの開始・終了日が異なる
開発チームに起こっていたこと • Klavisの開発途中の機能がdevelopブランチに乗っている状態で、MFVの機能をリ リースしたい時に、Klavisの機能を毎回revertする必要があった(もちろんその逆も)
開発チームに起こっていたこと • スプリント周期が両チームでズレているため、リリースタイミングにももちろん差があ り、双方で調整が必要な状態だった • hotfixなどの急を要するリリースは、当然計画されたリリースとは別に行う必要が あった • コミュニケーションも言語の壁や(2時間とはいえ)時差があり、100%の精度で行え ているわけではなかった。
運用による努力だけではなく、仕組みで解決する必要があった
当初の解消方法 / The first solution • 開発中の機能はdevelopブランチに乗せずに、エピックブランチを作り、そこに溜め るようにしていた • こうすることでdevelopブランチはそれなりにいつでもリリースできる状態を保ってい
た。
当初の解消方法の問題点 • エピックブランチの差分が1万行以上になり、ビッグバンリリースが続くようになっ た。 • エピックブランチをdevelopブランチにマージするとstgへのデプロイがされるが、そ こで発生した問題がどこで起こっているのか分かり辛くなった。 • エピックブランチのコンフリクトが多発するようになり、解消に時間がかかるように なった。
現在の解消方法 • 開発中の機能も全てdevelopブランチにマージしていく • この際、開発中の機能についてはfeature flagを設定し、stgのみで動作するように する。 • 本番環境ではfeature flagがOFFになっているので、リリースされても(顧客目線で
は)何も変化しない。 • 初期データ投入や機能追加に伴うマスタデータの変更などもfeature flagで制御可 能
現在の解消方法の利点 • エピックブランチは不要となった • コンフリクトも最小限になり、また小さな機能を開発後、即座 にstg環境でテストできるようになったので原因の特定も容易 になった • こまめにstg環境に反映することで、ビジネスサイドからの フィードバックが早めにもらえるようになった。
Klavisのfeature flagの仕組み • LaunchDarklyやUnleashのようなSaaS / OSSは利用していない。 • 環境変数で設定する、簡易的なfeature flagを自前実装している。
自前実装の理由 • LaunchDarklyを検討したが、調査時点で1ユーザー1ヶ月 $16.67と結構高かった。(当時はエンジニアが8人ほどいて、月2万 円弱はちょっとなーという感じだった ) • Unleashをself-hostする案もあったが、feature flagの仕組み がうまくフィットするかまだ見えていなかったため、一旦環境変
数を使った仕組みを構築した。
効果 Feature flagの本格利用開始 8/15ごろから効果が見え始め、サ イクルタイムが大幅改善
苦労したところ feature flag自体は1月末にはコード内にはあったが、なかなかチーム内で浸透せずに 実際利用されるまでに半年以上かかった。 意識改善はなかなか効果が出ておらず、現在でもPRのレビューをSlackでお願いしない と進まない状況になっているのでこの状況を打破したい課題感は残っている まだまだ改善などを行ってスタッツが上がりやすいコードベースにする必要はあるなと言 う感じ。 Feature Flagの設計・導入をしたのんちゃんの声
チームメンバーの感想 • 良かったところは? ◦ (epicブランチで開発する場合と比べて)stg環境に載せられるので開発者 以外にも事前に確認してもらえ、早めにフィードバックがもらえるし、バグ 出しが出来てよかった ◦ リリース時にいちいちリバートしなくて良かったところや、他サービスの開 発待ちなどの場合に、仮組状態でリリースしても本番環境に影響がないと
ころが良かった。
チームメンバーの感想 • feature flagの導入が中々進まなかった理由は? ◦ ⚪⚪機能(8月中旬から開発を開始した機能)がfeature flagが出来てから 最初の大型リリースだと思っていた。 ▪ Feature
flagの仕組みがある事を知らなかった ◦ BEの場合、複数機能の開発が並行していない限りは、FEから叩かなけれ ば実行されないので、必要性を感じていなかった。 ▪ 実際にはマイグレーションの結果、影響が出てしまう部分があったの で必要だった
まとめ • Feature Flagを導入してエピックブランチを無くし、コードの流動性を高め た。 • その結果PRの滞留時間が短くなり、コンフリクトが少なくなった。 • stg環境に出るスピードが早くなり、関係者の確認が開発と並行して行える 様になった。
最後に • クラビスではクラウドインボイスだけでなくSTREAMEDというプロダクトの開発・運 用も行っています • STREAMEDは運用開始から10年弱が経過しているシステムで、クラウドインボイ スとはまた異なる技術・運用課題があります • クラビスの持っている課題に興味を持っていただけた人は是非一度、ざっくばらん に弊社CTOの古濱とお話しましょう
• Connpassのイベントページにクラビスのカジュアル面談のリンクがあるのでそちら から申し込みいただきたいです!
複数拠点・複数チームにおけるデリバリの ボトルネックとその解消方法について