![ハイブリッド開発
nウォーターフォール＋アジャイル
• 全体の工程はウォーターフォール
• 実装などの各工程はアジャイル
Chatterjee, Rishab & Joarder, Kaushik & Chatterjee, Sourav & Sanders, Barry & Sinha, Urbasi. (2019).
qkdSim: An experimenter's simulation toolkit for QKD with imperfections, and its performance analysis
with a demonstration of the B92 protocol using heralded photon. [online]](https://image.slidesharecdn.com/202304-231007115030-92dc58f2/85/2023-04-27-320.jpg)
ソフトウェア工学2023 04 開発プロセスモデル
- 1. ソフトウェア工学 n開発プロセスモデル • ウォーターフォール，プロトタイピング，スパイラル，ア ジャイル，スクラム，XP • レビュー，コード規約 • 著作権，ライセンス，特許 玉木徹（名工大）
- 2. システム開発のライフサイクル nライフサイクル＝始まりから終わりまで • 要求分析，要件定義 • 顧客の望むこと（要求）を仕様（要件）に落とし込む • 外部設計 • システムの使い方と構成を仕様にする • 内部設計 • 実装の方針を決定する • プログラミング • 実際の開発を行う • テスト • 品質を保証するための確認を行う • 運用・保守 • 納品後のメンテナンスを続ける 上流工程 下流工程
- 4. 要件定義は終わらない n要求を集める作業をユーザーが妨げる可能性 • ユーザーは自らが何を欲しているか理解していないことがある。 • ユーザーは要求仕様書に関わりたがらないことがある。 • ユーザーは既にスケジュールと費用が確定した状態で新たな要求を出してくる。 • ユーザーとの対話には時間がかかる。 • ユーザーはレビューに参加したがらないか、参加できないことがある。 • ユーザーは技術に疎い。 • ユーザーは開発工程を理解しない。 n要求仕様は開発が開始されてからも変更され続ける Wikipedia, 要求分析「関係者の問題点」
- 5. 代表的な開発プロセス n一方通行の開発 • モデル • ウォーターフォール • V字 • 上流が下流に影響 • 終わるまで始められない • 遅れたらしわ寄せ n顧客の問題 • 最初の要件定義を分かっていない • 開発途中で様々な追加要求を出 してくることがある • 「それができるならあれもでき るよね」「これもできるように なったら嬉しい」など • 要件定義，外部設計，内部設計 をすべてやり直し • 顧客はモノを見ないと分からない， 納得しない • 見たら要求も出てくる，変わる • 顧客の意見は入らない • 受け入れテストまで成果物を見 られない
- 6. 代表的な開発プロセス nサイクルを伴う開発（反復型） • モデル • プロトタイピング • スパイラル • アジャイル • 工程を何度も繰り返す • 顧客の意見を確認し取り入れる • 顧客に途中の成果物を見せる • プロトタイプ • モックアップ（モック） • 顧客との信頼関係を築く https://pixabay.com/ja/illustrations/ui-モバイル-アプリ-771829/ Pixabay License
- 7. 開発プロセスとビジネスプロセス nサイクルを伴う開発プロセス • プロトタイピング • スパイラル • アジャイル nサイクルを伴うビジネスプロセス • MVP (minimum value product) • 最小限の機能のみを実装，リリース． • アーリーアダプターからのフィードバックを 次の製品に反映 • 注：開発モデルというよりはビジネス手法・ 事業モデル（リーンスタートアップ） n類似点 • 素早いフィードバックループの構築 社会 企業 BtoC BtoB リリース クライ アント ベンダ BtoB 開発
- 8. 開発プロセスモデル
- 9. 様々な開発プロセスモデルの発展 n開発プロセス • プロジェクトをすすめるための標 準的な方策 • ライフサイクル，開発工程など とも言う • 効率の良さが必要 • Q：高品質（Quality） • C：省コスト（Cost） • D：短期間（Delivery） n開発プロセスモデル • ソフトウェア工学の目標：生産性 と品質の向上のために，反復可能 かつ予測可能な開発プロセスの方 法論を確立する n種類 • ウォーターフォールモデル • プロトタイピングモデル • スパイラルモデル • アジャイル
- 10. ウォーターフォールモデル nメリット • 順番が明確 • 進捗管理が容易 • 分担も明確 • 長年利用されている nデメリット • 実際にはやり直しもある • 遅れが生じると下流にしわ寄せ がいく • システムが納品されるまでクラ イアントはシステムを見ること ができない 要件定義 外部設計 内部設計 実装 テスト 運用・保 守 要件定義書 外部設計書 内部設計書 プログラム 上 流 工 程 下 流 工 程 システム
- 11. ウォーターフォールモデル n大規模なプロジェクトは ウォーターフォールモデ ルが多い • 上流になればなるほど管 理が大変 • 下流の個別開発は異なる モデルの場合もある nすべてを反復型でやるこ とは少ない • 各工程では反復型 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html
- 12. プロトタイピングモデル n概要 • 各工程でプロトタイプを作成 • 作成して見せてフィードバック • 顧客にフィードバックし，要求を満 たしているのかチェック nデメリット • プロトタイプの開発に • コストがかかる • 時間をかけてしまう 要件定義 外部設計 内部設計 実装 テスト 運用・保 守 プロトタイプ
- 15. プロトタイピングモデル n水平プロトタイプ • 多くの機能を実現 • ただしすべてダミーであり，動作しない • UIの確認に適している • 操作はできるが，処理はしていない n垂直プロトタイプ • 少数の機能を実現 • すべて動作するが，完全な処理ではない • 最低限の処理結果を得ることができる 機能の種類 動作 する 水平プロトタイプ 垂直プロトタイプ 動作 しない 豊富 少数
- 16. スパイラルモデル n4つのフェーズを繰り返す • 目的と対策の決定 • 対策とリスクの評価 • 開発と検証 • 次フェーズの計画 n反復によって徐々に改良 • 要求を具体的に • 設計を詳細に Spiralmodel, vectorized from Barry W. Boehm: Software Engineering Economics, Prentice Hall PTR, 1981Marekventur - Own work •CC BY-SA 3.0
- 17. スパイラルモデルとプロトタイピングモデル The three basic approaches applied to software development methodology frameworks. Beao Old waterfall: Paul Smith - File:Waterfall model revised.svg File:Rapid application software development.svg File:Software Development Spiral.svg Three software development patterns mashed together. Public Domain n類似点 • プロトタイプを作成 • 顧客に確認 n相違点 • スパイラルモデルは • 要求分析も反復する • 仕様書を改善する • プロトタイプではない • 各反復で製品まで • サブシステム開発にも適用 • サブシステム1を作り，2を 作り，3を作る，と反復する
- 18. 高速アプリケーション開発 nRAD • Rapid Application Development • （ユーザーを含む）少人数のチームで開発 • プロトタイプを作ってそれを評価するというサイクルを繰り返す • 目的 • とにかく速く製品を開発することを目的とする • RAD専用のものを活用する • 自動化ツール • ライブラリ • テンプレート • モジュール Gambar RAD Modif A Ambarita - Own work CC BY-SA 4.0
- 19. アジャイル開発 nアジャイル（agile） • 俊敏な，機敏な，すばしこい n迅速かつ変化に柔軟に対応する ための手法の総称 n反復を繰り返す • 1つの機能を1つの「反復」という 時間単位で開発 • 比較的短期間で反復を繰り返す • 反復の期間は1〜4週間程度 • 要求分析，設計，実装，テストな どすべてを1反復で行う • 各反復の終了時にリリースするこ とを目指す n無駄なドキュメントを作るくら いなら動くものを作る • アジャイルソフトウェア開発宣言 Planbox - Own work CC BY-SA 3.0
- 20. アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、 左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく。 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含める ことを条件に自由にコピーしてよい。 https://agilemanifesto.org/iso/ja/manifesto.html 参考： アジャイル領域へのスキル変革の指針：ア ジャイルソフトウェア開発宣言の読みとき 方, IPA, 2020
- 22. アジャイルの考え方はコード開発だけではない n様々な部署で導入可能 • 企画部 • 事業部 • マーケティング部 • 人事部 • 経理部 n日本では • 導入がかなり遅れている DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
- 23. 様々なアジャイル開発手法 nスクラム（Scrum） nエクストリーム・プログラミング（XP, eXtreme Programming） nその他 • クリスタル（Crystal） • ユーザー機能駆動開発（FDD, Feature Driven Development） • 適応的ソフトウェア開発（ASD：Adaptive Software Development） • リーンソフトウェア開発（LSD：Lean Software Development） • etc
- 24. スクラム（Scrum） nアジャイル型開発手法の一つ • 「スクラムを組む」の「スクラム」 n要素 • バックログ • プロダクトバックログ • 顧客の要求など • スプリントバックログ • スプリントで行う作業 • スプリント • 反復の単位 • デイリースクラム • 毎日の進捗確認 参考 アジャイル領域へのスキル変革の指針：アジャイル開発 の進め方, IPA, 2020 The Scrum process Lakeworks - Own work CC BY-SA 4.0 Daily scrum Release Sprint planning
- 26. アジャイル時代の契約 n非アジャイルの場合 • 「更新が必要になれば、 新たに仕様書を作り、契 約を変更する」という作 業を繰り返した結果、契 約変更には数週間単位の 時間を要したという。 COCOAトラブルの要因 内情知る元 幹部が明かす「お役所体質」 2022/10/14 n契約書類作成の事務作 業もアジャイルになる 必要がある IPA,アジャイル開発版「情報システム・モデル取引・契約書」, 2020 https://www.ipa.go.jp/ikc/reports/20200331_1.html DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
- 27. ハイブリッド開発 nウォーターフォール＋アジャイル • 全体の工程はウォーターフォール • 実装などの各工程はアジャイル Chatterjee, Rishab & Joarder, Kaushik & Chatterjee, Sourav & Sanders, Barry & Sinha, Urbasi. (2019). qkdSim: An experimenter's simulation toolkit for QKD with imperfections, and its performance analysis with a demonstration of the B92 protocol using heralded photon. [online]
- 28. エクストリーム・プログラミング（XP） nアジャイル型開発手法の一つ • エクストリーム（extreme）：極 端な • 伝統的なソフトウェアエンジニア リングのプラクティスの有益な要 素を「極端な（エクストリーム な）」レベルに持っていくという 考えからその名前を取っている • https://ja.wikipedia.org/wiki/エクストリーム・プログラミング Extreme Programming (XP) requires planning and feedback at many levels and many frequencies.DonWells - Own work based on: XP- feedback.gif CC BY-SA 3.0
- 29. エクストリーム・プログラミング（XP） n 価値 • コミュニケーション • シンプルさ • フィードバック • 勇気 • 尊重 n 原則 • フィードバックは迅速かつ頻繁に • シンプルさを前提に • 変化を受け入れる n 開発プラクティス • テスト駆動開発 • 実際のコードを書くよりも前に単 体テストのコードを書く • ペアプログラミング • 二人一組でプログラミングを行う • 1人はコーディング（ドライバー） • もう1人は確認とサポート（ナビ ゲーター） • リファクタリング • コードを分かりやすく書き直す • YAGNI（You Aren't Going to Need It） • それは必要ない • （＝必要なことだけやろう）
- 30. ペアプログラミングとモブプログラミング nペアプログラミング • 二人一組 nモブプログラミング • 多人数 • コツ：自分の考えを常に言葉に出 し続ける French Mob programming session Sisipirate - Own work CC BY-SA 4.0 Engineers at a startup pair programming Vajrapani666 - Own work CC BY-SA 3.0
- 31. 歴史 n1970年代 • 構造化プログラミング n1980年代 • 構造化分析（SSADM，Structured Systems Analysis Method，構造化システム 分析・設計手法） n1990年代 • オブジェクト指向プログラミング（OOP，Object-Oriented Programming） • RAD • スクラム • エクストリーム・プログラミング n2000年代 • アジャイル宣言
- 33. レビュー
- 34. レビュー n開発工程の各段階での成果物を確認する作業 • 品質管理のため • 手戻りコスト削減のため • 手戻り：ある工程で判明した不具合を修正するために，それ以前の工程へ 戻ること • 同じ不具合を修正するにも，後の工程になるほどコストが大きくなる
- 35. 重要な10個の指標 nソフトウェアのプロジェクトの管理において，産業における価値とい う意味で，開発についての重要な以下の10個の指標を知っておくべき である．順序はおよそである． 1. 納品後に発覚した問題の修正には，要件定義や初期設計段階で発見して修正 するよりも費用は100倍もかかる． 2. 開発スケジュールは予定から25％までは短縮することはできるが，それ以上 は無理である． 3. メンテナンスにかかる費用は，開発にかかる費用の2倍である． 4. 開発とメンテナンスのコストは，ソースコードの行数（命令数）の関数であ る． 5. ソフトウェアの生産性は，個人に大きく依存する． Barry W. Boehm, Industrial software metrics top 10 list, IEEE Software, Vol. 4, No. 5, pp.84-85, 1987. https://asfak-ur-rahman.blogspot.com/2011/07/software-project-management-top-10-list.html
- 36. 重要な10個の指標 6. ソフトウェアとハードウェアのコスト比率は，1955年には15:85だったのが， 1985年には85:15になり，現在も増え続けている． 7. 開発に対する努力のうち、プログラミングに費やされているのはたった15% に過ぎない． 8. システムとプロダクトにかかるコストは，1命令あたりの開発コストが個々 のプログラムの3倍になる．つまりシステムプロダクトのコストは9倍になる． 9. ウォークスルーレビューによって誤りの60%を見つけることができる． 10. 多くのソフトウェアに関する現象はパレート分布に従っている．つまり貢献 の80％は貢献者の20％から来ている． Barry W. Boehm, Industrial software metrics top 10 list, IEEE Software, Vol. 4, No. 5, pp.84-85, 1987. https://asfak-ur-rahman.blogspot.com/2011/07/software-project-management-top-10-list.html
- 37. 現代：プログラミングはほんの一部 (16) APIの実現性の確認（候補 パッケージのAPI、既存システムとの 接続性等の評価） (1) 事業要件定義 (2) プロジェクトゴールの策定 (3) 要求品質の明確化 (4) パッケージを利用し実現す る業務の新全体像の作成 (5) ベンダに対しシステム、パッ ケージ等の情報提供要求、試算 見積依頼(RFI) (6) ユーザに対しRFIに基づくシ ステム、パッケージ等の情報の 提供、試算見積の提示 (7) 業務要件定義 (8) ベンダに対しパッケージ候補 選定のための情報提供依頼 (RFI) (9) ユーザに対しRFIに基づくパッ ケージ関連情報の提供、概算見 積の提示*2 (15) パッケージ候補の システム要件評価 (17) パッケージソフトウェアの 選定と要件定義 システム要件定義と評価 (22) モディファイ、アドオンの範囲の 確定、及びそれに伴うユーザI/F・他 システムI/F設計*3 (25) ソフトウェア設計*1 (41) ハード保守、カスタ マイズ部分保守開始 2.1 企画 2.2 要件定義 (27) 適格性確認テスト、監査、 ソフトウェア導入 (26) モディファイ、アドオンの設計、 プログラミング、ソフトウェアテスト 2.3 システム開発 3.1 運用 2.6 保守 運用準備 パッケージカスタマイズ 取引・契約モデルの全体像 重要事項説明書 A要件定義支援及びパッケージソフトウェア候補選定支援業務契約(カスタマイ ズモデル)：準委任、(1)～(13)適用、Bパッケージソフトウェア選定支援及び要件定義支援業務 契約(カスタマイズモデル)：準委任、(14)～(18)適用 別紙1 （パッケージ、SaaS/ASP活用、保守・運用）＜ 追補版＞ 設計・制作・テスト・移行 ( 29 ) 検 収 ( 受 入 れ ） (19) ベンダへの見積要求*2 (20) ユーザへの見積提出 (23) 外部設計書の承認(受入れ) (28) 納品 (45) 廃棄 (42) 運用支援 (43) システム運用評価 及び業務運用評価 (43) 投資効果及び業務 効果の評価 (36) 運用テスト (38) 利用者導入教育 ※数字は共通フレーム2013該当項番 (40) 業務運用 (37) 完了報告(受入れ） A 要件定義支援及びパッケージ ソフトウェア候補選定支援契約 重要事項説明書 D外部設計支援業務契約：準委任・(21)～(23)適用、Eソフトウェア設計・制作契約：請負・(25)～ (29)適用、F構築・設定業務契約：請負・(30)～(32)適用、Gデータ移行支援契約：準委任・(33)～(34)適用、H運用テ スト支援契約：準委任・(35)～(37)適用、I導入教育支援契約：準委任・(38)～(39)適用 (10) パッケージの機能要件、非機 能要件、使用許諾契約（利用条件、 保守等）の検討 (11) パッケージ候補の選定 (12) 業務要件及び適合するパッ ケージ候補の報告書の提出 (39) 完了報告（受入れ） パッケージソフトウェア利用コンピュータシステム構築委託契約書 重要事項説明書 J保守契 約：準委任・(14)(21) (25)(41)適用、K運用支援 契約 ：準委任、(42)適用) (33)データ移行 (34) 完了報告(受入れ） (30) 構築業務 （機器・OS等の設定、納品） (32) 検収(受入れ） ※ベンダ主体 ※ユーザ主体／ベンダ支援 E ソフトウェア設計・制作契約 F 構築・設定業務契約 G データ移行支援契約 I 導入教育支援契約 H 運用テスト支援契約 J 保守契約 K 運用支援契約 (13) 受入れ (18) 受入れ ■参照すべき規格：共通フレーム2013「2.1 企画プロセス」・「2.2 要件定義 プロセス」、JIS Q 20000 情報技術－サービスマネジメント、JIS Q 27001 情報技術－セキュリティ技術 テ システム ■チェックリスト：コンサルタントチェックリスト、セキュリティチェックリスト ■参照すべき規格：共通フレーム2013「2.2. 要件の 」・「2.3 システム開発プロセス」・「 .6 監査プロセス」、JIS Q 27001情報技術－セキュリティ技術 テ システ ム ■チェックリスト：RFPチェックリスト、パッケージ選定チェックリスト、SaaS/ASP選定チェックリスト ■参照すべき規格：共通フレーム2013 「3.1 運用プロセス」・「2.6 保守プロセス」、 JIS X 0129-1 7.1 利用時の品質、JIS X 0161 ソフ ス ■チェックリスト：検収チェックリスト パッケージソフトウェア、OS、第三者ソフトウェアの使用許諾契約 パッケージソフト、OS、第三者ソフトの使用許諾契約の検討 （制限事項、保守、バージョンアップ等） 選定したパッケージソフト、OS、第三 者ソフトの使用許諾契約の締結及び 必要に応じて保守契約の締結*1 選定したパッケージソフト、OS、第 三者ソフトの使用許諾契約の締結 及び必要に応じて保守契約の締結 *1 パッケージソフトウェアの使用許諾契約及び保守は、開 発に入る段階で締結するのが一般的であるが、APIの実現 性の確認、又は外部設計で、使用許諾契約、保守契約を 締結しなければならない製品がある。使用許諾契約、保守 契約の開始については(10)で事前に検討が必要である。 *2 システム規模と要件によって見積は概算もしくは詳細に なる。 (21) 使用許諾によってはパッケージ、 OS、ハードの導入及び保守の開始 （一部保守開始 *1） (31) システム結合、テスト Bパッケージソフトウェア選定支援 及び要件定義支援契約 D 外部設計支援契約 (14) 使用許諾によってはパッケー ジ、OS、ハードの導入及び保守の 開始（一部保守開始 *1） (24) ユーザへの見積提出 (35) 運用に関わる作業手 順の確立 IPA, 「情報システム・モデル取 引・契約書」第二版, 2020 ここだけ
- 38. 上流工程のレビュー n設計審査（デザインレビュー） • 上流工程の設計に関するレビュー • 成果物（仕様書）のチェック • 要件定義書のレビュー • 外部設計書のレビュー • 内部設計書のレビュー • タイプ • 顧客による設計の審査と承認 • 上位管理者（上司）による審査 と承認 • 第三者（コンサル）による評価 と問題点の洗い出し n 参考 • 定量的品質予測のススメ 〜ITシステム開 発における品質予測の実践的アプローチ〜, IPA, 2008 • 続 定量的品質予測のススメ 〜ITシステム 開発における定量的品質管理の導入ノウハ ウと上流工程へのアプローチ〜, IPA, 2011 • ソフトウェア開発データが語るメッセージ 「設計レビュー・要件定義強化のススメ」, IPA, 2017 • レビューの質の向上〜 幸せのレビュー目 指して〜, 財団法人日本科学技術連盟, 2012ソフトウェア品質保証部長の会2G, 2012 • レビューの質と価値の定量化の提案,一般 財団法人 日本科学技術連盟 SQiP研究会担 当, 2011
- 39. 上流工程のレビューの実際 定量的品質予測のススメ 〜ITシステム開発における品質予測の実践的アプローチ〜, IPA, 2008 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html n要求分析にもレビューは必要 n基本設計にもレビューが必要 • レビューで数千件の指摘がある 指摘は平均25件/KSLOC （中央値は2.5件/KSLOCだけど） 指摘250件 指摘2500件
- 40. コードレビュー nコードレビュー • 開発工程でのコードのレビュー • 目的 • 不具合の発見と修正 • メンバー間の理解とコミュニケーションの促 進，ノウハウの共有 • リスクと開発状況の把握 • 評価者 • レビューする人：レビュアー（reviewer） • レビューされる人：レビュイー（reviewee） • ピアレビュー：ピア（peer，同僚）によるレ ビュー • レビュアーにもレビュイーにもなる https://pixabay.com/photos/people-looking-in-laptop-5069842/ Pixabay license reviewer reviewee reviewer
- 41. コードレビュー n方法 • ウォークスルー：短時間での複数人チェック． フランク．短時間．何度も行う • インスペクション：公式．参加者の役割が明 確．フォーマル．長時間，回数は少ない • パスアラウンド：成果物を個別に送付．対面 ではない． https://pixabay.com/photos/work-typing-computer-notebook-731198/ Pixabay license
- 42. コードレビューの方法 n標準 • Googleが公開している基準がよく使われる https://google.github.io/eng-practices/review/reviewer/ https://github.com/google/eng-practices Google's Engineering Practices Documentation Japanese Translation https://shuuji3.xyz/eng-practices/review/
- 43. コードレビューの方法 nコードレビューで確認すること • コードはよく設計されているか • 機能がユーザーにとって良いもので あるか • UIの変更が賢明で見栄えが良いか • 並列プログラミングが安全に行われ ているか • コードが必要以上に複雑になってい ないか • 開発者は，将来的に必要になるかも しれないが，今は必要かどうか分か らないものを実装していないか • コードには適切なユニットテストが あるか • テストはよく設計されているか • 開発者はすべてに明確な名前を使っ ているか • コメントは明確で有用であり，「何 をする」ではなく「なぜするのか」 を説明しているか • コードは適切に文書化されているか （通常は g3doc） • コードがスタイルガイドに準拠して いるか nコーディング規約も重要 https://google.github.io/eng-practices/review/reviewer/ https://github.com/google/eng-practices
- 45. その他の話題
- 46. 著作権（copyright） nコードのコピペは著作権侵害 • ソースコードにも著作権がある • その他 • HTMLファイル，設定ファイル，etc • 要件定義書，外部仕様書，外部設計書，etc nどこまでが侵害か？ • 「表現が創意工夫があること」 • 誰が書いても同じものになるようなものに著作権はない int main(void){ int i; for(i = 0; i < 10; i++){ printf("hello world"); } return 0; }
- 47. ライセンス nフリーのソフトやコードにもライセンスはある • 無料・無断で使用してよいのは，ライセンスに明記された範囲でのみ nソースコードが一般公開されているソフトウェア • オープンソース（OSS, Open Source Software） • 商用利用OKが多い，各種条件あり nOSSライセンスのおもな種類 • GPL，LGPL • ソース公開が利用条件（copyleft） • MIT，BSD，Apacheライセンス， MPL • Public Domain (PD)，Creative Commons (CC)，etc • 補足 • 個人で遊ぶなら気にしなくても • ビジネスで組み込むなら考慮は必須 Choose an open source license CC BY 3.0 この画像のライセ ンスはCC-BY 3.0
- 49. ライセンス nよくある問題 • 研究・教育用はOK • 商用利用は要問い合わせ • ダメなときもある n深層学習時代の問題 • コードだけでなくデータセット にもライセンスがある http://www.uco.es/investiga/grupos/ ava/node/26 ArUco: a minimal library for Augmented Reality applications based on OpenCV https://image-net.org/about.php About ImageNet https://cocodataset.org/#termsofuse COCO Dataset
- 50. 生成系AI時代の「データの権利」 n 画像AIの種類 • 解析系AI：画像認識や音声認識．データ自体は表に出 なかった • 生成系AI：画像や文章の生成．データ自体が表舞台に 登場することになる n 「データセット」のライセンス • 頑張って収集した「データセット」を使って良いか • LAION-5BはCC-BY 4.0なので誰でも商用利用可 • 画像生成AI「Stable Diffusion」などの開発に大きな貢献を果たした超巨大データセット「LAION-5B」とは？, 2022/12/14, Gigazine n 「データ」の権利 • 収集された個々の「データ」を作成した個人には許 可をとってない • 画像生成AIは新たなアート？ それとも著作権侵害？ 最前線に迫る, 2023/3/30, NHK国際ニュースナビ • 文章・画像生成AIは著作権侵害か 訴訟に発展も, 2023/2/7, ウォールストリート・ジャーナル • 無断でダウンロードしたデータでもAI開発に使える？ 改正著作権法を弁護士が解説, 2019/3/29, @IT • 現状日本では合法（2019年著作権法改正第30条の4） まるで人間のアーティストが描いたような画像を生成するAIが「アーティストの権利 を侵害している」と批判される, 2022年08月15日 https://gigazine.net/news/20220815-stable-diffusion-controversy-ai-infringes-artists/
- 51. 特許 nアルゴリズムが特許にあったら無断使用はダメ • 特許保有者とのライセンス契約が必要 • フリーでコードが公開されていても特許に抵触することはある • 例：GIFファイルには特許問題があった（現在は期限切れでOK） • 知らずに利用すると，意図せず特許侵害で訴えられる可能性がある • 多額の賠償金を請求してくるパテント・トロールに注意 n特許と著作権 • 著作権：申請不要．だれでも著作者．表現に対して著作権が発生． • 同内容を自分なりの表現で再現するなら問題なし • 特許権：申請必要．審査あり．アルゴリズム・アイデアに対して特許権が発生 • 自分なりに再現してもアイデアが同じなら特許侵害 n知的財産権 • 特許権や商標権，意匠権などを含む広い所有権を指す