アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要
オージスさんのアジャイル開発の事例を見ていたら、アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要という指摘があって面白かった。
考えたことをラフなメモ書き。
【元ネタ】
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で計測できれば、過去の計測データを用いて、かなりの精度で見積りができるはず。
アジャイルに開発するには、要求が変化するにも関わらず、優れたモデリング能力と見積り能力が必要になるという指摘が面白い。
| 固定リンク
「モデリング」カテゴリの記事
- 自動車の組込ソフトウェア開発が難しい理由は3つある(2026.02.23)
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- 製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか(2026.02.04)
- プ譜でプロジェクトの目的を管理する(2026.01.31)
「ソフトウェア工学」カテゴリの記事
- 自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か?(2026.02.15)
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
「Agile」カテゴリの記事
- PMPとCSM取得者数推移(日本 vs 中国)から読み取れる指針は何か?(2026.02.23)
- SAFeはScrumと全く異なるアジャイル開発プロセスだ(2026.02.01)
- 第29回東京Redmine勉強会の感想~今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet(2025.11.09)
- RedmineJapan vol.4の感想part1~Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan(2025.07.31)
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)


コメント