ダッシュボーディング、またはデータの可視化

ダッシュボーディング（またはデータの可視化）にはどんなメリットがあるのかを確認し、何をグラフ化すればいいのかのアイデアを出してみましょう。

今日、あらゆる企業にとって最も価値のある資産はデータです。どの企業も、自社の製品やサービスに関連する膨大な量のデータを日々社内で生み出しています。このデータは、さまざまなソースに散らばっています。データから学ぶことは、戦略を決定し、競争に打ち勝ち、製品開発サイクルを改善し、製品を市場に送り出す効率を高めるために不可欠です。データは、適切に分析されれば、あらゆる企業の未来を真に形作ることができます。

この記事では、全てのソフトウェア会社に存在するデータを意味あるものにし、それを可視化する方法を説明します。さらに、企業のソフトウェア開発ライフサイクルのギャップを埋めるための意思決定にも役立ちます。

ダッシュボーディングとは

「ダッシュボーディング」が適切な言葉かどうかは分かりませんが（笑）、響きがいいので使います。ダッシュボーディングとは、複数のソースからかき集めたデータから、複数のグラフを含むダッシュボードを作成する作業のことです。つまり、数字を円グラフや棒グラフなどのグラフにすることです。

企業が長期にわたってたどっている傾向を視覚化するには、数字も良いですが、グラフの方が適しています。グラフを見れば、何がうまくいっていて、どの分野が改善を必要としているのかがよく分かります。これは、注意を要する分野のギャップを埋める戦略を経営陣が決定するのに役立ちます。

どんなデータを取得し、何を得るか

有用なデータとして取得できるものと、それを意味するものの可能性は、ほぼ無限大です。しかし、どんなソフトウェア会社にとっても、コードベースがどれだけ大きくなっているか、マスターブランチへの変更のマージにどれだけ時間がかかっているか、マスターブランチでどれだけ大きな変更が行われているかなど、ソースコードに関するデータは欠かせないものです。これらは、誰にでも共通するほんの一例に過ぎません。

次のセクションは、Harnessが複数のソースからスクレイピングしてグラフを作成しているデータポイントです。自分たちの何がうまくいっていて、より効率的なデリバリーのために何が注意すべきかを、このデータによりさまざまなチームが確認できました。

スクレイピングできるデータとは

ソフトウェアのライフサイクルに関連するデータを取得し、分析することができる場所はさまざまです。以下は、これらのデータをかき集め、ビジュアライゼーションの作成に使用できる場所の例です。

ソースコードの管理

どんなソフトウェア会社にもコードベースがあり、それを効率的に管理するためにSCMが欠かせません。SCMの例として、GitHub、Gerrit、GitLab、またはBitbucketがあります。以下のメトリクスを取得し、適切に分析すれば、ソフトウェアを顧客にリリースする際のブロックを緩和し、SDLC（ソフトウェア開発ライフサイクル）における既存のギャップを埋めることができます。

PRごとのコミットメント

プルリクエスト（PR）は、常に最小限のコミット数で構成されるべきです。１つのPRに含まれるコミット数が多いほど、より多くの手直しやリファクタリングが行われ、同じPRを何度も検証するためにリソースを消費したことを意味します。これはどの会社でも習慣やパターンになってはいけません。コストが劇的に増加する可能性があるからです。

マージまでの所要時間

リリース頻度は、数カ月に１回から、少なくとも週２回へと飛躍的に増加しました。バグ修正や機能はマージし、検証し、迅速に顧客にリリースしなければなりません。もし、TTM（Time To Merge）が上昇しているのであれば、どのようなステップで上昇しているのかを調べる必要があります。例えば、PRを検証するためのリソースが不足しているのか、あるいは何らかの承認遅延が発生しているのか、などです。 

PRの数

チームや個人のコードベースへの貢献度を任意の時点で追跡するために使用できる指標です。

コード行数

これは、追跡する上で非常に重要な指標です。新しい機能を追加してコードベースが進化すれば、コード行数は時間とともに増加します。しかし、新機能のリリースが少ないにも関わらず、コード行数が増えている場合は、注意が必要です。さらに、コード行数が増えるということは、コンパイルに時間がかかり、バグが発生しやすくなり、非効率なコードが書かれている可能性があります。

強制マージ

PRを強制的にマージすると、望ましくない結果をもたらすことがあります。また、実運用ブランチ全体を壊してしまうこともあります。従って、過去になぜ強制マージが起こったかを分析すれば（フレーキーである、が最も多い理由です）、マージプロセスを修正して強制マージの回数をゼロにすることができます。

ブランチとタグの数

これは任意ですが、コードベース内のリリースブランチやリリースタグを追跡するのに便利な場合があります。また、非常に古くてもう使われていないブランチを集めて、コードベースをすっきりさせるのにも使えます。

プロジェクト追跡システム

Jiraは、あらゆるプロジェクトを追跡するための最も一般的なツールであり、可視化のための多くのダッシュボードを提供しています。しかし、それらは独自の方法によるものであり、それを使用する全ての人にとって有用であるとは限りません。以下の指標をスクレイピングし、必要に応じてカスタマイズし、各チームの進捗を視覚化するために使用することができます。

チケットの状況

全てのバグや機能は、Jiraの１つのチケットまたは複数のチケットに対応します。スプリントで作業しているチームは、追跡目的でタスクのチケットを効率的に作成します。チケットのクローズ数、オープン数、期間などのデータを取得することができます。これにより、プロジェクトで作業しているチームの速度を推定したり、注意が必要な保留中のチケットがあるかどうかを簡単に発見することができます。さらに、各個人が投じる工数を見積もることができます。

CIシステム

mainブランチやQAブランチにマージする前に全てのコードが吟味される場所です。従って、各ジョブがどれくらいの時間を要しているか、成功したジョブと失敗したジョブの数などのパラメーターを分析することは、ギャップが見つかった際に改善に向けた将来の戦略を決定するのに役立ちます。

ダッシュボードを作成するために、これらの情報をどのように入手するのか

このようなシステムを設計するには、API、プログラミング言語（Java）またはスクリプト言語（Python）、データベース（SQL、NoSQL、Elasticsearch）、ダッシュボードを作成するためのツール（Kibana、Grafana、Looker）の知識が必要です。

私はPythonを好んで使用しています。さまざまなソースからAPI経由でデータを取得し、データをJSONまたはYAML形式にパースして、さまざまなデータベースにデータを送信するに当たって、Pythonは使い勝手がよく、フレームワークが市場に多数あるためです。データがデータベースに格納されると、ツールによっては、データを適宜利用してダッシュボードを作成することができます。clocはGithubに存在する、任意のリポジトリーのコード行数をカウントするツールの１つです。

ダッシュボーディングや可視化の利点は何か

これには特に最終的なメリットはありません。自社のデータから学ぶことは、常に既存のプロセスの効率化に役立ちます。可視化の一般的なメリットとしては、次のようなものがあります。

1. 複数のソースから一箇所で保持される全てのソフトウェア関連情報。
2. 社内チームのパフォーマンスと開発努力の明確な把握。
3. プロセス／製品／サービスの継続的な改善。
4. 内部および本番環境へのデプロイメント頻度に関する洞察。
5. コードとコーディングの品質。
6. 上層部の決定／計画努力。

ダッシュボーディングの醍醐味は、自社に特化したダッシュボードを開発できることです。自社開発なので、第三者企業とデータを共有する必要がなく、KI（Key Information）を完全にコントロールすることができます。

結論

データの可視化やダッシュボーディングは、ソフトウェア開発ライフサイクルにおけるボトルネックを継続的に特定するのに役立ちます。さらに、経営陣の意思決定にも役立ち、適切なタイミングで適切な場所に労力を配分することができます。ダッシュボーディングを通じて、ビジネスがどのように運営されているか、またどのように改善できるかを明確に洞察することができます。また、さまざまなプロジェクト、チーム、個人のベンチマークを決定するのにも役立ちます。

この記事が皆様のお役に立ち、ダッシュボード作成への取り組みを始める一助となれば幸いです。もっと詳しく知りたい方は、カスタムダッシュボードツールをご覧ください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。