情報システム開発手法に関する評価モデルの開発cocomo（constructive cost...

名古屋学院大学論集　社会科学篇　第 44 巻　第 1 号（2007 年 7 月）

― 17 ―

１．緒　言

　厳しい企業間競争の進展とともに，企業組織

では競争優位を支援する情報システムに多くの

期待が寄せられ，その導入・更改に寄与してい

るソフトウェア開発業界の役割が一層重要に

なっている。しかし，開発途中での仕様変更の

多発，品質確保および工期の短縮化に代表され

る3つの問題は，ソフトウェア開発企業の経営

に大きな影響を及ぼしかねなくなっている。

　開発途中での仕様変更の多発は，機能要件が

明確に定義できないことに原因であり，そのた

め再設計を伴う手戻りを頻発させる。また，品

質確保の難しさは，情報システム開発が人的な

手作業を伴うというソフトウェアの特徴に由来

していること，さらには，ノウハウの蓄積より

もソフトウェア技術の進展の速度が上回ってい

ることにも原因がある。工期の短縮化は，開発

対象の情報システムを早期に活用して業務効率

を向上させたいという顧客ニーズによるもので

ある。

　仕様変更が発生すると，製造がやり直されて

品質試験の期間が圧迫され，その結果，品質確

保が十分でない状態で顧客に納入される。また，

新しい技術の導入やオープンシステムへの移行

は，まだ安定稼動の実績が乏しいため，不具合

が発生する確率は高くなり，仕様変更に戻させ

ることもある。さらに，工期の短縮化も仕様変

更への対応を難しくし，かつ試験期間の短縮化

による品質確保が懸念される。これらの問題は

それぞれが絡み合い，解決を一層困難なものに

している。

　最近，個人と組織の力を活用するアジャイル

手法などの新たな開発手法 1）～ 3）が注目されて

いるのも，これらの問題を従来のソフトウェア

開発手法であるウォーターフォール（WF）手

法で解決することは容易でないためである。し

かし，これらの新たな開発方法の採用を決断す

るにはその判断材料に不明な点が多いのが現状

である。

　本論文は，あるソフトウェア開発企業のプロ

ジェクトにおける開発手法の選択に関して開発

企業と顧客との相互理解による開発手法に関す

る評価モデルの開発 4）を試み，適用事例と経営

に対する効果を考察した。

２．情報システム開発に伴う問題と新しい

試み

2.1　情報システム開発に伴う問題

（1）　仕様変更による手戻り

　経済産業省の調査 5）では，仕様変更が原因

で，再設計，再コーディングおよび再試験を発

生させる手戻りの頻度に関して，「手戻りなし」

3.2％に対し，「手戻り率20％以上」が全体の

40%にも達している実態が明らかにされてい

情報システム開発手法に関する評価モデルの開発

尾　崎　都司正

三　島　映　人＊

＊NTTアブリエ

― 18 ―

名古屋学院大学論集

る。近年，基幹システムにみられるようには情

報システム開発の規模が大きくなり，大規模な

情報システム開発ほど要件定義や設計の難易度

が高いことから手戻りのリスクも大きくなって

いる。

　仕様変更による手戻りが発生する原因として

は，主管となって仕様を取りまとめる顧客側の

体制・能力不足の問題や，システムの利害関係

者とのコンセンサスが十分でないことがあげら

れる。また，概要的・大枠・曖昧なことが多い

開発初期における顧客の要望を的確にまとめあ

げる受託者側の経験・スキル不足にも原因があ

る。さらに，完成しつつある情報システムを見

て顧客の気が変わり，仕様変更を要求されると

いう突発的な原因もある。

　仕様変更による手戻りは，開発プロジェクト

全体のスケジュールに遅れを発生させ，十分な

試験工程を経ないため新たな問題を発生させる

こともある。複雑かつ変化の激しい企業競争の

もとでは，仕様凍結は現実的に不可能であり，

手戻りの発生を許容するが，その頻度を低減さ

せる仕組みを整えることが必要である。

（2）　品質確保の難しさ

　情報システムの品質の定量化は困難である

が，監査の段階では設計書とプログラムの整合

性を相互にチェックすることによって品質を確

保することが理論的に可能である。しかしなが

ら，開発段階を過ぎた監査では，新たに監査の

ための時間と監査を厳密にする上でプログラム

技術の両方が要求されるため，この方法は実用

的ではない。

　品質測定方法としてレビュー結果の分類やレ

ビュー評価，さらには品質特性の分類法として，

「ISO/IEC9126」6）があるが，前者も監査の段階

での対応であり，後者は項目が多く，抽象的で

あるため，共に実用には供しがたい。

　一方，オープンシステムへの移行も品質確保

を難しくしている。すなわち，ソフトウェアの

動作環境に対応して広範囲の試験と情報技術の

互換性が必要されるオープンシステムは，現在

の技術レベルではこれらの互換性も完全ではな

図 2.1　システムの規模と管理・技術の複雑度の関係7）


― 19 ―

い。また，新しい登場するソフトウェア技術に

対する安定稼動の実績や技術熟練度の不足とい

う問題もある。

　橋本 7）は，平均的な情報システム開発の規模

を人数5 ～ 10人，期間10 ～ 15 ヶ月と設定し

て情報システムの開発規模を「管理の複雑さ」

と「技術的な複雑さ」の2つの要因で分類して

いる。「メンバーが地理的に離れて作業を行う」，

「開発対象の新規性が高い」などの条件が絡む

と品質確保が一層難しくなるが，この分類は品

質管理の凡その目安となる。このようにシステ

ム監査の段階よりも，開発時に品質確保ができ

る方法が求められている。

（3）　工期の短縮化

　顧客の戦略やビジネス上の都合によって工期

を短縮しなければならないこともあるが，企業

IT動向調査 8）でも，61%がシステム開発にお

ける工期が短くなったとの回答もあり，競争優

位・競争力確保の観点から顧客がビジネス環境

の変化に迅速に対応したいという要望の表れと

みられる。

　しかし，工期の短縮は，開発中の情報システ

ムの品質の低下の可能性を高めるだけでなく，

手戻りが発生すれば，工期を守ることで手一杯

となり，品質確保ができない事態を生じさせ

る。ソフトウェア開発は労働集約型の部分が多

く，こなすべき仕事量を[人]と[月]のみでカ

バーしようとすると，F. Brooksの指摘 9）のよ

うに「仕事の各部分とそれ以外の部分とを個別

に調整する仕事」が考慮されず，事態をさらに

悪化させることになる。

　工期は見積もり時に決定されるが，

COCOMO（Constructive Cost Model）法や

ファンクション・ポイント法ファンクション・

ポイント法などが見積もり手法として用いられ

ているが，正確な見積もりによる工期を算出す

ることは難しい。したがって，見積もり精度の

追求ができないことを前提にした柔軟な開発法

が必要とされている。

2.2　情報システム開発手法と工夫事例

（1）　情報システム開発手法の特徴

　最近，多くの開発手法が提唱されているが，

本論文で対象にする情報システム開発手法とそ

の特徴を略記する。

a．ウォーターフォール手法（Water Fall

Model）

　プロジェクトマネジメントが行いやすい手法

であるが，一方で，近年の仕様変更による手戻

り，品質確保の難しさ，工期の短縮化への対応

は難しい。

b．RUP手法（Rational Unified Process）

　反復型開発で小規模リリースを繰り返すこと

により全体的にシステムを構築していく手法で

ある。重要な機能やリスクの高い機能を優先的

に開発することにより，手戻りの発生や致命的

な問題の発生を低下させることができる。

c．XP 手法（Extreme Programming Proc-

ess）

　チームのコミュニケーションを活性化させる

ことにより，開発メンバーがモジュール構成や

内部設計，進捗状況や負荷の把握，リスクや問

題などを共有することを重視し，RUP手法よ

りも変化に柔軟性がある。

　このように開発手法には長所短所があり，開

発する情報システムの特徴にあわせて開発方法

を選択することが望ましい。

（2）　情報システム開発の工夫事例 4）

　情報システム開発におけるいくつかの工夫事

― 20 ―


例をあげ，開発プロジェクトの成否を分ける要

因を分析する。

a．事例1: S社Bプロジェクト

　S社のBプロジェクトは要求定義工程が3 ヶ

月のところ，顧客の要望を優先して工期2 ヶ月

として開始した。ウォーターフォール手法に

よって設計が行われ，コーディング工程で外部

設計に戻る事態が一部生じた。追加投入が3名

のところ，1名のみであったため，スケジュー

ルの遅れを試験期間の短縮で対応することに

なった。

　プロジェクトリーダーは，「工期が短いため，

品質に問題が発生する可能性があり，納品後

1 ヶ月間を試用期間として，その後に実運用を

開始したい」と提案し，顧客と合意して，品質

問題を試用期間中に解消した。このような対応

は，情報システム開発が双方の協働作業である

と認識する場合に限定されるが，試用期間とい

えども開発システムを安全に利用することがで

きなくなるため，理想的な対応とはいえない。

b．事例2: C社Mプロジェクト

　C社はシステムインテグレータであり，Mプ

ロジェクトも大規模システム開発である。この

プロジェクトはメンバーが100人規模で1年弱

の初期開発の後，実運用が開始され，5年以上

の運用の中で積極的にバージョンアップを繰り

返している。C社は大規模システムの開発経験

が長く，分業体制でプロジェクトを進めるだ

けでなく，開発手法もRUP（Rational Unified

Process）に移行し，Java言語による3階層

Webモデルやクラスタリングなどの高度な技

術を採用しても高品質かつ比較的短期間に納め

るノウハウをもっている。このプロジェクトも，

年に数回の機能追加・バージョンアップを繰り

返しているが，顧客側と開発側とのJAD（Joint

Application Design）によって仕様の確認と合

意をおこない手戻り防止を図っている。

c．事例3: 富士通コミュニケーションシステ

ム例 10）

　富士通コミュニケーションシステムのXP手

法の導入事例である。この事例ではXP手法は

提唱されて日が浅く，研究事例も少ないXP手

法の成果比較がなされている。従来はネット

ワーク監視制御用ソフトウェアをウォーター

フォール手法で開発していたが，ビジネス環境

の急変に対する顧客ニーズに対応するためXP

手法を適用した。ペアプログラミングを全開

発規模の21%に適用しており，2人以上のコー

ディングであっても単純に2倍の工数とはな

らず1.55倍となり生産性が向上している。「設

計」，「製造」，「試験」の工数は増加しているが，

システム試験（総合試験）において検出バグが

減少し，逆に，総工数は19%削減している。

　事例1はプロジェクトリーダーの判断で事後

対応を図った典型的な例である。品質確保のた

めに連日過酷な勤務状況が続くと，ミスはミス

を呼んでペナルティを科せられるケースもあ

り，信用を著しく失墜させることにもなる。こ

の事例では，変化に弱いウォーターフォール

手法を用いていたこと，さらに，F. Brooksの

指摘のようにこなすべき仕事量のみに注力して

[人]と[月]でカバーする考え方から脱却して

いない点も改善しなくてはならない。

　事例2は，一般に最も難しいと考えられる大

規模システム開発で，常時稼働におけるハイア

ベイラビリティの実現と，工期の遵守が行われ

ている要因として，進捗管理，問題管理，チー

ムの分業体制と統制およびプロジェクト管理の

適切性があげられる。また，変化に強いRUP

手法を用いた反復型開発や，JADによる要所で

の仕様合意なども無視できない要因である。事

例3では，メンバーによるリスクや問題などを


― 21 ―

共有した開発方法は，結果的に生産性を高める

ことを示している。

　これらの事例から，システム開発には，手戻

りは不可避であり，それを前提として，個人と

組織を中心にした開発方法が重要であることを

示唆していると考えられる。

３．情報システム開発手法の評価モデル

3.1　評価項目

（1）　開発手法の選択の条件

　ソフトウェア開発においては，ウォーター

フォール手法の利用が一般的であるが，新たな

開発への選択肢が広がり，それらを適材適所で

選ぶことにより，難しいプロジェクト 11）への

対応力を高めることが可能となっている。した

がって，（1）仕様変更による手戻りや（2）品

質確保の難しさ（3）工期の短縮化を図るには，

ノウハウが得られるまでのリスクの考慮と，プ

ロジェクトの特徴や手法の長所短所に合わせて

開発手法を選択することが望ましい。

　本研究では，選定対象とする開発手法を

ウォーターフォール手法，RUP手法およびXP

手法とし，開発プロジェクトごとに開発手法を

選択するため次のような条件を設定する。

条件1．複数の要素によってプロジェクトの

評価を行う。

条件2．複数の要素は，それぞれの重みに

よって評価を行う。

条件3．開発手法の特性とノウハウの程度に

よっても評価を行う。

　条件1は，品質・工期・手法のノウハウの存

在など，複数の要素による評価法を前提とした

ものである。条件2は，プロジェクトごとに評

価要素の重要度が異なり，要素間のトレードオ

フも可能とするものである。最後の条件は，ノ

ウハウの蓄積に応じて開発手法の選択ができる

とするものである。

（2）　評価項目

　条件1を満たす要素を具体的な評価項目とし

て設定する。大規模システム開発にはXP手法

は不向きであることから，ソフトウェア規模を

重要な評価項目とする。さらに，前節の事例で

も明らかなように，情報システム構築の短縮化

（短納期）も評価項目として選定する。

　また，システム要件を満たすために新技術を

利用しなければならない開発プロジェクトもあ

る。あるいは既存の技術であっても高度かつ複

雑な処理が予想され，コーディングしなければ

処理が予測できないなど，技術的な不安要素・

リスク（技術難）が大きい開発プロジェクトも

ある。このような場合，プロジェクト初期段階

で技術的に問題がないことを確認し，リスクが

クリアされなければならないので技術難も評価

項目とする。なお，技術的な難易度と似た要素

として，開発要件の難しさがある。ビジネスプ

ロセスの新規性が高かったり，BPR（Business

Process Reengineering）と開発プロジェクト

が並走する場合，初期段階ではビジネスプロセ

スが見えなかったり，例外的なビジネスプロセ

スが多数ある場合などのシステム化要件を明確

化できないことがあり，要件難を評価項目とす

る。

　さらに，開発対象の情報システムが社会のイ

ンフラであったり，ミッションクリティカルシ

ステムである場合，信頼性が何よりも優先され，

不安定な技術は排除されるので高品質も評価項

目に加え，開発手法の選択要素の選択として5

つの評価項目を設定する。

― 22 ―


3.2　開発手法選択評価モデルの考え方

　評価を手法と評価項目のマトリクスで表し，

ポイントを加算する方法が考えられるが，評

価項目間の重みの表現が曖昧であるため条件

2に対応することができない。要素の重みを正

しく表現できるツールとして，AHP（Analytic

Hierarchy Process：階層分析法）12）と，その発

展形であるANP（Analytic Network Process）15）

が最適と考えられるので，これらのツールを用

いて条件1 ～ 3を満たす開発手法選択評価モデ

ルを提案する。

（1）　第1ステップ

　図3.1に示した評価項目を用い，開発プロ

ジェクトの特徴から開発手法を選択する。受託

側が要件定義の段階で発注側（ユーザー側）か

ら開発システムの特徴ヒアリングにより引き出

し，その結果をもとにして，開発手法の選択判

断を行う。（図3.2）

　この結果から開発手法の順序づけができる

が，プロジェクトが失敗するリスクが高い場合

でもノウハウの蓄積が無い開発手法が選択され

る場合が生じる。例えば，ウォーターフォール

手法のノウハウだけしかもっていない場合に，

RUP手法やXP手法の優先順位が高くなること

もある。プロジェクトの失敗が懸念される状況

での優先順位が高くなる矛盾を解消するため次

のステップを追加する。


　プロジェクトが抱えるリスクへの対応を優先

すべきか，手法のノウハウ取得を優先すべきか

判断し，開発手法を選択する。この評価は，顧

客と開発側とのバランスをとるものであり，開

発手法の側からも評価項目を比較検討すること

が重要であるため，ANPを利用する。（図3.3）


　第1ステップと第2ステップの双方の判断を

AHPにあてはめ，総合的な判断をする。（図3.4）図 3.1　選択要素の抽出

図 3.2　プロジェクトの特徴から開発手法を選択する階層構造


― 23 ―

４．評価モデルの利用例

4.1　D社の経営状況と問題の設定

（1）　D社の経営状況

　D社は社員数170名に加え，開発プロジェク

トの期間・規模にあわせて外部の人材を年間

200名以上活用している。情報システム開発を

事業の柱とし，その他にハードウェア販売，コ

ンピュータネットワークソリューション，他

のソフト開発企業への人材派遣（業務委任契

約：SES契約），および大口顧客として親会社

の開発請負を行っている。年間売上高は約44

億円であり，売上高に占める経常利益の比率は

1.18％であり，DEA法による経常利益効率性

は，同業他社10社とくらべても優位とはいえ

ない。

　経常利益効率性が低い要因は，技術力や製品

力で他社に対して優位性や強みが少なく，製造

コストが大きい点にある。したがって，競争優

位性の強化と製造コスト削減が焦眉の課題と

なっている。このため，従来のウォーターフォー

ル手法の延長では生産性の向上を図ることは容

易でないと考え，情報システム開発手法の改革

を行うことにした。

（2）　問題の設定

　D社は長年ウォーターフォール手法を用いた

開発を行っている。ただ，短期の開発プロジェ

クトの増加への対策として，RUP手法やXP手

法などの新たな開発手法を機会があれば利用す

るという意向をもっている。ある顧客から新規

の情報システム開発が依頼され，要件定義とヒ

アリングを実施したところ，プロジェクトの特

徴は以下のとおりであった。

図 3.3　開発手法を選択する階層構造

図 3.4　総合的な判断をする階層構造

表 4.1　経常利益効率

DMU A B C D E

効率値 0.742 1.000 0.123 0.097 0.236

F G H I J

0.168 0.537 0.098 0.065 0.026

・小規模システム

・高信頼性が必要

・要件の似たシステム開発経験なし

・新しい技術でシステム化が可能

・納期に余裕あり

― 24 ―


4.2　評価モデルの計算例


　図3.2に示したレベル2に関して，列の評価項

目に対する行の評価項目の一対比較行列におけ

る最大固有値に対する固有ベクトルを求める。

通常の固有ベクトルはノルムが1であるが，AHP

では正規化して和を1にするところから，固有ベ

クトルと成分の比率は同じであるが混同するた

めウエイトと表記する。得られたウエイトは，

0.15以下であり整合性も良好である。（表4.2）

　次に，レベル2を評価基準にしてレベル3に

おける代替案（手法）の一対比較を繰り返す。

代替案の一対比較でも整合度は0.15以下であ

り，評価結果は妥当と考えられる。したがって，

効用関数の加法性を用いて開発プロジェクトの

特徴の観点からのウエイトを求める。

　開発プロジェクトの特徴を観点として判断さ

れた優先順序は，RUP（0.396）＞XP（0.366）＞

WF（0.238）となる。

表 4.2　評価項目間の一対比較

λmax ＝ 5.22　C.I ＝ 0.055

大規模要件難技術難高品質短納期ウエイト

大規模 1 1/2 1/2 1/2 2 0.155

要件難 2 1 1 1 1 0.221

技術難 2 1 1 1 2 0.250

高品質 2 1 1 1 1 0.221

短納期 1/2 1 1/2 1 1 0.153

― 24 ―

0.4290.4290.143

0.1430.4290.429

0.1430.4290.429

0.4000.4000.200

0.1050.2580.637

0.1550.2210.2500.2210.153

0.238＝ 0.396

0.366

表 4.4　代替案の一対比較

λmax ＝ 3　C.I ＝ 0

要件難 WF RUP XP ウエイト

WF 1 1/3 1/3 0.143

RUP 3 1 1 0.429

XP 3 1/3 1 0.429


λmax ＝ 3　C.I ＝ 0

技術難 WF RUP XP ウエイト

WF 1 1/3 1/3 0.143

RUP 3 1 1 0.429

XP 3 1/3 1 0.429


λmax ＝ 3　C.I ＝ 0

高品質 WF RUP XP ウエイト

WF 1 1 2 0.400

RUP 1 1 2 0.400

XP 1/2 1/2 1 0.200


λmax＝3.04　C.I＝0.019

短納期 WF RUP XP ウエイト

WF 1 1/3 1/5 0.105

RUP 3 1 1/3 0.258

XP 5 3 1 0.637


λmax ＝ 3　C.I ＝ 0

大規模 WF RUP XP ウエイト

WF 1 1 3 0.429

RUP 1 1 3 0.429

XP 1/3 1/3 1 0.143


― 25 ―

　開発手法の選択基準の重みをXとし，超行列

にすると，

となる。したがって，lim X 2k＋1＝X＊

k →∞ を求めると，

が得られる。

　よって，開発プロジェクトのリスクとノウハ

ウ蓄積の観点から判断された選好順序は，XP

（0.529）＞RUP（0.289）＞WF（0.182）となる。


第1ステップではプロジェクトの特徴での評

価，第2ステップではリスクに対する評価であ

り，第3ステップは総合化であり，これらの評

価項目に関して一対比較を行う。（表4.14）

　開発手法の選択手法の重みを Xとすると，


　図3.2に示したレベル2における評価項目間

の一対比較を行う。2行2列の場合には最大固

有値は2であり，完全整合となる。正規化した

ウエイトは「手法・ノウハウを蓄積する」が高

く，小規模開発プロジェクトに対する姿勢が窺

われる。（表4.8）

　次に，評価項目に対する各手法の評価を行

う。（表4.9 ～ 4.10）

　さらに，代替案からみた評価項目の一対比較

を行う。（表4.11 ～ 4.13）

表 4.12　評価項目の一対比較

RUP リスクノウハウウエイト

リスク 1 1/7 0.125

ノウハウ 7 1 0.875


XP リスクノウハウウエイト

リスク 1 1/7 0.125

ノウハウ 7 1 0.875

― 25 ―

X ＝

00.1250.875

000

000

0.6590.1560.185

000

0.1090.3090.582

00.1670.833

000

00.1250.875

000

00.1250.875

000


λmax＝3.03　C.I＝0.015

リスク WF RUP XP ウエイト

WF 1 5 3 0.659

RUP 1/5 1 1 0.156

XP 1/3 1 1 0.185

X＊＝

00.1330.867

000

000

0.1820.2890.529

000

0.1820.2890.529

00.1330.867

000

00.1330.867

000

00.1330.867

000


リスクノウハウウエイト

リスク 1 1/7 0.125

ノウハウ 7 1 0.875


λmax ＝ 3　C.I ＝ 0

ノウハウ WF RUP XP ウエイト

WF 1 1/3 1/5 0.109

RUP 3 1 1/2 0.309

XP 5 2 1 0.582


WF リスクノウハウウエイト

リスク 1 1/5 0.167

ノウハウ 5 1 0.833

― 26 ―


効用の加法性をもちいると行列の積で表すこと

ができるから，

　よって，総合的な選好順序は

XP（0.407）＞RUP（0.369）＞WF（0.224）となり，

このプロジェクトにおいては，XP手法が適切

と判断される。

4.3　経営への影響

（1）　中規模システムへの適用例

　前節では小規模システムを例に問題の設定を

行ったが，現実的には中規模システムの開発プ

ロジェクトが多いことから，競争優位や生産性

の向上を図るためRUP手法やXP手法などの新

たな開発手法の適用の可能性を探る。

　問題設定

　新規情報システム開発の要件定義とヒアリン

グを実施したところ，プロジェクトの特徴は以

下のとおりであり，D社はウォーターフォール

手法を採用したのは妥当であるか。

　第1ステップの評価項目間のウエイトは，図

3.2に示す5つの評価項目の一対比較で得られ，

その整合性も良好である（表4.15）。次に，評

価項目に対する手法のウエイトに関して，前節

の評価結果と異なるのは「大規模」と「高品質」

のみであり，それらの一対比較の結果を示す。

（表4.16 ～表4.17）

　第1ステップでの開発手法に関しては，線形

効用和を適用することによって

表 4.14　総合評価の一対比較

総合判断特徴リスクウエイト

特徴 1 3 0.750

リスク 1/3 1 0.250

・中規模システム

・高信頼性が必要

・要件が似たシステム開発経験あり

・開発経験のある技術でシステム化が可

能

・納期に余裕はないが妥当だと推測され

るスケジュール

X ＝WF 0.238 0.182

0.7500.250

0.224RUP ＝ 0.396 0.289 ＝ 0.369XP 0.366 0.529 0.407

X ＝0.4550.4550.091

0.1430.4290.429

0.1430.4290.429

0.4290.4290.143

0.1050.2580.637

0.2240.0860.0800.3250.265

＝

0.3020.3900.308

表 4.16　代替案間の一対比較

λmax ＝ 3　C.I ＝ 0

大規模 WF RUP XP ウエイト

WF 1 1 5 0.445

RUP 1 1 5 0.445

XP 1/5 1/5 1 0.091


λmax ＝ 3　C.I ＝ 0

高品質 WF RUP XP ウエイト

WF 1 1 3 0.429

RUP 1 1 3 0.429

XP 1/3 1/3 1 0.149

表 4.15　評価項目間の一対比較

λmax ＝5.29　C.I ＝ 0.072

大規模要件難技術難高品質短納期ウエイト

大規模 1 2 3 1 1 0.244

要件難 1/2 1 1 1/5 1/3 0.086

技術難 1/3 1 1 1/5 1/3 0.080

高品質 1 5 5 1 1 0.325

短納期 1 3 3 1 1 0.265


― 27 ―

で求められる。

　第2ステップにおいても評価項目間の一対比

較を行う。

　開発手法の選択基準の重みをXとし，超行列

にして，lim X 2k＋1＝X＊

k →∞ を求めると，

となる。同様にステップ3についての評価を行

うと，X ＝0.302 0.587

0.3330.667

0.4920.390 0.194 ＝ 0.2590.308 0.219 0.249

であり，総合的な選好順序は

WF（0.492）＞RUP（0.259）＞XP（0.249）を得る。

　このプロジェクトにおいては，ウォーター

フォール手法が適切であると判断され，D社の

意思決定は妥当であるといえる。

（2）　開発手法改革とその効果

　情報システム開発も不確実性が高く，プロ

ジェクトマネジメントを強化し，旧来の開発手

法から新たな開発手法に移行することが必要性

である。これらの開発手法は改革であり，周到

な準備や関係者の理解を得て取組まなければ工

期や品質に関わるビジネス上のリスクを伴う。

したがって，本評価モデルを用いながらリスク

の少ない小規模な実践によってノウハウ蓄積を

進める必要がある。

　D社が関係者の理解を深めながら，手法のノ

ウハウ蓄積やテーラリングを進めたとき，経営

に与える具体的な転換効果を考察する。

　情報システム開発業務で対象となるのは，「設

計」「製造」「試験 /総合試験」「運用 /保守」の


λmax ＝ 3　C.I ＝ 0

ノウハウ WF RUP XP ウエイト

WF 1 1/3 1/3 0.143

RUP 3 1 1 0.429

XP 3 1 1 0.429


WF リスクノウハウウエイト

リスク 1 5 0.833

ノウハウ 1/5 1 0.167

RUP リスクノウハウウエイト

リスク 1 9 0.900

ノウハウ 1/9 1 0.100

XP リスクノウハウウエイト

リスク 1 9 0.900

ノウハウ 1/9 1 0.100


リスクノウハウウエイト

リスク 1 7 0.875

ノウハウ 1/7 1 0.125

X ＝

00.8750.125

000

000

0.6590.1560.185

000

0.1430.4290.429

00.8330.167

000

00.9000.100

000

00.9000.100

000

表 4.21　総合評価の一対比較

総合判断特徴リスクウエイト

特徴 1 1/2 0.333

リスク 2 1 0.667

X＊＝

00.8610.139

000

000

0.5870.1940.219

000

0.5870.1940.219

00.8610.139

000

00.8610.139

000

00.8610.139

000

― 28 ―


工数削減であり，富士通コミュニケーションシ

ステムでは19％の工数削減が示されている。D

社のスキルを考え，最小値として25％工数削

減できることを想定した。S社の実績から全プ

ロジェクトのうち30％のプロジェクトが工数

削減対象，人件費の割合を売上高の85％とす

る。

　D社全体からみた人件費の削減率は6.8％と

なり，費用の減少により経常利益は52百万か

ら262百万円に増加する。加えて，稼働削減分

による売上獲得を推定すると259百万円が見込

まれ，経常利益も18百万円の増加となる。

　総合的には売上高が4415百万円から4674

百万円に，経常利益は52百万円から280百万

円に，利益率は1.18％から5.99％に改善される

ことが予測できる。

５．検討と考察

5.1　評価モデル

（1）　評価手法

　開発手法の選択は情報システム開発企業に

とって重要な意思決定であるが，本評価モデル

のような評価方法は提案されていない。本評価

モデルは，開発プロジェクトの特徴に即した開

発手法を選択するものであり，基本的には第1

ステップのAHP評価で終了する。しかし，開

発手法でのリスクが高い，あるいはノウハウが

不足している場合には，得られた評価に基づき

開発手法を採用することは危険である。このた

め，第2ステップではプロジェクトのリスクを

優先的にするか，将来のノウハウ蓄積すること

を優先的にするかをAHPおよびANPをもちい

て判断する。第3ステップで，第1ステップと

第2ステップのウエイトを判断して総合的な評

価をおこなっている。

　問題設定1に対しては第1ステップと第2ス

テップでは順位に逆転があるものの，総合的判

断として，開発プロジェクトの納期に余裕があ

り，新しい手法のノウハウ取得が可能であるこ

と，プロジェクトのリスクが低いことが新しい

手法であるXP手法を選択するべきという評価

に至ったと考えられるなど，慎重かつ安全に評

価できる方法である。

（2）　評価項目

　情報システム開発手法の評価項目は，一義的

に決定されるものではなく，顧客と受託側との

取引関係や，受託側の事情や状況によって選定

されるものである。本研究の対象とした3つの

問題の解消を目的としたが，これらの問題は終

局的に仕様変更の手戻りに帰結すると考えら

れ，仕様変更の要因として，開発規模や開発要

件の難しさ，技術的な難易度と信頼性を重視し

た高品質が評価項目として抽出されたのも当然

といえる。また，直接的ではあるが，納期の選

定も重要な項目としたため，顧客と受託側から

の制約条件を織り込んでいない。しかしながら，

基本的に考慮されるべき評価項目であり，汎用

性はあると考えられる。

　また，これらの5つの評価項目はAHPを適

用する場合にはそれぞれが独立であることが前

提であるが，互いに影響しあっているので絶対

的な評価をすることはできない。また，影響を

考慮した項を追加しても，その評価は不可能に

近い。したがって，一対比較値は影響を受けた

表 4.22　経常利益効率性　推定相対評価

DMU A B C D E

効率値 0.742 1.000 0.123 0.523 0.236

F G H I J

0.168 0.537 0.098 0.065 0.026


― 29 ―

ものであり相対的な評価と捉えれば，これらの

項目をAHPで評価できる。また，本評価モデ

ルは，いずれのステップにおいても評価項目の

追加は可能であり，単純ではあるが，頑強性を

もったモデルとなっているとも考えられる。

（3）　簡易評価法と固有値法

　表4.2のウエイトは固有値法で求めたもので

ある。固有法の代用として幾何平均をとると，

ウエイトは（0.148, 0.224, 0.257, 0.224, 0.148）

となり，固有法と若干の差がみとめられる。し

かし，最終的なウエイト（0.223, 0.370, 0.407）

を得て，簡易評価法と固有値法のどちらの手法

をもちいても本評価モデルでは差はなく，安全

な手法であると考える。

（4）　ANPの適用

　3レベルのAHPでは，評価がトップダウン

になる。ANPの適用事例 16）では，教師と学生

の評価がみられ，評価は双方向である。しかし

本ケースの場合には，評価者が同一ならば第2

ステップにおいては，第2レベルの評価項目の

評価値と，代替案からみた評価項目の評価値は

同じになるはずである。超行列をみるとほぼ同

じ評価値となっている。しかし，常に同じであ

る必要がない。教師側の役割をマネージャーク

ラスが担当し，学生側を手法に詳しい実務者が

担当したとすると，必ずしも評価値はほぼ同じ

になるとは限らない。

　AHPでの一対比較は，半分でよいが，理論

的にはすべてについて行っている。何重にも評

価を行って突出した評価を打消し，全体で無理

なく説明できる点に落ち着く地点が最大固有値

に対する固有ベクトルである。定性的評価を行

う場合，感覚も曖昧になるのは仕方がない。こ

の点で誤差を含んでいるが，多重の比較によっ

てそれらの差を有意なものとしないのがAHP

の特徴であり，ANPでもこの考え方が適用さ

れていて，評価値が異なることの方がむしろ望

ましいと考えられる。

　ところで，Step3の評価を評価項目からみた

場合と，代替案から評価項目をみた場合の評価

項目のウエイトを同一にすると効用の加法性の

同じ結果が得られる。

　このようにANPはやや数学的な技巧に偏る

傾向があるが，従来のAHPの概念を継承した

ものであるということができる。

5.2　経営への影響

（1）　中規模システムへの適用例

　受託側であるソフトウェア開発企業は，利益

を確保するために規模の大きい開発システムを

受注するのは当然であるが，大規模開発の経験

がなく，外部の人材を常時活用しなければなら

いプロジェクトはリスクが大きい。したがって，

中規模システムの受注は飛躍のために重要であ

り，RUP手法やXP手法などの新たな開発手法

によって利益の拡大を図ろうとしがちである。

　しかし，表4.9および表5.4からも明らかな

ようにリスクのウエイトが高く，D社は，この

0ω1ω2

000

000

w11w21w31

000

w12w22w32

0ω1ω2

000

0ω1ω2

000

0ω1ω2

000

2k＋1

＝

0ω1ω2

000

000

ω1w11＋ω2w12ω1w21＋ω2w22ω1w31＋ω2w32

000

ω1w11＋ω2w12ω1w21＋ω2w22ω1w31＋ω2w32

0ω1ω2

000

0ω1ω2

000

0ω1ω2

000

k→∞

― 30 ―


プロジェクトの失敗のリスクも考慮し，従来か

ら利用されノウハウのあるウォーターフォール

手法を選択した。開発手法の選択は情報システ

ム開発企業にとって重要な意思決定であり，慎

重かつ安全に新たな開発手法のノウハウ蓄積を

すすめて移行すべきであるのは当然であり，D

社の意思決定は妥当であるといえる。

　本ケースでは，ウエイトの差が歴然としてい

て優先順位は明確であったが，ウエイトの差が

小さい場合もある。その場合には，上位2つの

方法にのみ代替案を絞って同様のプロセスで本

評価モデルを適用するなどの工夫が必要と考え

られる。

（2）　転換効果

　富士通コミュニケーションシステムでは

19％の工数削減に対して，最小値として25％

工数削減の設定は過大評価と一見感じられる

が，未熟な状態でも良好な結果が得られ，ノウ

ハウ蓄積がなされればさらなる効果が期待でき

ること，「運用 /保守」に関しては工数削減の

データがないが，XP手法でペアプログラミン

グなどが行われればソフトウェアが高品質にな

ることから，この設定には問題がないと考えら

れる。

　詳細なデータをもとに前章では効果を推定し

たが，

4415百万円*85％ *30％ *25％＝281百万円

と大まかな試算によって推定効果をチェックで

きる。通常のソフトウェア開発では，圧倒的に

人件費の割合が高く，一般管理費を除いたもの

をソフトウェア原価とみても大きな誤差は生じ

ない。人件費の削減は，プロジェクトに携わる

外部の人材を軽減することによって達成でき

る。また，社員の負荷の軽減を新たな仕事に当

てることにより，売上も増加する。

　本評価モデルによる効果は，削減が容易な部

分を示唆した手法改革の第一歩であるといえる

が，効果をより強固にするのはプロジェクトメ

ンバーであることを考えると，プロジェクトメ

ンバーの選定評価へと拡充することも必要であ

る。

６．結　言

　本論文は，大手企業の情報部門が子会社化し

た中堅情報システム開発企業のD社を例に，情

報システム開発が抱えている問題の解決策とし

て，新たな開発手法の評価モデルを提案し，そ

の評価結果を経営の視点から考察したものであ

る。

　本研究から得られた結論を述べる。

⑴　情報システム開発における手戻りは不可

避であり，その影響を最小限に止めるよ

うに手法の選択を行う必要があり，本評

価モデルはそれに資するツールである。

⑵　評価モデルにおける評価項目は，状況に

応じて追加し，よりよい情報を得ること

に注意しなければならないが，本評価項

目は基本的なもと位置づけられる。

⑶　評価結果を分析し，関係者の十分な理解

のもとで手法の転換を図るべきであり，

安易な転換は慎まなければならない。

　本研究において提示した一つの情報システム

開発の評価法が情報システム開発企業における

効率化の向上に寄与できることを期待してやま

ない。

　本論文は，名古屋学院大学大学院経済経

営博士課程前期の修士論文の一部であり，第

1 回 JSAHP（JAPANESE SYMPOSIUM ON

ANALYTICAL HIERARCHY PROCESS）にて


― 31 ―

発表したものである。

　参考文献

1 ）畑田成広，樋口博昭，『最新XPエクストリーム

プログラミングの基本と仕組み』，秀和システム，

2002

2 ）Ken Schwaber，『Agile Software Development

with Scrum』，ピアソン・エデュケーション，

2003

3 ）山田正樹，アジャイル開発プロセスとは？，メ

タボリックス，2002，http://www.metabolics.

co.jp/XP/AgileCommentary.html

4 ）三島映人，経営効率化のための情報システム開発

における開発手法評価の一考察，名古屋学院大学

大学院修士（経営学）論文，2005

5 ）組込みソフトウェア開発力強化推進委員会，組込

みソフトウェア産業実態調査の集計結果と分析，

経済産業省，pp. 55，2004

6 ）東基衞，ISO/IEC 9126 Software Engineering

Product Quality，2004，http://raq.azuma.mgmt.

waseda.ac.jp/japanese/azuma-j.html

7 ）橋本隆成，『プロジェクト管理成功するソフト

ウェア開発の最新スタイル』，pp. 42，2004

8 ）（社）日本情報システム・ユーザー協会，企業IT

動向調査，情報処理推進機構，pp. 33，2004

9 ）F.Brooks，『人月の神話』，ピアソン・エデュケー

ション，pp. 17，2003

10）宮内茂樹，塚田三緒他，XP手法による開発プロ

セスの改善，Winter Workshop in Kobe，情報

処理学会ソフトウェア工学研究会，pp. 83―84，

2003

11）プロジェクトは，目標を達成するための計画やそ

の実現のために仕事の実行までを含めて指す。し

たがって，目標も大きくなり，集団で実行するこ

とになる。情報システムの開発もSA，E，PEな

ど複数の人々が関与し，要件定義，外部設計，詳

細設計，プログラミング，試験などの工程を経て

完成されるので，情報システムの開発はプロジェ

クトの形態をとっている。

12）木下栄蔵，『入門AHP』，日科技連，pp. 2―3，

2000

13）木下栄蔵，『入門AHP』，日科技連，pp. 139―

153，2000

情報システム開発手法に関する評価モデルの開発cocomo（constructive cost...

Documents