1

Developers Summit Developers Summit 20092009

システムの見える化システムの見える化～～エンドユーザーの立場から～エンドユーザーの立場から～

社団法人日本情報システム・ユーザー協会社団法人日本情報システム・ユーザー協会（（JUASJUAS））

専務理事専務理事 細川泰秀細川泰秀２００９・２・２００９・２・１３１３

2

質問１：ＩＴを使うことが企業に繁栄をもたらすＩＴ投資金額は年々増加している？

3

IT予算増減率

71%

112%

108%

-28%

-3%

-37%

-10%

111%

-26%

-18%

76%

55%

182%

46%

-50% 0% 50% 100% 150% 200%

A

B

C

D

E

F

H

I

J

K

L

M

N

P

Q

R

IT総費用増減率＝ ２００６年ＩＴ費用総額/ １９９６年ＩＴ費用総額

企業

技術進歩享受と削減努力企業

新規投資増加企業

4

１０年間のＩＴ投資成果個別プロジェクトの成果の集合は企業業績につながる

１０年間のＩＴ投資金額比率

１０年間の売上高、営業利益の伸び率

5％

-5％

売上高、営業利益の減少をＩＴ費用の削減でカバーした企業（ＭＡＸ50％）

-50％

売上増加を積極的なＩＴ投資が支えた企業

ＩＴ投資が有効効果をもたらさなかった企業

（内部固め投資にのみ注力した企業）

5

質問２：日本のシステムは、ウオーターフォール法を使うので品質が低い？

6

品質の指標と基本統計量・分布

• 欠陥率 ＝ （納入以降～安定まで、ユーザが発見した欠陥数）

÷ プロジェクト全体工数との定義で、欠陥率を計算した。

(カットオーバー後の欠陥ではない）

• 平均値は０．８1個、中央値は０．３３個であった。

不良プロジェクトの影響で欠陥平均値は、やや多くなっているが、世界的な

レベルでの比較では非常にレベルが高い。

欠陥率（欠陥数/工数）

欠陥率分布

14

50

3027

21

9

0

10

20

30

40

50

60

0 0.25 0.5 1 3 次の級

件数

平均値0.81

中央値0.33

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人月（開発要員）あたり０．２５個以下の

プロジェクトが４０％を超えている良い成績である。

（ほぼ１個/５人月の相当する→１個/５００万円を目標にする

と理解しやすい）

8

有り 無し 記入なし 計65 79 1 145

44.8% 54.5% 0.7% 100.0%0.37 0.78 0.17 0.592.62 11.89 0.17 11.890.00 0.00 0.17 0.00

品質基準

件数

平均換算欠陥率大換算欠陥率小換算欠陥率

比率

品質基準の有無と欠陥率

欠陥率の代わりに、換算欠陥率を用いて比較すると、品質基準を

持っていないプロジェクトでは、換算欠陥率が2.1倍になっていた。

換算欠陥率＝大規模不具合×2+中規模不具合×１+小規模不具合×1/2

9

外国と比較して、日本のソフトウエアー品質は高い

日本 米国 インド 欧州他

プロジェクト数 27 31 24 22

生産性プログラマーが１人月に記述するコード行数

469 270 209 436

ソフトウエアーの品質システム導入後１年間に発見された１Ｋあたりの不具合報告（中央値）

0.020 0.400 0.263 0.225

出展：ＩＥＥＥ software（２００３年１１,１２月号）ソフトウエアー開発の生産性と品質に関する国際比較

10

質問３：工期が短いと品質が悪くなる？

11

標準工期（適正工期）の考察

• プロジェクト全体工数と、全体工期がともに記入されている２０３プロジェクトについて、工数の3乗根と工期の関係をグラフ化し、回帰直線を引いた。

• 各企業においてこの式の何％までの短縮に耐えられるかは変わってくる

工期-工数グラフ

0

5

10

15

20

25

30

35

40

45

0 2.5 5 7.5 10 12.5 15

全体工数

全体

工期

100人月15人月 400人月 1000人月 2000人月 3000人月

Y＝２.４X

12

納期（工期）の評価尺度とアクション

納期（工期）に関する問題（基本設計からカットオーバー迄）

標準より長い工期 標 準 ２５％工期短縮 ２５％以上工期短縮

工期の標準

の考え方

金融等欠陥の発生

を無くしたい品質重

視のプロジェクトの

場合

工数の立方根の 2.4 倍

（例：１０００人月のプロジ

ェクトは２4 箇月）

・ユーザの要望

・流通業のシステム化など

に多い。

ユーザのやむを得ない外的事情で実施する場合

（対コンペ戦略、新商品の販売、株式の上場、企

業の統合など）

スケジューリ

ン グ の 対 応

策

充分なシステムテ

スト期間の確保

中日程計画の充実

（ 役 割 分 担 別 Ｗ Ｂ Ｓ 管

理）

中日程計画の充実

（週間別管理）

小日程計画の充実

（日別管理）

その他の対応策

・品質重視のテスト計画書及びテストケースの緻密化

・安定稼動のための分割立ち上げ等

・ＷＢＳによる総合計画と局面化開発

・レビューの徹底 ・テストケース充実 ・コンバージョンデータの

フル活用 ・確実な変更管理

同 左 + ・ＰＧの選抜

*標準化の徹底と実力のある一括外注の採用。

・システム範囲、対象の部分稼動

・ＲＡＤ+ＤＯＡ ・性能事前検証 ・変更管理の強化

同 左 + ・ベテランＰＭによる采配と会社あげての協力及び

監視 ・パート図での計画 ・ベストメンバー選出 ・クリーンルーム手法 ・二交代制の配置 ・顧客主体のテストチーム設置 ・パッケージの活用 ・部品の再利用 ・オープンな進捗情報管理

標準工期と実行工期の差(工期短縮率％）に着目してノウハウを蓄積する

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％

短工期でもプロジェクトマネジメント次第で遅延は防げる。ただし異常な工期短縮率（企業によって異なる）のプロジェクトは失敗の可能性が高い。

工期の適正度と遅延度の関係

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

「品質が良いものは高い」はシステム開発の世界では証明されていない。

もっとも安いプロジェクトが も品質が良いとの逆の結果になっている。

良い品質のプロジェクトは 小単価が高い（無茶な値切りをしていない）

発注者は品質について努力目標を提示する必要がある発注者は品質について努力目標を提示する必要がある

15

質問４：ユーザー企業のシステム費用は大半が開発費である？

16

新規投資割合は年々増加し、新規投資割合が4割に新規投資の予算執行率は9割、1割以上未達が1/3

保守運用費 新規投資 合計 保守運用費 新規投資 合計 保守運用費 新規投資

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%5.0% 16.7% 9.7%

08年度予想 1,079 789 1,868 2.2% 0.0% 1.3% 58% 42%

※伸び率の内、06年度実績の欄は予算進捗率、また、07年度計画の、上段は06年度計画比、下段は06年度実績比の伸び率

IT予算（百万円）

07年度計画 1,056

構成比

43%57%

伸び率（および予算執行率（※））有効回答=407

1,844789

新規投資割合（実績）は徐々に増加傾向03年：34%、04年：36% 05年：32% 06年：40% ０７年：43％ ０８年/42％

17

5年 10年 15年 20年

1.0

2.0

3.0

初期開発費

スクラッチ開発

ＥＲＰの例1

パッケージには様々な価額設定方式があるので個別に

比較すること

ＥＲＰの例2

ＥＲＰの例3

長期的ソフトウェア費用

５年間で開発費用と同じ程度の費用がかかっている

18

質問6：バグの少ないアプリケーション・システム

を作ると、保守契約がもらえないので、ベンダーは損をする？

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の規定を参照したが、これ以外に①効果の実現への協力、

②改善提案がある。プログラムを修正することだけが保守ではない

20

導入費用だけでなく、保守・運用費用を考慮したシステム構築を推進しないと、システムライフトータルでは高く。開発費用＋保守・運用費用の総費用を考慮する必要あり。

システムライフサイクル

費用 《導入費用》

《保守・運用費用》

ハード無償保証

▲ハード・OS納品

▲ハード1年間

無償保証終了

ハードウェア有償保証（購入時にSLA（期間:3年、5年・サービス内容:24Hr365日等）を決定するものが多くなってきている）

開発費用

← 期間 → アプリケーション保守費用

運用費用（利用期間：～平均７年～※1 ）

《延命課題》

システム総費用＝「導入費用＋開発費用」＋「保守（ハード費用＆OS・ミドルウェア）＋アプリケーション保守費用＋運用費用」 × 「期間」

A B

アプリケーション無償保証

▲アプリケーション1年間無償保証終了

ライフサイクルコストを計算し、有利な方式を選択することA ＜ B に、なるのにＡにだけ着目して発注すると損をする

▲アプリケーション納品

システム更改や、障害発生時対応等のリスク拡大

システムの寿命（2003年度の調査結果）・独自開発基幹システム：17年・ＥＲＰパッケージ：11年

システムライフサイクルコストの重要性

21

質問７：マスコミに報道されるシステム障害のほとんどは、開発時に原因がある？

22

障害事例と対策（ｐ企画、Ｄ開発、Ｍ保守，ｕ運用、Ｓ利用に主要な原因があり）

No. 障害事例 発生日 ユーザ企業 障害の概要 主な原因 再発防止策

8 totoシステムがダウン

2007/5/12

日本スポーツ振興センター

スポーツ振興くじ（toto）の販売システムが5月12日午前、アクセス集中によって利用しにくい状態になった。

各販売チャネルとシステムをつなぐ接続ゲートウエイの処理がボトルネックとなりトラブル。

運用、P07, P08, U03,2006年度

18

厚生労働省

2007/6/27

厚生労働省

国民健康保険の財政調整交付金を算出するシステムの欠陥により、全国の自治体（市町村）に交付する金額を誤って算定。

省令に基づいたプログラム仕様書に仕様漏れがあり、金額を算定するロジックに誤り。不足が生じた自治体は「2005年度だけでのべ605市町村」」（厚労省 保険局 国民健康保険課）に上る。自治体への交付金支払いが100億円不足

メンテ、M09, S03

22

日販の受注処理が一時停止

2007/7/25

日本出版販売

受注システムに障害が発生し、受注データの処理ができなくなった。

新システムに切り替えた際にシステム障害が発生し、受注データの処理ができなくなった。

再構築 D16, D19, D30, M03, M04２００７年７月１７日開発

27

神戸新聞のシステム障害

2007/9/22

神戸新聞社

障害が発生したのは紙面をレイアウトする「組版システム」。22日朝に、同システムのデータベース（DB）・サーバーにアクセスできなくなった。DBを冗長化していなかったため全体が利用できなくなった。

日本オラクルの「Oracle9i Database」。データの検索を高速化する統計情報の採取処理をした後、データベースのシステムを強制終了すると、まれに起動ができなくなる問題がある。

開発、D11, D18, U06

23

どのフェーズの問題なのか？

2006.12～2008.9に発生しマスコミに紹介され原因が判明した障害件数83件を

分析した。開発３割、保守と運用のフェーズに原因があるものは７割になっている。

開発だけに着目していては障害は減らない。

障害原因分析から一歩進めて対策分析を実施すると、企画、開発、保守、運用、利用の各段階で対策をとる必要があることが判明した。

件数 割合1(%) 割合2(%)

開発 18 21%

再構築 7 8% 29%

保守 25 30%

運用 34 41% 71%

計 84 100% 100%

開発はひと時

保守運用は永久

24

24

【注】 再構築は、開発に含める。保守は、開発と別枠にする。

ビジネスシステムの信頼性ランクは、その特性を配慮し、以下の評価方法を採用する。

要因 Type１ Type２ Type３ Type４

①人命に影響を与える可能性

ほとんどなし 軽微 重大災害 死亡事故

②障害金額の予測 １千万円以下

１億円以下 １０億円以下 １０億円以上

③社会的影響 ほとんどなし 軽微 多くの人に迷惑をかける

あるいは特定個人に大きな心理的影響を与える

重大な影響を社会に与える

レベル１ レベル２ レベル３ レベル４

守るべき品質評価点 ５０点以下 50～69点 70点～８９点 ９０点以上

＜Type－評点対応表＞

＜Type定義表＞

上記①～③の要因の内、 も高いタイプの項目にならい、自システムのTypeを決定する。

【障害事例対策報告書（仮）付1チェックリスト】

イメージ

24

要求が作るランク

事実を客観的に確認し、対策を検討するためのランク

2.各対策に対する取り組み度合い（レベル）を評価

3.合計点によりどのタイプの対策がなされているか判断

1.Typeの定義＜システムプロファイルの評価方法＞

そのレベルを確保するためには、チェックリストによる評点の合計が「守るべき品質評価点」以上を取得することが望まれる。

各対策ごとにクリアすべき取り組みレベルも今後検討する。【障害事例対策報告書（仮） チェックリスト 参考2 】

各レベルは各タイプに相当する

システム品質タイプと評価

25

質問８：業務中断にいたるシステム障害はハードウエアーによって引き起こされるものが多い？

26

年間障害発生頻度

表9- 55 9.9.5 年間障害発生頻度 (保守運用費52億円の規模企業を対象）

障害発生頻度（回／年） 事業中断になったケース（回／年）

設問 平均 MAX MIN 平均 割合％ MAXサーバー関係障害発生頻度 15.4 100 0 0.32

（2.0%）11.0 2

ネットワーク機器 6.5 48 0 0.27（4.2%）

9.3 4

電源系 1.0 4 0 0.16（16%）

5.5 1

ミドルソフトウェア 14.1 74 0 0.23（1.6%）

8.0 1

アプリケーションプログラム

49.3 253 0 1.1（2.2%）

38.0 8

運用トラブル 10.8 47 0 0.43（3.9%）

14.8 3

その他、人の作業に起因するもの 12.9 101 0 0.38（2.9%）

13.1 4

合計 110 2.89（2.6%）*

99.7

* 1億円あたり0.055件（2.89／52）基盤障害33.8％ アプリ38.0％が多い

27

障害指標の件数のまとめ

調査対象企業によって異なるが、おおよそ以下の業務停止障害が発生している

0.06件／保守運用費・1億円／年 ソフトウエアメトリックス運用調査 2008

0.06件／保守運用費・1億円／年 企業ＩＴ動向調査 2008

高信頼性システムの評価値 （システム利用者のため運用者のために整備が必要）

区分 種類 定義

1 稼働率 稼動した時間/稼動すべき時間（P.15参照）

2 稼動品質率 稼動品質率1＝業務停止になった回数/年間/ａ～ｃ

a.運用費又は保守運用費

b.ＳＴＥＰ数

c.ソフトウエアー資産金額

稼動品質率2＝顧客に迷惑をかけた回数/年間/ａ～ｃ

1回・年/100万ＳＴＥＰなどの優秀企業がある

次回以降の研究テーマ

28

質問９：情報産業は残業が多い辛い職場である？

29

(参考）ＪＩＳＡ企業の基本統計調査

年度 2004 2005 2006 2007 2008 コメント

売上高成長率 1.82 3.24 ２００８は見込み

残業時間/年

4.164.493.41

4.5

4.46

289 漸減

売上高営業利益率

4.29

296

4.25

307

4.7

4.89

6.8 向上

売上高経常利益率

5.28

4.39

6.84

6.34

5.64

5.53

6.99 向上

業務タイプ別営業利益率

ＳＩ型

5.00

4.25

4.74

6.12 向上

ソフトウエアー開発型 5.58 向上

情報処理型 7.47 向上

平均すれば特別長くはないが・・・・

１４００時間・毎年残業をしているＳＥも多い

経営者、管理者、本人の努力が必要

情報サービス産業協会報告書より

30

ＳＥの長労働時間の原因

①ムリな計画を立てている（ムリムリ残業）

・超短工期の受注（地獄に飛び込むことがわかっていない）・実力経験不足なのに受注（規模、業種・技術を未経験など）

②計画した仕事量が増加する（ボロボロ残業）

・仕様変更の多発（要求仕様書の検討が不十分・・・・）

・実装、テスト工期不足で品質がボロボロ（本番後の後負いフォローにおおわらわ）

③能力不足で、予定どおりにできない（ボロボロ、ダラダラ残業）

・個人能力が低い（教育不足、能力不適合・・・）

・効率低下（仕事の準備不十分、手法の間違い・・・）

④一定時間で仕事を終わらせる意識がない（ダラダラ残業）

・低給与水準の補い

・業績把握、評価制度の見直しも必要

ワークライフバランスの確保のためにはまず長時間残業からの脱出を

31

システム開発と残業問題３Ｋから３Ｔへ（楽しい、高い給与、定時で帰れる）

①残業をさせないことが高収益性の第一歩（特に一括請負の場合）

・見積は一定時間の残業が前提

→それで残業しなければ◎

・高残業を毎年続けているＳＥ，ＰＧは実力者が多い

→その人でなくてもできる仕事を外す（下級者やアルバイトの活用）

上級管理者の意識がまず第一

②無茶な残業をしなくて済む仕組みの構築

・工期の標準（別紙）

・要求仕様書の上級管理職による確認→ユーザーとの対話を（リスク管理方法の活用）

・ＰＡＭ ・ＰＡＣ ・ＴＲＭ ・ＷＢＳ ・ＣＣＰＭ ・ＤＢパトロール

・目標の設定

ａ. カットオーバーの日は定時で帰宅できるプロジェクトマネジメント

ｂ. 計画以上の利益を出そう運動

ｃ. 従来の方法、前提の見直し（もっとよい方法がある）

32

質問１０：米国の企業は、基本設計完了後にベンダー委託するので、失敗が少ない。日本のユーザーも見習うべきである。

33

契約形態と選択どのタイプを選択するのか、プロジェクト企画時に明確にして始めること

企画開発モデルタイプ

戦略企画

要件定義

外部設計

内部設計

プログラミング

保守運用

タイプ

保守 運用

１・ＩＴ利用模索プロジェクト

Ａ

Ｂ

Ｃ

Ｄ

Ｖ Ｖ

2.標準モデル Ｖ Ｕ

3.米国型インハウス・

モデル

Ｕ Ｖ

4.先進企業モデル Ｕ Ｕ

5.Ｗｉｎ－Ｗｉｎモデル

保守運用の選択

・右の選択

ユーザー企業の分担 ベンダー企業の分担

Ｖ ベンダー企業の分担Ｕ ユーザー企業の分担

34

問題感知力･問題解決力

現状把握･分析

問題点把握

理想像

想定

対策案

策定

設計

実装

運用

利活用

問題感知力

・ユーザー企業ではもっとも大切

・柔軟な理解力･発想力

問題解決力

・学校で習う内容

・たくましい実行力

活用力

・使いこなし力

・現場力

技術の伝承と進化

人間力

・感じ･考える力

・See→Touch→Measure →Analyze→Think→

・組織としての改善･改革風土

読み・書き・考える力

要素技術

（これだけは 新技術の使える者が優先する）

プロジェクト管理技術

・改善技術（ＩＥ，ＯＲ，ＱＣ、ＷＤ，ＫＴなど）

組織経営力

情報活用力

人間力

組織経営力

新ビジネス創造力

読み・書き・考える力

信頼性向上技術

育成阻害要因(解決可能）

・階層のフラット化・転職・成果主義 ・長時間残業

＊何かおかしいと感じる力

＊もっと良いもの･方法がないかと考える力

＊理想状態を想定できる力

独創力柔軟性

35

まとめシステムの上にシステムがある。

・目線を高めて、もっと良いものがないか考えること

・良いか悪いかを決める評価尺度の基準を持つこと

・レベルを上げるためのアクションを起こすこと

・この問題が解決したら、すべて良くなりますか？を繰り返すこと

ご清聴ありがとうございました