はじめに

自分は10月よりAPPRENTICE SHIP(内定直結型エンジニア学習プログラム)のカリキュラムに２期生として参加しています。
今回はその一環としてのチーム開発を行いましたので、記事を作成しております。

開発体制と開発条件

開発体制

今回の人生初チーム開発では、同じくエンジニアを志しているメンバーの中からランダムに選ばれた３名で開発を行いました。
実務未経験ということ以外はほとんど共通点のないメンバーでした。

開発条件

今回の開発テーマは 「自分たちの役に立つもの」
その上で代表的なフレームワークの使用禁止、実装期間は１週間という内容でした。
メンバーとは開発２ヶ月前から顔合わせを行い、週に２度のミーティングを行うという流れで開発が進んでいきました。

自分達は何を作ったか

『VScode shortcut quiz』

VScodeのショートカットをクイズ形式で出すアプリを開発しました。
VScodeを使ってはいるけどショートカットがあまり覚えれていない。もしくはVScodeを触って少し経つ方を対象に作成しました。

ホーム画面
クイズ画面

アンサー画面

このように、ホーム画面ではレベル別にクイズが選べるものとなっており、
レベル別に5問問題が出て、正解の入力をクリックとキーを入力するものとなっています。

作った経緯

VScodeをよく使う上でショートカットがあるのは知っていたが覚えきれていない。
覚えるのはよいけど、いざ使うシュチュエーションで忘れてしまう。
そもそも知らないショートカットが多い。

上記の理由からせっかくならクイズ形式で楽しく覚えようと言うことで作成に至りました。

アーキテクチャ

フロントエンド

webサーバーの構築に『http-server』
バックエンドとのhttp通信に『axios』

バックエンド

アプリケーションサーバーに『WEBrick』
DBとのやりとりに『mysql2』

データベース

データベースは『MySQL8.0』

開発においてのあれこれ

提案フェーズ

ここのフェーズではまず何を作るかの検討を行いました。
各自、作りたいアプリの案を出し合い、議論を進めていきました。

good(良かったこと)

ブレインストーミング形式でアプリのアイデアを出していった。自分でも思いつかない案出たり、案が出せずに沈黙したりなどなく楽しみながら提案ができた。(空気感が良かった。)
各自で一つ代表して自分の案をプレゼンテーションしたので、どう言ったものを作りたいかの共有が出来ていた。

bad(悪かったこと、ダメだったこと)

数を出し過ぎたことで最終的に何を作るかを決めるのに時間が掛かってしまった。
最後に各自で出した案を一つづつ検証したがそこでも譲り合いが発生して時間をかけてしまった。(掛けても良かったが設計、実装とのバランスが悪くなってしまった。)

対策

細かいところまで拾ってしまっていたので具体性の無い案や,実現性が乏しいものは積極的に排除していくこともしていく。
最後に作るものを決めかねて時間を使ってしまったので、そこは積極性を出すべきだったと反省している。

要件定義、設計フェーズ

ここのフェーズから作業を分担して行いました。
自分の作業は主に、環境構築とアーキテクチャ選定を任されました。

good(良かったこと)

「Ruby」「javascrip」「HTML」「CSS」と使用技術と使えるライブラリが絞られていたので技術選定を迷わずに出来た。また、ライブラリでありきで学習をしていたので改めて勉強になった。
環境構築とアーキテクチャ周りの選定の話をブログ記事にてまとめたお陰で、チーム内での共有がスムーズに行えた。またhttp周りの知識にメンバーが触れていなかったので、その説明にも一役買えたのが、良かった。

該当記事
WEBrickについて
https://qiita.com/hirapg_1123/items/4b78e376e042b51d3938
フロントで簡易的なサーバーを建てよう
https://qiita.com/hirapg_1123/items/b80d11eab37c721016b4

bad(悪かったこと、ダメだったこと)

要件定義、設計が採用された案を出したメンバーの範囲ということで、積極的に意見を出さなかった。
実装を初めてから詳細を話し合うと言う流れになってしまい。実装と行ったり来たりになってしまった。
データベースに関しても別メンバーの範囲だったのでコミュニケーション不足からの認識ずれがあった。
メンバーとの環境の差異でライブラリのインストールエラーで時間を割いてしまった。
上記に加えて、dockerでの環境構築も視野に入れていたが、上手くいかずに断念してしまった。

対策

各範囲、コミュニケーションを密に取る
前もってチームメンバーの技術力を共有し、「出来ること」「出来ないこと」をはっきりさせる。
dockerを学習範囲に入れる。(構築をする)

実装フェーズ

ここのフェーズではバックエンドを中心に実装を行いました。

good(良かったこと)

何はともあれ、発表までに動くものを作れた。
当初の予定では縦割り(レイヤーごと)ではなく、横割り(タスクごと)に作業を分割する予定だったが、時間との兼ね合いで縦割り作業へと柔軟に変更できた。

bad(悪かったこと、ダメだったこと)

要件定義、設計がかなりふわふわした状態で走り出してしまった。それが要因で、細かいところのすり合わせができておらす、処理の内容で認識がズレていた。
予め、バックエンドとフロントエンドのリクエストとレスポンス値を明確に定めていなかったので、作り切るまで値が確定せず、フロントとの同時作業に遅れが出てしまった。
最終的に前日は夜通し作業になってしまった。。。
時間的に余裕がなく、可読性の低いコードになってしまった。また、コメントアウトをあまり書き残せなかった。

改善案

処理の流れが他メンバーがイメージしきれていなかったので、そこは設計段階でしっかり共有する。
時間に余裕がなかったので、バッファを考えてガントチャートなどを使い進捗を確認をする。

次のチーム開発でやりたいこと。

今回はフレームワーク使用禁止という条件での開発だったので、あらためてRailsを触ってありがたさを感じました。。。
ですが、基本的な動きを一から考えてアプリを作成できるいい機会だったと思います。
特にサーバー周りはフレームワーク任せだったので動きを理解するいい機会でした。

次回はフレームワークを用いてのチーム開発があるので、今回の改善点を踏まえてアプリの開発を行いたいです。