「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Open棟梁の適用効果について説明します。
QCDF向上 †
以下の効果によるのQCDF向上を図ることが出来ます。
生産性向上 †
QCDFのうちの「（Q）CD」辺りに関連する。
生産性向上の効果 †
生産性向上の効果としては、
- 新規開発時は、1割程度の効率向上が可能と考えています。
- 保守・運用から、マイグレーション、再構築なども含め、
ソフトウェア・ライフサイクル全体で、3割程度の効率向上が可能と考えています。
データから見る生産性向上の実績 †
- 新規開発時の生産性向上
1割程度の効率向上が可能（これは、2.1 KS/人月 -> 2.3 KS/人月程度のインパクト）
- パーキンソンの法則
「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。」
により、工数が、品質向上工数に回されたりすることがあるので、
MAXの生産性データが測定できないという問題もあります。
- 実績データを分析してみると、以下に起因する、
生産性低下の影響が大きく、下振れのバラツキは大きいです。
- マイグレーション時
- 新規開発のｎ倍以上の生産性を観測している。
- ただし、スコープ（特にテスト）に依存する。
- 再構築時
- 新規開発の約２倍以上の生産性を観測している。
- 以下が工数削減根拠として大きい。
- 設計・チェックリストの再利用
- ビジネス・ロジックの流用
品質向上 †
QCDFの「Q」
- エンタープライズの品質保証を経由するため、生産性向上は品質向上に直結している。
- 定量的データはないが、定性的な情報が「利用者の感想」に含まれる。
柔軟性向上 †
QCDFの「F」
定量的効果（削減工数） †
少なく見積もっても、
40.0人月のアプリケーション開発工数のうちの12.5%前後の工数削減が可能
と考えます。
これにより、QCD（quality, cost, delivery）が向上します。
以下、内訳についての説明です。
前提の工程別工数比率 †
ソフトウェア開発の工程範囲での工程別工数比率は、
設計 : PG : テスト = 3 : 4 : 3
前後になる。というのが一般的。
設計工程 †
工数削減根拠 †
実績ある設計情報を再利用できます。
また、
のサポート技術情報を再利用できます。
工程別工数比率 †
全工程の30％程度
削減工数の例 †
40.0人月のアプリケーション開発工数のうち、最小で2.0人月の工数削減が可能
（全体工数と、使用する機能によっては10人月以上の削減も可能）。
プログラミング工程 †
工数削減根拠 †
- １リクエストで動作するコードの内、40％程度を共通化が可能。
※ 40％という数字は共通化などの工数削減施策により、削減された
"ステップ数"なので、そのまま削減された"工数"とはなりませんのでご注意下さい。
- また、D層（Dao）自動生成機能を使用することで、テーブル単位のCRUD部品が生成できる。
これにより、更新系処理（テーブル単位）のデータアクセスは全て部品化できる（大量データの追加・更新・削除は別途）。
工程別工数比率 †
全工程の40％程度
※プログラミング工程は、単体テスト工程を含む。
削減工数の例 †
- 最小で10%の工数削減が可能。
- 大規模案件になればなるほど大きくなるプログラミング工程の工数を削減できる。
テスト工程 †
工数削減根拠 †
- 以下を利用しテスト工程の効率向上が可能。
- デバッグログ
- アクセストレースログ
- SQLトレースログ
- 共通化により、
- プログラムの修正が容易。
- ビジネス・ロジックの実装に専念できる。
工程別工数比率 †
全工程の30％程度
削減工数の例 †
- 最小で10%の工数削減が可能。
- 大規模案件になればなるほど大きくなるテスト工程の工数を削減できる。
生産性向上効果の計算 †
新規開発時 †
40.0人月のアプリケーション開発工数に対して、5.0人月 (≒12.5%前後)程度の工数削減が可能。
- 設計工数（全体工数の3割 = 12.0人月）のうちの
アーキテクチャ設計工数である2.0人月程度の工数を削減可能
アーキテクチャの決定、プロジェクト・テンプレートの開発、共通部品の開発に関わる工数。
- 開発・テスト工数（全体の7割 = 28.0人月）の10.0%程度の工数を削減可能
- プロジェクト・テンプレートに準拠した開発、制御の反転（IoC）による共通化。
- 共通部品の再利用、データアクセスの自動生成、開発支援ツールによる生産性向上。
- 10.0%は、開発・テスト工程のステップ生産性で、2.1 KS/人月 → 2.3 KS/人月程度のインパクト
-----------------------------------------------------------
e.g.：40人月の案件を例に取ると、従来と比べ5人月前後の工数削減が可能。
-----------------------------------------------------------
2.0人月 + ( 40.0人月 * ( 0.4 + 0.3 ) * 0.1 ) ≒ 5.0人月 (≒12.5%前後)の工数削減。
# 電卓への入力式：[削減工数]人月 = [削減アーキテクチャ設計工数]人月 + ([適用前工数]人月 * ( 0.4 + 0.3 ) * 0.1)
-----------------------------------------------------------
※ 適用前工数とは、Open棟梁を適用しなかった場合のアプリケーション開発工数。
マイグレーション時 †
- 定義: マイグレーション ≒ ストレート・コンバージョン（.NETバージョンアップ）。
- マイグレーションの一般的な見積もりは以下の通りですが、
- コチラに書いたように、Open棟梁を使用して開発したアプリケーションの
P層以下のB層・D層のポータビリティは高く、簡単に移行することができます。
- マイグレーション ≒ ストレート・コンバージョンの生産性
- スコープ（特にテスト部分）に依存することが多い。
- 疎通確認までの範囲なら、.NETの高い下位互換性のため、
殆ど工数がかからないケースも多く、その場合、新規開発のｎ倍以上になる。
再構築時 †
- 既存パッケージやシステムの再構築に利用したケースが何個かアリ、
既存の設計・チェックリストの再利用と、ビジネス・ロジックの流用ができるので、
生産性の実績値は新規開発の２倍以上になることを確認しています。
- 工程別工数比率 ( 設計 : 開発 : テスト = 3 : 4 : 3 ) から、
- 設計の再利用のため、設計工数（全体工数の3割 = 12.0人月）。
- ビジネス・ロジックの流用のため、開発工数（全体工数の4割 = 16.0人月）の一部。
- 開発工数4割の内訳として、プログラミング : テスト = 3 : 1 程度になる。
- テスト自体は通常通り実施、プログラミング工数を1/2に削減できたとする。
- すると、この場合、開発工数は、全体工数の1.5割 = 6.0人月の工数を削減できる。
- 設計・チェックリスト・ビジネス・ロジック再利用のため、
テスト工数（全体工数の3割 = 12.0人月）の半分 = 6.0人月の工数を削減できる。
を削減した値に近似するため、実績値は、新規開発の2倍以上になります。
-----------------------------------------------------------
e.g.：40人月の案件を例に取ると、新規開発と比べ24.0人月前後の工数削減が可能。
-----------------------------------------------------------
(40.0人月 * 0.3) + (40.0人月 * (0.3 / 2)) + ((40.0人月 * 0.3) / 2) ≒ 24.0人月 (≒ 60.0%前後)の工数削減。
# 電卓への入力式：[削減工数]人月 = [新規開発時工数]人月 * ( 0.3 + (0.3/2) + (0.3/2) ))
-----------------------------------------------------------
移行手順 †
手順としては、
Open棟梁のテンプレートがあるので、
- それを案件ごとカスタマイズし、
- そこに既存のビジネス・ロジックを移植していく
というカタチになります。
マイグレーション時の場合と比べると、再構築はコードの移植・修正と、そのテスト工数が余分にかかりますが、
新規開発時と比べ、２倍以上の生産性が出るので、再構築が必要なケースでは適用する価値があります。
参考 †
定性的効果 †
本ページでは、QCDに対応する効果を説明していますが、
KPIとしては、QCD"F", 規格/標準, サポート力, ブランド認知などがあると考えています。
業務系ソフトウェア開発の生産性についての話 †
事例 †
大林組 営業情報システム再構築 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
