今回は CloudBees CEO & co-founder である、Sacha Labourey 氏のブログ記事を紹介します。
（この記事は、CloudBees社 Blog 「CloudBees Turning 10!」2020年3月9日 投稿記事の翻訳です）
今日はとても特別な日です。CloudBeesが10周年を迎えたのです。「10」！この10年間を思い起こすと、いくつかのシーンがよみがえってきます。JBossの買収から3年後、2009年にRed Hatを退社したときのことはよく覚えています。また何かを始めることになるのだとひそかに予感していましたが、それが何かはわかっていませんでした……数か月後に連絡をくれたFrançois Décheryは確信を抱いていました。「クラウドはITのすべてを塗り替えるだろう」と。私たちはその確信と、JBoss時代に学んだマーケットからスタートしました。Bob BickelやDavid Skokに初めて連絡し、私たちの最初の計画に意見を求めたときのことを覚えています。パリでのBobとのミーティングはひどいものでした。Bobは前の晩に調理の悪い鴨料理を食べたせいで一晩中具合を悪くした後でした。しかしすばらしいミーテイングでもありました。なぜなら、このとき初めてJenkinsという名前が付いたのです。当時まだトゥールーズに住んでいたLaurence Poussotは、CloudBeesの設立と維持に関わる事務を嫌な顔ひとつせず引き受けてくれました(われわれ共同設立者は、最初の日から3つの大陸に散らばっていたのです)。
エイヤフィヤトラヨークトルの噴火でヨーロッパ全体の空域が封鎖されるなか、ボストンのMatrix Partnersのオフィスで行われた最初のキックオフには、François、Michael Neale、Vivek Pandey、Ryan Campbell、そしてAdrian Brock（フライトが立往生したためリモートで）が参加しました。Kohsukeが加わったのは数か月後、Spike WashburnやGarrett Smithと同時期で、そのすぐ後にOracleとのHudson/Jenkins騒動、CloudBeesのPaaS時代、「Jenkinsエンタープライズの会社」時代が続いて現在に至ります。みな大切な思い出です。それは、起業家として得難い経験だったからというだけでなく（当時、10年後にはJBossの4倍の規模になっているなどと教えられたとしても、絶対に信じなかったでしょう）、この10年間は人間としてもすばらしい経験をしたからです。CloudBeesを立ち上げたとき、はっきり確信を持って求めたものはそれほど多くありませんが、1つのことだけは確かでした。私は傲慢なスターは求めませんでした。会社を築くのは大変なことですが、シンプルで良好な人間関係、直接の対話、そして透明性のある指針を維持するための努力に優るものはありません。毎日のように、こんなすばらしい仲間たち（Bees）と働くことができて光栄かつ幸運だと感じています。みんなすごいよ！
私の個人的な思い出はこれくらいにしましょう。しかし、CloudBeesの軌跡は、学び、変化し続け、ときには苦しみを乗り越えながら、どのように理想とビジョンに従ってやり遂げるかの一例でもあります。その旅路を皆さんともいくらか共有できればと思います……
CloudBees10年間の旅路
CloudBeesを設立したとき、私たちには明確なビジョンがありました。それは「アイデアから製品へのパスを合理化することで、開発者の影響力を高める」ことです。この10年間の旅で、さまざまな道に導かれましたが、最初のビジョンが見失われることはありませんでした。
このビジョンが最初に具体化したのは、Platform as a Service (PaaS)の開発を通じてでした。これは（当時のPaaSとは違って）単なる開発環境ではありませんでした。CloudBeesは、Gitからデプロイメントまでのアプリケーションライフサイクル全体をカバーした最初のPaaSだったのです。コアにJenkinsがあったのはもちろんです！
SVN から Git ホスティングまで、バイナリ リポジトリ、CI/CD、運用環境へのデプロイメント、アプリケーションのスケーリングと高可用性の提供まで―私たちはワンストップショップでした。
当時、PaaSマーケットは未成熟で（Dockerコンテナーは存在すらしていませんでした）企業は標準がない分野に投資するのに懸念を感じていました。重要なこととして、個々のチームにはこの「1つのサイズですべてに対応」アプローチは好評でしたが、導入を組織全体に広げようとすると、私たちのソリューションではいつも何かしら問題がありました。別のPaaS、別のクラウド、あるいはオンプレミスでデプロイしたいと希望される場合もあれば、別のリポジトリを使いたいと言われる場合もありました。結局のところ、簡単に始められるというのは非常に重要ですが、選択の自由と柔軟性はさらに重要です。企業にはすでに行った投資があり、さまざまな分野に投資し続けることを望んでいたので、「1つのサイズですべてに対応」アプローチは単純に不可能であり、もっと適応性の高いソリューションを探していたのです。
それでも、あるものだけは熱烈に市場に歓迎されました。それは私たちのソリューションが提供する、ソフトウェアデリバリープロセスを簡略化する能力です。最初のフェーズで、企業は私たちのソリューションの目的地（ランタイムPaaS、RUN@cloud）にはそれほど興味はないが、自社のアプリケーションが何らかの目的地に着くまでの過程を自動化するプロセスは非常に評価しているということを知りました。これが、すべてが常に流動的である「継続的エコノミー」につながり、必然的に、継続的インテグレーションと継続的デリバリーはまさに求められる「そのもの」だったのです。こうして2014年、私たちはすべてのランタイムPaaSから撤退し、Jenkinsに注力するという困難な決断を下しました。「CloudBees 2.0」時代に入り、私たちは「エンタープライズJenkinsの会社」になったのです。
この時期のCloudBeesは、ある意味、とても明快でした。世間にはJenkinsのワークロードを実行する何百万というサーバーがあり、そのうちの少なからぬ数が何らかの支援を必要としています。たとえばサポート、セキュリティ、スケーラビリティ/弾力性、認証、容易なアップグレード、管理など。これがその後のソリューション（CloudBees Jenkins Platform,、CloudBees Jenkins Enterprise、CloudBees Core）の重要なパートとなる「CloudBees Jenkins Operation Center」を生み出しました。当時、CI/CDプラクティスの採用は確実に進むいっぽうで、CI/CD市場はCI/CDベンダー間で比較的はっきりと住み分けされ、他のDevOpsベンダーはそれぞれの古巣のマーケット（Git、バイナリ リポジトリなど）に注力していました。当時の市場での注目は、次世代データセンターの獲得競争に集まっていました。その過程でDocker、Swarm、Mesosなどの台頭が見られ、最終的にはKubernetesに着地しました。この問題にけりがついたころ、市場は、目的地（Kubernetes）は重要だが、目的地にたどりつく旅の過程も重要だと気が付きました。効率的にアプリケーションを（継続的）デリバリーできないなら、目的地が効率的でもしかたがないではありませんか？目的地の問題であるとともに、旅の問題でもあるのです。
必然的に、DevOpsベンダーはより大きな構図について考えるようになり、古巣の「機能」（これは常にほかのより大きなコンセプトに包括されてしまうリスクがあるものです）を離れてよりグローバルな、真のソリューションに移行しました。時を同じくして、SaaSも含め、クラウドの採用が劇的に加速しました。
物語はひとっとびにCloudBees 3.0へと進むのでしょうか？そんなあっという間にとはいきません…。これは私たちにとっても旅の過程なのです。
この後はCloudBeesにとって過渡期が続きました。DevOps、クラウド、コンテナー、そして「クラウドネイティブ」開発の高まりに伴って、私たちのソリューションの深さと幅の両方を広げ、クラウド時代に特化した使いやすいツールを開発する必要があるという認識がJenkins Xを生み出し、SaaSが重要になるという認識がCloudBees CodeShipおよびCloudBees Rolloutに、企業はDevOpsの取り組みを効果的に測定する能力を必要とするだろうという予測がDevOpticsにつながり、最先端のクラウドネイティブアプリケーションをオーケストレーションするだけでなく、古いタイプのアプリケーションでも、継続的インテグレーションのメリットを継続的デリバリーにまで拡張したいという需要からElectric Flowを手掛けるようになりました。このような流れの中で―そして最先端を行く私たちの顧客が成功を収めてゆくのを確認する中で―ソフトウェアデリバリーを単に局地的な試みではなく、ビジネスプラクティスそのものとして確立する必要があるという認識に至ったのです。さらに、CloudBees 1.0時代に学んだことも依然として妥当です。企業はそれまで長い時間をかけて築いてきたものを総入れ替えするよりは、現状を受け入れられるようなソリューション、適応性の高いソリューションを望んでいます。
描きかけの絵画と同じように、個々の要素が部分部分で意味のある形をなし始めるいっぽうで、全体的な絵が明確になるにはいくらか時間がかかりました。
そしてついに現在地、つまりCloudBees 3.0に至ります…
CloudBees 3.0 – ソフトウェアデリバリーを制覇する
私はこのCloudBeesの新しい章にわくわくしています。たくさんの発見を経て、いま、私たちの描く絵は非常に明確です。オンプレミスからクラウドやSaaSまで、CIからCDまで、レガシーからクラウドネイティブアプリまで、ソフトウェアデリバリーの自動化からソフトウェアデリバリーのビジネスコンセプトへの昇格まで、これまでの私たちの資産が総合的な意味を持ちます。
CloudBees 3.0は共通プラットフォーム上に構築されます。これまで個々の製品に存在していた（製品の多くは買収によって獲得したものだったので）コンセプトがプラットフォームによって共有され、一つの方向に力を合わせます。ソフトウェアデリバリーをビジネスプロセスとして管理し、大規模な組織においても開発者の影響力を高めるという私たちのビジョンは、かつてなく実現に近づいています。CloudBeesでの仕事を通じて、私たちはあらゆる場所、あらゆるバックグラウンドのあらゆる開発者を支援し、彼らのパンチに最大限の重みを添えるという貴重な経験をしています。
構想
ソフトウェアが世界を侵食する時代において、「ソフトウェアデリバリー」が重要なコンセプトになっています。デリバリーの実現に使用される個々のツールだけでなく、デリバリーを維持するプロセスとデータには計り知れない価値があります。この分野でCloudBeesは他の追随を許さない先駆者です。関連するデータを収集し、洞察を引き出すいっぽうでプロセスをコントロールする手段を提供するという、デリバリーの総合的なオーケストレーションに関して、深みにおいても幅においても、CloudBeesに優る企業はありません。しかも、これらすべては、顧客の環境を置き換えるのではなく、既存の環境を受け入れたうえで実現できるのです。CloudBeesはソフトウェアデリバリー分野のリーダーです。
ソフトウェアデリバリー = SDA + SDM
多くの領域で当てはまることですが、何かの実行を担当するチームもあれば、実行の管理を担当するチームもあります。わかりやすい例を1つ挙げるなら、製品を生産する工場です。製品を電子的製品に置き換えれば、ソフトウェアの分野でも同じです。
したがって、ソフトウェアデリバリーも2つのレイヤーで構成されます。1つはソフトウェアデリバリーの自動化（つまり製品が生産される工場）で、もう1つはプロセスの管理（および制御ならびに最適化）です。ソフトウェアデリバリーオートメーション（SDA)とソフトウェアデリバリー管理（SDM)の登場です。チームを選別する必要はありません。あちらかこちらかではなく、両方が必要不可欠です。適切な管理なしに本当の価値を生み出す高品質のソフトウェアを確実にデリバリーすることはできませんし、存在しないものを管理することもできません。SDAとSDMはソフトウェアデリバリーの陰と陽です。
SDAの箱を開けてみると
SDAは、これまでCloudBeesの成功を支えてきた資産のすべてが入った箱です。Jenkinsに始まりJsnkins X、CloudBees Core、CloudBees Flow、CloudBees Accelerator、CloudBees Rolloutまで、継続的インテグレーション、継続的デリバリー/デプロイメント、フィーチャーフラグといったものがここに入ります。これがソフトウェアを作るという面に対応します。数日以内に、私たちはWebサイトを更新し、さまざまな進化を反映させる予定です。これについても追ってブログを書くつもりです。要点を言えば、CloudBeesのSDAソリューション全体がソフトウェアとしてもSaaSとしても利用可能になり、クラウドネイティブと従来型アプリケーションのどちらにも対応します。これによって私たちのポジションが非常に明確になります。従来型のプロジェクトからクラウドネイティブまで、ソフトウェア製品からSaaSまで、統一されたプラットフォームを中心として、お客様に適切な統合ソリューションを提供します。
SDAによってあらためて確信したのは、企業は統合的なアプローチによってデリバリーをオーケストレーションしたいが、オーケストレーションの個々のステップで使用するツールについては自由に選択したいと考えているということです。ツールは現れては消え、使うツールはチームによって大幅に異なる（そして頑固な）好みがあり、特定の機能ツールに縛られたい人は皆無です。私たちの戦略は、「1つのサイズですべてに対応」アプローチでどのチームにでもフィットするような平均的な統合済みソリューションを提供することではなく、今日も明日も、顧客にとっての多様性と選択の余地を受け入れるようなアプローチを採ることです。
ソフトウェアデリバリー管理（SDM)
上で述べたように、管理レイヤーのないソフトウェアデリバリーがうまくいくのは、「ローカル」な現象として、つまり小さな環境でだけです。最近のソフトウェアデリバリーおよびCI/CDプラクティスが、ユーザー/プロジェクト数という点でも、ペースという点でも、組織内で規模拡大するにつれて、現在何が起きているかを把握する能力は低下しがちです。SDMは、ソフトウェアデリバリーの規模拡大を可能にし、ソフトウェアデリバリーを積極的なフィードバックループに組み込みます。
いま企業は、ソフトウェアを通じてビジネス価値を生み出せるようになることの重要性をはっきりと理解しており、そのためにはさらに加速し、信頼性を高め、DevOpsとCI/CDに取り組む必要があることを知っています。－そしてここで間違いなくSDAが重要になってくるのです。SDAは小規模なチーム内でのPoC（コンセプト実証）に始まり、そこから拡大していきます。最初の成功に勢いを得て、組織全体に導入を広げ、成功が成功を生みます。年1回のリリースが四半期ごとのリリースになり、毎週のリリースになり、最先端を行くチームでは、変更をそのまま運用にプッシュする場合もあります。これは定期的に運用環境に公開するという、チーム単位で同期の取れたリリースではなく、常に複数の並行する変更の流れが任意の時点で運用環境にリリースされることを意味します。ここで一歩退いて、1つのチームだけでなく組織全体を視覚化してみましょう。すると、ばらばらの変更が左から右へ、右から左へ飛び交う嵐のような光景が目の前に展開され、現在の高度からでは嵐の全容を把握することはできません。いいニュースがあります。あなたはスピードを求め、加速を求めていたはずですが、それが手に入ったのです。いま、変更はありとあらゆる場所にあります。悪いニュースもあります。組織がいったい何をしているのか、まったく見通せない、あるいはまったく制御できないと感じているでしょう。心の平安は失われました。先端的なチームが最初に高速DevOpsのPoCを行った時には、何も問題はありませんでした。あなたはチームを信頼していました。彼らは組織でも最優秀のメンバーで、自分たちがどれだけ注目を集めているかを自覚し、組織にとって危険とならずに成果を出せるよう気をつけていました。でもいまは？ことは十人あまりの問題ではなく、何百人という開発者の問題で、何十というプロジェクトが常に変化し、何百というDevOpsツールがあるのです。この迷宮をどう管理すればよいのでしょうか？最適化すべき領域を見つけるにはどうすればよいのでしょうか？速度を妨げることなく、常にポリシーが順守されていることを保証するには、どうすればよいのでしょうか？どうすれば良くないニュースとして全国的に報じられるような事態を避けられるでしょうか？ここでSDMが視野に入ってきます。SDMは変更の大海を見下ろす鳥瞰的な視野を提供します。すべてのシグナルを捉え、単に記録システムに保存するのではなく、複数のチームがそれぞれ異なるシステムやツールを利用するのを踏まえて、データを統一的なDevOpsデータモデルとして正規化するため、後で個々のチーム固有の違いを気にすることなく、「組織を検索」できます。このようなデータをもってすれば、限界はありません。チームの生産性、複雑なチーム間のボトルネック、リリース日の予測、運用環境での特定のコードまたはライブラリの現在位置の解析など、知りたいことはいろいろあるでしょう。
データに基づいて、現在起きていることが従うべきルールや順守事項を満たしているかどうかをリアルタイムで検証することも可能になります。フロントエンドの銀行アプリケーションは、運用環境に公開する前に、特定のセキュリティチェックを受ける必要があります―いつどのようにか、あなたは気にしないかもしれませんが、必要はあります。リリースの前に一旦停止して、何が起きているかをチェックするというのは1つの方法です。これは現在のところ多くの企業がServiceNow/ITSMを利用して行っている方法です。しかしこれは、明らかにDevOpsのアンチパターンでもあります。それまであなたのチームは速度を上げるのに努力してきたのに、運用環境に入る前に、ゲートですべての変更を止めるのですか？安全だという確信を高めるために、ゲートでどんなことができると期待しているのでしょうか？SDMがあり、SDMが提供する鋭い目でシグナルを観察していれば、いつでもリアルタイムでポリシーが順守されているかを検証し、問題があればアクションを起こすことができます。リリースを止めることもあれば、過去七日間のあいだにセキュリティチェックが行われていれば、そのまま通すという判断をするかもしれませんし、アラートは上げるがリリースはブロックしないことにするかもしれません。重要なポイントは、せっかく苦労して達成した速度を落とすことなく、SDMの鋭い目でシグナルをリアルタイムで観察し、必要なときにだけ対処するという点です。これはまさに新時代に必要な劇的なパラダイムシフトです。
そしてSDMがもたらす理想的な境地は、ビジネス全体をソフトウェアデリバリー機能に結び付け、ソフトウェア価値創造の取り組みの影響を真に最大化できるというものです。 CloudBeesのビジョンの一節を思い出してください「…百万もの並行して走るクリエイティビティの流れを安全に、そして効果的にアイデアから価値まで進めるようにする」ここでキーワードとなるのが「価値」です。これは次のようなたとえで説明できます。
「もし森の中で木が倒れ、その音を聞く人がだれもいなかったら、音はしたのだろうか？」
同様に、ソフトウェアチームが世界最高の製品を作ったとしても、採用されず、ユーザーや顧客に製品の価値がきちんと理解されなければ、ソフトウェアは存在しないも同然かもしれません。
SDMはビジネス全体にわたるさまざまな職能間の壁を解消します―この点でも「受け入れる」のです。ソフトウェアデリバリーを中心として、あらゆるメンバーに可視性とコラボレーションの手段を提供し、より効率的にソフトウェアをデリバリーできるようにするだけでなく、有効性を高めます。すなわち、ソフトウェアと全体的なビジネス戦略や目標が一致し、あらゆる職能のチームがシームレスに協力して価値と影響の継続的改善を推進するのです。
私たちが「SDMはソフトウェアデリバリーをビジネスのコアプロセスにする」と言うのはこういう意味です。
私たちが話をお聞きする企業はどこでも、いま現在SDMを必要としているか、SDAを踏破したらSDMが必要になるだろうと認識しています。あらゆる企業は例外なく、複雑性を管理し、デリバリーを簡略化し、ソフトウェアを圧倒的なアドバンテージに変えるいっぽうで心の平安を得るためにSDMを必要とします。
CloudBeesは、SDMによってまったく新しい市場を打ち立てつつあります。この市場は、今日のCRMやERPと同様、自明のものとして受け入れられるでしょう。また、SDMは、これまでは非常に面倒だったり単純に不可能だった、より高いレベルでの管理に必要な洞察と価値を提供し、誰もが組織の中でいわば「前進」することを可能にします。
前へ！
Sacha