0から1へ: プログラミング初心者が感じたチーム開発体験
はじめに
はじめまして！アプレンティスシップ2期生のかじ(@cncnkitsune)です。
アプレンティスの詳細についてはこちら
このたび、アプレンティスのカリキュラムの一環で初めてのチーム開発を行ったので、
開発の背景や、得た知見などをお伝えできればと思います。
初学者が企業での業務という形以外でチーム開発を行うのは、そこそこ珍しい体験な気がするので
誰かの参考になれば幸いです！
ちなみに開発のテーマは、『自分たちの役に立つものを開発せよ』 でした。
縛りとして、HTML/CSS/JavaScript/MySQL/Rubyのみを使用し、フレームワーク(Rails,React)の使用は禁止。
ローカル上で動くようにして、発表会で5分間でプレゼンを行います。
自己紹介
現在25歳です。
20歳頃からプロゲーマーとして４年ほど生計をたててきました。2022年の夏頃に所謂、普通の社会人に興味を持ちプロゲーマーを辞めました。
そこから約1年、ITヘルプデスクとして社会人経験を積み、業務内容がルーティン化＋より高度な技術を身に着けたいと思い退職し、エンジニアを目指し始めました。
2023年の8月頃から独学をはじめ、10月半ばよりアプレンティスシップに参加
→11月からチーム開発スタート...といった経緯になります。
私に限っていうと、学習期間は三ヶ月。開発期間は約一ヶ月です。
（ただしアプレンティスの他のカリキュラムと並行して開発を行ったので、注力できた時間はもっと少ないです）
開発アプリの紹介
スケジュール調整アプリ 「スケミ」
サービス概要
スケミはスケジュール調整を、「軽く、早く、簡単に」という想いから作成したアプリです。
クリック・ドラッグで予定をスマートに登録できます
全員分のスケジュールが一致した部分はハイライトされます
開発背景
アプレンティスシップでは、チームごとに週に2回のチーム会を行ってカリキュラムの情報共有や、チーム開発を進めるルールがあります。
私達のチームもスケジュール調整をしていたのですが、メンバーの予定がバラバラでテキスト上だと中々日時を決められませんでした。
スケジュール調整のため、ネットでツールやアプリを探しました。◯oogleカレンダー,◯整さん...etc。
見ていくと意外に調整まで僅かながらハードルがあるな、と気づきます。
例えば、ログインが必要だったり、詳細を入力しないと使えなかったり、メンバーを追加しないといけなかったり。
業務で使用する上では、それぐらいカッチリしていた方が良いと思います。
ですが、プライベートでの予定調整では、
「もっとカジュアルに使えるほうがいいんじゃないか？」
と私は思いました。
それなら、と上記の問題を解決したシンプルなスケジュール調整アプリを作成しよう！とチームで話し合い、開発が決まりました。コンセプトもこの段階で自然と決まった感じです。
画面遷移図
初期段階でイメージを固めるために画面遷移図を作成しました。
最初は3ページを予定していましたが、開発に着手していくと、期日までに完成させられない雰囲気が漂ってきました。
そこで、まずは完成を第一に考えた結果、作成ページはボツにしました。
具体的なスケジュールの表示のさせ方、登録の仕方のUIイメージはいくつか頭の中にあったものを他所から拝借して共有しました。
テーブル設計
ユーザーと日時を紐づけるだけのシンプルな設計です。
一人のユーザーがたくさんのスケジュール（日時）を持つので、一対多の関係ですね。
工夫したポイント
- カレンダー上のセルをクリック・ドラッグすることでスケジュール登録できる
- 一覧ページで直感的に空きスケジュールを把握できる
この2点は仕様を考える初期段階でアイデアとして出て、コア部分として実装したいとチームで話していました。どちらもUXにダイレクトに影響すると思ったからです。
当時は、「セルから取得って私達でできるかな・・・」、「JSからRubyに渡してDBに・・・？」と不安だらけだったのを覚えています。
結果として、どちらも実装することができ、満足しています・・・！
開発するうえで遭遇した問題（重要度順）
・タスクの工数の見積もりの甘さ。実現可or実現不可かの検証
今回の場合、セルを選択して日時情報をDBに保存 というタスクがあったのですが、
これをタスク表にそのまま 「日時情報をDBに保存」 と記載しました。
当時のメンバーにはそもそもDBに保存する処理のイメージができている人がおらず、なんとなく出来るだろう。の状態でタスクに突っ込まれていました。
振り返るとシステムの根幹に関わる部分なので、ある程度の工数の共通認識は持っておくべきだったと思います。
単純なフォームを用意してユーザーを入力し、DBに保存する...といった検証を最初に行って、実現の可否を判断すると共に、大まかな工数の算出が出来ればよいと思いました。
そしてタスクの洗い出しの段階で、上記のようなタスクの見通しが見えないものに関しては、「検証」と称して見積もりを出すためのタスクをねじ込めると土台がしっかりしそうです。
・業務分担のやり方
チームメンバーのNさんがフロント部分を担当し、私はバックエンド部分を担当することに決めました。
ある程度、フロントの枠組みをNさんが作成してくれた後にpullして、開発に取り掛かります。
まずは入力フォームの名前を取得し、DBに保存する処理を考えます。
フロント部分にはJavaScriptの処理が記載されていて、そのとき気が付きました。
役割分担が成立していない・・・と。
フロント側にRubyに値を渡す処理を記述する必要があり、そのため１からフロントのコードを理解する必要がありました。（少なくとも私には！）
分担するメリットが薄いどころか、読んで理解する手間を考えると１からコードを書いたほうが早そう...と直感的に思いました。（学習的にはとても良いですが）
今だからわかるのですが、エンドポイントをデータの受け渡しの境界として利用し、作業を分担すると良いそうです。
それか、フロント担当はデータ部分に関与せずガワの部分だけ作成し、ほかはバックエンドに投げる...とか。
アプリを完成させた経験を持ち、データの受け渡しのイメージがある人じゃないと上記の発想に至らないので
今回こうなったのは必然というか、当たり前の結果だと思います。
こういった部分に疑問を感じて、分担方法を知れたりと本当にチーム開発のメリットは大きいです。
・ルール作り（Git、コーディング）
決まったルールでプルリクエストを送る、ブランチを切る等、一切していなかったため
プルリクの上にプルリクが無数に溜まったり、そもそも独自に開発しすぎてコンフリクトを起こしまくったりとGit周りでずっとひぃひぃ言ってた気がします・・・。
またコーディングに関してもインデント、シングルコーテションorダブルコーテーション、その他記述方法を
擦り合わせていなかったので、様々な記述が入り乱れてしまいました。
改善策としては、責任をもってルールを作る人を最初にたて、基準となるドキュメントを簡易的に作成できる良いかなと思います。
良かったポイント
・形にできた
一番はこれにつきます。メンバー4人ともが、ほぼ初アプリ開発＆初チーム開発の手探り状態のなか、何はともあれ形にして発表できる状態まで漕ぎ着けたこと。
正直言いますと発表の一週間前まではコア部分であるセルのデータ格納、データ取得が一切できていない状態で、
「これ本当に完成するのか・・・？」
とずっと不安な状態でした。笑
が最終的にはちゃんと動く形で発表できたので本当に良かったです。メンバー様々です・・・！
・奥せずチャレンジできた
今回、チームの中で時間の自由が一番あったのが私ということもあり、工数の大きい部分を受け持つようにしました。
出来るか分からないけど、とりあえずやってみようの精神で下記のことを成し遂げることができました。
・Dockerの導入
開発環境の話し合いをしていたときに、Dockerを導入することになり、初期セットアップを担当しました。Dockerfile, Docker-compose.ymlの記述の仕方など手探りながらも起動させることができ、嬉しかったです。
appコンテナとDBコンテナをcompose upで立ち上げたときに何度記述を確認してもエラーを吐く場面に遭遇しました。
結果としては、DBコンテナの初期セットアップが完了する前にapp側がDBを読み込もうとして失敗していたようでした。app側にsleepを与えることで無事解決したのですが、Chat-GPTに聞いても、うんともすんともで、最終的に技術記事に助けていただいたのは良い思い出です。
・バックエンドのコア部分を開発
- カレンダーのセルから日時情報を取得し、DBに格納
- 一覧ページでは全員分を表示
等のバックエンド開発を行いました。
期限が迫る中、分からない事だらけの実装は精神的にきつかったです。
Rails縛りがあるので、調べても大体のことはRailsで行えます！みたいなアンサーばかりでキレそうでした。
Chat-GPTにコードを提出してもらう → コードの意味を聞く → 自分なりにいじくる のループで地道に開発していきました。Chat-GPTのある時代で良かったです・・・・。
（このときにGPTがない時代にエンジニアになった方々に多大なリスペクトを覚えました）
ここでひたすらコードを読んだおかげか、今Railsチュートリアルに取り組んでいるのですが7章くらいまでサクサクと進めております。Railsの偉大さにも感動・・・・。
ここで粘れた経験は今後自分を助けてくれるものになると思っています。
プレゼンの準備をしっかりできた
もともとプロゲーマーの頃に配信活動、Youtube活動を行っていたのもあり、人前で話すことに苦手意識はありませんでした。（緊張はめちゃくちゃしますが）
ただカッチリした場＋プレゼンといった形式は人生で経験したことがなかったので、せっかくの機会ということもあり、プレゼン担当に立候補することにしました。
アプリがほぼ完成してからはひたすらプレゼン練習をやりました。
メンバーが作成してくれたプレゼンスライドの確認と文字起こしを行って、台本と合わない部分のスライドを視聴者がパッと見て頭に入りやすように改修しました。
具体的に言うと、文字数が多すぎる部分はカットし、口語とスライドの文字が大きくかけ離れないようにしたり、、です。
あとは録音して、通しで喋ってみる → 聞きづらい部分を、そもそもの台本が悪いか、話し方が悪いかで分け、修正 のループを20~30回程度行いました。
同時に時間も計測するようにし、5分間のプレゼンだったので大体4分半を目安に終えるように練習しました。
発表会はZoomだったので、事前にZoomの環境をチェックしてマイク、画面共有、映り具合等も事前に確認しました。ここら辺は配信の知識が活きた場面かなと思います笑
その甲斐あって、当日はスムーズに発表に臨むことができました。
まだまだ改善点はありますが、準備をすれば最低限納得できるクオリティの発表ができそう、と自信を持つことができました。
結果
発表会では、
・生徒同士で票を入れ合うBest Student Award
・メンターの方が票を入れるBest Award
があったのですが、そのうちの一つであるBest Student Awardを頂くことができました。（全7チーム）
Best Awardを取っていたチームはTwitter、Open AIのAPIを組み込んでアプリを作成していて
シンプルに強いなぁと思いました。UIも素晴らしかったです。
他のチームの作品も良い刺激になりまくりでした・・・。
終わりに、今後について
チーム開発を経て、複数人で創造することの難しさを知りました。
イメージの擦り合わせ、コミニュケーション、役割分担、GitHubの扱い、など一人で開発するだけでは身につかない多くのことを学ぶことができたので、苦しかったですがやってよかったなと思います。
（チームメンバーの方、本当にありがとうございます）
今後、アプレンティスのカリキュラムではRails,React,APIと学習していき、またチーム開発を行う予定があります。今回の反省を活かすとともに、前提となる技術力をしっかり学びチームに貢献できればと思います！
ここまで読んでいただきありがとうございました。少しでも参考になれば幸いです。
最後に、Twitterもやっているので良ければフォローいただけると嬉しいです！
同じようなモチベーションで学習している方がいればめちゃくちゃ繋がりたいです・・・！！
Discussion