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