いつも Evernote をご愛顧いただきありがとうございます。この度、皆様がもっとも気になっていることについてご説明したいと思います。
この 7 か月間、Evernote にはさまざまな変更が行われました。それにより、Evernote の長期的な見通しについて懸念を示すユーザの方々もいらっしゃいました。そこでこの度、はっきりとご説明したいと思います。 Bending Spoons の目標は Evernote を再び素晴らしいアプリとして蘇らせることです。私たちは、手っ取り早く利益を出すために手綱を握ったわけではありません。私たちの長期的なビジョンには短期的な痛みが伴いました。それらは残念なことではありますが、必要なことでもありました。これらの決断を行わなければ、Evernote は繁栄するどころか、生き残ることもできなかったでしょう。実際ほんの数か月前まで、Evernote の運命はかなり暗いものでしたが、今では長期的な未来を純粋に楽観視することができるまでになりました。
私たちの焦点は、Evernote を安全かつ信頼できる「第二の脳」にすることです。皆様の最も大切な情報をいつでもどこでも簡単に取り出せる、高速で絶対的に信頼できるデータベースとすることです。このアイデアは決して新しいものではなく、 20 年前に Evernote が生まれたときからの基盤です。そのために私たちが現在優先して行わなければならないことは、この基盤をこれまでよりもはるかに強固なものにし、当初から数十年にわたり受け継がれてきたビジョンを実現することです。
そこで今、私たちが直面している問題は「揺るぎない信頼と確実なスピードを兼ね備えた製品をみなさまにお届けするにはどうすればよいのか？」ということです。答えは、複雑で一言で言い表すことはできませんが、本ブログ記事や今後行われるみなさまへのコミュニケーションで、できるかぎりご説明できるよう最善を尽くします。
具体的な内容に入る前にご了承いただきたいのですが、以下でご説明する内容は決して包括的なものではありません。本記事では 3 つの主な分野に絞ってご説明いたします。他にも進行中の取り組みは多岐にわたり、それらについても随時お知らせいたします。
重要な最初のステップ：スピードと同期
すべての旅は最初の一歩から始まります。私たちの一歩は 2023 年 5 月に導入した、リアルタイム編集（RTE）のための新しい同期プロセスでした。このプロセスを導入した目的は、これまでで最速のノート同期を実現し、複数のデバイスで同時にシームレスな編集を行えるようにすることでした。それと同時に、ノートの競合を防ぐことも目指しました。
この野心的な目標を実現するには、強力なフレームワーク（Yjs）を用いてまったく新しいデータ構造（CRDT：競合しない複製可能なデータ型）を導入する必要がありました。これを実装したことにより、ノートのコンテンツをすべてのデバイス間で瞬時に同期できるようになりました。以前の HTML 形式のノートでは不可能だったことです。
そして今日、この重要なデータ構造とシステムのロールアウトが完了したことを、ここにご報告します。移行期には困難もありましたが、RTE のような根幹に関わる実装を行う際には、大規模な準備と事前のトラブルシューティングを行っても、多少の混乱は避けられません。私たちは難題が生じることを想定して十分な準備を整え、実現可能だという自信を得たところで実装に踏み切りました。また今回の実装で多くのことを学びました。そして、Evernote のユーザエクスペリエンスは、大部分のユーザの方にとって、以前に比べてはるかにスムーズかつ信頼できるものになったと自負しております。
スピード：最終的な微調整
新しい同期システムを使った RTE の導入はおおむね成功であったものの、一部のユーザの方においては、ノートの読み込み速度の低下が生じました。これはある程度までは想定内のことでした。新しい RTE ノートシステムでノートを初めて開く際に、そのノートは変換プロセスを遷移する必要があるため、読み込みに 2〜3 秒かかるからです。ただし、これは初回に開くときのみで、その後ノートを開くときには瞬時に読み込みと同期が行われます。
ただ、一部のユーザの方からは、RTE に変換された後もノートの読み込みが大幅に遅くなったというご報告をいただきました。この問題は、非常に特殊なケースにおけるシステムのノート処理により発生していたもので、巨大な履歴が異常に生成されていたことが原因でした。またそのために、読み込みの遅延以外にも、コンテンツの欠落やタスクの同期などにも問題が発生しやすくなっていたことがわかりました。
原因を特定した後、私たちは速やかに必要な解決策を実装しました。具体的には、バックエンドで 3 つのパフォーマンス関連のバグを修正しました（6 月 15 日、6 月 27 日、7 月 20 日にリリースされた修正がこれに該当します）。 この修正を行ってすぐ、影響のあったアカウントでノートの読み込み時間が健全に戻りました。万が一、まだ問題が発生している方がいらっしゃいましたら、Evernote の最新バージョンを使用されているかご確認ください。それでも問題が解決しない場合はサポートチームまでご連絡ください。
ナビゲーション：システム内部に実装した変更点
私たちが行ってきた改善の一部は、エディタでのユーザエクスペリエンスからは遠く離れた製品の深部で行われています。こうした改善のうち最も重要であったのは、Evernote デスクトップ版と Evernote Web のナビゲーションシステムを書き換えたことでした。この変更は 7 月末（バージョン 10.59）に実装されました。同時期にモバイル版のナビゲーションシステムも大幅にアップデートしています（バージョン 10.52）。基本的にナビゲーションシステムは、アプリの個々のコンポーネントが互いにどのように関連し合うかを決定します。モバイル版ではナビゲーションがネイティブ API を使うように変更しましたが、その変更は外からはほとんどわかりません。ただパフォーマンスは確実に向上しています。デスクトップの場合は、URL が変わったので変更が行われたことがわかります。
www.evernote.com?b=<notebookID>&n=<noteID> →
www.evernote.com/notebook/<notebookID>/note/<noteID>
これは一見、小さな変更のように思えますが、将来的に製品が進化していくにあたり、ナビゲーションシステムを簡単に拡張することができるようにするための重要な変更です。
モノリスの移行
もうひとつ、目には見えない重要な変更は、モノリスの移行です。これは複数のチームが協力して行っています。少し専門的なことになりますが、技術オタクの説明にお付き合いください。
現在の状況
モノリスは、Java EEの古いアプリケーションでバックエンドで Evernote の大部分のビジネスロジックを動かしています。そして、ノートを含む複数のエンティティのストレージと同期を担っています。
私たちが作業を開始する前は、データベースもアプリケーションレイヤーとして同じマシン上で動作していました（アプリケーションは Java EE、データベースは MySQL）。そのためマシンが非常に重くなり、管理も難しくなっていました。両者のコードと土台となるインフラストラクチャに、技術的負債が積もっていたのです。ありがたいことに、RTE のようなマイクロサービスが、このような状態からの脱却を支えてくれています。
次のステップ
次に注力しなければならないのは、コードを整理して技術的負債を一掃することです。インフラストラクチャについてはすでに進行しており、最近も本番インフラストラクチャ全体をモダンなテクノロジーですべて書き直しました。
この書き直しにあたり、アプリケーションとデータベースを分離しました。データベースは新しくモダンなインフラへ移行中です。これによりセキュリティと信頼性が大幅に向上されます。以前は環境設定を Puppet で管理していましたが、今はすべて Docker コンテナへとパッケージ化されています。この新しい本番環境は以前に比べて開発環境にかなり近い環境なので、開発作業も変更後の動作確認もはるかにスムーズになります。これにより、本番環境で発生するバグが減り、発生した場合も速やかに修正できるようになります。
さらなる道のり
今後数か月の間に、すべてのプラットフォームでスムーズなユーザ体験を確実にお届けできるように、バグの修正作業を倍増する予定です。さらに、タスク同期の信頼性を高め、Evernote クライアントのスピードも大幅改善する計画です（すでに、Web クライアントにおける早期テストでは良い結果が出ています。近く皆様にご報告したいと思っています）。
現在の最優先事項はコア機能とユーザ体験ですが、新たなイノベーションにも着手しています。すでに少人数のユーザ（社員と Evernote エキスパートの方たち）が今後実装予定の AI を活用した検索をテストしており、そのフィードバックは上々です。とはいえ、何よりもまずはしっかりと基盤を整えること。揺るぎない土台があってこそ、製品は進化できると考えています。
それでは、また次回皆様に進捗をご報告できるのを楽しみにしております。
今後とも Evernote をどうぞよろしくお願いいたします。
フェデリコ