1 of 25

情シスのチーム開発を

いい感じにする取り組み

2023.6.28

コーポレートエンジニア関西交流会 vol.2 LT

​

@thdy_jp

2 of 25

自己紹介

  • 加来 慎太郎 / Shintaro Kaku
  • 都内 IT 企業のコーポレートエンジニア
  • リモートワーカー@広島⛩️🦪🍁
  • Japan Okta User Group 運営� @thdy_jp� @thdy� thdy.jp

3 of 25

みなさん、

チームで開発してますか？

✋

4 of 25

仮説:

情シスには開発未経験者も

それなりにいる

5 of 25

仮説 2:

コードは書けてもチームでの

開発は経験ない、という方も

それなりにいる

6 of 25

チーム開発の理想と現実

  • 理想
    • コードを書いたらプルリクエストを上げてチーム内でレビューを回したい
  • 現実
    • Git / GitHub の扱いに慣れていない
    • レビューのやり方やレビューコメントの作法が分からない
    • 現代的なソフトウェア開発の素養がない

​

​

​

私自身もこれでした

7 of 25

チームでいろいろ取り組んだ結果

  • メンバー全員がコードを書いて PR →レビュー→デプロイまで�迷わずできている
  • 新しくメンバーが加わった際にもスムーズに開発に�入ってもらえる体制ができている

この状態になるまでに実際にチームで取り組んだことに�ついてお話しします

8 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

9 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

10 of 25

やることをまとめた README をつくる

開発環境の構築

  • clasp や CLI などの�インストール
  • lint の設定
  • GitHub の通知設定

開発の流れ

  • ローカル開発の手順
  • ブランチの切り方
  • コミットの積み方
  • PR に書くこと
  • レビューの作法

この通りにすればあとはコードを書くだけ

11 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

12 of 25

template リポジトリを活用する

  • 新しくツールを作成するときは必ずテンプレート�リポジトリを clone してから始める
  • これにより後述する lint の自動適用や clasp による�デプロイなどの CI/CD やディレクトリ構成を共通化�

13 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

14 of 25

husky でコミット時の lint を強制化する

https://typicode.github.io/husky/

15 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

16 of 25

コミットの prefix を例示する

  • 前述の開発時の README に記載している
  • ex.
    • feat: 新しい機能
    • fix: バグの修正
    • refactor: 仕様に影響がないコード改善(リファクタ)
    • test: テスト関連
    • chore: ビルド、補助ツール、ライブラリ関連�
  • ただしコミットよりも PR の説明をちゃんと書くことを重視

17 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

18 of 25

プルリクエストテンプレートを活用する

  • 前述のテンプレートリポジトリに .github/pull_request_template.md を仕込んである
  • これによりプルリクエストの説明内容の品質が保たれる
  • ex. 課題、やったこと、関連リンク、動作確認結果、レビュー期日、etc…

19 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

20 of 25

レビューコメントのラベルルールを決める

  • そのコメントは提案？ 質問？ 要求？
  • ニュアンスを伝えやすくするためにコメント冒頭に�あらかじめチームで決めたラベルをつける
    • [ask] 質問
    • [nits] ささいな気付き、重箱の隅 (non-blocking)
    • [imo] in my opinion、意見や提案 (non-blocking)
    • [must] 対応必須、問題の提起 (blocking)

21 of 25

レビューコメントのラベルルールを決める

saved reply にあらかじめ入れておくと便利

22 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

23 of 25

主な取り組み

  • やることをまとめた README をつくる
  • template リポジトリを活用する
  • husky でコミット時の lint を強制化する
  • コミットの prefix を例示する
  • プルリクエストテンプレートを活用する
  • レビューコメントのラベルルールを決める

だいぶいい

感じになった👍

​

24 of 25

まとめ

  • チームで開発の「型」を作るのは大事
    • スキルのベースラインが揃ってない場合は特に
  • GitHub にはチームでの開発をサポートするいろいろな�機能が用意されているので使いこなすと便利

​

うちはこうやってるよ！ というオススメの tips が�あればぜひ教えてください

25 of 25

情シスのチーム開発を

いい感じにする取り組み

2023.6.28

コーポレートエンジニア関西交流会 vol.2 LT

​

@thdy_jp