『The DevOps 逆転だ！』著者に聞く、「DevOps」や自動化よりも大切なこと：米国でDevOpsが浸透している「本当の理由」（1/2 ページ）
前回は国内DevOpsトレンドをけん引してきたベンダーキーパーソンによる座談会により「DevOpsとは何をすることか」を明確化した。今回はそこでの話も基に、『The DevOps 逆転だ！』の著者の一人、ジョージ・スパッフォード（George Spafford）氏に話を聞いた。
DevOpsのありようを小説で世界に訴えた著者に聞く「本当のDevOps」
『The DevOps 逆転だ！』（著：ジーン・キム、ケビン・ベア、ジョージ・スパッフォード／日経BP社／2014年8月）「店頭小売りとネット通販を統合したシステムを3カ月以内にリリースせよ」という経営からの要求を受け、チームでさまざまな課題に立ち向かう中で「自分たちのやり方」を見いだしていくストーリー。小説を通じてDevOpsが分かりやすく語られている。IoTやFinTechトレンドが本格化しつつある今、「ニーズを基にITサービスを開発・改善するスピード」が差別化の一大要因となっている。国内企業にもそうした認識が広がり、その実現手段となるDevOpsがあらためて見直されている。ただ、その重要性は認識されていながら、いまだ十分に理解されているとは言えない状況だ。
これを受けて、本特集では「DevOpsとは何か」を徹底的に見直すという趣旨で記事を展開。前回は国内DevOpsトレンドをけん引してきたベンダーキーパーソンによる座談会により「DevOpsとは何か」を明確化した。
今回は、DevOps関連書籍として世界的に話題になった『The PHOENIX PROJECT（邦題『The DevOps 逆転だ！』の著者の一人で、米ガートナー リサーチディレクターであるジョージ・スパッフォード（George Spafford）氏にインタビュー。座談会で明らかにしたDevOpsの考え方を確認するとともに、なぜ米国ではDevOpsが急速に浸透しつつあるのか、“真の理由”を聞いた。
DevOpsの目的はビジネス。「定義」は重要ではない
編集部 当初、DevOpsはスタートアップを中心に大きな注目を集め、その後、Webサービス系企業を中心に浸透していきました。しかし昨今、欧米では金融、保険、製造など、いわゆる従来型の一般企業にも浸透が進んでいます。その傾向はIoTやFinTechのトレンドも受けて日本国内にも表れつつあります。Webサービス系以外の企業でもDevOpsの実践者が増えている理由をどう見ていますか？
米ガートナー リサーチディレクター ジョージ・スパッフォード（George Spafford）氏スパッフォード氏 それには大きく2つの理由があります。1つはタイムレースが激化していること。もう1つは需要が複雑化していること。競争が激化しニーズの変化も激しい中で、企業が差別化を図り、収益を上げ続けるためにはスピーディにイノベーションを起こす必要性があります。このイノベーションを模索するためには、ウォーターフォールを軸としたやり方では“変革を起こすペース”についていけなくなってきているのです。
特に“時間の戦い”が差別化のカギを握っている業種ほど、DevOpsの必要性に対する認識は深いと思います。例えば金融サービスや銀行業です。ビジネス機会を狙ったり、自社の脅威に対応したりする上で「スピードが必要だ」と考えるようになっています。もちろん全産業で重要性は認識されていますが、時間を意識している企業、デジタル戦略でイノベーションを生み出すことを重視している企業ほど、早い段階からDevOpsが浸透していると言えます。
編集部 そうした認識は日本でも着実に広がりつつあります。しかしその実践手段となるDevOpsについては、まだ浸透しているとは言い難い状況であり、定義を求める声も少なくありません。
スパッフォード氏 定義というと、業界では半ば冗談のようになっていますが、「5人にDevOpsの定義を聞くと、7つの答えが返ってくる」と言われています。しかしガートナーによる定義はあります。それは『ビジネス目的のために、アジャイルとリーンのプラクティスを使って、ITサービスのデリバリを迅速化することで、ITカルチャーを変えていくもの』です。
ビジネスの価値をスピーディに提供するために、人または組織文化を重視しながら、開発と運用がチームとしてコラボレーションできるようにします。技術的には自動化ツールを使ってITライフサイクルの観点から、インフラをよりプログラマブルでよりダイナミックな形にしていきます。
これをより分かりやすく言うと、DevOpsは「各関係者で組織したチームが一緒になって、ビジネスが必要としていることを、なるべく速く開発・提供していこう」「ビジネスのペースに合わせて価値を速く提供し、その価値を守っていこう」という考え方の下、それをどう実現していくかというものです。
ここで最も大切なのは、ビジネスが主体だということ。「DevOpsをどう定義するか」はさほど重要ではありません。それよりも「チームをどう編成し、スピーディな価値の提供・改善をどう実現していくか」こそが重要です。各組織が自分たちのビジネスにおいて、それぞれの狙いや目的がある中で、スピーディに価値の提供・改善を行うための「仕組み」を作る。その実現手段を「DevOps」と呼ぼうが、別の名称で呼ぼうが、それはどうでもいいことなのです。
DevOpsは「人ありき」の取り組み
編集部 「これをやればDevOps」といったものではなく、『The DevOps 逆転だ！』にも描かれていたように、「自社のビジネス目的」「組織体制」などに応じて、「自分たちに最適なやり方」を自分たちで探していくもの、ということですね。
スパッフォード氏 その通りです。ただし、「それはある程度、境界線を決めた中での話」というただし書きを付けたいと思います。小さい企業であれば、ある程度自由が担保されていますが、エンタープライズの大規模な組織になると、ビジネスやシステムの複雑性も高まりますし、それに付随するリスクやコストも存在します。つまり「ビジネス目的を達成するために、文字通り何でもやっていい」ということではなく、一定の制約の中で行うことが重要です。よって、DevOpsチームの運用を担うリーダーは、複雑性、コスト、リスクを長期的な観点も含めて理解した上で、「どういう制約がある中で、どのようにスピーディな開発・提供・改善を実現するか」を考えることが大切です。
編集部 もう少し具体的に言うと、リーダーとはどのような役割になるのでしょうか？
スパッフォード氏 まずはチームの中で知見を蓄積・共有して、「どういう形でDevOpsを実践していくか」を考える必要があります。製造業における品質向上の取り組みも同様ですが、チームの中でベストプラクティスをどういう形で共有すべきかを決め、それを基にチームを運営していく。
注意すべきは、「全てをチームスタッフの意思に委ねてしまわない」ことです。チームスタッフだけでベストプラクティスやスタンダードを決めるようになると、学びが企業内に共有されず悪循環に陥ります。そこで誰かがコーチングし、リーダーシップを持ってチームをけん引し、周囲と情報共有していくことが重要になる。チームスタッフとコーチングするリーダーが一丸となって取り組みを回していくのです。
「DevOpsを取り入れろ」と、上から一方的に命令すればうまくいくというものではありません。「コーチングすること」と「命令を出すこと」は、まったく違います。アジャイルやDevOpsは、チームの中に見識ある人たちが集まっているので、「全てのベストプラクティスはチームに集約されている」と言えますが、その活動を支え、見守るのがコーチの役割であり、他のプロジェクトチームとの情報共有を促したり、必要であれば部門間調整を行ったりします。リーダーたる人たちが、「どういう制約がある中で、どのようにスピーディな開発・提供・改善を実現するか」「自分たちが決定できる範囲は何か」をチームに分からせ、気付かせることが大切です。
編集部 DevOpsはチームスタッフが「目的達成のためのプロセス作り」に積極的に関与しなければ実現できませんが、一方で、実現のためにはテクノロジーだけではなく組織間の調整も必要になる。リーダーはDevOpsを実践しやすいよう支援してあげる役割だということですね。
スパッフォード氏 そうですね。アジャイル開発の軸となったリーン開発もそうですが、DevOpsも「人」ありきなんです。DevOpsというと自動化が注目されがちですが、自動化は手段であり、DevOpsという取り組みの本質に照らせば重要ではないと言ってもいいでしょう。
参考リンク：
- 書籍でたどる「リーン」の本質（＠IT）
- 「アジャイル開発」と「リーン」の関係（＠IT）
DevOpsとは「ビジネスとITが連携して事業を回していく」ことであり、IT担当やマネジメントなどチームの「人」を、一緒に事業を回せるように変えていくことでもあります。そのチームをどうメンテナンスし、モチベートし、必要なリソースを提供していくか。それがリーダーの役割です。テクノロジーのみに終始する話ではなく、「リーダーの役割」や「経営の在り方」をどう変えるかという問題なのです。
関連記事
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。