日本のDevOps変革を促進するバリューストリームマッピング | gihyo.jp
アジャイルとDevOpsを組織全体に適用するための指南書『変革の軌跡』が2017年1月25日（水）に発売されます。本書の発売を記念して、マイクロソフトの牛尾剛さんにバリューストリームマッピングについて寄稿いただきました。 バリューストリームマッピングの重要性 みなさんの会社で、DevOps変革を推進するために、最初の第一歩として何をすべきだろうか。筆者は間違いなく「バリューストリームマッピング」をお勧めする。バリューストリームマッピングは、リーン生産方式の技法の1つであり、製品やサービスを顧客に届けるために必要なプロセスを分析するのに使用される。トヨタで使われていた手法をもとにしている。 バリューストリームマッピングの話を始める前に、Gene Kimがまとめた「DevOpsのThree Ways」についてお話ししておきたい。これは、DevOpsの3つの目的を明確にしたものだ。1つ目はアイデ
システム運用は自動化が常識に、NoOpsまでの歴史
システム運用の自動化を目指す「NoOps」が現実のものとなりつつある。クラウドやサーバーレス、自動化ツールの活用によって、障害からの自己修復も実現可能になった。 NoOpsは、「No Operations」の略。その名の通り「人間によるシステム運用作業の最小化」を目指す継続的な活動である。これまで長い間、システムの運用保守は、夜間の緊急連絡や休日出勤による担当者への負担、そしてシステム停止という形での利用者への負担を強いることが当然だと考えられてきた。 「壊れても回復できる」の発想へ転換 HA（ハイアベイラビリティ）やDR（ディザスターリカバリー）といった冗長化の仕組みを導入してシステムの可用性を高めても、いざ障害が発生すると、元の正常な状態に復旧するために、初期対応から原因究明、不具合修正など、担当者総出の作業が必要だった。 一方で、コンピューティング技術やネットワーク技術の進化と成熟に
Modern Agile 入門 #modernagile - @i2key のBlog
完全に出遅れ感ありますが、モダンアジャイルが気になってきたのでちょこっと自分の中で理解のために整理をしてみました。モダンアジャイル自体にプラクティス厨やめろというメッセージが含まれているかとは思いますが、とは言え、本家 Modern Agile - Industrial Logic でもある程度はプラクティス風な記載はされているので同様にやるべきこと、やるとよいことをプロットして思考を整理しました。箇条書きで見にくいかとは思いますが、あくまで自分用なので。今後追記編集していくかもです。テキトーに自分用メモとして書いただけなので間違ってたら指摘ください。また、入門というタイトルは自分が入門しただけなので、入門者のために書いてるわけではないのであしからずw 各プラクティスや方法論は理解してる前提で箇条書きしてます。 Modern Agileの位置づけの理解 ここにプロットされている諸々の方法論
Scrum / DevOps の導入を加速するグローバルマインドセット ～８つの習慣 その１ ～ - メソッド屋のブログ
クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「８つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。 今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「８つの習慣」を初めて発表させていただいた。 2017.scrumgatheringtokyo.org 「８つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうま
MS率いる黒船軍団が“DevOps鎖国”日本に開国を迫った日 (1/4)
牛尾氏は、DevOpsが浸透していない日本の現状を示した。調査によると、企業のソフトウェア開発プロジェクトにおけるアジャイル手法の採用率は、世界平均では95％（Version One調査、2015年）とすでにデファクトの位置付けとなっているのに対し、日本ではまだ31％（PMI調査、2015年）にとどまるという。エンタープライズ領域のソフトウェア開発を中心として、日本のDevOps導入は明らかに立ち遅れている。 こうした日本の現状について、牛尾氏は「200年前の『鎖国』時代とまるで同じだ」と厳しく指摘する。 「鎖国時代の日本は、2世紀にもわたって何も変化しなかった。新しいテクノロジーも、新しいライフスタイルも、海外から一切何も学ばなかった。一方で、そのころの米国では産業革命が始まり、新しいテクノロジーによって産業も社会構造も根本的に変化していった」（牛尾氏） この長い鎖国時代を通じて、欧米諸
DevOps スタータキットの公開 - メソッド屋のブログ
DevOps の概要、プラクティス、そしてそれに関するリソースを整理して自ら学習しやすいようにしてみました。DevOps の考え方、プラクティス毎に、ビデオとそこで使っているPPTを公開しますのでお楽しみください。 channel9.msdn.com docs.com docs.com 1. DevOps の歴史 DevOps を学ぶときに、海外と比べると日本の商習慣が異なるので、向こうで話されているDevOps の概要を聞いてもピンと来ないかもしれません。そこで、DevOps の歴史を7分程度で学べる動画を作成しました。 これで、DevOps が生まれきた背景が学べると思います。 docs.com 2. DevOps の概要 DevOps の歴史を知るとと、DevOps の概要がよりわかりやすいかもしれません。次のビデオをご覧ください。 docs.com DevOps プラクティス ビデ
突撃！隣のDevOps パート1【Wantedly編】 | DevelopersIO
はじめに こんにちは！おおはしりきたけです。今回は、突撃！隣の開発環境ではなく、突撃！隣のDevOpsというタイトルで、イケてる開発会社さんのDevOpsについてインタビューさせてもらいました。パート1として突撃！隣の開発環境のパート1でも紹介させて頂いた、WantedlyさんにDevOpsをどのようにやっているのかを伺ってきました！ 突撃！隣のDevOpsとは 突撃！隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、「開発」に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発（Development）と運用（Operations）が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求められます。そこで、突撃！隣のDevOps
自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダーにおくるDevOps実現のためのチームづくり
Shows