ホワイトペーパーレビュー

DevOpsのツボが分かる3つのホワイトペーパー

クラウド、ビッグデータに次ぐキーワードとなった「DevOps」。その実現の鍵となるアジャイル開発のポイントとともに、DevOps実践の要点を整理する。

公開 2013年08月30日 08時50分

更新 2013年08月30日 13時59分

著者

内野宏信

[TechTargetジャパン]

印刷する

　Dev（開発担当者）とOps（運用担当者）が連携してサービスのリリースサイクルを速める概念「DevOps」が注目されている。市場が激しく移り変わる現在、企業は各種ITサービスを短期間でリリースし、ニーズをくみ取りながら、迅速にサービスを改善していくことが生き残りのカギになる。DevOpsはその一手段として関心を集めているわけだが、その実現にはアジャイル開発の実践をはじめさまざまな課題がある。本稿ではDevOpsのポイントや、その鍵となるアジャイル開発導入の要点がつかめる3つのホワイトペーパーを紹介する。

DevOpsの全容と実践のポイントを分かりやすく整理

IT部門の開発チームと運用チームが断絶してしまう7つの理由

提供：日本ヒューレット・パッカード（8ページ）

　市場変化に応じてビジネスをスピーディに展開する上で、DevOpsが重要なことは認識していても、すぐに実践に移すことはなかなか難しい。その最大のハードルとなるのが、スピードとコスト低減が求められる開発部門と、開発成果物の安定運用が求められる運用部門という、ミッションが異なるが故に存在する文化の壁だ。

　だが従来のように、「両チームがまったく別の基準で評価される限り、両者の行動は協力よりもむしろ競争に」向かってしまう。そこで両チームが協力し合い、密に連携するためには、まず「評価基準を合わせることによって摩擦を減らし、同じ方向性に目を向ける仕組み」が求められる。具体的には「全体的な視点で捉える業績評価尺度を、部門間で統一することを検討する」「可能な限り、ダッシュボードを使ってIT部門全体で単一ビューを作成することで、ITマネージャはビジネスレベルでKPI を設定。両チームを同じレベルに配置して世界観を共有する」などがある。

　さらに、「アジャイル開発のスプリントの最後に実施されるデモに運用担当者を加え、互いのプロセスや弱点について学び合う」など、本ホワイトペーパーはDevOps実践の課題を順を追って解説し、その解決方法を非常に具体的に説いている。すっかり業界のキーワードとなったDevOpsだが、その全容とポイントを整理する上で大いに役立つのではないだろうか。

アプリケーションの品質問題をどう回避するか

アジャイル開発を阻むもの

提供：日本コンピュウェア（12ページ）

　開発部門と運用部門の連携を阻む問題のうち、アプリケーションの品質は特に大きな問題となる。具体的には、両部門で使っているツールが異なっていたり、開発・テスト環境と本番環境の差が大きかったりするために、運用部門は本番環境でも正しく動作することを確認する上で、同じ検証作業を何度も繰り返すことになりやすい。これがリリースの遅延とコスト増大を招く原因となっている。

　特に、運用部門による動作確認のフェーズで新たなバグが発生した場合、トラブルシューティングのために開発部門と運用部門の間で、真の問題はどこにあるのか、「責任の押しつけ合いが始まる」ことになりやすい。本ホワイトペーパーはこうした問題にフォーカスし、解決策としてApplication Performance Management（以下、APM）を使うことを提案している。

　APMはアプリケーションの性能問題をエンドユーザー視点で分析し、アプリケーションやその稼働を支えているシステム構成要素のどこに問題原因があるのか、迅速に特定できるツール。この監視・分析結果を開発部門と運用部門の「共通言語」にするとともに、開発、テスト、本番の各フェーズで用いることで、両部門が連携してその品質を担保する仕組みを作れるとしている。両部門のツール、環境の差異に起因するアプリケーションの品質問題について、複数のベンダーが解決策を提示している中でも、本ホワイトペーパーが提案する方法は非常にシンプルだといえる。その分、課題解決の要点もつかみやすいはずだ。

大規模開発でもアジャイル開発を取り入れるには？

ディシプリンド・アジャイル・デリバリー入門編

提供：日本IBM（20ページ）

　DevOps実践の鍵となるアジャイル開発は、以前から企業の注目を集めていながら、国内では「浸透している」とはいえない。アジャイル開発ではプロジェクトの早い段階から開発成果物をエンドユーザーと共にレビューし、要求品質を検証するプロセスがある。これを短期間で繰り返すことで、手戻りなくスピーディかつ着実に開発を進める点がポイントであるわけだが、この点が「小規模開発には向いているが、多数のステークホルダーが存在し、開発環境も分断されているような大規模開発には向かない」といった見方も生み出している。

　だがアジャイル開発の浸透を阻んでいるのはそれだけではない。開発関係者間のコミュニケーション、コラボレーションが軸となるアジャイル開発を、具体的にはどうすれば自社組織に適用できるのか、具体的な情報が十分とはいえないことも問題として挙げられる。

　本ホワイトペーパーはその点にフォーカス。IBMが提唱している、大規模開発の場合も含めて、さまざまな組織が無理なくアジャイル開発を実現できるプロセス「Disciplined Agile Delivery」（以下、DAD）を紹介している。従来のアジャイル開発手法が「ソフトウェアの構築」に焦点を当てていたのに対し、DADはプロジェクトサイクルを見据え、アジャイル開発を円滑に実践するためのマネジメントをサポートするガイダンスとなっている点が特徴だ。今回紹介したDevOps実践のポイントと併せて、アジャイル開発の具体的な適用方法を見直してみることで、自社におけるDevOps実現の可能性が見えてくるのではないだろうか。