Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ITトレンドに見る日本のエンタープライズITについて
Similar to ITトレンドに見る日本のエンタープライズITについて (20)
More from Yusuke Suzuki
Recently uploaded
Recently uploaded (9)
ITトレンドに見る日本のエンタープライズITについて
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 4. ITトレンドの流れ 3
- 9. Agile ウォーターフォールの考え方 • 最終成果物に向けて、フェーズごとの中間成果物を定め、 段階的に品質を確認する • 中間成果物は基本的に文書 8 基本設計 実装 テスト要件定義 計 画 受 入 文書 文書 文書 文書文書
- 10. Agile ウォーターフォールの課題 • 途中で「欲しい最終成果物」が変化してしまう »終わるころにはビジネス要件がさらに変化してもらう • 中間成果物では品質が確認できない »文書を見ているだけでは評価できないことがある • プロジェクト全体の状況把握が困難 »PMに集まる情報だけでは情勢の見極めにくい 9
- 11. Agile アジャイルの考え方 • リソースを定め、短期＆定期的に計画と評価を繰り返す • 評価は関係者全員で動くソフトウエアを確認 10 設計 実装 ﾃｽﾄ計 画 受 入 設計 実装 ﾃｽﾄ計 画 受 入 設計 実装 ﾃｽﾄ計 画 受 入
- 12. Agile アジャイルのメリット • 「今」欲しいものを得られる »このリリースで何かを得たいか、を決めればいい • 定期的に動く成果物で評価できる »動く成果物へのフィードバックから改善をしていく • チームが判断する »現場チーム内で状況が共有できるので判断が行いやすい 11
- 14. Agile ウォーターフォールとアジャイル • 計画主導 vs 調整主導 »ウォーターフォールは「計画からズレた時に調整する」 »アジャイルは「毎回、調整する」 13 GOAL GOAL START GOAL START GOALGOALGOAL
- 15. Agile Agileがもたらした変化 • ITサービスは変化し続ける »要件が社内ではなく社外にある場合、ユーザーからのフィードバ ックによって改善させていくしかない »「プロジェクト（有期）」から「プロダクト（無期）」へ • チーム活動を主体にする »絶対的なリーダーを求めるよりもチーム活動を重視する • ただし、すべてに最適ではない »SoR < SoE、Mode 1 < Mode 2 14
- 18. Cloud クラウドにおける3つの変化 • 1.インフラのサービス化 • 2.ミドルウェアのサービス化 • 3.システム構成のコード化 17
- 19. Cloud 1.インフラのサービス化 • 仮想化技術の応用 »SDx：ソフトウェアであらゆるものを定義する »広大なデータセンターの上に自分のための仮想インフラを構築 • インフラを「所有」から「利用」へ »IaaS（Infrastructure as a Service） »例：AWS EC2 18
- 20. Cloud 2.ミドルウェアのサービス化 • サービス化されたミドルウェア＝プラットフォーム »PaaS（Platform as a Service） »AWS RDSはデータベースサーバーのレンタルではない ▸バックアップもクラスタ構成も設定するだけ • 高度化するプラットフォーム »Webアプリ基盤：AWS Elastic Beanstalk »開発ライフサイクル込み基盤：AWS CodeDeploy/CodePipeline »サーバレス：AWS Lambda 19
- 24. DevOps DevOpsのはじまり • 2009年：DevOps »Agile 2008：Agile Infrastructure & Operations ▸政府系データセンターの移行にスクラムを導入した事例発表 ▸インフラ/運用系にアジャイル文化を導入しようとする機運 »Velocity 2009：10+ Deploys Per Day ▸Flickrにおける開発と運用の協業について »Devopsdays Ghent 2009 ▸ここから「DevOps」が生まれる 23参考：「The (Short) History of DevOps」（Damon Edwards） https://www.youtube.com/watch?v=o7-IuYS0iSE
- 25. DevOps Dev❤Opsのテーマ • そもそも開発と運用は仲が悪かった »「変更」と「安定稼働」は相反する • 頻繁に変更することが前提になった »リリース回数の圧倒的な増加 »システムの停止＝価値の棄損 • 開発が運用のことを意識すればいい »大抵の運用作業が自動化できてしまう 24 ビジネス 要件 企画 開発 運用
- 29. DevOps DevOpsがもたらした変化 • リリース（変更）が日常の行為 »Amazonは1時間に最大1000回もデプロイする ▸ http://www.publickey1.jp/blog/12/amazon11000_aws_reinventday2_am.html »繰り返すからこそ自動化するメリットが出る • コードが運用組織を不要化していく »運用機能を開発すればオペレーターは不要 »不要になるぐらい自動化しないとリリースが日常化しない 28
- 30. Microservices 29
- 31. Microservices マイクロサービスアーキテクチャとは • 2014年：「Microservceis」 by James Lewis »2011年：先端的なウェブサービス企業が似たようなアーキテクチ ャスタイルを取っていることが議論に »33rd Degree 2012「Microservices - Java, the Unix Way」 • DevOpsの発展系 • 実体に名前を付けたもの »コンセプトありきではない 30 参考：http://martinfowler.com/articles/microservices.html 参考： http://2012.33degree.org/talk/show/67 ビジネス 要件 企画 開発 運用
- 32. Microservices マイクロサービスの特徴 • Componentization via Services • Organized around Business Capabilities • Products not Projects • Smart endpoints and dumb pipes • Decentralized Governance • Decentralized Data Management • Infrastructure Automation • Design for failure 31 https://martinfowler.com/articles/microservices.html
- 39. Microservices 課題：テスト • 無限のテストケース »個別パーツのテストがパスしても、組み合わせでエラーになる »しかも、個別パーツは好き勝手にバージョンアップする ▸Test Doubles（スタブ/モック）の限界 • Consumer-Driven Contract testing »コンシューマーが要求するAPI挙動を契約として定義し、プロバ イダが契約を検証して破壊的変更を防ぐ 38
- 40. Microservices マイクロサービスがもたらす変化 • 現在でも進化を続けている状況 »サーバレス、コンテナオーケストレーション、非同期ストリーム • プラットフォームと個別サービスというエコシステム »オンラインゲーム向け、IoT向けなどのドメイン特化プラットフォ ームの出現 ▸新たなプラットフォーマーの出現 ≒ 現代のWintelは誰になるのか »標準化のEU、実力主義の北米 39
- 41. ITトレンドの流れ サマリ 40
- 42. ITトレンドの流れ サマリ 41 2001年 Agile 2009年 DevOps 2006年 Cloud 2014年 Microservices 2010年 ブルーグリーンデプロイメント 2011年 Microservicesのアイデア 2012年 カナリアリリース 2006年 AWS EC2 2009年 AWS RDS 2011年 AWS Elastic Beanstalk 2014年 AWS Lambda
- 43. ITトレンドの流れ サマリ • システム開発にアジャイルの考え方が求められた »計画駆動から調整駆動へ • クラウドの発展によりアジャイルに適した仕組みが進化 »自動化による疎結合アーキテクチャの実現 • 現時点ではMicroservicesとして進化中 »マネジメント論＋アーキテクチャ論 42
- 46. 日本のエンタープライズITの状況 Agile • 稟議という意思決定システムは計画主導になりがち »「やってみなければ分からない」が通じにくい • 外部調達なチームを維持するが困難 »社内にエンジニアが少ないのでリソース調達が外部頼りになる »準委任契約のコストは資産ではなく経費 • 継続的に改善し続ける＝「保守」から抜け出せない »「守りの作業」が中心になりがち 45
- 47. 日本のエンタープライズITの状況 DevOps • 運用部と開発部という組織の壁 »お互いが文書でやり取りすることになれてしまっている • 過去の知見/観点から抜け出せない »クラウドを仮想化インフラ（IaaS）としてしか扱えない »自動化文化 • エラーゼロが常識 »エラーゼロであるべき領域はあるが、多くのケースではリロード で済んでいるのは？ 46
- 49. 今後にむけて 48
- 51. 今後にむけて 期待をこめて • 改めてAgileの機運は高まっている気がする »デジタルトランスフォーメーションへの経営的興味 • アーキテクチャ論としてアジャイルを語れる »マネジメント論だけの状況よりも具体的 • Microservicesは段階的に取り組める »全部を作り直すのではなく、必要な部分からMicroservices化 »再構築でMicroservicesはナンセンス 50