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

2017年1月11日

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

オープンソースソフトウェア（OSS）は、公開されているソースコードが多くの人の目にさらされることで品質が向上していくという見方がある一方、その人の目を十分に確保するにはどうすればいいか、そしてその品質をボランティアを中心とした限られた人的資源などでどのように維持、向上させていくのか、といった課題も抱えています。

このパネルディスカッションでは、モデレータを含む4人のOSS開発者が、それぞれのOSSの開発現場でそうした課題をどう克服しようとしているのか、生々しい現場の状況と問題意識について議論していきます。

本記事では、その議論の内容を前編（本記事）、中編、後編の3本で紹介します。

OSSにおける品質管理・テストと運営

モデレータの和田卓人氏（タワーズ・クエスト）

和田氏　このセッションは、OSSにおける品質管理やテストなどをどう考え、運営しているのか、という内容でパネルディスカッションをさせていただきます。まずは登壇者がどんな方か、自己紹介してもらおうと思います。

パネリストの山本裕介氏（サムライズム）、川口章氏（ノーチラス・テクノロジーズ）、竹添直樹氏（ビズリーチ）

竹添氏　ビズリーチの竹添と申します。転職サービスの会社なのですが、今日は個人で「GitBucket」という、GitHubのような機能を提供するWebアプリケーションを作っているので、その立場で参加させていただきます。

もともと僕はSIerにいて、そのときはGitHubのような外部のサービスを使えなくて、それで社内でもGitHubのようなサービスが使えたらいいなと思ってGitBucketをはじめました。

なのでGitBucketはGitHubを参考に開発を始めたのですが、同じようなニーズを持ったお客さんが国内にも、海外にも多くいるので開発を続けています。

川口氏　ノーチラス・テクノロジーズの川口と申します。「Asakusa Framework」という、HadoopやSparkを利用してバッチアプリケーションなどを高速に実行するフレームワークを私の会社がオープンソースで作っていて、私はその開発メンバーとして参加しています。

Asakusa FrameworkのおもなフィールドはSIで、データやモデルがたくさんあって処理が複雑、というケースにフィットするフレームワークです。開発は3名くらいで、2人がコードを書いて、私はテストをしたりビルド環境を整えたり、ドキュメント管理をしたり、リリースエンジニアリングをしたりしています。こういう役割はJaSSTの参加者にも多いと思うので、その辺の実態をお話できればと思っています。

山本氏　サムライズムという会社でソフトウェアのリセラーをしています。今日は個人としての参加です。私は「Twitter4J」というライブラリを作っていまして、これはTwitterのAPIにJavaでアクセスできるライブラリで、例えばFacebookのAndroidアプリなど、非常によく使われています。

コントリビュータも100名を超えていて、プルリクエストもけっこうきます。

Twitter4Jは世の中でけっこうたくさん使われていて品質は重要になっているのですが、そこの体制などは前の2つのソフトウェアとは違う感じでやっているのかな、というあたりをお話できればと思っています。

和田氏　モデレータの和田です。私は「power-assert」というJavaScriptのテスト用ライブラリをオープンソースで開発しています。

power-assertは簡単な記法と詳細なレポートを両立させるのが特徴で、最近では国内外の採用例が増えてきました。

ということで、全員の立ち位置をまとめるとこんなかんじでしょうか。

Asakusa Frameworkは期間バッチシステム構築のためのもので、この4人のなかでは業務システム開発にいちばん近い。

GitBucketは、GitHubのようなものを社内で使うためのインストールするアプリケーション。ユーザー数が急速に増えている途中のソフトウェアでもあるため、その時期固有の悩みがあると思います。

一方のTwitter4Jは利用者もコントリビュータも多く、開発のフェーズとしては安定期。簡単に言えば、枯れているソフトで、Twitterのほうに仕様変更があるとそれがTwitter4Jにも入る、というようなフェーズ。

power-assertはライブラリとしてはTwitter4Jの立ち位置に近いですが、テストに使うためのソフトウェアということで、期待される要件がほかのソフトウェアとはちょっとだけ違ってくる、という感じです。

Asakusa Frameworkは定期的にリリース

和田氏　ここからディスカッションに入ろうと思いますが、まずはそれぞれのOSSプロダクトがどんな開発やリリースをしているか、というのを深掘りしていきたいと思います。

OSSというと、LinuxやApacheのような大きなソフトウェアでしかも膨大なコントリビュータがいるモノを想像しがちですが、ここに登壇している4人のソフトウェアはそれとはちょっと違っていて、GitHub登場前のOSSではなく、GitHub登場以降のOSSとはどんなものかという感覚をつかんでいただけるのではないかと思います。

ではAsakusa Frameworkの川口さんからお願いします。

川口氏　Asakusa Frameworkは2011年4月に初版をリリースして、そろそろ5周年を迎えるプロダクトです。最初は基幹システム向けのいろんなソフトウェアやライブラリとかツール群、部品の集合だったのですが、多くの人に使ってもらいたいということでOSSにしたという経緯があって、OSSらしくないところとOSSらしいところが共存しているようなプロダクトになっています。

ユーザーのフィードバックをもらって進化していくことを目指しているので、リリースの頻度はあえて3カ月に1回くらいと固定しています。

ソースはGitHubで公開していて、いまはプルリクベースで開発しています。実情としてはほとんど社内の人からのプルリクがほとんどで、ごくたまに社外からプルリクが来る、という状態になっています。

基幹システムで使われることを想定しているので安定性には気をつけていて、3カ月ベースでのリリースのうち最初の2カ月でフィーチャーフリーズをして、残りの1カ月で品質を上げたりドキュメントを充実させたり、さまざまなプラットフォームでテストをして、リリースしていく、という感じです。

この流れはもう5年もやっているのでリズムもできていて、社内ではうまく回っていると思います。

和田氏　3カ月でリリースというサイクルはいつ頃からだったんですか？

川口氏　わりと最初からです。決めていたわけではなかったのですが、例えばEclipseも1年に3回リリースされていて、きちっと決めてリリースされると使う側も準備するというか、バグがあっても次に直るのはいつ頃だか分かりやすいですし、どのタイミングでリリースされるのかが分かれば、ユーザーがどういう品質レベルで使うのか、自分たちでコントロールしやすいと思うので、定期的なタイミングでリリースするのはいいのかなと思っています。

Twitter4Jとpower-assertは随時リリース、GitBucketは毎月リリース

和田氏　Twitter4Jはどんな感じでリリースしていますか？

山本氏　プルリクエストやパッチなどをいただいて、私がレビューしてからマージして、Jenkinsで自動テストを動かして通ったら、手もとでスクリプトを動かしてリリースしています。

リリース頻度は不定期で、私が頑張っているときにはリリースしたあとまたすぐ次のリリースが出たりしていますが、重要な修正などがないときには半年リリースがない、ということもあります。

いまはそれほどアクティブに開発していなくて、Twitter APIで機能が追加されたら、誰かがそれに対応したコードを書いてくれたり、私が書いたり。Twitterに機能が追加されなくても、こういう機能がほしいという要望がときどきあって、最近だとApache Sparkで使いたいんだけどこうしませんか、というプルリクがあって、やらなくちゃ、というところですね。

和田氏　竹添さんのGitBucketのリリースまわりはどんな感じですか？

竹添氏　GitBucketは月イチで必ずリリースするようにしています。最初のバージョンは2013年だったと思いますが、そこから欠かさず続けています。リリースのタイミングは毎月月末か、ちょっと遅れると翌月の月初になります。

この機能ができるまでリリースしないというよりは、そのタイミングでできたものを入れると。1カ月で作れないモノや、時間が掛かる足回りのライブラリのバージョンアップなどはブランチを切って別のラインで開発を続けて、安定した段階で取り込んでいます。その場合にはメジャーバージョンアップになると思いますが。

ただ、データベースのデータが読めないなど致命的な場合にはホットフィックスとして通常とは別のリリースをしたりしています。

開発のリソースや人手の問題もあって、画面周りはユニットテストを書いてもテストしきれないものがあるので、画面周りの軽微なバグはユーザーさんからのフィードバックをもらって直していくというスタンスです。

バックエンドはできるだけテストを書いていますが、プルリクをもらったものに関してはTravis CIでCIを回して、それが通らないとマージしない、通らない状態で来たモノはテストを通るようにしてからにしてください、と言ってますね。

実際には僕らがテストを書いている部分もあるのですが、Travis CIで回す仕組みを作っているので、プルリクを送ってくるときにコントリビュータがコントリビュートをしやすい仕組みを用意して、僕ら開発者サイドのリソースだけではできないことを外部の人に協力してもらうように、などの工夫をしています。

和田氏　僕のところのpower-assertのリリースは不定期ですね。ソフトウェアがもう枯れているので、月イチで出すようなものがない。

大きな新機能はビッグブランチにして、できあがったら本線に合流するということをしていて、並行してたまにプルリクが来たり、例えば「ここのスペルが間違ってますよ」といったものから「ここのテストを足しておきました」といったものまでいろいろと来るので、そういうのはすぐに取り込んでリリースして、ビッグブランチの開発に戻る、という感じでやっています。

和田氏　ここまでのお話で、OSSのリリースのタイミングが定期リリースなものと不定期リリースなものとにざっくり分かれました。

定期リリースか不定期リリースかは、ソフトウェアが安定期にあるか、がんがん攻めているのか、といったことに関係しているようです。

川口氏　うち（Asakusa Framework）もホットフィックスをリリースすることがあって、ただホットフィックスによって別の何かを壊していないかどうかにかなり気をつけていて、そのために自動テストの仕組みを作り込んだり、リリースプロセスの自動化をやったりしています。ただ、そこにもコストがかかるので、どれくらいそういったことをやればいいか、プロダクトを作る立場としてバランスをとるのが難しいというのが日々苦労しているところです。

実は最初はガチガチのきびしいリリースプロセスを作ったのですが、それだと私の時間がたくさんとられてつらくなったので、それでライトウェイトなプロセスにしました。ところがそれだとホットフィックスのときのリリースプロセスが枯れていないので別のところを壊しやすくなるところがあって、そのあたりは時期によって変わってきていて、そこはいつも苦労しています。

一方、バグがあったときに回避手段を考えたり、ユーザー側の作業を止めないように調べて回答したりするのですが、Asakusa Frameworkならではの苦労している点として、ユーザーが業務のなかで使っているために割と機密性の高い処理を作っていることが多く、再現環境がなかなかもらえないところがあって、数少ない情報からトラブルシューティングしなければならなかったりします。その辺はエンジニアリングの腕の見せ所かなと思います。

≫中編に続きます。中編では、クリティカルなユーザー数に達するために英語圏で普及させるための努力などについて。