前回に続き、NikoNikoLog のモバイルウェブ版の開発の話です。

書かなきゃいけないことはたくさんあって、今整理しながら書いているのですが、ひとまず今回は完全に一般の方より開発者向けな話になってしまうかも。それではスタート。

最初のモック実装、そしてそのモック実装からわかったこと

前回の記事で書いた「iPhone版とほぼ同等の機能、ユーザー体験をiPhoneのSafariでも実現したくなった」を実現するために、次期リリースバージョンの NikoNikoLog は、当初からSPA（シングルページアプリケーション）として開発する方針は決めていました。

最初のモック実装は、Adobe XDで軽く画面デザインを練った後に、開発は実質2〜3日程度で行いました。モック実装とはいえどある程度動くものもできました。また、「iPhone版とほぼ同等の機能、ユーザー体験をiPhoneのSafariでも実現したくなった」の部分もそれなりのレベルでクリアすることができました。

しかしその中で顕著だったのが、ユーザー体験に直結する画面の細かい動きやアニメーションなどの部分、その他にも画面設計上は汎用性があるのに・・・みたいな部分が、どうしても冗長な実装になってしまっていたことでした。また、サーバーとのデータのやり取りはAjaxで行っていたものの、そう言ったデータの扱い方に関してもいくつか問題がありました。

例えば、一度サーバーから取得したデータはブラウザのローカルにキャッシュして使い回す仕組みなど、かなりの部分でもっとちゃんとした最適化が必要であると感じさせられるものでした。

そしてフレームワークを作ることになった

SPAを作るために使えるフロントエンド用のフレームワークっていろいろありますよね。react もあるし vue.js もあるし。react をベースにして material-ui を使うなんて選択肢だってあります。

正直、自社製品の開発以外ならこれらのフレームワークを使う方が生産性も高いし、開発効率もいいと思っています。開発コストも下げられるので、クライアントさんが存在する受託案件で同じようなものを求められた場合、予算が無限にあるような状態ではない限り、これらの既存のフレームワークを使うことを提案していたと思います。

ただ自社の製品となると話は少し違ってきます・・・それはなぜか？

フロントエンドのユーザー体験を非常に細かいレベルでコントロールしようと思うと、既存のフレームワークではかなり早い時点で限界が発生し、それを改善するために既存のフレームワークを改修していった場合、かなりの修正が必要になることがわかっていました。そしてその改修、修正がうまくできたとしても、それ自体が既存フレームワークのいいところを潰してしまう可能性自体も否定できませんでした。

また、ユーザー体験をコントロールするためのコードを既存のフレームワークの改修で対応した場合、そのコードが自社でフレームワーク化する場合と比較して、非常に複雑なものになってしまうことも想定されました。

少し蛇足になってしまうかもしれませんが、誤解を恐れずに言うと、アプリケーションのビジネスロジックやモデリング部分の開発する以上に、フロントエンドのユーザー体験を細かくコントロールするために発生するUI/UX設計とデザイン、開発、テストのコストは実は莫大なものだったりするのです。

次回・・・

開発がスタートしたフロントエンド用フレームワーク。次回はその概要や実際の開発の話などを中心に記事を執筆中です。

また次回の記事でお会いしましょう。