ビジネス加速に不可欠、あらためて考えるDevOpsツール（5/5 ページ）

公開 2018年09月26日 09時30分

更新 2022年10月03日 11時34分

著者

土肥正弘

[ドキュメント工房]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

成熟度モデルをベースに段階的な導入を

　上掲のように、非常に多種のツールが利用可能になっているが、企業の開発と運用体制に関わるだけに、全てを一気に導入するのはどんな企業でも不可能に近いと思われる。現状の課題解決に効く部分、あるいは着手しやすく効果が手にしやすい部分からの導入を考えるとよいだろう。始めは小さく、徐々に対象領域を拡張していけばいい。そのロードマップ策定の参考になるのが、ベンダーが提案している「成熟度モデル」だ（図6）。

図6 DevOpsの成熟度モデルの例（提供：日本IBM）

　当初は「経験あり」か「反復できる」レベルにあるだろうが、やがて「信頼できる」「拡張可能」なレベルにまで成熟させることを目標に、ツール導入や体制整備を図るとよい。大抵は「開発・テスト」のレベルアップがスタート地点になると思われる。

　例えば、各モジュールの完成を待たずに結合時のシステムの動作を模倣する「サービス仮想化」ツールをテスト工程で適用した事例では、テスト工程でのコスト削減効果が65％～85％、テスト環境の更新ダウンタイムが10時間から1時間に、開発環境のセットアップ時間が42日から3日に短縮できたケース（米国の銀行）もある。

　このように確実に効果が現れる部分からの着手が望ましい。そのフェーズの整備に伴い、デプロイや運用の課題も明確になってくるだろう。将来的にはビジネスプランニングのフェーズにフィードバックできる体制づくりが望ましい。

既存開発関連ツールの整理、標準化を念頭に一貫したソリューションを利用

　これまでのDevOpsツール導入事例で問題になることの1つは、それぞれのフェーズでプロジェクトごとに多様なツールが適用されることが多く、開発やテストの各フェーズで残すべきドキュメントが標準化されていなかったり、各フェーズの成果物間の関係を管理していないためトレーサビリティが保証されずテストで問題が発見されても修正に時間がかかったり、品質上の弊害が生じたりすることが挙げられている。

　つまり、部分最適化はできても、全体最適化に至らず、プロジェクトや企業としての効率が上がらない状況が見られるというわけだ。ツールのバリエーションが増えると個別作業は効率化しても、プロセス間連携の自動化が難しくなり、メンテナンスや技術修得の負荷も高まることになる（図7）。

図7 個別ツールによる部分最適化が招く管理の複雑性（出典：日本ヒューレット・パッカード）

　開発現場でのオープンソースツールの導入は進んでおり、機能も年々向上している。特定ベンダーが提供するツールに全て置き換えることは、ベンダーロックインを避ける意味でも、またツール導入に伴うさまざまなプロセスの移行やツール教育のコストを考えても現実的でない。

　そこで、商用でDevOpsプロセスをサポートするツールを提供しているベンダーは、自社製品と開発部門が既に利用している各種ツールとを連携させながら、首尾一貫したDevOpsプロセスを実現できるように製品ラインアップを図っており（図8）、それらを組み合わせたソリューションを利用することで、プロジェクト内部で蓄積したノウハウを継続利用しながら、プロジェクトに全体の可視性、生産性、品質の向上を提案している。プロジェクト単位でなく、会社全体の効率を考えたツール導入を考えたい。

図8 一貫したDevOpsソリューション（青い部分）と既存ツールの連携イメージ（出典：日本ヒューレット・パッカード）

開発・運用は外部委託…それでもDevOpsは有効？

　国内企業のITの特徴は開発や運用が外部のSIerなどに任されていて、企画部門以外は社内で担当していないケースが比較的多いことが挙げられる。またリリース回数が1日10本などという頻度とは遠く懸け離れている企業も多いだろう。

　それでもDevOpsが有効なのか、という疑問が湧くのも無理からぬところだ。しかし上述のようにDevOpsを「ビジネスの加速」を達成するものとして見る視点からは、リリース頻度で要不要を議論するのは適切でないようだ。

　アジャイル開発の必要性も感じないという企業は別だが、従来のボトルネックであるテストやデプロイ、運用の工数を短縮してサービスの早期提供、短期間での改善を図りたい企業では、たとえそれほどリリースが多くなくても、十分な導入効果を得ることが可能だろう。

　一方、ITの大部分をアウトソーシングしている場合には、個々のDevOpsプロセスを自社で構築してコントロールすることはなかなか難しい。しかしDevOpsのスコープの中には運用結果からのフィードバックを含むことに注意したい。

　仮に多くのプロセスがブラックボックス化しているとしても、システムの継続的モニタリングやユーザー視点からのモニタリングにより、プロダクトの客観的評価が可能であり、その結果を基にしたポートフォリオ管理なども、DevOpsツールの一部として提供されている。少なくともインプットとアウトプットをきちんと監視することで、改善ポイントは見えてくるだろう。

　またアウトソーサーとの情報共有やコラボレーションを強化することにより、より詳細な問題発見や改善ポイントが分かるようになるはずだ。理想的には社内のDevOpsチーム内に外部の専門家を取り込んで、一層の協力関係を作り上げることを目標にしたいが、自社のスキルアップや組織上および契約上の変革も必要になり、そう簡単なことではない。これについては国内外の他社の動きを注視して改善のヒントを探しながら、慎重に検討していく必要があろう。

コラム：DevOpsと「内部統制」は矛盾する？

　内部統制では開発と運用の分離が求められている。DevOpsはややもするとその原則をないがしろにするものと映るかもしれない。しかしDevOpsの実践では開発担当者と運用担当者の役割は整然と分離されており、両者は協調するにすぎず、一体化するわけではない。ツール機能によって開発と運用が一部一体化はするものの、そこでは人間の恣意（しい）的なコントロールを排除でき、しかも必ずログが残る。むしろ統制上は厳密になると考えられる。