Computer Weekly製品導入ガイド

DevOps採用を阻むビジネスと技術障壁の克服

DevOpsのメリットは十分に検証されている。だが、ソフトウェア開発とデリバリにこのアプローチを採用するに当たり、企業はどのような手順を踏むべきなのか。

　2015年の主要なITカンファレンスで、DevOpsの話題が多くのセッションを独占した。サプライヤーやアナリストは、企業がソフトウェア開発にアジャイルのアプローチを採用しなかった場合のビジネスリスクについて、盛んに警鐘を鳴らした。

　競争力を維持したい企業はもはや、開発部門とIT運用部門が切り離された、大規模で時間がかかるソフトウェア開発やテストサイクルにしがみついている余裕はないと、よくいわれる。そこで、開発側と運用側が小規模チームを組んで連携する協調的な方法でソフトウェアを開発してテストや更新リリースを行い、自動化ツールやモニタツールを使って新製品投入のペースをこれまで以上に速める必要があるという。

　だが、古いソフトウェア開発手法にとらわれた企業にとって、CIOがIT部門全体の支持を得ることなくDevOps方式の働き方を導入するのは容易ではない。

　「DevOpsは一見すると素晴らしく単純に思えるが、『開発』と『運用』の世界には、多様な職務が隠れている。しかも、そうした陣営のチーム間ではこれまで相互の交流がほとんどなかった」。IT研修企業Unicom Seminarsのゴータム・ミトラ氏はそう解説する。

　「適切なツールやプロセスを導入するのは比較的簡単だ。しかし文化は無視できない。この2つの陣営を連携させ、協調させるためには大きな変化が必要になる」（同氏）

DevOpsの導入

　Ordnance Surveyは紙の地図製作で有名だが、地図製作者や測量技師、政府機関、公益企業、建設会社で構成する社内チームのためのソフトウェア開発も手掛ける。

　Ordnance Surveyのアジャイルデリバリ管理者、キース・ワトソン氏は、社内の幅広いチーム間コミュニケーションやコラボレーション向上を後押しする一環として、DevOpsの道をたどってきた。

　かつてOrdnance Surveyにはソフトウェアインフラチームの他に、必要な環境を構築するためのチームがあった。

　「われわれが提供するサービスには、デベロッパーの要望に追い付けていないという点で、顧客に一定の不満があった。つまり開発環境の提供に時間がかかっていた。しかも開発は、半自動化されたスクリプトを使って手作業で行っていた。そのため個々の環境の提供に時間がかかっただけでなく、常に同じものになるとは限らなかった」。ワトソン氏はそう振り返る。

　提供した環境は必ずしも要求を満たしていなかったことから、ソフトウェア開発チームとインフラ構築チームの間の不和につながることもあった。

　この状況を是正するため、ワトソン氏は開発者とインフラアーキテクトの少人数グループをつくり、両グループ間でリクエストのやりとりに使っていたチケットシステムを廃止した。

　「チームができると、全員が互いの隣に座ることの効用が直ちに表れた。ニーズを理解するだけでなく、開発チームも環境チームも実在の人間だったと気付き、互いにうまくやっていけるようになった」とワトソン氏は説明する。

テクノロジーの変化

　DevOpsを取り入れるために、会社のITインフラの刷新が必要になることもある。多くの企業は、重要な一歩としてクラウドへの移行を推進している。

この記事の著者

関連記事

• 

  コード分析で分かった「商用ソフトはOSSよりセキュリティが強固」な理由とは？

• 

  10機種のスマートウォッチ全てに脆弱性が存在、「利用するのは待つべき」

新着ホワイトペーパー PR

• 製品資料
  [o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説　総物流費を抑制するサプライチェーン戦略
• 製品資料
  [o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド：効果的な意思決定を実現する秘訣とは？
• 製品資料
  [株式会社リンプレス] 非デジタル／IT人材を「自走するDX推進者」に変えるための育成ロードマップ
• 市場調査・トレンド
  [ワンアイルコンサルティング株式会社] AI時代の組織設計：「判断と責任」を人に残すための2つの原則とは？
• 技術文書・技術解説
  [ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む？　「変えない判断」から脱却する方法とは