こんにちは。今回は技育展の振り返りをしようと思います。 主に自分がやったことについて記述していきます。
0. 背景
大学院の講義で「オンライン授業のための質問回答プラットフォーム」というものをつくっていました。
この講義では、5~6人1グループで、4月~7月にかけて何か情報システムを作るという非常に指定が適当自由度の高い講義でした。
講義では、中間発表で
「んで、それ使ってもらえるの?」 「従来の質問フォームと何が違うの?」
と教員にボコボコにされたのですが、 最終発表では、学生投票で2位/8チーム、教員からも高評価をいただくことができました。
しかし、作ったものをこのまま講義内で終わらせるのもなんかもったいないなあと思い、たまたまぼくが見つけた「技育展」に出してみないか?と誘ったのが今回の登壇のきっかけになりました。
1. 技育展とは
株式会社サポーターズが主催する、学生向けのテックカンファレンスです。 要は、
学生が作ったアプリ、ゲーム、ロボットなどを企業さんや学生に向けてLTしようぜ!
って感じのイベントです。
今回は、技育展の8部門のうち「チーム開発」部門で登壇させていただきました。
2. 登壇決定まで
講義で開発していたので、ある程度形になっていました。なので、技育展の応募では優先的に見てもらえるように、すでに成果物があるよ!という人のための1次応募で提出しました。
チームの中からは自分含めて3人で応募することにしました。
応募した当時は「ほかの人のレベルが全然わからんけど、ワンチャン通るんではw」ぐらいのノリでしたが、 無事に登壇権を得ることができました。わいわい。
3. 登壇決定後
役割分担
もともとは6人で開発していたのですが、登壇するのは3人でした。 6人の時は、フロント、バック、環境構築、テストデータ生成、プレゼン役がありましたが、環境構築とテストデータは終わっており、バックエンドもほぼいじらなくて済むので、実質フロントとプレゼンのみでした。
自分はフロントエンド担当だったのと、デザイン関係ができるのが自分しかいなかったため、 引き続きフロントエンド、 UI/UX デザイン、機能開発をやりました。
残りの二方は、議論や機能の案出し、プレゼン資料作成を全面的に任せていました。
追加開発について
せっかく登壇が決定したので、追加開発でもしようか、という話になりました。 ただ、1か月もないため、たくさんの機能は追加で開発できません。
なので、本当に欲しい機能って何?ほかの質問回答フォームと劇的に違う、講義向けの機能って何?という議題で徹底的に3人で議論しました。
そこで議論した結果、講義資料と質問が手軽に結び付けられるといいよね!っていうのが出てきて PDFに質問をかける機能 を付けてみようという話になりました。
ただ、こちらの機能については実装の方針がなかなか立たず困っていました。
もともと近い機能として、講義資料のわからないページ番号のボタンを押すと、棒グラフで集計して視覚的にみんなが困っているところがわかる「Scream 機能」というのは実装してありましたが、集計がページ単位だったり、「質問回答プラットフォーム」の趣旨と微妙に方向性が違うこともあり、もう少し学生の疑問と質問を直接結びつけられる機能が欲しいと思っていました。
ある日、以前に大学の講義システムの担当者にプレゼンしたときに、Hypothesis というアノテーションをつけられる機能があるみたいな話があったよなあと思い出しました。
(プレゼンについての備忘録は上記の記事を読んでください)
もしかするとこれを使えば何かできるかもしれない、と考え調べてみたところ、APIに関するドキュメントを発見しました。
これを見つけてからすぐに、
というアイデアを浮かべ、実装に移りました。
1, 2 あたりは適当にググって実装方法を調べれば簡単にできました。3については、自分たちの作った質問フォームが Markdown に対応していたのでリンクを埋め込めるじゃないか、ということで、 簡単にアノテーションと資料を結び付けられるリンクを貼りつけることにしました。
無事に登壇5日前ほどにPDFとアノテーションを結びつける機能が完成させることができました。 機能の使い方も、講義資料にアノテーションを付ける→質問の際に勝手にそのリンクが取得できてコピペで質問に貼れる、と至ってシンプルな構造になり、短期間の開発の割には結構いい機能を追加できたと満足しています。
プレゼンなどの準備
技育展で登壇する前は、大学の講義で発表に使った PDF のプレゼン資料しかありませんでした。 ただ、普通にプレゼンを行っても当然勝ち目はないだろうとのことで、何か工夫する必要があると考えました。
プレゼンについては、ほかの二方に内容を任せることにしていたので、自分は手持無沙汰であったため、何か貢献できないかなと考えていました。 そこで思いついたのが、プロモーションサイトを作ることでした。
チームの動きとしてはやばいのかもしれませんが、Slack に「いい感じのサイトつくってみます」とだけ書き残してササっと作ってました。
プロモーションサイト
プロモーションサイトについては、自分がフロントエンドを担当していたこともあり、2~3時間程度で作成できました。 GitHub にリポジトリもあったため、github.io に公開することで簡単に多くの人に見てもらえるようになりました。 作ったサイトが以下のものになります。
見た目もそこそこな感じでできたと思います。 トップページの画像は自宅で適当に本とマグカップを置いてスマホで撮影したものですが、思ったよりいい画像になったので使いましたw
このサイトをつくりながら、
- サービスに名前がついていない(オンライン授業のための質問回答プラットフォーム、では長すぎる)
- ロゴマークがない
- いい感じのカード(リンクを埋め込むと表示される画像)がない
など、サービスに足りないものをたくさん見つけることができました。
また、懇親会ではどんなもの作ったんですか?と聞かれるので、このサイトを使って簡潔に作ったものの紹介ができたのも良かったです。
サービス名
サービス名称については、今回登壇しなかったチームメンバーが「CyQlone」でどうでしょう!と名付けてくれたのでかなりすんなりと決まりました。 これも講義でデモを行ったときに、たまたまトップページに font awesome のドラゴンのアイコンを使っていたところからひらめいたそうです。すごいセンスです。
上記のプロモーションサイトにも書いてありますが、由来としては、 Cyber + Q&A の Q + cyclone です。
ロゴ
デザイン関係については自分がチーム内ですべて受け持っていたので、一人で作っていました。 これも、ぼくが勝手に足りないよなあと思っていただけで、チームの人に頼まれたわけじゃなく、お節介だったかもしれませんが...。
ロゴについては、CyQlone の C をイメージしつつ、ドラゴンを主体にして描きました。
まあこんな感じです。クリスタでベクターツール使って納得いくまで戯れてました。
ロゴって、シンプルな見た目かつ、万人に受け入れられるような無駄のなく美しいデザインにしなければならないので、かなり難しかったです。最近はフラットデザインが主流になってきているのですが、フラットデザインほど見た目の割にデザインするのが難しいものはないと思っています。ぜひ一度やってみてほしいです。
カード
ロゴもサービス名もあるなら次は宣伝用のカードです。 いい感じのフォントと色遣いを選んでこんな感じのものをサクッと作成しました。
フォントは、あまり奇抜なものを選ばずちゃんと読めてかつかっこよさもあるものを選びました。
ベースカラーは真面目さのイメージ、京大のスクールカラーが濃青であること、CyQlone が嵐やそういったものにちなんでいることから青色を選択しました。背景色は、単色だと少々味気なかったので、軽く水色から青色へとグラデーションをかけました。
プロモーションサイトのURLを貼っただけでは、リンクのテキストだけがあり、当然クリックしてくれる可能性は低いため、このように人の目をひくカードを用意することで、少しでもクリックしてくれる可能性を上げたいと思っていました。また、カードのサイズも、きちんと Twitter カードの規定の比率に準じて作成し、サムネ映えするように作りました。
プレゼン
講義で発表したときは10分プレゼンを行い、そのあと講義1コマ分ほどデモを行うという感じでした。
しかし、技育展ではプレゼンはたったの5分しかなく、いままでの経過をすべて話したりデモを十分に行うという時間がありませんでした。
そこで、登壇メンバーでどんな内容をプレゼンに盛り込むのかということを議論しました。
事前に技育展 Slack のチーム開発のところでは、審査基準として
▼共通審査基準2項目 (1)技術的な挑戦 - 技術的に難しい/新しいことへの取り組み - ソースコードの中身(公開されているもののみ) (2)完成度 - 実装されている機能、内容 - デザイン/UI/UXなどの工夫 ▼各テーマ毎審査基準1項目 (3)プロダクト愛 - こだわりをもっているか、チーム全体で取り組めているか
という風に掲示されていました。なのでこれをベースにプレゼンを改良していくことにしました。
(1) の技術的な挑戦、については、COVID-19 でオンライン講義への移行が急速に進み、学生や教員からたくさん挙がった問題点を解決する、ということを主軸に置きました。 ソースコードについては、GitHub に公開していたので、事前に審査員の方に見せていました。このため、アーキテクチャの内容については、プレゼンの時間を考慮し、今回はプレゼンに入れませんでした。 ちなみにですが、構成は非常にシンプルで、Ruby on Rails + DB(sqlite3) となっています。
(2) については、実装内容はプロモーションサイトや事前の説明などで記載、デザインの工夫はぼくが UI/UX デザインの担当だったので、「とにかく使いやすく、シンプルに」ということを強調しておきました。
特に考えたのが(3)でした。 こだわりとしては、やはり自分たちの周りで今起こっているオンライン授業における問題を自分たちで解決したい、というのが一番でした。
さらに、チームメンバーは講義でほぼランダムに構成されたのにもかかわらず、ぼくがTAをやっていることや、教育情報の研究に携わっている人が1人いるというように、 オンライン授業の問題を多角的にとらえることができたことや、実際に開発にそれを活かしたことも大きなポイントであると考えたので、しっかりプレゼンに取り入れました。
また、すでに書きましたが、京大の講義システムの担当者にプレゼンし、オンライン講義の問題点や改善点、今後の改善について議論したことももちろん活動実績としてあるので、 プレゼンの最後に盛り込むことにしました。
最終的にプレゼンの構成は、
- 自己紹介(15秒)
- 問題と解決したいこと(1分程度)
- 実装した機能とデモ(2分半程度)
- こだわりポイント(40秒程度)
という構成になり、非常に伝わりやすい構成になったかなと思います。 スピーカーノートも無駄な要素を徹底的に省き、重点的に伝えたいことがしっかり強調されるように何度も練り直しました。
プレゼンの構成を練った後、デザイン担当のぼくがスライドをスタイリッシュな見た目になるように再構成しました。
一部ですが、左が Before で右が After です。
スライド作成ですが、
- 各スライドのタイトルはできる限りわかりやすく短く
- 文字や画像を詰め込みすぎない
- 視覚の流れを意識する(左から右、上から下)
- 「ゲシュタルトの法則」をしっかり意識してオブジェクトを配置する
- アニメーションを多用しすぎない(使う場合は決めポイントだけで使用する)
- インパクトのあるスライドは枚数を極力絞る(必殺技は何度も使えない)
- 配色は色相環での関係や、補色関係などを考慮して色を利用する
- 黒は非常に強い色なので、広い領域を使う場合は少し彩度を落とす(例えば、上記の「現場の意見 x 教育研究」の x とか)
といったように、たくさんの発表を聞いた後でも視聴者に負荷がかからずすんなり頭に入るように気を付けました。
トークについては、ほかの二人の声やしゃべり方が圧倒的にプレゼンに向いていたので、ぼくはほかの二人に何か問題があったときのための代役でした。
4. 結果
#技育展 テーマ別審査結果です。
— 【公式】技育プロジェクトbyサポーターズ (@geek_pjt) 2020年9月26日
「チーム開発」の受賞作品は
最優秀賞:オンライン授業質問回答プラットフォーム「CyQlone」
優秀賞:部室風SNS「traQ」
敢闘賞:大学生向けノートシェアリング「eeNotes」
となりました!
受賞された皆さん、おめでとうございます!! pic.twitter.com/gCtkqDxvE9
チーム開発部門でなんと最優秀賞をいただくことができました。
敢闘賞や優秀賞の講評を聞いているあたり、技術力とか完成度とか、今後の展開も期待できるとか、そんな感じの話が出てきていて、厳しいか...と若干諦めかけていましたが、 自分たちの作品名が呼ばれたときはディスプレイの前でガッツポーズしました!
講評では、システム自体の完成度の高さを評価されたほか、チーム開発ならではのスキルセットについてや、自分たちの周りで起こっている問題を自らの手で解決するといった こだわりポイントが企業の方に評価されたようで、事前に練っていた推しポイントがしっかり伝わったようでとても嬉しかったです。
これまで頑張ってきて本当によかったです。
5. 振り返り
思えば、
- そもそも COVID-19 が流行しなければこの開発には至らなかった
- チームメンバーは僕も含めて開発経験ほぼなしの初心者だらけだったけど勉強たくさんした
- 講義で先生やほかの学生に見てもらえる機会があった
- たまたまチームメンバーにTAや教育情報の人がいた
- 技育展の告知はたまたま見かけて軽い気持ちで誘ってみた
- 大学の講義システムの担当の人にプレゼンしたのはほかのメンバーが機会を作ってくれたから
というように、小さな偶然やほかの人が作ってくれたチャンスをしっかりモノにして、それを重ね合わせたのが大きかったのかなと思います。
個人開発だとどうしても個人の能力を超えるものをつくるのは困難ですが、チームだからこそこのスピード感やスキルセットが実現したのかなと思います。 チームメンバーの問題を見る視点や、アイデア力もそうですし、ワークショップで先生に評価していただいたり、講義を行う側の悩みを教えていただいたりと、ヒアリングもうまく活用できましたし、自分にないスキルはほかの人に任せればできあがっていく、という点はチーム開発ならではの面白さや良さだったと思います。
この開発の今後についてですが、さすがに既に存在している大学の講義システムにとって代わって使ってもらうのは、 セキュリティ上の問題、システムの安定性の問題、予算の問題、個人情報の問題...といろいろ問題が多すぎますので難しいです。 ですが、自分たちの学習環境、講義システムが改善されるようにこのように直接働きかけられたのが大きな貢献だと感じています。
6. 最後に個人的な話
個人的には、プログラミングは自分には本当に向いていないのかもしれない、と競プロをやっていたときは思いました。 周りの人は数学出来るし頭の回転も速いし、努力量も圧倒的だし、それがレーティングなどに表れていて、 とてもこの人たちと戦える気がしないと委縮していました。
他にも、3回生の時に、インターンにとりあえず応募してみるも最終選考でお祈りされて自信を無くしていました。
そうしているうちに、「成果物を出している学生は非常にレア」という話を聞いて、 ものづくりが好きなぼくは、ここで戦うべきなんじゃないかなと感じ、 思い切ってそっちの方面に舵を切りました。
例えば、ツイッターに簡単な bot を仕組んでみる、アドベントカレンダーの記事を書いて知識を共有する、といった簡単なことからはじめ、 アルバイトに応募してみて実際に実装に携わってみるといったことも行いました。
今回作成した CyQlone も、わたしたちが欲しい、というものを「できるだけシンプルに」実装できるということにこだわりました。 勉強しているとどうしても、技術的にしょぼいのでは?とか、ほかの人の作品はあんな技術使ってるのに自分たちはこんな基本的なものしか使いこなせていない...と凹むことが出てくると思います。 しかし、技術そのものを評価してもらいたいというわけじゃないのであれば、アーキテクチャも、操作性も、デザインも、すべてがシンプルな方が、実装する側にとっても利用する側にとっても良いと自分は思います。 そして、そのシンプルな実装を行えるようにするには、日ごろからいろんな分野の知識をためたり、コツコツ泥臭い実装を積むことを経験したり、 ネット上の記事や他人との交流から、こんな方法もあるよ、と知見を少しずつためていくことが大切だと私は思います。
また、デザインについては日ごろから良いデザイン、悪いデザインについて「どうしてこれは良い(悪い)のか」をすこし立ち止まって考えてみることがセンスを磨く第一歩かなと感じています。 UI / UX については良いインタフェースのパターンの積み重ねがありますから、基本的にはそのパターンを頭に入れておき、実際に設計する際は、複数のパターンを適用して、実際に使ってもらって、最も良いものを採用する、といったように試行錯誤することも大切です。あとは、藝術鑑賞するとか、自分で紙にスケッチしたり絵を描いたり...とかそういうのもきいてくるかもしれませんね。
技術力ではまだ拙いことが多くあれども、今回このように、企業の方から評価をいただけてとてもうれしく思いますし、 これからより一層実力を磨いていかなければならないと身が引き締まる思いでもあります。
同世代の学生たちが活き活きと発表している姿もとても印象的でしたし、懇親会でのトークも盛り上がり、刺激的な体験になりました。
本当にありがとうございました。