ＣＩ／ＣＤを導入した、IaCに移行した、監視ツールを入れた——それでも「DevOpsがうまく機能していない」という声は後を絶ちません。
AI時代の加速する変化の中で、組織がDevOpsを本当に機能させるには何が必要なのか。その問いに対し、組織・プロセス・品質の3つの切り口から実践的な答えを示すウェビナーを株式会社Sun Asteriskが開催しました。
登壇者プロフィール
株式会社Sun Asterisk Solution Architect / Unit Manager 橋本 武人
都内受託開発スタートアップにてエンジニアのキャリアをスタート。レガシー基幹システムのWebフルリプレイス、ECサイトのスクラッチ開発、不動産エージェントマッチングサービスのリードエンジニアとして担当。2022年9月にSun*にジョイン後は、生産管理システム・HR向けBtoB SaaS・幼児向けアプリ・ナレッジ共有プラットフォームなど、PM/Architect/SE/LeadEngineer/EM等の多様な役割を担いながら開発組織のマネジメントも担当。
株式会社クラウドワークス クラウドログ事業 セールスマネージャー内藤 洋介氏
クラウドログセールス兼コンサルティングセールスとして、お客様の課題に対し、クラウドログを中心とした様々な提案から導入支援を行う。また、業務改善セミナーへの登壇なども行っており、業界問わず導入に向けた支援実績が強み。
株式会社Magic Pod エバンジェリスト 伊藤 由貴氏
2012年に第三者検証会社へ入社。システムテスト自動化技術の普及推進チームを立ち上げ「テスト自動化エヴァンジェリスト」として活動。その後事業会社での一人目QAを経て2025年MagicPod入社。『ソフトウェアテスト技法練習帳』共著、JSTQB AL テスト自動化エンジニアシラバス翻訳メンバー。
DevOpsが“自走する”組織とは？形骸化を防ぐ、マインドセットと文化の醸成（Sun Asteriskセッション）
ツールを入れても変わらない組織の”あるある”
AI駆動開発が普及し、開発のあり方が短いサイクルで変わり続ける今、組織もスピーディーにアップデートを続ける必要があります。そのためにDevOpsに取り組む企業は多いはずですが、現場ではこんな状況が頻発しています。
- 工数・原価が見えない： どこがボトルネックなのか、データで特定できない
- 運用がバラバラ： ＣＩ／ＣＤ・IaC・監視を入れても、チームごとに使い方が揃わない
- 開発と運用が分断： 同じ現状認識を持てず、会話そのものがかみ合わない
このようにDevOpsが形骸化する原因は、文化が育つ前に手段だけを導入しているからかもしれません。ツールを導入する目的や使い方が明確でない状態では、たとえＣＩ／ＣＤを整備しても表面的な改善止まりとなり、プロダクトが抱える本質的な課題には届かないのです。
理想は「プロセスが勝手に育っていく」組織
では、どうあるべきなのか。目指すべき姿は、自己改善の文化が定着し、プロセスが自律的に育っていく「自走する組織」です。
この組織の構造は3層で捉えられます。最も重要な土台は、チームメンバー一人ひとりのアジャイルマインド・自己改善の文化です。「開発者体験とプロダクトを自ら良くしようとする内発的な意識」がなければ、どんな型を導入しても形骸化してしまいます。その上にPDCAを回す取り組みが乗り、さらにその上にプロセス・ツール・プラットフォームが位置づけられます。
PDCAを”仕組み”で回す
重要なのは、文化の醸成を精神論に頼らないことです。具体的には次のような仕組み化された取り組みがカギになります。
事業KPIと開発KPIを接続する
PDCAを正しく回すためには、KPIを事業KPIと開発KPIの2層で設計し、両者を接続することが不可欠です。
売上・チャーン率・回遊率といった事業KPIに相関する開発KPI（可用性・表示速度・変更失敗率など）を特定し、それを起点にアクションプランを設計します。業界ごとの例を示すと以下のようになります。
また、AI時代においてはコード行数・コミット数などの活動量を測るのではなく、価値の流れと健全性を測ることが重要です。AIによるコーディングが普及した今、活動量の指標だけを追うと品質の低下に気づけないリスクがあります。DORAメトリクス（デプロイ頻度・変更リードタイム・変更失敗率・復旧時間）や手戻り率・欠陥流出率など、価値の流れを表す指標を選ぶことが重要です。
DevOpsが止まる現場は、まず“見えていない”——工数・進捗・業務プロセスの可視化で捉えるボトルネック（クラウドワークスセッション）
感覚頼りの改善が招く空回り
「テスト工程に想定より20時間多くかかった」という事実があったとして、それだけで改善に動いていいのでしょうか。テスト量が多いのか、手戻りが多いのか、度重なる機能追加で確認項目が増えたのか——ボトルネックの「なぜ」と「どこに」が見えていない限り、改善策は感覚頼りになってしまいます。
クラウドワークスが指摘するのは、多くの現場でDevOpsの改善優先度が定量データではなく感覚で決まっており、改善効果や投資対効果が可視化されていないという問題です。
工数データの「粒度設計」が成否を分ける
ボトルネックを特定するためには、工数データを細かい粒度で記録・分析することが必要です。ただし、粒度設計にはトレードオフがあります。記録が簡易すぎると入力率は高まりますが分析には使えず、細かすぎると入力負荷が上がって定着しません。900社以上の導入支援実績を持つクラウドログによれば、この粒度設計こそが導入担当者が最も悩むポイントです。
工数データにプロジェクトのカテゴリー情報・取引先・部署情報を付与し、勤怠システムやSFA/CRMとも連携することで、データの情報価値はさらに高まります。
工数データでボトルネックを特定する：具体例
2週間サイクルで機能開発をしている内製チームで、「スプリント後半にQAが詰まってリリースが遅れる」という課題があったとします。工数データをカテゴリー別に分析すると、テスト工程だけで月間250時間を消費しており、そのうち8割が手動テストであることが判明。さらに担当者別に見ると、手動テストはAさん・Bさんの2名に集中し、自動テストはCさんにほぼ属人化しているという構造が浮かび上がります。
このようなデータを複数プロジェクト・複数カテゴリーで比較すると、「Webアプリ系プロジェクトはテスト工程比率・手動比率ともに高く、DevOpsへの投資効果が高い領域」といった判断を感覚ではなく定量データで下すことが可能になります。
さらに、過去の炎上案件と順調案件のデータを比較することで、トラブル対応工数が増え始めた段階で早期に異常を検知し、炎上を未然に防ぐ活用もできるようになります。
継続的テストから考えるDevOps（Magic Podセッション）
DevOpsに品質・テストが欠かせない理由
DevOpsの目的は「安心して、そして頻繁にリリースできる状況をつくること」です。この「安心して」を担保するのが品質保証活動であり、テストです。テストなしでリリースすれば本番環境で何が起きるか予測できない——逆に、きちんとテストを経てリリースすれば手戻りが減り、結果的に頻繁なリリースが可能になります。
DevOpsにおけるテストの考え方として、DevTestOps（継続的テスト）という概念があります。これはDevOpsのサイクル全段階でテストを実施するアプローチで、「ありとあらゆるタイミングでテストをすべき」という考え方です。従来の「テストフェーズ」のみでフィードバックを得る開発では、要件レベルで潰すべきバグが発見されるのが遅くなりすぎて、現代の開発スピードに追いつけません。
自動テストが続かない3つの理由
継続的テストを実現するには自動化が不可欠ですが、現場では自動テストが続かなくなる問題がしばしば起きています。主な原因は次の3つです。
- メンテナンス工数の膨張： テスト失敗の原因調査・テスト修正が積み重なり追いつかなくなる
- アプリ変更への追従困難： システムの更新頻度が高いとテスト側の更新が間に合わず手動に戻る
- 属人化： テスト自動化のナレッジが特定の担当者に偏り、その人が異動・退職すると継続できなくなる
これを防ぐために必要なのは、①テスト結果の信頼性を高く保つことと、②メンテナンス負荷をできる限り下げることの2点です。
ノーコード＋AIで自動テストを継続させるMagicPod
MagicPodはWebアプリ・モバイルアプリのE2Eテスト（システムテスト）をノーコードで自動化できるツールです。テスト対象の画面上でクリックや入力操作を選択するだけでテストステップを作成できるため、開発者だけでなくビジネスサイドやマネージャーもテスト自動化に関わることができます。これにより、属人化を防ぎながら、多様な視点から品質を担保できます。
さらに、自動テストの作成・実行・メンテナンスの各段階をAIがサポートする機能を備えています。特に「MagicPodオートパイロット」はAIエージェントを搭載しており、自然言語でテストの作成・修正を指示するだけでAIが実行します。従来は手動で行っていたメンテナンス工数を大幅に削減できます。
ユーザーからは「開発が終わったらすぐ自動テストが走って結果を確認できる流れを作れた」「作ったものはすぐに確認できる状態にしなければいけない」という声が寄せられており、CIcdパイプラインへの組み込みによってDevOpsのサイクルが回るようになった事例が増えています。
Sun AsteriskのDevOpsで実現する、品質と速度を両立した開発サイクル
まとめ
本ウェビナーで3社が共通して伝えたのは、「ツールを導入することはゴールではなく手段」という一点に集約されます。DevOpsを機能させるには、文化・プロセス・品質保証の3つが連動して初めて成立します。
- 文化（組織）： 精神論ではなく、振り返り・KPIレビュー・心理的安全性などの「仕組み」で自己改善の文化を育てる
- プロセス（可視化）： 工数データを適切な粒度で記録・分析し、感覚ではなく定量データでボトルネックを特定する
- 品質（継続的テスト）： DevOpsの全サイクルでテストを行い、ノーコード・AIを活用してメンテナンス負荷を下げながら自動テストを継続する
Sun Asteriskでは、1,300を超えるサービス開発・運用経験と1,000名超の開発人材を活かし、組織・文化の構築からDevOpsの実装・運用まで一気通貫で支援しています。DevOpsの形骸化や自走する開発組織づくりにお悩みの際は、ぜひSun Asteriskまでお気軽にご相談ください。