【13-E-1】 システムの見える化~エンドユーザーの立場から
Upcoming SlideShare
Loading in...5
×
 

【13-E-1】 システムの見える化~エンドユーザーの立場から

on

  • 3,470 views

 

Statistics

Views

Total Views
3,470
Views on SlideShare
3,461
Embed Views
9

Actions

Likes
1
Downloads
109
Comments
0

1 Embed 9

http://www.slideshare.net 9

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    【13-E-1】 システムの見える化~エンドユーザーの立場から 【13-E-1】 システムの見える化~エンドユーザーの立場から Presentation Transcript

    • Developers Summit 2009 システムの見える化 ~エンドユーザーの立場から~ 社団法人日本情報システム・ユーザー協会 (JUAS) 専務理事 細川泰秀 2009・2・13 1
    • 質問1:ITを使うことが企業に繁栄をもたらす IT投資金額は年々増加している? 2
    • IT総費用増減率= 2006年IT費用総額/ 1996年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
    • 10年間のIT投資成果 個別プロジェクトの成果の集合は企業業績につながる 売上増加を積極的なIT 投資が支えた企業 5% 売上高、営業利益の減少 10年間のIT投資金額比率 -50% をIT費用の削減でカバーし た企業(MAX50%) IT投資が有効効果をもたら さなかった企業 (内部固め投資にのみ注 -5% 力した企業) 10年間の売上高、営業利益の伸び率 4
    • 質問2:日本のシステムは、ウオーターフォール法 を使うので品質が低い? 5
    • 品質の指標と基本統計量・分布 欠陥率 = (納入以降~安定まで、ユーザが発見した欠陥数) • ÷ プロジェクト全体工数との定義で、欠陥率を計算した。 (カットオーバー後の欠陥ではない) • 平均値は0.81個、中央値は0.33個であった。 不良プロジェクトの影響で欠陥平均値は、やや多くなっているが、世界的な レベルでの比較では非常にレベルが高い。 欠陥率分布 平均値 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
    • 品質の指標と基本統計量・分布 欠陥率 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人月(開発要員)あたり0.25個以下の プロジェクトが40%を超えている良い成績である。 (ほぼ1個/5人月の相当する→1個/500万円を目標にする と理解しやすい) 7
    • 品質基準の有無と欠陥率 品質基準 有り 無し 記入なし 計 件数 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+小規模不具合×1/2 8
    • 外国と比較して、日本のソフトウエアー品質は高い 日本 米国 インド 欧州他 プロジェクト数 27 31 24 22 生産性 プログラマーが1人月に記述する 469 270 209 436 コード行数 ソフトウエアーの品質 システム導入後1年間に発見された 0.020 0.400 0.263 0.225 1Kあたりの不具合報告(中央値) 出展:IEEE software(2003年11,12月号) ソフトウエアー開発の生産性と品質に関する国際比較 9
    • 質問3:工期が短いと品質が悪くなる? 10
    • 標準工期(適正工期)の考察 工期-工数グラフ 45 40 Y=2.4X 35 30 全体工期 25 20 15 10 5 0 0 2.5 5 7.5 10 12.5 15 1000人月 3000人月 15人月 400人月 2000人月 100人月 全体工数 プロジェクト全体工数と、全体工期がともに記入されている203プロジェク • トについて、工数の3乗根と工期の関係をグラフ化し、回帰直線を引いた。 各企業においてこの式の何%までの短縮に耐えられるかは変わってくる • 11
    • 納期(工期)の評価尺度とアクション 納期(工期)に関する問題(基本設計からカットオーバー迄) 標準より長い工期 標 準 25%工期短縮 25%以上工期短縮 工 期 の 標 準 金融等欠陥の発生 工数の立方根の 2.4 倍 ・ユーザの要望 ユーザのやむを得ない外的事情で実施する場合 の考え方 を無くしたい品質重 (例:1000人月のプロジ ・流通業のシステム化など (対コンペ戦略、新商品の販売、株式の上場、企 視のプロジェクトの ェクトは24 箇月) に多い。 業の統合など) 場合 スケジューリ 充 分な シ ス テム テ 中日程計画の充実 中日程計画の充実 小日程計画の充実 ン グ の 対 応 スト期間の確保 (役割分担別WBS管 (週間別管理) (日別管理) 策 理) ・品質重視のテスト ・WBSによる総合計画 同左+ 同左+ その他の対 計画書及びテス と局面化開発 ・PGの選抜 ・ベテランPMによる采配と会社あげての協力及び 応策 トケースの緻密 ・レビューの徹底 *標準化の徹底と実力の 監視 化 ・テストケース充実 ある一括外注の採用。 ・パート図での計画 ・安定稼動のため ・コンバージョンデータの ・システム範囲、対象の部 ・ベストメンバー選出 の分割立ち上げ フル活用 分稼動 ・クリーンルーム手法 等 ・確実な変更管理 ・RAD+DOA ・二交代制の配置 ・性能事前検証 ・顧客主体のテストチーム設置 ・変更管理の強化 ・パッケージの活用 ・部品の再利用 ・オープンな進捗情報管理 標準工期と実行工期の差(工期短縮率%)に着目してノウハウを蓄積する 12
    • 工期の適正度と遅延度の関係 標準工期= 2.4 X 工数の三乗根と考え、工期が標準工期に対してどの程度短いかを 表す尺度として、以下のように工期短縮率を定義する。 工期短縮率 = 1 - (実工期 ÷ 標準工期) これを計算し分布を見た。 短工期、標準工期、長工期の基準を、それぞれ全体の25-50-25パーセント程度と なるように、定義した。 工期適正度 短工期 適正工期 長工期 全体 件数 50 104 48 202 割合 24.7% 51.5% 23.8% 100% 平均工期(月) 7.8 10.5 15.8 11.2 20%以上の遅延率 10.9% 12.0% 12.8% 11.9% 短工期でもプロジェクトマネジメント次第で遅延は防げる。 ただし異常な工期短縮率(企業によって異なる)のプロジェクトは失敗の可能性が高い。 13
    • 品質と価額の関係 品質区分(欠陥率) 総計 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
    • 質問4:ユーザー企業のシステム費用は 大半が開発費である? 15
    • 新規投資割合は年々増加し、新規投資割合が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% 07年:43% 08年 /42% 16
    • 長期的ソフトウェア費用 ERPの例1 ERPの例2 スクラッチ開発 3.0 ERPの例3 2.0 初 期 開 発 パッケージには様々な価額設定方式があるので個別に 費 1.0 比較すること 5年間で開発費用と同じ程度の費用がかかっている 5年 10年 15年 20年 17
    • 質問6:バグの少ないアプリケーション・システム を作ると、保守契約がもらえないので、 ベンダーは損をする? 18
    • 保守作業の目的別種類と割合 平均 中央値 最小 最大 標本数 保守の問い合わせ 30.1 29.0 0 100 147 保守の基盤整備 I 8.5 5.0 0 50 147 S 是正保守 23.5 20.0 0 100 147 O 適応保守 26.6 16.0 0 100 147 定 義 完全化保守 11.3 5.0 0 100 147 保守作業割合の調査結果を見ると、保守作業において「保守の問合せ」の占める割合 が大きいことが分かる。この作業項目が年間対応件数に大きく影響する。 是正保守とは障害(バグ)を修正すること、適応保守とは環境変化に適合させる保守 是正保守とは障害(バグ)を修正すること、適応保守とは環境変化に適合させる保守 のこと、完全化保守とは性能や保守性を改善する保守のこと のこと、完全化保守とは性能や保守性を改善する保守のこと ISO9001の規定を参照したが、これ以外に①効果の実現への協力、 ②改善提案がある。プログラムを修正することだけが保守ではない 19
    • システムライフサイクルコストの重要性 導入費用だけでなく、保守・運用費用を考慮したシステム構築を推進しないと、システム ライフトータルでは高く。開発費用+保守・運用費用の総費用を考慮する必要あり。 システムの寿命(2003年度の調査結果) システム更改や、 ・独自開発基幹システム:17年 《導入費用》 費用 障害発生時対応 ・ERPパッケージ:11年 等のリスク拡大 開発費用 《保守・運用費用》 運用費用(利用期間:~平均7年~※1 ) → アプリケーション ← 期間 アプリケーション保守費用 無償保証 ハードウェア有償保証(購入時にSLA(期間:3年、5年・サービス ハード無償保証 《延命課題》 内容:24Hr365日等)を決定するものが多くなってきている) ▲ ▲ ▲ システム アプリケーション ハード・OS アプリケーション ライフサイクル 納品 納品 1年間無償保証終了 ▲ ハード1年間 無償保証終了 システム総費用=「導入費用+開発費用」+「保守(ハード費用&OS・ミドルウェア)+アプリケーション保守費用+運用費用」 × 「期間」 B A ライフサイクルコストを計算し、有利な方式を選択すること A < B に、なるのにAにだけ着目して発注すると損をする 20
    • 質問7:マスコミに報道されるシステム障害 のほとんどは、開発時に原因がある? 21
    • 障害事例と対策(p企画、D開発、M保守,u運用、S利用に主要な原因があり) 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 なった。 データの処理ができなくなっ 理が一 2007年7月 た。 時停止 17日開発 開発、D11, 日本オラクルの「Oracle9i 2007/ 神戸新聞 障害が発生したのは紙面をレイ 2 神戸新 D18, U06 Database」。データの検索を 9/22 社 アウトする「組版システム」。22 7 聞のシ 高速化する統計情報の採取 日朝に、同システムのデータ ステム 処理をした後、データベース ベース(DB)・サーバーにアクセ 障害 のシステムを強制終了すると、 スできなくなった。DBを冗長化し まれに起動ができなくなる問 ていなかったため全体が利用で 題がある。 きなくなった。 22
    • どのフェーズの問題なのか? 件数 割合1(%) 割合2(%) 開発 18 21% 開発はひと時 再構築 7 8% 29% 保守 25 30% 保守運用は 71% 運用 34 41% 永久 計 84 100% 100% 2006.12~2008.9に発生しマスコミに紹介され原因が判明した障害件数83件を 分析した。開発3割、保守と運用のフェーズに原因があるものは7割になっている。 開発だけに着目していては障害は減らない。 障害原因分析から一歩進めて対策分析を実施すると、企画、開発、保守、 運用、利用の各段階で対策をとる必要があることが判明した。 23
    • システム品質タイプと評価 2.各対策に対する取り組み度合い(レベル)を評価 1.Typeの定義<システムプロファイルの評価方法> 【障害事例 対策報告書(仮) ビジネスシステムの信頼性ランクは、その特性を配慮し、 付1チェックリスト】 以下の評価方法を採用する。 イメージ 要求が作るランク 【注】 再構築 <Type定義表> は、開発に含 める。保守は、 要因 Type1 Type2 Type3 Type4 開発と別枠に ①人命に影響を与 ほとんどなし 軽微 重大災害 死亡事故 する。 える可能性 ②障害金額の予測 1千万円以 1億円以下 10億円以下 10億円以上 下 ③社会的影響 ほとんどなし 軽微 多くの人に迷惑 重大な影響を をかける 社会に与える あるいは特定個 人に大きな心理 的影響を与える 上記①~③の要因の内、最も高いタイプの項目にならい、 自システムのTypeを決定する。 各レベルは各タイプ に相当する 3.合計点によりどのタイプの対策がなされているか判断 <Type-評点対応表> レベル1 レベル2 レベル3 レベル4 守るべき品質評価点 50点以下 70点~89点 90点以上 50~69点 そのレベルを確保するためには、 チェックリストによる評点の合計 事実を客観的に確認し、対 が「守るべき品質評価点」以上を 策を検討するためのランク 取得することが望まれる。 各対策ごとにクリアすべき取り組みレベルも今後検討する。 【障害事例対策報告書(仮) チェックリスト 参考2 】 24 24 24
    • 質問8:業務中断にいたるシステム障害は ハードウエアーによって引き起こされるもの が多い? 25
    • 年間障害発生頻度 表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
    • 障害指標の件数のまとめ 調査対象企業によって異なるが、おおよそ以下の業務停止障害が発生している ソフトウエアメトリックス運用調査 2008 0.06件/保守運用費・1億円/年 企業IT動向調査 2008 0.06件/保守運用費・1億円/年 高信頼性システムの評価値 (システム利用者のため運用者のために整備が必要) 区分 種類 定義 1 稼動した時間/稼動すべき時間(P.15参照) 稼働率 2 稼動品質率1=業務停止になった回数/年間/a~c 稼動品質率 a.運用費又は保守運用費 b.STEP数 c.ソフトウエアー資産金額次回以降の研究テーマ 稼動品質率2=顧客に迷惑をかけた回数/年間/a~c 1回・年/100万STEPなどの優秀企業がある 27
    • 質問9:情報産業は残業が多い辛い職場である? 28
    • (参考)JISA企業の基本統計調査 情報サービス産業協会報告書より 2004 2005 2006 2007 年度 2008 コメント 売上高成長率 3.24 2008は見込み 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 業務タイプ別営業利益率 SI型 6.12 向上 4.29 5.28 5.64 ソフトウエアー開発型 5.58 向上 4.25 4.39 4.25 情報処理型 7.47 向上 5.53 5.00 4.74 平均すれば特別長くはないが・・・・ 1400時間・毎年残業をしているSEも多い 経営者、管理者、本人の努力が必要 29
    • SEの長労働時間の原因 ①ムリな計画を立てている(ムリムリ残業) ・超短工期の受注(地獄に飛び込むことがわかっていない) ・実力経験不足なのに受注(規模、業種・技術を未経験など) ②計画した仕事量が増加する(ボロボロ残業) ・仕様変更の多発(要求仕様書の検討が不十分・・・・) ・実装、テスト工期不足で品質がボロボロ(本番後の後負いフォローにおおわらわ) ③能力不足で、予定どおりにできない(ボロボロ、ダラダラ残業) ・個人能力が低い(教育不足、能力不適合・・・) ・効率低下(仕事の準備不十分、手法の間違い・・・) ④一定時間で仕事を終わらせる意識がない(ダラダラ残業) ・低給与水準の補い ・業績把握、評価制度の見直しも必要 ワークライフバランスの確保のためにはまず長時間残業からの脱出を 30
    • システム開発と残業問題 3Kから3Tへ(楽しい、高い給与、定時で帰れる) ①残業をさせないことが高収益性の第一歩(特に一括請負の場合) ・見積は一定時間の残業が前提 →それで残業しなければ◎ ・高残業を毎年続けているSE,PGは実力者が多い →その人でなくてもできる仕事を外す(下級者やアルバイトの活用) 上級管理者の意識がまず第一 ②無茶な残業をしなくて済む仕組みの構築 ・工期の標準(別紙) ・要求仕様書の上級管理職による確認→ユーザーとの対話を(リスク管理方法の活用) ・PAM ・PAC ・TRM ・WBS ・CCPM ・DBパトロール ・目標の設定 a. カットオーバーの日は定時で帰宅できるプロジェクトマネジメント b. 計画以上の利益を出そう運動 c. 従来の方法、前提の見直し(もっとよい方法がある) 31
    • 質問10:米国の企業は、基本設計完了後に ベンダー委託するので、失敗が少ない。 日本のユーザーも見習うべきである。 32
    • 契約形態と選択 どのタイプを選択するのか、プロジェクト企画時に明確にして始めること 保守 保守 運用 戦略 要件 外部 内部 プログ 運用 企画 定義 設計 設計 ラミン 企画開発モデルタイプ グ タイプ 1・IT利用模索プロジェ 保 A V V クト 守 運 B V U 2.標準モデル 用 の 選 C U V 3.米国型インハウス・ 択 モデル ・ D U U 右 4.先進企業モデル の 選 5.Win-Winモデル 択 ユーザー企業の分担 ベンダー企業の分担 U ユーザー企業の分担 V ベンダー企業の分担 33
    • *何かおかしいと感じる力 問題感知力・問題解決力 *もっと良いもの・方法がないかと考える力 *理想状態を想定できる力 対策案 設計 現状把握・ 運用 問題点 理想像 分析 把握 策定 実装 利活用 想定 問題感知力 活用力 問題解決力 ・ユーザー企業ではもっとも大切 独創力 ・使いこなし力 ・学校で習う内容 柔軟性 ・柔軟な理解力・発想力 ・現場力 ・たくましい実行力 ・感じ・考える力 技 読み・書き・考える力 読み・書き・考える力 術 ・See→Touch→Measure の →Analyze→Think→ 要素技術 情報活用力 伝 ・組織としての改善・改革風土 承 (これだけは最新技術の使える 新ビジネス創造力 と 者が優先する) ・改善技術(IE,OR,QC、WD, 進 化 KTなど) プロジェクト管理技術 信頼性向上技術 育成阻害要因(解決可能) 人間力 人間力 ・階層のフラット化・転職 ・成果主義 ・長時間残業 組織経営力 組織経営力 34
    • まとめ システムの上にシステムがある。 ・目線を高めて、もっと良いものがないか考えること ・良いか悪いかを決める評価尺度の基準を持つこと ・レベルを上げるためのアクションを起こすこと ・この問題が解決したら、すべて良くなりますか?を繰り返すこと ご清聴ありがとうございました 35