ＳＣＭとＩＴ経営・実践研究会 深堀りシンポジウム 経営者視点に基づくプロジェクトの成功・失敗の考察 QCDは唯一絶対の評価基準か？ 2010年8月28日 日本アイ・ビー・エム株式会社 栗山 敏 目 次 1. イントロダクション 本日のお話の背景と込めた想い（問題意識） 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 2 | | 経歴紹介 第一次学生時代 昭和５３年３月 昭和５７年３月 昭和５７年４月 大阪府立 北野高等学校 卒業 早稲田大学 法学部 卒業 日本アイ・ビー・エム株式会社入社 ・１５年間中堅企業担当の営業として情報システムの 提案・導入活動に従事。（営業マン） 平成１０年７月∼ エグゼクティブ・プログラムに異動。IBM天城セミナーの 平成１４年１２月 インストラクターとして経営管理者対象の研修を担当。 平成１１年４月 中小企業診断士登録（情報部門） 第二次学生時代 3 | | 平成１２年４月∼ 平成１４年３月 岩手県立大学大学院・ソフトウェア情報学研究科、 博士課程（前期）での「情報システム機能の有効性評価方法 に関する研究」にて修士号を取得。 平成１４年１２月 平成１５年１月∼ 平成２２年１月 ＩＴコーディネータ登録 IBMビジネスコンサルティングサービス株式会社に出向 IBM天城セミナーに復帰 第三次学生時代 平成２１年４月∼ 武蔵大学経済学部 博士後期課程在学中 プロジェクトをGolfに例えると・・・・本来はこうありたい。 ３打で ３打で 乗っけるよ！！ 乗っけるよ！！ ２パットで ２パットで 入れるね！！ 入れるね！！ ＨＡＰＰＹ ＨＡＰＰＹ 営業 ＰＭ グリーンオン ＝ 契約締結 というアナロジーです。 ＰＡＲ５：ロングホール SCMとIT経営・実践研究会 2006年11月 「失敗事例に学ぶＰＭ論」 福本 勲 会員 4 | | Golfに例えると・・・・実際は チョロ チョロ だ!! だ!! ＯＢだ！！ ＯＢだ！！ １つで １つで 入れてよ!! 入れてよ!! 次で 次で 取り返せ!! 取り返せ!! 営業 無理だよ 無理だよ そんなの!! そんなの!! ＰＭ 実際グリーンに乗ったのは 4打目、5打目、6打目・・・ 始まる前から破綻!! 始まる前から破綻!! SCMとIT経営・実践研究会 2006年11月 「失敗事例に学ぶＰＭ論」 福本 勲 会員 5 | | 大学院での研究テーマとその想い 情報システムプロジェクトの成功要因の研究 ∼人的要因と組織的要因を中心に∼ 平たく言えば・・・ 「デスマーチ」の撲滅！ 6 | | 次のようなプロジェクトは成功でしょうか？失敗でしょうか？ クイズ 統計資料では「QCD目標が達成されたプロジェクト」を成功としていることが多いが・・・ コストが計画よりも1円オーバーした。 本番稼動が計画よりも1日遅れた。 多少の超過はOKだとすれば、ではどの程度までなら許容範囲なのか？ ベンダーは情報システム部門からの仕様書の通りの品質、コスト、スケジュールでソフ トウェアを開発して納入した（QCDは100点）が、情報システム部門とユーザー部門の 意思疎通が行なわれておらず、納入されたソフトウェアは実務に使われなかった。 コストは2倍、スケジュールは1年遅れ・・・でも本来のプロジェクトの目的は達成され、順 調に稼動中。 【これからのお話の着眼点】 そもそもQCD目標は「適切に」設定されていたのか？ 実務の中でQCD目標はどのように（いつ、誰によって、どのように）設定されるのか？ であれば、プロジェクトの成否をQCD目標で判定するのはどこまで「適切」なのか？ 7 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 8 | | 日経コンピュータ 第２回プロジェクト実態調査８００社 2008年12月1日号特集・・・成功率は３１．１％ 2008年12月1日号特集・・・成功率は３１．１％ QCD目標のすべてを達成したプロジェクトを「成功」と定義 2003年は26.7% （＋4.4ポイント） 納期遅れの原因は「要件定義の長期化」がトップで43.6% - 要件自体が高度化し、難易度が上がった。 情報システム部門の要件定義能力が低下した。 品質は48.1%が目標を未達成。 - テストが不十分･移行作業に問題が発生・・・41.7% 要件定義が不十分・・・36.7% 情報システム部門の平均人数は13.1人。対象企業の全従業員672.2名に 対して1.9% 9 | | 「ＩＴ経営」を通じた「新しい成長」の実現 要件定義が困難になってきている 部門のシステムから企業間のシステムへ 省力化から増力化、新しいビジネスモデルの構築へ 10 | | 平成１８年４月１０日 経済産業省 バランス・スコア・カード的に見た要求定義の難易度の違い 省力化のシステムの要件定義の難易度は比較的低い。 - 定石がある、他社事例をベストプラクティスにできる、現場で完結する・・・ 増力化、画期的なビジネスモデル実現のシステムの要件定義の難易度は高い。 - 定石がない、不確定要因が多い、ステークホルダーが多い、経営戦略を織り込む必要がある・・・ 財務の視点 収益向上 売上増 コスト低下 お客様満足の視点 製品品質対する顧客満足度 納期に対する顧客満足度 業務プロセスの視点 業務プロセスの質向上 サイクルタイムの短縮 学習と成長の視点 従業員のスキル向上 11 | | 省力化のシス テムが検討対 象とする範囲 Standish Group、プロジェクトマネジメント学会などの調査 ＊「成功」の定義・・・品質、コスト、納期の3点すべてについて「当初 計画通りの成果」を収めたプロジェクト。（両調査とも定義は同じ。） 画像はカット 1994年のStandish Groupの調査 成功：16.2% キャンセル：31.1% 不成功：52.7% 「2・2・2の法則」 情報システム開発では、計画した2倍の 費用と2倍の時間がかかり、期待した2 分の1の機能しか実現できない 12 | | Caperas Jonesの調査概要 Caperas JonesはSPR社（Software Productivity Research Inc.） の会長であり、同社には1995年時点で約500社、6,700プロジェクトの データが蓄積されている。当調査の分析対象はこれらのプロジェクト に関するデータである。 当該データには大企業のものが多く、SPR社のユーザーはFortune500の100社を 占める。2,000プロジェクトが1,000FPを、うち200プロジェクトが10,000FPを超えて おり、大規模プロジェクトのデータが多数含まれている。 90%が米国内、約10%の700プロジェクトが日本を含む海外のデータである。 出典：Caperas Jones ソフトウェアの成功と失敗（1996） 13 | | Caperas Jonesの調査における用語の定義 中止・・・絶対的失敗 - 遅延・・・相対的失敗 - ソフトウェアプロジェクトが技術的に成功し、大きな問題も無く速やかに開発され、その開 発を委託した組織に少なからざるビジネス価値を提供した場合。 相対的成功 - プロジェクトがその予定されたスケジュールあるいはコスト目標と比較して大きく超過した 場合。（コストやスケジュールに関しては50%以上、加えてスケジュール面ではユーザー への引渡し後の全面利用が6ヶ月以上遅延） 計画通り＆早期終了・・・絶対的成功 - プロジェクトがその完成の前に中止される場合。 予想より良い成果を挙げえたプロジェクトの場合。 リカバリー - 悲劇的な結果または失敗に向かいつつあるプロジェクトがリカバリーアクションによって一 応許容できるレベルに戻ったり、あるいは少なくとも生き残る結果になる場合。 出典：Caperas Jones ソフトウェアの成功と失敗（1996） 14 | | Caperas Jonesの調査におけるプロジェクト要因ごとの成功率 プロジェクトの成否は①管理的問題、②技術的な問題、③社会的な問題の影響を受ける。そ れぞれのレベルによるプロジェクトの成否は下記の通りである。 最悪（プロジェクトの%） 中 止 手法 管理的 要因 社会的 要因 技術的 要因 見積 人手 計画作成 人手 遅延 計画 通り 最善（プロジェクトの%） 早期 終了 手法 45 15 0 品質管理 最低 最高 管理者の経験 浅い経験 豊富な経験 技術者の経験 浅い経験 豊富な経験 顧客の経験 浅い経験 スペシャリストの 存在 ジェネラリスト のみ キーとなるスペ シャリストの存在 開発技術 非効果的 効果的 ツールセット 不適切 部品再利用率 5%以下 計画 通り 早期 終了 1 2 78 19 1 2 79 18 1 22 62 15 自動化ツール 40 非正規 不安定 遅延 自動化ツール 追跡 要求の安定度 中 止 45 45 10 0 正規 豊富な経験 適切 15 75 10 0 安定 50%以上 出典：Caperas Jones ソフトウェアの成功と失敗（1996） 15 | | 素朴な疑問①・・・どうしてプロジェクトの失敗が無くならないのか？ PMP（プロジェクト・マネジメントの専門家）の取得者が大幅に増えているのに・・・ ソフトウェア工学は50年の歴史を持っているのに・・・ 要求工学の成果も蓄積されてきているのに・・・ 何かが根本的に欠けているのではないか？ 注・・・実際にはＩＴベンダーはPMBOKだけでなく、より具体的な開発方法論の 体系をもって現実に対処している。 16 | | 素朴な疑問②・・・経営者からはどう見えているのか？ 成功率が半分もないような「危険な」プロジェクトを、なぜ経営者は承認するのだろうか？ - プロジェクトの成功・失敗に関する統計データを知らない（無知）だけなのか？ ＩＴベンダーの「騙し方」が上手なのか？であればどうして何度も騙されるのか？ 経営者の視点によるプロジェクトを評価の結果は、プロジェクト・マネジャーのQCDの視 点からの評価と異なる可能性が高い。 QCDの観点では失敗とされたものが経営者の視点では成功、あるいはその逆と評価さ れるものが沢山あるのではないか？ 経営者の視点での成功率はもっと高いのではないか？でなければ経営者がそんな危険 な投資を承認するはずがない。 プロジェクトは本当にこんなに「失敗」しているのか？ 「誰から見た」成功・失敗なのか？ 17 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ PMBOK（プロジェクト・マネジメント）から言えること SWEBOK（ソフトウェア工学）から言えること 要求工学から言えること BABOK（超上流工程）から言えること 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 18 | | 登場人物（ステークホルダーズ）と手法の対応関係 要求工学 （超上流工程・BABOK） プロジェクト・オ−ナー スポンサー （経営者） プロジェクト ・マネジャー 上申/承認 ソフトウェア・エンジニアリング 要件定義をする人 （ユーザー側） 要件定義をする人 （ベンダー側） 要件定義書 QCD目標 （プロジェクト憲章） 開発業務をする人 （ユーザー側） 開発業務をする人 （ベンダー側） プロジェクト・マネジメント（プロジェクト全般のPDCA） 19 | | PMP資格の取得者数の推移 2006年末 2007年末 2008年末 2009年末 2010年5月 日本国内 18,009名 22,414名 25,580名 27,591名 28,674名 世界 221,144名 268,802名 318,274名 361,238名 385,159名 2001年には約2,000名 2003年には約4,000名 PMPの資格取得者数 ・5年間で2万5千名以上増加 ・10年間で約14倍 PMI日本支部 http://www.pmi-japan.org/ 20 | | 4つの仮説・・・「プロジェクトマネジメント手法＝PMBOK」と仮定します。 PMPの増加にも関わらず、なぜプロジェクトの成功率が上がらないのか？ PMBOKは無効な手法なのか！？ PMPなんか取得しても無意味なのか？ ＊「プロジェクト・マネジャーはＩＴベンダーから出る」、という前提で話を進めます。 仮説① 現在のプロジェクトマネジメント手法に不足しているものがある。 仮説② 問題が現在のプロジェクトマネジメント手法がカバーしていない領域から発生している。 仮説③ プロジェクトマネジメント手法が知られていない。あるいは使われていない。 仮説④ プロジェクトマネジメント手法を知っているが、使いこなせず、実践できていない。 21 | | 真/偽 仮説① 現在のプロジェクトマネジメント手法に不足しているものがある。 1. PMBOKはWhatを網羅的・体系的に述べているが、”How”に触れていない。 PMBOKが「BODY OF KNOWLEDGE」という名称なのは、辞書やルールブックに近い ものである、という意味なのだが、それが世の中から認識されていない。 ルールを知っているだけで、サッカーや野球で勝てるのか？といえば、だれでもNOが解 るはずなのに、プロジェクトマネジメントの世界では、勘違いが起こっている。 役に立つのは知識より、現場の経験によるノウハウである。（勿論知識も重要） 例えばステークホルダーマネジメントの重要性は述べているが、彼らの意思決定や合意 形成の促進、コンフリクトの解消に向けたネゴシエーションの方法など、Howに相当する 具体的なノウハウについては触れていない。 2. PMBOKが領域的にカバーしていないもの 22 ビジネス上の経営視点（プロジェクト・ポートフォリオ）・・・外部環境の変化を反映したここ のプロジェクトの見直し。八ツ場ダムの続行の可否といった事柄を、経営層を含めて、定 期的に見直すルールやしくみが必要。 PMBOKは個々のプロジェクトを成功に導く知識の体系であり、当該企業内の複数のプロ ジェクトのポートフォリオをマネージする視点は有していない。 （→P2M） | | プロジェクトマネジメントチームが必要とする専門知識 PMBOKガイドにも下記のように、PMBOKの知識だけでプロジェクトマネジメントが 成功するわけではないことが明記されている。 プロジェクトマネジメント 知識体系 PMBOKガイド 人間関係のスキル 一般的な マネジメントの 知識・スキル 23 | | 適用分野の 知識・標準・規制 プロジェクト環境 の理解 プロジェクトマネジメントのコンテキスト PMBOKガイドにはプロジェクトマネジメントのコンテ キストとして、 - プログラムおよびプログラムマネジメント ポートフォリオおよびポートフォリオマネジメント サブプロジェクト プロジェクトマネジメントオフィス の重要性が述べられているが、右記の記述レベルに とどまっており、詳細には触れていない。 （問題提起にとどまり、解決策を提示していない？） 24 | | 真/偽 仮説② 問題が現在のプロジェクトマネジメント手法がカバーしていない領域から発生している。 PMがプロジェクト発足前の営業活動段階から関与することは稀である。ところがプロジェ クト発足の前工程ではその受注を巡って様々な策謀が繰り広げられ、商談の勝者といえ ども十分な利益を確保できないことが珍しくない。 PMは波乱含みで（既に火種がある状態で）プロジェクトにアサインされ、最初の仕事は 「プロジェクト憲章の制定」だとされている。このことがPMに、プロジェクトのスタート段階 から現実離れしたQCD目標（特にコストと納期）を押し付けることにつながる。またこれら の問題を抜本的に改革する権限も通常は与えられない。 プロジェクト発足の前工程 PMBOKの規定範囲 コンペ、相見積り、互恵取引、政治 家の暗躍、選定委員会の迷走・・・ •プロジェクト憲章の制定 •プロジェクトマネージャーの任命 •・・・ プロジェクト マネージャー •・・・ •・・・ 25 | | 真/偽 仮説② 問題が現在のプロジェクトマネジメント手法がカバーしていない領域から発生している。 （PMBOKに限らず）手法でカバーできる領域とできない領域がある。 手法でカバーできる領域 ： 眼に見える（QCDなど） 例 ：成果物作成の目標品質に対して、要求通りに完成したか、納期通りか など。 手法でカバーできない領域 ： 眼に見えない（潜在するリスク、企業体質など） 例 ：事実としては、決めるべき人が決められない。 背後には、怒られるだけで褒められない人間関係、組織の壁、モチベーションの低さ、 企業体質（誰かの出世を邪魔したい、的な）、マネジメント能力の不備など。 例 ：過度な責任感と現実のGAP (1)現場の担当者 ： プロジェクトに問題あり ＝＞ホンネは「できっこない！」 (2)リーダー ：どうしてもやらねば。＝＞ホンネ「できないかもしれない、ができないとは 言えない」、「ここで、できないといえば、経営層、自分のメンツが・・・・」 →報告では「何とかします。」 (3)経営層 ：成功する？ ＝＞ホンネ「大丈夫かな？」 「でもリーダーが、やる、といっているのに、できないだろうとは言えない。」 これらの現象はプロジェクトマネジメントの問題ではなく、当該企業の情報伝達・ 情報共有や意思決定プロセス（更には企業文化や風土）の問題である。 26 | | 「敵は社内にあり」・・・正しい（適切な）報告が上がってくるか？ 画像はカット 2009年10月1日 経済産業省主催の情報化月間セミナー 「プロジェクトマネジメントの国際標準化とその意義」 より 冨永 章氏 PC236委員 （元・日本IBM専務取締役） 27 | | 出典：「プロジェクトの森」・・・健全な姿 プロジェクトマネージャー・リファレンスブック（プロジェクトマネジメント学会） 仮説③ プロジェクトマネジメント手法が知られていない。あるいは使われていない。 ＜発注企業＞ ＜構築企業＞ 経営者 企業戦略 企業戦略 ＣＩＯ ＩＴ戦略 営業責任者 ＩＴ戦略 戦略の﹁見える化﹂ 企画担当 提案書 利益目標 実施責任者 必要資源 営業戦略 ＲＦＰ 提案合意 営業担当 最適配置 SOW定義＆見積 ＳＯＷと 役割合意 ＰＭ プロジェクト メンバー 協同 作業 戦略に応じた要 求仕様提示 取引先 （顧客） 業務部門 責任者 ニーズの取込 ユーザー 28 経営者 売上目標 | | 外注先選定 ＰＭ ＳＯＷと役割合意 構築方針 構築 メンバー 協同作業 品質レビュー 外注先 外注先 外注先 (ﾊﾟｰﾄﾅｰ） と有効な支援 プロジェクト SOW：Scope Of Work 支援部門 真/ 出典：「プロジェクトの森」・・・森林汚染の状態 仮説③ プロジェクトマネジメント手法が知られていない。あるいは使われていない。 偽 「多勢に無勢」になっていないか？ この例では売り手側のPMと実施責任者のみがPMPを保有しており、お客様にはSPI/CPIとい う言葉も通じない。（専門用語を振り回すべきではないが、お互いにキーワードを知っていれば、 コミュニケーションは格段に高度に、効率的になる。） PMP保有者が売り ＜発注企業＞ 手側にのみ、かつ わずかしかいない。 成果主義 ＜構築企業＞ 経営者 経営者 利益至上 企業戦略不明 営業責任者 戦略が見えない 企画担当 戦略が見えず部分最適 追求 ユーザー | | コスト削減圧力 提案不参加 丸投げの多重層化 ＰＭ 業務部門 責任者 最小資源配置 形式的合意 丸投げ 重要度無視 の要求仕様 取引先 （顧客） 営業担当 非現実な提案 （コスト割れ） ＳＯＷ不明確 プロジェクト メンバー 29 売上至上主義 不明確なＲＦＰ ＰＭ 顧客無視 実施責任者 ＩＴ戦略無し ＣＩＯ SPIが・・・ CPIが・・・ コスト削減圧力 構築方針不明確 構築 空洞化（要員と メンバー スキル不足） 外注先 外注先 外注先 (ﾊﾟｰﾄﾅｰ） やる気低下 形式的レビュー有効な支援＜プロジェクトチーム＞ 無し プロジェクト 支援部門 出典：「プロジェクトの森」 プロジェクトマネージャー・リファレンスブック プロジェクトマネジメント学会 SPI；Schedule Performance Index CPI；Cost Performance Index プロジェクトマネジメント手法 自体への誤解や偏見、無理解 マネジメント手法は大規模プロジェクトに「だけ」必要だと思われている。 - - （大学で中途半端にプログラミングをかじった人に多いが）情報システム構築＝プログラミン グと勘違いしている。「プロジェクトマネジメント」という業務や役割の必要性・重要性を理解で きていない。 スパイラルやアジャイル開発手法を過信し、ウォーターフォール手法で実施すべき規模の閾 値が体感できていない。 例・・・10階建てのビルには、エニジニアリングの発想とPMの関与が必要（ほぼ全員認める）。 2階建木造は、大工さん一人で、建てられる。ログハウスは、素人でも、建てられる。 →自分がこれから立てようとしているのはどちらの規模なのか、客観的に判断できない。 最後は「まあ何とかなるだろう」で始める。 - プロジェクトマネジメントの重要性が理解できていないユーザーは「PM費用」を削りたがり、 複数のソフトハウスに直接分割発注したりする。その結果、ユーザー企業でプロジェクトマネ ジメントができるはずもなく、システム構築はデスマーチ状態に陥る。 「マネジメント」という言葉自体への偏見 - 30 マネジメントが「管理」と訳されたことにより、「マネジメント」＝「他人の仕事を増やす煩わしい もの、余計な仕事を増やす邪魔者」との誤解や偏見が蔓延してしまった。 誤りの例 ： マネジメント＝＞ 警察・・・これは本来は「コントロール」では？ 正しい例 ： マネジメント＝＞ ナース(看護婦）・・・癒しと改善機会を与え、 良い結果をもたらそうとする行為。 | | 真/偽 仮説④ プロジェクトマネジメント手法を知っているが、使いこなせず、実践できていない。 1. まず仮説②で挙げた「多勢に無勢」の状況はこれにも該当する。 プロジェクトメンバーのステークホルダーの中でPMBOKを習得しているメンバーが10%以下で あったら、PMBOKの用語や考え方は共通言語にはなり得ず、結果的に「実践できない」ことに なる。 2. PMP取得者自体に起因する問題（ある敏腕PMの苦言） 31 一言でいうと、頭でっかち。頭が動いても、手が動かない。手法に走り、現場で使えない。 PMBOK自体がHowではなくWhat主体なので、試験にも実務に根ざすようなHowは出題されな い。従って実務経験が乏しくてもPMPは取得できてしまう。にも関わらず、PMPを「プロジェクトマ ネジメントの神様」のように過大に期待し、現実を見て過大に失望している企業が多いのではな いか？（まるでブーム時期のMBAのよう？） 資格の維持・更新にはPDU（Professional Development Unit ）などの要件を設けているが、こ れらは学習時間の評価であり、実務経験ではない。 中小企業診断士も似たようなものかな・・・？ | | 4つの仮説のまとめ・・・4つとも正しい！ プロジェクト発足の前工程 コンペ、相見積り、互恵取引、政治 家の暗躍、選定委員会の迷走・・・ 仮説① 現在のプロジェクトマネジメント 手法に不足しているものがある。 プロジェクトマネジメントの課題は 単にPMPを増やせば解決すると いったものではなく、もっと広範に わたる根の深いものである。 実際のプロジェクト組織 PMBOKの規定範囲 •プロジェクト憲章の制定 •プロジェクトマネージャーの任命 •・・・ 仮説② 問題が現在のプロジェクトマネ ジメント手法がカバーしていな い領域から発生している。 •・・・ •・・・ 多勢に 無勢 実務経験不足 仮説④ プロジェクトマネジメント手法 を知っているが、使いこなせ ず、実践できていない。 32 | | 仮説③ プロジェクトマネジメント手法 が知られていない。あるいは 使われていない。 ＩＴベンダーのPMがマネージできるプロジェクト・マネジメントの限界 ＩＴベンダーのプロジェクト・マネジャーの使命は本来、「与えられたスコープの作業と成 果物を、QCD目標の制約条件の中で作成すること」である。 スコープやQCD目標はプロジェクト憲章に記載される。プロジェクト憲章を作成する のはスポンサーやイニシエイターで、承認者はプロジェクト・オ−ナーである。 従ってプロジェクトの目的達成責任はユーザー企業のプロジェクト・オ−ナーにこそ あることになる。スコープの設定あるいはQCDの設定を誤ったことに責任を有する のはプロジェクト・マネジャーではなくてプロジェクト・オーナーである。 ということは、「スコープ設定が正しかったのか？」、「QCD目標は適切に設定されていたの か？｣という問いはＩＴベンダーのプロジェクト・マネジャーの範疇では解決できないことになる。 現在の日本のプロジェクトの現状は、本来の責任外のことまでプロジェクト・マネ ジャーに押し付け過ぎではないか？ 背景にはプロジェクトの構想策定や要求定義作業にＩＴベンダーの支援を仰がざるを 得ない情報システム部門のパワー不足の問題が横たわっている。 33 | | ではどうすれば良いのか？（改革提言） でも何でもかんでも最後は ユーザー企業の経営者の 責任にしていいのかな？ 仮説１関連・・・現在のプロジェクトマネジメント手法に不足しているものがある。 - PMBOKは座学と割り切り、OJTを真剣に拡充する。PMPのご利益について過大な宣伝をしない。 仮説２関連・・・問題が現在のプロジェクトマネジメント手法がカバーしていない領域から発生している。 - 営業マンにSI終了までの利益責任を負わせる。（「売り逃げ」を許さない。） 「戦略的受注」で5,000万円の赤字覚悟で受注したのであれば、PMに「黒字化」を求めてはいけない。 5,000万 円以内の赤字に収めたら表彰すべき。 仮説３関連・・・プロジェクトマネジメント手法が知られていない。あるいは使われていない。 - - - PMPの取得、PMBOKの理解をお客様側、特に経営層にも求めるのは非現実的である。従ってPM補佐として、 営業（部長）経験者をサブPMとしてアサインし、お客様とのネゴシエーションやコミュニケーション分野でPMを補 佐する体制を敷く。（一般にPMはSEなど、技術畑出身者が多く、営業出身者ほどネゴシエーションに長けていな い場合が多い。） PMBOKの内容を平易な言葉や例えに置き換えてユーザー企業の理解と賛同、そしてプロジェクト作業への協力 を引き出すことが必須である。この役割をサブPMに持たせる。 経営層にプロジェクトマネジメントの重要性をご理解いただくために、経営層に対する啓蒙の場でプロジェクトマ ネジメントに関するテーマをもっと積極的に取り上げるべきである。 仮説４関連・・・プロジェクトマネジメント手法を知っているが、使いこなせず、実践できていない。 - 34 座学とは言いながら、PMBOKは重要。なのでPMP取得者を劇的に増やす施策を試みる。同時に仮説１と同じく、 OJTの拡充を急ぐ。 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ PMBOK（プロジェクト・マネジメント）から言えること SWEBOK（ソフトウェア工学）から言えること 要求工学から言えること BABOK（超上流工程）から言えること 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 35 | | ソフトウエア・エンジニアリング（工学）の歴史と定義 フリッツ・バウアー（1968年 ソ フトウエア・エンジニアリング会 議チェアマン） - ソフトウェア危機 が喧伝される 実機（real machine）上で効率 良く動作し，信頼できるソフトウ エアを，経済的に取得するため の合理的かつ工学的な原則 （sound engineering principles）を確立し，用いること IEEE -（1）：ソフトウエアの開発・運用・保 画像はカット 守に関する，体系的で，規律のとれ た，数量化できるアプローチの適用 （application），すなわちソフトウエ アに対するエンジニアリングの適用 -（2）：（1）に示したアプローチの研 究 36 | | http://itpro.nikkeibp.co.jp/article/lecture/20061102/252567/?ST=selfup SWEBOK・・・IEEE（米国電気電子学会）を母体とする団体SWECCが 策定した，ソフトウエアの開発・保守に関する知識体系の1つ。 「ソフトウェア要求」は超上流工程と接点を持っている。 画像はカット 出典：SWEBOK（Software Engineering Body Of Knowledge）2004年版 37 | | IEEE 830 の推奨する要求仕様の構成 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕 様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求 仕様をSyRSと略記する。 画像はカット 38 | | IEEEstd830 SRSガイドラインの構成 QCD目標のQで問われるのは「仕様」のとおりに成果物が作成されているかという 適合率の問題であり、本来のプロジェクト・オ−ナーやユーザーが持つ「要求」どお りにシステムが作られたかどうかは問うていない。 逆に「要求」を「仕様」を経由せず、直接プログラミングすることはできない。 かつQの範囲は「機能要求」に関する「プロダクト」の部分だけを評価しており、非機 能要求は、契約上明確にスコープに盛り込まれない限り、開発企業の「良心」に委 ねられている。 SRS（Software Requirements Specification：ソフトウエア要求仕様書） 39 | | 画像はカット 要求仕様が満たすべき8つの性質 IEEE std-830 1998 SRS（Software Requirements Specification：ソフトウエア要求仕様書） 性質：説明・・・これらのうち赤字の部分はその判断根拠を超上流工程に求める必要がある。 1. 正当性：SRSがすべての要求を含み，かつそれ以外の要求をふくまないこと 2. 無あいまい性：SRSのすべての要求の意味が一意に識別されること 3. 完全性：SRSが、次をすべて含んでいること - ・すべての必要な要求 ・すべての入力データと状況に関する応答の定義 ・用語および図表の説明 4. 一貫性：SRSに含まれる要求間で矛盾がないこと 5. 順位付け：要求が重要性や安定性に関して順位付けられていること 6. 検証容易性：SRSに含まれるすべての要求に対して有限のコストで評価可能な手続きが存 在して検証できること 7. 修正容易性：要求の変更に対して、容易かつ完全で一貫性を保ってSRSを修正できるような 構造を持つこと 8. 追跡性 要求の根拠が明確で、開発工程全体で参照できること 40 | | SWEBOKの「ソフトウェア要求」に関する記述① ソフトウェア要求とは、特定の問題を解決するために、開発され、適用されるソフト ウェアによって開示されなければならない特性である。 ソフトウェア要求者およびソフトウェア品質管理担当者は、現実的な資源制約の範 囲内で、要求が正しいものであることの確信が得られるようにしなければならない。 これは「マネジメント」の範囲まで検討しないと判断できないでしょう？ 要求抽出 - - ソフトウェアによる解決が求められている問題に対する理解を構築する必要がある。理解 の構築は基本的には人の行為であり、この中で利害関係者が識別され、開発チームと顧 客との関係が確立される。 ソフトウェアユーザーとソフトウェア・エンジニアの良好な交流が要求抽出の基本に必要。 ユーザーは自分たちの仕事を説明することに苦渋を示す。また協力することを快く思わな かったり、拒否したりする。そのために次の手法が活用できる。 ・・・インタビュー、シナリオ、プロトタイプ、進行役付き会議、観察 あくまで教科書的なＴo Beの提示に終始している。 出典：ソフトウェアエンジニアリング 基本知識体系 SWEBOK2004 41 | | SWEBOKの「ソフトウェア要求」に関する記述② 要求分析 - 要求に関する優先度は、「必須、極めて望ましい、望ましい、任意」のレベル分けと、開発や 要求実現のコストとのバランスも考えて設定されなければならない。 要求折衝、要求の妥当性確認についても、具体的な解決策が示されないスタンス は変わらない。 これでは要求の膨張に悩むプロジェクト・マネジャーの現実的な支援 にはならない。 極めつけ - システム要求が仕様化された後、ソフトウェア要求がシステム要求から導出され、その後で ソフトウェア部分要素に対する要求が仕様化されるものとする。 システム要求の仕様化はシステムエンジニアリングの範疇に属し（IEEE std 1233）、ソフト ウェアエンジニアリングの範囲外とされなければならない。 つまりソフトウェア工学は要件定義の面倒は見ません、ということ！？ 結局、どうしていいか分からない、ということなんですね？ 出典：ソフトウェアエンジニアリング 基本知識体系 SWEBOK2004 42 | | ソフトウェア・エンジニアリングの限界 ソフトウエア・エンジニアリングの目標 - （1）ユーザーからの要求を漏れなくソフトウエアに反映させる （2）バグが含まれていないソフトウエアを作成する （3）ソフトウエア開発を自動化し，保守を効率化する このことによって「ソフトウエアのQ（品質），C（コスト），D（納期）を改善すること」 つまり「ユーザーからの要求」が前工程で明確化されていることが大前提となってい る。ソフトウェア・エンジニアリングだけではプロジェクトの要求定義より上流はカ バーできない。 実際のソフトウェア・エンジニアリングに関する研究の重点は開発工程に置かれて おり、要件定義へのフォーカスはされていない。 43 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ PMBOK（プロジェクト・マネジメント）から言えること SWEBOK（ソフトウェア工学）から言えること 要求工学から言えること BABOK（超上流工程）から言えること 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 44 | | 要求工学の連載・・・山本博士 2008/ 6/28 にSCM研究会 で講演いただきました。 画像はカット 【特集】システム開発の上 流工程に山積する課題解 決に向けた提言シリーズ ・・・「要求工学概要」 http://www.bcm.co.jp/site/youkyu/index.html 45 | | 要求工学の概要 画像はカット 要求エンジニアリングがその目的を達成するために実施する一般的なプロセスは、大きく「要 求開発（Requirements Development）」と「要求管理（Requirements Management）」に分け て説明される。 要求開発は要求を確定するプロセスであり、最終的に要求を明確にした「要求仕様書（SRS： Software Requirements Specification）」という文書をアウトプットする。多くの場合、このプロ セスは要求開発プロジェクトが実施する。 46 | | http://jibun.atmarkit.co.jp/lskill01/rensai/req/02/01.html 「ソフトウェア要求」の詳細 画像はカット http://jibun.atmarkit.co.jp/lskill01/rensai/req/01/02.html 47 | | 要求工学の定義 定義１ Ramamoorthy 要求工学は、ユーザ要求を仕様化するプロセスである。作成された仕様がシステム 開発の設計、製造、試験工程をガイドする。 定義２ SWEBOK 要求工学は要求の系統的な処理を表す。ソフトウェア要求は要求工学プロセスから 生じる生産物である。 定義３ Kotonya 要求工学は、コンピュータシステムに関する要求の集合を、発見、文書化、保守する ことに関するすべての活動を対象とする。要求工学では系統的で反復可能な技術を 用いてシステム要求が完全、無矛盾、実際的であることを確認する。 定義４ Loucopoulos 問題分析時に相互作用的で協調的なプロセスにより要求を生成すること、観察結果 を種々の表現形式により文書化すること、取得された理解の精度を検討すること、これ らをシステム的に行うプロセスのことをいう 定義５ Zave 要求工学はソフトウェアシステムに関する実世界のゴール、機能、制約を扱うソフト ウェア工学の分野である。要求工学では、これらとソフトウェアの振る舞いに関する正 確な要求仕様との関係や、時間ならびに関連するソフトウェアに関してこれらの要因が どのように進化していくかについても扱う。 48 | | 要求工学プロセスの基本モデル 画像はカット Loucopoulos, P. and Karakostas, V.,富野監訳、要求定義工学入門、共立出版、1997. 49 | | 要求工学プロセスの基本モデル 要求抽出では問題領域の専門家の知識や顧客ニーズ、現状の問題、経営課題など に基づいて要求を獲得する。このときシナリオやユースケースなども利用する。要求 抽出には要求の収集、分析、優先順位付けがある。 要求分析では要求抽出で獲得した要求間の構造や一貫性を明らかにするとともに要 求に優先順位を付与して顧客との合意を形成する。この過程で顧客には概要レベル の要求を提示する。より詳細な要求仕様を提示するのは次の段階である。 問題領域からソリューション領域への移行のポイントは要求項目と、その優先順位が 明確になっていることである。 要求仕様化では優先順位のついた要求を具体的に文書として記述する。このとき要 求と要求仕様との追跡性を管理する。もし、すべての要求が仕様化されていなければ 要求仕様には抜けがあり、不完全である。もし要求に対応しない要求仕様があればそ れは冗長である可能性がある。 要求確認では要求仕様を顧客に提示して妥当性を確認する。妥当性が確認された要 求仕様は設計工程に引き継がれる。これに対して妥当でない要求仕様については変 更するために要求工学プロセスを反復する必要がある。 妥当でない要求の可能性としては、どのプロセスで誤りが発生したかに応じて、仕様 化ミス、要求分析ミス、要求ミスが考えられる。 50 | | 要求工学の限界 確かにTo Beの姿は理想的に描かれている。 しかしその具体的方法論までは明示されていない。 要件定義でのトラブルがなくならないのは・・・ - 要求工学が普及途上にあるためなのか？ 習得の難易度が高過ぎるせいなのか？ 仮説・・・優先順位付けの判断などでは経営戦略との連携を もっと蜜にしなければならないのでは？ 51 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ PMBOK（プロジェクト・マネジメント）から言えること SWEBOK（ソフトウェア工学）から言えること 要求工学から言えること BABOK（超上流工程）から言えること 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 52 | | BABOK登場！（Business Analysis Body of Knowledge） プロジェクトの最大のトラブル要因である「要件定義の失敗」を超上流工程で食い止める取組み 画像はカット z 非営利団体のIIBA（International Institute of Business Analysis 本部：カナダ）が 2006年7月に発表 z ビジネス分析の専門職種をBA（Business Analyst）と定義し、その資格認定試験を CBAP（Certified Business Analysis Professional）として開始 z 2010年5月、日本でもBA取得第1号が誕生 「使えないシステムをなくすBABOKとは？」を基に作成 http://www.atmarkit.co.jp/im/carc/serial/babok/01/01.html 53 | | BABOK概要（日経コンピュータ、2010年7月7日） 2010年5月、日本でもBA取得第1号が誕生 富士ゼロックス総合研究所 伊藤 衡さん 12月のSCM研究会のゲスト 講師です。乞うご期待！ 画像はカット 54 | | BABOKの概要（BABOKガイド）と体系 画像はカット IIBA日本支部のホームページから買えます。 http://store.iiba-japan.org/shopdetail/001000000002/ 「使えないシステムをなくすBABOKとは？」を基に作成 http://www.atmarkit.co.jp/im/carc/serial/babok/01/01.html 55 | | PMBOKとBABOKの関係 着眼点 対象とするプロジェクトの 「フェーズ」 両者が対象とするプロジェクト のフェーズが異なる。接点で は、両者にはラップするフェー ズがあり、その部分において は両者ともに使える。 利用者 WBS/OBSの作成時に両方の 視点を入れると効果的。 適用範囲 BABOK PMBOK 所謂、システム化の言葉が出る以 前のフェーズ。 『ビジネスの分析』にフォーカスして、 その後システム化上流の仕様の確 立へと進む。 特に経営からの視点が主。 BABOKとオーバーラップするが、ある 程度プロジェクト化される時点。 特にベンダーが絡み始めたフェーズで、 例えばITであれば『システム化要件の 成果物を作るに至る管理』を含めた土 台となる指南書。 （主として）ユーザー企業 上級SE ビジネスコンサルタント ビジネスコンサルファーム システム化プロジェクトが形成され、そ こにアサインされたのプロジェクト・マネ ジャー 主に業者/ベンダー側のプロジェクトマ ネジャ 主に投資の初期段階が対象で、や や情報システムにフォーカス 情報システムに特化しておらず、プロ ジェクトと定義される対象全てに適用が できる。 例・・・オーナー社長から、「うちの会 社に日本一の生産性を誇る工場を作 ろう！！お前が責任者をしろ！！」と 言われたら、先ずは、BABOK 56 | | 例・・・火星に人を送り込むプロジェクト を進めたいが、そのマネジメントはどの ように？ →PMBOK 各手法の位置づけとカバレージの関係 それぞれがサイロになっていて 全体を一気通貫で論じている人がいない！ BABOK（超上流工程） プロジェクト・マネジャーの使命は、「与えられたスコープの作業と成果物を、QCD目標の制約条件の中で作 成すること」 経営者視点でのプロジェクトへの要求 要求工学 要求工学は要求の系統的な処理を表す。ソフトウェア要求は要求工学プロセスから 生じる生産物である。（SWEBOK）要求工学は「要求開発（Requirements Development）」と「要求管 理（Requirements Management）」に分けられる。要求開発は要求を確定するプロセスであり、最終 的に要求を明確にした「要求仕様書（SRS：Software Requirements Specification）」という文書をア ウトプットする。 スコープとQCD目標の決定 プロジェクト・マネジメント （プロジェクト・マネジャーの視点） プロジェクト・マネジャーの使命は、「与えられたスコープの作業と成果物を、QCD目標の制約条件の中で作成す ること」 ソフトウェア要求（仕様）の明確化 ソフトウエア・エンジニアリング IEEE std-830 の要求仕様書の8つの条件を満たす必要がある。 「実機上で効率良く動作し，信頼できるソフトウエアを，経済的に取得するための合理的かつ工学的な 原則を確立し，用いること」 1968年、NATO（北大西洋条約機構）ソフトウエア・エンジニアリング会議チェアマン、フリッツ・バウアー 「ソフトウエアの開発、運用、および保守における、システマティックであり、ディシプリンに基づいた、定 量的なアプローチの適用である。換言すれば、ソフトウェアへのエンジニアリングの適用である。」 SWEBOK 「ユーザーからの要求」が前工程で明確化されていることが大前提 57 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 日本だから失敗するのか？米国ではうまくいっているのか？ プロジェクトの失敗に関する「なぜなぜ5回」 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 58 | | 結論 結局米国も事情は 似たり寄ったりであった・・・ 59 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 日本だから失敗するのか？米国ではうまくいっているのか？ プロジェクトの失敗に関する「なぜなぜ5回」 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 60 | | Standish Groupの調査における成功の原因（1994） 【プロジェクトの成功（タイプ1）要因・トップ10】 15.9% ユーザー部門の巻き込み 13.9% 経営陣の支援獲得 13.0% 要求が明確 9.6% 適切な計画の立案 8.2% プロジェクトへの現実的な期待 7.7% プロジェクトの小刻みなマイルストーン管理 7.2% 優秀なスタッフ 5.3% オーナーシップ 2.9% ビジョンと目標の明確化 2.4% 厳選されたスタッフのハードワーク 13.9% その他 画像はカット 回答者は情報システム部門の責任者、マネジャーである。（これがこのレポートの限界であり、 QCDだけでプロジェクトを評価して良いのかという問題提起の起点となる。） 61 | | Standish Groupの調査における失敗の原因（1994） 【プロジェクトのチャレンジ（タイプ2）要因・トップ10】 12.8% ユーザー部門の巻き込み不足 12.3% 要求と仕様が不明確 11.8% 要求と仕様の度重なる変更 7.5% 経営陣の支援不足 7.0% テクノロジーが不完全 6.4% リソースの不足 5.9% プロジェクトへの非現実的な期待 5.3% 不明確な目標 4.3% 非現実的なタイムフレーム 3.7% 新しいテクノロジー（への熟練不十分） 23.0% その他 【プロジェクトのキャンセル（タイプ3）要因・トップ10】 13.1% 不完全な要求 12.4% ユーザー部門の巻き込み不足 10.6% リソースの不足 9.9% プロジェクトへの非現実的な期待 9.3% 経営陣の支援不足 8.7% 要求と仕様の度重なる変更 8.1% 計画の欠如 7.5% 状況の変化で情報システムが不要に なった 6.2% ＩＴマネジメントの欠如 4.3% テクノロジーの未成熟 9.9% その他 回答者は情報システム部門の責任者、マネジャーである。（これがこのレポートの限界であり、 QCDだけでプロジェクトを評価して良いのかという問題提起の起点となる。） 62 | | Standish Groupの調査における失敗原因の因果関係 経営陣の支援不足 ユーザー部門の 巻き込み不足 注・・・「経営者の支援不足」は経営者 が経営の意図を明確にするという基 本にまで立ち返る必要がある。 新しいテクノロジー （への熟練不十分） 不明確な目標 要求と仕様 が不明確 要求と仕様の 度重なる変更 テクノロジーの未成熟 テクノロジーが不完全 計画の欠如 プロジェクトへの 非現実的な期待 経営環境の変化 状況の変化で情報シ ステムが不要になった これは経営者視点では失敗ではない？ （リソースは確かに無駄にしたが・・・） | ＩＴマネジメントの欠如 リソースの不足 不完全な要求 63 筆者が追加 | 非現実的なタ イムフレーム Caperas Jonesの調査における成功・失敗の原因 プロジェクトの成否はプロジェクトメンバーのCapabilityやその結果もたらされるアウトプット の品質に負う部分が大きいことが分かる。 反面開発ツールや管理ツール（見積や計画作成ツール）は生産性向上のためには重要であ るが、プロジェクトの成否への影響度はCapabilityよりも低いことが分かる。 項目 カテゴリー 管理者の経験度 社会 技術者の経験度 社会 品質管理レベル 管理 要求の安定度 技術 部品再利用率 技術 スペシャリストの存在 社会 適切な開発技術 技術 見積の自動化 管理 計画作成の自動化 管理 正規の追跡 管理 顧客の経験度 社会 適切なツールセット 技術 64 | | 成功要因 失敗要因 1. 2. 3. 4. 5. 経験豊富な管理者 経験豊富な技術者 最高の品質管理 安定した要求 部品再利用50%以上 1. 2. 3. 4. 5. 経験の浅い管理者 経験の浅い技術者 最低の品質管理 不安定な要求 部品再利用5%以下 6. 7. 8. 9. 10. 11. 12. キーとなるスペシャリストの存在 効果的な開発技術 自動化された見積 自動化された計画作成 正規の進捗追跡 経験豊富な顧客 適切なツールセット 6. 7. 8. 9. 10. 11. 12. ジェネラリストのみ 非効率な開発技術 人手による見積 人手による計画作成 正規でない進捗追跡 経験の浅い顧客 不適切なツールセット Caperas Jonesの調査における失敗原因の分析 栗山が追加 経営陣の支援不足 経験の浅い管理者 経験の浅い顧客 プロジェクト・マネ ジメントの未成熟 開発担当者 の能力不足 経験の浅い技術者 ジェネラリストのみ （キーとなるスペ シャリストの不在） PMの能力不足 正規でない進捗追跡 不安定な要求 人手による（自 動化されてい ない）計画作成 人手による（自 動化されてい ない）見積 テクノロジーの未成熟 非効率な開発技術 不適切なツールセット 部品再利用5%以下 最低の品質管理 仕様変更の頻発 成果物のQCD悪化 65 | | 結果系 QCD目標を突き詰めていくと・・・ 経営者のビジネス・ポート フォリオに関する意思決定 （情報システムの軽視） 原因系 不十分なリソース投入 課題1：プロジェクトの 失敗（QCDの悪化） によるプロジェクト現 場の3K化 システム系作 業の失敗・プ ロジェクトの 中止 経営者の支援 不足に行き着く リカバリー策の失 敗、長時間労働で の対応 リソース不足 （スキルレベル と人数・専従度） QCDの悪化 課題2：プロ ジェクトの目 標未達（目標 と現実の ギャップ）によ る経営者の満 足度低下 変更管理・変化 対応の失敗 要求定義の失敗 経営戦略視点からのプ ロジェクト目標の明確化 の失敗 非システム系 作業の失敗 プロジェクト・ マネジメント の失敗 システム開発（ソフ トウェア・エンジニ アリング）の失敗 リソースの配分不足（重要なプロジェクト と判断すればリソースは配分される） リソースのMaturity 不足・育成不足 66 | | プロジェクトの失敗とは、突き詰めて考えれば以下のいずれかである。 67 自社のMaturityやCapabilityのレベル以上の難易度のプロジェクトへの 挑戦による失敗 必要なCapabilityを持つプロジェクトメンバーの人選、アサイン、アロ ケーションの失敗 経営者がプロジェクトの目標を明確に定めない意思決定の失敗 プロジェクト開始時には想定していなかった外部・内部環境の変化 その根底には自社の人材育成への過信や不足、プロジェクトへの必要 な資源投入の不足といった経営判断の誤りがある。 プロジェクトは不確定要因との闘いの連続。両社のトップマネジメントに よるステアリング・コミッティーの有無と機能の程度が大きく影響する。 （変化対応力とリカバリー能力） | | 「プロダクト・ライフサイクル」の範囲だけでは問題は解決できない！ この範囲だけで考えていると、「要件定義が進まないのはエー ス人材を投入してくれないから。ユーザー企業の経営者の意 思決定が間違っている」という発想にしかならない。 契約行為 システム要件定義 プロジェクト実施工程 上流工程 下流工程 システム設計 運用テスト 保守 システム・テスト 運用 ソフトウェア設計 中流工程 ソフトウェア・テスト プログラミング 情報処理推進機構・ソフトウェアエンジニアリングセンター 「ＩＴプロジェクト見える化部会資料」を基に作成 68 | | 「超上流工程」から「成果の検証」までEnd to endでカバーする手法が必要 超上流工程 「目的達成度」がある値以上 のものが「成功」 BABOK 経営戦略∼ビジネスケース 目的 結果 目的達成度 成果検証 ビジネス要件定義∼業務要件定義 契約行為 システム要件定義 要求工学 ユーザー受入テスト PMBOK ヘルプデスク BICC EATなど プロジェクト実施工程 上流工程 システム設計 SWEBOK ソフトウェア設計 中流工程 下流工程 運用テスト 保守 システム・テスト 運用 ソフトウェア・テスト プログラミング プロジェクト・マネジメントやソフトウェア・エンジニ アリングはプロジェクト実施工程に閉じている。 69 | | 「エンド・ツー・エンド」主張の根拠 プロジェクト・マネジメント（PMBOK）の限界 ソフトウェア・エンジニアリング（SWEBOK）の限界 要求工学の重要性と限界 超上流工程（BABOK）の重要性と上記3つとの融合の必要性 エンド・ツー・エンドの視点に基づくプロジェクト評価 経営環境の変化 ビジネス・ポートフォリオ （経営者の視点） プロジェクト目標 の変更 70 仕様変更 | | QCD目標 （プロジェクト・マネジャーの視点） PMBOK SWEBOK 要求工学 超上流工程 BABOK 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 プロジェクトがビジネス価値を実現するまでの因果関係 因果関係の網の目構造論 P2Mのアプローチから言えること プロジェクトの「成功」の定義とエンド・ツー・エンド評価の必要性 6. 論理と現実の乖離についての認識と対処法 71 | | 経営者の情報システムに対する期待 経営者は「それなりに」情報システムに期待している。 情報システムが持つ課題解決に大きな期待を掛けている。しかしそれは十分に満たさ れていない。 この意見は各企業で過去に実施された多数のプロジェクトの成否を総合的に評価した ものと考えられ、このギャップを縮めていくことが真の課題である。 QCD基準で言われているほど、経営者はプロジェクトの失敗率が高いと考えていない 可能性がある。 →それはなぜか？ Q1.ＩＴの活用度を高めれば企業競争力を高められると思うか？ - 思う やや思う 余り思わない 思わない 34.4% 46.4% 17.1% 1.9% Q2.経営層が期待する効果をＩＴで生み出せているか？ - 72 思う やや思う 余り思わない 思わない | | 8.3% 44.2% 42.7% 4.2% 日経コンピュータ 2009年6月24日号 プロジェクトがビジネス価値を実現するまでの因果関係 プロジェクトでは「システム系作業」に注目されがちであるが、成功のためには「非システム系作業」 も成功裏に実施される必要がある。 かつ「非システム系作業」は基本的に提供側企業には委託できず、その実行責任は経営者にある。 加えてプロジェクトの最終的な成否は（予期せぬ）内部・外部環境の変化の影響を受ける。 非システム系作業 システム開発作業以外の プロジェクト目的達成に必要な取組み ビジネス価値 | 内部環境の変化 動機付け、ワークロードの確保 ヘルプデスク BICC EATなど | 外部環境の変化 ユーザー企業 メンバー 適切な人材のアサインと ︵ 業務改革の成果など︶ 内部環境の認識 73 ①経営戦略の明確化 ②プロジェクトの目的の明確化 （実現を目指すビジネス価値） ③新ビジネスモデルの考案 ④経営資源投入の意思決定 ユーザー企業側 プロジェクト・マネジャー 非システム系成果物 経営者 （スポンサー） WBS：Work Breakdown Structure 提供側企業 プロジェクト・マネジャー システム系成果物 vs QCD目標） ︵ アプリケーションプログラムなど︶ 外部環境の認識 プロジェクト・チーム システム系作業 WBS 提供側企業 •成果物 委託/受託関係 メンバー •タスク （スコープ＆成果物 Business Intelligence Competency Center ◆統計学の知識を必要とする高度な情報分析をサポートする専門組織。 - ユーザー部門から複雑な分析作業を請け負い、代行する。 BIツールをユーザー部門が使いこなせるように啓蒙活動をする。 ◆バンテック 2010年4月にBICC設立へ 物流大手のバンテックは、2010年4月にERP（統合基幹業務）システムで得られる情報を経営管理 の高度化に役立てるための社内組織、BICC（ビジネス・インテリジェンス・コンピテンシー・セン ター）を設置する計画を明らかにした。 同社は2009年4月に、独SAP製のERPパッケージを導入済み。同年4月1日にグループ再編を実 施し、持ち株会社であるバンテック・グループ･ホールディングスを存続会社として、自動車部品物 流を中心としたバンテックと、航空・海上輸送を得意とするバンテックワールドトランスポートが合併 したのに伴い、ERPパッケージを導入した。 同社でCIO（最高情報責任者）の役割を担う執行役員の加松哲夫情報システム部長は「BICC設 立の主な狙いは、PDCA（計画・実行・検証・見直し）サイクルを回すのに必要なKPI（キー・パ フォーマンス・インジケーター、重要業績評価指標）の数字を各事業部門の責任者が迅速に把握で きるようにすることだ」と説明する。 （上木 貴博＝日経情報ストラテジー） [2009/11/30] http://itpro.nikkeibp.co.jp/article/JIREI/20091126/341133/ 74 | | EAT（Enterprise Application Training ） ∼変革の度合に合わせた学習目的と適切な研修方法を用いて定着化する∼ フォーカス領域 学習の性質（目的） 研修方法 – 集合研修および e-ラーニング 変革の度合 マインド (Heart) • 信念 • ソフトスキル • 有用性 • 経営層のメッセージ • 小グループ内での相互作用 • トレーニング実施後の同期生ネットワーク • 真意に対するQA窓口（スピークアップ） 企業変革 （ビジネスモデル チェンジ） 知識面 (Head) • プロセス • 理解 • 自己学習環境 • インフォーマルラーニング • ナレッジマネージメント • シミュレーション 業務プロセス変革 スキル (Hands) • 処理手続 • 操作手順 • 事実とするもの • 集合研修 • ドリルと演習 • 実験、実習 • パフォーマンスサポート（ヘルプデスク） システム操作変革 “Heart” “Head” “Hands” 知識面 — 風土変革に対する受容（行動の変容） — 新しい知識と展望の理解 — 新しいスキルの学習（システム操作など） マインド スキル 75 | | 変革移行管理手段としてのEAT 変革移行管理 (Change Management) の1つとして、変革の受容度を高めるため、マインド面・知 識面・スキル面でのサポートを行い、変革に対する正しい理解や継続的な変革推進を促します。 マインド マインド やりたくない やりたくない やってみよう やってみよう 知識面 知識面 わからない わからない わかった わかった スキル スキル できない できない できる できる ②効果創出までの 期間の短縮 生産性 チェンジカーブ （改革における生産性の推移） ③生産性 改善効果 の最大化 当初の生産性 本番稼動 黒表記：ＥＡＴを行う場合 赤表記：ＥＡＴを行わない場合 ①生産性の 落ち込みの 最小化 ①’生産性の 落ち込み 未知数 時間 ②効果創出までの 期間未知数 76 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 プロジェクトがビジネス価値を実現するまでの因果関係 因果関係の網の目構造論 P2Mのアプローチから言えること プロジェクトの「成功」の定義とエンド・ツー・エンド評価の必要性 6. 論理と現実の乖離についての認識と対処法 77 | | 「因果連鎖の網の目」構造論 「因果連鎖の網の目」構造論における「現実」の認識 - 複数の要因が絡み合って結果が起こり、それらの複数の結果が次の原因となるといった連 鎖が時間軸の上を流れている。 戦略とは現実への介入である。そして介入においては現実が意図したとおりに変化 するとは限らない。 自社以外に顧客や競争相手がいる「市場」においては、現実を設計どおりに実現す ることは元々困難である。 「介入」とは？ 自分も状況の一つの要因に過ぎないと捉え、自分 が何かを完全にコントロールして状況を変えると いったことはもともとできない、という前提の基に、 自分が何をすべきか（行為）を決定し、それによっ て状況に影響を与えていくこと。 構築論と戦略論を架橋する役割としてのCIO・・・根来 龍之 78 | | 「構築論」と「戦略論」における現実認識の形式の相違 両方のアプローチ間を架橋するのがCIOの使命である。 構築論（プロジェクト・マネジャーの視点）・・・「つくる」こと - 構築論における投資は「設計図」の実現をそのままはかるもの。 構築論は「もの−こと」構造論である。 情報システム構築においては、若干の戦略変更があっても変更しないですむようにシステムをつくることが 重要であり、不確実性はシステムの外部にあるものとされる。 変化に強いシステムを設計・実現することが目標。 経営者にとっては「1円の超過」、「1日 の遅延」は多くの場合、問題ではない。 戦略論（経営者の視点）・・・「状況に介入する」こと - - 戦略論における投資は想定した因果連鎖に基づいて、状況に「介入」し、その波紋を観察し、次 の投資をまた行なうという連続的な「変化」の過程に自らを置くこと。 戦略論は「因果関係の網の目」構造論である。 ＩＴ投資においては、投資には「意図せざる結果」がつきものだという、不確実性への宿命的関与が必要。 決して全体を見通すことができない現実における「選択の自由と責任」が前提として必要。 構築論と戦略論を架橋する役割としてのCIO・・・根来 龍之 79 | | 意図せざる結果の存在 行為・・・自己原因の「意図した結果」の追求 - 将来に向かって自分が意図した結果を作り出すために行なうのが行為である。行為者は 因果関係の「地図」を基に、行為の設計図をもって自らを状況に投げ入れる。このとき、現 在の行為は選択の自由があるため、現在より後の因果連鎖を不確実にする（取りうる行為 によって異なる因果連鎖を生じさせる）。つまり行為は自分を原因にするという性質がある。 これを行為の「投企」性または「自己原因」性という。そして結果的に、重要な因果連鎖を把 握できていれば「意図」が達成できることになるが、因果連鎖の網の目構造論を前提とす れば、必然的に事前に因果連鎖の100%の吟味はできない。 他社の行為が新たな因果連鎖を新たに作るという性質があるので、因果連鎖は必 然的に不確実になる。 意図せざる結果の存在は宿命的なものである。しかしこのことは、それに対応する ことが不可能だとも無意味だとも主張している訳ではない。 構築論と戦略論を架橋する役割としてのCIO・・・根来 龍之 80 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 プロジェクトがビジネス価値を実現するまでの因果関係 因果関係の網の目構造論 P2Mのアプローチから言えること プロジェクトの「成功」の定義とエンド・ツー・エンド評価の必要性 6. 論理と現実の乖離についての認識と対処法 81 | | プロジェクト＆プログラムマネジメント標準ガイドブック（P2M） 複数のプロジェクトを計画通りに遂行するための知識を体系化したもの。 決められた個々のプロジェクトを計画通りに遂行するだけでなく、企業の価値そのも のを高めるという、より広い観点に立って複数のプロジェクトを組み合わせて実施す る点がPMBOKと大きく異なる。 PMBOKの知識領域・・・「時間」や「予算」「品質」など9つ P2Mの知識領域・・・「戦略」や「ファイナンス」「関係性」など11の領域 プロジェクト&プログラムマネジメント(P2M)標準ガイドブック 日本プロジェクトマネジメント協会 82 | | ＩＴプロジェクトとプロジェクトBSC ＩＴに関わるプロジェクト・マネジメント標準の多くは、いずれも個別プロジェクトを対称 にしていて、プロジェクトのQCD管理や技術者のスキル評価が中心となっている。 CMMについても、それはあくまでプロジェクト遂行の組織能力を評価するもので あって、経営戦略への貢献度などについて明らかにするものではない。ここにプロ グラム概念の導入の必要性が認められる。 プロジェクト・バランス・スコアカード (P2Mシリーズ) 小原 重信 (編集), 浅田 孝幸 (編集), 鈴木 研一 (編集) 83 | | プロジェクト・バランス・スコア・カードの例 全社バランス・ スコア・カード 業務 学習 営業員のPDA操作習得 財務 満足度向上 売上拡大 売上拡大 学習 営業員のPDA の機能・操作性 への満足度90点 業務 | ・ＰＤＡソフ ト開発 ・ﾈｯﾄﾜｰｸ 環境構築 ・納期ＤＢ 構築 顧客 | 学習 学習 納期即答率および PDA講習受講率 100% 業務 業務 営業全員 がＰＤＡを 持ち,商談 中に その場で 納期回答 顧客 顧客 即時納期 回答によ る ・顧客満足 度向上 ・機会損失 の削減 お客様満足度スコア 90点または リピート受注率90% 財務 財務 売上３％以上アップ 財務 84 即時納期回答 顧客 納期精度98%以上 ・出荷日程 精度 の向上 プロジェクト・バランス・スコア・カードにおけるKPIの例 責任・権限 ＫＰＩ（成果目標） 営業部門 PDAを活用してお客様満 足度を高め,売上を増大さ せる お客様満足度スコ ア（リピート受注 率）向上と売上3% アップ 営業員が全員PDAを 使いこなせる PDA講習会受講率お よび納期即答率100% 情報システ ム部門 営業員に十分な機能を持 つ使い易いPDAを提供す る 営業員のPDAの 機能・操作性への 満足度90点 営業部門にPDA講習 会を実施し,操作を習 得してもらう PDA講習会の満足度 90点,操作の問合せへ の迅速な対応（ヘルプ デスク） 製造部門 営業部門に信頼性の高 い納期情報を提供する 納期精度98%以上 生産管理の仕組みを 見直し,納期回答精度 を向上させる 購買,生産計画,進捗管 理,在庫管理・・・等々 の見直し 85 | | 前提条件やスキル ＫＰＩ（プロセス目標） P2Mとプログラム−プロジェクトの関係のイメージ図 以下の例ではシステム開発「プロジェクト」以外の様々な要因が因果関係の連鎖を 形成し、「（第一次）SCM推進プログラム」を形成している。 この場合、個々のプロジェクトにおけるQCD目標は余り重要ではなく、全体としての 「（第一次）SCM推進プログラム」のビジネスゴールの達成こそが重要である。 移行支援・ユーザー教育 構想立案・要求定義 システム開発プロジェクト 当面のビジネスゴール QCD目標で評価 戦略課題の設定 （例・SCM） 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 業務改革プロジェクトA 86 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 プロジェクトがビジネス価値を実現するまでの因果関係 因果関係の網の目構造論 P2Mのアプローチから言えること プロジェクトの「成功」の定義とエンド・ツー・エンド評価の必要性 6. 論理と現実の乖離についての認識と対処法 87 | | 立論における情報システム構築プロジェクトの「成功」と「失敗」の定義 経営者視点に基づくプロジェクトの「成功」と「失敗」の定義と評価のタイミング 【定義】 そのプロジェクトに託された目的（ビジネス価値の実現）の達成度 【評価のタイミング】 構築した情報システムが、目的として掲げた何らかのビジネス価値を実現したタイミング （通常、当該情報システムが稼動し、一定期間経過後） 高↑ 目的達成度 ↓低 ︵経営者の視点︶ 「成功」の範囲 不満足な成功 満足な成功 純粋な失敗 形式的な成功要件を 満たした失敗 低← QCD目標達成度 →高 （プロジェクト・マネジャーの視点） 88 | | プロジェクトの「成功」と「失敗」の定義と評価のタイミング 本番稼動後、ある一定の期間後の評価が必要 超上流工程 BABOK 経営戦略∼ビジネスケース 目的 結果 目的達成度 成果検証 ビジネス要件定義∼業務要件定義 契約行為 システム要件定義 要求工学 上流工程 中流工程 | 下流工程 SWEBOK ソフトウェア設計 | PMBOK プロジェクト実施工程 システム設計 89 ユーザー受入テスト ヘルプデスク BICC EATなど 運用テスト システム・テスト ソフトウェア・テスト プログラミング 保守 運用 JIPDEC・・・「IT 投資マネジメントの フレームワークに関する調査報告書 IT投資マネジメントフレームワーク 全社ＩＴマネジメント組織 ＩＴ投資 テーマの選択 戦略マネジメント 経営戦略と 戦略マップ の作成 事業戦略と 戦略マップ の作成 全社情報資本 ポートフォリオ の評価 全社ＩＴ投資 テーマ案 の設定 ＳＢＵ情報資本 ポートフォリオ の評価 ＳＢＵ ＩＴ投資 テーマ案 の設定 意思決定 会議体 実施の 可否判定 全社ＩＴ投資 計画の作成 ＳＢＵ ＩＴ投資 計画の作成 実施の 可否判定 個別プロジェクト の実行状況 のフォロー 全社ＩＴ投資 計画の見直し 全社情報資本 ポートフォリオ の更新 個別プロジェクト の実行状況 のフォロー ＳＢＵ ＩＴ投資 計画の見直し ＳＢＵ情報資本 ポートフォリオ の更新 ＳＢＵ ＩＴマネジメント組織 モニタリング フェーズ（中間） 計画フェーズ 個別プロジェクト マネジメント 実施計画 策定 投資額の 見積もり 評価方法 の決定 目標の 決定 ＩＴ投資 の評価 計画フェーズ 90 データ収集/分析 機能の構築 | | 事前評価 の実施 プロジェクト の実施 コントロール フェーズ（事後） 中間評価 の実施 事後評価 の実施 実施計画 の修正 モニタリング コントロール フェーズ（中間）フェーズ（事後） 企業はプログラムとプロジェクトの集合体である 移行支援・ユーザー教育 構想立案・要求定義 システム開発プロジェクト 戦略課題の設定 （例・SCM） 当面のビジネスゴール QCD目標で評価 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 移行支援・ユーザー教育 構想立案・要求定義 業務改革プロジェクトA システム開発プロジェクト 戦略課題の設定 （例・SCM） 当面のビジネスゴール QCD目標で評価 - 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 移行支援・ユーザー教育 構想立案・要求定義 - 業務改革プロジェクトA システム開発プロジェクト 戦略課題の設定 （例・SCM） 当面のビジネスゴール QCD目標で評価 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 移行支援・ユーザー教育 構想立案・要求定義 業務改革プロジェクトA システム開発プロジェクト 戦略課題の設定 （例・SCM） 当面のビジネスゴール QCD目標で評価 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 移行支援・ユーザー教育 構想立案・要求定義 業務改革プロジェクトA システム開発プロジェクト 戦略課題の設定 （例・SCM） QCD目標で評価 当面のビジネスゴール 業務改革プロジェクトB SCM推進プログラム の範囲（継続する） 業務改革プロジェクトA 91 情報システム投資は | | - 戦略関連 情報関連 業務関連 インフラ関連 に分類できる。 この考え方は・・・ ＩＴポートフォリオ戦略論における各構成要素に対するマネジメントの目的 戦略やプログラム、プロジェクトのミックスによってこれら4 象限への投資配分が決まるのであって、逆ではない。 •管理強化 •より質の高い情報 •より高度な統合 •品質の向上 情報 関連 •コストの削減 •スループットの向上 戦略 関連 業務関連 インフラ関連 ピーター・ウェイル 92 | | •売上の増加 •競争優位 •競争の必要性 •市場ポジショニング •革新的なサービス •ビジネス統合 •柔軟性と俊敏性を備えたビジネス •事業部ＩＴの限界コストの削減 •ＩＴコストの削減 •標準化 ＩＴポートフォリオ戦略論 –最適なＩＴ投資がビジネス価値を高める- ビジネスとＩＴの整合性 表現の 障壁 戦略的コンテクスト 製品/市場/投資/顧客 戦略的意図 環境 影響を及ぼす 機会：テクノロジー 脅威：競合他社 規約：規則 現行の戦略 推進する 影響を及ぼす 情報を強化する 要件定義の障壁 実現の障壁 ＩＴ戦略 ＩＴポートフォリオ ＩＴの役割 情報 関連 サービスの提供 指針と標準 整合させる 戦略 関連 業務関連 インフラ関連 ピーター・ウェイル 93 | | ＩＴポートフォリオ戦略論 –最適なＩＴ投資がビジネス価値を高める- 情報システム投資マネジメントの考え方 ここに下記の無形資産への投資計画も盛り込む必要が出てくる。 - 人的資本レディネス 情報資本レディネス 組織資本レディネス 現在のポートフォリオ 近未来のポートフォリオ 絶対額の増減の決定 配分の決定 情報 関連 戦略 関連 業務関連 インフラ関連 94 | | 情報 関連 戦略 関連 業務関連 インフラ関連 人的資本レディネスの測定 「戦略的職務群」に対応する。 「戦略への方向付けの創造」と「レディネスの創造」によって強化される。 人的資本レディネス・モデル 画像はカット 戦略マップ ：バランスト・スコアカードの新・戦略実行フレームワーク ロバート・S・キャプラン、デビッド・P・ノートン 95 | | 情報資本レディネスの測定 「戦略的ＩＴポートフォリオ」に対応する。 「戦略への方向付けの創造」と「レディネスの創造」によって強化される。 主張はピーター・ウェイルにほぼ同じ。 画像はカット 戦略マップ ：バランスト・スコアカードの新・戦略実行フレームワーク ロバート・S・キャプラン、デビッド・P・ノートン 96 | | 組織資本レディネスの測定 「組織変革の方針」に対応する。 「戦略への方向付けの創造」と「レディネスの創造」によって強化される。 画像はカット 戦略マップ ：バランスト・スコアカードの新・戦略実行フレームワーク ロバート・S・キャプラン、デビッド・P・ノートン 97 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 98 日本的（悪しき）商慣習の打破に向けて 要求定義問題にアジャイル開発は処方箋足り得るか？ | | プロジェクトが失敗に至る代表的なシナリオ ②プロジェクトの開始前工程 競争入札や競合結果の与件としての影響 7 プロジェクト遂行能力の不足 ユーザー企業の優越的立場 コミュニケーション 49 ユーザー企業の優越的立場 杜撰な計画 統合 スコープ 54 27 55 4 調達 19 1 17 21 受注優先 主義 3 QCDの破綻 タイム 9 44 コスト 10 45 品質 9 37 曖昧な契約 （含・未契約状態） 56 情報処理推進機構 ソフトウェア 凡例 エンジニアリングセンター 『ITプロジェクトの「見える化」 上 流工程編』, 日経BP社, 2007 99 16 非現実的な与件に 基づく開始 （特に納期とコスト） 3 楽観的見通し 人的資源 3 楽観的見通し リスク ①プロジェクトの開始後工程 | | スポンサーによるプロ ジェクト放棄の決断 （失敗の確定） ステークホルダー の心象悪化 リカバリーの失敗 明確な契約を締結 しない商慣習（18件） プロジェクト開始前工程 固有のトラブル プロジェクト開始前に 顕在化した件数 個々のトラブルが該当する PMBOKの知識エリア プロジェクト開始前に顕在化ま たは与件可能であった件数 プロジェクト開始後 に顕在化した件数 「源流」工程に潜む失敗の潜在的リスク要因 契約前に顕在化 または予見可能 未契約状態および成果物確認前 の次フェーズの作業実施 契約後に 顕在化 18 楽観的見通し 56 0 ユーザー企業の優越的立場 17 2 競争入札や競合結果の与件 としての影響 7 0 80 2 合計 情報処理推進機構 ソフトウェアエンジニアリングセンター 『ITプロジェクトの「見える化」 上流工程編』, 日経BP社, 2007 100 | | 「悪しき商慣習」の観点からのプロジェクト失敗原因の掘り下げ① (ⅰ)楽観的な見通しと杜撰な計画 失敗したプロジェクトには，楽観的な見通しのもとにプロジェクトを開始した例が 多数見受けられる．完全な準備と体制で臨んだつもりでも，プロジェクトは想定外 の事象や環境の変化によってQCDなどに影響を受けることが少なくない．増して や十分なリスクマネジメントを行なわず，希望的観測でプロジェクトを開始すれば, 成功は覚束ない. (ⅱ)ユーザー企業の優越的な立場と曖昧な契約 101 不平等な取決めや曖昧な契約条件に基づいてプロジェクトが開始されたケース が18件確認された．未契約のまま開始されたプロジェクトや，提供側企業が明示 的に契約を実施していないケースもあった．これらの背景にはユーザー企業の 優越的な立場や，契約という行為に関する日本社会の伝統的な商慣習も関係し ている．両者のパートナーシップが確立されていなければ，プロジェクトの過程で 大きなトラブルの要因となるに違いない． 発注者と受託者という関係では，その優越的な立場を濫用し，困難な条件の強 要が行われ易い．しかしそれらは，結果的に自らの不利益になることを十分認識 すべきであろう．自社の経営戦略実現の手段として情報システムを位置付けるな らば，その開発作業の多くを委託する提供側企業とのパートナーシップを疎かに するべきではない． | | 「悪しき商慣習」の観点からのプロジェクト失敗原因の掘り下げ② (ⅲ)競争入札方式や競合状態の悪影響 調達コストの低減や透明性の確保の観点から，競争入札方式による調達が以前から行 なわれている．しかし，この方式は経営戦略を実現するための情報システムの調達方 法としては重大な疑問が残ることが，調査から示唆された． 受注競争状態にある提供側企業にとっては，本来プロジェクトを成功裏に進める上で重 要であっても，自社の受注に不利に作用しかねない情報の開示は，少なくとも，営業活 動時点では得策でない．まず，受注することを優先し，プロジェクト実施段階の課題を明 示することを回避しようとするに違いない．しかしこのことは，ユーザー企業のCIO（情報 システム部門の責任者），更に経営者にとって大きなリスク要因となる． (ⅳ)提供側企業の受注優先主義 更なる背景として,提供側企業の受注優先主義の悪影響が事例から読み取れる.勿論こ れは個々の企業の経営判断に属することであり,採算度外視の低価格応札も一定の説 得力を持つ場合もあるかもしれない.しかし,「一円入札」の例を引くまでもなく，低コストに 執着することは，とりわけ知的サービスの低下をもたらし，後工程に悪影響を与える可 能性が高い． また,営業部門は受注金額だけを評価され,最終的な損益はPMの属する開発部門の責 任となっている企業も少なくない.このような評価基準の下では職務に忠実な営業マンで あればあるほど,損益算定や付帯条件の整備よりも,受注の獲得が優先してしまうであろ う.このような受注姿勢も失敗プロジェクトの原因の一部になっていることは間違いない． 102 | | 「悪しき商慣習」の観点からのプロジェクト失敗原因の掘り下げ③ プロジェクト失敗の源流と経営者の役割 103 これまで経営者にとって，情報システム構築は情報システム部門や提供側企業 の問題であったかもしれない．しかし，企業統合や新しいビジネスモデルの実現 を目指した多額の投資であるならば，その成否は経営者自身の責任と業績に深 く関わらないはずはない． プロジェクトが稼働遅れ，品質不良，予算超過，といった不満足な結果となれば， それは情報システム部門や利用部門の問題にとどまらず，経営者自身の問題と なる.もし経営者がこれらに無関心であったとするならば，そのプロジェクトは経営 にとって無価値であったことを示唆している． 無論，PMのスキル不足，提供側企業の能力不足という責任追及は無意味では ないが，プロジェクトが失敗に向かいつつある段階では解決策にはなり得ない． 要求定義が曖昧という指摘も少なくないが，不確実な経営環境のなかで，仕様 は度重なる変更にさらさられることも珍しくない．一旦決めたから変更しないとい うプロジェクトマネジメント手法も常に正しいとは言えない． 情報システムが支援する経営戦略やビジネスモデルへの関係者の理解不足，曖 昧な契約関係の背後にある強圧的な業者管理姿勢など,失敗の源流には企業の 風土・文化，すなわち企業経営の問題が横たわっているに違いない. | | マネジメント・コミッティーの重要性 要件定義、仕様凍結は益々困難になる。 社会・経済の環境変化は益々速くなる。 予測どおりにプロジェクトはまず進まない。 だからこそマネジメント・コミッティーが機能するお客様かどうかの見極めが重要 【マネジメント・コミッティー関連】 ステアリング・コミッティー、エスカレーション・パスは機能するか？ タイムリーにお客様のスポンサーとプロジェクトの状況についての折衝ができたか？ 業務改革など、お客様主導（責任）で実施いただく作業は実施されていたか？ 自社はパートナーとして認知されているか、業者扱いか？ プロジェクト・マネジャーの要望をスポンサーは適切に受け止め、アクションをとったか？ プロジェクト憲章の制定、またはそれに相当する活動は行なわれたか？ これらの要件が満たされていれば、プロジェクトは曲がりなりにも成功に向かっていける。 最後の知恵は、「傷の浅いうちに撤退すること」 104 | | 目 次 1. イントロダクション 2. プロジェクトの成功・失敗に関する統計データ 3. QCD目標を突き詰めていくと、どこに到達するか？ 4. プロジェクト失敗の真因に関する考察 5. 経営者の意思決定メカニズムと情報システム・プロジェクト への認識 6. 論理と現実の乖離についての認識と対処法 105 日本的（悪しき）商慣習の打破に向けて 要求定義問題にアジャイル開発は処方箋足り得るか？ | | アジャイル開発について 画像はカット 106 | | アジャイル開発は要件定義の問題を解決するか？ アジャイル開発は万能の解決策ではない！ 顧客が理解できない要求仕様を書くよりも、アジャイル開発で顧客と折衝するほうがいいといわれるこ とがある。確かにプロトタイプが簡単にできれば要求も簡単に獲得できる可能性がある。 しかし上述したような要求の優先順位をプロトタイプの中に組み込むことは容易ではない。 またもし要求を明示的に記述しておかなければ、プロトタイプがすべての要求に対応する仕様を実現し ていることをどうやって確認するかという問題がある。またプロトタイプで必要な要求が確認できなかっ た場合にはどうするのかという問題も残る。どこにも要求に関する記録は残っていないのだ。 したがってアジャイル開発であっても要求を文書化しておく必要があることに注意すべきである。またプ ロトタイプの場合、要求仕様が何なのかを具体的に確認するためにはいつもプロトタイプを動作させて みないとわからないため、かえって仕様確認に手間がかかる可能性もある。 ちょっと考えればわかることだが、プロトタイプの開発にもコストと時間が必要だ。製造業などでは、製 造期間を短縮するために最近では「試作レス」の導入も検討され始めていることを考えると、今後はア ジャイル開発レスのソフトウェア開発の方がかえって先進的なアプローチになるかもしれない。 いずれにしても要求のアジャイル開発の目的を明確にして有効性を明確にしておくことが肝要だ。そう でないと何のためのアジャイル開発なのかがわからなくなる。したがって、この問題への対処としては、 要求についてまず合意すること、次いでその中で真にアジャイル開発により確定すべき要求があるとき に限定してアジャイル開発を実施するというのが実践的ではないだろうか？ もしアジャイル開発の目的が曖昧ならプロトタイプを作成しても要求は曖昧なままであり、徒労に終わ るに違いない。逆に要求が明確ならプロトタイプを作成するよりも仕様の具体化を急ぐべきであろう。 http://www.bcm.co.jp/site/youkyu/index.html 107 | | ご清聴有難うございました。 さて、ご質問＆ディスカッション・・・ 108 | |
© Copyright 2024 Paperzz
