Comments
Description
Transcript
情報システム構築における経営者の役割と行動
SCMとIT経営・実践研究会 7月例会 「情報システムを成功に導く経営者の支援行動」 出版記念セミナー 2013年7月20日 武蔵大学総合研究所 奨励研究員 中小企業診断士・ITコーディネータ 栗山 敏 本日のスケジュール 13:00-13:10 松島教授・祝辞 13:10-15:00 栗山・プレゼンテーション 15:00-15:20 ハーフタイム・連絡事項 15:20-16:00 質疑応答 16:00-17:00 パネル・ディスカッション ご質問はお手元の「質問カード」にご記入下さい。 ハーフタイムに回収してQAに用います。 2 初の単著、7月10日発売！ 3 経歴と研究のモチベーション 栗山 敏（昭和35年3月28日生 53歳） 日本IBMに30年勤務 法人顧客担当営業（15年） コンサルタント（7年） ユーザー企業の経営層向けセミナー講師（8年） 問題意識と研究のモチベーション IT投資の効果をなぜ論理的に説明できないのか？ 2000～2002年 岩手県立大学大学院・ソフトウェア情報学研究科 前期博士課程 「情報システム機能の有効性評価方法に関する研究」にて修士号 プロジェクトの失敗をどうすれば撲滅できるのか？ 2009年～ 武蔵大学経済学部大学院・経済学研究科 後期博士課程 経済・経営・ファイナンス専攻 「プロジェクトを成功に導く経営者の行動」にて学位請求論文を準備中 4 本書の位置付け 先行研究①・・・2011/3 プロジェクトを成功に導く経営者の支援行動 に関する仮定の構築 「経営者視点による情報システム・プロジェ クト評価手法の再構築」 （日本ビジネス・マネジメント学会, 第7号） 先行研究② ・・・2011/6 経営者の支援行動に関する仮定その妥当 性を事例研究によって確認 「経営者の情報システム･プロジェクトの支援 に関するベストプラクティス」 （日本商学研究学会誌, 第5号） 今後の課題 1. 導出された経営者の支援行動が「何故」 プロジェクトを成功に導くのか？ 2. 一連の支援行動は実務のどのような課 題をどのように解決するのか？ 3. そのような支援行動をどうすればより確 実に引き出せるのか 5 これらを統合して 博士号学位請求論文へ →それに先立って今回出版 ①ベストプラクティスがプロジェク トを成功に導く因果関係の明確化 ②ベストプラクティスが実行される とは限らない。しかし実行されるよ うにしなければならない。 先行研究③ ・・・2013/6 経営者の支援行動の阻害要因の明確化と解 決策の検討 「プロジェクト・マネジメントの機能不全解消に 向けた経営者の支援行動に関する一考察」 （日本商学研究学会誌, 第6号） より確実なベストプラクティスの実行 →プロジェクトの成功率の向上 （成果報酬型契約に注目） プロジェクトの失敗原因の類型化 プロジェクトの失敗は 「プロジェクト・マネジメントの機能不全」！ 一円入札や、競争入札や競合 の結果、あり得ないQCDが目標 として与えられるケースなど プロジェクト・マネジャーの責任 自責 失 敗 原 因 の 源 QCD目標の不適 切な設定など PM手法の範囲外 PM手法の範囲内 プロジェクト・マネ ジャーのスキル・ 経験不足など 対策はプロジェクト・マネジャーの 人材育成と能力アップ（実践力） 6 他責 プロジェクト関連リ ソースの不足など 本書が主要な考察対 象とする範囲 Agenda 7 1 プロジェクトの成功・失敗とは何か？ 2 プロジェクトを成功に導く経営者の支援行動 3 経営者の支援行動をより確実に実現するために 情報システムの構築手順 要件定義の局面 開発作業の局面 環境の変化 目的の設定と 頂上までの確か な道のり 定着山 構築山 落石・ 崖くずれ 熊 標識不明 毒草 創造山 登頂への障害 体調不良 舵取り山 不安 腹痛 風邪 踏み出し山 なぜ改革か！ 何を変えるか！ どう変えるか！ 仕組みを作る！ 企画 全体構想立案 基本計画立案 業務／IT開発 （１） （２） 基本構想立案 ＷＨＡＴ 企画 WHY 企画プロジェクト 構想プロジェクト 企画書 8 基本構想書 （３） 基本計画作成 ＨＯＷ 計画プロジェクト 基本計画書 （４） 業務/ＩＴ開発 BUILD 開発プロジェクト 装備の故障 仕組みを浸透させる！ 展開 （５） 展開 DEPLOY 展開プロジェクト 開発計画書 展開計画書 情報システム構築プロジェクトの工程 超上流工程 成果検証 経営戦略～ビジネスケース ユーザー受入テスト ビジネス要件定義～業務要件定義 契約行為 システム要件定義 プロジェクト・ライフサイクル 上流工程 下流工程 システム設計 運用テスト 保守 システム・テスト 運用 ソフトウェア設計 中流工程 9 ソフトウェア・テスト プログラミング Pressman, R. S., Software Engineering : A Practitioner's Approach (Software Engineering and Technology Ser.), McGraw Hill Higher Education, 1982（岡田正志訳『ソフトウェア・エンジニアリング 序説』, TBS出版会, 1983年）.Roger S. Pressman (1982)： Software Engineering 情報システム構築プロジェクトは合意形成の積み重ね これらすべてに関する合意を形成することが「要件定義」 （情報システム構築プロジェクトの最初で最大の難関） これらのすべてに、納得感 と合意が必要！ Why・・・なぜそれをシステム化すべきか？ （システム化に値するか？） What･･･何をシステム化するか？ （対象業務の範囲＝スコープ） How・・・どのようにシステム化するか？ （どのような機能を持たせ、 幾らまで投資する価値があるか？） 10 プロジェクトの量的・質的変化がもたらす難易度の上昇 部門のシステムから企業間のシステムへ（大規模化） 業務改革が前提となる情報システム構築（複雑化、不確実性の増大） 情 報 シ ス テ ム の 導 入 第一段階 情報システムの導入 12.1% （米国では2.0%） 部情 門報 内シ でス 活テ ム 用を 第二段階 部門内最適 53.7% （米国では38.0%） 「省力化」のプロジェクト 「 部 門 」 の 壁 企 業「 部情 内門報 でをシ 最超ス 適えテ ム 活てを 用」 第三段階 企業内最適 26.7% （米国では41.3%） 「 企 業 」 の 壁 「 企取情 最業引報 適を先シ ス 活超・ 顧テ 用え客ム て等を 」 第四段階 企業間最適 7.5% （米国では18.7%） 「増力化・競争優位構築」のプロジェクト ＩＴ経営ロードマップ改訂版 平成22年3月 経済産業省 11 http://www.meti.go.jp/policy/it_policy/it_keiei/action/conference/roadmap_revised.pdf 情報システム構築プロジェクトに現れる変化 • プロジェクトの難易度が高まる。 • 経営者の関与の必要性が高まる。 第一段階 比較項目 12 情報システ ムの導入 第二段階 部門内最 適 「 部 門 」 の 壁 第三段階 企業内最 適 「 企 業 」 の 壁 第四段階 企業間最 適 目的 省力化、自動化 ･･･ 戦略目的の達成、 競争優位の確立 規模 比較的小規模 ･･･ 比較的大規模 業務改革の要否 基本的に不要 ･･･ 多くの場合に必須 不確実性・リスク・難易度 比較的低 ･･･ 比較的高 プロジェクトの特性 情報システム構築 プロジェクト ･･･ 情報システム構築を伴なう 経営改革プロジェクト 経営者の関与の必要性 基本的に不要 ･･･ 多くの場合に必須 大規模化に伴う、難易度の幾何級数的増大 5 C2 ＝ 10 C ＝ 45 10 2 ステークホルダー間のコミュニケーションパスが増加するにつれ、 合意形成（要件定義など）が困難になる。 合意を形成するための工数が劇的に増大する。 ステークホルダーの数は2倍に過ぎないが、コミュニケーションパ スは4.5倍にもなる。 プロジェクトの難易度が上がる 13 業務改革を伴う情報システムの要件定義が困難な理由 業務改革後の業務プロセスは誰も見たことが無い。 それをシステム化するって・・・？ To Be （新業務プロセス） 業 務 改 革 As Is （現状の業務プロセス） 14 要件定義 業務要件 システム要件 • 想像の世界で業務要件やシステム要件を決め ざるを得ない。 • やってみないと分からない（不確実性の増大）。 • 新業務プロセスの「見える化」とステークホル ダーの納得感が無ければ要件定義ができない。 手作業の置換 業務要件 システム要件 ERPパッケージの導入が難航する理由 目的は「ありたい姿」の実現だったはず。それは明確だったか？ To Be（ありたい姿） Fit/Gap分析 （ERP）パッケージ コア・コンピタンス コモン・コンピタンス • コア・コンピタンスよりもパッケージの機能が 劣っていたらパッケージ導入は「レベルダウン」 • コモン・コンピタンスはパッケージに合わせられ ない明確な理由の有無で判断 （取引先、商慣行など） 使えない！ 合わない！ As Is（現状の姿） 15 Fit/Gap分析 （ERP）パッケージ ERPパッケージ：Enterprise Resource Planning（統合基幹業務システム） プロジェクトは放置すれば「必然的に」失敗する！ 適切にマネージしなければ、プロジェクトは必然的に失敗する！ プロジェクトの特性（ ⇔ ルーチンワーク ） 1. 個別性・・・非反復的活動であるため、計画立案時の参考情報が乏しい。 2. 有期性・・・成果物が完成してもスケジュールを満たさなければ無価値。 3. 不確実性・・・通常業務と比べて不確実性が高まるのは必然。 伊藤健太郎 『プロジェクトはなぜ失敗するのか ―知っておきたいITプロジェクト成功の鍵』 16 デスマーチ ： エドワード・ヨードン 「ソフトウエア開発プロジェクトは なぜ混乱するのか」 失敗の原因をPMの能力不足「のみ」に帰結させるな！ プロジェクト・マネジャーやメンバー（ITベンダー・ユーザー企業 双方）の能力不足がプロジェクトの失敗につながるケースは確 かに少なくない。 しかしPMやメンバーの能力やスキルが向上すれば、すべてう まくいくという、逆説は成り立たない。 問題の構造はもっと複合的かつ複雑である。 PMやメンバーの能力に全責任を帰結させる論調からは、建設 的な解決策は期待できない。 （単なる「スーパーPM待望論」では解決につながらない。） 一方、「経営者のリーダーシップ不足」という議論も不毛。 「ベンチがアホやから、野球がでけへん・・・」と同じ。 17 次のようなプロジェクトは成功？失敗？ ① コストが計画よりも1円オーバーした。 QCD：品質・コスト・納期 ② 本番稼動が計画よりも1日遅れた。 ③ ITベンダーは情報システム部門からの仕様書の通りの品質、コスト、スケジュー ルでソフトウェアを開発して納入した（QCDは100点）が、情報システム部門と ユーザー部門の意思疎通が行なわれておらず、納入されたソフトウェアは実務 に使われなかった。 ④ コストは2倍、スケジュールは1年遅れ・・・でも本来のプロジェクトの目的は達成 され、システムは順調に稼動中。 【これからのお話の着眼点】 QCD（品質・コスト・納期）目標「のみ」で評価することは、どこまで 「適切」なのか？ QCD目標は、誰にとっての評価基準なのか？ 経営者は何を基準に成否を評価している（と考えられる）のか？ 18 Standish Group （1994～） の調査 ＊「成功」の定義・・・品質、コスト、納期の3点すべて について「当初計画通りの成果」を収めたプロジェクト。 何と31%もがキャンセル！ 「2・2・2の法則」 情報システム開発では、計画した2倍の 費用と2倍の時間がかかり、期待した2 分の1の機能しか実現できない 19 日経コンピュータ 第２回プロジェクト実態調査 2008年12月1日号特集・・・成功率は３１．１％ QCD目標のすべてを達成したプロジェクトを「成功」と定義 2003年は26.7% （＋4.4ポイント） 納期遅れの原因は「要件定義の長期化」がトップで43.6% 要件自体が高度化し、難易度が上がった。 情報システム部門の要件定義能力が低下した。 品質は48.1%が目標を未達成。 テストが不十分･移行作業に問題が発生・・・41.7% 要件定義が不十分・・・36.7% 情報システム部門の平均人数は13.1人。対象企業の全従業員672.2名に 対して1.9% 20 素朴な問題意識 ① そもそもなぜQCD目標が達成できないのか？ ② そもそも成功率が30%程度しかないプロジェクトへの投資は「適 切な」経営判断、意思決定と言えるのか？ 世の経営者たちはそんなに不適切な意思決定を繰り返しているのか？ QCD基準の調査はいずれも情報システム部門の責任者に対して行なわ れている。経営者がどう評価していたかの調査は存在しないので不明。 プロジェクトは本当にこんなに「失敗」しているのか？ 「誰から見た」成功・失敗なのか？ 21 問題意識① 「なぜQCD目標が達成できないのか？」 この問いは「QCD目標は適切に設定されている」 という暗黙の前提に立っていないだろうか ？ 失敗の原因は １０個ある！ 未知、無知、調査・検討の不足、 企画不良、価値観不良 「計画や目標設定」の失敗 （事前） 不注意、手順の不遵守、誤判断、 組織運営不良、制約条件の変化 「変化対応」の失敗 （途中・事後） 畑村陽太郎 『失敗学のすすめ』講談社, 2000年. 22 ① 「なぜQCD目標が達成できないのか？」の分解 ケース1：「変化対応の失敗」 （QCD目標が適切に設定されていた場合） 適切な目標が設定されていたのであれば、それが達成できなかった のは好ましくないことである。 その原因究明と再発防止策が厳密に行なわれなければならない。 ケース2：「計画や目標設定の失敗」 （QCD目標が適切に設定されていなかった場合） その目標の達成度で結果を評価することこそが不適切である。 「なぜ目標を適切に設定することが難しいのか」こそが検討されねばならない。 23 ここまでの話の展開の整理（ストーリーの確認） トラブルが多い！ 成功率は30%と言われている！！ 問題意識① そもそもなぜQCD目標が達 成できないのか？ 問題意識② そもそも成功率が30%程度しかないプロ ジェクトへの投資は「適切な」経営判 断、意思決定と言えるのか？ •そもそもこの問いが成立しない。 •経営者の判断は今のところ「不明」だから。 「計画や目標設定」 の失敗（事前） •予算制度の制約 •業務改革による不確実性 24 「変化対応」の失敗 （途中・事後） •経営者の支援不足 •プロジェクトの「消滅」 QCD目標を「適切」に設定するのが困難な理由① 予算制度の制約で、前年度に概算金額で申請せざるを得ない。 ある年度にシステムを開発しようとするならば、予算は前年度に（＝要件 定義の実施以前で）申請し、承認を得ておかなければならない。 前年度 大体X億でYヶ月 くらいかな・・・？ 構想策定段階 25 当年度 え！ そんなにかかるの か！？ 要件定義段階 QCD目標を「適切」に設定するのが困難な理由② 再掲 「QCD目標は適切に設定されている」とは言い切れない！ ではQCD基準「だけ」で評価することは適切なのか？ 戦略的IT投資に必須な「業務改革」がもたらす不確実性 業務改革を行った後にしか、利用部門は必要機能を定義できない。 改革された業務プロセスは未実施であり、それにITを活用しようとしても、 正しく運用され得るかどうか、うまくITが機能するかどうかは、不確実。 To Be （新業務プロセス） 業 務 改 革 As Is （現状の業務プロセス） 26 要件定義 業務要件 システム要件 • 想像の世界で業務要件やシステム要件を決めざるを 得ない。 • やってみないと分からない（不確実性の増大）。 • 新業務プロセスの「見える化」とステークホルダーの納 得感が無ければ要件定義ができない。 手作業の置換 業務要件 システム要件 ここまでの話の展開の整理（ストーリーの確認） トラブルが多い！ 成功率は30%と言われている！！ 問題意識① そもそもなぜQCD目標が達 成できないのか？ 問題意識② そもそも成功率が30%程度しかないプロ ジェクトへの投資は「適切な」経営判 断、意思決定と言えるのか？ •そもそもこの問いが成立しない。 •経営者の判断は今のところ「不明」だから。 「計画や目標設定」 の失敗（事前） •予算制度の制約 •業務改革による不確実性 27 「変化対応」の失敗 （途中・事後） •経営者の支援不足 •プロジェクトの「消滅」 ① 「なぜQCD目標が達成できないのか？」の分解 ケース1：「変化対応の失敗」 （QCD目標が適切に設定されていた場合） 適切な目標が設定されていたのであれば、それが達成できなかった のは好ましくないことである。 その原因究明と再発防止策が厳密に行なわれなければならない。 ケース2：「計画や目標設定の失敗」 （QCD目標が適切に設定されていなかった場合） その目標の達成度で結果を評価することこそが不適切である。 なぜ「目標を適切に設定することが難しいのか」こそが検討されねばならない。 28 Standish Groupの調査における失敗の原因（1994） なぜQCD目標が達成できないのか？ 【プロジェクトの不成功（タイプ2）要因・トップ10】 12.8% ユーザー部門の巻き込み不足 12.3% 要求と仕様が不明確 11.8% 要求と仕様の度重なる変更 7.5% 経営陣の支援不足 7.0% テクノロジーが不完全 6.4% リソースの不足 5.9% プロジェクトへの非現実的な期待 5.3% 不明確な目標 4.3% 非現実的なタイムフレーム 3.7% 新しいテクノロジー（への熟練不十分） 23.0% その他 29 【プロジェクトのキャンセル（タイプ3）要因・トップ10】 13.1% 不完全な要求 12.4% ユーザー部門の巻き込み不足 10.6% リソースの不足 9.9% プロジェクトへの非現実的な期待 9.3% 経営陣の支援不足 8.7% 要求と仕様の度重なる変更 8.1% 計画の欠如 7.5% 状況の変化で情報システムが不要に なった 6.2% ＩＴマネジメントの欠如 4.3% テクノロジーの未成熟 9.9% その他 The Standish Group “The CHAOS Report”（1994）： <http://www.standishgroup.com/sample_research/chaos_1994_1.php> Standish Groupの調査における失敗原因の因果関係 ユーザー部門の 巻き込み不足 人的能力 関連 リソースの不足 不完全な要求 要求と仕様 が不明確 要求と仕様の 度重なる変更 経営環境の変化 30 不明確な目標 計画の欠如 プロジェクトへの 非現実的な期待 非現実的なタ イムフレーム ユーザー代表のプロジェクト・メンバーに求められる能力 1. 現状の理解 現状の業務がどうなっているかを把握している。 2. 改革ビジョン 現状業務のどこに課題があり、どのように変更すべきかに関するビジョ ンを持っている。 自部門だけでなく、前後の工程や全社最適の視点から改革のポイントを 指摘できる。 3. リーダーシップとネゴシエーション 改革案を自部門に持ち帰り、賛同と支持を取り付けることができる。 これらの能力が伴っていないと？ 1. 誤った現状認識に基づく要件定義につながる。 2. 的外れ、または部分最適な要件定義が行なわれる。 3. 要件を確定できず、スケジュール遅延とコスト超過につながる。 現状でも多忙な現場のキーパーソンをアサインすることが必須。 31 Standish Groupの調査における失敗原因の因果関係 では、経営者が戦略目的を込めたプロジェクトが、なぜ「経営者の支援不足」で頓挫するのか？ 経営陣の支援不足 ユーザー部門の 巻き込み不足 人的能力 関連 リソースの不足 不明確な目標 要求と仕様 が不明確 経営環境の変化 テクノロジーの未成熟 テクノロジーが不完全 計画の欠如 戦略 関連 プロジェクトへの 非現実的な期待 状況の変化で情報シス テムが不要になった これは経営視点では失敗ではない 32 ＩＴマネジメントの欠如 新しいテクノロジー （への熟練不十分） 不完全な要求 要求と仕様の 度重なる変更 テクノロジー 関連 非現実的なタ イムフレーム パイロットと機関長のメタファー 「共通言語」が存在する パイロット 何！ それは大変だ！！ 機関長 機長！ エンジンが3基停止 しました！！ 33 「共通言語」が存在しない 経営者 それがどうか したのか・・・？ プロジェクト・マネジャー 社長！ 要件定義が終わりま せん！！ 誰の視点からプロジェクトの成否を評価するか？ 「有効である」＝「目的に合致している」ということ。「目的」が異なれば「期待す るもの」も異なり、「期待するもの」が異なれば「有効と判断する基準」も異なる。 利害関係者 一月三舟 財務的視点重視 経営者／管理者層 ユーザー部門 情報システム部門 情報 システム 34 IT投資と,P/L・B/Sレベルの財務的リ ターンとの因果関係 円滑な業務遂行と効率性 経営者 情報 ｼｽﾃﾑ 部門 有効性の評価基準（価値観） ﾕｰｻﾞｰ 部門 各自の担当する職務分掌によって要 求事項は異なるが,どんなITを用いて それを実現するかには通常無関心 円滑なプロジェクトの進捗 （QCD） 先進的技術の取込みやシステムの 高度化など この問題を放置すると、プロジェクトで の要件定義のトラブルに直結する。 「情報システム部門のお客様」とは誰か？ 数十年来の「常識」 「ユーザー部門を楽にするため」 だけに何億ものＩＴ投資をすること は適切な経営判断なのか？ •情報システム部門のお客様は「ユーザー部門」である。 •ユーザー部門の不便、非効率を解消することが情報システム部門の使命である。 大前提は「省力化」のためのシステム（業務改革を伴わない）。 これから求められるパラダイム（視座） •情報システム部門のお客様は「経営陣を含む全社員」である。 •「経営戦略の遂行を支援すること」こそが、これからの情報システム部門の使命。 大前提は「増力化」、「競争力の強化」によって、 「会社を強くする」システム。（社員は楽にならないかもしれない） それこそが「経営に貢献する」システム！ 35 「プロジェクトの失敗」と「プロジェクト・マネジメントの失敗」 プロジェクトとは・・・ 「独自の成果物またはサービスを創出する目的のために、異 なる組織のメンバーが集まり、決められた期間と、限られた予 算のもとで、計画的に実行される活動」 プロジェクト・マネジメントとは・・・ 「プロジェクトに与えられた目的を達成するために、人材・資 金・設備・物資・スケジュールなどをバランスよく調整し、全体 の進捗状況を管理する手法」 この管理指標としてQCDが主に使われてきた。 PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition, Project Management Institute Inc., 2008 （『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）第4版』PMI日本支部, 2008年）. 36 プロジェクトの「成功」と「失敗」の再定義 プロジェクトの成否 ← 高 → （ 経目 営的 者達 の成 視 点度 ） 低 「成功」の範囲 不満足な成功 純粋な失敗 満足な成功 形式的な成功要件を 満たした失敗 プロジェクト・マネジメントの成否 低← QCD目標達成度 →高 （プロジェクト・マネジャーの視点） 37 経営者とプロジェクト・マネジャーの判断基準の違い 経営者はQCD基準とは別の観点で意思決定を行なっており、かつ その基準に照らせば成功率は決して低くないのではないか？？ プロジェクト・マネジャーのスコープ 経営者のスコープ 構想立案・ 要求定義 移行支援・ ユーザー教育 QCD目標で評価 システム開発 プロジェクト 戦略課題の設定 （例・SCM） 業務改革 プロジェクトB 業務改革 プロジェクトA 時間の経過 38 当面の ビジネス ゴール SCM推進プログラム の範囲（継続する） 経営者の判断は「ダブルループ学習」方式？ シングルループ学習 一旦設定したQCD目標は変更せずに、その目標達成を目指す、 「プロジェクト・マネジャーの視点」・・・成功率は低い ただし目標の安易な下方修正では困ります！ ダブルループ学習 一旦設定したQCD目標をも随時見直すことでプロジェクトへの支援を継続し、自ら の戦略目的の達成を追求する「経営者の視点」・・・成功率は低くない？ ダブルループ学習 シングルループ学習 目標 Governing Variables 39 行動 Action Strategies 結果 Consequences Argyris, C., “Double Loop Learning in Organizations”, Harvard Business Review, Sep-Oct, 1977 （DIAMONDハーバード・ビジネス・レビュー編集部訳『組織能力の経営論-学び続ける企業のベ ストプラクティス』ダイヤモンド社, 2007年, 85-124頁）. エンド・ツー・エンドの時間軸におけるプロジェクト評価 「目的達成度」がある値以上 のものが「成功」 超上流工程 目的 経営戦略～ビジネスケース 結果 目的達成度 成果検証 ビジネス要件定義～業務要件定義 ユーザー受入テスト 契約行為 システム要件定義 プロジェクト・ライフサイクル 上流工程 下流工程 運用テスト QCD基準 システム設計 保守 システム・テスト 運用 ソフトウェア設計 中流工程 40 ソフトウェア・テスト プログラミング プロジェクトには「大義名分」が必要です！ 中期経営計画書の重点施策 社長の年頭所感のキーメッセージ 事業部長を眠れないほど悩ませている課題・・・などなど 控えおろう～！！ 41 次のようなプロジェクトは成功？失敗？（解答例) ④コストは2倍、スケジュールは 1年遅れ・・・でも本来のプロ ジェクトの目的は達成され、 システムは順調に稼動中。 「成功」の範囲 高 ← → （ 経目 営的 者達 の成 視 点度 ） 低 ①コストが計画よりも1円オーバーした。 ②本番稼動が計画よりも1日遅れた。 不満足な成功 純粋な失敗 満足な成功 形式的な成功要件を 満たした失敗 低← QCD目標達成度 →高 （プロジェクト・マネジャーの視点） 42 ③ITベンダーは情報システム部門からの仕様書の通り・・・ QCD100点で納入したが、・・・実務には使われなかった。 経営者の視点とプロジェクト・マネジャーの視点（まとめ） 目的達成度もQCD目標達成度も高い 「満足な成功」を是非とも目指しましょう！ 成否の判断基準 経営者の視点 （戦略マネジメント） プロジェクト・マネジャーの視点 （プロジェクト・マネジメント） 43 戦略目的の達成度 （QCD目標は見直し の対象となり得る） 判断のタイミング 戦略目的が達成された タイミング スコープと サービス・イン QCD目標の達成度 （本番稼動）の （QCD目標は固定） タイミング Agenda 1 プロジェクトの成功・失敗とは何か？ 2 プロジェクトを成功に導く経営者の支援行動 3 経営者の支援行動をより確実に実現するために 44 先行研究① 分析フレームワークの構築（経営者の役割と責任） 企業経営における業績管理の意義 （実績の集計と評価、経営成果の分析） 過去 経営環境の不確実性への対応 （ダブルループ学習、リスク・マネジメント） 現在 未来 経営管理サイクルに基づく戦略の策定と遂行 （バランスト・スコアカードに基づくPDCAサイクル） ①業績管理情報に基づき、適切な意思決定を行なうよう努めること。 （過去～現在） ②戦略を適切に策定し、確実に実施すること。その前提として 無形の資産のレディネス向上に継続的に取り組むこと。 （過去～現在～未来） 45 ③ダブルループ学習の視点に立ち、不確実な事態に適切に対処すること。 （現在～未来） プロジェクトの成否に影響を及ぼした経営者の行動 計画化 （Planning） 「計画化 （Planning）」 関連 「組織化 （Organizing）」 関連 組織化 （Organizing） 指揮 （Leading） 統制 （Controlling） P1：情報システム導入の可否を判断、承認 P2：QCD目標を決定し、周知徹底 P3：戦略目的を決定し、周知徹底 O1：プロジェクト遂行に必要なメンバーを質・量の両面で確保 O2：プロジェクトに必要な人材の計画的育成と、レディネスの向上 L1：ステークホルダーのモチベーションへの配慮・高揚 「指揮 （Leading）」 関連 L2：経営者とプロジェクト・メンバーの共通言語と効果的なコミュニケーショ ンの確立 L3：効果的なコミュニケーションのために、自ら積極的に学習 L4：諸々の局面でリーダーシップを発揮 「統制 C1：プロジェクトの戦略目的達成を優先し、不確実な事態に適切に対処し （Controlling）」 ながら柔軟にQCD目標の修正を受け容れ、あるいは戦略目的に基づい 関連 て要件を圧縮 46 事例企業の概要 47 IT経営達成 度（＊） ERP 基幹システムのグローバル展開 ステージ4 ○ 流通業 物流システム ステージ4 C社 製造業 物流システム ステージ4 D社 製造業 基幹システム再構築 ステージ4 E社 製造業 基幹システム再構築 ステージ3 F社 製造業 生産管理＆PDMシステム ステージ3 G社 サービス業 新エントリーシステム ステージ3 H社 製造業 生産管理システム ステージ3 I社 流通業 物流システム ステージ3 J社 流通業 基幹システム再構築 ステージ3 ユーザー 業種 A社 製造業 B社 プロジェクト概要 ○ ○ ＊ IT経営達成度とは「IT経営ロードマップ」における4つのステージを示す。 事例企業の成否の分布 経営者とプロジェクト・マネジャーの評価結果は やはり異なっていた！ 不満足な成功 高 満足な成功 F社 A社 B社 G社 H社 C社 D社 ← E社 目的達成度基準では成功率は 8/10 I社 J社 → （ 経目 営的 者達 の成 視 点度 ） 低 QCD基準では成功率は 4/10 形式的な成功要件を 純粋な失敗 満たした失敗 低← QCD目標達成度 →高 （プロジェクト・マネジャーの視点） 48 プロジェクトの成否と経営者の行動の相関関係 プロジェクトの成否に影響なし（行なわれていて当然） プロジェクトの成否に強い相関関係あり 49 ユー ザー QCD 基準 目的達成 度基準 P1 P2 P3 O1 O2 L1 L2 L3 L4 C1 A社 達成 達成 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ B社 達成 達成 ○ ○ ○ △→ ○ △ ○ ○ △ ○ ○ C社 達成 達成 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ D社 達成 達成 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ E社 未達成 達成 ○ △ ○ ○ △ ○ ○ △ ○ ○ F社 未達成 達成 ○ △ ○ ○ ○ ○ ○ ○ ○ ○ G社 未達成 達成 ○ ×→ △ ×→ ○ ×→ ○ × △ ×→ ○ △ ○ △ H社 未達成 達成 ○ ×→ △ ×→ ○ ×→ ○ × ×→ ○ ×→ ○ △ ×→ ○ △ I社 未達成 未達成 ○ △ × × × × × × × × J社 未達成 未達成 ○→ × △ × △ △ × × × × △ 「計画化（Planning）」に該当する経営者の行動と得られた知見 計画化 （Planning） P1：情報システ ム導入の可否 を判断、承認 成功に導いた行動 失敗に導いた行動 事例企業の大半が予算制度が確立されている上場企業であり、役員会承認は全件で当 然の如く実施。ただし形式的なものでは成功は保証されないことも判明。 （A社）社長が要件膨張に対して、 P2：QCD目標 を決定し、周知 徹底 プロジェクト目的の達成に必須か 否かの観点から自らレビューし、 アドオン要求の多くを却下。 （E社）常務がQとCではITベンダー に遵守を求め、Dでは妥協、といっ た強弱をつけたネゴシエーション を、経営会議の承認の下に実施。 （C社）物流改革に伴い、営業所か ら在庫がなくなることへの心理的 （J社）プロジェクトがシステム部門主導で開始さ 抵抗に対して、経営陣が確固たる れ、戦略に立脚した戦略目的は明確に示されず 業務改革ビジョンを示し続けること P3：戦略目的を 。システム部門の設定した目標も未達成である で、現場を説得。 が、戦略目的の達成度は更に曖昧。 決定し、周知徹 （D社）原価や販売計画などの情 （I社）事業継続のために必要なシステムを開発 底 報の即日入力を労働強化だとす するという観点では、機能的な目的は達成。し る現場の抵抗を、社長自らがその かし経営陣はその投資効果を全く評価せず。 重要性を業務面と経営面から繰り 返し説明、説得。 50 「計画化（Planning）」に該当する経営者の行動と得られた知見 計画化 （Planning） P1：情報システ ム導入の可否 を判断、承認 P2：QCD目標 を決定し、周知 徹底 成功に導いた行動 失敗に導いた行動 事例企業の大半が予算制度が確立されている上場企業であり、役員会承認は全件で当 ・事例企業の大半が予算制度が確立されている上場企業 然の如く実施。ただし形式的なものでは成功は保証されないことも判明。 であり、役員会承認は全件で当然の如く実施。 （A社）社長が要件膨張に対して、 ・ただし形式的なものでは成功は保証されないことも判明。 プロジェクト目的の達成に必須か 否かの観点から自らレビューし、 アドオン要求の多くを却下。 （E社）常務がQとCではITベンダー に遵守を求め、Dでは妥協、といっ た強弱をつけたネゴシエーション を、経営会議の承認の下に実施。 （C社）物流改革に伴い、営業所か ら在庫がなくなることへの心理的 （J社）プロジェクトがシステム部門主導で開始さ 抵抗に対して、経営陣が確固たる れ、戦略に立脚した戦略目的は明確に示されず 業務改革ビジョンを示し続けること P3：戦略目的を 。システム部門の設定した目標も未達成である で、現場を説得。 が、戦略目的の達成度は更に曖昧。 決定し、周知徹 （D社）原価や販売計画などの情 （I社）事業継続のために必要なシステムを開発 底 報の即日入力を労働強化だとす するという観点では、機能的な目的は達成。し る現場の抵抗を、社長自らがその かし経営陣はその投資効果を全く評価せず。 重要性を業務面と経営面から繰り 返し説明、説得。 51 「計画化（Planning）」に該当する経営者の行動と得られた知見 計画化 （Planning） P1：情報システ ム導入の可否 を判断、承認 成功に導いた行動 失敗に導いた行動 事例企業の大半が予算制度が確立されている上場企業であり、役員会承認は全件で当 然の如く実施。ただし形式的なものでは成功は保証されないことも判明。 ・（A社）社長が要件膨張に対して、プロジェクト目的の 達成に必須か否かの観点から自らレビューし、アドオ プロジェクト目的の達成に必須か ン要求の多くを却下。 否かの観点から自らレビューし、 アドオン要求の多くを却下。 ・ （E社）常務がQとCではITベンダーに遵守を求め、Dで （E社）常務がQとCではITベンダー に遵守を求め、Dでは妥協、といっ は妥協、といった強弱をつけたネゴシエーションを、経 た強弱をつけたネゴシエーション 営会議の承認の下に実施。 を、経営会議の承認の下に実施。 （A社）社長が要件膨張に対して、 P2：QCD目標 を決定し、周知 徹底 （C社）物流改革に伴い、営業所か ら在庫がなくなることへの心理的 （J社）プロジェクトがシステム部門主導で開始さ 抵抗に対して、経営陣が確固たる れ、戦略に立脚した戦略目的は明確に示されず 業務改革ビジョンを示し続けること P3：戦略目的を 。システム部門の設定した目標も未達成である で、現場を説得。 が、戦略目的の達成度は更に曖昧。 決定し、周知徹 （D社）原価や販売計画などの情 （I社）事業継続のために必要なシステムを開発 底 報の即日入力を労働強化だとす するという観点では、機能的な目的は達成。し る現場の抵抗を、社長自らがその かし経営陣はその投資効果を全く評価せず。 重要性を業務面と経営面から繰り 返し説明、説得。 52 「計画化（Planning）」に該当する経営者の行動と得られた知見 計画化 （Planning） P1：情報システ ム導入の可否 を判断、承認 P2：QCD目標 を決定し、周知 徹底 成功に導いた行動 失敗に導いた行動 事例企業の大半が予算制度が確立されている上場企業であり、役員会承認は全件で当 ・ （C社）物流改革に伴い、営業所から在庫がなくなるこ 然の如く実施。ただし形式的なものでは成功は保証されないことも判明。 とへの心理的抵抗に対して、経営陣が確固たる業務 （A社）社長が要件膨張に対して、 改革ビジョンを示し続けることで、現場を説得。 プロジェクト目的の達成に必須か ・ （D社）原価や販売計画などの情報の即日入力を労働 否かの観点から自らレビューし、 強化だとする現場の抵抗を、社長自らがその重要性を アドオン要求の多くを却下。 （E社）常務がQとCではITベンダー 業務面と経営面から繰り返し説明、説得。 に遵守を求め、Dでは妥協、といっ た強弱をつけたネゴシエーション を、経営会議の承認の下に実施。 ・（J社）プロジェクトがシステム部門主導で開始され、 戦略に立脚した戦略目的は明確に示されず。システ ム部門の設定した目標も未達成であるが、戦略目的 の達成度は更に曖昧。 （I社）事業継続のために必要なシステムを開発すると いう観点では、機能的な目的は達成。しかし経営陣は その投資効果を全く評価せず。 （C社）物流改革に伴い、営業所か ら在庫がなくなることへの心理的 （J社）プロジェクトがシステム部門主導で開始さ 抵抗に対して、経営陣が確固たる れ、戦略に立脚した戦略目的は明確に示されず 業務改革ビジョンを示し続けること P3：戦略目的を 。システム部門の設定した目標も未達成である で、現場を説得。 ・ が、戦略目的の達成度は更に曖昧。 決定し、周知徹 （D社）原価や販売計画などの情 （I社）事業継続のために必要なシステムを開発 底 報の即日入力を労働強化だとす するという観点では、機能的な目的は達成。し る現場の抵抗を、社長自らがその かし経営陣はその投資効果を全く評価せず。 重要性を業務面と経営面から繰り 返し説明、説得。 53 「組織化（Organizing）」に該当する経営者の行動と得られた知見 「組織化 （Organizing）」 関連 成功に導いた行動 失敗に導いた行動 (B社)開始直後にプロジェクト・マネ O1：プロジェ クト遂行に必 要なメンバー を質・量の両 面で確保 ジャーを変更。初代は要件定義フェー ズの業務プロセスの変更への現場の反 発に適切に対応できず、立ち往生。後 任は初代の教訓を活かし、迅速な意思 決定や審議事項への承認、プロジェク ト・メンバーへの動機付け、自身が矢面 に立つトラブル対応の3つを堅持。 (H社)当初、プロジェクト・マネジャーの 独善的な仕事の進め方によってプロ ジェクトが混乱。その原因を経営陣が 喝破し、V取締役を後見役としてアサイ ンしたことによってプロジェクトが正常化。 （I社）経営陣にプロジェクトの実務知識を持 O2：プロジェ （A社）ロジェクト・メンバーに各部門の エースを専属で投入。その際に人材を クトに必要な 引き抜かれる現場からの抵抗を社長が、 人材の計画的 「エースの抜けた穴を次のエースを育 育成と、レディ 成して埋めることこそ管理職の責任」、 ネスの向上 との論理で説得。 54 つ役員が不在で、経営陣としての対処が必 要という認識が皆無。人材不足は明らかで あったが、そのような状況でプロジェクトを開 始することのリスクも経営陣に十分理解され ていなかった。平素からの地道な人材育成 、あるいはそれが困難な場合には社外に適 切なパートナーを確保するなどの対策がま ず必要である。 「組織化（Organizing）」に該当する経営者の行動と得られた知見 「組織化 （Organizing）」 関連 成功に導いた行動 失敗に導いた行動 (B社)開始直後にプロジェクト・マネ ジャーを変更。初代は要件定義フェー (B社)開始直後にプロジェクト・マネジャーを変更。初代 O1：プロジェ クト遂行に必 要なメンバー を質・量の両 面で確保 O2：プロジェ クトに必要な 人材の計画的 育成と、レディ ネスの向上 55 ズの業務プロセスの変更への現場の反 は要件定義フェーズの業務プロセスの変更への現場 発に適切に対応できず、立ち往生。後 任は初代の教訓を活かし、迅速な意思 の反発に適切に対応できず、立ち往生。後任は初代 決定や審議事項への承認、プロジェク の教訓を活かし、迅速な意思決定や審議事項への承 ト・メンバーへの動機付け、自身が矢面 に立つトラブル対応の3つを堅持。 認、プロジェクト・メンバーへの動機付け、自身が矢面 (H社)当初、プロジェクト・マネジャーの 独善的な仕事の進め方によってプロ に立つトラブル対応の3つを堅持。 ジェクトが混乱。その原因を経営陣が (H社)当初、プロジェクト・マネジャーの独善的な仕事 喝破し、V取締役を後見役としてアサイ ンしたことによってプロジェクトが正常化。 の進め方によってプロジェクトが混乱。その原因を経 （I社）経営陣にプロジェクトの実務知識を持 営陣が喝破し、V取締役を後見役としてアサインしたこ つ役員が不在で、経営陣としての対処が必 とによってプロジェクトが正常化。 （A社）ロジェクト・メンバーに各部門の 要という認識が皆無。人材不足は明らかで エースを専属で投入。その際に人材を 引き抜かれる現場からの抵抗を社長が、 「エースの抜けた穴を次のエースを育 成して埋めることこそ管理職の責任」、 との論理で説得。 あったが、そのような状況でプロジェクトを開 始することのリスクも経営陣に十分理解され ていなかった。平素からの地道な人材育成 、あるいはそれが困難な場合には社外に適 切なパートナーを確保するなどの対策がま ず必要である。 「組織化（Organizing）」に該当する経営者の行動と得られた知見 「組織化 （Organizing）」 関連 成功に導いた行動 失敗に導いた行動 (B社)開始直後にプロジェクト・マネ O1：プロジェ クト遂行に必 要なメンバー を質・量の両 面で確保 ジャーを変更。初代は要件定義フェー ズの業務プロセスの変更への現場の反 発に適切に対応できず、立ち往生。後 任は初代の教訓を活かし、迅速な意思 決定や審議事項への承認、プロジェク ト・メンバーへの動機付け、自身が矢面 （A社）プロジェクト・メンバーに各部門のエースを専属 に立つトラブル対応の3つを堅持。 で投入。その際に人材を引き抜かれる現場からの抵 (H社)当初、プロジェクト・マネジャーの 独善的な仕事の進め方によってプロ 抗を社長が、「エースの抜けた穴を次のエースを育成 ジェクトが混乱。その原因を経営陣が して埋めることこそ管理職の責任」、との論理で説得。 喝破し、V取締役を後見役としてアサイ ンしたことによってプロジェクトが正常化。 ・（I社）経営陣にプロジェクトの実務知識を持つ役員が （I社）経営陣にプロジェクトの実務知識を持 O2：プロジェ クトに必要な 人材の計画的 育成と、レディ ネスの向上 56 つ役員が不在で、経営陣としての対処が必 不在で、経営陣としての対処が必要という認識が皆無。 （A社）ロジェクト・メンバーに各部門の 要という認識が皆無。人材不足は明らかで エースを専属で投入。その際に人材を 人材不足は明らかであったが、そのような状況でプロ あったが、そのような状況でプロジェクトを開 引き抜かれる現場からの抵抗を社長が、 始することのリスクも経営陣に十分理解され 「エースの抜けた穴を次のエースを育 ジェクトを開始することのリスクも経営陣に十分理解さ ていなかった。平素からの地道な人材育成 成して埋めることこそ管理職の責任」、 との論理で説得。 、あるいはそれが困難な場合には社外に適 れていなかった。平素からの地道な人材育成、あるい 切なパートナーを確保するなどの対策がま はそれが困難な場合には社外に適切なパートナーを ず必要である。 確保するなどの対策がまず必要である。 「指揮（Leading） 」に該当する経営者の行動と得られた知見 指揮 （Leading） L1：ステーク ホルダーのモ チベーションへ の配慮・高揚 L2：経営者と プロジェクト・メ ンバーの共通 言語と効果的 なコミュニケー ションの確立 L3：効果的な コミュニケーシ ョンのために、 自ら積極的に 学習 L4：諸々の局 面でリーダー シップを発揮 57 成功に導いた行動 失敗に導いた行動 （A社）社長は選任した個々のプロジェ （J社）親会社はO社製ERPパッケージを導 クト・メンバーに対して、人選の背景や 想いなどを繰り返し説き、動機付けを 行なった。 （G社）経営陣が一貫したメッセージで プロジェクトの支援を続け、経営の立 場から物流改革に対する不退転の意 志を現場に伝え続けた。 入済みであり、親会社にはグループ全体を それで統一したいという意向があった。J社 の検討チームはO社製ERPの自社への適合 性に懸念を表明し、代替案も上申したが、結 果的に押し切られた。これ以降、J社には検 討作業の無力感と親会社への不満がくすぶ る結果となった。 （F社）プロジェクト・チームと経営陣の 間で「技術重視の社風」が共通言語と して機能し、その重要性が全社的に共 有されていた。それを受けて問題発生 時に専門のスタッフの追加投入が即 刻承認された。 （A社）社長が自らの情報システム構 築に関する知識不足を補うため、同業 他社を訪問し、成功の勘所を学習。 （D社）社長自らステアリング・コミッ ティーやプロジェクト会議に参加し、要 件の取捨選択やQCD目標の維持に強 力なリーダーシップを発揮した。 （A社）新システムの稼動直後に寄せ られた、操作性に関するユーザー部 門の多数の苦情に対して社長がプロ ジェクト・メンバーを擁護し、パッケージ の画面・帳票をそのまま使わせた。 （J社）プロジェクト開始後6ヶ月目に、社長を 含む複数の経営陣が交代。要件の膨張に 直面していた旧経営陣は一旦プロジェクトを 凍結し、新経営陣に善後策を委ねたが、既 に規定路線として変更できない事柄も多く、 十分な成果を得ることはできなかった。 失敗事例のすべてにおいて、経営陣がプロ ジェクトに無理解・無関心な態度をとるなど、 リーダーシップは総じて観察されなかった。 「指揮（Leading） 」に該当する経営者の行動と得られた知見 指揮 （Leading） 成功に導いた行動 失敗に導いた行動 （A社）社長は選任した個々のプロジェ （J社）親会社はO社製ERPパッケージを導 クト・メンバーに対して、人選の背景や （A社）社長は選任した個々のプロジェクト・メンバーに 入済みであり、親会社にはグループ全体を それで統一したいという意向があった。J社 対して、人選の背景や想いなどを繰り返し説き、動機 の検討チームはO社製ERPの自社への適合 性に懸念を表明し、代替案も上申したが、結 付けを行なった。 果的に押し切られた。これ以降、J社には検 （G社）経営陣が一貫したメッセージでプロジェクトの支 討作業の無力感と親会社への不満がくすぶ る結果となった。 援を続け、経営の立場から物流改革に対する不退転 （F社）プロジェクト・チームと経営陣の の意志を現場に伝え続けた。 間で「技術重視の社風」が共通言語と L1：ステーク ホルダーのモ チベーションへ の配慮・高揚 想いなどを繰り返し説き、動機付けを 行なった。 （G社）経営陣が一貫したメッセージで プロジェクトの支援を続け、経営の立 場から物流改革に対する不退転の意 志を現場に伝え続けた。 L2：経営者と プロジェクト・メ ンバーの共通 言語と効果的 なコミュニケー ションの確立 L3：効果的な コミュニケーシ ョンのために、 自ら積極的に 学習 L4：諸々の局 面でリーダー シップを発揮 58 して機能し、その重要性が全社的に共 有されていた。それを受けて問題発生 ・ 時に専門のスタッフの追加投入が即 刻承認された。 （A社）社長が自らの情報システム構 築に関する知識不足を補うため、同業 他社を訪問し、成功の勘所を学習。 （D社）社長自らステアリング・コミッ ティーやプロジェクト会議に参加し、要 件の取捨選択やQCD目標の維持に強 力なリーダーシップを発揮した。 （A社）新システムの稼動直後に寄せ られた、操作性に関するユーザー部 門の多数の苦情に対して社長がプロ ジェクト・メンバーを擁護し、パッケージ の画面・帳票をそのまま使わせた。 （J社）親会社はO社製ERPパッケージを導入済みであ り、親会社にはグループ全体をそれで統一したいとい う意向があった。J社の検討チームはO社製ERPの自 （J社）プロジェクト開始後6ヶ月目に、社長を 含む複数の経営陣が交代。要件の膨張に 社への適合性に懸念を表明し、代替案も上申したが、 直面していた旧経営陣は一旦プロジェクトを 凍結し、新経営陣に善後策を委ねたが、既 結果的に押し切られた。これ以降、J社には検討作業 に規定路線として変更できない事柄も多く、 十分な成果を得ることはできなかった。 の無力感と親会社への不満がくすぶる結果となった。 失敗事例のすべてにおいて、経営陣がプロ ジェクトに無理解・無関心な態度をとるなど、 リーダーシップは総じて観察されなかった。 「指揮（Leading） 」に該当する経営者の行動と得られた知見 指揮 （Leading） L1：ステーク ホルダーのモ チベーションへ の配慮・高揚 L2：経営者と プロジェクト・メ ンバーの共通 言語と効果的 なコミュニケー ションの確立 L3：効果的な コミュニケーシ ョンのために、 自ら積極的に 学習 L4：諸々の局 面でリーダー シップを発揮 59 成功に導いた行動 失敗に導いた行動 （A社）社長は選任した個々のプロジェ （J社）親会社はO社製ERPパッケージを導 クト・メンバーに対して、人選の背景や 想いなどを繰り返し説き、動機付けを 行なった。 （G社）経営陣が一貫したメッセージで プロジェクトの支援を続け、経営の立 場から物流改革に対する不退転の意 志を現場に伝え続けた。 入済みであり、親会社にはグループ全体を それで統一したいという意向があった。J社 の検討チームはO社製ERPの自社への適合 性に懸念を表明し、代替案も上申したが、結 果的に押し切られた。これ以降、J社には検 討作業の無力感と親会社への不満がくすぶ る結果となった。 （F社）プロジェクト・チームと経営陣の 間で「技術重視の社風」が共通言語と （F社）プロジェクト・チームと経営陣の間で「技術重視 の社風」が共通言語として機能し、その重要性が全社 的に共有されていた。それを受けて問題発生時に専 門のスタッフの追加投入が即刻承認された。 して機能し、その重要性が全社的に共 有されていた。それを受けて問題発生 時に専門のスタッフの追加投入が即 刻承認された。 （A社）社長が自らの情報システム構 築に関する知識不足を補うため、同業 他社を訪問し、成功の勘所を学習。 （D社）社長自らステアリング・コミッ ティーやプロジェクト会議に参加し、要 件の取捨選択やQCD目標の維持に強 力なリーダーシップを発揮した。 （A社）新システムの稼動直後に寄せ られた、操作性に関するユーザー部 門の多数の苦情に対して社長がプロ ジェクト・メンバーを擁護し、パッケージ の画面・帳票をそのまま使わせた。 （J社）プロジェクト開始後6ヶ月目に、社長を 含む複数の経営陣が交代。要件の膨張に 直面していた旧経営陣は一旦プロジェクトを 凍結し、新経営陣に善後策を委ねたが、既 に規定路線として変更できない事柄も多く、 十分な成果を得ることはできなかった。 失敗事例のすべてにおいて、経営陣がプロ ジェクトに無理解・無関心な態度をとるなど、 リーダーシップは総じて観察されなかった。 「指揮（Leading） 」に該当する経営者の行動と得られた知見 指揮 （Leading） L1：ステーク ホルダーのモ チベーションへ の配慮・高揚 L2：経営者と プロジェクト・メ ンバーの共通 言語と効果的 なコミュニケー ションの確立 L3：効果的な コミュニケーシ ョンのために、 自ら積極的に 学習 L4：諸々の局 面でリーダー シップを発揮 60 成功に導いた行動 失敗に導いた行動 （A社）社長は選任した個々のプロジェ （J社）親会社はO社製ERPパッケージを導 クト・メンバーに対して、人選の背景や 想いなどを繰り返し説き、動機付けを 行なった。 （G社）経営陣が一貫したメッセージで プロジェクトの支援を続け、経営の立 場から物流改革に対する不退転の意 志を現場に伝え続けた。 入済みであり、親会社にはグループ全体を それで統一したいという意向があった。J社 の検討チームはO社製ERPの自社への適合 性に懸念を表明し、代替案も上申したが、結 果的に押し切られた。これ以降、J社には検 討作業の無力感と親会社への不満がくすぶ る結果となった。 （A社）社長が自らの情報システム構築に関する知識 不足を補うため、同業他社を訪問し、成功の勘所を学 習。 （F社）プロジェクト・チームと経営陣の 間で「技術重視の社風」が共通言語と （D社）社長自らステアリング・コミッティーやプロジェク ト会議に参加し、要件の取捨選択やQCD目標の維持 して機能し、その重要性が全社的に共 有されていた。それを受けて問題発生 に強力なリーダーシップを発揮した。 時に専門のスタッフの追加投入が即 刻承認された。 （J社）プロジェクト開始後6ヶ月目に、社長を含む複数 （A社）社長が自らの情報システム構 築に関する知識不足を補うため、同業 （J社）プロジェクト開始後6ヶ月目に、社長を 含む複数の経営陣が交代。要件の膨張に の経営陣が交代。要件の膨張に直面していた旧経営 他社を訪問し、成功の勘所を学習。 直面していた旧経営陣は一旦プロジェクトを （D社）社長自らステアリング・コミッ 陣は一旦プロジェクトを凍結し、新経営陣に善後策を 凍結し、新経営陣に善後策を委ねたが、既 ティーやプロジェクト会議に参加し、要 に規定路線として変更できない事柄も多く、 委ねたが、既に規定路線として変更できない事柄も多 件の取捨選択やQCD目標の維持に強 十分な成果を得ることはできなかった。 力なリーダーシップを発揮した。 く、十分な成果を得ることはできなかった。 （A社）新システムの稼動直後に寄せ 失敗事例のすべてにおいて、経営陣がプロ られた、操作性に関するユーザー部 門の多数の苦情に対して社長がプロ ジェクトに無理解・無関心な態度をとるなど、 リーダーシップは総じて観察されなかった。 ジェクト・メンバーを擁護し、パッケージ の画面・帳票をそのまま使わせた。 「指揮（Leading） 」に該当する経営者の行動と得られた知見 指揮 （Leading） L1：ステーク ホルダーのモ チベーションへ の配慮・高揚 L2：経営者と プロジェクト・メ ンバーの共通 言語と効果的 なコミュニケー ションの確立 L3：効果的な コミュニケーシ ョンのために、 自ら積極的に 学習 L4：諸々の局 面でリーダー シップを発揮 61 成功に導いた行動 失敗に導いた行動 （A社）社長は選任した個々のプロジェ （J社）親会社はO社製ERPパッケージを導 クト・メンバーに対して、人選の背景や 想いなどを繰り返し説き、動機付けを 行なった。 （G社）経営陣が一貫したメッセージで プロジェクトの支援を続け、経営の立 場から物流改革に対する不退転の意 志を現場に伝え続けた。 入済みであり、親会社にはグループ全体を それで統一したいという意向があった。J社 の検討チームはO社製ERPの自社への適合 性に懸念を表明し、代替案も上申したが、結 果的に押し切られた。これ以降、J社には検 討作業の無力感と親会社への不満がくすぶ る結果となった。 （F社）プロジェクト・チームと経営陣の 間で「技術重視の社風」が共通言語と して機能し、その重要性が全社的に共 有されていた。それを受けて問題発生 時に専門のスタッフの追加投入が即 刻承認された。 （A社）社長が自らの情報システム構 築に関する知識不足を補うため、同業 他社を訪問し、成功の勘所を学習。 （D社）社長自らステアリング・コミッ ティーやプロジェクト会議に参加し、要 件の取捨選択やQCD目標の維持に強 力なリーダーシップを発揮した。 （A社）新システムの稼動直後に寄せ られた、操作性に関するユーザー部 門の多数の苦情に対して社長がプロ ジェクト・メンバーを擁護し、パッケージ の画面・帳票をそのまま使わせた。 （J社）プロジェクト開始後6ヶ月目に、社長を （A社）新システムの稼動直後に寄せられた、操作性に 含む複数の経営陣が交代。要件の膨張に 関するユーザー部門の多数の苦情に対して社長がプ 直面していた旧経営陣は一旦プロジェクトを 凍結し、新経営陣に善後策を委ねたが、既 ロジェクト・メンバーを擁護し、パッケージの画面・帳票 に規定路線として変更できない事柄も多く、 十分な成果を得ることはできなかった。 をそのまま使わせた。 失敗事例のすべてにおいて、経営陣がプロジェクトに 失敗事例のすべてにおいて、経営陣がプロ ジェクトに無理解・無関心な態度をとるなど、 無理解・無関心な態度をとるなど、リーダーシップは総 リーダーシップは総じて観察されなかった。 じて観察されなかった。 「統制（Controlling） 」に該当する経営者の行動と得られた知見 統制 （Controlling） 成功に導いた行動 失敗に導いた行動 （D社）社長が毎週のプロジェクト会議 C1：プロジェ に参加し、自らERPパッケージへのア クトの戦略目的 ドオン要求の必要性を精査。アドオン 達成を優先し、 を大幅に絞り込むことに成功し、スケ 不確実な事態 失敗事例では、一旦設定したQCD目標の変 ジュールとコスト目標も達成。 に適切に対処 更を経営陣が拒絶したこと、およびQCD目 （E社）プロジェクト・マネジャーが合意 標を維持するためのスコープや対象業務の しながら柔軟に 形成の場としてステアリング・コミッティ 絞込みにも一切経営陣が協力しなかったこ QCD目標の修 ーを有効活用。経営陣とは月1回、IT とが共通している。 正を受け容れ、 ベンダーとは週1回のプロジェクト会議 あるいは戦略 を基本とし、追加のテーマについては 目的に基づい 都度非公式な意見交換の場を高い頻 て要件を圧縮 度で設定し、意思決定を行なった。 62 「統制（Controlling） 」に該当する経営者の行動と得られた知見 統制 （Controlling） 成功に導いた行動 失敗に導いた行動 （D社）社長が毎週のプロジェクト会議 C1：プロジェ に参加し、自らERPパッケージへのア （D社）社長が毎週のプロジェクト会議に参加し、自ら クトの戦略目的 ドオン要求の必要性を精査。アドオン 達成を優先し、 ERPパッケージへのアドオン要求の必要性を精査。ア を大幅に絞り込むことに成功し、スケ 不確実な事態 失敗事例では、一旦設定したQCD目標の変 ドオンを大幅に絞り込むことに成功し、スケジュールと ジュールとコスト目標も達成。 に適切に対処 更を経営陣が拒絶したこと、およびQCD目 （E社）プロジェクト・マネジャーが合意 標を維持するためのスコープや対象業務の しながら柔軟に コスト目標も達成。 形成の場としてステアリング・コミッティ 絞込みにも一切経営陣が協力しなかったこ QCD目標の修 とが共通している。 ーを有効活用。経営陣とは月1回、IT （E社）プロジェクト・マネジャーが合意形成の場として 正を受け容れ、 ベンダーとは週1回のプロジェクト会議 あるいは戦略 ステアリング・コミッティーを有効活用。経営陣とは月1 を基本とし、追加のテーマについては 目的に基づい 都度非公式な意見交換の場を高い頻 回、ITベンダーとは週1回のプロジェクト会議を基本と て要件を圧縮 度で設定し、意思決定を行なった。 し、追加のテーマについては都度非公式な意見交換 の場を高い頻度で設定し、意思決定を行なった。 失敗事例では、一旦設定したQCD目標の変更を経営 陣が拒絶したこと、およびQCD目標を維持するための スコープや対象業務の絞込みにも一切経営陣が協力 しなかったことが共通している。 63 マネジメント・コントロール層に「共通言語」が必要です！ 経 営 感 覚 の あ る 経営戦略 PM 64 戦略的計画 業績管理 が 戦 略 ま で を カ バ ー プロジェクト管理 • 経営用語 マネジメント・コントロール • 管理会計用語 プロジェクト A プロジェクト B 経 営 者 が プ ロ ジ ェ ク ト 実 務 を 学 習 オペレーショナル・コントロール プロジェクト C • 情報システム用語 • プロジェクト・マネジメント用語 Anthony, R.N., Planning and Control Systems – A Framework for Analysis （高橋吉之助訳『経営管理システムの基礎』 1965） 戦略を可視化できる手段が必要です SCN : Strategy Capability Network 顧客価値 提供価値 （効果） 成果指標 株主価値 プログラム：営業改革 （効果目標） 顧客提供価値の増大 利益向上 SCN （ｽﾄﾗﾃｼﾞｰ・ｹｰﾊﾟﾋﾞﾘﾃｨ・ﾈｯﾄﾜｰｸ）・・・提供価値、ケーパビリティーに対してそ 効果KGI:営業経費 の達成度を測るための評価指標（KPI)を設定し、効果と実現手段の因果関係を お客様の業務効率化 お客様の個別要求仕 売上増 に貢献 様への迅速な対応 コスト削減 明確化 ケーパビリティー （実現能力） 効果KPI:商談成約率 お客様のニーズに合っ た提案をタイムリーに できる 営業付帯業務 を削減できる KPI:Mgrﾚﾋﾞｭｰ率 トップ営業のノウ ハウを活用できる イネーブラー （実現手段） KOPT ナレッジマネジメ ントの仕組み 65 ナレッジDB ナレッジ評価・ 品質改善のプ ロセス テクノロジー プロセス トップ営業の 提案ノウハウ の形式知化 ナレッジ お客様ニーズを迅 速・的確に把握で きる 顧客情報一元化 の仕組み 顧客DB テクノロジー 技術者との業務 連携ができる 案件毎の役割分担 と活動ステータス 情報の共有 顧客接点情 報活用目的と ルールの明 確化 組織 ﾁｰﾑｾﾘﾝｸﾞのた めの役割・組織・ 業績評価指標定 義 KPI:顧客活動時間 案件活動時間 提案のムダ打 ちを削減できる マネージャが注力す べき案件を選択し営 業を直接指導できる 案件熟度 情報の入手 営業の結果だけ でなくプロセスを 評価する業績評 価制度 売上見込み管理・ 見積作成業務を 効率化できる KPI:案件登録数 SFA ツール テクノロジー モニター指標 商品手配プロセ スおよびルール の見直し プロセス KOPT・・・Knowledge（人的ノウハウ）、Organization（組織）、 Process（業務プロセス）、IT（情報システム） プロジェクト・バランス・スコア・カードの例 全社バランス・ スコア・カード 業務 学習 営業員のPDA操作習得 即時納期回答 顧客 財務 満足度向上 売上拡大 売上３％以上アップ 財 務 顧 客 顧 客 顧 客 業 務 業 務 業 務 学 習 66 財 務 財 務 納期即答率および PDA講習受講率 100% 学 習 お客様満足度スコア 90点または リピート受注率90% 営業員のPDA の機能・操作性 への満足度90点 学 習 納期精度98%以上 プロジェクト・バランス・スコア・カードにおけるKPI 責任・権限 ＫＰＩ（成果目標） 営業部門 PDAを活用してお客様満 足度を高め,売上を増大さ せる お客様満足度スコ ア（リピート受注 率）向上と売上3% アップ 営業員が全員PDAを 使いこなせる PDA講習会受講率お よび納期即答率100% 情報システ ム部門 営業員に十分な機能を持 つ使い易いPDAを提供す る 営業員のPDAの 機能・操作性への 満足度90点 営業部門にPDA講習 会を実施し,操作を習 得してもらう PDA講習会の満足度 90点,操作の問合せへ の迅速な対応（ヘルプ デスク） 製造部門 営業部門に信頼性の高 い納期情報を提供する 納期精度98%以上 生産管理の仕組みを 見直し,納期回答精度 を向上させる 購買,生産計画,進捗管 理,在庫管理・・・等々 の見直し 67 前提条件やスキル ＫＰＩ（プロセス目標） 改めて、「大義名分」の価値 大義名分が明確になっていると、 要件の切り分け基準が明確になり、圧縮し易い。 スコープの再設定、ステップ分けでの優先順位が付け易い。 追加費用や期間延長の許容限度を判断し易い。 →経営にとってのプロジェクトの成否の判断が容易になる。 「大義名分」を決定するのは 経営者の役割です！ 68 「大義名分」が果たされるなら、許容範囲で のQCD目標の変更はOK？ プロジェクトを成功に導く経営者のメンタリティー（まとめ） (1)プロジェクト目的の明確化 (2)実施許可と予算の承認（形式的では不十分） (3)適切なプロジェクト・メンバー選定と動機付け (4)円滑なコミュニケーションと状況の変化に対する適切な対応 そして、それを支える 地道な人財育成！ 69 こういうメッセージをキックオフ・ミーティングで発して下さい！ 今回のプロジェクトの目的は「戦略的メッセージ（XXX）」であって、 現場の省力化は第一義ではない。 目指すのは改善（手作業の自動化）ではなく、変革（イノベーション）である。 そのためにプロジェクトにはベストメンバーを選出した。それが私の、このプロ ジェクトに賭ける期待の表われと理解してほしい。 要件定義では大勢のメンバーに一時的に関与してもらうが、現状の業務の手 順や画面・帳票の体裁にこだわった部分最適な発言は厳禁とする。常にある べき姿から発想し、全体最適の視点で思考して欲しい。 途中で想定外の事態が発生したらすぐに知らせてくれ。タイムリーに的確な判 断と対処を行なうことを、経営サイドとしても約束する。 70 Agenda 1 プロジェクトの成功・失敗とは何か？ 2 プロジェクトを成功に導く経営者の支援行動 3 経営者の支援行動をより確実に実現するために 71 プロジェクトのステークホルダー（不健全な状態） ユーザー企業の内部事象 両者の接点事象 ＜発注企業＞ ITベンダーの内部事象 成果主義 ＜構築企業＞ 経営者 経営者 利益至上 企業戦略不明 ＣＩＯ 戦 略 が 見 え な い ＩＴ戦略無し 不明確なＲＦＰ 企画担当 ＳＯＷ不明確 非現実な提案 （コスト割れ） 重要度無視 の要求仕様 戦略が見えず部分 最適追求 72 売上至上主義 営業担当 業務部門 責任者 ユーザー 形式的合意 最小資源配置 コスト削減圧力 提案不参加 丸投げの多重層化 ＰＭ プロジェクト メンバー 取引先 （顧客） 実施責任者 丸投げ ＰＭ 顧客無視 営業責任者 コスト削減圧力 構築方針不明確 構築 空洞化（要員と メンバー スキル不足） 外注先 外注先 外注先 (ﾊﾟｰﾄﾅｰ） やる気低下 形式的レビュー有効な ＜プロジェクトチーム＞ 支援無し プロジェクト 支援部門 出典：「プロジェクトの森」・・・森林汚染の状態 コンフリクトの源泉と経営者の支援行動の関係 ユーザー企業の内部事象 他の事象への影響や解決 経営者に求められる役割と行動 該当する経営者の の方向性 の概要 ベストプラクティス そもそも明確化されていない のはP2の機能不全そのもの 戦略目的を、QCD目標や投資限 企業戦略が不明 である。これはP3を阻害する。 度を決定できる精度まで明確化 P2、L2、L4、C1 伝達機能の不全の場合は する。 L2,L4,C1が打開策である。 「企業戦略が不明」の一因で 顧客無視 あり、P2の機能不全につな 戦略立案能力を高める。 P2 がる。 SOWを不明確にし、P3を阻 CIOポストの明確化と、役職や機 IT戦略なし 害する。経営戦略とIT戦略 P2、L2 能としての確立。 の乖離はL2で解消できる。 SOW不明確 P3を阻害する。 IT戦略の明確化。 P2 重要度無視の要 ユーザー部門代表のプロジェク 求仕様 P3を阻害する。 ト・メンバーに適任者を選抜。およ P2,O1,O2,L1,L2,L4 戦略が見えず部 び継続的な人材育成を実施。 分最適追求 事象 73 コンフリクトの源泉と経営者の支援行動の関係 両社の接点事象 他の事象への影響や 経営者に求められる役割と行 該当する経営者のベストプラク 解決の方向性 動の概要 ティス P2そのものの機能不 RFPに記載されるべきIT戦略や 不明確なRFP 全であり、P3を阻害 業務の変革点などの明確化、お P2,O1,O2 する。 よびRFP作成能力の向上。 RFPの完成度を高める。採算度 行き過ぎた「コスト削減圧力」をIT 非現実な提案、 ロジカルなP3へのア 外視で受注を最優先するITベン ベンダーにかけることを回避させ コスト割れ プローチを崩壊させる。 ダーを排除する。 る。 競争入札方式は経営戦略を実 戦略目的を持つ情報システムの ロジカルなP3へのア コスト削減圧力 現するための情報システムの調 場合には、力量が把握できてい プローチを崩壊させる。 達方法としては疑問が残る。 る既存のパートナーを選定する。 P2,O1,O2 精緻な要件定義を行なう能力を 丸投げ P2,P3を阻害する。 （「不明確なRFP」の帰結する結 自社で養成する。 果である。） 事象 74 コンフリクトの源泉と経営者の支援行動の関係 ITベンダーの内部事象 成果主義 売上至上主義 利益至上主義 基本的にはユーザー企業の経営者の影響の及ぶ範囲ではない。 ただし「不健全な」ITベンダーを排除することは不可能ではない。 これらは基本的に個々のITベンダーの経営方針に関わるものであり、善悪で論じるべきものでは ない。また言葉の語感とは別に、企業が"going concern"であることを考慮すると、必ずしも責めら れるべきものでもない。しかしこれらの追求が顧客や社会の要請を超えてまで強まり、優先される 場合には、それなりの社会的な制裁を覚悟する必要があるということに帰結する。短期と中長期 最少資源配置 のバランスをとるのは容易な問題ではないが、その範疇の課題である。 コスト削減圧力 「丸投げの多重層化」の当然の帰結の一つである。 営業部門は受注金額だけを評価され、最終的な損益はPMの属する開発部門の責任となってい るITベンダーは少なくない。このような評価基準の下では職務に忠実な営業マンであればあるほ 形式的合意 ど、損益算定や付帯条件の整備よりも、受注の獲得が優先してしまうであろう。このような受注姿 勢も失敗プロジェクトの原因の一部になっていることは間違いない。 PMがプロジェクト発足前の営業活動段階から関与することは稀である。提案内容の実現の可能 PMが提案に不参 性を技術面からアセスすることなく、提案がユーザー企業に行なわれる。加えてQCD目標の変更 加 権限はほとんどの場合、PMには与えられていない。このようなプロジェクトが，Yourdonが”Death March「死の行進」”と揶揄する事態に発展し易い。 丸投げの多重層化 日本のシステム開発業界の伝統的な構造であるが、下請法上は多くの課題を抱えている。 プロジェクトの提案フェーズに関与していなかったPMが、受注直後に受託したシステムのハード 構築方針不明確 ウェア、ソフトウェア面の構築方針を明示できなかったとしても、それは必ずしもそのPMの能力不 足ということにはならないはずである。 要員とスキルの空 自分より下位層の下請けITベンダーへの「丸投げ」の、当然の帰結である。 洞化 パートナーのやる 「丸投げの多重層化」に起因する「コスト削減圧力」の当然の帰結の一つである。ユーザー企業の 気の低下 優越的な地位の濫用がその根本原因であるが、これは独善禁止法マターである。 形式的レビュー、 PMOの組織と機能のあり方の問題であり、個々のITベンダーの施策に依存する。 有効な支援無し 75 ここまでのまとめ プロジェクトのコンフリクトと経営者の支援行動の対応関係 コンフリクト ユ ー ザ ー 企 業 の 内 部 事 象 IT ユ ー ザ のー 接企 点業 事と 象 ベ ン ダ ー 76 対策 企業戦略が不明 P1 顧客無視 P2 IT戦略なし P3 SOW不明確 重要度無視の要求仕様 O1 O2 戦略が見えず部分最適追求 L1 不明確なRFP L2 非現実な提案、コスト割れ L3 コスト削減圧力 L4 丸投げ C1 経営者の支援行動をより確実に引き出すには？ 最大の課題 社長には誰も命令できない！ （誰が猫の首に鈴を付けるのか？ あるいはどうやって？） 77 解決の方向性（法的拘束力・社会的要請・CSR） プロジェクト・マネジメントの機能不全を解決し、 経営者の支援行動をより確実に引き出すために ① ② ③ ④ ⑤ 78 プロジェクト・マネジメント責任と協力義務 下請法のソフトウェア開発業務への適用 情報システム・モデル取引・契約書 各種の啓蒙活動 成果報酬型の契約 ①プロジェクト・マネジメント責任と協力義務 スルガ銀行－IBM裁判（ 2012年3月） 「プロジェクトは共同作業というべき側面を有する」 ユーザー企業の協力義務 • プロジェクト・メンバーを厳選 • 十分なリソースを投入 「ユーザー企業が開発過程において、ど のような機能を要望するのかを明確に 伝え、ベンダーとともに検討し、画面や 帳票を決定し、成果物の検収をするなど の協力を行なう義務」 社長、 メンバーを厳選し、プロジェクト にアサインしないと、我社は「協 力義務違反」に問われますよ！ P1：情報システム導入の可否を判断、承認する P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く 契約書を「信義誠実の原則に基づい て協議する」から、協力義務の明記へ。 79 C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する ②下請法のソフトウェア開発業務への適用 そもそも下請法とは？ 下請代金支払遅延等防止法（以下、下請法）は、私的独占の禁止及び公 正取引の確保に関する法律（以下、独占禁止法）の補完法 2004年、ソフトウェア開発業務が下請法の対象へ 正独占禁止法（ 2010年1月施行）では、優越的地位の濫用を行った者に、 公正取引委員会が課徴金納付命令が可能、違反内容と社名も公表 下請法における禁止行為 ①書面の交付義務 ②下請代金の支払期日を定める義務 ③書類の作成・保存義務 ④遅延利息の支払い義務 ⑤買いたたきの禁止 ⑥受領拒否の禁止 ⑦返品の禁止 80 ⑧下請代金の減額の禁止 ⑨下請代金の支払い遅延の禁止 ⑩割引困難な手形の交付の禁止 ⑪購入・利用強制の禁止 ⑫不当な経済上の利益の提供要請の禁止 ⑬不当な給付内容の変更及びやり直しの禁止 ⑭報復措置の禁止 ⑮有償支給原材料等の対価の早期決済の禁止 ②下請法のソフトウェア開発業務への適用 ・仕様と開発や支払予定の早期決定 →①書面の交付義務 →②下請代金の支払期日を定める義務 ・成果物の納品後の迅速な検収 →⑥受領拒否の禁止 →⑦返品の禁止 →⑬不当な給付内容の変更及びやり直しの禁止 P1：情報システム導入の可否を判断、承認する ・当初計画のQCD目標のキープ →⑤買いたたきの禁止 →⑧下請代金の減額の禁止 O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する ・ITベンダーを含めたモチベーション向上 →優越的地位の濫用（独占禁止法・第19条） P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する 社長、 上記のような行為（不作為）は、 「下請法違反」に問われますよ！ 81 L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する ③情報システム・モデル取引・契約書 経済産業省が組織した「情報システムの信頼性向のた めの取引慣行・契約に関する研究会」の成果物として 2007年に公表（ただし強制力はない） 第4条（ユーザ・ベンダがそれぞれ担当する役割分担） 第8条（協働と役割分担） 要件定義 第14条（要件定義作成支援業務の実施） 第12条（連絡協議会の設置） ステアリング・コミッティー 第33条（本契約及び個別契約内容の変更） 第34条（システム仕様書等の変更） 第35条（中間資料のユーザによる承認） 第36条（未確定事項の取扱い） 変更管理 第37条（変更管理手続） 情報システム保守運用委託モデル契約書 保守・運用段階のサービス品質 社長、 情報システム・モデル取引・契約書で はこんなことが奨励されていますよ！ 82 請負契約と準委任契約の民法上の瑕疵担保責任 などに関する相違点を正しく理解 →同契約書の普及によるプロジェクトの成功率向上 P1：情報システム導入の可否を判断、承認する P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する ④各種の啓蒙活動 P1：情報システム導入の可否を判断、承認する J-SOX 証券取引法等の一部を改正する法律およびその整備 法（以下、金融商品取引法）の改正（ 2006年） P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る REBOK（要求工学） Requirement Engineering Body Of Knowledge（情報 サービス産業協会、2011）では経営者を、要求工学の 理解者（Requirements Engineering Supporter）と定義 経営者として習得が望まれる要求工学に関する知識 のエッセンスを整備 （情報処理学会のデジタルプラクティス誌・2013年4月 号の特集、「要求工学で情報システム開発を変える： ユーザとベンダのWin-Win Wayへ」など） O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する 社長、 色々勉強して下さいね！ 83 L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する ⑤成果報酬型の契約 情報システムの導入効果に応じて対価を増減 させる取り決め P1：情報システム導入の可否を判断、承認する P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る 契約の対象項目を、売上や利益といった、より経営者 に身近なものに設定 →経営者の関心の高まり →経営者の支援行動の促進 →プロジェクトの成功率向上 ITベンダーにとってこの契約は、情報システム がもたらす一次的な効果と契約対象である経 営指標とのギャップに起因するリスクが大きい。 O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する 社長、 こんな契約内容であれば関心をお持 ちいただけますよね？ 84 L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する 凡例 まとめ・・・「経営者の効果的な支援行動の阻害 要因解消に向けた取り組み」の因果関係図 P1：情報システム導入の可否を判断、承認する P2：QCD目標を決定し、周知徹底し、理解を得る P3：戦略目的を決定し、周知徹底し、理解を得る O1：プロジェクトの発足時に、その遂行に必要な メンバーを質・量の両面で確保し、プロジェクト・ チームを編成する O2：プロジェクトの遂行に必要な人材を計画的に 育成し、そのレディネスを高める努力を継続する L1：ステークホルダーのモチベーションに配慮し、 それを高める努力を行なう ①プロジェクト・マネジメント義務と協力義務 ②下請法のソフトウェア開発業務への適用 ③情報システム・モデル取引・契約書 ④啓蒙活動 ⑤成果報酬型の契約 ①ユーザー企業は、自らが主導して実施すべきとされている工程に十分なリ ソースを投入しない場合には、協力義務違反を問われ得る ②書面の交付義務、下請代金の支払期日を定める義務 ②買いたたきの禁止、下請代金の減額の禁止 ②受領拒否の禁止、返品の禁止、不当な給付内容の変更及びやり直しの禁止 ②優越的地位の濫用(下請法は独占禁止法の補完法)の罰則規定 ③情報システム保守運用委託モデル契約書(基本契約書/個別契約書) ③第4条（個別契約） 第5号 「ユーザ・ベンダがそれぞれ担当する役割分担」 第8条（協働と役割分担） ③第14条（要件定義作成支援業務の実施） L2：経営者（IT投資マネジメント）とプロジェクト・メ ンバー（プロジェクト・マネジメント）間の共通言語 を確立し、効果的なコミュニケーションを確立する L3：効果的なコミュニケーションを確立するため に、自ら積極的に学習する L4：諸々の局面でリーダーシップを発揮し、プロ ジェクトを成功に導く C1：プロジェクトの戦略目的達成を優先し、不確 実な事態に適切に対処しながら柔軟にQCD目標 の修正を受け容れる。または戦略目的に基づい て要件を圧縮する 85 ③第12条（連絡協議会の設置） ③第33条（本契約及び個別契約内容の変更）、第34条（システム仕様書等の変 更）、第35条（中間資料のユーザによる承認）、第36条（未確定事項の取扱い）、 第37条（変更管理手続） ④日本版SOX法や内部統制の要請から、ITガバナンスを確立し、IT投資の効果 やリスクに関してステークホルダーに説明責任を負うことになった ④JISA REBOK企画・普及ワーキンググループにて要求工学の普及策を検討 中で、経営者をも対象とする啓蒙書を発刊予定 ⑤情報システムの導入効果に応じて対価を増減させる成果報酬型契約は、評 価指標が経営目標に近いほど、経営者の関心を高める効果が期待できる 経営者向けセミナーでのクロージング・メッセージ 『愛の反対は憎しみではなく無関心です』 プロジェクトに「関心」を、 できれば「愛」を持って下さい。 経営者の「何としても成功させたい」 との熱い想いが、 プロジェクトを成功に導きます。 マザー・テレサ 86 一筆書きクイズ・・・本書の着眼点のユニークネス プロジェクト・マネジメント 経営学、組織論・・・ プロジェクト・マネジメント ソフトウェア工学 ソフトウェア工学 87 ご清聴有難うございました！ 88 本書全体の流れ① 序章 本研究の目的は次の2つである。 ①経営者視点を明確に意識し、「情報システム構築を伴なう経営改革プロジェクト」の成否に関するマネジメント・フレームワークを構築する。 ②経営者がプロジェクトの成功に向けて行なうべき支援内容を、具体的な行動レベルで明らかにする。 第Ⅰ部 企業経営における経営者の行動・・・経営学の先行研究に基づき、経営者の責任と役割を時間軸別に明確化 1章 企業経営における業績管理の意義 過去から現在の時間軸における経営者の役割は、 業績管理情報に基づき、適切な意思決定を行なう よう努めることである。 2章 経営管理サイクルに基づく戦略の策定と遂行 過去・現在・未来にわたるPDCAサイクルの時間軸における 経営者の役割は、戦略遂行のドライバーとしての無形の資 産の価値を正しく認識し、それら無形の資産の充実度とレ ディネスを高めていくことである。 3章 経営環境の不確実性への対応 現在から未来への時間軸における経営者の役 割は、ダブルループ学習の視点に立ち、不確 実な事態に適切に対処することである。 第Ⅱ部 企業経営の視点に基づくプロジェクトの成功要因 （第Ⅰ部で導出した経営者の責任と役割を、情報システム構築プロジェクトに即して詳細化） 4章 情報システム構築プロジェクトの成否 についての考察 （プロジェクトの成否の意味するものを問い 直し、再定義する。） 5章 情報システム構築プロジェクトの特性と 管理の要諦 （プロジェクトの特性を踏まえ、その成功を意 図して提唱、実践されてきた手法の貢献と課題 について検討する。） 6章 プロジェクト・マネジメントとIT投資マネジメント の連携 （経営者の意思決定支援を意図してきたIT投資マネジメン トをプロジェクト・マネジメントと連携させることで、提 起された課題の解決を図る。） ①業績管理情報に基づき、適切な意思決定を行なうよう努めること ・業績管理の手法を援用し、プロジェクト・ マネジャーとの相互理解のための「共通言 語」を確保することが重要である。 ・REBOK以外の手法はいずれも、経営者の意思 決定支援をスコープ外としているため、貢献は 期待できない。その中でREBOKの取り組みは現 在進行形であり、今後の成果が期待される。 ・従来のIT投資マネジメント手法では、戦略的計画（IT投 資マネジメント：PDCAサイクルにおけるPCA）とオペレー ショナル・コントロール（プロジェクト・マネジメント： 同サイクルにおけるD）を連携させるマネジメント・コン トロール層に相当する概念や手法が確立されておらず、両 者が分断された状態に置かれてきた。 ②戦略遂行のドライバーとしての無形の資産の価値を正しく認識し、それら無形の資産の充実度とレディネスを高めていくこと ・プロジェクトにアサインできるメンバーを 質的にも量的にも計画的に育成すること、お よびそのレディネスを高める努力を継続する ことが重要である。 ・いずれの手法も戦略の策定や実施のプロセス はスコープ外としている。しかしREBOKは、要 求工学に関する人的資本の充実やレディネスの 向上を明確に意図している。 ・従来のIT投資マネジメント手法は、戦略の策定から実施 に至るPDCAサイクルのDo工程をプロジェクト・マネジメン トに委ねてきた。ここでPDCAサイクルが分断されており、 戦略の遂行が不確実なものとなっている。 ③ダブルループ学習の視点に立ち、不確実な事態に適切に対処すること ・プロジェクト・マネジャーなどの声に耳を 傾け、当初設定したQCD目標の墨守を求める のではなく、プロジェクトの戦略目的の達成 を優先し、可能な範囲でQCD目標の修正を受 け容れることが重要である。 89 ・いずれの手法も各活動が順次的に進捗するこ とが大前提とされており、「手戻り」や計画変 更を「悪」としてきた。これらのパラダイムを 変革し、実用的な技術基盤を伴なったアジャイ ル開発などの手法の適用可能性を常に注視して おくことが重要である。 ・従来のIT投資マネジメント手法はPDCAのDo（情報システ ム構築工程）を詳細に扱っておらず、計画が立案されれば そのとおりに完成するという前提に立ってきた。またプロ ジェクト・マネジメント工程で発生する不測の事態に対す る対応策も想定していなかった。したがってこれら両者の 連携を図ることが課題の解決につながると期待される。 本書全体の流れ② 第Ⅱ部 企業経営の視点に基づくプロジェクトの成功要因 4章 情報システム構築プロジェクトの成否 についての考察 5章 情報システム構築プロジェクトの特性と 管理の要諦 6章 プロジェクト・マネジメントとIT投資マネジメント の連携 ①業績管理情報に基づき、適切な意思決定を行なうよう努めること ②戦略遂行のドライバーとしての無形の資産の価値を正しく認識し、それら無形の資産の充実度とレディネスを高めていくこと ③ダブルループ学習の視点に立ち、不確実な事態に適切に対処すること 7章 経営者の行動を支える意識改革と組織体制 「情報システム構築を成功に導く経営者の行動特性に関する仮定」は以下の通り。 「計画化（Planning）」関連 P1：情報システム導入の可否を判断、承認する。 P2：QCD目標を決定し、周知徹底し、理解を得る。 P3：戦略目的を決定し、周知徹底し、理解を得る。 「組織化（Organizing）」関連 O1：プロジェクトの発足時に、その遂行に必要なメンバーを質（スキルレベル）・量（人数や専任度）の両面で確保し、プロジェクト・チームを編成する。 O2：プロジェクトの遂行に必要な人材を計画的に育成し、そのレディネスを高める努力を継続する。 「指揮（Leading）」関連 L1：ステークホルダーのモチベーションに配慮し、それを高める努力を行なう。 L2：経営者（IT投資マネジメント）とプロジェクト・メンバー（プロジェクト・マネジメント）間の共通言語を確立し、効果的なコミュニケーションを確立する。 L3：効果的なコミュニケーションを確立するために、自ら積極的に学習する。 L4：諸々の局面でリーダーシップを発揮し、プロジェクトを成功に導く。 「統制（Controlling）」関連 C1：プロジェクトの戦略目的達成を優先し、不確実な事態に適切に対処しながら柔軟にQCD目標の修正を受け容れる。または戦略目的に基づいて要件を圧縮する。 第Ⅲ部 事例研究 上記「情報システム構築を成功に導く経営者の行動特性に関する仮定」の妥当性を事例研究にて確認する。 90 本書全体の流れ③ 第Ⅲ部 事例研究 「情報システム構築を成功に導く経営者の行動特性に関する仮定」の妥当性を事例研究にて確認する。 8章 研究方法の検討 ・情報システム構築プロジェクトを成功に導く経営者の行動に関する一連の仮定の妥当性を確認する研究方法論としては、事例研究が最適である。 9章 事例研究の実施方法に関する検討 ・先行研究に基づいた仮定の妥当性を事例研究によって確認するアプローチもまた、サンプル数の制約はあったとしても、社会現象のメカニズムの 解明に少なからぬ意義を提供するものである。 10章 プロジェクトを成功に導く経営者の行動 ・7章の10項目のうち、P1は10社のすべてで実施されていたが、結果は千差万別であり、この項目は成否の決定要因ではないことが明らかになった。 それ以外の項目では実践度とプロジェクトの成功率に正の相関が見られた。 ・プロジェクトを成功に導く経営者の行動特性は、プロジェクト目的の明確化、適切なメンバー選定と動機付け、状況の変化への対応であった。か つこれらの行動は互いに因果関係を持っており、根底にあるのは経営者としての当該プロジェクトを成功させたいという意識の強さであることが明 らかになった。 ・また経営者の行動の効果は、ステークホルダー間のコミュニケーションのレベル、ステークホルダーの当事者意識の強さ、ステアリング・コミッ ティーといった組織の構成メンバーとそのモチベーションのレベルに影響を受けることも明らかになった。 11章 経営者の支援行動を実現する具体策 ・経営者に支援行動を強制することは誰にもできない。しかし下記取り組みはその促進効果を期待できる。 プロジェクト・マネジメント責任と協力義務 下請法のソフトウェア開発業務への適用 情報システム・モデル取引・契約書 各種の啓蒙活動 成果報酬型の契約 終章 今後の課題 ・本論文では議論の発散を回避するために一旦捨象したプロジェクト・チームを、その構成メンバーであるユーザー企業の情報システム部門とITベ ンダーに分解し、この両者間の利害相反（契約や役割分担、責任範囲）に関して実務の中で生じる課題の解決を図っていきたい。 ・研究の着眼点は11章で挙げた5項目を基本とし、アプローチとしては引き続き事例研究に基づいて実施する。 Appendix （事例研究10社の調査内容） 91