なぜDevOpsは正しく理解されてこなかったのか？～ベンダーキーパーソンが徹底討論～（後編）：「DevOpsとは？」の決定版。今ハッキリさせる「正しいDevOps」実践法（4/4 ページ）

» 2016年01月22日 05時00分公開

[文:斎藤公二／インタビュー・構成:内野宏信／＠IT]

※本記事はアフィリエイトプログラムによる収益を得ています

SIerに運用を外注していてもDevOpsは実現できる

編集部　ところで、先ほどトップダウンと内製化がDevOpsのキモだという話が出ましたが、企業においてDevOpsの仕組みが作られると、一連のデプロイパイプラインのうち、SIerはどこに食い込むことができるのでしょうか？

自社の目的、状況に応じて、複数の手段を選び、組み合わせることでスピーディに開発・リリースするDevOpsの「仕組み」を構築する（資料：ガートナー／特集第2回「DevOps再入門～DevOpsが生きる領域、ITILが生きる領域～」より）。ただ、こうなると「SIerはどこに参加するのか」という議論もある

日本CA 渡辺隆氏　2014年より現職。継続的デリバリーやテストの自動化など、DevOpsを支援するツール群の日本での事業責任者を担当。以前は、Rational SoftwareやIBMで開発ツールやプロセスの製品マーケティングを担当

渡辺氏　INGバンクで面白いのは、チームにSIerも入っていることです。スクラムチームの発展系として、プロダクトオーナーと開発担当、運用担当を入れて1チーム10人体制でDevOpsチームを運営している。例えば「預金」のチーム、「チャネル」のチームといった単位です。

　その体制が今ある顧客事例の中では究極の形ですが、日本でもすぐにそういう体制を取れるかというとそうではないと思います。そこで、まずはその前段階として継続的デリバリーをやりましょうと勧めています。そこが回り始めると運用も一つのチームの中に入ってくる。それには2～3年かかると思いますが、有効だと思います。

編集部　何らかの形でSIも顧客企業に食い込んでいく必要があるわけですね。一方で、企業側にとっても「SIerに委託しているからDevOpsは無理」ということはないわけですね。

藤井氏　ただ「受託開発」といっても、完全な内製化のように「命令系統も含めた一体化」は契約的にできない部分もあります。これは法的な問題なので崩せないラインです。そこが障害になるなら、DevOpsというコンテクストで言われている技術を諦めるのではなく、「DevOpsに必要な各要素の効率化」をすればいい。その効率化を突き詰めた結果、それでも足りないなら、「契約形態を見直す」というやり方でもいい。つまり、あるステージでは各々の効率化をして、それらを一連のプロセスとして段階的につなげていく。最終的にDevOpsの実現に至るまでに、そうしたステージが何段階かあってもいいと思うんです。

　現在の契約形態を見ると、そうした段階をたどらざるを得ないのも事実です。従って、弊社でも「最初から全部やるべきだ」ではなく、「最後にここに到達するために、ここからやりませんか」という提案をすることが多いです。

編集部　確かにDevOpsの取り組みにおいて、「契約があるから」「コンプライアンスを担保できないから」と最初から諦めている傾向もありますよね。

藤井氏　よくあるのが「部門を分けろ、と監査で言われた」というケースです。「コンプライアンス上、開発部門に顧客のデータを触らせることはできない」といった形ですね。「コンプライアンスがあるから」「法的な契約の問題があるから」と安直に対応するのではなく、本当に必要なら、目的に向けて一つ一つ問題を崩していくことが大切だと思います。この「本当に必要なことは何か」を一緒に解きほぐすお手伝いをするのもわれわれの役割です。

今後のサービス開発はどうなる？

編集部　これまでの議論を通じて、「DevOpsとは」が明確になりましたし、「なぜ今、重要なのか」「多くの企業にとって実践を検討する必要があるのか」についてもはっきりしたと思います。

　特にその必要性については、冒頭でも述べたように、IoTやFinTechトレンドが本格化し、新しいサービスのスピーディな開発・改善が求められている中で一層高まっていくと思います。皆さんは今後のサービス開発はどのようになっていくと見ていますか？

長沢氏　当然、今までとは違う流れが出てくると思います。根幹にあるのは「ビジネスに寄与すること」であり、そのためにサービスを作る。その観点で見ていくと、開発・運用していくシステムは、ビジネスとしてやったことがない新規のシステムに取り組んだり、要件が固まらないものに着手してテクノロジーでその発展をリードしていったり、といったことが必要になると思います。

　そうなると、自社が使ったことのないテクノロジーを使わざるを得ない状況も出てくるでしょうし、他のサービスとつながなければいけない問題も出てくる。単純に言うと、規模は小さいが複雑なプロジェクトが増えるように思います。

　そういう中では、自分たちの開発・運用の能力をもう一度見直して、いい点は伸ばす、足りない点は成熟度を上げるか、他から持ってくる、といったことに冷静に取り組んでいくことで、「ビジネスにITで寄与できるか」どうかが決まってくると思います。

藤井氏　IoTについて言えば、大量データがスピーディに分析されて、アクションにつながる知見が得られるとなると、「因果律」をベースにニーズを理解、予測、検証するプロセスではなく、「結果」を見て開発していく“条件反射のサービス開発”になるのかなと思います。そう考えると、短期間でどんどんものを作る、改善することがサービス開発の根幹になる。

川瀬氏　そうですね。単純に「作る」だけではなく、「顧客に満足してもらえるものを常に提供し続ける」、かつ「満足を獲得し続ける」ことが重要になっていきますから、やはり「創り続ける」「活かし続ける」仕組みを作るDevOpsが一層重要になるように思います。

米マイクロソフト牛尾剛氏　マイクロソフトDevOpsテクニカルワーキンググループ。黎明期からアジャイル/DevOps実践者、コンサルタントとして、多くの企業のアジャイル/DevOps導入を支援。海外講演も多数

牛尾氏　僕は、なぜ日本だけ眉間にしわをよせて開発しているんだろうと思いますね。今、ソフトウェアの世界では一人でやれることがとても増えている。例えばDockerでデプロイの形が根本から変わってきている。「Docker Swarm」を使って1万台にデプロイすることもできれば、「Mesosphere DCOS」を使うと、クラスタまるごと1台のコンピューターのように扱える。こうしたことをスタートアップだけではなく、エンタープライズでもやろうと思えばできるんです。

　失敗を恐れて眉間にしわを寄せて開発するのではなく、こうした環境があることを生かして、ビジネスを楽しめばいいと思う。さまざまなことにチャレンジして間違っていたら修正すればいい。そういう時代になるんじゃないかなと思います。

参考リンク：

渡辺氏　私は、変化するニーズに応えていくために、「新しいサービス」を作る期間がますます短くなっていくと思います。例えば、6カ月以内に主軸となるようなサービスを作る大企業もあります。

　また、これを実現するために、LOBに近い人たちがイニシアチブをとる傾向も強まっていますし、大企業でもいろんな人とワークする機会が増えてきている。その代表的なものがハッカソンです。従来は有名な大企業がハッカソンで社外からサービスのアイデアを募るということはなかったのではないでしょうか。またAPI公開などを通じて、従来は競合関係にあった企業と連携するケースも増えてくるのではないかと思います。

参考リンク：

FinTechとは何か？（＠IT）
5分で絶対に分かるAPI設計の考え方とポイント（＠IT）

　基盤は完全にクラウドになっていくでしょうね。IoTでモバイルを軸とした新しいサービスを作ろうとすると、そういう方向に流れていかざるを得ないし、実際そういう方向に進んでいると思います。2016年はこうした動きが加速するのではないでしょうか。これに伴い、DevOpsの必要性はますます高まっていくはずです。

DevOpsを通じて「ビジネス」を楽しもう

編集部　ただ、DevOpsの重要性や取り組みの中身を理解していても、実際にやるとなると、思いもよらない問題も生じるのかもしれませんね。

藤井氏　トップの理解もその一つかもしれません。例えば日本企業では、トップがWebメディアなどの情報を見て「アジャイルをやってみろ」という傾向もありますよね。現場からすると、「アジャイルをやったと分かってもらうために、何をすればよいか」で悩んでしまうケースも少なくない。

牛尾氏　それはつらい。

藤井氏　こうした問題を個人の才覚で解決できる人はできるんですが、必ずしもそれで全て解決できるわけではない。われわれベンダーの立場としては、個人や組織の才覚ではハンドリングできない部分で、いかにサポートするかが重要だと思っています。上の人の説得もお手伝いするし、仮に誤解があったとしても、その誤解を一気に崩そうとするのではなく、少しずつ説明していったり。日本ではそういうやり方が必要なのかなと思います。

牛尾氏　僕の場合は、個人的にですが、企業へのアプローチを変えたんですよ。以前は、「受託開発のスタイルの中で、どうやればアジャイルができるか」といった具合に、課題を一つ一つ洗い出しては解決していくアプローチを取っていましたが、最近になって「そういうやり方はもういいかな」と。

　というのも、グローバルを見れば他の企業は非常に積極的にアジャイル開発やDevOpsに取り組んでいるわけです。日本という狭いマーケットで考えれば、今のところは大丈夫かもしれませんが、日本企業も世界と戦えるよう、もっとエバンジェライズしていかないとダメなんじゃないかと。そのためになら自分は劇薬になってもいいかなと（笑）。

　世界から「あの会社はすごい」と言われる事例を作りたいんです。そのためには、藤井さんがおっしゃったような一歩一歩進めていくやり方も必要ですし、Hackfestを開くなど僕のようなテロ的なやり方（笑）もいいと思うんです。各ベンダーが、それぞれの考え方でアプローチをしていくうちに、多くの日本企業にとってDevOpsに取り組みやすい「いいやり方」が広まっていくといいなと思っています。

　一方、企業の方も「これはこうしないといけない」という思考では何もできないので、「どうやったらおもろいかな」「こんなんしたら競合に勝てるかもしれへん」といった具合に、苦しまんでも、DevOpsを通じてビジネスを楽しんだらいいのではないかと思います。

編集部　今回はDevOpsの手段ではなく、意義や考え方を徹底的に見直すという趣旨でした。この根幹の部分をしっかりと認識し直しておくことで、これまでに数多く公開されてきた「手段」に関する情報源も、「定義」や「マニュアル」ではなく、豊富な「選択肢」として見えてくるのではないかと思います。ありがとうございました。

◇

　最初に「何がしたいのか」という“自社のビジネス目的”があり、それに必要と判断すれば、SoR／SoEを一つの基準にDevOpsの適用領域を考え、「必要なときに、必要なだけリリースできる仕組み」を作る。DevOpsに取り組む目的も各社各様なら、その仕組みを作るための手段に何を選ぶか、手段をどう組み合わせるかも各社各様。ベンダーは「各社の目的」の実現のために、各社の志向や状況に応じて選べる、さまざまな手段とサポートを用意している――。

　DevOpsの本質をあらためて確認した本座談会。DevOpsに着手済みの企業も、これから取り組む企業も、ぜひ参考にしてほしい。次回は座談会の中でも話題に上った書籍、『The PHOENIX PROJECT』（邦題『The DevOps 逆転だ！』）の著者の一人、ジョージ・スパッフォード（George Spafford）氏へのインタビュー模様をお届けする。

特集：今、国内DevOpsを再定義する

2013年から盛り上がりを見せた国内DevOpsトレンド。だがこれを見る立場、観点によって「文化」「自動化」など解釈が拡大し、取り組む企業も限定的だった。だが欧米ではそうしたフェーズはすでに終わり、収益・ブランド・業務効率向上に不可欠な要件となっている。そして今、国内でも再び「DevOps」が注目されている。その理由は何か？結局DevOpsとは何を指し、何をすることなのか？今あらためて、国内DevOpsを再定義する。