最近、取材先から「DevOps（デブオプス）」の話題を聞くケースが増えてきた。DevOpsに厳密な定義はないが、一般的には「開発チームと運用チームが一丸となり、ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける取り組み」といった意味だろう。

　このうち「ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける」という部分に着目すると、現在のDevOpsには、大事なピースが二つ欠けているように思う。

一丸となるべきは開発と運用だけではない

　その一つは「利用部門」である。

　ビジネス上の効果を高めるシステム改善を行う上では、利用部門が起点になる。利用部門が既存システムの改善要望を出し、それを開発チームと運用チームが一丸となったITチームが受け付け、実現していく。その際、改善要望を単に受け付ければいいわけではない。詳しくは後述するが、利用部門に要望の目的を確認したり優先順位付けをしたりする手間の大きなプロセスが必要になる。

　そのため、一丸となるべきは、開発チームと運用チームだけでない。利用部門の協力的な姿勢が欠かせない。開発チーム、運用チーム、利用部門の3者が一丸となることで初めて、「ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける取り組み」が可能になる。

　とはいえ、開発チームと運用チーム（以降では二つのチームを合わせてITチームと呼ぶ）は、利用部門と対立しやすい立場にある。人的リソースや全社のIT予算枠などの制約で、利用部門の要望をすべては受け入れられないからだ。要望を却下するほど、ITチームと利用部門の溝は深まる。

　3者が一丸となる工夫の好例として、大成建設の事例を紹介したい。

　同社は、システム部門である情報企画部のなかに「コンサルティングチーム」を、利用部門には主要システムごとに「サービスオーナー」という担当者を置いている。どちらも窓口担当となって、情報企画部と各利用部門の橋渡しをする、という役回りだ。

　とはいえ両者に利害対立があると、サービスオーナーの協力を得られないため、コンサルティングチームは要望を実施するかどうかを決める審査機構から切り離している。その上で、全社最適の視点を持ちつつも、各利用部門の側に立って助言し要望の実現を図ることによって、協力関係を築いている。