もはやウオーターフォールだけでは戦えない理由：“黒船”たちがde:codeで語ったDevOpsの極意（2/2 ページ）

「謝るのは後でいい！」、小さくてもいいからまず実践を

　では、DevOpsを推進していくために必要なことは何だろうか？ パネリストらの答えは「まず実践」に尽きるようだ。

　「まず何でもいいから小さな領域で取り組んで、うまくビジネスを加速でき、成長できるという成果を示すことだろう。DevOpsを導入し、バグを素早く見つけ、継続的デリバリや自動化によって、（ビジネスに）これだけの成果が得られるのだと示し、気付きを得ることだ」（ハシモト氏）

　「まずやってみて、実践から経験を得ることが重要だ。正しいツールを用いて実践し、その成果をオープンにして共有していけば、周囲もそれを学びたいと考え、自ずとプロセスや文化の変化につながるだろう」（ケーシー氏）

　技術の扱い方について注意を促したのは、ウィリアムズ氏だ。「Dockerがいい例だが、新しいテクノロジは突然現れ、市場を席巻していく。これには、新たなイノベーションをもたらすという良い側面もあるが、悪い側面もある。ある特定の技術に“賭ける”のではなく、イノベーションを継続できるよう新しい技術を“見ていく”ことが大切だ」

　グッゲンハイマー氏は、継続的インテグレーションや可視化、リリースオートメーションといったキーワードを挙げた上で、単刀直入にこのように述べた。

　「言い訳はなしだ。話は簡単で、まずスタートしてみればいい。誰かに許可を得る必要はない。とにかくやってみて、うまくいったら後から『ごめんね、成功しちゃった』って言えばいい」

クリエーションライン 執行役員 鈴木逸平氏

　これを受けて、日本の組織の実情を知る牛尾氏は、「まずバリューストリームマッピングから取り組んでみてほしい」と提案。

　「特に日本の場合に重要なのは、ビジネスルールを変える権限を持つ利害関係者をうまく巻き込んでいくこと。そうした権限者を巻き込んでバリューストリームマッピングを共有することで、『これは無駄だね、これはいいね』といった共通理解を得ることができ、“ビジネス価値を生み出すまでのリードタイム”の短縮や、そのために自動化が必要なプロセスが見えてくる」

　鈴木氏も、「坂本龍馬のようなビジョンを持って、まず小さくてもスタートすることが大事。そして、本を1冊丸ごと読んだり、ブログを読んだりするよりも、何より体験することが大切だ」と“実践”を勧めた。

選択肢があることがオープンソースの強み、コミュニティで勝負を

　ところで、パネリスト各氏は、DevOpsという潮流をめぐっては協力し合いながらも、おのおの何らかの「プロダクト」を提供する立場でもある。そこに矛盾は生じないのだろうか？

　この答えはシンプルで、「われわれの製品には必ず他の選択肢がある。それがオープンソースプロダクトのいいところだ。決してロックインされておらず、異なるアプローチに容易に変更できる。『見えないトライアル』と言っているが、使ってみて必要であればサポートもどうぞ、という形だ」（ケーシー氏）

　「機能で争うのではなく、コミュニティ対コミュニティの争いであり、オープンソースの世界ではこれが重要だ。日本でも活発なDevOpsコミュニティが生まれることを期待しているし、それを支援していきたい」（ウィリアムズ氏）

　「大事なのは、バリューストリームマッピングを通じて、プロセス全体をスローダウンさせている理由を見つけること。最もインパクトが大きいところを特定し、その解決に適したものであれば、他のものを提案することもある」（ハシモト氏）

　牛尾氏はこうしたコメントを受け、「マイクロソフトも世界的なコミュニティの一員だと考えている。Azureを使う人もいれば、AWSやGoogleを使う人もいる。問題は、皆さんが何をやりたいのかに耳を傾け、ツールやビジョンを共有し、改良し続けていくことだ」と、DevOpsの実践を呼び掛けた。

　そして最後にあらためて「黒船は間違いなく到来している」と強調したのはグッゲンハイマー氏だ。「真っ暗なトンネルに入るなら、周りで何が起き、自分がどのくらい進んでいるかを把握することが大事だ。継続的フィードバックを通じて何が起きているかを可視化し、それに基づいてサービスを改善し続けることを短いサイクルで繰り返すことが重要であり、われわれはパートナーとしてそれを手助けしていく。一丸となって、この旅の目的地を目指そう」と会場に呼び掛け、パネルを締めくくった。

　市場環境変化が速く、先を見通しにくい上、何が正解かも分からない中で、ニーズの変化に対応しながら、スピーディにビジネス価値を生み出し続けるためにはどうすれば良いのか？

　DevOpsは、そうした状況にある中で「ビジネス価値を生み出すまでのリードタイムをいかに短縮するか」「リードタイム短縮を阻む制約条件をいかに発見し、解決していくか」という取り組みだ。そしてその実現のために、幅広い選択肢の中から自分たちの目的に最適なツールを自由に選び、組み合わせて、「サービスをスピーディかつ継続的に開発・改善できる“自分たちに最適な仕組み”」を作る、ビジネス部門も巻き込んで、常により良いものへとカイゼンし続けるプロセス、文化を作る取り組みだ――。

　DevOpsというと、日本ではいまだ「自動化」や「ツール」を想起する傾向が根強い。だが、それらはあくまで手段の1つにすぎない。“黒船”たちの言葉からは、そうしたDevOps本来の姿を、あらためて実感できるのではないだろうか。