こんにちは、DobokuLab 1期生の水谷です。
【アプリ制作未経験が、液状化アプリを作ったら？】
をしばらく定期にお届けします！今回はその第7弾！
液状化アプリというものがこちら！！
無料で、サンプルデータが既に入っているのでぜひ使ってみてください！！
またフロントエンド側のソースコードも公開いたします。興味あるという方、コードレビューしていただける方見ていただけたらと思います！！gitの使い方知らないけど見たいという方いらっしゃいましたら、私のTwitterのDMにお越しください！
バックエンド担当のはたはたさん、そしてフロントエンド担当の水谷でリレー形式で書いていくので、記事がそれぞれの担当の制作順につながっていることもあるので、こちらで整理してありますのでご覧ください。
さて、フロントエンド編③では”チームで開発する”というところに焦点を当ててお話していきます。大学では個人作品が多いのでこういったことは少ないかもしれませんが、会社でなにかwebやアプリ系の開発をするとなったらチームで開発するということが一般的かと思います。
チーム開発の楽しみ方
チーム開発を実際やってみた経験などをメンバーに聞いてみました。
みずたに
はたはたさん
笹澤さん
やはりプログラミングやりたかったら1人というのはなかなかモチベーションが続かないが、みんなでやればできるし感動を共有できる。これは3人とも同じことを言ってます。さらに、ローンチ日のTwitterが楽しかったことはきっとさらに大人になっても消えないことでしょう。
でももしかしたらこんなことを考えた人もいるのではないでしょうか？
・みんなでやると誰が何をやっているとかが分からなくならないのか？
・自分が失敗したら迷惑かけないのかな？
大丈夫です。それを管理する方法がちゃんとあります。web業界ではかなりつかわれており、このアプリ制作時にももちろん使いました。それがgitというものです。
チーム開発の考え方
もし何も考えずに始めたら？
wordやExcelを同時編集しようと思った時に皆さんは今まで、共同編集モードを使ったりファイルを送って編集したりといった手段を用いていたのではないのでしょうか？
しかしweb制作となると、
画像の左側を見てもらえばわかるようにファイル数がけた違いに多くなります（画像にはすべてのファイルが収まらなかったです。）ファイル数1つをword文書1つとして考えたときにこれだけあると単純に共同編集は出来なさそうですよね。
では仮にこれを何も管理もせずに行ったらどうなるでしょうか。
間違いなく、ケンカが起きますね（笑）。AさんとBさんの関係のように作業の2度手間になってしまったり、あるいはCさんのようにAさんの作ったものとBさんの作ったもののどっちを信用すればいいのかということになったり、とにかく問題が山積みとなってしまいます。
チーム開発必須のツール
チーム開発必須のツール、それは
です。正確には違うのですが、よくgithubを略してgitというくらいこのgitとgithubはよく使われるツール、サービスです。また難しそうなものが、、と身構えなくて大丈夫ですよ。しかしこのgitによって上の3人の悩みが一気に解決されます。
簡単に考え方だけ示すと、
というようにかなりすっきりするのが分かるかと思います。効率的で他人が何をやっているか直感的になりますね。また、変更・修正を加えたファイルをもとのところに戻す際にどこをどのように直した、消したの変更履歴が全て残るのでもし間違えてしまったとしても変更内容を取り戻すことができます。さらにその内容を開発メンバー全員が見れるのでおかしなところがあった場合には確認していただくことも可能となります。画期的ですね！
ちなみにgitについてネットで調べてみると土木学生がちょっとアプリを作ってみたい！というだけなら、ここまでいらないという内容が多いです。
なによりgitは土木学生目線でいうならかなり専門的になりますから本当に必要なところだけ理解してあとはふーんで乗り切りましょう！
まだ簡単すぎてつまらない！という人向けにさらに話を進めます。よくわからない、そこまで詳しく知る必要のない人は次の章へ進んでください！
なんだかよくわからない単語が出てきましたね。
まず何もgitで管理していない状態の時のことをmasterということにしましょう。例えば今回作った液状化アプリを拡張しようということになったときにこの場でもし編集してミスると、そのときに液状化アプリを使ってくださっている方には訳も分からず誤作動を起こさせてしまいます（修正の間使えなくなってしまいます）。そうなっては困るので、masterとファイルの内容を全く同じものをdevelop（開発環境）として作ります。この動作をブランチ（日本語で’枝’の意）を切るといいます。
こうすることによって開発環境の方で作業していてミスが起きても、本番環境であるmasterブランチには影響が出ないということになります。そしてさらに前述したチケットごとに管理できるほうが都合が良いため、チケットの枚数だけブランチを切ってそこで作業します。（ここについては人単位にブランチを切るなど開発チームによって異なります。）
チケットごとに切り、そこが完成したらその内容をdevelopに入れて、さらにブランチを切って別のチケットに書いてあるタスクをするという繰り返しを行います。developの内容で本番のほうに入れても問題なくなって初めてmasterに内容を更新させます。
他にもブランチには緊急用のものなど開発チームや開発内容によっても大きく異なりますが、一般的にmasterとdevelopを分けることのほうが多いように思います。
ざっくりではあり、かなり一部分についてのgitの話でした。
アプリやwebをチームで開発するときのフローというのはこのようなものがあるのですね。知らなかったという人も多いのではないでしょうか。
gitについてより詳しいことを知りたい、勉強してみたい方は
改めて言いますが、gitについてネットで調べてみると土木学生がちょっとアプリを作ってみたい！というだけなら、ここまでいらないという内容が多いので、実際に使ってみて必要なところだけ勉強しましょう！！質問はいつでも受け付けますね。
まとめ
私はチーム開発について開発メンバーの数だけ、ブランチの切られた数だけアプリは強く面白くなると思ってます。
その人が初心者かある程度の経験者かそれは関係ありません。アプリを面白くしたい！その思いがあれば、例えばアプリのデザイン、機能、計算処理、あるいはチーム内連携に必ず良い変化が生まれてくるでしょう。自分ができないときは頼んでしまえばいいんです。そこで学べます。自分ができそうで相手ができないときにはそこをやる、そうやって人対人についても相乗効果を生み出していくのです。そして何よりこうすることで自分の成長が、周りの反応などでより感じられると思いますよ！
最後に、土木学生で特に専門知識があまりない2回生までの人へ、今のうちに画面作れるようにして研究をした時やそれの発表の手段として将来への投資に、3回生以上の方も表現の幅増やしてみませんか？？
ぜひ、私たちと一緒にプログラミングを勉強しましょう！
ご興味ありましたら、ぜひ私のTwitterのDMよりぜひご連絡ください!
フロントエンド編定期連載は今回で最後になります。また不定期で記事上げていきます！
それではまた。
