DevOpsが浸透しない「本当の理由」：特集：DevOpsで変わる情シスの未来（9）（3/3 ページ）

» 2015年03月25日 18時00分公開

[編集部／＠IT]

本番環境で、期待通りの成果を収めるために

編集部　ではそうした“品質”を担保するために、開発側は具体的には何に留意するべきなのでしょうか？

藤井氏　運用後の不具合が大きなビジネスリスクになり得る以上、開発段階でも“良いモノ”と“キチンと動く”の二つをどう実現するかを考える必要があります。その一つの手段としてアジャイル開発があるわけですが、その中でもあらためて探索的テストに注目しています。

　アジャイルの世界では「探索的テスト」を行います。「決まった要件を基にテストケースを作り、それを全部消化したから品質が良い」とするだけではなく、実際にユーザーが使う際のユーザビリティやユーザーエクスペリエンスを担保するために、テスト項目として明確に設定しにくい点について、有識者が実際にシステムを触ってテストを行います。その上で、「こうした方がよい」「ここはおかしい」といった点を発見する。

　これは手動で行うことになるため、テストをする手順が特に決まっていない例が一般的です。そのため、好ましくない挙動が生じても、「何を、どう操作したら、どのような挙動が生じたのか」が分からなくなりがちという問題があります。そこで操作のログ収集機能を持つ探索的テストの支援ツールなどが必要になってきます。

　実際のユーザビリティを担保するという点で、サービス仮想化ツールとネットワーク仮想化ツールも重要なポイントになります。前者は、並行開発で連携先モジュールが未完成の状態でも、その振る舞いをシミュレーションすることによって、他のチームの開発進捗に左右されず本番環境同様のテストを随時可能とするツールです。

　後者は、本番環境同様のネットワークインフラをシミュレーションするツール。Web上でサービスを提供するシステムの品質管理は、日本の恵まれたネットワークインフラでのパフォーマンステストだけでは十分とは言えません。モバイルを使ったり、海外でサービスを提供したりするとなれば、そのネットワーク環境に即したテスト環境が必要になるわけです。

　つまり「品質」とは、単に「バグを減らす」ことだけではなく、各種テストがどのような環境で行われたのか、“本番環境でのユーザビリティを担保できるリアリティあるテスト”があって初めて、担保できるといえます。

　というのも、DevOpsという短期で開発／サービスインする仕組みの中では、ビジネス目的に応じた期待通りの成果を着実に収めていかなければなりません。しかしスピードが上がると、属人的な“なあなあ”で乗り切れる余地はどんどん少なくなってくる。従って、探索的テストのような、より良い品質を模索する「エンドユーザー視点での品質向上の仕組み」や、サービス仮想化／ネットワーク仮想化のような、「品質管理作業そのものの質を高める手段」の両方が重要な意味を持つようになります。その上でリリース後、本当に成果が出ているかを監視し、PDCAサイクルを速いスピードで回していく。

　このように、DevOpsとは単なる「自動化ツール」や「協力する文化」といった話ではなく、「顧客ニーズにスピーディに応えるためのITバリューチェーンを構成する、一つのストリーム」なのです。繰り返しになりますが、PDCAサイクルを速く回す手段として自動化があり、ロイヤルティ／収益を確実に向上させるためにテストがあり、こうした改善サイクルを滞りなく回すためにルールの見直しや人のロールモデルの変化がある。これを自社で行うとすればどうすべきなのか？――スローガンから一段掘り下げた議論が不可欠です。

ベンダーやメディアの言葉をうのみにするな

編集部　なるほど。ただ現実には、DevOpsというと「自動化ツール」「文化」といった捉え方が非常に強いですよね。例えば「DevOps」でグーグル検索すると、ChefやPuppetといったツールの話ばかりが表示されます。こうした点、DevOpsに偏ったイメージを抱かせてしまう一因となってきたのかもしれませんね。

「そのツールはそもそも何のために必要なのか？そもそも自分たちは何をしようとしているのか？一つ一つを疑うことが問題の本質に目を向けさせるはずです」

藤井氏　Webやメディアに出ている情報が人々の印象を左右するとすれば、そうかもしれませんね。「開発部門がChefを使って運用自動化するなら、運用部門のロールはどう変わる」とか、ビジネス部門の視点で「短期リリースの成果を出すために、何をどのように測ればDevOpsの効果と言えるのか」など、ツール以外の話もバランスよく議論されることが期待されます。

編集部　ではあらためて、現場のプレーヤーたちがDevOpsを正しく理解し、有効にビジネスを推進していくためにはどうすればよいのか、アドバイスをいただけますか？

藤井氏　そうですね。「ビジネスに目を向ける」も答えではありますが、これはマネジャー層など、組織におけるポジションがある程度高くなければ、あまり現実的とは言えません。従って逆説的にいえば、ツールベンダーの言うことをうのみにしないことでしょうね。

　「ツールができること」は興味深いことではありますが、大事なのはその裏にある設計思想です。多くのツールベンダーは「何が問題なのか」「どういうアプローチで解決するか」という議論をそれなりに経て個々のツールの機能を定義しています。

　言い換えると皆さん自身の会社で「何が問題なのか」「自社にとって何が本当に必要か」といった視点がないと適切な選択ができなくなります。「ビジネス貢献！」のような大ざっぱなセールストークは疑いの目で受け止め、「何の役に立つのか」「誰の役に立つのか」「そもそも何に困っていたのか」といったように一歩引いてツールを見るスタンスがあれば、表面的な機能の違いなどではなく、「もともとの狙い、目的」におのずと目が向くようになる。仮に採用しようと考えて稟議を上げるにしても、周囲を説得できるロジックを用意できるようになると思うんです。

　無論、これはDevOpsに限った話ではありません。しかしDevOpsがスローガンに終わってきた理由も、このように一段、ブレークダウンして見るスタンスの不足にあるといえるのではないでしょうか。

◇

　先駆者利益獲得や差別化のためには、スピーディなビジネス展開が不可欠――そうした認識が着実に浸透している今、国内でもようやくDevOpsに関する具体的な議論が広がろうとしている。自社のビジネス目的は何か、差別化のためにはどうすべきなのか、それに対してIT部門は何をすべきなのか、あらためて問い直してみてはいかがだろう。自社のITバリューチェーンの全体像とそれにおけるDevOpsの位置付け、なすべきことを明確化することで、スローガンではないDevOpsの形が見えてくるのではないだろうか。