1. はじめに
普段はWEBフロントのデザインから実装までを行っています。
今回社内で自社プロジェクトをやってみようということになり、元々趣味の範囲で作っていたメモWEBアプリを拡張出来ないかと考えました。体制についてはせっかくの機会なので、個人ではなく複数人でのチーム開発にしました。
私の立ち位置としてはUI/UXとプロジェクトのディレクションという立ち位置で動いています。この記事は開発というよりディレクションに近いお話を出来ればと思います。
特に山場や発見がある記事では無いと思いますが、自身の振り返りも含めて丁寧に書いてみました。長くは無いのでサラッと読んでいただけると嬉しいです。
ⅰ. 記事の概要
技術的な内容というより、社内において複数人での開発を進めるフローの備忘録になります。役にたった記事などはリンクでご紹介しようと思います。
- はじめに
- 立ち上げ
- Nostrのはじめましてと初期開発
- 自主開発の立ち位置の再確認
- 振り返りとか
ⅱ. 対象読者
- 少人数プロジェクトの事例に興味があるひと
- プロジェクトの備忘録などを読むのが好きなひと
2. 立ち上げ
立ち上げの経緯としては、社内での自主プロジェクトの一環として立ち上げました。
社内でバックエンドにも興味のあるフロントエンジニアと、開発の色々なフローを経験してもらいたくディレクターにも参加してもらいました。
ⅰ. 企画
当初はバックエンドは専門外なので、個人開発でも使用していた、Firebase（Firestore）をバックエンドで採用して進めようかと考えていました。
ただ、自主プロジェクト立ち上げのタイミングで、Nostrについての記事を目にしました。少し調べるとNostrは仕様定義を行い、実装は各オープンソース・プロジェクトが各自取り入れるという形だと知りました。バックエンドも含めた仕様設計をどうするかが個人的に懸念だったので、『Nostrの仕様と既にあるバックエンドのオープンソースを使えば良いのでは？』と考えNostrを採用することにしました。
Nostrの情報：
Nostrの説明と考えなどは下記がとてもわかり易かったです。
仕様などについては、ScrapBoxが情報が多かったです。
この時の主な目的
NostrではRelayという分散サーバーがバックエンドに相当します。既に世界中にはいくつもRelayサーバーが立ち上がっていたので、自前のバックエンドを立てるよりも、先ずはNostrを理解するためにもWEBクライアント（WEBフロント）を作成することにしました。いくつか既にWEBクライアントも世の中には有ったのでそちらを参考にもしながら、独自のクライアント作成を目指していました。
Nostrのクライアント：
いくつかの記事を参考にSnortでアカウント（秘密鍵）の作成をしてみました。Snortは正直に言うと使い易いとは思えません。これは言語（産地）の問題もあるかもしれませんが、Rabbitの方が一覧性や機能面で良さそうに感じました。どちらもSNSクライアントとしての方向性が伺えます。
Snort:
Rabbit: Rabbitは、自分たちで実装して強く感じたのですが、とても良くできていると思います。
3. Nostrのはじめましてと初期開発
ユーザーとしても触ったことのないところからNostrを理解していくことになりました。
弊社でこれまで関わってきたサービス開発とは大きく違い、Nostrはクライアントにかなりの責務を持たせる思想でした。分散サーバーというのもあると思いますが、基本的にデータの整形などフロントで可能な事はフロントで行うという仕様になっています[1]。フロントを主な仕事の領域にしているので、この仕様は普段との違いも含めて得るものは多いと思っていました。
ⅰ. 目指したクライアント
初期開発として、シンプルなSNS的なクライアントの作成を目指しました。
具体的な仕様としては
- ユーザーのタイムライン
- フォロウィーのタイムライン
- グローバル（登録しているRelay）のタイムライン
- 投稿機能
- テキスト投稿
- リアクション（SNSで言う良いねようなもの）
- リプライ
- ログインはnos2x（nos2xについてはこちら）を使用する
これらの機能をシンプルなUIで表示する事を目指しました。nos2xを使用するのも秘密鍵の生成や管理をnos2xに任せられるので採用しました。これによって開発を機能実装に絞ることが出来たと思います。
ちなみに仕様を読んで初期開発からそもそも外したもの
- 画像投稿
- 画像投稿先を選定するのはテキスト投稿が完成してからとの判断
- 投稿の埋め込み
- 仕様が複雑だったので
ⅱ. 開発
Nipという仕様を調べて、ローカルで実装し確認するという流れで開発は進めました。
既に稼働しているRelayやWEBクライアントがあるので、Chromeの開発モードなどでデータの中身を確認することで、各種の記事情報だけでは理解できない部分の助けになりました。
イベントの発行をするだけのツールや、リレーの情報を確認するツールなど色々なツールも使いつつ、理解と実装を進めました。
任意のイベントを自由に送受信できる開発者向けクライアント
ⅲ. 初期開発の着地
目指した機能自体の実装はなんとか形に出来ました。ただ、Nostrの仕組み上Relay毎の実装に差があったり、ユーザーが登録している多数のRelayの処理など、今回の体制と目的（自主開発）を考えるとこのまま進めても良い形での着地は難しいと判断し、目的を再度考えることにしました。
普段向き合っているUI/UXを向上させようとすると、対処しないといけない部分が多くありました。
下記のスクラップも共感する部分です。
1:nの多数接続なので、色々と工夫が必要なのだと思います。投稿する時にはユーザーが投稿先に登録しているRelayにイベントを送信します。この辺りはBFFなどでフロントと切り離すのも手なのかなと思いました。やはりフロントだけでサクッと、とは行きませんでした。
繰り返しになりますが、その点を考えてもRabbitは良く出来ていると思います。
4. 自主開発の立ち位置の再確認
まず最初の目的としてフロントをメインとした自主開発、というところに立ち返りました。多数のRelayとの向き合いよりも、フロント開発の手軽さと試したい技術の取り込み易さを担保するためにも、リレーは１つ、それも自前で用意したものにすることにしました。
こうなるとNostrである必要は無いのですが、チームとして取り組んだのでそのままスライドする方が良いと判断しました。
ⅰ. 目指す方向性
1:1のシンプルなWEBアプリという方向は決まったので、あとはクライアント側の欲しい機能を追加していく、使いやすくしていく、その際に今まで使っていない技術・ツールを使ってみる、という目的を設定しました。
明確なゴールは設定していません。使用シーンとして思い描いているのは、良い意味での雑なTimes、あるいは掲示板のようなイメージです。
Slack、Notionなど文章を書くシーンはリモートワークが定着したことも有って増えていると思っています。なので、そういったシーンを開発の側から見てみる、というアプローチでなにか得るものがあれば良いなと思います。
ⅱ. 実装・構築
開発は前回のコードとは完全切り替えることにしました。
モノレポも試してみたく、自前のRelay（OSSパッケージを利用）もモノレポに入れています。
UI/UX周りについてもshadcnやtailwindも取り入れて、より実務的にしています。
ⅲ. 現状（WIP）
フェーズ２はプライベートなSNSなので、より通知が必要かと考え導入を挑戦したのですが、結果として今は諦めることにしました。開発のスピードなども考えWEBクライアントを開発のメインに置いているのですが、ブラウザ通知はまだまだ限定的で、デスクトップアプリとしてラップする方法やPWAでの実行も模索したのですが、現状はオーバースペックだと判断しました。
現在はTiptapを導入して、メモ機能の体験を良くしようとしています。
5. 振り返りとか
『なにかやる』という手段を目的として始めましたが、もともと興味があった分野や、新しい技術の実践の場として、ある程度機能していると思っています。
個人での開発であれば、ライブラリのQuickStartなどを１回通すのも手ですが、複数人で取り組む場合は今回のように続ける事が大事だと感じています。
本業の影響で手があまり付けれなくなったり、次に何をするかが不明確になると「枯れて」しまうのはあるあるです。なので、少ないコミットでも良いので、放置状態にならないようにする事が大切な事だと思います。
今後も少しずつですが、育てて行ければと考えています。
参考資料：
Nostrの技術的なZennスクラップ
-
正しくはRelay以外で、という認識でしょうか。BFFで行うものも良い場合があると内部での話に出ていました。 ↩︎
ASTRSK(astrsk.co.jp)は、スタートアップ・新規事業開発に強いシステム開発会社です。サービスやシステムの構築を得意としており、開発をはじめデザインやUXにおいても優れた経験と技術を有しています。
Discussion