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
310
複数拠点・複数チームにおけるデリバリのボトルネックと解消方法について
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.
速度向上の秘訣 CI_CDにおけるDockerビルドの高速化(仮)
moneyforward
0
280
ぼくが見た ガーディアンの過去‧現在 そして未来
moneyforward
0
100
キレイゴトじゃないのよ!顧客・社員・事業の3方良しを目指す開発組織
moneyforward
0
75
マネーフォワード クラウド経費 フロントエンド分離はじめました
moneyforward
0
120
開発組織の目線を合わせる 未来のプロダクトビジョン
moneyforward
0
100
Money Forward Tech Event vol.1
moneyforward
0
86
API連携に伴う規制と対応 / Regulations and responses to API linkage
moneyforward
0
700
マネーフォワード クラウド確定申告のフルリニューアル
moneyforward
0
1.6k
マネーフォワード クラウドの事業戦略とカスタマーサクセス / Business Strategy and Customer Success of Money Forward Cloud
moneyforward
1
800
Other Decks in Technology
See All in Technology
The XZ Backdoor Story
fr0gger
0
3.6k
プログラム検証入門
riru
6
860
Tricentisにおけるテスト自動化へのAI活用ご紹介/20240910Shunsuke Katakura
shift_evolve
0
180
忙しい人のためのLangGraph概要まとめ
__ymgc__
1
170
自作Cコンパイラ 8時間の奮闘
soukouki
0
830
不動産 x AIことはじめ~データの真価を拓くために
estie
0
110
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
300
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
1
600
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
6
1.4k
四国のあのイベントの〇〇システムを45日間で構築した話 / cloudohenro2024_tachibana
biatunky
0
330
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
130
Swift Testingのconfirmationを コードリーディング/Dive into Swift Testing confirmation
laprasdrum
2
250
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
128
8.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
41
6.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
Optimizing for Happiness
mojombo
375
69k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
610
Automating Front-end Workflow
addyosmani
1365
200k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
Into the Great Unknown - MozCon
thekraken
29
1.4k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Writing Fast Ruby
sferik
623
60k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.8k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
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のイベントページにクラビスのカジュアル面談のリンクがあるのでそちら から申し込みいただきたいです!
複数拠点・複数チームにおけるデリバリの ボトルネックとその解消方法について