Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

LiBRA 09.2019 / 開発と運用

647 visualizaciones

Publicado el

https://libra.netcommerce.co.jp/

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

LiBRA 09.2019 / 開発と運用

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

×