この記事は夏のブログリレー21日目に投稿された @quarantineeeeeeeeeeによる 講習会をシステム化するサービスを作ろうとした【ハッカソン反省】 の続きです。
作品紹介
私たちが作ったのは、「stoQ」という講習会ナレッジベースです。部内で開催された講習会をストックしていき、資産として新たな学習者に届けることを目指しました。
traP-jp
さらに、このサービスが使われるようになるために、講習会運営にデータを入力してもらう必要があったため、情報入力用のUIを誰でも編集できるような機能も実装し、運営の入力の手間を減らすことも考えました。
この作品は、ハッカソンにご協賛いただいた株式会社ナレッジワーク様より、企業賞に選定いただきました！
また、話の成り行きでUIライブラリを自作することになりました。
traP-jpそれでは、今回のサービスを作るにあたっての背景や、設計時の意思決定について紹介していきます。
作品を作るに至った背景
traPでは、経験者が知識やノウハウを参加者に伝えていく「講習会」がたくさん開かれています。例えばtraP内のゲーム班ではUnity講習会を、アルゴリズム班ではアルゴリズム基礎講習会を開催しています。
しかしここには大きな問題が3つあります。
問題①：講習会を開催するための手続きが複雑
講習会を開く前には様々な準備が必要です。
講習会の日時を決めたり、資料を作ったり、部内のスケジュール管理アプリに講習会を登録したり、開催する講義室を予め予約してもらったり、部内に向けて告知したり、......などなど、たくさんあります。
そのため、初めて講師をやることになったり、講習会の運営に初めて携わることになった人は、「何から手を付ければ良いのか分からない」となってしまいます。
問題②：手続きが明文化されておらず、属人化してしまっている
また、講習会の準備は講習会によって少しずつ違います。講習会によって開催する回数が異なるのはもちろん、受講できない人を減らすため、全く同じ内容の講習会が複数回開催されるものもあります。例えば、ゲーム班のUnity講習会は全3回からなる講習会ですが、プログラミング基礎講習会は全8回からなります。（ちなみに、プログラミング基礎講習会のテキスト は公開されています！）
それにも関わらず、講習会の準備はほとんど明文化されていません。毎年行われる講習会であれば、たいてい先輩が書き残した引継ぎ資料がありますが、講習会によって充実度はまちまちです。準備のやり方を特定の人しか把握していない属人化した現状は良いとは言えません。
問題③：過去の講習会の情報が、アクセスしやすい場所に体系化されてまとまっていない
もちろん講習会が実施された当時は、その講習会に関する様々な情報をあちこちから得られるでしょう。たとえばtraQ（※1）の投稿やknoQ（※2）に追加されたイベント情報を見ることで、いつどこで誰がどんな講習会を実施するのかや、どこでテキストを見れるのかに加え、質問したい場合はだれに聞けばいいのかなど、を知ることができるようになっています。多くの講習会は録画を撮影しており、サークルメンバーであれば、だれでもアーカイブを視聴できるようになっています。
とはいえ、講習会のデータはたくさん残っていても、有効活用できているとは言い難い状況でした。部内Wikiはあるが、使いにくく、別に講習会に特化して情報が書かれているわけではありません。また、初心者に講習会を受けてもらいたくても、初心者ほどtraPに慣れておらず情報を探すのが難しい傾向にあると考えています。
※1 traQ：部内連絡用チャットツール。部内イベントに関するお知らせ、サークル運営のためのやり取りに加え、traPのメンバー間での情報共有や雑談などもおこなわれている。2026/9/6時点での総メッセージ数は993万件！ https://github.com/traPtitech/traQ , https://github.com/traPtitech/traQ_S-UI
※2 knoQ：部内イベント管理サービス。借りている講義室の情報やイベント対象者、出欠確認などを行えるサービス。 https://github.com/traPtitech/knoQ , https://github.com/traPtitech/knoQ-UI
問題の解決に向けて
これらの問題を解消するため、講習会の知見を資産としてまとめるサービスを作ろうと考えました。また、ただまとめるだけではなく、情報が集まるための仕組みも一緒に作ることにしました。
講習会の情報を集めるためには、講習会を開催する人に入力してもらうのが手っ取り早いです。しかし、講習会を開催する人にお願いしても、全員が全員書いてくれるわけではないでしょう。そこで、情報を登録するだけではなく、講習会の開催を丸ごとサポートするサービスとすることで、自然と情報を入力してもらえるようにしようと考えました。
講習会を開催したい人に、まずこのサービスを開いてもらいます。開催にあたって必要な手順がすべて書いてあるので、講習会主催者はこの流れに従って準備すればよいし、サービス側にとっては必要な情報を入力してもらえるわけです。
ただ、ここでさらに別の問題が発生します。「講習会の開催にあたって必要な手順」というのは、しょっちゅう変更されます。手順をソースコードに書いてしまうと、プログラミングに詳しい一部の人しか書き替えられなかったり、そもそも更新が大変で放置されてしまったりといった問題がおきるでしょう。
誰でも簡単に書き換えられるようにするため、講習会開催のための一連のフローを投稿できるようにしました。
フローの中に書いた、{{ }} は、対応するIDの入力欄となります。入力画面を自由にカスタマイズできるようにすることで、講習会開催マニュアルがだれでも簡単に修正できるようにしました。
自作UIライブラリ「BasiQ-UI」について
余談ですが、今回のハッカソンのために開発していたUIライブラリについても紹介します。
部内チャットツール traQ のデザインを参考にしつつ、最低限UIを作るために必要なコンポーネントをたくさん作りました。しかし、traQは6年近くにわたって継続的に開発されていることもあって、必ずしも一貫したデザインとなっているわけではありません。
そのため、traQのデザインをできるだけ再現しようとはせず、短期間で開発を進められるよう大胆に整理してあります。また、アクセシビリティ対応を重視した設計・デザインを行いました。
開発の様子
準備期間
開発期間（前半）
8/23にBasiQ UI v0.1.0-beta.0をリリースしました。
開発期間（後半）
完成までにやらなければならないタスクが概ね整理されたのは8/30で、やっと画面の構成やデータベースの設計が始まりました。
最終発表まで毎日のようにDiscordで通話しながら開発したり、大学に集まって開発したりしていました。
感想
mikannkann
正直、今回は今まで参加したハッカソンの中でも、だんとつで時間がありませんでした...
仕様をかなり詰めていたぶん、もう少し開発に時間をかけられたらよかったな、という少しもったいない気持ちがあります。
一方で、時間がなかったにもかかわらず、今までのハッカソンの中で一番深く仕様を考えられたことは、実はかなり嬉しかったりもします。
一見すると、このサービスは単純で、すぐに作れそうです。
ただ、真剣に設計しようとすると、実はかなり難しく、とても考えごたえがありました。
設計の段階で妥協してしまえば、もっと簡単に、
それこそ数時間で「それっぽいサービス」を作れたと思います。
ただ、今回のチームには、そういう妥協では納得する人がいませんでした。
しかも、メンバーそれぞれが違う方向に長けていたので、
それぞれの視点から本気で考えて、本気でぶつかり合うことができました。
（そして、自分も含めて全員ちゃんとバトルするので、ただでさえ時間がないのに全然話がまとまらない）
1-monthonなのに、結果的には開発に使えた時間がかなり短く、そこはやっぱり悔しいです。
ただ、自分はこういうぶつかり合いが大好物なので、本当に楽しかったです。
簡単には話がまとまらない。
でも結局、こういうめんどくさいチームが、自分は好きなんだと思います。
次は、スケジューリング、もっと頑張りたい！！
rurun
AIを叩きながら案を出したり、ちゃぶ台返しをしたり、旅行に行ったり、プレゼンの一発ネタを作ったり、旅行に行ったりしていました。
これはハッカソンに限らないことかもしれませんが、これまで何度かハッカソンに参加する中で、「アイデア」と「完成」、「ハッカソン後に使い続けてもらう」というそれぞれの間に大きな壁があることを感じてきました。今回のハッカソンでは、「ハッカソン後に使い続けてもらう」ところまで見据えてやってきましたが、結果的にはそこまで辿り着けませんでした。
今回の開発では、Codexの有料プランを持っている人が複数人いて、最初は余裕だろ、と思っていた部分もありました。しかし、いくらAIがプログラミングをできるようになったとしても、こちらがきちんと指示をしていかないと、「なんとなく良さそうなもの」はできても、「traPの現状に即した、みんなが使ってくれるもの」は出来上がりません。その部分のハンドリングをうまくやり切ることができなかったのが、当初目指していたところまで完成しきれなかった要因だと感じています。
みんなで議論をする中で、サービスを継続して使ってもらうためのアプローチ（講習会運営のサポート、編集・投稿可能なフローなど）は良いアイデアを出せました。しかし、どんな情報を載せるか、どういう流れでサービスを使ってもらうか、といったところの具体的な設計までは詰めきることができませんでした。各々の頭の中にはあっても、それぞれのメンバーでちょっとずつ思い描いているものが違ったり、それをAIにうまく共有できなかったりしたのが難しいところでした。
とはいえ、AIが自律的にできる部分と、人間が介入しないといけない部分の境目を見ているようで、とても面白かったです。
また、チーム開発ならではの難しさとしてみんなでなかなか集まれなかったのも反省の一つです。考えていることがみんな少しずつ違って、それを擦り合わせていくのは対面でなければ難しいと思います。対面で意見をぶつけ合ったり、みんなでわいわいしたりする方が楽しいですしね。その分AIに文脈を渡すのは難しくなっていくけど...
さらに、メンバーによって開発経験やAIへのアクセスに差がある中で、もっとみんなが楽しんで参加できるチーム運営にも課題があったなと感じています。
色々と書いてきましたが、反省の裏返しで、さまざまな学びのあるハッカソンでした！
yasako
コンポーネントライブラリって作るの難しいんですね。かろうじて「ライブラリ」を名乗れるくらいのコンポーネント数や品質は達成できたのでは無いかなと思っています。詳しくはBasiQ-UIについて紹介した項を読んでほしいのですが、最初の一週間半は、ずっとFigmaをいじっていました。大変だった...。Figmaをいじって、使う色や余白等のデザインに関する大まかな方針が決まったあとは、コンポーネントをどんどん実装しつつ、他の人が作ってくれたモックに、作ったコンポーネントを導入して置き換えていく作業を担当していました。
どんなサービスを作るのか議論する際に、とくに僕が意識していたのは、「実際に使われるサービスにしたい」ということです。上でも書きましたが、情報を集めるための場所を用意したとしても、継続的に情報が入力・更新され、どんどん蓄積されていくような状態までもっていきたいなと思っていました。
何を作るのかについてはいろいろと考えたものの、完成させることが目標のハッカソンとしては、あんまりうまく行かなかったなという印象です。UIライブラリは僕が一人で作りましたし、講習会サービスも設計に時間をかけすぎた結果バイブコーディングで無理やりそれらしいものにする、という感じになってしまいました。また、Web開発が比較的初心者の人をサポートする余裕が無くなってしまったのもかなり悔しいです。
次回への反省としては、ちゃんと対面で集まって話し合いをしましょう、開発開始前に何をつくるかちゃんと話し合っておきましょう、という2点です。
みんな忙しいのは分かり切っているので、早めに動きましょう。
y_33550336
アイコンのデザインと、バッジを生成したときの見た目が大丈夫そうかに少し関わりましたー！
今回具体的な実装はAIになり自分は課金をしていなかったので見守る係になってしまいましたが、実際に初めて本格的にAIコーディングをしている人を見てその使い方の上手さに驚かされました…！
最終的なゴールを見失わずに、どうやったらそこにたどり着くことができるかを一緒に考えて、必ず認識の齟齬が生まれないように常にどこまで理解しているかを確認することが大切なのだと感じました
これは人間同士のコミュニケーションでもお互いに理解度をしっかり把握して、考えていることや持っている情報を交換することが重要だと改めて思ったので、チームメンバーとの報連相はもちろんのこと、AIとの関わり方も同じようにすればうまくやっていける(いけた)のではないかなーと思いました
正直、ここまでしっかりターゲットを明確に決めてどのようなプロダクトがユーザーにとって快適なものになるか、ということについて考えたことがなく、仕様書についてこんなにも議論したことがなかったので個人的に新鮮で難しい経験でした…
それぞれが思う「よいサービス」というものが微妙に違うこともあるのかなかなか意見がまとまらず、あまり自分がうまく参加することができなかったので少し悔しかったです
ただ、こういう失敗もよい経験になるはずであり、AIの活用方法などいくつかの学びを得ることもできたので、今回のハッカソンに参加できてとても貴重な機会でした！
Ida-ji
講習会の事情を元に案出しをしたり、日程調整などのマネジメントを行いました。
良い開発か良くない開発かで言うと、間違いなく良くない開発でした。私が実装において何もできず無力だったことが何より悲しかったです。
チームメンバーで日程が中々合わなかったり、対面で会って話し合っても目指す方向性を中々決めきれなかったことが要因だと思います。やっぱり言語化をして相手にちゃんと伝えることが重要だと思いました。
言い訳をすると、現在のtraPの講習会システムがあまりにも複雑すぎるのもありました。どこから手を付ければ良いのか分からなかったです。それでも、チームメンバーなりに話し合って良さそうな択を選び続けてこれたのは意義があると思っています。
web制作のモチベは上がりました！これからもtraPのweb制作の分野に携わっていきたいですね。
quarantineeeeeeeeee
AIって使うのムズいですね！コンテキストとかいうのムズすぎてムズいです。今回の開発では、AIへのアクセス状況がメンバーによって違う中で、AIの恩恵を預かりながらも、アクセス状況による体験の差が少ないような開発方法を模索していました。しかし、最終的に時間が足りなくなって、結局はAIを使える人によるバイブコーディング気味で完成まで押し進めざるを得なくなってしまったのが悔しいです。
本当に役に立つサービスはなんなのか、というような議論はとても盛り上がったと感じているし、AIの使いこなし方の知見も、メンバー同士で色々共有することができました。その一方で、マネジメントとしてはまだまだ成長の余地を痛感しています。これからの集団開発では、良いチーム作りのための考え方などにも力を入れていきたいです。
