More than 3 years have passed since last update.

チーム開発を終えて(スクール振り返り)

Last updated at 2020-05-11Posted at 2020-05-11

はじめに

【この記事を書いたきっかけ】
3ヶ月間のプログラミングスクールのカリキュラムを終えて、2ヶ月目のチーム開発においての学びや気づいた事をいつでも振り返れるようする為。

1チーム4人のグループに分かれて、ECサイトを開発する。
流れとしては要件定義→設計→開発→テスト

要件定義・設計はある程度決められており、（機能やワイヤーフレームなど）
自分たちで行った作業は主にER図・テーブル定義書・アプリケーション定義書・開発・テスト

・ログイン機能(devise)
・それぞれのページのレイアウト(Bootstrap)
・担当範囲以外のヘルプ

deviceを使ってユーザーと管理者を分けてログイン機能を追加した。デザイン面の担当でBootstrapを使ってレイアウトを整え、自分の手が空いたら他の箇所の手伝い。

チーム開発では当たり前のことだが、開発ブランチと本番ブランチに分けて開発を進めていく。
(メンバーごとにブランチを分け、機能や修正ができたらpushしてmasterブランチにマージする)

今回はコミット名は細かく決めていなかったが、実務ではずっと同じメンバーで開発する訳ではないので、誰でも理解できるようにコミット名のルールを決めると良い。

今回は時間が少なかったので、テストは手動で動作確認したのみだった。

なので、RSpecでテストコードを書いてテストすれば、エラーが出るところがあったかもしれない。アプリが完成した後に、テストコードを書いて実行するとエラー祭りで解消するのに時間がかかるので早めにテストコードを書く必要があると実感。

テスト駆動開発（TDD）もあるぐらいなので、テストは機能追加時など早めに書くのが良い。テストしておけば、リファクタリングもしやすい。

エンジニアは一人でパソコンと向き合って作業を進めるイメージだったが、そんな訳でもない。

実際は開発をする上でチーム内でコミュニケーションをとるのは必要不可欠。積極的にコミュニケーションをとる事で意見も言いやすくなり、開発がしやすい場になる。

また、コミュニケーションを取っておかないと認識のズレが起き、エラーやミスが出る原因となる。

私はチームの最年少だったので意見を良いやすい立場ではなかったが、積極的に発言するように意識した。

自分ができることやできないことなどしっかり伝えないと相手も理解できないし、年齢に遠慮して発言できないと最終的に迷惑をかける可能性もある。

開発途中にはKPTを2回実施し、振り返った。KPTでも同様にそれぞれがしっかり考えを話すことでお互いの状況を理解できるようになる。

チーム開発ではコンフリクトが起きたので、随時対処する必要があった。

<コンフリクトで意識したこと>
コンフリクトが起きないようにチーム内でチャットツールなどを使い、
どの範囲を変更するかなど密なコミュニケーションを取った。

それでもコンフリクトが起きることは必ずあるので、
対処する際はどの範囲を削除するかなど確認して修正する。

チーム開発を通してGitHubの使い方をより理解できたのは良かった。

・ブランチを切ることで同時に開発が進められる・コンフリクトが起きた際の対処法
など実際に開発をしながら経験した事で理解もしやすく、現場に入っても活かせる。

だが、それでもまだまだGitHubを有効活用できる。例えば、issueごとにプルリクエストを出すなど、より実務に近い形で活かせる使い方をしていきたい。

要件定義からテストまでサービスが完成するまでの流れを一通り知ることができた。

要件定義や設計だけでも数日時間がかかったのは驚きだったが、これらのことをせずにいきなり開発してしまうと必要な機能の漏れなども出てくるので必要な過程だと実感。また、要件定義や設計をしっかり行うことで開発スピードも早くなる。

チーム開発を通して開発だけでなく要件定義、設計などの上流工程の内容について学ぶことができた。

チーム開発を通して学べることはたくさんあった。チーム内でレベルの高いエンジニアがいると、自分ももっとやらないといけないと良い刺激を受ける。実際の現場ではチームで開発を進めるのが基本なのでもっとチーム開発の経験を通して力をつけていきたい。