※この記事は筑波大学にて行われたenPiTの授業の最終レポートである。
enPiTという授業について
今年度は夏季集中授業から秋学期ABCモジュールを通して行われ、およそ半年間受講した。この授業は、チームで一つのプロダクトを開発しながらアジャイル開発を体験して、アジャイルについての理解を深めようという授業である。
チームメンバー
私の所属していたチームは「最後は人海戦術」という名前で活動した。
構成メンバーは以下の通り。
- プロダクトオナー : K. H. (Hiromichi)
- スクラムマスター : S. R. (Monburan014)
- M. B. (B.M.)
- 私 (blue031415)
開発したプロダクト
そつたんについて
そつたんは、筑波大学情報学群情報メディア創成学類22, 23, 24生の履修要覧をわかりやすく表示する履修支援ツールである。
従来の卒業要件チェッカーと異なり、履修支援という観点から開発したプロダクトである。
私たちは、現状の筑波大学が抱える履修の困難さの原因に、卒業要件が複雑かつ大学公式の履修要覧が分かりづらいということが大きく関わっていると考えた。
卒業要件は大学が定めたものであるため、そこを変えることはかなわない。
しかし、履修要覧が分かりづらいという課題については、プロダクトの力で解決できると考えた。
また、筑波大学の情報系の学部には既に有志が開発した卒業要件チェッカーは存在している。でも、それを全員が利用しているわけではない。私たちはその理由を有志の誰かが作成したものを完全に信頼できていないからと考えた。
そこで、私たちのプロダクトは大学公式の履修要覧にオーバーレイして分かりづらさを解消するという方針をとることで、信頼性を保ったまま履修支援をおこなうプロダクトの開発に取り組んだ。
そつたんでできること
- 現在の履修がどのくらい卒業要件を充足しているのか確認できる
- 必修科目はどの科目区分のどの科目を履修すべきか確認できる
- 選択科目は現在どの科目を修得しているのか確認できる
- 専門科目、専門基礎科目の選択科目それぞれ、どの科目を履修したらいいのかを表形式で確認できる
実際の使用方法はプロダクトの説明を確認して欲しい。
説明を読んだだけで使い方を把握できるように説明を書いた。
技術
Webアプリケーションにすることが決まったのでTypeScriptを使用することにした。また、ライブラリとしてReactを使用した。
デプロイ先にはVercelを使用した。
このような簡素な構成にしたのは、テックリードとなるような人がいなかったため学習量を最低限に抑えたかったからである。
そつたんができるまで
夏季集中授業中
プロダクトの方向性の決定
夏季集中授業で私たちのチームは結成された。
メンテナンスフリーの卒業要件チェッカーを作成するという案のもとに私たちが集まって結成された。AIなどを活用し、大学から公表される履修要覧を解析し、履修要覧が更新されるタイミングでチェッカーが自動的に更新されるというものだ。それを全ての学類において実装することで、多くの筑波大学生から長期に渡って使用してもらえるプロダクトが出来ると考えていた。
その後、プロダクトの価値検証のためにユーザーインタビューを行った。
ユーザーインタビューの結果、ある人は履修要覧の情報が多く、次に何を修得すべきかが分かりづらいところに困難を抱えており、別の人は、既存の卒業要件チェッカーはどんな人が作成したのかということや、どのような処理が行われているのかということも不透明ため使用しないと回答してくれた。
このユーザーインタビューの結果からユーザーにとって本当に必要なのは、メンテナンスフリーの卒業要件チェッカーではないのではないかということになった。
また、メンターとの話の中で、卒業要件チェッカーが必要になるのは、履修が分かりづらいことに起因しているのではないか、また、大学公式の履修要覧の情報量が多く見づらいものになってしまうのは履修の仕組みが複雑だからではないかと考えた。
大学が定めた履修を変えることはできない。しかし、履修のわかりづらさを解決するツールであれば開発することができるのではないかという結論になった。
また、始めはターゲットを全学類にしていたが、それでは私たちが価値検証できないということで、S. R.とK. H.も含まれる筑波大学情報学群情報メディア創成学類22, 23, 24生を対象とすることにした。（ちなみに私とM. B.は情報学類所属のためツールが完成しても使用できないが、私たちは４年の必修科目以外既に履修し終えていたので必要性が少ないということで情報メディア創成学類23生の彼らを優先した。）
こうして、そつたんの方向性が決まった。
このとき完成したエレベーターピッチは以下である。
そつたんの開発方針の決定
ここまででどんな方針でプロダクトを開発するのかが決定した。
次は実際にどのようなアプローチで課題解決に取り組み、どのような開発方針でプロダクトを開発するのかを話し合った。
方針として、現在修得済みの単位が確認できないと履修は組めないということになり、まず始めに修得済み・履修済み単位の確認機能を実装することになった。その次の機能としては履修の仮組機能や履修の例を提案してくれる機能などが候補に挙がったが、本当に必要かの検証が出来ていなかったことや時間的、技術的に実現可能かどうかが不明だったことなどを理由に、ある程度単位確認の機能を開発してから再度チームで話し合うことにした。
始めに実装する修得済み・履修済み単位の確認機能について、修得済み単位まで含めたのはこのツールが履修支援を目的としているものだからである。
筑波大学生が履修を組むとき、成績がまだ出ていない科目が存在するのは珍しいことでない。
そういったとき、成績がまだ出ていない科目も修得したものとして考えて次の履修を考えることがほとんどである。
だれも、単位を落としている前提で履修を組んだりしない。
また、去年のenPiTのプロダクトを参考にして、大学公式の履修要覧にcssを当ててオーバーレイをするようという方針に決定したのもこのときである。
こうして開発が始まった。
３回目のロングレビューまで
３回目のロングレビューまでは単位確認の機能の実装にかかった。
修得した・履修中の科目を大学公式の履修要覧にオーバーレイすることで、どこの区分のとの科目とどれだけ履修しているのかが分かるようになった。
思ったよりも時間がかかってしまった。
1回目のロングレビューまではモブプログラミングを取り入れて開発を進めた。
班員全員がReactの知識に乏しく、またフロントエンドの開発自体が初めてというメンバーもいたため最初は全員で相談しながら進めようという話になったのだ。
とはいえ、やはりモブプログラミングでは遅い。
そこで１回目のロングレビュー後、ある程度私たちの理解も深まってきたので、ペアプログラミングに移行した。
ここら辺からかなり作業速度が速くなったと思う。
そして３回目のロングレビューまでに単位認定機能の実装を完成することができた。
この機能において工夫した点は、選択科目や共通科目の基礎科目などのそれぞれの区分にどの科目が該当するのかをホバーイベントにて科目名が分かるようにしたことである。
ここまで実装できた段階で次にどんな機能を解決するかを話し合うことになった。
授業の仮組機能を始めいくつか案が上がったなかから、技術的、時間的に開発できるのか、開発したとして本当に使ってくれるのかという観点から、専門科目、専門基礎科目の選択科目それぞれに該当する科目を一覧で表示するという機能を開発することになった。
このときに、開発した機能を本当に使用してもらえるかということや、私たちの解決したい課題が何かということに戻って議論できたのは非常によかったと思う。
４回目のロングレビューまで
専門科目、専門基礎科目の選択科目それぞれに該当する科目を一覧で表示する機能の開発とこれまでのロングレビューでもらったフィードバックをもとにユーザにとって使いづらい部分の解消に取り組んだ。
このように一覧で今後履修すべき科目を提示することで、ユーザーはどの科目の中から履修すべきかが簡単に把握できるようになった。また科目番号からシラバスにアクセスできることで気になった科目がどんな科目かを簡単に確認できるようにもなった。
最終発表会まで
年が明けた最初の授業でプロダクトオーナーのK. H.が年末に実際にプロダクトを使用して履修を考え、そして使いやすかったという話をしてくれてプロダクトの方向性があってることを確認できたのが良かった。
一覧機能を実装し終えたところで、次は何をするのかという話し合いを行った。新機能を開発する案も上がったが、新機能を開発するよりも、これまでもらったフィードバックのうち残っているものを改善してユーザーの使いやすいプロダクトにする方が、ユーザーにとっての価値が高くなるという結論になった。いくら機能が多くてもユーザーにとって使いにくいプロダクトでは使ってもらえない。
あまり勧められたことではないが、年明けの授業が少ないので最後は残業してもいいやという意見が多くあったため、残業前提で進めることにした。残業より発表会までにしっかりと開発をしたいという意見で一致したからだ。
残業前提であるが、１回分の授業時間を使用してタスクの洗い出し、検討、割り当てをしっかり行い、いついつまでに機能を完成させるというように期限を決めることで、各々が自分のタスクを把握し、必要なだけ自宅で開発するだけで済んだのはよかった。また、タスクの割り当ての段階でしっかり話し合ったことで、他の人のタスクが何でどんな変更をするのかまで全員が把握していたことも上手に開発が進んだ大きな要因だと思う。
ここになって初めてペアプロから個人での開発に移行した。
また、発表資料作成のためのアイデア出しの時間を確保しこれまでのチーム運営やプロダクトについて振り返ることができたことも非常に良かった。
最終発表会
なんと、優秀賞をいただいた。私たちは誰も賞をいただけると思ってなかったのでみんなしてびっくりしていた。
また、他のチームのプロダクトや琉球大学のチームのプロダクトも見ることができたので非常に面白かった。筑波大学の他のチームのプロダクトは定期的にレビューの機会があり、どんなものか大体把握していたが、最終発表会の成果物の完成度の高さには驚いた。また琉球大学のチームのプロダクトは完成度も高かったが、アイデアにも驚かされ非常に面白かった。
そつたんの今後について
履修要覧が変わったタイミングで更新をするいう案も上がっているが、今後どうなるかはその時次第である。
しかし、チームメンバーとは今後も定期的に交流が続きそうである。ハッカソンでるという話も上がっている。
個人の振り返り
この授業の当初の目的はアジャイルという開発手法を学習するというものであった。この点について、正直今回の授業の進め方的に、開発しながら勉強するという方針なのだろう。しかし、アジャイルについての座学はあったものの開発に入るまえの数日のみであった。毎回の授業の冒頭で教師からの話の中でアジャイルについての補足や振り返りもあったものの、実際に開発に入る前の座学だけでは、チーム開発どのように進めるべきか本当にこの進め方がアジャイルとして正しいのかがわからなかった。なので、定期的にもう一度アジャイルについて振り返るまとまった時間が欲しかった。そのため、今回の開発手法がアジャイルとして正しいのか、アジャイル開発とはどんなものなのかということが最後までうやむやなままだった。
それでも、メンターさんや他の受講生と打ち上げの時にこれらのことについて話したなかで私がしっくりしたのは、アジャイル開発というのは書き換え可能な設計書をもつという説明だ。はじめから仕様がかっちり決められているウォーターフォール開発と違ってレビューを受けて柔軟に設計書を書き換えられるのがアジャイル開発というものだ。
この説明を正解とするなら、レビューを受けて修正を行ったり、ユーザーにとって価値があるのか、ユーザーの価値が最大化されるものは何かを考えながら、プロダクトの機能や開発方針を変更しながら開発を進めていったのはアジャイル開発になっていたと思う。
アジャイル開発は変更が多いため、大規模開発よりも小規模開発にむいていると思う。また、ユーザーにとっての価値を検証しながら開発をすすめるため、新しいものを開発するときにむいている手法のようにも思った。
また、今回の授業で個人的に大切だった学びは、技術的に面白いものがユーザーにとって価値あるものではないということである。私たちは始めの方に記載した通り、メンテナンスフリーの卒業要件チェッカーを作成しようとしていた。それは開発する私たちにとって技術的に面白そうであるからである。ところがユーザーにとって開発する側の面白さなんて関係ないく、得られる体験が同じであればなにを使おうと関係ないということをユーザーインタビューを通して分かった。これは少し考えれば当たり前のことであるが開発をしていると忘れることが多い視点であり、これから先も意識していかなければならないことである。非常にいい気付きだと思う。
チーム開発という点では、私たちのチームは非常に上手くいったと思う。４人という人数だからこそ何もしていない人が生まれづらかったし、モブプログラミングをしても全員が一つの画面に入り込めたと思う。また、全員の技術を加味して、モブプログラミングからペアプログラミング、個人でのプログラミングと段階的に移行できたことも、全員の技術力向上とプロダクトの理解に非常に良かったと思う。また、テックリードがいなくメンバーの学年もあまり離れていなかったこともあって、全員がコードを理解し、全員が意見を出して議論しながら進めていくことで全員が当事者意識をもって開発が出来たのもかなり大きな要因であると思う。
また、私たちは夏季休業中に決定したエレベーターピッチを変更することなく開発を進めることができた。つまり、プロダクトの方向性が最初から変わっていないのだ。実装する機能で迷うことがあっても最初に決めた方針に戻って考えることが出来たことも開発をすすめる上で非常に大きかった。
最後に、アジャイル開発で開発を進めてきたことやチーム開発を体験できたことは非常に大きな学びと経験になったので、この授業を履修してよかったと思う。
チームAMF
最後は人海戦術の最終的なチームAMF