結城です。
ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の8つ目は、「こういうことはしないようにしましょう」という反面教師として、要望が通らない場面での望ましくない振る舞いが見られる実際のフィードバック事例をご紹介します。
（以下の引用部は、元々はすべて英語でなされたやり取りですが、原文と訳文を両方掲載すると長くなりますし、ここでは英語の表現自体を参考にするわけではないので、筆者による抄訳のみ掲載します。）
Firefoxのタブバーの位置の議論
最初に、経緯を簡単に説明しておきましょう。
Firefoxのタブバーは、当初は「戻る」「進む」などのボタンがあるツールバーの下に置かれていましたが、Google Chromeに合わせるようにFirefox 4でウィンドウの最上部へと変更され、その後元の位置に戻す設定も削除されたという歴史があります。
タブバーの位置がウィンドウ最上部で固定されるようになった直後から、「元の位置に戻せるようにして欲しい」という要望が寄せられ始めましたが、その当時はいくつかのアドオンを使ってタブバーの表示位置を変更できたことから、要望は却下されていました。しかし、その後のFirefoxの仕様変更により状況が変わったため、再びこの要望がクローズアップされた……というのがここで採り上げる報告の背景事情です
■タイトル タブを（ツールバーの）下に置くモードの追加 ■説明（要約） この報告はBug #755593の複製として作られました。 その報告の最後のコメントでは、動作を元に戻すアドオンがあるので、この事はもはや問題ではないということになっていました。 最近のバージョンのFirefoxではアドオンでは実現できず、about:config（訳註：詳細設定の画面）でuserChrome.css（訳註：FirefoxのGUIを高度にカスタマイズする、上級者向けの設定ファイル）を有効化し特定のコードをそこに書くという手間が必要となっており、これは大多数の人にとって直感的ではない、と私は思います。 なお悪い事に、Mozillaはタブバーの移動のために必要なコードを変更させ続けており、平均的なユーザーまでもが手作業でそれに追従することを強いられています。 また、大多数の人が最上部にタブバーを置いたまま使っているのは、既定の設計がそう変わった後にただそれを受容したからであって、彼らが望んでそうしたわけではありません。
これに対し、とある開発者は以下の通りコメントし、この報告に「RESOLVED（解決済み）」「WONTFIX（対応しない決定をした）」という印を付けました。
私達はこれをやらないことにしました。 というのも、これを望む人の数が非常に少なく（あなたが述べている通り、ほとんどの人はタブバーの位置がどちらでも気にしていないようです）、「タブバーを下にする」モードを実装し維持するコストが不釣り合いな程に大きいからです。
ここで、開発者から判断の根拠が2つ示されていることに注目してください。このことから、「この機能は実装しない」という決定を覆すために必要なのは以下のことであると言えます。
-
要望を寄せる人が多いという事実を示す。
-
対応するコストは実際には小さいという事実を示す。
これに対して実際にどのようなコメントが行われたかを見てみましょう。
適切でない振る舞いの実例
開発者のコメントを受け、報告者以外の人達からは批判的なコメントが寄せられました。その中から2件を抜粋してみます。1件目はこちら：
私はこれが理由でFirefoxの使用をやめました。 あなた達がGoogle Chromeをコピーしたいなら、私はGoogle Chromeに移ります。 私はこの機能だけが理由でFirefoxを使っていました。 「みんな地獄に落ちろ」とあなた達が言っているということが私には信じられません。 地獄に落ちろとは言ってないと証明したいなら、この問題を修正して証明してください。
もう1件はこちら：
「この事を問題視している人は非常に少ない」と言うのは無意味です。 大多数のユーザーは「バグを報告する」ということ自体を知りません。 彼らはたとえ、困っていて深刻な影響を受けていても、それに甘んじて生活する事を学んだか、他のブラウザーに移ることを選びました。 このようなユーザー層からの声をあなた達はほとんど聞いていません。 そういう人の中で、実際に時間をかけてフィードバックする人はほとんどいません。 実際に報告している人は、その問題が彼らにとって本当に重要で、深刻な影響があるからこそしています。 そして、「WONTFIX（修正しない）」という解決を突きつけられ顔をドアにぶつける羽目になった人達がそこにいます。 彼らに大きな影響を与えた問題はまだ残ったままです。 繰り返しますが、それを受容して生きるか、ブラウザーを乗り換えるしかありません。 その中には、この問題について筆を執る時間をもう取らないと決めた人達もいます。 理由を考えてみてください。
この両者に共通しているのは。決定を覆すために必要なことを実施するというアクションは起こさず、悪く言えば、自分の主張が100%通るまでゴネることしかしていない、という点です。
悪い例の1つめは、以下のように分析できます。
-
開発者の感情を逆撫でする、捨て台詞じみたことを言っている。
-
私に見捨てられたくなければ私の要求に応じろ、という恫喝的な言い方をしている。
-
「○○していないことを証明せよ」という不可能な要求をしている（悪魔の証明）。その「証明」の方法として、自分の要望を実現することを唯一受け入れ可能な答えとして示しており、それ以外の解決策は拒否する姿勢を取っている。
悪い例の2つ目は、以下のように分析できます。
-
自分がいかに困っているかを説明することに終始して、開発者の翻意を迫る以外の事をしていない。
-
開発者が聞く耳を持っていないと決めつけている（実際には、聞いた上での議論の末に決定が下っている）。
-
原文では「they do it BECAUSE the problem IS important ...」のように一部のフレーズを大文字にして強調している（英語の文章では、このような表現は 「声を荒げる」 ということに相当する）。
これらの例は、OSSプロジェクトの行動規範（Code of Conduct）において 「容認されない行動の例」として挙げられることの多い「荒らし・煽り、侮辱的・軽蔑的なコメント」に該当する と筆者には思えます。
開発者は、寄せられる要望のすべてには応えられません。矛盾する要望同士には応えられませんし、プロジェクトとして「これはやらない」と敢えて決定する（スコープを明確にする）こともあります。仮にスコープ内だとしても、人的・金銭的リソースが足りないため実現できないということもあります。
判断を覆すための材料を提示する責任は、基本的に、判断に異を唱える側の方で負うことになります。それは、判断の元になった前提を崩す新しいデータを示すことかもしれませんし、あるいは、リソース不足が原因なのであれば、それを補うリソースを提案者が提供する（寄附、コードでのコントリビュートなど）ことかもしれません。
そう考えると、悪い例に共通しているのは、そのような責任を回避して、すべてをプロジェクト運営者側に押しつける姿勢だと言えるでしょう。
要望が通らなくても、建設的な議論はできる
一方、報告者自身も一旦は感情的になった様子ではありながら、こちらはもう少し建設的なコメントをしていました。
（訳註：開発者からの「他のブラウザーではそもそもCSSでそのようなカスタマイズをすることすら不可能なので、今でも恵まれた状況だということを分かって欲しい」というコメントを受けて） 確かにありがたいことですが、この方法はいつまで利用可能と思えばいいでしょうか？ Firefox側で絶えず行われる変更に対し、この回避策を使いたい人はその都度追従しなくてはならず、このような事実は間違いなく、Firefox開発者たちがこの回避策自体をぶっ壊してしまおうとしているような印象を与えます。 実際に彼ら開発者は、WebExtensionsへの移行によって多くのUIカスタマイズ性を失わせ、私がFirefoxを好きだった理由の多くを吹き飛ばしてしまいました。
これに端を発して、2人の開発者から以下のような状況説明のコメントがなされました。
開発者たちはFirefoxのUIをHTMLで書き直すことに忙しいだけです。 CSSでのカスタマイズ性自体はどこにも行っていません。（中略）userChrome.cssの機能は非常に単純です。 機能のメンテナンスに要するMozilla側のコストは非常に小さいと言えるので、機能が消えることはまずないでしょう。
いえ、CSSでのカスタマイズ性がどこにも行っていないというのは真実ではありません。 Firefox 69ではuserChrome.cssは設定で有効化しないと使えなくなっています。 （中略） userChrome.cssはユーザーが自己責任で使う機能なのに、色々な問題の報告がなされる原因となっているため、ベンダーにとってブランド価値に対する脅威となっています。 （中略） ともかく、私はここがuserChrome.css自体の将来についての議論に相応しい場とは思いません。 本題と関係ない話をしてしまったことを、長大なCcのリストに含まれている人々にお詫びします。 （訳註：Bugzillaでは興味がある報告に自分のメールアドレスを登録し、コメントが付くごとにそれをメールのカーボンコピーのように受け取れるようになっている）
ここでの報告者のコメントで注目したいのは、「回避策が将来的に使えなくなってしまうことを心配している」という、今まで言語化されていなかった新たな懸念点を説明している、という点です。
報告者の側は「相手は開発者で専門家なんだから、このくらい当然知ってるだろう、察してくれるだろう」という期待を持ちがちでしょう。しかし、OSSでは（実際にはOSSに限りませんが）開発者といえどもすべてのことを把握しているとは限りません。この事例でも、1人目の開発者は「代替の手段もなくなりそうになっている」という事実を正確には把握していなかったようです。
問題の種類によっては、開発者より外部の人の方が詳しいということはざらにあります。開発者は「ソフトウェアを開発する技術の専門家」ですが、「その問題について研究する専門家」とは限らないのです。判断材料になりそうなのにまだ議論のテーブルに載せられていない情報を持っているのなら、報告者の側から積極的に情報をテーブルに載せていくことが大事です。
また、もう一つこの報告者のコメントで注目したいのは、主観と客観を区別しているという点です。
前出の良くないコメントの例はどちらも、「開発者たちはこう考えている」という、文の主語が発言者自身ではなく開発者となる書き方をしています。本人の考えを勝手に代弁するのは、端的に言えば「相手の考えを決めつける」ことです。このような言われ方をすると、言われた側は「いやそんなことは言っていない」と反論したくなるものです。
それに対し、報告者のコメントでは「～な印象を与えます1」という書き方をしています。これは、受け取り手の側（自分）はこう感じたという、間接的にではあるものの自分が主語となる言い方です。このような書き方であれば、言われた側も「そうか、あなたはそう思ったのか」と、抵抗なく発言内容に耳を傾けることができます（ここで「いや、あなたがそう感じるのは勘違いだ」などと反論しだせば、それこそ、その方が決めつけになってしまいます）。
このイシュー自体は、「議論が過熱して罵倒合戦になる」恐れがあるということで、それ以上コメントできないように開発者によって制限が設定されました2。しかし、userChrome.cssという機能が廃止されたとするとこのようなニーズに影響が出る、という情報が示されたことによって、プロジェクトにとっては機能の存続の判断材料が増えたと言えるのではないでしょうか。
まとめ
ノータブルフィードバックの8回目として、Firefoxに行われた実際のフィードバックの中で見られた「要望が通らなかったときにするべきでない、望ましくない振る舞い」の例をご紹介しました。
このような失敗事例の紹介も交えながら、「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる！ はじめてのOSSフィードバックガイド ～ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと～」を、同人誌としてリリースしました。本記事の内容はこの本からの抜粋となっています。4月5日までオンライン開催されている「技術書典 応援祭」内のマーケットにて紙版＋電子書籍（または電子書籍のみ）を購入頂けますので、ゆっくりオフラインで読みたい方はぜひチェックしてみて下さい。
