LoginSignup
8
1

More than 3 years have passed since last update.

実務未経験者が共同開発をして公開するまで

Last updated at Posted at 2021-03-03

1.はじめに

オンラインサロンにて共同開発のお知らせがあり、チームリーダーとして開発を行いました。
未経験者が共同開発を終えて学んだこと、気をつける点を書いていきます。
これから共同開発に参加する方の少しでも参考になれば幸いです。

2.簡単な自己紹介

・学習期間2020年10月〜 
・実務未経験
・転職に向けて学習中

3成果物について

(トップ画面)
1.jpg

成果物はこちら(架空サイト)

4.概要

概要
・開発期間は3週間
・週1のミーティング
・完全再現ではなく、納期優先

メンバー構成
・現役エンジニア(メンター)1名
・実務未経験者3名

環境 / 技術
・EJS
・Sass
・Javascript(jQuery)
・Node.js
・記法 Scss
・CSS設計(FLOCSS)
・GitHub(ソースコード管理)

5.事前準備、環境構築

【実施事項】
・初回ミーティング
Trelloでタスク管理
・実装内容をissueに登録
・チーム内のルール決め
・Node.jsのバージョンを統一
・GitHubでリポジトリ作成


【実施したこと】
チームリーダーとしてスケジュールの管理、進捗の確認、ミーティングの日程調整を行いました。
また、1日の進捗報告を必ず行うことでメンバー全員で個々の状況を把握することができました。

【学んだこと、気をつけた点】
Trelloのガントチャートでタスク管理。ヘッダーやお問い合わせフォーム等の担当ページをチーム全体で管理・共有することでスケジュールを把握して、デプロイから逆算して実装を進めていくことができました。

6.実装

【実施したこと】
・GitHubでソースコードを管理
npmでパッケージをインストール
・ブランチの作成
・担当部分の実装
・CSS設計:FLOCSS記法


【学んだこと、気をつけた点】
メンバー全員が仕事の合間を縫って開発に取り組んでいたため、質問する時は何をどのように試したこと、実装したい内容を詳細に説明するように心がけました。また、わからないことはSlackで質問して記事の共有やコードの確認、修正をして開発を進めていきました。

コードの記述はSassを使用。
FLOCSS記法で開発を進める仕様でした。初見でしたが、FLOCSSについての記事を読んだり、メンバーのコードを確認することで書き方を知ることができました。FLOCSSを使用して一番最初に実感したことは、CSSの記述が少なく済むことです。Project、Componentでコードの再利用ができたり、BEMを取り入れることで要素と要素の繋がりがわかりやすくなりコードの可読性が上がります。チーム開発やコードを確認するときには重要な記法だと開発を通じて経験することができました。

FLOCSSを使ってCSSファイルを20,000行から9,000行にした話

ブランチはmasterと担当ページごとにブランチを切り、pushしていきました。個人でブランチを切ることは少ないと思いますが、共同開発でのmasterブランチは本番環境リポジトリになるため、誤ってmasterブランチにpushしてしまうと他のメンバーにも影響してしまうので、gitコマンドを調べたり、git branchで現在の作業ブランチの確認を行い、プルリクをしてからpushするようにしました。結果として、gitコマンドの理解が深まりました。

7.実装ページ

・TOPページ
・ROOMページ
・AREA GUIDEページ
・ACCESSページ
・CONTACTページ
・Faqページ
・Header
・Footer

【学んだこと、気をつけた点】
開発中に大変だったことは以下の2点です。
①実装したいコードの書き方がかわからない
②エラーの修正


①実装したいコードの書き方がかわからない
実装を担当したHeader、Footer、ARIA GUIDEページを進めていく中で、JavaScriptの実装では動作がうまくいかないときが何度もありました。そのときに実践していたことは、似たようなサンプルをGoogle検索やQiitaで調べてコードを少し書き換えてみる。それでもうまくいかないときはメンバーやメンターに質問をするようにして実装を進めていきました。


②エラーの修正
エラーコードの内容がわからないときはGoogle翻訳で日本語に変換してから、ネットで検索したり、コードがどこまで動作しているかconsol.logを使い検証ツールで確認作業を行いました。

また、エラーはメモに保存してエラーの内容と解決方法を残しながら進めていき、同じエラーが起きてもメモを見返して対処するようにしていきました。

8.コードレビューまでの流れ

【実施したこと】
・ローカルリポジトリへ保存
・リモートリポジトリ(現在と同じ作業ブランチ)にプッシュ
・プルリクエスト
・チーム内でコードレビュー
・レビュー結果に基づき修正
・メンターによるコードレビュー
・再度、修正
・リモートリポジトリ(masterブランチ)へプッシュ


【学んだこと、気をつけた点】
gitコマンドの一連の流れを学習することができました。特に頻繁に使うコマンドやエラーはメモを取るようにして、次回以降に同じ内容のエラーが出てもすぐ対処できるようにしていきました。

また、メンバーやメンターからコードレビューをしていただいたことで、コードを変更する時の注意点や、文章が事前に用意されているときは手打ちせず、コピペをすることだったり、修正依頼が来たときに対処しやすいコードの書き方をご教授いただき見本に近い実装をすることができました。

9.まとめ

共同開発でデプロイするまでの開発フローやコミュニケーションの取り方を経験することができました。
特にGitHub、Git、コミュニケーションの取り方は重要だと考えます。

GitHubのリモートリポジトからローカルリポジトリにクローン、ブランチを切って作業を進めることや、ローカルリポジトリにコミット、プルリクエストしてissueを閉じるまでの流れを理解すること、Gitはコマンド操作、コミュニーケーションを取るときには詳細を伝えることで開発をうまく進めていけると思います。

最後にここまで読んでいただきありがとうございました。

8
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
1