Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
クラウドの発展と
デベロッパーの役割について
2016/7/16
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
【S-1】
#devsumiS1
自己紹介
鈴木雄介
• グロースエクスパートナーズ(株)
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/...
アジェンダ
• クラウドがもたらしたもの
• クラウドの発展
• エンタープライズとクラウド
• クラウド時代のデベロッパー
• まとめ
2
クラウドがもたらしたもの
3
クラウドがもたらしたもの
クラウドにおける3つの変化
• 1.インフラのサービス化
• 2.ミドルウェアのプラットフォーム化
• 3.システム構成のコード化
4
クラウドがもたらしたもの
1.インフラのサービス化
• 仮想化技術の応用
»SDx:ソフトウェアであらゆるものを定義する
»広大なデータセンターの上に自分のための仮想イン
フラが構築できる
• インフラを「所有」から「利用」へ
»IaaS(In...
クラウドがもたらしたもの
2.ミドルウェアのプラットフォーム化
• ミドルウェアの仮想化
»AWS RDS(Relational Database Service)はデー
タベースサーバーのレンタルではない
▸バックアップもクラスタ構成も設定す...
クラウドがもたらしたもの
2.ミドルウェアのプラットフォーム化
• プラットフォームを利用する
»PaaS(Platform as a Service)
»アプリとインフラの境界線がなくなる
• 積極的にプラットフォームの制約を受け入れる
»制...
クラウドがもたらしたもの
3.システム構成のコード化
• 仮想化されたインフラやプラットフォームがコ
ードから操作ができる
»つまり、「構成する」ことの自動化ができる
• 非機能要件がコーディングできる
»これまでは機能要件しかコーディングでき...
クラウドがもたらしたもの
クラウド技術の可能性
• 3つセットでクラウド技術
»1.インフラのサービス化
»2.ミドルウェアのプラットフォーム化
»3.システム構成のコード化
• クラウドファースト
»2.プラットフォームと3.コード化を有効活...
クラウドがもたらしたもの
ITサービス運営のスピードアップ
• ITサービス運営=企画→開発→運用という営み
»「アプリを書く」ことが早くなるのではない
• 「作る」だけでは価値じゃない
»システムを動かして、ビジネス価値を生み出す
10
クラウドの発展
11
クラウドの発展
クラウドが何をもたらしたのか
• クラウドが何をもたらしたのかを理解する
• 15年前から、僕らはITサービス運営のスピー
ドアップに取り組んでいた
»アジャイル
»DevOps
»マイクロサービスアーキテクチャ(MSA)
12
クラウドの発展
アジャイル
13
アジャイル
アジャイルのはじまり
• 2001年:アジャイルソフトウェア開発宣言
»プロセスやツールよりも個人と対話を、
»包括的なドキュメントよりも動くソフトウェアを、
»契約交渉よりも顧客との協調を、
»計画に従うことよりも変化への対応を
...
アジャイル
ウォーターフォールの進め方
• 最終成果物に向けて、フェーズごとの中間成果
物を定め、段階的に品質を確認する
15
基本設計 実装 テスト要件定義
計
画
受
入
文書 文書
アジャイル
ウォーターフォールの課題
• 欲しい最終成果物が変化してしまう
»終わるころには欲しいものでは異なる
• 中間成果物では品質が確認できない
»文書を見ても評価できない
• 調整が後手後手になりやすい
»情勢の見極めがPMの力量に左右...
アジャイル
アジャイルのアプローチ
• 期間とリソースを定め、計画と評価を繰り返す
• 評価は関係者全員で動くソフトウエアを確認
17
設計 実装 テスト
計
画
受
入 設計 実装 テスト
計
画
受
入 設計 実装 テスト
計
画
受
入
アジャイル
アジャイルのメリット
• 「今」欲しいものを得られる
»次のリリースがあるという安心感
• 定期的に評価ができる
»フィードバックを元に進めていける
• プロセスではなくチーム
»状況が共有できるので判断が行いやすい
18
アジャイル
「仕事の仕方」の違い
• WF:やるべきことを終わるまでやる
»必要な期間とリソースを調達する
»一発リリースと保守活動
• アジャイル:期限までに今やるべきことをやる
»決められた期間とリソースの範囲内でやる
»段階リリースで改善...
クラウドの発展
DevOps
20
DevOps
DevOpsのはじまり
• アジャイルを「開発→運用」に適用する
• 2009年:DevOps
»Agile 2008:Agile Infrastructure & Operations
▸政府系データセンターの移行にスクラムを導...
DevOps
Dev❤Opsのテーマ
• そもそも開発と運用は仲が悪い
»「変更」と「安定稼働」は相反する
• 前提が変わってしまった
»アプリは変更してなんぼ
»システムの停止=価値の棄損
• 運用の完全自動化(Opsの不要化)
»クラウド技...
DevOps
ブルーグリーンデプロイメント
• システム構成の自動化がもたらしたアイデア
»本番環境をコピーして、新バージョン用の本番環境
を作る
»ユーザーのアクセスを切り替える
▸もちろん、切り戻しも一瞬
23
ブルーグリーンデプロイメント
24
Web App DB
ルーター100
100
ブルーグリーンデプロイメント
25
Web App DB
ルーター100
100
Web App DB
ブルーグリーンデプロイメント
26
Web App DB
ルーター100
95
Web App DB
5
ブルーグリーンデプロイメント
27
Web App DB
ルーター100
100
Web App DB
ブルーグリーンデプロイメント
28
ルーター100
100
Web App DB
DevOps
ブルーグリーンデプロイメント
• 可能な限りサービスを止めない
»数%の犠牲(の可能性)によって全体を救う
»日中リリースが可能で切戻しコストも低い
• カナリアリリース
»ブルーグリーンデプロイメントがベース
»一部のユーザーだ...
DevOps
ダークカナリア
• カナリアリリースを応用
»「秘密のカナリア」
• 開発者だけがアクセスできるテスト用バージョ
ンを本番環境にリリースする
»連携先システムも含めて、ステージング環境の構築
が困難な場合は有効
»もちろんバグが残...
DevOps
カオスモンキー
• 本番環境をランダムにダウンさせる製品
»モンキー:サーバー
»ゴリラ:アベイラビティゾーン
»コング:リージョン(≒データセンター)
• 自動化スクリプトのテスト
»本番環境でしか実施できない
»もしものために...
クラウドの発展
マイクロサービス
アーキテクチャ
32
マイクロサービスアーキテクチャ
MSA
• 2014年:「Microservceis」
»2011年:先端的なウェブサービス企業が似てような
アーキテクチャスタイルを取っていることが議論に
»33rd Degree 2012「Microserv...
マイクロサービスアーキテクチャ
モノリシックなシステムの課題
• 部分の変更が全体に波及する
»全体への影響調査
»全体でのリグレッションテスト
• 技術の選択に幅がなくなる
»システム全体を単一の構造で作る
»技術の切れ目でチームも構成しがち...
マイクロサービスアーキテクチャ
MSAの特性(技術面)
• 部分の変更を全体に波及させない
»システムをサービス同士の連携で実現する
»サービス同士が疎結合になっていれば、サービスは
いつでも変更してよい
▸APIによる連携
▸サービスの無停止...
マイクロサービスアーキテクチャ
MSAの特性(組織面)
• サービス単位でマネジメントすればよい
»サービスの切れ目でチームを分ける
»サービスごとにリズムと技術を最適化
• たくさんのチームでシステムを作る
»アジャイルを最も効率的に機能させ...
マイクロサービスアーキテクチャ
MSAの注意点
• アプリ管理ではなくシステム管理
»巨大なシステムをいかに管理するか
• 設計指針ではなく結果論
»アジャイル+クラウド+DevOps+サービス指向を突
き詰めていった結果、自然にそうなる
• ...
マイクロサービスアーキテクチャ
いかにサービスを分けるか
• ドメイン(問題領域)
»≒業務
»変更ベクトルの濃淡に境界線を引いたもの
• ドメインモデル
»ドメイン専門家の頭の中
»≠UI/UX(ユーザーとのインタラクション)
▸APIによっ...
クラウドの発展
おさらい
39
クラウドの発展
おさらい
• 2001年:アジャイル
• 2006年:クラウド & AWS EC2
• 2009年:DevOps & AWS RDS
• 2010年:ブルーグリーンデプロイメント
• 2011年:AWS Elastic Bean...
クラウドの発展
全てはアジャイルから
• アジャイルのムーブメントを運用にまで延ばし
たのがDevOps
• その間にクラウド技術が発展し始め、プラット
フォーム利用や自動化が促進
• ムーブメントと技術が統合した姿がマイクロサ
ービスアーキテ...
エンタープライズとクラウド
42
エンタープライズとクラウド
エンタープライズとは
• 安心安全で絶対に間違いが許されない?
• エンタープライズにおける2つのシステム
»SoR(System of Record/記録のシステム)
»SoE(System of Engageme...
エンタープライズとクラウド
良い悪いではない
• 適切にツールとして使うことが大事
»アジャイルとウォーターフォール
»DevOpsとITIL
»MSAとSOA
• まずは「マインドセット」の変更を
»態度:be Agile(定期的な改善)
»...
クラウド時代のデベロッパー
45
クラウド時代のデベロッパー
コーディング対象の拡がり
• 機能要件だけではなく非機能要件もコードに書
けるようになってきた
»アプリとインフラは不可分に
• PaaSを選ぶ ≒ OSSフレームワークを選ぶ
»PaaS=アプリ+インフラのフレーム...
クラウド時代のデベロッパー
システム開発からサービス運営へ
• 「要件を満たすアプリを作る」から「価値があ
るサービスを運営する」へ
»効率的に作るよりも、効率的に動かす
• 企画→開発→運用のあらゆる所でエンジニア能
力が求められるように
»...
クラウド時代のデベロッパー
「技術」の多様化
• より特定の目的に沿った技術の登場
»それらの技術をいかに組み合わせて楽をするか
»IoT、AIなどなど
• より特定の目的に沿った方法論の登場
»企画:戦略理解→ユーザ中心設計→機能リスト
»開...
クラウド時代のデベロッパー
技術の使われ方を意識する
• 技術そのものだけではなく「技術の使い方」の
トレンドを意識する
»「おしゃれな技術」という理解は無意味
»何に最適な技術なのか?を理解し、無理をさせない
• 使い方にはマネジメントプロセ...
クラウド時代のデベロッパー
スキルを縦か横に拡げる
• 機能別から価値を出すためのチーム分けへ
• スペシャリストかゼネラリスト
»スペシャリスト:特定領域の専門家
»ゼネラリスト:専門家を繋いで価値に繋げる
50
開発
企画
システム作り
運...
クラウド時代のデベロッパー
ビジネスの中心になろう
• 「ITがビジネスの最重要課題」なら「デベロッ
パーがビジネス活動の中心」にいるべき
»ビジネスパーソンとしてのデベロッパー
• デベロッパーにもビジネススキルが必須
»コミュニケーション能...
まとめ
52
まとめ
全てはアジャイルからはじまった
• アジャイルのムーブメントを運用にまで延ばし
たのがDevOps
• その間にクラウド技術が発展し始め、プラット
フォーム利用や自動化が促進
• ムーブメントと技術が統合した姿がマイクロサ
ービスアーキ...
まとめ
クラウドファースト
• クラウドを利用してITサービス運営を早くする
»単純にIaaSを使うのではなく、プラットフォームや
自動化スクリプトを使い倒す
• 技術を使う側に発想の転換が必要
»アプリとインフラの境目がなくなる
»非機能要件...
まとめ
クラウド時代のデベロッパー
• 色々と拡がった
»非機能要件もコーディング対象
»システム開発からサービス運営へ
• 多様化した「技術」の使われ方を意識する
• スキルを縦か横に拡げる
• ビジネスの中心になろう
55
最後に
56
お知らせ
さらに詳しく知りたいなら
• クラウドファーストアーキテクチャ設計ガイド
» 第1章 クラウドファーストの意味
» 第2章 クラウド技術の構成
» 第3章 クラウドファーストに至るまでの歴史
» 第4章 エンタープライズとクラウドファ...
Upcoming SlideShare
Loading in …5
×

クラウドの発展とデベロッパーの役割について - デブサミ関西2016

9,971 views

Published on

2016年9月16日に開催されたDevelopers Summit 2016 KANSAI(デブサミ関西2016)の基調講演「クラウドの発展とデベロッパーの役割について」の資料です。
togetterは、こちら http://togetter.com/li/1025022

Published in: Technology

クラウドの発展とデベロッパーの役割について - デブサミ関西2016

  1. 1. クラウドの発展と デベロッパーの役割について 2016/7/16 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 【S-1】 #devsumiS1
  2. 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. アジェンダ • クラウドがもたらしたもの • クラウドの発展 • エンタープライズとクラウド • クラウド時代のデベロッパー • まとめ 2
  4. 4. クラウドがもたらしたもの 3
  5. 5. クラウドがもたらしたもの クラウドにおける3つの変化 • 1.インフラのサービス化 • 2.ミドルウェアのプラットフォーム化 • 3.システム構成のコード化 4
  6. 6. クラウドがもたらしたもの 1.インフラのサービス化 • 仮想化技術の応用 »SDx:ソフトウェアであらゆるものを定義する »広大なデータセンターの上に自分のための仮想イン フラが構築できる • インフラを「所有」から「利用」へ »IaaS(Infrastructure as a Service) »例:AWS EC2 5
  7. 7. クラウドがもたらしたもの 2.ミドルウェアのプラットフォーム化 • ミドルウェアの仮想化 »AWS RDS(Relational Database Service)はデー タベースサーバーのレンタルではない ▸バックアップもクラスタ構成も設定するだけ • 高度化するプラットフォーム »Webアプリ基盤:AWS Elastic Beanstalk »開発ライフサイクル込み基盤:AWS CodeDeploy / AWS CodePipeline 6
  8. 8. クラウドがもたらしたもの 2.ミドルウェアのプラットフォーム化 • プラットフォームを利用する »PaaS(Platform as a Service) »アプリとインフラの境界線がなくなる • 積極的にプラットフォームの制約を受け入れる »制約を受け入れて利用したほうが便利 »OSSライブラリと一緒 7
  9. 9. クラウドがもたらしたもの 3.システム構成のコード化 • 仮想化されたインフラやプラットフォームがコ ードから操作ができる »つまり、「構成する」ことの自動化ができる • 非機能要件がコーディングできる »これまでは機能要件しかコーディングできなかった »サービスそのものがコードで表現できる 8
  10. 10. クラウドがもたらしたもの クラウド技術の可能性 • 3つセットでクラウド技術 »1.インフラのサービス化 »2.ミドルウェアのプラットフォーム化 »3.システム構成のコード化 • クラウドファースト »2.プラットフォームと3.コード化を有効活用 »オンプレからの単純移行(IaaS)では足りない 9
  11. 11. クラウドがもたらしたもの ITサービス運営のスピードアップ • ITサービス運営=企画→開発→運用という営み »「アプリを書く」ことが早くなるのではない • 「作る」だけでは価値じゃない »システムを動かして、ビジネス価値を生み出す 10
  12. 12. クラウドの発展 11
  13. 13. クラウドの発展 クラウドが何をもたらしたのか • クラウドが何をもたらしたのかを理解する • 15年前から、僕らはITサービス運営のスピー ドアップに取り組んでいた »アジャイル »DevOps »マイクロサービスアーキテクチャ(MSA) 12
  14. 14. クラウドの発展 アジャイル 13
  15. 15. アジャイル アジャイルのはじまり • 2001年:アジャイルソフトウェア開発宣言 »プロセスやツールよりも個人と対話を、 »包括的なドキュメントよりも動くソフトウェアを、 »契約交渉よりも顧客との協調を、 »計画に従うことよりも変化への対応を • 主に「企画→開発」にフォーカス 14参考:http://www.agilemanifesto.org/iso/ja/
  16. 16. アジャイル ウォーターフォールの進め方 • 最終成果物に向けて、フェーズごとの中間成果 物を定め、段階的に品質を確認する 15 基本設計 実装 テスト要件定義 計 画 受 入 文書 文書
  17. 17. アジャイル ウォーターフォールの課題 • 欲しい最終成果物が変化してしまう »終わるころには欲しいものでは異なる • 中間成果物では品質が確認できない »文書を見ても評価できない • 調整が後手後手になりやすい »情勢の見極めがPMの力量に左右される 16
  18. 18. アジャイル アジャイルのアプローチ • 期間とリソースを定め、計画と評価を繰り返す • 評価は関係者全員で動くソフトウエアを確認 17 設計 実装 テスト 計 画 受 入 設計 実装 テスト 計 画 受 入 設計 実装 テスト 計 画 受 入
  19. 19. アジャイル アジャイルのメリット • 「今」欲しいものを得られる »次のリリースがあるという安心感 • 定期的に評価ができる »フィードバックを元に進めていける • プロセスではなくチーム »状況が共有できるので判断が行いやすい 18
  20. 20. アジャイル 「仕事の仕方」の違い • WF:やるべきことを終わるまでやる »必要な期間とリソースを調達する »一発リリースと保守活動 • アジャイル:期限までに今やるべきことをやる »決められた期間とリソースの範囲内でやる »段階リリースで改善活動 19
  21. 21. クラウドの発展 DevOps 20
  22. 22. DevOps DevOpsのはじまり • アジャイルを「開発→運用」に適用する • 2009年:DevOps »Agile 2008:Agile Infrastructure & Operations ▸政府系データセンターの移行にスクラムを導入した事例 »Velocity 2009:10+ Deploys Per Day ▸Flickrにおける開発と運用の協業について »Devopsdays Ghent 2009 ▸ここから「DevOps」が生まれる 21 参考:「The (Short) History of DevOps」(Damon Edwards) https://www.youtube.com/watch?v=o7-IuYS0iSE
  23. 23. DevOps Dev❤Opsのテーマ • そもそも開発と運用は仲が悪い »「変更」と「安定稼働」は相反する • 前提が変わってしまった »アプリは変更してなんぼ »システムの停止=価値の棄損 • 運用の完全自動化(Opsの不要化) »クラウド技術の成熟との強い相関 22
  24. 24. DevOps ブルーグリーンデプロイメント • システム構成の自動化がもたらしたアイデア »本番環境をコピーして、新バージョン用の本番環境 を作る »ユーザーのアクセスを切り替える ▸もちろん、切り戻しも一瞬 23
  25. 25. ブルーグリーンデプロイメント 24 Web App DB ルーター100 100
  26. 26. ブルーグリーンデプロイメント 25 Web App DB ルーター100 100 Web App DB
  27. 27. ブルーグリーンデプロイメント 26 Web App DB ルーター100 95 Web App DB 5
  28. 28. ブルーグリーンデプロイメント 27 Web App DB ルーター100 100 Web App DB
  29. 29. ブルーグリーンデプロイメント 28 ルーター100 100 Web App DB
  30. 30. DevOps ブルーグリーンデプロイメント • 可能な限りサービスを止めない »数%の犠牲(の可能性)によって全体を救う »日中リリースが可能で切戻しコストも低い • カナリアリリース »ブルーグリーンデプロイメントがベース »一部のユーザーだけに特定のバージョンを提供する 29
  31. 31. DevOps ダークカナリア • カナリアリリースを応用 »「秘密のカナリア」 • 開発者だけがアクセスできるテスト用バージョ ンを本番環境にリリースする »連携先システムも含めて、ステージング環境の構築 が困難な場合は有効 »もちろんバグが残っている可能性があるので、適用 する機能は限定される 30参考:「Scaling micro services at Gilt」http://www.slideshare.net/trenaman/javaone-2015-scaling-micro-services-at-gilt
  32. 32. DevOps カオスモンキー • 本番環境をランダムにダウンさせる製品 »モンキー:サーバー »ゴリラ:アベイラビティゾーン »コング:リージョン(≒データセンター) • 自動化スクリプトのテスト »本番環境でしか実施できない »もしものために平日日中に実行する 31参考:https://github.com/Netflix/SimianArmy
  33. 33. クラウドの発展 マイクロサービス アーキテクチャ 32
  34. 34. マイクロサービスアーキテクチャ MSA • 2014年:「Microservceis」 »2011年:先端的なウェブサービス企業が似てような アーキテクチャスタイルを取っていることが議論に »33rd Degree 2012「Microservices - Java, the Unix Way」 • アジャイル+DevOpsをアーキテクチャ論に展 開したもの 33 参考:http://martinfowler.com/articles/microservices.html 参考: http://2012.33degree.org/talk/show/67
  35. 35. マイクロサービスアーキテクチャ モノリシックなシステムの課題 • 部分の変更が全体に波及する »全体への影響調査 »全体でのリグレッションテスト • 技術の選択に幅がなくなる »システム全体を単一の構造で作る »技術の切れ目でチームも構成しがち ▸コンウェイの法則 34
  36. 36. マイクロサービスアーキテクチャ MSAの特性(技術面) • 部分の変更を全体に波及させない »システムをサービス同士の連携で実現する »サービス同士が疎結合になっていれば、サービスは いつでも変更してよい ▸APIによる連携 ▸サービスの無停止リリース • 個別サービスの変化がシステム全体の変化 35
  37. 37. マイクロサービスアーキテクチャ MSAの特性(組織面) • サービス単位でマネジメントすればよい »サービスの切れ目でチームを分ける »サービスごとにリズムと技術を最適化 • たくさんのチームでシステムを作る »アジャイルを最も効率的に機能させる仕組み 36
  38. 38. マイクロサービスアーキテクチャ MSAの注意点 • アプリ管理ではなくシステム管理 »巨大なシステムをいかに管理するか • 設計指針ではなく結果論 »アジャイル+クラウド+DevOps+サービス指向を突 き詰めていった結果、自然にそうなる • 「MSAで再構築」は「愚」 »MSAは今にすぐに取りかかれる 37
  39. 39. マイクロサービスアーキテクチャ いかにサービスを分けるか • ドメイン(問題領域) »≒業務 »変更ベクトルの濃淡に境界線を引いたもの • ドメインモデル »ドメイン専門家の頭の中 »≠UI/UX(ユーザーとのインタラクション) ▸APIによってドメインとUXを分割するべき 38
  40. 40. クラウドの発展 おさらい 39
  41. 41. クラウドの発展 おさらい • 2001年:アジャイル • 2006年:クラウド & AWS EC2 • 2009年:DevOps & AWS RDS • 2010年:ブルーグリーンデプロイメント • 2011年:AWS Elastic Beanstalk • 2012年:カオスモンキー & カナリアリリース • 2014年:マイクロサービスアーキテクチャ 40
  42. 42. クラウドの発展 全てはアジャイルから • アジャイルのムーブメントを運用にまで延ばし たのがDevOps • その間にクラウド技術が発展し始め、プラット フォーム利用や自動化が促進 • ムーブメントと技術が統合した姿がマイクロサ ービスアーキテクチャ • エンタープライズでも適用事例が←イマココ 41
  43. 43. エンタープライズとクラウド 42
  44. 44. エンタープライズとクラウド エンタープライズとは • 安心安全で絶対に間違いが許されない? • エンタープライズにおける2つのシステム »SoR(System of Record/記録のシステム) »SoE(System of Engagement/絆のシステム) • SoEはWebサービスが参考になる »ただし、「信頼」には足る必要性がある »SoRとの連携については注意が必要 43
  45. 45. エンタープライズとクラウド 良い悪いではない • 適切にツールとして使うことが大事 »アジャイルとウォーターフォール »DevOpsとITIL »MSAとSOA • まずは「マインドセット」の変更を »態度:be Agile(定期的な改善) »技術:プラットフォームの活用 44
  46. 46. クラウド時代のデベロッパー 45
  47. 47. クラウド時代のデベロッパー コーディング対象の拡がり • 機能要件だけではなく非機能要件もコードに書 けるようになってきた »アプリとインフラは不可分に • PaaSを選ぶ ≒ OSSフレームワークを選ぶ »PaaS=アプリ+インフラのフレームワーク »制約に従うなら使った方が便利 46
  48. 48. クラウド時代のデベロッパー システム開発からサービス運営へ • 「要件を満たすアプリを作る」から「価値があ るサービスを運営する」へ »効率的に作るよりも、効率的に動かす • 企画→開発→運用のあらゆる所でエンジニア能 力が求められるように »効率的に作るよりも、より適切な機能を提供する 47
  49. 49. クラウド時代のデベロッパー 「技術」の多様化 • より特定の目的に沿った技術の登場 »それらの技術をいかに組み合わせて楽をするか »IoT、AIなどなど • より特定の目的に沿った方法論の登場 »企画:戦略理解→ユーザ中心設計→機能リスト »開発:アジャイル、各種ツール »運用:DevOps、各種ツール 48
  50. 50. クラウド時代のデベロッパー 技術の使われ方を意識する • 技術そのものだけではなく「技術の使い方」の トレンドを意識する »「おしゃれな技術」という理解は無意味 »何に最適な技術なのか?を理解し、無理をさせない • 使い方にはマネジメントプロセスも含む »建築では工法と構造が一体なのは当たり前のこと 49
  51. 51. クラウド時代のデベロッパー スキルを縦か横に拡げる • 機能別から価値を出すためのチーム分けへ • スペシャリストかゼネラリスト »スペシャリスト:特定領域の専門家 »ゼネラリスト:専門家を繋いで価値に繋げる 50 開発 企画 システム作り 運用 サービス運営 企画+開発+運用 企画+開発+運用 企画+開発+運用
  52. 52. クラウド時代のデベロッパー ビジネスの中心になろう • 「ITがビジネスの最重要課題」なら「デベロッ パーがビジネス活動の中心」にいるべき »ビジネスパーソンとしてのデベロッパー • デベロッパーにもビジネススキルが必須 »コミュニケーション能力やプレゼン能力 »チームビルディング 51
  53. 53. まとめ 52
  54. 54. まとめ 全てはアジャイルからはじまった • アジャイルのムーブメントを運用にまで延ばし たのがDevOps • その間にクラウド技術が発展し始め、プラット フォーム利用や自動化が促進 • ムーブメントと技術が統合した姿がマイクロサ ービスアーキテクチャ • エンタープライズでも適用事例が←イマココ 53
  55. 55. まとめ クラウドファースト • クラウドを利用してITサービス運営を早くする »単純にIaaSを使うのではなく、プラットフォームや 自動化スクリプトを使い倒す • 技術を使う側に発想の転換が必要 »アプリとインフラの境目がなくなる »非機能要件もコーディングできる »プラットフォームの制約を受け入れる 54
  56. 56. まとめ クラウド時代のデベロッパー • 色々と拡がった »非機能要件もコーディング対象 »システム開発からサービス運営へ • 多様化した「技術」の使われ方を意識する • スキルを縦か横に拡げる • ビジネスの中心になろう 55
  57. 57. 最後に 56
  58. 58. お知らせ さらに詳しく知りたいなら • クラウドファーストアーキテクチャ設計ガイド » 第1章 クラウドファーストの意味 » 第2章 クラウド技術の構成 » 第3章 クラウドファーストに至るまでの歴史 » 第4章 エンタープライズとクラウドファースト » 第5章 アーキテクチャー設計ガイド » 第6章 クラウドファーストにおけるエンジニア 57 https://www.amazon.co.jp/dp/4822237818

×