最新ユーザー事例探求 第51回

コードの変更回数や障害チケットの残存期間を可視化、さらに機械学習適用や部門間での情報共有も

DevOpsの成果をSplunkで分析＆可視化、横河電機のチャレンジ

　産業用制御システム／計測機器メーカーである横河電機では、ソフトウェアシステム製品の開発部門において、数年前からDevOpsの取り組みを進めてきた。現在ではさらに、そこから生まれるさまざまな開発メトリクスデータをAWS上の「Splunk Enterprise」に取り込んで分析／可視化することで、開発業務の効率化や改善にチャレンジし始めているという。

　今回は、2018年6月8日開催の「SplunkLive! TOKYO」で事例講演を行った横河電機 devopsグループリーダの藤原匠さんと、同社におけるDevOpsの取り組みを共に推進してきた高橋秀行さん、多田哲さんにお話をうかがった。

（右から）横河電機 IAシステム＆サービス事業本部（IA-SS）システム開発センター システムソフトウェア技術部 devopsグループリーダの藤原匠さん、同社IA-SS システム開発センター 統括管理部長の高橋秀行さん、同社IA-SS ライフサイクルサービス事業部 ソリューション開発部 開発運用課の多田哲さん。2013年当時は同じ部署に所属し、DevOpsの取り組みを推進してきた仲間だ

自動化の取り組みを1人で始め、チーム内の“DevOpsマインド”が醸成されるまで

　横河電機のIAシステム＆サービス事業本部（IA-SS）は、産業プラント向けの生産制御システム「CENTUM VP」や安全計装システム「ProSafe-RS」といったWindowsソフトウェア製品を開発／提供する部門だ。その中で藤原さんは、こうしたソフトウェア製品の開発インフラ構築／運用と、ビルドの実施やインストーラの開発などを主な業務としている。

　横河電機におけるDevOpsの取り組みは、5年前の2013年、藤原さんが「1人で」始めたのだという。当時の藤原さんは製品のテスター業務に従事しており、ソフトウェアのインストールや設定の作業を繰り返していたが、担当製品のインストール作業には1回あたり総計で5時間以上かかっていた。当然、そこに人が張りついて作業するのでは効率が悪い。

　そこで藤原さんはオープンソースのサーバー構成管理ツール「Chef」を導入し、OSの設定やアプリケーションのインストールといった作業を自動化した。その効果は絶大であり、その後、Chefの適用先は同社内のソフトウェア開発工程や国内／海外拠点における出荷作業にも拡大し、作業工数を累積で数千時間ぶんも削減している。この取り組みを通じて、藤原さんはInfrastructure as Codeのもたらす効果やDevOpsという考え方を理解していった。

　さらに2014年からは藤原さん、高橋さん、多田さんらのチームが中心となり、より本格的にDevOpsの取り組みを推進することになった。開発側（Dev側）ではなくインフラ側（Ops側）が主体となった、ボトムアップでのDevOpsアプローチだ。

　藤原さんらが当時担当していたプロジェクトは、1990年代から長年にわたり開発が継続しているソフトウェア製品の開発プロジェクトで、ソースコード規模は数千万行、200名以上の開発者が関わる大規模なものだった。藤原さんは製品のビルド工程を担当していたが、ビルド開始から完了までには総計で24時間以上もかかり、しかも工程の途中には手作業が残っていたため、ビルド処理を開始して放置できるわけでもなかった。「作業が非効率なだけでなく、社内から急に『明日使いたい』と言われても対応できませんでした」（藤原さん）。

藤原さんらが当時担当していたのは非常に大規模な開発プロジェクトだった

　この課題を解決するために、ビルド業務にかかる時間と手間を削減する3つの取り組みに着手した。まず、手作業を排除して自動化するためにオープンソースのCIツールである「Jenkins」を導入。加えて、古いビルドシステムも見直し、必要であればモダンな言語で再実装を行ったり、Jenkinsとの親和性改善を図った。そして、とくに処理時間のかかっていたボトルネック部分をひとつずつ潰していったという。その結果、全工程を自動化することによって、24時間かかっていたビルド業務は5時間にまで短縮された。

　こうしてインフラ周りの運用自動化を進めた結果、開発インフラチームのパフォーマンスは4倍以上に向上し、開発者の業務にも間接的に改善効果をもたらしたという。さらにインフラチーム内では自動化ツールを扱うスキルが向上し、「DevOpsが文化として定着したことで“DevOps的な考え方”ができるようになりました」と、藤原さんは自ら取り組んでみることでチーム内に起きた変化を語る。

　取り組みが成功した要因について、藤原さんは「上司（高橋さん）やリーダーの支援」と「チームメンバーの“改善”マインド」があったからだと分析する。後者について、5年前のチーム内は「『時間がないから何も改善できない』と考えるようなつらい状況」だったが、運用自動化によって時間的な余裕が徐々に生まれ、その余剰時間をさらなる業務改善に生かしていく好循環が生まれたという。

一般的なDevOpsの主要プラクティス。横河電機の場合はインフラの自動化やワンステップビルドからスタートした

　藤原さんらの取り組みは、元々“Ops側”＝インフラ運用側主体の動きであり、横河電機全社で見ればまだまだ小さな動きではある。長い歴史を持つ製造業がすぐに“DevOps的”なアジャイル開発手法を取り入れられるわけでもない。それでも、最近では社内にDevOpsユーザー会が立ち上がり、部門間の情報共有や取り組みの支援も始まるなど、意識変化が少しずつ始まっているのは確かのようだ。ちなみに「devopsチームリーダ」という藤原さんの肩書きがDevOpsを小文字で表記しているのは、DevとOpsの間のサイロ（垣根）をなくすという目標に基づくという。

偶然出会ったSplunkを使い、開発業務の改善を次の段階へ

　取り組みの成功要因としてもうひとつ、藤原さんは、ちょうど同じ時期に情報システム部門がAmazon Web Services（AWS）やSplunkといった新たなIT環境の社内利用を促進し始めたことを挙げた。この偶然が、次なる取り組みへとつながったからだ。

　上述したとおり、2013年からスタートしたDevOpsの取り組みは着実に成果を上げてきた。しかしスタートから数年が経過し、インフラチームの扱う範囲での自動化がひととおり終わると、改善効果の幅は次第に小さなものになっていた。

　「ある意味必然なのですが、取り組みが進むにつれて、改善の効果がだんだん出にくくなっていました。そろそろ何か別のところに（改善のための労力を）振り向けてもいいかな、と考えていました」（藤原さん）

　そんなとき、藤原さんはSplunkと出会った。情報システム部門が開催した社内セミナーで、セキュリティツールとして導入されたSplunkが紹介されたのだった。セキュリティツールとして説明されたため「最初はピンと来ませんでした」と笑う藤原さんだが、「DevOpsでもデータを入れてみたら何かわかるかもしれない」と講師に言われ、手元のデータをSplunkに取り込んでみたところ簡単に可視化ができた。「その簡単さに感動すら覚え、すぐにSplunkのファンになりました」（藤原さん）。

現在の横河電機におけるSplunkの活用範囲。セキュリティやDevOpsだけでなく、幅広い領域でデータ分析／可視化に利用されるようになっている

　Splunkの有用性を知った藤原さんは、当時抱えていた課題もこれを使って解決できるのではないかと思いつく。それは「開発プロジェクトの進捗状態が見えづらい」という課題だった。

　「たとえば『今週開発したテスト版のクオリティが異常に低いのだけど、その原因がよくわからない』ということがありました。プロジェクトの規模が大きいため、プロジェクトマネージャーでさえも細かな開発の状況まではわかりませんでした。もしもそのとき、その週に多くのコード変更が行われたことが可視化されていれば、それが原因ではないかと考えられたはずです」（藤原さん）

　もちろん、工数管理システムなどを使った開発プロジェクト全体の管理はこれまでも行われてきた。ただし、「コード変更の回数」のような具体的な状況を知るには、1、2カ月ごとに訪れるフェーズ終了ごとのレビューを待たなければならなかった。ここでは管理システムからデータを取り出し、Excelに取り込んで担当者が手作業でグラフ化を行っており「リアルタイムに状況が見えないことが大きな課題でした」と多田さんは説明する。

　そこで藤原さんらはSplunkを使い、コード変更のメトリクスを可視化してみることにした。具体的には、チーム開発支援製品であるマイクロソフトの「Team Foundation Server（TFS）」から、ソースコードの変更履歴データを取り出してSplunkに取り込み、変更回数を週ごとのグラフとして自動的にまとめる。さらにグラフ上ではコードが対応する機能別に色分けをし、どの機能で変更が多かったのかが一目でわかるようにした。

　「最初にこのグラフを作ってみて『なかなか使えるぞ』と思ったので、そこからSplunkの活用に弾みがつきました」（藤原さん）

1週間ごとのコード変更回数グラフ。変更対象の機能ごとに色分けもされている

システム構成。Jenkinsが定期的にデータ取得を指示し、AWS上のデータ前処理サーバーがTFSからデータを取得して処理、Splunkが取り込んで自動的に可視化される