enPiT個人振り返り

この記事は先日参加したenPiTにて、
2020年10月から2021年1月にかけてアジャイル開発を行った振り返りです。

そもそもenPiTとは

enPiTとは文部科学省の推進する以下のようなプロジェクトです。

「成長分野を支える情報技術人材の育成拠点の形成(enPiT)」は、4分野における高度IT人材の育成を目指しています。大学・企業界の協力体制のもとで推進されるリアリティの高い講義や演習など、特色あるプログラムを通じて実社会においてイノベーションを起こすことができる人材を輩出します。
(https://www.enpit.jp/ より引用)

今回私が参加したのは分野はビジネスシステムデザイン分野であり、以下のようなことを目的としています。他にもビッグデータ分野などが存在しますが、詳しくはホームページをご覧ください。

enPiTビジネスシステムデザイン分野(通称:BizSysD)は、社会やビジネスニーズに対する
実用的なソリューションとしてのビジネスアプリケーションやシステムデザインを
自ら提案、開発し、顧客の潜在的要求を満たすことのできる人材育成を目指します。
(https://bizsysd.enpit.jp/ より引用)

開発したプロダクト

今回開発したのは、「Bookstore Walking」という名前のプロダクトです。
これは、本屋を散歩するのが好きな人向けのオンライン書店です。
大量の本を俯瞰することによって、ユーザ情報に基づき本を推薦するサービスとは違って、
本との偶然的な出会いを実現できます。

リーンキャンバス

使い方

本の表示には表紙モードと背表紙モードの2つがあります。

流れ

まず表示されている本をクリックすると、本の詳細情報が表示されます。
気に入れば楽天の外部リンクから購入するという流れです。

機能

表紙モード
- 本の表紙一覧が表示されます
- 新書などの本の種類によって大きさが違います
無限スクロール
- サイトの一番下にスクロールをすると本が追加されていきます
背表紙モード
- タイトルのみを本の背表紙に見立てて表示します
- 出版社ごとに色が違います
本の詳細
- 楽天などの外部リンクに飛んで、本の購入ができます
- メージをめくるエフェクトで概要を読めます
- 縦読みに変更もできます
ジャンル絞り込み
- 新書や文庫など本の種類で絞り込めます

開発における自分の主な役割

私はバックエンドの開発を担当しました。
バックエンド担当は2人で、もう1人は主にデータ収集のAPIをやってもらい、
私はDBの設定や技術選定などを主に行いました。
具体的な作業としては

バックエンドの技術選定
- サーバーサイドで何を使うか
- DBをどうするか
DBの設定
- Firestoreの設定
- サイトのデータ動的化（ハードコーディングしてた）
本番環境の設定
- herokuの設定
- GitHubからの自動デプロイ設定
GitHub運用ルールの提案
- ブランチの切り方
- プルリクのマージ方法

などです。
あとは話し合いの時にすこし声が大きい人でした。（これよくね！とか無責任に言ってた）

各スプリントのふりかえり

私達のチームは大学院生しかいないため、ミーティングが不定期だったので、リリース単位で振り返りをします。

リリース0回目

やったこと

モックを作り、紙芝居のようにして作りたいものをチームで共有し、それを発表しました。

チームメンバーが何かで作ってくれました。
素晴らしい完成度。

起こったこと、学んだこと

まず本屋で本を見るような体験ってなんだというところから始まり、
どんな機能を作ればいいか議論しました。
それぞれが本屋の何がいいかを語り合い、親交を深めました。
いきなりコーディングを行わず、しっかりと議論したのは正解でした。
作りたいものの可視化を行ったことで、
何を作っていけばいいのかがはっきりしました。

リリース1回目

やったこと

書籍データをハードコーディングし、本の表紙一覧を表示しました。
herokuにデプロイしました。

起こったこと、学んだこと

学部生チームと違い、頻繁に集まれないため開発方法を模索しました。
各々のタスクを明確化し、次のミーティングまでにそれをこなしてくるという方法を取りました。
タスクを明確化することでさぼれなくなり、辛かったです。
みんなちゃんとやってくるのはさすがでした。

リリース2回目

やったこと

表紙の大きさを本の種類ごとに変更しました。
背表紙モードを追加しました。

起こったこと、学んだこと

議論した結果、この規模なら無理してサーバーサイドで何かやらなくてもいいのではないかとなりました。
フロント側で完結させ、DBはAPIを叩くような方針に決めました。
開発規模に合わせて適切な技術選定を行うだけで、開発工数がぐっと減るのだな改めて感じました。

リリース3回目

やったこと

ジャンルの絞り機能を追加しました。
背表紙の色を出版社ごとに変えました。

起こったこと、学んだこと

データのAPIの規約が何やらややこしいぞとなりました。
規約をちゃんと読むことの大切さを学びました。

そろそろデータを動的かしないとまずいと焦りを感じています。

リリース4回目

やったこと

ついにデータの動的化。
本の詳細ページから外部リンク（購入ページ）へ飛べるようになりました。
また、本をめくるエフェクトも追加しました。

起こったこと、学んだこと

動的化を行うのは、やはり連携が難しかったです。
フロント側にデータの処理方法を変えてもらったり、
データ収集した人にデータの格納方法を変えてもらったりと
自分の詰めのあまさが出てしまいました。
前もってちゃんと言っておくべきでした。。。すみません。

チームメンバーについて

k-yonezu
- 私。前述の通り
- ミーティングにたまにいないことがある
enteru
- フロント側担当の人
- 同研究室の頼れる相棒
- まかせたタスクはきっちり期限通りにこなしてくる
- コミュニケーションコストがとても低くみんなとすぐ仲良くなる
- たまにいないことがある
sghirg
- フロント側担当の人
- 最後にページをめくるエフェクトを実装した天才
- 無口なタイプだけど、しっかりとするどい意見をくれる
- たまにいないことがある
masaya-YAMADA
- データAPI担当の人
- プロダクトオーナー
- 彼がいなかったらこのプロダクトは始まりもしなかった
- プレゼン、発表が天才的にうまい
- みんながやりたがらないことを率先してやってくれる
- たまにいない（しっかり連絡してくれる）
kotaYkw
- フロント側担当の人
- Vue経験者
- 技術力がとても高い
- フロント側の人のまとめ役
- 問題発生時になんとかしてくれる人
- 大体いる
yjunya
- 幻のメンバー
- 知らぬ間にいなくなっていた

期間を通した個人的振り返り

一番はチームメンバーにとても恵まれたなと思いました。
以前は自分で実装した方が速い！とイキっていましたが、
みんな私より優秀でタスクを振れば完璧にこなして、
最終的にはみんなでやったほうが自分がやるより全然速いなと思いしました。
逆にそこに甘えてしまう部分があり、最後に詰めの甘さが露呈したのはまずかったので、
しっかりと課題として受け止めたいです。

それぞれが責任感をもって開発を行っていたからこそ、
今回のように不定期ミーティングでもうまくいったと考えています。
そのようなチームメンバーと一緒に開発できたことは、とても貴重な経験です。
また教師陣の方、メンターの方、その他サポートしてくださったすべての方のおかげで
チーム開発、アジャイル開発をとても楽しく学べて最高でした。

追記

今回の記事は後期開発分の記事で、前期にも夏合宿において開発を行いました。
それについては機会があれば記事にしたいと思います。
開発したのはyoutubeチャンネル間の関係をネットワークグラフによって可視化し、
おすすめのチャンネルを推薦するプロダクトです。