ページのイメージ
WEB開発 2020/10/29

チームでのシステム開発をふり返ってみる

  •  
  • このエントリーをはてなブックマークに追加

こんにちは、ITソリューション課の中村です。

 

いま自分はイエタテの開発を、4名のチームで行なっています。

エンジニア4人でどのようにチーム開発をしているか紹介したいと思います。

 

設計・製造・レビュー・テストを分担

 

4名いるので、

 

設計   → Aさん

製造   → Aさん

レビュー → Bさん

テスト  → Cさん

 

のように、手分けをして行います。

 

ベテランの方にレビューしてもらうととても多くの気づきがあり、学ばせてもらえます。(感謝!)

複数人の目に触れて、考えることで品質向上にもつながります。

 

さらに、これらの工程の中で

効率化のためのちょっとしたルールを設けています。

 

設計書や仕様書は1か所で共有

 

設計書やテスト仕様書はGoogleスプレッドシートに書いて、一か所にまとめて保存しています。

そうすることでレビューや修正、テスト結果の確認がスムーズになります。

また、過去の内容を見返したいときにも探しやすいです。

 

Gitのブランチ名には規則をもうける

 

Git(バージョン管理システム)を使用しているのですが、そのときのブランチ名には規則があります。

こうすることでマージ先がわかりやすくなり、複数人で1つの案件にとりかかりやすくなります。

 

例)

 <main_branch>  メインとなるブランチ
 <main_branch_common>  メインから派生したブランチ 共通プログラム用
 <main_branch_markup>  メインから派生したブランチ マークアップ制作用
 <main_branch_list>  メインから派生したブランチ 一覧制作用

 

レビューにラベルをつける

 

ソースコードレビューの際にはコメントを残したい行を指定し、

そのコメントがどういう意味合いであるのかをラベル付けします。

 

例)

[good] 良かったところ
[must]  必ず対応してほしい!
[imo]  自分の意見や提案・好み。 自分ならこう書くけどどうかな?
[nits]  些細な指摘。 ほんの小さな指摘だけど出来れば直してほしい。インデントやタイポ
[ask]  質問,確認。 コードの意味や背景が分からないから教えて!こういう理解でOK?

 

参考サイト

レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話
https://qiita.com/godgarden/items/3ea57a7ee6dbff1df6e6

 

このラベルを共通認識として持っていることで、考えていることが伝わりやすくなります。

 

進捗ミーティング

 

週に1回ミーティングをしています。

 

CV数などの到達度や、イエタテ全体の動きの共有。

進行中のタスクの現状確認や、新しいタスクの役割決め、

各自がここからの1週間でやることと、その先のタスクの見通しなどを行います。

 

席で作業しているときも、それぞれ質問や会話をすることはありますが

全員そろって話すことは少ないので、認識を合わせる大切なミーティングです。

 

まとめ

 

複数人で開発を進める上で、チーム内で決めたルールが非常に効果を発揮していると思います。

ルールが増えすぎると息苦しくなってしまいますが、

プロダクトと同じように、チーム開発も改善を重ねていきたいと思います!

 

 

 


しずおかオンライン中途採用社員も、積極募集中!
「womo」「イエタテ」のスタッフとして、地域の魅力を伝える仕事です。
くわしくはこちら!

Category

Ranking