Comments
Description
Transcript
高品質のための超上流工程における企業の課題・取組み事例集
高品質のための超上流工程における 企業の課題・取組み事例集 ～ 超上流工程の検討精度の向上に関する調査報告書 ～ ２０１３年３月 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター エンタプライズ系プロジェクト 目 次 1. 背景と目的 ......................................................................... 2 1.1. 背景 ........................................................................... 2 1.2. 目的 ........................................................................... 2 2. 総括と対象読者 ..................................................................... 3 2.1. 総括 ........................................................................... 3 2.2. 対象読者 ....................................................................... 4 3. 調査方法 ........................................................................... 5 3.1. 実施方針 ....................................................................... 5 3.2. 実施手順 ....................................................................... 5 4. 調査結果 ........................................................................... 7 4.1. 回答状況 ....................................................................... 7 4.1.1. 企業の内訳 ................................................................. 7 4.1.2. 課題・解決策の収集件数 ..................................................... 7 4.1.3. 情報共有ニーズ ............................................................. 7 4.2. 課題の傾向 ..................................................................... 8 4.2.1. 全体の傾向 ................................................................. 8 4.2.2. 工程別の傾向 ............................................................... 8 4.3. 課題の分析 ..................................................................... 9 4.3.1. 課題の整理と仕分け ......................................................... 9 4.3.2. 超上流の 5W2H.............................................................. 11 4.3.3. 5W2H の関係性.............................................................. 12 4.3.4. 17 個のカテゴリの再分類 .................................................... 13 5. 優先度を上げて取り組むべき課題と解決策 ............................................ 14 5.1. 投資マネジメントルールの導入 .................................................. 14 5.2. 超上流工程のプロセス定義 ...................................................... 15 5.3. 実施案件の優先順位づけ ........................................................ 16 5.4. 多段階見積・多段階発注 ........................................................ 17 5.5. 開発体制への専任者の組込み .................................................... 18 6. おわりに .......................................................................... 19 7. 付録 .............................................................................. 19 7.1. 超上流工程における課題と解決策一覧 ............................................ 19 7.2. 超上流工程における課題のマインドマップ ........................................ 19 1 Copyright © 2013 IPA, All Rights Reserved 1. 背景と目的 1.1. 背景 ネットワークの発達とともにビジネスモデルは大きく変化し、企業のビジネスにおいて、システ ムはなくてはならない存在となった。ビジネスとシステムの関係性は深化を続け、システムに対す る要求は複雑化、高度化している。システム開発の QCD に対する高い要望を達成するためには、ユ ーザとベンダが堅固な協力体制を組むことはもとより、要件定義に入る前の両者の活動が大きなカ ギを握っている。 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター（以下、 IPA/SEC という。 ）は、2004 年の設立以来、超上流工程の重要性を提唱し、 「経営者が参画する要求 品質の確保 ～超上流から攻める IT 化の勘どころ～」「超上流から攻める IT 化の原理原則 17 ヶ条」 「共通フレーム 2007, 2013」等の書籍や SEC セミナーを通じて、その重要性も然ることながら、経 営者及び業務部門の役割や責任の明確化が必要であるというメッセージを発信し続けてきた。 「経営者が参画する要求品質の確保」で用いた「超上流」という言葉も、当初は馴染が薄かった が、今ではシステム開発プロジェクトを遂行する際の重要なキーワードとして多くのメディアに取 り上げられるようになり、産業界では超上流工程への意識が高まっている。しかしながら、超上流 工程における課題に対して具体的な取組みを始める企業が多数出てきている一方で、それに起因す るプロジェクトの失敗は依然として後を絶たない。 これまで、IPA/SEC は超上流工程の重要性の認知に重きを置いてきたが、これらの工程における 多くの課題の解決策、あるいは様々な取組みのヒントになるような具体的な情報を提供すべき時期 にきている。 1.2. 目的 本調査では、超上流工程において、各企業がどのような課題認識を持ち、それをどのように解決 しているのかを把握するため、以下の 3 点に関するアンケートを実施した。 (1) 各企業が抱えている超上流工程の課題にはどのようなものがあるのか？ (2) 個々の課題に対する具体的な解決方法が策定されているか？ (3) 他社で行われている取組みを共有したいというニーズがあるか？ その結果、具体的な課題と解決策、並びに情報共有に対するニーズが収集できたので、報告書及 び付録（アンケート結果）という形で公開する。 課題や解決策の内容には様々なものがあるが、その内容を共有することで、各社が超上流工程を 進める際のヒントを得ていただくことが目的である。当然ながら各企業、あるいは開発プロジェク トの特性を踏まえたものとなり、第三者的に見た場合は、 「この課題にはこの解決策」と一意に言え ないものも多い。しかしながら、課題の背景も含めて内容を読み解くことで、是非とも参考にして いただきたい。 2 Copyright © 2013 IPA, All Rights Reserved 2. 総括と対象読者 2.1. 総括 本報告書の詳細に入る前に、先に調査の総括を述べておく。 「1.1. 背景」にも述べたとおり、超上流工程の重要性を説いて久しい。IPA/SEC が超上流工程に 取り組み始めた頃の解決策として、 「先ずは目的（効果）を明確にする」ことを挙げていたが、それ とともに、以下のような 7 つのポイントに留意してプロジェクトを推進すべきであると説いている。 図 1 超上流の重要な 7 つのポイント （SEC BOOKS『経営者が参画する要求品質の確保』より） 目的の明確化をはじめ、いずれも極めて基本的な事柄であり、恐らく誰もが「当たり前」と思う に違いない。今回の調査を始める前は、8 年前と比べて変わっているところや、時の流れを経て新 たに登場した課題があるのではないかと思っていたが、今回の調査結果をご覧いただければお分か りのように、 「何も変わっていなかった」と言っても過言ではない。システム開発の現場には、これ らの基本的な課題が厳然としてあるのである。 しかし、こうも言えるのではないだろうか。 「これらの課題は簡単に駆逐できるものではない。継続的な取組みによって、粛々と 解決していかなければならないのだ」と。 この結果を受けて、改めて下記をメッセージとして掲げたい。そして、ユーザが当然のように超 上流工程を主導し説明責任を果たすことで、プロジェクトの成功を積重ねていただきたいと思う。 システムによって何を実現したいのかは、 ユーザにしか決められない。 ユーザの積極的な参画がプロジェクトを成功に導く。 本調査結果に限らず、各種メディアや業界団体で、超上流工程の課題に対する取組み事例を目に するが、その数は着実に増えているという印象だ。しかし、うまくいくケースには下記の共通性が あるように思う。 『経営層の人間が意思をもって推進している』 この点も踏まえ、経営者並びに事業部門のトップの方々が、 “システム開発＝情報システム部門の 仕事”という発想から脱却し、推進力を発揮することを切に願う。 3 Copyright © 2013 IPA, All Rights Reserved 2.2. 対象読者 本報告書の対象読者は、業種によらず、企業あるいは自治体等の情報システム開発において超上 流工程に携わる人であるが、 「2.1. 総括」に述べたとおり、特にユーザ企業の経営者及び事業 部門の方々にはご一読いただきたい。また、 「経営者が参画する要求品質の確保」を読まれていな い方は、これを機に是非一度目を通していただきたい。なお、 「経営者が参画する要求品質の確保」 では、超上流工程と役割分担、システム開発に必要な要件の定義と役割の関係を、それぞれ図 2、 図 3 のように定義している。併せて参照いただきたい。 超 上 流 システム化 システム化 の方向性 計画 経営層 Ｒ Ｆ Ｐ 業務 部門 情報 ｼｽﾃﾑ 部門 Ｒ Ｆ Ｐ 仮 試 算 ベンダ 試 算 要件定義 Ｒ Ｆ Ｐ 要 件 定 義 書 概 算 図 2 超上流工程と役割分担 （SEC BOOKS『経営者が参画する要求品質の確保』より） 部署等／ 役割（ロール） 要件の 定義内容 社長 経営層 担当役員 部門長 業務推進担当 事業要件 定義 業務部門 システム推進担当 業務（システム） 要件定義 関連会社 部門長 情報システム 部門 （ＩＴ）システム 要件定義 システム開発担当 システム子会社 元請けベンダ ベンダ アウトソーサ サブベンダ 図 3 要件の定義と役割 （SEC BOOKS『経営者が参画する要求品質の確保』より） 4 Copyright © 2013 IPA, All Rights Reserved 3. 調査方法 3.1. 実施方針 本調査の実施方針を以下に示す。 (1) アンケート形式とする。 (2) 細かい質問項目は設定せず、フリーで記入できる形式（図 4）とする。 (3) 超上流工程を対象とする。なお、本調査における「超上流」工程とは、事業戦略・事業計画、 システム化の方向性、システム化計画、要件定義の 4 つの工程を指す。 (4) 偏りがないようユーザ及びベンダの双方を調査対象とする。 (5) ソフトウェア開発に限定せず、 「システムを開発する」「事業(業務)を成功させる」という広い 視点での回答を依頼する。 なお、回答者は、 「システム開発において超上流工程に携わっている方」「超上流工程における課 題解決をミッションとしている方」 「課題解決のための具体的な取組みを策定、実施している方」を 想定し実施した。 企画プロセス フェーズ 記入例 事業戦略・事業計画 NNNNNNNNNNNNNNNNNNNNN NNNNNNNNN システム化の方向性 NNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNN 要件定義プロセス 開発プロセス 要件定義 システム設計 システム化計画 NNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNN NN 問題/ 課題 解決策/ 取組み 図 4 アンケートフォーマット 3.2. 実施手順 本調査は、以下の流れで実施した。 アンケート準備 シート配布 シート回収 内容精査 追加調査 分析 報告書作成 (1) アンケート準備 実施計画を策定し、アンケートの形式及び項目を決定する。調査対象企業の候補をリストアッ プして協力を依頼＊1 する。 (2) シート配布 アンケートシートを Excel で作成し、調査対象企業に配布する。 (3) シート回収 アンケートシートをメールで回収する。ユーザとベンダからの回収件数を確認し、必要に応じ てバランスを取るべくアンケートを新規に依頼する。 5 Copyright © 2013 IPA, All Rights Reserved (4) 内容精査 アンケートシートの内容を精査し、追加調査すべき点（疑問点、更に深く知りたい点など）の 有無を確認する。 (5) 追加調査 追加調査すべき点がある場合はシートにコメントを記入し（図 5）、メールのやり取り、もしく は対面ヒアリングで確認する。 (6) 分析 アンケート結果を分析し、最終的な成果物の形式及び内容を検討する。 (7) 報告書作成 上記(4)～(5)のアンケート結果（ローデータ）に、(6)の分析結果を加え、アンケート結果の見 せ方を工夫するとともに、報告書としてまとめる。 (*1) 調査対象企業の募集は、一般社団法人日本情報システム・ユーザー協会（JUAS）の協力を 仰ぐとともに、報告者の個人的なリレーションを通じて行った。 図 5 追加調査のコメント 6 Copyright © 2013 IPA, All Rights Reserved 4. 調査結果 4.1. 回答状況 4.1.1. 企業の内訳 アンケートへの回答は、大手・中堅のユーザ、ベンダ各 10 社、計 22 名から得られた。20 社のう ち 17 社が首都圏、3 社が地方の企業、また、19 社は民間企業である。このうち、15 社に対して追 加調査を実施した。アンケートの結果（課題及び解決策）は【付録 1】として添付する。 なお、企業名及び企業プロフィールは非公開とする。 4.1.2. 課題・解決策の収集件数 事業戦略・事業計画、システム化の方向性、システム化計画、要件定義における課題及び解決策 の件数を表 1 に示す。同種の課題、解決策であっても重複してカウントしている。 表 1 収集した課題及び解決策 工程 課題 解決策 事業戦略・事業計画 29 16 システム化の方向性 46 31 システム化計画 54 39 要件定義 60 43 189 129 計 4.1.3. 情報共有ニーズ アンケート調査の中で、他社の超上流工程の課題及び解決策を共有したいかどうかを聞いた。回 答者 22 名のうち 4 名が無回答、残りの 18 名の全員が「他社での取組みを知りたい」 （図 6）と回答 した。サンプル数自体は少ないものの、情報共有のニーズは高いと言える。 いいえ, 0 無回答, 4 はい, 18 図 6 情報共有ニーズ 活用方法及び共有形態については、以下のような要望が挙げられた。 活用方法：開発標準への取り込み、開発プロセスの改善、課題が顕在化したときの参考 共有形態：報告書・ガイドブック、フォーラム・ワークショップ、 HP で Web 公開 7 Copyright © 2013 IPA, All Rights Reserved 4.2. 課題の傾向 4.2.1. 全体の傾向 事業戦略・事業計画の課題及び解決策は、他の工程と比べると相対的に少なめだった。全体を眺 めると、各企業とも色々な策を講じてきたことがうかがえる。また、 「ユーザならではの」 「ベンダ ならではの」という課題は少なく、似たようなものが多い。言い換えれば、どこの企業でも同じよ うな問題を抱える可能性があるということである。 類似問題に対する他社での取組みは参考になると思われる。特に、実践を経て既に定着している ものは、汎用的なものであればあるほど参照価値が高い。 4.2.2. 工程別の傾向 収集した課題を、ある程度の粒度で 17 個のカテゴリに分類した。超上流工程における各カテゴリ の件数を表 2 及び図 7 に示す。 表 2 課題のカテゴリと工程別件数 カテゴリ 1 事業戦略・事業計画とシステム化計画の乖離 2 対応すべき課題の優先順位が曖昧 3 ユーザニーズの把握不足 4 組織体制、役割分担が不明確 5 商品、サービスの検討不足 6 プロジェクトの目的が不明確 7 契約、見積が不十分 8 業務知識、経験、スキルの不足 9 組織ビジョンが不明確 事業戦略・ 事業計画 システム化 の方向性 12 8 10 5 4 システム化 計画 2 10 9 7 3 3 2 1 1 13 3 3 13 6 既存システムの仕様が不明確 11 新技術、新サービスの採用 12 開発方針、開発計画が不十分 13 プロジェクト管理が不十分 7 3 14 費用対効果が不明確 3 15 要件定義不足、レベルの甘さ 16 要件定義の終了条件が曖昧 17 リスク管理の甘さ 29 46 13 4 3 7 1 10 計 要件定義 54 26 6 1 60 事業戦略・計画では、 「事業戦略・事業計画とシステム化計画の乖離」 「対応すべき課題の優先順 位が曖昧」が多く、システム化の方向性になると、上記に加えて「組織体制、役割分担が不明確」 「商品、サービス検討不足」 「プロジェクト目的が不明確」が課題となってくる。 システム化計画では、 「契約、見積が不十分」 「開発方針、開発計画が不十分」という課題が増え、 要件定義に至っては、 「要件定義不足、レベルの甘さ」が圧倒的に多い。 8 Copyright © 2013 IPA, All Rights Reserved 0 5 10 15 20 25 30 35 40 事業戦略・事業計画とシステム化計画の乖離 対応すべき課題の優先順位が曖昧 ユーザニーズの把握不足 組織体制、役割分担が不明確 商品、サービスの検討不足 プロジェクトの目的が不明確 契約、見積が不十分 事業戦略・事業計画 業務知識、経験、スキルの不足 システム化の方向性 組織ビジョンが不明確 システム化計画 要件定義 既存システムの仕様が不明確 新技術、新サービスの採用 開発方針、開発計画が不十分 プロジェクト管理が不十分 費用対効果が不明確 要件定義不足、レベルの甘さ 要件定義の終了条件が曖昧 リスク管理の甘さ 図 7 課題のカテゴリと件数 4.3. 課題の分析 4.3.1. 課題の整理と仕分け 収集した課題及び解決策には、様々な粒度のものがある。それは、各企業が抱えている課題の差 でもあるが、回答者の考え方、書き方に依存している部分も大きい。それを補完するための策の一 つとして前述の追加調査を行ったが、課題分析においては別の策も実施した。 具体的には、 「本質的な課題は何なのか？」を探るべく、マインドマップ（図 8）を利用し、以下 の 3 つの点に注目した課題の整理、統合を実施した。 課題の先行関係 課題 A によって課題 B が発生。 つまり、課題 A が潰せていれば課題 B は発生しないはずである。 課題の類似性 課題 C と課題 D は本質的には同じものなので、同じカテゴリに分類することができる。 課題の類推 課題 E があれば通常は課題 F もあるはずである。 （過去の経験に基づいた課題の類推と補完） この整理と仕分けの結果より、課題の関連性を含め、例えば以下のような構図が見えてくる。 (1) ユーザの意思決定に直結する課題は、当然ながら次工程の課題と密接な関係がある。例えば、 事業戦略・事業計画が抽象的、あるいは曖昧な状態であれば、対応すべき課題の優先順位が付 けられず、その延長線上にある商品やサービスの検討は困難となる。 (2) 事業戦略・事業計画の策定でとどまっていればいいが、無理にシステム化の検討に着手するこ とで傷口が広がる。 「何を実現したいのか？」が固まっていないため、開発側の検討は見切り発 車となり、事業側が迷走すればするほど両者の乖離は大きくなる。 9 Copyright © 2013 IPA, All Rights Reserved (3) 事業の目的が曖昧な状態であればシステム化の目的も曖昧となる。いつしかシステム化するこ と自体が目的となり、事業戦略・事業計画と切り離されたところで開発がスタートする。結果 的にベンダから見た場合は、結果的にユーザニーズの把握不足という状況に陥る。 (4) 予算を取る際、 「何を実現したいのか？」が明確でない状態であるにもかかわらず、無理矢理ベ ンダに見積を依頼し、超概算でコストを算出する。根拠の乏しい見積が独り歩きし、根拠の乏 しい予算となって立ちはだかることになる。 (5) 費用対効果の評価基準が曖昧、あるいは定性的評価をよしとすることで、案件の客観的な評価 ができなくなる。その結果、明らかに費用対効果の低い案件が、システム化計画や要件定義の 段階でも土俵に上がったままとなる。 (6) 事業とシステムが密接な関係にあるにも関わらず、開発経験が豊富な人材が検討体制（特に事 業部門側）に組み込まれていない。それどころか、無用な人事異動を行ったり有識者や経験者 のアサインが遅れたりすることで、プロジェクトは混迷を深める。 (7) システム化計画に入るまでに「やりたいこと」が固まっていないどころか、要件定義に入って から考えようとしている。要件定義は「やりたいこと」を再確認し、具体化し、ブレないよう に固めることが目的であるが、その理解が乏しい。必然的に、要件定義は不十分な状態となる。 文章にしてみると当たり前のことばかりのようにも見えるが、程度の差こそあれ、開発現場には 同じような課題が存在している。ユーザ自らが「何を実現したいのか？」をしっかりと検討し、明 確に意思決定することが最も重要である。それなくして先に進むことはできず、先に進めたところ で早晩行き詰るということだ。 超上流工程において優先度を上げて取り組むべき課題は、必然的に「事業戦略・事業計画とシス テム化計画の乖離」 「プロジェクトの目的が不明確」といった目的に関するもの、それに次いで「商 品、サービスの検討不足」 「対応すべき課題の優先順位が曖昧」 「要件定義不足、レベルの甘さ」な どの具体的な施策ということが言えよう。 図 8 超上流の課題のマインドマップ なお、マインドマップは【付録 2】として添付するが、精緻な整理を目的としたものではないた め、先行関係や重複排除という点では完成度が高いとは言えない。【付録 2】を参照いただく際は、 ご注意願いたい。 10 Copyright © 2013 IPA, All Rights Reserved 4.3.2. 超上流の 5W2H 「4.3.1. 課題の整理と仕分け」の「開発現場の構図」やアンケート結果を見ると、基本的なアク ションがきちんと取られていないことに起因していることに気づく。例えば、責任部署が曖昧であ る、然るべき要員が確保されていない、課題の優先度が決まっていない、プロジェクトの目的が不 明確である、というようなものは、単純に言えば、責任部署を明確にする、必要な要員を確保する、 課題の優先順位を決める、プロジェクトの目的を明確にする、というアクションを取ればよい。 「言うは易く行うは難し」であることは分かっている。恐らく、どの企業も“基本的に何をすれ ばよいのか”は理解しているものの、口で言うほどうまくはいかないというのが現状だろう。しか し、ちょっと胸に手を当てて考えてみていただきたい。本当に、それらが“基本的なこと”として 理解されているだろうか？ プロジェクトに関わる全てのステークホルダがきちんと理解している だろうか？ 理解しているのは“あなた方だけ”ということはないだろうか？ これまでの打ち手 がうまくいかなかった原因を“基本的なこと”に立ち返って振り返っているだろうか？ 報告者の個人的な感覚なのかもしれないが、特に超上流工程においては、様々な“基本的なこと” が、然るべき“流れ”の中で行われていないことに本質的な問題があるように思われた。 そこで、課題分析においては、もう一つ別の整理を実施した。 他者とコミュニケーションを図る際、相手に伝えるべきポイントを Who, What, When, Where, Why, How で整理するとよいとよく言われる。ビジネスにおいては How much を加えた 5W2H がよく引き合 いに出される。 Who 誰が？ What 何を？ When いつ？ Where どこで？ Why なぜ？ How どうやって？ How much いくらで？ これに、超上流工程における“基本的な”検討事項を当てはめてみると、以下のようになると思う。 Who 組織・体制 What 解決すべき課題 When 計画・納期 Where 対象範囲 Why 目的・目標（効果） How 実現方法・手段 How much 投資額 例えば、事業部門とシステム部門との間のコミュニケーション（例えば、開発の依頼）に、上記 の要素が必要だとするならば、どれか一つが欠けてもコミュニケーションは成り立たない、あるい は不完全な状態ということになる。プロジェクトを立ち上げても、上手く進む可能性は低くなると いうわけだ。 11 Copyright © 2013 IPA, All Rights Reserved 4.3.3. 5W2H の関係性 では、これらの要素は、どのように関連づいているのだろうか？ やはり「目的・目標（効果） 」が最初に来るだろう。何をおいてもこれを決めなければ、それ以外 の全てが決められないはずである。これがブレると、それ以降の全ての作業がブレることになる。 しかし、実際は「目的が不明確」な状態のままプロジェクト編成され、開発作業に入っていってし まったりする。どう考えてもうまくいくはずがない。 目的・目標（効果）が決まった後は、 「解決すべき課題」 、つまり目的・目標を達成するために何 をするのかを決めるべきだろう。具体的に何をするかが決まらなければ、対象範囲や組織・体制な どを決めようがない。このように考えると、超上流の 5W2H は図 9 のような関係になる。 対象範囲 目的・目標 （効果） 解決すべき 課題 組織・体制 計画・納期 投資額 実現手段 図 9 超上流の 5W2H の関係性 実際には、目的・目標（効果）から始まって、最も右にある投資額まで流れて終わり、というわ けにはいかない。一旦策定した計画、あるいは納期の実現性が薄ければ、対象範囲を絞るとか解決 すべき課題を減らすといった対応が必要になる。あるいは、投資額が企業としてのキャパシティに 見合わなければ、目的・目標（効果）自体を見直すことになるかもしれない。 例えば、社長が「売上を 50％伸ばせ（＝目的）」と言ったとしよう。それを受けて事業部門が新 商品（＝解決すべき課題）を検討し、組織・体制、実現手段を固めつつ、プロジェクト計画を立て る。ここで投資額を試算して 10 億円と出たところで、当然ながら決裁を仰ぐ。社長が OK と言えば プロジェクトは進むし、5 億円までしか出せないと言えば、何かを見直さなければならない。因み に、ここで絶対にやってはいけないのは、何も見直すことなくベンダに「5 億でやって！」と投げ ることであるというのは言うまでもない。 図 9 は、優先度も含めて綺麗にまとまっているように見えるが、企業の置かれている状況、特性、 担当者の技量、QCD の優先順位など、様々な細かい要因によって状況は変わる。つまり、投資額か らの単純なフィードバックでは対応できない場合も多いということだ。そこには多様な状況があり、 それに対する多様な取組みがある。 これは【付録 1】の課題と対応策にも当てはまる。多様であるが故に、そこに直接的な“答え” はないかもしれないが、 「うちには合わない」と見切るのではなく、課題の背景も含めて内容を読み 解くことで、少しでも役立ちそうなものを発掘していただきたい。 【付録 1】の課題と対応策を“ご みの山”とするか“宝の山”とするかは利用者次第である。 12 Copyright © 2013 IPA, All Rights Reserved 4.3.4. 17 個のカテゴリの再分類 超上流の 5W2H を前提に、 「4.2.2. 工程別の傾向」の表 2 で示した 17 個のカテゴリを再分類した ものを表 3 に示す。 「4.3.1. 課題の整理と仕分け」及び 5W2H の関係性を前提に考えると、超上流工 程における検討は、原則図 9 の要素の順番で進めるのがよいと考える。表 3 で言えば「検討事項」 の上から順番に取組みの優先度が高いということである。 例えば、 「対応すべき課題の優先順位が曖昧」という課題が顕在化している場合、単に優先順位を 付けていないだけなのかどうかを考え、更に上流の課題に起因しているのであれば、そこまで遡る べきである。先に述べたように、無理に進めたとしてもプロジェクトが行き詰るか、QCD の面でト ラブルに発展する可能性が高い。 表 3 課題のカテゴリと検討事項 カテゴリ 5W2H 検討事項 1 事業戦略・事業計画とシステム化計画の乖離 Why 目的・目標（効果） 2 プロジェクトの目的が不明確 Why 目的・目標（効果） 3 費用対効果が不明確 Why 目的・目標（効果） 4 ユーザニーズの把握不足 What 解決すべき課題 5 商品、サービスの検討不足 What 解決すべき課題 6 対応すべき課題の優先順位が曖昧 Where 対象範囲 7 既存システムの仕様が不明確 Where 対象範囲 8 要件定義不足、レベルの甘さ Where 対象範囲 9 組織体制、役割分担が不明確 Who 組織・体制 10 業務知識、経験、スキルの不足 Who 組織・体制 11 組織ビジョンが不明確 Who 組織・体制 12 新技術、新サービスの採用 How 実現手段 13 プロジェクト管理が不十分 How 実現手段 14 リスク管理の甘さ How 実現手段 15 開発方針、開発計画が不十分 When 計画・納期 16 要件定義の終了条件が曖昧 When 計画・納期 17 契約、見積が不十分 How much 投資額 13 Copyright © 2013 IPA, All Rights Reserved 5. 優先度を上げて取り組むべき課題と解決策 分析結果を基に、優先度を上げて取り組むべき課題のうち幾つかをピックアップし、それぞれに ついて内容の説明及び実践的な解決策を紹介する。 5.1. 投資マネジメントルールの導入 プロジェクトの目的・目標の明確化と、システム化の方向性以降における検討のブレの極小化を 目的として、投資マネジメントに関する全社ルールを導入する。効果目標を具体的に設定すること で、誇大効果案件の削減や、目的（効果）とシステム化要件の整合性の向上が期待できる。投資マ ネジメントの流れの例を図 10 に示す。 取組みの概要 ・事業部門が中心となって投資目的を決定し、どのような商品、機能、業務プロセスが必要と なるのかを検討する。 ・一定規模（1 億円以上など）の案件は投資決裁会議に諮り、基準（ROI、投資回収年など）を クリアしたもののみを先に進める。 ・定量的評価ができるよう、目標（売上、利益、KPI 等）を数値化して設定する。この仕組み と、システム開発の実施判断あるいはゲートレビューとを関連づけるとよい。 投資判断フェーズ モニタリングフェーズ 実行 ビジネス投資決裁 事業 部門 ｢事業戦略｣ (フリー) ビジネス投資 決裁書 システム投資決裁 ｢投資・ＩＴ戦略｣ (フォーマット) (フォーマット) 会議体 主管部署 (事務局) ポ イ ン ト システムカットオーバー 1ヵ月後をメドに実施 効果測定 報告書 ●チェックポイントに従って記入 ●チェックポイントに従って記入 システム 部門 システム投資 決裁書 システム効果測定 ビジネスモニタリング ●事業計画に先立ち まとめ (フォーマット) 個別会議 ●ゲートレビュー 決裁会議 全社マネジメント＋システム部門 ●ゲートレビュー システム部門 ■要件定義(新たなCash発生)前に実施 ■投資額・効果目標の ■商品P/L、C/F費用対効果等で判断 最終化 ■費用対効果、KPIを目標として設定 →経済的費用対効果 ■Q単位で決裁案件を取締役会で共有 →KPI目標 ●レビュー システム部門 全社マネジメント ■達成状況評価 ■マイルストーン毎の ■｢打ち手｣の協議 達成状況評価 ■｢打ち手｣の協議 図 10 投資マネジメントの流れの例 ポイント ①投資の目的及び目標、具体的な商品やサービス等を検討し、事業部門がビジネス投資決裁会 議に起案する。この時点の投資額は、要件定義前の概算でよい。 ②担当役員を含めた会議体で投資の妥当性を評価する。投資基準をクリアしているか、投資価 値があるか、何を目標とするのか等について確認する。 ③案件を先に進めてよいとなった場合は、総投資額の一部が承認される。この時点で決裁され るのは、要件定義（基本設計含む）部分の金額のみである。 ④要件定義終了後、ベンダに最新見積を依頼する。投資内容を含め、ビジネス投資決裁時との 差異が大きい場合はシステム投資決裁会議を開催する。 ⑤システムのリリース後、速やかにシステム効果測定を実施する。また、設定したビジネス目 標の達成度を確認する。 14 Copyright © 2013 IPA, All Rights Reserved 5.2. 超上流工程のプロセス定義 要件定義に入る前のプロジェクトの検討精度の向上と、システム化の方向性以降における検討の ブレの極小化を目的として、超上流工程のプロセスを定義する。マイルストーンを設定し、検討状 況を把握することで、システム部門の参画タイミングを見極めることができる。超上流工程のプロ セス定義の例を図 11 に示す。 取組みの概要 ・要件定義工程の前にビジネス検討／プロジェクト定義工程を設け、事業部門が中心となり、 ビジネスに関する検討を集中的に行う。 ・システム部門は、事業側の検討状況を見ながら、システム化計画に着手できるかどうかを見 極め、要件定義以降の計画を立案する。 ・ビジネス検討／プロジェクト定義工程の終了条件を満たさない場合は、要件定義工程に進む ことができない。その可否はゲートレビューで判断する。 ビジネス検討／ プロジェクト定義 要件 定義 設計・ 製造 投 資 決 裁 ① ゲ ー ト レ ビ ュ ー ① テスト・ 移行 運用・ 保守 投 資 決 裁 ② ゲ ー ト レ ビ ュ ー ② ゲ ー ト レ ビ ュ ー ③ 効 果 測 定 ゲ ー ト レ ビ ュ ー ④ ゲ ー ト レ ビ ュ ー ⑤ ゲ ー ト レ ビ ュ ー ⑥ ゲ ー ト レ ビ ュ ー ⑦ プ ロ ジ ェ ク ト 評 価 超上流工程 事業部門主導 目的・方針決定 サービス・目標決定 ビジュアル化 プロジェクト定義（システム化計画） システム部門主導 図 11 超上流工程のプロセス定義の例 ポイント ①単に工程を新設するのではなく、成果物を定義し、担当者及び納期を明確にすることで、検 討の抜け漏れを防止する。 （ “何となく検討を進める”という状態の排除） ②ビジネス検討を分割することで、検討し決定すべきことを明確にし、ステップを踏んで進め ることができる。ステークホルダ間の合意形成も図りやすい。 ③ビジネス検討を分割しマイルストーンを設定することで、プロジェクトの進捗状況が把握し やすくなり、適切なマネジメントが可能になる。 15 Copyright © 2013 IPA, All Rights Reserved 5.3. 実施案件の優先順位づけ 大枠で予算を取った後は、開発現場に権限委譲しているケースも多いのではないかと思われる。 自分の懐を痛めるという感覚がなければ使えるものは全部使う、つまり無駄な投資が発生するとい う方向に流れやすくなる。費用対効果は全体で見ることも必要だが、投資効果を個々の案件単位で 評価し、優先順位づけを行う（著しく効果が低いものは案件を取り下げる）ことを推奨したい。 取組みの概要 ・BSC（balanced scorecard）の 4 つの視点、あるいはそれに類する形式で効果を可視化し、費 用対効果等をベースに経営層による実施判定を行う。 ・案件ごとに施策、投資額、効果、優先順位を明確にする。各案件の効果は、定量的に表すこ とを原則とする。 ・必要に応じて、提案部署にシステム化による効果検証を実施させ、経営層に報告させる。 ・図 12 に BSC の例を示す。BSC は通常、「財務、顧客、業務プロセス、学習と成長」の 4 つの 視点を用いるが、この例では、 「財務、顧客、業務プロセス、カスタマ」と少しカスタマイズ している。なお、左下の大きな BOX は、BSC を構成する一つの BOX を拡大したものである。 案件名 業務施策 ・業務施策ｘｘｘｘｘ ・業務施策ｘｘｘｘｘ ＩＴ施策 ・ＩＴ施策ｘｘｘｘｘ ・ＩＴ施策ｘｘｘｘｘ 投資額：****万円 投資額：****万円 効果 ＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸ 図 12 BSC の例 ポイント ①プロジェクトとして実施したい案件を視覚的に表現することで、ステークホルダ間での情報 共有が行いやすい。 ②達成したい目的・目標と各案件との関連を明確にすることで、余計なシステム化施策（開発 案件）が入り込む余地をなくす。 ③費用対効果によって予め優先順位をつけておくことで、プロジェクトの途中で案件調整が必 要になった場合でも、速やかに判断することができる。 16 Copyright © 2013 IPA, All Rights Reserved 5.4. 多段階見積・多段階発注 ユーザ、ベンダ双方のコスト影響の極小化を目的として、多段階見積・多段階発注を実施する。 要件が確定していない時点の見積を予算とせず、実態に即した対応が必要である。 見積り時期とリスクの関係を図 13 に示す。工数やスケジュールはプロジェクトが進むにつれて具 体化、詳細化され、それとともにリスク（不確定要素）は減少する。事業戦略・事業計画やシステ ム化の方向性の段階でのスケジュール及び工数と、システム化計画や要件定義段階でのそれとの差 を課題だとする企業があるが、 上記のような理由から、両者の間に乖離が発生するのは当然である。 取組みの概要 ・ある時点で見極められている要件を基に見積を試算し、リスクを加味した上で、幅を持たせ た金額を算出して予算とする。 ・要件定義あるいは基本設計段階での規模（コスト）変動を考え、カットオーバーまでの一括 決裁は行わず、先ずは要件定義及び基本設計部分のみを決裁し、ベンダに発注する。 ・基本設計が終了した時点での見積を確定見積とし、詳細設計以降の決裁及び発注を行う。 見 積 額 妥当な見積 誤差 わずかな情報／ 高いリスク システム化 の方向性 システム 化計画 仮試算 試算 情報の充実／ 低いリスク 要件定義 設計 製作 時間 概算 確定 図 13 見積り時期とリスク （SEC BOOKS『経営者が参画する要求品質の確保』より） ポイント ①多段階見積・多段階発注にすることで、ユーザ、ベンダともにコスト超過リスクの低減が可 能となる。 ②要件定義あるいは基本設計終了時点でプロジェクトを評価することで、必要に応じて規模や スケジュールの調整ができる。 ③リスクを事業部門と共有し、回避策を打つかリスクとして抱えるかを早期に判断する。いず れの場合も事業部門のコミットメントが必要である。 ④予算の確定時に、見積額とは別にリスク対策費を計上（リスクの数値化）しておくのが望ま しい。 17 Copyright © 2013 IPA, All Rights Reserved 5.5. 開発体制への専任者の組込み 組織や体制に関する見積は甘くなりがちである。特に事業側担当者のシステム開発経験が乏しい ほど、そのような状況に陥りやすい。 “組織”としての開発経験は継承されにくいため、やはり有識 者の確保は外せない。それが難しい場合は、開発側からのフォローやウォッチ、兼務発令などの人 事施策も必要となる。 企画プロセスから要件定義プロセスに移る段階で、担当者が変わるケースがあるが、プロジェク ト当初から参画し、要求・要件の整理を担当した要員は、原則要件定義終了まで異動させないこと が望ましい。 取組みの概要 ・有識者や経験者のプロジェクトへの参画を必須とし、会社特有の緻密な業務仕様を持つシス テムの場合には、体制の半数以上を占めるようにする。 ・計画的な人材育成、異動計画を実施する。また、有識者や経験者のみならず、実際にシステ ムを使う部門を巻き込む。 ・プロジェクト編成時に「開発の規模、難易度、有識度」と「アサイン予定の要員の経験、ス キル」を マッチングすることにより、体制の妥当性を評価する。 ポイント ①事業部門の役割を明確化するとともに、精度の高い業務遂行を実現する。同時に、フォロー するシステム部門の負荷軽減を図る。 ②体制確保が難しい場合は、部門外有識者の確保、システム部門による支援など、次善の策を 早め早めに検討し、決定後は速やかに実施する。 報告者として、是非とも取り組んでいただきたいと考える課題と解決策を幾つか挙げたが、4 章 に記載したとおり、 他にもたくさんの課題と解決策が寄せられており、そこには多くの企業が悩み、 模索し、取り組んできた足跡があり、英知がある。 ［検討事項］ ［カテゴリ］という項目、あるいはフリーワード等を用いて、 【付録 1】超上流工程 における課題と解決策一覧.xlsx をじっくりとご覧いただきたい。 18 Copyright © 2013 IPA, All Rights Reserved 6. おわりに システムは「事業として実現したいもの」を支援するためのツールに過ぎず、システムあるいは その開発自体が最終的な目的・目標となるケースは稀である。繰返しになるが、システムによって 何を実現したいのかはユーザにしか決められない。ユーザが主導をとって、実現したいことを検討 し、決定する工程が「超上流」工程であり、他の何者もそれを真に代行することはできない。 とは言え、システム開発は協働作業である。ユーザだけでも実現できず、ベンダだけでも実現で きない。両者がしっかりと協調してプロジェクトを進めていくことが必要である。Win-Win の関係 を築けるように、そして一つでも成功プロジェクトが増えるように、本調査の結果が微力でも両者 の一助になることを願っている。 7. 付録 7.1. 超上流工程における課題と解決策一覧 外部ファイル参照： 【付録 1】超上流工程における課題と解決策一覧.xlsx 7.2. 超上流工程における課題のマインドマップ 外部ファイル参照： 【付録 2】超上流工程における課題のマインドマップ.pdf 以上 19 Copyright © 2013 IPA, All Rights Reserved