はじめに
この記事は、筑波大学で開講されたenPiTの個人レポート記事です。
enPiTは、身近な困りごとを解決するプロダクトを、同じ困りごとを解決したいと共感した人たちとチームを組んで開発するプロジェクトです。詳しくはこちらのページに載っています。(アクセスしてみたら更新されていませんでしたが......)
様々な大学で同名の講義が展開されているみたいですが、筑波大学では9月に夏合宿として7日間の集中講義と、10月以降の秋学期での通常講義を合わせて、約半年の間同じチームでプロダクト開発に取り組みます。
私たちのチームでは、筑波大学情報メディア創成学類の学生の履修を支援する「そつたん」というプロダクトを制作しました。
開発の軌跡
チーム編成
夏合宿では、困りごとベースで編成されたチームで、学外のアジャイルコーチの指導をもとにプロダクトのユーザー価値などを検証しながら、スクラム形式でプロダクト開発を進めます。スクラムを用いたアジャイル開発は、夏合宿以降の授業でも継続して行いました。
同じ困り事をもつ仲間として集まったチームは、mastのB2が2人とcoinsのB3が2人の4人チームになりました。以下にメンバーのリストを載せます。
- Monburan014 (私/スクラムマスター)
- hiromichi-5 (mast B2/プロダクトオーナー)
- mikadonec (coins B3)
- blue031415 (coins B3)
スクラムにおける役割については、今回のプロダクトで対象とするユーザーを情報メディア創成学類のB2・B3に絞って開発を進めることにしたため、mastの2人でPO/ScMをしました。
最初に考案したプロダクト
私たちのチームが共感していた困り事は、「メンテナンスフリーな卒業要件チェッカーがほしい」というものでした。
筑波大学の卒業に必要な単位要件は、正直わかりにくい学類が多いです。特に今回のプロダクトを作る過程で他の学部の履修要覧を確認しましたが、理解が難しいと感じる学類が多かったです。
さらに、卒業要件を満たしているか確認するツールは学校からほとんど提供されません。情報学群に限っては、有志が制作した非公式のツールが存在します。しかし、個人制作なので製作者の学年向けにのみ公開されることが多く、卒業要件が改定されると利用できなくなります。
そこで、冒頭の困りごとに戻るわけです。今現在成長中のAIなどを駆使すれば、改定された卒業要覧の表を読みこみ、自動で卒業要件チェッカーが生成されるツールを作ることができるでしょう。これが実現できれば、履修漏れをなくすことができ、履修にかかる時間も短縮できると考えました。
しかし、その考えは覆されました。
プロダクト開発を始める前にユーザーインタビューを行う機会がありました。インタビューで意見を聞く中で、所属する学類に卒業要件チェッカーがあるにも関わらず、それを利用しない人がいることがわかりました。
利用しない理由として挙げられたものの一つが、ツールの信頼性でした。有志が制作したツールは、その情報が正しいということを保障することができません。チェッカー上では卒業要件を満たしていると表示されても、判定の過程は示されないため判定内容が正しいのかどうかが不明です。
また、卒業要件チェッカーの利用ケースは、先に履修を決定し、その履修に誤りがないかを確かめるという場合が多いでしょう。それで誤った履修をそのまま登録することは防げますが、そもそも履修を誤らないように支援できる方が良いでしょう。
つまり、卒業要件チェッカーの制作だけでは、履修要覧の理解しにくさに由来する問題の本質的な解消にはならないと考えました。
この過程で、技術的に面白いことが、ユーザーが欲しい機能に直結しないということを学びました。
最終的なプロダクトの姿
信頼性を高く保ち、履修要覧を理解しやすくするようなツールが開発できれば、前述のような問題を解決することができると考え、最終的に「そつたん」の開発につながりました。
要件として、以下の2点をクリアしたいと考えて開発を進めました。
- 大学公式の資料である履修要覧に修得状況をオーバーレイすることで信頼性を保つ
- 履修要覧において見る必要がある部分を色付けたり吹き出しをつけ、理解しやすくする
夏合宿の開発期間では、まずは一部の科目で履修状況に合わせてオーバーレイできる仕組みづくりに取り組みました。
秋学期の開発
開発方針が定まり、秋学期以降もスプリントを回しながら開発を進めました。
メンバー全員が今回使用する言語がバリバリ書けるというわけではなかったので、最初は4人で1つの画面を見ながらコードを書き、慣れていくにつれてLiveShareを用いたペアプログラミングに移行し、最終的にはGitHub Projectsを活用したIssue単位での1人ずつのコーディングができていました。
プロダクト方針の改善
この授業でのスプリントは、最初にその日のスプリントゴールを決めた後、100分ほどの開発時間を経て、最後に必ずレビューを行います。そのため、100分の開発時間の中でレビューで見せられるような成果を見える形にする必要がありました。
最初はこのレビューをうまく活用することはできていませんでしたが、約4スプリントごとに行われるロングレビューにおいて、事前準備の甲斐があり有用な意見を多数もらえました。この経験をもとに、レビューでもらいたい意見をもとにスプリントゴールを定め、レビューでは事前にチームで合意をとり聞きたいことをしっかり定め、もらった意見を反映することでどんどんユーザー価値を高める好循環につなげることができました。
最終的にできたプロダクト
レビューによってもらった意見から、表示形式などを変更することはありましたが、前述の2つの要件は変更することなく、最終的な姿に落ち着きました。
使い方・特徴
使い方や特徴については、プロダクトのヘッダー部分にとても簡潔にまとまっているので、こちらを参照してください。本当にいいデザインだと思います。
信頼性のために履修要覧にオーバーレイしていることと、履修要覧を理解しやすいように表示を工夫していることが大きな特徴だと思います。
個人的な振り返り
チームについて
当たり前ですが、チームメンバーのバックグラウンドはそれぞれ結構違ったので、プロダクトについての議論だけでなく雑談でも、自分にはない視点から見たアイデアが出てくることが、かなり面白かったです。
それぞれ学年も1つ差で、もとから友達だったかのように話しながら開発を進めることができました。打ち上げも盛り上がりました！！
また、ユーザー価値を意識することの大切さをチーム全体で共有できるようになってからは、プロダクトの方針の議論においても、アジャイル的な進め方を一貫することができたと思います。例えば、最終的なプロダクトには選択科目の候補を表形式で一覧表示できる機能を実装しましたが、その前には「時間割形式で選択科目を選択し、時間割の仮組みができる機能を作る」という案がありました。
しかし、ユーザーインタビューで「時間割形式じゃなくて表の方がいい」という意見があったことを踏まえて議論した際に、「インタラクティブな部分を増やすことが、本当にユーザー価値に繋がるのか」ということを前提に議論を進めることができ、最終的には表形式にする方がユーザーにとって良いだろうということで実装しました。
後から振り返ってみると、最初にチームで経験した「自動生成が根本的な解決策じゃない」という結論に近く、技術的に面白いことが、ユーザーが欲しい機能に直結しないという学びをしっかり活かせた場面だったと思います。
プロダクトについて
かなり納得のいくプロダクトが制作できました。自分自身、来年度の履修を組む過程で絶対に利用します。スプリント後半において、「ユーザーに使われるものを作る」という意識を持って制作することができたため、今後mastの新B2/B3の人たちに利用してもらえたら嬉しいです。
アジャイル開発について
初めてアジャイルという言葉から聞いたのですが、確かに短期でのプロダクト開発にはバッチリな手法であると認識することができました。ただ、自分たちのチームが今回の開発サイクルを十分に活用できていたかは微妙なところがあったのかなと思います。
チームAMFについても他のチームに比べ付箋の数が少なく、振り返りが不十分だったのかもしれません。ただ、AMFに書いた反省点を踏まえて開発に活かしていけた部分も多かったので、チーム開発としてはかなり上手くできたと思います。
おわりに
今までのものづくりの経験は、自分が欲しいか、特定の人から頼まれたプロダクトを1人で作ったことしかありませんでした。今回みたいに、対象とするユーザーを定め、そのユーザーに対する価値を検証し、チームで短期の開発に取り組む、という経験は卒業後に社会で関わることになる開発現場の流れに近く、とても良い経験になりました。
enPiTに携わる教員やメンターの方、そしてチームメンバーの3人に、この場を借りて感謝を申し上げます。ありがとうございました！