揚げログ

Karaageの活動報告とメモ

もう一つの修士論文。「大学院生活8割費やした個人開発の全てを振り返る」

今回は、長文コミュニケーションサイト Letero | 紡いだ言葉を、通わせる。 について語りたいと思う。これは、完全な個人の趣味でやっている、いわゆる個人開発である。一時期はこれで起業も検討したが、私個人の情勢の変化により、現在は趣味兼副業として細々とやる方針で進めている。ただ、自信のあるプロジェクトであることには間違いないので、かけた労力と払った犠牲の分、良いものに仕上がっていけば良いと思う。

はじめに。作ってるサービスの概要

Leteroは、自分の好きなことや推してるもの・人、また社会に対して感じることや、日々思ってること、このようなあらゆる「日々思ってるけど人にわざわざ話すにはちょっと重い」みたいなことを投稿できるサイトである。

このサイトの特徴として、投稿に対しコメントではなく投稿で返信(返書と呼んでいる)をすることができ、投稿者は自分と同じ熱量熱意、温度感で書かれた他の人の意見や見方を得られる可能性がある。

letero.jp

まず、このプロジェクトは3回の大きな変化を通り越して、今の「長文コミュニケーションサイト」という主題に至る。初期は、「時系列にニュースが追えて一次ソースへのアクセスが容易なキューレーションサイト」であった。第2期は、「エビデンスベースのディスカッションサイト」であった。そして第3期は「思考のポートフォリオ」、さらに現在は「長文コミュニケーションサイト」である。

ただ、インターネット上に質の高い情報が集まる場所を作るという目標は一貫している。

がむしゃらにインターネット上の課題解決に向かって突っ走ってた黎明期

当時、インターネット上・マスメディアを通した情報流通に対して、いろいろ思うとこはあった。当時目指していたサービスで提供したかった「良質な情報」の定義は、このようなものであった。

Topic Note が求める良質な情報とは

インターネット上に流通する全情報を追うのは不可能である。

インターネットユーザーの多くは、SNSやキュレーションサイトを主な情報取得窓口としている。

これらのサービスから情報を得るとき、ユーザーは自ずとコンテンツ自体や発信元にフォーカスさせられる。 一方で、物事の流れや繋がりへのフォーカスは薄くなる。

そこで、Topic Noteでは、情報内容に着目し、ユーザーにその繋がりと所拠を見せることを重視し、これをもって情報を良質と定義する。

初期 一次ソースの自動まとめサイト TopicNote (2018.11~2019.06)

フェイクニュースの問題やマスコミへの不信感がネット上で見られるようになり、極力発信者のフィルターを通さず、情報を”トピック”に束ねていく(自動で)というサイト・アルゴリズムの開発を行っていた。 具体的には、Pythonで作成したスクレイピングプログラムで、ニュースサイトをクロールし、取得したテキストをDoc2Vecでベクトル化する。そして各ニュース文のベクトルの内積で内容的な近さを数値化し、同一トピックを判定する。 実際には、もう少し複雑なアルゴリズムであるが、ここではこの程度に留めておく。

f:id:krgpi:20210121212416p:plain

ところが、皆さんもご存知のように、特に”トピック”単位でネットニュースが時系列でまとめて見られる機能は、Google, Twitterに完全にやられてしまったので、方針転換をすることにした。この時は、機能やサービス内容が完全に新しいもので、世界のどこにも似たサービスがないことに、特に拘っていた。新しいことがやりたかったのだ。 また、私は実装面でサポート、また理念に共感しプロジェクトの成功に尽力してくれそうな人を集める目的で、あらゆる人脈を駆使し最大6名のチームメンバを抱えたが解散となった。

2期 エビデンスベースのディスカッションサイト (2019.09~2020.01)

まず「インターネット上に質の高い情報が集まる場所を作る」というミッションは変えていない。私がこの時期に着眼していたのは、TwitterやYahooニュースのコメント欄が、大体荒れ放題になっていることだ。そこで、次のような目標を当時掲げていた。

Topic Note が求める良質なコンテンツとは

インターネットが普及しコンテンツが多様化したたことで、ジャンクな情報が増えた。日々、ネット上では恣意的なまとめ記事や釣りタイトル記事が量産され、また炎上や荒らしが横行し、ネットユーザーを消耗させている。時事関連ではこれが顕著に見られ、問題の本質を忘れ感情に任せて個人に対する罵倒や根拠のない批判を浴びせる人が少なく無い。

特に、SNSやキュレーションサービスのコメント欄でしばしば見られる、荒らしや誹謗中傷、恣意的な意見などの低質な投稿は、投稿の敷居が下がったことによる弊害とも言える。一方で、建設的な議論を展開しようとしたり、エビデンスベースでの主張や客観的な立場に立った批判的検証を行おうとする人もいる。

そこで、TopicNoteでは、インターネット上に、情報源を明示・客観性を維持した情報が集まる場所を作り、また建設的な議論をしたい人が集まる場所を作る。

そうすることで、仮に恣意的な論調が展開されたとしても、多角的な視点からエビデンス付きで反論や批判、または検証が入るようになり、議論自体が良質なコンテンツ足りうるようになると考えている。

このように、インターネット上に、情報源を明示・客観性を維持した情報が集まり、建設的な議論をしたい人が集まる場所を作ることで、ネットユーザーに対して、少しでも物事を考えることに関心を与えたり、そのきっかけを作りたいと考えた。

そこで、インターネット上に「エビデンスベースのディスカッションが出来るサイト」を作ることを目標にし、実際これは完成まで漕ぎ着けた。ほぼ1ヶ月でFirebase+Nuxt.jsで実装し認証にはFirebase Authenticationを使った。APIはGo langで実装した。フロントエンドに全く触ったことない状態から始めたにも関わらず、実質30日程度で完成させてしまったのは、驚異のスピードであり、私としても人生で何番目かに入る集中力を発揮していたと思う。

f:id:krgpi:20210121212314p:plain

サービス概要は、

議論を必要とするあらゆる話題を"トピック"として立てられます。議論は"ディスカッション"で、"エビデンス"ベースで行うことができます。 であった。これは、誰かが問題提起や主張を展開する"トピック"に対し、他のユーザーがディスカッションを付ける形式であった。

このロゴは、知り合いのデザイナーの方に依頼し、作成していただいた初期ロゴである。 さらに、「建設的な議論が積み上がっていくイメージ」でアイコンも作っていただいた。

f:id:krgpi:20210121212503p:plain

しかし、ここまで実装して、サービスの展開を考えた時に、ユーザーにとりディスカッションやトピックを積極的に投稿するインセンティブに欠けることに気付き、改めてサービス内容について見直す運びとなった。

Makers応募

2期のディスカッションサイト"TopicNote"の実装が大詰めを迎えていたころ、私としては実装が終わった後のことを考え始めていた。企画・開発はすでに経験したことがあったので、特に迷うことなく進められたが、その後実際、運用・スケールしていく事に関しては、無知の状態であった。このサービス形態は、少なくとも投稿ユーザーがいない事には何も始まらないので、ユーザーを増やすことは非常に重要である。この辺りの知見を求めると同時に、プロの視点をいれることでサービス内容をより良い方向に改良し、最終的にはスピード感を持ってスケールしたいと考えていたため、MAKERS UNIVERSITY第5期生の応募をし書類審査が通ったので面接まで行った。 Makersの説明会では、非常に大きな刺激を受けることができた。説明会に来ていた15名ほどの参加者の自己紹介を聞いたが、多くはプロジェクトの立ち上げ、ミッションやビジョンの設定、資金調達といった企画的な部分を得意とする、または強く希望してやっていきたい人であった。一方で、対象とする領域は実に多種多様であった。このような人々とお互いの成功に向けて切磋琢磨することは、間違いなくお互いにとってプロジェクトを前推し進める原動力になるし、同年代の同じような考えを持った人々が持つ、自分とは別の視点を知ることができると考えていた。しかし残念ながら落選してしまった。

主に、TopicNoteの具体的用途やユーザーのインセンティブなどについての回答が詰まったような気がした。これまでも自信がない選考は大体ダメだったので、特に驚きはしなかったが、スランプには突入してしまった。

ビジネスモデルやデザインの勉強をしていった時期

ここまでは、かなりやるぞっという勢いだけで進んできた感じがあったが、初期の勢いが少しずつ衰えていた時期に差し掛かっていた。また、開発がひと段落したこともあり、ユーザーをどうやったら集められるか、ということを本気で考え出していた。本来であれば、これは開発するよりも先に考えるべきことだと、今となってはそう思うが、当時は開発コストを非常に重く見積もっており、とにかく大まかな構造を作ってしまってから直していけばいいという考えで進めていた。ここからは、ユーザーがサービスを利用するインセンティブをどう作るかを議論したことや、ビジネスモデルやデザインについて勉強したことについて記していく。

3期 TopicNoteからIdeoj ~思考のポートフォリオ~ へ

TopicNoteは、「エビデンスベースでディスカッションができるサイト」であったが、ディスカッションを書くことでユーザーが得られる直接的なメリットが見えてこなかった。つまりインセンティブとしては物足りない感じが拭えなかった。要は、これ誰が使うん?という状態になってしまったということだ。 そこで、様々なトピックについて自由に考えを表明・議論することが出来るディスカッションサイトであるというベースを維持しつつ、ライターが議論を通じて自分の考え・立場・意見を発信することができ、またそれらの集積して自分のスタンスをまとめた「思考のポートフォリオ」を作れる機能を新たに設けることとした。これにより投稿者がポートフォリオを充実させられるというインセンティブを持つことで、より良質な投稿を多数行うことが期待できる。また、読者は投稿者のポートフォリオを確認することで、投稿がどのようなポジションから書かれたものか、どのようなバイアスがかかっている可能性があるか、などを知ることができる可能性がある。 このような流れもあり、サービス名を変更することにした。新しいサービス名は「Ideoj(イデオ)- 思考のポートフォリオ」である。Ideojはエスペラント語で”考え”の複数形で、正しい読み方はイデオイであるが、語感を考えてイデオにすることとした。

デザインコンセプトの決定

サービス内容が具体的に決まったことをうけ、オリジナルな配色やテーマ作り、適用することとした。サービスの個性をより前面に打ち出す目的がある。フォント選びなどもここで行った。Ideojは、多様な視点から書かれるバイアスのない良質な読み物がたくさん集まるサイトにする予定である為、「活字で打たれた英字新聞」のようなテイストにすることが決まり、同時にデザインプロトタイプの作成が始まった。

まずはミニマルサンプルを作った。読み物としてのページにすることを非常に重要視したため、フォント選びや行間、一行あたりの文字数などにも相当こだわった。

Ideoj Design Test

このサンプルページは非常に構成要素が少ないが、長文の読みやすさという観点において、かなり調査・研究した結果となっている。また、そのほかのページ内要素の配置や配色などについての試行錯誤は、この辺の記事に残ってる。

agelog.hateblo.jp

agelog.hateblo.jp

とりあえずのリリース

2020年4月29日、世の中が自粛でまさに大変だったとき、ようやくリリースにこぎつけた。それに伴い、サービス内容を説明する動画や、サービスに沿った記事を同時に作成した。当初の予定では、YouTubeチャンネルは答えのない議題に対して2人で様々な観点からディスカッションする様子を配信し、視聴者の意見をサービスに投稿してもらうことで、サービス利用者の流入を目指す目的があった。

https://youtu.be/BinuBVsE3RY

特にお気に入りの記事(友人が作った)を貼っておく。

letero.jp

この記事を元にしたディスカッション動画も作った。

https://youtu.be/A0TwAT3c2Gs

4期 Ideojから長文コミュニケーションサイトLeteroへ

とりあえずのリリースをした結果、さまざまな方からフィードバックをいただくことができた。ここで多かったのが、他サービスとの差別化が見えづらい、ということだった。また当時用意していたサンプル記事も、意見表明的なものが多く返書(レス)を付けづらいものだった。つまり、長文を通じたコミュニケーションが生じて欲しいというサイトの目的が達成されていないことが明らかとなった。

そこで、開発チームでは、コミュニケーションとしての長文を書いてもらえるようなアフォーダンスをどうサイトにつけていくか、という議論を機能面と外観面で行った。

外観面

外観の面では、ボトルレターを世界観とすることにした。投稿をレター(手紙)に見立てたとき、それはボトルレターのようなものである。ボトルレターを放流する側は、宛てのないメッセージを手紙に込めるだろう。我々のサービスでは、文章を投稿するだけではなく、そのさきのコミュニケーションまでユーザーにして欲しいという願いがあり、それには投稿側に受け手を意識してもらう必要があることから、このボトルレターの概念がサービスの理念と合致した。

機能面

インタフェース・webデザインの勉強

正直これまでは、他のサイトの構造や見た目を自分なりに噛み砕いたり分析してデザインを行っていたが、ここにきて何冊か書籍を買い集め、開発メンバーで読み合わせた。

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

  • 作者:Robin Williams
  • 発売日: 2008/11/19
  • メディア: 単行本(ソフトカバー)

これにより、デザインを考え出すところから実装するまでの流れがかなり効率的になった。まだユーザーがほぼいないこのサービスにおいては、期待するユーザー行動を考えるところからデザインを行った。

f:id:krgpi:20210121232150j:plain
期待するユーザ行動の設計メモ

さらに、デザインとしては非常に基本的なことを多々学んだ。また、心理学の観点からインタフェースについて考察された本も大変参考になった。

特に、以下の3点は機能や外観の設計を見直す上で、非常に重要な指針となった。

  • 情報は少ないほどきちんと処理される→トップページ、返書一覧ページ、LPなど
  • 脳の処理の負荷→投稿フォーム、ユーザー設定変更、各所インターフェース
  • 人は物語を使って情報をうまく処理する→leteroのコンセプトの訴えかけに使える?

これはトップページの設計を行なった際のメモである。左側に貼ってあるスクショは改修前のトップページであり、それに対して右側のメモでは書籍から得た知見をもとに色々改善案を出している。 f:id:krgpi:20210121233847j:plain

そして、出来上がったデザインがこちらである。

f:id:krgpi:20210121234510p:plain

投稿のページもこのようになった。上の方に貼ったプロトタイプで策定した一行あたりの文字数や行間などが維持されつつ、サービスの世界観を伝える配色(やや深みのあるオーシャンブルー・砂浜をイメージした砂色)や、長文コミュニケーションの要である右カラムの返書の一覧などが追加された。

f:id:krgpi:20210121235252p:plain

ビジネスモデルキャンバスの勉強

私が大学院の夏の集中講義でたまたま受けた講義で、ビジネスモデルキャンバスとターゲットキャンバスを知った。簡単にいうと、自分たちが持っているリソースや使える手段を、顧客が抱える悩みや痛みに対して、どのような方法や形態で提供するかを整理できる表みたいなものである。ここで重要なのは、単に悩みや痛み(pain)を解決するだけでは、継続利用につながるか、また競合に勝てるか、という点でビジネスモデルとしては要素が足りないということだ。付加価値(ユーザにとってのgain)をつけることが、特に似たようなサービスがある場合や、自分のサービスのファン(継続利用者)を増やしたい場合に有効になる。

当然、我々のサービスに対しても、painとgainはなんだろうかと考えた。例えば、painについてはこのような結論を得た。

f:id:krgpi:20210121231449j:plain

改めて考えると、消費スピードが早いことをユーザー側がどの程度痛みとして持っているのかは疑問符がつくが、ここでは今後のサービス開発の方向性をある程度打ち出せた。

参考にした本

現在と今後について

開発メンバーが修論で忙しくなってしまい、2020年9月から活動が休止されている。

個人開発で得たもの

Nuxt.js, Go, GCPへの理解

欲しい機能や見た目を実現するために、1からコーディングを行った。自分のパソコン上では正しく動いているのに、サーバーにデプロイしたら動かなくなるとか、見た目が崩れるとか、フロントエンド開発ではあるあるなのかもしれないが、この辺が原因が特定できなかったりして一番大変だった気がする。データベース設計やデータ構造の策定なども、非常に多くの考慮すべきことがあり、苦労した。また、今回汎用プラグインでは目的が達成できなかったため、レター投稿のエディターを自作することになり、これもまたかなり複雑な実装を必要とした。

f:id:krgpi:20210122001106p:plain

プラットフォーム運営の難しさへの理解

ビジネスを考えること、企画することの楽しさ

この企画で学ぶことになった、ビジネスモデルキャンバスはビジネスに限らず様々な分野に応用可能だと思う。例えば人と人との関係構築や就活に使えると思う。自分の持っているもの(リソース)を相手に提供する方法や形態は、相手のpain, gainによって最適な形があるだろうし、それを目指すことでwin-winの関係を作れると思う。

チーム作業の楽しさ

この開発、費やした時間の8割くらいは企画練りやサービス内容、つけるべき機能やデザインについてのディスカッションだったような気がする。やはり、自分が持っていない観点からの意見が得られること、自分が知ってるつもりだったことが相手から聞かれたことで、実はちゃんと勉強したことがなかったことに気づくことがあったりと、語り尽くせないほどチーム開発におけるディスカッションでは得るものがあった。また、先が見えない・分からないことを勧めるのはとても不安なことであるが、あらゆる段階で他人視点のチェックが入ることで、サービスが目指している姿とやろうとしてる実装やデザインそして企画がズレてきてないかを、常に確かめて自信を持ちながら前に進むことができた。