ども、@kimihom です。
先日、私の運営するサービスでカレンダーUIの機能をリリースした。開発ストーリー的な話は以下の記事でオフィシャルに記載している。
今回のリリースは視覚的に説明しやすいので、本記事で技術寄りの内容を記すとする。
カレンダーUI の概要
まず今回の実装した概要を動画としてキャプチャしたのでご覧いただきたい。
この機能の特徴として、以下のような点が挙げられる。
- 1日だけでなく複数日にまたがって斜めスクロールができる
- 削除は1日ごと
- 収縮が可能
- 1日で複数の期間を登録
- 一括で上書き可能
- 期間を各エリアの最上部に表示
このようなドラッグ&ドロップして期間を選択するUI を実現したいとき、あなたならどういう方針で開発を進めていくだろうか。
こだわりがあるほど自前実装
ほとんどの場合、まずはオープンソースのカレンダーライブラリを探すことだろう。自分のやりたいことに近いライブラリがあれば、そのライブラリを読み込んでちょろっと初期設定をすれば完成だ。そんな最適なライブラリがあれば良いのだけど、今回のこだわりUIでは以下のような特徴がある。
- "祝日"を含めた週間表示だけ
- 一括選択と一括の上書きができる
- 削除は一括ではなく1日ごと
ほとんどのカレンダーUIのオープンソースでは、Google Calendar を目指した月間・週間・デイリー表示の3パターンのUIがあったり、祝日の列を追加することが考慮されていなかったり、予定を追加・編集するためのウィンドウといった余計な機能があったりする。そもそも、こうしたカレンダーのオープンソースの目的は "予定を入れるためのUI" だ。今回の "営業時間を設定するUI" とは根本の目的が違う。
にも関わらず、強引にオープンソースだけで乗り切ろうとすると悲惨な結末が待っている。初期設定のカスタマイズで済めば良いのだけど、ほとんどの場合は中のソースコードまでいじる必要が出てくる。結果として、自前実装するよりも膨大な時間と多くのバグを抱えた不安定な機能としてリリースを迎えることになるだろう。
「エンジニアならプルリクせよ」って話が出てくるかもしれないが、こうしたコンセプトから違うUIで機能追加のプルリクするのは良いことではないことは想像に容易い。もしそれがマージされたら、そのオープンソースの設定がファットになって、もはや誰のためのUIコンポーネントだかわからなくなる。実際、最終的にそういうファットなライブラリは結構ある。どんどん重い複雑なライブラリになって、やがて他のシンプルなライブラリが登場して誰も使われなくなる結末を迎えるのだ。
こだわりがあるほど自前実装が必要になるのはそこにある。自前実装すれば、以下のようなメリットが待っている。
- 本当に必要な機能を実現できる
- 最小限のソースコードになる
- 拡張・メンテしやすい
- サービスの差別化につながる
実際、このカレンダーは300行程度のJavascript で実装されている。何か修正・改善したいって時でも300行程度のソースを読み返すだけなのは心理的にとても良い。「あの部分のソースはもういじりたくない」って箇所をいかに減らしていけるかってのも、エンジニアの腕の見せ所だ。ただし、こうした独自UIの実装はフロントエンドの開発経験がそれなりに必要ではある。UI にこだわりを持ってスキルを磨いていけば、やがてどんなUIでも実現できるようになるだろう。
終わりに
今回は見た目がガラリと変わるほどの大きなUI改善だった。もちろんこの実装をするまでには多くの時間と考慮を必要としたけども、最終的により便利になったことに喜びを感じている。
「不思議と使いやすい」と思っていただけるようなサービスには、サービスに最適なUIがあるからだと信じている。だからこそ、私はフロントエンドの実装をものすごくこだわっている。こだわってやってきたからこそ、今ではどんなUIでも実装できる自信を持って開発することができる。
今回の内容は、どんな業界の "職人" にも同じことが言えるのではないか。職人であればあるほど素材にこだわる。私たちエンジニアで言えばソースコードだ。今後、ユーザーはますます食べ物と同じ感覚で「使いやすさの違い」がわかってくるはずだ。
特にフロントエンドUIに関しては自前実装にこだわるエンジニア職人になろうじゃないか。
