DevOpsって何？

Tweet

DevOpsとは「Development(開発)」と「Operation(運用)」を組み合わせた造語です。

DevOpsの目的

DevOpsの目的は、ソフトウェアの開発から運用までの流れをスムーズにし、品質やスピードを向上させることです。

DevOpsを超ざっくり言うと

DevOps（デブオプス）は、「開発」と「運用」のチームが仲良く協力して、ソフトウェアを素早く、そして安全にユーザーに届けるためのやり方です。ITにおける開発と運用のDXです。要するに開発からリリース、運用を自動化出来るよという当たり前の話をカッコつけて言っているだけです。

1. 作ってすぐ届ける
   普通、開発（作る）と運用（届ける）は別のチームだけど、DevOpsでは一緒に動きます。作ったらすぐ届ける！みたいな感じです。

2. 自動でやる
   人が全部手作業でやるとミスが多くなるから、自動でやっちゃいます。プログラムが「テストしとくよ〜」「サーバーに置いとくよ〜」って勝手にやってくれる感じ。

3. 問題をすぐ見つける
   作ったソフトがちゃんと動いているかを監視して、問題があったらすぐ分かるようにします。なので、すぐ直せる！

なんでDevOpsがいいの？

• 速く届けられる
  お客さんに素早く新しい機能や修正を届けられるから、「あれも直して！これも追加して！」がすぐにできます。

• ミスが少なくなる
  自動でやるから、手作業でミスするリスクが減ります。

• 開発と運用が仲良くなる
  チームが協力するので、「こっちの仕事じゃない」とか言わずにサクサク進むようになります。

DevOpsは「みんなで協力して、良いものを早く作ってすぐに届けよう！」っていう働き方ですね。

DevOpsの特徴

DevOpsでは、開発チームと運用チームが密に連携し、以下のようなプロセスやツールを活用します。

1. 継続的インテグレーション（CI）
   開発者がコードを頻繁に統合し、バグを早期に発見できるようにする手法です。CIツール（JenkinsやGitLab CIなど）を使って、自動的にテストやビルドを行います。

2. 継続的デリバリー（CD）
   コードが本番環境に自動でデプロイされる仕組みです。これにより、コードの変更が安全かつ迅速にユーザーに届けられます。

3. 自動化
   インフラ構成、テスト、デプロイの自動化により、手作業を減らし、エラーを防ぎます。AnsibleやTerraform、Dockerなどがよく使われます。

4. 監視とフィードバック
   システムのパフォーマンスやエラーをリアルタイムで監視し、フィードバックを得て改善を続けます。監視ツール（PrometheusやDatadogなど）を活用し、障害の早期発見と対応を行います。

DevOpsを導入することで、開発サイクルが短縮され、リリースがスピーディかつ安定的になり、最終的にユーザーの満足度向上が期待できます。また、開発者と運用者の協力体制が強化されるため、プロジェクト全体の透明性も増します。

DevOpsをやっているチームとやっていないチームの比較

DevOpsを取り入れているチームと、取り入れていないチームを比較すると、次のような違いがあります。

1. リリースのスピード

• DevOpsチーム：コードを書いてから本番に反映するまでの流れがスムーズです。頻繁に少量の変更をリリースするため、ユーザーに素早く新機能を届けられます。
• 非DevOpsチーム：大きなリリースが少ない頻度で行われ、1回の変更でたくさんのコードがまとめられがち。そのためリリースに時間がかかり、ユーザーに届けるまでのスピードが遅くなります。

2. エラーの発見と修正

• DevOpsチーム：テストやデプロイが自動化されているため、エラーがあれば早期に発見し、迅速に修正できます。また、監視ツールでリアルタイムにシステムを監視しているため、問題が発生するとすぐに対処できます。
• 非DevOpsチーム：手動でテストやデプロイを行うため、エラーの発見が遅れることが多いです。エラーが見つかった場合でも、修正に時間がかかり、対処が遅れることがあります。

3. チーム間のコミュニケーション

• DevOpsチーム：開発と運用が密に連携しているため、情報共有や意思疎通がしやすくなり、問題があればすぐに相談できる環境が整っています。そのため、チーム間での対立が少なく、協力してプロジェクトを進められます。
• 非DevOpsチーム：開発と運用が別々に活動していることが多いため、互いの状況を理解しにくく、情報の伝達ミスや認識のズレが起きやすいです。「開発チームが作ったものが運用でうまく動かない」「運用の要望が開発に伝わらない」といった問題が発生することがあります。

4. 品質の安定性

• DevOpsチーム：継続的なテストやデプロイで品質を確保しやすく、プロダクトの安定性が高まります。リリース前に問題が見つかれば、その場で対応することができます。
• 非DevOpsチーム：大規模なリリースごとにテストを行うため、変更量が多く、一度のミスが大きな問題を引き起こすリスクがあります。また、テストが行き届かない場合、リリース後に予期せぬ不具合が発生しやすくなります。

5. 改善とフィードバックのサイクル

• DevOpsチーム：ユーザーのフィードバックや、運用中に見つかった改善点を素早く反映し、プロダクトを常に改善できます。「継続的インテグレーション（CI）」と「継続的デリバリー（CD）」を使うことで、短いサイクルでの改善が可能です。
• 非DevOpsチーム：大規模なリリースの間隔が長いため、フィードバックを反映するまでに時間がかかります。改善のサイクルが長いため、ユーザーのニーズや環境変化に対応しづらくなります。

6. チームの柔軟性とモチベーション

• DevOpsチーム：チームメンバーが一体となって働き、業務の自動化により単調な作業が減り、クリエイティブな部分に集中できます。また、自分たちが作ったものをすぐに見届けられるため、モチベーションが高まりやすいです。
• 非DevOpsチーム：チームが分断され、運用担当者は単調な保守作業が増え、開発担当者はユーザーに届けるまでの遅さにやきもきすることが多いです。そのため、メンバー間の摩擦や不満が溜まりやすく、モチベーションも下がりやすいです。

まとめ

DevOpsを導入しているチームは、リリースが速く、エラーが少なく、チームの連携も良いのが特徴です。一方、DevOpsをやっていないチームは、リリースやエラー対応に時間がかかり、チーム間のコミュニケーションにも課題が出やすい傾向があります。

DevOpsはみんなやるべきか？

DevOpsは、すべてのチームが必ずしも「やるべき」というわけではなく、プロジェクトの規模やチームの特性によって向き不向きがあるのが現実です。導入することで得られるメリットは大きいですが、必ずしも全てのチームにとって最適な選択肢とは限りません。

DevOpsが向いているチーム・プロジェクト

• スピードが求められるプロジェクト：頻繁にリリースや変更が必要なプロジェクト（例：Webサービスやモバイルアプリなど）では、DevOpsのメリットが最大限発揮されます。
• 長期的な改善が求められるプロジェクト：リリースを重ねながら少しずつ改良していく場合、ユーザーのフィードバックをすぐに反映できるDevOpsは非常に効果的です。
• エラーやダウンタイムが致命的なシステム：金融や医療など、システムの信頼性が極めて重要な場面では、DevOpsの自動テストや監視が役立ちます。

DevOpsが向いていないチーム・プロジェクト

• 小規模で変化が少ないプロジェクト：開発頻度が低く、変更が少ないプロジェクトでは、DevOpsのメリットはあまり得られません。設定やツールの導入コストが無駄になる可能性があります。
• リリースの頻度が低いケース：年に数回程度しかリリースしないプロジェクトでは、DevOpsの仕組みを整える手間がかえって負担になる場合があります。
• 大規模なシステムの初期開発段階：プロジェクトの初期段階では、大量の変更や試行錯誤が発生するため、最初から自動化を目指すと、かえって開発が滞ることもあります。

DevOpsを検討する際のポイント

• チームのスキルレベル：DevOpsにはツールの知識や自動化スクリプト作成が求められます。チームメンバーがDevOpsの基本スキルを持っているかどうか、またそのスキルを育成できるかも重要です。
• プロジェクトのコストとリソース：自動化や監視ツールの導入には初期費用がかかり、維持管理にもリソースが必要です。コストに見合った効果が得られるかを見極める必要があります。
• 文化や風土：DevOpsは「開発」と「運用」が密接に協力する文化を伴います。分業がしっかりしている企業では、その文化変革自体に時間と労力が必要になるかもしれません。

まとめ

DevOpsは全員にとって必ずしも「やるべき」ではないですが、必要とするプロジェクトにとっては非常に効果的な手法です。導入する際にはプロジェクトの特性やコスト、チームの状況をよく検討し、徐々に導入を進めることでDevOpsのメリットを最大化できるでしょう。

銀行などで使うミッションクリティカルな製品でのDevOpsの立ち位置

銀行などのミッションクリティカルなシステムでも、DevOpsは一定の条件で導入する価値がありますが、通常のDevOpsと比較して特に慎重で高度な設計が求められるのが特徴です。ミッションクリティカルな製品は、システムが止まることが大きな損害やリスクにつながるため、単に素早いリリースを目指すDevOpsではなく、信頼性やセキュリティを最優先にしたDevOpsが必要です。

ミッションクリティカルなシステムにおけるDevOpsのメリット

1. 迅速なセキュリティ更新とバグ修正
   銀行のシステムでは脆弱性の発見が即座に対処されることが重要です。DevOpsの自動化プロセスにより、セキュリティパッチやバグ修正を迅速に本番環境に反映でき、リスクを早期に排除できます。

2. 高い品質管理
   継続的インテグレーション（CI）や継続的デリバリー（CD）を活用することで、頻繁なテストが可能になります。ミッションクリティカルなシステムでは、厳密なテストと品質管理が求められるため、CI/CDの導入によりリリース前に細かい不具合を排除し、安定性を高められます。

3. 迅速なフィードバックサイクル
   顧客のフィードバックやシステムの使用データを活用し、問題を早期発見・対処する体制が整います。リアルタイムの監視とアラートで、システムのパフォーマンスが常に最適に保たれるため、サービスの安定性を維持できます。

注意点と制約

ミッションクリティカルなシステムでは、通常のDevOpsとは異なる高度なセキュリティと信頼性が求められます。具体的には以下の点で通常のDevOps手法が修正されることが多いです：

1. 本番環境へのリリース管理
   ミッションクリティカルな環境では、変更がリスクになるため、CI/CDパイプラインを通しても自動で本番環境にデプロイすることは少なく、「継続的デリバリー」までを自動化し、「デプロイ」は慎重な管理下で手動で行う場合が多いです。

2. 厳密なセキュリティ対策
   DevOpsのプロセスにも厳格なセキュリティチェックを組み込む必要があります。たとえば、脆弱性スキャン、暗号化管理、セキュリティポリシーの遵守などを自動テストに組み込みます。また、アクセス管理や権限設定も強化する必要があります。

3. テストの充実度
   銀行システムでは、障害が起きた際の被害が大きいため、単なる機能テストではなく、災害復旧テストや負荷テスト、セキュリティテストもDevOpsプロセスに組み込むことが求められます。すべての変更が影響を与えないかを厳密にテストするため、通常のDevOpsと比較してテスト体制が強化される傾向にあります。

4. 監視と対応の自動化
   ミッションクリティカルな環境では、問題の早期発見が非常に重要です。DevOpsの一環として監視システムを導入し、問題が発生した際には自動でアラートが出されると同時に、修復やバックアップの開始が自動化されているとより安全です。

ミッションクリティカルな環境でのDevOps導入まとめ

銀行のようなミッションクリティカルな環境では、通常のDevOpsの「スピード」を重視するのではなく、「信頼性・セキュリティを担保しつつ、素早く対応する」という方針が最も重要です。DevOpsの持つメリットを活かしつつ、銀行業界の高度なセキュリティ・信頼性要件に適合するようカスタマイズすることで、安定した運用と継続的な改善が実現可能になります。

DevOpsはWEBアプリやモバイルアプリなど簡単なものにしか適用できない？

DevOpsの手法はWebアプリやモバイルアプリのような頻繁なリリースやユーザーフィードバックが求められる分野で特に効果を発揮する傾向があります。しかし、必ずしもこれだけに限定されるわけではなく、DevOpsは適切に運用すれば大規模なシステムや機能開発でも機能します。ただし、大規模開発におけるDevOps運用にはいくつかの工夫が必要です。

1. 大規模機能開発でのDevOps運用の課題と解決策

• 頻繁なリリースと安定性のバランス
  大規模機能開発では、各機能が複雑に関連しているため、DevOpsの頻繁なリリースが逆に混乱を招く可能性があります。この場合、「段階的リリース」や「機能フラグ」を活用して、機能を開発段階で細分化し、完成した部分から少しずつリリースしていくのが効果的です。特に大きなシステムでは、全機能を一気に公開するのではなく、機能単位でのリリースを行うことで、リリースごとの影響を最小限に抑えられます。

• 統合テストと品質管理
  大規模開発では、リリース前に多くの統合テストが必要で、これに時間がかかることがDevOps導入の障害となることもあります。解決策として、開発を「マイクロサービス」に分割することで、個々の機能を独立してテストできるようにすると、DevOpsの効果を維持しつつ品質も確保できます。また、テスト環境の自動化やシミュレーション環境の整備でテスト時間を短縮することも可能です。

2. 大規模な既存システムへのDevOps適用

• レガシーシステムの技術的負債管理
  特に大規模な既存システムでは、複雑な構造や技術的負債が障害になる場合があります。DevOpsの導入時に技術的負債の解消を段階的に行うか、特定部分のみをDevOpsのプロセスに移行し、徐々に拡大するアプローチが効果的です。

• チーム間の調整
  DevOpsでは、開発と運用が密に連携することが前提ですが、チームが多くの役割に分かれている大規模組織では、すべてをDevOpsに統一するのが難しい場合があります。この場合、まず小規模な機能や部門からDevOpsを試行し、成功事例を基に他チームへの展開を進めるといった段階的導入が現実的です。

3. ミッションクリティカルでのDevOps運用の拡張方法

銀行などの大規模システムの新機能開発では、リリースが慎重に管理される必要があります。そのため、「すべての変更が自動で本番に反映される」という一般的なDevOpsの方法とは異なり、以下のような工夫が必要です：

• フェーズごとのリリース制御：リリースを段階的に進め、あるフェーズごとにリリース検証を行うことで、DevOpsの柔軟性を保ちながらも高い信頼性を確保します。
• デプロイのトリガーを明確に管理：本番環境へのデプロイは、ステージング環境での全テストがクリアされたタイミングで手動または慎重な承認を経て行うなど、クリティカルな部分は一部手動にすることで安定性を保ちます。

まとめ

DevOpsは、Webやモバイルアプリのようなスピーディーな開発に非常に向いていますが、大規模なシステムやミッションクリティカルな開発でも、適切に設計・運用すれば十分に機能します。特に大規模開発では、従来のDevOpsの「自動でスピーディーに」の部分を必要に応じて調整し、信頼性を重視した運用が求められます。このように、プロジェクトに応じてDevOpsを柔軟に取り入れることで、そのメリットを最大限に引き出すことができます。

誰でもDevOpsは導入できる？

ミッションクリティカルな分野にDevOpsを適用するには、かなり高度なスキルが求められます。一般的なDevOpsの知識や経験だけでは十分ではなく、信頼性、セキュリティ、リスク管理の観点から深く理解し、実装できるエンジニアが必要です。言い換えれば、ミッションクリティカルな分野におけるDevOpsには「アホなエンジニア」では難しいでしょう。

ミッションクリティカルなDevOpsに求められるスキルと知識

1. 高いセキュリティ知識
   金融や医療などのシステムでは、セキュリティリスクが非常に大きく、脆弱性対策や権限管理、データの暗号化などの高度な知識が不可欠です。たとえば、CI/CDの自動化プロセス内で脆弱性スキャンやセキュリティチェックを組み込むといった対応が求められます。ここで間違いがあるとシステム全体が危険にさらされるため、セキュリティの深い知識と実践経験が必要です。

2. インフラストラクチャの信頼性と耐障害性設計
   ミッションクリティカルなシステムでは、システムがダウンすること自体が許されません。したがって、冗長性（リダンダンシー）やフォールトトレランス、フェールオーバー構成、災害復旧の仕組みを組み込む設計が必須です。これには、クラウドインフラやオンプレミスのネットワーク知識、さらには負荷テストや障害シナリオの設計能力も含まれます。

3. 大規模システムのアーキテクチャ設計
   大規模なミッションクリティカルシステムでは、DevOpsのプロセスにそのまま乗せるだけでなく、スケーラビリティやスピードだけでなく、堅牢性を重視したアーキテクチャ設計が求められます。マイクロサービス、コンテナ化、サービスメッシュといった分散システムの構成、またそのための監視・ログ管理の技術が求められるでしょう。

4. リスクマネジメントとエスカレーション
   DevOpsは自動化が基本ですが、ミッションクリティカルなシステムではすべてを自動で進めるのではなく、リスクに応じて人間による承認プロセスや、特定の手動操作が必要な場面も発生します。この際、リスク管理の視点から緊急時にどうエスカレーションするか、またどのように安全に変更を適用するかといった判断力が必要です。

5. 深いモニタリングとアラート設定の経験
   DevOpsの一環として監視が自動化されていても、問題が起きた場合の早期発見とその影響範囲を迅速に把握するには、高度なモニタリングとアラート設計が必要です。システムの各部分の正常性を確認し、異常があれば即座に対応できるような設計は、一般的なエンジニアの監視設定とは一線を画します。
   たとえば、ログの異常検出をリアルタイムで行うためにAIベースの監視ツールを導入するなど、通常以上の監視システムが求められる場面もあります。

ミッションクリティカルなDevOpsにおける人材確保のポイント

• エキスパートとプロセスガイドの配置：チーム内に高スキルのエンジニアを配置し、彼らが全体のプロセスや安全基準を構築・管理することで、他のエンジニアが段階的にスキルアップできる環境を整えるのも有効です。
• 継続的なトレーニングとドリル：運用エンジニア全員が障害発生時に冷静に対処できるよう、障害発生シミュレーションや定期的なトレーニングが必要です。
• 外部パートナーとの協力：ミッションクリティカルシステム向けのDevOpsノウハウを持つ外部の専門家やベンダーの支援を受けることで、運用の最適化が図れます。

まとめ

ミッションクリティカルなシステムにDevOpsを適用するのは、通常のシステム運用とは一線を画し、高度な専門知識と実務経験を持ったエンジニアによる綿密な設計と運用が必要です。このような場面でDevOpsを導入するためには、高いスキルを持ったエンジニアチームとともに、リスク管理を重視したプロセス設計が欠かせません。

DevOpsをやれとイキりエンジニアが言ってきたら

以下のドキュメントを提出させましょう。書けない場合は任せてはいけません。どこかで聞きかじったことを偉そうに言っているだけです。

DevOps導入を主張するのであれば、そのエンジニアには導入の目的、期待される効果、リスク、具体的な計画を明確にし、他のメンバーが納得できる内容で提案書を作成させるのが良いでしょう。以下のような構成のドキュメントを提出させると、適切な検討が促されます。

1. 導入背景と目的

• 現状の課題：現在の開発や運用における具体的な課題を説明させます（例：リリースの遅延、テストの手間、エラーの対応速度など）。
• 導入目的：DevOps導入によって具体的に何を改善したいのかを明確にさせます。目的が曖昧だと、単なる「流行っているから」導入することになりかねません。

2. 期待される効果・メリット

• 開発速度：リリースサイクルの短縮や、開発チーム・運用チームの協力体制による効率化など、具体的な改善点をリスト化します。
• 品質向上：継続的インテグレーション（CI）や自動テストの導入によるバグの早期発見や、品質向上への貢献を説明させます。
• コスト削減：自動化による人的コストの削減や、迅速なバグ修正による障害対応の軽減などを示させます。

3. 具体的なDevOps導入計画

• ステップごとの実行計画：段階的に導入を進めるためのスケジュールを作成させます。たとえば、最初にCIを導入し、次に自動デプロイ（CD）を設定するなど、フェーズごとに計画させると現実的です。
• 導入範囲：どのシステムやどのプロジェクトからDevOpsを導入するのかを明確にさせます。全体に一気に導入するのではなく、影響範囲が少ないプロジェクトから進める計画も含めます。
• 必要なツール・インフラ：提案している内容に必要なツール（例：Jenkins、Docker、Terraformなど）やインフラをリスト化させます。また、それらのツールの知識やスキルがチーム内にあるか、もしくは学習が必要かを検討させます。

4. リスクとその対策

• 導入時のリスク：DevOps導入には移行中の業務負担増や、初期の混乱などが予想されます。例えば、ツール選定や学習コスト、既存システムとの適合性などをリストアップさせます。
• セキュリティリスク：特にミッションクリティカルなシステムの場合、セキュリティや権限管理の観点からのリスクも十分に検討させます。
• リスク軽減策：リスクに対してどのような対応策を講じるのか、具体的な対策も記述させます。

5. 費用とリソース計画

• 導入コスト：ツールやインフラの導入にかかる初期費用と、運用コストを具体的に試算させます。
• 人的リソース：どのリソースがどれくらい必要か、また既存チームで対応できるのか、外部パートナーを必要とするのかなど、リソースの計画を立てさせます。
• ROI（投資対効果）：導入することによって、どのような形で効率化やコスト削減が図れるのか、またその効果がどれくらいで実感できるのかも記述させます。

6. KPIと成功指標

• 評価基準：DevOps導入が成功しているかどうかを判断するための指標を設定させます。たとえば、リリースサイクルの短縮率、エラー発生率の低下、テストカバレッジの向上などのKPI（重要業績評価指標）を具体的に明示させます。
• レビューと改善サイクル：定期的にレビューを行い、DevOpsプロセスを改善していく計画を記述させます。

7. ケーススタディ・導入事例の調査

• 他の企業や競合がDevOps導入に成功している事例をリサーチさせ、自社にどのように応用できるかを考えさせます。単なる成功事例の紹介ではなく、どういった条件で成功し、自社ではどう応用するかまで明確にさせます。

8. 結論・まとめ

• 導入するかどうかの判断材料：これまでの内容を基に、導入が適切かどうか、具体的な判断材料と結論を記載させます。

この提案書を作成させることで、エンジニアがDevOps導入の影響やリスク、必要なリソースを具体的に検討する機会になります。また、提案内容に基づいて他のメンバーが意見を出し合えるため、導入の是非を適切に判断できるでしょう。