リアルタイムメモ共有ディスカッションサービスをひとりで作った作業の記録

はじめてのnoteの投稿です。
今日 meeemo というウェブサービスをつくってローンチしたので、その作業についての記録を忘れないうちに書き残しておこうと思います。

未来の自分に、過去の自分はちょっと頑張ったんだぞということを思い出すための記録として。

文章を書くのは得意ではないので、一人称や文末が統一されてなかったりしますがご容赦ください。

サービスのコンセプト

いつでも、手軽にオンラインでメモ共有ディスカッションができるサービスです。

実際にサービスを使って作った架空のディスカッションはこんなかんじ。

サービスの概要

このサービスについて軽く概要と主要な機能を紹介させてください。

・議題ごとにディスカッションするスペース(ボード)を作成できる
・テキスト、画像をリアルタイム共有
・メモの作成と編集は会員登録なしで可能
・タブレット、スマホでも使える
・サービス内にチャットUIを搭載

ここで試すことができるので、よければ触ってみてもらえると嬉しいです。
https://meeemo.space/boards/yBdYOkjr

サービス開発の動機

以前、10人程度で集まって大きな模造紙に付箋を貼り付けていくというよくある形式でのブレインストーミングディスカッションをする機会がありまして、そのディスカッションを終えたあとに、自分はディスカッションで語った議題よりもディスカッションという行為自体の問題を考えていました。

それは結果を張り出した模造紙をそのままの形での保管することが難しかったり、場所やペンや付箋紙自体の物理的に足りないものがでたり、そもそも参加したくても出来なかったという話があったこと。
「あれ、これ付箋を使うブレストをオンラインでやれたら解決するのでは?」と思って調べてみたところ、高機能なオンラインブレストツールはいくつかあったのだけども、スマホとタブレット操作に対応しているものがGoogleドキュメントのごく一部のサービス程度で、それらもディスカッション用というわけではなく、観測した範囲ではほとんど見つからなかった。

「でも、ぱっとディスカッションしたいときにいつでも持ってるのはスマホだよなー。そうか、ならば作ろうか。」となったのがサービス自体の開発の動機となっています。

正直にいうと、世間一般の人々はそんなにブレインストーミングや付箋を使ったディスカッションなんてしないと思し、そういうことをするITの人々は別のディスカッションツールを使っていそうなので、まぁ鳴かず飛ばずで終わりそうだと、リリースした本日の今の所おもっています。

開発は企画・デザイン・実装 すべて自分

作ってみたら案外規模がでかいサービスになってしまい、月日が驚くほど早く過ぎ去って、これらの作業を全部やったところ当初予想していた工数の数倍の時間(全部の作業を合わせて1人月強)を費やしてしまった。正直けっこう頑張りました。

使用したツール・フレームワークとか

単に慣れているというだけで採用したものもあれば、初めて挑戦するものもありました。

バックエンド
API・ルーティング:CakePHP
リアルタイム通信:node.js (socket.io)

フロントエンド
コンポーネント化:Riot.js 
リッチテキストエディタ:Quilljs
GUI系操作:jQuery+諸々

デザインツール
Adobe XD
Adobe Illustrator

デザイン + 実装 をやっていく

デザインが本業でない素人に毛が生えた程度の自分が「デザインをした」と表現するのもおこがましいのだけれども、そこは勘弁していただきたい。

AdobeXDでイメージを固めていく + 作る

まずはXDで何となくこんなイメージかな・・・というものを雑に描いていった。上の図はだんだん画面イメージのバージョンアップを繰り返しているものです。

この作業は自分の中で作りたいものに対して確立していないふわふわなイメージを視覚化してちゃんと練り上げる作業なので、細かいことはあんまり気にしないでザクザクやっていきます。

このとき、スマホでどうするかもなんとなく想定しながら作ります。

ざっくりプロトタイピングする

なんとなく雰囲気をXDで作ったらマークアップをしてプロトタイピングをしてブラウザで動作させてみます。

ブラウザというのは縦横の大きさが思わぬ大きさだったり、OSによってスクロールバーが出たりでなかったり、タッチデバイスとポインティングデバイスのどっちでも対応できなくてはいけないという、よくよく考えるとシステムを動かすという視点でみるとクソオブクソみたいな環境なわけなのですが、実際にブラウザでざっくり作ったものを動かしてみると「この要素は見た目から意味が伝わらないな」とか「この要素幅が大きすぎて邪魔になるな」とか「スマホのとき操作が詰むな」とかいろいろと気づくことになるわけです。

このとき、XD上ではなく実際にコーディングしてみた結果でもってデザイン側を修正していきます。その作業を経て、それを全体のトーンに反映させていくという作業を何度か行いました。
やっていることとしては一人でアジャイルをしている状態に近いと思います。ものによっては、要素や機能自体をリストラしたり追加したりすることになるので派手な修正や手戻りが出てくることにもなりました。

蛇足的なことを書くと、一人の人間で開発作業をやってもこうやって何度も手戻りが発生するんだから、多人数でやる仕事の開発が手戻りしないわけがないですね。

心の乱れはUIにそのまま現れる

一人でやっているにもかかわらずこのようにぐるぐると修正を繰り返すのにはハッキリとした原因があって、それは「コンセプトがきちんと言語化できていないこと」であると表現できます。

実は、記事冒頭に書いていたサービスのコンセプトや開発の動機の部分はかなり思考整理を経て、余分だったものを排除して言語化したものなので、正直に白状すると後付けに近いんですが、開発当初は「投票できる機能もあるべきかな」「手描きもできるべきでは」「リストのように一覧化して見られるといいのでは」みたいなことや元々のコンセプト的にだいぶ違うことももあれやこれや考えていたりしました。

これは心が道に迷っているという状況なので、何度もやり直したり、考えてもしっくりこないデザインに遭遇したときは、最初に立ち返って「そもそもやりたいことは何なのか・それをやるには超最低限の範囲だと何がいるのか」を自問自答し直して心を整え直して軌道修正していきました。

今回、サービス名やロゴなどもほぼ実装が組み上がってから考えて作成して、それに伴った変更なども行いました。
これについては単純に段取りが悪く、もっとコンセプトを早く言語化できていればこんなに手戻りはなかっただろうと思う半面、つくりながら修正していったからたどり着いたというのも確かでありニワトリタマゴの話とも言えます。

しかし、仕事・業務においては、コンセプトをガッチリ固めることで手戻りが少ない作業フローに乗せることが出来るだろうという想定の改めての学びにもなりました。

技術力の壁の問題と対処方法

見た目がある程度整ってくるとまた別の壁がでてきます。

悲しいことに自分は卓越した技術があるスペシャリストタイプのエンジニアではなく、会社員時代とフリーランスになった今をあわせて、もう10年以上エンジニアとしてやってきてはいるものの、生来の雑な性格も相まって「俺は雰囲気でプログラミングをしている」みたいな感じのレベルなのです。

そうなると、何が起こるかといえばやりたいけど自分の技術レベルでは開発できないことに遭遇することになります。

その問題に自分だけの状況で立ち向かう方法は色々と存在します。

まず非常に泥臭い方法としては単純な努力。昨今の世界は素晴らしく、たいていのナレッジは検索すれば見つかるので、あとはそれをもとに自分で問題に対する答えを組み上げるというアプローチです。

もうひとつは実にふつうな方法で、オープンに公開されているライブラリやフレームワークを使ってやりたいことを解決するということです。
今回は大抵の問題はこのアプローチで解決ましたし、これを前提にしていました。改めて言うほどのことでもなかったですね。
余談としまして、仏教の言葉に「お陰様」という言葉がありますが、タイトルに一人で作ったとは書いたものの、このように陰ながら多くの人々に支えられて作られています。話を戻す。

今回、オープンソースによる実装課題解決を前提にするにあたって、Riot.jsをコンポーネント用フレームワークに採用したのは、単に自分が好きだからというところもあるけれども、提供機能も実装も非常にシンプルで、他のライブラリと共存させるときに不都合が発生しづらいと見込んでいたからでもあります。
見込んでいただけでちゃんと確認して作業したわけではないけれども、実際に組み合わせによる問題は起こらなかったです。Riot.jsはいいぞ。

妥協点と自分の正義としての持論を用意する

技術的問題の部分について書いたとおり、自分自身はイケてない系エンジニアなので、かなりRiot.jsとjQueryとCakeをキメラ化させてしまっており、まともなエンジニアに読ませたらブチ切れられそうなソースコードが出来上がっています。イケてないなりにそのぐらいの自覚はある。

しかし、まずは動くことこそが重要なのだと思っているし、一人でやれることの限界があるので、コードの品質についてはある程度のところで妥協するスタイルをとっています。
そして、重要なこととしてはコードがいくら美しかろうと使う人には関係ないのです。保守などの都合でコードの美しさが必要なら、美しくある必要が求められてからいくらでもリファクタリングすればいい。まずは動けばよかろうなのだ。

動作確認をする

ここで初めて人に頼った。
この話は別途改めて記事を書きたいのでここでは割愛する。

公開準備をする

この段階までくると日々熱に浮かされたようにそわそわしており、後頭部がじんじんし、舌に痺れを覚えるクリエイター・ハイとも言える状態になります。そんな言葉があるのかはわかりませんが。

このとき、非常にそわそわしてしまい焦っていたのですが、サービスを乗っけるさくらのVPSの設定がうまいこといかず、逸る気持ちに任せてOSの初期化をしてやり直ししていたら、うっかり以前作った別のサービス(匿名でTwitterに発言ができるようになるというもの)を可動させているサーバーをリポジトリごとOS初期化してしまうという完全にバカとしか言いようがないことをやらかしてしまいました。今こうして文字にして書き出してみても改めて愚かだなと思うけれども、自戒のために記録しておきたい。

サービス公開するための作業で後悔が発生してしまったのです。

クリエイターたるもの、いつでもCoolにいなくてはいけないのだ…。ある意味、今回の開発で最大の学びになった部分かもしれません。

公開した

そして公開したサービスが https://meeemo.space/です。
自分が欲しくて作ったものが、少しでも誰かの役に立てばいいなと思います。

余談ですが、今回開発を構想した当初(4月前ぐらい)は仮想通貨マイニングをこれに導入してどうなるか試してみようと思っていましたが、現在それを気軽に試すことは難しくなってしまいました。広告にかわる個人サービス運営の収入としての希望を見出していたため、coinhiveを巡る今後の展開については非常に気になっています。

また、今回の記事では実装に関する細かいことなど、端折ってしまったこともいっぱいあるので、次回は今回の経験を通して学習できたことなどについて、また改めて記事を投稿したいと思います。
ここまでお付き合いくださり、ありがとうございました。

16

ampersand_xyz

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。