はじめに

ソフトウェア開発組織の改善を進めるうえで、 「何をもって良い組織と言えるのか」、「改善の効果をどう測るのか」は常に悩ましいテーマです。組織のエンジニアリングチームは「うまくいっているのか」,「何がボトルネックなのか」を感覚だけで語ることの限界を感じたことはないでしょうか。ソフトウェア開発は個人プレーではなく、プロセス・ツール・人の協働によって価値を生み出すチームスポーツと言ってもよく、改善の単位も「個人」ではなく、エンジニアリングチーム全体で捉える必要があります。

 

本コラムでは、開発組織評価の代表的な枠組みである、以下のの3つを取り上げ、 それぞれの役割と、どう組み合わせて活用すべきかを解説します。

• • SPICE（プロセス成熟度）
  • DORAメトリクス（デリバリーパフォーマンス）
  • SPACEフレームワーク（人とチームの状態）

 

評価の前提：目的は「管理」ではなく「改善」

最初に確認しておきたいのは、 評価は人やチームを序列化するためのものではないという点です。
評価の目的は、

• • 現状を正しく理解する（チームの強みと弱みの理解）
  • 課題やボトルネックを可視化する（課題/ボトルネックの特定）
  • 改善施策がチームにどのような影響を与えたかを確認する(効果を検証)
  • エンジニア同士やマネジメントとの対話を深める（建設的な対話を促す）

といった、継続的改善を支えることにあります。
この前提を共有しないまま指標だけを導入すると、数字を守ること自体が目的化し、現場の疲弊を招きかねません。

 

SPICE：プロセス成熟度の評価

SPICE（ISO/IEC 330xx） は、ソフトウェア開発プロセスの能力（Capability）を評価する枠組みです。要件定義、設計、実装、テストなどの工程が一定の成熟度レベルで統制されているかを測定します。

SPICEで評価できること

• • • プロセスが標準化・管理されているか
    • 組織内で再現性のある開発が実現できているか
    • 継続的改善が文化として根付いているか

SPICEの成熟度レベル（例）

• • • レベル 1：実行されているが管理されていない
    • レベル 2：管理され、最低限のプロセスがある
    • レベル 3：織標準プロセスが定義されている
    • レベル 4：プロセスが定量的に管理されている
    • レベル 5：プロセス改善が組織的に推進されている

SPICEで利用できる具体的な評価指標の例

プロセス運用に関する指標

• • • 要件レビュー実施率
    • 変更管理プロセス遵守率
    • リスク管理票の更新頻度
    • プロジェクト計画の逸脱率（進捗・工数など）

品質管理に関する指標

• • • 工程別の手戻り件数（要件→設計・設計→実装 など）
    • レビュー指摘の再発率
    • テスト計画と実績の乖離率

SPICEの指標は、プロセスが安定して回っているかを確認する際に非常に有効です。一方で、SPICEは人の心理的状態やチームの疲弊まではほとんど扱いません。

 

DORAメトリクス：デリバリーパフォーマンスの評価

DORA（DevOps Research and Assessment）は、開発チームのパフォーマンスを測定するための指標群です。
Google Cloud が主導する大規模調査に基づいており、“高いパフォーマンスを出すチームが共通して持っている特徴”として知られています。

DORAの４つ主要指標（Four Keys）

• • • デプロイ頻度
      価値をユーザにどれだけ頻繁に届けられているか
    • 変更リードタイム
      コード変更が本番環境に届くまでのスピード
    • 変更失敗率
      リリース後に発生する障害の割合
    • 復旧時間（MTTR）
      障害発生時の復旧までの時間

DORAで使える具体的な評価指標の例

• • • 自動テスト実行率
    • CI/CD パイプライン成功率
    • プルリクエストの平均レビュー時間
    • リリースごとのバグ発生率

これらは、スピードと安定性を同時に捉えられる点が特長です。

 

SPACE：人とチームの「状態」を可視化

SPACEフレームワークは、Microsoft Research や GitHub などの研究者によって提唱された、 開発者生産性を多面的・人間中心に捉えるための枠組みです。

SPACEの5つの観点

• • • S：Satisfaction and Well-being（満足度・幸福度）
    • P：Performance（成果・品質・価値）
    • A：Activity（活動量）
    • C：Communication and Collaboration（協働）
    • E：Efficiency and Flow（効率性とフロー）

SPACEの特徴
SPACEは「この指標を使うべき」という規範的モデルではありません。組織のコンテキストに応じて、適切な指標を選び、組み合わせて使います。特に重要なのは、以下のような、DORAやSPICEでは見えにくい側面を補完できる点です。

• • • 数値改善の裏でエンジニアが疲弊していないか
    • コミュニケーションが滞っていないか
    • 割り込みが多く集中できていないのではないか

DORA・SPACEだけでは測れない評価の視点（補足）

フロー全体を見る指標

• • • • サイクルタイム
      • WIP（仕掛かり作業数）
      • フロー効率

これらは SPACE の Efficiency and Flow を具体化したものです。チームが「どこで詰まっているか」を明確にします。

 

技術的健全性

• • • • 技術的負債の増減
      • 静的解析違反数
      • 依存関係の陳腐化

短期的な成果には表れにくいものの、 将来のパフォーマンスに大きく影響する要素です。

 

SPICE・DORA・SPACEの使いわけ

組織／チームの改善では、SPICE・DORA・SPACEを必ずしも同時に評価する必要はありません。重要なのは、「いま何を知りたいのか」に応じて使い分けることです。

①DORA：「何が起きているか」を知る

改善の出発点として有効なのが、DORAメトリクスです。

・リードタイムが長い
・デプロイが滞っている
・障害対応に追われている

といった、チームの成果としての状態を客観的に把握できます。ただし、DORAが示すのはあくまで「結果」であり、なぜそうなっているかまでは分かりません。

②SPACE：「チームの状態はどうか」を確かめる

DORAで気になる結果が見えたら、次に見るべきは チームの状態です。SPACEフレームワークを使うことで、

・無理をして改善していないか
・コミュニケーションは機能しているか
・集中して開発できているか

といった、数値に表れにくい側面を確認できます。SPACEの役割は、改善がチームにとって健全かどうかを見極めることです。

③SPICE：改善を「再現できる仕組み」にする
最後に問うべきなのが、「このやり方は、チームの力として定着するか？」という点です。SPICEは、以下のような、チームを支える土台を評価します。

・やり方が個人に依存していないか
・プロセスが暗黙知になっていないか
・改善が継続できる仕組みになっているか

④改善では「流れ」で使う
SPICE・DORA・SPACEは、次の順で使うと分かりやすくなります。改善後は再び DORA を確認し、この流れを繰り返します。

 

 

 

おわりに

組織／エンジニアリングチームの評価は“目的”ではなく、“組織を強くするための手段”です。また評価指標は、エンジニアリングチームを縛るためのものではなく、チームと向き合い、より良くするための共通言語です。
SPICE、DORA、SPACEを適切に組み合わせて得られた情報をもとに、

• • • 「なぜこうなっているのか」
    • 「何から改善すべきか」
    •  「人は無理をしていないか」

を対話して共有化することが、重要です。

評価を武器にするのではなく、 学習と改善を支える補助線として使うこと。それが、健全で持続可能なソフトウェア開発組織につながると考えます。

 

（佐藤　崇）