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

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

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

機械学習による「障害チケットの担当者割り当て自動化」など、適用範囲を拡大

　その後、藤原さんらはSplunkを使い、開発業務に関係するさまざまなシステムからメトリクスデータを収集して分析や可視化を行っている。今回の取材ではその一部を紹介してくれた。

　たとえば「障害チケットの消化状況」グラフだ。これは、バグトラッキングシステムからチケットのデータを収集し、ソフトウェアの障害報告（チケットのオープン）から修正（クローズ）までにかかった経過日数と件数を分析してグラフ化するものだ。これも開発の状況が知りたいというプロジェクトマネージャーからのリクエストで作成したという。

　「データを可視化してみると、オープンからクローズまでの期間の中央値は『半月～1カ月』でした。プロジェクトマネージャーは『もっと早く修正できていると思った、意外だった』という反応で、今後、クローズが遅れている障害については早期に原因を調査するなどして改善したいと話していました」（藤原さん）

障害チケットの消化状況グラフ。可視化してみると想像していたよりも長期間かかっていることがわかった

　障害チケットに関しては、Splunkの機械学習機能（MLTK：Machine Learning Toolkit）を適用して、障害の内容にふさわしい担当者を予測する「担当者割り当ての自動化」にも挑んでいる。

　まず、過去の障害チケットの内容から「AWS Comprehend」を使ってキーフレーズを抽出し、次に担当者とキーフレーズの対応リストを作成したうえでSplunk MLTKに学習させる（モデルを生成する）。このモデルを使うことで、新規に障害チケットが登録されれば、その内容から最適な担当者を予測する（割り当てる）ことができるという仕組みだ。結果として「7割以上の適合率が実現する、非常に優秀なモデルができた」（藤原さん）。

障害チケットの担当者割り当て自動化。機械学習を適用し、新規障害チケットの内容からそれに適した担当者を予測する

　JenkinsのログデータもSplunkで可視化しているという。数年間利用してきた結果、Jenkinsで制御するジョブの数は増えているが、各ジョブが“属人化”し、それぞれが正常に動作しているのかどうかがわかりづらかったという。そこでSplunkでダッシュボードを作り、ジョブがいつ動作し、エラーが出ていないかどうかを一目で監視できるようにした。

　そのほか、これまで利用してきたソフトウェアコードの静的解析ツールのデータや、自社開発の工数管理システム、バグトラッキングシステムなどのメトリクスデータを取り込み、多様な切り口で分析／可視化する用途にもSplunkを利用しているという。従来のツールでは、あらかじめ用意された視点以外でデータを分析しようとすると、Excelにデータをコピー＆ペーストして後は手作業で――となりがちだった。多田さんは「横河電機のような歴史の古い会社では自社開発のツールを持っていることが多いので、それぞれからデータを取ってきて関連性を分析できるのがすごく良いと思います」と、Splunkの利便性を語る。

　ちなみに、こうしたさまざまなデータの収集と分析／可視化を行うシステム構築について、藤原さんはその経験から「必要十分なデータを投入できるまでの工程がおよそ8割を占める」と述べる。当初は「必要十分なデータ」とはどれなのかを試行錯誤する必要があったといい、その結果、現在ではPythonを使ってデータクレンジングなどの前処理を行ったうえでSplunkに投入している。一方で、データ投入後にグラフやダッシュボードとして可視化する作業にはさほど手間がかからないという。

「メトリクス分析」を正式な開発要件に、次は部署間のデータ共有を目指す

　藤原さんらが構築し、これまでは実証実験的に効果を確認してきたこうした開発メトリクス分析ツールだが、今年からは正式な開発要件として加わることになるという。

　「次のプロジェクトから、正式な要件として『開発状況の分析を行う』と入れるように働きかけたいと考えています。今年は（開発メトリクスの分析が）本格的に入っていく年になると思います」（藤原さん）

　それに伴って、ツールの利用対象とする社内ユーザーも拡大していく方針だ。まずはプロジェクトマネージャや開発部門のマネージャが利用することを想定しているが、最終的には現場の開発者個々人でも、自分の開発状況を確認できるようにする。そのために、今年はそれぞれの役職に応じたダッシュボードを用意していくという。

　高橋さんはマネジメント側の視点から、優れた開発者を社内表彰する際の基準となるデータを、開発メトリクスの分析によって得たいと語った。たとえば「書いたコード量は多いのにバグが少ない」開発者を表彰する、といったものだ。

　「これまでだと単純に書いたコードが多い＝『苦労した』開発者を表彰するというものになりがちでした。実際にはマネージャーも（バグの少ない優れた開発者は誰か）わかっているのですが、表彰するにはそれがデータとしてきちんと見えるといいですね」（高橋さん）

　開発状況を共有することで、さまざまな場面における業務の効率化も期待できる。たとえば多田さんは、ソースコードの変更回数データを「テスト計画にも使いたい」と語る。これまでは単純にコード量の多い部分を手厚くテストしていたが、今後は変更回数が多く、品質が不安定化しているおそれのある部分を重点的にレビューできるようになる。さらには変更回数だけでなく、「どのくらいの期間にわたって変更されているか」についても指標にしうるという。複数回のテストをまたぎ、長期間にわたって繰り返し変更されている部分は、問題がうまく修正できていない可能性が高いからだ。

　「横河電機は『制御』の会社です。制御においては『データとして計測し、可視化できないものは制御できない』のが基本。しかし、ソフトウェア開発の現場を見ると、これまではメトリクスデータが可視化できていなかった。その状態で開発を『制御』する、つまり適切にマネジメントすることは、実はできないはずなのです。これまでの取り組みで可視化はできたので、次はそのデータで開発現場を制御するところまで持って行きたいですね」（多田さん）

　また藤原さんは、開発部門内での業務改善に加え、Splunkという共通データ基盤を通じて「社内にある部門間のサイロを壊していく」ことにも取り組みたいと語った。前述したとおり、横河電機では開発部門だけでなく幅広い部門の業務で、データ分析／可視化にSplunkを活用している。Splunkに社内のデータが集まっているならば、それを互いに参照し利用できるようにすることで、業務の品質や効率をより向上させることができるはず、という発想だ。

　「たとえばコールセンターへの問い合わせ履歴を開発部門から参照できれば、自分の担当プロダクトにどんなクレームが入っているのかを知ることができます。また、開発部門における開発状況のデータを品質保証部門に提供すれば、開発フェーズのもっと早期に品質保証の視点から介入し、データに基づく議論ができるようになるかもしれません。こうして蓄積されたデータどうしをつなぎ、スピードを速めていくのが“devops的な考え方”だと思っています」（藤原さん）

　DevOpsの取り組みでは収集するデータ量も比較的少ないため、セキュリティなど他の用途でSplunkを導入している企業ならば、そこに相乗りするかたちでも十分にスタートできる。藤原さんはそう説明したうえで、「今日紹介したような単純な事例は、どんな会社でもすぐに取り組めます。ぜひ始めてみてほしいですね」と語った。

■関連サイト

• 横河電機
• Splunk