『The DevOps 逆転だ！』著者に聞く、「DevOps」や自動化よりも大切なこと：米国でDevOpsが浸透している「本当の理由」（2/2 ページ）
前回は国内DevOpsトレンドをけん引してきたベンダーキーパーソンによる座談会により「DevOpsとは何をすることか」を明確化した。今回はそこでの話も基に、『The DevOps 逆転だ！』の著者の一人、ジョージ・スパッフォード（George Spafford）氏に話を聞いた。
DevOps浸透の背景には、「品質」と「カイゼン」に対する反省がある
編集部 米国ではそうした認識が多くの企業に浸透しているということですね。ただ、DevOpsが浸透している一つの背景として、米国企業の「内製文化」も指摘されていますが。
スパッフォード氏 そうした表面的なことよりも、「大野耐一氏が体系化したトヨタ生産方式、石川馨博士のTQC（Total Quality Control：総合的品質管理）、ウィリアム エドワーズ・デミング博士が取り組んだリーンの方法論などが大切なんだ」という認識に、多くの企業が今あらためて立ち返っている、ということが大きな要因です。換言すれば、近年、多くの米国企業において、「刻々と変化する市場環境の中で、“より良い品質のものを迅速に提供し続ける”ためには、人をエンパワーし、チームが一丸となってカイゼンを目指すべきであるのに、そうしたことが忘れ去られてきたのではないか」という反省があるのです。
トヨタ生産方式：トヨタ自動車が編み出したモノづくりに関する体系的活動。一般に「かんばん」「多能工」「多工程持ち」「省人化」「少人化」「アンドン」などの各手法を組み合わせた生産方法と説明されるが、「絶え間ない改善の精神」「改善を行う際のものの見方・考え方」がトヨタ生産方式の本質と説明されることもある。
TQC（Total Quality Control：総合的品質管理）：主に製造業において、製造工程のみならず、設計・調達・販売・マーケティング・アフターサービスといった各部門が連携をとって、統一的な目標の下に行う品質管理活動のこと。
ニーズの変化が激しい中で、スピーディに、（各社が考える）より良い品質のものを開発・提供し、差別化を図り続けるためにはどうすれば良いか――そうした文脈で言えば、コマンド＆コントロール文化とウオーターフォール型の開発スタイルは崩壊したと言っていい段階にあります。DevOpsは、現在の経営環境に対応するために、従来型の古典的なやり方を見直す動きの1つなのです。
参考リンク：リーンソフトウェア開発 「7つの原則」（＠IT）
米国では多くの企業が「IT部門が変わらなければいけない」と認識しています。ビジネス側も「今までと同じことをやっていたのでは競争優位性は生まれない」と考えています。「ビジネスだけ」「ITだけ」が変わるのではなく、「どうすれば両者が一緒に変わっていけるのか」ということに、多くの企業が注目しているのです。
「価値を生み出すまで」という視点でボトルネックを発見、解消する
編集部 ではDevOpsに取り組む上では何がポイントになるのでしょうか？ あらためて実践のアドバイスをいただきたいのですが。
スパッフォード氏 米ガートナーが2015年に行った「DevOps adoption, Gartner Sep. 2015 survey」で「DevOpsを展開する上での阻害要因は何か」を聞いたところ、50％は「人の問題」と回答しました。次に多かったのは「プロセス作り」で37％。ただ、その理由を堀り下げてみると「スキルやナレッジがない」など「人」に起因するものが多かった。一方、「ツール」は8％にすぎず、「フィードバックにおける情報の流れ」は5％でした。やはり、まずは前述のように「一緒に事業を回せるようになるために、人や組織をどう変えるか」を考えることが大切であり、続いてプロセスを検討する必要があります。
その点では、エリアフ・ゴールドラット氏が提唱したTOC（Theory of Constraints：制約理論）の5ステップが参考になります。大切なのは「価値を生み出すまでの平均時間をどう短くするか」「アイデアがビジネス価値を生むまでのプロセスをどう設計し、短時間化するか」という考え方です。
多くの人が、「プログラミングの時間を短縮する」「コードをプロダクション環境に乗せるまでの時間を短縮する」といったことを考えがちですが、TOCの5ステップに基づき、ビジネス目的を実現するまでの大きなサイクルを視野に入れる。その上で「どこが制約条件になるか」「最も制約がかかっている部分は何か」に注目して、制約を取り払うのです。
TOCの5ステップ
ステップ1：制約条件の特定
ステップ2：制約条件の活用
ステップ3：制約条件に従属させる
ステップ4：制約条件を強化する
ステップ5：再度、制約条件を特定する
※TOCでは「改善」ということを厳密にとらえている。すなわち、「改善とはボトムライン（利益）を改善する活動のみを指す」ということである〜中略〜企業全体のサプライチェーンを見渡した際に、真の制約条件こそがサプライチェーン全体の利益を規定してしまうという理解から、総花的に改善するのではなく真の制約条件から重点的にかつ真っ先に取り組むことを指摘している。（「サプライチェーンの原点TOCとは何か」より／＠IT）
その結果、企業によっては「サーバのプロビジョニング」が制約になることもあるし「手動でのテスト」や「リリース」が制約になることもある。「テスト事項を集めること」が制約になっている場合もある。そのうち、どこを自動化ツールに置き換えられるか、といった順序で考える。
しかし、ビジネス価値を生み出すまでのサイクル全体を見ずに、「デプロイパイプラインのうち、どのステップが」といった個別最適な見方に終始してしまうと、リスクやコストが膨らむばかりでより良いプロセスは作れないことになってしまいます。
TOCでは全体最適を追求し、個々の改善を積み上げる部分最適化手法を否定している。このことは全ての改善活動が企業の利益に直結していなければならないというゴールドラット博士の考え方に起因する。海外部品に置換し部品原価を削減しても、リードタイムが延びて製品の在庫がかえって増加してしまったり、 結果的に値引き販売に走り販売経費が増してしまうようでは企業利益は増加しない。（「サプライチェーンの原点TOCとは何か」より／＠IT）
「どうビジネス価値を出すか」、エンジニアには探究心が必要
編集部 お話を振り返ると、『The DevOps 逆転だ！』でも感じましたが、DevOpsはまさしく「ITサービス」というものづくりの在り方を見直すものですし、今後のサービス開発・運用の柱となっていくといえると思います。こうした中で、ITエンジニアはどう変わっていくべきだと思いますか？
スパッフォード氏 重要なのは、探究する気持ちとイノベートする気持ちです。これまでは過去の成果を基に、似たものをアレンジして新しい製品・サービスを展開することもできました。ですがこれからは、潜在・顕在ニーズを基にまったく新しいものに取り組まなければなりません。そこで重要になるのは、やはり開発、運用、ビジネス企画など、チーム全体が一緒になって、顧客も巻き込みながら「今、何が求められているのか」という解を見つけ、それをどう継続的に実現、改善していくかを見極めることです。それを実現するために、探究心を持ってイノベーションを目指す中で、開発エンジニアと運用エンジニアは自ずと手を取り合っていくことになるはずです。
編集部 IoT、FinTechトレンドも本格化しつつある中で、「DevOps」は数年後には当たり前となり、言葉もなくなっていくのかもしれませんね。
スパッフォード氏 そうかもしれませんね。しかし個人的には、先の話のように何と呼ぼうが構わないと思っています。（経営環境変化が速い中で）「目的を達成するために、“自分たちの組織では”、どんな考え方で、どんなプラクティスで、どんな取り組みを行っていくか」が大事ですから。今後、グローバルでどんな取り組みが出てくるのか、私も楽しみにしています。
ガートナー 長嶋裕里香氏に聞く「インタビューに同席して」
編集部 今回のインタビューを通じて、「DevOpsという手段」が目的化してきた国内の傾向をあらためて確認できたように感じます。
長嶋氏 手段が目的化する傾向は、DevOpsに限らずありがちなことのように思います。ITILが注目され始めたときも同様であり、「サービスデスクを入れること」が目的化してしまう例も目立ちました。「何をアウトカムしなければいけないのか」が忘れられ、「ツール」や「やり方」の話が先行してしまう。
開発手法についても同じことが言えます。例えば「アジャイル開発を選ぶ」理由は、ウオーターフォールがダメだからではなく、「目的に合致している」から。もちろん、この「目的」とは「開発部門のため」でも「運用部門のため」でもありません。しかし現実には必ずしもそうした選び方ができていないことも多いのではないでしょうか。
ゴールドラットの制約理論の話も出ましたが、『The DevOps 逆転だ！』に描かれているのも、「サービスを通じて、自分たちはどんな価値を提供していくのか」という「目的」を実現するために、プロジェクトチームが1つ1つ制約を発見し、解決していく姿です。価値を生み出すために、手段として何を選ぶか、何をするかは各社自身が判断すべきことです。
編集部 ただ「ビジネスだけ」「ITだけ」ではなく「いかに両者が一緒に変わっていくか」という認識は日本でも深まりつつあります。それでもDevOpsの浸透が遅れている理由はどこにあるのでしょうか。
長嶋氏 1つは「それほどのスピードを要するサービスはうちにはない」という“思い込み”が強いことだと思います。DevOpsが必要な領域は、必ずしもコアコンピタンスの領域だけではありません。新規事業の場合もありますし、そうした領域に適用している事例もあります。“既存のものありき”で考えてしまうと、そうした部分に気付きにくいのではないでしょうか。
もう1つは、「やろう」という意思決定を下せる人が日本では少ないことだと思います。少しずつ変わりつつありますが、日本ではIT部門の意思決定権を持つ方々において、「モード2」そのものの理解、そしてその必要性の理解が十分ではない傾向が見受けられます。
こうした中でDevOpsを推進する上では、IT部門が旗振り役となるアプローチもありますが、ビジネス部門主導で行われる可能性も高いと言えます。DevOpsをビジネスの手段と考えると、必ずしもIT部門主導でなくてもいいわけです。実際、「モード2」についてはビジネス部門の方が感度が高いと思います。
モード1／モード2：ガートナーではシステムの特性を分けて考える「二つの流儀」という考え方を提唱している。「モード1」は変化が少なく、確実性、安定性を重視する領域のシステム。「モード2」は、開発・改善のスピードや「使いやすさ」などを重視するシステムを指す。モード1、2共にユーザーの「満足度の高さ」を狙うことは同じだが、モード1が「安心・安全」を狙うのに対し、モード2は「すぐに分かる、できる、使っていて楽しい」といった要素を優先する（「DevOps再入門〜DevOpsが生きる領域、ITILが生きる領域〜」より）
編集部 その点、「変化に追従するスピード」が必要なのはもちろんですが、米国企業におけるDevOps浸透の背景には、「品質」に対する反省がある、といった指摘は大きなポイントだと思います。
長嶋氏 これまでIT部門は、システムを向いて仕事をしてきたことが多かったと思います。特に運用部門はモニタリングツールやアラートなどを見て対処するのが一般的でしたが、本来はその先にいるユーザーや社外の顧客に目を向ける必要があります。提供しているITサービスの稼働状況を見て、モニタリングツール上では正常だったとしても、快適にサービスを届けられていない場合もあるわけです。今は大企業のIT部門に「本当にそういう意識、視点がありますか」ということが強く問われている状況だと思います。
DevOpsはビジネスのため、ユーザーのために、いかにより良いサービスを提供し続けていくか、という取り組み。「自分たちが提供できる価値は何か」、コアコンピタンスに縛られることなく、考えてみてはいかがでしょうか。そして先を予測しにくい中で、ニーズの変化に追従しながら「価値」を提供し続けるためにはどうすれば良いのか――そのためには必然的にDevOpsのアプローチが必要になることを、あらためて理解できるのではないでしょうか。
特集：今、国内DevOpsを再定義する
2013年から盛り上がりを見せた国内DevOpsトレンド。だがこれを見る立場、観点によって「文化」「自動化」など解釈が拡大し、取り組む企業も限定的だった。だが欧米ではそうしたフェーズはすでに終わり、収益・ブランド・業務効率向上に不可欠な要件となっている。そして今、国内でも再び「DevOps」が注目されている。その理由は何か？ 結局DevOpsとは何を指し、何をすることなのか？ 今あらためて、国内DevOpsを再定義する。
Copyright © ITmedia, Inc. All Rights Reserved.