タイトルから分かる通り、ネタ枠ですよ！

一時期 devops がバズワードと化し、猫も杓子も devops、devops と言葉だけが先行していました。そういったことがなくなり、ほっと胸を撫で下ろしていると、

NoOps「devops は短サイクル開発なだけ！ SRE は devops の進化したもの！　NoOps は アーキテクチャ設計 に SRE と devops を内包したもの！」
devops やっているぞヒューマン「devops やっているって言うため、足りないときは空コミットしたりして、毎日 10 deploy してますが大変ですよね！」
devops わかってるぞヒューマン「私はビジネスを考えているので、devops なんていう dev と ops のことは開発だけでやってください！」

ということがここ最近よく起きるようになりました。というわけで、devops に対しての誤解を解くとともに、実際 devops をどういう風にしたのか、どういった成果、業績がでたのかを複数の事例でご紹介します。

タイトルから分かる通り、ネタ枠ですよ！

大事なことなので 2 回書きました。

アジャイルソフトウェア開発のスクラムで開発をする上で、スクラムチームとして、プロダクトオーナー・開発チーム・スクラムマスターのいずれかのロールを担当します。
今までいずれか一つのロールを経験してきていると思いますし、なかには複数のロールを経験されている方もおられるでしょう。
それぞれが経験したロールの視座から他のロールについて好ましい振る舞い、好ましくない振る舞いを直感的または論理的に理解しているのではないでしょうか。

同時期に、まったく異なるプロジェクトで、プロダクトオーナー・開発チーム・スクラムマスターのロールを経験と周囲からのフィードバックを得る機会に恵まれました。
そこから、それぞれのロールが他のロールに対する大きな勘違いがあることに気づきました。

このセッションでは、実例に基づき、プロダクトオーナー・開発チーム・スクラムマスターに対してのよくある勘違いについてご紹介します。
また、その勘違いを乗り越え、どの側面を改善することでより良い振る舞いができるかについてもお話します。

上長に「お前は技術もマネジメントもビジネスも何も分からないクズ」と言われ、本当に自分が「技術もマネジメントもビジネスも何も分からないクズ」なのかどうかを確認しようと思い立った。

確認する方法としてテスト駆動開発(TDD)でお馴染みの三角測量(その人にはたまたまそう見えたということが起こらないように2つ以上の値を使用してテストをする)で確認することに思い至り、ちょうどタイミングよく運転資金が枯渇し閉店を余儀なくされた馴染みの飲食店とパン屋があったので、そこに自己資金を運転資金として投入し、自分の技術と知識と能力を使って閉店を免れられるのかどうかを確認した結果を紹介する。

「『DevOps』を導入したい」、「『DevOps』を導入してカイゼンできた」
などさまざまな場所で「DevOps」という言葉を見たり、聞いたりするようになってきました。
しかし、それらの「DevOps」を注意深く観察すると、明確な定義なく言葉だけが独り歩きしている場合が非常に多い状況です。
「DevOpsとは様々な自動化を進めることである」「DevOpsとはDevとOpsが一緒に仕事することである」などは典型的な誤解に基いています。

本セッションでは、DevOpsとは何か？をあらためて原典から確認すると共に、
軽視されることが多い、組織文化について説明します。

このセッションでは、昔に構築した古いコアシステムを新規リニューアルするにあたり、ある人が自分の学んだAgile(Scrum, XP)、DevOps(ツールと組織文化)を実際の現場に適用したら何が起こったのか？についてのお話します。

e.g. 

• 商用環境でのインフラ構築経験がないのに、「障がいを想定した可用性・冗長性」を考慮したインフラの設計・構築を要求された。その時、私はどうしたか？
• プロダクトオーナーからの要求に対して、ステークホルダーが猛反対。その時、私はどうしたか？
• ステークホルダーがプロダクトオーナーをないがしろにして、要求の優先順位を変えてきた。その時、私はどうしたか？
• etc...

DevOpsの組織文化は特にMicorosoftが実践したProblem Solving Teamの結成に近い話になっています。また、「人生は近くで見ると悲劇だが、遠くから見ると喜劇である」とチャーリー・チャップリンがいったと言われていますが、近く（＝現場の私）から見ると悲劇ですが、遠く（＝観客）から見ると喜劇に見えるのではないかと思います。