ソフトウェア開発に力を入れる先進企業がOSSの専門チーム「OSPO」を設立するきっかけとは：始めよう！　企業としてのオープンソース活動（3）（2/3 ページ）

　このような対応ミスを教訓として、OSPOの設立やOSSに対する方針／ポリシーの制定といった、会社としての取り組みが始まります。

　OSPOの設立後は、このようなレターや問い合わせはOSPOに連絡が届き、適切に対処されることになります。

ケース3：社内の各部署でそれぞれの判断でOSSを使い始めているが、考え方を合わせたい

　OSSについてよく理解しているメンバーがある程度いて、開発活動の中で発言力を持っている場合、当初はそのメンバーの発言力の及ぶ範囲で、適切にOSSが取り扱われることも多いです。ただし、発言力の及ぶ範囲であり、また、そのメンバーの理解の範囲にとどまるため、会社全体として十分な取り組みにはなりません。

　また、他の複数の部門にもOSSについて理解しているメンバーがいて、それぞれの部門の範囲での取り組みが行われている場合があります。社内である程度OSSが普及してきた時期に、こうした状態になることがよくあります。

　ケース2で触れた、ライセンス違反の指摘を受けるような問題が起こらなければ、この状態のまましばらくは続いていくことが考えられます。それでも時間の経過とともに、メンバーの異動や部門間での開発成果の流用などをきっかけとして、考え方や対応の仕方の違いが無視できなくなります。そこで、会社全体の統一的な活動を求める動きが起こり、OSPOが形成されます。

　これは、会社のオープンソース関連活動がボトムアップで形成されていく典型的なケースです。

より発展的なOSPOを社内で設置する理由

　OSSについて十分な理解を持つ人が多くいる会社の場合、初期のOSPOが生まれるきっかけとなる事態が発生したとしても、個々のエンジニアや法務、知財、技術管理等の既存の組織が適切に処理し、これまでOSPOという組織が生まれるまでには至らないケースもありました。

　しかし、最近では「OSPO」という名前が知られるようになり、これまで社内でOSSの取り扱いを検討・推進する役割を果たしていた組織や集団が、自らをOSPOだと認識するようになりました。

　各社のOSPOについての紹介や、OSPOの在り方を議論するコミュニティー活動により、OSPOの必要性が広く周知されるようになりました。さらに、OSPOの役割はもっと広いと考えられるようになりました。

　このように、OSSについて理解している人が多く、従来はOSPOという組織や集団が必要なかった会社において、より広い役割を担うOSPOが生まれるきっかけには、次のようなものがあります。

• ケース4：OSSを利用するための社内手続きに手を取られずに開発に集中したい
• ケース5：OSS・コミュニティーとのより良い関係を模索したい

　いずれも、OSSを単に調達ソフトウェアとして捉えるのではなく、OSSの開発を自社の事業活動の一部として積極的に関わろうとするものです。

ケース4：OSSを利用するための社内手続きに手を取られず、開発に集中したい

　OSSを使うことのメリットに気付いたエンジニアがもっと積極的にOSSを利用し、コミュニティーに対してバグ報告や修正提案を行っていこうとするときに、社内手続きの壁に突き当たります。

　例えば、OSSをダウンロードして利用を始めると、OSSを利用する際の条件であるライセンスを会社として受諾することになります。すると、これまでの会社のルールに照らせば、「契約締結」と似たような社内承認手続が必要と考える人が出てきます。また、バグ報告や修正案をコミュニティーに提供しようとする行為は、相手を限定しない公への情報発信になるため、「社内技術の流出」や「社外発表」になるのではないかとの考えも出てきます。

　既存のルールのままでOSSを扱おうとすると、手続きや社内の説得にエンジニアの労力と時間が奪われ、OSSのメリットが十分に生かせなくなって「OSSを使うより自分たちで開発した方がいい」という判断になってしまいます。

　OSSが一般的に使われ始めた初期の頃は、このように既存のルールでOSSを扱おうとして、実質的にOSSを利用できなかった会社もあったようです。

　その後、OSSが徐々に使われるようになり、ソフトウェア全体の80％を占めるといわれる今日の状態になる過程で、OSSの利用メリットとリスクのバランスの取れたルールを作り上げる必要が生じました。

　この新しいルールを検討するため、社内でOSSについてよく知っている人を中心として、委員会やワーキンググループが作られ、OSPOとなっていきます。

ケース5：OSSやコミュニティーとのより良い関係を模索したい

　オープンソースコミュニティーに対して、OSSの不具合を報告したり、OSSの改善コードを提案したり、カンファレンスなどのイベントに参加したりすると、OSSが作られていくプロセスや、互いの意見を尊重しながらコンセンサスが作られる様子についてさらに理解が深まっていきます。

　すると、OSSが単なる「自由に利用できるソースコード」ではなく、通常のソフトウェア開発とは異なるダイナミズムとカルチャーで成立しているソフトウェアと考えるようになります。そして、このダイナミズムとカルチャーがソフトウェア開発にとって非常に効果的かつ効率的であり、会社内のソフトウェア開発と連携することで、単にOSSを利用するだけでは得られなかった、より大きな効果を得られると考えるようにもなります。

　そこで、このOSSのダイナミズムとカルチャーに会社を適応させることで、より大きな効果を得るための取り組みを推進する役割を持つ組織としてOSPOが生まれます。既にOSPOが存在していても、これまで説明したケース1〜3では、この役割を持つまでに至っていないことが多いです。

　ケース5は、ケース3のようにボトムアップではなかなか起こりません。ボトムアップで必要性が発信されることが多いですが、最終的には会社全体に影響力を持つ人、つまり経営陣（Cレベル）からのトップダウンで形成されることがほとんどです。