3. IT総費用増減率＝ ２００６年ＩＴ費用総額/ １９９６年ＩＴ費用総額
IT予算増減率
-50% 0% 50% 100% 150% 200%
A 71%
B
C 112%
企D 108%
業
E -28%
-3%
F
-37%
H
I -10%
新規投資増加企業
J 111%
K -26%
L -18%
76%
M
55%
N 技術進歩享受
と削減努力
P 182%
企業
Q 46%
R
3
4. １０年間のＩＴ投資成果
個別プロジェクトの成果の集合は企業業績につながる
売上増加を積極的なＩＴ
投資が支えた企業
5％
売上高、営業利益の減少 １０年間のＩＴ投資金額比率
-50％ をＩＴ費用の削減でカバーし
た企業（ＭＡＸ50％）
ＩＴ投資が有効効果をもたら
さなかった企業
（内部固め投資にのみ注
-5％
力した企業）
１０年間の売上高、営業利益の伸び率
4
6. 品質の指標と基本統計量・分布
欠陥率 ＝ （納入以降～安定まで、ユーザが発見した欠陥数）
•
÷ プロジェクト全体工数との定義で、欠陥率を計算した。
(カットオーバー後の欠陥ではない）
• 平均値は０．８1個、中央値は０．３３個であった。
不良プロジェクトの影響で欠陥平均値は、やや多くなっているが、世界的な
レベルでの比較では非常にレベルが高い。
欠陥率分布
平均値
0.81
60
中央値
50
50 0.33
40
件数
30
27
30
21
20 14
9
10 欠陥率（欠陥数/工数）
0
0.25 0.5 1 3 次の級
0
6
7. 品質の指標と基本統計量・分布
欠陥率
Aﾗﾝｸ Bﾗﾝｸ Cﾗﾝｸ Dﾗﾝｸ Eﾗﾝｸ Fﾗﾝｸ
0 0.25未満 0.5未満 1未満 3未満 3以上 計
件数 15 51 29 27 23 9 154
比率 9.7% 33.1% 18.8% 17.5% 14.9% 5.8% 100.0%
・不具合数数/1人月（開発要員）あたり０．２５個以下の
プロジェクトが４０％を超えている良い成績である。
（ほぼ１個/５人月の相当する→１個/５００万円を目標にする
と理解しやすい）
7
8. 品質基準の有無と欠陥率
品質基準
有り 無し 記入なし 計
件数 65 79 1 145
比率 44.8% 54.5% 0.7% 100.0%
平均換算欠陥率 0.37 0.78 0.17 0.59
最大換算欠陥率 2.62 11.89 0.17 11.89
最小換算欠陥率 0.00 0.00 0.17 0.00
欠陥率の代わりに、換算欠陥率を用いて比較すると、品質基準を
持っていないプロジェクトでは、換算欠陥率が2.1倍になっていた。
換算欠陥率＝大規模不具合×2+中規模不具合×１+小規模不具合×1/2
8
9. 外国と比較して、日本のソフトウエアー品質は高い
日本 米国 インド 欧州他
プロジェクト数 27 31 24 22
生産性
プログラマーが１人月に記述する 469 270 209 436
コード行数
ソフトウエアーの品質
システム導入後１年間に発見された 0.020 0.400 0.263 0.225
１Ｋあたりの不具合報告（中央値）
出展：ＩＥＥＥ software（２００３年１１,１２月号）
ソフトウエアー開発の生産性と品質に関する国際比較
9
11. 標準工期（適正工期）の考察
工期-工数グラフ
45
40
Y＝２.４X
35
30
全体工期
25
20
15
10
5
0
0 2.5 5 7.5 10 12.5 15
1000人月 3000人月
15人月 400人月 2000人月
100人月
全体工数
プロジェクト全体工数と、全体工期がともに記入されている２０３プロジェク
•
トについて、工数の3乗根と工期の関係をグラフ化し、回帰直線を引いた。
各企業においてこの式の何％までの短縮に耐えられるかは変わってくる
•
11
12. 納期（工期）の評価尺度とアクション
納期（工期）に関する問題（基本設計からカットオーバー迄）
標準より長い工期 標 準 ２５％工期短縮 ２５％以上工期短縮
工 期 の 標 準 金融等欠陥の発生 工数の立方根の 2.4 倍 ・ユーザの要望 ユーザのやむを得ない外的事情で実施する場合
の考え方 を無くしたい品質重 （例：１０００人月のプロジ ・流通業のシステム化など （対コンペ戦略、新商品の販売、株式の上場、企
視のプロジェクトの ェクトは２4 箇月） に多い。 業の統合など）
場合
スケジューリ 充 分な シ ス テム テ 中日程計画の充実 中日程計画の充実 小日程計画の充実
ン グ の 対 応 スト期間の確保 （役割分担別ＷＢＳ管 （週間別管理） （日別管理）
策 理）
・品質重視のテスト ・ＷＢＳによる総合計画 同左+ 同左+
その他の対 計画書及びテス と局面化開発 ・ＰＧの選抜 ・ベテランＰＭによる采配と会社あげての協力及び
応策 トケースの緻密 ・レビューの徹底 *標準化の徹底と実力の 監視
化 ・テストケース充実 ある一括外注の採用。 ・パート図での計画
・安定稼動のため ・コンバージョンデータの ・システム範囲、対象の部 ・ベストメンバー選出
の分割立ち上げ フル活用 分稼動 ・クリーンルーム手法
等 ・確実な変更管理 ・ＲＡＤ+ＤＯＡ ・二交代制の配置
・性能事前検証 ・顧客主体のテストチーム設置
・変更管理の強化 ・パッケージの活用
・部品の再利用
・オープンな進捗情報管理
標準工期と実行工期の差(工期短縮率％）に着目してノウハウを蓄積する
12
13. 工期の適正度と遅延度の関係
標準工期= 2.4 X 工数の三乗根と考え、工期が標準工期に対してどの程度短いかを
表す尺度として、以下のように工期短縮率を定義する。
工期短縮率 ＝ １ － （実工期 ÷ 標準工期） これを計算し分布を見た。
短工期、標準工期、長工期の基準を、それぞれ全体の２５－50－25パーセント程度と
なるように、定義した。
工期適正度 短工期 適正工期 長工期 全体
件数 50 104 48 202
割合 24.7％ 51.5％ 23.8％ 100％
平均工期(月） 7.8 10.5 15.8 11.2
２０%以上の遅延率 10.9％ 12.0％ 12.8％ 11.9％
短工期でもプロジェクトマネジメント次第で遅延は防げる。
ただし異常な工期短縮率（企業によって異なる）のプロジェクトは失敗の可能性が高い。
13
14. 品質と価額の関係
品質区分（欠陥率）
総計
A(0) B(~0.25) C(~0.5) D(~1) E(~3) F(3~)
件数 9 38 24 24 17 8 120
単価（平均） 96.2 113.5 105.8 101.6 113.7 117.3 108.6
単価（最大） 140.4 272.7 162.5 285.7 175.7 250.0 285.7
単価（最小） 71.5 46.2 43.2 41.4 70.8 45.7 41.4
「品質が良いものは高い」はシステム開発の世界では証明されていない。
もっとも安いプロジェクトが最も品質が良いとの逆の結果になっている。
良い品質のプロジェクトは最小単価が高い（無茶な値切りをしていない）
発注者は品質について努力目標を提示する必要がある
14
16. 新規投資割合は年々増加し、新規投資割合が4割に
新規投資の予算執行率は9割、1割以上未達が1/3
IT予算（百万円） 伸び率（および予算執行率（※）） 構成比
有効回答=407
保守運用費 新規投資 合計 保守運用費 新規投資 合計 保守運用費 新規投資
06年度計画 1,031 765 1,796 - - - 57% 43%
06年度実績 1,005 676 1,681 (※) 97.5% (※) 88.4% (※) 93.6% 60% 40%
2.4% 3.1% 2.7%
07年度計画 1,056 789 1,844 57% 43%
5.0% 16.7% 9.7%
08年度予想 1,079 789 1,868 2.2% 0.0% 1.3% 58% 42%
※伸び率の内、06年度実績の欄は予算進捗率、また、07年度計画の、上段は06年度計画比、下段は06年度実績比の伸び率
新規投資割合（実績）は徐々に増加傾向
03年：34%、04年：36% 05年：32% 06年：40% ０７年：43％ ０８年
/42％ 16
17. 長期的ソフトウェア費用
ＥＲＰの例1
ＥＲＰの例2
スクラッチ開発
3.0
ＥＲＰの例3
2.0
初
期
開
発
パッケージには様々な価額設定方式があるので個別に
費
1.0 比較すること
５年間で開発費用と同じ程度の費用がかかっている
5年 10年 15年 20年
17
19. 保守作業の目的別種類と割合
平均 中央値 最小 最大 標本数
保守の問い合わせ 30.1 29.0 0 100 147
保守の基盤整備 Ｉ 8.5 5.0 0 50 147
Ｓ
是正保守 23.5 20.0 0 100 147
Ｏ
適応保守 26.6 16.0 0 100 147
定
義
完全化保守 11.3 5.0 0 100 147
保守作業割合の調査結果を見ると、保守作業において「保守の問合せ」の占める割合
が大きいことが分かる。この作業項目が年間対応件数に大きく影響する。
是正保守とは障害(バグ）を修正すること、適応保守とは環境変化に適合させる保守
是正保守とは障害(バグ）を修正すること、適応保守とは環境変化に適合させる保守
のこと、完全化保守とは性能や保守性を改善する保守のこと
のこと、完全化保守とは性能や保守性を改善する保守のこと
ＩＳＯ9001の規定を参照したが、これ以外に①効果の実現への協力、
②改善提案がある。プログラムを修正することだけが保守ではない
19
20. システムライフサイクルコストの重要性
導入費用だけでなく、保守・運用費用を考慮したシステム構築を推進しないと、システム
ライフトータルでは高く。開発費用＋保守・運用費用の総費用を考慮する必要あり。
システムの寿命（2003年度の調査結果）
システム更改や、
・独自開発基幹システム：17年
《導入費用》
費用
障害発生時対応
・ＥＲＰパッケージ：11年 等のリスク拡大
開発費用
《保守・運用費用》
運用費用（利用期間：～平均７年～※1 ）
→ アプリケーション
← 期間 アプリケーション保守費用
無償保証
ハードウェア有償保証（購入時にSLA（期間:3年、5年・サービス
ハード無償保証 《延命課題》
内容:24Hr365日等）を決定するものが多くなってきている）
▲
▲ ▲
システム
アプリケーション
ハード・OS アプリケーション
ライフサイクル
納品
納品 1年間無償保証終了
▲
ハード1年間
無償保証終了
システム総費用＝「導入費用＋開発費用」＋「保守（ハード費用＆OS・ミドルウェア）＋アプリケーション保守費用＋運用費用」 × 「期間」
B
A
ライフサイクルコストを計算し、有利な方式を選択すること
A ＜ B に、なるのにＡにだけ着目して発注すると損をする 20
22. 障害事例と対策（ｐ企画、Ｄ開発、Ｍ保守，ｕ運用、Ｓ利用に主要な原因があり）
No. 障害事例 発生日 ユーザ企業 障害の概要 主な原因 再発防止策
運用、P07,
各販売チャネルとシステムを
スポーツ振興くじ（toto）の販売
8 totoシス 2007/ 日本ス
P08, U03
つなぐ接続ゲートウエイの処
システムが5月12日午前、アクセ
テムが 5/12 ポーツ振
,2006年度
理がボトルネックとなりトラブ
ス集中によって利用しにくい状
ダウン 興セン
ル。
態になった。
ター
メンテ、M09,
省令に基づいたプログラム仕
1 厚生労 2007/ 厚生労働 国民健康保険の財政調整交付
S03
様書に仕様漏れがあり、金額
8 働省 6/27 省 金を算出するシステムの欠陥に
を算定するロジックに誤り。不
より、全国の自治体（市町村）に
足が生じた自治体は「2005年
交付する金額を誤って算定。
度だけでのべ605市町村」」
（厚労省 保険局 国民健康保
険課）に上る。自治体への交
付金支払いが100億円不足
再構築 D16,
2007/ 日本出版 受注システムに障害が発生し、 新システムに切り替えた際に
2 日販の
D19, D30,
7/25 販売 受注データの処理ができなく システム障害が発生し、受注
2 受注処
M03, M04
なった。 データの処理ができなくなっ
理が一
２００７年７月
た。
時停止
１７日開発
開発、D11,
日本オラクルの「Oracle9i
2007/ 神戸新聞 障害が発生したのは紙面をレイ
2 神戸新
D18, U06
Database」。データの検索を
9/22 社 アウトする「組版システム」。22
7 聞のシ
高速化する統計情報の採取
日朝に、同システムのデータ
ステム
処理をした後、データベース
ベース（DB）・サーバーにアクセ
障害
のシステムを強制終了すると、
スできなくなった。DBを冗長化し
まれに起動ができなくなる問
ていなかったため全体が利用で
題がある。
きなくなった。
22
23. どのフェーズの問題なのか？
件数 割合1(%) 割合2(%)
開発 18 21% 開発はひと時
再構築 7 8% 29%
保守 25 30%
保守運用は
71%
運用 34 41% 永久
計 84 100% 100%
2006.12～2008.9に発生しマスコミに紹介され原因が判明した障害件数83件を
分析した。開発３割、保守と運用のフェーズに原因があるものは７割になっている。
開発だけに着目していては障害は減らない。
障害原因分析から一歩進めて対策分析を実施すると、企画、開発、保守、
運用、利用の各段階で対策をとる必要があることが判明した。
23
24. システム品質タイプと評価 2.各対策に対する取り組み度合い（レベル）を評価
1.Typeの定義＜システムプロファイルの評価方法＞ 【障害事例
対策報告書（仮）
ビジネスシステムの信頼性ランクは、その特性を配慮し、 付1チェックリスト】
以下の評価方法を採用する。 イメージ
要求が作るランク 【注】 再構築
＜Type定義表＞
は、開発に含
める。保守は、
要因 Type１ Type２ Type３ Type４
開発と別枠に
①人命に影響を与 ほとんどなし 軽微 重大災害 死亡事故
する。
える可能性
②障害金額の予測 １千万円以 １億円以下 １０億円以下 １０億円以上
下
③社会的影響 ほとんどなし 軽微 多くの人に迷惑 重大な影響を
をかける 社会に与える
あるいは特定個
人に大きな心理
的影響を与える
上記①～③の要因の内、最も高いタイプの項目にならい、
自システムのTypeを決定する。
各レベルは各タイプ
に相当する
3.合計点によりどのタイプの対策がなされているか判断
＜Type－評点対応表＞
レベル１ レベル２ レベル３ レベル４
守るべき品質評価点 ５０点以下 70点～８９点 ９０点以上
50～69点
そのレベルを確保するためには、
チェックリストによる評点の合計
事実を客観的に確認し、対
が「守るべき品質評価点」以上を
策を検討するためのランク
取得することが望まれる。
各対策ごとにクリアすべき取り組みレベルも今後検討する。
【障害事例対策報告書（仮） チェックリスト 参考2 】
24
24
24
26. 年間障害発生頻度
表9- 55 9.9.5 年間障害発生頻度 (保守運用費52億円の規模企業を対象）
障害発生頻度（回／年） 事業中断になったケース（回／年）
設問 MAX MIN MAX
平均 平均 割合％
15.4 100 0 0.32 11.0 2
サーバー関係障害発生頻度
（2.0%）
6.5 48 0 0.27 9.3 4
ネットワーク機器
（4.2%）
1.0 4 0 0.16 5.5 1
電源系
（16%）
14.1 74 0 0.23 8.0 1
ミドルソフトウェア
（1.6%）
49.3 253 0 1.1 38.0 8
アプリケーション
（2.2%）
プログラム
10.8 47 0 0.43 14.8 3
運用トラブル
（3.9%）
12.9 101 0 0.38 13.1 4
その他、人の作業に起因するもの
（2.9%）
110 2.89 99.7
合計
（2.6%）*
* 1億円あたり0.055件（2.89／52）
基盤障害33.8％ アプリ38.0％が多い
26
27. 障害指標の件数のまとめ
調査対象企業によって異なるが、おおよそ以下の業務停止障害が発生している
ソフトウエアメトリックス運用調査 2008
0.06件／保守運用費・1億円／年
企業ＩＴ動向調査 2008
0.06件／保守運用費・1億円／年
高信頼性システムの評価値 （システム利用者のため運用者のために整備が必要）
区分 種類 定義
1 稼動した時間/稼動すべき時間（P.15参照）
稼働率
2 稼動品質率1＝業務停止になった回数/年間/ａ～ｃ
稼動品質率
a.運用費又は保守運用費
b.ＳＴＥＰ数
c.ソフトウエアー資産金額次回以降の研究テーマ
稼動品質率2＝顧客に迷惑をかけた回数/年間/ａ～ｃ
1回・年/100万ＳＴＥＰなどの優秀企業がある
27
29. (参考）ＪＩＳＡ企業の基本統計調査
情報サービス産業協会報告書より
2004 2005 2006 2007
年度 2008 コメント
売上高成長率 3.24 ２００８は見込み
1.82 3.41 4.49 4.16
残業時間/年 289 漸減
307 296
売上高営業利益率 6.8 向上
4.5 4.7 6.84
売上高経常利益率 6.99 向上
4.46 4.89 6.34
業務タイプ別営業利益率
ＳＩ型 6.12 向上
4.29 5.28 5.64
ソフトウエアー開発型 5.58 向上
4.25 4.39 4.25
情報処理型 7.47 向上
5.53 5.00 4.74
平均すれば特別長くはないが・・・・
１４００時間・毎年残業をしているＳＥも多い
経営者、管理者、本人の努力が必要 29
31. システム開発と残業問題
３Ｋから３Ｔへ（楽しい、高い給与、定時で帰れる）
①残業をさせないことが高収益性の第一歩（特に一括請負の場合）
・見積は一定時間の残業が前提
→それで残業しなければ◎
・高残業を毎年続けているＳＥ，ＰＧは実力者が多い
→その人でなくてもできる仕事を外す（下級者やアルバイトの活用）
上級管理者の意識がまず第一
②無茶な残業をしなくて済む仕組みの構築
・工期の標準（別紙）
・要求仕様書の上級管理職による確認→ユーザーとの対話を（リスク管理方法の活用）
・ＰＡＭ ・ＰＡＣ ・ＴＲＭ ・ＷＢＳ ・ＣＣＰＭ ・ＤＢパトロール
・目標の設定
ａ. カットオーバーの日は定時で帰宅できるプロジェクトマネジメント
ｂ. 計画以上の利益を出そう運動
ｃ. 従来の方法、前提の見直し（もっとよい方法がある） 31
33. 契約形態と選択
どのタイプを選択するのか、プロジェクト企画時に明確にして始めること
保守 保守 運用
戦略 要件 外部 内部 プログ
運用
企画 定義 設計 設計 ラミン
企画開発モデルタイプ
グ タイプ
１・ＩＴ利用模索プロジェ 保 Ａ Ｖ Ｖ
クト 守
運
Ｂ Ｖ Ｕ
2.標準モデル 用
の
選
Ｃ Ｕ Ｖ
3.米国型インハウス・
択
モデル
・
Ｄ Ｕ Ｕ
右
4.先進企業モデル
の
選
5.Ｗｉｎ－Ｗｉｎモデル 択
ユーザー企業の分担 ベンダー企業の分担
Ｕ ユーザー企業の分担 Ｖ ベンダー企業の分担 33
34. ＊何かおかしいと感じる力
問題感知力･問題解決力 ＊もっと良いもの･方法がないかと考える力
＊理想状態を想定できる力
対策案 設計
現状把握･ 運用
問題点 理想像
分析 把握 策定 実装 利活用
想定
問題感知力 活用力
問題解決力
・ユーザー企業ではもっとも大切 独創力 ・使いこなし力
・学校で習う内容
柔軟性
・柔軟な理解力･発想力
・現場力
・たくましい実行力
・感じ･考える力
技
読み・書き・考える力 読み・書き・考える力
術 ・See→Touch→Measure
の →Analyze→Think→
要素技術 情報活用力
伝
・組織としての改善･改革風土
承 （これだけは最新技術の使える
新ビジネス創造力
と 者が優先する）
・改善技術（ＩＥ，ＯＲ，ＱＣ、ＷＤ，
進
化 ＫＴなど） プロジェクト管理技術 信頼性向上技術
育成阻害要因(解決可能） 人間力 人間力
・階層のフラット化・転職
・成果主義 ・長時間残業 組織経営力 組織経営力
34
35. まとめ
システムの上にシステムがある。
・目線を高めて、もっと良いものがないか考えること
・良いか悪いかを決める評価尺度の基準を持つこと
・レベルを上げるためのアクションを起こすこと
・この問題が解決したら、すべて良くなりますか？を繰り返すこと
ご清聴ありがとうございました
35
