「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
KPI・KGI †
KPI †
目標を達成するうえで、
「進捗度合いが測れる目安となるような」
定量化されている指標
KGI †
目標そのモノとその達成度。
開発基盤のKPIとKGI †
開発基盤の役割 †
開発基盤は、
ソフトウェア・ライフサイクル上での「Q/C/D/F」向上
というKGIを達成するための、
KPI
- 柔軟性、保守性
- 迅速な障害対応
- バージョンアップ
- 互換性（compatibility）
- 移行性（portability）
を向上させる
として機能する。
開発基盤とKPI・KGI †
- 開発基盤のKPIとKGIは、以下のような関係にある。
| KGI | | KPI |
QCD
・Q : Quality（品質/信頼性）
・C : Cost（原価低減）
・D : Delivery（納期短縮）
品質・生産性 | ⇔ | 標準化の度合い |
| 共通化・再利用の度合い |
F : Flexibility（柔軟性）
保守性 | ⇔ | ・様々なアーキテクチャへの対応
・最新技術のサポート |
| ・迅速な障害対応 |
| ・バージョンアップの指標の指標 |
| ・互換性（compatibility）の指標 |
| ・移行性（portability）の指標 |
- また「コチラ」での検討内容を付加すると、
以下のような、KGI・KPI項目も必要と考える。
| KGI | | KPI |
| 規格/標準 | ⇔ | 対応の度合い。 |
・.NET
・Windows Forms, WPF, UWP,
・ASP.NET WebForms?, MVC,
・ASP.NET WebService?, WCF, WebAPI,
・ASP.NET Identity, ADO.NET, etc.
・OSS
・Apache log4net、DotNetZip?, Dapper,
・PostgreSQL, MySQL,
・.NET Standard, .NET Core,
・Apache Cordova, etc.
・プラットフォーム
・Windows, Linux,
・Android, iOS, etc.
・標準技術
・JavaScript? (ECMAScript),
・JSON, JWT(JWS/JWE/JWK),
・OAuth2/OpenID Connect/Financial API, etc. |
| サポート力 | ⇔ | サポート技術情報サイト |
・ページ数
・PV数 |
| ブランド認知 | ⇔ | プロモーション・サイト、配布サイト |
・ページ数
・PV数
・DL数 |
KGI †
アプリケーション開発から、保守までを含めたライフサイクル全体の成功
＝ ソフトウェア・ライフサイクル上での「Q/C/D/F」向上。
品質/信頼性 †
標準化、共通化・再利用に起因した、
Q : Quality（品質/信頼性） †
生産性 †
共通化・再利用、提供機能の利用、UXに起因した、生産性の向上による、
C : Cost（原価低減） †
D : Delivery（納期短縮） †
柔軟性、保守性 †
柔軟性の向上による
F : Flexibility（柔軟性） †
- 柔軟性
- 様々なアーキテクチャへの対応、最新技術のサポート
- バージョンアップ
- 互換性（compatibility）
- 移行性（portability）
- 保守性
- 迅速な障害対応
- ライフサイクルの延長
- バージョンアップ
- 互換性（compatibility）
- 移行性（portability）
その他 †
規格/標準 †
なるべく多くの規格/標準に対応している。
- 規格、デジュリ・スタンダード
- デファクト・スタンダード、グローバルス・タンダード
サポート力 †
問題解決に掛った時間
- 有償/無償を問わず、何かしらの手段で迅速なサポートが期待できる。
- また、制限事項が少なく、セルフサポートが可能。
ブランド認知 †
ブランドとして認知されている。
≒ 全ステークホルダーに対する説得力を持つ。
KPI †
以下を指標として利用できる。
標準化の指標 †
標準化の度合い †
- 業務設計だけで如何にブレずに実装に落とし込めるか。
- 開発要員によって、モジュール設計や処理方式が、
- 異なる場合、標準化の効果は弱いと言える。
- 同じに慣れば、標準化の度合いは弱いと言える。
標準化の効果 †
大規模案件になればなるほど大きくなる標準化等の設計工数を削減できる。
- 開発手順の一本化
- 開発の標準化による生産性・品質・信頼性の向上と、脆弱性の排除。
- 標準化や自動生成により、バラつきの無い手順で開発可能。
- 標準化により、共通化・再利用性が高まる。
例えば、カスタマイズ可能レイヤへ、
共通機能を追加・カスタマイズすることも可能になる。
- カスタマイズ & フィッティングで異なる要件の案件を跨いだ横展開も容易。
- 内部統制的なログ機能、国際化対応（多言語化）機能などを追加実装可能。
- 標準化によりトラブルが減る、トラブルシュートが容易になる。
- 標準化によりトラブルが減る。
- 標準的に実装される各種トレースログ出力を利用できる
（開発時だけでなく、保守・運用時も利用可能）。
- 開発時のデバッグのし易さ、デバッグ手順の確立。
- 保守・運用時のトラブルシュートのし易さ、
- トラブルシュート手順の確立。
- 一括外注、オフショア
標準化により、一括外注、オフショアなどの開発が容易になる。
- オフショア開発での管理を容易にして
プロジェクトの成功確率を飛躍的に高める。
共通化・再利用の指標 †
対象 †
- 暗黙知
- 開発の暗黙知を「プロジェクト・テンプレート」に蓄積可能。
- いちいち、マニュアルを参照しなくても理解できる。
- APIの利用方法
- 主要な共通部品の存在
- APIを組み立てテンプレート化する手順
- ツール・ライブラリ
「各種機能」のツール・ライブラリを再利用できる。
共通化・再利用の度合い †
- 共通部品の規模
- 用意されている共通部品の規模。
- 利用している共通部品の規模。
- １つのオンライン処理が動作する中で処理される
ユーザコードと共通化コードのステップ数の比率
共通化・再利用の効果 †
設計と実装の共通化・再利用による工数削減が可能
柔軟性、保守性の指標 †
迅速な障害対応 †
問題特定・対策に要した時間数
- きめ細やかなログ出力による
- FAQや事例情報の蓄積による
ランタイムのバージョンアップに追随可能か？
ランタイム/ライブラリを別ランタイム/ライブラリに装換可能か？
異なる環境に移行可能か？
その他の指標 †
規格/標準の指標 †
規格/標準への対応の度合い。
- .NET
- Windows Forms, WPF, UWP,
- ASP.NET WebForms?, MVC,
- ASP.NET WebService?, WCF, WebAPI,
- ASP.NET Identity, ADO.NET, etc.
- OSS
- Apache log4net、DotNetZip?, Dapper,
- PostgreSQL, MySQL,
- .NET Standard, .NET Core,
- Apache Cordova, etc.
- プラットフォーム
- Windows, Linux,
- Android, iOS, etc.
- 標準技術
- JavaScript? (ECMAScript),
- JSON, JWT(JWS/JWE/JWK),
- OAuth2/OpenID Connect/Financial API, etc.
サポート力の指標 †
サポート技術情報サイト
ブランド認知の指標 †
プロモーション・サイト、配布サイトの
参考 †
参考になるリンク先。
KPIとKGI †
KPI †
KGI †
QCDF †
Q（quality） †
「予防コスト（適合コスト）」、「不良コスト」の削減が、
下記の「CD（cost, delivery）」に反映される。
CD（cost, delivery） †
「適用効果」を参照。
F（flexibility） †
「柔軟性、保守性」を参照。
柔軟性、保守性 †
バージョンアップ †
互換性（compatibility） †
ランタイム/ライブラリを別ランタイム/ライブラリに装換可能か？
- Open棟梁も、UIサブシステムや、データアクセスがコンパチブルになっている。
移行性（portability） †
異なる環境に移行可能か？
- クロス・プラットフォームであるほうが良い。
- プラットフォーム間を移動する際に影響が少ないほうが良い。
- テンプレートをPaaS化、その後、ゲートキーパーデザインパターンに適合させた事例。
標準化 †
品質管理用語。≠ 規格・標準。
製品などの形・大きさ・性能・測定方法などを一定の取り決めに従って統一していく活動のこと。
参考 †
ユーザ様 向けに提案型営業をしていて思ったこと。 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
