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
340
複数拠点・複数チームにおけるデリバリのボトルネックと解消方法について
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
170
マネーフォワードが取り組む グローバルテックカンパニーへの挑戦 / Money Forward’s Challenge to Become a Global Tech Company
moneyforward
0
230
マネーフォワードのエンジニアリング進化論 / The Evolution of Engineering at Money Forward
moneyforward
0
440
Rubyにおける並行処理 / Concurrency in Ruby
moneyforward
0
140
通知基盤におけるKafka活用事例 / Kafka Case Study on the Notification Platform
moneyforward
0
280
マネーフォワードにおけるデータ戦略 / Data Strategy at Money Forward
moneyforward
0
250
FiftyOneを用いたOCRモデルの比較 / Comparing OCR Models using FiftyOne
moneyforward
0
110
グローバル環境における効果的なチームワーク / Effective Teamwork in a Global Environment
moneyforward
0
90
速度向上の秘訣 CI_CDにおけるDockerビルドの高速化(仮)
moneyforward
0
330
Other Decks in Technology
See All in Technology
Storage Browser for Amazon S3
miu_crescent
1
210
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
530
Turing × atmaCup #18 - 1st Place Solution
hakubishin3
0
490
alecthomas/kong はいいぞ / kamakura.go#7
fujiwara3
1
300
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
220
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
270
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
Amazon SageMaker Unified Studio(Preview)、Lakehouse と Amazon S3 Tables
ishikawa_satoru
0
160
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
righttouch
PRO
0
120
WACATE2024冬セッション資料(ユーザビリティ)
scarletplover
0
210
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
We Have a Design System, Now What?
morganepeng
51
7.3k
The Invisible Side of Design
smashingmag
298
50k
A Philosophy of Restraint
colly
203
16k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Music & Morning Musume
bryan
46
6.2k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Docker and Python
trallard
42
3.1k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
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のイベントページにクラビスのカジュアル面談のリンクがあるのでそちら から申し込みいただきたいです!
複数拠点・複数チームにおけるデリバリの ボトルネックとその解消方法について