1. 基礎からわかるDevOps 2016/11/11 Ryuzee.com 吉羽龍太郎
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する 従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee
4. 時価総額ランキング 2016 2006 1. アップル (6091億ドル) 1. エクソンモービル (4470億ドル) 2. アルファベット (5434億ドル) 2. GE (3840億ドル) 3. マイクロソフト (4487億ドル) 3. マイクロソフト (2940億ドル) 4. Amazon (3969億ドル) 4. CITIグループ (2730億ドル) 5. Facebook (3683億ドル) 5. ガスプロム (3680億ドル)
5. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertainty (不確実) / Complexity (複 雑) / Ambiguity (曖昧) ✤ ITはビジネス上の成果達成のための重要な要素に ✤ 多くのサービスがこの10年以内に登場し既存のビジネスモデルに影響を与 えたり、人の働き方を変えている。GitHub (2008), Dropbox (2008), Evernote (2008), Slack (2014), Uber (2010), Airbnb (2008) , SORACOM (2015, Japan)
6. システムの機能の利用割合 いつも使う 7% よく使う 16% たまに使う 13% まったく使わない 45% ほとんど使わない 19% The Standish Group “Chaos” report 2002
7. システムの機能の利用割合 いつも使う 7% よく使う 16% たまに使う 13% 64% まったく使わない 45% ほとんど使わない 19% の機能はほとんど、もしく はまったく使われていない。 PCのプレインストールソフ トウェアなどを考えると想 像がつく The Standish Group “Chaos” report 2002
8. あなたの開発はムダだらけ？ ✤ 作りすぎのムダ => 使わない機能 ✤ 手待ちのムダ => 仕様未決で開発待ち ✤ 運搬のムダ => 他部署への引き継ぎ ✤ 加工のムダ => ドキュメントの体裁 ✤ 在庫のムダ => 同時にたくさん着手 ✤ 動作のムダ => 不要な作業、遅い作業 ✤ 不良を作るムダ => バグ修正
9. うちのチーム1スプリント ですごい量の新機能作れ るんだぜ！
10. うちのチーム1スプリント ですごい量の新機能作れ るんだぜ！ 使わない機能を作ってしまうのを避けなければならない。 作り過ぎるとコスト、複雑度、アプリやバグ調査のための時間などが増え てしまう。
13. 本当に顧客が望んでいるもの を予測したり、その機能が使 われるか、ビジネス価値向上 の余地があるかを予測するの は難しい
14. 事前に正しいことを知るのは難しい。 素早い変化についていける能力を持つことが重要
15. すばやいフィードバックサイクルを作る d Learn Bu il s a e M e r u
16. ウォーターフォール(V字モデル) 要件定義 受け入れ試験 基本設計 総合試験 詳細設計 結合試験 製造・単体
17. ウォーターフォール(V字モデル) 要件定義 受け入れ試験 た 来 、出 て ぎ も す そ り も か 基本設計 そ か 。 が 化 間 こ 変 時 が が と 求 こ 要 い は な に い 頃 て っ あ る が か 件 分 要 こで 詳細設計 製造・単体 総合試験 結合試験
18. すなわち巨大なウォーターフォールは 変化の早い領域では機能しない
20. 領域別の特性 正解が存在し変化の少ない 領域。状況を理解・分類し、 ベストプラクティスに基づ いて進めていく
21. 領域別の特性 正解が1つではないものの、 比較的予測しやすい領域。 状況を専門家が分析して理 解し、取り得る手を検討し て進めていく。うまくやる 方法は複数あるためそれを グッドプラクティスとして 活用していく
22. 領域別の特性 問題を把握するために試行 錯誤（探索）を行い、それ によって状況を把握・理解 する領域。そのあとに次の 対応を考えていく。この場 合、うまくやる方法はあと からわかることになる
23. 領域別の特性 革新的なことが求められる 領域で正しい答えもわから ないので、まず行動してか ら理解していくしかない領 域。既存の知識が役に立た ないこともある
24. 領域別の特性 そもそも上記の4つのどれに あてはまるかもわからない 状況を指す
25. 領域の分類例 領域 対象業務 典型例 明白な領域 業務の一部 経理システム、データ入力、エンドユーザーコン ピューティング 込み入った領域 バックオフィス業務 ERP 複雑な領域 他部署や社外との連携 サプライチェーンマネジメント カオスな領域 新規事業 R&D、スタートアップ、ソーシャルゲーム
26. 領域の分類例 領域 対象業務 典型例 明白な領域 業務の一部 経理システム、データ入力、エンドユーザーコン ピューティング 込み入った領域 バックオフィス業務 ERP 複雑な領域 他部署や社外との連携 サプライチェーンマネジメント 対象領域によって開発手法を選ぶ必要性 カオスな領域 新規事業 R&D、スタートアップ、ソーシャルゲーム
27. アジャイル開発のメインストリーム化 State of Agile Survey 2014 (c)VersionOne
28. アジャイル開発手法の利用状況 VersionOne 10th Annual State of Agile Report
29. 課題の整理 ✤ よいソフトウェアを顧客に届けることはビジネスにとって極めて重要 ✤ しかし届ける速度は遅く、間違いがおこりやすい (特にトラディショナル な企業や大企業…) ✤ これによってビジネス上の機会やお金を失う ✤ 他にも自分たちには問題が ✤ ITがボトルネックになっている
31. DevOpsの起源 ✤ Agile 2008 ConferenceでPatrick Debois氏 (veeweeや sahara等のOSS ツールの作者)が、 Agile Infrastructure & Operations というテーマで 発表 ✤ 2009年のO Reilly Velocity ConferenceでFlickrのエンジニアJohn AllspawとPaul Hammondが行った発表 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.
32. https://www.youtube.com/watch?v=LdOe18KhtT4
33. DevOpsの構成要素 ✤ Culture (文化) ✤ Lean (リーン) ✤ Automation (自動化) ✤ Measurement (測定) ✤ Sharing (共有)
34. DevOpsは銀の弾丸ではない ✤ 皆様!! 弊社の最新ツールを導入すると簡単にDevOpsを達成できますよ ✤ みんな、他の会社のCEOから聞いたんだけどその会社DevOpsを導入して 成功したらしいよ。すぐうちもやろう！すぐそれもってきて！予算つける から！ ✤ DevOps?? やっとかよ。待ちくたびれたな。早速自動化コード書こうぜ。 自動化しなきゃいけないものが沢山あるんだ
35. DevOpsは銀の弾丸ではない ✤ 皆様!! 弊社の最新ツールを導入すると簡単にDevOpsを達成できますよ ✤ みんな、他の会社のCEOから聞いたんだけどその会社DevOpsを導入して 成功したらしいよ。すぐうちもやろう！すぐそれもってきて！予算つける から！ ✤ DevOps?? やっとかよ。待ちくたびれたな。早速自動化コード書こうぜ。 自動化しなきゃいけないものが沢山あるんだ
36. DevOpsは文化とツールを活用することで、 ビジネスの成功を目指すものであり、 ビジネスのためのアジリティを向上させ、 リスクを低減するものである。
38. OpsはDevのような考え方をし DevはOpsのような考え方をする しかし……
39. DevとOpsの間でのコンフリクト ✤ ミッションや責任の違い (それは誰が決めたのか ないが…) だし合理的かはわから ✤ それは自分の仕事じゃないです、という台詞の誘発 (誰がそんなこと言っ てるんだ?) ✤ サイロ型組織 ✤ そしてオーバーヘッドが生まれる
41. なんでアプリをもっとちゃんとした 品質で作らないんだよ。夜間コール がんがん受ける身にもなれよ
42. アプリとサーバをちゃんと動かすの がおまえの責任だろ。おれのせいに するな なんでアプリをもっとちゃんとした 品質で作らないんだよ。夜間コール がんがん受ける身にもなれよ
43. 同じような話があなたの組織にもある？ ✤ このコードは僕が書いたんじゃないので分かりません ✤ このタスクは○○さん担当なので僕を責められても… ✤ これは規則で決まってるんです。なので従わなきゃいけません… ✤ 他の部門がいつも遅いんで、そのせいで遅れるんです… ✤ 他の仕事があるんで…
44. 実際のところ、ソフトウェア開発上の問題の多くは、 技術的というより社会学的なものである –トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
45. サイロによるオーバーヘッド ✤ 他の部門とのコミュニケーションにかなり多くの時間を使っている ✤ (もちろんコミュニケーションは重要だが、問題は中身が手続き論に終始 しがちなこと) ✤ 結果として顧客にとって直接的に価値になることに時間が使えていない
46. 時間の4分の1以上が会議に費やされているならば、 組織構造に欠陥があると見てよい –ピーター・F. ドラッカー
47. 原則 ✤ チームは他の部門に引き継ぎすることなくソフトウェアを直接顧客に届け られる能力を持っていた方がよい ✤ 可能であれば組織構造を変え、密結合な組織間の関係を疎結合に
48. Werner Vogels, CTO, amazon.com You build it, You run it
49. 2ピザルール チームのサイズを 2枚のピザでみんなが満腹になるサイズに保つ
50. チームの進化 タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立 意見を言うようになる 一緒に活動し、異なる よく機能するチームと 目的を果たし、チーム しておりコミュニケー が、一方で自分と違う 意見を受け入れる。目 なる。チームには一体 が解散する時期 ションが少ない 意見に抵抗を示すよう 的や期待値などが一致 感がある。自立性が高 になる する い
51. すごいチームを作る：多様性は改善を加速する
52. コミュニケーションオーバーヘッドの削減 ✤ Amazonはamazon.com用のサーバを調達する手続きをAPIに置き換えた ✤ そうすることで、コミュニケーションオーバーヘッドを削減しプロビジョ ニングまでの時間を短縮
53. 組織構造はアーキテクチャに影響を与える ✤ コンウェイの法則 ✤ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations - M. Conway ✤ システムを設計するあらゆる組織は、必ずその組織のコミュニケーション 構造に倣った構造を持つ設計を生み出す ✤ Microservicesに関心があるかもしれないが、それを実現できるかどうか は自分の組織構造に大きく依存。過度な幻想を抱かないこと
54. 組織構造が及ぼす影響の考察 (開発部門とインフラ部門の例)
55. 組織構造 (1) ✤ 開発部門とインフラ部門が独立した組織で、独立したチームのもとでプロ ジェクトを実施する場合 開発部門 インフラ部門
56. 組織構造 (1)における考察 ✤ SI等でよくある組織構造。部門単位で利益確保したり部門配賦をおこなう ✤ ポテンヒットを避けるために責任分界点を明確にしたがる ✤ 強力なコントロール ✤ 部門間のコミュニケーションは文書によるものが多い (例)払い出し依頼 ✤ インフラ提供メニューを均質化しやすく、払い出しはある程度自動化可能
57. 組織構造 (1)における課題 ✤ 同じ専門性の人は一箇所に集めた方が効率的になる、という誤解 ✤ コミュニケーションのオーバーヘッドが大きい ✤ リアルタイムな対応が難しくリードタイムの考慮が必要 ✤ 初期の作業効率化や再利用性のメリットは享受できているが、サービス全 体の視点が抜けやすい ✤ 責任範囲を分けても残るポテンヒットと非効率
58. 開発部門1 開発部門2 インフラ部門 開発部門3 組織構造 (1-1)
59. 組織構造 (1-1)における考察 ✤ 開発部門がどんどん増えた場合にインフラ部門側がボトルネックになる可 能性 ✤ ビジネスの要求に関係なく、インフラ部門としてのSLAを基準にしてイン フラが作られる ✤ 均質化を進めないと対応しきれなくなるのでアプリ側の要件をインフラに あわせることを要求しはじめる ✤ ビジネス側の論理より組織構造の制約を優先してしまっている ✤ ビジネス側、アプリ側から不満が出てくる可能性
60. 開発部門 サービスA サービスB サービスC サービスD インフラ部門 サービスE サービスF 組織構造 (1-2)
61. 組織構造 (1-2)における考察 ✤ 開発とインフラで部門や責務を分離しているのにマイクロサービス化しよ うとした例 ✤ 各サービス側はI/Fの一貫性を維持しながらサービスの更新をおこなって いくが、インフラの変更が重荷になる（基本的には破綻の方向） ✤ インフラ側はいつ何をやるべきか制御しきれずリードタイムが安定しない ✤ 個々のサービスまで把握できないので純粋にインフラだけを提供する形と なり運用まで責任を持つことは相当難しい ✤ セルフサービス化「しない」意味がなくなってくる
62. 組織構造 (2) ✤ 開発部門とインフラ部門が独立した組織だが、プロジェクト単位でバーチャ ルチームを作る構造 開発部門 インフラ部門
63. 組織構造 (2)における考察 ✤ インフラ担当がチームに参加するためコミュニケーションの負荷は減る ✤ 一方で複数プロジェクトを兼任した場合インフラチームではなく個人に負荷 が偏ってしまう ✤ 部門単位の利益や稼働率といった前述の問題は解消しきれない可能性は残る ✤ 個人の能力への依存を避けるために、インフラ部門での情報やベストプラク ティスの共有が必要になる ✤ アーキテクチャはアプリケーション個別に最適化しやすい ✤ 運用に入ったあとも体制を維持できれば変化に対応し続けられる
64. 組織構造 (3) ✤ 製品単位でチームを作り、その中にインフラエンジニアを含める。製品は もっと粒度の小さいサービスであることもある 製品Aチーム 製品Bチーム 製品Cチーム
65. 組織構造 (3)における考察 ✤ サービスをゴールにできるので集中しやすい ✤ チーム内でフルスタックに構成したチームで一番変化に強くなる ✤ 必ずしもインフラ専任とは限らずアプリ開発者のうちインフラもできるエ ンジニアが担当することもある ✤ 他の製品チームをあまり意識することがないので全製品をまたいだ一貫性 は担保されない可能性 ✤ 認証やセキュリティ等をどう要求基準にあわせるかについてはコントロー ルが必要
66. 組織構造 (3-1) 製品Aチーム ✤ 先ほどのチームに加えて標 準化(や最低限の基盤)・セキュ リティチームを用意する （仮想チームであることも） 製品Bチーム セキュリティ/標準化 製品Cチーム
67. 組織構造 (3-1)における考察 ✤ 前述の組織構成を活かす一方で、リスクとなりそうな箇所を標準化したり、共 通系サービスを提供したり、必要な部品を提供していく。社内オープンソース ✤ 例えばクラウドを利用している場合はセキュリティ設定済みのイメージ、 Terraformのスクリプト、各種ガイドラインなど。場合によっては定期的に検 査をおこなうような形 ✤ チームの自律性＋外部からの最低限守るべきルールの提供という形になるため スピード・自由度・安全のバランスが取れる ✤ Infrastructure as Codeやマイクロサービスのメリットを最も享受しやすい ✤ AmazonとかNetflixはこんな感じ
69. リーンシンキング ✤ 組織をまたがるバリューストリームに注目する ✤ もしチームがサイクルタイムを減らせたとしても必ずしも全体のリードタ イムが短くなるとは限らない ✤ ボトルネックが存在する可能性がある… ✤ 制約理論(ToC)を学ぶとよい
70. ケーススタディ(1)このプロセスの問題は？ 不具合… デプロイ拒否 修正待ち… 分析 開発 Dev テスト QA / デプロイ Ops $$$$
71. ケーススタディ(1) ✤ このケースでは全体のリードタイムがソフトウェアの低品質によって引き 起こされている。なのでデプロイを自動化してもデプロイできるフィー チャーの数は増えない
72. ケーススタディ(2) ボトルネックはどこ？ WIP: 2 2日/ WIP: 4 3日 / WIP: 6 2日/ WIP: 1 20日 / 機能 機能 機能 機能 分析 開発 テスト QA / デプロイ Dev Ops $$$$
73. ケーススタディ(2) ✤ このケースではリードタイムはとても長い。というのもQA/デプロイが20 日も占めているから。さらに同時に1つしかデプロイできないのでスルー プットも低い。ここでDevチームの生産性を向上させても全体のリードタ イムとスループットの向上はわずか
75. トヨタ生産方式(TPS)では ✤ 前工程は神様 後工程はお客様 ✤ 前工程がきちんとした品質のものを届けてくれる(のに感謝) ✤ 顧客とは実際のエンドユーザーだけでなく、内部の後工程も指す ✤ 品質を作りこむ。不良を次工程に回さない (プロセスを逆流させない)
76. 継続的な改善を続ける ✤ 改善とは、自分たちの仕事を「安全」にする ✤ 改善とは、自分たちの仕事を「簡単」にする ✤ 強制的に立ち止まれる仕掛をつくる (人間は停止するのが苦手) ✤ 問題を防ぐところにいきなり効率は求めない (まず穴を塞ぐ)
78. 5S (整理/整頓/清掃/清潔/しつけ) ✤ 整理：必要なものとそうじゃないものを分け不要なものは捨てる (いつか 使う？は使わない…) ✤ 整頓：必要なものをジャスト・イン・タイムで取り出せるようにする。人 の動きや利用頻度で場所を決める。定位置を定める ✤ 清掃：きれいに掃除する=予防 (その時間を業務に組み込む) ✤ 清潔：整理・整頓・清掃を維持する ✤ しつけ：これらのルールを守らせる
79. 例えば？ ✤ ✤ ファイルサーバにたまった大量のドキュメントを考えてみよう ✤ 古くて不要になったもの ✤ 作りかけのもの ✤ 複製されてちょっと改変されたもの ✤ 本当は必要なのに更新されていないもの 笑い話：あるドキュメントに「この記述をみつけた人にビール奢ります」 と書いたところ誰からも連絡がなかった
80. 春の大カイゼン運動 生産性 改善の数 90 67.5 45 22.5 0 1 2 3 4 5 6 7 8 9 10
81. 春の大カイゼン運動 生産性 改善の数 90 67.5 45 「改善運動」ではなく「改善活動」を 22.5 0 1 2 3 4 5 6 7 8 9 10
83. カイゼンのパターン：工程をなくす(Eliminate) Before 工程A After 工程A 工程B 工程C 工程C
84. カイゼンのパターン：工程を統合する(Combine) Before After 工程A 工程B 工程A 工程C
85. カイゼンのパターン：順番を変える(Rearrange) 手戻り Before 工程A 工程B 工程C After 工程C 工程A 工程B
86. カイゼンのパターン：単純化する(Simplify) 工程B1 Before 工程A 工程B 工程C 工程B2 After 工程A 工程B 工程C
88. 基本的な考え方 ✤ 自動化にはコストがかかる ✤ 基本ができていない場合は達成まで時間もかかる ✤ 作業でやった場合と比較してどちらが安いか ✤ 実行回数や問題が発生した場合の対処コスト等を含めて考える ✤ ただし、損益分岐点は思った以上に早い ✤ 顧客が要求するスピードやアプリケーションのライフサイクルを踏まえる ✤ 自動化それ自体は「ゴールにはならない」
89. どのツールから始めるか ✤ まだやっていなければ、バージョン管理、テストの自動化、継続的インテ グレーションのような基本的な技術要素からはじめる ✤ バッチサイズを小さくして、ビジネスのニーズにあわせて頻繁にデリバリー しようとすると何が必要か？ ✤ 継続的な品質保証、確実なデプロイ、影響範囲の局所化… ✤ 作業を「安全に」「簡単に」
90. テスト自動化 自動化しない場合のテスト工数 自動化した場合のテスト工数 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10
91. テスト自動化 自動化しない場合のテスト工数 自動化した場合のテスト工数 100 75 ビジネス側は肥大化する回帰テストによる 速度低下とコストを負担したいはずがない 50 25 0 1 2 3 4 5 6 7 8 9 10
92. デプロイ自動化 ✤ バージョン管理、テスト自動化(単体・受け入れ)、データベース自動マイグ レーション、継続的インテグレーションができるようになれば、デプロイ の自動化が可能 ✤ 毎回同じ手順で、頻繁にデプロイできるようにする ✤ 成功・失敗を人による判断に委ねない (自動で判定する) ✤ 失敗したらすぐにロールバックできるようにしておく ✤ 綺麗なアーキテクチャはデプロイしやすさにつながる
93. インフラ構築自動化 (Infrastructure as Code) ✤ アプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも 適用可能 (バージョン管理、テスト自動化、継続的インテグレーションなど) ✤ 領域はサーバの内部(OSの設定やミドルウェアの設定)だけに限らない ✤ サービスを動かすインフラ全体(ネットワークやそもそものサービススタック 全体)が対象になり得る ✤ インフラなのかアプリなのかの境界がなくなっていく (そもそもビジネス側はそれぞれの区分けに関心があるわけではない)
94. ツールの導入の原則 ✤ ツールが組織構造の問題を解決するわけではない点を理解する ✤ なぜそのツールを導入するかの理由を明確に ✤ メジャーなツールを選ぶ ✤ 同時に沢山のツールを導入しない ✤ 利用者を教育する ✤ 自分たちでメンテナンスする
96. 見えないものは改善できない ✤ 効果を測定したり、改善すべき点を見つけるためには、現状を見えるように する必要がある ✤ データはいつでも誰もが簡単に見えないといけない ✤ 以下のようなデータを測定することが多い ✤ 開発速度(ベロシティ)、不具合数、デプロイ回数、変更量、リードタイ ム、失敗したデプロイ回数、障害からの復旧時間(MTTR)、平均障害間 隔(MTBF)、チケット数、可用性、パフォーマンスデータ、リクエスト 数、ユーザー数、ユーザー増加数、機能別利用状況、売上… ✤ データで共通理解を持ち、プロセスや製品の改善に活用する
97. データを冷蔵庫に入れない いつでも簡単に「見たくなくても」見えるようにする https://www.flickr.com/photos/bradipo/5617896008/
98. https://www.flickr.com/photos/intelfreepress/6675763157/
100. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
102. なにを共有するのか？ ✤ ビジョンやゴールを共有する ✤ 背景や対象の理解を共有する ✤ 責任や成功を共有する (Shared Responsibility) ✤ 経験や学びを共有する これらは開発と運用の間だけに限らない
103. Endless Journey to DevOps
104. なぜDevOpsが必要か？ ✤ ビジネスが速い速度で変化するから ✤ ただ、なぜ自分の組織でDevOpsが必要なのかは自分たちで明らかにする 必要がある ✤ DevOpsがトレンドで流行しているから というのは最悪な答え ✤ 自分たちの目的を見つける ✤ いきなり「クリティカル」な領域で試さない
106. 事例を収集する上で、第一になさなければならないことは 「事例を収集する意味を明確にすること」
107. DevOps実現の典型的なステップ ✤ 全体のプロセスを見る ✤ ビジネスとITの関係における問題や課題を見つけるとともに、全体を遅く しているボトルネックを探す ✤ フロー、あるべき姿、状況確認のためのメトリクス、スケジュール、体制 などを計画する ✤ これらをPDCAサイクルで繰り返す ✤ すなわちDevOpsはアジャイルなやり方で実現していくべき
108. やるべきことに優先順位をつける ✤ こうやったらよさそうというものは沢山見つかるかもしれないがリソース や費用の制約、日々の仕事もあるので一度に全部はできない。 ✤ 一度に沢山のことを変えるのは自分やチームや組織を混乱させる。またど れに効果があったのかもわかりにくいので避ける。
109. 継続的にプロセスを改善し続ける ✤ 全体のバリューストリームと自分たちのまわりの両方に注意を払う。ふり かえりはどんな開発手法を採用しているかに関係なく有効 ✤ ゴールに向かって進んでいるかをメトリクスを使って確認する
110. リーダーシップとスポンサーシップが必要 ✤ 全員がリーダーであること。そしてDevOpsは組織にかなり関係があるた め経営からのスポンサーシップが必須。自分のまわりを改善するだけでも 効果はあるかもしれないが、システム全体を改善するともっと大きな利益 があるはず
111. (再掲)DevOpsの構成要素 CLAMS ✤ Culture (文化) ✤ Lean (リーン) ✤ Automation (自動化) ✤ Measurement (測定) ✤ Sharing (共有)
112. 提供サービスの概要 アジャイルコーチング Agile開発については多くの誤解があり、 また経験の無いチームが自力で行うのは 難易度が高いものです。当方ではオンサイ トでAgile開発での企画∼開発まで全工程 を支援します。例えばプロジェクト立ち上 げに際しての集合研修、ふりかえりや計画 ミーティングのファシリテーションな ど。 DevOps実践支援 Cloud Architecting支援 ビジネスの成長やシステムの利用状 況に柔軟に対応できるのがクラウド の特性ですが、一方でシステムアー キテクチャがレガシーであればその メリットを享受できません。本支援 ではマイクロサービス化を始めとし て、柔軟で結合度の低いクラウドネ イティブアーキテクチャの構築を支 援します。 DevOpsには組織とツールの2つの要 技術顧問・執筆・講演 素があります。サイロ型の組織構造 技術顧問として定期的に訪問した のDevOps型組織への転換(組織デザ り、Agile・DevOps・クラウドに関 イン、採用プロセス、評価プロセ する講演をいたします。またWeb・ ス)、ツールによるデプロイ・プロビ 書籍・雑誌など各媒体向けの執筆・ 翻訳を行ないます。 ジョニング・運用・監視の自動化な ど幅広い側面で支援します。 主な提供トレーニング：「強いチームの作り方」「カイゼン」「スクラム」「カンバン」「Chef入門」など
