華やかな開発を支える無視されがちな活動：オープンソースソフトウェアの育て方（1/3 ページ）

プログラミングはオープンソースプロジェクトで行われる活動の一部に過ぎません。しかし、ドキュメントやテストなどのプログラミング以外の活動が脚光を浴びることはまれです。本稿では、こうした無視されがちな活動を企業がどうサポートできるのかについて考えます。

[Karl Fogel， ]

プログラミング以外の活動を支援する

　プログラミングはオープンソースプロジェクトで行われる活動の一部に過ぎません。プロジェクトのボランティアから見ると、プログラミングは最も目立つ、華やかな部分です。このことは、ドキュメントやテストなどのプログラミング以外の活動が、少なくとも独占的なソフトウェアと比較すると残念ながら無視されることがある、ということを意味しています。企業は、自らが持つソフトウェア開発の内部インフラをオープンソースプロジェクトに与えることで、こうした無視されがちな活動を埋め合わせることができます。

　内部インフラをオープンソースプロジェクトにうまく与えるための鍵は、企業の内部プロセスをオープンソースプロジェクトのそれに変換することです。この変換にはそれなりの努力が必要です。企業の内部プロセスとオープンソースプロジェクトのそれは一致しないことが多いですし、そうした違いは人間が介入しないと埋められないものだからです。例えば、企業とオープンソースプロジェクトは異なるバグ追跡システムを使っているかもしれません。たとえ同じものを使っていたとしても、蓄積したデータがまったく違うかもしれません。なぜなら、企業のバグ追跡の対象がオープンソースプロジェクトのそれとはまったく違うからです。一方のシステムにある情報の断片は、もう片方のシステムに反映させるべきかもしれませんし、企業秘密にかかわるものだから削除すべきかもしれませんし、一方にないものをもう片方に追加しなければいけないかもしれません。

　ここでは、企業とオープンソースプロジェクトをそうした点で橋渡しする方法を説明します。うまく橋渡しすれば、オープンソースプロジェクトがより順調に動き、コミュニティーは与えられたリソースを理解するはずです。また、企業が自分のエゴのために物事を不適切に進めているのではないかと疑わなくなるはずです。

品質保証（テストの専門家など）

　独占的なソフトウェアの開発では、バグ探しやパフォーマンス、スケーラビリティのテスト、インタフェースやドキュメントの確認、などの品質保証専門チームを置くことが普通です。フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、品質保証に関する活動は積極的に行われないのが一般的です。これはテストのような地味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、ユーザー数が多いプロジェクトのコミュニティーでは、テストの網羅率が高くなると人々が考えるということもあります。また、パフォーマンスやスケーラビリティのテストの場合は、ボランティアは必要なハードウェアリソースを得られないから、ということもあります。

　多くのユーザーを抱えているプロダクトには多くのテスターがいる、という考えはまったく根拠がないものではありません。一般的な環境で、基礎的な機能にテスターを割り当てるのはあまり意味がないのは確かです。なぜなら、そういう状況ではバグがすぐに見つかるのが自然の流れだからです。しかし、ユーザーはただ仕事をこなそうとするだけなので、プログラムの動作の限界を意図的に探そうとはしません。よってある程度のバグが残る可能性があります。さらに、容易に回避する方法があるバグの場合、ユーザーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。最も油断ならないのは、あなたの顧客（あなたが関心がある人たちです）のソフトウェアの使い方が、そこら辺にいる平均的なユーザーの使い方と違う場合があることです。

　テスト専門のチームは、こうした手合いのバグをフリーソフトウェアでも発見してくれます。難しいのは、テストチームが行った作業の結果を、分かりやすい方法で皆に伝えることです。組織内のテスト専門部署は、テスト結果を報告する独自のやり方をそれぞれ持っています。例えば企業独自の方言や、特定の顧客や彼ら向けのデータに関する特定の知識などです。こういった独自の情報は、書式や秘密保持の観点から、公開されているバグ追跡システムに載せるのは不適切です。たとえあなたの企業で使っているバグ追跡システムが、フリーソフトウェアプロジェクトのそれと同じだったとしても、特定の企業向けのコメントやバグに関するメタデータ（例えば、バグに対する内部的な優先度や、特定の顧客向けに解決するスケジュール）を作る必要があるでしょう。こうした情報は外部には漏らさないのが普通です――場合によっては、顧客にすらみせてはいけないものです。しかし、たとえ秘密でなくても、それらはフリーソフトウェアプロジェクトにとっては関心がないものです。よって、そうした情報に気を取られてはいけません。

　しかし、バグ報告そのものはフリーソフトウェアプロジェクトにとって重要なものです。実際、テスト専門のチームから上がってきたバグ報告は、多くのユーザーから受け取るそれよりもある意味価値があるものです。なぜなら、彼らはユーザーが調べてくれないことを調べてくれるからです。テストチームからしかあがってこないバグ報告がある場合、確実に保存してフリーソフトウェアプロジェクトが利用できるようにしておきます。

　確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、彼らとの仲介役（通常は開発者の1人）が、内部向けのバグ報告を新しいものに「翻訳」してバグ追跡システムに登録するようにします。ここでいう「翻訳」とは、単に顧客特有のデータ（バグの再現手順には、もちろん顧客の同意を得た上で顧客のデータを使う場合があります）を参照せずにバグについて説明することです。

　テストチームが直接問題を登録する方がどちらかといえば望ましいです。こうすることで、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。役に立つバグ報告をすると、技術的な貢献をすることと同じくらいあなたの組織への信頼は高まります。これは開発者にとっては、テストチームと直接話をする機会につながります。例えば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、開発者はスケーラビリティに関するバグ（これをテストするリソースを彼らは持たない場合があります）を修正する作業に注力でき、その修正が望ましい結果を出しているか検証するよう、バグ追跡システム上にコメントすることでテストチームに頼むことができます。

　開発者から多少の抵抗があることは覚悟しておいてください。プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。テストチームが重要なバグを発見し、理解しやすいバグ報告を行えば、こうした抵抗を振り払うのは簡単です。一方、彼らのバグ報告の質がユーザーからあがってくるそれと大差ない場合は、開発者と彼らが直接話をする意味はありません。

　どちらにせよ、組織内部のバグ報告が、外部のバグ追跡システムにいったん登録されたら、組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。組織の管理者や雇われている開発者は、必要に応じて顧客に特有の情報について注釈をつけても構いませんが、みんなが使えるようにするために、外部の情報を利用するようにしましょう。

　こうした作業の過程で、あなたには余計な負担が掛かるはずです。1つしかバグがないのに二重にバグ報告を管理するのは、1つを管理するのに比べて仕事が多くなるのは当然です。ただ、こうすることで多くのプログラマーがバグ報告の情報を利用でき、問題の解決に貢献できるようになるのです。