「どのソフトウェアにフィードバックするか」がはっきりしたら、次にはっきりさせるのは*「何をフィードバックするか」*です。
OSS Gateワークショップにビギナーとして参加される方は、OSSに関わりたい意欲はあるものの、具体的に「これをフィードバックしたい」というネタはお持ちでないことが多いです。本書の読者の中にも、同様の方は少なくないでしょう。
そこで本章では、「フィードバックするネタ1」の見つけ方をご紹介します。これを読めば、あなたも明日からOSSへフィードバックするネタに事欠かなくなるはずです。
フィードバックできるネタの探し方といっても、べつにゲーム開発におけるデバッガー部隊のように「普通はやらない操作をとにかくいろんな組み合わせでたくさん試してみる」なんてことをする必要はありません。
するべきことはたった1つ、OSSを普通に使うということです。ワークショップでも、「まずは普通に使ってみる」ステップに半分くらいの時間をあてています。
ただし、そのときには使っている途中で遭遇した些細な「つまずき」を見落とさないことが大切です。
何が「つまずき」なのかピンと来ない、「普段からOSSを使っていて、つまずいたことなんて無いんだけど……」という人は、ちょっと立ち止まって考えてみてください。それはあなたが「自分がつまずいたということ」自体に気付いていないだけかもしれません。
「そんなバカな！」と思った方は、以下のような話に身に覚えはないでしょうか？
- 書かれているとおりの手順でインストールしたが、失敗した。ググったら2、◯◯というパッケージを先に入れておくよう解説しているブログ記事があった。
- どこから始めればいいか分からなかったので、「（機能の名前） 使い方」でググってQiitaやStack Overflowや個人のブログの解説を参照した。
- コマンドを実行したら、いきなりエラーになった。2回目はなぜか成功した。
- 機能を実行しても何もメッセージが出なくて、ちゃんと動いたかどうかよく分からなかった。ファイルのほうを見たら、実はちゃんと保存されていた。
どうでしょう。「いつものことで、特別つまずいたとは思っていなかった」「そんなことでいちいち止まってたら、仕事にならないし」と思う人もいるのではないでしょうか。
何かするたびにつまずけば、ストレスになります。また、よくつまずくのは自分の技術力が低いことの表れだと考えるなら、つまずきを意識するのは自分の無能さと向き合うということで、それもまた辛いものです。そもそも、そのOSSを使って本来やりたいことが別にあったわけで、それと無関係なことに時間を取られること自体煩わしいでしょう。
なので、誰もがつまずきを意識しないような鈍感力を身に着けてしまいがちです。ですが、OSSにフィードバックするにはこの鈍感力が邪魔になるのです。
本書を読まれている方の中には、すでに積極的に情報をアウトプットしている人もいるかもしれません。たとえば以下のようなやり方を取っている人は多いでしょう。
- 社内のWikiなどにメモを書いて、他のチームメンバーに情報を共有する。
- Qiitaや社外向けのブログに記事を書いて、広く一般に情報を公開する。
- 同様のノウハウを集めて編集し、技術書典のような場で同人誌として頒布する。
ところで、そこに書いたのはどんな情報でしょうか？ 普通に使おうとしてつまずいたことの注意点やノウハウを述べていたなら、フィードバックのチャンスかもしれません。
実際の事例として、筆者の同僚の堀本さんが、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に関わりたいと考えている人は、ぜひそこから一歩先に考えを進めてみてください。「使うときに特別な注意が必要ないのが一番いい」、これはどんな場合にも言えることです。
この考えを持っていれば、「些細な戸惑い」や「使用上の注意点」はおのずと「改善したほうがよい点」に見えてきます。
インストール時などの使い始めの時期に遭遇するつまずきは、「普通に使う過程で遭遇するつまずき」の代表で、OSS Gateワークショップでもよく見られます。
OSS Gateワークショップでは、ビギナー参加者の方には基本的に、公式の導入手順やチュートリアルに厳密に則ってOSSを導入してみて、そこでのつまずきをフィードバックする体験をしてもらっています。というのも、このやり方はつまずきに遭遇して何かをフィードバックできる可能性がそれなりにあり、しかも、結果的にそのOSSに関わる多くの人に喜んでもらえるからです。
謙虚な人は、つまずきに遭遇した時に「つまずいたのは自分が勉強不足だからだ、豊富な知識があれば事前に気がつけたはずだ」「こんな所でつまずくのは初心者だけに違いない、こんな所でつまずいたと人に知られるのは恥ずかしい」と考えるかもしれません。
確かに、技術力があれば、こういうつまずきも難なく乗り越えられるでしょう。ですが、つまずきに気がつけるかどうかは、それとは別の能力です。乗り越える力はまだなくても、つまずきに気付く力さえあれば、フィードバックはできます。
謙虚に学ぶ姿勢は大事ですが、ここは一旦謙虚さを忘れて、自分の気持ちに素直になって「どうだったら嬉しかったのか」を考えてみましょう。つまずいたのは「ソフトウェアに問題があるから」「説明が足りないから」ということはないでしょうか？
自分の知識不足を恥じる考え方は、一旦封印しましょう。むしろ、「こんな最初の部分につまずくような部分が残ってることのほうが悪い」と考えていいくらいです。そういう視点で「つまずき」を「どうだったらよかったか」と表現してみましょう。
たとえばこんな感じです。
- インストール手順の説明の中に必要な前提が書かれていなかったのでつまずいた。
- →必要なパッケージがあるなら、最初からそれも手順に書いておいたり、自動的にインストールするようになってくれていたりすればいいのに……
- コマンドを実行したら、初期設定をしてくださいと言われてエラーになった。
- →初期設定が必須なら、インストール手順の中に書いてあればいいのに……
- 機能を実行しても、ちゃんと動いたかどうかよく分からなかった。
- →動作確認の方法も書いてあればいいのに……
ほら、今までストレスでしかなかったものが、改善できそうな点に見えてきましたね。これを開発元に報告したり直したりしていくことが、OSSへのフィードバックなのです。
多くの小規模なOSS開発プロジェクトでは、インストール手順や使い方の説明などのドキュメントが未整備だったり不完全だったりしがちです。開発者自身などの熟練者にとっては明文化の必要が薄い上に、熟練者と使い始めの人では前提知識に差があり、熟練者が使い始めの人の気持ちになりきるのは難しいからです。
使い始めるのに色々な暗黙知が必要だと、「すでにわかっている人」以外にとってそのOSSはどんどん使いにくく・関わりにくくなってしまいます。そうすると、新規のユーザーや開発者が増えません。その一方で、それまで関わっていた人達はライフステージの変化などにより「卒業」していきます。そうして最終的には、新機能の追加も無ければ脆弱性の修正も無く誰にもメンテナンスされないままの、見捨てられたプロジェクトになってしまいます。それは、一般のユーザーにとっても望ましくない事態です。
だからこそ、新たに使い始めて実際につまずいた人からのフィードバック、特に、公式の導入手順へのフィードバックは大事なのです。短期的な問題の解消のみならず、プロジェクト自体の長期的な継続のためにもなりますので、非常に有意義と言えるでしょう。
ところで、「こんなことでつまずくのは自分くらいに違いない」と思ってしまうのとは全く逆のフィードバックの見落としパターンで、「こんなあからさまで目立つ不具合、きっと誰かが報告してるはずだ、待っていればそのうち直るはずだ」と思ってスルーしてしまうパターンもあります。いわゆる傍観者効果、「誰も！！！ 消防車を呼んでいないのである！！！」というやつです3。
不具合に遭遇したときに、それがあまりに単純だったり、インストール手順のような目立つところにあったりすると、「すでに報告されているのではないか」と心配して報告をためらってしまう、という事例は実際にワークショップの中でもよくあります。
そのような場合、筆者は「まず既存の報告がないか10分ほど調べてみて、見つからなければ自分が思う内容・表現のままで報告してしまってよい」と考えています。詳しくは第N章で改めて述べますが、仮に「同じ問題だが、報告の表現の仕方が違っていたために、その探し方では見つからなかった」ということであれば、あなたが行う報告は、同じ探し方をする人にとっての立派な誘導・道しるべとなるからです。
また、あなたにとってはあまりに明々白々なつまずきでも、開発者や他のユーザーにとってはそうではなかった、そもそも今まで他の人の環境では問題が起こっていなかった場合も十分にあり得ます。これは、開発者にしてもユーザーにしても、自分が普段から使っている環境のさまざまな前提をついつい「当然の、誰の環境でも共通する前提」と思ってしまいがちだからです。
そういった無駄な「お見合い」は、減らしていくに越したことはありません。皆さんにも、勇気を出してぜひフィードバックに挑戦して欲しいところです。
どんなソフトウェアであれ、使っているとつまずきは日々発生します。つまずいたままではどうにもならないので、ググったり試行錯誤したりしてつまずきを回避する、という日常を多くの人が送っていることでしょう。
そういうときに、その都度開発元にフィードバックできればベストなのですが、最初のうちは「よし、やるぞ！」と気合いを入れて臨まなければ「フィードバックするモード」に頭を切り替えられないかもしれません。スケジュールの都合などで、すぐにフィードバックするのは難しい場合も多々あると思います。
そんなときは、無理に一気にフィードバックしなくても構いません。ただ、つまずいたという事実に敏感に気付くようにして、つまずきを忘れないように記録を残しておくようにしてください。
そして、「毎週月曜日の17時から2時間」のようにタイミングを決めて、残したメモを元に実際にフィードバックしてみるようにし、「フィードバックする」こと自体を習慣化するといいでしょう。
そうして少しずつ機会を重ねていく中で「あれっ、フィードバックに30分もかからなかったぞ？」と気がつけばしめたものです。そうなればもう「定期的に」する必要はなく、つまづいた時に即フィードバックできるようになっているはずです。
「OSSへフィードバックするって、何か特別なことだ」「そんなことができるのは別の世界の人だ」と思っていましたか？ フィードバックは決して特別なことではなく、このように日常の延長線上にある物なのです。
皆さんも、OSSを使っていて遭遇した些細なつまずきをきっかけに、フィードバックに挑戦してみてください。
Footnotes
-
OSS Gateワークショップでは、これを「フィードバックポイント」と呼んでいます。 ↩
-
Googleで検索したということ。 ↩
-
のりつけ雅春「しあわせアフロ田中」4巻収録の1エピソードがなぜかインターネットミーム化したもの。詳しくは https://nlab.itmedia.co.jp/nl/articles/1902/18/news125.html に解説があります。 ↩