Strapのリッチテキストエディターを移行した話
この記事は、https://qiita.com/advent-calendar/2020/goodpatch の14日目の記事です。
自己紹介
Goodpatchで自社プロダクトの開発をしている石井大雅と申します。
Goodpatchには2018年新卒として入社し、現在はProttのバックエンドの開発とStrapのアプリケーション開発を担当しています。
はじめに
Strapは「リモートコラボレーションの可能性を広げるクラウド型ワークスペース」というコンセプトを持つ、複数の職種がチーム内に存在する「クロスファンクショナルチーム」がコラボレーションする「場」を提供しているサービスになります。
こちらに詳しいStrapのストーリーが書かれているため興味のある方はこちらも一読してみてください。
「シンプルで誰でも使える」プロダクトは、ユーザーの実感を共有しながら作る――「Strap」開発の舞台裏
今回はStrapの開発の中で既存のリッチテキストエディター（以下 エディター）を移行したことについてお話できたらと思います。
調査の全体像
この作業の始まりは、エディターを移行するための調査ではなく、既存のエディターの挙動を改善するための調査として始まりました。この時点ではエディターの移行は解決策の選択肢の１つでしかなく、どのようなアプローチが一番価値をもたらすかという視点で解決策を出していきました。
調査の最初にまず行ったことは、情報収集です。今回は既存のエディターの挙動を改善するという目的があったので、まず「どのような問題」が発生しているのかどうかをリストアップしていきました。
また実際にアプリケーションを触ってユーザーレベルでどのような挙動が起こっているかも確認し、その内容もリストアップしていきました。
この段階で、エラーの頻度やユーザーへの影響度からリストアップした内容に対して重み付けをして、優先度を判断しました。
このステップで一番大事にしたことは、「現状の正確な状況把握」と「この問題の全体像を把握し、何を解決したいのかの輪郭を明確にすること」でした。
次に、解決策を考察しました。
一番上段では既存のエディターを改善するか新しいエディターに移行するかの選択から入りました。それぞれ選択の先にある作業の工数感やプロダクトを使っているユーザーと開発チームへのインパクトの視点で比較を行いました。運用などの中長期的な観点も踏まえ、費用対効果が高い解決策を選択するためです。
このステップで一番大事にしたことは、「中長期的にどのような利益が対ユーザー、対開発チームにもたらされるのかの観点で選択をすること」でした。
またこの段階で、チームのメンバーとも認識合わせをし方向性の共通認識を取りました。理由としては、この選択はプロダクトの利用ユーザーだけでなく、開発チームの開発体験も意識しなければならないからというものと、チームの多角的視点を取り入れることで今回の選択の解像度や質を向上させるという目的がありました。
実はこの段階で、新しいエディターへ移行するという選択がチームの方針として決まったのですが、はてはて。。。個人的にエディター選定の経験が今までなかったので正直勝手がわからないのに加え、エディターのライブラリは検索するだけでも無数に出てきます。その中からStrapのユースケースに適したエディターを選択をするためにどのような観点で選択をスべきかを整理しました。
次の章でその意識した観点についてお話できればと思います。
エディター選定で意識した観点
私は、今回のエディター選定に際して「課題解決」と「価値創造」という２つの側面から観点を考察するというアプローチを取りました。
まずは下記に述べる観点から大体25種類のライブラリを精査していきました。
課題解決
- 既存のエディターで起きていたエラーを解消できるかどうか
- IMEで起きる入力時の挙動を改善できるかどうか
価値創造
- 日本語入力体験を向上させることができるかどうか
その他
- ライブラリのメンテナンスが活発に行われているかどうか
- Strapが定義している推奨ブラウザがサポートされているかどうか
- 導入が容易かどうか
- 拡張が容易かどうか
上記の観点で精査をした6種類のライブラリに関して簡単なプロトタイプを作成し、挙動の詳細を確認していきました。
考慮した観点としては以下になります
- 導入が容易かどうか
- 拡張が容易かどうか
- UIのカスタマイズ性
- セキュリティ的に問題ないか
- プロトタイプを動かして触ってみて挙動や体験が向上しているかどうか
前半と後半で重複している部分はありますが、特に太字にした部分に対して詳細に話そうと思います。
日本語入力体験を向上させることができるかどうか
当たり前の話に聞こえると思いますが、プロダクトのターゲットユーザーが日本人である場合、日本語入力体験は当たり前機能に分類されると思います。当たり前機能はあって当たり前、ないとユーザーが不満を持つ機能のことですが、もし競合サービスが海外プロダクトだった場合、日本語入力はそれ単体でかなりの価値を持ち、場合によっては差別化要因になりえます。
そのため日本語入力体験の向上という目的を一番重要な観点として選定を進めていきました。
導入が容易かどうか
ライブラリを導入するときにはどのオフィシャルドキュメントを読み込んで選定をすると思いますが、まずライブラリの設計思想がシンプルで明快でわかりやすいかどうかは大事な観点にしました。理由としては、プロダクトの開発は必ずと言っていいほどチームで開発するため自分だけがわかる、他のメンバーがこのライブラリを扱うときの取得工数が著しく上がるような選定は良くないと思うからです。
また既存のテキスト周りのインターフェースをあまり変更せずに実装が行えるかどうかも観点としては重要なポイントでした。仮にインターフェースをかなり大幅に変えなければならない場合、作業の工数が大幅に上昇するのと影響度が大きいためテストが大変、デグレが発生する可能性が上がるという状況になると考えたからです。（もちろんそうしなければならないケースは存在します）
拡張が容易かどうか
コードベースで拡張性が高い状態が品質の高い状態の一つの要因であるということは開発者では自明の事実ですが、今回のライブラリではそのコードベースとは別にライブラリが持つ機能としての拡張性にも注目しました。リッチエディターの要件は、かなり柔軟に、また頻繁に更新されるものだと思います。
例えば今後文字の部分装飾がしたいというユーザーのニーズは必ず出てきますし、それを達成することも視野に入れて選定をする必要がありました。
拡張性は、サービスを長期的に運用していく上で欠かせない要因だと思います。そのためライブラリの選定にも拡張性はかなり重要な要素になりました。
上記のフローを経て、いくつか最終候補に残ったライブラリはあったのですが、プロトタイプを触ったり、開発のコードベースの内容を精査した結果、私が選定したエディターライブラリは、Quillという名前のものです。
Quillは他のライブラリと比べてもかなりユーザー目線でデザインされたエディターで有ることがわかりました。ユーザーの入力にフォーカスし、DOMの制約とは別の部分でAPIを使って細かな操作や制御をすることができます。
またコンテンツやフォーマットなどもかなり柔軟に拡張できるので今後の要件の変更にも耐えうるものと判断しました。
まとめ
今回はStrapでのエディター移行についてお話させていただきました。
ひとえにエディター移行といっても、移行が目的なのではなく移行をすることにより何が達成されるのかから始めることはすごく大事なことだなと自分自身も感じました。
今回述べた観点は、必ずしもエディターの移行に対してのみ適用できるものではないと思っています。もっと身近の様々な開発上の選択をする際の一つの方法としてお役に立てればいいなと思います。
最後に宣伝になってしまいますが、Strapというプロダクトは現在も鋭意開発中です。興味のある方はこちらのページを覗いてみてください。
