こんにちは。テクマトリックスの橘です。

弊社の開発基盤ソリューションチームでは、JenkinsやGitHub Actionsを利用したCI環境の構築を支援しています。サービス立ち上げ当初は、「CI をよく知らない」「導入検討をしたことがない」というお客様も多くいらっしゃいましたが、2026 年現在では CI は一般的な取り組みになってきたと感じます。
一方で、CI を導入してみたものの「思ったように成果が出ない」「これで良いのか判断できない」といった声もよく伺います。たとえば、日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年（出典：ガートナージャパン）では、CI/CD がピーク期を過ぎ、幻滅期に入ったとされる旨が報告されています。こうした状況だからこそ、いま一度 CI の狙いと設計を見直し、メリットを最大限に引き出すことが必要だと思います。
本記事では、弊社が CI 環境の構築をご支援したお客様事例をご紹介します。事例を通じて、CI 環境構築の進め方や成果につながる工夫を具体的にイメージしていただければ幸いです。

本題に入る前に

CI や Jenkins の基本をもう少し整理してから読み進めたい方は、弊社ウェビナーの内容が参考になるかもしれません。 CI の基礎や Jenkins の基本操作を、デモを交えて紹介しています。
毎月、前半の水曜日に開催をしています。参加費は無料です。

背景

まずは、CI環境を構築させていただいたお客様の概要です。

• 業界：自動車部品サプライヤー
• 製品：車載ECU
• 従業員規模：100～200人

こちらのお客様とは、もともと弊社で扱っているC/C++言語向けの静的解析・単体テスト自動化ツール C/C++test やソースコード解析ツールの Understand などをご利用いただいていましたが、先方よりCI環境構築についてのお問い合わせをいただき、下記のような課題をお伺いしました。

お客様の課題

• C/C++test を導入しているが、共用のノートPC上で解析を実行しており、開発者の裁量で解析を手動実行している。
• Subversionを利用しているプロジェクトが多く、Gitへの移行を進めてはいるが、スムーズに進んでいない。
• 将来的に CI の適用範囲を広げたい一方で、CI 環境の管理は開発者の兼任になる見込みであり、メンテナンスや改善活動のハードルが高い。

課題の分析

上記の課題について、掘り下げていくと以下のような潜在的な課題も見えてきました。

• 機能安全規格 ISO 26262 に準拠するための MISRA チェックが確実に実行されない可能性がある。さらに、解析までのリードタイムが長いことで、品質面・進捗面に影響するおそれがある。
• Subversion 中心の運用では、プルリクエスト／マージリクエストを起点としたレビューや承認フローを標準化しにくい。
• CI を「片手間」で運用する体制だと、トラブル発生時に CI のダウンタイムが長期化し、スケジュール遅延にも影響する可能性がある。また、改善が止まることで、効率化・高速化のメリットを十分に享受できないおそれがある。

方針とツールの選択

これらを踏まえ、CI 環境と Git 環境をどう構築するか、またどのツールチェーンを採用するかを議論しました。構築方針で最も重視したのは、シンプルな構成でスモールスタートすることです。

CI 環境を構築する際は、組み込みたい要素が増えがちです。例えば、調達するマシン、ツールのライセンス、実行結果の閲覧方法など、検討事項が一気に増えます。さらに、現時点では自動化できていない作業（バッチがない／CLI 実行実績がない、など）まで取り込もうとすると、設計が複雑化し、構築完了までの期間も延びやすくなります。

そこで今回は、既存プロセスへの影響をできる限り抑えつつ、すでに自動実行の土台がある ビルド／静的解析／システムテストを「最初の CI」の対象としました。CI ツールは OSS の Jenkins を採用しています。

ソースコードリポジトリは、社内の一部プロジェクトで利用実績のあった GitLab を全社向けに再構築し、新規開発プロジェクトでは GitLab の利用を必須としました。既存の Subversion 管理プロジェクトを Git に移行する案もありますが、「どこまで移行するか」「移行後の運用・メンテナンス方針をどうするか」といった論点が増えるため、今回は 既存プロジェクトは Subversion のままとし、GitLab と Subversion の並行運用を選択しました。

また、CI/CD において重要となるのが「フィードバックの仕組み」です。メール通知のみでは CI/CD 関連の連絡が埋もれるリスクがあるため、チャット通知によってフィードバックループを回す方針としました。チャットツールの利用実績がなかったことから、OSS 版 Slack とも呼ばれ、GitLab と同時に導入しやすい Mattermost を採用しました。

加えて、お客様がもともと利用されていた以下のツールを CI に組み込み、自動実行するパイプラインを設計しました。

• ビルドツール：Green Hills MULTI
• 静的解析ツール：Perforce QAC
• 静的解析ツール：Parasoft C/C++test
• システムテストツール：Vector CANoe

ご提案内容

弊社から構築させていただいたのは下記のような環境となります。

お客様環境の構築イメージ

パイプラインの流れ

GitLabにソースコードがプッシュされる、あるいはマージリクエストが作成されると、以下のようにツールが実行されていきます。

1. GitLabのWebhook機能により、Jenkinsのパイプラインがトリガーされる
2. Jenkinsコントローラーから各エージェントに対して順番にツールの実行指示がされる
   1. Green Hills MULTIによるビルド
   2. C/C++test 及び QACによる静的解析を並列で実行
   3. CANoeによるシステムテスト
3. Mattermost経由で開発チームに対して通知

これにより、手動実行や担当者依存による抜け漏れを防止し、コミットされたコードが所定の検証を経て製品コードとして扱われる運用を実現しました。

CI環境の拡大への対応

お客様の要望の一つとして、CI環境を全社的に広げていきたいというものがありました。そんな時に利用すると非常に便利なJenkinsの機能がパイプライン共有ライブラリです。

パイプライン共有ライブラリを利用すると、以下のサンプルのようにJenkinsfile内ではパラメータのみの設定程度で済み、プロジェクト側でJenkinsfileを一から用意するといったことも不要になります。また、チャット送信のように汎用性の高い処理も共有ライブラリに登録しておくことで、テンプレート側からその機能を呼び出したり、他のパイプラインからも利用する、といったことが可能になります。

※以下のコードはイメージです。実際の動作を保証するものではありません。

Jenkinsfileと共有ライブラリの関係イメージ

プロジェクト側のJenkinsfile例

@Library('my-shared-library') _ //利用する共有ライブラリの名前を指定

corporatePipeline([
    dockerImage: 'gcc:latest', // C言語コンパイラが入ったDockerイメージ
    buildCommand: 'make clean all', // ビルドコマンド
    testCommand: './run_tests', // テスト実行コマンド
    mattermostChannel: '#general' // 通知先のMattermostチャネル名
])

パイプラインのテンプレート例

def call(Map pipelineParams) {
    pipeline {
        agent { docker { image pipelineParams.dockerImage } }
        stages {
            stage('Build') { steps { sh pipelineParams.buildCommand } }
            stage('Test') { steps { sh pipelineParams.testCommand } }
        }
        post {
            always {
                    def message = "ステータス: ${currentBuild.result}\n" +
                                  "詳細URL: ${env.BUILD_URL}\n" +
                                  "ビルド番号: #${env.BUILD_NUMBER}"
                    sendNotificationChat(pipelineParams.mattermostChannel, message)
            }
        }
    }
}

チャット送信機能のカスタムステップ例

def call(String channel, String message) {
    script.httpRequest(
        url: 'YOUR_MATTERMOST_WEBHOOK_URL',
        requestBody: '{"channel":"' + channel + '", "text":"' + message + '"}'
    )
}

本記事では共有ライブラリの詳細解説は割愛しますが、共有ライブラリは CI/CD プロセスの標準化と効率化を進めるうえで非常に強力です。より詳しく知りたい方には、以下のトレーニングもおすすめです。
Jenkins パイプライン 中級 トレーニング

運用開始、そして運用後に出てくる課題に対して

Jenkins や GitLab は導入してすぐに使いこなせるものではなく、プロジェクトを進めながら学習も並行する必要があり、負荷が高くなりがちです。そこで弊社では、各ツールのハンズオントレーニングを実施し、基本操作や運用方法を実機で確認しながら学べる形で、移行がスムーズに進むようご支援しました。

また、運用開始後には構築前に想定していなかった問題が発生することも少なくありません。構築後のサポートとして、運用開始後の定期的なタイミングでフォローアップミーティングを設け、運用状況の確認と課題のヒアリングを実施しました。そのうえで、適切な設定方法の情報提供や、パイプライン改善案のご提案を行いました。

CI 環境や Git 環境は「作って終わり」ではなく、継続的に改善していくことで、新たな課題にも対応できるようになります。

導入による効果

構築した環境を実運用いただいたうえで、お客様から伺った効果の一部をご紹介します。

エラー対応の速度向上

従来はマイルストーンごとにビルドや静的解析を実行していたため、エラーへの対応が遅れることがありました。CI によりコミットごとに解析が走るようになったことで、プロジェクト内の不具合にリアルタイムに対応できるようになりました。

属人性の排除

従来はビルド担当者や静的解析の実行担当者へ依頼してから作業が進む流れで、特定の人に依存したプロセスになっていました。CI により属人性が排除され、誰がコミットしても同じプロセスでビルドやテストが実施されるようになりました。

コードレビュープロセスの習慣化

従来はコードレビューは担当者任せかつ記録も取っていないという状況でしたが、マージリクエストをプロセスに組み込んだことで、コードレビューが必ず実施され、CIの結果を参考にマージリクエストの承認などの判断ができるようになりました。

最後に

本記事では、弊社で CI および Git 環境を構築したお客様事例をご紹介しました。全体の流れや検討ポイントについて、イメージを掴んでいただけたでしょうか。
（今回は CI 要素が強めになったため、近いうちに Git の構築や運用改善の事例もご紹介できればと考えています。）

他のお客様事例や、CI のメリット、 Subversion から Git へ乗り換える際のポイントなどをさらに詳しく知りたい方には、以下のウェビナーが参考になるかもしれません。事例紹介を含め、実際の運用開始に至るプロセスとその背景を幅広く解説しています。

こちらも定期開催されており、個別の導入相談に役立つ情報を凝縮した内容です。日程や詳細はリンク先ページに掲載していますので、必要に応じてご確認をお願いします。