アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要
オージスさんのアジャイル開発の事例を見ていたら、アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要という指摘があって面白かった。
考えたことをラフなメモ書き。
【元ネタ】
OGIS Scalable Agile Method の真髄(前編)
OGIS Scalable Agile Method の真髄(後編)
ざっくり読んだ感じでは、RUPをベースにオブジェクト指向設計に基づいたモデリングを行い、反復型開発でシステムを構築していくような開発スタイルを提唱している。
オージスさんはオブジェクト指向設計の老舗であり、モデリング力があるからこそ、アジャイル開発にオブジェクト指向設計を組み合わせた開発スタイルを提唱できるのだろうと思う。
興味深い点は、アジャイル開発のように、契約時の要件が固まっていない場合、「発生する変更の規模を測定する」考え方から見積りを行う点だ。
(引用開始)
機能規模測定手法を用いて、スコープの変化を許容するソフトウェアの調達方法としては southernSCOPE [12] というものが提案されています。この方法は、オーストラリアのヴィクトリア州における情報システムの調達において開発されたものです。
southernSCOPE の実行手順は以下のとおりです。
(1)ソフトウェアを調達する際に、顧客はスコープマネジャーを雇う
(2)スコープマネジャーは、FP (Function Point) 法により初期の費用とスケジュールを見積もる
(3)顧客は、機能概要や制約を記述したRFPを作成し、入札にかける
(4)顧客は、調達先と機能規模あたりの単価に合意する
(5)分析フェーズを実行することで、要求仕様書を作成する
(6)要求仕様書に基づいてスコープマネジャーが機能規模を算出し、顧客は予算とスケジュールを考慮してどの機能が必要かを決める
(7)開発途上での変更について、 スコープマネジャーが費用に対する影響を算出し、顧客と開発者が合意する
(8)開発が完了した時点で、顧客は納品されたソフトウェアと変更に対する費用を支払う
(引用終了)
上記の方法では、設計フェーズを反復しながらモデルを洗練化していき、出来上がったモデルに対し、FP法(ファンクションポイント法)で機能規模を計測する所が重要。
FP法は、InputとOutputのデータの内容が決まれば、そのシステムの規模を測定できるという見積りの仕組み。
FP法は従来から長い歴史があり、計測方法や機能規模に関するデータもたくさん蓄積されているので、持続的に計測できれば、規模見積りに役立つだろう。
更に重要な点は、機能規模をファンクションポイントで客観的に計測できるようなモデルを作る能力があるのが前提だ。
オージスさんのように、長年モデリングに携わって、モデリングの経験が深いからこそ、FP法は生きる。
児玉公信さんの「システム開発の見積りのための実践ファンクションポイント法」では、ER図とDFDからFP法を計測する事例が載っていて、とても勉強になる。
そもそもFP法は、データモデリングと相性が良い。
ER図からテーブルのCRUD表が作れれば、ILF・EIFのようなデータをすぐに洗い出せるし、ILF・EIFを参照・出力するようなプロセスを考えれば、FP法ですぐに計算可能だからだ。
オブジェクト指向設計はおろか、DFDやER図をまともに書けないようでは、FP法で計測することすらできないだろう。
個人的には、DOAを標榜する人達は何故、自分たちが作ったモデルに対してFP法で機能規模を見積もる手法を展開させなかったのか、不思議だ。
そもそも、モデルをシステム提案という早い段階から設計する理由の一つは、ざっくりでもいいから、早めにシステムの規模を見積り、開発コストを見積りたいからだ。
だからこそ、優れたモデリング能力があれば、曖昧な要求からある程度のモデルを導くことができるので、FP法で即座に見積りできるはず。
機能規模をFPで計測できれば、過去の計測データを用いて、かなりの精度で見積りができるはず。
アジャイルに開発するには、要求が変化するにも関わらず、優れたモデリング能力と見積り能力が必要になるという指摘が面白い。
| 固定リンク
「モデリング」カテゴリの記事
- リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか?(2026.04.08)
- すり合わせの優位性は健在か?日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実(2026.03.29)
- アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か(2026.03.23)
- アーキテクチャモダナイゼーションとはそもそも何なのか?(2026.03.22)
- 自動車の組込ソフトウェア開発が難しい理由は3つある(2026.02.23)
「ソフトウェア工学」カテゴリの記事
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmineはチェンジマネジメントのツールであるべきだ(2026.07.13)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
「Agile」カテゴリの記事
- 製造業の工程管理の課題とアジャイル化の壁(2026.07.12)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
- 製造業アジャイルの事例リンク(2026.07.08)
- プロセスには「学習のループ」が必要だ(2026.06.20)
- 自動車・半導体・防衛産業から読み解く、業界を制する設計思想(2026.06.10)


コメント