SlideShare una empresa de Scribd logo
1 de 54
Descargar para leer sin conexión
エンタープライズにおけるDevOpsの実態!
-Cloud Native Application Platformの選択-
Developers Summit 2017 【17-E-5】
ハッシュタグ: #devsumiE
日本ヒューレット・パッカード株式会社
北山 晋吾
2
自己紹介
元楽天株式会社 所属
国際ECサービスのインフラ部門
日本ヒューレット・パッカード株式会社 所属
テクニカルアーキテクト
テクノロジーコンサルティング事業統括
クロス・インダストリ・ソリューション統括本部
テクノロジーアーキテクト部
好評発売中
http://amzn.asia/ghfpKwi
2016年末「Ansible実践ガイド」執筆
北山晋吾
経歴など
もーど1のかお
shkitayama spchildren
3
本日のAgenda
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
4
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
5
2017年
エンタープライズは何が変わったのか!?
Transform
to Digital Business
6
2017年デジタルビジネス時代
アイデアエコノミーのビジネストラディショナルなビジネス
バイモーダルITへの対応
サービス
コスト効率化・堅牢性重視
顧客
主にシステム部門
競合
国内大手IT SIer
サービス
スピード、流動性重視
顧客
主に事業部門
競合
海外大手クラウドベンダー
デジタル・ビジネスとは、仮想と物理の世界を融合して人/モノ/ビジネスが直接つながり、顧客との関
係が瞬時に変化していく状態が当たり前のビジネス形態のこと。
27.3%
11.5%
28.5%
17.6%
13.3%
7参照: https://www.gartner.co.jp/press/html/pr20161118-01.html
日本企業のデジタル・ビジネスの現状
全く取り組んでいない
その他
日本企業のデジタルビジネスへの取り組み
出展:ガートナー2016/08 (n=165)
既に一定数の企業がデジタル・ビジネスに取り組んでいるものの、成果が挙がっている企業は一部。
部門レベルでは取り組んでいる
が成果は出ていない
全社レベルで取り組んでいる
が成果は出ていない
全社レベルで取り組んでお
り、成果が挙がっている
部門レベルで取り組ん
でおり、成果が挙がっ
ている日本企業の約70%がデジタルビジネ
スに取り組んでいるものの、成果が挙がっ
ているのは全体の25%程度。
25%
8
バイモーダルITとは
そもそもバイモーダルITとは、企業システムの特性を分けて適切なリソースを配分するための概念
Mode1 従来型の企業ITに不可欠な堅牢性を維持する
Mode2 ビジネスイノベーションに対応する俊敏性を実現する
Gartnerによるカテゴリ Mode1 Mode2
ジェフリー・ムーア氏の提唱 SoR (System of Record) SoE (System of Engagement)
アプリケーション
アーキテクチャ
トラディショナルアプリケーション
(Monolithic Architecture)
クラウドネイティブアプリケーション
(Microservice Architecture)
システム特性 正確性、安全性、堅牢性 迅速性、柔軟性、スケーラビリティ
開発手法 ウォーターフォール型 アジャイル型
投資判断ポイント 投資対効果(ROI)に基づいた投資
業務システムの維持とコスト削減
ビジネスチャンスに基づいた投資
新たなチャレンジ
顧客提供価値 ITセントリック、効率性 ユーザー体験、スピード
人材とスキル 信頼性、コスト効率化重視 試験的な取り組みを重視
Mode2
9
バイモーダルITの捉え方
Mode1
・Webシステム
Web系企業
・基幹システム
銀行、通信などSIer
が得意とする業界
業界や企業単位で区切ることは、
あまり意味がない。
どのサービスにおいても、Mode1の要素とMode2
の要素があり、そのリソース配分を設計するた
めの枠組み。
Mode1/Mode2のリソースの分類基準は、ビジネスのス
ピードとスケールの違い。
Mode2
Mode1 Mode2
Mode1
サービス サービス
企業
サービスが成功する
と、安定を優先せざ
るを得ない
(金のなる木事業)
サービスが成功する
までは、スピードと
柔軟性に対応
(スター事業)
10
バイモーダルITの本質
バイモーダルなシステムを目指すことは重要だが、本質的には組織の問題である。
教科書的な示唆
堅牢性と流動性の双方の要素を分けて、バイモーダルITに取り組むべきである。
以下のような価値観は不適切…
・Mode1からMode2へ移行しないといけない。(Mode1からMode2に移ることはない。)
・Mode2の業界だから、Mode1のシステムは関係無い。
本質的な示唆
自社の業務やシステムのMode1 / Mode2の比率に合わせて、組織構造(人的リソース)やプラット
フォーム(システムリソース)の割合を調整するべきである。
11
バイモーダルITで再分配すべきリソース
いままでと同様のリソース配分で投資を行っていては、バイモーダルの特徴を活かすことができず、プロ
ジェクトが進まない。
アプリケーションから
生成されたデータを、
自社のITのために利用
すべきか、顧客満足度
向上のために利用すべ
きかで、異なるノウハ
ウが必要になる。
Mode1では、堅牢性、
正確性を重視した開発
プロセスに対し、
Mode2ではスピードを
重視した柔軟な開発プ
ロセスが必要となる。
スケールアップ型のト
ラディショナルアプリ
ケーションと、スケー
ルアウト型のクラウド
ネイティブアプリケー
ションの設計が必要に
なる。
オンプレミスな環境だ
けでなく、パブリック
クラウドと連携した、
ハイブリッド環境を設
計することが必要にな
る。
年度予算ではなく、経
営戦略の方針変更に伴
い、突然のプロジェク
トへの予算を確保でき
る仕組み(予算のア
ジャイル化)が必要に
なる。
Knowledge Process Technology ArchitectureCost
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
12
これまでのビジネスを支える開発プラットフォーム
これまでは、仮想化環境の上で業務システムの安定稼働とコスト削減を図ることがITのあるべき姿。
ITIL
Monolithic Services
Virtual Machine
Cloud
Biz
(事業部門)
開発&運用
(システム部門)
SIer
System
正確性
安全性
堅牢性
Mode1(SoR)
Platform
Mode1
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
13
バイモーダルを支える開発プラットフォーム
ビジネスの迅速性にあわせてプラットフォームを選択できる柔軟な設計が必要。
DevOps
Micro Services
Containers
Cloud
ITIL
Monolithic Services
Virtual Machine
Cloud
Mode1 Mode2
SIer
Biz
(事業部門)
開発 & 運用
(システム部門)
Biz
(事業部門)
Mode1
(SoR)
Mode2
(SoE)
System
安全性
迅速性
柔軟性
スケーラブル
正確性
堅牢性
Platform
14
バイモーダルITにおける課題
もちろんバイモーダルに対応するためには、適切なリソース配分(組織体系とプラットフォーム)が必要と
なる。
Biz
(事業部門)
SIer
正確性
安全性
堅牢性
SIer
安全性
迅速性
開発 & 運用
(システム部門)
Biz
(事業部門)
Biz
(事業部門)
柔軟性
スケーラブル
正確性
堅牢性
Mode1
(SoR)
Mode2
(SoE)
System
Platform
開発&運用
(システム部門)
System
Mode1(SoR)
Platform
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
15
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
16
組織構造とシステムアーキテクチャ
Mode1とMode2のシステムに対して適切にリソースを展開するためには、システムリソースに合わせた組
織構造をとる必要がある。
コンウェイの法則 (Melvin Conway)
システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に模倣した構造
を持つ設計を生み出す。
参照: 「System of Record と System of Engagement」 by Naoya Ito
Mode1 (SoR)
チーム
Mode2 (SoE)
チーム
プラットフォームチーム
事業部門
Mode1チーム
標準化して、安定稼働していくことが目標。
Mode2チーム
トライアンドエラーで迅速性を高めることが
目標。
プラットフォームチーム
両者の技術基盤を支えていく。
40.6%
29.4%28.1%
17参照: https://www.gartner.co.jp/press/html/pr20160601-01.html
バイモーダルを推進する組織構成
新組織の立ち上げ
組織としての責任/権限を設定できる一方で、予
算やリソースを別途確保する必要がある。
従来のIT組織に専門チームを設立
取り組みやすさがある一方で、事業部門にプロ
ジェクトの価値や成果をダイレクトに伝えにくい。
タスクフォースの結成
事業部門との協業は進む一方で、成果物やゴール
が曖昧になりやすい。
従来のIT組織と
は別の新組織
従来のIT組織内の
専門チーム
事業部門との
タスクフォース
その他
「バイモーダル」なIT組織の構成
出展:ガートナー2016/05 (n=160)
バイモーダルを推進する組織構成の多くは、以下の3構成から成り立っている。
バイモーダルを推進するチームの40%は既存のIT組
織から構成されている。
18
既存のIT組織からバイモーダル対応の組織構造へ
バイモーダルにおけるシステムは、信頼性だけでなく、スピードや柔軟性を重視しているため、運用チー
ムに求められる役割が大きく変わる。
Mode1 (SoR)
チーム
Mode2 (SoE)
チーム
プラットフォームチーム
事業部門
Mode1 (SoR)
チーム
システム運用
チーム
事業部門
•利用方法についての問い合わせ業務
•決まったオペレーションを実施する定常業務
•障害対応
•システムの管理業務
(構成管理やキャパシティー管理など)
•システムの安定性だけでなく、迅速性のあるシステム基盤を設計
•運用管理の自動化の仕組みを設計・構築
•標準化されたポリシーやルールの整備
バイモーダル対応の組織
運用チームの変化
既存のIT組織
19
プラットフォームチームに必要な人材とは?
20
プラットフォームチームのメンバーに求められる能力
たとえば…。
・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用
・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善
・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用
・デプロイや各種オペレーション自動化ツールの開発、運用
・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用
・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用
・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用
などなど
・サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務
・システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用
参照: https://www.mercari.com/jp/jobs/sre/
21
プラットフォームチームのメンバーに求められる能力
たとえば…。
・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用
・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善
・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用
・デプロイや各種オペレーション自動化ツールの開発、運用
・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用
・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用
・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用
などなど
サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務。
システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用。
参照: https://www.mercari.com/jp/jobs/sre/
実は、これmercariさんの採用情報...
22
SRE(Site Reliability Engineer)とは
Google のプロダクトやサイトを安定運用する役割り。オペレーションチームによって行われた作業をソフ
トウェアを利用し、手作業を自動化に代えていくことが求められる。
つまり、『すべてがソフトウェアの問題として扱われる』というアプローチを取って作業を行うエンジニア。
サーバー管理者としての役割り
・インフラの自動化
・障害対応
・システムの維持
ソフトウェアエンジニアとしての役割り
・サイトのパフォーマンスを改善
・可用性、スケーラビリティを向上
参照: https://landing.google.com/sre/book.html
23
SREへのステップアップ
いままでオペレーターだった人たちが、急にSREになれるわけではない。
ソフトウェア化を推進する中で、価値を生み出し役割りの幅を広げることが重要。
Mode1の延長 Mode2への対応
キャズムの壁
オペレーター 構成管理の自動化 クラウド基盤の管理
アプリケーション
開発基盤の管理
アプリ改善
既存のシステムをAnsibleやChefなど
の構成管理ツールを利用して、自動
化を図り、手作業の工数を削減。
APIを利用したハイブリッドクラウド環
境のコントロール。また、OpenStackな
どの統合管理ソリューションの利用。
アプリケーションのパフォーマンス改善、
オートスケール、動的障害復旧などの
サービス品質の向上。
Dockerコンテナの管理やアプリケー
ションパッケージのトラブルシュー
ティングなどのサービス管理
24
運用チームの意識変化
バイモーダル対応の組織では、アプリケーションの迅速性が求められると同時に、
運用チームの意識の変化が鍵となる。
Mode1 (SoR)
チーム
Mode2 (SoE)
チーム
事業部門
Mode1 (SoR)
チーム
事業部門
運用チームの変化
他のチームと共通人材プール。
つまり、SREメンバーを増やす
と、必然的に開発チームの稼
動を減らせることが期待。
SREへのステップ
オペレーター 構成管理の自動化 クラウド基盤の管理
アプリケーション
開発基盤の管理
アプリ改善
Site Reliability Engineering
システム運用
チーム
バイモーダル対応の組織既存のIT組織
25
組織構造の改革のまとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
バイモーダルを推進する組織構成は、既存組織のメン
バーから構成されることが多い。
既存組織のメンバーから構成する場合は、システム運用
者の役割りが変わることを意識する必要がある。
既存のシステム運用者が、いきなりSREになれるわけでは
なく、徐々に対応範囲を広げていくことが求められる。
組織構造の改革には時間がかかるが、これらを変えずにバイモーダルを実践することはできない。
SREの育成
26
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
27
バイモーダルに対応するプラットフォーム
これらを迅速かつ、柔軟に提供できるプラットフォームがあれば、ビジネスは飛躍的向上する。
Cloud Native Application Platformでは、従来のアプリケーションよりも運用工数を減らし、開発工数を上げ
ていくことが求められる。
HWやOSのセットアップ
ランタイムのビルド ライブラリの管理
アプリケーション開発基盤
- Cloud Native Application Platform -
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
28
バイモーダルを支える開発プラットフォーム
Cloud Native Application Platformの選択肢は、「Platform as a Service(PaaS)」または「Container
Orchestration」の2つが主流。
DevOps
Micro Services
Containers
Cloud
ITIL
Monolithic Services
Virtual Machine
Cloud
Mode1 Mode2
Cloud Native
Application Platform
の選択
- PaaS
- Container Orchestration
※パブリッククラウドかオンプレミスかは別の話。
- 構成管理の自動化
Cloud Native Application Platformの機能
29
PaaS
コンテナをマルチノード上でスケーラブルに立ち上げるコンテナ管理ツール
コンテナで機能するアプリケーションを管理するためには、インテリジェントに
クラスタ管理する必要があり、そのためのオーケストレーションが必要。
Infrastructure
Private Cloud / Public Cloud
Cloud Native Application Platform
アプリケーションライフサイクル基盤のプラットフォーム
アプリケーション実行環境の提供に加え、システム開発におけるソースコードの
保存から、リリースまでの一連の流れを含むサービス。コードをリポジトリに登
録しておくと、チェックアウト、ビルド、アプリケーションサーバーへのデプロ
イまでを実行してくれる。
両者が提供する機能
・マルチホストコンテナ環境
・ルーティングなどの付加サービス
・オートスケール、障害検知の仕組み
・デプロイ(CI)機能
両者のプロダクト背景は異なるが、機能だけ見ると似ているところに収束している。
Availability (可用性)
オートスケール
アクセスルーティング
自動リカバリ
Security (セキュリティ)
テナント管理/分離
アプリのアクセス制御
Maintainability (運用/保守性)
継続的デリバリ(CI)機能
バージョン管理
障害検知
Container Orchestration
30
Private Cloud Public CloudHybrid Cloud
PaaSの導入環境とプロダクト
PaaSは独自技術が多くそれぞれ特徴があるが、移植性と相互運用性を提供しはじめている。
商標: それぞれのロゴは、各社/組織団体の登録商標です。
Technology Stack
(Open PaaS)
Solution Stack
(Proprietary PaaS)
Proprietary
Technology
Technology Stack
31
Private Cloud Public Cloud
Dockerコンテナ自体がポータビリティがあるため、色が付けづらくソリューションが複雑化している。
Container Orchestrationの導入環境とプロダクト
Hybrid Cloud
商標: それぞれのロゴは、各社/組織団体の登録商標です。
Solution Stack
32
Cloud Native Application Platformを導入検討する際のポイント
根本的には、クラウドを選択する際と代わりはないが、間違えて選択するとアプリケーション開発のボト
ルネックとなってしまう。
運用も含め、社内のケ
イパビリティだけで補
える技術なのか、外部
に委託するのか。
プラットフォーム導入
の重視したい点が、ア
プリケーション開発の
迅速化なのか、コスト
削減なのか。
独自の技術で構成され
ているのか、もしくは
ポータビリティのある
デファクトスタンダー
ド技術で構成されてい
るのか。
オンプレ上だけでなく、
パブリッククラウド上
でハイブリッド展開が
可能か。
CAPEXとOPEXが妥当な
のか。オンプレ製品で
もOPEXがかかるもの
もある。
Knowledge Process Technology ArchitectureCost
デプロイ環境の確認 依存性の確認導入目的の確認ケイパビリティの確認費用対効果の確認
33
(補足) Container Orchestrationの利用状況
Container Orchestrationは、Kubernetesの利用の人気が高まっている。
参照: https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2016.pdf
Container Market Adoption
出展: DevOps.com & ClusterHQ 2016/04 (n=218)
Container Orchestrationを検討している企業の
30%はKubernetesを利用している。
34
Today, the community is seeing widespread
adoption of Kubernetes, a system with origins at
Google that is becoming the de facto standard
for open source container orchestration.
現在コミュニティは、オープンソースコンテ
ナオーケストレーションのデファクトスタン
ダードになっているGoogleのKubernetesの普
及を目の当たりにしています。
(補足) Container Orchestrationのデファクトスタンダード
CoreOSがfleetの開発を終了し、代わりにKubernetesを採用することとなった。(February 7, 2017)
参照: https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html
35
PaaSとContainer Orchestrationはどう使い分けるの ?
開発成果物
(Artifact)
36
アプリケーションエンジニアの開発成果物
ソースコードの
アップロード
言語、フレーム
ワークの選定
ミドルウェアの
設定
アプリパッケージ
の作成
パッケージを
デプロイ
(Build Pack)
通常、アプリケーションデプロイのフローでは開発成果物(Artifact)に違いがでてくる。
ソースコードの
アップロード
言語、フレーム
ワークの選定
ミドルウェアの
設定
コンテナイメージ
の作成
Dockerイメージ
をデプロイ
(Docker Image)
PaaS
Container Orchestration
※ただし、近年Docker型のPaaSも増えてきている。
アプリケーション
エンジニア
アプリケーション
エンジニア
デプロイ テスト
37
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリケーション
Infrastructure
as code
アプリケーション
エンジニア
SRE
アプリケーション開発
構成管理の自動化
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト
Continuous
Integration
CIツール
開発成果物の展開 機能/結合テスト
アプリケーション
単体テスト
application
code
ビルド/テスト
自動化ツール
IaaS
アプリエンジニアは、アプリのデプロイ
SREは、VMのデプロイ
Mode1のCIパイプラインと役割り
イメージ化
VMテンプレートの管理
デプロイ テスト
38
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリパッケージ
コンテナイメージアプリケーション
エンジニア
SRE
アプリケーション開発
PaaS / Container Orchestration
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト
開発成果物の展開 機能/結合テスト
アプリケーション
単体テスト
application
code
ビルド/テスト
自動化ツール
PaaS
Container Orchestration
Mode2のCIパイプラインと役割り
Continuous
Integration
CIツール
NoOps
※ソフトウェアによる可用性、スケーラビリティ向上に専念
アプリエンジニアは、アプリのデプロイ
デプロイ テスト
39
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリパッケージ
コンテナイメージアプリケーション
エンジニア
SRE
アプリケーション開発
PaaS / Container Orchestration
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト
開発成果物の展開 機能/結合テスト
アプリケーション
単体テスト
application
code
ビルド/テスト
自動化ツール
PaaS
Container Orchestration
Mode2のCIパイプラインと役割り
Continuous
Integration
CIツール
NoOps
※ソフトウェアによる可用性、スケーラビリティ向上に専念
アプリエンジニアは、アプリのデプロイ
Containerの管理は誰の責任?
40
Cloud Native Application Platformの選択
PaaS
Container
Orchestration
CIパイプラインにおける現状の責務によって、プラットフォームを選択すると導入が行いやすい。
現状の責務 導入後の責務
アプリケーション
エンジニア
インフラ
エンジニア
アプリケーション
エンジニア
Site Reliability
Engineering
- アプリデプロイ - VMの実行管理
- リリース作業
- 開発成果物の作成
(コンテナイメージ)
- コンテナの実行管理
- リリース作業
- アプリデプロイ
- VMの実行管理
- リリース作業
- VMの払い出し
- リソース監視
- 開発成果物の作成
(コンテナイメージ.ア
プリパッケージ)
- リリース作業
- コンテナ/アプリの
実行管理
- 運用の完全自動化
- アプリパフォーマン
ス改善
Dev vs Opsなチーム
DevOpsなチーム
アプリエンジニアに
デプロイの操作権限
を付与していく
41
コードレポジトリ
・GitHub Enterprise
・Bitbucket
・GitLab
CIツール
・Jenkins
・Circle CI
・Travis CI
・Concourse CI
成果物レポジトリ
・Jfrog Artifactory
・Github Enterprise
コンテナイメージレ
ポジトリ
・Docker Trusted
Repository
PaaS
・Cloud Foundry
・Heroku
・Bluemix
Container
Orchestration
・Docker Datacenter
・Mesosphere
・Kubernetes
構成管理の自動化
・Ansible
・Chef
※凡例
手動タスク
自動化タスク
機能テストツール
・UFT
・Selenium
・Appium
・JMeter
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト開発環境
CI環境
ステージング環境
QA環境
本番環境
利用ツール例
デプロイ 機能テスト
コード
反映
コード
反映
デプロイ リリース
Issue Tracking
・JIRA
・Redmine
Promote
Promote
開発成果物の管理
開発成果物の管理
CI/CDのプラットフォーム選択
プラットフォームの選択が一番CI/CDのプロセスに影響を及ぼす。
アプリケーションのアーキテクチャおよ
び非機能要件/運用要件によって選択
42
プラットフォームの改革のまとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
バイモーダルのうちMode2を支えるプラットフォームは、
「PaaS」と「Container Orchestration」が主流。
PaaSとContainer Orchestrationの機能は似ているが、
提供可否はベンダーに寄って色があるため、目的にあっ
たものを選択する。
PaaSとContainer Orchestrationは、既存のCIパイプラ
インの役割りによって導入を選択する。
プラットフォームの選択次第でアプリケーションのアーキテクチャやプロセスが変わる。
現状のプロセスにあった
プラットフォームの選択
43
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
44
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
2017年デジタルビジネスが加速し、バイモーダルITへの
対応が必然となる。
SREの育成と現状のプロセスにあったプラットフォーム
の選択が必要。
自社の業務やシステムのMode1/Mode2の比率に合わせ
て、組織構造とプラットフォームの割合を戦略的に配置
できた企業が競争優位性を築くことができる。
デジタルビジネス時代で生き残る組織
戦略的リソース配置
(逆コンウェイの法則)
45
はじめるには、何からすればいいの?
46
バイモーダルITへのステップ
バイモーダルへのステップは、DevOps導入のステップと同じ。
メンバーの構成
現状分析
ゴールの設定
POCの実施
フィードバック
まずは組織、プラット
フォームにおける課題
を見つけ、そのボトル
ネックを探す。
あるべきCIのパイプラ
インや役割り、システ
ムの構成を計画する。
・チーム体制
・スケジュール
・アーキテクチャ
ゴールに近づけるか否
かを判断する材料を集
める。
・スピード開発
・事業部門予算で対応
POCの成功可否で実
サービスへの展開を判
断
・継続的プロセス改善
・CI/CDの導入
やるべきことに優
先順位をつける
この時点で標準化
しない
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
ユーザーが主導 ベンダーと共創
47
Appendix
- HPEのバイモーダルソリューション -
商標: それぞれのロゴは、各社/組織団体の登録商標です。
HPEのクラウド戦略
Hybrid management
HPE Helion and HPE Partner Professional Services
Traditional workload orchestration cloud-native orchestration
Amazon
Web
Services
Microsoft
Azure
Cloud
Service
Providers
Eucalyptus
HPE Helion
OpenStack®
Azure
Stack
HPE Synergy, HPE ConvergedSystem,
HPE CloudSystem, HPE ProLiant
Private or managed clouds
Emerging
Platforms
(Mesos, etc.)
vSphere
Public
cloud
Public
cloud
Legacy
Existing
HPEのクラウド戦略は、マルチベンダー&ハイブリッド化。
Mode1でもMode2でもクラウド層を安定化させることは変わらない。
49
開発成果物の管
理形態
中心となるソフトウェ
ア
特徴 対応するインフラ
PaaS アプリケーショ
ンパッケージ
HPE Helion Stackato • 多様なアプリケーションフレームワークに対応するBuildpack
によりソースコードからアプリケーションランタイムを自動
ビルド
• ルーティング、ロードバランス、ログ集約などエンタープラ
イズアプリケーションに必要な機能を統合
• バックエンドサービス(DBなど)に接続するためのサービス
ブローカー
• CIツール(Helion Code Engine)が付属し、シンプルなCI/CDがこ
れだけで完結
• vSphere,AWS,OpenStack
• Azureにも対応予定
• CloudFoundry準拠のパブリックPaaS
とのアプリケーション互換性(IBM
Bluemix, NTT-com ECL/Cloudn, Pivotal
Web Service, 富士通 K5, GE Predixな
ど)
Container
Orchestration
Dockerイメージ Docker Datacenter • Docker Engineの基本機能に、クラスタ管理機能(Swarm)を統
合
• Docker社が提供するツールのみでシンプルなコンテナオート
メーションが実現できるため導入と管理が容易
• HPE ハードウェア製品(OneView, Synergy)との統合
• エンタープライズサポートあり(HPEから販売可能)
• オンプレミス(物理、仮想、プライ
ベートIaaS)
• パブリックIaaS上の仮想マシンインス
タンスをホストとして構築すること
も可能
Mesosphere DC/OS • OSSのApache Mesosを中心に管理ツールを統合し、エンタープ
ライズ向けアプリケーション実行環境としてパッケージング
• パブリックIaaSへの対応にも力を入れており、大規模ハイブ
リッドクラウド環境に最適
• エンタープライズサポートあり(HPEから転売可能)
• オンプレミス(物理、仮想、プライ
ベートIaaS)
• パブリックIaaS上の仮想マシンインス
タンスをホストとして構築すること
も可能
• パブリックIaaS上のマネージドサービ
スとしても利用可能
Kubernetes • Google社のアプリケーションプラットフォーム(Borg)のアー
キテクチャをOSS化。現在Cloud Native Computing Foundationが
強力に推進
• Pokemon Goで実証されたスケーラビリティ
• OSS(各Linuxディストリビューションのサブスクリプションサ
ポート)
• 各種Linux OS上でOSSとして利用可能
• ホストのオーケストレーションツー
ル(Terraformなど)と統合するとさ
らにソリューションを強化できる
HPEが提供するのCloud Native Application Platform
50
Helion Stackato 4のアーキテクチャ
51
HPEが提供するプロフェッショナルサービス
52
一緒に、デジタルビジネス時代を楽しみましょう。
Thank you
54
参考文献
CONTAINER MARKET ADOPTION SURVEY A Joint Production of: 2016
https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2016.pdf
Gartner
https://www.gartner.co.jp/press/html/pr20160601-01.html
System of Record と System of Engagement by Naoya Ito
https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement

Más contenido relacionado

La actualidad más candente

失敗と向き合う姿勢を正す話
失敗と向き合う姿勢を正す話失敗と向き合う姿勢を正す話
失敗と向き合う姿勢を正す話LIFULL Co., Ltd.
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)Developers Summit
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumiItsuki Kuroda
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のりRecruit Lifestyle Co., Ltd.
 
NoOpsへの挑戦
NoOpsへの挑戦 NoOpsへの挑戦
NoOpsへの挑戦 Hiromasa Oka
 
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】dreamarts_pr
 
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~SPIRAL Inc.
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupItsuki Kuroda
 
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡Naomichi Shimazu
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料Tomohiro Fujii
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とはStudyTech
 
Future tech night #12~goで始めるサーバレスファーストという選択肢~
Future tech night #12~goで始めるサーバレスファーストという選択肢~Future tech night #12~goで始めるサーバレスファーストという選択肢~
Future tech night #12~goで始めるサーバレスファーストという選択肢~masahiko ito
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7Itsuki Kuroda
 
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門Developers Summit
 
DevOps 概要 - インフラ革命、今起きていること
DevOps 概要 - インフラ革命、今起きていることDevOps 概要 - インフラ革命、今起きていること
DevOps 概要 - インフラ革命、今起きていることHiro Fukami
 
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」Serverworks Co.,Ltd.
 
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2智治 長沢
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanItsuki Kuroda
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013智治 長沢
 

La actualidad más candente (20)

失敗と向き合う姿勢を正す話
失敗と向き合う姿勢を正す話失敗と向き合う姿勢を正す話
失敗と向き合う姿勢を正す話
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり
 
NoOpsへの挑戦
NoOpsへの挑戦 NoOpsへの挑戦
NoOpsへの挑戦
 
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
 
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~
国産業務PaaSを担いで稼ぐ方法 ~SIerの生き残る道の1つとなるか? ~
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡
【DevOpsDaysTokyo2021】「ログイン画面が開きません」から始まるチーム改革の軌跡
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とは
 
Future tech night #12~goで始めるサーバレスファーストという選択肢~
Future tech night #12~goで始めるサーバレスファーストという選択肢~Future tech night #12~goで始めるサーバレスファーストという選択肢~
Future tech night #12~goで始めるサーバレスファーストという選択肢~
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
 
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門
【16E2】New Relic を使ったDevOps 時代のパフォーマンス監視と障害分析入門
 
DevOps at ChatWork
DevOps at ChatWorkDevOps at ChatWork
DevOps at ChatWork
 
DevOps 概要 - インフラ革命、今起きていること
DevOps 概要 - インフラ革命、今起きていることDevOps 概要 - インフラ革命、今起きていること
DevOps 概要 - インフラ革命、今起きていること
 
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
 
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2
これからのソフトウェア開発におけるプロジェクト管理の展望 Episode 2
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
 

Similar a デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択

基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」Cybozucommunity
 
Mirai carved out by innovations
Mirai carved out by innovationsMirai carved out by innovations
Mirai carved out by innovationsOsaka University
 
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~Yuki Ando
 
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介Junichi Kodama
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立についてMasahiko Ebisuda
 
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...Rakuten Group, Inc.
 
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)Tokoroten Nakayama
 
Low-Codeプログラミングシステム Node-REDとその応用
Low-CodeプログラミングシステムNode-REDとその応用Low-CodeプログラミングシステムNode-REDとその応用
Low-Codeプログラミングシステム Node-REDとその応用HiroyasuNishiyama1
 
20180921 Twilio Smart Communication Award 2018
20180921 Twilio Smart Communication Award 201820180921 Twilio Smart Communication Award 2018
20180921 Twilio Smart Communication Award 2018Ukyo Satake
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)伸夫 森本
 
第14回SIA例会プレゼン資料
第14回SIA例会プレゼン資料第14回SIA例会プレゼン資料
第14回SIA例会プレゼン資料Tae Yoshida
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織Recruit Technologies
 
05.日本マイクロソフト(株)_発表資料
05.日本マイクロソフト(株)_発表資料05.日本マイクロソフト(株)_発表資料
05.日本マイクロソフト(株)_発表資料wagatuma
 
アジャイル開発のためのDatadog
アジャイル開発のためのDatadogアジャイル開発のためのDatadog
アジャイル開発のためのDatadogNobuyasu Seki
 
20200717 kanazawauniv takasu キャリア、コミュニティとアカデミア、そして事業開発
20200717 kanazawauniv takasu  キャリア、コミュニティとアカデミア、そして事業開発20200717 kanazawauniv takasu  キャリア、コミュニティとアカデミア、そして事業開発
20200717 kanazawauniv takasu キャリア、コミュニティとアカデミア、そして事業開発Nico-Tech Shenzhen/ニコ技深圳コミュニティ
 
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -Tier_IV
 

Similar a デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択 (20)

Ms retail update ra 20191030
Ms retail update ra 20191030Ms retail update ra 20191030
Ms retail update ra 20191030
 
Smfl20201001
Smfl20201001Smfl20201001
Smfl20201001
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
 
Mirai carved out by innovations
Mirai carved out by innovationsMirai carved out by innovations
Mirai carved out by innovations
 
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
 
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について
 
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
 
Developers Summit 2013【15-B-6】開発者の "資産形成" につながる Action とは?
Developers Summit 2013【15-B-6】開発者の "資産形成" につながる Action とは?Developers Summit 2013【15-B-6】開発者の "資産形成" につながる Action とは?
Developers Summit 2013【15-B-6】開発者の "資産形成" につながる Action とは?
 
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
 
Low-Codeプログラミングシステム Node-REDとその応用
Low-CodeプログラミングシステムNode-REDとその応用Low-CodeプログラミングシステムNode-REDとその応用
Low-Codeプログラミングシステム Node-REDとその応用
 
20180921 Twilio Smart Communication Award 2018
20180921 Twilio Smart Communication Award 201820180921 Twilio Smart Communication Award 2018
20180921 Twilio Smart Communication Award 2018
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)
 
第14回SIA例会プレゼン資料
第14回SIA例会プレゼン資料第14回SIA例会プレゼン資料
第14回SIA例会プレゼン資料
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
 
05.日本マイクロソフト(株)_発表資料
05.日本マイクロソフト(株)_発表資料05.日本マイクロソフト(株)_発表資料
05.日本マイクロソフト(株)_発表資料
 
アジャイル開発のためのDatadog
アジャイル開発のためのDatadogアジャイル開発のためのDatadog
アジャイル開発のためのDatadog
 
20200717 kanazawauniv takasu キャリア、コミュニティとアカデミア、そして事業開発
20200717 kanazawauniv takasu  キャリア、コミュニティとアカデミア、そして事業開発20200717 kanazawauniv takasu  キャリア、コミュニティとアカデミア、そして事業開発
20200717 kanazawauniv takasu キャリア、コミュニティとアカデミア、そして事業開発
 
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -
Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 -
 

Más de Shingo Kitayama

Kubernetes Security with DevSecOps
Kubernetes Security with DevSecOpsKubernetes Security with DevSecOps
Kubernetes Security with DevSecOpsShingo Kitayama
 
GitLab Auto DevOps with Container CI/CD
GitLab Auto DevOps with Container CI/CDGitLab Auto DevOps with Container CI/CD
GitLab Auto DevOps with Container CI/CDShingo Kitayama
 
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)Shingo Kitayama
 
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界Shingo Kitayama
 
Apache Mesosってなに
Apache MesosってなにApache Mesosってなに
Apache MesosってなにShingo Kitayama
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Shingo Kitayama
 
今日からはじめるディープラーニング
今日からはじめるディープラーニング今日からはじめるディープラーニング
今日からはじめるディープラーニングShingo Kitayama
 

Más de Shingo Kitayama (8)

Kubernetes Security with DevSecOps
Kubernetes Security with DevSecOpsKubernetes Security with DevSecOps
Kubernetes Security with DevSecOps
 
GitLab Auto DevOps with Container CI/CD
GitLab Auto DevOps with Container CI/CDGitLab Auto DevOps with Container CI/CD
GitLab Auto DevOps with Container CI/CD
 
GitLab Prometheus
GitLab PrometheusGitLab Prometheus
GitLab Prometheus
 
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
 
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界
【OpenStackDaysTokyo】4-B1-3 自動化を支えるCICDパイプラインの世界
 
Apache Mesosってなに
Apache MesosってなにApache Mesosってなに
Apache Mesosってなに
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
 
今日からはじめるディープラーニング
今日からはじめるディープラーニング今日からはじめるディープラーニング
今日からはじめるディープラーニング
 

Último

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
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
「今からでも間に合う」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
 
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
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 

Último (12)

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~
 
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?
 
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
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
「今からでも間に合う」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へ
 
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
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 

デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択