$30 off During Our Annual Pro Sale. View Details »

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

nukisashineko
December 12, 2020

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

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

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

nukisashineko

December 12, 2020
Tweet

More Decks by nukisashineko

Other Decks in Technology

Transcript

  1. チームメンバーをエンパワーメントしよう!
    レガシープロジェクト改善事始め
    ぬさし( @nukisashineko )
    1/19

    View Slide

  2. チームをエンパワーメントする
    ● 輪読会、勉強会、モブプロ等
    ○ スキルマップを広げ、基礎力の向上
    ● Developer Experience(開発体験)の向上
    ○ 環境の質向上、手動運用を自動化する等
    2/19

    View Slide

  3. 方針・指針
    1. できることからやるのが一番早い
    2. 簡単で自動化可能なものから始める
    何から改善して
    いけばいいの?
    3/19
    ● できること=手を動かした経験があるもの
    ● できること ≠ 知ってること (経験がないもの)

    View Slide

  4. 方針・指針
    1. できることからやるのが一番早い
    2. 簡単で自動化可能なものから始める
    1. すぐに効果が出ること
    2. チームへ効果が出ること
    4/19
    コスパ良く改善するには
    何から改善して
    いけばいいの?
    も重要

    View Slide

  5. 改善対象のプロジェクトを紹介
    ● 10年を超えたサービス
    ● ローカル開発環境はない
    ○ debug不可能
    ● アプリ・DBはオンプレ
    ○ ロギングが貧弱
    ● CIは無い
    5/19

    View Slide

  6. 改善可能な点
    ● debugを動かせるようにする
    ● CIの導入
    ● 新しいツールやSaaSの導入
    ……
    ● etc.
    6/19

    View Slide

  7. 7/19
    「じゃあ何からやったの?」
    debugを動かせるようにした!
    活動報告(1) - 環境改善
    選択理由:
    「できることだった!」

    View Slide

  8. debug環境作成 - 作って配る
    8/19
    ● 1週間目→検証用のovaファイルを入手
    ● 1ヶ月目→debug可能環境へ再構築
    ● 2ヶ月目→
    repository化&
    チームメンバーに配布
    作業時間は1[時間/日]

    View Slide

  9. debug環境作成 - メンバーに使ってもらう
    9/19
    ● debugを文化にする
    ○ ドキュメントは丁寧に
    ○ remote debug設定は簡単化 (gitに含める)
    ○ debuggerの使い方をハンズオンする(都度)
    「作ったよ!」で終わらず使い続けて広める

    View Slide

  10. debug環境作成 - 結果
    10/19
    ● debugが使える!
    ○ 調査時間の大幅削減 (printf debugと比較)
    ● 問題の切り分けが容易に!
    ○ ローカル環境があるという強み

    View Slide

  11. 11/19
    「次は何をやったの?」
    GitHub Actions(CI)を導入しました
    活動報告(2) - 自動化による省力化

    View Slide

  12. CIの導入 - 指摘の自動化 - master merge
    12/19
    「PR依頼の前にmaster mergeしといてよ」

    View Slide

  13. CIの導入 - 指摘の自動化 - Linter dry run
    13/19
    「PR依頼の前にLinterの実行をしといてよ」

    View Slide

  14. CIの導入 - 結果
    14/19
    ● PRの往復時間削減!
    ○ レビュイーが修正点に気づける
    ● 本質的な指摘が増えた!
    ○ 時間をロジック検討に多く使える

    View Slide

  15. 改善の際に注意すべきこと
    ● 改善はチームメンバーの参意を確認
    ○ チームで保守・運用するため
    ● 大きな変化はゆっくり起こす
    ○ 唐突で大きな変化は定着しない
    15/19

    View Slide

  16. 改善の際に注意すべきこと - 例を元に
    ● 例:Linterの導入
    ○ よくあるパターン (完璧主義)
    ■ 「Linterで機械的なレビューを行うため
     全部のファイルへ置換を行います!」
    ■ 「確認範囲が拡大して難しいから後で」
    16/19

    View Slide

  17. 改善の際に注意すべきこと - 例を元に
    ● 例:Linterの導入
    ○ やるべきパターン (導入を目指す)
    ■ 「影響範囲が広がらないように
     新規ファイルに限って適用します!」
    ■ 「それならお試しで導入してみたいね」
    17/19

    View Slide

  18. 何からやればいい?という人へ
    1. Linter (PHP-CS-Fixer, PHPMD, Phan)
    2. Github Actions
    3. SaaSの監視ツール
    Extra.
    debug環境の用意
    18/19
    PR高速化
    自動化の事始め
    導入が楽で高機能
    開発体験に効果的
    難易度高め

    View Slide

  19. まとめ - チームをエンパワーメント事始め!
    ● できるものから始める
    ● 作ったらチームの文化にする
    ● 独りよがりな開発にしない
    19/19

    View Slide