FOSS調達ポリシーで会社を守る：Magi's View（2/3 ページ）

[Bruce-Byfield，Open Tech Press]

対策

　レビン氏やビュイフライデー氏に言わせると、FOSSであろうがプロプライエタリなソフトウェアであろうが、ソフトウェアを管理する方法にほとんど差はない。

　ビュイフライデー氏は次のように述べている。「オープンソースのコードも市販ソフトウェアと同じように扱うべきです。市販のコードの場合、スケーラビリティーや発売時期、可能なサポート契約、使用予定のバージョンに関するうわさを評価するでしょう。製作したのがベンダーではなくコミュニティーだからといって、コミュニティーをベンダーと見てはならないということにはなりません」。問い合わせはサービス契約によるのではなくメーリングリストに行うなど、ビジネス手法は異なるだろうが、FOSSの場合にも相当な注意義務の原理は適用される。

　また、レビン氏は、十分な情報を知った上で判断するため「誰がどのような環境で作ったものか」を知る必要があると説く。

　ビュイフライデー氏もレビン氏も、FOSSの調達を管理するなら、まず、社のポリシーを明確にすることから始めるべきだという。ここで言うポリシーは、ホワイトリストとブラックリストのように単純な形でもよい。ライセンスやソフトウェアプロジェクトやバージョンなどについて、使用可能なものと不可のものを表したリストだ。肝心なのはこの基本ポリシーが法務や製品の責任者からシステムの管理や開発の担当者に至るまで広範な利害関係者が協力して作ったものである点で、そうでなければ無意味である。全員参加というこの条件自体が緊張感の源にも成りうる。プログラミング担当者も社内の管理職や担当者と同様の貢献が求められるからだ。ともあれ、多くの場合、合理的なポリシーを作るためにはIT部門の貢献が欠かせない。

　開発者をFOSS調達ポリシーの策定作業に参加させる理由はそれだけではない。開発者はポリシーを運用する責任の大部分を負っているからだ。従って、ポリシーが出来上がったら、すべての開発者が理解し支持するようにしなければならない。しかし、ビュイフライデー氏によると、驚くべきことに、Palamidaの顧客のうち、この段階を踏まずに調達ポリシーを策定したところが3分の1もあるという。「これは問題です。ポリシー策定に全力を尽くしたのに、現場にいる者の意見を聞いていないのですから」

　次に、調達請求の審査手続きを定める。特に、通常業務としての審査担当者と、その決裁権限を超えるときの上級職への回送手続きを定めること。開発者がそうした手続きに準ずるだろうかとビュイフライデー氏に尋ねると、通常の請求が迅速に処理され、それ以外の請求も綿密に検討されていれば守ってくれるだろうという。しかし、請求の結果が届くまでに6カ月もかかるようなら、ほとんどの開発者は「手続きどおりにしたことを後悔するでしょう。しかし、結果がすぐに分かるのであれば従ってくれるはずです」

　最後に、ポリシーを策定し、コードベースの監査に使うソフトウェアを選定する。これは膨大な作業になるので、ビュイフライデー氏はトリアージを勧めている。つまり、最も重要性の高いコードから評価するのだ。

　「はじめから全コードベースを監査しようなどと考えてはいけません。ソースコードが100Gバイトもあったらどうします？」。高度な検査を行うべきところだろうが、「最も重要なソフトウェアから着手することをお勧めします。収入に占める割合が最も大きいもの、あるいは市場露出度の最も高いものから始めるのです。その監査が終わったら、次は無作為に選ぶか、あるいは優先度に基づいて次に重要なソフトウェアを順次監査していきます」

　レビン氏によると、こうした監査は独立した手続きにするよりも、既存の開発手続きの中に組み込んだ方がうまくいくという。多くの場合、一番よいのは、品質検査またはビルド手続きの中に組み込むことだ。