DocBase独自のリッチテキストエディター開発を支えた超画期的なアジャイル手法

 

こんにちは、クレイの正岡です。
好きなモンスターはメタルスライムです、よろしくお願いします。

今回は、先日正式リリースしたDocBaseのリッチテキストエディターの開発プロセスについて喋ろうと思います。

DocBase独自のリッチテキストエディターを開発しました

DocBase独自のリッチテキストエディターとは？

既存のサービスにリッチテキストエディターを盛り込もうと思ったとき、まずは既存のOSSを探しますよね。既存のコードと要件を考慮した上で相性の良いライブラリは何なのか？と検討することと思います。

そう、普通は。

我々DocBase開発チームは違います。
僕たちはリッチテキストエディターを独自に開発することにしました。
この記事を書くにあたって、その理由を開発リーダーに改めて確認しました。

僕：どうして独自開発に踏み切ったんでしたっけ？かくかくしかじかでしたっけ？

リーダー：「やってみたかった」という理由だけで、合理的な理由はない。

僕：なるほど。

しかも僕たちが目標にしているリッチテキストエディターは、他のそれとは一味違います。

マークダウンを書きながら、同時にプレビュー側でも編集できるようにする。

という状態を目標にしました。

マークダウンでドキュメントを書くアプリには、マークダウンの結果をプレビューする機能があると思います。DocBaseでは、そのプレビューをリッチテキストエディターとしても使える状態を目指したのです。

 

 

どうしてそんなことをするのか？

人によってはマークダウンによるメモの編集が難しくなってしまう状況があることが分かっていました。例えば、マークダウンでテーブルを編集したり、マークダウンの記号が多くなったメモを編集したりする場合です。マークダウンに対する慣れの問題も関係しますね。

なので、

・マークダウンを使えない人は、リッチテキストエディターで快適に編集してもらう
・マークダウンを使える人は、リッチテキストエディターの恩恵も受けてもらう

ということによって、圧倒的に使いやすいエディターを目指したのです。

さあ出発だ！目標は申し分なし、パーティメンバーは・・

さて、意気揚々と始まったリッチテキストエディター開発ですが、膨大なバグとの戦いの幕開けでもありました。

例えば、テキスト選択、カーソル移動、文字入力、改行はエディターの基本的な機能ですよね。そんな機能は楽勝に思えます。しかし、それらの基本的な機能にこそ非常に多くのバグとの戦いがありました。
さらに、リッチテキストエディターで使える新たな機能やリッチテキストエディター以外の機能の開発も進めなければなりません。

しかも、開発メンバーはたった4名。

ドラ⚪︎エじゃないんだから。

膨大なバグを相手にどうやって少ないメンバーで戦ったのか。
その 超画期的な 超泥臭いアジャイル手法を紹介しようと思います。

改善サイクルのブン回しと怠惰の美徳

改善サイクルの仕組み化

リッチテキストエディター開発プロジェクトが本格的に始まる前夜、先ほどの開発リーダーがリッチテキストエディター開発の基盤を作り上げました。

歓喜に湧く弊社。しかし、リーダーは冷静でした。
これから始まる戦いを予期していたのか、こんなテンプレートを作ってくれました。

WYSIWYG {不具合、要望}
<!-- ※タイトルをわかりやすいものに変更してください -->

## 概要

## 再現手順

## 期待する動作

## 対応可否

<!-- 議論した結果を記載する欄なので、最初は空欄で良いです -->

「リッチテキストエディターについてバグを見つけた場合や何か機能追加の要望を思いついたら、このテンプレートを使ってDocBaseでメモを作って共有してくれ」と。

基本的な使い方はほとんど見たままですが、

1. {不具合、要望} に報告内容のタイトルを入力する
2. 概要 セクションには、動作環境やざっくりとした説明を書く
3. 再現手順 セクションには、操作手順を書く
4. 期待する動作 セクションには、どう動けば嬉しいのかを書く
5. 対応可否 セクションには、認識合わせの上、対応可能であればプロジェクト管理チケットのURLを書く。対応が不可能なら理由を書く

というものです。

このテンプレートが共有されてから、以下のようなサイクルが活発に回るようになりました。

バグの修正中に別のバグを発見するパターンも多かったです。

このサイクルによって共有されたメモの数は、テンプレートが共有された2023年1月31日から2024年5月28日までの間で約500件。

そして、昨年2023年のDocBaseのリリース回数は34回。
毎月およそ2.8回リリースできていたようです。

機能の追加やバグの修正をこまめにリリースできたのはこのサイクルのおかげですね。

基本であり重要な戦術

改善サイクルを頻繁に回すことも重要ですが、それ以前の基本的なことも重要でした。
先ほどのサイクルをより詳しく書くとこうなります。

詳しく説明します。

優先順位をつける

サイクルの「評価」にあたることですが、1つは優先順位をつけること。

バグ修正と一言でいっても、

• 重要なバグと、重要ではないバグ
• 緊急性が高いバグと、緊急性が低いバグ

など姿形が異なります。

また、当然バグ修正だけをやっていればいいわけではありません。バグを修正した上で、さらに便利な体験をしていただくための新機能を開発する必要があります。
そして、そこにも

• 必要な機能と、必要ではない機能
• 緊急性が高い機能と、緊急性が低い機能

があります。さらに、エディターの改善だけでなく他のDocBaseの機能についての改善も必要です。

それも限られたリソースの中で。

そのためには、タスクに優先順位をつけることが必須でした。やる価値が低そうなものや労力の割にリターンが少なそうなものは、優先順位を下げるかそもそもチケット化せずに後回しにしました。

ローマの哲人セネカもこう言っています。

ようするに、われわれは、なんの成果も得られない無駄な仕事をするべきではないし、得られる成果に見合わない仕事をするべきでもないのだ。

（「人生の短さについて 他二篇」光文社古典新訳文庫）

 

 

 

できるだけ最小限に

こちらも「評価」にあたることですが、できるだけ最小限に開発することも重要でした。

何か行動する際、人間どうしても「あれもこれも」と欲が出てしまいがちです。
例えば、僕は去年の4月から2ヶ月間国内を放浪しながら仕事をしていたのですが、各地の観光名所を「あれもこれも」と巡っているうちに疲れ果て、挙句に「やっぱ家が最高」となってしまいました。

開発についても同様です。「これもあった方が良さそう、あれもあった方が良さそう」と機能を付け加えているとタスクばかりが量産され、一生終わらないプロジェクトにだんだんと疲弊してしまいます。

そのため、本当に開発しなければならない機能を見極め、まずは最小限に抑えて開発することが重要でした。

セネカがなんと言っていたかもう忘れてしまった人に向けて、もう一度引用します。

ようするに、われわれは、なんの成果も得られない無駄な仕事をするべきではないし、得られる成果に見合わない仕事をするべきでもないのだ。

 

テストしよう

文字通り、サイクルの「テスト」にあたります。
当然ですが、機能追加やバグ修正のたびにテストを書いておくことも非常に重要でした。

テストを書く作業は、場合によっては正直非常に面倒で退屈です。
が、直したはずのバグが再発してしまわないためにはテストが必要です。
その退屈なテストコードは、将来ユーザーの皆様と開発メンバーの命を守ることでしょう。

ここでもう一度、セネカの言葉を思い出してください。
・・忘れた人へ。

ようするに、われわれは、なんの成果も得られない無駄な仕事をするべきではないし、得られる成果に見合わない仕事をするべきでもないのだ。

 

終わりに

以上のようなプロセスでリッチテキストエディターの開発を進めてきました。

その中で「完成度がめきめき上がっていて、自社プロダクトも頑張らねばと思いながら使ってます。」という嬉しいフィードバックをいただくこともありました。

しかし、システムにバグはつきものです。
それに、今後もリッチテキストエディターの完成度を上げるだけでなく、編集体験の向上につながるような機能の追加や検索機能の改善などを予定しております。

引き続き、チーム一同がんばります。

この機会にぜひ、DocBaseのリッチテキストエディターを体験してみてください。
お読みいただいてありがとうございました。