筑波大学のenPiTという授業でアジャイル開発について学びました。
作成したプロダクトやその感想に関してこちらに記載します。
開発したプロダクト：そつたん
筑波大学情報学群情報メディア創生学類生向けの履修支援ツールそつたんです。自分の履修状況を確認しつつ、次の履修を決定することを支援するツールです。
履修要覧に重ねて自分の履修状況が表示されるので、誰が作ったのかわからんクソややこしい履修要覧の理解も高められます。
ソースコード等はこちらからどうぞ
使い方と機能の説明
1. Twinsから成績データを取ってくる
実はTwinsから自身の履修状況のcsvファイルを取ってこれます(意外にもあまり知られていませんでした。)
ホーム→成績→一番下までスクロール→ダウンロード→ファイル形式:csv,文字コード:UTF-8を選択する→出力
でダウンロードできます。詳しい説明はプロダクトをご覧ください。
2.そつたんにアクセス
3.ダウンロードしたcsvファイルをアップロードする
左側の「CSVファイルをアップロード」からcsvファイルをアップロードします。これで前準備は終了です。
4.履修状況を確認する
csvファイルをアップロードすると履修が完了しているところは緑色、履修していないところは黄色で表示されます。(つまり黄色の部分がなくなって一面が緑色になれば卒業できます。)
選択科目の部分は緑か黄色に色のついている部分をマウスでホバーすると現在履修済みor履修中の科目が表示されます。
専門科目と専門基礎科目の選択科目の部分は「科目一覧」ボタンを押すことでそれぞれの欄で取ることのできるすべての科目が表示されます。
詳しい説明に関してはプロダクトに載っていますので筑波大生(メディア創生学類)の方はぜひ使ってみてください！！！
チームに関して
メンバー構成
mikadonec：情報科学類3年(私)
blue031415：情報科学類3年
hiromichi-5：情報メディア創生学類2年 (プロダクトオーナー)
Monburan014：情報メディア創生学類2年 (スクラムマスター)
主にこれからこのプロダクトのユーザになるであろうメ創2年の二人にプロダクトオーナーとスクラムマスターを任せました。
開発の進め方
技術関連
最初は全員技術的に未熟であったので4人で同じコードを見ながら開発を進めていました。途中からは2人ずつの2チームに分かれて開発を進めました。最終的には1人1人が別々の課題を解決するという形で開発を進めました。
全員の知識が満遍なくついていったので良い進め方だったと思います。
コミュニケーション関連
Discordを通じて問題点を共有しました。
また、学年の差異はありましたが、授業の際には全員が疑問に思っていることを口に出せる環境だったと思います。(これ結構重要だと思います。心理的安全性ってやつ？)
プロダクト開発の軌跡
1.初期の案
メンテナンスフリーな卒業要件チェッカーを作ろうとしていました。つまり、履修要覧が更新されたら、何らかのシステムが自動的にチェッカーの情報を更新してくれるようなプロダクトです。
2.ユーザインタビューで得られた意見
ユーザインタビューによって以下の知見を得ました。
- 卒業要件チェッカーは内部構造や自身が今履修している科目がちゃんと計上されているか不透明であるため使っていない(信頼性がない)
- 履修要覧がわかりにくくて履修を組めない人がいる
3.ユーザインタビューを通して
メンテナンスフリーな卒業要件チェッカーは必要とされていないのでは、、、？
→→→見やすさと信頼性があって履修組みを支援できるようなプロダクトを作ろう！！！
4.そつたんを産むまでに
1スプリント1.5時間くらいでレビューのためにユーザ価値を産まなければならないのでキツかったです。
また、ユーザが限られているプロダクトなためユーザ価値を検証するのは苦慮しました。「あなたはメ創生です！」みたいな催眠まがいのこともしました。
毎授業の振り返りであるAMFでは特に授業の終盤n搾りかすみたいな意見しか出てきませんでした。これは反省点です。改善点を見つけられるようにチームの一人一人が注意深くチームを観察するべきだと思いました。(当時は開発でアップアップだったのでなかなか厳しかった、、、)
最終的なAMFも他のチームと比べると少し量が少なかったです。(量が多ければいいということでもありませんが)
個人的な振り返り
プロダクトに関して
良かった点
良いものができたのではないかなと思います。他の卒業要件チェッカーとは違って卒業要覧を見やすくしているという点に差別化ポイントがあります。また、取れていない部分は黄色にハイライトされるのでどこから何の単位を取ればいいか容易にわかります。元来の卒業要件チェッカーにはない価値をユーザに提供できているのではないでしょうか？
悪かった点
プロダクトが対象としている学類がメディア創生学類しかないというのは少し汎用性が低いなと思いました。まあ短い時間で粗製乱雑になるよりかはマシですかね。授業時間も短い中で毎回レビューもしなければならなかったですし
チーム開発に関して
良かった点
和気藹々とできました。別に商品化して売り出すわけではないので、張り詰めた空気の中で良いプロダクトを「作らなければならない」といった状況にならず個人個人を尊重してできたかなと思います。
悪かった点
最後までアジャイルが一体何を表しているのかよくわかりませんでした。
あるひとは思想と言い、あるひとは開発のフレームワークであると言い、またある人はウォータフローへのアンチテーゼと言い、全員微妙にずれていてバラバラでした。
特によくわからなかったことはアジャイルマニフェストです。
「個人と対話」ってどの個人を指していてどの個人を指していないんですか？
「顧客との協調」ってどのレベルまで協調すればいいんですか？等々
これは日本語訳の問題なのかわかりませんが曖昧かつ抽象的でわかりにくいです。AMFが書きにくかったのもこの曖昧さと抽象さが原因です。
一意に定めろとまでは言いませんが、この授業内だけでもある程度定義をしておくことは重要でないかなと思います。
学んだこと
レビューをもらうサイクルの重要性
短いスプリントでユーザから意見をもらうことによってプロダクトを改善できることを学べました。これは今後取り掛かることになるであろう研究にも応用できるなと感じました。
コミュニケーション大事
アジャイル開発がより主流になるにつれ技術力よりもむしろコミュニケーション能力(チームへ素早くフィッティングできる能力)を求められるようになるのではないかと思います。コミュニケーション大事！！！
技術的にすごい≠使われる
これはenPiT発表会のスライドにも載せたことですが、技術的にすごいからといって実際に使われるわけではないこともプロダクトを開発していく中で強く感じました。一昔前のセグウェイなんかもこれに該当するのかな。同時にユーザに意見を聞くことの重要性も学びました。
自分は開発手法みたいな定量的でない話があまり好きではない
これは一番の発見です。こういった抽象的な分野よりも得に数学のような定量的に物事を判断する方が得意なのだなと気づきました。(アジャイルの抽象で曖昧な部分が嫌いなのもこれが原因だと思います。)
いかに良いレビューをもらうか
いかに良いレビューをもらうか、どのレビューを採択するかと言う問題はアジャイルにおける最重要な問題だと考えます。良いレビューをもらうには必然的にどの部分に関してレビューをもらうかといった前準備が重要です。今後の参考
最後に
私は今後おそらく研究職(つまりノットプログラマー)として就職することを考えています。
そんな中、自分の見たことのない世界を見てみたいと言う思いでこのenPiTに参加しました。
実際に参加してみて、自分があまり関わったことのない種類の人々や手法を拝見して興味深かったとともに、プログラマーは自分に向いていないと言う知見を得ることもできました。これは実際にやってみないと満足できない私からしたら大きな経験であり、このような機会をいただけたことを嬉しく思います。
最後に、このような不純な動機でenPiTに参加した私を暖かく迎え入れてくれたチームメンバーに多大なる感謝の念をあらwとともに、レビューやアドバイスをくださったメンター、教員の皆様、および他チームのメンバーの方々にもこの場を借りてお礼を申し上げます。