初めてのチーム開発を終えて
2023年12月22日～2024年1月10日の約3週間で初めてのチーム開発を
行いました。今回は企画者およびリーダーとして関わりました。
まずは、できる限りの時間を費やしてくれて企画に最大限にコミット
してくれたチームメンバー、色々なアドバイスをして頂いたスタッフ
の方やチューターの方や先生達に深く感謝いたします。
今回のチーム開発について一通りまとめたいと思います。
０．コンセプト
今回のチーム開発では下記のコンセプトを掲げてメンバーを募集
・みんなで集まってわいわい意見を出しながら、意見を取り入れながら
作っていく！
・休む日はきっちり休んで作る時は作るでメリハリつけて作っていく！
また、チームに参加するメリットとして下記の内容を提示
・子供と大人が扱いやすいアプリを作成を進めていくことで
→UI・UXのスキルアップ！
・みんなで手順や機能追加、日程調整を考えながら行うことで
→プロジェクトマネジメントのスキルアップ！
・プログラムも助け合い教えあいながら一緒に作っていくことで
→プログラミングのスキルアップ！
上記の企画をプレゼンした結果、現在子育て中の2人とUI・UX分野が得意な
1人が参加してくれることが決まり、4人で開発を始めることになりました。
使用したツール：パワーポイント
使用用途：
チームメンバー募集の際のプレゼン作成で使用
１．役割決め
デプロイフェーズでハスラー（起業家）コースを希望する人がいる
なら、その人にリーダーを譲って自分は開発者としていこうかなと
甘い考えを持っていました(笑)
しかし話し合いをした結果、自分がリーダーになりました。それも
そうですよね、自分が企画者なんだから(笑)
それ以外の役割については、ほぼほぼ決めていません。
というのも、全員で代わりばんこで色々な役割を経験していく方が
今後のコース選択を考えやすくなるし、それぞれが総合的にレベル
アップできるということでそのようになりました。
また、住んでいる所がバラバラで会うことができないので、集まる
時は学校が用意してくれているgatherを使用することにしました。
(zoomやgoogle meetは無料アカウントの場合、時間制限があるため)
今回はスクラム開発で開発いたしました。自分は今回のチーム開発
が終わってから下記の本を読んだのですが、先に読んでおけば良かった
と後悔したほどスクラム開発について分かりやすく書かれています。
使用したツール：ZOOM
使用用途：
役割決めや企画のおおまかな説明
２．全体のスケジュールを作成
初めての事が多かったので、リスケすることを前提にして余裕を
持ったスケジュール作成を行いました。スケジュールには開発に
必要な項目と期間、日付を書き込んでいきました。
全員の一日の流れ等を話し合って全体で集まる時間を夜の21時に
設定することにしました。（デイリースクラム）
終わってみれば、ほぼ毎日朝9時～12時、14時～17時、21時～23時
でみんなで集まって作業してましたけどね(笑)
スケジュールはとりあえずで設定しただけなので、やってみて上手
くいかない場合は、その都度変えていこうということで合意して進
めていきました。
そのため、リスケしやすくスムーズに開発を進めることが出来たと
思います。
個人の大まかな予定（休みたい日など）も加えていくことで、予定
が立てやすかったです。
使用したツール：ZOOM、googleスプレットシート
使用用途：
講義時の講義用のZOOMのブレイクアウトルームを使用
スケジュールはスプレットシートに記入。行は日付、列名は作業内容の
予定・集まる時間・（個人名）の予定×４
３．必要となる機能面の洗い出し
まずはプロダクトバックログを洗い出しました。
企画の構想段階では自分の中で、どのような機能を入れるかイメージをして
いましたが、今回はチーム開発ということもあり、取り入れる機能はチームで話し合ってみんなのアイデアを取り入れることにしました。
過去の苦い経験
以前、別のワークショップに参加した際にチームで考えることがあったの
ですが、自分の意見をゴリ押し過ぎてしまいチーム内に不協和音が生じて
しまった苦い経験があります。
上記の経験を踏まえて自分の意見をゴリ押しせず、全員の意見を取り入れて
いくようにしたことで、自分の想像以上のアイデアが生じたと思います。
また最初は、恐らく私の意見を尊重しようとして他のメンバーが意見を出す
ことを遠慮している感じでしたが、思ったことをドンドン言ってもらい出て
きた意見をドンドン取り入れていくことで話し合いが活発になりました。
そうしていくと他のメンバーも当事者意識を持って取り組んでくれるように
なり、友達の保育士に聞いてくれたり近所の幼稚園バスの運転手さんに意見
を聞いてくれたりと積極的に動いてくれました。
スプリントバックログ
意見をバシバシ出していき、その中で優先順位を付けていく方法により
プロダクトの解像度が上がっていったと思います。
今回はスクラム開発を取り入れていましたので、優先順位の高いものを
今回のスプリントのスプリントバックログとして、それ以外のものは
今後、このプロダクト開発を継続する場合のスプリントのバックログと
して残しておくことにしました。
使用したツール：gather、googleスプレットシート
使用用途：
gatherで集まって、画面の共有等で使用
スプレットシートで１列でプロダクトバックログを書いていき、上から
優先順位の高いプロダクトバックログになるように並べ替え
今回のスプリントのスプリントバックログを黄色に枠で囲って黄色にして
目立つようにした
４．FigmaでUI部分を作成
上記で決めたスプリントバックログから、さらに細かくタスクを作ろうと
した段階でメンバーから「外観がないとイメージがしづらいからＵＩの部分
を作ってタスクを作った方がわかりやすいのでは？」という提案をしてもらい、スプリントバックログに沿った外観の作成作業を始めました。
Figmaを使用することで、全員で一緒の画面で同時に作業することができ、
全員が手を動かしながら作業できたことは良かったです。
UIの部分を作りながらUXの事を考えてボタン等の配置を変えたり、画面を
作りながら面白いアイデアも出てくることもありました。
(ボタンを押すとボタンが変形、声が出る、などなど)
出てきたアイデアは最初から否定をしてはいけません。一旦Figmaで作成
してみて必要なさそうだったり、技術的に厳しそうだなと思った時点で
みんなの意見を聞いて合意を得てから削っていくという方法が良いです。
プロダクトを作っていく中でもアイデアが湧いたりする場合もあったので
この工程以外の時にもFigmaの修正をしていました。
Figmaを作りこむことで分かったこと
アプリの外観を作ることで、どのようにページ遷移するべきか見えてきます。そして、そこから必要な情報が見えてきてDBのテーブル構造を考える
ことができました。
外観のページのファイル名も先に考えておいたことは良かったです。
実際にプロダクトをで作っていく中で、扱っているファイルがどのファイル
なのかが可視化できてわかりやすくなり共有しやすかったです。
Figmaでたっぷり時間をかけて作り込んだ設計図が、この次の作業から最後
の最後まで重要な作業指針になることを実感しました。
このFigmaでの作業がチームとして最も力を入れた部分です。
今回はなるべく早く次の工程のプロダクト作成に取り組みたかったため、
Figmaの使い方はあまり調べていません。なので上手く使えていない部分
はかなりあったと思います。
例えばフレーム化であったりコンポーネント化だったり左の項目名もごちゃ
ごちゃになってしまった部分があるので、Figmaの使い方をもう少しマスタ
ーした上で使っていくと更に良くなっていく気がします。
使用したツール：gather、Figma、google スプレットシート
使用用途：
gatherで集まって、画面の共有等で使用
Figmaでアプリの外観、ページ遷移、DBのテーブル構成など作成
スプレットシートで必要なタスクを作成
５．githubを使用したデータの共有
設計図が完成したので、プロダクト開発に取り掛かりました。
本来であればチームや会社用のgithubのリポジトリからそれぞれの個人
のgithubに招待をして同じリポジトリを使用しながら開発する流れに
なると思うのですが、今回は自分のgithubに企画用のリポジトリを作成
してメンバーを招待する形で開発を行うことにしました。
しかし、最初の段階で2枚の分厚い壁にぶち当たります。
Laravelの壁
今回はLaravelを使用したプロダクトを開発していたのですが、githubに
プッシュしても.gitignoreで指定しているファイルはプッシュされません。
しかし、プッシュされないファイルの中に起動するために必要なファイル
が含まれていたので、そのファイルをどのように共有するかがわかりません
でした。探せど探せどうまくいく方法が見つからず、途方に暮れていたの
ですが、スタッフさんに相談して先生に繋げてもらったことで教えて頂き
無事難題をクリアすることができました。
詳しい解決方法は省略しますが、下記のURLの「既存アプリケーションでComposer依存関係のインストール」の部分の実行や、npmのインストール
作業をしていくことが必要でした。
githubの壁
チューターさんに色々と教えてもらい、ある程度のgithubを使用したチーム
開発の流れを教えてもらいました。
しかし、自分も含めて全員が日頃からgithubを使用していなかったので、
ブランチ？プルリク？マージ？？と全然理解していませんでした笑
まずは、それぞれ本を読んだりググったりしてgithubを使用したチーム開発
の方法を調査することにしました。自分が参照したのは下記の本です。
（古い本のため情報が古いので注意）
後日下記のUdemyの動画を見たのですが、凄く分かりやすかったので
オススメです(上の本より良いと思う、セールの時に買った方がいいよ)
調査してから、まずはテスト用のリポジトリを作成してブランチを切って
コミット→プッシュ→プルリク→マージする流れを繰り返しました。
テスト環境である程度慣れてから本番環境で開発してよかったです。
本番のプロダクト開発ではコンフリクトも発生して対応できたので、いい
経験になりました。イシューやマイルストーンもちょこちょこ使ってみま
した。
６．いざ開発！！
最初は、自分がある程度の所までコーディングして、行った作業の説明を
しながら、細かい部分を他のメンバーに作ってもらおうかなと思いました。
いざ実践してみると、自分だけがコーディングして他のメンバーが手持ち
無沙汰になってしまいました。これではマズイ！！と思いました。
なぜならメンバー募集の際に、このチームに参加するとプログラミング
スキルがアップするよ！と言っておきながら現状は自分のみがコーディング
して自分だけ経験を積んでいっているような状態になったからです。
しかもFigmaの設計図の時はワイワイ楽しみながら作業ができていて、モメ
ンタム（勢い）がある状態だったのに、このままではモメンタムが失われて
しまうという危機感に駆られました。
すぐに方向転換をして、チューターさんに教えてもらったコンポーネント
作成、ビューの作成、ルート等の作成を分けて作業するという方法に変更
して、それぞれの作業をみんなで1つ1つこなしていくやり方にしました。
ペアプログラミングならぬグループプログラミング(造語)で！
開発する際は二人（上級者&初心者）でコーディングするペアプログラミングという手法を取り入れることがあるそうです。
効率は悪いですが、このチーム開発は勉強の一環ということもあり全員で
教えあいながら作業していくことにしました。(グループプログラミング)
（後日談ですが、スクラム開発の中に上記のやり方が存在しておりグループ
プログラミングではなく「スウォーミング」という名前らしいです）
コンポーネントの作成などは分担して作っていき、誰かが作り上げる毎に
お互いを褒めたたえていたので、雰囲気は物凄くよかったです。
ある程度コンポーネントの部分を作り終えると、ビューの部分を1枚1枚
代わりばんこでコーディングして、あーでもない、こーでもないと言い合い
ながら、開発を進めていきました。
コントローラーやモデルを含むルートの処理なども同様に自分は口出し役
となって、メンバーにコーディングしてもらうようにしました。
GIVEする際に自分自身が内容を理解できていないと相手に説明しても伝わ
らないので、GIVEしていく事で自分自身もLaravelの知識が深まった気がし
ます。GIVEすることで分かってくることもあるのでTAKEにもなりました。
雑談も大事
夜の作業は21時から22時若しくは23時に終了しましたが、その後は少し
雑談タイムがありました。朝や昼の作業でも合間合間に雑談タイムが
ありました。以前の自分であれば雑談なんて無駄だ！と思っていた時期も
あり、実際に雑談を遮ったりしてめちゃくちゃ顰蹙を買うという苦い経験もありました笑（前述のワークショップの時）
しかし今の自分は改心していたので（たぶん）、一緒に雑談を楽しむことが
できました。雑談を挟むことで息抜きにもなりますし、お互いの事を知る
ことができるため、よりチームの結束が深まったと思います。
任せることも大事
自分自身、実家に帰ったり用事が入って作業に参加できない時がありました。その際、メンバーから「先に進めても大丈夫？」と言われましたが
もちろん快諾しました。
私のプロダクトではなく、チームみんなのプロダクトですからね。
もしかしたらメンバーとしては先に進めた後で、私が確認したときに私が
考えていたものと違うものになったらどうしようと思ったのかもしれません。そうはなりませんでしたが、そうなったらそうなっても良いと思っていました。それがみんなで考えた結果であるので、私自身がその結果に合わせようと考えていました。
意図的ではないですが、結果的に任せる形で作業してもらうことになり作業してもらったことで、より当事者意識を持ってもらえたのではないかと思います。結果オーライって感じですね。
責任は一人で背負うのではなく、みんなで分けて持った方が良いです。
使用したツール：gather、vscode、github、docker、figma
使用用途：
gatherで集まって画面の共有等で使用
vscodeを使用してコーディング
githubを使用してファイルの共有等を実施
dockerを使用して作成したlaravelファイルの確認
figmaで作った設計図を見ながら、色々作成
７．プレゼン作成
最後の土日は自分が用事が入って作業ができないため、発表のプレゼン作成
をメンバーに依頼しました。
canvaでスライドを作ってくれており、物凄く良いスライドが出来上がっていてビビりました笑
そのスライドと、その時点での作成途中のプロダクトを使用してプレゼンを
一通りやってみました。
気になった部分を修正することで、更により良いスライドが出来上がったと
思います。
発表前日！
発表前々日まではプロダクト作成に時間を使っていましたが、発表前日は
まるまる発表の修正および練習に当てました。
これは一番最初のスケジュール作成段階でに決めていたことです。
練習する中でスライドを修正したり音を加えたりして、ワイワイしながら
楽しんで練習することが出来たと思います。
使用したツール：canva
使用用途：
発表のプレゼンのスライドを作成。全員で作業できるのでチーム開発の場合はPPTより良いかも
８．チーム開発プロダクト発表当日
発表順は5番目だったので、ドキドキしながら順番を待っていました。
自分のチームのプロダクトに対して自信はありましたが、他のチームの
プロダクトもやっぱり凄かったです。よう3週間で作ったなと、、
自分のチームの番になり、自分のPCの画面を共有して発表したのですが
最初の方で音が鳴る部分があったのに鳴らない！？となって、かなり
テンパりました。(脈拍急上昇)
スタッフさんのフォローがあり、なんとか音が鳴るようになったので
良かったです。最後の最後でミスってしまい、みんなに申し訳なかった(泣)
そんなこんなで少し発表時間をオーバーしてしまいましたが、自身のある
発表ができたと思います。
その時点ではやり切った思いがあったので、頭の中では「ナンバーワンにならなくてもいい、もともと特別なオンリーワーン」ってな感じでSMAPの
「世界に一つだけの花」が流れていました(←本当かぁ？)
結果発表！！
結果は、、、、、2位でした！！よっしゃーー！
高評価を頂くことができて、とても嬉しかったです。それもこれもチームのメンバー、関わってくれた方達のおかげです。本当に感謝です。
メンターさんからの総評としてはスクラムが非常に綺麗で、コミットも非常に綺麗とコメントしていただきました！
ただコミットメッセージはふざけまくっていたので、そこの部分はきちんと指摘をもらいました笑（指摘はあるだろうなとちゃんと思ってました！)
分かりやすく意味のあるメッセージにすることが大事です！
設計の重要さも大事ですが、その設計をチーム全員が理解できてるというところが最も大事ですよねというコメントも頂き、まさにその通りだと感じました。チームのベクトルは常に合っていたと思います。
９．チーム開発を終えて
プレゼンの最後のスライドのコメントで、チームメンバーが「コミュニケーションについてチーム内で意見を出し合い検討して話し合って作業を進めることができました。温かみを持ったアプリを作りたいという思いが一致していたので、アプリをよりよくするためにたくさんの素敵なアイディアが詰まったプロダクトとなりました」とプレゼンを締めてくれました。
確かに出来上がったプロダクトには、メンバーが考案したアイデアが色々な
部分に散りばめられています。
自分一人で作ろうとしていたら、ここまでのクオリティにはできなかった
と思います。色々と一人ではできない経験を積むことができました。
自分は卒制で別のプロダクトを作ろうと考えており、他のメンバーもそれぞれ違うプロダクトを作ろうとしています。
その為このチームでの作業はこれで終了になりますが、このチームで開発を
経験できたことはとても良かったし、とても楽しかったです！！
おわり
この記事が気に入ったらサポートをしてみませんか？