DevOpsが日本でも取り上げられるようになり数年が経ちました。

DevOps Day Tokyo の開催も、Developers Summit Summer での基調講演も、2013年の出来事でした。その後、DevOpsと呼ぶかは別として機敏な企業で実践され、書き下ろしの書籍や翻訳書も増えてきました。

DevOpsもバズワードの仲間入りを果たし、メディアもベンダーもDevOpsをキーワードとしています。手段やツールに焦点が当たる中、バズワードに振り回され、迷い道に導かれる方も増えてきたと感じます。

このセッションでは、エバンジェリストとして ITの現場の苦悩と、ビジネスの現場の期待を背負ったDevOpsについて見てきた経験から、できるだけビジネスの視点でDevOpsに取り組むにあたって持つべき指針や姿勢について俯瞰して見ていきたいと思います。

DevOps を始める最初のステップとして、大変有効なValue Stream Mappingの具体的な進め方について解説いたします。Value Stream Mappingによって、皆さんのプロジェクトの無駄や、自動化可能箇所を発見、共有することができ、リードタイムの削減に大変貢献いたします。特に日本で必要なステップやステークホルダの巻き込み方、ファシリテートの仕方まで踏み込んで解説いたします。

　講演者は、Value Stream Mapping を多数実施した経験そして、第一人者のMary Poppendieck との共演で学んだこと、他国の動向も含めて楽しく解説していきたいと思います。

なにするの?

全員で1つの同じコンピュータを使って仕事をするモブプログラミングという開発手法で、
「ゼロから始めるDevOps(youtube)」で紹介されている以下の内容を含むパイプラインを、
VSTSと、WebApps、Load Testを使って構築します。

• GitHubにあるC#で作られたWebアプリケーションをビルド
• WebAppsを使ったWebサイトをInfrastructure as Codeで構築
• Webサイトにビルドしたアプリケーションをデプロイ
• Webサイトに対して負荷テストを実施

モブプログラミングって何?

Hunter社のWoody Zuill氏らが作り上げた、全員が同じ時に、同じ場所で、同じコンピュータ上で仕事をするソフトウェア開発手法です。
(モブプログラミング - Woody Zuill氏とのインタビュー より。一部改変)
その様子については動画 A day of Mob Programming - YouTube が詳しいです。

日本でも最近チャレンジされている方が増えてきているようです。

• モブプログラミングを試してみてわかった事|ネスケラボ
• モブプログラミングやってみたら最高だった #MobProgramming ジムには乗りたい
• （なんちゃって）モブ・プログラミング（もどき）でスキル伝授をしてみた

なぜ開発環境にしたの?

1開発環境って、1,2人がもくもくとメンテしてる感じですよね。
でも、それを続けてると、立ち入り禁止区域みたいになるじゃないですか。誰それさんがいないから、ビルド止まったままですとか。あんまり嬉しくない状態ができたり。
開発環境だって、プロダクションコードと同じように、みんなでメンテできた方が良いですよね。

でも、それ､どうやんの? ってところで、モブプログラミングなんです。
全員で同じコンピュータ、同じスクリーンをみながら構築すれば、開発環境に関するあれこれをその場で全員が学ぶことができるわけです。
みんなで開発環境をメンテする第一歩にぴったりだと思いませんか?

 巷で噂のDevOps。

ところが、

• DevOpsってなんだろう？
• ぶっちゃけそんなにみんなやってるのかな？

などいまさら聞けないDevOpsが皆さんの中にきっとあるはずです。
今回はDevOpsをテーマに熱いパネラーと共に朝まで徹底生討論をします。

このセッションは参加型パネルディスカッションです。
実践できている人もまだできていない人も現場の話をしにきませんか？

パネラーは随時追加していく予定です。パネラーとして参加されたい方もご連絡下さい。
もちろん当日の飛び込み討論も歓迎です。もしかしたらあのDevOps有名人も！？

DevOps Days Tokyo2017に参加しようか迷っているそこのあなた！
あまり詳しくなくても実践できていなくても、興味さえあればきっと大丈夫なので、このセッションをきっかけに一緒にDevOps Days Tokyo2017に参加してみませんか？

スタートアップや、WEB系の企業では当たり前になりつつある、アジャイルやDevOpsの概念の導入が、
大企業ではなかなか浸透しないのはなぜだろう？
いま、KDDIでDevOpsという概念の導入を取り組みを試行錯誤している中で、
これは効果が出ていると思うプラクティスをご紹介いたします。
すでに実践している人には当たり前、でもやったことが無い人、そしてDevOpsのOpsに属する方たちは、
意外とわかったつもりでわかってない、気づいていないことがあるかもしれません。

DevOps を導入してリードタイムを短くしたり、フィードバックサイクルを短くしたい。でも具体的にどうしたらいいのだろう？本講演では、このような声にお応えして、DevOps 技術系プラクティスを解説しながら、具体的なデモを踏まえてどのようにDevOps プラクティスを実装すればいいのかを解説いたします。技術プラクティスのみに集中するため、DevOpsの概要や、導入手法などは他のセッションをご参照ください。CI / CD, Feature Flags, Canary Testing 等々を生で体験して持ち帰ることができるチャンスです。お見逃しなく！

「DevOpsにアジャイルは必要ですか？」
最近、頻繁に受ける質問です。

昨今、Docker・Chef・Ansible・Kubernetesなど、DevOpsを実現するためのツールの成熟とその活用事例が着実に増えつつあります。また、これらを紹介する書籍やオンライン記事も急増しています。

一方で、ツールに比重を置きすぎたり、ツールの導入・改善にばかり着目してしまうことで、本来実現すべきビジネス価値の創出（プロダクト改善）や、フィードバックによる成長といった側面（プロセス改善）が軽視されていないか？と言う疑問も感じています。

当セッションでは、DevOpsを「プロセスを促進する自動化技術基盤」と捉え、アジャイルの各種プラクティスと組み合わせることで、プロダクト開発の効率化、チーム・メンバーの学習・成長、およびステークホルダーとの協働を実現できることを、具体的事例に基づいてお話させていただきます。

InSpec is an open source testing framework that specifies compliance, security and policy requirements in a human-readable language. Compliance and security are the next steps in building your software-defined infrastructure, building resilience into your continuous delivery pipelines. InSpec makes it easy to incorporate existing standards and your own security requirements into simple, cross-platform tests. InSpec reduces the risk of new features and releases making unsafe changes to your infrastructure and helps eliminate the time lost to external audits. This talk will provide an overview of working with InSpec and how you can build "Compliance as Code" into your pipelines. 

モノからコトへ。「作るシステム」から「使い続けるシステム」へ。昨今、顧客が求める価値に向かい、素早く継続的にサービスを提供しつづけるためには「リーンスタートアップ的な手法」や「DevOps」はかかせません。その一方で、クラウド技術の発展に希望を持ちつつも、従来型のアーキテクチャ設計は依然、事前の土台がためが必須です。「やりたいコト」と「用意しなければならないモノ」。この間に生じるズレや葛藤は、プロダクトオーナーの悩みの種となっています。

本セッションでは、私がこれまで支援してきた事例の中で、企画サイドや開発サイドがこの悩みに対しどのように動くべきだったのか、私なりのふりかえりを交えつつ、みなさんと考察を深めていきたいと思います。

 DevOpsのサイクルを作りたいと考える方は多いと思います。

しかし、いざ作ろうとしてもアジャイル・自動化・Infrastructure as Codeなどと取り組みたいことが多く、改善がなかなか進まない事があると思います。

また、世の中にあるツールの利用事例を真似をしようにも、利用している技術や環境のギャップから導入ができない事もあると思います。

このセッションでは、私達のチーム（Hadoopの運用チーム）で実際に行った事例を基に、何から始めると改善が進むのかを紹介します。