大学サービスを4年運営した
2023年今年大学を卒業した hikaeです。 かわいい後輩たちも、既におじさんです。
1年生の終わりから5年生まで、大学生向けのサービスを運営して感じた大学サービスを運営してみる良さについて語っていこうと思います。
自分がやったこと
自分が制作・運営したのは「筑波大学生専門の時間割 Twin:te」です。 当時、筑波大学の特殊な時間割に対応・データ連携できる時間割がないことから、開発がスタートしました。
たこなす(Twitter: @ITF_tako)のプロトタイプをユーザーが使いやすいようにデザインしてリリースしたのが2019年です。 その後、ユーザーが増えるたびにリデザインを繰り返し、今のアプリがV3(2021年~)です。 細かい話は公式ブログに任せます。
自分はフロントエンドとチーム開発の管理を責務としていました。 特にフロントチームは、サーバーのマイクロサービスのように完全に独立した設計でなかったため、複数人で同時並行に開発ができるように工夫したりしていました。*1
権限を委譲する
さて本題です。Twin:teはありがたくも4年目を迎え、順調に引き継ぎが行われています。 どんなに時間をかけても金銭的メリットのないこのコミュニティ。なぜTwin:teが4年目を迎えることができたのか。
サービスを同級生で作ることはできても、それを後輩や新規メンバーに受け継ぐにあたって一番大きな壁は、当事者でないことです。 既にあるサービスに新たな機能をつけようと考えた場合、これまでの遺産を作った人たちの合意が壁になってしまうと思います。 「このプロダクトは自分たちがつくった」といえる状態になれば、新しい意見や開発のモチベーションも出てくると思います。
例えば、自分は後輩*3に対して、ページ単位で機能ごとに全て任せました。HosokawaRは検索ページをすべて作っています。 この状態にしたことで、「この機能は自分が一番詳しい」といった当事者意識が出てくると考えました。
二人とも当事者意識が高く、もともとの性格もあると思いますが、ある程度は寄与していると考えています。
判断をコミュニティに委ねない
コミュニティが大きくなると勝手に動くことができなくなります。こういった時必要な過程が合意形成です。 例えば、大規模なアーキテクチャの変更を行おうと思ったとき、毎回の判断をミーティングやチャットで話していたらメンバーが消耗してモチベーションが下がってしまう原因になります。 合意形成で望ましいのは、作っていいか相手に聞くのではなく、プロトタイプを作った段階で合意を取ることです*4。 自分は4つのサークルに入っていましたが、ミーティングでコミュニティに判断を委ねる習慣ができてくると、真面目な人が消耗する悪循環に陥ると感じました。
営利目的でサービスを作らない
まずは、自分たちのサービスのマネタイズについてです。 Twin:teは寄付を募っており、そこからサーバー代やApple税などの諸経費を払っています。
自分としても、この形式がもっともよい状態だと思います。 いろんなアプローチは考えているのですが、Twin:teの作りたいものを作りたい人がつくるというスタンスが好きなので、今の現状が成り立っている内は変にマネタイズするといった進路変更はないです。
サービスを作りたい人の場合、個人開発やベンチャー立ち上げもよくあるでしょう。これらにないメリットとして、
- 活動がある程度パブリックなので、人の目につきやすい
- 大学サービスは攻めている市場が小さく、ブルーオーシャン
といった点がいいと思います。大学サービス発で天下を取ろうとしている〇〇〇ー〇などありますが、最終形態がSNSではすぐに消え去ると思います。大学サービスは非営利団体*2のモデルを踏襲することが望ましいです。
メンバー募集は受け入れて満足しない
これまでの要因を振り返って、新規メンバーを受け入れるにあたって重要なことは、同じモチベーションを持った人がモチベーションのあるうちに当事者意識のできるものを持つことまではコミュニティ運営者の責任であるということです。採用において、自分たちは同じような考えの人は全員受け入れてきました。自分たちのサービスの裁量権を新規メンバーに与える勇気と責任があって初めて採用が機能すると考えています。 そう考えると、初期の段階での採用は、与えられる役割の数だけ採用するのがとてもよいです。僕たちは総務あたりに役割がたくさん残っていますよ。
Twin:teの今後の目標は?
Twin:teはサービスというよりコミュニティというのが正しいですね。Twin:teコミュニティが今後どうなっていくかは、現メンバーしかわかりません。今後増えるメンバーがコミュニティと共に成長して、思いもしないようなコミュニティになってほしいと思っています。引き続き、サポートだけしていく所存です。
参考文献
- 学習する組織
- ティール組織
Every Noise at Onceの使い方
論文も読めるようになりたい
今回は暇人のための音楽検索サービス「Every Noise at Once」とその使い方についての記事です。好きな音楽ジャンル見つけてみませんか?
Every Noise at Onceの機能
ジャンルベクトル
Every Noise at Once(以下everynoise)は見てわかるように音楽のジャンル毎に検索できるサービスです。
面白いのがジャンルがめっちゃ細かいです()
これらの情報はSpotifyのデータが利用されています(なのでSpotifyユーザーだとさらに便利)
ちなみに左右上下の意味はあまり気にしたことないです。なんとなくのベクトルが貼ってあるので近くを見ると趣向が近いものを見ることができます。
ジャンルごとの歌手
ジャンルをクリックすると歌手のベクトルが可視化されて出てきます。
ちなみに左右上下の意味はあまり気にしたこと(ry
知っているジャンルでもたまに知らない人でてきます
プレイリスト
これが結構いいかんじです。
左から「すべてのプレイリスト」「入門プレイリスト」「さらに知りたい人向けのプレイリスト」「オタク向けプレイリスト」「今年度のプレイリスト」って感じにあるので入門プレイリスト(Introってやつ)を聞いてみるとジャンルについて完全に理解できます。
その他
アルゴリズムやこれらデータを使ったその他機能はこちらに乗ってます
https://everynoise.com/#otherthings
まとめ
雑な紹介だけど使ってみた方がわかりやすいかも
振り返る 2021
やってなかった
コミュニケーション年間
コミュニケーションをスキルと慣れで克服する。
名前伏せるけどビジネスコミュニティやエンジニアコミュニティなどに参加するなど。 内向的性格とコミュ障の違いを押さえたら楽になった。
しばらく時間を空けちゃうとコミュニケーション能力が著しく低下しちゃうので、まだまだ。 慣れでかなり良くなることが実感できたので良かった。
チーム開発
円滑な開発を目指した。 積極的にメッセージ送るという珍事を行いコミュニケーションを活発化させようとした。
同時にスクラムマスターも取得した。 更新までに徳(Scrum Education Units)をつむ必要があります。LTしなきゃ。
副産物として就活を有利に進められました。
起業
新しい働き方を実践する。
まずはフリーランス(個人事業主)から。めんどくさいことはfreeeにやらせよう。6月から開始。4案件ほど(継続含む)
思ったより早く始められた。初案件までに3か月を要した。 大学生だとコミュニティがデカいので人づてでの紹介がしやすい。
顧客目線でプロジェクトの成功に並走するには何度もコミュニケーションをとることが重要。 相手の解像度を上げ、必要なところにコストをかける。
実際にやると、学びに良い。 周りも個人事業始める人増えてうれしい。
確定申告(3月)まで結果を待ちましょう。
やること 2022
テーマは「分」
去年の「分散」から発展して、新たに「分配」を加えた。
国民全員に資産分配するより、コミュニティへの分配のほうが実現しやすい。 分散化によって分配が可能になることで、生産性の向上を目指せると考えられるからだ。
DAO(自律分散型組織)はベースとしてかなり有力。 表のシステムとしては、ホラクラシー型組織が面白い。最近日本のスタートアップでも採用が目立つ。
「中国の共同富裕」と「岸田政権の新しい資本主義」、「欧州のBI」を参考にしている。
非同期コミュニケーション
じゃあ何やるねんのところは、「非同期コミュニケーション」。
「去年コミュニケーション年間」と称していくつかのコミュニティーやイベントに参加した。 慣れの分野だと思うので、非同期コミュニケーションに関しても同じようにやっていきたい。
非同期コミュニケーションのメリットは時間の制約がないところ。
非同期コンピューティングもシステムの分散化で生まれたものだと思うし、 Twitterのドーシー氏退任もあって分散SNSは今年少なくとも話題になると思う。
月1でやってみた系ブログを書くようにする。
今の雑魚文章からどれだけましになるのかを実験する。
エッジサイド
先駆者から一年ほど遅れたけどやっていく。
2020年あたりから、フロントエンドの再定義が流行した。 UXの観点からみると、SSR、エッジサイド、BFFといったサーバーサイドよりな分野もフロントエンドが役割を持つと考えている(僕はUXエンジニアと呼んでいる)ので最近やっている。
Cloudflareが神。同時にプラットフォーム非依存によるPaaSの分散もやっていく。
このあたりが極められれば、マイクロフロントエンドにも手を付けられそう。フロントをプロジェクト毎に「分ける」技術。
メンズメイク
パーソナルカラー、顔タイプ、骨格診断、、、 何もわからん!
やるぞ!
一番伝わりやすい表面から自分の個性を出せるように。
最近スキンケアをハトムギ(ナチュリエ)に変えた。
参考文献
www.slideshare.net
GitHubスポンサーで支援してみた
きっかけ
いつものようにGitHub見てたら、めっちゃおしゃれなREADMEがあったんですよね。 まあ、いつも見ているページなんですけど、インターン先(*1) がOSSへの寄付に結構積極的でそういった話していたので僕もやってみようかと思いました。
過去の寄付歴
といっても以前にも複数のプロジェクトに寄付したことがあって、少額ながらもOpen Collectice使ってました。
vue, Nuxt.js, rust-analyzerの3つですね。 Facebook由来のReactなどと比較するとコミュニティー駆動なプロジェクトで、当時は結構お世話になってました。
ちなみに支援やめた理由は、Vue使わなくなったからではなくちょっと大きな自己投資しちゃった分の節約なんですけど笑。 学生だからしょうがないね
github.com ↑自分のOpenCollective歴
GitHubスポンサーつかってみた
GitHubはよく使うSNS(*2) なので気軽にアクセスできるのはいいですね、サムネみたいに1ドルの寄付だけでバッチを獲得できます。
今回支援したのはVue, NuxtのコアメンバーでおおくのOSSを持っているantfuさん。
Tailwindcssを高速化したWindicssや、スライドをvueとマークダウンで作成できるslidevなど、フロントエンド技術の最先端を走っている感あります。
みんなも気軽につかってみては?
プログラミング書いた人であれば絶対にお世話になっているOSSがあるはず(書いたことない人も) ってか機械さわってたら全てに入っているので、ちょっとみてみると面白いかも。
このサイトみてみたら、僕のコードだけで2.5kのプロジェクトに支えられているらしい!恐ろしい!
*1 株式会社HERPに長期インターンしている
筑波大学のシラバス閲覧アプリをつくった
目次
はじめに
夏なのにサマーインターン受けなかった @ITF_hikary です。 さて、今回はシラバスっぽいなにかを作ってみました。以下からログインなしで遊べます。
↓↓
はじめに使い方について説明したあとに、 今回の開発に至った経緯と、どのように開発を行ったのかについてお話できればと思っています。
どういったアプリ?
このアプリは筑波大学で履修できる授業を検索し閲覧できるようにするアプリです。 追加機能として、授業に対して★星レビューができるようになっています。(Googleログイン)
ログインして授業評価できるようになりました!アルファ版として公開してるのでどうぞ https://t.co/Kh3yPd37q8 pic.twitter.com/JIdu8KxLI7
— hikae (@ITF_hikary) 2021年8月20日
開発に至った経緯
授業情報であるシラバスはkdbを通して閲覧することができます。しかしこのkdbは処理が重く、変わりのアプリとして「kdbっぽいなにか」っていうプロダクトをみんな使っている現状です。
このアプリではシラバスについてはとくに何もしてないのですが、シラバス自体もかなり不便です。 多くの人がいまだに紙の履修要覧を利用しているのではないでしょうか?
具体的には東京大学の履修検索システムでは、マイリスト機能(kdbっぽいなにかにある)などwebならではの機能がついており、履修仮組に便利です。
こちらは有志によるものですが、立教大学ではレビュー機能、オススメ授業レコメンド、チャットなどSNSを利用した履修をさらに強化する機能がついており、とても便利です。
シラバスページをおしゃれにして、シンプルなレビュー機能をつけてみたら便利になるのではと思いアプリを作成してみました。
開発過程
今回のアプリは3日(2日目にリリース)で実装しました。
1日目の段階でシラバスが表示できるようになり、 2日目には検索機能とレビュー機能を追加してリリース。 3日目はアルゴリズムの修正による高速化のみを行っています。
今回のアプリはフレームワークとしてNext.js(React)を採用しており、Vercelにてホスティング、Firebaseをデータベース、認証に使っています。
Next.jsについて
Next.jsを採用した背景としては、SSRによるAPI機能によりバックエンドを統合した開発を行おうと思ったからです。ホスティングにVercelを利用しているのもそのためです。
テンプレートとして、先日作成したRSSリーダーのプロジェクトを用いて開発を行いました。
Vueとの比較
vite(vue3)と比較すると、Firebaseをクライアントで操作する場合はvueのほうが使いやすかったしホスティングもFirebaseにまとめやすかった印象でした。
@vueuse/firebase
で一貫した開発ができたのはとても良かったです。
さいごに
レビュー機能は荒れる心配があるので、ちょっとだけためらいがある印象です。 ユーザーの声を参考に便利な機能を増やしていくのがいいと考え、機能を最小限に抑えたリリースを行いました。(MVP) この記事を最後まで見ていただいた方にはぜひアプリを触っていただけたらいいなと思います!