こんにちは。リンクアンドモチベーションでエンジニアをしている長谷川です！
はじめに
この記事では、エンジニアの皆さんに向けて、ソフトウェア開発の分析ツールについて紹介します。
開発チームのパフォーマンスを良くするために役立つ分析ツールとして、Findyさんが提供しているFindy Team+がよく知られています。でも、海外にもたくさんの良いツールがあります。
そこで、この記事では、もう知っている人も多いと思いますが、まずAnalytics Toolを使うとどんな指標が見れるのかを簡単に説明します。その後、いくつかのツールをピックアップして、それぞれどんなものかをざっくり解説していきます。
サイクルタイムって何？
サイクルタイムは、ソフトウェア開発のスピードを測る大切な指標の一つです。具体的には、最初のコードを書き始めて（コミット）、それが実際にユーザーが使える環境（本番環境）にデプロイされるまでの時間のことを言います。これは、チームの開発がどれくらい速いか、そしてちゃんと動くものが作れているかの両方を見るためのものです。
サイクルタイムが短いと、次のような良いことがあります。
- 早くユーザーに届けられる
- 質の高いソフトウェアを提供できる
- 開発する人が楽しく開発できる
- ユーザーが満足してくれる
- 改善するためのフィードバックが早くもらえる
サイクルタイムの4つの段階と、もっと良くするためのヒント
サイクルタイムは、主に次の4つの段階に分けられます。それぞれの段階で、うまくいかないところや、もっと良くできるポイントがあります。
1. コーディング：オープンまでの時間（Time to Open）
- 説明
最初にコードをコミットしてから、その変更をレビューしてもらうためにプルリクエスト（PR）を出すまでの時間のことです。
よくある困ったこと
- 一度に変えるコードの量が多すぎる
- コードチャーンが多い
※補足
コードチャーン (Code Churn) というのは、書いたコードが短い期間に何度も追加されたり、変更されたり、削除されたりすることです。コードチャーンが多いと、コードが不安定になったり、バグが出やすくなったりすることがあります。
・色々なことを同時にやろうとして、集中できない
・何からやるべきか、優先順位がはっきりしていない
- 改善するためのヒント
- PRは小さくまとめて、早めに出すようにする
- コードチャーンをチェックして、なるべく少なくする
- 何を優先するかをはっきりさせて、作業の切り替えを少なくする
- いつまでに終わらせるかの目安を決めて、チームの作業スピードを上げる
2. ピックアップ：最初のレビューまでの時間（Time to First Review）
- 説明
PRを出してから、誰かが最初にレビューを始めるまでの時間のことです。
よくある困ったこと
- レビュー待ちのPRが溜まっている
- レビューをする人の負担が偏っている
- どのPRからレビューすべきか、順番が決まっていない
改善するためのヒント
- チームみんなでコードレビューをする
- レビューを協力して行う
- レビューの速さと丁寧さのバランスを取る
- レビューのやり方や優先順位を見直す
3. レビュー：マージまでの時間（Time to Merge）
- 説明
最初のレビューが終わってから、そのPRのコードがメインのコードに取り込まれる（マージされる）までの時間のことです。
よくある困ったこと
- レビューが厳しすぎたり、逆にざっくりしすぎたりする
- レビューの意見交換がスムーズにいかない
- 何度もレビューのやり取りが発生する
改善するためのヒント
- レビューの範囲のちょうど良いバランスを見つける
- 分かりやすくて、どうすれば良いかが伝わるコメントをする
- チーム内で協力して、レビューのやり取りを少なくする
- シンプルで効果的なレビューのやり方を作る
- コードレビューガイドラインを作る
補足 コードレビューガイドラインがあると、レビューの質も効率も上がります。例えば、コメントをするときに、どんな意図のコメントなのかを伝えるための印（マーカー）を使う、といったことが考えられます。
例えば、こんなマーカーがあります。
| マーカー | 説明 |
|---|---|
[must] |
これは直さないとマージできない |
[should] |
直した方が良いけど、時間がないなら後回しにしても良い |
[q] or [ask] |
ここ、どういう意味ですか？とか、なんでこうしたんですか？ |
[imo] |
僕の意見としてはこうだけど、参考にしてください |
[fyi] |
参考になる情報や背景を共有したいときに |
[nits] |
細かい指摘。そんなに重要じゃないけど、もし良かったら |
こういうマーカーを使うと、レビューのコメントがより分かりやすくなります。
チーム内で独自のマーカーを作成するのも良いかもしれませんね。
【参考】
- Google Code Review Guide: https://google.github.io/eng-practices/review/
4. デプロイ：デプロイまでの時間（Time to Deploy）
- 説明
PRがマージされてから、実際にユーザーが使う本番環境にリリースされるまでの時間のことです。
よくある困ったこと
- 本当にリリースして大丈夫か、自信がなくて時間がかかる
- リリース作業の手順が良くない
改善するためのヒント
- どんどんリリースしていく文化を作る
- 一度にリリースする量を少なくする
- もっと頻繁にリリースする
- 開発者とユーザーの間のフィードバックを早くもらうようにする
ベロシティメトリクスって？
ベロシティは、開発チームが一定の期間（例えばスプリント）にどれくらいの作業を完了できるかを示す指標です。これは、通常、ユーザーストーリーとかタスクといった単位で数えられます。
ベロシティメトリクスは、開発のスピード、作ったものの質、そして締め切りまでに終わらせる力を見るためのものです。
大事なベロシティメトリクス
スループット（Throughput）
サイクルタイム（Cycle Time）
- これはさっき説明した通り、作業を始めてから終わるまでの時間です。
- サイクルタイムを短くするには、時間がかかっている工程を見つけて、そこを改善していく必要があります。
- これはさっき説明した通り、作業を始めてから終わるまでの時間です。
MTTR（Mean Time to Restore）
デプロイ頻度（Deployment Frequency）
- どれくらいの頻度でソフトウェアの変更を本番環境にリリースしているかを示すものです。頻度が高いほど、新しいものを早くユーザーに届けられて、フィードバックにも素早く対応できます。
- デプロイ頻度を上げるには、CI/CD（継続的インテグレーション/継続的デリバリー）の仕組みを整えて、テストを自動化することが大切です。
- どれくらいの頻度でソフトウェアの変更を本番環境にリリースしているかを示すものです。頻度が高いほど、新しいものを早くユーザーに届けられて、フィードバックにも素早く対応できます。
メトリクスを上手く見るためのヒント
- どんな状況でデータが集められたかを考える
- 一つの数字だけじゃなく、時間の流れでどう変わってきたかを見る
- 数字のデータと、チームの意見や感想も一緒に考える
- 目標と比べてどうかを測る
- ただ良く見せるためだけのメトリクスに惑わされない
- メトリクスは参考にするもので、絶対的なルールじゃない
- チームやプロジェクトに合わせてメトリクスを工夫する
- 一つのメトリクスに集中しすぎると、他の大事なことを見落とすことがある
- 定期的にメトリクスを見直して、必要なら変えていく
- メトリクスをチームで共有して、みんなで良くしていこうという雰囲気を作る
ベロシティを上げるための方法
- チームにとって「速い」ってどういうことかを共通認識化する
- データを見て、どこが遅いのかを見つける
- データを使って、チームで話し合って改善点を見つける
- 速さも大事だけど、品質も落とさないようにする
- 定期的にメトリクスを見て、少しずつ良くしていく
- 実際にやってみてどうだったかの意見を聞いて、やり方を調整する
- できることは自動化する（例えば、テストやデプロイ）
ソフトウェア開発分析ツールの紹介
G2というサイトでは、次のような評価の高いソフトウェア開発分析ツールが紹介されています。
- Waydev
エンジニアリングのリーダー向けのツールで、サイクルタイムを自動で測って報告してくれます。どこに時間がかかっているかを見つけたり、コードレビューの効果を測ったりするのに役立ちます。
- DevDynamics
エンジニアリングの分析ツールで、大事な指標を一つの分かりやすい画面にまとめてくれます。チームのパフォーマンスについて色々な情報を提供してくれて、改善すべき点を見つけやすくしてくれます。
- LinearB
エンジニアリングのメトリクスと作業管理を自動化するツールです。開発者の作業の流れを良くして、PRやブランチなどの情報をリアルタイムに開発プロセスと結びつけます。
エンジニアリングの管理プラットフォームで、プロダクトとエンジニアリングのデータを一つにまとめます。これを使うと、誰が何をやっているか、リソースがどう使われているかが分かりやすくなり、より良い判断ができるようになります。
- Code Climate
開発チームがコードの品質、セキュリティ、テストの範囲を常に高く保てるようにサポートします。エンジニアリングのメトリクスを見える化して、データに基づいた意思決定を助けます。
これらのツールは全部、エンジニアリングチームのパフォーマンスを上げて、開発のやり方をより良くするために作られています。自分のチームの規模や必要な機能に合わせて、ぴったりのツールを選ぶことが大切です。
まとめ
ツールによっては、勤怠管理システムやカレンダーと連携して、バーンアウト（燃え尽き症候群）になりそうかどうかを教えてくれるものもあります。
サイクルタイムとベロシティメトリクスを良くすることは、ソフトウェア開発チームの効率と生産性を上げるためにとても重要です。それぞれの段階で何が問題になっているかを見つけて適切な対策をしていきましょう。
ツール活用とルールメイキングとを組み合わせれば、チームの生産性は向上し、市場の変化にも素早く対応できるようになります。一番の目標は、開発する人が楽しく開発でき、お客さんに最高のプロダクトを届けることです。
