開発生産性向上の取り組みログ

旭川 ゆるい勉強会で発表した時の資料です。

Transcript

1. 開発生産性向上の 取り組みログ 旭川 ゆるい勉強会 2023/10/21 @92thunder
2. 自己紹介 • 国定 凌太 @92thunder • 1994年生まれ • 岡山県 → 上京して就職 → 2023年6月に旭川に移住 • 津山高専 → ソニーグループ会社 → 当時創業1ヶ月経ったばかりのスタートアップ • テックタッチ株式会社のフロントエンドエンジニアとして 自社サービスの開発に取り組んでいます
3. 「テックタッチ」の紹介 • WebサイトにサードパーティJSを組み込むことで、 ノーコードでガイドやツールチップでの案内を追加できる • スニペット / ブラウザ拡張で提供
4. 生産性向上に向けて取り組んでいるが 何度も壁にぶつかりながら試行錯誤している 自分の頭の中を整理するためにも話します
5. なぜ開発生産性向上に取り組むか • 「LeanとDevOpsの科学」の影響を受けて Eliteチームと呼ばれる開発チームを目指してビジネスに貢献したい • 個人開発や開発初期のmainブランチに変更を加えて すぐに反映されるあの感じで普段から開発できたら絶対楽しい • 技術大好き、マネジメントが好きというわけではないが アジャイルや開発プロセスの領域は好き https://amzn.asia/d/0vi6VZG
6. 開発生産性を測る Four Keys • 変更のリードタイム - commit から本番環境稼働までの所要時間 • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 学術的にもこれらの向上が生産性の高いチームに繋がることが証明されている
7. リードタイム短縮に注力 • 現状自動テストが難しく手動テストに頼っているということもあり デプロイ頻度は3ヶ月に1度で固定し、品質をじっくり検証している ◦ ここに手をかけるにはBiz含む関係者の調整やデプロイ完全自動化など 時間をかけて取り組む必要がある • リードタイム短縮のプラクティスはたくさんあるので手をつけやすい ◦ ペアプロ、トランクベース開発、同期コードレビュー、自動テスト 他の指標は並行しつつ、リードタイム改善に向けて手を動かす
8. トランクベース開発：1日に1回はmainにマージ • Git-FlowやGitHub-Flowに代表されるようなブランチ戦略の1つ • mainブランチから派生したブランチで作業し 1日に1回はmainブランチにマージする • デプロイ頻度のメトリクスにも直結するため mainブランチは常にマージ可能な状態を維持する必要がある 機能の開発途中ではマージできない🤔
9. フィーチャートグルで開発途中の機能でもマージできる • マージ可能な状態 = 本番環境で開発途中の機能が見えない • フィーチャートグル機構があれば コードに変更を加えず機能の使用可否を切り替えできる • 1日1回mainブランチにマージするには必要不可欠 新機能の導線を隠す！
10. フィーチャートグルを作る • 動的フィーチャートグル ◦ 管理画面からネットワーク経由で切り替えできる ◦ 障害に強い構成にするため、キャッシュ機構が必要 • 静的フィーチャートグル ◦ ソースコードの一箇所を変更するだけで機能の公開を切り替えできる ◦ 簡単に導入できるためこちらを選択 • Reactで開発体験に気をつけていい感じに実装しドキュメントもバッチリ 作って2ヶ月、未だ使われてない😢
11. ドキュメント抜粋
12. フィーチャートグルを適用しやすいケース • 既出機能ではなく「完全に新規」の機能 • 導線がはっきりしていて機能公開の切り替えが容易 • 新機能が他の機能でも基盤とする実装に依存していない 適用しにくいケースの方が圧倒的に多い🥺
13. 既出機能にも改修が必要な新機能 新機能 既出 機能 コンポーネント 少し手を加えれば同じコンポーネントを 使い回すことができる🤩 新機能 既出 機能 コンポーネント コンポーネントにも分岐が強要されてしまう 🤢 フィーチャートグルによる分岐があちこちに発生すると辛い ... フィーチャー トグル コンポーネント
14. フィーチャートグルを使う方法を模索中 • 既出機能の一部を変更する場合、思い切ってコピーする作戦 ◦ /awesome_feature ▪ main ▪ component1, component2… ↓コピー ◦ /new_awesome_feature ▪ main ▪ component1, component2... 似たようなコードが増え、完全置き換えまでにバグになるリスク増
15. フィーチャートグルを使うための設計スキル • SOLID原則に立ち返る ◦ S: 単一責任 ◦ O: 既存コードの変更なしで拡張できるように • DI(依存性注入)という考え ◦ DIするためには、既存の機能との分離が必要 ◦ 上位レイヤーでモジュールや振る舞いを注入する考え方が 導線を切り替えるだけで、機能の公開可否できる設計に繋がる フィーチャートグルを使うために良い設計に近づく副次的効果
16. 開発タスクを細分化する技術 • 機能ブランチに変更を加えていく方が考えることが少なくて楽 タスク分割から意識しないとフィーチャーフラグを使う考えに繋がらない • INVEST ◦ 独立、交渉可能、価値がある、見積もり可能、小さい、テスト可能 • INVESTに従ってタスクを分割するには 普段からタスク分割に気をつけた上で、それなりの開発経験が必要
17. 開発生産性の向上を目指す ⬇ タスク分割、設計、自動テストなど 高いソフトウェア開発スキルに 向き合い続けることにも繋がる