Thank you for submitting your request.
We will get back to you shortly.
START A CONVERSATION
Share your requirements and we'll get back to you with how we can help.
企業のDevOps変革を後押し
技術が絶えず進歩している業界において、組織の成功はITアジリティの備えがあるかにかかっています。当社はDevOpsコンサルティング企業として、お客様のビジネスがクラウド・ネイティブ技術や自動化、継続的デリバリーに順応し、機敏性を保てるよう支援します。こうした技術の導入はスタートアップにとっては容易かも知れませんが、従来型の企業の場合はより綿密な計画の策定が必要です。
従来型のビジネスは、元々独立した部署が各々（改革や安定などの）異なる目的を持った状態で機能するため、目まぐるしく変化するビジネス環境に適応する能力に欠ける、という問題がありました。DevOps変革では、このサイロ化アプローチからシングルバリューストリームへと転換し、段階的な改良を通じて顧客、デザイン、プロダクション及びデリバリーを繋げていくことを目指します。これには組織構造、組織文化、技術スタック面での革新が求められます。
DevOpsコンサルティング
当社DevOpsコンサルタントがお客様の組織でどのような変化が求められているのかを特定するお手伝いをいたします。レディネス評価を行って、変革を始動させましょう。
バリューストリームの特定とマッピング
多くの企業がイノベーションを支えるための開発ベロシティを加速させる必要性があると認識しています。また、品質や信頼性、セキュリティを損なうことなくアジリティを確立させる上で、旧来のプラクティスやプロセスを変える必要があるということも理解しています。そんな企業がつまづくのが、どこからどのように始めれば良いのかの見極めです。そこで当社のコンサルタントがこの難関突破をお手伝いいたします。
当社のDevOpsアーキテクトは、お客様のチームとの連携や経営陣からの知見をもとに、お客様の組織におけるプロセスと各ステージでのアクティビティを把握します。そして価値を高めるステップ、そうでないステップを特定します。このような現状を反映したバリューストリームマッピングを行うことで、お客様のプロセスにおける重要なステップ、さらに最適化する上で改善が求められる点を系統的に可視化します。
バリューストリームを通じたワークフローの改善
バリューストリームの現状を把握することで、ストリームを通じたワークフロー改善のために無駄を洗い出し、それらを軽減または排除する方法の特定が容易になります。その後、当社で将来像設計のお手伝いをし、あらゆる面で可能な限り自動化させ、短時間で高品質なソフトウェアの展開を実現します。
バリューストリームマッピング（VSM）アクティビティを完了した企業の多くは、Kanbanのような技術を利用することでワークフローを管理、最適化しています。ワークフローの見える化を行うことで、プロセス全体の一貫した全体像が可視化され、最終成果物に対する各チームの貢献度がクリアに見えてくるのです。
ソフトウェア開発バリューストリームを通じたワークフローの改善ステップ
- 業務の見える化をする（例: Kanbanボードを活用）
- 仕掛品を減らす/制限する
- チーム間のハンドオフ回数を減らす
- ビルド、テスト、セキュリティチェックおよびデプロイを自動化する
- 小ロットでリリースする
- 早期フィードバックを提供する
チームの編成
DevOps変革をする中で、組織のチームを共通の目標・プロセス・ツールに合わせて再編成する必要が出てくることがあります。開発チームと運用チームは機敏性に優れた一つのチームとして価値を提供するために、協働することが求められます。これはチームとして十分な権限を持ち、自立した機能横断型チームを設けることで実現可能です。こうしたチームは、時間制限のあるプロジェクトがある際に一時的に異なる部署から人材を集めて編成することもできます。こうしてハンドオフが少なくなることで、チームがより効率的に動ける様になるのです。。
システムエンジニアがコードを書き、デベロッパーがアプリケーションの展開や拡張に関わるインフラについて深い知識を持つ完全に自立したチームの実現は容易ではありません。そこで、開発チームと運用チーム間の緊密な連携に基づいたモデルを採用してみるのも良いでしょう。このモデルにおいて両チームは、計画立案から本番環境での継続的な監視の段階にかけて協働し、責任を分担することが望ましいでしょう。
あるいは、DevOps専門チームを設けて、バージョン管理、継続的インテグレーション、デプロイの自動化といった課題に共有サービスをもって対処するという選択肢もあります。これは一種の職能別組織であるゆえ、構造上の落とし穴に陥らないよう注意する必要があります。
また、一定の変更を行った上で、既存の組織構造（職能別/事業部制/マトリクス）を維持できる場合もあります。当社のDevOpsコンサルタントなら、利用可能なリソースやチーム間の関係性、現在の組織構造の柔軟さ等を考慮した上、お客様に最適な選択をするサポートをいたします。
どの組織モデルを実装する場合についても、チームにおいて重要な特徴が次の通りです。
- ビジョンと目標の共有、ソリューション目線
- 価値を段階的に提供する力
- 質の高い技巧と誇り
- 明瞭な説明責任とフラット組織
- オープンなコミュニケーションと継続的な改善
DevOps変革のための技術スタック
適したチーム選び、オープンで誠実な連携の文化形成の次にDevOps変革に重要となるステップは、ビルド、テスト、デプロイ、インフラ、その他可能な範囲でのプロセスの自動化です。
継続的インテグレーション（CI）
デベロッパーの作業成果物をを早い段階で高頻度で共有リポジトリに統合することで、バグを早期に発見し、すばやく解決につなげることができます。通常業務の一環として小ロットでの統合を行えば、ソフトウェアを高頻度でデリバリーできるようになるのです。ここでデベロッパーが頻繫なコード変更をメインリポジトリにコミットするのに活用できるバージョン管理ツールは多数あります。継続的インテグレーションサーバーはコード変更のバージョン管理システムのポーリング、最新コードの読込、さらにビルドを行います。
自動化テスト
継続的インテグレーションの環境が整ったら、次は自動化テストです。それぞれのコードコミットはビルドスクリプトに統合され、自動化テストで検証されます。テストが自動化されていない場合、開発ベロシティがどれだけ加速化してもリリースサイクルは遅いまま、ということになりかねません。
ユニットテスト、受け入れテスト、統合テスト、さらには性能テストやセキュリティテストといった非機能テストまでも自動化することができます。ユニットテストと受け入れテストは並行して稼働するようにも設定できます。当社で非機能テストを自動化するために使うツールは JMeter、NeoLoad、、Browsera等です。
デベロッパーワークステーションそのものにいくつかの自動化テストを構成することで、デベロッパーが自分の作業へのフィードバックをより速く受け取ることができます。例えば、RubyデベロッパーがFoodcriticからコード構造や構文に対するフィードバックを得ると同時に、Sonarlintがテスト自動化エンジニアが書いたSeleniumテストの解析をすることが可能になるのです。
ここで重要なのはテストの信頼性を確実なものにすることです。誤判定は自動化テストが解決する以上の問題を引き起こす可能性があるからです。当社では、一連の小規模で信頼性の高い自動化テストから入り、時間をかけてその対象を広げていくことを推奨しています。
インフラのセットアップ
ソフトウェアのビルドを自動化することができたら、次は環境（開発/テスト、ステージング、本番）のプロビジョニングと運用を自動化していきましょう。最新のプロビジョニング・構成管理ツールを利用すると、プログラムコードに従った環境設定とシステム構成の管理が可能になります（インフラ・アズ・ア・コード）。
構成ドリフトを発生させない一貫性のある信頼できるインフラをお探しなら、一度デプロイしたらサーバーの変更が無いイミュータブル・インフラモデルをおすすめします。このアプローチで変更が必要になると、適切な更新が行われた新規サーバーを割り当てて既存のものと置き換えます。
インフラ設定がコードに書き起こされている場合、バージョン管理システムと自動化テストを用いて環境プロビジョニングを行い、アプリケーションコードに使われるCI/CDパイプラインに統合することが可能です。Foodcritic for Chefやpuppet-lint for Puppetといったツールは環境構築に用いられたコードの分析に活用できます。こうしたプラクティスやセキュリティハードニングチェックを一連の自動化テストに加えても良いでしょう。
コンテナ化
組織によってはインフラ・アズ・ア・コードとコンテナを組み合わせることも良いでしょう。これにより、アプリケーション環境からインフラ要件を切り離すことができるようになります。
コンテナは運用システムの構成要素（言語ランタイム、ライブラリ、システムファイル）をアプリケーションと結合させます。こうした構成要素はホスト環境を変えずに変更を加えることが可能であり、よって毎回特定の開発環境をセットアップする必要がありません。またコンテナは簡単に環境の複製ができ、仮想マシンに比べて軽量です。
デプロイメント・パイプライン
継続的インテグレーションと自動化テストの設定ができたら、デプロイメント・パイプライン構築に進んでいきます。このパイプラインではあらゆる変更がリリース候補版になります。つまりコード変更の一つ一つがデプロイ可能なパッケージを作るビルドを実行するのです。自動化テスト（ユニットテスト、静的コード解析、受け入れテスト）はデベロッパーに迅速なフィードバックを提供するため行われます。こういったテスト（通常並行して実行される）に合格したパッケージは次の段階の一連のテスト（探索的テスト）を受け、最終的に本番環境にデプロイされていきます。万が一ビルドがある変更によって不合格となった場合、私たちはデプロイメント・パイプラインを構成してアンドンコードを引くことですべてのユーザに警告を発するとともに、エラーが解消されるまで、もしくはそのコミットがロールバックされパイプラインがグリーンの状態に戻るまでの間、それ以上の変更が統合されないようサポートいたします。
継続的デプロイメント（CD）
ここまでであなたのチームは高頻度な変更の実行、迅速なフィードバックの提供、そして本番環境へ自信をもってデプロイできるコードベースの維持ができるようになりました。成熟した継続的デリバリー環境があれば、お使いのコードベースはオンデマンドで一日に複数のデプロイを実行することができるようになります（グリーン環境）。つまりバグのないソフトウェアを高頻度でリリースできる状態にあるということです。
継続的デプロイメントは継続的デリバリーパイプラインのさらなる拡張をもたらし、実際のデプロイをも自動化させます。デプロイメント・パイプラインの最終段階において、コードベースは人の手を介すことなく自動でデプロイすることができるようになります。このようなシステムは新しい機能の迅速なリリースやユーザからのフィードバックをより速く集める支えとなります。
監視
DevOps方式は、継続的インテグレーション、自動化テスト、継続的デプロイメントを機能に持つことで頻繫なコード変更を可能にします。そこで求められるのがお使いのアプリケーションコードや環境、オーケストレーション技術の総合的かつリアルタイムの監視です。アプリケーションの性能監視ツールの一つであるNew Relicは本番環境のアプリケーションの継続的監視に活用できます。チームが本番同様の環境で開発・テストを進めるようになるにつれ、継続的な監視範囲をステージング環境、テスト環境、さらには開発環境にまで拡大することもできます。
Devopsパイプラインの初期段階での自動化監視は、ラインのスムーズな流れを保つのに役立ちます。ビルド（開発の進捗状況）や自動化テスト、デプロイ、サーバーヘルス、アプリケーションログを監視する上で、得られたデータを中央に集約し分析や比較することが極めて重要となります。ここから導き出された指標をグラフに示したり統計的に分析することで、傾向の特定、問題の検知、システム停止の警告発信などを行うことができます。
継続的インテグレーション（CI）
デベロッパーの作業成果物をを早い段階で高頻度で共有リポジトリに統合することで、バグを早期に発見し、すばやく解決につなげることができます。通常業務の一環として小ロットでの統合を行えば、ソフトウェアを高頻度でデリバリーできるようになるのです。ここでデベロッパーが頻繫なコード変更をメインリポジトリにコミットするのに活用できるバージョン管理ツールは多数あります。継続的インテグレーションサーバーはコード変更のバージョン管理システムのポーリング、最新コードの読込、さらにビルドを行います。
自動化テスト
継続的インテグレーションの環境が整ったら、次は自動化テストです。それぞれのコードコミットはビルドスクリプトに統合され、自動化テストで検証されます。テストが自動化されていない場合、開発ベロシティがどれだけ加速化してもリリースサイクルは遅いまま、ということになりかねません。
ユニットテスト、受け入れテスト、統合テスト、さらには性能テストやセキュリティテストといった非機能テストまでも自動化することができます。ユニットテストと受け入れテストは並行して稼働するようにも設定できます。当社で非機能テストを自動化するために使うツールは JMeter、NeoLoad、、Browsera等です。
デベロッパーワークステーションそのものにいくつかの自動化テストを構成することで、デベロッパーが自分の作業へのフィードバックをより速く受け取ることができます。例えば、RubyデベロッパーがFoodcriticからコード構造や構文に対するフィードバックを得ると同時に、Sonarlintがテスト自動化エンジニアが書いたSeleniumテストの解析をすることが可能になるのです。
ここで重要なのはテストの信頼性を確実なものにすることです。誤判定は自動化テストが解決する以上の問題を引き起こす可能性があるからです。当社では、一連の小規模で信頼性の高い自動化テストから入り、時間をかけてその対象を広げていくことを推奨しています。
インフラのセットアップ
ソフトウェアのビルドを自動化することができたら、次は環境（開発/テスト、ステージング、本番）のプロビジョニングと運用を自動化していきましょう。最新のプロビジョニング・構成管理ツールを利用すると、プログラムコードに従った環境設定とシステム構成の管理が可能になります（インフラ・アズ・ア・コード）。
構成ドリフトを発生させない一貫性のある信頼できるインフラをお探しなら、一度デプロイしたらサーバーの変更が無いイミュータブル・インフラモデルをおすすめします。このアプローチで変更が必要になると、適切な更新が行われた新規サーバーを割り当てて既存のものと置き換えます。
インフラ設定がコードに書き起こされている場合、バージョン管理システムと自動化テストを用いて環境プロビジョニングを行い、アプリケーションコードに使われるCI/CDパイプラインに統合することが可能です。Foodcritic for Chefやpuppet-lint for Puppetといったツールは環境構築に用いられたコードの分析に活用できます。こうしたプラクティスやセキュリティハードニングチェックを一連の自動化テストに加えても良いでしょう。
コンテナ化
組織によってはインフラ・アズ・ア・コードとコンテナを組み合わせることも良いでしょう。これにより、アプリケーション環境からインフラ要件を切り離すことができるようになります。
コンテナは運用システムの構成要素（言語ランタイム、ライブラリ、システムファイル）をアプリケーションと結合させます。こうした構成要素はホスト環境を変えずに変更を加えることが可能であり、よって毎回特定の開発環境をセットアップする必要がありません。またコンテナは簡単に環境の複製ができ、仮想マシンに比べて軽量です。
デプロイメント・パイプライン
継続的インテグレーションと自動化テストの設定ができたら、デプロイメント・パイプライン構築に進んでいきます。このパイプラインではあらゆる変更がリリース候補版になります。つまりコード変更の一つ一つがデプロイ可能なパッケージを作るビルドを実行するのです。自動化テスト（ユニットテスト、静的コード解析、受け入れテスト）はデベロッパーに迅速なフィードバックを提供するため行われます。こういったテスト（通常並行して実行される）に合格したパッケージは次の段階の一連のテスト（探索的テスト）を受け、最終的に本番環境にデプロイされていきます。万が一ビルドがある変更によって不合格となった場合、私たちはデプロイメント・パイプラインを構成してアンドンコードを引くことですべてのユーザに警告を発するとともに、エラーが解消されるまで、もしくはそのコミットがロールバックされパイプラインがグリーンの状態に戻るまでの間、それ以上の変更が統合されないようサポートいたします。
継続的デプロイメント（CD）
ここまでであなたのチームは高頻度な変更の実行、迅速なフィードバックの提供、そして本番環境へ自信をもってデプロイできるコードベースの維持ができるようになりました。成熟した継続的デリバリー環境があれば、お使いのコードベースはオンデマンドで一日に複数のデプロイを実行することができるようになります（グリーン環境）。つまりバグのないソフトウェアを高頻度でリリースできる状態にあるということです。
継続的デプロイメントは継続的デリバリーパイプラインのさらなる拡張をもたらし、実際のデプロイをも自動化させます。デプロイメント・パイプラインの最終段階において、コードベースは人の手を介すことなく自動でデプロイすることができるようになります。このようなシステムは新しい機能の迅速なリリースやユーザからのフィードバックをより速く集める支えとなります。
監視
DevOps方式は、継続的インテグレーション、自動化テスト、継続的デプロイメントを機能に持つことで頻繫なコード変更を可能にします。そこで求められるのがお使いのアプリケーションコードや環境、オーケストレーション技術の総合的かつリアルタイムの監視です。アプリケーションの性能監視ツールの一つであるNew Relicは本番環境のアプリケーションの継続的監視に活用できます。チームが本番同様の環境で開発・テストを進めるようになるにつれ、継続的な監視範囲をステージング環境、テスト環境、さらには開発環境にまで拡大することもできます。
Devopsパイプラインの初期段階での自動化監視は、ラインのスムーズな流れを保つのに役立ちます。ビルド（開発の進捗状況）や自動化テスト、デプロイ、サーバーヘルス、アプリケーションログを監視する上で、得られたデータを中央に集約し分析や比較することが極めて重要となります。ここから導き出された指標をグラフに示したり統計的に分析することで、傾向の特定、問題の検知、システム停止の警告発信などを行うことができます。
DevOps実行のためのリリースパターン
オンデマンドでデプロイする柔軟性を獲得すると、新しい機能のリリースをどれだけ速く実行するかを選ぶことが可能になります。インフラ階層で実行される環境ベースのリリースパターンを選ぶことも、またコードによって実行可能になるアプリケーションベースのパターンを選ぶこともできます。
環境ベースのリリースパターンではアプリケーションコードに変更を加える必要がほとんどありません。複数環境にデプロイできますが、ライブトラフィックを得られる環境は一つに限られます。コードを検証環境にデプロイすることで、リスクとデプロイ両方のリードタイムを格段に短縮できます。
ブルーグリーン
デプロイメント
同一の２つの本番環境（ブルー環境とグリーン環境）で、ライブトラフィックを得られるのは一つ（ここではブルー）のみ。 変更は遊休環境（グリーン）でのテスト・検証を経て、ライブトラフィック処理に切り替えられる。 デプロイメント後、ブルー環境がステージング環境となり、グリーン環境がライブトラフィック処理にあたる。 ダウンタイムのない、1ステップでシンプルで簡単にデプロイ可能。 即時にロールバック可能。不具合があれば、トラフィックをブルー環境に切り替える。
カナリア
デプロイメント
ブルー/グリーンデプロイメントに比べ、低リスクで新たな変更の導入ができる。 変更はユーザの一部（ランダムサンプルまたは地理的位置/人口動態に基づき選別）に利用可能になる。 新バージョンは全ユーザに徐々にリリース、旧版もゆっくりと廃止される。 段階的なロールアウトで新バージョンのキャパシティテストができる。 問題が検出された場合、ユーザは旧バージョンにリルートされる。
クラスター
別イミューンシステム
カナリアデプロイメントの延長で、自動化されたデプロイ・ロールバックプロセスのこと。 変更は段階的にデプロイされ、リアルタイムでクラスターとビジネス指標の監視が行われる。 SLAを満たさない場合、プロセスは自動的に変更を差し戻す。 より短時間で性能劣化の検出および対処ができる。 問題の調査と解決が終わるまで、次のデプロイは凍結される。
ブルー/グリーンデプロイメント
同一の２つの本番環境（ブルー環境とグリーン環境）で、ライブトラフィックを得られるのは一つ（ここではブルー）のみ。 変更は遊休環境（グリーン）でのテスト・検証を経て、ライブトラフィック処理に切り替えられる。 デプロイメント後、ブルー環境がステージング環境となり、グリーン環境がライブトラフィック処理にあたる。 ダウンタイムのない、1ステップでシンプルで簡単にデプロイ可能。 即時にロールバック可能。不具合があれば、トラフィックをブルー環境に切り替える。
カナリアデプロイメント
ブルー/グリーンデプロイメントに比べ、低リスクで新たな変更の導入ができる。 変更はユーザの一部（ランダムサンプルまたは地理的位置/人口動態に基づき選別）に利用可能になる。 新バージョンは全ユーザに徐々にリリース、旧版もゆっくりと廃止される。 段階的なロールアウトで新バージョンのキャパシティテストができる。 問題が検出された場合、ユーザは旧バージョンにリルートされる。
クラスター別イミューンシステム
カナリアデプロイメントの延長で、自動化されたデプロイ・ロールバックプロセスのこと。 変更は段階的にデプロイされ、リアルタイムでクラスターとビジネス指標の監視が行われる。 SLAを満たさない場合、プロセスは自動的に変更を差し戻す。 より短時間で性能劣化の検出および対処ができる。 問題の調査と解決が終わるまで、次のデプロイは凍結される。
アプリケーションベースのリリースパターンでは、わずかな構成変更でアプリケーション機能を選択的に公開できるため、より優れた柔軟性が得られます。このリリースパターンはコード変更が必要となるため、導入には開発サポートが必要です。
フィーチャー（機能）トグル
コードを本番環境にデプロイすることなく、機能を有効化・無効化できる。 一定のユーザに対して公開する機能の制御ができる。 問題が生じている機能をただちにロールバックするようにトグル設定を調整できる。 ゆっくりと性能をダウングレードする。利用可能な機能数を減らすことで、より多くのユーザに提供し、サービス全体の障害を回避する。
ダークローンチ
ダークローンチでフィーチャートグルを拡張する。 ユーザに公開することなく、本番環境に機能をデプロイできる。 大規模で高リスクな変更の安全テストを本番同様の負荷において行う。 少数のユーザ群に段階的に機能をロールアウトし、万が一差し戻しになった際の影響を最小限に抑える。
フィーチャー（機能）トグル
コードを本番環境にデプロイすることなく、機能を有効化・無効化できる。 一定のユーザに対して公開する機能の制御ができる。 問題が生じている機能をただちにロールバックするようにトグル設定を調整できる。 ゆっくりと性能をダウングレードする。利用可能な機能数を減らすことで、より多くのユーザに提供し、サービス全体の障害を回避する。
ダークローンチ
ダークローンチでフィーチャートグルを拡張する。 ユーザに公開することなく、本番環境に機能をデプロイできる。 大規模で高リスクな変更の安全テストを本番同様の負荷において行う。 少数のユーザ群に段階的に機能をロールアウトし、万が一差し戻しになった際の影響を最小限に抑える。
DevOpsモデル向けのソフトウェアアーキテクチャ
組織のDevOps実行目標を達成するにあたり、ソフトウェアアーキテクチャは重要な役目を持ちます。少人数で独立して生産性が保てるチームにとって使いやすいアーキテクチャは常に求められています。サービスとゆるく結ばれているサービス指向アーキテクチャなら、低リスクで軽微な変更を行うことが可能になるため、チームの生産性、テスタビリティ（可検査性）およびセキュリティを高める働きをします。
モジュール構造のマイクロサービスアーキテクチャは、無駄な連携が多く、ビルドに時間が掛かり、拡張性が乏しい純モノリシック構造のそれと異なり、独立したテスト、デプロイ、拡張ができるアーキテクチャです。ストラングラーアプリケーションといったプラクティスを導入すれば、モノリシックシステムをよりサービス指向のアーキテクチャに徐々に置き換えることも必要に応じて可能になります。
サービスとしてのDevOps - 移行を実現
新たなモデルをスムーズに迎えられるようチームを後押しします。当社のコンサルタントとDevOpsアーキテクトにお任せいただければ、インフラとCI/CDパイプラインの評価・実行・維持を行うことでお客様の移行を終始サポート。また、以下のDevOpsコンサルティングサービスもご利用いただけます。
- CI/CDパイプライン実装
- インフラ再設計/インフラ・アズ・ア・コード設定
- 構成管理
- サーバーオーケストレーション
- コンテナ化
- リリース管理
- クラウド移行（AWS、Azure、GCP）
- マイクロサービスアーキテクチャ
DevOpsへの道のりは、頻繁な評価と継続的な改善を行うことで理想の状態へと向かっていく、着実な成熟度を確立していく道のりです。当社のDevOpsコンサルティング・導入サービスでは、組織の成熟度を問わず、お客様のさらなる発展を支援いたします。今すぐ当社のDevOpsエンジニアにご相談ください。