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
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
13
4.6k
NPOでのDevinの活用
codeforeveryone
0
840
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
490
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
2
18k
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
300
生成AI時代のコンポーネントライブラリの作り方
touyou
1
230
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
1
120
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
10
5.6k
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
830
Featured
See All Featured
A better future with KSS
kneath
238
17k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Documentation Writing (for coders)
carmenintech
72
4.9k
Bash Introduction
62gerente
613
210k
Balancing Empowerment & Direction
lara
1
430
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Why Our Code Smells
bkeepers
PRO
336
57k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
690
Adopting Sorbet at Scale
ufuk
77
9.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
How to train your dragon (web standard)
notwaldorf
95
6.1k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
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に従ってタスクを分割するには
普段からタスク分割に気をつけた上で、それなりの開発経験が必要
開発生産性の向上を目指す ⬇ タスク分割、設計、自動テストなど 高いソフトウェア開発スキルに 向き合い続けることにも繋がる