開発者ファーストのライセンスコンプライアンスを効果的に導入する方法

ライセンスコンプライアンスは、これまで開発者にとって障害と捉えられてきましたが、今後もそうである必要はありません。ライセンスコンプライアンスは、ビジネスリスクを最小限に抑えるうえで欠かせません。しかし、開発を妨げずに大規模に実現するには、開発者ファーストの考え方が必要です。

最終的に、ソフトウェアで何を使うかを決めるのは開発者です。ソフトウェアライセンスへの準拠を実現するには、開発者が適切なコンプライアンス上の判断を下せるよう十分な権限と適切なツールを提供し、適切なガバナンスを行うコンプライアンスチームと連携できるようにする必要があります。

開発者の自律性の重要性

ソフトウェアはデジタルトランスフォーメーションを推進する原動力であり、今日の世界はソフトウェアを生み出す開発者を中心に動いています。それぞれの市場で競争力を保つには、開発者が迅速に価値を提供できるよう、あらゆる力を尽くすことが求められます。開発者は、システムを端から端まで担う必要があります。ニーズを理解し、解決策を考案し、実装、デプロイ、運用し、その経験から学ぶ。これを繰り返すのです。

このプロセスを成功させるには、開発者が自ら判断を下し、それを実行するための適切なツールを使える自律性が必要です。外部チームの介入が必要になるたびに、プロセスは遅れ、摩擦が生じます。これは根本的に、最小限のリスクでスピードを実現するというビジネスの目標に反します。

ライセンスコンプライアンスは、開発者との連携がうまくいっていないことで知られる分野の一つです。通常、開発ライフサイクルの後半で実施される手作業中心の硬直したコンプライアンスプロセスは、開発ワークフローを妨げがちです。

しかし、そうする必要はありません。開発者がライセンスコンプライアンスに取り組めるようにするための開発者への権限付与と開発者にとっての使いやすさ、そして適切な判断が行われるようにするためのガバナンスという、3つの重要な課題に対処することで、ライセンスコンプライアンスを見直し、開発者ファーストにできます。

コンプライアンス上の判断を後押しする

開発者は毎日、数え切れないほどの判断を下します。そのため、目指すべきは、適切なコンプライアンス上の判断を下せるよう支援することです。

できるだけ早い段階でテストする

ビルドが完了してからライセンスの問題一覧を開発者に提示しても、逆効果であるだけでなく、開発者と管理者の間に摩擦を生むだけです。開発者がコンプライアンス上の判断を下せるようにするには、後々の手間を省くため、非準拠のコンポーネントをできるだけ早く検出できる必要があります。これはローカルの開発環境から始まり、Gitのワークフロー、さらにCI/CDへと続きます。

白黒が明確なものと、判断の余地があるものを分ける

現在、200を超えるオープンソースライセンスが使われています。あるコンポーネントを別のものより優先して採用する際に、どのようなリスクをもたらす可能性があるのか、開発者が明確に理解できるようにする必要があります。

すべてのライセンスがGPLのように、開発者に明確な一線を示すわけではありません。より曖昧で、解釈の余地が大きいライセンスもあります。たとえば、帰属表示を求めるライセンスのオープンソースコンポーネントを考えてみましょう。開発者は、実際に帰属表示が行われているかどうかを判断できます。また、ライセンスが不明な場合は、開発を続けてコンプライアンスチームに情報共有するか、承認が下りるまで開発を止めるかを判断するための知識とツールが必要です。

開発者に提供されるコンテキストが充実しているほど、検討中のオープンソースコンポーネントに伴うリスクと価値を適切に評価できるようになります。こうしたコンテキストは、開発者向けトレーニングに加え、著作権情報など、ライセンスの問題に関する状況に即した情報を提供する開発者向けツールによって得られます。

並行して進める

開発チームは、プロジェクトの終了まで管理者との連携を待つ余裕はありません。継続的な開発が行われる現代において、このような逐次的なアプローチはもはや成り立たず、不必要な摩擦を招くだけです。そうではなく、開発者と管理者が良好な関係を築き、コンプライアンス対応を並行して進める必要があります。

開発者は、たとえ連絡しにくかったり難しかったりしても、早い段階で管理者に連絡を取り、いつ、どのように協力を求めるかを知っておく必要があります。管理者は、助言やトレーニング、情報共有を通じて対話を支援し、方向性を示すべきです。

開発者にとっての使いやすさで導入を促進する

開発者には、セキュリティやコンプライアンスを含む多くの新しい責任が課されていますが、それぞれの分野の専門家とは限りません。開発者にコンプライアンスへ積極的に取り組んでもらうには、適切なライセンスコンプライアンス上の判断を下し、実行しやすくするための投資が重要です。

開発ワークフローに組み込む

時間がかかり、逆効果にもなりかねないライセンスコンプライアンスのワークフローを開発チームが導入する可能性は、非常に低いでしょう。もちろん、無理に導入させれば、不信感や反感を招きます。

外部連携ではなく、既存のGitベースのワークフローに摩擦なく自然に組み込むことで、開発者への浸透を大きく促進できます。

可視性を確保する

ライセンスの問題を検出した後、開発者が対処しやすくなるのは、可視性が高いほどです。ライセンスの問題一覧を示すだけでなく、解決までの道筋を明確に提示できるソリューションを選びましょう。

たとえばSnykは、アーティファクトのコンテキストではなく、アプリケーションのコンテキストでライセンスの問題を説明します。依存関係ツリー全体を開発者に提示し、問題がどの経路で持ち込まれたのかを正確に把握できるようにします。これにより、開発者は迅速かつ十分な情報に基づいて判断できます。

「継続的なコンプライアンス」

現代のソフトウェア開発ライフサイクルでは、ほぼあらゆるプロセスに「継続的」という言葉が付く時代です。ライセンスコンプライアンスを開発者にとってより取り組みやすくするうえで、自動化が重要な検討事項であることは言うまでもありません。

SDLC全体を通じてライセンスコンプライアンスを自動化すると、摩擦を減らし、開発者の生産性を最大化できます。CI/CDビルドにライセンステストを組み込むのは、精度の高いテストを前提とすれば、始めるうえで優れた方法です。自動化は重要ですが、不適切なポリシーによってビルドが何度も失敗するようでは、逆効果になりかねません。

柔軟なガバナンスと硬直したガバナンス

開発チームに権限を委ねるには、可視性を確保し、信頼できる状態にすることが重要です。ビルドの各イテレーションに組み込まれるコンポーネントを自動かつ一貫して追跡し、情報を分かりやすく表示するダッシュボードで支援する必要があります。

これはあらゆるリスク管理に当てはまりますが、法令遵守では特に重要です。組織は状況を把握する必要があり、情報源をレビュー会議だけに頼ることはできません。テクノロジーの中で把握できるようにする必要があります。

これが整ったら、ガバナンスにおける厳格な基準と柔軟な基準を明確に区別することに投資しなければなりません。

すべてが白か黒かで割り切れるわけではなく、合理的な努力を行ったことを示せば十分な場合もあると、コンプライアンス担当者なら誰もが知っています。ここで、白黒が明確でない領域について、デプロイ後すぐに問題を見つけて対処することが「合理的な努力」と見なされるか考えてみましょう。多くの場合、それで十分です。このアプローチを取り入れれば、開発を妨げる頻度を減らせます。

この区別を設けることで、開発チームに大きな違いが生まれます。開発者が何かをリリースできないようにビルドを失敗させるのではなく、疑わしいライセンスがデプロイされたことをコンプライアンスチームに通知し、迅速に評価して対応の要否を判断してもらうことができます。

理想的には、こうした対話は並行して行われています。開発チームとコンプライアンスチームの連携が良好であれば、開発ワークフローの早い段階で対話が行われるでしょう。しかし、後になってから行われたとしても、直ちに打ち切ってすべてを止める必要はありません。それでは反感を招くだけです。

まとめ

開発者の自律性とスピードがますます重視される時代において、ライセンスコンプライアンスは、開発者の力を引き出すものとは言いがちです。しかし、そうである必要はありません。ライセンスコンプライアンスを開発者ファーストにすることは可能です。

Snykは、開発者に使いやすいツール、柔軟なガバナンス、エンドツーエンドの可視性を備えた開発者ファーストのソリューションを提供し、開発者がライセンスコンプライアンスに取り組めるよう支援します。その結果、より準拠したコードを実現し、最終的にリスクを低減できます。詳しくはこちらをご覧いただくか、無料でご利用を始めてください。