お疲れ様です。sukeです。
この記事は2022年度の筑波大学のenPiTという授業でチーム開発をした時の個人レポートです。
授業の流れ
春学期(4~7月)
- 自己学習
- チーム開発のための準備
- アジャイル、スクラムについて学ぶ
- チームで解決したい困りごとについて理解を深める
- チーム開発①(1週間)
秋学期(10~1月)
- チーム開発②(週2回、各3時間で3ヶ月)
春学期
自分について
1. 技術力について
- 4月
- GitHubの使い方もよく知らない
- 7月
- GitHubはぼちぼち
- Reactで簡単な家計簿を作成
- Vueで宝探しゲームを作成(ハッカソンに参加)
2. 得意なこと
- アイデアだし
- 意見を出す、まとめる
チーム開発①
7月に1週間かけて参加したチーム開発
制作したプロダクト
プロダクト名 : BUBBLE
EVP
[BUBBLE] は
[SNS上の情報の多様性（投稿の種類）を調べるのに時間がかかること]を解決したい
[SNSで情報を集める人]向けの
[Webアプリケーション] です。
これは [ワードクラウド] によって、
[タイムラインやトレンド] とは違って
[素早く全体像を把握すること] を実現できます。
アプリの概要
上記の画像のように、自分が知りたいキーワードを入力すると、そのキーワードに関するツイートに含まれる単語について、よく発言されているものをワードクラウドの形で出力し、ワードクラウド内の単語をクリックすることでその単語が含まれているツイートの内容を確認することができる。
開発チームについて
- メンバー構成
- PO: A.Sさん
- プロダクトの方向性を決定づける困りごとの提案者, デザインや裏方
- ScM: R.Mさん
- スクラムマスターとしてチームを支えるほか、積極的に意見を出していく
- suke(筆者)
- 意見, アイデア出し
- S.Cさん
- 方向性の修正や議論の集約
- TKさん
- 質問役, タスクの明確化
開発を通して学んだこと
このチーム開発①の段階では、アジャイルもスクラムも具体的にどのようなものかわかっていませんでした。もちろん開発がスタートする前には講義等でそれらの内容について説明を受けてはいたのですが、覚えの悪い私には定着しておらず、また実際にアジャイル開発どころか個人での開発すら経験のなかった私にとっては本当に全てが手探りの状態でした。さらに、私自身だけでなくチーム全体として見ても技術力が高いとは口が裂けても言えなかったので、チーム開発①については「良いプロダクトを作るためのアジャイル開発」ではなく「アジャイル開発のためのプロダクト作り」と考えて、主に1.全体の流れの把握, 2.心理的安全性, 3.「価値」基準のプロダクト作りに注力しました。
ただし前提として、このチーム開発①に関してはチームメンバー全員が元々ある程度親交がありました。それゆえに会話に困るということは特になく、スタートの段階から心理的安全性がある程度担保されていました。そのため、2については他の場面にも使えるような学びはあまり得られていないと思われます。1の全体の流れの把握に関しては、PBLやスプリントの回し方、レビューのもらい方等についてある程度把握できたと思います。3については、チーム開発①が終了した段階では達成できたと感じていたのですが、チーム開発②を終えた今となっては、全くと言っていいほどできていなかったと実感します。というのも、「自分で良いと思うもの」と「顧客が本当に欲しいと思うもの」の振り分けがまだまだ甘かったと思うことと、時間を言い訳に価値基準ではないPBLの切り方をしていたからです。
結論としては春学期学んだことは全体の流れの把握くらいなものであったと思います。
ここから読めばOK
秋学期
チーム開発②
10月から1月にかけて、週2回(各3時間)のチーム開発
制作したプロダクト
プロダクト名 : 青い栞
EVP
[青い栞] は
[旅行計画をゼロから考えるのがめんどくさい]を解決したい
[旅行に行きたいがツアーで縛られたくない、でも自分であちこち調べるのは嫌だというわがままさん(グループ)]向けの
[旅の栞提案アプリ] です。
これは [提案された旅の予定をカスタマイズすること] によって、
[旅行会社のツアーや比較サイト、Visit A City] とは違って
[ゼロから計画を考える負担を減らしつつ、自由度の高い旅行計画の作成]
を実現できます。
↓実際のアプリ画面
アプリの概要
観光スポットの情報が載っているカードをプランの中にドラッグ&ドロップしたり、逆に追加候補に落とすなどすることによって旅程を自由に、簡単にカスタマイズすることができるようになっています。また、プランが更新されるたびにスポット間の距離と移動時間が表示され、左の地図のスポットの場所にピンが刺さるようになっています。
開発チームについて
- メンバー構成
- PO: ものけさん
- テックリーダー, 意見アイデア出し
- ScM: えふじさん
- 時間の管理, miroのチームボードの整理, 意見の集約
- suke(筆者)
- 意見, アイデア出し
- ぬたひろばさん
- 鋭い意見出し, レビュー時等の発表
自分が意識していたこと
秋学期の開発では、春と違いほとんど話したこともない人たちとのチームでした。そのため、心理的安全性については特に意識していました。私は話し過ぎてしまうという欠点があるので、人の話を聞くということを常に意識しながら参加しました。まあ当たり前のことなんですが、なかなか苦手で...。さらに、価値基準での開発の2点に注力しました。鯔のつまり春と同じことをしているわけですが、先に言ってしまうと秋に関してはこの２つに関して多くの学びがあったと思います。
プロダクトとチームの軌跡
Sprint 1/4
EVPを考えるところから始まりました。当初は「レジャレコ」と言う別のアプリケーションの開発を考えており、旅行の行き先を提案してくれると言うものでした。ただ、これは春学期にこのチームの前身となるチームが作っていた「メシレコ」と言う飲食店提案アプリのジャンル違いといったものでした。これはメシレコがとても良いサービスであったことからある種の思考停止によって作ることが決まったものです。この段階では、私以外の3人が春学期にチームであったことなどもあり、活発な意見交換というよりは少し遠慮気味な状態でした。実際振り返りにも'遠慮しがち'というものがあります。
Sprint 2/4
このスプリントではチームにとって大きな転機が訪れました。プロダクトを作り直すことにしたのです。それもEVPの段階から。先ほども話した通り、レジャレコは思考停止による産物であることに気づき、ユーザが本当に必要としている価値はどこにあるのかという点から絞り直すことにしました。それによって生まれたのが「青い栞」です。その時の議事録の一部を載せておきます。
この段階で、プロダクトの価値とチームとしてこの授業で一番重視したいことの2つが定まりました。捨てるものと拾うものの選択が可能になったことが今後の開発に大きな影響を与えたと感じます。
EVP(再掲)
[青い栞] は
[旅行計画をゼロから考えるのがめんどくさい]を解決したい
[旅行に行きたいがツアーで縛られたくない、でも自分であちこち調べるのは嫌だというわがままさん(グループ)]向けの
[旅の栞提案アプリ] です。
これは [提案された旅の予定をカスタマイズすること] によって、
[旅行会社のツアーや比較サイト、Visit A City] とは違って
[ゼロから計画を考える負担を減らしつつ、自由度の高い旅行計画の作成]
を実現できます。
チームとしてこの授業で重視したいことの優先度
- アジャイルを学ぶ
- 良いプロダクト完成させる
ちなみに、この2つは必要十分条件の関係にあることに最後に気がつきます。
Sprint 3/4
このスプリントでは動く負債が生まれ、苦しめられました。ドラッグ&ドロップを実装する上で、ライブラリのロジックをしっかりと理解せずに使っていたことが仇になり、バグの対応にたびたび時間を取られることになりました。しかし、そのことが逆にチームの学びの機会を与えてくれました。スプリント毎に行われるレビューを無駄にしないために、機能実装が進まない中でもユーザが求める価値を絞り込むための方法を模索しました。その結果、実際の機能の雰囲気だけがわかれば良いレビュー内容が得られることがわかり、最小限の実装で価値検証をする方法を考えられるようになったのです。例えばスポット間の移動時間に関して、本来であれば車や電車での所要時間が必要となるところを緯度と経度から徒歩でのおおよその時間を算出して提示するようにしました。この圧倒的に簡単になった実装でも、ユーザには実際に使用した時の雰囲気が伝わりさまざまな意見をもらうことができます。なぜなら、アプリケーション自体に新規的価値はあるものの、その個々の機能自体はユーザが必ずどこかで目にしたことがあるため、勝手に補完してくれるからです。
Sprint 4/4
このスプリントでは、実際の機能の開発とレビューのための簡易的な機能の開発の2つのアプローチを同時に進めるという取り組みが生まれました。これによって、効率と保険の２つを得ることができました。簡易実装での価値検証だけしていてもプロダクトは完成に近づきません。また、4人という少ない人数で実装する機能を分散すると技術力不足も相まってかえって非効率であることから、モブプロ、ペアプロで全員で1つの機能の実装を進めていたのですが、それだとマンパワーをフルに発揮することができていませんでした。そこで、同一の機能について、レビューをもらうための簡易実装と本実装の２つにチームを分けることによって効率の問題と本実装がうまくいかなかった時でもレビューをもらえる状態にできました。ここでのミソは、簡易実装はほぼ間違いなく時間内に終わるように考えることでした。
チームで工夫した取り組み
- 感謝チャンネル
- Discord上で雑に感謝のスタンプを送るチャンネル
- PRごとのデプロイ
- Netlifyを用いてPRごとに自動でデプロイされるシステムを構築
- 分散型休憩システム
- チーム全体で休憩するのではなく、作業チーム単位でキリが良いタイミングで休憩を取ることで、効率化を図る
- 分業と共有
- これは特別なことではないが、Sprint4でも触れた通り分業の仕方と属人化しないための共有の徹底
- 名言集
- miro上でその日にあった名言を赤い付箋で残した
- (例：アジャイルのための開発ではなく開発のためのアジャイル, プランニング時にレビューをセッティング、聞きたいことがない→それ今回すべきスプリントじゃないのかも)
- 振り返り手法のカスタマイズ
- 授業で提示されたスプリントの振り返り方法にチーム独自の方法を付け加えた
- レビューのための開発
- 欲しいFBの内容が思いつかない機能の開発は今やるべき開発ではない。このレビューが欲しいから、この機能を開発しようという順番
学んだことのまとめ(ここだけ読んでもいい)
良いプロダクトを作るために必要なことは、
- ユーザに提供できる価値基準で開発すること
- 良いチームで開発すること
ユーザに提供できる価値基準で開発するには、
- レビューからFBを得て、それを反映させていくこと
- ユーザのスコープを絞り、プロダクトに必要なFBを見極めること
良いチームで開発するには、
- 心理的安全性を確保すること
心理的安全性を確保するには、
- 互いの長所を見つけること
- タスクをなるべく均等に振り分けること
- 会話に適度に遊びを入れること
- 人の話を最後まで聞くようにすること
- 技術力がある人、発言力がある人が自分はできる側の人間であることを自覚し、全部自分でやるという選択を取らないこと
引け目を感じると、人は自分の意見を言うことができなくなると思います。少ない人数でのチーム開発において、1人の意見が得られないと言うことはプロダクトの方向性の決定に大きな負の影響を与えます。それゆえに、心理的安全性の確保は一番大切であると感じました。