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
320
複数拠点・複数チームにおけるデリバリのボトルネックと解消方法について
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.
MEet Flutter Add-to-App: Unlocking Our Productivity
moneyforward
0
130
マネーフォワードが取り組む グローバルテックカンパニーへの挑戦 / Money Forward’s Challenge to Become a Global Tech Company
moneyforward
0
180
マネーフォワードのエンジニアリング進化論 / The Evolution of Engineering at Money Forward
moneyforward
0
320
Rubyにおける並行処理 / Concurrency in Ruby
moneyforward
0
110
通知基盤におけるKafka活用事例 / Kafka Case Study on the Notification Platform
moneyforward
0
230
マネーフォワードにおけるデータ戦略 / Data Strategy at Money Forward
moneyforward
0
210
FiftyOneを用いたOCRモデルの比較 / Comparing OCR Models using FiftyOne
moneyforward
0
72
グローバル環境における効果的なチームワーク / Effective Teamwork in a Global Environment
moneyforward
0
74
速度向上の秘訣 CI_CDにおけるDockerビルドの高速化(仮)
moneyforward
0
310
Other Decks in Technology
See All in Technology
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
870
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
540
マルチプロダクトな開発組織で 「開発生産性」に向き合うために試みたこと / Improving Multi-Product Dev Productivity
sugamasao
1
310
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
150
SRE×AIOpsを始めよう!GuardDutyによるお手軽脅威検出
amixedcolor
0
180
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
Featured
See All Featured
Building Applications with DynamoDB
mza
90
6.1k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Speed Design
sergeychernyshev
25
620
Into the Great Unknown - MozCon
thekraken
32
1.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Six Lessons from altMBA
skipperchong
27
3.5k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
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のイベントページにクラビスのカジュアル面談のリンクがあるのでそちら から申し込みいただきたいです!
複数拠点・複数チームにおけるデリバリの ボトルネックとその解消方法について