2023年度筑波大学でenPiTに参加し、アジャイル開発を学びました。
この記事はenPiTの振り返りレポートです。
はじめに
enPiTとは
enPiTとは、ビッグデータ・AI/セキュリティ/組み込みシステム/ビジネスシステムデザインの4分野における高度IT人材の育成を目指している文部科学省のプログラムです。(公式サイト)
私が参加したビジネスシステムデザイン分野(BizSysD)では、アジャイル開発やスクラムなどを学ぶことができます。
なぜ参加したの？
私は現在大学院生なのですが、学部生の時もenPiTに参加していました。今回のenPiTは二回目になります。学部の時はWebアプリケーションの開発に興味があり、enPiTに参加しました。今回参加した理由は、もう一度アジャイル開発を学び直したかったというのもありますが、シンプルに学部の時のenPiTが楽しかったからです。
チームメンバー
5人のチームでアジャイル開発を行いました。メンバー構成はこんな感じです。
- Y.K.：プロダクトオーナー。プロダクトの方向性やレビューに責任を持ってくれました。
- H.M.：(新)スクラムマスター。チーム全体をうまく誘導してくれました。
- T.H.：(旧)スクラムマスター。言いにくいことも言ってくれました。
- M.H.：クリティカルな意見をくれました。
- T.K.：自分。主にプロダクト開発してました。
あと一人、夏までのメンバーがいました。
ここからは開発したプロダクトと開発プロセスについて振り返っていきます。
春〜夏
前期の振り返りを簡単に。
前期はアジャイル開発やスクラムの基礎知識や、開発技術の勉強をする期間でした。前期の最後に6日間の夏合宿があり、メンバーの困り事を持ち寄ってプロダクト開発を行いました。私たちのチームは、「お天気コンパス」というプロダクトを開発しました。"天気の確認をせず、外出後痛い目を見てしまう"という課題を解決するスマートフォンアプリです。
夏の開発は、デモの見せ方に苦労しました。実際の天気は操作できないので、プロダクトが提供する価値を実際に体験してもらうことができませんでした。体験を想像してもらうだけでもある程度のフィードバックは受けられましたが、本質的なフィードバックはあまり得られなかった印象があります。
秋
秋から新メンバーとして、T.H.が参加してくれました。
また、夏からのテーマは継続せず、「雑談が苦手」を新たなテーマとしました。
開発したプロダクト
私たちのチームは「e-talk support」というWebアプリを開発しました。
EVP
[e-talk support]は
[雑談が苦手だという課題]を解決したい
[オンラインで会話する人]向けのWebアプリ です。
これは
[事前に話題の種を共有すること]によって、
[ネタ切れすることなく安心して会話に望めます]。
ここから、このプロダクト開発のプロセスについて書いていきます。
Sprint1
Sprint1では主に困り事の特定と、深堀を行いました。メンバーそれぞれが抱える困り事を共有し、その中で共感の多いものを解決したい困り事として決定しました。最初は「雑談が下手」という漠然とした困り事でしたが、なぜ雑談が下手なのか、なぜ雑談が下手と感じるのか、どんな場面でそう感じるのか、メンバーの体験をもとに困り事の深堀を行いました。
また、この時期は困り事の深掘りや解決策の方向性を確認するためのフィードバックを集めていました。プロダクト開発が進んでいなかったので、モックを作成してプロダクトのイメージを掴んでもらったのは良かったと思っています。フィードバックを多く集めるためにどうすれば良いか考え、改善していったのも良かったです。私たちのチームの場合は、オープンクエスチョンだけでなく、選択肢を提示すると多くのフィードバックを集められました。ただ、回答が制限される側面もあるので、フィードバックの集め方は常に意識する必要があると感じました。
sprint2
Sprint2からは本格的なプロダクトの開発が始まりました。この頃特に苦労したことは、スプリントゴールの未達が多かったことです。原因としては、(1)レビュー準備に時間を取られすぎた、(2)コスト推定が甘かったことだと考えています。
(1)
毎回レビューの前に15分程度時間を取り、メンバー全員でレビューの目的や流れについて話し合っていました。しかし、全員の時間をとる割には一人当たりのレビューに対する貢献度が低く、結果として開発に時間を当てられませんでした。そこで、レビュー担当を独立して用意することにしました。レビュー担当が叩き台を準備→他メンバーが確認という流れにすることで、開発の時間を確保することができました。責任が明確になったことで、レビューの質も向上したように思います。
(2)
コスト推定が甘かったのは、技術力不足に原因があったと思っています。ある機能の実装に対するコストを推定するには、ある程度技術を知っていないと難しいと感じました。特に最初期は開発経験がないので、メンターさんにコストの相談をすべきだったと反省しています。あとは、コストを感覚的なものではなく定量的に考えられるようにすると、推定の精度を効率よく上げられたかもしれません。
また、Sprint2のロングレビューから、実践的なレビューを意識しました。
実際にDiscordで雑談会を開催し、オンライン懇親会の主催者/参加者としてリアルな体験をしてもらうことで、本質的にユーザーが求めているものを検証していきました。
sprint3
Sprint3からメンバーの役割を明確にしました。これまでの開発で、カンバンを上手く利用できなかったり、開発とスクラムマスターの両立が難しかったり、さまざまな問題が出てきました。そこで、メンバーの得意を活かせるように、スクラムマスターの変更や責任の明確化を行いました。結果として、新しいスクラムマスターがカンバンを改善、開発効率の向上、楽しい開発など、開発プロセスの大幅な改善に繋がりました。
sprint4
Sprint4では主に最終発表に向けてUIの向上やバグの改善を行い、プロダクトの品質向上に努めました。Sprint3で役割を明確にしたことで、上手くチームが回っていたと思います。ただ、自分の役割だけに集中しすぎてしまう場面もあったので、個人の時間とチームの時間のバランスをとることが大事にすべきだと学びました。休憩時間前後などいき的に進捗を共有する時間を作るのも良かったかもしれません。
全体を振り返って
ここまでの話から特に印象深い学びをいくつかピックアップしました。
役割分担
役割を分担して各メンバーの得意を活かせるようにしたことが開発効率と質の向上に大きく貢献していたと思います。最初はメンバーの適正が(本人含め)分からないので、モブプロやペアプロを取り入れたり、全員でレビュー準備をしていました。しかし、段々と適正が分かってくると、得意分野に集中した方が上手くチームが回っていきました。それぞれの得意を掛け合わさった結果だと思います。メンバー全員がチーム内での役割と貢献を理解することを今後も意識していきます。
実践的レビューを通した価値検証
実践的レビューから多くのフィードバックが得られました。ユーザーに体験を想像してもらうのではなく、リアルに体験してもらうことで、プロダクトの方向性を確認できたり、意外な改善点を見つけたりすることができました。アジャイル開発において、レビューが重要な位置付けにあることを理解できたのではないかと思います。フィードバックの聞き方やデモの進め方など、レビューの質を上げる改善点はまだまだあるので、レビュー自体をアジャイルしていくこと重要だと感じています。
チームによって特色がある
ピックアップしたものではありませんが、振り返るとチームによって開発プロセスや価値観に大きな違いがあるなと感じています。例えば、私たちのチームではモブプロは序盤でやめてしまったのですが、他チームでは後半も取り入れていました。私が学部時代に参加していたチームでは、ペアプロを取り入れていた記憶があります。このように、チームによって最適解は大きく変わるものだと思いました。今回のチームで上手くいったことも、違うチームでは上手くいかないこともあると思います。チームで多くの施策を打ちながら、経験的にそのチームにとっての最適解を見つけていくことが重要だと感じています。
enPiT@函館みらい大(2024/3/5追記)
2024年の2月、分野別ワークショップに参画している大学の交流会に私たちのチームが参加したので、そこでの学びを追記します。
フィードバックはテキストだけじゃない
「レビュワーが言語化したフィードバックだけでなく、体験中のユーザーの様子そのものがフィードバックになる」ということです。プロダクトを使用しているユーザーの様子を観察することで、どの画面で使い方に迷いが生じていた/使われない(気づかれない)機能がある/想定外の使い方をしている、といった非言語のフィードバックを得ることができます。
体験に基づくフィードバックは質が高い
プロダクトの一部分の機能だけに注目したフィードバックよりも、体験の中でその機能がどうなのかという視点のフィードバックの方がプロダクトの改善につながります。このボタンの色は赤と青どちらが良いか？というものではなく、プロダクトを実際に使用し、その体験の中でボタンの色は赤が良いというフィードバックが得られると、よりユーザー視点のプロダクトを開発できます。
enPiTあるあるかもしれませんが、フィードバックを多く集めるためにアンケート形式でレビューをしてしまいがちです。アンケート形式だとフィードバックは多く得られますが、質の高いフィードバックは得られにくいので、注意が必要だと感じました。
ユーザー視点でプロダクトを開発する時は、体験を点ではなく線で捉えることが重要だと学びました。
タスク分割を怠らない
技術力の差がある状態でどのように開発を進めるのか、という課題はenPiTの期間中考えていたことでした。私たちのチームでは役割分担を行うことで開発効率を高めていましたが、あるチームのアプローチが非常に勉強になりました。そのチームでは、タスク分割をかなり細かく行っていたそうです。そして、技術力に自信がない人でも取り掛かれそうなタスクを作っていました。結果的に、全員が開発に貢献することができ、全体の効率も高まったそうです。正直タスク分割を怠っていた部分があるので、この点は非常に良い学びでした。