CloudNative Days Tokyo 2019にスカラーシップ枠で行ってきた

こんにちは、7月の22日・23日に東京で開催されていた、CloudNative Days Tokyo 2019(CNDT)に参加してきました。 今回はCNDTのスカラーシップ枠で参加してきたので、参加した感想とか諸々をまとめて行きます。

オープンソースカンファレンス2019 Hokkaidoに出展してきた

はじめに

今年も、オープンソースカンファレンス2019 Hokkaido(OSC19do)が札幌で5月31日(金) と6月1日(土) の2日間開催され、僕は2日目に公立はこだて未来大学高度ICTコース・システムソフトウェア研究室のブースでシステムソフトウェアの展示をしていました。

プロジェクト学習とenPiTが終わってしまった

先日、2018年度 enPiT ビジネスシステムデザイン分野ワークショップというものがありました。 今まで、chikuwait.hatenablog.com

chikuwait.hatenablog.com

とかで書いてきたプロジェクト学習と、enPiTを1年間やってきたわけですが、ついに筑波での発表で終了というわけです。絶賛虚無虚無プリン。この気持ちを整理するためにも1年間を振り返ってみようかなと。

いつもの前提

プロジェクト学習

公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業では様々なテーマで最大15人程度のチームを組んで1年間取り組みます。詳細はこちらを参照。

www.fun.ac.jp

enPiT

enPiTは、

「成長分野を支える情報技術人材の育成拠点の形成(enPiT)」は、4分野における高度IT人材の育成を目指しています。大学・企業界の協力体制のもとで推進されるリアリティの高い講義や演習など、特色あるプログラムを通じて実社会においてイノベーションを起こすことができる人材を輩出します。

という目的のもとに文科省がやっている実践的なIT人材を育成するためのプロジェクトです。enPiTには4つの分野(ビックデータ・AI分野、セキュリティ分野、組込みシステム分野、ビジネスシステムデザイン分野）があります。未来大はビジネスシステムデザイン分野(通称BizSysD)に参加しています。BizSysDでは、 実際の地域などの課題を解決するようなアプリケーションやサービスの開発をPBLをやっていたりします。 また、未来大ではプロジェクト学習のシステム開発系テーマをPBLの発展学習科目としています。

まあ、詳細はこちらから bizsysd.enpit.jp

時系列で振り返る

4月

どのプロジェクトに行こうか決める時期。まあ特に特別なことはなく、先生と面談したり友達がどこに行くかを聞きながらどこに行こうか悩む。「ビーコンIoTで函館のまちをハックする – BEACON FUN Reloaded」ともう一つのテーマで少し悩んだものの、最終的にビーコンプロジェクトのほうを第1希望にしました。

5月

プロジェクト開始。無事ビーコンプロジェクトで決まったのでまあ幸先良いスタートだったと個人的には思っています。 まず最初に、プロジェクト学習では、リーダーを選出をします。このリーダー決めで何を間違えたのか、僕がリーダーになってしまいました。僕リーダーやりたくなかったんですが、投票で決まってしまいまして。 人を束ねたりすることが大の苦手なのに、いきなり15人の大所帯なチームのリーダになってしまいさぁ大変。

そして、この時の僕の中のリーダー観というのは、なんかちゃんとWBSみたいの書いて工数とか考えたり、自分からチームを引っ張って、仕事（タスク）を他のメンバーに上手に振る人みたいなものだと思っていました。そして僕はそういう行為が苦手です。さあ何がこの先なにが起こるのでしょうか。もう嫌な予感しか無いですよね。

6月

5・6月の主な活動は技術（ビーコン）についての調査だったり、課題を探すためにフィールドワークといったものなので、特に炎上する要素はあまり無いはずです。プロジェクト学習では、プロジェクト全体としてのレギュレーションみたいなテーマ（ビーコンプロジェクトはBLEビーコン使ったサービスを作るとか）は定まっているんですが、詳細に何を開発するとかは自分たちでフィールドワークをしてアイデア出しなどのプロセスを通して決めます。フィールドワーク自体がアイスブレイクも若干兼ねていたりして、みんなでワイワイしながら函館周辺を巡って課題を探すのは結構楽しかったです。初期からメンバー間の仲も良くてすごく雰囲気は良かったと思います。いつもワイワイしていた感じ。

↓フィールドワークで観光客気分のメンバー

ただ、タスク自体は僕が一旦まとめてそこから降るみたいなことをしていました。もちろん振るのは得意ではないので自分でどんどんスタックして抱え込むことが徐々に増えていきました。 なんとかしなきゃ！と思いつつもどうしたらいいかわからず、タスクを抱え込みメンタルが厳しくなってきます。 そして、6月末くらいから徐々に当初の計画（僕が勝手に理想だと思っていたスケジュール）から遅れて、1人で焦り、周りにも共有できないで勝手にメンタルが死んでいきます。

7月

7月には中間発表会というポスターとスライドを使った発表会と、中間報告書というTeXで結構な量を書くグループの報告書があります。もちろんポスターも報告書も作るのには時間がかかりますし、先生のレビューとしてもらって修正するなどが必要です。 しかしながら、スケジュールも遅れて遅れて、開発するサービスのアイデア出しを7月になってもやっている状態でした。 なんとか立て直さないと間に合いません。かといって、我々のチームはアイデア勝負なのでこのアイデア出しのプロセスを手抜きするわけにも行かないんですよ。詰んだ。

↓アイデア出しの時

それでも僕はなんとかせねば！と思い、瀕死のメンタルの中、WBSとガントチャートを作りました（？？？？？？？？） まあ、お察しなんですけども、まわりにヤバイという話をたいして共有してないし、明らかに間違ったピラミッド型しているチームでWBSを作ってタスクを無理やり振ろうとしたって失敗するんですよね。 計画通りにいくはずもなく目標からどんどん遅延に遅延を重ね、どう考えても終わらないスケジュールに無理くり間に合わせようとして、僕は勝手にストレスで胃に穴があきそうでした。

そして僕のメンタルは爆散しました。

最終的に、中間発表会の3日前に開発するサービスが決定し、エクストリームにポスターなどの発表準備を整えました。正直夜中までみんなを拘束する形になってしまいました。 いや本当にみんなすまなかった。マジでごめんなさい。 ただ、良くも悪くもこの炎上をきっかけにチームらしさは増したような気がします。今まで身内感覚でお友達という感じでしたが、この炎上からヤバい状況を乗り越えられる仲間みたいな雰囲気にはなっていったような気がします。結果オーライなのか？炎上でまとまるチーム…。 そして、中間発表会ギリギリまで開発するサービスを本気で検討していたおかげで、全員がこのサービスマジでいいんじゃね、みたいな雰囲気を出し始めていたような気がします。 「どうせ１年間やる授業、やるならマジで良いものが作りたい。」そんな気持ちがメンバーの中にあったのかなと思います。アイデア出しは妥協せずにトコトンやるべき。

↓真夜中の大学でポスター作る人々

8月・9月(夏休み)

大炎上事件から一段落つき、夏休みに入る前に「後期の開発に向けて技術習得を夏休みでやろう！！！」という雰囲気が出来てました。 「正直夏休みだしみんなそこまで出来ないだろうしまあ厳しいだろうな～～」なんてことを僕は思っていたわけなんですが、なんか週１で進捗報告会が始まったり、勝手に通話しながらお互い困ったことを相談しながらサーバサイド(Rails、Python、Go)やiOS(swift)、Android(Kotlin)などを各自が勉強していました。また開発慣れしている人がいい感じに引っ張っていってくれて、すごく開発へのモチベーションが高かったです。お前らどうした、夏休みだぞ。

その時僕は、「あれ、このチームめっちゃヤバイんじゃないの？？？？？？」ってなるわけですよ。 もともと開発が大好きだったやつが僕以外に4・5人いるとはいえ、これだけポテンシャルがあるチームをどうしたら、最＆高のチームのすることができたのだろうか悩みました。 ここまでの段階を振り返りとこのヤバイチームのポテンシャルを僕が謎のリーダー観でぶっ潰していたんじゃないのか？？？？そんな風にも思いました。 僕がやるべきだったのは、みんなにタスクを振ることではなく、みんなに伸び伸びやってもらって最大のパフォーマンスを発揮させながら方向性がずれないようにすることだったのでは？と感じました。 そのためにも、今のピラミッド型みたいのはやめるべきだし、自己組織型なチームにしていきたいと自分の今までのやり方を改めることにしました。ここで僕はチームをコントロールすることではなく、チームに尽くすという考え方に至ります。

そして、僕はこの時にもう一つの悩みとして、今後の開発進め方に不安を持っていました。夏休みが終われば開発が始まるわけですが、12月の第一週に最終成果発表があります。 つまり、約二ヶ月で考えたサービスを実現させなければなりません。よく本学のプロジェクト学習では、期間的に開発して終わり！という事が多く、ユーザビリティテストとかそういう使ってもらえるというフェーズに行くことが少ないです。個人的にはやっぱり作って終わりではなく、本当に使ってもらえるようなサービスを作りたいと思っていました。そこで、2ヶ月で最高のプロダクトを開発して、全員が成長できる方法を考える必要がありました。そこで、２ヶ月という期間で最高のものを作るためには、定期的に動くものを作って、評価と修正をを繰り返しながらやっていけるような良い仕組みが……。

あれっ？？？自己組織的なチームにしたいし、継続的に動くものを作りたい？？？？これはアジャイル開発とかいうやつでは？？？？？？？

というわけで、アジャイル開発をやろうぜ！！！！！って僕は心の中に決めました。導入までの詳細な流れは９月末の自分が書いていた 学生だってちゃんと開発したい！大学の授業でスクラムを導入しようと思った話 - Man page of CHIKU_WAIT(2)には「なんとかせなば俺たちは死ぬ」みたいな僕の気持ちがあります。

ちなみに余談ですが、enPiTのFD合宿(教員の研修)でビーコンプロジェクトの担当教員が「ちくわを助けて(意訳）」と言ったらしく、僕のメンタルが爆散したことが他の先生にも知られてしまった。

10月

そして夏休みも終わり、開発が始まりました。アジャイルについてはスクラムを導入してみようという事になったのですが、そこまで本格的に導入できるとは思っていませんでした。 週二回の授業で毎日デイリースクラムは現実的に無理だろうと思っていましたし、

が、蓋を開けてみたらなんと。僕は一度も強制したりやれと言った覚えも無いのに毎日デイリースクラムしてるじゃないですか。え、週二回しか授業無いんだよ？？？お前ら大丈夫？？？？ はい、思ったよりみんなのやる気がありました。お前らやっぱり凄い。とはいっても、スクラムの経験が足りていないので、皆SCRUM BOOT CAMP THE BOOKを読みながら試行錯誤でやっていく感じです。最初は1スプリントでバックログの内容が消化できない！無理！！みたいな感じもありましたが、次第に慣れていくことでベロシティも落ち着ついていくようになりました。ただ、この頃の僕はベロシティが全て！！！みたいな感じになっていたので、それは違うよなと今は考えています。あと、個人的に難しかったのはレトロスペクティブの質でした。どうしても最初は何をKPTで振り返ったら良いのかわからない！！という声があったので、できるだけ最初は質を気にしないようにしました。Problemにお酒を飲みすぎたとか、睡眠不足とかそこらへんから書いてもらうくらいから始めて、なんでも良いからチームを改善していく事を少しづつやるようにしてみました。正直このやり方で良かったのかわからないので、もうちょっと試行錯誤が必要だったのかもしれない。

↓毎日15人が超狭い部屋に集結する様子

↓プランニングポーカー使ってる様子

また、技術的な物もできるだけ妥協しないでやっていこうと個人的に考えていました。どうせやるなら技術的にも妥協したくないので、テストを書く文化、コードレビューをする文化、CI/CDちゃんとやっていくことを目指しました。 テストもコードレビューも漠然と「やってくれ！！」だと中々浸透しませんでした。そこで、テストの書き方をメンバーに伝える業、コードレビューのガイドラインみたいな文章を練成してプルリクエストのテンプレートにチェックリストを用意したり等々をやっていきました。コードレビューに関してはガイドライン作る前は僕がサーバサイドのレビュー全部引き受けてスプリント中コードレビューで疲弊するみたいなこともありました。ガイドライン作ってから皆がかなりレビューをやるようになったので、負担はほぼゼロになった。 CI/CDに関してはやろうぜ！！！って言うよりもわかってる人がｶﾞｯってやって仕組みや意義をちゃんと他の人に伝えていくという感じでした。 インフラに関しては、僕以外に経験がある人が居なかったので、サクッと1人でKubernetes使ったりして作りました。インフラも誰かとやる事を考えたのですが、サーバサイドの勉強とかで皆いっぱいいっぱいだったので、自分一人でやってしまった。本当は誰かとやったほうが学びにはなったんだろうな～。反省。

開発の流れとしては、サーバサイド(Rails)の場合、GitHubでプルリクベースの開発で、TravisCIとSiderでテストとRubocop先生がパス＆開発メンバーでコードレビューをしてLGTMだったらマージして10分後に自動でデプロイというような流れで行っていました。

11月

11月に入り、スクラムに慣れた来たこともあってどのチームも毎週動くものを出し続けてバリューが最the高というすごい時期だったと思います。 この頃はもう授業がない時間帯は15人ほぼ全員が一つの部屋に集まって開発をしていました。また、ペアプロ・モブプロも隔週で時間は設けていたのですが、特に時間を用意しなくて困ったりなんかあったら自然とモブプロが始まるような感じです。ほぼ全員のメンバーが良いものを作りたいというようなモチベーションを持っているように感じて、僕は幸せでした。また、10月・11月にはピラミッド型組織は完全に消え去っていました。なにかタスクが発生したら、特に何もいわないでも得意な人が自分で拾っていく感じ。おかげで僕は開発基盤改善業や全サービスにコミットしたり技術的な面から全体をサポートするような自分の得意なところに集中することが出来てました。あんなに辛い気持ちしかなかった前期に比べ、後期は毎日ブーストが掛かっている状態で最高だった。

また、11月末にはユーザビリティテストがありました。メンバーは最初はあまり乗り気ではなかったですが、次第にユーザに使ってもらえるぞ！！！みたいなやる気を出し始める人が居て、元からスピード感あった開発なのにさらにスピード感が増していきました。お前ら大丈夫か。ユーザビリティテストの前日の段階でその週のバックログの内容は消化できていました。が、急に直前に謎の凝り性を発揮し始めて チュートリアルを作り始めたり、ロード画面を作り始めたりしようとする人たちがいた。結局テストの当日朝6時まで開発やっていた。なんか凄かったな…。ここまで来ると何かの愛を感じる。

↓テスト直前に真夜中に開発する人たち

↓コーヒー飲みながら直前まで開発する人たち

12月

ユーザビリティテストも無事に終わり、成果発表が近づいてきました。本来スケジュール的にはユーザビリティテストの後に改善する時間はなく、すぐにポスターとスライド作成する必要があったのですが、ギリギリまでサービスを改善したいという人が圧倒的多数だったので、ギリギリまで改善して、地獄のエクストリーム発表準備をすることになりました。お前ら本当にそれでよかったのか。しかも今回は先生まで巻き込んで夜中までポスターを作るという鬼畜の所業。先生、夜中まで突き合わせてごめんなさい…。

↓夜中まで先生に付き合ってもらってポスターレビュー

↓大学に夜残ったメンバーでご飯

そして、12月にはenPiT BizSySD 北海道・東北グループ合同発表会もありました。 チームのenPiT履修生で仲良く旅行みたいな気分で行きました(もちろん真面目に発表したよ)。ただ、発表があまり良くなったのか、どのサービスも賞が取れなくて悔しい思いをしました(全員先生に慰められた）。盛岡美味しかった。

↓観光気分の人々

↓盛岡で懇親会と二次会のあとで皆で集まって遊んだ

1・2月

この時期に入ると、開発も終わり、成果発表や最後の報告書提出があります。 どうやら、うちのメンバーはみんな開発は好きなようですが、文章を書くのが苦手なようで。執筆が全然進まず、気がついたら提出期限。報告書提出が締め切り1分前になるみたいなエクストリーム提出をして、さらにミスを見つけて再提出という大失態。頼む、文章書くのもやる気を出してくれ。

成果発表では、秋葉原でのプロジェクト学習の成果発表と、筑波でのビジネスシステムデザイン分野ワークショップの2つがありました。 僕はどちらも参加したのですが、秋葉原の発表が終わった二日後には筑波に向かってました。1週間の間に東京と函館を2往復して超疲れた。 でもどちらでも、すごく評価は良かった（個人的に）と思っているので、行ってよかった。筑波のワークショップは他大学のやっていきも感じることができるので最高。

↓秋葉原で声が枯れた人々

チームメンバーに恵まれた1年だった

今年を振り返ってみると本当にチームメンバーに支えられてやってきた。正直このチームじゃなかったらやってこれなかった。 このチームだから良いものが作れたと思ってるし、技術的にも色々やってこれたんじゃないかな。 それに皆のモチベーションはありえないほどすごかった。たかが週2の必修の授業なのに、あそこまで情熱があったのは何だったんだろうね。 最強のチームだと思ってる。

あと、個人的には全員が成長できるチームであったと思う。コミット数とかを集計しても、何もやってない人なんて誰もいなかったし、各自が自分のできることを最大限やってた。デザイナーだった人がコミットかなりしてたし、開発メンバーがイラレ駆使しまくってすごい。

最初こそリーダーやるの辛かったし、二度とやりたくないと思った。けど、最後振り返ってみるとこのチームでリーダーやらせてもらって本当に良かったし貴重な経験ができた。本当に最the高なチームだった。

今の気持ち

この1年間、すごく早かった。最初こそは辛いことも多かったけど、本当に楽しかったです。貴重な経験しかなかったし、学びで溢れてた。 もうプロジェクト学習が終わってしまって、このメンバーでなにかやることはもう無いんだなって思うとすごく寂しいです。泣きそう。 もしもう3ヶ月あったら、このチームはどれだけヤバくなっていくんだろう、どれだけ強くなんだろうって思うし、その状態を見てみたい。 本当にメンバー一人一人が必要不可欠だったし、誰かが居なくてもうまく行かなかったんだろうなあと感じてます。 すごくドラマティックな1年だった。

本当に、1年間ありがとうございました。（全然まとまらない文章になってしまった）

メンバーの反応

みんなみてくれ！ https://t.co/gQxgO7YeQd

— 大橋 (@kazuma_0129) February 24, 2019

エモエモのエモブログ https://t.co/8IdHsry2FH

— ともか - 200 (@moko2356789) February 24, 2019

本当に最高の一年でした。めっちゃ良い環境で学べたと改めて思う(報告書はごめんなさいm(._.)m) https://t.co/3lsMERtlQD

— まっつ (@kota_2402) February 24, 2019

最初は1年間もやるのかー...と思っていたプロジェクトが，まさかこんな最高でエモな活動になるとは思いませんでした．ビーコンでプロジェクトできて良かった．本当にありがとう https://t.co/Q4HZsMaBON

— ohayota command (@Odart_16h) February 24, 2019

2018年振り返り

というわけで、もう2018年も終わりなので、振り返りをしようかなと思っています。 皆様は、一年間どうだったでしょうか？ 僕は本当に今年色々ありました。ただ全体的に反省点が多く、ダサい1年だったなあというお気持ちです。

未来大高度ICTコースのはなし

この記事はFUN Advent Calendar 2018の19日目の記事です adventar.org 某学科長に宣伝が足りないと言われたので。はい、本題通りです。みんな来てくれ。

不人気なコースなので宣伝をしていこうかなという次第です。学◯委員会のコース説明みたいなのでもハブられるので…

大学の授業でペアプロ・モブプロをやってみた話

こんにちは。最近大学でサーバサイドのコード書いたりモバイルのバグ探ししまくったりドキュメントやガイドラインを生やしたりインフラの設定生やしたりコードレビューしたりリーダー業したりスクラムの導入をしてるchikuwaitです。

いつもの前提

前回のブログ(学生だってちゃんと開発したい！大学の授業でスクラムを導入しようと思った話 - Man page of CHIKU_WAIT(2))でも書いてありますが、 公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業では様々なテーマで最大15人程度のチームを組んで1年間取り組みます。詳細はこちらを参照。www.fun.ac.jp

前回同様、リーダー業やってて色々な開発手法だったり入れてみた話をしていこうかなと思います。

ペアプロ・モブプロについて

ペアプロとは

ペアプログラミングのことで、名前のごとくペア（2人）でプログラムを書いていく開発スタイルです。ペアプロにはドライバとナビゲータという役割があります。 ドライバは実装の細かい部分を考えながらナビゲータと一緒にプログラムを完成させることに集中し、ナビゲータは一緒に考えたりコードレビューやバグチェックなどをします。 また、ドライバとナビゲータは一定期間でローテーションしていきます。

モブプロとは

モブプログラミングのことで、ペアプロの人数をもう少し増やして、4〜5人程度のモブ（群衆）でプログラムを書いていく開発スタイルです。ペアプロ同様にドライバとナビゲータが存在し、一人がドライバ、残りはナビゲータです。

ペアプロ・モブプロに至った理由

チームの状況

プロジェクト学習では基本的に成果発表などの授業スケジュールの関係で後期の9月末〜12月第一週が開発期間となるような事が多いです。とはいえ、メンバー全員が授業でやらないようなモバイルアプリやサーバサイドアプリの開発スキルを持ち合わせていてすぐにサービスの開発！！！みたいなことはほぼありえないので、基本的にどのチームも夏休み期間でその分野の勉強をするようなことが多いです。 私達のチームでも開発経験が少ない学生には夏休みでSwift、Kotlin、Ruby(Rails)について個人での開発経験が多いメンバーが支援しながら本を一冊やり終えたりしながら技術のキャッチアップをしてもらいました。多分他のチームよりは頑張ってやってたと思います。

しかしながら、いくら本を何冊かやったところで開発めっちゃすぐにできるようにはならないですし、一人である程度書けるようになるには時間がかかります。そこで僕としては個人で色々アプリ書いてきた人の知見を直接教えたりしながら全員一定レベル（一人である程度機能追加ができるレベル）まで成長できるような仕組みがほしいなと考えていました。そこで試しにペアプロ・モブプロを導入してみようと考えました。

何を求めてやったのか

僕としてペアプロ・モブプロに求めたものは以下の通りです。

• メンバーの教育
• ソースコードの共有初秋
• レビューコストの削減
• 品質向上

上でも書いたメンバーの教育を第一目標として、直接レビューをすることで一人である程度実装ができるようなるくらいを目標にしました。 また、複数人でコードを考えることでソースコードを共有所有していきたいと考えました。それから、どうしても自分である程度書ける人や開発をリードする学生にソースコードのレビューが集中しがちなので、リアルタイムなコードレビューはレビュー待ちプルリクエスト渋滞の解消なども期待しました。

やってみた

授業でペアプロ・モブプロやるときのルールとしては

• 1時間ごとにドライバ交代
• できたら褒めたり拍手したりハイタッチ
• 強い口調や不快にさせる言動はNG
• お菓子食べたりしながらリラックス を設定しました。

本当はもっと大きなモニターを使いたかったんですが教室の関係上無理でした…。

実際やってみてどうなった

授業でモブプロ・ペアプロを導入することで、メンバーの中ではわりと好評だったりしました。どうしても自分ひとりで躓いて解消できない…みたいなことは学生多かったりしたので三人寄れば文殊の知恵というわけではないですがうまくコミュニケーション取りながら詰みポイントを解消していったようです。知識が共有できて良さそうでした。あと結構意外だったのはペアプロ・モブプロをすることで生産性が少し下がるかなと思っていましたが、殆ど変わりませんでした。一人で躓いて時間を浪費することが減ったからかな？

ただ、頻度は結構難しいところで、最初は週１でやっていましたが、どうしても一人でもくもくする時間もほしいという声もあったので隔週にしたりしながら頻度の見極めをしていく必要があるかなと感じました。最終的に私達のチームでは特に時間を設けることはせず、必要なタイミングで自己主張していくと自然と人が集まってペアプロ・モブプロが始まるという感じのスタイルになっていきました。

最後に

ペアプロ・モブプロは全員をある一定レベル以上にする育成方法としては結構イケてるのでは？と思いました。ただ、乗り気ではないメンバーもいるのでそこは上手くチーム内でどうやっていくかを最適化できれば良さそうだと思います。ぜひ大学の開発演習でやってみてください。何よりも楽しいので。

学生だってちゃんと開発したい！大学の授業でスクラムを導入しようと思った話

前提

僕が居る公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業ではサービスの開発や心理学研究、楕円曲線暗号のアルゴリズムの高速化やアルゴリズムの改良といった様々なテーマで最大15人程度のチームを組んで1年間取り組みます。実社会に根ざした問題群を解決していく方法を探求する取り組みらしいです。また、教員はあくまでもアドバイザーで、どんなことをするのか、何で開発するのか、どう開発していくのか、スケジュールはどうするのかすべて学生が主体となって決めていきます。そのため、チームによってですが、授業の時間以外も時間を費やすことが多く、3年生はプロジェクト学習に全力を注ぐと言っても過言ではないと思います。詳細はこちらを参照。www.fun.ac.jp

僕が所属しているプロジェクトは「ビーコンIoTで函館のまちをハックする – BEACON FUN Reloaded」というテーマでビーコンと呼ばれるBluetoothの電波を発信する小さな機器を用いて世の中にはまだないような新しいサービスで函館のまちをハックすることを目的としています。