SlideShare una empresa de Scribd logo
1 de 136
最新のITトレンドとビジネス戦略
開発と運用編
2021年10月版
ご案内
2
知識の定着は、ネットを眺め、資料を読むだけでは不十分です。実際に第三者
を相手に自分の言葉で説明してみるのが最も効果的です。
また、本プレゼンテーションは、ロイヤリティ・フリーです。ご自身の資料と
して、加工編集して頂いても構いません。
知識の確かな定着と仕事の生産性向上のために、ご活用下さい。
ネットコマース株式会社
斎藤昌義
http://libra.netcommerce.co.jp/
最新のアップデートは、「ITビジネス・プレゼンテーション・ライブラリー/LiBRA」にて随時更新しております。
アジャイル開発とDevOps
システムの開発と運用とは
システム
開発
Development
アプリケーション
を実行可能にする
こと
 アプリケーショ
ンを企画設計し
プログラムを作
ること。
 最適な技術を目
利きし、その適
用方法を決める
こと
 アプリケーショ
ンを動かすため
の仕組み(プ
ラットフォーム
とインフラ)を
整えること
システム
運用
Operation
アプリケーション
やプラットフォー
ムとインフラを安
定して動かし続け
ること
 稼働状況やトラブ
ルの監視
 万が一のための
バックアップや復
旧(リカバリー)、
安定稼働のための
改善など
 ユーザーからの問
い合わせやトラブ
ル対応に対処する
こと
インフラストラクチャー
サーバー、ストレージ、データセンターなどのハードウェアや設備
プラットフォーム
データ管理、セキュリティ管理、通信、ハードウェア制御、決済などの共通機能
アプリケーション
会計管理、販売管理、オンライン・サービスなどの
業務成果を生みだすソフトウェア/プログラム
開発や実行のための環境の整備
プログラミング・テスト
概要設計・詳細設計
企 画
システム化の対象範囲
レベルD
存在しない
レベルC
初期段階
レベルB
反復可能だが直感的
レベルA
標準プロセスが定義されている
レベルAA
管理が行き届き測定可能
レベルAAA
最適化されている
Source: Capability Maturity Model Integration, CMMI
システム化
の対象範囲
システム化
の対象範囲外
改善の4原則:ECRS
Eliminate
排除
Combine
統合
Rearrange
交換
Simplify
簡素化
業務の目的を見直し
なくすことを考える
業務をまとめることで
効率化できるかを考える
順序を入れ替えることで
効率化できるかを考える
省力化しても同じ結果が
得られるかを考える
旧来のテクノロジーを前提とした習慣化したプロセス 新しいテクノロジーを前提に再定義したプロセス
+デジタル
ITの役割分担
ストラテジック
アプリケーション
コモディティ
アプリケーション
コア・アプリケーション
デジタル・プラットフォーム
機械学習・ブロックチェーン・IoTなど
ERP・SCM
電子メール
オフィスツール
経費処理
経費精算
スケジュール
ファイル共有
プロジェクト管理など
デザイン思考
リーンスタートアップ
常に最新
メンテナンス・フリー
エコシステム
事業戦略に直結
ジャストインタイム
事業の成果に貢献 クラウド・サービス
を採用
内製チームで開発
アジャイル開発×DevOps
システム構築事例 :オンライン・サービス事業者
財務会計・人事
Netsuite
管理会計
Tableau
勤怠・給与
e-Pay
経費精算
Concur
連結会計
Diva
人事ダッシュボー
ド
QlicView
考課・目標管理
Cydas
KPI管理
内製
作画・共有
Cacoo
情報共有
Quita
進捗管理
Tollelo
開発ソース管理
GitHub
開発案件管理
Jira
開発情報Wiki
Confluence
ファイル共有
Box
シングル
サインオン
Okta
メール
G Suite
チャット
Slack
無人受付
Smart at
ワークフロー
kintone
名刺管理
sansan
マーケティング
Marketo
基幹業務
システム開発 コミュニケーション その他
クラウド
SaaS
オンプレミス
パッケージ
オンプレミス
内製
作らない技術を前提としたシステム
自動車の
配車サービス
地図情報 代金決済
セキュリティ
ID認証 損害保険
マイクロサービス、REST/AP|I
クラウド・サービス
クルマと人
マッチング
ITの変化とビジネス対応
オープンソース・ソフトウェア
クラウド
サービス
OSS
差別化するための
独自性の高い
プログラム
ITサービスを
短期間に実現する
事業の成果に貢献する
事業の売上や利益の増加
できるだけ作らずに短期間でITサービスを実現する
「作る技術」から「作らない技術」へ
作る技術 作らない技術
仕様書に定められた機能を実装すること
を目的に、丁寧に手間を掛けて、QCDを
守って、プログラムを作る技術
ビジネス成果の達成を目的に、既存のIT
サービスを駆使し、できるだけ作らずに
短期間でITサービスを実現する技術
ビジネス目的:工数を売る
組織力を駆使して、作る技術を持つエン
ジニアをできるだけ多く動員し、工数を
最大化して、売上規模を拡大すること
ビジネス目的:技術力を売る
作らない技術力を持つ個人やチームをお
客様の事業の成果に見合う金額で提供し
て、高い利益率を継続的に確保すること
エンジニアの役割:
お客様をインタビューして、要件を定義
し、WBSに従って進捗を管理するPMや
仕様書に従ってコードを書くエンジニア
エンジニアの役割:
お客様と事業の目的とビジョンを共有し、
ITサービスを提供するための障害を排除
し、お膳立てを整えるスクラムマスター
と、既存のサービスや技術を自分たちで
目利きし、最速最短でビジネスの成果に
供するITサービスを実現するエンジニア
作らない技術のスタック
アジャイル開発
Agile Development
 ビジネスの成果に貢献するコードだけ
 変更に柔軟・迅速に対応
 バグフリーで提供
DevOps
Development & Operation
 運用の安定を維持
 本番環境への迅速な移行
 高速な改善
クラウド
Cloud Computing
 最新の機能やリソースの調達
 経費化による不確実性への担保
 構築や運用、セキュリティから解放
高品質で無駄なく変更要求に即応できるソフトウエアの実現
安定稼働と高速なデリバリーの両立
最新機能の調達と構築・運用からの解放
 デザイン思考
 XP(エクストリーム・プログラミング)
 スクラム など
 CI(継続的インテグレーション)/CD(継続的デリバリー)
 コンテナ
 マイクロ・サービス など
 サーバーレス/FaaS
 PaaS/SaaSとAPI
 リポジトリー・サービス など
心理的安全性と自律したチーム
ゼロトラスト・ネットワーク
ITの役割の歴史的変遷
ビジネス
バッチ処理システム
ビジネスの事後で事務処理
オンライン処理システム
ビジネスと同時並行で事務処理
モノとサービスの組合せ
モノが主役・サービスは脇役
インターネット/Webシステム
一方通行発信・受信・会話型EC
サービス中心
サービスが主役、モノが脇役
エンゲージメント型Web
モバイル、ソーシャル、UXなど
~1970
~1990
~2000
2010~
ハイパー・コンペティション
不確実性の増大・競争原理の変化
モノ中心
モノ、製品が主役
ウオーター
フォール
ウオーター
フォール
アジャイル
アジャイル
& DevOps
IT
モノ中心
モノ、製品が主役
開発手法
アジャイル・DevOps・クラウドは常識の大転換
構築 運用 構築 運用
 構築・運用サイクル:5年~
 業務要件:変えられない/計画通りが前提
 要求水準:高品質/完璧
 責任分担:要求(事業会社)/その他全て(SI事業者)
サーバー
ストレージ
ネットワーク
HWや設備を調達
システム構築・運用
一連の業務を外注
所有+構築・運用
指示・外注が前提
従来のやり方(建築工事と保守点検)
 設計・実行サイクル:分/時間/日
 業務要件:変える/計画通りは無理が前提
 要求水準:高速にアップデートし品質を維持
 責任分担:全て(事業会社)/支援(外部事業者)
機能部品の組合せ
手順の設計と実行
自分が責任・主管
使用+設計・実行
自前・内製が前提
これからのやり方(賃貸やレンタカー)
クラウドには
 預ける・載せる・任せる発想はない
 アウトソーシングではない
 借りて、自分で使いこなす発想が必要
ビジネス・スピードの加速とシステム開発・運用の関係
ビジネス 要件定義
設計
開発
テスト
本番移行
リアルタイムな現場のニーズの変化やフィードバックをうけて、
小さな単位で高速に改善を繰り返し、ビジネスの成果に、いち早く貢献する
将来を予測し緻密な計画を立て、
必要性が高いと考えられるニーズに基づき仕様に固め、その通りに開発する
ワークロードとライフ・タイム
16
ワ
ー
ク
ロ
ー
ド
ライフ・タイム
ウォーターフォール開発
外注
アジャイル開発
内製
リリース後も
継続的に改善
常に最新を維持
リリース後の
手戻りが許されない
“完全”な成果物を提供
生産物としての
情報システム
サービスとしての
情報システム
人間の役割のシフト
生産性
高付加価値業務
繰り返し作業
自動化
個々の作業の
自動化
個々の
業務プロセスの
自動化
企業内・外の
ビジネス全体の
デジタル化と革新
全社規模の
業務プロセスの
標準化・最適化
出典: SAP CSG analysis, McKinsey Quarterly Report 2016 年 7 月、Google PR, Microsoft PR, SAP Market Model
既存業務を
標準化して自動化
より高付加価値
な業務へシフト
これからの開発と運用のあるべき姿
18
業務=本業
社員(人間)が本業を担い
事業の拡大や競争力を強化
売上や利益の増大をめざす
品質向上/コスト削減/納期短縮
IT=支援
標準化された業務プロセスを
現場に使わせ、徹底させる
IT=支援=コスト
コストの削減→外注
情シスの要請に応えシステムの構築と運用
デジタル・トランスフォーメーション以前
徹底した管理と統制=自社所有とウォーターフォール
業務とITの一体化
=本業
ITにより業務プロセスを構築
業務とITが渾然一体となって
事業を遂行し、成果を最適化
業務がITへITが業務へと
シームレスに変換される状態
IT=本業を実現する要件
IT=本業=投資
投資対効果の最大化→内製
業務現場にジャストインタイムでサービスを提供
デジタル・トランスフォーメーション以降
迅速なサービス提供=クラウド・アジャイル・DevOps
ウォーターフォール開発×オンプレミス×開発・運用業務委託の限界
これからの開発や運用に求められるもの
アジャイル開発
Agile Development
 ビジネスの成果に貢献するコードだけを
 変更に柔軟・迅速に対応して
 バグフリーで提供する
DevOps
Development & Operation
 運用の安定を維持しながら
 本番環境への迅速な移行と
 継続的デリバリー
クラウド
Cloud Computing
 最新・高速・俊敏な開発実行環境の調達
 経費化による不確実性への担保
 運用やセキュリティから解放と人材の再配置
デジタル・トランス・フォーメーション
業務がITへITが業務へとシームレスに変換される状態
差し迫るSI/SES事業の限界
SI/SES事業の収益モデルが限界
 技術力を伴わない工数ビジネスは利益が出なくなる
 物販は収益を下支えできなくなる
 何も手を打たなければ優秀な人材の流出が拡大する
事業会社におけるITの本業化
 外注対象の限定と内製化の拡大
 ウォーターフォール型開発の限界
 ITの評価基準がコストから投資へ転換
ウォーターフォール開発×オンプレミス×開発・運用業務委託の限界
アジャイル開発
Agile Development
 ビジネスの成果に貢献するコードだけを
 変更に柔軟・迅速に対応して
 バグフリーで提供する
DevOps
Development & Operation
 運用の安定を維持しながら
 本番環境への迅速な移行と
 継続的デリバリー
クラウド
Cloud Computing
 高速で俊敏な開発実行環境の調達
 経費化の拡大による不確実性への担保
 運用やセキュリティから解放と人材の再配置
現
場
に
ジ
ャ
ス
ト
イ
ン
タ
イ
ム
で
I
T
サ
ー
ビ
ス
を
提
供
す
る
ITのスピードが高速化
 ITのスピードにビジネス・プロセスが追いつかない
 全ての組織がサービス・プロバイダー化する
 どの様にITサービスを提供し維持するのか
 Value-driven (価値主導)
 Evolving(発展、展開する)
 Responsive(敏感に反応する)
 Integrated(統合、結合された)
 Service(サービス)
 Management(マネジメント)
企業レベルでサービス管理を行うための運用モデル
VeriSM
21
アジャイル開発
Agile Development
 ビジネスの成果に貢献するコードだけを
 変更に柔軟・迅速に対応して
 バグフリーで提供する
DevOps
Development & Operation
 運用の安定を維持しながら
 本番環境への迅速な移行と
 継続的デリバリー
クラウド
Cloud Computing
 高速で俊敏な開発実行環境の調達
 経費化の拡大による不確実性への担保
 運用やセキュリティから解放と人材の再配置
不確実性のコーン
22
システム企画 要件定義 基本設計 詳細設計 プログラミング
4.0x
2.0x
1.0x
0.5x
0.25x
初期の
プロダクト定義
承認された
プロダクト定義
設計仕様 詳細設計 研修された
ソフトウエア
要求仕様
見
積
金
額
の
変
動
幅
プロジェクトフェーズ
スティーブ・マコネル著「ソフトウェア見積り 人月の暗黙知を解き明かす」
倍
の
振
れ
幅
16
システム開発の理想と現実
23
品質
Quality
納期
Delivery
費用
Cost
品質
Quality
納期
Delivery
費用
Cost
品
質
の
低
下
納期とコストの厳守
理想の結果 実際の結果
早期の仕様確定がムダを減らすというのは迷信
24
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
ほとんど/決して使われていない: 64%
常に/しばしば使われている: 20%
早期の仕様確定がムダを減らすという迷信
0 3 6 9 12
25%
50%
75%
100%
時間経過(月)
要
求
の
信
憑
性
要求の時間的変質
24ヶ月後に25%程度
平均的な値
変化が大きくなっている
全ての要件をあらかじめ決めなくてはならない
「ウォーターフォール開発」
では、この変化への対応が難しくなってきた!
早期の仕様確定がムダを減らすというのは迷信
経過時間
要
求
の
信
憑
性
変化への即応と高い品質を両立する
「アジャイル開発」
への期待と関心が高まっている!
要求変化の
スピードが
加速
「仕様書通り作る」から「ビジネスの成果への貢献」へ
27
ビジネスの成果に直接貢献する
加速するビジネス・スピード
に即応する
本当に「使う」システムだけ
を開発・運用する
アジャイル開発
ビジネスと一体化した開発
DevOps
開発と運用の同期化
自動化と高速開発
クラウド前提の環境
テクノロジーを戦略的に活用する
開発と運用の方向性
28
「計画通り」は実現不可能
不確実性の増大とスピードの加速
ビジネスを取り巻く環境の変化
アジャイル開発
DevOps
ビジネスの成果に貢献するシステムを、バ
グフリーで変更にも柔軟に開発する
安定稼働を維持しながら、開発されたシス
テムを直ちに・頻繁に本番環境に移行する
VeriSM
クラウド
ITとビジネスを同期
化させ、ビジネス・
スピードを向上させ
る取り組み。
オンデマンドで必要
なシステムの機能や
性能を手に入れるた
めの仕組み
変化への即応力を競争の武器にする
IaaS PaaS SaaS
自社所有
クラウドの普及による責任区分の変化
アプリケーション
データ
ランタイム
ミドルウェア
オペレーティング
システム
仮想化
サーバー
ストレージ
ネットワーク
アプリケーション
データ
ランタイム
ミドルウェア
オペレーティング
システム
仮想化
(必ずしも使わない)
サーバー
ストレージ
ネットワーク
データ
ランタイム
ミドルウェア
オペレーティング
システム
仮想化
(必ずしも使わない)
サーバー
ストレージ
ネットワーク
アプリケーション
アプリケーション
データ
ランタイム
ミドルウェア
オペレーティング
システム
仮想化
サーバー
ストレージ
ネットワーク
ユ
ー
ザ
ー
企
業
の
自
己
責
任
構
築
⇒
外
注
ビ
ジ
ネ
ス
ク
ラ
ウ
ド
事
業
者
の
責
任
使
用
⇒
セ
ル
フ
サ
ー
ビ
ス
コード管理 コード確認 登録 構築 リリース
議事録・ガントチャートなど
情報はバラバラで
リアルタイムに進捗や状況が分からない
誰がやっているのかが分からない
伝言ゲームで現場の空気が伝わらない
タイムリーに検証ができない
リリースに時間かがかかる
開発と運用 現状
コード管理 コード確認 構築 リリース
開発と運用 これから
タスク
の共有
進捗や課題などのをリアルタイムに共有
開発する現場と利用する現場が一体となる
フィードバック・アップデート・リリース
のサイクルを高速で回す
DevOpsは迅速かつ安定的にソフトウエアをユーザーに届けることを目的に、開発と運用のチームが協働
し、プロダクトのリリース・サイクルを効率化する考え方。DevOpsを実現するためには、ボトルネック
改善に向けた最適なツール導入とDevOpsに適した文化の形成が求められる。
DevOpsの全体像
開発
Development
運用
Operation
気付きからサービスに至る全体プロセス
共感
定義
アイデア創出 学び・気付き デイリー
スクラム
スプリント
レビュー
振り返り
スプリント
プランニング
ビルド
ピボット or 継続?
実証実験開始
顧客の課題 ソリューション
デザイン思考 リーンスタートアップ
アジャイル開発
気付き・問題意識
タスクリスト
運 用
デプロイ
運用
監視
DevOps
サービス
フィードバック
SRE
Site Reliability Engineer
アップデート
データ収集
継続的な改善
CI Continuous
Delivery
Continuous
Integration CD
DXを実践するための環境
git/リポジトリー・サービス
Dev
開発
Ops
運用
コンテナ
CaaS/FaaS
コンテナ
サーバーレス
SaaS/PaaS
クラウド オンプレ
kubernetes
マイクロ・サービス・アーキテクチャー
作らない技術
企業文化・風土
HRTの精神
Humility:謙虚な気持ちで常に自分
を改善し、Respect:尊敬を持って
相手の能力や功績を評価し、Trust:
信頼して人に任せる
自律したチーム
現場への大幅な権限委譲、明確なビ
ジョンの提示と共有、徹底した情報
共有、円滑でオープンなコミュニ
ケーションなど
デジタル・リテラシー
事業部門の啓蒙と知識の底上げ、内
製化の推進、自前主義の排除、最新
技術の積極的活用、社内外の枠を越
えたオープンなコミュニケーション
アジャイル開発
 QAの体制、手法を強化すれば品質が上がるのか?
 1000行当たりのバグの発生率を管理する意味? (統計的品質管理)
 そもそもバグとは品質の問題? (不良作業)
 優秀なプロジェクト管理者を配置すれば上手く行くのか?
 コンテンジェンシーを見込めば、リスクが軽減するのか?
アジャイル開発とは
 PMBoKに沿ってプロジェクトを推進すれば上手く行くのか?
品質は結果ではなく
過程(プロセス)
管理者の役割は
開発者の障害を
取り除くこと
納期と品質はトレードオフ
だから品質を優先し
納期優先で開発機能数
を絞り込む
全部作らない代わりに使う機能だけをバグフリー・予算内で・納期通り作る開発の考え方
アジャイル開発
アジャイルソフトウェア開発宣言
37
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を
通じて、よりよい開発方法を見つけだそうとしている。この活動を通し
て、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動
くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよ
りも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは
右記のことがらにより価値をおく。
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, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
アジャイル宣言の背後にある原則
38
 私たちは以下の原則に従う:顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
 要求の変更はたとえ開発の後期であっても歓迎します。
 変化を味方につけることによって、お客様の競争力を引き上げます。
 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
 ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
 意欲に満ちた人々を集めてプロジェクトを構成します。
 環境と支援を与え仕事が無事終わるまで彼らを信頼します。
 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
 動くソフトウェアこそが進捗の最も重要な尺度です。
 アジャイル・プロセスは持続可能な開発を促進します。
 一定のペースを継続的に維持できるようにしなければなりません。
 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
 チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最
適に調整します。
開発と運用:従来の方式とこれからの方式
39
価値観
スピード
働き方
時間の使い方
計画
プロジェクト
リスク
役割
進捗管理
見える化
評価基準
要求
設計
コード
開発
品質
ドキュメント
デプロイ&リリース
運用
運用管理
リーダーシップ
計画重視
遅い
働き方仕事はまとめた方が効率が良い
残業を認める仕事の目的を達するまでの時間
計画重視、全期間にわたる計画立案(計画通りことは運ぶ)
しっかりと計画を立て、理論的に進める
プロジェクト後半に増大
専門家による分業
管理指標
作業が終わらないと見えない
計画に対して
管理可能、100%定義可能
機能中心設計
属人化する
基本は個人(専門家)
管理強化(当たり前品質)
多種多様、管理基準
半自動
分離独立
ITIL
統率型(指示&命令)
ウォーターフォールを中心とした従来の方式
リソース重視、適応性重視
早い
仕事は1つ筒こなした方が効率が良い、残業は認めない
区切られた時間内で仕事の目的を達成(タイムボックス)
計画作り重視、朝令暮改、詳細1か月(計画通り事は運ばない)
フィードバック重視、反復的(イタラティブ)に進める
プロジェクト広前半に増大
多能工型(T型人材)
現地・現物管理(動くプログラムのみ)
ほぼいつでも見える(徹底した透明性)
ビジネス価値(ビジネスの成果)に対して
管理不能、定義不能(標的は動くが前提)
プロセス中心設計
属人化排除
チームの連帯責任
向上の可能性あり(魅力的な品質)
MRI(必要最低限)、使用目的の明確化
自動(ディプロ医メント・パイプライン)
オペレーションの一体化
計量化したサービス管理 & ISO20000
侍従型(サーバント・リーダーシップ/ファシリテーション)
アジャイル開発&DevOpsによるこれからの方式
アジャイル開発が目指していること
ユーザーが求めているのは
情報システムが提供するサービス
 業務の生産性を向上させる
 売上や利益を向上させる
 顧客満足を高める
QCD(Q:品質 C:コスト D:納期)
を守って情報システムを納品する
 バグを○○%以下にする
 コーディング規約を遵守する
 納期を間に合わせる
ビジネスの現場にジャストインタイムで
必要とされるサービスを提供し続ける
スピード、バグフリー、変更への即応
アジャイル開発:システム構築からサービスの提供(体制変化)
ユーザー まとめ役
プログラマー
SE プログラマー
テスター
品質保証
ユーザー プロダクト
オーナー
プロジェクト
管理者
スクラム
マスター
ウォーターフォール開発(機能が主役、人は従、伝言ゲーム)
アジャイル開発(人と流れが主役、機能は従、信頼関係に支えられた観察と対話)
要望
要求
仕様
設計
仕様
システム
仕様
テスト
仕様
常時コミュニケーション
要求・意思決定
要望
アジャイル開発のプロセス
開発 開発 開発
イテレーション/反復#1 イテレーション/反復#2 イテレーション/反復#3
開発
イテレーション/反復#n
 業務上の重要度に基づいて優先順位を決めて業務プロセスを積み上げてゆく。
 リリースされるプロセスは実行可能であり、ユーザーがそれを使って検証できる。
 現場のフィードバックを受け入れ、次のイテレーションで統合してリリースする。
リリース フィード
バック
最も重要度の高い
業務プロセス
業務上の成果があげられる
と判断されて完成とする
重要度の高い順番に
業務プロセスを追加
追加されたプロセスは既にリリースした
プロセスと統合し品質を確認する
ウオーターフォール開発
要
件
定
義
外
部
設
計
内
部
設
計
プ
ロ
グ
ラ
ム
設
計
プ
ロ
グ
ラ
ミ
ン
グ
統
合
テ
ス
ト
結
合
テ
ス
ト
リリース
アジャイル開発の基本構造
100%
0%
時間
仕様書に記載した
全ての機能
100%
0%
時間
予定していた
全体仕様
30%
60%
80%
現場からの
フィードバック
現場からの
フィードバック
現場からの
フィードバック
?
仕様書に対して100点満点狙い
ビジネスの成果に対して合格点狙い
途中の成果からフィードバックを得て、
仕様や優先順位の変更を許容する。
ウォーターフォール開発の考え方
アジャイル開発の考え方
現場からのフィードバック
最後になって訂正・追加などが集中
目標としていたビジネスの成果が
達成できていれば完了
仕様凍結(確定)させて仕様書通りに開発が100%完了したら、
現場からのフィードバックを求める。
仕事の仕組みは確定できるを前提にした開発
仕事の仕組みは変化するを前提にした開発
アジャイル開発の進め方
スプリント
レビュー
振り返り
プロダクト・オーナー
デイリー
スクラム
スプリント
バックログ
スプリントの
繰り返しプロセス
スプリント計画
ミーティング
稼働する
ソフトウェア
スコープ デザイン
プロダクト
バックログ
プロダクト
バックログ
スクラム・マスター
ウォーターフォールとアジャイルの違い その1
 用意されたプロセスやツール
 全てを網羅したドキュメント
 お互いの妥協点を探る契約交渉
 一度決めた仕様や計画に従うこと
 システムを納品すること
計画通りに完成させること
「計画通り」が正義という信念
 自律的な判断と行動
 実際に使う動くソフトウェア
 顧客との対話と協調
 変更や変化への柔軟な対応
 ITサービスを提供すること
ビジネスを成功させること
「計画通り」は無理という現実
ウォーターフォールとアジャイルの違い その2
 ユーザーと開発者はプロジェクトを通して、日々一緒
に働く
 ユーザの満足を優先し価値あるソフトウェアを早く継
続的に提供する
 要求の変更はたとえ開発の後期であっても歓迎する
 動くソフトウェアをできるだけ短い間隔( 2~3週間
あるいは2~3ヶ月)でリリースする
 動くソフトウェアこそ進捗の最も重要な尺度
 技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
 シンプル(無駄なく作れる量)に作ることが基本
 最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
 チームが最も効率を高めることができるかを定期的に
振り返り、それに基づいて自分たちのやり方を最適に
調整する
アジャイルな思想
 ユーザと開発者はいつもは別の場所にいてプロジェク
トを通して定例ミーティングを行う
 ユーザーの満足や価値のあるなしではなく、とにかく
ソフトウェアを提供する
 要求の変更を開発の後期に出すの勘弁して欲しい
 パワポ、エクセル、ワードの仕様書を丁寧に清書して
( 2~3週間あるいは2~3ヶ月)納品する
 動くソフトウェアこそ進捗の最も重要な尺度
 技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
 仕様書通り(間違っていようが)に作ることが基本
 最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
 チームがもっと稼働率を高めるように監視し、それに
基づいて自分たちへの批判や不満を回避するために、
念のため納期を厳しめに設定する
ウォーターフォールな思想
https://speakerdeck.com/kawaguti/flipped-agile-manifest
Yasunobu Kawaguchi氏 資料を参考に作成
ウォーターフォール開発とアジャイル開発(1)
47
要件定義
開 発
テスト
膨大なドキュメント
動くソフトウェア
保守
本気で検証
改修を要求
真面目に考える
よく分からない
納期遅延
品質問題
リソース
時間
ユーザーは
はじめて本気
ソフトウェアを使う
ユーザー
マジ
アジャイル開発の進め方
48
1.まずは人が通れるほどのトンネルを貫通させる。
2.大きな工事機械が入れるように拡げてゆく。
3.二車線の道路に拡張し、設備を整備する。
ウォーターフォール開発とアジャイル開発(2)
49
リソース
動くソフトウェア
動くソフトウェア
動くソフトウェア
動くソフトウェア
ソフトウェアを使う
ユーザー
動くソフトウェア
を作り続けるれば
ユーザーはずっと本気
マジ!
マジ!
マジ!
マジ!
テ
ス
ト
時間
アジャイル開発
ウォーターフォール開発
最初に要件をあらかじめ
全て決めてから開発
要件
設計
コーディング
単体テスト
結合テスト
ウォーターフォール開発とアジャイル開発(3)
リリース
ビジネス上の重要度で要件
の優先順位を決め、これに
従って必要機能を順次開発
反復(イテレーション)1
反復 2
反復 3
反復 4
リリース
リリース
リリース
リリース
Continues Integration
品質の作り込み
ウォーターフォール開発とアジャイル開発(5)
◎
〇
△
X
反復 1 ビジネス価値 ◎
反復 2 ビジネス価値 〇
反復 3 ビジネス価値 △
反復 4 ビジネス価値 X
「MVP(Minimum Viable Product:仮説を検証することができる最低限のプ
ロダクト)」かつ、ビジネス価値の高い機能・プロセスを優先して開発する。
ウォーターフォール開発とアジャイル開発(6)
プラン
ドリブン型
バリュー
ドリブン型
工数
アジャイル
納期
工数 納期
実現仕様
ウオーターフォール
要求仕様
要件 設計
コーディング
単体テスト
結合テスト
リ
ス
ク
時間
反復1
リ
ス
ク
時間
反復2 反復3 反復4
前提条件
原理的に
不良が起きない
納期が守られる
コストと納期を
守ること
機能と品質を実
現すること
ゴールは何か?
アジャイル開発の目的・理念・手法
53
高品質で無駄がなく、変更要求に対応できるきるソフトウエアを作成する為
 適切な一連の手順に従う
 高い協調と自律的なプロジェクト関係者によって実施される
 イタラティブ(反復/周期)、インクリメンタル(順次増加部分を積み上げていく)方式
 ダイナミックシステムズ開発技法(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、プログラマー、テスター)
目的と理念
手 法
共通する要素
スクラム:自律型の組織で変化への柔軟性を担保する
54
 さまざまな専門性を持った人がチームを組み、最初
から最後まで一緒に働く。
 人とチームを重視し、彼らが自律的に働ける環境を
与えることでブレークスルーが起こりやすくなり、
同時に製品化までの時間が短くなる。
 リーダーは、自律するチームの障害を取り除くこと
が仕事であり管理しない。
日本で行われている
新製品開発のプロセスを
米国のやり方と比較した論文
1986,Harvard Business Review
Scrum(スクラム)
1990年代Jeff Sutherlandらが
ソフトウェア開発のに適用
アジャイル開発
 不安定
高い自由裁量と困難なゴールを持つ
 自己組織化
情報ゼロから相互交流し自律的に仕組みを作る
 全員多能工
分業を共有しメンバーがプロジェクトの責任を自覚する
イノベーションを
生みだす方法論
不確実な要素が多いソフトウェア開発にお
いて、フィードバックを得ながらより価値
の高いソフトウェアを提供するための方法
を体系的に整理したフレームワーク
アジャイル開発の系譜
55
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の概念、管理手
法の採用
スクラム:特徴・3本の柱・基本的考え方
56
システム開発のフレームワーク(1995)/ Ken Schwaber & Jeff Sutherland
 特徴
 軽量
 理解しやすい(シンプル)
 会得するのは比較的難しい
 三本の柱
 Transparency (透明性)
 Inspection (視察、検査)
 Adaptation (適応、順応、改作)
 基本的考え方
 タイム・ボックス(Time Box)
時間を区切って、その時間内に目的を果たす仕事を行う仕事の仕方
 機能横断的な固定化されたチーム
チーム内で役割分担を決めず、全員が必要な仕事をこなす多能工(T型人間のチームででき
るだけチームメ ンバーを固定化した方がよい
 持続可能なペース
徹夜や残業を排除して安定した持続可能な一定のペースで開発し、定期的にリリースを行う
スクラム:スクラム・プロセス
57
イテレーション(反復) 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
スタンドアップミーティング & スプリント・レビュー・振り返り
スクラム:プロダクト・オーナー
58
ミッションと責任
 プロダクトの完成図と方向性を示す
 プロダクトに必要な機能の詳細を決める
 リリースの内容と日程を決める
 市場価値に基づくプロダクト・パックログの優先順位を決める
 スプリント毎に優先順位を変更できる権限を持つ
 プロダクトの収益性(ROI)の責任を持つ
プロダクト・オーナーが行う事
 プロダクトのビジョンを作成し、関係者に示し、共有する
 対象プロダクトのビジネス要求(ビジネス環境)の説明
 エピック、ユーザーストーリーの確定とペルソナの作成
 ユーザーストーリー毎の受け入れ基準の承認
 プロダクト・バックログの優先順位付けとプロジェクト期間中の維持管理
 開発チームへのユーザーストーリーの説明
 開発チームのDoD(完了の定義)作成の支援
 リリース計画の承認
 稼働環境の定義
 EOL(プロダクトの終焉)条件の設定
スクラム:スクラム・マスター
59
 チームの機能や効率化を支援する
 チームが最大パフォーマンスを発揮できる環境を作る
= 妨害からチームを守る
 チームがスクラム・プロセス通りに作業を実施できる様に支援する
 チームに気付きを与える
 チームの自律を支援する
 チームの能力をユーザーに売り込む
 プロジェクト関係者間の信頼感を醸成する
 お客様(ユーザー)第一の思想
 ジャスト・イン・タイムの徹底
 カイゼン活動の促進
 チームのモチベーションの向上
スクラム・マスター
スクラム:開発チーム
60
 自己組織的なチームである
 自律性
メンバーが自ら日々の仕事を管理する
 自己超越
常に目標を達成するように自らを追い込み、常に自身のプラクティスを改善する
 相互交換作用
機能横断的かつ定めた役割がない
 目標にコミットする義務がある
 チームはスプリント計画ミーティングでコミットした目標を達成する責 任
を持つ
 目標達成につながるならば方法を限定しない
 チームは全ての決断を下す権限、必要なことを何でも行う権限、あらゆる障
害の除去を依頼する権限を持つ
 争議はチーム内で解決する
 作業規約を作る
エクストリーム・プログラミング(XP)
61
 テスト駆動開発(Test-Driven Development:TDD)=テストファース
ト・プログラミング
 実装する機能をテストするプログラムを書く
 コードを書いてテストする
 デザインを見直す
 信号が青になる(テスト・コードが成功する)まで繰り返す
 リファクタリング
 完成したコードの見直し(実装された機能を変えずに、コードをシンプルに、
見やすくする)
 任意の作業(全員が行う&時間が空いたら行う)
 ペアプログラミング
 ドライバー(コードを書く人)
 ナビゲーター(コードをチェックする人、ナビゲーションをする人)
 この役割を1日の中でペア間で、途中で交代する
 ペアの組み合わせを毎日替える
 10分間ビルド
 自動的にシステム全体をビルドして、全てのテストを10分以内に実行させる
Kent Beck(1999年)によって提唱された開発手法
アジャイル開発で品質が向上する理由
62
 ムダ取りの原則を徹底する。
作業にムラがあるから、ムリをするようになる。
ムリな作業をした結果、ムダが生じる。
ムラを防止するのは、一定の作業リズム(タクトタイム=タイムボックス)
 タスクの粒度を小さくする。
作業手順(工程設計)を考えなければタスクは小さくできない。
タスクが小さくなれば、ミスを容易に発見できる。手戻りも小さい。
タスクを小さくするとムダが見えてくる。
正味(本来の価値を作り込む)作業、付帯(事前、事後の)作業、ムダな作業
タスクを小さくすることで、整流化が容易になる。(ボトルネックの解消: 一個流し生産)
 全員での作業で透明性が高まる。
一人で抱え込む仕事がなくなる。
事前に他人の目が届く(チェック)
 トヨタ生産方式(TPS)の自働化の思想をプロセスに組み込める。
不良作業をしない。不良品を流さない。不良品を受け取らない。(自工程完結)
不良が起こったらラインストップをして、関係者全員が異常に気づく。(見える化)
 作業者(開発者)に直接フィードバックする仕組みが構築できる。
『擦り合わせ』をしながら作業が進む。
アジャイル開発で品質が向上する理由
63
タスクの粒度を小さくすることは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
DoD (Definition of Done) 完了の定義
64
 各作業の完了基準
 閾値(標準値)を決める。
 作業経過、結果を計測する。
 自工程完結の基本的な姿勢(現場での意思決定)
 仁=他人の努力を無駄にしない思いやり
検
査
検
査
検
査
発生防止
流出防止
プロセス プロセス プロセス 検
査
納入
検査 検査 検査
DoD
ウォーターフォールとアジャイル
要件 設計 実装 テスト
ウォーターフォール
アジャイル
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
ソフトウェアV&V(ベームのVチャート)
要件 設計 実装 テスト
ウォーターフォール
コンセプト
探索
コンセプト確認
要求
要求ベースライン
要求確認 設計確認 確認テスト
製品設計
製品設計検証
詳細設計
プログラム設計検証
コード 単体テスト
統合テストと
システムテスト
受け入れテスト
バリデーション(確認)
ベリフィケーション(検証)
導入 運転試験と評価
利用と
サポート
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
アジャイル
設計 に対する 検証(ベリフィケーション)ではなく、
要求(要件) に対する 確認(バリデーション)を繰り返す
要求 確認 要求 確認 要求 確認 要求 確認 要求 確認
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
アジャイル開発(スクラム開発)の体制(理想)
Product
Owner
Developer
End
Users
Agile Team
要求(要件) に対する 確認(バリデーション)を直接実施
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
アジャイル開発(スクラム開発)の体制(実際)
Product
Owner
Developer
End
Users
Agile Team
要求(要件) に対する 確認(バリデーション)を直接しにくい/頻繁にはできない
Business
Unit
要求(要件) に対する 確認(バリデーション)を間接的に行うこととなりがち
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
アジャイル開発(スクラム開発)の体制(さらに複雑となったある事例)
Product
Owner
Developer
End
Users
Agile Team
Project
Manager
要求(要件) に対する 確認(バリデーション)を正しく行うことができない状況
Sales
Project
Leader
Project
Owner
Project Member
Customer
その結果、短期間のイテレーション(反復)を繰り返していても、後になって仕様変更、仕様追加が発生
❓
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
アジャイル開発(スクラム開発)の体制(複雑なケースへの対応)
Product
Owner
Developer
End
Users
Agile Team
Project
Manager
エンドユーザーとの直接対話パスを確保し、
要求(要件)に対する確認(バリデーション)を実施できる体制とすべき
Sales
Project
Leader
Project
Owner
Project Member
Customer
デンソー・デジタルイノベーション室長・成迫剛志 作成資料
DevOps
ビジネス 開発 運用
アジャイル開発 DevOps
アプリケーション開発環境
マイクロ・サービス、ルールエンジン、AI、APIなど
ITインフラストラクチャー
IaaSなどのクラウド
アプリケーション実行環境
コンテナ・オーケストレーション・ツール
サーバーレス・FaaS
Infrastructure as Code
運用の自動化
SRE
Site Reliability Engineer
アイデアの創発
 デザイン思考
 リーンスタートアップ
トライ・アンド・エラー
のサイクルを高速で回す
ビジネス・スピードを加速する方法
 ビジネスの成果に貢献するコードのみ
 現場のニーズにジャストインタイム
 バグフリーと変更への迅速・柔軟な対応
 開発されたコードを直ちに本番移行
 安定稼働の維持
 変更やスケールへの迅速・柔軟な対応
開発と運用の協調・連携を実現するDevOps
74
情報システムに求められること
 システムによってビジネスの成功に貢献すること
 ビジネスの成功のための貢献を確実、迅速にユーザーに届けること
 ユーザーの求める貢献の変化に迅速・柔軟に対応すること
開発チーム(Development)
システムに新しい機能を追加すること
運用チーム(Operation)
システムを安定稼働させること
迅速にアプリケーションを開発・更新し
すぐにユーザーに使ってもらいたい
確実に本番システムに安定させ
安心してユーザーに使ってもらいたい
対立
アジャイル開発 SDI/IaaS(インフラのソフトウエア化)
ツール と 組織文化 の融合
開発チーム(Development)と運用チーム(Operations)が、お互いに協調し合い
「情報システムに求められること」を実現する取り組み
いますぐ変更を
反映したい!
安定運用したい!
DevOpsのメリット
 ソースコードを変更してすぐデプロイとテストができるため、早い段階で問題を発見できる。
 テストやビルド、デプロイなども、自動化・省力化することで、ヒューマンエラーを防げる。
 いざ本番環境になって動かない!というリスクが低い。
 開発と運用が稼働状況を共有することで、問題点や修正のステータスを把握しやすい。
 新しい機能で問題が起きた時の対応についても、フィードバックがスムーズ。
 運用はリリースの信頼性が高まることで、システムの変更を承認しやすくなる。
継続的インテグレーション(Continuous Integration)
開発者が自分のコード変更を頻繁にセントラルリポジトリにマージし、その度
に自動化されたビルドとテストを実行します。小さなサイクルでインテグレー
ションを繰り返し行い、インテグレーションのエラーを素早く修正することに
よりチームは統合されたソフトウェアをより迅速に開発できるようになります。
コミット
ビルド
テスト
結合
Continuous Integration
CI
フィードバック
後工程
コミット
ビルド
失敗
変更
コミット ビルド
変更
原因究明
変更
ビルド
失敗
変更 ビルド 変更 ビルド 変更 ビルド
「ビジネス×IT」環境の変化 + ビジネス・スピードの加速
ITニーズの変化:「効率化×生産性×低コスト」から「差別化×競争優位」へのシフト
IT環境の変化 :モバイル、IoT、ビッグデータなどの新しいテクノロジーへの対応
IT利用の変化 :ITリテラシーの拡大やデジタル・ビジネス、ビジネスとITとの一体化
DevOpsとは何か?
76
業務部門
開発部門 運用部門
依頼
業務部門
開発部門 運用部門
情 報
システム
情 報
システム
連係・協力
対応に長いリードタイム
 組織の間を隔てる意思疎通の壁
 煩雑な業務プロセス
 手間のかかる構築や確認などの作業
ビジネス・ニーズに迅速・柔軟な対応
 役割や関係などの組織文化の変革
 ビジネス・プロセスの変革
 自動化ツールの整備・活用
DevOps
DevOpsとは何か?
77
業務部門
開発部門 運用部門
情 報
システム
連係・協力
継続的デリバリー
Continuous Delivery
継続的インテグレーション
Continuous Integration
バージョン管理
自動構築
動的テスト
非機能テスト
サーバー構築
オートスケール
自動運用
コミュニケーション
ツール
ビジネス・ニーズ
開
発
要
望
フ
ィ
ー
ド
バ
ッ
ク
ツールによる自動化
DevOpsとは何か?
78
お互いを尊重する(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などのチャットツールに自動的にビルドやデプロイのログ、アラート内容を投稿する仕組みを
作ることで情報をお互いに共有する
ツ
ー
ル
組
織
文
化
改善
サーバー仮想化とコンテナ
79
OS
ハードウェア
ハイパーバイザー
仮想サーバー
ミドルウェア
アプリ
OS
仮想サーバー
ミドルウェア
アプリ
OS
仮想サーバー
ミドルウェア
アプリ
サーバー仮想化
ハードウェア
コンテナ管理ソフトウエア
OS
ミドルウェア
アプリ
ミドルウェア
アプリ
ミドルウェア
アプリ
コンテナ コンテナ コンテナ
コンテナ
ライブラリ
環境変数
ライブラリ
環境変数
カーネル カーネル カーネル
カーネル
ライブラリ
環境変数
ライブラリ
環境変数
ライブラリ
環境変数
ライブラリ
環境変数
隔離されたアプリケーション実行環境を提供(クラッシュの分離、独自のシステム管理とユーザー・グループ)
実行イメージのスナップショットをパッケージとしてファイルにして保存できる
アプリケーションに加えて仮想マシン・OS
の実行イメージを持つ必要がある
アプリケーションとOSの一部
の実行イメージを持つ必要がある
デプロイするサイズ
大きい
起動・停止時間
遅い
デプロイするサイズ
小さい
起動・停止時間
早い
異なるOS
可
異なるOS
不可
メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い
構成の自由度が高い
異なるOS・マシン構成を必要とする場合など
軽量で可搬性が高い
実行環境への依存が少なく異なる実行環境で稼働させる場合など
サンド・ボックス化
Sand Box
仮想マシンとコンテナの稼働効率
80
ハードウェア
仮想マシン
ミドルウェア
アプリケーション
OS
仮想マシン
OS
仮想マシン
OS
ミドルウェア
アプリケーション
ミドルウェア
アプリケーション
ハードウェア
OS
コンテナ管理機能
カーネル
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
カーネル カーネル カーネル
ライブラリ
環境変数
ライブラリ
環境変数
ライブラリ
環境変数
コンテナ
仮想マシン
仮想マシンとコンテナの稼働効率 1/2
81
ハードウェア
仮想マシン
ミドルウェア
OS
仮想マシン
OS
仮想マシン
OS
ミドルウェア ミドルウェア
カーネル カーネル カーネル
ライブラリ
環境変数
ライブラリ
環境変数
ライブラリ
環境変数
仮想マシン
OSの維持コストが高いので
1つのOSに複数のアプリケーションを同居させる
あるいは基盤更改などで移行する時も分離できず
再構築することもおおい
ライブラリが共通で依存関係があり
アップグレードもパッチ適用もできず塩漬けになりがち
仮想マシンごとに
OSを稼働させとハードウェア・エミュレーションがあり
ハードウェアとOS起動+運用が必要となり
オーバーヘッドが大きい・起動は分単
アプリ アプリ アプリ アプリ アプリ アプリ アプリ アプリ アプリ
仮想マシンとコンテナの稼働効率 2/2
82
ハードウェア
OS
コンテナ管理機能
カーネル
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
コンテナ
アプリ+ミドルウェア+ライブラリを
一体として管理できる
ライブラリの依存関係を気にせずに
OSのアップグレードやパッチを適用できる
アプリ+ミドルウェア+ライブラリの塊(コンテナ)
は相互に独立している
各コンテナのライブラリは分離・独立しているので
好きなバージョンを組み合わせられる
OSは1つだけでオヘバーヘッドが少ない
OSの1プロセスとして稼働・起動は秒単位
コンテナのモビリティ
83
ハードウェア
OS
コンテナ管理機能
カーネル
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
いま使っているシステム環境
83
ハードウェア
OS
コンテナ
管理機能
カーネル
ハードウェア
OS
コンテナ
管理機能
カーネル
ハードウェア
OS
コンテナ
管理機能
カーネル
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
ミドルウェア
アプリ
ライブラリ
環境変数
コンテナ
コンテナ・レベルで稼働は保証されている
他のシステム環境
DevOpsとコンテナ管理ソフトウエア
アプリケーション
開発・実行環境
ミドルウェア
オペレーティング
システム
サーバー
(ハードウェア)
ハイパーバイザー
アプリケーション
開発・実行環境
ミドルウェア
オペレーティング
システム
サーバー
(ハードウェア)
コンテナ管理
そのまま本番で動かしたい(動作保証)
開発から本番以降への時間を短くしたい
実行に必要な最小のサイズで移行したい
仮想マシン
コンテナ
仮想化環境
動
作
保
証
動
作
保
証
オーバーヘッド
物理マシン(ハードウェア)
との依存関係を切り離す
OSとの依存関係を切り離す
DevOpsとコンテナ管理ソフトウエア
オペレーティング
システム
サーバー
(ハードウェア)
コンテナ管理
動
作
保
証
オペレーティング
システム
サーバー
(ハードウェア)
コンテナ管理
動
作
保
証
オペレーティング
システム
サーバー
(ハードウェア)
コンテナ管理
アプリケーション
開発・実行環境
ミドルウェア
コンテナ
動
作
保
証
Build,Ship and Run
Any App,Anywhere
アプリケーション開発者は、OSやインフラを意識することなくアプリ
ケーションを開発し、どこでも実行できるようになる
開発しテストが完了したアプリは、すぐに本番環境で実行させることができる
本番環境
テスト環境
開発環境
モビリティの高いコンテナ
86
デバイス
エッジ
サーバー
オンプレミス
サーバー
クラウド
ハードウェアやOSに依存することなくソフトウェア機能を配置・移動できる
コンテナ連係
その運用管理
コンテナとハイブリッド・クラウド/マルチ・クラウド
コンテナ管理
コンテナ管理
コンテナ管理
Microsoft Azure
自社所有システム
AWS
コンテナ連係
その運用管理
コンテナ連係
その運用管理
アプリケーション
開発・実行環境
ミドルウェア
コンテナ
アプリケーション
開発・実行環境
ミドルウェア
コンテナ
アプリケーション
開発・実行環境
ミドルウェア
コンテナ
DockerとKubernetes の関係
88
 コンテナの作成
 コンテナの実行
 コンテナ内でファイルシステ
ムとして使われるイメージの
作成および管理 など
 関連するコンテナのグルーピング
 コンテナに割り振られる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)
Twelve Factorsとの関係
89
Ⅰ. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
Ⅱ. 依存関係
依存関係を明示的に宣言し分離する
Ⅲ. 設定
設定を環境変数に格納する
Ⅳ. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
Ⅴ. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
Ⅵ. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
Ⅶ. ポートバインディング
ポートバインディングを通してサービスを公開する
Ⅷ. 並行性
プロセスモデルによってスケールアウトする
Ⅸ. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
Ⅹ. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
Ⅺ. ログ
ログをイベントストリームとして扱う
Ⅻ. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
アジリティーの高いWebサービスを構築するための方法論
コンテナ Kubernetes
https://12factor.net/ja/
Kubernetes
Master
全体のコンテナの稼働
状況などを把握し、運用
管理者が指定したよう
に、コンテナ配置、削除
などを指示
Kubernetes の全体構造
90
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
コンテナ
ライブラリ
環境変数
アプリや
ミドルウェア
Kubernetes
Node
Kubernetes
Node
Kubernetes
Node
Kubernetes
Pod
Kubernetes
Pod
Kubernetes
Pod
Kubernetes
Pod
コンテナ管理システム
コンテナ管理システム
が稼働しているマシン
/サーバーの単位
コンテナの
まとまりの単位
Kubernetes
Cluster
Nodeの集まりの単位
物理マシン/仮想マシン
 yaml形式記載された設定
ファイル
 kubectlコマンドを使って、
設定をKubernetes
Masterに反映
 Kubernetes Masterは反
映された内容を元に、
NodeやPodを操作
マニフェスト
意味:ギリシャ語で「人生の道標」
読み方:クーベルネイテス
略称:K8s
DevOpsとコンテナ管理ソフトウエア
91
同一のプラットフォームでなくても動作保証されるので
第三者が作ったコンテナ(アプリケーションと実行環境)
を共有することで、開発のスピードアップを実現できる。
Hub
モノリシックとマイクロサービス
サーバー コンテナ
コンテナ
コンテナ
常時稼働が求められるサーバーで動く 必要な時だけ稼働すればよいコンテナで動く
マイクロサービス
マイクロサービス
モノリス型アーキテクチャ マイクロサービス型アーキテクチャ
巨大な1枚岩のような
マイクロサービス(Micro Service)
93
ユーザー・インターフェイス
顧客管理
注文管理
在庫管理
出荷管理
Webブラウザ Webブラウザ
Webブラウザ
共有データ
顧客管理
注文管理 在庫管理
出荷管理
Webブラウザ Webブラウザ
Webブラウザ
個別データ
ユーザー・インターフェイス
個別データ
個別データ
個別データ
モノリス型アーキテクチャ マイクロサービス型アーキテクチャ
マイクロ
サービス
巨大な1枚岩のような
複数の独立した機能(マイクロサービス)を
組み合わせることでひとつの処理を実現する
大きな単一の機能によって
ひとつの処理を実現する
単一の機能
独立した機能
内
部
は
複
数
の
機
能
で
構
成
マイクロサービス(Micro Service)
94
ユーザー・インターフェイス
顧客管理
注文管理
在庫管理
出荷管理
Webブラウザ Webブラウザ
Webブラウザ
共有データ
顧客管理
注文管理 在庫管理
出荷管理
Webブラウザ Webブラウザ
Webブラウザ
個別データ
ユーザー・インターフェイス
個別データ
個別データ
個別データ
モノリス型アーキテクチャ マイクロサービス型アーキテクチャ
マイクロ
サービス
巨大な1枚岩のような
単一の機能
独立した機能
内
部
は
複
数
の
機
能
で
構
成
マイクロサービス単位でマシンが必要
各機能の単位でマシンが必要
*「マシン」とは物理マシンだけではなく仮想マシンやコンテナも含む。
マイクロサービス・アーキテクチャの6つのメリット
修正
修正
リリースの同期は必須 個別にリリース可能
Java Java Java
Java Java Java
Java Ruby php
C++
Java
Script
C#
言語は統一 機能にふさわしい言語を選択
影響? 影響? 影響?
影響? 変更 影響?
一部機能変更・全体テスト 一部機能変更・対象機能のみテスト
変更
全体で拡張 個別に拡張
正常 正常 正常
正常 障害 正常
正常 正常 正常
正常 障害 正常
一部障害で全体停止 一部障害でも正常箇所は稼働
流用 流用
特定の機能流用は困難 特定機能の流用は容易
1.機能の独立性
2.言語の独立性
3.保守の容易性
4.拡張の柔軟性
5.障害時の可用性
6.再利用の容易性
「これなら分かる! マイクロサービス(入門編)~モノリスと比較した特徴、利点と課題(CodeZin)」を参考に作成
マイクロサービス・アーキテクチャの3つの課題
96
機能間で通信は発生しない 機能間で通信が行われる
全体をひとつのチームで行うので
人の入替えやノウハウ共有が容易
各機能個別に組織が分かれるの
人の入替えやノウハウ共有が困難
過剰分割の影響は内部に留まる
一貫したユーザー体験を提供
過剰分割はパフォーマンスを劣化
機能別に異なるユーザー体験のリスク
1.機能間の通信によりパフォーマンスが出にくい
2.人の入れ替えやノウハウの共有が難しく”人”や”知見” の活用効率が低くなる
3.プログラム構造次第でパフォーマンスやユーサー体験に悪影響
 通信により組み合わせるという仕組みから、パフォーマンス
を出しにくい。
 性能向上のため各機能間は非同期通信とし、機能をまたがっ
たトランザクション保証はしないため、正常終了した後に後
続処理がエラーとなることも想定した設計が必要。
 個人ユーザー向けの決済処理のような再試行が難しい業務の
場合は、実装が難しい。
 マイクロサービスを適用したアプリケーションを作るには、
個々の機能と同じように独立し完結した組織でなければなら
ないが、それができる保証はない。
 チームごとに独自文化が形成されチーム間でスキルの共用が
難しい。
 文化の違いから人的ローテーションも難しくなる。
 マイクロサービスの利点を生かすには、機能の境界を適切に
設定することが必須となるが、分ける範囲を誤れば機能間の
通信が大量に発生する。
 分けるべきであった機能を一つにしてしまえば保守性や再利
用性などのメリットが満たせない。
 独自性がすぎるとユーザー体験がちぐはぐになってしまう。
「これなら分かる! マイクロサービス(入門編)~モノリスと比較した特徴、利点と課題(CodeZin)」を参考に作成
オーケストレーションとコレオグラフィ
オーケストレーション(Orchestration) コレオグラフィ(Choreography)
オーケストレーション・プログラム
リ
ク
エ
ス
ト
リ
プ
ラ
イ
サービス
(アプリケーション機能)
サービス
(アプリケーション機能)
全体の処理の流れを制御する指揮者にあたるプログラム
が存在し、指揮者からのリクエストによってサービスを
実行し、実行結果をレスポンスとして指揮者に返して処
理を継続させるプログラム実行方式。
全体の処理の流れやサービスの呼び出しを制御する指揮
者は存在せず、個々のサービスに予め与えられた動作条
件や次にどのサービスを起動させるかといった振り付け
に従って自律的に動作させるプログラム実行方式。
指揮者の指示に従う演奏方式 演劇や踊りなどの振り付け
リクエスト・リプライ方式で実行されるのが一般的
 利用する全てのサービスは、指揮者であるプログラムが
処理の順序や得られた結果に続く処理を制御。
 各サービスは、そのサービスを制御する指揮者が行って
いる同一の処理のためだけに利用され、他の指揮者が制
御する別の処理を引き受けて実行することはない。
 サブルーチン・コールやメソッド・インボケーション
(呼び出し)と同様の考え方。
イベント・ドリブン方式に向いている
 イベントの発生によって特定の業務処理サービスが駆動
される方式。 イベントの例
 新規に注文が入った
 倉庫に商品が入庫した
 新規顧客が登録された など
 発生したイベントを他のサービスに通知することで、必
要な処理を継続的に実行させる。
Version 1.3
Version 2.0 Version 1.5 Version 1.4
エンジニアの役割分担
98
ITインフラ ITインフラ ITインフラ ITインフラ
開発エンジニア 開発エンジニア
SRE
テスト・エンジニア
マイクロ・サービス×コンテナによる独立したプロセス
クラウド・ベースでの
組織横断的な仕組み作り
「クラウド・ネイティブ」とは
99
開発者は他社と差別化できるビジネスロジックに集中したいのに
付加価値を生み出さない作業で負担を強いられる
 ミドルウェアの設定
 インフラの構築
 セキュリティ・パッチの適用
 キャパシティ・プランニング
 モニタリング
 システムの冗長化
 アプリケーションの認証・認可
 APIスロットリング など
この負担から開発者を解放
DevOps
マイクロ・サービス
アーキテクチャ
コンテナ
サーバーレス/FaaS(Function as a Service)
アプリケーションを継続的・高速にアップデートし
ビジネス・ニーズに即座に対応
クラウド・サービスの区分
自社所有 IaaS
仮想マシン
CaaS PaaS FaaS
ユーザー企業が管理
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
SaaS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
IaaS
ベアメタル
クラウドサービス事業者が管理
連携機能
CaaS PaaS FaaS SaaS
サーバーレスの仕組み
101
ブラウザからのアクセス
センサーからの発信
異常データの送信
タイマーによる起動
プログラムの実行
データベース・アクセス
機器の制御
レポートの作成
メールによる通知
イベント
処理 リソース
サービス
イベント
サービス
イベント
AWS Lambda
プログラムを「関数」としてアップロード
サーバーやサービスを立ち上げておく/
いちいち立ち上げる必要無し
イベント(トリガ)により処理を起動
課金は処理に要した時間のみ
メモリ容量や処理能力は自動で設定
毎日数件から毎秒数千件まで自動的にスケール
クラウド処理のためサーバー障害が発生しない
AWS以外の様々なWebサービスにも対応
イベントドリブンで最小限の処理を行う
= IoTなどで活用
サーバーレスとサーバーレスアーキテクチャ
サーバーレス = サーバーのセットアップや管理を行わなくともプログラムを実行できる
独立したWebサービスを
連携させる
Webサービスを
コンポーネントとして利用
FaaSによるクラウド上の
コンポーネント連携
AWS Lambda
Azure Functions
Azure Service Fabric
Google App Engine
Google Cloud Functions
サーバー上でプロセスが
稼働/待機
イベントにより
プロセスを起動
サーバー上でサービスが
稼働/待機
BaaS/mBaaS
API連携
様々なXaaS
ASP/SaaS
PaaS
IFTTT/マッシュアップ
サーバーレス・アーキテクチャ
FaaS:Function as a Service
イベントドリブン方式でアプリケーションを実行さ
せることができるクラウドサービス
お客様と自分たちのビジネス価値を再定義する
104
アプリケーション
プラットフォーム
インフラストラクチャ
ビジネス・プロセス
データ
アプリケーション
プラットフォーム
IaaS
ビジネス・プロセス
データ
アプリケーション
ビジネス・プロセス
データ
SaaS
ビジネス・プロセス
データ
PaaS PaaS
アプリケーション API
自社資産・自社運用
サービス・運用委託
1960〜 2010〜 2015〜 2016〜
FaaS 超高速開発
ツール
ビジネス価値は ビジネス・プロセスとデータ
手段は 使用 へシフト
お客様が開発と運用に求めていること
105
情報システムの
品質
成 果
生産量
スピード 最大
新しいビジネス・プロセスに対応し
データをいち早く生みだすために
できるだけ作らないで使用の拡大へシフトする
これからのITとITビジネス
106
ビジネス
アプリケーション
ミドルウェア
オペレーティング・システム
ハードウェア
ネットワーク
データセンター
ビ
ジ
ネ
ス
価
値
の
創
出
手
段
の
提
供
サービス
として利用
保守
運用
開発
導入
構築
プラットフォーム
インフラストラクチャー
人間の役割が拡大する領域
機械の役割が拡大する領域
 ITを活かした経営・事業戦略の策定
 ITを活かしたビジネスの開発
 システム全体の企画・設計
 クラウド・コンピューティング
 サーバーレス・アーキテクチャ
 人工知能を活かした自動化・自律化
運用技術者から
システム・アーキテクトやSREへの転換
アプリケーション開発者から
ビジネス・アーキテクトやコンサルへの転換
運用技術者からSREへ
107
ITの実務上の利用方法について問い合わせを受けて対応する
窓口業務
定められたオペレーションを繰り返し実施する定常業務
ITに関するトラブルに対応する障害対応業務
インフラ(ネットワークやOS・ハードなどの基盤部分)に関
する管理業務(構成管理やキャパシティ管理など)
積極的にソフトウェアで
置き換えていく
 クラウド・サービス
 自動化/自律化ツール
ビジネスもアプリも要件がどんどん変わっ
ていくので、継続的に改善して手作業をソ
フトウェアに置き換えていく必要がある
 変更への即応性や信頼性の高いシステム基盤を設計
 運用管理の自動化/自律化の仕組みを設計・構築
 開発者が利用しやすい標準化されたポリシーやルールの整備
運用技術者
Operator / Operation Engineer
SRE
Site Reliability Engineer
組織横断的なインフラ整備
作業者から
ソフトウェアエンジニア
への変身!
http://japan.zdnet.com/article/35090649/
http://torumakabe.github.io/post/bookreview_site_reliability_engineering/
参考になる記事:
DevOpsのための取り組み
これまでのソフトウェア開発
108
アルゴリズムの発見 プログラミング+演算
経験値×職人技で成果が左右される
入力 出力
データの増大と多様化・処理テーマの増大と多様化・変化のスピードが加速
経験値×職人技での対応に限界
これからのソフトウェア開発
109
機械学習によるモデル化
適切なデータの選択
データ・クレンジング
入力 出力
アルゴリズムの実装を行わず処理プロセスを自動化
学習モデルの選択
多少の試行錯誤
×
Microsoft Azureによる予測モデルの開発方法
110
システム開発における役割の変化
111
アルゴリズムの発見
データ構造
の設計
処理フロー
の設計
プログラミング
演算
要件定義
学習データ
の準備
学習モデル
の選択
推論エンジンによる推論
要件定義
学習モデルによる学習
デバッグ&テスト チューニング&テスト
保守 フィードバック
サービス要求 サービス提供 サービス要求 サービス提供
学 習
データ
ビジネス課題の明確化・システム企画 ビジネス課題の明確化・システム企画
本番環境への
デプロイメント
本番環境への
デプロイメント
これまでのシステム開発 これからのシステム開発
システム開発のこれから
112
仕様を作る
アルゴリズ
ムを考える
プログラム
を書く
データを
集める
データを
分析する
モデルを
創る
課題・テーマ
課題解決
テーマ実現
従来のアプローチ これからのアプローチ
高頻度で高速回転
ひとつひとつ確実に
Microsoftの”Sketch2Code”
113
手書きのワイヤーフレームをHTMLに自動変換
開発の自動化とは
AIによる自動プログラミング
人手によるプログラミング
フレームワーク
ノーコード/ローコード
BRMS(Business Rule Management System)
サーバーレス/FaaS
SaaS
API/PaaS
業務現場にジャストインタイムでサービスを提供
アジャイル開発
Agile Development
DevOps
Development & Operation
クラウド
Cloud Computing
機械学習を使ったシステム開発
APIエコノミー
アプリケーション
プログラム
API
116
アプリケーション
プログラム
API
Application
Program
Interface
APIの呼び出し
戻り値の返信
サービス
サービス
API
Application
Program
Interface
APIの呼び出し
戻り値の返信
プログラムの機能を呼び出し、その実行結果を戻り値として受け取る
サービスの機能を呼び出し、その実行結果を戻り値として受け取る
お店やプレイスポットを検索するFoursquareで取得した位置情報を
Uberに送りタクシーを配車してもらう。
APIエコノミー(2)
117
サービス
API
サービス
API
サービス
API
サービス
API
サービス
API
サービス
API連携
独自機能
サービス
API連携
独自機能
サービス
API連携
独自機能
Foursquare+Uber
 FoursquareからUberで車を手配
 観光地での迅速な配車サービス
会計管理+地方銀行
 リアルタイムの会計情報で与信
 中小企業への迅速な融資
自動車会社+損害保険
 運転の丁寧さで保険料率を変動
 支払リスクの低減と事故の削減
API Gatewayサービス
APIの作成
APIの配布
APIの保守
APIの監視
APIの保護
サービス
API
サービス
API
サービス
API
サービス
API
サービス
API
サービス
API
API Gatewayサービス
IBM
AWS
オープンソース・ソフトウェア
Open Source Software
オープン戦略
自社技術による顧客の囲い込み
特許などによる技術の保護
自社のみで利益を独占
外部のリソースを積極活用
自社で全てを開発する必要は無い
スモールスタートが可能
オープン化
かつての
常識
 オープンソース・ソフトウエア
 オープン・データ
 オープン・ハードウェア
クラウド時代の
常識
 プロプライエタリ・ソフトウェア
 独自アーキテクチャ
 ファミリー化戦略
「オープン」の損得勘定
成功例
・Apple II、MS-DOS、Windows
・System360
・プラットフォームとしてのIBM PC/AT
これまでも「オープン」はあった
メリット
デメリット
他社が周辺機器、アプリを
開発してくれる
互換製品によってシェアや
利益を落とすリスクがある
失敗例
・IBM 互換機
・IBM にとっての PC/AT
「公開しすぎ」は良くない
OSSとは
Linuxディストリビューション
ディストリビュータ
ボランティア・プログラマ
無償で貢献
【パッケージ費用】
*ただし、実費
Linux利用者
再パッケージ
インストーラーやマニュアルなど
パッケージ提供
無償で利用
(自己責任)
ソースコードのままでは使いにくい
カーネル以外にもライブラリ等が必要
動作するHWが不明確
Linuxカーネル
開発コミュニティ
成果物
Linuxカーネル
ソースコード
オープンソース開発の実際
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 ビジネスを手がける企業
が資金を提供してコミュニティ
を維持しているということ
=
開発の実体は商用ソフトと変
わりがないとも言える
Linuxの転機/IBMによるコミットメント
自社OSと同等のサポート
http://www-03.ibm.com/press/us/en/pressrelease/2262.wss
http://www.nikkeibp.co.jp/archives/189/189148.html
自社内に専任の開発部隊を設置
オープンソースへの投資を約束
Linuxの開発・ビジネスモデル
成果物
ボランティア・プログラマ
無償で貢献
【サポート費用】
Linux利用企業
Linuxカーネル
開発コミュニティ
Linuxカーネル
ソースコード
プログラマ
Linux関連ベンダ
プログラマ
Linuxを使った
ビジネス
【サポート費用】
再パッケージ
インストーラーやマニュアルなど
パッケージ提供
サポート提供
ディストリビュータ
変わるオープンソース
FLOSS (Free/Libre and Open Source Software)
FOSS (Free/Open Source Software)
2つのオープンソース
「元祖」オープンソース
オープンであることが「目的」のオープンソース
ビジネスに使えるオープンソース
オープンであることが「メリット」になるオープンソース
フリーソフトウェア
Free Software
「自由」なソフトウェア
オープンソースソフトウェア
Open Source Software
ソースを公開している
ソフトウェア
再配布条件が厳しい 再配布条件が緩い
例えばセキュリティ・アプライアンスの場合
ハードウェア
オペレーティングシステム
ファイアウォール/アンチウイルス
ファイアウォール/アンチウイルス 差別化要因=最も重要
既製品で充分 (OEM/ODM)
セキュリティ強化OSを自社開発/購入
手軽に使えて改変可能で安価なOSがあれば、それを強化して使うことによ
り開発コスト・調達コストを抑えられ、時間も節約できる
Linuxのコミュニティに自社の開発者を参加させ、成果を得る
カスタマイズが容易になり、自社に有利な仕様も入れることができる
単独で開発するよりも安価に、迅速に高品質のOSを開発できる
ここに注力
OSSはベンダーにとってもメリットがある
集合知の活用による
クオリティの向上
様々な立場からの知見、アイデアが寄せられるため、商用ソフトよりも新機能の導入が早い。ま
た、まだ研究段階にある技術などがどんどん盛り込まれるため、最先端の技術に触れられる。
世界中のプログラマが開発・テストに参加することから、開発速度やバグフィックスの速度が速
くなる。
自社技術の普及
知名度の向上
自社技術が普及し、サポートや周辺製品でのビジネスチャンスにつながる
自社技術の中立性・オープン性をアピールできる
透明性を確保できる
「それは仕様です」問題を回避できる。商用ソフトでは、ソースや仕様、決定過程が公開されて
いないため、「直せない」あるいは「直すのが大変な」バグなのか、本来の仕様なのかが外部か
らは特定できず、ベンダーの主張に従わざるを得ない。
ベンダーロックインの排除
ハードウェアとOS・アプリケーションが密接に連携している場合、いったんソリューションを選ぶと、
その後そのベンダーからの乗り換えは非常に難しくなる。この結果、独自ハードウェアおよび独
自ソフトの購入を続けなければならない。また、多くの場合、そういったハード・ソフトはコストパ
フォーマンスが悪く、割高な場合が多い。
カスタマイズ
自社仕様にあわせて自由にカスタマイズできる。(特にアプリケーション)
コミュニティによる開発が何らかの理由で中止されたとしても、自分でバグフィックスや機能拡張
を続けることが可能。
開発コストの削減
ソフトウェアを最初から開発するコストを省ける。(ベンダー間での2重投資の回避)
コミュニティの力を借りて製品の品質を向上させることができる。
利用者
にとっての
メリット
ベンダー
にとっての
メリット
導入コストの低減
ほとんどのOSSはライセンス料が無料で、サポートが必要なければ無償で利用することが可能。
必要に応じて有償でサポートを購入。
エンジニアの育成 社外のプログラマと接することによるプログラミングスキルの向上
LiBRA 10.2021 / 開発と運用
LiBRA 10.2021 / 開発と運用
LiBRA 10.2021 / 開発と運用
LiBRA 10.2021 / 開発と運用
LiBRA 10.2021 / 開発と運用
LiBRA 10.2021 / 開発と運用

Más contenido relacionado

La actualidad más candente

LiBRA 07.2021 / 開発と運用
LiBRA 07.2021 / 開発と運用LiBRA 07.2021 / 開発と運用
LiBRA 07.2021 / 開発と運用Masanori Saito
 
LiBRA 04.2019 / ビジネス戦略編
LiBRA 04.2019 / ビジネス戦略編LiBRA 04.2019 / ビジネス戦略編
LiBRA 04.2019 / ビジネス戦略編Masanori Saito
 
LiBRA 12.2020 / 開発と運用
LiBRA 12.2020 / 開発と運用LiBRA 12.2020 / 開発と運用
LiBRA 12.2020 / 開発と運用Masanori Saito
 
LiBRA_210201/Infra&platform
LiBRA_210201/Infra&platformLiBRA_210201/Infra&platform
LiBRA_210201/Infra&platformMasanori Saito
 
LiBRA 06.2021 / 開発と運用
LiBRA 06.2021 / 開発と運用LiBRA 06.2021 / 開発と運用
LiBRA 06.2021 / 開発と運用Masanori Saito
 
LiBRA 08.2021 / Strategy DX以外
LiBRA 08.2021 / Strategy DX以外LiBRA 08.2021 / Strategy DX以外
LiBRA 08.2021 / Strategy DX以外Masanori Saito
 
LiBRA 10.2021 / DX以外
LiBRA 10.2021 / DX以外LiBRA 10.2021 / DX以外
LiBRA 10.2021 / DX以外Masanori Saito
 
LiBRA 09.2021 / 開発と運用
LiBRA 09.2021 / 開発と運用LiBRA 09.2021 / 開発と運用
LiBRA 09.2021 / 開発と運用Masanori Saito
 
LiBRA 09.2021 / DX以外
LiBRA 09.2021 / DX以外LiBRA 09.2021 / DX以外
LiBRA 09.2021 / DX以外Masanori Saito
 
LiBRA 05.2021 / Strategy_other
LiBRA 05.2021 / Strategy_otherLiBRA 05.2021 / Strategy_other
LiBRA 05.2021 / Strategy_otherMasanori Saito
 
LiBRA_210201/Biz Strategy
LiBRA_210201/Biz StrategyLiBRA_210201/Biz Strategy
LiBRA_210201/Biz StrategyMasanori Saito
 
LiBRA 06.2021 / クラウドコンピューティング
LiBRA 06.2021 / クラウドコンピューティングLiBRA 06.2021 / クラウドコンピューティング
LiBRA 06.2021 / クラウドコンピューティングMasanori Saito
 

La actualidad más candente (20)

LiBRA 07.2021 / 開発と運用
LiBRA 07.2021 / 開発と運用LiBRA 07.2021 / 開発と運用
LiBRA 07.2021 / 開発と運用
 
211101_LiBRA_AI
211101_LiBRA_AI211101_LiBRA_AI
211101_LiBRA_AI
 
LiBRA 05.2021 / Infra
LiBRA 05.2021 / InfraLiBRA 05.2021 / Infra
LiBRA 05.2021 / Infra
 
LiBRA 04.2019 / ビジネス戦略編
LiBRA 04.2019 / ビジネス戦略編LiBRA 04.2019 / ビジネス戦略編
LiBRA 04.2019 / ビジネス戦略編
 
LiBRA 09.2021 / AI
LiBRA 09.2021 / AILiBRA 09.2021 / AI
LiBRA 09.2021 / AI
 
LiBRA 12.2020 / 開発と運用
LiBRA 12.2020 / 開発と運用LiBRA 12.2020 / 開発と運用
LiBRA 12.2020 / 開発と運用
 
LiBRA_210201/Infra&platform
LiBRA_210201/Infra&platformLiBRA_210201/Infra&platform
LiBRA_210201/Infra&platform
 
LiBRA 06.2021 / DX
LiBRA 06.2021 / DXLiBRA 06.2021 / DX
LiBRA 06.2021 / DX
 
LiBRA 06.2021 / 開発と運用
LiBRA 06.2021 / 開発と運用LiBRA 06.2021 / 開発と運用
LiBRA 06.2021 / 開発と運用
 
LiBRA_210201/AI
LiBRA_210201/AILiBRA_210201/AI
LiBRA_210201/AI
 
LiBRA 08.2021 / Strategy DX以外
LiBRA 08.2021 / Strategy DX以外LiBRA 08.2021 / Strategy DX以外
LiBRA 08.2021 / Strategy DX以外
 
LiBRA 10.2021 / DX以外
LiBRA 10.2021 / DX以外LiBRA 10.2021 / DX以外
LiBRA 10.2021 / DX以外
 
LiBRA 09.2021 / 開発と運用
LiBRA 09.2021 / 開発と運用LiBRA 09.2021 / 開発と運用
LiBRA 09.2021 / 開発と運用
 
LiBRA 09.2021 / DX以外
LiBRA 09.2021 / DX以外LiBRA 09.2021 / DX以外
LiBRA 09.2021 / DX以外
 
LiBRA 05.2021 / Strategy_other
LiBRA 05.2021 / Strategy_otherLiBRA 05.2021 / Strategy_other
LiBRA 05.2021 / Strategy_other
 
211101_LiBRA_DX以外
211101_LiBRA_DX以外211101_LiBRA_DX以外
211101_LiBRA_DX以外
 
LiBRA_210201/Biz Strategy
LiBRA_210201/Biz StrategyLiBRA_210201/Biz Strategy
LiBRA_210201/Biz Strategy
 
LiBRA 05.2020 / AI
LiBRA 05.2020 / AILiBRA 05.2020 / AI
LiBRA 05.2020 / AI
 
LiBRA 06.2021 / クラウドコンピューティング
LiBRA 06.2021 / クラウドコンピューティングLiBRA 06.2021 / クラウドコンピューティング
LiBRA 06.2021 / クラウドコンピューティング
 
LiBRA 10.2021 / ERP
LiBRA 10.2021 / ERPLiBRA 10.2021 / ERP
LiBRA 10.2021 / ERP
 

Similar a LiBRA 10.2021 / 開発と運用

LiBRA 03.2021 / DevOps
LiBRA 03.2021 / DevOpsLiBRA 03.2021 / DevOps
LiBRA 03.2021 / DevOpsMasanori Saito
 
LiBRA 04.2021 / DevOps
LiBRA 04.2021 / DevOpsLiBRA 04.2021 / DevOps
LiBRA 04.2021 / DevOpsMasanori Saito
 
LiBRA 11.2020 / 開発と運用
LiBRA 11.2020 / 開発と運用LiBRA 11.2020 / 開発と運用
LiBRA 11.2020 / 開発と運用Masanori Saito
 
LiBRA 07.2021 / インフラとプラットフォーム
LiBRA 07.2021 / インフラとプラットフォームLiBRA 07.2021 / インフラとプラットフォーム
LiBRA 07.2021 / インフラとプラットフォームMasanori Saito
 
LiBRA 06.2021 /インフラとプラットフォーム
LiBRA 06.2021 /インフラとプラットフォームLiBRA 06.2021 /インフラとプラットフォーム
LiBRA 06.2021 /インフラとプラットフォームMasanori Saito
 
LiBRA 09.2021 / インフラストラクチャー
LiBRA 09.2021 / インフラストラクチャーLiBRA 09.2021 / インフラストラクチャー
LiBRA 09.2021 / インフラストラクチャーMasanori Saito
 
LiBRA 03.2021 / Infra & Platform
LiBRA 03.2021 / Infra & PlatformLiBRA 03.2021 / Infra & Platform
LiBRA 03.2021 / Infra & PlatformMasanori Saito
 
LiBRA 10.2020 / 開発と運用
LiBRA 10.2020 / 開発と運用LiBRA 10.2020 / 開発と運用
LiBRA 10.2020 / 開発と運用Masanori Saito
 

Similar a LiBRA 10.2021 / 開発と運用 (20)

LiBRA 03.2021 / DevOps
LiBRA 03.2021 / DevOpsLiBRA 03.2021 / DevOps
LiBRA 03.2021 / DevOps
 
LiBRA 04.2021 / DevOps
LiBRA 04.2021 / DevOpsLiBRA 04.2021 / DevOps
LiBRA 04.2021 / DevOps
 
LiBRA 11.2020 / 開発と運用
LiBRA 11.2020 / 開発と運用LiBRA 11.2020 / 開発と運用
LiBRA 11.2020 / 開発と運用
 
LiBRA 07.2021 / インフラとプラットフォーム
LiBRA 07.2021 / インフラとプラットフォームLiBRA 07.2021 / インフラとプラットフォーム
LiBRA 07.2021 / インフラとプラットフォーム
 
LiBRA 06.2021 /インフラとプラットフォーム
LiBRA 06.2021 /インフラとプラットフォームLiBRA 06.2021 /インフラとプラットフォーム
LiBRA 06.2021 /インフラとプラットフォーム
 
LiBRA 09.2021 / インフラストラクチャー
LiBRA 09.2021 / インフラストラクチャーLiBRA 09.2021 / インフラストラクチャー
LiBRA 09.2021 / インフラストラクチャー
 
LiBRA 03.2021 / Infra & Platform
LiBRA 03.2021 / Infra & PlatformLiBRA 03.2021 / Infra & Platform
LiBRA 03.2021 / Infra & Platform
 
LiBRA 04.2021 / IoT
LiBRA 04.2021 / IoTLiBRA 04.2021 / IoT
LiBRA 04.2021 / IoT
 
LiBRA 07.2021 / AI
LiBRA 07.2021 / AILiBRA 07.2021 / AI
LiBRA 07.2021 / AI
 
LiBRA 06.2021 / IoT
LiBRA 06.2021 / IoTLiBRA 06.2021 / IoT
LiBRA 06.2021 / IoT
 
LiBRA 05.2021 / IoT
LiBRA 05.2021 / IoTLiBRA 05.2021 / IoT
LiBRA 05.2021 / IoT
 
LiBRA 07.2021 / IoT
LiBRA 07.2021 / IoTLiBRA 07.2021 / IoT
LiBRA 07.2021 / IoT
 
LiBRA 04.2021 / AI
LiBRA 04.2021 / AILiBRA 04.2021 / AI
LiBRA 04.2021 / AI
 
211001_LiBRA_IoT
211001_LiBRA_IoT211001_LiBRA_IoT
211001_LiBRA_IoT
 
LiBRA 06.2021 / AI
LiBRA 06.2021 / AILiBRA 06.2021 / AI
LiBRA 06.2021 / AI
 
LiBRA_210201/IoT
LiBRA_210201/IoTLiBRA_210201/IoT
LiBRA_210201/IoT
 
LiBRA 10.2020 / 開発と運用
LiBRA 10.2020 / 開発と運用LiBRA 10.2020 / 開発と運用
LiBRA 10.2020 / 開発と運用
 
LiBRA 10.2021 / AI
LiBRA 10.2021 / AILiBRA 10.2021 / AI
LiBRA 10.2021 / AI
 
LiBRA 09.2021 / DX
LiBRA 09.2021 / DXLiBRA 09.2021 / DX
LiBRA 09.2021 / DX
 
LiBRA 09.2021 / IoT
LiBRA 09.2021 / IoTLiBRA 09.2021 / IoT
LiBRA 09.2021 / IoT
 

Más de Masanori Saito

211101_最新トレンド_パッケージ
211101_最新トレンド_パッケージ211101_最新トレンド_パッケージ
211101_最新トレンド_パッケージMasanori Saito
 
LiBRA 10.2021 /クラウドコンピューティング
LiBRA 10.2021 /クラウドコンピューティングLiBRA 10.2021 /クラウドコンピューティング
LiBRA 10.2021 /クラウドコンピューティングMasanori Saito
 
LiBRA 10.2021 / DXとこれからのビジネス
LiBRA 10.2021 / DXとこれからのビジネスLiBRA 10.2021 / DXとこれからのビジネス
LiBRA 10.2021 / DXとこれからのビジネスMasanori Saito
 
LiBRA 10.2021 / DXの基本
LiBRA 10.2021 / DXの基本LiBRA 10.2021 / DXの基本
LiBRA 10.2021 / DXの基本Masanori Saito
 
LiBRA 10.2021 / 総集編#02
LiBRA 10.2021 / 総集編#02LiBRA 10.2021 / 総集編#02
LiBRA 10.2021 / 総集編#02Masanori Saito
 
LiBRA 10.2021 / 総集編#01
LiBRA 10.2021 / 総集編#01LiBRA 10.2021 / 総集編#01
LiBRA 10.2021 / 総集編#01Masanori Saito
 
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修LiBRA 09.2021 / 新入社員のための最新ITトレンド研修
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修Masanori Saito
 
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向けLiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向けMasanori Saito
 
LiBRA 09.2021 / 総集編 1/2
LiBRA 09.2021 / 総集編 1/2LiBRA 09.2021 / 総集編 1/2
LiBRA 09.2021 / 総集編 1/2Masanori Saito
 
LiBRA 09.2021 / 総集編 2/2
LiBRA 09.2021 / 総集編 2/2LiBRA 09.2021 / 総集編 2/2
LiBRA 09.2021 / 総集編 2/2Masanori Saito
 

Más de Masanori Saito (17)

211101_DXの基礎
211101_DXの基礎211101_DXの基礎
211101_DXの基礎
 
211101_最新トレンド_パッケージ
211101_最新トレンド_パッケージ211101_最新トレンド_パッケージ
211101_最新トレンド_パッケージ
 
211101_DevOps
211101_DevOps211101_DevOps
211101_DevOps
 
211101_LiBRA_DX
211101_LiBRA_DX211101_LiBRA_DX
211101_LiBRA_DX
 
211101_LiBRA_ERP
211101_LiBRA_ERP211101_LiBRA_ERP
211101_LiBRA_ERP
 
LiBRA 10.2021 / ERP
LiBRA 10.2021 / ERPLiBRA 10.2021 / ERP
LiBRA 10.2021 / ERP
 
LiBRA 10.2021 / DX
LiBRA 10.2021 / DXLiBRA 10.2021 / DX
LiBRA 10.2021 / DX
 
LiBRA 10.2021 /クラウドコンピューティング
LiBRA 10.2021 /クラウドコンピューティングLiBRA 10.2021 /クラウドコンピューティング
LiBRA 10.2021 /クラウドコンピューティング
 
LiBRA 10.2021 / IoT
LiBRA 10.2021 / IoTLiBRA 10.2021 / IoT
LiBRA 10.2021 / IoT
 
LiBRA 10.2021 / DXとこれからのビジネス
LiBRA 10.2021 / DXとこれからのビジネスLiBRA 10.2021 / DXとこれからのビジネス
LiBRA 10.2021 / DXとこれからのビジネス
 
LiBRA 10.2021 / DXの基本
LiBRA 10.2021 / DXの基本LiBRA 10.2021 / DXの基本
LiBRA 10.2021 / DXの基本
 
LiBRA 10.2021 / 総集編#02
LiBRA 10.2021 / 総集編#02LiBRA 10.2021 / 総集編#02
LiBRA 10.2021 / 総集編#02
 
LiBRA 10.2021 / 総集編#01
LiBRA 10.2021 / 総集編#01LiBRA 10.2021 / 総集編#01
LiBRA 10.2021 / 総集編#01
 
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修LiBRA 09.2021 / 新入社員のための最新ITトレンド研修
LiBRA 09.2021 / 新入社員のための最新ITトレンド研修
 
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向けLiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
 
LiBRA 09.2021 / 総集編 1/2
LiBRA 09.2021 / 総集編 1/2LiBRA 09.2021 / 総集編 1/2
LiBRA 09.2021 / 総集編 1/2
 
LiBRA 09.2021 / 総集編 2/2
LiBRA 09.2021 / 総集編 2/2LiBRA 09.2021 / 総集編 2/2
LiBRA 09.2021 / 総集編 2/2
 

Último

情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 

Último (12)

情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 

LiBRA 10.2021 / 開発と運用