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
Ryota Kunisada
November 14, 2023
Programming
0
98
開発生産性向上の取り組みログ
旭川 ゆるい勉強会
で発表した時の資料です。
Ryota Kunisada
November 14, 2023
Tweet
Share
More Decks by Ryota Kunisada
See All by Ryota Kunisada
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
330
フロントエンドエンジニアとQAエンジニアの協働による自動テストを増やす開発プロセス
92thunder
0
69
トランクベース開発の導入で見えた DevOpsの技術・プロセス・文化との繋がり
92thunder
0
1.1k
どんなページでも動かす!JS_CSS汚染を避ける戦い
92thunder
0
250
Other Decks in Programming
See All in Programming
A full stack side project webapp all in Kotlin (KotlinConf 2025)
dankim
0
120
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
390
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
140
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
PipeCDのプラグイン化で目指すところ
warashi
1
270
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
86
29k
Is Xcode slowly dying out in 2025?
uetyo
1
270
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.3k
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
Featured
See All Featured
For a Future-Friendly Web
brad_frost
179
9.8k
Become a Pro
speakerdeck
PRO
29
5.4k
What's in a price? How to price your products and services
michaelherold
246
12k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Six Lessons from altMBA
skipperchong
28
3.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Faster Mobile Websites
deanohume
307
31k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Docker and Python
trallard
44
3.5k
Transcript
開発生産性向上の 取り組みログ 旭川 ゆるい勉強会 2023/10/21 @92thunder
自己紹介 • 国定 凌太 @92thunder • 1994年生まれ • 岡山県 →
上京して就職 → 2023年6月に旭川に移住 • 津山高専 → ソニーグループ会社 → 当時創業1ヶ月経ったばかりのスタートアップ • テックタッチ株式会社のフロントエンドエンジニアとして 自社サービスの開発に取り組んでいます
「テックタッチ」の紹介 • WebサイトにサードパーティJSを組み込むことで、 ノーコードでガイドやツールチップでの案内を追加できる • スニペット / ブラウザ拡張で提供
生産性向上に向けて取り組んでいるが 何度も壁にぶつかりながら試行錯誤している 自分の頭の中を整理するためにも話します
なぜ開発生産性向上に取り組むか • 「LeanとDevOpsの科学」の影響を受けて Eliteチームと呼ばれる開発チームを目指してビジネスに貢献したい • 個人開発や開発初期のmainブランチに変更を加えて すぐに反映されるあの感じで普段から開発できたら絶対楽しい • 技術大好き、マネジメントが好きというわけではないが アジャイルや開発プロセスの領域は好き
https://amzn.asia/d/0vi6VZG
開発生産性を測る Four Keys • 変更のリードタイム - commit から本番環境稼働までの所要時間 • デプロイの頻度
- 組織による正常な本番環境へのリリースの頻度 • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%) • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 学術的にもこれらの向上が生産性の高いチームに繋がることが証明されている
リードタイム短縮に注力 • 現状自動テストが難しく手動テストに頼っているということもあり デプロイ頻度は3ヶ月に1度で固定し、品質をじっくり検証している ◦ ここに手をかけるにはBiz含む関係者の調整やデプロイ完全自動化など 時間をかけて取り組む必要がある • リードタイム短縮のプラクティスはたくさんあるので手をつけやすい ◦
ペアプロ、トランクベース開発、同期コードレビュー、自動テスト 他の指標は並行しつつ、リードタイム改善に向けて手を動かす
トランクベース開発:1日に1回はmainにマージ • Git-FlowやGitHub-Flowに代表されるようなブランチ戦略の1つ • mainブランチから派生したブランチで作業し 1日に1回はmainブランチにマージする • デプロイ頻度のメトリクスにも直結するため mainブランチは常にマージ可能な状態を維持する必要がある 機能の開発途中ではマージできない🤔
フィーチャートグルで開発途中の機能でもマージできる • マージ可能な状態 = 本番環境で開発途中の機能が見えない • フィーチャートグル機構があれば コードに変更を加えず機能の使用可否を切り替えできる • 1日1回mainブランチにマージするには必要不可欠
新機能の導線を隠す!
フィーチャートグルを作る • 動的フィーチャートグル ◦ 管理画面からネットワーク経由で切り替えできる ◦ 障害に強い構成にするため、キャッシュ機構が必要 • 静的フィーチャートグル ◦
ソースコードの一箇所を変更するだけで機能の公開を切り替えできる ◦ 簡単に導入できるためこちらを選択 • Reactで開発体験に気をつけていい感じに実装しドキュメントもバッチリ 作って2ヶ月、未だ使われてない😢
ドキュメント抜粋
フィーチャートグルを適用しやすいケース • 既出機能ではなく「完全に新規」の機能 • 導線がはっきりしていて機能公開の切り替えが容易 • 新機能が他の機能でも基盤とする実装に依存していない 適用しにくいケースの方が圧倒的に多い🥺
既出機能にも改修が必要な新機能 新機能 既出 機能 コンポーネント 少し手を加えれば同じコンポーネントを 使い回すことができる🤩 新機能 既出 機能
コンポーネント コンポーネントにも分岐が強要されてしまう 🤢 フィーチャートグルによる分岐があちこちに発生すると辛い ... フィーチャー トグル コンポーネント
フィーチャートグルを使う方法を模索中 • 既出機能の一部を変更する場合、思い切ってコピーする作戦 ◦ /awesome_feature ▪ main ▪ component1, component2…
↓コピー ◦ /new_awesome_feature ▪ main ▪ component1, component2... 似たようなコードが増え、完全置き換えまでにバグになるリスク増
フィーチャートグルを使うための設計スキル • SOLID原則に立ち返る ◦ S: 単一責任 ◦ O: 既存コードの変更なしで拡張できるように •
DI(依存性注入)という考え ◦ DIするためには、既存の機能との分離が必要 ◦ 上位レイヤーでモジュールや振る舞いを注入する考え方が 導線を切り替えるだけで、機能の公開可否できる設計に繋がる フィーチャートグルを使うために良い設計に近づく副次的効果
開発タスクを細分化する技術 • 機能ブランチに変更を加えていく方が考えることが少なくて楽 タスク分割から意識しないとフィーチャーフラグを使う考えに繋がらない • INVEST ◦ 独立、交渉可能、価値がある、見積もり可能、小さい、テスト可能 • INVESTに従ってタスクを分割するには
普段からタスク分割に気をつけた上で、それなりの開発経験が必要
開発生産性の向上を目指す ⬇ タスク分割、設計、自動テストなど 高いソフトウェア開発スキルに 向き合い続けることにも繋がる