オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（中編）

2016年3月8日に都内で開催されたソフトウェアテストシンポジウム「JaSST'16 Tokyo」において、オープンソースソフトウェアの品質管理についてのパネルディスカッション「OSSにおける品質管理・テストと運営」が開催されました。

（本記事は前編、中編、後編の3本から構成されます。いまお読みの記事は中編です）

Twitter APIを叩くTwitter4Jのテストは手間が掛かる

和田氏　リリース周りの話の次は、テスト周りの話を聞いてみようと思います。みなさん、どんなテストを書いているかとか、こんなテストを書いておいてよかったとか、そういう話はありますか？

川口氏　テストについて言うと、Asakusa Frameworkは分散処理基盤、つまりHadoopやSparkに強く依存しているプロダクトなので、これらと組み合わせてやってみないと分からないというのがある一方で、ユーザーは複雑なバッチアプリケーションを書くので、環境に依存せずにいろんなデータパターンでテストを書かなくてはいけないという側面もあって、そこを両立させるところにいつも悩んでいます。

前者に関してはなかなか自動化しにくいというか、Hadoop環境を作ってテストするのはシンプルなデータなら簡単に用意できますけれど、複雑なデータや複雑なアプリケーションを用意するのは非常に難しくて、そこは手動で行うことも多いです。

一方、Asakusa Frameworkはヘビーユーザーが社内の案件だったりするので、お客さん向けに社内で作っているバッチアプリの開発中にいろんなフィードバックがもらえて、テストや品質管理のポイントになりそうなところは社内のフィードバックをもらってそこのテストを重点的に書くとか、そういうことはやりやすかったですね。

山本氏　Twitter4JはJavaなのでテストはJUnitで書いているのですが、必ずしも全部のパターンのテストを書いてはいません。テストケースは書けば書くほど費用対効果が落ちるので、全部のケースを通すような網羅性は重視していません。ただ、テストを書くことをサボっているとどんどんテストを書かなくなってしまうので、まずいなと思ったところからテストのカバレッジのメトリクスを取っています。

Jenkinsでテストを動かすときのカバレッジが分かるようにしていて、いまは60％から50％くらい。Twitter4Jとしてはカバレッジが50％だとちょっと抜けが目立ってくるかなと思っているので60％に近づけるようにしていて、それ以上だとちょっとパラメータが違う程度で効率が落ちるのでやってないですね。

それからTwitter APIを叩くというライブラリの性質上、いろんなテスト用のTwitterアカウントを使うんですね。新規に作ったけれどアイコンがないアカウントとか、いちどもツイートしていないアカウントとか、片方向のフォローとか双方向とか、鍵付きのアカウントとか、15個から20個のアカウントを作ります。

ただコントリビュータがこういうアカウントを10個も20個も作るのは大変なので、その辺はコントリビュートのハードルになるのかなあと。だいたいのコントリビュータがテストを書いてくれますが、テストを書くのが難しいのもあって、テストがないコードも受け付けるようにしています。

また、私の手もとにはTwitterのIDを自動生成するコードもありますが、道義的に考えると悪用されないようにそれをGitHubにあげるわけにもいかず、その辺はちょっと難しいところがあります。

テストのときはTwitter APIを叩かなくてはいけないのですが、アクティブに開発しているとすぐにAPI利用制限の上限に達してしまうので、ユーザーアカウントのセットを複数持って、上限に達したら切替えるみたいなこともしています。

それからTwitter APIは必ずしもレスポンスを返してくれるわけではありませんし、エラーが返ったり、10回に1回くらい変なレスポンスが返ってくるなんてこともあります。なので、必ずしも全部のテストケースが成功しないんですね。だからある程度見切ってリリースする必要もあります。

ところが見切って出したらAPIのバグじゃなくてこちらのバグだったりもします。

GitBucketはドキュメントもチャットも英語で

和田氏　Twitterでもらった質問にも答えていきましょうか。

（GitBucketを開発している）竹添さんに質問です。GitHubの機能にない機能の要望があったらどうしますか？ です。

竹添氏　そういう要望はあります。自分たちの業務フロー用にこういう機能がほしい、といった要望ですが、GitHubにないとか、GitHubの機能を追いかけるうえで障害になりそうなものは基本的にはリジェクトしています。また、GitBucketにはプラグインの機能があって、それで実現できそうなものはプラグインとして作ってくださいとお願いしています。

会場から　プルリクを投げるのを目的にしている人とか、技術的な課題を解決するのが好きなだけの人とか、そういう人からの要望をユーザーの代表からの要望として扱っていいのかどうか。

竹添氏　プロダクトが有名になってくるとコントリビューションが目的になる人が出てきて、使っていない人からプルリクが来ることもあるかと思いますが、GitBucketはまだそうなってはいなくて、ユーザーさんがほとんどですね。

GitBucketが特徴的なのは、GitBucketというのはアプリケーションなので、ライブラリやフレームワークなどと違ってユーザーさんが開発者じゃないことがあるんです。だからユーザーがフィードバックやコントリビュートできる人かというと必ずしもそうではなくて。

一般に、OSSではユーザーの5％がフィードバックしてくれるとも言われていますが、GitBucketはユーザー層の関係でたぶんもっと少ないんです。だからユーザーを増やさないとフィードバックしてくれる人も増えなくて、日本だけでは頭打ちになるので海外のユーザーも積極的に得たいと思っています。

そこでドキュメントは英語で書くとか、コミュニティのIssueやプルリクのやりとりも、チャットも英語でやりますとか。Issueの一覧に漢字があると、海外の人は読めなくて帰っちゃうので。

体感的に言うと、日本のユーザーの10倍くらいの人数が海外にいるので、例えば日本のユーザーにある程度の不便をおかけしても、海外のユーザーのフィードバックのほうが総量として無視できない状態なので、プロジェクトとしては英語を重視する形でやっています。

山本氏　Twitter4Jのコントリビュータは開発者ですね、Javaのライブラリなので。で、コントリビュータを増やすにはユーザーを増やさなくちゃ行けないのは同じで、ユーザーを増やすには、第一にやっぱり英語を重視していますね。

ソースコードのコメントもそうですし、ドキュメントも英語で書いたり。Webは日本語も用意していますが。中国語に翻訳したい、というコントリビュータもいたりしますね。韓国語はプルリクをもらって、マージしたので韓国語のWebサイトもあります。

あとはプロモーションですね。使いたい人が発見してもらえるようなググラビリティ（検索しやすさ）。JavaとTwitterで検索をしたら一番上に出るようにすると、そこに主眼を置いて「Twitter4J」という名前にしましたし。そういうストレートな名前はあんまり好きではないのですが。

それからテック系のニュースサイト、Java関連がよく載っているサイトだったりに、新バージョンが出たらリリースを送ったり。できるだけ英語圏の人の目につくようにもしていました。

川口氏　Asakusa Frameworkはユーザーの開発現場がオフラインだということがかなり高い確率であって、気軽にインターネットを見たりGitHubが見られないことも多いんですね。Asakusa Framework自体への質問にも、これをオフラインで使うにはどうすればいいですか、というものが多くて。

そういう中でオープンな形でコントリビュートしてもらうのは、けっこう難しいなあというのがありますね。

和田氏　power-assertは基本的には竹添さんや山本さんと一緒で、メインのコミュニケーションチャンネルは英語でやる。ドキュメントも英語で書く。サポートも英語でやる。Issueやプルリクも英語でやると。

英語でないと十分なフィードバックの数に達しない

なんでかというと、ひとつは竹添さんが言ってたように、実際にフィードバックしてくれる人の割合が5％だといわれているように一定だとすると、こういう環境で動かなかったので直しましたとか、ここが動きませんでしたといったフィードバックによる品質向上は、分母に依存するんですね。

つまりプロダクトの品質を自分が頑張りすぎないで、ユーザーと一緒に高めていくための取り組みとして、僕らは英語で出ていかないと十分なフィードバックの数に達しない。日本語だけでは達しないわけです。

なんで英語を頑張るかというと、ひとつは僕らの品質保証プロセスの側面があって、英語の方が品質が保ちやすいから、コントリビュートしてくれる人が多いからです。OSSの評価で考えると、日本語だけだと品質が大丈夫か、目は足りているか、というのを気にしたりします。

なので日本のユーザーには面倒をかけるところがありますが、英語にこだわるのはこうした台所事情があるんですね。

例えば、僕が使ってないOSとか僕が使ってないOSの言語設定とかで発生するバグは僕が気付きようがないので、いろんなところで使ってもらって報告してもらうしかありません。そのためにユーザーの分母を広げなくてはいけませんし、宣伝をしてたくさんのユーザーに使ってもらうことが一番の品質保証なんですね。

そういうところは、これまでのソフトウェアの品質保証のアプローチとはちょっと違うんです。そうして伸びてきたのがLinuxだったりします。

なんで日本のOSSなのに英語なの？ ってよく聞かれるのですが、こんな事情があるんだよ、というのが今日のパネルで皆さんに伝えたかったことのひとつです。

日本人の方がきちんと質問してくる

会場から　僕はLibreOfficeというOSSのコミュニティで活動していますが、あれくらいの規模になると日本語話者のフィードバックを捨てるのはもったいなくなってきています。英語でやりとりしていると、日本語話者のフィードバックがうまくひろいきれないのですが、そういう状況にはなっていないのでしょうか？

和田氏　英語でコミュニケーションをしてユーザーが増えてくると、今度は日本語話者のフィードバックを潜在的に失うリスクがたかくなってもったいないのではないか、という話ですが、みなさんいかがですか。僕のpower-assertはそこに達していませんが。

山本氏　Twitter4Jは英語と日本語と両方（コミュニケーションチャンネルを）用意しています。コメントとかIssueはぜんぶ英語ですが、日本語でも質問できるメーリングリストは用意しています。

フィードバックを得るために障壁を低くするのは大事だと思っているので、それこと基本的な質問でも受け付けています。例えば、「それはJavaの質問でしょ？」というような、クラスパスの通し方とかでも私自身が丁寧に答えることでコミュニティの平和を保って質問しやすくしているところがあります。

会場から　みんなツイッターで文句は言うのだけど、フィードバックとしてくることはないんですよ。そこが課題ですね。

竹添氏　日本語でGitBucketの質問を受け付けるためのチャットは用意しています。それからツイッターでエゴサーチして文句も拾うようにしています。できればIssueにあげてくださいとお願いしては居ますが、それでひるんじゃう人にはこちらでIssueをひきとってあげたりしています。

たぶん日本でのIssueを拾いに行けるということは、開発リソースに余力があると思うのですが、私たちの開発状態としてはそこまではまだ余裕がないので、チャットだけ用意して、来たものだけ対応するというスタンスにしています。

山本氏　海外の人と日本人の質問では、日本人の方がきちんと質問してくる感じで、海外の人はもっとカジュアルに、「え、そんなこと聞くの？」という質問も多いですね。

和田氏　ツイッターで製品名でエゴサーチして、動かないとつぶやいている人に「どんな感じですか？」と聞いて、解決したら、それをFAQとして英語でWebサイトに書く、ということもしています。

質問やフィードバックを待っているだけでなく、こちらから能動的にGoogleやツイッターで検索したりするのも、同じ質問にいろんな人がひっかかって質問してくるのに対応していると結局は開発リソースが取られてしまうので、FAQの充実やメーリングリストの過去ログを検索可能にしたりして、はまった人が自分で解決できるように仕込んでいます。

≫後編に続きます。後編では、あるユーザーからの要望をユーザー全体からの要望として受け取っていいのかどうか、といった開発者の悩みについて。