「Development」（開発）と「Operations」（運用）を合体させた「DevOps」という言葉が、日本においても2年前くらいから注目されている。米国では、約4年前に誕生し、その後注目を集めるようになっていたので、米国から1、2年遅れで、日本に上陸してきた格好だ。
DevOpsは、クラウドやSNSといった、コンシューマ系の変化が速い分野で生まれてきた言葉だ。システム開発に半年、1年かけている間に、ビジネスの状況が変わってしまっては意味がない。そこで、ビジネスやニーズの変化に耐えうるスピード感で開発しリリースできるITサービス・デリバリの新しいアプローチが必要になった。それが、DevOpsである（図）。
今までの延長線上にはない新しいアプローチ
日本では、運用と開発が密に連携することをDevOpsと呼ぶケースが多い。これは、間違いではないが、誤解を招く。今までのやり方のまま、運用と開発が密に連携しても、それは「DevOps」とは呼ばない。
DevOpsは、今までの「延長線上」にあるものではない。これまでとは一線を画すスピード感を実現するためのサービス・デリバリの新たなアプローチとして、組織、文化、習慣も含めて、改めて作り上げていくべきものと捉えるべきだ。
SIer（システムインテグレータ）からは、「要するにアジャイル開発のことですよね」と言われることもある。また、運用担当者は、リリース自動化を思い浮かべることが多いようだ。これらも間違いではないが、サービス・デリバリのアプローチとしては、アジャイル開発だけでも不十分だし、リリースの自動化だけでも不十分。これらを包含した形で、サービス・デリバリのやり方や文化、組織や体制をも見直していこうというのが、DevOpsの本質である。
小さな単位で、変更、リリースを繰り返す
DevOpsでは、小さな単位で変更・リリースのスパイラルを繰り返す。最初の完成度や品質がたとえ60％程度であったとしても、スピード重視で素早くリリースする。そして改善や最適化を繰り返すことを前提にしている。結果、週末や年末にまとめてリリースするのではなく、毎日毎日、何十回もリリースすることを可能にする。
これを実現するためには、承認プロセスも変えなければならないだろう。具体的には、テストを実施して、ポリシーを満たしていれば承認なしで自動リリースする。保守的な人は、「失敗したらどうするの？」と考えるかもしれないが、小さな単位でリリースすることで、影響度を少なくし、駄目ならすぐに元に戻す、といったことを前提にする。