Jaap Schuttevaer氏は，Agile Testing Day Netherlands 2015カンファレンスで，DevOpsに関するワークショップを行った。参加者にDev&OpsとDevOpsのアプローチを経験してもらうことが，ワークショップの目標だ。彼らはこれらのアプローチをどのように感じたのだろう，DevOpsの効果，長所と短所は何なのだろうか。
参加者はグループに分けられ，ボールをひとつのエリアから別のエリアに移動させるという課題が与えられた。 エリアの間には２メートルの距離がある。ユーザは２つのエリアに分かれるが，ボールを持って歩いたり，投げ渡すことは許されない。そのためのツール，つまり，ボールを移動させるためのソリューションが必要だ。
最初のラウンドでSchuttevear氏は，チームとユーザに対して，DevとOpsの分離アプローチを用いた方法を説明した。ユーザとOpsメンバは別の部屋に移動し，Devメンバ(開発者，アナリスト，テスタ)が部屋に残る。チームにはそれぞれ，２つの部屋を自由に行き来できるデリバリマネージャがいる。
開発メンバには材料の入った箱と，ボールを移動させるツールを作るためのユーザストーリが与えられた。
ユーザである私は，エンドゾーンにボールを停止させるデバイスを必要としている。
それがあれば，停止ゾーンに毎分，より多くのボールを運ぶことができる。
目標は，私たちのチームが勝利することだ。
そのころ別の部屋では，ユーザが，自分たちの望むソリューションについて話をしていた。例えば何人かは，デリバリエリア内に留まるようにボールを投げられるか試していた。
デリバリマネージャは，開発メンバとユーザと運用担当の部屋を行き来して，開発中のソリューションをチェックした。最初のソリューションを見たとき，彼らはオペレーションマニュアルを要求した。運用メンバがソリューションをインストールするために必要だったからだ。その後で，ソリューションにはユーザインターフェースを設けないことという，新たな要件が追加された。ユーザと運用のニーズを開発者に伝えるためと，開発者が提供するソリューションを確認するために，各グループのデリバリマネージャは頻繁に歩き回ることになった。
ある開発チームは，目的のエリアに投げ込まれたボールを止めるものを作った。 別のチームは，ボールをガイドする縁の付いたトラックを作り上げた。そこで生じたのは，これらのソリューションのデプロイの難しさ，という問題だ。これが分かったのは，運用メンバがマニュアルに従ってソリューションをインストールしようとした時だった。ユーザは準備が出来上がるのを待たなくてはならなかったが，一方で開発メンバは，それが動作するのかどうか，フィードバックを待たなくてはならなかった。
第２ラウンドでは，DevOpsアプローチが取られた。今度はアナリスト，開発者，テスタ，デリバリマネージャ，運用担当者がすべて同じ部屋に入った。各チームはすぐさまオペレーション室に移動することを決め，そこで議論し，さまざまなソリューションを試した。開発者とテスタが共同でソリューションを構築し，ユーザがそれを試し，DevOpsチームに直接フィードバックを提供した。
今回は開発者と運用担当者がDevOpsアプローチで共同作業していたので，ソリューションのインストール方法は明確になった。開発者がインストールを手伝えるので，マニュアルはもはや必要ではない。
どのチームも，DevOpsアプローチで開発された第２ラウンドのソリューションの方が優秀で，テスト時にはより多くのボールを移動することができた。
完了ミーティングではSchuttevaer氏から参加者に対して，Dev&OpsとDevOpsアプローチについてどのように思ったか，という質問があった。それに対して，DevOpsアプローチではデリバリマネージャのすることはほとんど何もない，あるいはDevOpsでは全員が同じ部屋にいたので，お互いに話し合って助け合うという，よりよい共同関係を持つことができた，などの結論が出された。DevOpsアプローチでは運用面で何が行われるかを開発者が知っているので，より優れたソリューションを開発することができる。 ある参加者はDevOpsについて，作業を管理する上でまったく異なる方法であり，成果もまったく違う，という意味のことを述べた。
DevOpsがDevとOpsの間の壁を壊すことによって組織にもたらすものは何なのか，InfoQはSchuttevaer氏にインタビューするとともに，DevOpsを導入しようとする組織へのアドバイスを聞いた。
InfoQ: DevOpsとは何か，組織に何をもたらしてくれるのか，考えを聞かせて頂けますか？
Schuttevaer: DevOpsは，Development(開発)とOperations(運用)を統合するゲームの名称です。スクラムやXPなどによってアジャイルを導入しようとする組織は，製品開発の開発側に注目します。この段階で取り組まなくてはならない大きな課題のひとつは，アナリストやプログラマ，テスタといった仕事のタイトルで形成された，専門知識のサイロ間にある壁を壊して，皆が一緒に作業するようになることです。
スクラムを動作させるための最初の努力が終われば，開発チームには，迅速なフィードバックサイクルが手に入ります。後はこれを押し進めればよいのです。たいていの開発チームは，スプリント毎に新たな機能を製品に追加しようとします。彼らが思い浮かべるのは，継続的デリバリを行うような考え方なのです。
それによって，乗り越えなければならない厄介な壁が，組織の中に存在することが明らかになります。新たに開発されたバージョンの製品を実務に移行するためには，このような壁が大きな障害になります。これらの壁はすべて，開発部門，運用担当，保守部門の間にある隔たりによって発生するのです。
InfoQ: これまで見てきたDevとOps間の壁には，どのようなものがありましたか？
Schuttevaer: 克服すべき壁には，いくつかのタイプがあります。最初のひとつは組織的なもので，他の多くの壁の根本原因にもなっています。規模の大きな組織では，IT組織を“製品の変更(Dev)”と“製品の保守(Ops)”の２部門に区別しているところが多くあります。このような決定方法には，たくさんの問題があります。それぞれの部門にはマネージャとスタッフがいて，独自の考え方，責務，パフォーマンス目標を持っています。開発者が新機能の開発に注力するでしょうし，運用部門にとっては安定性の維持が重要なのです。
多くの場合は，物理的にも分かれています。開発と運用が違うフロアに配置されていたり，別のビルにいることもあります。このような組織的な分離は同時に，結果として“私たちと彼ら”という態度を生み出します。この滑稽な開発システムでは，“開発終了”したものを壁越しに，運用部門に投げつけようとします。一方の運用部門では，山のような“製品受入基準”にチェックリストを添付して，自分の身を守りにかかります。つまりこれが，“コラボレーション契約”です。
InfoQ: 壁を壊すためには，何をすればよいのでしょう？
Schuttevaer: このような壁が作られた大きな原因は，開発と運用が組織上，別々のグループに分離されたことにあります。これを壊して，DevとOpsの密接で透過的な連携を実現するためには，組織が変わらなくてはなりません。階層を(直接)変更する必要はなく，機能的な変更から始めてもよいのです。ですからまずは，DevチームにOpsメンバが参加するところからDevOpsを始めてください。
簡単そうに聞こえるかも知れませんが，大変な問題を伴う場合もあります。ひとつのチームルームに人を集めれば，物理的な分離の問題は解消します。コミュニケーションも改善されるでしょう。ですがまだ，克服の必要な根本的な問題が残っています。開発者は，運用担当者たちのタスクやツール，責任といったものをあまり理解していませんし，経験したこともほとんどありません。その逆も同様です。相互理解と連携は，ただでは手に入りません。刺激し，成長させなければならないのです。“新しい”Opsチームメンバたちも，Devチームのメンバたちのようなスクラムの経験は学んだことがありません。それにもうひとつ，ほとんどの人たちが変化を直接的には支持しない，という点も注意が必要です。
InfoQ: DevOpsを採用しようとしている組織に，何かアドバイスをお願いします。
Schuttevaer: DevOpsを取り入れたいのでしたら，提供できるアドバイスがたくさんあります。 物理的距離の低減，変化には不安と時間が付きものなことを考慮する，Opsの人たちはDevの人たちが学んできているようなアジャイルの考え方を経験していない点に注意すること，など，私がこれまで話したことは，ほとんど用いることができると思います。
継続的デリバリを実施しようとしている組織やスクラムチームには，第1のアジャイルの価値である，“プロセスやツールよりも個人と対話を”，を心に留めておいてほしいと思います。ですから，継続的デリバリの高度なプロセスやツールにいきなり飛び込まずに，DevとOpsが緊密に協力するところから始めてください。そして常に，最終目標を忘れないことです。DevOpsはスプリント毎のスループットを向上し，フィードバックを高速化し，より高品質の製品を生み出してくれるでしょう。