WYSIWYG選定におけるPros&Consで何を考えたか

はじめに

既存プロダクトに対し、HTMLメールの送信ができる機能を開発した際の記録となります。
検討時からは半年以上のタイムラグがありますので、ご了承ください。

何にせよまずは要求の整理

基本的には、あらゆる開発の事始めになるかと思いますが、今回も例の如く要求事項の整理から始めました。
正確ではありませんが、ざっくり当時のものを記載すると以下のようになります。

• 開封率を高めるメルマガ配信のPDCAを回せるようになる
• クリック率を高めるメルマガ配信のPDCAを回せるようになる
• ビジュアライズされた訴求力のあるメールが配信できるようになる

開封率やクリック率の可視化はWYSIWYG選定とは切り離して考えることができると思いましたので、ポイントとしては3点目の「ビジュアライズされた訴求力のあるメールが配信できるようになる」になりそうです。

誰がその機能を利用するのか

「ビジュアライズされた訴求力のあるメールが配信できるようになる」を実現するために、誰がその機能を利用するのか、ペルソナ設計をしました。
こちらも詳細を省いたものですが、ポイントだけ簡単に記載しておきます。

ペルソナ①

• HTML/CSSコーディングスキルはなし
• マーケ専任でもなく、事務作業など他の仕事と掛け持ちでメルマガの運用

ニーズ

• レイアウトやテンプレートを流用して、デザインなど綺麗に見えるようなものでメールを送りたい
• 自分でカスタマイズする部分は、画像やボタンリンクなど限られたものを最小限に変更するだけで利用できる

ペルソナ②

• マーケ業務の経験あり、開封率の高くなりやすいメールのノウハウは一定持っている
• 若干HTMLやCSSに手を加えるくらいは可能
• 他ツールでwebマーケなどのメールを送信している

ニーズ

• 自作したメールで開封率、CTR等の反応元にPDCAを回したい
• 部分的にコーディングでメールの微修正をしたい

選定に必要な最低限の要件を言語化

上記を満たすための要件を明確にしていきます。
今回は利用者として高度なスキルを持ったユーザーが想定されている訳ではないので、
WYSIWYGとして満たさなければいけない機能要件は低そうです。
こちらも当時のメモを記載します。

高度な編集機能は求められていない。コーディングすることなくGUIでのHTMLメール作成が最低限できること。

• 基本的なHTMLメールの作成
  • ボタン、画像、カラム、区切り線、ヘッダー、テキストの埋め込みができる
  • 上記、スタイルや配置の変更ができる
• レイアウトの適用ができる
• SNS(youtubeやinstagram)の埋め込みがソースコードを編集しなくてもできる
• （+α）プレビューの確認が可能
  • PC/タブレット/モバイルでの確認

比較検討

ここからいくつかのプラグイン等を調査し、Pros&Consしていきました。
ピックアップ水準は最低限の要件を満たした上で、利用実績が一定見込まれるものとしています。

No.	WYSIWYG名	利用実績参考	コスト	日本語
1	Quill	https://github.com/quilljs/quill fork 2.9k star34.4k	無料	×
2	Redactor	git非公開 前身ツールあり14年程のサービス提供	$179〜	◯
3	CKEditor5	30.000+Customers 30M+Downloads	無料	◯
4	Editor.js	https://github.com/codex-team/editor.js fork 1.7k star21.2k	無料	×
5	FroalaEditor	https://github.com/froala/react-froala-wysiwyg fork 521 star133	$239~	◯
6	unlayer	https://github.com/unlayer/react-email-editor fork 632 star3.6k	無料	◯
7	TinyMCE	https://github.com/tinymce/tinymce-react fork 117 star751 358,372downloads	無料	×

ここからまずコスト面とメンテナンス性を加味して、無料かつ日本語対応しているものを選択肢として残していきました。この時点で、CKEditor5またはunlayerを有力候補としています。

この段階で利用するプラグインは2択となりましたが、そこから要求事項に立ち返り、1つ選択する流れとしました。

要求事項に立ち返る

結論として、選択したのはunlayerになります。
まさにそのポイントとなったのは、利用者が「ビジュアライズされた訴求力のあるメールが配信できるようになる」という要求でした。
利用者想定（ペルソナ）に照らし合わせ、CKEditor5でリッチなメールを送信しようとした場合のハードルの高さに対し、慣れは必要ですがunlayerでの操作性が上記を満たすのにより適していると判断したからです。

最終チェック「プロダクトはどこを目指すのか」

最後にチェックとして設けた観点として、プロダクトの目指す方向とWYSIWYGの選定がマッチしているか？というものがあります。
本来であれば要件としてプロダクトに組み込む際の観点にあれば良いと思いますが、その当時検討至らずでこのタイミングでのチェックをしました。
プロダクトとしては「簡単に誰もが操作しやすいシンプルなUXを提供する」という目指す形があったため、そのままunlayerで開発を進めることになりましたが、こういったコンセプトに対して衝突を起こさないかは非常に重要な観点であると感じます。

振り返って

今回はプロダクトの1機能であるHTMLメールの単なるWYSIWYG選定の話になります。
機能全体の話だと要求の整理も要件定義ももっと話が広がるのでピックアップする形で残してみました。WYSIWYG選定に関しても、突き詰めればこれ以外にも検討の幅は広くなり、深くも考えることができると思います。

特に最近では、一つ一つの意思決定が事業計画やプロダクトの成長計画に影響を及ぼすことを実感しています。それに沿わない意思決定が後に負債として噴出し、気づいたときにはコストとして見做されるようになります。

当たり前ですがペルソナとして設計した利用者像も、プロダクトのターゲットはどんなところか？からブレイクダウンした上での設計になっています。（詳細は記載していないですが🙇‍♂️）技術選定にしろ、（どの）設計にしろ、レビューや意思決定に関しては事業の理解がないと成し得ないものであると再認識をした案件になりました。