「はやってるからやってみよう」←アウト

DevOpsを推進するCIOがハマる5つのワナ

DevOpsという手法が登場して久しいが、安易な考えで手を出すと必ず失敗する。CIOが陥りがちな5つの落とし穴を紹介する。

公開 2015年01月20日 08時00分

更新 2020年01月24日 15時18分

著者

Archana Venkatraman

[Computer Weekly]

印刷する Googleで優先するソースとして追加

　エンタープライズ分野でDevOps移行のペースが勢いを増している。だが、DevOps戦略を自社に取り入れようと考えているCIOには、避けなければならない5つの落とし穴がある。

　DevOpsとは、アプリ開発チームとシステム運用チームの作業を統合するというITの実践手法だ。開発チームと運用チームは自動化によって緊密に連携できるため、ビジネスの変化にいち早く対応できる。

　これまでのITプロセスでは、アプリ開発チームがビジネス目標を確認し、コードやソフトウェアを作成してきた。作成したプログラムはテストチームに渡され、開発チームとは切り離された状態でテストが行われる。テストに成功したプログラムやソフトウェアは、ユーザーにリリースするために開発チームから運用チームに送られる。

　だが、このような縦割り型の作業では別のチームの制限事項や問題点が分からず、結果として不満が生まれ、作業効率が低下する。さらに重大なことに、IT部門にも業務部門にも悪影響が生じる。

　DevOpsアプローチにより、チームが違っても共同作業が可能になる。効率を上げる小さなアップデートを頻繁に行える。エラーが少なくなり、ITの質が向上する。また、DevOpsを実践すれば、ソフトウェアエンジニア同士や、IT部門と他部門との間に生まれるギャップやコミュニケーション不足が少なくなる。

　しかし、DevOpsを進める過程では企業文化も変える必要があるため、手間が掛かる可能性もある。この過程でCIOが陥ってはならない落とし穴が5つある。

1．DevOpsを単なる自動化推進運動と捉えてしまう

　DevOpsでは、開発プロジェクトをテスト環境から本番環境に移す際にも、運用上の問題に対処する過程でも、可能な限り自動化することが重要になる。

　企業のソフトウェアシステム構築と運用を支援する英Skelton Thatcherの共同創設者兼主席コンサルタントのマシュー・スケルトン氏は、「DevOpsの目的はそれだけではない」と話す。マネージドクラウドプロバイダーである米Rackspaceが主催したDevOpsに関するパネルディスカッションで、スケルトン氏はComputer Weeklyに次のように話した。「DevOps戦略を策定する中で自動化担当の特別チームを編成することを考えているならば、肝心な点を見落としている」

　DevOpsでは、もちろん開発チームと運用チームとコード要素の受け渡しを自動化する必要がある。効率を上げるにはロールバックやフィードバックのプロセスの自動化も求められる。「自動化ばかりに力を注いでも、ITの効率化につながるのはごくわずかだ」と同氏は語る。

　サービスとしての運用を手掛けるDevOpsGuysの共同創設者ステファン・ザイール氏は、次のように付け加える。「DevOpsで考慮するのはITに関係することだけではない。自動化だけに注目しても、高速化されるのはソフトウェアのみだ。ボトルネックは解消されず、それが生じる場所が変わるだけだ」

　パネルディスカッションにも登壇したザイール氏は、DevOps戦略の計画時にはCulture（文化）、Automation（自動化）、Lean（無駄の削減）、Measurement（測定）、Sharing（共有）を重視するCalmモデルを考慮するようCIOにアドバイスした。

　DevOpsのIT面だけに取り組むチームを新たに編成すると、社内に新たなギャップが生まれると同氏は警告する。