この記事はFUN Advent Calendar 2021 Part1の22日目の記事です。
21日目はぺるき君の記事でした。入学前からこんなに高度なエンジニアリングをしているなんて素晴らしい…自分が入学した時はプログラミングのプの字も知らない凡人だったので尊敬します。未来大の未来は明るいですね！
はじめに
こんにちは、きーちゃん(@E_oxypetalum_7)と申します。
Sound Createという音楽制作サークルで部長やってたり、12/5のあとりあくんの記事に書かれている「RALAF」のコントリビューターなんかもやってたり、いろんなとこにちょこちょこ首を突っ込んでる人です。
かなり久々の投稿になりますが、今回は未来大の目玉カリキュラムの一つである「プロジェクト学習」について書いていきたいと思います。
一つ断っておきますと、自分自身この一年間で得たことが多く、様々な心情や知見を書きたい気持ちがあるのでかなりの長文記事になってしまうかもしれません。要所要所かいつまんで見ることをオススメします。
プロジェクト学習とは
弊大では、PBL(Project-Based Learning)科目として「システム科学情報実習」が全コースの3年生必修科目にあり、俗称でプロジェクト学習と呼ばれています。PBLとは和訳では「問題解決型学習」となり、「答えが複数あるオープンな課題に対して、自ら仮説を立てて検証、解決を試みる中で学ぶ」という学習方法です。また、弊学のプロジェクト学習のシラバスには前述のような内容に加えて、「成果を内外に発表し、大学および地域社会に貢献する」という目標も掲げられています。公立大学らしい地域還元の姿勢ですね。また、弊大には学部1年生から院生までの志望者が参加することができる「高度ICT演習」もありますが、こちらもプロジェクト学習になります。
所属プロジェクト紹介
さて、3年生になった自分が実際に所属したのは「使ってもらって学ぶフィールド思考システム2021」(通称：すうぃふと2021)でした。このプロジェクトは、フィールドワークを通して抽出した地域課題やニーズを元に、それを解決・改善するシステムを開発することを理念に置いています。課題・ニーズをシステムに昇華する上流から、実際に実装してユーザに届けるまでの下流までの工程を網羅的に経験することができるのがこのプロジェクトの特徴だと思います。
今年のすうぃふとプロジェクトは解決または改善するフィールドでさらにチームに分かれ、地域の災害問題をテーマとした「地域×災害チーム」、高齢者をITで支援することをテーマとした「高齢者支援チーム」、シビックテック(自治体と市民がITを用いて地域の問題を解決すること)をテーマとした「シビックテックチーム」に分かれて活動しました。その中でも、自分は「地域×災害チーム」に所属しました。
地域×災害チームが開発したのは、児童が楽しく学べる防災学習レクリエーションゲーム「DID IT」です。このプロダクトは、「函館市の防災意識を向上させたい」というヒアリングから得たニーズを元に、小学生の防災意識へのアプローチをすることで、児童を通して親御さんの世代まで波及的な防災意識の向上を狙う目的で生み出されました。「DID IT」では児童たちが専用のアプリケーションを用いて、小学校中に配置された防災に関するゲームを解きながらゴールを目指し、楽しみながら防災学習をすることができます。また、このプロダクトは函館市立えさん小学校さんの協力を得て、開発の監修と、実地試験の施行をして頂きました。実地試験では児童が自分達のプロダクトを使いながら防災学習を楽しむ様子を見られることができてとても嬉しかったです。
また、お陰様でHAKODATEアカデミックリンク2021という函館市内の8高等教育機関が各々の研究成果を発表する交流会にて、DID ITは審査員特別賞を頂くことができました！
まさか在学中に自分が学長表彰を頂くことができるようになるなど思ってもいなかったのでとても嬉しかったです。DID ITプロジェクトはまだ今後の展望を残していますので、これを励みに頑張って行きたいです。
さて自分語りも程々(?)に、ここからは自分がプロジェクト学習の中で得た気付きや学びについて書いていきたいと思います。
僕とプロジェクトとスクラム
弊プロジェクトのもう一つの特徴として、アジャイル開発手法の一つであるスクラムを採用したことが挙げられます。「アジャイルってなんぞ」「スクラムってなんぞ」という方も居ると思うので簡単に説明してみたいと思います。
まず、アジャイル開発とは従来型の重厚な開発プロセスの問題を解決するために軽量なやり方を模索したエンジニア達が、各々が根底に持っている共通点に合意してアジャイルソフトウェア開発宣言を示したことから始まる、特定の理念に則った開発手法を包括して言ったものになります。
アジャイルマニフェストには、
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
という四つの価値が掲げられており、アジャイル開発に属する手法はこの精神に則って作られています。
そして、スクラムというのは、アジャイルのマインドに則った開発手法フレームワークの一つです。つまりスクラム ⊂ アジャイルです。スクラムは以下の要素から成り立ちます。
スクラムチーム
スクラムを実践するチームを「スクラムチーム」といいます。スクラムチームはスクラムを行う本人であるという自覚を用ち、それぞれのロールが持つ説明責任を果たす必要があります。
プロダクトオーナー
プロダクトオーナーはプロダクトの価値を最大化することに責任を持つロールです。
プロダクトオーナーは後述のプロダクトバックログという作成物について責任を持っていて、自分達が作るプロダクトの真の価値はどこにあるのかを見極めて、チームのプロダクトに関するビジョンの中心となることが求められます。
スクラムマスター
スクラムマスターは**スクラムチームがスクラムのフレームワークを理解し、チームが自ずとスクラムを実践できるようになる(=自己組織化)**ことに責任を持ちます。
スクラムマスターはスクラムの実践の為に、チームへの支援やスクラムの障害となるものの排除をすることが必要になります。
開発者
開発者はスクラムの中で実際に成果物を作る張本人になります。ユニークなロールとはなっていませんが、開発者がスクラムをよく理解し、フレームワークに上手く順応してくれることもスクラムのキーポイントになります。
スプリントとイベント
スクラムでは、「スプリント」と呼ばれる小さな期間を設けて、その中で計画、実装、リリースを行い、スプリントを反復して重ねていくことで成果物を形作っていきます。1スプリントのプロセスは4つの「イベント」という活動から成り立ちます。
スプリントプランニング
スプリントプランニングはスプリントの冒頭に行われ、後述のプロダクトバックログに基づいて、該当スプリントで実現する項目(スプリントゴール)を定め、具体的なタスクへ落とし込んでスプリント期間での実装に移れる状態を作り出すミーティングです。
デイリースクラム
デイリースクラムは毎日行われる短時間ミーティングで、スクラムチームがスプリントゴールに向けて適切に向かえているか、各メンバーのタスクに障害は発生していないかを確認する取り組みです。
スプリントレビュー
スプリントレビューはスプリントで作られた成果物を関係者にデモし、フィードバックを得る機会です。ここで得たフィードバックは後にプロダクトバックログへと反映され(バックログリファインメント)、プロダクトをユーザがより求める物へ近づけます。スプリントレビューにはスクラムチームだけでなく、実際に使ってもらう対象や、プロダクトの依頼主、関連分野の有識者などの利害関係者(=ステークホルダー)を招待します。
スプリントレトロスペクティブ
スプリントレビューがある意味「プロダクトに対するふりかえり」であるのに対し、スプリントレトロスペクティブは「開発プロセスに対するふりかえり」になります。スプリントレトロスペクティブはスクラムチームで開発プロセスをふりかえり、開発で起きた問題や不明点を次スプリントで改善できるように方策を立てる取り組みです。多くの場合は「KPTM」などのふりかえりフレームワークを用いて行います。
作成物
スクラムのプロセスを進める中では、3つの作成物が出来上がることになります。
プロダクトバックログ
プロダクトバックログは、そのプロダクトで実現したいことを優先度順に並べたリストになります。このリストはスクラムのプロセスの中で常に更新され続け、プロダクトの価値を司る柱になります。
スプリントバックログ
スプリントバックログは、該当のスプリントで実現するプロダクトバックログ項目を含む、それを実現する為に行うタスクのリストです。このリストはバックログ実現の為の受け入れ要件が明確になっており、開発者が直ぐに取り組めるようになっている必要があります。
これらの要素からスクラムは成り立っています。文字で長々と説明されても中々頭に入って来ないと思いますので、なんとなく雰囲気を掴めるような図を作ってみました。(これもプロジェクト中の成果物)
タイトルにもありますが、自分はプロジェクトではスクラムマスターのロールを担当しました。理由としては、プロジェクト学習よりも先に3年次から入っていた高度ICT演習にてスクラムのついて明るい先輩に出会い、一足先ににスクラムの学習をしていたこと、そして自身も学習の中でスクラムについて興味が湧いていたことが挙げられます。自分は当初正直言ってあまり突出した技術スタックのある人間では無かったので、「アジャイル/スクラム」という武器を増やしてくれた高度ICT演習と先輩方には本当に感謝しています。
スクラム体験記
続いて、僕がスクラムマスターというロールの元、プロジェクトを通してスクラムをやった上で感じたり学んだことについてさらに書いていきたいと思います。(結構話題が右往左往します)
スクラムをPBLでやるのは茨の道である
いきなり突拍子もない事を言いますが、自分がプロジェクトを通してスクラムをやった上での今現在の意見として「スクラムをPBLの中で忠実に行う事はかなり厳しい」という結論を出しています。まず理由の一つとして、スクラムにはスプリントを遂行する為の沢山のイベントがあります。しかしカリキュラム上でプロジェクト学習に配当されている時間は週に4時限分(2時限分×2日)です。スクラムのフレームワークを忠実にこなすのであれば、デイリースクラムは当然プロジェクト時間外に行わなければなりませんし、本活動時間は1週間スプリントの場合スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブでほとんど消えてしまいます。開発が佳境に入ると自分の時間をほぼ完全に犠牲にしてプロダクトへ注ぎ込むような毎日を送っていました。社会に出たことがない半人前がいう事ではないかもしれませんが、このフレームワークはプロダクトの開発にメインリソースを割くことができる社会人エンジニアの為に設計されていて、学業がメインの学生が片手間に扱えるフレームワークではないのかな、とも思いました。しかし、これはスクラムのフレームワークを乗りこなし、学生PBLで確実にプロダクトを生み出すことを目的とした場合の話であり、学生のうちにこのユニークな開発プロセスを経験することはとても有意義なことだと思います。散々書きましたが、自分は大きな学びになりましたし、スクラムやアジャイルに魅力を感じているので皆さんも是非いつかアジャイル/スクラムに触れてみてほしいです。
イベントを大切にしよう～デイリースクラム編～
前述の通りスクラムは様々なイベントで構成されており、このイベントはやり方によってはスクラムチームを良い方向に導く事も悪い方向に導く事ができると思います。それが顕著だったのがデイリースクラムでした。デイリースクラムは原則毎日同時間帯同タイムリミットで行うのですが、その時間設定ややり方を誤るとチームメンバーの時間をむやみに奪いじわじわと自分達を蝕んでいきます。一時期は「朝の方が判断力が高まる」などの理由から毎朝8:30からデイリースクラムを行っていました。しかし、朝に弱いメンバーが段々デイリースクラムについていけなくなり、デイリースクラムに出ることができない＝チームの最新の状態を共有出来ないので開発に支障が出始めました。おまけにデイリースクラムを欠席してしまう罪悪感からプロジェクトへの意欲が低下してしまう様子も見られ、負のスパイラルに陥っていました。そこからはなるべく無理のないお昼の時間帯にデイリースクラムを変更するなどして、自分達のチームに合ったやり方でスクラムを続けていきました。
Tips① -同期&非同期ハイブリッドデイリースクラム-
自分達でスクラムを工夫していく中で、かなり上手くいったプラクティスの一つとして「同期&非同期ハイブリッドデイリースクラム」がありますので紹介したいと思います。まず、原則デイリースクラムは集まって同期でやるものなのですが、昨今の情勢的に(スクラムに限らず)作業をオンラインに落とし込むことが多く、最初はslackのデイリースクラム専用のチャンネルに投稿をすることでデイリースクラムを行っていました。しかし、一日のどこかで投稿する決まりではありましたが非同期的な性質上議論が生まれず、デイリースクラムの本来の役割を満たさないと判断したため、discordで集まった上でデイリースクラムを行うようになりました。ですが、discordで集まっていざ各々の状況を報告しても、5人がその場で喋った情報から重要な情報をかいつまんで精査することは難しく、大事なことを聞き漏らしがちでした。そこで、まずは所定の時間に集まってslackに各々が報告したい事を書き、書かれたことから気になった事や大事なことについて議論するようになりました。こうすることで、スクラムメンバーの各々が気になっているトピックを漏れなく共有しながら、デイリースクラムの時間内に効率よく重要な事柄についての議論を抑えることができるようになりました。
Tips② -デイリーおえかき-
先ほども言いましたが、デイリースクラムは毎日のメンバーの時間を少しずつ消耗するので、一つ一つのミーティングは軽量でも回数を重ねる毎に負担になっていきます。そして、マンネリ化したデイリースクラムはチームメンバーにとって退屈なものになり、デイリースクラムへの出席のモチベーションを低下させます。そんな状況を打破しようと考えたのが、スクラムマスターによる「デイリーおえかき」です。
この画像は、自分が描いたイラストになります。この画像をデイリースクラム時のdiscordで画面共有して、最初に日付と今日のスケジュール、そして「今日の記念日」をアナウンスします。こうすることで殺伐としたデイリースクラムに日替わりでエンターテイメント的な要素を入れる事で、デイリースクラムに楽しみを見出してもらおうとしました。結果としては大成功で、デイリースクラムが嫌いだったチームメンバーからも高評価をもらえ、デイリースクラムを良い雰囲気で継続することができました。自分はたまたまお絵かきを取り入れましたが、単純に今日の記念日についてのアナウンスをしてみたり、デイリースクラムにお菓子を配ってみたり…などでも全然良いと思います。スクラムイベントに彩りを添えて、チームがスクラムを前向きな気持ちで取り組めるようにする事もスクラムマスターとしての支援の一つなのではないかな、と思って紹介しました。
イベントを大切にしよう～スプリントレトロスペクティブ編～
自分がスクラムのイベントで想像以上に大切だな、と感じたのが「スプリントレトロスペクティブ」でした。ふりかえり、というとめんどくさいイメージがある方もいるかもしれないですが、スプリントレトロスペクティブは次のスプリントをより良質な物のにする為に必須です。自分達は「KPTN(Keep, Problem Tweet, Next)」というフレームワークを用いてふりかえりを行っていました。まずTweet, Keep, Problemというエリアに各々が付箋でどんどん該当スプリントで考えたり感じた事を書きます。Tweetには取り留めのない近況、Keepにはスプリントで良かった/継続したいこと、Problemには困った/改善したいことを描きます。次にメンバーは一定数の票を持って話し合いたいトピックについて投票します。自分達は一人に3point分, 2point分, 1point分換算の3票を持たせ、投票したときの累計ポイントで話し合うトピックを選定していました。そして、話し合いの中で次スプリントで行うと決めた事柄をNextに書いて行きます。最初は荒削りだったスプリントが、スプリントレトロスペクティブを経る度にどんどん整備されて良質なものになっていく様はとても楽しいですよ。最後の方はスプリントレトロスペクティブが楽しすぎて
なんていう発言もしていました。皆さんも是非スプリントレトロスペクティブを通して良質なスクラムを目指して見て下さい。
まとめ
結構多岐にわたるトピックを長々と書いてしまいましたが、逆にそれだけプロジェクト学習の中で濃密な体験をしてきたということなのかなあ、と思っています。正直な所、前述の通り自分は入学した時には「ちょっとパソコンが好きな一般人」くらいのスキルセットだったので、周りの人からのプロジェクト学習についての話を聞くたびに「自分はプロジェクト学習で活躍することができる人材になれるのだろうか」という不安がずっとありました。もちろんプロジェクトの中では至らなかった点も多々あったとは思いますが、こういったソフトウェア工学的なスキルや開発スキル(スクラムマスターですがバリバリ開発もやってました(スクラム的にはホントは良くない))、またデザインコース生からの知見の共有の元デザインについても触れたりするなど、様々な面で実践と成長をすることができました。なので、自分としては入学当初の自分に向かって自身を持って成長できたと伝えられると思っています。未来大には沢山の成長する機会があると思いますが、プロジェクト学習は自分次第でいくらでも成長することができる特にいい機会だと思います。もしこれを読んでいるあなたがプロジェクト学習を控えているとするなら、是非一生懸命に、楽しんでやって欲しいです。長文失礼しました、最後まで読んでいただきありがとうございました！
明日23日は吾妻ちとせ君の記事です。お楽しみに！