なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜（後編）：「DevOpsとは？」の決定版。今ハッキリさせる「正しいDevOps」実践法（1/4 ページ）
IoTやFinTechトレンドの本格化に伴い、DevOpsが今あらためて企業からの注目を集めている。だがDevOpsは、いまだ正しい理解が浸透しているとは言いがたい状況だ。そこで＠IT編集部では、国内のDevOpsの取り組みをリードしてきた五人のベンダーキーパーソンによる座談会を実施。今回は後編をお伝えする。
「DevOpsとは何か」というフェーズに終止符を
市場変化の加速、スピーディなサービス開発・改善により収益向上を狙うIoTトレンドの本格化などに伴い、2015年はあらためてDevOpsが見直される年となった。こうした中、欧米ではFinTechも追い風に、金融、製造、流通など幅広い業種でDevOpsの適用が進んでいる。だが多くの日本企業は、その重要性を認識してながら、正しい理解、実践には至っていないのが現状だ。
参考リンク：
そこで＠IT編集部では、日本のDevOpsトレンドをリードしてきたベンダー所属のキーパーソンによる座談会を実施。前編では「DevOpsの今」を俯瞰するとともに、「DevOpsで本当に大切なこと」、そして「何ができればDevOpsなのか」といったDevOpsの出発点を振り返った。
後編では「DevOpsには何から取り組むべきか」「何が実践のポイントになるのか」を掘り下げていく。
座談会メンバー（順不同）
- 渡辺隆氏 日本CA DevOps&Application Delivery ディレクター
- 藤井智弘氏 日本ヒューレット・パッカード ソフトウェア事業統括 シニアコンサルタント
- 川瀬敦史氏 日本IBM クラウド・ソフトウェア事業部 DevOpsエバンジェリスト
- 長沢智治氏 アトラシアン シニア エバンジェリスト
- 牛尾剛氏 米マイクロソフト シニア テクニカル エバンジェリスト DevOps
「自分たちのやり方」を作るにはどうすれば？
編集部 座談会の前半では「ビジネスのためという目的が見えていなかったこと」「DevOpsを適用すべき領域、具体的な実践方法は、自社の目的・組織に応じて、自分たちで決め、そのための手段も自分たちで選ぶべきものであること」――こうした、これまであまり語られてこなかったことをあらためて確認することができたと思います。
後半では「自分たちのやり方」を作る上でのポイントをお尋ねしていきたいと思います。まずは何から始めると良いのでしょうか？
藤井氏 日本ヒューレット・パッカードでも顧客企業にDevOpsの海外事例をよく紹介していますが、そこでは前半での話のように、「まずマニフェストを作る」ことを解説しています。まず言葉で誘導して、最初にチームの意識を合わせる。「自分たちのビジネスゴールは何か」「売り上げを伸ばすのか」「シェアを伸ばすのか」など、最初にチームの意識合わせを明確化するのが重要だと思います。
日本ヒューレット・パッカード 藤井智弘氏 ともすれば“How to”の議論に終始しがちな新しい開発スタイルに対して、いまこそ「品質へのこだわり」を再度盛り上げるべきと思う昨今。『ディシプリンド･アジャイル･デリバリー』監訳者
一般にDevOpsと聞くと対コンシューマー向けという話が多くなりがちですが、先の話のように、大企業の中にはさまざまな部門がある以上、「目的」はいろいろあり得るわけです。「対コンシューマー」のサービス開発だけではなく、「社員の生産性を上げる」ことも間接的なビジネスの競争力になり得る。
例えば、「社員の生産性を上げる」という目的を考えると、これまで野良ITとして嫌忌されてきた「現場主導での社外サービス導入」を、どううまく業務システムとして取り込むかがキーになると思っています。
リリースサイクルが短く非同期にアップデートされるさまざまな社外サービスを取り込みつつ、ある部分は作り込み、同時にセキュリティなどのコンプライアンスも担保しなければならない。せっかく社外サービスを取り込んでも、従来の業務システム開発でのスピード感で進めていては、メリットを享受できません。
これまでも開発部門、運用部門各々が独立して施策を打ってきているのですから、「ビジネス貢献」というハイレベルのキーワードの下では、「これまでの改善活動と何が違うの？」という話になってしまう。目的を一段ブレークダウンしたときに、「スピード」というDevOps特有の要件があるか否かが重要です。
「DevOpsを知りたい」と言われたときには、"DevOpsが求められるようになった背景"を知ってもらうために、Flickrの講演を見ることを勧めています。しかしうのみにするのではなく、「自分たちにとってスピードがどういう意味を持つか」を自分たちなりに解釈してもらった上で、「そのために、ビジネス部門、開発部門、運用部門が協力して合理化を突き詰め、それを継続していくこと」といった説明の仕方をしてもいいと思います。
この「合理化」を図るためには、「結果を測る」ことが必要ですし、なぜそうなったのかという「分析」も必要。また、サービスの社外向け、社内向け問わず、ビジネスに役立たせる上では品質が不可欠なので「テスト」も必要となる。このように、かなり言葉を日本的に直して「手段」に落としていかないとやはり腹落ちはしにくいと思います。
編集部 取り組みの根幹となる「カタチにするまでの時間を、なぜ短くしなければならないか」は、自分たちで解釈することが重要なのですね？
藤井氏 その答えは、ベンダーが客観的な立場から出せるようにないと思います。Webサービス系やスタートアップ企業は分かりやすいですが、一般企業の場合、先の話のようにいろいろな「目的」があるので、ただ「スピードが必要」と言ったところで、「ウチはそんなにリリースしない」と言われることが多いのではないでしょうか。DevOpsの必要性がないと判断している組織が無理に入れる必要はないと思います。
日本IBM 川瀬敦史氏 複数の外資系ITベンダーにて“Dev（開発）”と“Ops（運用）”に関わるソリューション提案や導入支援を数多く実施。その経験を生かし、顧客のビジネス成功に向け、顧客と二人三脚でDevOpsの展開をサポート中
ただ、「本当に必要がないか否か」は議論の余地がある。ベンダーとしては、「こういう手段があると、こういうやり方もできるようになる。それなら変える方が得なんじゃないですか」という提案はできる。無理に押し付けたりはせず、可能性を見せるわけです。
川瀬氏 私も顧客企業を訪問するとDevOpsの定義を求められることが多く、Flickrの「1日10回リリース」の話から始まって、「いかに共通の認識、意識合わせが必要か」などを説明するのですが、議論の大元となる「ビジネスをどうしたいのか」については、われわれが答えを一方的に提示してはいけないところだと考えています。そこで必ず、IT部門、ビジネス部門、各関係部門に一緒に考えていただき、まずは共通認識を持ってもらう。そうなると、その「目的」のためには「DevOpsをどのサービスに適用すればいいか」「DevOpsの実践手段となるツールは何を選べばいいか」という話に自然と落ちてくることが多いですね。
Copyright © ITmedia, Inc. All Rights Reserved.