チームで開発するために整えておくべきと思うことを紹介します。 どんなアプリケーション、開発言語でも共通する基本的なことです。

1. チームで開発するための
環境を整える
2024-03-14 社内勉強会
onozaty

2. チームで開発するための環境を整える
• チームで開発するために整えておくべきと思うことを紹介
• どんなアプリケーション、開発言語でも共通する基本的なこと
• 『こういうのもやっておいた方が良いよ』といったことがあれば、
後で教えてください

3. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

4. 1. 情報共有できるようにする
• チームで作業を行う上で、情報共有できる仕組みが必要になる
• チャットだけではなく、情報を整理/ストックできるような仕組み
を用意し、そこを見れば(検索すれば)プロジェクトに必要な情報に
たどり着けるようにする
• 新しいメンバが増えた場合にも、そこを見れば済むようにしておく
• チャット
• Slack、Teams、Google Chat、Rocket.Chat など
• 情報をストックできるもの
• Confluence、GitHub/GitLabのWiki、Redmine/BacklogのWiki など

5. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

6. 2. タスクを確認できるようにする
• 各メンバのタスク状況を確認できるように
• タスクを管理できるようなものを用意し、そこをみれば、メンバの
作業状況(どこまで作業進んでいるか、何が解決している/していな
いのか)がわかるように、アップデートしていく
• 作業をしている人は、他のメンバが見てもわかるように情報を残していく
• チャットで確認したようなことも、タスク側に残していくと良い
• GitHub、GitLabのIssue など
• Jira、Redmine、Backlog など (プロジェクト管理ツール的なもの)

7. 2. タスクを確認できるようにする
• チケット管理をメイン機能としたものに比べ、GitHubやGitLabの
Issueは簡易的なものなので、そのプロジェクトで管理したいタスク
に応じて、何を使うか決めると良い
• コードに関するタスクしか管理しないならば、GitHubやGitLabのIssueでも
十分
• それ以外のタスクも管理するならば、タスク管理がメインとなっているJira
やRedmine、Backlogを使った方が出来ることが多く、管理しやすいと思う

8. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

9. 3. コードレビューができるようにする
• ソースコードのレビューを行うことで、コードの品質を担保する
• コードを書いた人以外がチェックすることで気が付けることも多い
• チーム内での知識の共有や教育にも繋がる
• レビュー依頼、レビューコメントのやりとりが行えるものを利用
• Pull RequestがApproveされないとマージできないようなフローとし、
マージ先には直接pushできないように設定すると、フローが強要で
きて良い
• GitHub、GitLab、Bitbukect など

10. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

11. 4. ローカル開発環境を統一する
• 各メンバが開発するためのローカル開発環境は、できるだけ同じ状
態にしておかないと、ビルドやテストなどの動作で差が出てしまい、
余計な工数がかかることになる
• 同じような状態の環境が作れるようにしておく
• 手順をWikiなどにまとめて、後から参画したメンバでも同じような環境が作れるように
• 設定等もソースコードと一緒に管理し、同じ設定で開発できるように
• 構築のための手数自体もできるだけ減らし、差が生まれる可能性を減らす＆より短い時
間で構築できるように
• DockerやVagrantなどの仮想化技術も活用

12. 4. ローカル開発環境を統一する
• Visual Studio Code の DevContainer という仕組みがおすすめなので、
まずはそちらを利用可能か検討すると良い
• DevContainerは、Dockerコンテナ上でVSCodeを通じて開発するための機能
• DockerとVSCodeがインストールされていれば、VSCodeを起動するだけで、必要な環
境が構築できるようになる
• 各種設定やミドルウエアをコンテナに押し込める(Dockerfileで記述)ので、各メンバ間
の環境の差異を無くせる
• DBなども別のコンテナとしてセットで起動可能(Docker Composeで定義)
• VSCodeの設定(インストールする拡張機能など)もファイルで定義でき、コンテナ
側で用意される
• DevContainerの設定はファイルとして定義するので、何か環境周りが変わったときは、
そのファイルを各メンバで取り込んでもらった(git pullしてもらった)うえで、コンテ
ナを再度ビルドすれば反映される

13. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

14. 5. コードのフォーマットを統一する
• チーム内でコードのフォーマットを統一することで、コードが読み
やすくなる
• 無駄な宗教戦争も減らせる
• フォーマットを設定し、その設定はソースコードと一緒に管理して、
各担当者で同じ設定となるように
• ファイルを保存した際に、自動的にフォーマッタが実行されるよう
にするのも忘れずに

15. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

16. 6. 静的解析ツールを利用する
• 静的解析ツールを利用すると、コードを静的に解析して潜在的な問
題点などを検出することがる
• 実行前やコードレビューに回す前に問題点に気が付くことができるので、
後の工程で余計な工数がかかるのを防ぐことができる
• 様々なツール、チェック項目が提供されているが、もしも何を設定
して良いのかわからない場合には、デフォルトの設定を試しながら、
プロジェクトにあった設定にしていく
• 何か問題が見つかった場合に、それを静的解析で検出できないか調べて、
項目として追加して改善していくと良い

17. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

18. 7. ビルドの手間を減らす
• ビルドをするのに手作業が入ってしまうと、繰り返しビルドするの
が手間になる
• ビルドが手間になってしまうと、ビルドの頻度が落ち、ビルドが失敗する
ことに気が付くのが遅れかねない
• 1コマンド(or 1アクション)でビルドが完了するようにする
• ソースコードをリポジトリからチェックアウト後、1つのコマンドでビルド
が完了するような形になっていることが望ましい

19. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

20. 8. デバッグできるようにする
• デバッグ実行可能とすることで、コードを追いやすくなる
• IDE上からブレイクポイントを張って、デバッグ実行できるように
• 何か問題があって、それがどういった状態で発生したのかを確認す
る際にも、デバッグ実行できることが開発効率をあげることになる

21. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10. CIで定期的にチェックし、フィードバックを得る

22. 9. ユニットテストを書けるようにする
• コーディングを行う上で、ユニットテストには多くのメリットがあ
る
• 生産性向上
• ユニットテストを書くことで、小さな単位でコードを書いて動作を確認すると
いったことができる
• 一通りコードを書ききってから確認するより、手戻りも減らせることになる
• リグレッションテストによる問題の早期発見
• ユニットテストがあることで、変更箇所が意図せずに他の箇所に影響を与えてし
まうようなこと(リグレッション)にすぐに気が付くことができる
• リファクタリングしやすくなる
• ユニットテストがあることで、振る舞いが変わらないことを保証できるので、リ
ファクタリングが行いやすくなる

23. 9. ユニットテストを書けるようにする
• ユニットテストは繰り返し実行できる状態にしておく
• ビルド含めて繰り返し実行できる状態になっているとよい
• ユニットテストの網羅性を確認するために、カバレッジレポートも
確認できるように
• カバレッジレポートを確認することで、足りていないテストに気が付くこ
とができる
• ユニットテストでもデバッグ実行できるようにしておく

24. 1. 情報共有できるようにする
2. タスクを確認できるようにする
3. コードレビューができるようにする
4. ローカル開発環境を統一する
5. コードのフォーマットを統一する
6. 静的解析ツールを利用する
7. ビルドの手間を減らす
8. デバッグできるようにする
9. ユニットテストを書けるようにする
10.CIで定期的にチェックし、フィードバックを得る

25. 10. CIで定期的にチェックし、フィードバックを得る
• CIツールを導入し、定期的にビルド、テストなどを行う
• 結果はチャットなどに通知し、すぐに問題に気が付けるように
• branchで問題無くても、mainにマージされたタイミングで他のマー
ジとの組み合わせによってビルドやテストが壊れるといったことは
良くあるので、それをすぐに検知したい
• mainをチェックアウトした人が気が付くのではなく、CIで自動的に検出す
ることで、どのマージによって壊れたのかといったことを把握して、すぐ
に対応することができる
• GitHub Actions、GitLab CI/CD (GitLab Runner)、CircleCI、Jenkins