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

• 製品資料
  [株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる
• 製品資料
  [株式会社キーエンス] なぜRPA導入は頓挫する？　シナリオ作成の壁を乗り越える解決策とは
• 製品資料
  [株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？　PLMとの融合で実現する高速開発
• 事例
  [日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？　「新たな働き手」を支える3要素とは
• 製品資料
  [日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣