オープンソース化・OSS利活用に関する有識者検討会（第5回）

概要

本検討会の概要は、オープンソース化・OSS利活用に関する有識者検討会をご覧ください。

開催情報

日時：
令和8年（2026年）1月23日（金）15時00分から17時00分まで
場所：
オンライン（Microsoft Teams）
出席委員：
庄司座長、今村委員、中村委員、岩原委員、関アドバイザー、外山アドバイザー、鈴木アドバイザー

議事次第

  • 開会
  • 座長の挨拶
  • 議事
    • 第4回有識者検討会サマリ
    • オープンソース化に関する論点と仮説の共有及び議論
    • OSS利活用に関する論点と仮説の共有及び議論
    • 今後のスケジュール
  • 閉会・諸連絡

資料

議事要旨

事務局から前回の検討会の振り返り、今回の検討会での論点と仮説について説明があった後、討議が行われた。各委員からの主な意見は以下のとおり。

デジタル庁がオープンソース化を推進するに当たり、外部コミュニティと連携しその活性化を図るには、どのような施策を講じるべきか

  • 資料に記載されているレベル1とレベル2の差が大きいと感じる。オープンソースに対し貢献を求めるには、「多くの人が利用する」というフェーズを入れる必要がある。世の中のニーズに合致したものを提供し、多くの人に利用されることで熱心なユーザーが生まれ、オープンソースがとても便利だと思って使ってもらえるフェーズが必要と考える。
  • インナーソースの場合、参加者は府省庁等になるが、オープンソースだと対象が国民全体となり、文化や目線も異なる。そのため、オープンソースとインナーソースは、分けて議論するべきである。オープンソースの論点の資料上で「限定公開」と表現されていることに矛盾がある。また、本格的にオープンソース化を進めていく場合は、一般的にレベル3までは準備段階だと考えられている。使ってもらわなければフィードバックが得られず、会員デモやマーケティングの施策も準備に含まれる。
  • レベル3までにニーズの掘り起こしやニーズの理解が混在しており、整理し直す必要がある。レベル0で準備段階として、オープンソース化するための戦略（目的・背景・想定利用者等）を考えておく必要がある。使われる見込みがなければ、オープンソース化する意味がない。
  • 資料に書かれている多くの施策は必要だと考えるが、コストがかかることを踏まえ、慎重に考えるべきである。広く利用されるためにオープンソース化すべきことが明確なものにはコストをかけるべきである。しかし、担当課の立場として、オープンソース化すべきことが明確ではないものについて公開するか否かを検討する際、コミュニティの活性化まで厳しく求められるとオープンソース化しないことになるという懸念がある。必須項目と、必須ではないがあれば望ましい項目を分けて議論すべきである。
  • 何を必須とするか、何があればよいのかということについては、オープンソースのタイプやカテゴリーによると思われる。SDKやPlugin、converter等の開発ツールは、公開されれば広く利用されると考える。
  • 記載の内容は「利用されないものは公開する必要がないから、はじめから準備するべきだ」という考えではなく、「公開してだんだん広く使われるようにレベルをあげて推進していこう」という考えに基づいているものだと考える。レベル0の1つとしてリーガルチェックがあるが、リーガルチェックが最初にあることに違和感がある。まずはオープンソースが公開された背景や目的・利用勝手が検証された後に、リーガルチェックを実施するものだとイメージしており、リーガルチェックが最初にだけあることには違和感がある。しかし、公開するものについて前もってリーガルチェックをするこれまでの議論の流れもあり、レベル0から3をまとめて考えるべきかどうか悩ましい。
  • 最初にリーガルチェックをする場合にどの程度時間をかけるのか、スピード感を重視する際にチェックに時間ばかり掛かってしまうのは課題となる。
  • リーガルチェックの内容は、オープンソースとインナーソースではコミットの仕方や深さに違いがあるため、その重要度や深さに応じた対応が必要となる。また、調達先との契約でOSS化が可能であるか、整合性が取れているかどうかもリーガルチェックに関係してくる。

OSS利活用に係る外部コミュニティの活性化に寄与するため、デジタル庁は組織の内部コミュニティにおいて、どのような施策を講じるべきか

  • オープンソース化の論点と同様に、まず自分たちが使うことが重要である。観測になるが、国内のOSSコミュニティは、ほとんどが「ユーザー会」という認識である。OSSを使う中で、「大好きなツールだから貢献しよう」という機運につながるので、まずは使ってもらうことが重要になってくる。
  • オープンソースの文化ややり方は外部コミュニティに行かないと分からないため、内部コミュニティは、外部コミュニティのトピックの共有や発表の練習、ノウハウの共有等の場にしていくことが適切である。内部と外部の垣根は無くして積極的に外部コミュニティへ参画していくべきである。
  • 外部のイベントや勉強会に積極的に参加することが重要である。諸外国の例では、政府職員がカンファレンスに出席するだけでなく発表もしており、それに向けて資料準備やリリースのタイミングを合わせていると考える。外部に向けて発表することも、マイルストーンに組み込まれると良い。資料に記載されているような、教育・オンボーディングも必要である。また、GitHubへベンダーがアクセスして個々のプロジェクトでOSSを活用しやすいようにするなど、ベンダーとどのようにやり取りするかは重要である。納品をシームレスにし、OSSを扱いやすくするような開発体制を整えることが重要である。
  • 資料に整理されている内容はどれも重要であると考える。コミュニティへ貢献していくことが、OSS利活用をしていく上で、最終的に自分たちにも利益をもたらすことをうまく伝えていくことが重要ではないか。
  • 研修や演習については、かなり実施工数のかかる作業が想定される。一方リソースは限られているため、誰が担い、どこまで内製化するかは検討する必要がある。

デジタル庁のオープンソース化・OSS利活用を円滑に進めるため、OSPOとPJ担当（PJMO）の役割分担を、実務に即してどのように定義すべきか

  • 潤沢に人材がいると仮定して考えた場合、OSPOとPJMOを繋ぐ役割、つまり両方の言葉を理解して「翻訳」できる人がいることが理想である。PJMOの中の人材で、OSSに興味があり、OSPOに出入りするモチベーションがある人が有志として担うことになると考える。
  • オープンソースとして公開すること、オープンソースを使うこと、既存のオープンソースにコントリビューションすることという3つの側面が混在しており、分担が分かりにくいため、「単にオープンソースを使う支援」、「コミュニティに入ってコントリビューションする支援」、「自らOSSを公開してコミュニティ形成する支援」の3つの観点で整理すると分かりやすいのではないか。また、コンプライアンスを遵守してOSSを利用することも重要であり、整理が必要である。
  • OSPOとPJ担当との組織的な距離が遠いと、相談ニーズを拾いきれない可能性を懸念している。デジタル庁はユニット制であるため、重要なプロジェクトには、政策・法務ユニットから弁護士等の専門人材をアサインして、OSPOとPJの架け橋となるような人材を配置することも考えられる。OSPOが設置されるまでの間も、政策・法務ユニットから法務関連を担当する人材を個別のプロジェクトにアサインし、ナレッジを蓄積していくことが一つの方法の案である。
  • 資料にまとめられているOSPOの役割についての内容に違和感はないが、現状公開されているもののデータベース化や管理も役割として必要である。
  • 現在、公開されているソフトウェアの管理は必要だが、上位の概念としてソフトウェア資産全体という考え方もある。
  • 法務コンプライアンスに関連する役割として、うまくいかないことがないようにチェックするという視点が重要であり、支援だけでなく、監視する観点でチェックする機構が、OSPOもしくはOSPO外に必要だと考える。
  • 同じ部署に支援機能とチェック機能があると、業務が属人化してしまう懸念があるため、支援機能とチェック機能は別の部門の役割とし、システマティックなフローを構築することが望ましい。

デジタル庁のプロジェクト運営の内製化に向けた人材育成において、どのようなスキルモデルを定義すべきか

  • スキルモデルは資料に記載されているようにシンプルではなく、ロールモデルのようなものに分解して整理する必要がある。OSPOは、PJ担当のロールモデルとは異なり、オープンソースのコンプライアンスの専門家を置き、ライセンスのクリアランスを担当する者のスキルの定義をすることや、OSPO全体をリードするロールモデルや開発者を導く役割も必要である。資料に記載のPJ担当は、外部のオープンソースに対してどのように関わるかの観点で分けられており、コントリビューションする人のロールモデルのようになっているが、PJ担当は、外部OSSへの貢献者だけでなく、利用者（アーキテクト等）や、自ら公開したOSSの管理者といった多様な役割を考慮すべきである。
  • 1人の職員に対し、すべてのスキル領域を求めるのは現実的ではない。専門分野以外のスキル領域についてまでレベル1のスキルを求めるのも難しく、必要性も乏しいのではないかと感じた。コミュニティマネージャーのような立場の方でも、Issueを自分で書ける人ばかりではなく、全てのスキルを1人に求める必要はない。エンジニアが技術面に専念できるよう、OSPOが技術以外のことを担っているパターンもあり、組織のOSPOの在り方によって異なるが、政府においては全てのスキルが必要ではなく、グラデーションがあってもいいのではないか。
  • OSSライセンス/知財対応については、横断的に見た場合、レベル3がレベル2よりもスキルレベルが低いと考えられ、レベルの設定をもう少し精査する必要がある。レベル4については、OSS担当者がライセンス方針を決定するだけでなく、知財や権利の担当者と対等に話ができるレベルがあれば十分だと考える。
  • レベル1のOSSライセンス/知財対応について、単にOSSを利用するのであれば、ライセンスの表記は不要である。再配布についても記載があるが、オープンソース化と混乱する恐れがあるため、「利用時」や「再配布」という表現は省き、「ライセンス表記などの基本ルールを適切に実行できる」とした方が分かりやすい。
  • OSSに関する契約条項の記載の仕方等には、特に専門的な知識が必要であり、OSPOの人材採用には、OSSについての実績や経歴を有しているという視点も重要である。

デジタル庁の内部人材に対して、オープンソース化・OSS利活用を推進できるPJ担当（PJMO）及びOSPOを育成するためには、どのような教育研修を設計すべきか

  • OSPOの体系的な研修はLinux Foundation等にあり有益だと考えるが、世の中の動きが速いので、できる限り外部でコミュニティと共に学ぶ文化を作ることが望ましい。オープンソースの利用については、分野によって必要な知識が異なるため、分野ごとに有効な研修を整理していくと良い。
  • OSPOが教育資料としてデジタル庁のPJ担当に向けて何を提供できるかという点については、OSPOそのものというよりもOSSの研修が求められていると考える。OSPO人材育成の研修ではなく、OSSに関するコンプライアンス編やトラブルシュート編といった、新人研修で使われるような実践的な教材が適していると考える。
  • Linux Foundationの資料を参考に、デジタル庁に合うものを取り入れ、教材を作成していくのがよいのではないか。
  • 最新の動向を素早く共有できる仕組みを整えるとともに、PJ担当者が直面する課題は類似していることも多いので、関係者間で定期的に勉強会を開催することで知識の底上げが図れると考える。
  • 2018年にSOFTICでOSS利用に関するQ&A集が出ているが、企業や弁護士が委員として継続的に改訂作業を行っており、改訂版が間もなく公開予定である。PJ担当者のe-learningの教材の一つにするのも良い。OSPOの担当者が、当該Q&A集に委員として関わり定期的に議論を重ね、執筆作業に携わることも有益ではないか。

以上