結城です。

先だってFirefoxのフォーク版の一つとして知られるWaterfoxプロジェクトのブログにてアナウンスがあった、Waterfoxの次期バージョンにおける「タブのプレビュー画像を伴った縦置き型のタブバー」の開発を、当社業務の一環として筆者が担当させて頂きました。

先方のブログでも言及されている「仮想スクロール」の技術的な詳細については、筆者個人のブログにて、解説記事を別途公開しております。 ここでは、それとは別の切り口として、「個人の開発者宛に頂いた連絡を、どのようにして企業の案件として請け負い、成果をオープンソース開発プロジェクトに還元したか」に焦点を当て、前後編に分けて、前編（この記事）では初期の交渉と仕様検討段階で行ったこと、後編では実装段階で行ったことをご紹介します。

初期の交渉

発端となる依頼

始まりは、筆者の個人活動のメールアドレス宛に届いた、Waterfoxプロジェクト主催のAlexさんからのご相談でした。 メールには、Waterfoxプロジェクトで縦置き型のタブバーを正式な新機能として実装しようとしていて、同様の趣旨の機能を提供するFirefox用アドオンであるTree Style Tab（以下、TST）の作者の筆者に、仕事として助力をお求めである旨が綴られていました。

アドオン作者にブラウザー本体の改造について相談を？と疑問に思われるかもしれませんが、Firefoxはバージョン57の時点でアドオンの仕様が大きく変わっており、Firefox 56以前のアドオンは「XULアドオン」と呼ばれ、その開発にはFirefox本体の開発と共通する知識が必要でした。 ですので、その時代を知る古株の拡張機能作者である筆者にご相談が寄せられたのは納得のいくところです。

会社への相談

ただ、どのような形で関わるにせよ、作業量はかなりの大きさになりそうです。 諸事情により本件に投じられる筆者のプライベートの時間は限られたものとなりそうだったため、開発を個人で責任を持ってお請けするのは難しいと思えました。

幸い、当社ではオープンソース開発を事業として行っており、公開プロジェクトの開発への業務での参加¹も、海外企業をスポンサーとした業務²も、どちらも先例があります。 そこで、本件も社の業務時間で行えないかどうか、先方と当社のブラウザーサポート事業チームの両方に相談したところ、「双方のスケジュール感・予算規模・筆者の案件へのアサイン状況などの問題がなければ、社の仕事として請けるのは可能である」との判断を頂けました。

正直なところ、本件のような事例の再現性で最重要キーになるのはこの点でしょう。 雇用主と依頼主のどちらについても「オープンソース開発のマネタイズ」に肯定的だったのは、幸運でした。 （そうでなければそもそも、TSTが生まれてすらいなかったかもしれません。）

要件定義と見積もり

ヒアリング

スケジュール（どのくらいの期間がかかるか）と工数（どのくらいの予算が必要か、相手の想定予算に収まるのかどうか）を見積もるためには、要件定義が必要です。 具体的にどのようなゴールを目指すのか先方に尋ね、要件は以下の通りと分かりました。

• パワーユーザー向けに、Waterfoxにおいてシームレスに利用できる縦型タブバーを実現する。
• 実装方法は問わない。
  • TSTを下敷きにする場合、開発の成果はTST側にフィードバックして公開しても問題無い。
• 機能としては、以下を必須の要件とする。
  • 縦置きタブバーであること。
  • タブ内埋め込みのプレビュー（サムネイル）があること。
  • ブラウザー本体の設定画面に設定画面を組み込むこと。
  • 設定画面へ遷移するためのボタンがあること。
• 開発期間は2ヵ月ほどを目処とする。

これを踏まえ、これらの要件を満たす具体的な方法として、以下の表の3つの方向性を検討してみました。

案	メリット	デメリット
素案1: Waterfox自体のタブ実装を改造する。	開発の自由度が高い。	開発結果の検証コストが大きい。 将来のバージョンのFirefoxへの追従コストが非常に大きくなる恐れがある。
素案2: TSTをWaterfox向けに改造する。	既にある物が出発点となるため、必要工数は小さくなる（はず）。 開発結果の検証コストが小さい。 将来のバージョンのFirefoxへの追従コストが小さくなる。 TSTへ成果が還元される。	Manifest V2の先行きが不透明。 WebExtensions APIの制約により実現できない機能があり、Experiments APIの実装コストが必要。 タブの数が多いときの性能に難がある。
素案3: Waterfoxネイティブのサイドバーパネルとして実装する。	開発の自由度が高い。 将来のバージョンのFirefoxへの追従コストが小さくなる。	開発結果の検証コストが大きい。 すべてを実装し直すためのコストがかかる。

以下、それぞれの検討内容を述べていきます。

素案1：Waterfox自体のタブ実装を改造する

Waterfox自身がすでにFirefoxを改造したものなので、この選択肢はWaterfoxプロジェクトとしては順当なものです。 このやり方では、技術的にはほぼ無制限に自由な開発が可能なのがメリットですが、それとひきかえのデメリットもあります。

まず、開発結果を検証するためには「Waterfox本体のビルド」の手間がかかります。 CIの定義ファイルを見ると、Windows版のビルドは複数のステージに分けて行われており、それなりの手間がかかる様子が窺えます。 いくらか簡略化はできたとしても、アドオン開発の手軽さに比べると重たい作業なのは変わりません。

また、筆者が最も大きなデメリットと考えるのは、開発の成果がベースバージョンのFirefoxに対して密結合になるため、Firefoxの変更の影響を強く受ける点です。

Firefox 56以前は、Firefoxの開発チームも既存のXULアドオンとの互換性をある程度意識していたそうですが、XULアドオンが廃止されて互換性維持の制約がなくなった現在のFirefoxでは、大胆な変更が度々行われており、追従コストは以前よりも大きくなっています。 WaterfoxはFirefox ESR³を元にしているため、更新の頻度は1年に1回程度で済みますし、ベースバージョンとなるFirefoxも単一のバージョンに限られるので、複数バージョンのFirefoxを想定した工夫が不要な分、XULアドオン開発よりも工数は小さくなりそうです。 それでも、毎回のメジャーアップデートへの追従では1人月程度の工数は発生しかねません。

会社の業務としては継続的な収入を見込める案件は歓迎ですが、この件が今回のみの単発作業にとどまった場合、以後の追従作業に支障が生じる恐れがあり、Waterfoxプロジェクトとしてはデメリットとなり得ます⁴。

素案2: TSTをWaterfox向けに改造する

すでにあるFirefox用アドオンのTSTを要件に合うように改造する場合は、全体的に必要な工数が小さくなるのが大きなメリットです。

前項での懸念の1つめの「ビルドの手間」は、アドオンであれば、変更の度にブラウザーのUI上で再読み込みするだけで済みます⁵。 また、Firefox本体の更新に対する今のアドオンの追従の容易さは、現在のTST自身がその証明となっています。

　

この場合のデメリットの1つ目は、TSTが準拠しているアドオンの仕様である「Manifest V2」の将来性の不透明さです。 FirefoxではManifest V2は当面存続する旨が公表されていますが、将来に渡って安心して使える確約はありません。

この懸念を払拭するには、Manifest V3へ移行するほかありませんが、この時点で今回の要件をManifest V3で満たせるかどうかは不明でした。 というのも、Manifest V3ではTSTの重要コンポーネントの1つである、タブのツリー構造に矛盾が生じるのを防ぐための「タブの変更を常時監視する、永続的なバックグラウンドページ」を使用できない⁶からです。 このような制約があっても必要な動作を実現できるのかは、PoC⁷を用いての検証が必要です。

　

デメリットの2つ目は、WebExtensions APIでは実現できない機能や、WebExtensions固有の制約があることです。 WebExtensions APIの機能的な制約により、TSTには「実装したいができない」機能がいくつかあります（詳しくは後述）。 今回の要件の中にも、ブラウザー本体の設定パネルへの機能追加など、WebExtensions APIでは実現できない機能が含まれています。 そのため、この選択肢においてはExperiments APIの使用が必須となります。

Experiments APIは、WebExtensions APIベースのアドオンにXULアドオンと同等の自由度をもたらす技術です。 リリース版のFirefoxでは機能が封印されていますが、Waterfoxでは機能が有効化されているため、「Waterfox専用のアドオン」の開発では使用を前提にできます。 前述したManifest V3での制約も、極端な話、「永続的なバックグラウンドページ」を代替する物をExperiments APIで実装する形で制限を回避できます。

ただ、Experiments APIの実装は前項同様に、ベースバージョンとなるFirefoxの変更の影響を強く受けます。 Experiments APIに依存する箇所が増えれば増えるほど、Firefoxの更新への追従コストは大きくなる⁸リスクがあります。

また、WebExtensionsアドオンが別プロセスで実行されることに由来する既知の不具合がある⁹、という問題もあります。 問題の深刻度次第では「Waterfoxにパッチを当てて問題を解消する」対処も有り得ますが、実際にどこまでできるかは予算のかけ方次第です。

　

「パワーユーザー向けの機能として提供する」という前提からは、タブが多いときの性能問題も懸念されます。 本件開始時点でのTSTバージョン3.9.22では、数千個単位でタブを開いている複数のユーザーから、動作速度の遅さやメモリー消費量の多さが指摘されていました。 Waterfoxの想定ユーザー層を考慮すると、この点は無視できません。 性能面の懸念を払拭するためには、タブの数が多くなっても性能が劣化しにくい実装方式である仮想スクロールの導入も必須と考えられました。

Manifest V3への移行や仮想スクロールの導入は、TSTで前々から課題と認識していた点で、もしうまく実現できれば、成果をそのまま公開版のTSTにフィードバックできます。 先方は「TST開発プロジェクト自体への支援もしたい」とお考えだったので、この点は非機能要件としてのメリットと言えます。

素案3: Waterfoxネイティブのサイドバーパネルとして実装する

これは、WebExtensions APIの制約に囚われない自由な実装を行いつつ、その実装を「Waterfox専用のサイドバーパネル」内に閉じることによりFirefox由来の部分との接続を弱めて、将来のバージョンのFirefoxへの追従コストを小さくする、という「いいとこ取り」を狙った案です。 技術的な障壁は特になく、最も高機能・高性能かつ長期的に有用な成果を得られると期待できるのがメリットです。

この選択肢のデメリットは、開発規模が大きくなることに尽きます。 WebExtensionsベースではないので、現行のTSTのコードはそのままでは流用できず、多くの部分をゼロから作る必要があります。 開発の成果を検証するためにWaterfoxのビルドが必要であるという点や、成果物がWaterfoxプロジェクトの負債になりかねない点も、素案1と同様です。

提案とフィードバック、作業計画の具体化

Waterfoxプロジェクトが何を優先するかによって、最適な選択肢は異なります。 そのため、この3つの素案を先方に提示し、意見を求めてみました。

そうしたところ、この中では素案2の方向性（WebExtensionsアドオンとして開発）が最も有力そうだとの回答を頂けたため、ここから先はその方向での詳細を詰めるべく、技術的な議論や情報のすり合わせを行いました。

その過程で、先方がすでに得ておられた技術的な知見を共有していただくこともでき、こちらで懸念していた点のいくつかについては、解消の筋道が立ってきました。 また、素案検討段階で未知数の部分が多かった「Manifest V3での実現可能性」についても調査を進め、PoCの設計方針が見えてきました。

ここまでの情報を踏まえて整理した作業内容と計画は、以下のようになりました。

• 機能はWebExtensionsアドオンとして実装する。
  • 開発するアドオンは、TSTの実装を一部流用する。
• 開発は以下の2段階に分けて行う。
  • 第1段階：現行のTSTと同等の基本機能の実装。
    • まずPoCを作成し、Manifest V3で素直に実装した場合の実用性を検証する。
      • PoCでの実証結果が芳しければ、そのままManifest V3で開発を進める。（この成果はTSTに還元する）
      • PoCでの実証結果が芳しくなければ、Manifest V2での開発（TSTの改造）に舵を切る。
    • Manifest V2とManifest V3のどちらで実装するとしても、UIは仮想スクロールを用いて、ほぼ新規に開発する。
  • 第2段階：Waterfox固有の機能拡張部分の実装。
    • サムネイル、設定画面の組み込みなど、WebExtensions APIでは実現不可能な部分をExperiments APIで実装する。
• これらの作業は2ヵ月程度の作業期間内で可能そうである。

こうして、ある程度の精度での見積もりができたことで、晴れて本件を社の案件として受注できるとの判断が下り、筆者の担当業務として取り組める運びとなりました。 開発内容にはまだ未知数の部分があり、詳細な作業の内容は変動する恐れがあるため、契約は請負契約ではなく準委任契約とし、期待される開発の成果と開発の期間のみをお約束する形です。 以降は、契約の話を会社間で進めてもらう一方で、筆者は引き続き、先方との間で実装方針検討のための技術的な議論を進めていきました。

方針の見直し

議論のさなか、先の素案2での「永続的なバックグラウンドページをExperiments APIで代替する」方向性の検討過程で、「そもそも、Manifest V3における制約を迂回してバックグラウンドページを永続化できれば、短命のバックグラウンドページへの設計変更もExperiments APIでの代替実装も必要ないのでは？」という疑問が浮上してきました。

そこで、この方向性について双方で調査を進めたところ、バックグラウンドページの永続化の可否は一定時間経過後にバックグラウンドページをアンロードする処理の中で判定されており、現状でも、隠し設定のextensions.background.idle.enabledをfalseに設定すれば「Manifest V3でバックグラウンドページを永続化」できると分かりました。

この隠し設定は全てのアドオンに影響が及ぶため、正式リリースには反映しづらいのですが、「どこを変更すればバックグラウンドページを永続化できるか」が分かったことの意義は大きいです。 調査と検証の結果、Experiments APIでもこの箇所への介入はできないと分かりましたが、Waterfox側で小改修を行えば、今回開発するアドオンに限定してのバックグラウンドページの永続化は可能です。 また、将来のバージョンのFirefoxに追従する際にも、「バックグラウンドページのアンロード処理に介入する」改修自体はそれほど困難な物とはならないと予想できます。

以上の事を踏まえ、最終的な作業内容と計画を以下の通り変更・決定しました。

• 機能はWebExtensionsアドオンとして実装する。（仮称「Waterfox Sidebar」）
  • 開発するアドオンは、TSTの実装を一部流用する。
• アドオンの仕様はManifest V3とする。
  • ただし、バックグラウンドページは何らかの方法で永続化できる前提とする。
    • つまり、アドオンの全体的な設計はManifest V2からほぼ変えない。
    • バックグランド永続化の具体的な方法は、Waterfox側での特別な対応を想定する。
• UIは仮想スクロールを用いて、ほぼ新規に開発する。
• サムネイル、設定画面の組み込みなど、WebExtensions APIでは実現不可能な部分をExperiments APIで実装する。

これを踏まえて、作業用のリポジトリーを先方の管理下に用意して頂き、ここからようやく実装作業に入ることになります。

まとめ、次回予告

以上、個人開発のオープンソースソフトウェアに寄せられた連絡を企業としての開発案件に繋げた事例の紹介の前編として、交渉の経緯と見積もり段階での検討内容をご紹介しました。

ここまでの流れは、クライアントがWaterfoxというオープンソース開発プロジェクト¹⁰である点を除けば、一般的な「ソフトウェアの受託開発」業務の話と言えます。 マネタイズに苦労するプロジェクトが多い中で、Firefoxの成果をベースにしているとはいえ、外部の開発者に依頼ができるくらいの資金力をWaterfoxプロジェクトが持てているのは、すごいことだと筆者には感じられます。

ところで、冒頭に上げたWaterfoxプロジェクトのブログ記事や筆者個人のブログ記事をご覧になられた方はお気付きかと思いますが、実はこの件の最終的な着地点は「Waterfoxのサイドバー開発」というよりは、「オープンソース開発プロジェクトであるTSTとWaterfoxのコラボレーション」「TSTの開発をWaterfoxが支援」という見え方となっています。

さて、一体この後何があってそうなったのか。 後編では、計画に基づいて開発を始めて序盤で起こった方針の再検討と、「TSTプロジェクトの都合」と「Waterfoxプロジェクトの都合」をどのように両立させたかの工夫についてご紹介します。

1. Groonga、Fluentdなど。 ↩

2. Fluentd開発・サポートなど。 ↩

3. Extended Support Release。セキュリティアップデートが約1年間提供され続ける法人向けバージョン。 ↩

4. メリットとデメリットを考えるときは「誰にとってなのか」が重要です。自分と相手のメリットとデメリットが一致しているときは何も悩まず済みますが、このように「自分達にとってはメリットになるが、相手にとってはデメリットになり得る」事柄は、判断が難しい所です。筆者は基本的には、「自分と相手の共同プロジェクトとして末永く運用していく上でどうか」という観点で整理するようにしています。 ↩

5. web-extを使用すれば、ファイルの編集を検知しての自動再読み込みすら可能です。 ↩

6. Manifest V3では、バックグラウンド動作は、何らかのイベントを契機に実行される短命なスクリプトのみ使用が許されています。 ↩

7. Proof of Concept。概念実証のための実装。 ↩

8. それでも、ブラウザーそのものの改造に比べれば追従コストは小さいのですが。 ↩

9. 具体的には、Bug 1595883やBug 1773886など、TSTにおいてFirefox本体側の修正を待っている問題がいくつかあります。 ↩

10. 正確には、その主催であるAlex氏が運営するBrowserWorks社。 ↩