はじめに
この記事は筑波大学のenPiTという授業の最終レポートです。
enPiTという授業はアジャイル開発の手法でのチーム開発を学ぶ授業です。
この記事では
- enPiTを通して体験したこと
- enPiTを通して起こったこと
- enPiTを通して学んだこと
について紹介します。
開発したプロダクトについて
enPiTでは春学期と夏合宿、秋学期に分かれてスケジュールが組まれています。
春学期ではアジャイル開発の手法について学び、
夏合宿や秋学期で実際にプロダクトを開発するための技術を自習します。
その後6日間でプロダクトを作成する夏合宿と3ヶ月弱でプロダクトを作成する秋学期にて、
実際にチーム開発を行いながらアジャイル開発を学びます。
私は夏合宿と秋学期で合計2つのプロダクトを作成しました。
それぞれについて紹介させていただきます。
メシレコ
まず夏合宿の際に作成したプロダクトの「メシレコ」について紹介します。
プロダクトの紹介
以下が「メシレコ」の説明になります。
メシレコは
外に食べに行くときに行く場所の候補先が決まらない課題を解決したい
特に食べたいものが無かったり、どんなお店があるか分からなかったりする人向けの
グルメレコメンドアプリです。
これはユーザーの条件に沿ったおすすめのお店を１つずつ提案することによって、
食べログやGoogle Mapとは違った
TikTokのようなレコメンドスタイルで、案出しにかかる時間を劇的に短縮し、
スムーズでストレスフリーなご飯決めを実現できます。
- 画像
- こちらからアクセスできます。https://meshireco.netlify.app/
経験したこと（プロセスベース）
まずチームメンバーのほとんどが利用経験のない技術を用いて
全員で開発することを経験しました。
メシレコでは、
カードをスワイプする良いライブラリが存在するという理由で
Reactというフレームワークを選択しました。
一方、チームメンバー5人のうち私だけがReactを触ったことがある状態で、
開発に支障をきたす懸念がありました。
そのため最初はモブプログラミングを利用してフレームワークの使い方を共有することをこころがけました。
実際にコードを書く役割（ドライバー）を使用経験が無い人が行うことで、
わからないところが無いまま進まないように取り組みました。
また全員がコードに触れれる状態にすることが目的であったため、
最小限のコードで必要最低限の知識を共有することをこころがけました。
上記の工夫と優秀なチームメンバーに恵まれ、わずか１日でチームメンバーだけで自走できる状態になることができました。
実際にスワイプする機能は使用経験がないメンバーのみで実装することができました。
またスプリントゴールの定め方も適切に定めることができました。
夏合宿では１スプリントを１日(8:40 ~ 18:00)で回しており,
各スプリントゴールは以下のようになっていました。
| スプリント | スプリントゴール |
|---|---|
| 1日目 | スワイプで次のお店が出てくるようになりました！ |
| 2日目 | 筑波大生お昼休み版リリース！！ より詳しいお店情報を確認できるようになりました！ スワイプ操作が行いやすくなりました |
| 3日目 | スマホでの表示に対応した |
| 4日目 | UI超パワーアップ！！ ・見た目がかわいくなりました ・地図や詳細情報を参照しやすくなりました ・定休日などが表示されるようになりました ・お店カードがなくなった後に再表示できるようになりました スマホ対応版リリース！！ 現在地から近いお店が出てくるようになりました！！ |
スプリントゴールを明確かつ最小に定めたことにより, チームメンバーの認識をそろえて開発することができました。そのため各スプリントレビューにおいて動いているプロダクトを触ってもらいながらコメントを貰うことができました。
また機能を最低限に絞ってレビューをもらうこと、プロダクトのエレベータピッチを明確にすることにもこだわりました。そしてスワイプした方向でジャンルを絞るやレビューで多く寄せられたブックマーク機能をこのプロダクトの趣旨に沿わないとして実装しない判断を下すことができました。
そういった取り組みにより最小限のコードで開発することを行え、限られた期間の開発にしては実用的な状態まで開発仕切ることができたと考えています。
実際に以下のような嬉しいコメントをもらうことができました。
- ちょ、これ普段使いしたい、すごい（地図やホットペッパーに飛べるし、価格帯あるし、ジャンルや営業時間もあるのが素晴らしい）
- これは、日常でも使えるし、土日使いたい・・・！（と思ったけど、外出れないんだった；；）
- これ、すごくない？完成度高くて、びっくりしてるんだけど
- これリクルートに持ち込みませんか
- ホスト可能なら、そのままにしておいてくれると使いたい！スマホホーム画面に追加しました
青い栞
次に秋学期で作成したプロダクトの「青い栞」について紹介します。
私はこの開発でプロダクトオーナーとして関わりました。
プロダクトの紹介
以下が「青い栞」の説明になります。
[青い栞] は
[旅行計画をイチから考えるのがめんどくさい]を解決したい
[旅行に行きたいがツアーで縛られたくない、でも自分であちこち調べるのは嫌だというわがままさん]向けの
[旅の栞提案アプリ] です。
これは [旅の骨組みを提案しそれをカスタマイズすること] によって、
[旅行会社のツアーや比較サイト、Visit A City] とは違って
[イチから計画を考える負担を減らしつつ、自由度の高い旅行計画の作成]
を実現できます。
-
画像
-
こちらからアクセスできます。https://aoi-shiori.netlify.app/
経験したこと（プロセスベース）
青い栞の開発ではプロダクトの大幅な方針変更を経験しました。
旅行の案だしに関する困りごとを解決することを目標に、最初は以下の説明のようなプロダクト「レジャレコ」を開発していました。
[レジャレコ] は
[外出先でふとできた空き時間をどうやって潰せばよいかわからない問題]を解決したい
[旅行などの外出が多い大学生グループ]向けの
[スポットレコメンドアプリ] です。
これは [ユーザの条件に沿ったおすすめの場所を1つずつ提案すること] によって、
[Instagramの地図検索やGoogle Map] とは違って
[TikTokのようなレコメンドスタイルで、案出しにかかる時間を劇的に短縮し、スムーズでストレスフリーに空き時間の活用法を決めること]
を実現できます。
しかし、レビューでも不評であり、チームメンバー・プロダクトオーナーとしてもこのプロダクトで課題が解決できると感じるようになりました。その後方針転換を行い、現在の「青い栞」の開発に移りました。
この方針転換はよい判断だったと振り返っています。
まず私自身プロダクトオーナーとして課題を解決できそうな雰囲気を感じれるようになりました。またチームメンバー全員が開発しているプロダクトである青い栞を好きになりました。そして何より、このプロダクトがenPiTのチームの中で最優秀賞を取ることができたことも良い判断だったという理由の裏付けになっています。
なぜこの方針転換がうまくいったのかについて、いま振り返る中で以下の3つのポイントがあったと思います。
- 課題を見失わなかった
- チームメンバーそれぞれが思うことを話せた
- 競合・先行者の事例から学べた
まず元の課題である「旅行の案だしが面倒くさい」という点に立ち返り、どういった点が面倒くさいか3つのケースに分析しました。
その上で、転換前のプロダクト「レジャレコ」では採用しなかった残り2つの課題にフォーカスしたプロダクトにしようと決めました。
またメンバーそれぞれが考えていることを話し合うことができました。
チームとしてこの授業に何を求めているかや授業での開発を行うのかどうかといった、プロダクトのゴールに限らずに話し合いを行いました。
また話した内容が多岐に渡たり話し合いの脱線が危惧されたため、プロダクトオーナー・スクラムマスターが自発的に議事録を書きながらすすめました。
そのことでチーム・プロダクトとしての目標が明確になり、開発がスムーズにすすむようになったと考えています。
取り組む課題について明確になったものの、選択した「旅行計画を自動で提案する」という課題については解決策や先行事例が複数ありました。例えば旅行計画を立てるのが面倒くさいという課題については旅行サイトやパッケージツアー・個人のブログなどが該当します。さらに旅行計画を自動で立てるという点においてもAIを活用したアプリなどが昔存在していました。そこで、「なぜ既存の解決策では解決しきれないと感じるのか」「なぜ先行事例はその後撤退・普及しなかったのか」について考えました。すると「旅行計画のたたき台を提案されつつも、そのたたき台のまま旅行するのではなくカスタマイズしたい」という新たな課題が見えてきました。このように競合・先行者の事例から学び分析することで、プロダクトの価値をより明確にすることができました。
またチームで開発に取り組むにあたって様々な工夫を行うことで、雰囲気よくチーム開発を行うことができました。
私達のチームには感謝チャンネルというDiscordのチャンネルがあり、誰かが発表したり取り組んだ際に「感謝」というスタンプを送る文化があります。もともとは「感謝」と言うのが口癖だった私をネタにして作った冗談のチャンネルでしたが、このチャンネルによりチームメンバーそれぞれが貢献しているという意識が高まったと感じています。
また開発する中でチームメンバーが発したいい言葉を名言として残す文化もあります。
こちらはただ面白半分で行っていたことですが、チームの雰囲気の形成に貢献したと思います。
雰囲気の良いチームであったため、開発プロセスの変更を積極的に試すことができました。
例えばレビューを行う際にプロダクトの紹介を省略することでコメントを貰う時間を増やそうと試したりしました。
結果としてはプロダクトの紹介を省略することで帰ってプロダクトに対する理解が浅くなり、良いフィードバックが得られにくいといった学びを得ることができました。
またenPiTではチーム全員でモブプログラミングを行い休憩を同時に取ることが主流でした。
一方私達のチームは試行錯誤を重ね、個別に休憩をとる「分散型休憩システム」や4人チームを2人ずつのグループに分けてペアプログラミングを行う方式をとるなど、チームにあった開発手法をとることができました。
さらにグラデーション投票(下記の図)という他のチームが行っていた取り組みを取り入れるなど、他のチームの知見を生かしていけたことも特徴的でした。
最後に
- enPiTを通して学んだことを活かしていきたい的なことを書く
- 具体的に書く
1年間のenPiTの授業を通して、課題を解決するプロダクトをチームで作る上で以下の2つが大事だと感じました。
- 明確なゴール
- チームメンバー1人1人の尊重
明確なゴールを定めることで、チームとしてもプロダクトとしてもスプリントゴールにしてもよりアウトプットに対する解像度が上がることを経験しました。また最初から明確なゴールを定めていくことが難しいからこそ小さくゴールを定めてフィードバックを繰り返していくことが重要だと考えています。
またチームメンバーそれぞれを尊重することはチーム開発において重要であったと考えます。チームメンバーを尊重するからこそ有意義な話し合いができ、チームメンバーそれぞれを信頼しているからこそ分業することができたと思います。欠席した際などに情報共有を忘れないこともチームメンバーの尊重につながっていたと思います。今回私たちはチームメンバーそれぞれを信頼できたため、新しいライブラリの導入といった小さくしづらいがスプリント内で達成できるか難しいゴールに対しても、チームとして複数のアプローチそ行うことができました。その結果、実装に対する負担を軽減しながら心理的安全性を保ちつつ開発を進めることができました。属人化は防ぎつつメンバーの強みは生かしていけたこともチームメンバーの尊重につながっていったと思います。
今回得られたこの２つの学び、そして何より価値のあるプロダクトを楽しく開発することができた経験を、今後の仕事・研究などに活かしていきたいと思います。
結びにenPiTでお世話になった教員の先生方、メンターの方々、他のチームの方々、そして何よりチームメンバーのえふじ・えびちゃん・ぬたひろばに尽きない感謝をしつつ、最終レポートとさせていただきます。