Jiraなしのエンジニアリング指標
Jiraがなくても大切なことは計測できます。Git、CI、チームがすでに使っているツールでエンジニアリングの健全性を追跡します。
By Chris Calo · 2026-03-23
最良のエンジニアリング可視性を持つ小規模チームは、たいていJiraが追うよう求める指標を追うのをやめたチームです。
これは単なる反論のように聞こえることはわかっています。正直、少しそういう面もあるかもしれません。しかし私は3年近く、スプリントボードの管理、バックログの整理、そしてその朝誰かがJiraを開いた時点ですでに半分終わっていたチケットの見積もり更新を忠実にこなしてきました。2週間ごとに（Zoomで – 2023年の話です）、すでに話し合いの中で知っていたことをそのまま教えてくれるベロシティチャートを眺めていました。JiraなしのエンジニアリングMetricsを探していたわけではありません。ベロシティチャートが何の役にも立っていないと認めたときに、自然とそうなったのです。
チームが1つのテーブルを囲める規模であれば、Jiraがなくても状況を把握できます。すでに使っているツールからのより良いシグナルが必要なのです。
これは「Jiraは悪い」という記事ではありません。JiraはJira型のトラッキングが必要な組織にとって優れたツールです（ある規模になると本当に必要です）。しかし10〜40人規模のスタートアップのエンジニアリングマネージャーが、ベロシティチャートを作るためだけにJiraにお金を払っているとしたら、それは昼食を温めるために業務用オーブンを買うようなものです。
「ベロシティチャートを作るためだけにJiraにお金を払うのは、昼食を温めるために業務用オーブンを買うようなものです。」 – Chris Calo
Jiraの指標が実際に計測するもの
率直に言いましょう。ほとんどのJira指標はエンジニアリングのアウトプットではなく、Jiraの使用状況を計測しています。ストーリーポイントはチームのストーリーポイント見積もり能力を計測します。ベロシティはチームがスプリントをほぼ同じキャパシティで埋め続ける一貫性を計測します。バーンダウンチャートは誰かが木曜日の午後にチケットをボードを横断してドラッグしたかどうかを計測します。
これらがまったく役に立たないとは言いません。しかしこれらは開発者生産性指標に見せかけたプロセス指標であり、その乖離こそがエンジニアリングマネージャーが本質を見失う場所です。
私はステークホルダーミーティングの前に1時間近く費やしてJiraデータを「順調に進んでいます」というスライドデッキに整形したEMでした。ステークホルダーは頷き、先週火曜日のログインバグについて1つ質問して、ミーティングは終わります。その1時間はスライドデッキのためでした。実際の答えは「エンジニアに聞いてください」でした。
指標が計測する作業よりもメンテナンスに時間がかかるなら、指標が問題です。
チケットボードではなくGitからのサイクルタイム
小規模プロダクトチームにとって、サイクルタイムは通常最も高いシグナルを持つ指標です。最初のコミットから本番デプロイまでの期間を計測し、Git履歴とCIパイプラインのみから導出できます。チケットボードは不要です。
構成要素：
- ブランチまたはPRの最初のコミットタイムスタンプ
- PRマージタイムスタンプ
- デプロイタイムスタンプ（CI/CDから – GitHub Actions、CircleCI、お使いのもの）
1と3の差分がサイクルタイムです。コーディング時間（1からPRオープンまで）、レビュー時間（PRオープンからマージまで）、デプロイキュー（マージから本番まで）にセグメント分けすると、作業が実際にどこで滞るかを示す診断ツールになります。
初めてチームでこれを実施したとき、数字は本当に驚くべきものでした。レビュー時間がボトルネックだと思っていました（誰もがレビュー時間がボトルネックだと思いますよね？）。実際はコーディングからPRのフェーズは問題なく、レビューも問題なく、ステージング環境が不安定で誰も修正を優先していなかったため、マージからデプロイの間で平均2日間を失っていたのです。ベロシティチャートではこれは決して浮かび上がらなかったでしょう。
計測方法
GitHubをお使いであれば、CLIで取得できます：
```bash
過去30日間のマージ済みPRを取得
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
デプロイタイムスタンプについては、ほとんどのCIシステムがAPIまたはwebhook経由で公開しています。PRマージSHAをデプロイイベントにマッピングすると、フェーズ別にセグメント化されたサイクルタイムが得られます。
ヒント： CIがデプロイタイムスタンプを明確に公開していない場合、最もシンプルなアプローチはコミットSHAとともに#deploysチャンネルに投稿するSlackボットです。タイムスタンプ、人間が読めるログ、そして副次的な効果として出荷頻度を示すチャンネルが得られます。
コードレビュースループット
レビュースループット（エンジニア1人あたり週次レビューPR数と、PRオープンから最初のレビューまでの中央値時間）は、あらゆるスプリント指標よりもチームの健全性を多く語ります。過小評価されています。
なぜか？レビュー行動は先行指標だからです。レビュー時間が長くなるとき、通常はエンジニアが過負荷になっているか、コンテキストスイッチが多すぎるか、（これが居心地の悪いもの）お互いのコードを避けているかです。いずれも、2週間後に締め切り遅延として現れる前に知っておく価値があります。
GitHubはAPIでこのデータを提供しています。主要なフィールドはPRのcreatedAtと最初のレビューイベントのsubmittedAtです。
私が注目する数字は最初のレビューまでの中央値時間（時間単位）です。いくつかの小規模チームの経験では、健全なレビューケイデンスは8時間以下の傾向があります。継続的に1日を超えると、何か構造的なものが変化しています。何であれ、Jiraでは見えません。
ミーティングと意思決定の比率
これは従来のエンジニアリング指標ではなく、KPIではなく大まかなヒューリスティックです。しかし小規模チームでは、驚くほど示唆に富むことがわかっています。
今週チームが持ったミーティングの数を数えてください。そこから生まれた具体的な意思決定の数を数えてください（「Xを調査すべき」ではなく、オーナーと次のステップを持つ実際の決定）。後者を前者で割ります。
ミーティングの半分未満しか決定を生んでいないなら、それらが時間に見合っているか問う価値があります。リスク軽減やコンテキスト共有のためのミーティングは正当であり、すべてが決議で終わる必要はありません。しかし非公式にでもこれを追跡し始めると（私は文字通りノートに集計していました）、どのミーティングが生産的でどれが誰も疑問を呈していない儀式かを感じ取るようになります。
これを約1ヶ月追跡した結果、どんな生産性に関する記事よりもミーティングのスケジューリング方法が変わりました。月曜日のスタンドアップが3週間連続でまったく決定を生んでいないとわかると、キャンセルすることが過激に感じられなくなります。
JiraなしのエンジニアリングMetricsを構築する：軽量ダッシュボード
BIツールは必要ありません。Notionページ、Googleスプレッドシート、または4つの数字を含む週次Slack投稿で十分です：
- 中央値サイクルタイム（Git/CIから）– 出荷速度は上がっているか下がっているか？
- 最初のレビューまでの中央値時間（GitHubから）– チームはすぐにレビューしているか？
- デプロイ頻度（CIまたは#deploysチャンネルから）– どのくらいの頻度で出荷しているか？
- ミーティングと意思決定の比率（手動集計）– ミーティングは価値を生んでいるか？
4つの数字、すでに持っているツールから導出でき、Jiraボードのメンテナンスは不要。週次で更新します。数字が2週間連続して悪化したら調査します。安定していれば放っておきます。
目的は監視システムを構築することではありません（しないでください – エンジニアに嫌われます、そして彼らは正しい）。エンジニアリングチームの可視性は作業自体から生まれるべきで、作業について報告するよう人々に求めることからではありません。 That’s the principle behind a single view of what the team is doing: the signals already exist in your tools, and how managers see team progress without asking for status reports is really about connecting those signals, as is task visibility across Linear, GitHub, Slack, and Notion.
最良のエンジニアリング指標は、収集コストが低く、操作しにくく、行動を促せるものです。ストーリーポイントは3つすべてで失敗します。
チケットボードが実際に必要なとき
これは「Jiraは悪い」という記事ではないと言いましたし、本心でそう思っています。プロジェクト管理ツールなしで指標を追跡することが真に無責任になる正当な状況があります：
- タスクステータスの監査証跡が法的に要求されるコンプライアンスの厳しい業界
- 非公式な調整では手に負えないクロスチーム依存関係がある大規模なエンジニアリング組織
- チームにまたがる真実の単一情報源が必要な専任プロジェクト管理機能を持つ組織
そのような状況であれば、Jira（またはLinear、Shortcut）が正しい選択です。私が主張しているのは、小規模チームにとって指標のためだけに重量級ツールをメンテナンスするのはコストに見合わないということです。チームの実際の作業ではなく、ツールの作業モデルに最適化することになります。
正直なところ、Jiraを使っているチームでさえ、ボードデータを上記のGitベースの指標で補完することで恩恵を受けるでしょう。Jiraは人々が自分が何をしていると言っているかを教えてくれます。Gitは実際に何をしているかを教えてくれます。両方とも有用ですが、ステータス更新の演技に免疫があるのは一方だけです。
指標の問題がスタートアップで繰り返し出てくるなら、1ヶ月間4つの数字のダッシュボードを試してみてください。JiraなしのエンジニアリングMetricsはセーフティネットなしで行くように聞こえるかもしれません。しかしGit履歴とCIパイプラインにどれだけのシグナルがあるかを見れば、チケットボードが何を加えていたのか不思議に思うでしょう。
カスタムスクリプトやJiraボードなしに、サイクルタイム、滞留中のPR、レビューのボトルネックを自動的に把握しましょう。
Q: プロジェクト管理ツールなしで有意義なエンジニアリング指標を取得できますか？ A: はい。サイクルタイム（最初のコミットからデプロイまで）、レビュースループット、デプロイ頻度はすべてGit履歴とCIパイプラインに存在します。エンジニア40人未満のチームでは、チケットボードが生み出すものよりも鋭く、操作しにくい傾向があります。また正確さを保つためにカードをボードに引っ張る必要もありません。
Q: SugarbugはエンジニアリングMetricsを自動的に表示しますか？ A: SugarbugはGitHub、Linear、Slack、カレンダーに接続してチームの活動のナレッジグラフを構築します。滞留中のPR、レビューのボトルネック、未解決の決定といったパターンをフラグします。GitHub APIに対してカスタムスクリプトを書いてメンテナンスすることなく、ここで説明したシグナルの多くをカバーします。
Q: Jiraのメトリクス利用を停止する賛同を得るにはどうすればよいですか？ A: 反乱ではなく実験として提案しましょう。既存のJiraダッシュボードと並行してGitベースの指標を4週間追跡し、どちらの数字が実際の変化を促したかを比較します。Gitの指標がより実行可能であれば（私たちの経験ではその傾向があります）、主張は自然に成立します。
Q: プロセス指標とパフォーマンス指標の違いは何ですか？ A: プロセス指標（ストーリーポイント、ベロシティ、バーンダウン）はチームがワークフローをどれだけ一貫してこなすかを測ります。パフォーマンス指標（サイクルタイム、デプロイ頻度、レビュースループット）はチームが実際に何をどのくらい早く出荷するかを測ります。小規模チームはほぼ常に後者からより多くのシグナルを得られます。パフォーマンス指標は手動ステータス更新ではなく作業自体から導出されるからです。