日本システム監査人協会第168回月例研究会

Size: px

Start display at page:

Download "日本システム監査人協会第168回月例研究会"

つづるかいじ
4 years ago
Views:

1 日本システム監査人協会第 233 回月例研究会 IT システム開発のトラブルはどこからくるのか? 日本アイビーエム株式会社東京基礎研究所インダストリーソリューションサービス品質エンジニアリング部長細川宣啓氏 2018 年 7 月 12 日 ( 水 ) 機械振興会館ホール

2 トラブルプロジェクトの発生メカニズムと対策の今昔物語 2018 年 6 月 13 日日本アイビーエム株式会社東京基礎研究所細川宣啓

3 目次 1. 品質に対する一般認識 2. 開発者運用者の役割 3. 弊社の取り組み /08/15

4 1. 品質に対する一般認識品質の一般定義は絶対的なものではなく相対的なものです ISO 8402 ( 品質管理及び品質保証 - 用語 ) あるものの明示された又は暗黙の必要性を満たす能力に関する特性の全体 ISO 9000 ( 品質マネジメントシステム ) 本来備わっている特性の集まりが要求事項を満たす程度品質保証 : 品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部 /08/15

5 1. 品質に対する一般認識 IT に対する期待は立場によってまちまちなため品質の一律な定義はできません IT に対する期待の一例 IT 部門責任者開発担当者プロジェクトの... 納期コスト生産性要件対応率初期障害率経営層プロジェクト成功率システム障害発生件数要員の稼働率要員のスキル先進性利用部門責任者運用担当者システムの... 稼働率障害発生件数障害対応時間変更要求対応率 IT ベンダー事業の売上げ利益お客様満足度への IT の貢献 IT 予算水準の妥当性 IT 部門の価値 (IT 施策の実現度など ) 業務の効率改善度プロジェクトの投資額対効果契約遵守 ( 納期コスト ) SLA お客様満足度利用者使いやすさ応答時間監査部門機密性完全性 /08/15

6 1. 品質に対する一般認識 IT プロジェクトの成功率は 3 割うち過半数が品質の問題というデータもありますが失敗プロジェクト自体が開発方法や開発者の品質の問題と捉えることもできるでしょう日本企業における IT プロジェクトの成功率日経コンピュータ , 特集プロジェクト成功率は 26.7%,pp50-71 より /08/15

7 1. 品質に対する一般認識失敗プロジェクトをプロジェクトそのものの問題と構造的な問題に区別する考え方もあります 1) プロジェクトそのものに問題があるそもそもプロジェクト計画に無理があるスコープ納期予算要求品質スキルプロジェクトの進め方に無理があるプロジェクトマネジメント要員調達意思決定 2) 業界や組織などに構造的な問題がある業界や組織の文化常識がプロジェクトになじまない意思決定者の個人的性格目的がプロジェクトになじまないどちらもプロジェクト単体では対応できない参照資料 : 日本システムアナリスト協会不条理なコンピュータ研究会メンバー清水順夫プロジェクト失敗の構造を生むユーザー企業が抱える問題 30 のプロジェクト破綻例に学ぶ IT 失敗学の研究 /08/15

8 1. 品質に対する一般認識情報システム部門のミッションも変化しています情報システム部門に対する期待の変化グローバルレベルの競争経営が情報システム部門へ連結経営の重視顧客ニーズの多様化 IT の急速な進歩プロセス指向期待する役割業務プロセス企業競争力強化への貢献ビジネス環境変化改革への貢献機能指向業務効率向上への貢献業務効率化ビジネス戦略支援 /08/15

9 1. 品質に対する一般認識 IT 部門の組織的な位置づけもまた変化しており IT および IT 部門の貢献度をどう評価するか評価の裏づけとしてのシステムの品質をどう捕らえるかは難しい課題です CIO の抱える問題と IT 部門の位置づけ外部に任せるアウトソーシング再内包化内部統制セキュリティ経営資源の選択と集中コスト削減 IT 子会社化人材の確保技術やスキルの高度化 CIOのミッション ITを使って経営に貢献する ITのリスクを管理する IT 資源を最大限活用する IT 部門の位置企業本体で持つ /08/15

1. 品質に対する一般認識参考 : 情報システム部門のミッションと課題 ( 例 ) 情報システム部門のミッション ITを使って経営に貢献する ITのリスクを管理する IT 資源を最大限活用する情報システム部門の課題 IT 投資コストの抑制 IT の投資対効果が見えない効果的な IT 投資が行えない保守コストの増大 IT サービスの品質低下重大なセキュリティ事故の発生属人的な IT

10 1. 品質に対する一般認識参考 : 情報システム部門のミッションと課題 ( 例 ) 情報システム部門のミッション ITを使って経営に貢献する ITのリスクを管理する IT 資源を最大限活用する情報システム部門の課題 IT 投資コストの抑制 IT の投資対効果が見えない効果的な IT 投資が行えない保守コストの増大 IT サービスの品質低下重大なセキュリティ事故の発生属人的な IT 運用による重大トラブルの発生組織の弱体化情報システム部門の役割が不透明利用部門の IT 有効活用を支援できないプロジェクトマネジメント能力の低下欠如コストセンターとしの位置付けから脱却できない情報システム部門の価値に対する不信感の増大ベテラン要員の減少情報システム部門の要員のモラルダウン無秩序なシステム開発運用 IT に関する標準や業務ルールの未確立サーバーシステムの乱立統一性の無いシステムインフラによる開発運用コストの増大社外向け Web のデザインの不統一変化に対する対応の遅れコード体系の不整合によるパッケージ導入の阻害複雑化したシステムインフラによるシステム統合の阻害 /08/15

11 目次 1. 品質に対する一般認識 2. 開発者運用者の役割 3. 弊社の取り組み /08/15

12 2. 開発者運用者の役割ところで IT に対する期待や IT 部門の位置づけが変化する一方で情報システムの開発運用における各者の論理的な役割分担は変わっていません情報システム管理体系各部門の役割り分担の明確化と部門間牽制 1. 役割適用業務システムの企画立案具現化の推進ユーザー要件の確定システムテストへの参画局面完了の承認システムの普及推進投資の最適化 2. 責任 / 権限システム化ニーズのまとめシステム化優先順位付け構築 / 運用者の決定活用の促進期待効果の実行評価 1. 役割対象とする業務のシステム化による期待と目標の定義システムを活用し目標に貢献する 2. 責任 / 権限システム化ニーズ業務への適用予算措置利用者のニーズの提示構築内容の検収活用ガイド等定着への活動実施サービスの利用による効果結果の提示ユーザーオーナーアプリケーションシステムサービスの提供開発運用委託サプライヤー 1. 役割高品質の情報システム構築 / 運用低コストの情報システム構築 / 運用納期遵守の情報システム構築 / 運用 2. 責任 / 権限オーナーからの依頼に基づく実施実施内容の監査性の証明サービスの提供技術 / 人材の育成 /08/15

意思決定者の必要性関係者が増えるとニーズとサービスを整理調整するためにシステム投資の意思決定者であるオーナーが必要になりますオーナーはユーザー側サプライヤー側および経営側の3 種類が考えられます ( アプリケーション ) オーナー

13 2. 開発者運用者の役割補足説明 : オーナーユーザーサプライヤーの関係基本形基本的な役割分担はユーザーがサプライヤーにニーズを示しサプライヤーがシステムサービスを提供することですアプリケーションオーナー機能の必要性戦略的にビジネスに貢献するシステムが求められるとユーザーとサプライヤーの橋渡しをするアプリケーションオーナー機能が必要になりますユーザー ( 利用者 ) ニーズサービスサプライヤー ( 提供者 ) CEO CFO CIO 意思決定者の必要性関係者が増えるとニーズとサービスを整理調整するためにシステム投資の意思決定者であるオーナーが必要になりますオーナーはユーザー側サプライヤー側および経営側の3 種類が考えられます ( アプリケーション ) オーナー CEO,CFO 経営責任者 ( 経営オーナー ) CIO (IT 部門のオーナー ) ユーザー ( 利用者 ) ( アプリケーション ) オーナーサービスサプライヤー ( 提供者 ) ユーザー ( 利用者 ) ニーズ /08/15 サービスサプライヤー ( 提供者 )

14 2. 開発者運用者の役割弊社の SI サービスの位置づけを単純化するとサプライヤーの役割になります弊社の SI サービスの位置づけ CEO CFO CIO オーナーシステム化ニーズ業務への適用開発運用委託ユーザーサプライヤーお客様サービスの提供弊社 /08/15

15 2. 開発者運用者の役割お客様のニーズに合わせオーナーやユーザーの責務を分担させていただくケースもあります CEO CFO オーナー CIO 企画意思決定もアウトソースしている場合システム化ニーズ業務への適用開発運用委託お客様弊社ユーザー業務もアウトソースしている場合サービスの提供サプライヤー /08/15

16 2. 開発者運用者の役割開発者は開発者の役割を果たす必要がありますライフサイクル上の役割分担オーナーユーザー ( お客様 ) 契約受入戦略策定企画立案要件定義設計開発テスト運用保守契約引渡サプライヤーはこの部分でご提案作業や開発準備などはあるサプライヤー ( 開発者 = 弊社 ) サプライヤー ( 運用者 = お客様弊社 ) /08/15

17 参考 ) 大トラブル発生の段階 - トラブルは大トラブルになりやすいスコープの見誤りにより見積りコストでの開発目途が立たないお客様満足度 ( 提案品質 ) 良プロジェクトスタート時にこの象限にないのは論外無理な提案トラブル健全フロシェクトコスト ( プラン ) 悪良コスト不足により品質低下 SOW( カバレッジ ) の縮小大トラブルトラブル低品質納期遅れリカバリするために体制強化オーバーラン悪スキル不足 16

18 負の連鎖を断ち切る必要があるさもなければ同じことの繰り返し... スキルリソースが不足不十分な体制リスク未対応のままビジネスプレッシャーに押し切られる優先度の明確化低稼働率のためリソースシフト将来起こる案件を把握してアサインするためにオポチュニティ情報をシェアコストが十分でなく稼働率低迷育成する時間が取れないミスマッチのアサイン育成強化 PM/ITA/SS トラブル解決のため優秀な PM ラインを投入トラブルの発生 17

19 例 ) 月次報告をプロジェクトに義務づけプロジェクトの健康度を測るために 7 つの観点で検証追跡しています従来の月次報告 Q: 品質 C: コスト D: 進捗 R: リスク D:Discipline 遵守ただちに是正アクションが必要近いうちに是正アクションが必要順調特別なアクション不要 7 Keys Health/Risk Management ステークホルダーがコミットしている Stakeholders are Committed ビジネス上の利益が実現されている Business Benefits are being realized 作業およびスケジュールは予測可能である Work and Schedule are Predictable スコープは現実的で的確に管理されている Scope is Realistic and Managed チームは高いパフォーマンスを実現している Team is High Performing リスクが軽減されている Risk are Being Mitigated デリバリー組織にとっての利益が実現されている Delivery Organization Benefits are being realized 各 Key の詳細解説は付録にあります 18

20 サービスサイエンスの一例として 7Keys の結果や月次報告書の記述内容を元にトラブルを予兆させる手掛かりを抽出しようとしています 7 Keys スコア因子分析プロジェクトの 7 キースコアの時系列変化のパターン時系列変化によりプロジェクトの状態を把握できないか? アクションの効果を可視化したい 7 Keys スコア算出のための質問項目数 : 77 ニューラルネットワークプロジェクトのリスクの予測質問項目の答えの変化により将来のリスクを予測できないか? プロジェクトレポートのテキスト分析によるキーワード抽出傾向分析など重要質問項目の選択ニューラルネットワークと統計的学習手法によりデータに基づく重要質問項目の決定 19

21 因子分析トラブルパターン解析 Reduction of dimension for easier visualization - Analyzed data 7 Keys All Score (QA report) - For overall trend 御参考資料 Two main factors are selected from 7 keys by Principal Factor Method with promax rotation Project time-transition pattern is useful to confirm action effectiveness 7 keys factor relationship by Structural Equation Modeling DelScheduleRiskScope ,5,6,11 7, y=0.0751x % Status Green Incomplete Red Yellow y=-0.155x % scope schedule Delivery benefit factor result Stakeholder benefit team risk StakeholderBenTeam Factor 1 2 Delivery Benefit Schedule Risk Scope Stakeholder Benefit Team

22 参考 ) 因子分析トラブルに陥るときのパターンの可視化 /07 ed exit 6/07 id,ip exit 7/07 itb, st, si 8/07 red 12/07 mnt review 2007/8 si 2007/9 Status Red Yellow Contract update /07 ip exit 5/07 red 7/07 itb exit ITb 2007/5 Status Green Red Yellow DelScheduleRiskScope /2 2008/1 2007/ / /10 DelScheduleRiskScope /9 2007/8 2007/7 2007/2 2007/3 2007/4 2007/ / /9 2007/1 2006/ StakeholderBenTeam StakeholderBenTeam 21

23 バックアップマスタースケジュールだけでも兆候がとらえられることがあります品質欠陥の兆候 : マスタースケジュールからわかる兆候の例局面間のオーバーラップがある ( 特に要件定義と外部設計の境界の重なりまたはこのどちらかが他の局面とオーバーラップ ) マスタースケジュールが頻繁に更新されている今後の計画だけで過去が省かれているマスタースケジュールマイルストーンが書かれていないタスク間の依存関係が示されていないクリティカルパスがわからないマスタースケジュールと WBS や要員計画との整合性がない周辺の関連するプロジェクトのスケジュールが書かれていない注意 : 上記のケースが常に失敗するわけではない /08/15

24 バックアップ特に意思決定やコミュニケーションの不足は失敗しやすい環境を作ります品質欠陥の兆候 : 失敗を予兆させるコミュニケーション状況の例お客様のマネジメントレベルと定例会合がない投資額に見合うお客様トップレベルの参画がない最終意思決定者が曖昧で体制図に書かれていない最終意思決定は多数の関係者による合議となっている体制図がない体制図上に責任者が書かれていないまたは複数書かれている ( プロジェクトリーダーチームリーダー...) 注意 : 上記のケースが常に失敗するわけではない /08/15

25 バックアッププロジェクトマネジメントの勘所 (1/4) 1. 全体スコープ常に明確にしておく最初に明確化 ( お客様協力会社 ) 作業範囲と分担( それ以外はやらないという意味ではない限界以上は別枠管理) 作成成果物 etc 当初それで見積りを作成契約時との整合性を持たせる随時関係者の共同認識台帳管理一目でわかるように変更管理必ず変更管理システムを通して対応する担当者が勝手に受けない些細な仕様変更の積み重ねに要注意チリも積もれば数十人月? 総量重要度別チーム別等の工数期間の把握 /08/15

26 バックアッププロジェクトマネジメントの勘所 (2/4) 2. スケジュール進捗管理目に見える形 ( 仕組み ) で実施 (WBS ベースなど ) 現状および予定の把握数字とグラフ対策などを共通フォームで ( 全員が共有 ) EVM による管理 3. 品質開発工程での作り込みテスト検証では手戻りしてしまう! 品質保証 (QA:Quality Assurance) 開始前のガイドルール化成果物作成ガイド各局面完了基準ウォークスルーインスペクションのルール化ガイド等 WBS:Work Breakdown Structure, EVM: Earned Value Management /08/15

27 バックアッププロジェクトマネジメントの勘所 (3/4) 4. 生産性品質の向上ノウハウ情報の活用仕組み作りは後からでも可まずルール化スコープ( 作業 (WBS) 成果物) の定義サンプルテンプレートサンプルフォーム... 作成成果物の展開と活用スキルの横展開各種のデザイン開発スキルプロジェクト運営スキルなどデータ管理一元管理後工程でとても有効 5. コスト問題の早期発見 ( 顕在化 ) お客様に報告迅速対応初期消火の徹底結果的に最小費用化 /08/15

28 バックアッププロジェクトマネジメントの勘所 (4/4) 6. リソースメンバーの体調管理抜けると大きなインパクト早く治すお客様にきちんとお願いし了解を得る 7. 報告定期報告定義( 種類内容相手先サイクル ) 不定期報告 ( リスク作業工数...) 隠さない状況対策案見通し... 等を判り易くまとめてご報告緊急時はまず口頭で /08/15

29 バックアップ失敗プロジェクトの共通の特徴プロジェクト計画の不備プロジェクトマネジメント (PM) 計画 (PMP) がない過少見積り自己流見積り品質管理の不備変更管理の不備 PMの不備 ( 特にスコープマネジメント不備 ) PMの不足上流局面が不備のまま次局面へ見切り発車開発当事者以外の要員 ( 例 : コンサルタント ) が要件定義を実施立上り時の体制社内要員不足開発者 ( 質量とも ) 不足テクニカルスペシャリスト不足プログラミングが多いにもかかわらず非局面化要件定義 (RD) が適切に行われていない不適切な契約 / サブコントラクティング = 共通項 = プロセス, 標準からの逸脱 /08/15

30 目次 1. 品質に対する一般認識 2. 開発者運用者の役割 3. 弊社の取り組み /08/15

31 3. 弊社の取り組み弊社の考える品質は一言で言えばお客様の要求を満たすことですそのことがお客様の満足度を高め結果的に品質が高いサービスをお届けすることになります弊社の品質 = お客さまの要求を満たすことお客様の高い満足度 = 品質が高いお客さまの要求を満たすには... 優れた製品やサービスそれをご提供する人管理方法協力会社等の高いスキルが必要です... これらを実現するために一定の利益も必要です /08/15

プロセスプロジェクトマネジメント能力 QA レビューお客さま満足度 REV GP 評価カルチャー方法論

32 3. 弊社の取り組み品質を高めるためのポイントはサービスをご提供するデリバリーチームのプロジェクトマネジメント能力 CRM プロセス QA レビューの 3 つです品質向上のポイントお客さま満足度調査プロジェクトチーム CRM プロセスプロジェクトマネジメント能力 QA レビューお客さま満足度 REV GP 評価カルチャー方法論開発方法論開発プロセスプロジェクト指向組織スキル技術多様な研修開発ツールベストプラクティス /08/15

33 3. 弊社の取り組みお客様の要求を満たすためには何よりもサービスを提供するデリバリーチームの品質が高くなくてはいけません弊社はデリバリーチームに高いプロジェクトマネジメント能力を求めていますプロジェクトマネジメントとは... 個々人を組織化して作業を順序良く行うことにより 1. 決められた品質以上の成果物を 2. 決められた期間以内で 3. 決められた予算以内で作り上げるしかも最短距離を最適な技術で /08/15

34 3. 弊社の取り組み実際ソフトウェア開発の生産性の個人差は 3~25 倍以上あり品質を高めるためにはデリバリーチームメンバーのスキルの維持向上が何よりも必要です個人のスキル分布例参照 :IBM サンノゼ研究所 Programming &Programmers Productivity /08/15

35 3. 弊社の取り組みプロジェクトチームは下記のマネジメント体系に沿ってプロジェクトを遂行することが求められます立ち上げ企画運営変更管理プロジェクト計画 WBS ( 成果物一覧 ) 進捗管理予算管理問題 / 課題管理品質管理計画リスクリスク管理終結プロジェクトマネジメント体系評価 /08/15

3. 弊社の取り組み主要なプロジェクトは EVM による進捗管理を行うことが義務付けられています EVM と EAC EAC( 完了時コスト予測 ) 1,200,000 1,000,000 VAC( 完了時コスト差異 ) ETC( 残作業コスト予測 ) <EVM による進捗報告項目の一例 > 800,000 PV( 出来高計画値 ) BAC ( 完成時総予算 ) SV A チーム 1.

36 3. 弊社の取り組み主要なプロジェクトは EVM による進捗管理を行うことが義務付けられています EVM と EAC EAC( 完了時コスト予測 ) 1,200,000 1,000,000 VAC( 完了時コスト差異 ) ETC( 残作業コスト予測 ) <EVM による進捗報告項目の一例 > 800,000 PV( 出来高計画値 ) BAC ( 完成時総予算 ) SV A チーム 1.2 B チーム 0.9 C チーム ,000 CV( コスト差異 ) CV ,000 SV( スケジュール差異 ) TV 5 日先行 3 日遅れ計画通り 200,000 AC( コスト実績値 ) EV( 出来高実績値 ) SV = 計画と実績のコスト差異を表します CV = 計画と実績のスケジュール差異を表します TV = 計画と実績の時間差異を表します 0 8/30 9/6 9/13 9/20 9/27 10/4 10/11 10/18 10/25 11/1 11/8 11/15 11/22 11/29 12/6 12/13 12/20 12/ /08/15

37 3. 弊社の取り組みインスペクションやチームレビューなどプロジェクト内での日常の品質管理活動も重要ですレビューの種類最も公式コスト高最も非公式コスト低インスペクションチームレビューウォークスルーペアプログラミングピアデスクチェックパスアラウンドアドホックレビュー公式レビュー Karl E. Wiegers ピアレビュー日経 BP ソフトプレス /08/15

38 弊社の取り組み欠陥除去活動は規模の大きなプロジェクトほど効果が期待できます 1 K ステッフ当たりの相対負荷個人差欠陥除去活動最小労力開発 K ステップ /08/15

39 3. 弊社の取り組み人材については必要な 3 つのスキル領域 ( 経営ビジネス IT ) を定義しています経営に関する知識スキルビジネススキル 100 事業活動の概要 101 リーダーシップ 102 顧客市場の理解と対応 103 戦略の策定と展開 104 人財開発と学習環境 105 プロセスマネージメント 106 情報の共有化と活用 107 事業活動の成果 108 顧客満足経営に関する知識スキルミッション達成 IT 経営ビジネスビジネススキル 300 コンサルティングスキル 301 ドキュメンテーション能力 ( 静的なもの ) 302 コミュニケーション能力 ( 動的なもの ) 303 問題解決能力 304 プロジェクトマネジメント能力 305 英語 306 ヒューマンスキル ( 人間力 ) 307 投資価値定量化スキル IT に関する知識スキル IT に関する知識スキル : : 107 事業活動の成果事業計画の予算管理ができる投資対効果の把握ができる財務管理がわかる有形資産の管理ができる 108 顧客満足顧客満足度不満足度の判断ができる 200 最新 IT の技術動向, 技術予測, 評価技術 201 自社の IT 基盤の理解 203 システム構築技術 204 プロジェクト管理技術, 技法, 知識 205 情報システム構築提案評価技術 206 ハードウェア, ソフトウェア通信ネットワーク関連技術 207 データベース関連技術応用技術 208 クライアントサーバ技術 209 個別アプリケーション技術 210 ネットワーク技術応用技術 211 システム運用管理構成管理知識 212 インターネット関連技術 213 ドキュメントソリューション技術 /08/15

40 3. 弊社の取り組みプロジェクトの上流フェーズでの品質の作りこみも大きな効果を発揮しますコスト大規模開発での手戻りコストの実績局面内での欠陥除去コスト前工程以前の欠陥除去コスト本来の理想的開発コスト要件定義外部設計内部設計開発実施 ( 統合テスト a ) 統合テスト b システムテスト局面 /08/15

41 3. 弊社の取り組み配布対象外プロジェクトチームを支える CRM プロセスも品質管理の重要なポイントです弊社の CRM プロセス (1/2) オポチュニティマネジメントソリューションデザインーソリューションデリバリーオホチュニティの連絡オホチュニティ内容の確認オホチュニティの検証オホチュニティの評価ソリューションデザイン営業活動の終了プロジェクトの開始 - プロジェクトの遂行会議レビューの仕組み S J-SOX Control Point QAレビューポイントプロジェクトのクローズ 1.1 お客様のビジネスと契約情報の識別 1.2 オポチュニティ識別者 (OI) のアサイン 1.3 オポチュニティの通知 / OM システムの更新 2.1 お客様のビジネスニーズの理解 2.2 お客様のスポンサーの確認 2.3 オポチュニティの識別 3.1 オポチュニティの確認 3.2 お客様要望事項の討議 / 識別 3.3 オポチュニティの検証 / OM システムの更新 4.1 カスタマーレコードの確認 4.2 オポチュニティアセスメントの実施と BTT の決定 4.3 リスクアセスメントの実施 4.4 オポチュニティの評価 S DB1 B2B B&P /08/15

42 3. 弊社の取り組みプロジェクトのトラブルの原因の 3 割は企画計画段階にあると言われておりプロジェクト開始までにそれらの要因を潰す必要があると考えます IT プロジェクトの危機要因 ( 分析の一例 ) 企画計画出展 : クロスリンクコンサルティング失敗を回避するプロジェクトマネジメントの勘所要件定義プロジェクト体制 34% 32% 34% 戦略的意図無謀な市場参入売上げ至上主義 PM 選定の誤り等要件設定能力不足要件構築力不足マネジャーのマネジメント能力不足組織の PM サポート不足上流の品質管理の重要性早くコーディングに着手しても早く完成しない~むしろ遅れる大規模システムの欠陥の45%~80% は設計までの問題に起因する早期の欠陥除去はスケジュール遵守に不可欠であるテストによる欠陥除去は必須だが, プロジェクトの全体から見れば有効ではない出展 :Capers Jones /08/15

43 3. 弊社の取り組み 3 つめのポイントとして QA を中心としたプロジェクトの品質管理活動があります Quality Assurance (QA) とはお客さまのご要望を満たす高品質かつ一定の利益の確保ができるソリューション提供を確実にするための独立したレビュー活動である QA レビューによって弊社が提供するサービスの品質を組織的かつ継続的に確保向上することによりお客様の経営に対する適切な貢献を果たし結果としてお客様と弊社の双方の利益を確保する QA レビューは提案書の作成時からサービス実施期間にわたり第三者 ( 社長直属組織 ) であるサービス品質部門の専任 QAer によって実施される /08/15

44 3. 弊社の取り組み QA はトラブル予防発生トラブル対応スキル向上の 3 つの目的を持っています予防トラブルプロジェクト QA と PM のスキルの向上全ての契約の提案の品質を向上する - 適切なリスクレベルの決定 - IBMのサービス実現可能性の検証 - リスク抑制のアクション及びプラン策定のために提案書作成責任者を支援プロジェクトの品質を向上するプロダクト品質プロセス品質の両方 - 問題の早期発見 - 問題収束アクションを作るプロジェクトマネジャーへの支援トラブルプロジェクトの数の減少 - 実行可能な改善策を策定する PM への適切な提言と支援 - 改善活動のフォローアップビジネスへの影響の検証と報告根本原因の分析と問題収束アクション作成の支援お客様満足度の向上 QA 教育と研修の実施 QA 活動を通しプロジェクトチームへプロジェクトマネジメントに必要とされる能力の向上を支援 /08/15

45 3. 弊社の取り組み QA 部門はプロセスとプロダクトの両面から品質を検証していますプロダクトの品質 * 設計品質プログラム品質と分類されることもある正しいものを作っているか作成物をチェック開発局面毎の作成物の中身 - 文法上のエラー - 局面に応じた精度 - 目標品質の実現性 - 全体の整合性妥当性契約書と提案書成果物等の整合性プロセスの品質正しく作っているか品質を作りこむ過程をチェック開発局面や開発メソッドの妥当性契約や計画の妥当性プロジェクトマネジメントの方法チーム内レビューの方法 /08/15

46 3. 弊社の取り組み QA レビューを補足する具体的検証作業として QI を実施しています When? プロジェクト上流フェーズにて ( 概念 / 基本設計 ) What? 中間最終成果物の品質を QI とは何か Why? Who? レビュー専門の第三者組織が How? 目視でプロセスに従って一定評価基準にてプロジェクトリスク最小化と上流成果物品質の向上欠陥検出品質向上 / 欠陥予防リスク最小化 /08/15

47 3. 弊社の取り組み最新のスキルと現場感覚を持った QAer を確保するために現場との人材交流を進めていますサービス品質の位置づけと人材調達社長サービス品質担当役員サービス品質所属部員の 3 分の一が過去一年で現場と入れ替わっています品質技術 SI サービス担当 QAer SI サービス提供部門 SI プロジェクト担当者の頻繁な異動 /08/15

48 3. 弊社の取り組みプロジェクトがレビューの価値をどのように捕らえるかによって効果も変わるでしょう QAに付加価値を求めるのか自己点検の機会と見るのか WWのルールとして強制されるのか自発的なチェックポイントと見るのか QA バイオレーションを避けるのか積極的な点検に活用するのか考え方の違いはプロジェクトの結果にも影響している /08/15

49 3. 弊社の取り組みこれらの取り組みの効果を測るためプロジェクト毎お客様毎に満足度を伺っています調査項目 Q1 総合満足度 Q3_19 適切なソリューション設計 Q3_1 目的要望に対する傾聴 Q3_20 コンサルティング方法論 Q3_2 目的要望に対する理解 Q3_21 メンバーの専門性の保有 Q3_3 目的要望に対する対応 Q3_22 プロフェッショナルとしての資質 Q3_4 技術的支援の満足度 Q3_23 IBMパートナー / 上位管理者の対応 Q3_5 技術的支援対応の満足度 Q3_24 お客様とのチームワーク Q3_6 業界に対する知識保有 Q3_25 プロジェクトマネージャーへの総合満足度 Q3_7 ビジネスに対する提案革新 Q3_26 IBMパートナー / 上位管理者の貢献度 Q3_8 合意内容の契約書への反映 Q3_27 全体を通した明快なコミュニケーション Q3_9 価格設定他社との比較 Q3_28 協業のし易さ Q3_10 プロジェクト全体の満足度 Q3_29 要望に対する達成 Q3_11 効果的なコミュニケーション Q3_30 投資に見合った価値 Q3_12 完了時の成果物の納品 Q8-Q10 リースの利用 Q3_13 プロジェクト期間 LM1-2 再販他社への推奨 Q3_14 効果的な管理運営 Q16 お客様の所属とITへの責任の有無 Q3_15 メンバーの知識ノウハウの提供 Q17 IT 関連,Consultingを選択する際の役割 Q3_16 プロジェクトの品質 Q18 お客様の職位 Q3_17 IT 技術を業務に結びつける能力 Q19 お客様の従業員数 Q3_18 結果に対する説明責任 Q21 アンケート以外でのご意見ご要望 /08/15

50 3. 弊社の取り組み IBM の ADE モデルによればプロジェクト遂行には 6 つの要素があります ADE モデル : プロジェクト遂行に必要な 6 つの要素組織の目標計画の明確性取組み姿勢コミュニケーション動機付け企業文化等カルチャー開発保守の手順技法標準化管理方法等品質生産性見積りコストスケジュール満足度業績評価管理指標等評価組織スキル方法論技術開発支援ツール管理ツール開発保守環境ハードウェアソフトウェアネットワーク等組織人の役割責任体制人材配置等 /08/15 開発方法論や IT 技術等の教育訓練管理者教育等 ADE: Application Development Effectiveness

51 3. 弊社の取り組みプロジェクトの遂行能力は桶の水量にたとえることができ 6 つの要素のバランスが重要です対応策 : 評価指標の導入と評価対応策 : 採用研修ナレッジの共有など対応策 : 体制と責務の明確化 /08/15

52 3. 弊社の取り組み配布対象外これらの活動の結果長期的にはトラブルプロジェクトが大きく減少していますトラブル減少のトレンド /08/15

53 ありがとうございました /08/15

プロジェクトマネジメント知識体系ガイド (PMBOK ガイド ) 第 6 版訂正表 - 第 3 刷り注 : 次の正誤表は PMBOK ガイド第 6 版の第 1 刷りと第 2 刷りに関するものです本 ( または PDF) の印刷部数を確認するには著作権ページ ( 通知ページおよび目次の前 )

プロジェクトマネジメント知識体系ガイド (PMBOK ガイド ) 第 6 版訂正表 - 第 3 刷り注 : 次の正誤表は PMBOK ガイド第 6 版の第 1 刷りと第 2 刷りに関するものです本 ( または PDF) の印刷部数を確認するには著作権ページ ( 通知ページおよび目次の前 ) の一番下を参照してください 10 9 8 などで始まる文字列の最後の数字はその特定コピーの印刷を示します