講演2 ベンダーマネジメント v1.0...2014/12/03 · Management Innovation by ICT Solution...

CIO-Partners Consulting Service for Management Innovation

Management Innovation by ICT Solution

ＣＩＯパートナーズ株式会社http://CIO-Partners.co.jp


【講演２】ベンダーマネジメントのツボ

２０１４年１２⽉３⽇

ＣＩＯパートナーズ株式会社マネージャー安⽥信弘



2

第２部の構成

1. ベンダーマネジメントとは

2. 情報システム部⾨の業務とベンダーマネジメント

3. ベンダーマネジメントを実現するための前提条件

4. プロジェクトの各局⾯とベンダマネジメント４－１システム選定４－２契約４－３プロジェクト管理４－３（１）開始４－３（２）実⾏４－３（３）検収４－４終結

5. プロジェクトを成功させるために

Copyright(C) 2012-2014 CIO-Partners co.,Ltd. All rights reserved.



3

１．ベンダーマネジメントとは

情報システム部⾨が抱えられる⼈員には限りがある。情報システム⾃体も⾼度化・複雑化し⾃社要員のスキルだけでは対応しきれない状況もあり、開発プロジェクトにおいて⼈的資源やノウハウを外部に求めることは、⽇常的な⾏為となっています。

しかしプロジェクトの失敗原因としてベンダーマネジメントの不⾜がクローズアップされ、訴訟例も増えています。


つまり、ベンダーマネジメントとはシステム部⾨の限られたテーマではなく、

企業の成⻑を司るコア・コンピタンスに⼤きく関係

ベンダーマネジメントとは…

1. 開発・運⽤・保守の各々の局⾯で、取引先が提供する付加価値（役務・サービスや納品物）をＱ（品質）、Ｃ（コストの妥当性）、Ｄ（納期）の観点から発注者（依頼者）の⽴場で、継続的に管理、検証する事

2. また、特に企画局⾯において経営戦略に沿った施策（企画）の具体的な検討・⽴案に向けて技術動向、他社動向等の検討材料（情報）を収集すると共に、ニーズ（要件）に⾒合った適切なパートナーを選定する事



4

２．情報システム部⾨の業務とベンダーマネジメント


経営⽅針に沿った情報システムの実現

情報システム化戦略や年度予算の⽴案と実⾏技術動向、他社動向の評価と採⽤⽅針の決定課題の分析・評価と優先順位の決定仕様・要件の決定社内提案（コンサルティング）

ＴＣＯの最適化（ＩＴコストの削減）

発注先の評価と選定・⾒直し発注価格の決定（妥当性評価）と予算管理投資効果の測定・評価

納品物（成果物）の品質評価と検収ベンダー業務内容の評価・検証

ＩＴコンプライアンスの遵守

契約管理資産管理（固定資産、情報資産、知的財産）社内ルール（⽅針や基準、⼿続き等）の⽴案利⽤者に対する適正利⽤の促進内部統制対応（アクセス管理など）

システムの安定稼動

部員の確保・育成ヘルプデスクと障害対応（⼀次対応）システムの稼動状況の監視（モニタリング）⽇常的な運⽤・管理メンテナンス（データやマスタを含む）

情報システム部⾨の４⼤ミッション

業務量：⼤

戦略性：⾼い

⾚字（⾚線）部分を中⼼に、ベンダーマネジメントは、様々な業務で必要に･･･

図：情報システム部⾨のミッション・業務⼀覧



5

３ベンダーマネジメントを実現するための前提条件

ベンダーマネジメントを⾏うに当たって以下の項⽬についてユーザーとベンダー双⽅の合意形成が取れていることが前提となります。

1.外注の⽬的と範囲の明確化ユーザーとベンダーとの間で利害が対⽴して、プロジェクトの実⾏の障害となることが少なくありません。事前に「外注の⽬的と範囲」を明確にしてプロジェクト全体で合意を得ておくことは重要です。

2.役割と責任の明確化ユーザとベンダーにおいて役割と責任が曖昧なままプロジェクトを開始しがちです。「決定事項と思っていたら、実は未決定のまま進んでいた」「課題の検討を担当者が忘れていたため、課題が放置されていた」といったことが発⽣しないよう、計画段階で役割分担を取り決めておくことで、タスク毎の実⾏責任を明確化する事が重要です。

3.丸投げはしないユーザ企業も積極的にシステム開発プロジェクト管理に関与する業務改⾰の⼀環として、システム開発プロジェクトは実⾏されます。ベンダーが請け負ったＳＩプロジェクトでは、ベンダーが開発プロジェクトの遂⾏責任を持つわけですが、システム開発を完了させ業務改⾰を予定通り実現するためには、ユーザーもベンダーの報告だけでなく、開発プロジェクトの状況を正しく把握すべく、開発プロジェクト管理に積極的に参加していくことが必要です。




6

４．プロジェクトの局⾯とベンダーマネジメント

プロジェクト局⾯に合わせたベンダーマネジメントが重要です。


構想要件定義基本設計詳細設計・開発テストＰＪ

局⾯本番稼働

ベンダー

マネジメント

局⾯

システム選定

契約①

ＰＪの管理

契約②

ＰＪの管理

ＰＪの管理

ＰＪの管理

契約③

運⽤管理

社内ＰＪチーム結成

ＲＦＰ提⽰

契約締結

キックオフ

要件定義書納品

契約締結

要件定義ルールの合意形成

︵キックオフ︶

基本設計書納品

︵基本設計ルールの合意形成︶


詳細設計書納品

︵開発ルールの合意形成︶


テスト仕様書・ソース納品

︵テスト運⽤ルールの合意形成︶

契約締結

運⽤開始

運⽤管理ルールの合意形成



7

４．１システム選定

システム選定の流れは、以下の通りとなります。

– プロジェクトの⽬的に沿って外注化範囲と⽬的を設定します。– 事前に複数の候補ベンダーを選出と情報収集をしておき、ＲＦＰに基づいた提案をベンダーに依頼します。

– ベンダーからの提案を受け、客観的に公平な評価を実施したうえで、システム選定を⾏います。

1. プロジェクト⽬的に沿った機能要求事項を洗い出し、ＲＦＰにまとめます。

2. ベンダーに依頼する業務範囲と⼯程（発注スコープ）を決定し、いつまでにどのような⽅法（⼊札、数社による競合、特定ベンダーとの交渉）で、どの程度のコストと納期で発注するかを決めます。

3. 発注スコープに内在するリスク分析を⾏い、契約形態（請負・準委任・派遣等）と契約条件・条項を決め、候補ベンダーへＲＦＰを提⽰します。

4. ベンダー提案の評価シートを予め作成し、数値化して評価します。【評価項⽬】

– 技術⾯– マネジメント⾯– 価格⾯




ベンダーとの契約で重要なのは、「きちんとした契約を取交わす＆⾒直す」事です。

局⾯に応じた契約形態をとる新システム導⼊の際、要件等をまとめる局⾯と、その後の設計〜開発、テスト局⾯では、対価の対象が異なる事が多い。（※また、運⽤・保守の際にも、多くの場合で同様）

こうした場合、対価の対象が異なる契約を、「⼀括受託」などの形態でまとめて契約するのではなく、各々の局⾯に応じて、契約形態を変更する事が、相互の権利関係を明確にする上でも望ましい。

• 役務に対価を⽀払う（例：要件定義など） → 準委任契約• 引き渡されるシステム⾃体に対価を⽀払う（例：設計・開発局⾯など） → 請負契約

契約内容をきちんと詰めるベンダーとの取引関係の中で、特にリスクが⼤きい項⽬は、予め契約内容を双⽅で協議し、合意形成しておく事が望まれる。

具体的には、①知的財産に関する権利関係、②再外注（⼆次請け、三次請け）、③ベンダーの管理責任、④契約の更新、⑤（特に役務の）サービスレベル、⑥瑕疵担保責任の範疇、保障期間などはベンダーの「⾔う通り」に契約して後々、問題とならない様に注意する必要がある。

妥当性のある⾦額で契約する「⼀式」などの内訳が分からない⾒積りや、ＳＥのスキルと作業に要するスキルの⽐較検証が出来ない⾒積りでは、妥当性のある⾦額での契約は望めません。

また、「相⾒積り」による検証のみならず、経年効果（ベンダーのスキル蓄積効果）を考慮に⼊れた契約⾦額の⾒直しが重要といえる。

8

４．２契約




納品検収

契約締結

ルール合意

要件定義書作成

内部レビュー

内部レビュー

納品検収

ルール合意

基本設計書作成

内部レビュー

納品検収

ルール合意

詳細設計書作成

内部レビュー

納品検収

ルール合意

詳細設計書作成

４．３プロジェクトの管理

請負型のプロジェクトにおいて、管理実⾏主体はベンダーにあります。但し、ベンダーに管理を丸投げするのではなく、ユーザーも主体的にプロジェクトの各局⾯に応じたプロジェクト管理のＰＤＣＡサイクルを回していく事が必要です。


要件定義

基本設計

詳細設計・開発

テスト

各局面毎に、検収を受けた成果物が次局面に流れる

9



10

４．３プロジェクト管理（１）開始

ユーザーが効果的にベンダーマネジメントを実施するためには、プロジェクトの開始前に、実施可能な仕組みを作り、ベンダーとの合意をもって役務・提供や成果物の提供を受けることが必要です。

① ユーザー、ベンダー双⽅でプロジェクト⽬標を共有する。

② 会議体の設定を⾏い、会議の⽬的と参加メンバーの決定を⾏う。（以下は例）• 週次進捗会議 …各作業項⽬の進捗確認と課題の状況整理と対策検討• ステアリングコミッティ …進捗上の懸念事項・課題について対応⽅法の決定指⽰

③ 開発スケジュールや品質管理についての管理指標の作成と管理⽅法等については、必ず確認します。

• 開発スケジュールの⽴案と、詳細化したＷＢＳによる進捗管理• 成果物の明確化（作成者と合意形成の相⼿も明⽰する）• 品質管理⽅法（成果物の検収時期と検収基準）ルールの作成• 開発標準（ルール）の作成• 要員・開発体制の提⽰（と妥当性チェック）• 次フェーズ移⾏の基準

④ ベンダーが社内管理で使⽤した資料を使った進捗会議を⾏うことも⾮常に有効です。多くのベンダーが社内管理⽤として使⽤しているプロジェクト管理ツールを評価・確認して、利⽤可能なものは活⽤していく事が重要です。




11

４．３プロジェクト管理（２）実⾏

ベンダーの作業状況は把握しにくく、⾃社作業と同じレベルで管理することは不可能です。請負契約・準委任契約では、どこまで踏み込んで管理するかも難しい問題であり、プロジェクト管理はポイントを絞って⾏うことが要求されます。以下の管理を中⼼としたベンダマネジメントのＰＤＣＡサイクルを実⾏することが重要です。


①進捗管理〜週次の進捗会議、報告書内容に基づき進捗状況をチェックするＷＢＳを基に予定と実績を対⽐することで作業の状況を⾒える化し、対応を検討します。現状を（特に悪い報告）もれなく把握するためには、ベンダーとの関係を密にとり、進捗・品質・問題等が⾃然にとれるような関係になることが求められます。

②課題管理〜発⽣した問題・課題を個別管理する発⽣した問題や検討課題を早期に報告管理するルールを徹底させます。ポイントは、①対象の課題の状況（誰がボールを持っているか・期⽇までに対応可能か）と、②対応の完了は対象となる成果物に反映させて終了とすることです。

③リスク管理ユーザーが⾏うリスク管理では、ベンダーのリスク管理の状況を評価し、不⼗分と判断した場合には、ユーザーの視点でベンダーを⽀援しリスク管理を徹底させることが必要です。気になったリスクを進捗会議等の場で確認して、「気づき」を与えることも重要です。

③品質管理〜納品・レビュー計画に沿って随時レビューを実施する検収時に不具合を発⾒（＝即）進捗の遅れに繋がります。これを避けるため、納品前の事前チェック・レビューの実施、テストプランの事前レビューを⾏うことと局⾯移⾏での承認プロセスで成果物のレビューを効率的に⾏うかが重要です。



12

４．３プロジェクト管理（３）検収（１／２）

契約に記載されている納品物がもれなく納品されているか、品質は次⼯程に回しても問題はないかレビューを⾏い、検収します。成果物の品質が低ければ、下流⼯程の成果物の品質がそれ以上になることはありません。

プロジェクトの各局⾯により検収内容は異なり、必ず上流局⾯での成果物が検収の基準となります。

詳細設計書のレビューまで必ず⾏う。但し、詳細設計書の記述内容がシステム寄りで、ユーザーに記載内容が判らないケースも多く⾒受けられます。詳細設計書の記載内容についてもユーザーが確認可能なように、何をするプログラムなのかをプログラムの概要に記載し、新業務フローとの関連が取れるような形で作成することが必要です。さらに、変更管理についても記載していく事で、設計書の履歴を確認できることも重要です。


局⾯成果物検証の基礎

構想ＲＦＰ

要件定義要件定義書ＲＦＰ記載の機能要件

基本設計基本設計書要件定義書の「課題に対する実現⽅法」、「機能⼀覧」等

詳細設計詳細設計書基本設計書の「新業務フロー」等



13

４．３プロジェクト管理（３）検収（２／２）

テストの局⾯についても、単体テスト、結合テスト、総合テスト、ユーザーテストの局⾯がある。それぞれのテストの⽬的は異なっており、開発の各局⾯の要求事項が満たされているかを確認する場であり、特に受⼊テストは開発局⾯最後の重要な検証となります。


局⾯成果物検証の基礎

単体テスト単体テスト仕様書・報告書テスト仕様書

結合テスト結合テスト仕様書・報告書詳細設計書・テスト仕様書

総合テスト総合テスト仕様書・報告書基本設計書・テスト仕様書

受⼊テスト受⼊テスト仕様書・報告書要件定義書・ＲＦＰの機能要件

基本設計

詳細設計

開発

総合テスト

結合テスト

単体テスト

要件定義受⼊テスト



14

４．４終結

開発プロジェクトが終息すると、以下の項⽬を確認して、検収書をベンダーに渡し、⽀払を⾏うことになりますが、プロジェクト終了時のゴタゴタの中で漏れ等を発⽣させないため、予め確認項⽬をチェックリスト化しておくことが有効です。

1.最新化された成果物がすべて納⼊されたことの確認。2.瑕疵担保責任期間・保証期間の確認。3.開発プロジェクト後の運⽤・保守について、システムに関する様々なスキルが運⽤・保守メンバーに引き継がれていることの確認。

4.プロジェクト中に渡した機材、資料の回収が⾏われていることの確認。5.その他契約書に記載された作業で未履⾏の作業はない事の確認。

ベンダーマネジメントに関しての評価を⾏います。ベンダーの評価だけでなく、ベンダーマネジメント⾃体の評価を⾏い次回以降の開発プロジェクトに対して、ベンダマネジメント⾃体のレベルアップを図ることができます。

1.今後も継続して取引を⾏うことが有効なベンダーなのか。2.システム選定と発注プロセスの改善事項はあったのか。3.契約に関して、追加記載すべき事項があるのか。4.プロジェクト管理において、改善点はなかったのか

上記事項をまとめて、ベンダマネジメントに反映させていく事で今後のプロジェクトの成功確率はさらに向上するものと確信します。




15

５．業務改⾰プロジェクトを成功させるために

これまでプロジェクトを成功させるためのベンダーマネジメントのポイントを挙げてきました。各⼈が“やらなければならないこと”を明確化し、“ちゃんとやっていること”を確認することです。ベンダマネジメントとは、当たり前の事を当たり前にやる状況を作り出すことです。

そのためには・・・


外注の⽬的と範囲を明確にして役割分担を明確にする。管理するだけでなく、ユーザーとベンダー双⽅が信頼しあう関係。ベンダーの能動的なアクションを引き出していく事。

機能要求事項を洗い出しＲＦＰにまとめる。きちんとした契約を取交わす。各局⾯での成果物を明確化する。

プロジェクト⽬標を共有し、物事を決定する際の原則とする。最初に管理ルールを明確化し、共有し、実践する。前の局⾯の成果物が次の局⾯の基礎資料と認識し、皆で共有化を図る。

最初が肝⼼

共有化

信頼関係



当資料に関する、お問合せやご質問等ございましたら、下記までご連絡ください。

ＣＩＯパートナーズ株式会社〒550-0014⼤阪市⻄区北堀江 1-19-8 四ツ橋ＫＭビル７階（担当：安⽥）

℡ [email protected]


講演2 ベンダーマネジメント v1.0...2014/12/03 · Management Innovation by ICT Solution...

Documents

Transcript of 講演2 ベンダーマネジメント v1.0...2014/12/03 · Management Innovation by ICT Solution...