Software Engineering Center - IPASoftware Engineering Center 1 Information-technology Promotion Agency, Japan Software Engineering Center 超上流工程における課題と対応事例

1 Software Engineering Center

Information-technology Promotion Agency, Japan

Software Engineering Center

超上流工程における課題と対応事例

～アンケートで見えてきた、やっぱり取組むべき対策～

独立行政法人情報処理推進機構(IPA) 技術本部ソフトウェア・エンジニアリング・センター(SEC)

森下哲成

エンタプライズ系総合セミナー第2日：「ITサービスを取り巻く環境と要求」

2013年3月5日

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Software Engineering Center 2 エンタプライズ系総合セミナー, 2013-03-05 Copyright © 2009-2013 IPA, All Rights Reserved.

IPAはSECの設立以来、超上流工程の重要性を提唱し、「経営者が参画する要求品質の確保」「超上流から攻めるIT化の原理原則17ヶ条」「共通フレーム2007」等の書籍やSECセミナーを通じて発信してきた。

産業界では、超上流工程への意識が高まってきており、超上流工程における問題に対して、具体的な取り組みを始める企業が多数出てきている一方で、依然としてそれに起因するプロジェクトの失敗が後を絶たない。

超上流工程において、各企業がどのような課題認識を持ち、どのように解決しているのか、また、他社事例の共有に対するニーズがあるかどうかを確認する調査を実施した。

その内容をご紹介することにより、プロジェクトにおいて超上流工程を進める際のヒントを得ていただくことが趣旨である。なお、調査結果の詳細は、今月末に公開する予定である。

講演趣旨



1.1 事例収集の方法と考慮事項

ヒアリングシートを配布し、回収後内容を詳細に確認。

疑問点がある場合は、個別にヒアリングを実施。

偏りがないよう、ユーザおよびベンダの双方を対象。

ソフトウェア領域に限定せず、システム領域を前提。

対象フェーズは、超上流（事業戦略・事業計画、システム化の方向性、システム化計画、要件定義）に限定。

1．事例調査方針



1.2 ヒアリングシート

以下のシートに問題/課題および実践中の（あるいは考え得る）解決策/取組みを自由に記入。

1．事例調査方針

事業戦略・事業計画システム化の方向性システム化計画システム設計要件定義

企画プロセス開発プロセス要件定義プロセス

問題/ 課題

解決策/ 取組み

フェーズ

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNN 記入例



2．調査結果



2.1 協力企業

中堅・大手のユーザ、ベンダ各10社、計22名の方々。

2.2 情報共有ニーズ

ヒアリングに際し、超上流工程における問題/課題や解決策に関する情報共有ニーズについて聞いた。

【質問】超上流工程に関する他社の課題や解決策は参考になると思いますか？【回答】はい：18名（100％）いいえ：0名（無回答：4名）

活用方法：開発標準への取り込み、開発プロセスの改善、課題が顕在化したときの参考

共有形態：報告書・ガイドブック、フォーラム・ワークショップ、 HPでWeb公開

2．調査結果



2.3 全体傾向

事業戦略・事業計画、システム化の方向性、システム化計画、要件定義における「問題/課題」「解決策」の件数は以下の通り。（※同種の内容の重複あり）

2．調査結果

問題解決策フェーズ

２９１６事業戦略・事業計画

４６３１システム化の方向性

５４３９システム化計画

６０４３要件定義

計１８９１２９



2.3 全体傾向

事業戦略・事業計画のものは相対的に少なめ。全体を眺めると、各社とも色々な策を講じてきたことが伺える。

問題は「ユーザならではの」「ベンダならではの」というものは少なく、似たようなものが多い。

言い換えれば、どこの企業でも同様の問題を抱える可能性があるということである。

類似問題に対する他社での取り組みは参考になると思われる。特に、実践を経て既に定着しているものは（汎用的なものであれば）価値が高い。

2．調査結果



2.4 フェーズ別傾向

抽出した問題/課題を、ある程度の粒度でカテゴライズ。

結果は以降の通り。( )内は課題の件数。

2．調査結果

事業戦略・事業計画

・事業戦略・事業計画とシステム化計画の乖離（12）・対応すべき課題の優先順位が曖昧（8）・ユーザニーズの把握不足（5）・組織体制、役割分担が不明確（4）




2．調査結果

システム化の方向性

・事業戦略・事業計画とシステム化計画の乖離（10）・組織体制、役割分担が不明確（10）・商品、サービスの検討不足（9）・プロジェクトの目的が不明確（7）・契約、見積が不十分（3）・業務知識、経験、スキルの不足（3）・組織ビジョンが不明確（2）・既存システムの仕様が不明確（1）・新技術、新サービスの採用（1）



2．調査結果


システム化計画

・組織体制、役割分担が不明確（13）・契約、見積が不十分（13）・開発方針、開発計画が不十分（7）・業務知識、経験、スキルの不足（6）・商品、サービスの検討不足（3）・プロジェクト管理が不十分（3）・プロジェクトの目的が不明確（3）・費用対効果が不明確（3）・対応すべき課題の優先順位が曖昧（2）・既存システムの仕様が不明確（1）



2．調査結果


要件定義

・要件定義不足、レベルの甘さ（26）・組織体制、役割分担が不明確（13）・業務知識、経験、スキルの不足（7）・要件定義の終了条件が曖昧（6）・プロジェクトの目的が不明確（4）・契約、見積が不十分（3）・リスク管理の甘さ（1）



2.4 フェーズ別傾向（サマリ）

事業戦略・計画では「システム化計画との乖離」「課題の優先順位付け」が多い。

システム化の方向性になると、上記に加えて「組織体制、役割分担が不明確」「商品、サービス検討不足」「プロジェクト目的が不明確」が問題となってくる。

システム化計画では「契約、見積が不十分」「開発方針、開発計画が不十分」という問題が増える。

要件定義に至っては「要件定義不足、レベルの甘さ」が圧倒的に多い。

2．調査結果



2．調査結果

0 5 10 15 20 25 30 35 40

事業戦略・事業計画とシステム化計画の乖離

対応すべき課題の優先順位が曖昧

ユーザニーズの把握不足

組織体制、役割分担が不明確

商品、サービスの検討不足

プロジェクトの目的が不明確

契約、見積が不十分

業務知識、経験、スキルの不足

組織ビジョンが不明確

既存システムの仕様が不明確

新技術、新サービスの採用

開発方針、開発計画が不十分

プロジェクト管理が不十分

費用対効果が不明確

要件定義不足、レベルの甘さ

要件定義の終了条件が曖昧

リスク管理の甘さ

事業戦略・事業計画



要件定義



2．調査結果

カテゴリ問題/課題解決策/取り組み

3


中期計画上の各項目が、組織の経営・戦略にどのように寄与するのか曖昧となっているため、費用対効果の観点から実施すべきでない（劣後する）案件についても、システム化を前提とした計画項目が策定される。

システム化の実施にあたり、事前に、ＢＳＣの４つの視点で効果を可視化した上で、費用対効果等による経営層による実施判定を行うプロセス（ＩＴ投資管理プロセス）を導入。※計画策定前ではないものの、無駄なシステム化の防止に繋がっている。

4


中期計画上の各項目が、組織の経営・戦略にどのように寄与するのか曖昧となっているため、提案部署（ユーザ部署）の効果に対する責任意識が乏しく、ユーザ部署によるシステム化の検討自体が消極的となっている。その結果、システム部門が業務プロセスを含めた要件定義を策定することとなり、後工程で認識齟齬を招く要因となる。

ＩＴ投資管理プロセスにおいて、提案部署にシステム化による効果検証を実施させ、経営層に報告するという、効果測定スキームを定義した。

6


事業戦略や事業計画が各論に落とし切れていない（曖昧な部分、いい加減な部分がある）ため、結果的にシステム化の方向性やシステム化計画が大きく変わることがある。

プロセス全体をコーディネートするロールのチームを設置し、課題の階層的な見える化（企業価値⇒経営戦略・事業戦略⇒プロセス戦略・情報化戦略、、、）とステークホルダ間の意見調整経過の見える化をしながらプロジェクトを進めている（事案によるが顧客の合意が取れれば）

22

ユーザニーズの把握不足

超上流工程・プロセスの作業というものは、なかなかプロセスや成果物の標準化だけで対応しきれるものではなく、過去の実績、事例などを共有することで、対応できないかと模索している。

全社的なノウハウ共有の基盤を構築し、横展開している。そこに提案書や上流工程の作業標準などの共有可能な情報（マスキングを行う）を現場・プロジェクトが提示し、（アクセス権など対象者の範囲もあるが）開発部門・要員が参照可能な状態にしている。この仕組みにより、過去の事例を参考にすることで、業種・業態やシステム化方式など共通的な切り口から上流工程対応のヒントや留意点、実際の成果物作成、計画策定などに利用している。

26対応すべき課題の優先順位が曖昧

事業領域ごとに戦略が乱立し、会社としての統一感がなく、投資の優先度が付けられないため総花的な戦略となることが多い。

製品/サービスと事業をマトリクス化し、各領域の重要度を定義することにより、投資を集中すべき事業・製品/サービス領域の優先順位付けを行う。

システム化の方向性事業戦略・事業計画

2.5 問題/課題と解決策（抜粋）



2．調査結果


3

プロジェクトの目的が不明確

中期計画上の各項目が組織の経営・戦略にどのように寄与するのか曖昧となっているため、システム化を検討する際に、本来目的（効果）の意識が欠如し、中期計画の各項目を実施すること自体が目的化してしまい、本来の効果を見いだせないシステム化を実現してしまう危険性がある。

・システム化の方向性を検討するにあたり、初動として、提案部署から「本来の目的」など必要情報を聞き出し合意を得るよう、システム部門の担当者向けの行動のガイドラインを策定した。・要件定義書に「目的（背景）」を明記している。

4


新商品・新サービスの場合、成功するモデルがどういうものかわからないため、どれだけ費用をかけてシステム化を行えばよいか判断できない

全く新規のサービスで投資金額が大きい場合には、規模を限定したトライアルサービスとしてリリースをして、トライアルサービスの評価を行った上で、本格的な投資を行うか判断をする。

プロセス全体をコーディネートするロールのチームを設置し、課題の階層的な見える化（企業価値⇒経営戦略・事業戦略⇒プロセス戦略・情報化戦略、、、）とステークホルダ間の意見調整経過の見える化をしながらプロジェクトを進めている（事案によるが顧客の合意が取れれば）システム化をしないことも視野に入れた複数の代替案の抽出と費用対効果（システム化価値）の検討をプロセス内に組み込んでいる

12


システム全体の最適化には、テクノロジーだけでなくシステムで実現している業務を深く理解している必要があるが、そのような要員を長期間確保することが難しい。

お客様の業務やその実現のためのアプリケーションについて、そのノウハウを整理し、横展開できる形にまとめることで、個人ではなく組織に蓄積する仕組み、プロセスを構築中（”アセット化”の取り組み）

29


企業や団体、組織における中・長期的な経営・事業戦略を受け、コンピュータシステムが関与する情報戦略を立案することが難しい。システム化の方向性を見据えた、情報システム構想を立案することができない。

自社内の開発標準群に「企画プロセス編」を構築し、全社横展開を図っている。（共通フレームを参考にしている。）作業プロセスやそこで必要な入力情報、プロセスを経て作成する成果物などが標準化されているので、企画プロセスを行う要員がそれらを参考に、成果物の標準フォームを用いることで作業が可能になっている。作業の抜け・漏れがなく、作成する成果物も明確なため、ユーザとの合意形成や見積りなどにも効果がある。また、プロセスや成果物が標準化されているので、当該作業の完了基準も明確となり、妥当性の確認が可能となる。

6

新しい商品やサービスについての検討が遅れ、システム化の方向性（目的や範囲など）が明確に定まらないまま、システム化計画に着手する傾向がある。





2．調査結果


1


システム化について、ユーザ部署が主体的かつ積極的に検討すべき、システム化に併せて必要な業務施策（規程改正や重要なステークホルダーへの合意を得る等）について、対応漏れや遅延が発生する。※それを補うため、システム部門の担当（実質PM)が、必要以上の範囲（ユーザ部署の責任範囲）を負ってしまい、本来注力すべきシステム化の活動に支障を来すケースが散見される。

・システム化計画（ステークホルダーマネジメント計画を含む）について、ＰＭＯが支援することで、WBS自体の漏れ等を防止している。・ＰＭが必要以上の範囲まで負わないよう、事前にPMがステークホルダーマップを作成し、各ステークホルダーへ合意を得る部署（フロント）や関連部署（バックエンド）を整理させるようにしている。（PMOが支援）

4契約、見積が不十分

計画の早い時期ではプロジェクト全体、特にシステム開発に必要な投資額の見積が難しく、システム設計以降になってから膨らみがちである。

早い段階でも可能な限り機能を見積りを行うことと、期間を決めて計画自体に修正する必要がないか調整を行い、初期段階の費用と大きくぶれていないか確認しつつ進める

13


プロジェクトの遂行にあたり、社内開発プロセスは定義されているが、実際は、そのプロセスに完全に従って進めてもらえるように、第三者監査が十分に機能していない。そのため、各開発フェーズにおいて、タスクや視点の抜け漏れが発生している。

第三者視点での、プロジェクトマネジメント品質確認プロセスを導入した。これにより、プロジェクトの進め方を客観的に評価して、担当・マネージャー・上層部に報告し、適宜改善を図ってもらえるようなプロセスを導入した。また、セルフチェックシートの導入により、各マイルストーン単位で担当プロジェクトリーダーが実施すべきタスクの遂行状況確認や、ケアしなければいけないマネジメント視点を再確認することができるようになっている。

18商品、サービスの検討不足

超上流からシステム側が入って検討しようとしてもサービス仕様が決まらないため、システム仕様も決められない。

情シス内に相談窓口を設け、構想段階から検討できる体制を構築。

27

業務知識、経験、スキルの不足

ユーザ部門が，業務フロー図，業務処理記述書等を記載出来なくなっている。特に，再開発システムの場合は，システム化範囲がブラックボックス化している場合が多い。

ユーザ部門と，システム部門での企画プロセス・要件定義プロセスでの成果物作成の責任範疇の明確化を実施した。また，情報部門にＴＳＯ（テクニカルサポートオフィス）を設置し，上流工程におけるシステム化のサポート体制を構築した。

34

開発方針、開発計画が不十分

システム化計画、所謂超上流工程のプロジェクト計画の妥当性を評価することが難しい。

ユーザ側が企画プロセスを行うケースが多いとも思われるが、企画プロセスが行われているかという観点でも、全社開発標準の「要求定義」編を利用しており、チェックリストを構築している。RFPをいただく際、もしくは入力情報としての成果物をいただく際など、超上流工程が適切に行われているのか、不十分な点はどこにあるのかなどをチェックし、前提条件やリスクマネジメントに取り込み、要件定義以降の見積りや計画に反映している。




2．調査結果


11


性能要件（レスポンス等）を確実に満たせるようにしたいが、上流時点ではその保証が難しく、最悪の場合はシステムテストの性能確認段階で、要件変更や取り下げを余儀なくされ手戻りになる。

・要件定義段階から可能な処理方式を限定してしまい、その中で実現できない要件は原則不可とした。（例外の処理方式を採用した場合は、性能を保証できないことを利用部門へ説明した。）・請負契約に性能保証入れる。（そのために、前提となる環境や利用条件を明確にした。）

23業務知識、経験、スキルの不足

部門内に新しい技術情報に長けた人材が不足している（非機能要件）

育成やローテーションなどを見直している。全社または部門内で育成ワーキングを立ち上げ、スキルの底上げを図っている

37


要件定義以降、つまり早い段階での見積りや計画の妥当性の評価が難しい。

全社的な有識者の認定レビューアを選任しており、第３者レビュー制度を仕組み化している。その中で、要件定義工程での見積りや計画レビューを実施することで、その妥当性を確認している。要件定義の見積りは開発標準やプロジェクト管理の標準に基づいたWBSを構築しており、プロジェクトでテーラリング（修整）しながらWBS見積りを行っている。FPを利用した係数モデル見積りや、（想定・仮説の割合が多い段階であるが）画面・帳票見積り、機能を想定した類推見積りなど、複数見積りにより精度向上を図っている。

38


要件定義について適切な作業ができず、QCDを確保できない。また設計工程に必要な情報が引き継がれない。

開発標準群での「要件定義」編を構築し、全社横展開している。また、全社のノウハウ共有の基盤が構築されているのだが、ＪＩＳＡ要求工学ＷＧの要求管理・開発のベストプラクティス報告書などを共有し、要件定義での活用ポイントや留意点など現場での活用を推進している。VDM形式手法による上流工程の明確化について、現場主導で活動を行っている。

39

要件定義不足、レベルの甘さ

要件定義時の非機能漏れや不明確な事でトラブルに至るケースがある。

IPA・SECからの非機能要求グレード関連を参考に、非機能要件チェックワークシートなどを標準文書として全社展開を行っている。また、ユーザビリティの視点を要件定義開発標準に組み入れ、顧客満足度向上に寄与するユーザ視点の品質向上に取り組んでいる。

要件定義



3.1 課題の分類と仕分け

課題の先行関係

ex. 課題Aによって課題Bが発生した。つまり、課題Aが潰せていれば、課題Bは発生しないはずである。

課題の類似性

ex. 課題Cと課題Dは本質的には同じものである。よって課題は同じカテゴリに分類することができる。

課題の類推

ex. 課題Eが発生していれば、通常は課題Fもあるはずである。

3．課題の整理と分析




3.1 課題の分類と仕分け

マインドマップを利用



3.2 超上流の5W2H


Who 誰が？What 何を？When いつ？Where どこで？Why なぜ？How どうやって？How Much いくらで？



3.2 超上流の5W2H

Who 組織・体制What 解決すべき課題When 計画・納期Where 対象範囲Why 目的・目標（効果）How 実現手段How Much 投資額




目的・目標（効果）

解決すべき課題

対象範囲

組織・体制

実現手段

計画・納期投資額

3.3 5W2Hの関係性

目的・目標（効果）が全ての起点。ここが決まらないと全てが決められない…

…はずなのに、なぜかプロジェクト化される不思議。




3.4 5W2Hで再カテゴライズ事業戦略・事業計画とシステム化計画の乖離 Why 目的・目標（効果）対応すべき課題の優先順位が曖昧 Where 対象範囲ユーザニーズの把握不足 What 解決すべき課題組織体制、役割分担が不明確 Who 組織・体制商品、サービスの検討不足 What 解決すべき課題プロジェクトの目的が不明確 Why 目的・目標（効果）契約、見積が不十分 How Much 投資額業務知識、経験、スキルの不足 Who 組織・体制組織ビジョンが不明確 Who 組織・体制既存システムの仕様が不明確 Where 対象範囲新技術、新サービスの採用 How 実現手段開発方針、開発計画が不十分 When 計画・納期プロジェクト管理が不十分 How 実現手段費用対効果が不明確 Why 目的・目標（効果）要件定義不足、レベルの甘さ Where 対象範囲要件定義の終了条件が曖昧 When 計画・納期リスク管理の甘さ How 実現手段




3.5 優先度の高い課題の設定

① 分析した結果を基に、取り組むべき課題を設定。

5W2Hの関係性

課題発生のメカニズム（背景、要因等）

解決策の実施状況（どの社でも実施可能では？）

② 課題に対する解決策を設定。

対策を実施すべきフェーズ

課題：解決策 = m：n




4.1 事業戦略・事業計画～要件定義

一定規模（ex.1億円）以上の案件に投資決裁会議を適用。基準（ex.ROI、投資回収年）をクリアした案件を実施。

事業部門は投資目的を決定し、どのような商品、機能、業務プロセスが必要なのかを検討。

後に定量的に評価できるよう、目標（売上、利益、KPI等）を数値化して設定。

この仕組みと、システム開発の実施判断あるいはゲートレビューと関連づけ。

4．取り組むべき課題と解決策

①投資マネジメントに関する仕組みを導入する



4.1 事業戦略・事業計画～要件定義

ビジネス（目的・目標）の検討が不十分な状況にも関わらず、システム化の方向性の検討やシステム化計画に着手してしまい、それ以降の工程で手戻りが発生する。

コストと効果の整合性検証が困難で、システム化による効果検証が行えない。当初見込んでいた通りの効果が出ているかどうかを定量的に測定することができない。


特段の対策を打たないと…



システム部門

事業部門

主管部署 (事務局)

モニタリングフェーズ実行

投資判断フェーズ

ポイント

ビジネス投資決裁

ビジネス投資決裁書

決裁会議

｢投資・ＩＴ戦略｣ (フォーマット)

全社マネジメント＋システム部門

｢事業戦略｣ (フリー)

●チェックポイントに従って記入

●ゲートレビュー

■要件定義(新たなCash発生)前に実施 ■商品P/L、C/F費用対効果等で判断 ■費用対効果、KPIを目標として設定 ■Q単位で決裁案件を取締役会で共有

■投資額・効果目標の

最終化 →経済的費用対効果 →KPI目標

システム部門

個別会議

システム投資決裁

システム投資決裁書

●ゲートレビュー

(フォーマット)

●チェックポイントに従って記入

システムカットオーバー 1ヵ月後をメドに実施

システム効果測定

システム部門

効果測定報告書

●レビュー

■達成状況評価 ■｢打ち手｣の協議

(フォーマット)

ビジネスモニタリング

全社マネジメント

●事業計画に先立ちまとめ

■マイルストーン毎の達成状況評価 ■｢打ち手｣の協議

会議体


取り組み事例①





実施の効果

効果目標を具体的に設定することで、誇大効果案件が激減

投資の目的（効果）と内容（システム化要件）の整合性が向上

目的の明確化により、問題単純解決型から目的達成型へ進化

PDCAサイクルにより、早期に次の打ち手を検討





有効な視点

グロスで効果が出ていても、投資内容を細分化すると効果が出ていなかったり、逆に投資（施策）が足りないケースがある。

メリデメを整理し、複数案を検討することで、効果の大きい案が導出されることがある。（案件のMust/Wantの整理、必然性の検討）

期間、コストキャップ、チェックポイントを明確化し、条件付き決裁OKもあり。



4.2 事業戦略・事業計画～システム化計画

事業部門は事業計画に基づき、ビジネスの目的・方針を決定するとともに、どのような商品（サービス）、機能、業務プロセスが必要なのかを検討。

システム部門は事業側の検討状況を見ながら、システム化検討に入れるかどうかを見極め、事業側の議論、検討が不十分であると判断した場合は、システム化検討・計画フェーズは凍結。

次フェーズに入る場合はゲートレビューを実施。


②超上流のプロセスを定義する



4.2 事業戦略・事業計画～システム化計画

事業部門のパワーやスキルが不足している、あるいはそれらを理由に、本来自らが主導すべき事業計画（商品・サービス等ビジネスの検討やプロセス改善など）までも開発側に頼り切る。

目的や方向性が定まらないままプロジェクトが進み、後工程で要件の抜け・漏れや誤解が発覚したり、費用対効果の薄いシステムが開発される。





超上流工程


取り組み事例②

ビジネス検討／プロジェクト定義

要件定義

設計・製造

テスト・移行

運用・保守

ゲートレビュー②

ゲートレビュー③

ゲートレビュー④

ゲートレビュー④

ゲートレビュー⑤

ゲートレビュー⑦

プロジェクト評価

ゲートレビュー①

投資決裁①

効果測定

投資決裁②



システム部門主導

事業部門主導



ビジネス検討／プロジェクト定義の細分化

目的・方針決定サービス・機能・

目標決定ビジュアル化

システム化計画（プロジェクト定義）





実施の効果

サブフェーズ間にマイルストンを設定、ゲートレビューと合わせ超上流でのマネジメントが可能

成果物定義とともに、担当者、納期を明確化（"何となく進める"を排除し、抜け漏れを防止）

事業部門自らやりたいことを集中検討し、ステークホルダ間で合意（認識齟齬の排除）

事業部門の検討状況を見ながら、システム化計画に着手（無理に先に進めない）



4.3 システム化の方向性～システム化計画

ある時点で見極められている要件を基に見積を試算し、不確定要素を加味した上で、ある程度の幅を持たせた金額（=予算）を算出する。

要件定義時のコスト変動を前提に、C/Oまでの一括決裁は行わず、先ずは要件定義部分（できれば基本設計含む）のみ決裁してベンダに発注する。

要件定義終了時点で再度見積り、残りの部分の決裁および発注を行う。


③多段階見積・多段階発注を実践する



4.3 システム化の方向性～システム化計画

コストの乖離が大きくユーザとベンダ双方が納得できる見積になかなかならない。見積を出し直すたびに、その説明に大きな労力が必要となり、見積の精査と合意に、多大な時間を費やしている。

事業計画やシステム化の方向性の段階での超概算見積をもって予算確定させ、その数字がひとり歩きする。不確定要素に関する合意がなく、規模が膨れた場合でも、初期見積に固執する。






取り組み事例③

実施の効果

多段階見積にすることで、ユーザ、ベンダともにコスト超過リスクの低減が可能

要件定義終了時点のProjの客観的評価により、必要に応じて規模やスケジュールの調整が可能

全体予算の確定時に、見積額とは別にリスク対策費を計上（不確定要素の数値化）

事業部門と不確定要素を共有し、早目に回避策を打つかリスクとして抱えるかを判断



4.4 システム化計画～要件定義

有識者や経験者のプロジェクトへの参画を必須とし、会社特有の緻密な業務仕様を持つシステムの場合には半数以上の体制を構築する。

計画的な人材育成、異動計画が必要。また、有識者・経験者のみならず、実際にシステムを使う部門を巻き込む。

プロジェクト編成時に「開発の規模、難易度、有識度」と「アサイン予定の要員の経験、スキル」をマッチングすることにより、体制の妥当性を評価する。


④開発体制には原則専任者を組み込む



4.4 システム化計画～要件定義

システム化計画が遅れたり、要件定義以降のスケジュールや品質面で問題が発生する。

事業部門が、業務設計、業務仕様の詳細化などを十分に行うことができず、要件定義以降に手戻りが発生する。

要件を正確に抽出、伝達することができず、要件の抜け・漏れや内容の不備（誤解、不足、不整合など）が発生する。






取り組み事例④

実施の効果

事業部門の役割の明確化と精度の高い業務遂行、フォローするシステム部門の負荷軽減

要件定義、基本設計の精度の向上、システム全体品質の確保

どうしても体制確保できない場合は、早め早めに次善の策を検討、実施（部門外有識者の確保、システム部門による支援など）



ご清聴ありがとうございました

Documents

Software Engineering Center - IPASoftware Engineering Center 1 Information-technology Promotion Agency, Japan Software Engineering Center 超上流工程における課題と対応事例