19
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GitHubを使わないチーム開発の難しさ

Posted at

初めに

 私はGASを使ってチーム開発をする機会がありました。ただ、なんとGitHubを使うことができませんでした。未経験の方もいたのでGitHubのキャッチアップまで時間を確保するのも難しいですし、多くの理由から使えないようになっていたんだと思います。
 まず、このチーム開発では未経験3人と経験者1人(自分)でチームを組んで開発していきます。そして、前提として経験者はアドバイザー的な立場となってチーム開発をするように言われます。つまり、企画とか発表を押し付けて経験者1人が開発することは推奨されないということです。

これは困った!!

いい物を作るなら1人で作った方が早い様に思えてしまう。GitHubもないから別々で作ってもコードをくっつけるもめんどくさいし、キャッチアップの時間も必要になる。良い結果を残そうとすると一人でやった方が早いし、チームメンバーも薄々そう思っているのではないかという疑心暗鬼になってしまう。

ただ本当に大事なこととは

結果的に1人で開発することはせずに、全員の今後のためになるにはどうしたらいいかを一番に考えて行動することにしました。一人でカタカタして得られた良い製品ではなんとなく罪悪感が残りそうです:hugging:チームメンバーが開発を通して経験者がやってくれたから達成感はあんまりないとかなったら悲しいですよね:sob:
せっかくだから開発ってちょっと楽しいと思えるくらいの最初のお手伝いができたらと思ってみんなで開発するにはどうしたらいいか考えてました。

本題

GitHubの役割

チーム開発で必要なことはざっくりこの二つだと考えています。

・環境を分けることができる
・書いたコード簡単に?統合することができる

環境を分ける
→複数人で同じファイルを触ると間違って人のコードを消してしまったり、同じ変数を使っていたりトラブルが起きてしまいます。そのため、同じファイルを複製して各々専用のファイルとして扱う必要があります。これを、環境を分けると表現しています。

書いたコードを統合する
→環境を分けたことで実際の製品の状態にするには統合しないといけません。GitHubならいい感じに統合してくれます。GitHubがないと変数名とか関数名が被ってなくて、このコードを何行目に入れたらよくて、ここは同じ機能だから無視してくて等々、考えるだけでめんどくさそうなのでこれ以上の例は上げません。考慮する要素が多くあるため、見逃してしまうことが多いです。人為的ミスを極力減らしてくれるGitHub君は素晴らしいということですね:thinking:

問題点

環境を分けるのはコピペで何とかなります。問題は、コードを統合する事です。これがめんどくさいわけです。開発の成功体験をみんなが積むための壁となって立ちふさがるわけですね:frowning2:

改善案

分担する前に機能を関数まで落とし込んで関数ごとの入力、出力を明確にしておくことが大切だと思っています。

これは、前提としてついついスプレッドシートから値を取得する機能の人、カレンダーにスケジュールを入れる機能の人みたい感じで機能ごとに分担してしまうと入力、出力が統一されておらず統合がしにくくなります。

A関数→B関数→C関数みたいな感じで繋がりを意識できるところまで設計を落とし込むことができたら、関数をコピペするだけでほぼ統合が終わることになります。こうなると人為的ミスはかなり起こりにくいいですね。なんなら他のファイルから関数を呼び出す方法がわかっているならmainファイルに1行書くだけで統合が終わりみたいなものです。

以下は、かなり抽象的ですが関数を動かすmainを用意しておいて先に関数を繋げて、関数さえ正しく動けば完成する状態まで全体を設計しておく。そして、関数ごとに仕事を分けて開発を進めることでGitHubが無くても簡単に統合できると思いました。

main.gs

int a = 〇;

Num = A(a);
Ans = B(Num) + C(Num);

return Ans;

A(a){
int x;
ここにAさんが機能を書く
return x
}

B(b){
int y;
ここにBさんが機能を書く
return y
}

C(c){
int z;
ここにCさんが機能を書く
return z
}

振り返り

では、開発中にここまで考えてきれいに進められていたかというと自分できていませんでした。mainファイルは頭の中にはできていてメンバーにはこんな感じで機能を作ってほしいと頼んでいました。今思うと、ちゃんとここまでmainファイルを作り込んだものを見せて頼んだ方がわかりやすかったのですが、ややこしい話よりも機能を実装するという方に集中させてあげたいという気持ちを盾にめんどくさがりな部分がでていました。

この記事を書いているときにGitHubがとか関係なくチーム開発はこうやってちゃんと考えた方がいいよねって話になってる気がしましたが許してください。
チーム開発をこうして振り返るとやっぱり難しいチャレンジだと思います。実際のチーム開発ではもっと適当だったのでこんなのでもしっかり機能を作ってくれたチームメンバーには感謝しかありません:sunglasses:1人では見られなかった景色をみせてくれて良い機会となりました。

19
10
2

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
19
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?