株式会社クリアコード > ククログ

ククログ


ノータブルフィードバック8 - 要望が通らなかったときの振る舞い方

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の8つ目は、「こういうことはしないようにしましょう」という反面教師として、要望が通らない場面での望ましくない振る舞いが見られる実際のフィードバック事例をご紹介します。

(以下の引用部は、元々はすべて英語でなされたやり取りですが、原文と訳文を両方掲載すると長くなりますし、ここでは英語の表現自体を参考にするわけではないので、筆者による抄訳のみ掲載します。)

Firefoxのタブバーの位置の議論

最初に、経緯を簡単に説明しておきましょう。

Firefoxのタブバーは、当初は「戻る」「進む」などのボタンがあるツールバーの下に置かれていましたが、Google Chromeに合わせるようにFirefox 4でウィンドウの最上部へと変更され、その後元の位置に戻す設定も削除されたという歴史があります。

(Firefox 3.5では下にあったタブが、現在はウィンドウ最上部にある)

タブバーの位置がウィンドウ最上部で固定されるようになった直後から、「元の位置に戻せるようにして欲しい」という要望が寄せられ始めましたが、その当時はいくつかのアドオンを使ってタブバーの表示位置を変更できたことから、要望は却下されていました。しかし、その後の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日までオンライン開催されている「技術書典 応援祭」内のマーケットにて紙版+電子書籍(または電子書籍のみ)を購入頂けますので、ゆっくりオフラインで読みたい方はぜひチェックしてみて下さい。

*1 原文では「it definitely gives the impression that~」となっています。

*2 原子力発電所の設置の可否のような難しい問題の議論にはあまり人が参加せず、自転車置き場を設置するかどうかのような身近で些細な問題の議論にはなぜか人が集まってきて加熱するという、いわゆる「自転車置き場の議論」を避けるために、OSSのイシュートラッカーではこのような措置が執られることがあります。

2020-04-02

ノータブルフィードバック7 - 開発者の環境では必要ない改善の提案

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の7つ目は、前回フィードバック対象となったMouse Dictionaryに対して筆者が別に行った、連続した一連のフィードバックです。

実際の報告

最初に行ったのは、前回のフィードバックで表示されるようになった初期設定の案内文の内容が、Firefoxでの実際のUIに整合しない状態だったために行ったフィードバックです。

■タイトル

初回使用時の案内がFirefoxでの状況にマッチしていない

■説明

初回使用時に辞書が未設定だと、ページ内に開いたポップアップの中に「初めに辞書データをロードしてください(拡張のアイコンを右クリック→「オプション」)」という案内のメッセージが表示されます。
しかしながら、Firefoxにはこのメニュー項目がありません。実際には、

  • アイコンを右クリック→「拡張機能を管理」を選択→「...」をクリック→「オプション」を選択

とする必要があります。

初回使用時に戸惑ったため、メッセージを各実行環境向けに変えることが望ましいと思われます。

このイシューに対応するプルリクエストは以下の内容でした。

■タイトル

Show initial setup guide for Firefox
≪Firefox用の初期設定案内を表示する≫

■説明

#32 に対する実装の提案となります。
こんな感じでいかがでしょうか?

■変更内容

メッセージの定義部にFirefox用のメッセージを追加し、実行環境によってメッセージを切り替えるようにした。

そのレビューの中で「コーディングスタイルをprettier準拠に揃えて欲しい」という指摘を受けたのですが、それをきっかけに作成した別のプルリクエストが、次の物です。

■タイトル

Add prettier
≪prettierを追加する≫

■説明

#33 でコーディングスタイルのご指摘をいただきましたが、コーディングスタイルもlintの一環とすることでコーディングスタイルの揃え忘れを減らせるのではないかと思いました。
いかがでしょうか?

変更内容:
package.jsonの文法チェック用の指定に変更を加え、コーディングスタイルをチェックするようにした。

注目したい点

状況に合わせたフィードバックの仕方

コミットメッセージから自動的に埋められたプルリクエストのタイトルを除いて、英語と日本語の併記ではなく、日本語だけでの報告となっています。これは、

  • プロジェクトオーナーが日本語話者だと分かっている。
  • 小規模な問題で、すぐにプルリクエストを出して問題を解消するつもりなので、イシューが長期に渡って残ることをあまり考慮しなくてもよさそう。

という前提があったためです。また、説明文については、「再現手順」「実際の結果」「期待される結果」を見出しを立てて強調するということもなく、自然文の中に入れてサラッと流してしまっています。これも、「初回起動時の一幕」という前提があるため、要点さえ押さえておけば伝わるだろう、という判断に基づいています。

フィードバックの経験が少ない状況では、どの情報を含めてどの情報を省略するべきかということの判断基準が不足していますので、下手をすると「その情報じゃなくて、こっちをむしろ残すべきだった」というような情報を省略してしまいかねません。そのため、「これでできる! はじめてのOSSフィードバックガイド」では「情報不足よりは情報過多の方がよい」という考えに基づいて、基本的な報告のフォーマットを紹介しています。

そのような取捨選択の感覚は、恐らく、報告をする立場だけだとあまり身に付きません。というのも、フィードバックは 「フィードバックを受ける側(開発者)にとって助けとなる内容」であること が望ましく、「どういう報告なら開発者は嬉しいか」ということは、突き詰めると開発者でなければ分からないからです。筆者の場合は、自分自身が開発者としてフィードバックを受ける機会が重なる中で、「こういう場面では、この情報をもらっても開発者の自分はあまり嬉しくない」という経験を得ており、それが取捨選択の判断基準になっています。

フィードバックの連鎖と、開発者以外の人に役立つフィードバック

また、もう一つ注目して欲しいのは、「プルリクエストに対するレビューを受けたときに気が付いたことを、別のプルリクエストで即座に(カジュアルに)フィードバックしている」という点です。1つフィードバックをすると、それがまた次のフィードバックにつながるということは、非常によくあります。

そうして行った2つ目のプルリクエストは、実はプロジェクトオーナーの方にとっては直接的には必要のない変更です。筆者は特に文法チェックや整形などの開発支援の仕組みを持たないテキストエディタを使っていますが、プロジェクトオーナーの方ご自身は、コーディングスタイルの整形はVSCodeの設定でファイルの保存時に行うようにされているからです。

このようなときには、自分が使っているテキストエディタの設定を変更したり、そのような設定がなければ別のテキストエディタへ乗り換えたりと、自分の手元の環境の範囲で改善を図る方が多いでしょう。しかしここでは、それを 「個人の環境設定の問題」とは捉えず、「プロジェクトオーナーがプルリクエストの内容を一々チェックしないといけないという、プロジェクトの問題」と捉え 、それを解消するプルリクエストを出したのでした。「問題をプロジェクトの問題だと捉えると、フィードバックできる点になる」ということの実例と言えるでしょう。

まとめ

ノータブルフィードバックの7回目として、フィードバックの連鎖の中で行った、「開発者の方にとって直接的には役には立たないけれども意味のある改善」の例をご紹介しました。

このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」を、電子書籍としてリリースしました。本記事の内容はこの本からの抜粋となっています。4月5日までオンライン開催されている「技術書典 応援祭」内のマーケットにて紙版+電子書籍(または電子書籍のみ)を購入頂けますので、ゆっくりオフラインで読みたい方はぜひチェックしてみて下さい。

2020-03-27

ノータブルフィードバック6 - 初回使用時のつまずきを減らす提案

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の6回目として、今回は、[株式会社アカツキさんの社内で実施したOSS Gateワークショップ][20190529]の中で実際に行われた、Webページ上でマウスカーソル(ポインタ)をかざした位置の語句を辞書で引いて結果をポップアップ表示する「Mouse Dictionary」というGoogle Chrome/Firefox用の拡張機能での、「初回使用時にポップアップが真っ白になってしまう」という現象に対するフィードバックをご紹介します。

実際の報告

■タイトル

White screen shown in the first boot

■説明

Steps to Reproduce

  1. Install Chrome (ver. 72.0.3626.109 Official Build 64bit) into MacOSX 10.14.3 .
  2. Install Mouse Dictionary (ver. 1.1.9) from Chrome Web Store.
  3. Click extension icon of Mouse Dictionary, and open the popup window.
  4. Point any English term.

Expected Result

  • Shown translated sentence of English term in the popup window.

Actual Result

  • White screen shown in the popup window.

Suggestion

  • Add how to installation (ex. "Open option menu on the first boot.") in the store page.
  • Or, add description (ex. "Not initialized. Please open option menu.") in the not initialized popup window.

再現手順

  1. MacOSX 10.14.3 に、Chromeのバージョン:72.0.3626.109(Official Build)(64 ビット)をインストールする
  2. chromeウェブストアから Mouse Dictionary (バージョン:1.1.9) を拡張機能としてインストールする
  3. 拡張機能一覧から Mouse Dictionary のアイコンをクリックして、ポップアップウィンドウを立ち上げる
  4. ポップアップウィンドウが立ち上がった状態でウェブページ内の任意の英単語にマウスカーソルを合わせる

期待する結果

  • Mouse Dictionary のポップアップウィンドウに、翻訳結果が表示される

実際の結果

  • ポップアップウィンドウ内は白紙のまま、何も表示されない

提案

  • 最初にオプションメニューを開くことが必須ということを、ストアページの説明文に記載してはどうでしょうか
  • もしくは、辞書情報が登録されていないのでオプションメニューを開かなければならない旨を、ポップアップウィンドウに表示してはどうでしょうか

注目したい点

日本語でも書く

OSS Gateワークショップの中で行ったフィードバックなので、報告の仕方は「再現手順、期待する結果、実際の結果」という基本のフォーマットに則っています。

ここで注目したいのは、本文を英語と日本語の2パターンで書いているということです(ここに掲載するために翻訳したのではなく、元々の報告の時点で両方載っています)。これは、説明文からリンクされている開発者の方による解説記事が日本語で書かれており、作者の方が日本語話者の方だということが分かっていたためです。

OSSへのフィードバックは、書ける場合は英語で書いておいたほうが望ましいです。というのも、英語を読み書きできる人と日本語を読み書きできる人とでは前者の方が圧倒的に数が多く、日本語だけで報告を書いていると、同じ問題に遭遇した人が「既存の同様の報告」にたどり着けない恐れがあるからです。

とはいえ、英語を書くことに不慣れな人は、自分の伝えたかったことをきちんと英語で表現できているか不安なものです。この事例のように作者の方が日本語話者と分かっている場合には、両方の言語で報告を書いておくことで、万が一の場合の誤解を防げるという安心感を持って報告できるでしょう。

使い始めのつまずきを報告している

第1回でとりあげたOCamlへのフィードバックでは、インストール後のバージョン確認の手順の間違いをフィードバックしましたが、今回もそれと同様に、初めて使うときにつまずく人の多そうな点をフィードバックしています。

一般ユーザーでも開発者でも、「説明書を読まずに使い始める」人は一定数います(筆者もそうです)。そのような人にとっては、説明を読んで使うことが前提のツールは使い始めていきなり「詰んで」しまう、ということになりがちです。初期化用のウィザードやチュートリアルはその最も丁寧な対応の例ですが、そこまで凝った対応でなくても、この提案のように「案内のメッセージを出す」だけでも、ほとんどのユーザーにとっては大きな助けになるでしょう。

提案も書く

また、報告の最後に 「提案」として改善案を示している ところもポイントです。操作に対する「期待される結果」は「翻訳結果が表示されること」なのですが、初回使用時という場面では、初期設定なしにそのような結果を得るのは難しいです。そこで、この報告では次善の策として、ユーザーがしなければならないことの案内を明示するのはどうか、と提案しています。

開発者側で気を回して「こうなっているといいのでは」と推測して実装した結果が、実際のユーザーのニーズに合致していなかった、ということは度々あります。ユーザー自身が「どうなっていると嬉しい」という内容を詳しく伝えることで、そのような無駄足を踏まずに済むと言えます*1

まとめ

ノータブルフィードバックの6回目として、Google Chrome/Firefox向け拡張機能の初回使用時の動作についてのフィードバックをご紹介しました。

このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」を、電子書籍としてリリースしました。本記事の内容はこの本からの抜粋となっています。4月5日までオンライン開催されている「技術書典 応援祭」内のマーケットにて紙版+電子書籍(または電子書籍のみ)を購入頂けますので、ゆっくりオフラインで読みたい方はぜひチェックしてみて下さい。

*1 ただ、開発者側の視点では、ユーザーから寄せられた提案にそのまま従うことが必ずしも正解とは限らない、ということも言えます。というのも、ユーザー自身の発想が特定の場面やそれまでの経験に囚われている場合、言葉として表現された物が本来のユーザー自身のニーズからかけ離れてしまっていることがあるからです。開発者はユーザーからの提案を判断材料の一つとしつつ、その提案が発せられた背景をきちんと分析し、常に最適な解決策を考えるよう努める必要があります。

2020-03-23

ノータブルフィードバック5 - 開発者が把握していない使い方についての報告と、そこからのプルリクエスト

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の5つ目は、当社の畑ケさん*1meta-clangというプロジェクトに対して行ったフィードバックです。

実際の報告

■タイトル

meta-clang's llvm-config is not compatible with MULTILIBS
≪meta-clangのllvm-configが、MULTILIBSと互換性がない≫

■説明

≪不具合の説明≫
One of the our target boards(RZ/G2E)'s Yocto default conf/local.conf specifies MULTILIBS = "multilib:lib32" and DEFAULTTUNE_virtclass -multilib-lib32 = "armv7vethf-neon" to be able to run 32bit ARMv7 binaries.
≪私達が開発している対象のボード(RZ/G2E)の一つのYoctoレシピの既定のconf/local.confには、32bit ARMv7バイナリを動かすために、 「MULTILIBS = "multilib:lib32"」と「DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf-neon"」という設定が含まれています。≫
So, built binaries will be installed in /usr/lib64/ instead of /usr/lib.
≪そのため、ビルドされたバイナリは/usr/libではなく/usr/lib64/の中にインストールされます。≫

Because our SDK environment does not assume /usr/lib for library installation directory.
≪なぜなら、私達のSDKの環境は/usr/libをライブラリのインストール先ディレクトリーとして想定していません。≫
Instead, /usr/lib64 is used for 64bit libraries and shared object. And /usr/lib32 is used for 32bit objects.
≪その代わりに、/usr/lib64は64bitライブラリと共有オブジェクトに使われます。また、/usr/lib32は32bit版オブジェクトに使われます。≫

ref: https://llvm.org/docs/CMake.html#frequently-used-cmake-variables

To Reproduce
≪再現するには≫

Steps to reproduce the behavior:
≪この動作を再現するための手順:≫

  1. Specify MULTILIBS = "multilib:lib32" and DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf-neon" in local.conf
    ≪「MULTILIBS = "multilib:lib32"」と「DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf-neon"」をlocal.confの中で設定する≫
  2. Add meta-clang layer
    ≪meta-clangレイヤを追加する≫
  3. bitbake clang-cross-aarch64
    ≪bitbake clang-cross-aarch64を実行する≫
  4. add meta-browser and meta-rust layer
    ≪meta-browserとmeta-rustのレイヤを追加する≫
  5. bitbake firefox
    ≪bitbake firefoxを実行する≫
  6. See error
    ≪エラーが表示される≫

Error
≪エラー≫

≪実際に出力されたエラーの全文が貼り付けられているが、ここでは省略。≫

Expected behavior
≪期待される挙動≫

meta-clang's llvm-config can work with DEFAULTTUNE_virtclass-multilib-lib32 specified environment.
≪meta-clangのllvm-configが、「DEFAULTTUNE_virtclass-multilib-lib32」が指定された環境で動作すること。≫

llvm-config points to ${RECIPE_SYSROOT}/usr/lib/clang/8.0.1/lib/linux/ but actual libclang libraries are put in ${RECIPE_SYSROOT}/usr/lib64/clang/8.0.1/lib/linux/
≪llvm-configは「${RECIPE_SYSROOT}/usr/lib/clang/8.0.1/lib/linux/」を指定しますが、実際のlibclangライブラリは「${RECIPE_SYSROOT}/usr/lib64/clang/8.0.1/lib/linux/」に置かれます。≫

LLVM insists that using LLVM_LIBDIR_SUFFIX to control installation directory suffix such as lib64 or lib32.
≪LLVMでは、インストール先ディレクトリーの末尾をlib64やlib32のように変えたい場合、LLVM_LIBDIR_SUFFIXを使う必要があります。≫

We should handle library directory glitch it llvm-config with LLVM_LIBDIR_SUFFIX.
≪私達はLLVM_LIBDIR_SUFFIXを伴ったllvm-configのライブラリーの配置先ディレクトリーのずれに対処するべきでしょう。≫

Desktop (please complete the following information):
≪ビルド環境のデスクトップ機(以下の情報を埋めてください)≫

  • OS: Ubuntu
  • Version 16.04.6 LTS

Additional context
≪追加の情報≫

(Updated) I'd encountered this issue during meta-browser's firefox recipe building.
≪(追記)私はこの問題に、meta-browserのFirefoxのレシピを使ってのビルド作業中に遭遇しました。≫

フィードバックの経緯

組み込み機器向けにカスタマイズしたLinuxディストリビューションを作成するためのツールセットの一種であるYoctoでは、そのLinuxディストリビューションに組み込めるパッケージが多数公開されています。その中で、C言語のコンパイラであるclangを組み込むための設定ファイルやスクリプトを提供しているのが、meta-clangというプロジェクトです。畑ケさんがとある組み込みボード*2用にFirefoxをビルドしようとして、Firefoxのビルドに必要なmeta-clangを構成に入れたところ、ビルド結果が想定通りにならず、Firefoxパッケージをビルドできないという状況に遭遇しました。

この時点で原因がmeta-clangにあるということは明らかだったため、畑ケさんは手元でとりあえずの回避策を講じた上で、問題に遭遇したということをmeta-clangにフィードバックしました。すると、その報告に対してプロジェクトオーナーから「Can you cook up a patch?(パッチを作ってもらえませんか?)」とコメントが返ってきました。そこで、畑ケさんは「I'm cooking up patches....(今パッチを作成中です……)」とコメントした上で、手元で行っていた暫定的な回避策を一般公開できるようにより洗練させ、プルリクエストにしました

その後パッチがマージされたことで、この報告もクローズされています。

注目したい点

これも、「自分の手元でなんとかして動くようにした」というところで終わらせないで、開発元にエスカレーションした事例です。

最終的にプルリクエストを出すところにまで至っていますが、畑ケさんは当初はそこまでするつもりはありませんでした。しかし 「パッチを作ってもらえませんか?」と逆に依頼された ことがきっかけとなり、プルリクエストの作成に至りました。フィードバックは「自分にできることをまずはやる」所から始めるとよいですが、やろうと思っていなかったことに挑戦する機会にもなるということの好例と言えるでしょう。

この報告はプロジェクトのイシューテンプレートに基づいて書かれていていますが、「To Reproduce」には再現手順と実際の結果が、「Expected behavior」には期待される結果が書かれており、問題の報告の基本の3要素がきちんと含まれていることが分かります。

フィードバックする前の予備調査の時点で、畑ケさんはこの作者の人が、ここで使おうとしている「MULTILIBS」という機能を使っていないようだ、ということを把握していました。そのため、再現手順や環境の作り方をより細かく具体的に書き、作者が容易に現象を確認できるようにすることを意識したそうです。CJKの言語に特有の事情を詳しく説明した前回の例と、考え方は同じです。

文中に登場している「glitch」という単語は、辞書では「故障」「誤動作」「異常」といった意味と出ますが、語源は「slip(滑る)」や「slide(ずらす)」と同じで、ニュアンスとしては「本来の正常な状態からずれてしまっている」状態を表すそうです。インデントのずれや画像の位置ずれなどにも使える表現ということで、覚えておくとよいでしょう。

ところで、この例も報告文の中にミスタイプがあります。

We should handle library directory glitch it llvm-config with LLVM_LIBDIR_SUFFIX.

この文の「it」は誤記で、「in」が正しいです。先の筆者の例と併せて見ると、誤記はありふれたものだということをなんとなく感じて頂けるのではないでしょうか*3

まとめ

ノータブルフィードバックの5回目として、開発者が想定していない使い方での不具合を報告するフィードバック例をご紹介しました。

このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」を、電子書籍としてリリースしました。本記事の内容はこの本からの抜粋となっています。ダウンロード購入のチャンネル、紙媒体版などの詳細については、「ノータブルフィードバック」第4回目の記事を併せてご参照下さい。

*1  「はたけ」と読む珍しい名字のため、社内でもよく「ケ」が行方不明になりがちです。

*2 複合機やカーナビなどの制御に使われるコンピューター。

*3 畑ケさん本人にこの事を知らせると「やっちまったぁぁ」と恥ずかしがっておられましたが、本書でフィードバック初心者の方に勇気を持ってもらうための礎になっていただきました。合掌。

2020-03-02

ノータブルフィードバック4 - 開発者が知らない言語圏に固有の問題の報告

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の4つ目は、筆者がチャットツールのZulipに対して行ったフィードバックです。

実際の報告

■タイトル

typeahead: "keydown" events for Enter and Arrow keys should be ignored while "composition"
≪インクリメンタル検索: Enterキーと矢印キーのkeydownイベントは「コンポジション」の最中は無視されるべき≫

■説明

First, I describe what is the "composition".
≪最初に、「コンポジション」とは何かを説明します。≫

In CJK language regions, people use some software named "IM" (input method) to input heir local language text. For example, when I search a Japanese term "日本語" (means "Japanese language") in a Zulip instance with Firefox, I need to do:
≪CJK(中国語・日本語・韓国語)の言語の地域では、人々は彼らの地域言語のテキストを入力するために「IM(インプットメソッド)」と呼ばれるソフトウェアを使っています。たとえば、私が日本語の単語「日本語」をFirefoxで表示したZulipで検索するとき、私は以下のような操作をする必要があります:≫

  1. Click the search field.
    ≪検索欄をクリック。≫
  2. Activate the IM. The "composition" session starts.
    ≪IMを有効化する。「コンポジション」のセッションが始まる。≫
  3. Type keys: n, i, h, o, and n. (in a composition session)
    ≪(コンポジションのセッションの中で)n, i, h, o, nとキーを入力する。≫
  4. Hit the Space key to convert the text to Japanese term. "日本" is suggested. (in a composition session)
    ≪(コンポジションのセッションの中で)テキストを日本語の単語に変換するために、スペースキーを押す。「日本」が提案される。≫
  5. Hit the Enter key to determine the text "日本". (in a composition session)
    ≪(コンポジションのセッションの中で)「日本語」というテキストを確定するために、Enterキーを押す。≫
  6. Type keys: g, and o. (in a composition session)
    ≪(コンポジションのセッションの中で)g, oとキーを入力する。≫
  7. Hit the Space key to convert the text to Japanese term. "語" is suggested. (in a composition session)
    ≪(コンポジションのセッションの中で)テキストを日本語の単語に変換するために、スペースキーを押す。「語」が提案される。≫
  8. Hit the Enter key to determine the text "語". (in a composition session)
    ≪(コンポジションのセッションの中で)「語」というテキストを確定するために、Enterキーを押す。≫
  9. Deactivate the IM. The "composition" session ends.
    ≪IMを無効化する。「コンポジション」のセッションが終了する。≫
  10. Hit the Enter key again to search "日本語" on Zulip.
    ≪「日本語」をZulipで検索するために、Enterキーをもう1度押す。≫

While the composition session, "keydown" events for special keys (Enter and Arrow) are handled by the IM to choose a term from variations >or determine the choice. Thus I hit the Enter key three times in this case. The first time and the second are notified only to IM, so Zulip receives only the third time.
≪コンポジションのセッション中は、(Enterや矢印などの)特別なキーに対するkeydownイベントは、IMによって、複数の候補の中から単語を選択したり選択を確定したりするために使われます。そのため、私はEnterキーをこの例では3回押しています。1回目と2回目はIMに対してのみ通知されるため、Zulipは3回目のみを受け取ります。≫

And, there is one problem on lately development build of Firefox.
≪そして、最近のFirefoxの開発者向けビルドでは一つ問題があります。≫

  • 1446401 - Start to dispatch keydown/keyup events even during composition in Nightly and early Beta
    https://bugzilla.mozilla.org/show_bug.cgi?id=1446401
    ≪1446401 - Nightlyと初期ベータ版で、コンポジション中のkeydownとkeyupイベントを通知するようにする≫
  • Intent to ship: Start to dispatch "keydown" and "keyup" events even if composing (only in Nightly and early Beta) - Google Group
    https://groups.google.com/forum/#!topic/mozilla.dev.platform/oZEz5JH9ZK8/discussion
    ≪リリースしようとしているもの: Nightlyと初期ベータ版のみにおいて、コンポジション中にkeydownとkeyupイベントが通知されるようになります≫

Due to the change, now development build of Firefox (aka Nightly) notifies "keydown" events to the webpage, for all keyboard operations while "composition" sessions. As the result, the search field shows suggested results while I'm typing alphabet keys. This is good improvement, but there is one new problem: when I hit the Enter key to determine a chosen term, it is also notified to Zulip. Thus, when I just determine the first part term "日本" of the joined term "日本語", Zulip unexpectedly handles the Enter key to search the part "日本" and I cannot input following part "語" anymroe.
≪この変更のため、Firefoxの開発版ビルド(別名Nightly)は「コンポジション」セッション中の物も含めすべてのキーボード操作に対し、keydownイベントをWebページに通知します。その結果、検索欄は私がアルファベットのキーを入力している最中に候補を表示します。これは良い改善ですが、しかし新たに1つの問題が発生しています:選択を確定するために私がEnterキーを押したとき、それがZulipにも通知されます。そのため、私が「日本語」という複合語の一部として「日本」を確定しようとしたときにまで、Zulipは意図せずそのEnterキーの操作を「日本」という単語を検索するための物として取り扱い、続く「語」という単語を私は入力することができません。≫

To fix this problem, Zulip need to ignore keydown events for Enter and Arrow keys while the composition session. While a composition session, all keydown events have the isComposing (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/isComposing) property with true value, so you just need to return when the property is true. Could you apply this change to Zulip?
≪この問題を直すためには、ZulipはEnterと矢印キーのkeyダウンイベントをコンポジションのセッション中は無視する必要があります。コンポジションのセッション中は、すべてのkeydownイベントがisComposingというプロパティをtrueという値を伴って持っています。そのため、そのプロパティの値がtrueであるときはすぐに処理をリターンする必要のみあります。この変更をZulipに反映してもらえませんか?

Environment:
≪環境≫

  • Zulip 1.8.0
  • Mozilla Firefox Nightly 62.0a1
  • Ubuntu 16.04LTS + IIIMF ATOK X3

フィードバックの経緯

筆者の所属会社では、社内のチャットとしてSlackではなく独自にサーバーを立てたZulipを使っています。その運用中に、Firefoxの開発版で問題になる箇所があることに気付いたため、開発元にフィードバックしたという事例です。

日本語のようにキーボードのキーの数よりも入力したい文字の種類が圧倒的に多い言語では、文字入力専用のソフトウェアを介して文字を入力するのが一般的です。また、日本語の文章では単語間にスペースが入らないのが一般的です。このような言語には他に中国語と韓国語もあり、テキストデータやその入力、文字コードの取り扱いの文脈ではこれらの言語がよく話題に挙がるため、3つをひっくるめて 「CJK」 *1と呼ぶことがあります。

CJKを想定していない機能とCJKの言語はあまり相性が良くない傾向にあり、「インクリメンタル検索」もその一例です。英語のようにキーと入力したい文字とがほぼ1対1で対応している言語では、文字を入力したそばから検索が進行するインクリメンタル検索が好まれます。しかし、CJKの言語では「入力中の文字が最終的に入力したい文字とは異なっている(未確定である)」という状態があります。この状態を考慮していない実装でインクリメンタル検索が発動すると、日本人にとっては文字入力がそもそもできないという困った事態になります。

この報告を行った前後の時期には、Firefoxの仕様変更でこの種の問題が起こりやすくなっていたため、Mozillaからもソフトウェア開発者やWeb制作関係者向けに公に注意が呼びかけられていました。報告の中で紹介している記事が、まさにそれです。

注目したい点

CJKを母語としない開発者にはこういった事情がなかなか分からないらしく、「そもそもどういう前提があるのか」ということから詳しく説明しないと、問題に対処してもらえないということも珍しくありません。そのためこの報告では、CJKの言語ではどうやって文字を入力するのか、その中でこの問題がどういう影響を及ぼすのか、ということを詳しく述べました。その後のコメントで実装の改修案を併せて示したこともあってか、開発者の方には問題をスムーズに認識してもらうことができ、迅速に解決してもらえました。

言語のように自分の生活と密接に結び付いた領域の話は、報告者にとってもあまりに当たり前のことすぎて、明確に言葉で説明するのが逆に難しいものです。報告者が「なんでこれが問題だと分かってくれないんだ!?」とフラストレーションを感じる一方で、その報告内容は、報告を受けた側から見ると「要領を得ない言葉足らずのもの」となっていることも多く、何が問題なのかを理解できないために、うっかり適切でない判断をしてしまうことがあります。そのような悲しいすれ違いを避けるためにも、報告者は自分の状態を「自明のもの」と考えず客観視して、どこが相手からは見えていない部分なのかを探り、自分から情報を積極的に開示する姿勢を保つことが望ましいです。

なお、同様のことがアラビア語などの書字方向がRTL(右から左に文字が流れる)の言語にも言えるようです。LTR(左から右)の言語だけを想定したソフトウェアは(特にGUIが)、RTLの言語で使うと悲惨なことになりがちなようです。皆さんがOSSを公開したら、もしかするとそういった言語圏の方から逆にフィードバックを受けることになるかもしれませんので、そのときはぜひ耳を傾けてください。

ところで、以下の文のおかしいところに皆さんは気が付かれましたか?

In CJK language regions, people use some software named "IM" (input method) to input heir local language text.

実はこの文の「heir」は誤記で、「their」が正しいです。ベテランでもこのようなミスタイプが残ったまま報告してしまうことがある*2と思うと、皆さんも、英語の間違いを過度に恐れる必要はないのだなと勇気づけられるのではないでしょうか。

まとめ

ノータブルフィードバックの4回目として、開発者が日本語に詳しくないときに日本語入力の場面に固有の不具合を報告するフィードバック例をご紹介しました。

このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」を、本日付けでリリースしました

本記事の内容はこの本からの抜粋となっています。全文を読む方法には以下の選択肢があります。

  • EPUB/PDF形式の電子書籍データは、現時点では結城が個人的に運営しているBOOTHおよびAmazon Kindleダイレクト・パブリッシングでご購入いただけます。
  • 紙媒体版は、「技術書同人誌博覧会」や今後の「技術書典」に持ち込ませて頂く予定です。他には、同人誌書店での委託販売・通販なども検討中ですが、具体的な予定はまだありません。
  • 本の原稿のリポジトリでは全文を読めるほか、リポジトリをcloneしてビルドすると、これらのチャンネルで頒布している物と同等のデータをお手元で作成できます。腕に自信のある方はチャレンジしてみてもいいかもしれません。(そういうわけなので、有料の販売については投げ銭もしくはビルド作業の手間賃と考えて頂ければ幸いです)

*1 そのまま「Chinese, Japanese and Korean」の略です。

*2 ちなみに筆者は、コミットログのメッセージでもよくミスタイプをしていますが、そのままpushしてしまっています(pushした後で気が付くことが多い)。

2020-02-29

ノータブルフィードバック3 - リリースマネージメントの見落としの報告

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の3つ目は、当社の足永さんがcollectdというソフトウェアに対して行った、リリースマネジメントに関するフィードバックです。

実際の報告

■タイトル

The source packages of collectd-5.9.2 aren't generated by the formal procedure
≪タイトル:colelctd-5.9.2のソースパッケージが通常の手順で生成されない≫

■説明

Version of collectd: collectd-5.9.2 on git
≪collectdのバージョン:git上のcollectd-5.9.2≫

Expected behavior≪期待される結果≫:
version-gen.sh script should generate "5.9.2" on collectd-5.9.2 tag.
≪version-gen.shスクリプトがcolelctd-5.9.2タグに基づいて「5.9.2」を生成する。≫

Actual behavior≪実際の結果≫:
version-gen.sh script generates "5.9.1.7.gdfb9dd0 on collectd-5.9.2 tag.
≪version-gen.shスクリプトがcolelctd-5.9.2タグに基づいて「5.9.1.7.gdfb9dd0」を生成する。≫

Steps to reproduce≪再現手順≫:
$ git clone https://github.com/collectd/collectd.git
$ cd collectd
$ git checkout collectd-5.9.2
$ ./version-gen.sh

Cause of the issue≪問題の原因≫:
collectd-5.9.2 tag isn't annotated.
≪collectd-5.9.2タグに注記が付いていない。≫

フィードバックの経緯

足永さんがとある案件でcollectdの独自改修版を作成して、お客さん向けに提供するためのパッケージを所定の手順で作成しようとしたところ、当時の最新リリース版である「5.9.2」からの派生版なので「5.9.2.(リビジョン番号)」というバージョン番号が自動生成されるはずが、なぜか「5.9.1.(リビジョン番号)」というバージョン番号になってしまう、という現象に遭遇しました。

この原因を足永さんが調べたところ、以下のことが分かりました。

  • パッケージ作成用のスクリプトは、Gitリポジトリに対して打たれたタグのメッセージが特定の形式に則って書かれている場合にのみ、それを正常なバージョンとして認識するようになっている。
  • バージョン5.9.2のタグのメッセージは、その形式に則っていなかった。

実際に、公開されているcollectdに対して何も変更を行っていない状態でパッケージを作成しようとしても、やはり同様の現象が発生する状態でした。そのため、足永さんはこの問題をcollectdプロジェクトで解決されるべき物として、調査結果を踏まえてフィードバックしました。

報告の後のコメントのやり取りの中では、collectdプロジェクトにおいてリリース作業の担当者が今回から変わっていたことと、前任者から手順が正しく引き継がれていなかったためにタグのメッセージが適切に設定されていない状態だったということが分かりました。その後、問題の状態は解消され、この報告もクローズされています。

注目したい点

「作成されたパッケージのバージョン番号が違っている」というつまずきに遭遇したときには、暫定的な回避として「できたファイルのバージョン番号の部分をとりあえず書き換えて済ませる」というような対策を取ることが多いでしょう。そういったその場しのぎだけで終わらせずに開発元にフィードバックすると、同じ問題につまずく人が減ります。

この報告には、問題報告の基本の3要素である「再現手順」「期待される結果」「実際の結果」が揃っていて、再現手順には実際に操作したコマンド列もそのまま記載されています。文章で長々と説明しなくても、要点を押さえてあれば適切に伝わるということがよく分かります。

「期待される結果」「実際の結果」の説明文の英語の表現にも着目してください。

version-gen.sh script should generate "5.9.2" on collectd-5.9.2 tag.

「パッケージ作成手順に従って作業したら5.9.2というバージョンが付くべき」ということを言い表すのに、リポジトリに含まれているパッケージ作成用のスクリプトを主語にして「このスクリプトはこのような事をするべき」という書き方をしています。日本語で言いたいことを余すことなくすべて英語で言い表そうとしなくても、無生物を動作の主体として明記することで簡潔に表現できるという好例でしょう。

このフィードバックの面白いところは、ソフトウェアそのものの不具合というよりも、プロジェクトのリリースマネジメントへのフィードバックとなっているという点です。プロジェクトにおいて作業を複数人で分担している場合に、そのときの作業者の属人的な知識に依存したまま体制が組まれてしまっていると、他の人に作業が引き継がれた後にこのような形でトラブルが起こる場合があります。このフィードバックがなされていなければ、新しい担当者は次のリリースで同様の問題に遭遇し、原因の究明に奔走する羽目になっていたかもしれません。

まとめ

ノータブルフィードバックの3回目として、コードでもドキュメントでもない部分へのフィードバック例をご紹介しました。

このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」を、2月29日に電子書籍としてリリースします。本記事の内容はこの本からの抜粋となっています。ダウンロード購入のチャンネル、紙媒体版などの詳細については、は前々回記事を併せてご参照下さい。

書評のご紹介

前回記事に続き、筆者が個人的にご縁のあった関係で、イラストレーター業とWebデザイナー業を並行しておられるえす吉さんより書評を頂きましたのでご紹介します。ありがとうございます!

全体を通して豊富な実例とあわせた解説がされていて、最後まで詰まることなく読み進められました!

初心者が不安に感じる箇所を章ごとに丁寧に解消してくれるので、読み終わる頃には、この本を片手にまずは身近な問題に一歩踏み出してみよう、と思える内容だと感じました。

実際にそのOSSを切実に必要としている人からのフィードバックは、OSSの使い勝手やドキュメントの質の向上のために非常に重要です。また、Webサイトの「アプリ化」がめざましい昨今では、Web制作とOSSの関係性はより密になってきています。えす吉さんのようにWeb制作の現場でOSSをユーザーとして利用される立場の方からもOSSへフィードバックすることのハードルが下がって、仕事環境や成果物が改善されていくことに繋がれば何よりです。

2020-02-28

ノータブルフィードバック2 - 画面表示に関わる問題の報告

結城です。

ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の2回目として、画面上の表示に関わる問題の、より分かりやすい説明の仕方の例をご紹介します。

実際の報告

今回の例は筆者が開発・公開している、Firefoxに「縦長のツリー表示のタブバーとして動作するサイドバー」を提供するアドオン「Tree Style Tab」に寄せられたフィードバックです。早速見てみましょう。

■タイトル

Close button too small on some tabs and not of the same size in some tabs
≪いくつかのタブのクローズボタンが小さすぎ、他のタブでのものとサイズが異なる≫

■説明

Short description
≪短い説明≫
Close button too small on some tabs and not of the same size in some tabs
≪いくつかのタブのクローズボタンが小さすぎ、他のタブでのものとサイズが異なる≫

Steps to reproduce
≪再現手順≫

  1. Start Firefox with clean profile.
    ≪Firefoxを新しいプロファイルで起動する≫
    2.Install TST.
    ≪Tree Style Tabをインストールする≫
  2. Resize the TST bar to the minimum width possible
    ≪TSTのタブバーを、可能な限り最小の幅にリサイズする≫
  3. Open multiple tabs under multiple trees
    ≪複数のツリーの配下に複数のタブを開く≫

Expected result
≪期待される結果≫
Close button is of the same shape and size in all the opened tabs
≪すべての開かれたタブにおいてクローズボタンが同じサイズ・同じ形で表示される≫

Actual result
≪実際の結果≫
Screenshots 1 and 4 seem to have normal shaped and sized close buttons but screenshots 2, 3 have small button with different shapes.
≪スクリーンショットの1番と4番は通常の形とサイズでクローズボタンが表示されているようですが、スクリーンショットの2番と3晩ではボタンが異なる形になっています。≫

Environment
≪環境≫

  • Platform (OS): Arch Linux
    ≪プラットフォーム(OS):Arch Linux≫
  • Version of Firefox: 57.0
    ≪Firefoxのバージョン:57.0≫
  • Version (or revision) of Tree Style Tab: 2.2.7
    ≪Tree Style Tabのバージョン:2.2.7≫

添付されていたスクリーンショット(左から1、2、3、4)

注目したい点

文章ではなく画像で説明している

GUIを提供するソフトウェアでは、画面上の表示に関する問題が色々と起こります。その中でも、「ボタンが表示されない」のようなゼロかイチかで表現できない、「小さい」「大きい」「普通と形が違う」といった表現しかしようのない問題は、言葉での表現が非常に難しいです。主観的な表現は、「彼は見えにくいと言っているが、自分には十分に見える」というように、報告者と開発者の間で解釈が食い違うことも多いです。

そのため、画面表示に関わる問題は、スクリーンショットスクリーンキャスト(動画) があると、状況を開発者が正確に把握する上で大きなヒントになります。この事例でも、

  • 現象が起こるのは特定のテーマが選択されたときである。
  • 現象が起こるタブは深い階層に置かれたタブである。

ということが画像から読み取れて、迅速な原因究明につながりました。

なんとなく、で通じる英語

この報告をくれた人は、GitHubのユーザー情報によるとインドのベンガル在住のようです。英語のネイティブスピーカーでないためか、タイトルの

Close button too small on some tabs and not of the same size in some tabs

で「Close button」の後にbe動詞が抜けていたり*1、全体的に文が短かく簡潔だったりして、見る人が見れば「英語話者でない人が書く、あまり巧みでない英語」と感じられるものかもしれません。

でも、それで全然いいのです。報告は報告したい内容が伝わりさえすればよく、英語としての正しさは、その邪魔にならない程度に確保されていればまったく問題ないということが、この例からは分かるでしょう。

まとめ

ノータブルフィードバックの2回目として、GUIを伴ったソフトウェアの画面上の表示に関わる不具合のフィードバック例をご紹介しました。

前回記事にも記載しましたが、「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」をリリースします。本記事の内容はこの本からの抜粋となっています。

「これでできる! はじめてのOSSフィードバックガイド」は、EPUB/PDF形式の電子書籍のダウンロード販売を2月29日より執筆者の結城が個人的に運営しているBOOTHにて行う予定です。また紙媒体版についても、今後「技術書同人誌博覧会」や、クリアコード関係者が参加する技術イベントなどに持ち込ませて頂いて、細々と頒布していく予定です。どうぞご期待ください。

書評のご紹介

まとめた後ですが書評のご紹介です。

  • OSSへのフィードバックなんて自分とは遠い世界のことだと思っている人
  • 技術的に成長したいけれど身近なところに「師匠」がいない人

といった、本書の対象読者に近いと思われる方々がリスナー層に含まれていそうなPodcast「しがないラジオ」のパーソナリティのgamiさんに頂いた書評となります。お忙しい中ご覧頂き、ありがとうございます!

OSSを使う側から育てる側へ、エンジニアとしてのステージを1つ上げる。その初めての「OSSコントリビュート」にフォーカスして具体的な手順を解説した貴重な本。著者の失敗談が記載され、先に失敗を擬似体験できるのも魅力。OSS活動に興味があるエンジニアは必読の一冊です!

「しがないラジオ」は、技術力を高めてtech企業に転職したい方に人気のPodcastで、特に、さまざまな業界の方がゲスト出演されているSp.回(筆者も過去にゲスト出演させていただきました)は、キャリア形成の参考になるだけでなく「こんなふうにしてITエンジニアになった人もいるんだ!」「そんな働き方もあるんだ!」という新鮮な驚きを得られるコンテンツです。通勤時や筋トレ作業などのお供に最適と評判ですので、ぜひご一聴いただければ幸いです。

*1 期待される結果の文を見ると、「Close button is」と書きたかったのではないかと推測できます

2020-02-26

ノータブルフィードバック1 - 導入時のつまずきを減らす報告

結城です。

最近このブログで、「よいコミット・よいコードの実例」を紹介することを通じて他の人のコードを読むことを奨励していく、ノータブルコードというコーナーが始まりました。それに便乗する形で、「OSSへのよいフィードバックの実例」の紹介を通じて身近なところからのOSSへのフィードバックを奨励していく記事を掲載していきたいと思います。

1回目は、当社の堀本さんがOCamlというプログラミング言語に対して行ったフィードバックをご紹介します。

フィードバックの経緯

当初、OCamlのWindowsでのインストール手順は、必要なコマンドを以下の順で実行するよう書かれていました。

opam init
eval `opam env`
opam switch create 4.06.1
eval `opam env`
which ocaml
ocaml --version

この最後のocaml --versionは、実行結果としてocamlコマンドのバージョン番号が表示されることをもって、OCamlのインストールに成功したことを確認するためのものです。

しかしながら実際には、これを実行すると「--versionは未知のオプションである」というエラーが表示されます。実は、正しいオプションは-version(ハイフンが1つ)で、インストール手順の記述が誤っていたわけです。

堀本さんはこれを受けて、誤記を訂正するプルリクエストとして以下のようなフィードバックを行いました

■タイトル

install: fix a typo
≪インストール:誤記の修正≫

■本文

Dear developers.
≪開発者の皆さん、こんにちは。≫

In my environment, --version is unknown option.
≪私の環境では、--versionは未知のオプションと表示されます。≫
Probably, -version is valid option for ocaml command.
≪おそらく、-versionがocamlコマンドの正しいオプションです。≫

ほとんどの人は気にしないで使っていたのだと思われますが、いきなりエラーに見舞われると、初学者ほど戸惑うものです。

このプルリクエストは無事にマージされ、現在はそのようなつまずきは起こらなくなっています。

注目したい点

ここで注目して欲しいのは、フィードバックの結果、ソフトウェアを使い始める際に特別な注意が必要ない状態になったということです。

ブログなどでソフトウェアを紹介するとき、「このソフトウェアを使う時はこのような点に注意が必要です」といったノウハウを添えて紹介する記事はよくあります。ですが、冷静に考えてみれば、ソフトウェアを使い始めた人が高確率で戸惑うであろう注意点は、注意するべき点と言うよりも不具合不備と言った方が適切です。

ノウハウの言語化・文書化は有意義ですが、OSSに関わりたいと考えている人は、ぜひそこから一歩先に考えを進めてみてください。 「使う時に特別な注意が必要ないのが一番いい」、これはどんな場合にも言える事です 。この考えを持っていれば、「些細な戸惑い」や「使用上の注意点」はおのずと「改善した方がよい点」に見えてくるでしょう。

まとめ

ノータブルフィードバックの1回目として、OCamlのインストール手順に対して行われたフィードバックをご紹介しました。

ここで紹介したような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる! はじめてのOSSフィードバックガイド ~ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと~」をリリースします。本記事の内容は、この本からの抜粋となっています。
(表紙)

「これでできる! はじめてのOSSフィードバックガイド」は、今週末開催されるはずだった技術書典8というイベントで同人誌として頒布する予定……でしたが、技術書典8の中止により機会が流れてしまいました。

しかし執筆自体は完了しているため、ひとまず本来の開催予定日だった2月29日より、EPUB/PDF形式の電子書籍のダウンロード販売を開始したいと思います。販売チャンネルは、現時点では結城が個人的に運営しているBOOTHを予定しています。紙媒体版についても、同人誌書店での委託・通販や、今後「技術書同人誌博覧会」や、クリアコード関係者が参加する技術イベントなどに持ち込ませて頂いて、細々と頒布していければと考えていますので、お手元に置いておきたいという方はご期待下さい。

2020-02-25

フリーソフトウェアの法人向けサポートの一環で行った開発元へのフィードバックの事例紹介

当社の法人向けサポートサービスでは、企業のお客様がフリーソフトウェアを使われていて遭遇されたトラブルの解決や原因究明、文書化されていない技術情報の調査などを有償にて行っています。「特殊な労働力を提供してお客様の役に立ち、その対価としてお金を頂く」ということで、ビジネスモデルとしてはシンプルです。

ところで、当社の理念は「自由と稼ぐの両立」です。前述のビジネスモデルから「稼ぐ」は容易に読み取れますが、これがどのように「自由」に繋がっているかは見えにくいかもしれません。

まず単純に、「ユーザーが増える事が自由なソフトウェアの推進になる」という事が言えます。それは「そのソフトウェアを使うと開発チームに広告収入が入る」といった直接的な還元に限りません。例えば、そのソフトウェアのユーザーが増えると、業界内でのそのソフトウェアの影響力が増すので、プロプライエタリな製品にとってはそのデータ形式やプロトコルを無視しにくくなり、ユーザーが特定の製品に囲い込まれるリスクが低減する、という効果が期待できるでしょう。

また、こちらがこの記事の本題なのですが、このビジネスの中で実際の使用環境で見つかった不具合を報告したり、実際の使用環境でのニーズを汲み取った提案をしたりという形で、そのソフトウェアの改善に寄与できます

ということで、以下、Mozilla製品の法人向けサポート由来のフィードバックの事例を4つご紹介します。

Bug 1540943 - Broken message body on forwarding a mail including invalid character(Mozilla Thunderbird)

これは、メールの本文にエンコーディング上不正な文字が含まれていると転送メールの本文が文字化けしてしまうという問題です。法人利用では様々なメールが頻繁に・大量にやり取りされるため、このような「普通は起こらないエッジケース」が起こる事があり、また、それがビジネス上の支障になってしまう場合もあります。この現象に遭遇されたお客さまの場合、取引先からのメールを転送しようとすると文字化けしてしまうという事でお困りでした。

原因と回避策を調査した結果、本文として転送する場合には発生を避けられない問題である事が分かったため、お客さまには「添付として転送」などの別の操作を使って回避して頂く事をお薦めし、開発元には上記のBugの通り、その時点で判明していた発生条件などの情報を報告しました。

その後、開発者の方の目に留めて頂き調査が進んで、最終的にはソースコード中の1行をピンポイントで修正(呼び出す関数を変更)して問題を解消するパッチが投入されました。変更点が少なかった事から、この修正はThunderbird 60のメンテナンスリリースにも反映される結果となっています。

Bug 1563665 - Replied mails are not marked as "replied" if the folder has a comma (,) in its substance file name(Mozilla Thunderbird)

これは、メールフォルダに対応するローカルディスク上のファイルの名前に , (半角コンマ)が含まれているとそのフォルダ内のメールに返信などの操作をしても「返信済み」のようなマークが付かないという問題です。Thunderbirdではメールフォルダ1つがディスク上の1ファイルとなるmbox形式が初期設定となっており、ファイル名はフォルダ名そのままではなくMUTF-7という特殊なエンコーディング方式で英数字に変換されているのですが、台北 のような特定の文字列で変換結果が &U,BTFw- となり , が含まれる事になって、全く予想もしていなかった所でこの不具合に遭遇してしまう場合があるという状況でした。

お客さまには、MUTF-7でのエンコーディング結果に , が含まれないようにフォルダ名を工夫するという回避策をご案内していますが、どんな文字列がエンコーディング後にこのパターンになるのかについては事前の予想が難しいため、残念ながら万全とは言えない回答となってしまいました。

この問題は原因そのものは判明したものの、古くからある設計上の判断に起因する問題ということで、どのような方向で対処するのが妥当かという技術的判断の落とし所が見つかるまで、修正にはまだしばらく時間がかかりそうです。

Bug 1569089 - The "-version" ("-v") command line option doesn't report version information when using cmd.exe(Mozilla Firefox)

これは、Firefoxの起動オプションの一部が特定の状況下で動作しなくなっているという問題です。Firefoxは実は firefox.exe -v という風に -v オプションを指定して起動すると一般的なコマンドと同様にバージョン情報を文字列として出力するようになっており、これを使って現在インストール済みのFirefoxのバージョンを確認するという運用を取られているお客さまがいらっしゃったのですが、FirefoxをESR68に更新するとバージョン情報が出力されなくなったために運用に支障が生じている、という事でお問い合わせを頂きました。

調査の結果、Bugに記載しているとおりこの問題そのものは回避が不可能という事が分かったため、Firefoxのバージョンを調べるには何かしら別の方法*1を使わなくてはならない旨をお客さまにはお伝えしました。

-v はあまり使われる事の無さそうなオプションで、我々も正直な所、今回の調査を行うまでオプションの存在自体を把握していませんでした。しかし、報告したBugは優先度P2 (クリティカルな問題に対して付けられる P1 の次に高い優先度)と設定されています。本稿執筆時点では未解決ですが、もしかしたら案外早く修正される事になるかもしれません。

Add managed storage support (Duplicate Tabs Closer)

こちらはFirefox本体ではなくアドオンへの改善提案です。「Duplicate Tabs Closer」は同じURLのタブを重複して開く事を制限するアドオンで、重複の検出基準や検出時の挙動について様々な設定ができるようになっています。しかしながら、それらの設定値はローカルストレージ領域を使って保存されており、システム管理者の側では設定を制御できません。ですので、法人利用であらかじめ動作を決めておきたい場合、アドオンのソースコードを編集して組み込みの初期設定を変更する必要があります。

お問い合わせを頂いたお客さまの導入環境向けにそのように改造する事自体は容易ですが、提供開始後にアドオンが更新されたらそれへの追従の必要が生じます。また、その後同様のニーズをお持ちのお客さまから相談を頂く度に改造版を作る必要もあります。

その一方、Firefoxのアドオン向けAPIにはManaged Storageという機能があり、専用のファイルもしくはポリシー設定用の policies.json に書いた設定をアドオン側で読み取る事ができます。もしDuplicate Tabs CloserがManaged Storageに対応していれば、アドオンのソースコードを毎回編集する必要はありません。

以上の事を踏まえて、Managed Storageから設定値を読み込んで反映するという動作を追加する変更を提案した物が、上記のプルリクエストです。こちらは作者の方のご理解を得る事ができ、無事にマージして頂けました。

法人向けサポートからアップストリームへフィードバックする事の意義

アップストリームへのフィードバックは開発の現場に直接関わる事に等しいため、的確なフィードバックには様々な知識が必要になってきます。FirefoxやThunderbirdのように「ソフトウェア開発者でないエンドユーザーも使う物」ではこの点がネックとなりがちなためか、ユーザー自身によってなされた報告にはどうしても、不正確な報告や発生条件の絞り込みが不足した報告が散見されます。また、多くの日本人にとっては英語自体がハードルとなって余計にフィードバックしにくいという問題もあります。当社が法人サポートの中で行っているフィードバックは、これらの点を補ってフリーソフトウェアを推進していく物と言えます。

ビジネス的観点においても、アップストリームへのフィードバックには意義があります。問題点をそのプロダクトの開発元にフィードバックしないで手元での回避だけを行っていると、プロダクトの更新や変更でその回避策が取れなくなる恐れがあり、将来的なリスク要因になります。早め早めにフィードバックしてプロダクト本体側で問題を解決する事によって、その種のリスクが低減され、より安定して運用できるようになる事が期待できます*2。安物買いの銭失いにならなければ、それはサービスの付加価値と言えます。

そうしてプロダクト自体の品質が高まって企業で採用しやすくなると、法人向けサポートの需要の拡大にも期待できます。また、当社内でフィードバック対象のプロダクトへの理解が深まり知見が増えれば、それだけサービスの品質が向上します。

開発プロジェクトにとっても、ユーザーとなるお客さまにとっても、サポートを提供する当社にとっても利益になるという事で、これは「自由と稼ぐの両立」という理念の1つの実践例となっているわけです。

まとめ

以上、当社が法人向けサポートサービスを通じて行ったフィードバックの例を挙げて、会社の理念をどのように実践しているかをご紹介しました。

当社の法人向けサポート事業はいわゆるSI業界の周辺にあり、直接の取引先やその先のお客さまには「お堅い」業界の会社さまも多くあります。そのような業界はオープンさ・自由さと縁遠いという印象を持つ方が多いかもしれませんが、実際にはその内側ではフリーソフトウェアが使われていることは珍しくありません。やり方次第ではその領域のビジネスと自由なソフトウェアの推進を同時に行えるという事例の1つとして、参考にして頂ければ幸いです。

また、業務上でのフリーソフトウェアの使用においてトラブルに遭遇されていて、フリーソフトウェア製品やプロジェクト側の知識の不足でお困りの企業の担当者さまがいらっしゃいましたら、お問い合わせフォームよりお問い合わせ下さい。

*1 Windowsのレジストリの情報を参照する方法が一般的です。

*2 理論上、そうして問題が解消されていった先には全く仕事が無くなるという未来がいずれ訪れる事になりますが、実際にはプロダクトもユーザー側の要件も変化し続けるため、そのような未来がすぐに訪れるという事は、幸か不幸かまだ無さそうです。

2019-09-09

OSSへフィードバックしてみたいけど、英語でどう書けばいいのか分からない

結城です。

ここまで、OSSへのフィードバックをやってみようとした時に躓きがちなポイントについて、フィードバックするトピックの見つけ方報告に盛り込むとよい内容その情報の送り届け先の選び方の知見をそれぞれ述べてきました。

ところで、それらの技術的な内容以前のハードルとして、言語の壁という物もあります。実際にOSS Gateワークショップでも、フィードバック内容をまとめた後、英語でそれを書き直すという段階で手こずっておられる方がかなり多い印象があります。

ITエンジニア向けに「こういう英語表現を覚えよう」という情報を紹介する記事は時々見かけます。ですが、ワークショップでビギナー参加者の方が英語を書くのに苦労している様子を実際に見ている印象では、必要なのはそういった記事で紹介される「実際の現場でよく使われる単語や熟語の情報」ではなく、「実際の現場で英文を書く時に行われる考え方の解説」の方であるように筆者には感じられました。

そこで今度は、OSSへのフィードバックを英語でやる時の考え方に焦点を当てて解説してみます。対象読者は、英語に苦手意識のある方、中学高校の英語の授業で英作文はした事があるけれども自分でゼロから何かを説明する英文を書いた事はない方、といったレベル感を想定しています。

「日本語の文章を英語に変換する」のではなく、「同じ事を説明する英語の文章を作る」という考え方をしよう

英作文に不慣れな人は、まず「日本語の文章」を考えて、それを「対応する内容の英語の文章」に変換するものだ、と考えがちなのではないでしょうか。

いきなり言ってしまうのですが、それは無理なので、潔く諦めてしまいましょう

例えば有名な話ですが、外出先から帰宅した人が在宅していた人に言う「ただいま」や、それに応えての「おかえりなさい」は、英語に翻訳しようがないと言われています。そもそも欧米には「帰宅した時に挨拶を交わす」文化が無いため、そういう言葉どころか概念が無いのだそうです。この例を一つとってみても、「日本語で書いた文章をきっちり英語に変換しきる」という事は根本的には不可能だという事が分かるのではないでしょうか。

ではどうするのかといえば、「伝えたい内容、対象」そのものの方に立ち返って、それを表現する英語の文章を考える、という事になります。

例えば、ここに1本のペンがあるとします。その状態を英語で表すには、どんな文章が考えられるでしょうか?

  • This is a pen.(これは一体何であるか?という点に着目)
  • There is a pen.(どこにあるか?という点に着目)
  • I have a pen. / This is my pen.(誰の物か?という点に着目)

「これはペンです」という日本語の文章を先に与えられていれば、「This is~」という文しか思いつかないかもしれません。しかし事実の方に焦点を当てると、色々な角度から表現できるという事が分かるのではないでしょうか。

「すでに書いてしまった日本語の文章」に囚われないで、「目の前にある物」や「目の前で起こっている事実」の方を意識するという事を、常に心がけるようにしてみて下さい。まずはそれが最初のステップです。

平易に言い換えてみよう

この事を考える上で参考になる物として、「やさしい日本語」(※リンク先はPDF)があります。

やさしい日本語とは、

  • 海外からの旅行者がよく訪れる観光施設や、移民者が手続きに来る市区町村の役所などにおいて、日本語が不得手な人が読む事を想定して
  • 複雑な表現や難しい単語をなるべく使わずに、平易な単語や単純な文の書き方を心がけて

書かれた日本語の文章の事を言います。日本語ネイティブスピーカーではない人だけでなく、子供や高齢者、障害者など幅広い層にとってもメリットがあるという事で、近年注目されてきているそうです。

「やさしい日本語」を書くためには、同じ物事をより平易な表現で言い換える必要があります。例えば、

訪日観光客で洛中・洛外は連日溢れかえっており、史跡や寺社仏閣が観光資源として有効に機能していて、誇らしい。

という文章は、

  • 多少ニュアンスは変わったとしても各単語を平易な表現に言い換える。
    • 訪日観光客→他の国から来た人達
    • 洛中・洛外→京都の町
    • 連日溢れかえり→毎日たくさんいる
    • 史跡や寺社仏閣→古い建物、お寺、神社など
    • 観光資源として機能→見どころになる
  • 接続された文を短い文に切り分ける。
  • リズム感や格好良さを優先していたトリッキーな語順を整理する。
  • 省略された主語(行為の主体)を補う。

といった加工をする事で、

京都の町には毎日、たくさんの人達が他の国から来る。
古い建物、お寺、神社などが見どころになっている。
私はとてもうれしい。

のように言い換えられるでしょう。

英語が不得意な人は、英語の文法にも単語力にも自信が無い事が多いと思います。しかしその一方で、日本語はそれなりに使えるという自信が(無意識にでも)あるはずです。そのため、自分の持てる限りの日本語力を駆使して考えた日本語の文章には、難しい単語や言い回しが無意識のうちに入ってしまいがちです。日本語力と英語力の間にギャップがあるために、日本語の方で選んだ単語や表現に対応する英語の言い方が分からなくて、手が止まってしまう……これこそが「英語になると途端になにも書けなくなる」事の正体です。

なので、日本語の文章を英語に訳せる自信が無い場合、その前段階のワンクッションとして、まずは自分が書いた文章を「やさしい日本語」に書き直すようにしてみて下さい。そうすればきっと、次のステップにもスムーズに進めるようになるでしょう。

「SVOの平叙文」で考えよう

英語の話に戻ります。

中学高校までの英語の授業では様々な文法や単語を教わりますが、こと「OSSへのフィードバック」という場面で言うと、実際に使う知識はその中のごく一部です。特に文章の形は、基本的にS(subject:主語)-V(verb:動詞)-O(object:目的語)の形式で書くと考えていいです。これは「私は○○をした」「あなたは××である」のような単純な文章、いわゆる平叙文という形式です。

日本人が英文を書くと受動態(受け身の形、主語が何々されるという文)が多くなりがちだ、とよく言われます。それは、こなれた日本語の表現では主語が省略されがちで、主語が省略された文章をそのまま直訳すると、必然として受動態にせざるを得ないからです。

ですが、「誰が」何をしたのか、「誰が」どうなったのか、という事を省略しないようにすれば、文章は自然とSVOの文型になります

「誰が」を書いたら主語が「I(私は)」「You(あなたは)」ばかりになってしまう? それは、「主語は人間だ」という無意識の思い込みがあるからです。英語では、物でも現象でも概念でも普通に主語になります。主語をどう書くかに迷ったら、一旦あらゆる物事を擬人化してみて下さい

例えば、

Firefoxの法人向けポリシー設定で、検索候補の表示を無効化するSearchSuggestEnabledfalseに設定しても、単独のWeb検索バーでは検索候補が表示され続けてしまう。

という不具合を報告したいとします*1。これはどう言い換えられるでしょうか。

日本語での省略された主語は「私が(~を設定した)」ですね。しかし、ここには「Firefox」や「SearchSuggestEnabledという設定項目」、「その設定の値がfalseである状態」、「単独のWeb検索バーというUI部品」「検索候補」といった登場人物達がいます。ということでこれらを主語にしてみると、例えば以下のような表現ができます。

  • 「設定の値がfalseである状態」を擬人化して主語にする:

    SearchSuggestEnabled=false does not hide search suggestions on the search bar.
    SearchSuggestEnabled=falseという状態が、検索バーの検索候補を隠してくれない)

  • 「検索候補」を擬人化して主語にする:

    Search suggestions on the search bar are visible with SearchSuggestEnabled=false.
    SearchSuggestEnabled=falseという設定の時に、検索バーで検索候補が見える)

どうでしょう。このくらいの英文なら、自分にも書けるような気がしてきませんか? これに

  • There is an enterprise policy SearchSuggestEnabled.
    (~という法人向けポリシー設定があります。)

  • The location bar shows search suggestions. The web search bar also.
    (ロケーションバーは検索候補を表示します。Web検索バーも同様。)

などの文を添えれば、上述の例で報告したかった内容は言い表せたと言っていいでしょう。

いかがでしょうか。長く複雑な構造の文章で表されていた内容であっても、一文一文を細かくぶつ切りにして、それぞれに主語を与えてSVOの形で書き直してみれば、こんな要領の平易な英語の文章で表現できるのです。

ソフトウェア開発の場面であれば、「モジュール名」「メソッド名」「変数名」「ソースコード中の行番号で示した行」などなど、他にも色々な物が「登場人物」になり得ます。皆さんも、名前が付いている物は片っ端から主語にしてみて下さい。

ありふれた動詞や形容詞を使おう

文章をぶつ切りにしてSVOの文型に揃える事には、同時に、使う動詞や形容詞を辞書から見つけやすくなるという効果もあります。というのも、和英辞書で動詞や形容詞を調べると例文は大抵「誰々が何々をする」のようなSVOの文の形になっているからです。辞書で見つけた例文をそのまま使える、これは大きな利点です。

また、先の例で使った動詞が

  • show(表示する)
  • hide(隠す)
  • are visible(~が見える状態である)

という、教科書に出てきたりプログラムやCSSの中で見かけたりするような、特に難しくない・ありふれた単語だったという点に気が付いたでしょうか? 「やさしい日本語」において、難しい単語を使わず平易な単語を使うように言い換える、多少の細かいニュアンスをそぎ落としてでも端的に意味が通じる言葉を選ぶという事を説明しましたが、英語でも同じ事が言えます。言いたい事に厳密に当てはまる難しい英単語は、おおむね意味合いが通じる平易な単語で代用できるのです。平易な動詞や形容詞でも、主語を変えると意外と広い意味で使える、というのもSVOの文型を使う事の利点です。

筆者はこういう場面で使われやすい英単語をもう少し知っているので、実際にはこのような場面では状況に応じて

  • appear(出現する、表れる)
  • append / add(追加する)
  • disappear(消える)
  • deactivate / disable(無効化する)

のような単語を使うと思います。ですが、こういった単語を知らなくても、先の平易な単語でも言いたいことは通じます。より厳密な単語を覚えていくのは追々で問題ありません。他の人が書いている文章で「この単語、なんていう意味だろう?」と思ったらその場で調べて、自分が似たような場面に遭遇したら次から使ってみる、そんな感じで少しずつ語彙は増えていくので安心して下さい。

とはいえ、ソフトウェア開発の場面で特有の頻出単語という物は確かにあります。例えば以下のようなまとめの記事もありますので、暗記が得意なら、頻出単語をあらかじめ頭に入れておいてもいいでしょう。

困った時は箇条書きにしよう、文章以外の表現手段も使おう

報告に盛り込むべき内容の話において、不具合や要望を伝える時は

  • steps to reproduce(再現手順)
  • expected result(期待される結果)
  • actual result(実際の結果)

を軸にすると上手く言いたい事を整理できる、という事を述べました。実際に報告を書く段階においては、このそれぞれを前述のようなぶつ切りのSVOの文型で書いていけばよいという事になります。

しかし、そうすると今度は文同士の繋がりをどうするかで悩む事になりがちです。確かに、ぶつ切りの文章は少々不格好なのは否めません。せめて順接*2か逆接*3かくらいは示しておきたい……いやそれだけじゃなくて因果関係も示したい……という風に考え始めて、またしても「日本語での表現の仕方は分かるが、英語での表現の仕方が分からないので、手が止まる」というドツボにはまり込んでしまうのは、よくある事です。

筆者は、そこで悩むくらいなら箇条書きで書いてしまう事をお勧めします。例えば対等な物を並べるなら、この項の冒頭のように序列無しの箇条書きにすればいいですし、順番や優先順位に意味がある場面では、項目の頭に数字を付けた序列付きの箇条書きにすればいいです。例えば「再現手順」は以下の要領で書けるでしょう。

  1. ◯◯をする。
  2. ××をする。
  3. △△が◇◇になる。

これなら、受け取り手が順番を読み違える事は無いですし、「Repeat steps from 1 to 4.(1から4を繰り返す)」のように手順そのものを指し示す抽象的な書き方も容易にできます。また、箇条書きを階層化すると、

  1. ◯◯をする。
    • ◎◎が出る。
  2. ××をする。
    • ◎◎が消える。
  3. △△が◇◇になるかどうか。
    • ◇◇になっていたら、4に進む。
    • ◇◇になっていなかったら、1に戻る。

というように、各項目に付随する補助的な情報だったり、条件ごとに変わる操作だったりと、各項目の因果関係や依存関係を含んだ複雑な情報もスッキリ表せます。

あるいは、ここまでやるならむしろフローチャートの図で情報を示してもいいかもしれません。そう、説明する方法は「英語の文章」でなくてもいいのです。スクリーンショットで示した方が早ければスクリーンショットに丸や矢印を描き込んだ物を添付してもいいですし、静止画では説明が難しければスクリーンキャストをYouTubeあたりにアップロードして伝えてもいいです。あるいは、プログラムやデータを実際に作れるのであれば、それを使って実行すれば必ず現象が再現するというテストケースを添付するのが一番いいです。

思い出してみて下さい。皆さんがしたい事は、「英語の文章を書く事」ではなかったはずです。本当にしたい事は「不具合を伝える事」や「要望を伝える事」の方ですよね。その手段として日本語が通じないから、別の手段として英語で説明しようとしてるだけです。「英語という手段で説明する事」自体に囚われてしまうと、本来の目的を見失ってしまいがちです。そんな時は画面から目を離して、落ち着いて深呼吸しましょう。そうすると、別のやり方を思いつけるかもしれません。とにかく自分に今使えるあらゆる手段を柔軟に使い分けて、どんな形ででも伝えたい事を伝える事が一番大切です。

もっと言うと、「OSSプロジェクトのイシュートラッカー」は美しい英文を披露する発表の場ではありません。OSSを公開して実際に障害報告を受ける側になっている筆者の実感としては、ぶっちゃけ、流暢な英語で芸術的に見事な文章をたらたらと書かれても、英語が不得手な筆者はかえって読むのに苦労するばかりで、全然嬉しくないです。それだったら箇条書きで書いてくれた方が、ずっと読みやすく・分かりやすくて助かります。

そう、これも忘れてしまいがちなのですが、OSSプロジェクトで既に英語で文章を書いている人だって必ずしも英語が得意とは限らないのです。OSSの開発者には中国人もいれば韓国人もいるし、ロシア人やインド人もいます。皆さんもどうかその事を心に留め置いて、「英語」にばかり固執しないようにして貰えると筆者は嬉しいです。

自信が無ければ英和翻訳にかけてみよう

話題がまた少し逸れました、英語の話に戻りましょう。

前述したような考え方に則って英語の文章を書いてみたけれど、ちゃんと書けているのか、本当に通じるのか、自信が無い……そんな時は、書いてみた英文を「英語→日本語」の機械翻訳にかけてみる事をお勧めします。

機械翻訳は、「日本語に熟達した人が書いたこなれた日本語の文章を、そのニュアンスを捉えた上で、こなれた英文に翻訳する」というような高度な翻訳は(まだ)こなせませんが、「平易な英文を、平易な日本語の文章に翻訳する」のには充分すぎるくらいに使えます。英和翻訳した結果の日本語の文章を読んでみて、言いたかった事がちゃんと言い表されていると思える結果になっているなら、その英文は人前に出して全然大丈夫です。

筆者も実際に、書いてみた英文の正しさに自信が無い時はGoogle翻訳で英和翻訳してみています。その結果を見ながら、単語の意味や前置詞の使い方を間違えている事に気が付いて手直しするという事も多々あります。

平易な文章の英和翻訳が実用になるなら、平易な文章の和英翻訳の結果も使えるのでは? と思うかもしれませんが、筆者はそれは以下の3つの理由からお勧めしません。

  • 前述しましたが、日本語に熟達した人が日本語で文章を書くと、どんなに気をつけていても、無意識のうちに主語や目的語の省略などを行ってしまいがちです。機械翻訳ではそのような「文章の中には含まれていない外部の情報」を推測する事が難しいために、誤訳が発生しやすいです。
  • 和英翻訳された後の英文が自分自身の英語力を大きく超える物だった場合、その意味を自分で読み取る事すらできず、翻訳結果が正しいかどうかを自分では判断できないという事が起こります。
  • サービス・ツールによっては、機械翻訳の結果の文章の使い道を利用規約で制限している場合があります。例えば、OSSは商用利用を禁止しませんが、翻訳結果の商用利用を禁止しているサービスで翻訳したテキストをOSSに含めてしまうと、利用規約に違反してしまいます。実際に、Web翻訳の結果をOSSに不用意に入れた人がいたために、その人が過去関わった全ての翻訳済みリソースについて権利面での妥当性を再確認せざるを得なくなったという事例があります。

近年、機械学習の発展のお陰か、みらい翻訳のように「こなれた日本語を入力しても、それなりにこなれた英語の文章に翻訳できる」*4翻訳サービスが登場してきています。しかし、どれだけ翻訳精度が向上しても上に挙げた2つ目や3つ目の懸念点は解消されません。機械翻訳の結果はあくまで、最終的にOSSに含めるテキストや投稿する文章そのものではなく、それらを考えるための判断材料として使うに留める事を、筆者は強くお勧めします。

まとめ

以上、OSSへのフィードバックで避けて通れない「英語で文章を書く」という事について、テクニックよりは原理原則に焦点を当てて知見を紹介してみました。

実は、ここに書いたようなことは海外旅行などでも使える一般的な考え方です。実際に、悪魔英語 喋れる人だけが知っている禁断の法則という漫画にもおおむね似たような事が書かれていました。「学校である程度の英語教育を受けたにも関わらず、自分からは英語を話せない・書けない」という人にとっての処方箋は、だいたい似たような感じの所に落ち着くのかもしれません。

ここで述べた事を実践して書かれる英語は、はっきり言えば「たどたどしくてつたなくて不格好な、ヘタクソな英語」です。でも、それでいいんです。ネイティブスピーカーとリアルタイムで舌戦を繰り広げるとか、格式高い場でスピーチをするとか、そういう場面でもない限りは 「だいたい通じる下手な英語」で大抵は間に合います

確かに、海外に移住して「生活」するとか、「相手に隙があれば目ざとくそれを突いて、とにかく自分の利益を最大化しよう、という考え方をしている相手」との交渉といった場面になってくると、英語が下手だと相手からナメられたり足下を見られたりといった不利益を被る事もあるようです。ですがOSS開発の場では、筆者が知る限りは別にそんな事はありません。むしろ、インド人や中国人など英語ネイティブでない人が、めちゃくちゃな英語で普通にコミュニケーションしているという場面の方をよく目にします。世界中で見れば「英語のネイティブスピーカー」より「外国語として英語を使う非ネイティブスピーカー」の方が多いわけで、そういう意味では我々の方が多数派なのです。特別に自分が劣っているというわけではないので、安心して下さい*5

このあたりの事について、英語話者の視点から書かれた「酷い英語をもっとお願いします」という記事(※リンク先はその日本語訳)があります。英語話者の人にとっても、英語が壁となって有用な意見やフィードバックを得られない事は損失なので、英語の上手い下手なんて気にしないでガンガン伝えて欲しい、という感覚があるのです*6。ですから皆さん、どうか物怖じしないで英語での報告に挑戦してみて下さい。

*1 これは前の記事でも紹介した、実際に報告を行った事例です。実際の報告内容も併せて参照してみて下さい。

*2 後に続く文章が前の文章にそのまま続く事を示す接続。日本語なら「そして」「さらに」など、英語なら「and」「then」などがあたります。

*3 後に続く文章が前の文章を否定する接続。日本語なら「しかし」「なのに」、英語なら「but」「however」などがあたります。

*4 英語が得意で留学経験もあるような人が見ても、「なるほど確かにこう書けるな」と思えるレベルの翻訳結果が得られているようです。

*5 かといって、上達しようという意識を全く持たなくてもよいという訳でもありません。自分の言いたい事を適切に表現できる英語力があった方が、説明や説得をよりスムーズに進められる事は間違いありませんから。

*6 この対極の話として、努力で英語を身に付けられた人が「みんな英語にすればいいじゃん」とローカル言語への翻訳を否定する発言をした事例がありましたが、その事例ではプロジェクト運営者サイドからも改めて、英語だけが全てではないという事が述べられていました

2019-07-12

タグ:
年・日ごとに見る
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|