Skip to content

OTR_DevInfraKPIandKGI

Jump to bottom
nishi_74322014 edited this page Nov 1, 2026 · 4 revisions

開発基盤のKPIとKGI

概要

開発基盤の KGI（重要目標達成指標）と KPI（重要業績評価指標）を説明する。

開発基盤は、

ソフトウェア・ライフサイクル上での「Q/C/D/F」の向上

という KGI を達成するために、次の KPI を向上させる枠組み・緩衝層として機能する（≒ CSF）。

  • 標準化
  • 共通化・再利用
  • 柔軟性・保守性（迅速な障害対応、バージョンアップ、互換性、移行性）

詳細

KGI と KPI の関係

KGI KPI
QCD（Q：品質・信頼性、C：原価低減、D：納期短縮） 標準化の度合い、共通化・再利用の度合い
F（柔軟性）、保守性 様々なアーキテクチャへの対応・最新技術のサポート、迅速な障害対応、バージョンアップ・互換性・移行性の指標
規格/標準 標準技術への対応の度合い
サポート力 サポート技術情報サイトのページ数・PV 数
ブランド認知 プロモーション・サイト、配布サイトのページ数・PV 数・DL 数

後半の 3 つは、近年のソフトウェア開発の傾向の「脱、独自・オレオレ」の検討から追加したもの。

KGI

アプリケーション開発から保守までを含めた、ライフサイクル全体の成功（＝ Q/C/D/F の向上）。

区分 内容
品質・信頼性（Q） 標準化、共通化・再利用に起因する品質・信頼性の向上、脆弱性の排除
生産性（C・D） 共通化・再利用、提供機能の利用、UX に起因する原価低減・納期短縮
柔軟性（F） 様々なアーキテクチャへの対応、最新技術のサポート
保守性 迅速な障害対応、ライフサイクルの延長
規格/標準 デジュリ・デファクト・グローバル・スタンダードへの対応
サポート力 有償・無償を問わず迅速なサポートが期待でき、制限事項が少なくセルフサポートが可能
ブランド認知 ブランドとして認知され、全ステークホルダーに対する説得力を持つ

KPI

標準化の指標

  • 標準化の度合い：業務設計だけで、どれだけブレずに実装に落とし込めるか。
    • 開発要員によってモジュール設計や処理方式が異なるなら、標準化の効果は弱い。
    • 同じになるなら、標準化の効果は強い。
  • 標準化の効果
    • 開発手順の一本化：バラつきの無い手順で開発でき、生産性・品質・信頼性が上がり、脆弱性を排除できる。
    • カスタマイズ可能レイヤ（ベースクラス2）に共通機能を追加でき、要件の異なる案件にも横展開しやすい。
    • 標準的に出力されるトレースログにより、開発時のデバッグ・保守運用時のトラブルシュートが容易になる。
    • 一括外注・オフショアなど、文脈を共有しない実装者に任せやすくなる。

「開発要員によって処理方式がブレない」ことは、実装者がコーディング・エージェントでも同じ指標で測れる。
同じ依頼を複数回・複数のエージェントに出して、出力の方式が揃うかどうかが、標準化の度合いになる
（コーディング・エージェント時代の開発基盤）。

共通化・再利用の指標

  • 対象
    • 形式知：プロジェクト・テンプレートのデザイン・パターン、サポート技術情報。
    • 暗黙知：テンプレートに蓄積された API の利用方法・共通部品の存在・テンプレート化の手順。
    • ツール・ライブラリ。
  • 度合い
    • 用意されている・利用している共通部品の規模。
    • 1 つのオンライン処理の中で処理される、ユーザ・コードと共通化コードのステップ数の比率。

柔軟性・保守性の指標

指標 問い
迅速な障害対応 問題の特定・対策に要した時間（きめ細かいログ出力、FAQ・事例の蓄積による）
バージョンアップ ランタイムのバージョンアップに追随できるか
互換性（Compatibility） ランタイム / ライブラリを、別のものに装換できるか
移行性（Portability） 異なる環境に移行できるか
  • バージョンアップ：Windows Forms や ASP.NET Web Forms は安定性が非常に高いが、
    安定性の低い JavaScript の MV* フレームワークの上では維持が困難になる。
  • 互換性：ランタイム・フレームワークには得手・不得手があるので、コンパチブルであることが重要。
    Open 棟梁も、UI サブシステム（通信制御機能）やデータアクセス（クロスDB対応、ADO.NET vs ORM）がコンパチブルになっている。
  • 移行性：クロスプラットフォームである方がよい。

    • Open 棟梁は .NET Framework 4.8 と .NET 10.0 の両方を対象とし、.NET 版は Linux 上でも動作する（2026 年 10 月時点）。

    • テンプレートを PaaS 化し、その後ゲートキーパー・デザインパターンに適合させた事例がある。
      次の 2 つの図は、当時の Microsoft Azure の Web / Worker ロールでの事例である。

      Azure の PaaS でプロジェクト・テンプレートを適用した事例

      セキュリティ対策で処理方式を変更した事例（ゲートキーパー）

AI 駆動開発の品質の指標

コーディング・エージェントに書かせる開発で、品質が保たれているかを見る指標。
いずれも、リポジトリ（Git の履歴・テストの成果物・Issue の記録）から取れるものに絞る。
計測の結果は Open 棟梁の課題と対応の 7 に載せる。

指標 何を見るか 取り方
テストの件数 テストの基盤が育っているか テストの属性（NUnit の [Test] など、xUnit の [Fact] など）の数。テストケース一覧の件数
カバレッジ テストが届いていない所はどこか（判定ではなく、書き足す先の指針） テストの実行時に集計した表（OpenTouryo の COVERAGE.md など）
テストとコードの変更量の比 テストを先に・厚く書いているか 期間ごとの、テストのパスとライブラリのパスの追加行数（git log --numstat）
期待値の変更 エージェントがテストを都合よく書き換えていないか 期待値（ゴールデン・ファイルなど）を変えたコミットの数と、そのうちコードの変更と同時のもの・期待値だけのもの。人が差分を見る対象。羅針盤を導入した後は、トレーラー（Expectation-Change）が付いたものの割合（3 段で塞げば 100%。漏れがあれば仕組みの穴）
回帰テストの数 見つかった問題が、回帰テストに変わっているか Issue に紐付いた回帰テストの件数
仕様の根拠の付与 テストの期待値が、仕様に基づいているか 根拠（RFC・OIDC などの該当箇所）を書いたテストの割合。Open 棟梁は、リスク「高」の名前空間で [Basis] の付いたテスト メソッドの割合（ソースの属性を数える）
手戻り 一度で直し切れているか 「漏れ」など、同じ Issue の追加の修正のコミットの割合
静的解析の指摘 既知の型の問題が残っていないか CodeQL などの指摘の件数と、対応のコミット
別モデルのレビューの指摘 作る役と検証する役を分けた効果があるか 別のモデルのレビューで見つかり、書いたモデルのレビューでは見つからなかった指摘の数。指摘をそのまま数えず、判定を経てから数える
  • 数値は、良し悪しの判定ではなく、推移を見るために使う。行数は生成物・サンプルを含み、粒度も一定でない。
  • 根拠付きのテストの割合は、100% を目指すものではない。根拠を書けないテスト（同じ実装の往復だけを見るテストなど）があるためである。
  • 外部の基準（適合性テストなど）を通した結果が、最終的な裏付けになる。

その他の指標

  • 規格/標準：.NET（Windows Forms、WPF、ASP.NET、ADO.NET など）、OSS（log4net、Dapper、PostgreSQL、MySQL など）、
    プラットフォーム（Windows、Linux など）、標準技術（JSON、JWT、OAuth2 / OpenID Connect / FAPI など）、
    設計・実装（デザイン・パターン、クリーン・アーキテクチャ）への対応の度合い。
  • サポート力：サポート技術情報サイトのページ数・PV 数。
  • ブランド認知：プロモーション・サイト、配布サイトのページ数・PV 数・DL 数（NuGet のダウンロード数など）。

参考

Tags: 再構築

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki
開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally