開発と運用の間の垣根を取り払うことでITサービス提供のさらなるサイクル短縮を実現する「DevOps」は昨今国内でも注目されるようになりまし た。Dev（Development=開発）とOps（Operations＝IT運用）をつなげようと言うことでつけられた造語です．読み方は「デブ オップス」です．
HPでも去る1月30日~31日のJaSST '13 Tokyo （ソフトウェアテストシンポジウム）においてDevOpsの講演セッションを行い、多くの方にご聴講いただきました．そのお客様アンケートにおけるご感想でも、DevOpsは今後いずれは取り組むべき課題として認識していらっしゃる方が多数いらっしゃることがわかりました．
では，改めて，なぜDevOpsなのでしょうか？「ITサービス提供のさらなるサイクル短縮」を実現すると何がうれしいのでしょうか？
今，世の中に求められているものというのが非常に分かりづらくなっています．生活に必要なものは十分にそろっていています．十分なほど有り余る状態 で必要なものを探せば山のように情報が入手できます．例えば，今週，今まで行ったことのない小田急線沿線の駅で食事（仮に新百合ケ丘としておきましょう）をしようということになったとします． 今まで行った事がない場所なのでどこに行けばよいかわからないとしても，Googleで検索すればいくつものグルメサイトが見つかり，無数のお店を勧めて きます．このようなときにどうやってお店を選択するのでしょうか？ある時期，多くの人が口コミを見て選んでいたかもしれません．しかし口コミに差がない と，（どれもいいことが書いてある）口コミでは選ばなくなります．では，お店の情報の何を見て選ぶのでしょうか？駅から近い？ コスパがいい？ 和風/洋 風/関東風/京風？ クーポンが多い？ 決定的なものは何でしょうか？ 優先度が高いものは何でしょうか？
はっきりとした解は分かりません．しかし，情報を提供するグルメサイトは，何かしらチャレンジして多くのお客を自分のサイトからお店へ誘導しなけれ ばなりません．誘導できることが掲載されたお店に価値を提供したことになるからです．また，その誘導によって納得したお店が選べれば，サイトへアクセスし た食事をするお店を探していたお客に対しても価値を与えたことになります．
はっきりとした解がないときには、上記のようにいろいろ試して価値の提供を試みるしかありません．Webサイトのレイアウトを変えてみる．クーポンの 内容を変えてみる．といったようにいろいろなトライを繰り返すでしょう．こういったトライのなかで，世の中のニーズが見えてきます．そしてそこから見つけた価値をITシステムに搭載し，世の中の利益に転換するのです．これがITシステムの意義です．
しかし，こういったトライをしたいときにIT開発..デブが，「そのレイアウト変更には1ヶ月かかります」とか，「クーポンの仕掛けの変更は欠陥になる恐れがあるから控えてください」とか言い出したら如何でしょうか？
また，IT運用..オップスが，「しょっちゅう変更が入ると安定した運用が出来ません」とか，「変更して数多くの人のアクセスが想定されるのでサーバーを高機能なものに変更しないといけません，3ヶ月待ってください」とか言い出したら如何でしょうか？
これではトライが出来ずいつまでたっても良いWeｂサイトになって行きません．そうなってしまうとビジネスが成り立ちません．ビジネスが成り立たなければ，そもそも文句を言っていた開発者達が受け取るはずの報酬をどこからも調達できないのです．
ただ，しょっちゅう変更要求が入る開発や運用の現場が混乱した状態を継続し続けているのも事実です．これらを解決しようといろいろな試行錯誤がなさ れ，開発現場にはアジャイルというコンセプトが提唱され，運用ではクラウドが浸透しだしました．ITを利用する人たちのためにはスマホやタブレットという 手段が提供されるようになりました．
その流れを受けてDevOpsが提唱されだしました．
DevOpsは，開発と運用という二つの世界をつなぐパイプライン（搬送経路）を良くするためのコンセプトです．開発と運用の間には開発したアプリ ケーションを本番環境へリリースするという搬送過程がありますが，その搬送過程にはいろいろな課題があります．いろいろな課題の中でも組織的なサイロ，ま たサイロによるコミュニケーションギャップが最も大きな課題です．コミュニケーションの問題の核は「品質」です．開発 から運用に渡されるものが品質がよければ問題ないのです．問題は渡されたものを本番環境に入れることで動かなくなったり，不正な動きをしだしてしまったり といった障害が起きることです．それにより「開発者が品質の悪いものをよこしたせいだ」と運用者は思いますし，「運用者は文句ばっかり言って対応しない」 と開発者は思うでしょう．これがスピーディにトライを繰り返せなくなる障壁になるのです．
運用へリリースする際のパイプライン（搬送経路）の搬送役がテストです．コードを書くまえにテストを書き，コー ドを書いたらテスト，ビルドをしたらテスト，本番前にはユーザの使うように動かして問題ないことをテスト，性能をテスト，セキュリティをテストといった多 くのテストを繰り返して本番環境にアプリケーションを搬送していきます．本番環境に搭載する前にも受け入れテスト，議事本番環境でテスト，本番環境でテス トして本番運用に入ります．
この搬送をスムーズにすればトライをスピーディに繰り返せますし，，搬送後に問題が起きなくなれば，コミュニケーションギャップも緩和されます．こ れは，つまりテストを効率的かつ効果的にすることです．テストを効率よく行うために，テストケースの共有，自動テストスクリプトの共有，テスト結果のクロ スリファレンス，テスト時に見つかったバグ情報の共有．テスト環境の共有，といった共有が必要になります．また搬送経路を渡っていく過程を自動化するとさ らに効率よくなります．そうみるとテストの効率化がDevOpsの肝なのかもしれません．
上記の効率化するツール群としてHPのツールを活用してもらいたいと思い．3月19日に無料セミナーを開催することになりました．「HPALMセミナーHPのDevOps ビジョンと推進するための仕組み」 というタイトルのセミナーです．セミナーではDevOps，エンタープライズアジャイル，継続的テストの３つをテーマにしたセッションを用意していま す．HPの自動テストツールであるUFTの最新バージョンのご紹介も行います．お時間のある方はぜひ足を運んでもらえればと思います．