Mais conteúdo relacionado Semelhante a LiBRA 10.2020 / 開発と運用 (20) Mais de Masanori Saito (20) LiBRA 10.2020 / 開発と運用9. アジャイル・DevOps・クラウドは常識の大転換
構築 運用 構築 運用
構築・運用サイクル:5年~
業務要件:変えられない/計画通りが前提
要求水準:高品質/完璧
責任分担:要求(事業会社)/その他全て(SI事業者)
サーバー
ストレージ
ネットワーク
HWや設備を調達
システム構築・運用
一連の業務を外注
所有+構築・運用
指示・外注が前提
従来のやり方(建築工事と保守点検)
設計・実行サイクル:分/時間/日
業務要件:変える/計画通りは無理が前提
要求水準:高速にアップデートし品質を維持
責任分担:全て(事業会社)/支援(外部事業者)
機能部品の組合せ
手順の設計と実行
自分が責任・主管
使用+設計・実行
自前・内製が前提
これからのやり方(賃貸やレンタカー)
クラウドには
預ける・載せる・任せる発想はない
アウトソーシングではない
借りて、自分で使いこなす発想が必要
16. 差し迫るSI/SES事業の限界
SI/SES事業の収益モデルが限界
技術力を伴わない工数ビジネスは利益が出なくなる
物販は収益を下支えできなくなる
何も手を打たなければ優秀な人材の流出が拡大する
事業会社におけるITの本業化
外注対象の限定と内製化の拡大
ウォーターフォール型開発の限界
ITの評価基準がコストから投資へ転換
ウォーターフォール開発×オンプレミス×開発・運用業務委託の限界
アジャイル開発
Agile Development
ビジネスの成果に貢献するコードだけを
変更に柔軟・迅速に対応して
バグフリーで提供する
DevOps
Development & Operation
運用の安定を維持しながら
本番環境への迅速な移行と
継続的デリバリー
クラウド
Cloud Computing
高速で俊敏な開発実行環境の調達
経費化の拡大による不確実性への担保
運用やセキュリティから解放と人材の再配置
現
場
に
ジ
ャ
ス
ト
イ
ン
タ
イ
ム
で
I
T
サ
ー
ビ
ス
を
提
供
す
る
17. ITのスピードが高速化
ITのスピードにビジネス・プロセスが追いつかない
全ての組織がサービス・プロバイダー化する
どの様にITサービスを提供し維持するのか
Value-driven (価値主導)
Evolving(発展、展開する)
Responsive(敏感に反応する)
Integrated(統合、結合された)
Service(サービス)
Management(マネジメント)
企業レベルでサービス管理を行うための運用モデル
VeriSM
17
アジャイル開発
Agile Development
ビジネスの成果に貢献するコードだけを
変更に柔軟・迅速に対応して
バグフリーで提供する
DevOps
Development & Operation
運用の安定を維持しながら
本番環境への迅速な移行と
継続的デリバリー
クラウド
Cloud Computing
高速で俊敏な開発実行環境の調達
経費化の拡大による不確実性への担保
運用やセキュリティから解放と人材の再配置
18. 不確実性のコーン
18
システム企画 要件定義 基本設計 詳細設計 プログラミング
4.0x
2.0x
1.0x
0.5x
0.25x
初期の
プロダクト定義
承認された
プロダクト定義
設計仕様 詳細設計 研修された
ソフトウエア
要求仕様
見
積
金
額
の
変
動
幅
プロジェクトフェーズ
スティーブ・マコネル著「ソフトウェア見積り 人月の暗黙知を解き明かす」
倍
の
振
れ
幅
16
27. QAの体制、手法を強化すれば品質が上がるのか?
1000行当たりのバグの発生率を管理する意味? (統計的品質管理)
そもそもバグとは品質の問題? (不良作業)
優秀なプロジェクト管理者を配置すれば上手く行くのか?
コンテンジェンシーを見込めば、リスクが軽減するのか?
アジャイル開発とは
PMBoKに沿ってプロジェクトを推進すれば上手く行くのか?
品質は結果ではなく
過程(プロセス)
管理者の役割は
開発者の障害を
取り除くこと
納期と品質はトレードオフ
だから品質を優先し
納期優先で開発機能数
を絞り込む
全部作らない代わりに使う機能だけをバグフリー・予算内で・納期通り作る開発の考え方
アジャイル開発
29. アジャイル宣言の背後にある原則
29
私たちは以下の原則に従う:顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最
適に調整します。
33. ウォーターフォールとアジャイルの違い その1
用意されたプロセスやツール
全てを網羅したドキュメント
お互いの妥協点を探る契約交渉
一度決めた仕様や計画に従うこと
システムを納品すること
計画通りに完成させること
「計画通り」が正義という信念
自律的な判断と行動
実際に使う動くソフトウェア
顧客との対話と協調
変更や変化への柔軟な対応
ITサービスを提供すること
ビジネスを成功させること
「計画通り」は無理という現実
34. ウォーターフォールとアジャイルの違い その2
ユーザーと開発者はプロジェクトを通して、日々一緒
に働く
ユーザの満足を優先し価値あるソフトウェアを早く継
続的に提供する
要求の変更はたとえ開発の後期であっても歓迎する
動くソフトウェアをできるだけ短い間隔( 2~3週間
あるいは2~3ヶ月)でリリースする
動くソフトウェアこそ進捗の最も重要な尺度
技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
シンプル(無駄なく作れる量)に作ることが基本
最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
チームが最も効率を高めることができるかを定期的に
振り返り、それに基づいて自分たちのやり方を最適に
調整する
アジャイルな思想
ユーザと開発者はいつもは別の場所にいてプロジェク
トを通して定例ミーティングを行う
ユーザーの満足や価値のあるなしではなく、とにかく
ソフトウェアを提供する
要求の変更を開発の後期に出すの勘弁して欲しい
パワポ、エクセル、ワードの仕様書を丁寧に清書して
( 2~3週間あるいは2~3ヶ月)納品する
動くソフトウェアこそ進捗の最も重要な尺度
技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
仕様書通り(間違っていようが)に作ることが基本
最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
チームがもっと稼働率を高めるように監視し、それに
基づいて自分たちへの批判や不満を回避するために、
念のため納期を厳しめに設定する
ウォーターフォールな思想
https://speakerdeck.com/kawaguti/flipped-agile-manifestYasunobu Kawaguchi氏 資料を参考に作成
41. アジャイル開発の目的・理念・手法
41
高品質で無駄がなく、変更要求に対応できるきるソフトウエアを作成する為
適切な一連の手順に従う
高い協調と自律的なプロジェクト関係者によって実施される
イタラティブ(反復/周期)、インクリメンタル(順次増加部分を積み上げていく)方式
ダイナミックシステムズ開発技法(Dynamic Systems Development Method) Dane Faulknerほか
アダプティブソフトウェア開発(Adaptive Software Development) Jim Highsmith
クリスタルメソッド(Crystal Methods) Alistair Cockburn)
スクラム(Scrum) Ken Schwaber、Jeff Sutherland
エクストリームプログラミング(XP/eXtreme Programing) Kent Beck、Eric Gammaほか
リーンソフトウェア開発(Lean Software Development) Tom and Mary Poppendieck
フィーチャ駆動開発(Feature-Driven Development) Peter Code、Jeff DeLuca
アジャイル統一プロセス(Agile Unified Process) Scott Ambler
反復(周期)的(Iterative) --- 定期的なリリース
漸進的(Incremental) --- 徐々に機能を増加
適応主義(Adaptive) --- 変化に対応(即応)
自律的(Self-Organized) --- 学習する組織
多能工(Cell Production) --- 一人多役(SE、プログラマー、テスター)
目的と理念
手 法
共通する要素
43. アジャイル開発の系譜
43
TPS
Toyota Production System
Total-TPS TMS
Total Management System
直接の製造部門中心
の考え方
製造工場の間接部門迄範
囲を広げた考え方
本社組織等の非製造部門迄範
囲を広げた考え方
Agile dev. Scrum
TOC
(E. M. Goldratt)
Lean
KANBAN
Lean Software
Development
ムダ取り、カイゼン
を中心にしたアプ
ローチ
整流化(流れ)中心
JIT、カイゼンの考え
SURIAWASE
Software
Development
TMS(トータル・マネジメント・
システム)の概念を取り入れた、
確実に効果を得られるプロジェク
ト管理手法で、
大規模開発も考慮されたスクラム
を基本としたプロジェクト運営
TPSから派生した欧米での概念、手法
個
別
手
法
の
採
用
トータルTPS、TMSの概念、管理手
法の採用
44. スクラム:特徴・3本の柱・基本的考え方
44
システム開発のフレームワーク(1995)/ Ken Schwaber & Jeff Sutherland
特徴
軽量
理解しやすい(シンプル)
会得するのは比較的難しい
三本の柱
Transparency (透明性)
Inspection (視察、検査)
Adaptation (適応、順応、改作)
基本的考え方
タイム・ボックス(Time Box)
時間を区切って、その時間内に目的を果たす仕事を行う仕事の仕方
機能横断的な固定化されたチーム
チーム内で役割分担を決めず、全員が必要な仕事をこなす多能工(T型人間のチームででき
るだけチームメ ンバーを固定化した方がよい
持続可能なペース
徹夜や残業を排除して安定した持続可能な一定のペースで開発し、定期的にリリースを行う
45. スクラム:スクラム・プロセス
45
イテレーション(反復) 4
1~4週間
イテレーション(反復) 3
1~4週間
イテレーション(反復) 2
1~4週間
イテレーション(反復) 1
1~4週間
納品 納品 納品 納品
プロダクト・オーナー
プロダクト・バックログ
1. --------------------
2. --------------------
3. --------------------
4. --------------------
5. --------------------
6. --------------------
スプリント・プラン
イテレーション毎の
内容区分
2時間程度の単位
スクラム・マスター
タスク・リスト
スプリント・バックログ
1. --------------------
2. --------------------
3. --------------------
4. --------------------
5. --------------------
開発チーム
バーンダウン
チャート
デイリー
スクラム
開発・テスト
インテグレーション
To Do On Going Done Keep
Problem
Try
スタンドアップミーティング & スプリント・レビュー・振り返り
46. スクラム:プロダクト・オーナー
46
ミッションと責任
プロダクトの完成図と方向性を示す
プロダクトに必要な機能の詳細を決める
リリースの内容と日程を決める
市場価値に基づくプロダクト・パックログの優先順位を決める
スプリント毎に優先順位を変更できる権限を持つ
プロダクトの収益性(ROI)の責任を持つ
プロダクト・オーナーが行う事
プロダクトのビジョンを作成し、関係者に示し、共有する
対象プロダクトのビジネス要求(ビジネス環境)の説明
エピック、ユーザーストーリーの確定とペルソナの作成
ユーザーストーリー毎の受け入れ基準の承認
プロダクト・バックログの優先順位付けとプロジェクト期間中の維持管理
開発チームへのユーザーストーリーの説明
開発チームのDoD(完了の定義)作成の支援
リリース計画の承認
稼働環境の定義
EOL(プロダクトの終焉)条件の設定
48. スクラム:開発チーム
48
自己組織的なチームである
自律性
メンバーが自ら日々の仕事を管理する
自己超越
常に目標を達成するように自らを追い込み、常に自身のプラクティスを改善する
相互交換作用
機能横断的かつ定めた役割がない
目標にコミットする義務がある
チームはスプリント計画ミーティングでコミットした目標を達成する責 任
を持つ
目標達成につながるならば方法を限定しない
チームは全ての決断を下す権限、必要なことを何でも行う権限、あらゆる障
害の除去を依頼する権限を持つ
争議はチーム内で解決する
作業規約を作る
49. エクストリーム・プログラミング(XP)
49
テスト駆動開発(Test-Driven Development:TDD)=テストファース
ト・プログラミング
実装する機能をテストするプログラムを書く
コードを書いてテストする
デザインを見直す
信号が青になる(テスト・コードが成功する)まで繰り返す
リファクタリング
完成したコードの見直し(実装された機能を変えずに、コードをシンプルに、
見やすくする)
任意の作業(全員が行う&時間が空いたら行う)
ペアプログラミング
ドライバー(コードを書く人)
ナビゲーター(コードをチェックする人、ナビゲーションをする人)
この役割を1日の中でペア間で、途中で交代する
ペアの組み合わせを毎日替える
10分間ビルド
自動的にシステム全体をビルドして、全てのテストを10分以内に実行させる
Kent Beck(1999年)によって提唱された開発手法
51. アジャイル開発で品質が向上する理由
51
タスクの粒度を小さくすることはTPSにおける小ロット化と同様
「流れ」を作り、負荷を平準化し、柔軟性を高める
タスクの粒度は小さいほど良い
1日以内、理想は1時間
責任を持って見積ができる
バグを作り込まない(簡単にテスト可能)
他のペアと同期がとれる
ダイナミックなプロジェクト運営が可能となる(チーム編成の増減、分散開発など)
タスクが小さくできないのは、作業対象の内容把握に問題が存在するのではないか?
タスクを小さく分割するという事は、作業指示書を作成する事。
Statements of Source
code
Test Cases Test Coverage
1 1 100.00%
10 2 100.00%
100 5 95.00%
1,000 15 75.00%
10,000 250 50.00%
100,000 4,000 35.00%
1,000,000 50,000 25.00%
10,000,000 350,000 15.00%
Application size, Test Cases, and Test Coverage. Logical source code statements
By Caper Jones
52. DoD (Definition of Done) 完了の定義
52
各作業の完了基準
閾値(標準値)を決める。
作業経過、結果を計測する。
自工程完結の基本的な姿勢(現場での意思決定)
仁=他人の努力を無駄にしない思いやり
検
査
検
査
検
査
発生防止
流出防止
プロセス プロセス プロセス 検
査
納入
検査 検査 検査
DoD
54. ビジネス 開発 運用
アジャイル開発 DevOps
アプリケーション開発環境
マイクロ・サービス、ルールエンジン、AI、APIなど
ITインフラストラクチャー
IaaSなどのクラウド
アプリケーション実行環境
コンテナ・オーケストレーション・ツール
サーバーレス・FaaS
Infrastructure as Code
運用の自動化
SRE
Site Reliability Engineer
アイデアの創発
デザイン思考
リーンスタートアップ
トライ・アンド・エラー
のサイクルを高速で回す
ビジネス・スピードを加速する方法
ビジネスの成果に貢献するコードのみ
現場のニーズにジャストインタイム
バグフリーと変更への迅速・柔軟な対応
開発されたコードを直ちに本番移行
安定稼働の維持
変更やスケールへの迅速・柔軟な対応
58. DevOpsとは何か?
58
お互いを尊重する(Respect):
一緒に働く相手のことを心から思いやる、相手を一人の人間として扱い、能力や功績を評価する
お互いを信頼する(Trust):
自分以外の人は優秀で、正しいことをすると信じる。信じて仕事を任せる
失敗に対して健全な態度を取る(Healthy attitude about failure):
新しいことに挑戦すれば自ずと失敗は起こってしまうものであり、相手のミスだと責めない
相手を非難しない(Avoiding Blame):
相手に非があると断じて言葉で責めるのではなく、次に同じ問題が起こらないように建設的な批判を行う
自動化されたインフラストラクチャ(Automated infrastructure):
インフラの構築を自動化する。よく使われているツールにはAnsibleやChef、Dockerなどがある
バージョン管理システムの共有(Shared version control):
GitやMercurialなどの同じバージョン管理システムをDevとOpsで共有する
ワンステップによるビルドとデプロイ(One step build and deploy):
手順書などを使い、手動でビルドやデプロイをするのではなく、ビルドやデプロイを自動化する。よく使われているツールや
サービスにはJenkinsやCapistranoなどがある
フィーチャーフラグ(Feature flags):
詳細は後述のコラムで説明。コード中の機能の有効/無効を設定ファイルで管理する
メトリクスの共有(Shared metrics) :
取得したメトリクスの結果をダッシュボードでお互いに共有する。よく使われているサービスにはNew RelicやApplication
Insightsなどがある
IRCとインスタントメッセンジャーのBot(IRC and IM robots):
SlackやHipChatなどのチャットツールに自動的にビルドやデプロイのログ、アラート内容を投稿する仕組みを
作ることで情報をお互いに共有する
ツ
ー
ル
組
織
文
化
改善
68. DockerとKubernetes の関係
68
コンテナの作成
コンテナの実行
コンテナ内でファイルシステ
ムとして使われるイメージの
作成および管理 など
関連するコンテナのグルーピング
コンテナに割り振られるIPアドレスの管理
コンテナ間ネットワークルーティング管理
複数のコンテナを利用した負荷分散
コンテナに割り当てるストレージの管理
コンテナの監視 など
ネットワークのルーティングや複数コンテナの
連携、複数台のサーバーを対象にコンテナを横
断的に管理する機能などは提供されていない。
クラスタ環境でDockerを利用する場合は別途何らかの管理手法を用意する必要がある。
Dockerと連携して利用できるデプロイ/オーケストレーションツールのひとつ
By Google
Manage a cluster of Linux containers as a single
system to accelerate Dev and simplify Ops.
Linuxコンテナのクラスタを単一のシステムとして管理して
開発を加速し、運用を簡素化します。
意味:ギリシャ語で「人生の道標」
読み方:クーベルネイテス(koo-ber-nay'-tace)
69. Twelve Factorsとの関係
69
Ⅰ. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
Ⅱ. 依存関係
依存関係を明示的に宣言し分離する
Ⅲ. 設定
設定を環境変数に格納する
Ⅳ. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
Ⅴ. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
Ⅵ. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
Ⅶ. ポートバインディング
ポートバインディングを通してサービスを公開する
Ⅷ. 並行性
プロセスモデルによってスケールアウトする
Ⅸ. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
Ⅹ. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
Ⅺ. ログ
ログをイベントストリームとして扱う
Ⅻ. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
アジリティーの高いWebサービスを構築するための方法論
コンテナ Kubernetes
https://12factor.net/ja/
75. マイクロサービス・アーキテクチャの6つのメリット
修正
修正
リリースの同期は必須 個別にリリース可能
Java Java Java
Java Java Java
Java Ruby php
C++
Java
Script
C#
言語は統一 機能にふさわしい言語を選択
影響? 影響? 影響?
影響? 変更 影響?
一部機能変更・全体テスト 一部機能変更・対象機能のみテスト
変更
全体で拡張 個別に拡張
正常 正常 正常
正常 障害 正常
正常 正常 正常
正常 障害 正常
一部障害で全体停止 一部障害でも正常箇所は稼働
流用 流用
特定の機能流用は困難 特定機能の流用は容易
1.機能の独立性
2.言語の独立性
3.保守の容易性
4.拡張の柔軟性
5.障害時の可用性
6.再利用の容易性
「これなら分かる! マイクロサービス(入門編)~モノリスと比較した特徴、利点と課題(CodeZin)」を参考に作成
78. Version 1.3Version 2.0 Version 1.5 Version 1.4
エンジニアの役割分担
78
ITインフラ ITインフラ ITインフラ ITインフラ
開発エンジニア 開発エンジニア
SRE
テスト・エンジニア
マイクロ・サービス×コンテナによる独立したプロセス
クラウド・ベースでの
組織横断的な仕組み作り
80. クラウド・サービスの区分
自社所有 IaaS
仮想マシン
CaaS PaaS FaaS
ユーザー企業が管理
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
SaaS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
IaaS
ベアメタル
クラウドサービス事業者が管理
連携機能
CaaS PaaS FaaS SaaS
97. ローコード開発ツール
97
要件定義 概要設計 詳細設計 単体テスト 結合テス
ト
プログラミング 結合テスト
従来型
開 発
要件定義 運用・保守
(高速化・効率化)
結 合
テスト
ローコード
開 発 ローコード開発
人手による作業
ツールによる
自動化
プログラム生成型
統合環境型
プラットフォーム型
画面や業務ロジック、データ構造などセグメント
毎に機能が独立
アプリケーション層よりも上位に特化、システム
を統一的に構築、抽象化モデルを使いGUIで開発
システム開発だけではなく、ライフサイクル全体
を統一的に管理・支援
NTTデータ・TERASOLUNA
NEC・SytemDirector Enterprise
FUJITSU・Software Interdevelop Designer
など
GeneXus
キヤノンITS・Web Performer
住友電工情報システム・楽々Framework3
ジャスミンソフト・Wagby
SCSK・FastAPP
など
OutSystems
ServiceNow
Mendix AppPlatform
サイボウズ・kintone
Microsoft PowerApp/Datahlex
Salesforce・Lightning Platform
AWS・Honeycode
Google・AppSheet
など
運用・保守
98. 自動生成
ローコード開発ツールの 基本的な構造
98
要件定義 概要設計 詳細設計 単体テスト 結合テス
ト
プログラミング 結合テスト
設 計
リポジトリ
画 面
業 務
ロジック
データ
構 造
アプリケーション
データベース
運用・保守
アプリケーション
実行基盤
運用管理
ツール
運 用
レポート
プラットフォーム型 ローコード開発ツール
人手による
作業
ツールによる自動化
GUI
画面・業務ロジック
・データ構造を管理
クラウド・サービス
オンプレミス
108. オープンソース開発の実際
2008.4.2 付け ITpro
Linux推進団体のLinux Foundationは米国時間2008年4月1日,Linuxカーネルの開発について調査した結果を発表した。
それによると,過去3年間でカーネルの開発に携わる開発者数は3倍に増えており,サポート企業も増加しているという。
今回のレポートは,カーネル2.6.11~2.6.24までの約3年間の統計をまとめたもの。Linuxカーネルの開発には,100社を
超える企業に所属する1000人近い開発者が関わっているという。レポートでは,2005年以降カーネル開発者数が3倍に増
えた理由として,組み込みシステム,サーバー,デスクトップ市場におけるLinuxの重要性が増したことを受け挙げている。
カーネルの開発に携わる開発者の70~95%は,開発作業に対して支払いを受けている。カーネルへのコントリビューショ
ンの70%以上は,米 Red Hat,米Novell,米IBM,米Intelなどに勤務する開発者によって提供されたものだった。これらの企
業は,カーネルを向上させることで,市場における競争力が得られると考えているという。また,加えられた変更の13.9%
は企業に属さない個人開発者によるものだった。
開発ペースについては,1日平均3621行のコードがカーネル・ツリーに追加されており,ほぼ2.7カ月ごとに新しいカーネ
ルがリリースされているという。 」
http://itpro.nikkeibp.co.jp/article/Research/20080402/297751/
「Linux カーネルの開発に携わる
開発者の70~95%は,開発作業
に対して支払いを受けている。」
という事実
Linux ビジネスを手がける企業
が資金を提供してコミュニティ
を維持しているということ
=
開発の実体は商用ソフトと変
わりがないとも言える
113. FLOSS (Free/Libre and Open Source Software)
FOSS (Free/Open Source Software)
2つのオープンソース
「元祖」オープンソース
オープンであることが「目的」のオープンソース
ビジネスに使えるオープンソース
オープンであることが「メリット」になるオープンソース
フリーソフトウェア
Free Software
「自由」なソフトウェア
オープンソースソフトウェア
Open Source Software
ソースを公開している
ソフトウェア
再配布条件が厳しい 再配布条件が緩い
120. ITにおける「オープン」の変遷
IBM System/360
Apple II
IBM PC
Free Software
Open Source Software
Open Source Hardware
1960
1970
1980
1990
2000
2010
アーキテクチャの公開
回路図/OS APIの公開
ソースコードの公開
HWのファミリー化
周辺機器/SWの互換性確保
サードパーティの活用
・周辺機器
・アプリーケーション
ベンダーロックインの回避
開発効率の向上
ソフトウェアの民主化
設計情報の公開 コスト削減
互換機の誕生
新しいビジネスモデ
ルの誕生
Open Cloud OSSのクラウドインフラ インフラの標準化
Open Data 官公庁データの公開 ビッグデータの無償利用
UNIX
ソース公開
(独禁法による販売禁止)
研究機関での普及
分散した共同開発
互換機の誕生とPC
事業らの撤退
世界中で機能拡
張・バグ修正
豊富な周辺機器・
アプリケーション