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

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

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

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

 巷で噂のDevOps。

ところが、

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

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

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

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

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

「DevOps を導入したい」
「技術的負債と向き合わないといけない」
そう感じているエンジニアは多くいると思います．

しかし，急成長するスタートアップにおいて，新規機能の開発を優先することが多いのではないでしょうか？
また，経営層がエンジニアリングの価値を深く把握できていない場合，
「DevOps を導入するメリット」や「技術的負債と向き合わないといけない理由」が伝わりにくいのではないでしょうか？

本トークでは，組織に対して課題を感じた私が，
経営層を巻き込むことで開発組織を変革した，実体験に基づく実践的なアクションを紹介します．

• なぜ開発組織を変革するために「経営層を巻き込むこと」が重要なのか？
• どのようにして「技術的負債」を経営層に理解してもらうのか？
• どのようにして「信頼残高」を増やすのか？

そして DevOps の導入を最重要課題と位置付け，組織に広めるために実施したアクションとその成果を紹介します．

• どのようにして DevOps を組織に広めるのか？
• なぜウェブオペレーションの自動化が重要なのか？
• なぜ数値の可視化と効果計測が重要なのか？

DevOps のこと，技術的負債のこと，組織変革のことを一緒に考えませんか？

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

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

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

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