FOSS調達ポリシーで会社を守る
Levinによると、FOSSを利用すると企業にありがちな対立が露呈するという。FOSSはインターネットに接続さえできれば誰でもどこにいても入手でき、購買部門を通す必要がない。所要時間もごく短時間で済むことが多い。これは、購買部門を無駄と見なす多くの開発者にとって大いに歓迎すべきことだ。しかも、FOSSの特性、中でもライセンスは、開発者にとって極めて納得しやすいものだ。その上、経営陣の多くも、顧客の必要性より自分たちの都合を優先するかのようなソフトウェア・ベンダーの現状に不満を持っている、あるいは、社内で使用するソフトウェアのコストを抑えつつ大いに活用できる手段としてFOSSを見ているという。
FOSS利用で難しいのは、それによってあらゆる種類の問題が発生する可能性が生まれることだ。FOSSの入手は容易だ。したがって、セキュリティーやライセンスの問題を抱えるコードが、誰もそれに気づかないまま、ファイアウォールの内側に持ち込まれる恐れがある。ソフトウェア開発会社であれば、あってはならないコードが自社製品に紛れ込み、法的あるいはマーケティング上の大問題を引き起こすかもしれない。FOSSプロジェクトではなくFOSSベンダーから入手するようにすれば問題は緩和されるが、それでもクライアントが危険にさらされるコードが含まれている可能性は残る。
また、OpenOffice.orgやFirefoxなどのよく知られたソリューションが一般利用者の目にも触れるようになるにつれ、社内サーバーでもFOSSが利用されるようになってきたことが事態をさらに悪化させている。
Bui-Fridayによると、Palamidaのある顧客は、こうした複雑化する状況に対して、「調達責任者を数百人も抱えているような」気分だ、「サンノゼにいる開発者が何を何のためにダウンロードしているかなんて知りようがないし、東欧にいる開発者がダウンロードしてコードに組み込んだものとそれが同じかどうかなんてわかるはずがない」と述べたという。
さらに、企業組織の分散化と開発の外注化が進んでいることも問題を大きくしている。「外注先の開発者たちに書面にないことを守れと要求することはできません。ですから、オープンソース調達手続きとそれにまつわるセキュリティー要件があることを明示しない限り、外注先にはそうした点に関する注意義務はありません」と、Palamidaのシニア・コミュニケーションズ・マネージャーのMelisa LaBancz-Bleasdaleは言う。
もちろん、そうした問題が必ず発生するというわけではないだろう。Levinが指摘するように、懸念の程度は企業が受け入れるリスク・レベルに大きく依存する。「保険をかけたがる人もいれば、そうでない人もいます。当社としては、ソフトウェアを評価しコードを調べるよう勧めています。発覚してから驚くより、先に知っていた方がまだよいからです」。また、Bui-Fridayが指摘するように、一部の企業、とりわけ金融機関や公的機関は社内手続きを管理するよう義務づけられている。
Levinは、「サードパーティーからソフトウェアを入手した瞬間に、リスクの性格は変化します。自社製作のコードなら比較的管理しやすい。しかし、サードパーティーから入手すればリスク・レベルが上がります」と言う。
対策
LevinやBui-Fridayに言わせると、FOSSであろうがプロプライエタリー・ソフトウェアであろうが、ソフトウェアを管理する方法にほとんど差はない。
Bui-Fridayは次のように述べている。「オープンソース・コードも市販ソフトウェアと同じように扱うべきです。市販のコードの場合、スケーラビリティーや発売時期、可能なサポート契約、使用予定のバージョンに関する噂を評価するでしょう。製作したのがベンダーではなくコミュニティーだからといって、コミュニティーをベンダーとして見てはならないということにはなりません」。問い合わせはサービス契約によるのではなくメーリング・リストに行うなど、ビジネス手法は異なるだろうが、FOSSの場合にも相当な注意義務の原理は適用される。
また、Levinは、十分な情報を知った上で判断するため「誰がどのような環境で作ったものか」を知る必要があると説く。
Bui-FridayもLevinも、FOSSの調達を管理するなら、まず、社のポリシーを明確にすることから始めるべきだという。ここで言うポリシーは、ホワイトリストとブラックリストのように単純な形でもよい。ライセンスやソフトウェア・プロジェクトやバージョンなどについて、使用可能なものと不可のものを表したリストだ。肝心なのはこの基本ポリシーが法務や製品の責任者からシステムの管理や開発の担当者に至るまで広範な利害関係者が協力して作ったものである点で、そうでなければ無意味である。全員参加というこの条件自体が緊張感の源にも成りうる。プログラミング担当者も社内の管理職や担当者と同様の貢献が求められるからだ。ともあれ、多くの場合、合理的なポリシーを作るためにはIT部門の貢献が欠かせない。
開発者をFOSS調達ポリシーの策定作業に参加させる理由はそれだけではない。開発者はポリシーを運用する責任の大部分を負っているからだ。したがって、ポリシーができあがったら、すべての開発者が理解し支持するようにしなければならない。しかし、Bui-Fridayによると、驚くべきことに、Palamidaの顧客のうち、この段階を踏まずに調達ポリシーを策定したところが3分の1もあるという。「これは問題です。ポリシー策定に全力を尽くしたのに、現場にいる者の意見を訊いていないのですから」
次に、調達請求の審査手続きを定める。特に、通常業務としての審査担当者と、その決裁権限を超えるときの上級職への回送手続きを定めること。開発者がそうした手続きに準ずるだろうかとBui-Fridayに尋ねると、通常の請求が迅速に処理され、それ以外の請求も綿密に検討されていれば守ってくれるだろうという。しかし、請求の結果が届くまでに6か月もかかるようなら、ほとんどの開発者は「手続きどおりにしたことを後悔するでしょう。しかし、結果がすぐにわかるのであれば従ってくれるはずです」
最後に、ポリシーを策定し、コードベースの監査に使うソフトウェアを選定する。これは厖大な作業になるので、Bui-Fridayはトリアージを勧めている。つまり、最も重要性の高いコードから評価するのだ。
「初めから全コードベースを監査しようなどと考えてはいけません。ソースコードが100GBもあったらどうします？」。高度な検査を行うべきところだろうが、「最も重要なソフトウェアから着手することをお勧めします。収入に占める割合が最も大きいもの、あるいは市場露出度の最も高いものから始めるのです。その監査が終わったら、次は無作為に選ぶか、あるいは優先度に基づいて次に重要なソフトウェアを順次監査していきます」
Levinによると、こうした監査は独立した手続きにするよりも、既存の開発手続きの中に組み込んだ方がうまくいくという。多くの場合、一番よいのは、品質検査またはビルド手続きの中に組み込むことだ。
周知徹底
FOSS調達ポリシーの必要性についての認識は、Bui-FridayもLevinも、発展途上だと認めている。ソフトウェアを販売している技術系企業は高い意識を持っていることが多いが、業務で使っているだけの大企業の認識はまだ甘い。
実際、FOSSの利用が広がっているにもかかわらず、利用現場での理解は多くの点で限定的だ。Levinは、技術革新の普及過程に関するEverett Rogersモデルを援用して「率先採用する人たちにはオープンソースに関する一般知識がありますが、その外側にいる人たちには知識が不足している。転換点を過ぎ、企業は認識し始めていますが、まだ全面普及には至っていないという状況です」
その上、多くの企業はFOSS調達を管理するための活動にあからさまに二の足を踏む。「真っ先に言われる言葉は『大変そうだ。私の手には負えそうもない』です」とLaBancz-Bleasdaleは言う。Bui-Fridayによれば、ソフトウェア監査も同様だという。
しかし、Bui-Fridayは次のように説いている。「監査しないからといって、調達ポリシーを策定しない理由にはなりません。調達ポリシーは、オープンソース・ソフトウェアを上手に管理する手段であり、優れた方法です。しかも敷居は低い。すべての部門が参加できるので、どこかの部門が置いてきぼりになることもなく、コスト効果も非常に高い」。調達ポリシーを策定するだけでは不十分だが、FOSSの導入を放任するよりは遥かによいのである。
ITManagersJournal.com 原文
