開発者としてのキャリアをスタートさせたときにまだ存在していなかった DevOps が、私のキャリアをどのように変化させたのか。

「DevOps とは何ですか？」というテーマのブログを書くように求められるときは、他の方とは異なるアプローチで執筆することにしています。このブログでは、テクノロジー業界で過ごした長年の経験に基づいて DevOps について定義したいと思います。プロフェッショナルとしての私の歩みにおける DevOps との関わりについて説明し、その関わりが私と私のキャリアにどのように影響したかをお話します。

90 年代

90 年代半ば、インターネットはまだ黎明期であり、現在ほど、あらゆるものがつながり合っていませんでした。多くの人が、大切な人の連絡先情報を手書きで記した小さな手帳を持ち歩いていました。また、多くの人が、折り返し電話を要求するために使用されるポケベル（別名ページャー）を持っていました。情報は、定期刊行物や書籍などの紙媒体でのみ普及していました。人は図書館を訪れ、書籍を読み、インデックスカードベースのカタログシステムで資料を検索し、雑誌、新聞、または書籍を実際に開いて、必要な情報を得ていました。これは、アナログ時代の揺るぎない手動のプロセスでした。

私は 1994 年に職業としてプログラミングを始めましたが、テクノロジーを取り巻く環境は今日とは明らかに異なっていました。多くの企業は、テクノロジーの価値を認めてはいたものの、投資や採用をためらっているという微妙な立場にいました。当時、サーバー、CPU、メモリ、ストレージは非常に高価でした。帯域幅は不足しており、制限されており、非常に高額でした。多くのソフトウェア開発および運用（SREまたはシステム管理）チームは、アプリケーションおよび管理インフラストラクチャを手動で、さらに重要なこととして、別々に、開発、テスト、およびリリースしていました。データセンターは、適切な電力供給、温度制御、配線を設計、構築、実装し、すべてを管理できる有能で熟練した担当者が常駐し、高価なインフラストラクチャハードウェアを設置する必要がありました。小規模なスタートアップ企業から巨大な企業まで、すべてが何らかの形の「データセンター」を利用していました。

当時の私のソフトウェア開発は次のような業務でした。

1. 個別にコードを記述する
2. 「新規保存…」の方法で、新しいコードのバージョンを作成する
3. 手動でコンパイルする
4. アプリケーションを手動でテストする（通常は、ポイントアンドクリック、サブミット、結果の検証というプロセスを繰り返していました）
5. コードレビューはほとんど行っていませんでした
6. デプロイ用のリリースパッケージを手動で作成する
7. パッケージのリリース/インストールノートを作成する
8. フロッピーディスク、CD、またはネットワークファイルの共有ディレクトリを介して、リリースパッケージを運用チームに提供する
9. 待ちぼうけ

新しいリリースの結果を待つには、4 時間から 10 日間がかかっていました。この時間の長さは、運用チームの忙しさと、新しいリリースをデプロイするオペレーターのスキルに依存していました。開発者と運用チーム間のコミュニケーションはほとんどありませんでした。実際、ほとんどの開発チームと運用チームは反目していました。チーム間ではソフトウェアの品質（テストされていない、またはテストカバレッジが不十分）に対する深い不満があり、本番環境へのソフトウェアのデプロイが迅速に行われないためにこのような敵対が発生していました。

キャリアを積むにつれて、開発チームと運用チーム間における不要な敵対を引き起こす要因について熟考する時間が増えていきました。熟練した技術があるスタッフがいるこれらの非常に有用なチームが、同じ目標とミッションを達成するために効率的で一貫して作業する方法を見つけられない理由を、私は理解できませんでした。開発チームと運用チームがまったく連携していないことは明らかでした。両方のチームには、ソフトウェアを本番環境にリリースするという 1 つの目標がありました。この目標以外について、問題を解決するために協力することに関心はありませんでした。このテクノロジーの時代には、開発者と運用者の関係は分断されており、悪影響を受けており、有害な文化が生まれていました。もちろん、これはすべてのチームや組織に当てはまるわけではありませんが、ここで説明したような悪しき文化の何らかの形で、ほとんどのチーム/組織に存在していたと思っています。

アジャイル

自分が取り組んでいた業務への姿勢、考え方、文化について簡単に理解してもらうために、自分のキャリアの早い段階におけるソフトウェア開発者としての経験を説明しました。当時の素晴らしい思い出を美しく描いているわけではないことは自分でも分かっています。まったく異なる経験をした方もいるかもしれませんが、私が経験したような機能不全について多くのチームも同感してくれるのではないでしょうか。

時間が経ち、テクノロジーが進化するにつれて、機能が向上した安価で高速なハードウェアと広い帯域幅が利用できるようになりました。また、開発チームは、ソフトウェアの開発方法を向上しました。開発チームは、プロセスを徹底的に分析し、ソフトウェア開発ライフサイクル（SDLC）のボトルネックを特定しました。また、ソフトウェア開発プロセスを変更し、チーム間のコミュニケーションを改善することにより、高品質なソフトウェアを迅速に提供できることに気付きました。多くのチームと組織が、アジャイルソフトウェア開発の概念 の採用と実践を開始しました。これにより、開発の問題を理解し、新しい方法論と戦略を生み出す新しい概念とアイデアを取り入れることができるようになりました。これらのアジャイル手法では、コラボレーション、顧客フィードバック、小規模で迅速なリリースを中心とした、反復的なアプローチが採用されています。

さまざまな開発チームや組織と一緒に数年間、アジャイルの原則を採用しながらソフトウェア開発の運用を成功させ、チームが以前よりもはるかに迅速にコードを生成していることに気付きました。開発者は、コード上でオープンに協力しあいました。そこでは複数のチーム間でコードを作成、変更、共有を可能にするバージョン管理システムが重要な役割を果たしました。時間の経過とともに、開発チームはさらにスマートに作業を進めることができるようになり、高品質のコードを作成する時間が劇的に短縮されました。コードは高速で記述、テスト、およびパッケージ化されていきました。開発チームはフル回転し、コードが高速で作成されていきましたが、予期しない問題が発生し悩まされることになりました。開発中の新しいコードは、作成されるようなペースでは迅速にリリースされなかったのです。これは、リリースまたはデプロイプロセスを十分に考慮することなく、ソフトウェア開発プロセスの改善にのみ注力していたためでした。そのため、顧客にリリースできていない新しいコードが溜まっており、開発者にとって非常に大きな問題となっていたのです。

DevOps との出会い

自分が書いたコードは、いつでも気にかけており、自分のコードを「誰が、どのように、何を、どこで」使用するのかについて非常に興味を持っていました。私は、この好奇心を満たすために、運用チームと良好な関係を築かなければならないことを分かっていました。キャリアの早い段階で、私は、開発チームと運用チームは共存関係にあることに気づいていましたが、他の開発者と運用担当者も、自分と同じ考え方を共有していると素朴に思っていたのです。しかし、現実にさらされたとき、私は閉口しました。これらのチーム間に「障壁」がある理由を本当に理解できませんでした。私はこれらの「障壁」は、開発チームと運用チームがそれぞれの帝国を作って守るための言い訳ではないかと考えるようになりました。また、これらの 2 つの組織の間にあったこの障壁が、イノベーションを抑制する大きな要因になっていると考えていました。この問題を認識してから、私は常に自分のことを「運用側よりの開発者」と呼ぶようになりましたが、これはなかなか言い得て妙であったのではないでしょうか。

運用チームとの基本的な連携機能が欠如していることによって、アジャイルの取り組みよって得られたすべての恩恵が完全に無に帰していることに気付いてからは、システム開発ライフサイクルに運用（ops）を組み込む新しい戦略を作り上げるために、チームを結成しました。このときにはまだ、DevOps という用語はありませんでしたが、この言葉に宿る精神は、そのときに、アジャイルを採用および実践した開発チームの中に確実に存在していました。多くの「アジャイル」チームは、同じように困難な状況下に置かれていました。開発チームは、ソフトウェアを迅速に開発するようになっており、実際にコードを本番環境にリリースするときに大きな障壁に直面していました。

開発者の何人かの同僚は、運用チームとの私が良好な関係を気づいており、その関係を活かして、両方のチーム間の橋渡しをするように提案しました。私は、自分に災いが降りかかること、折角運用チームと築いてきた関係を危険にさらすことを若干懸念していました。開発チームの権力闘争と誤解される恐れのあるアイデアによって、関係を傷つけたくありませんでした。そのため、この急進的なアイデアによって運用チームにアプローチする方法について、長い間懸命に考えました。頭の中で何度も会話をリハーサルしたことを覚えています。そして、対話の準備ができたと思ったときに、運用チームとの打ち合わせをスケジュールしました。不安は、打ち合わせの日が近づくにつれて大きくなっていきました。

ついに、その日にやってきました。私は、自ら作った台本（何度もリハーサルした）に基づいて会話を始めました。本当に驚いたのですが、運用チームのマネージャーは、私に話をやめるように言った後で、運用チームが開発チームと同じスピード感で歩調を合わせるためにはどうしたらよいのかと質問してきたのです。このマネージャーは、開発チームが調整、品質、速度を向上し、成功を収めていることを、運用チームは見てきたことを説明しました。彼は、また、運用チームが、現在のプロセスがソフトウェアリリースを高速化するための大きな障害になっていることを認識していることも伝えてきました。これが運用チームの立場であり、運用チームは開発と運用のプロセスの両方を改善するために開発チームと喜んで協力したいと聞いて、私は本当に大喜びしました。

そして、単純でも簡単でもない「障壁を打ち破るため」のジャーニーに取り組むことになったのです。両チームが理解して受け入れることができるリーンアジャイル戦略を考案することが、私たちが克服しなければならなかった最大の障害だった記憶があります。開発チームはすでにアジャイルを取り入れており、アジャイル文化にシフトしていたため、開発チームが運用チームに提案をするときに、ある意味で上から目線だったのかもしれません。開発チームの自信は、利己的と認識されました。この状況と、人の敏感性を考慮し、聞き手の心を閉ざしてしまうような偽善者なトーンを最小限に抑える方法で、お互いの問題を解決するために役立つコミュニケーション戦略を迅速に磨きました。チーム間のコミュニケーションのレベルを上げることは、壁を打開するときの最も大きな課題だと感じました。コミュニケーションの問題を改善する方法を取り入れた後には、開発チームと運用チーム全体は、別の部門として、そして単一の部門としても機能できるようになり、ソフトウェアデリバリの業務を同期化することができました。

時が経つにつれて、開発チームと運用チームのインタラクションが改善され、最終的には、過去にあった機能不全が解消されました。チームはお互いに信頼し合うようになり、極めて高い効率化を実現できました。開発者は、開発プロセスとスタックのパラダイムに関連する詳細について運用担当者を教育するようになりました。運用担当者は、開発者にリリースのプロセスとインフラストラクチャのメンテナンスにおけるチームの役割について詳しく教育していました。これらのチームの統合に向けた変更は、一度に行われたわけではありません。時の経過とともに変化が進んでいきました。文化の変化が成功した理由は、双方のチームが同じように努力し、試行錯誤を繰り返して、向上するための方法を学んでいったことです。私たちのチームは、コミュニケーションと透明性がもたらす利点を学びました。それにより、各部門の役割と、部門がプロセス全体にどのように影響しているのかを明確に把握することができたのです。

DevOps とは何か？

「DevOps」という用語が生まれる前に、私たちのチーム間では真の DevOps 文化が生まれていました。数年後、DevOps という用語を初めて聞いた後、瞬間的に、それが何を意味するのかわかりました。DevOps という言葉は、我々が成し得たことを言い表す最適な言葉でした。

では、DevOps の私の定義を読者の皆さんにもお伝えします。

DevOps とは…

• コンセプトである
• マインドセットである
• 個人が理解し、受け入れる共通した姿勢である
• 育成し繰り返し改善する必要がある文化である
• 共有することである
• メンタリングすることである
• 学習することである
• インクルーシブであらゆるアイデアにオープンなことである
• 反復的である
• 継続的である
• コラボレーティブである
• 自信を持ってソフトウェアを開発およびデリバリするための素晴らしい方法である

DevOps とは…

• 簡単に達成または実装できることではない
• 製品またはツールチェーンのひとつではない
• 役職や役割のひとつではない
• ひとつのクラウドインフラストラクチャプロバイダーではない
• ひとつの書籍ではない
• ひとつのテクノロジーではない
• ひとつのプログラミング言語ではない
• ひとつのマーケティングキャンペーンではない
• CI/CDではない
• Kubernetesではない
• コンテナではない
• オープンソースソフトウェアではない
• コードとしてのインフラストラクチャではない
• オートメーションではない
• 軽々しく扱えるものではない！

結論

最初に述べたように、自分の数十年に及ぶ経験に基づいて、DevOps についての自分の見解を紹介しました。私の過去の経験を読んでいただいたことで、新しい視点で DevOps を捉えることでき、DevOps の必要性と DevOps が組織にもたらす価値を知っていただく一助となることを願っています。自分の経験を思い出し、それを皆さんと共有することができ本当に楽しかったです。

最後まで読んでいただき、ありがとうございました。