チームメンバーをエンパワーメントしよう！ レガシープロジェクト改善事始め

PHP CONFERENCE JAPAN 2020のLTに登壇する際の資料

https://fortee.jp/phpcon-2020/proposal/2f75bfc5-b6ad-433b-afc9-732e3fd75aa8

Transcript

1. チームメンバーをエンパワーメントしよう！ レガシープロジェクト改善事始め ぬさし( @nukisashineko ) 1/19
2. チームをエンパワーメントする • 輪読会、勉強会、モブプロ等 ◦ スキルマップを広げ、基礎力の向上 • Developer Experience（開発体験）の向上 ◦ 環境の質向上、手動運用を自動化する等 2/19
3. 方針・指針 1. できることからやるのが一番早い 2. 簡単で自動化可能なものから始める 何から改善して いけばいいの？ 3/19 • できること＝手を動かした経験があるもの • できること ≠ 知ってること (経験がないもの)
4. 方針・指針 1. できることからやるのが一番早い 2. 簡単で自動化可能なものから始める 1. すぐに効果が出ること 2. チームへ効果が出ること 4/19 コスパ良く改善するには 何から改善して いけばいいの？ も重要
5. 改善対象のプロジェクトを紹介 • 10年を超えたサービス • ローカル開発環境はない ◦ debug不可能 • アプリ・DBはオンプレ ◦ ロギングが貧弱 • CIは無い 5/19
6. 改善可能な点 • debugを動かせるようにする • CIの導入 • 新しいツールやSaaSの導入 …… • etc. 6/19
7. 7/19 「じゃあ何からやったの？」 debugを動かせるようにした！ 活動報告(1) - 環境改善 選択理由： 「できることだった！」
8. debug環境作成 - 作って配る 8/19 • １週間目→検証用のovaファイルを入手 • １ヶ月目→debug可能環境へ再構築 • ２ヶ月目→ repository化＆ チームメンバーに配布 作業時間は１[時間/日]
9. debug環境作成 - メンバーに使ってもらう 9/19 • debugを文化にする ◦ ドキュメントは丁寧に ◦ remote debug設定は簡単化 (gitに含める) ◦ debuggerの使い方をハンズオンする(都度) 「作ったよ！」で終わらず使い続けて広める
10. debug環境作成 - 結果 10/19 • debugが使える！ ◦ 調査時間の大幅削減 (printf debugと比較) • 問題の切り分けが容易に！ ◦ ローカル環境があるという強み
11. 11/19 「次は何をやったの？」 GitHub Actions（CI）を導入しました 活動報告(2) - 自動化による省力化
12. CIの導入 - 指摘の自動化 - master merge 12/19 「PR依頼の前にmaster mergeしといてよ」
13. CIの導入 - 指摘の自動化 - Linter dry run 13/19 「PR依頼の前にLinterの実行をしといてよ」
14. CIの導入 - 結果 14/19 • PRの往復時間削減！ ◦ レビュイーが修正点に気づける • 本質的な指摘が増えた！ ◦ 時間をロジック検討に多く使える
15. 改善の際に注意すべきこと • 改善はチームメンバーの参意を確認 ◦ チームで保守・運用するため • 大きな変化はゆっくり起こす ◦ 唐突で大きな変化は定着しない 15/19
16. 改善の際に注意すべきこと - 例を元に • 例：Linterの導入 ◦ よくあるパターン (完璧主義) ▪ 「Linterで機械的なレビューを行うため 　全部のファイルへ置換を行います！」 ▪ 「確認範囲が拡大して難しいから後で」 16/19
17. 改善の際に注意すべきこと - 例を元に • 例：Linterの導入 ◦ やるべきパターン (導入を目指す) ▪ 「影響範囲が広がらないように 　新規ファイルに限って適用します！」 ▪ 「それならお試しで導入してみたいね」 17/19
18. 何からやればいい？という人へ 1. Linter (PHP-CS-Fixer, PHPMD, Phan) 2. Github Actions 3. SaaSの監視ツール Extra. debug環境の用意 18/19 PR高速化 自動化の事始め 導入が楽で高機能 開発体験に効果的 難易度高め
19. まとめ - チームをエンパワーメント事始め！ • できるものから始める • 作ったらチームの文化にする • 独りよがりな開発にしない 19/19