ご注意とお願い
以下の資料は、著作権法と不正競争防止法の保護を受けています。
従って、資料の一部あるいは全部について、ＣＩＯパートナーズ株式会社からの承諾を得ずに、いかなる方法においても無断で、複製、ノウハウの使用、企業の展開等をすることは禁じられています。
恐れ入りますが、上記をご承諾頂ける場合のみ、以下のレポート名をクリックして頂き、本編にお進みください。
第１部 クラウド・タブレット時代のＩＴ戦略とＩＴマネジメント（クリックして開く）
アジェンダ
クラウド・タブレットの導入状況
大手企業ではグローバル化の進展（海外進出）が顕著であり、
情報系（メール、掲示板、WEB）でのクラウド採用に留まらず、営業管理（CRM、SFA）、人事・総務管理などで、
クラウド（SaaS）を採用するケースも少なくありません。
また、クラウドで普及が進む「情報系」「営業管理」機能はモビリティ（特性）が大きく、利便席を高める点に特徴があります。
タブレットの普及（企業での採用）がさらに加速する兆し
クラウド・サービスのメリットと留意点
| メリット | 留意点 |
|---|---|
| ▼IT資産の圧縮 ・顧客企業が調達すべきIT資産を最小限に抑制。（可能） | ▼乗り換え・解約リスク ・他のサービス提供者への乗り換えに大きなリスクや負荷が生じる。（懸念がある） ・契約期間内にサービス注視（契約解除）を申し入れる場合、違約金が発生する可能性がある |
| ▼変動費化 ・自前でIT資産を保有する場合と比べて、サービス量（コンピューターの処理量）に応じてサービス利用料が決まる為、コストの変動費化を図りやすい。 ※ただし、処理量と利用料の相関（運動の程度）はサービス料金体系により異なる為、注意が必要。 | ▼カスタマイズの制約 ・自社都合による独自の機能改訂などに、柔軟な対応を望み難い｡（融通が効かない恐れがある） ※消費税増税など法改正への対応は、自社都合ではない為、上記懸念は後退する。 |
| ▼運用コストの圧縮 ・セキュリティ対策やBCP対策等は、サービス提供者が実作業を担う為、自前で実作業に取組む負荷が大幅に軽減 ・セキュリティポリシー策定、危機管理態勢の強化等といった企画やマネジメント業務に従事する工数が確保 ・老朽化や保守期限切れに伴うサーバー入替等、技術的要因に起因する導入後の追加コストの発生を圧縮 ・システムを自前で保有する場合に発生するシステム運用に伴う業務負荷を大幅に軽減 ・（一般的に）ITコスト（TCO）を約3〜5割低減｡（可能） | ▼その他 ・他社も含めた膨大なデータがセンターに集約される為、ハッキング等のターゲットとなり易くなる｡（結果、情報漏えいリスクが高くなる懸念がある） ・突発的な事由等により、サービス提供者（契約先）が継続的なサービス提供を断念するリスクがある｡ |
クラウドの良し悪しを踏まえつつ、如何に各社が上手く取り入れていけるかが重要
そもそも、ITを経営に如何に活かすべきか…
- 現状、多くの企業が効率化に主眼を置いて、IT投資（整備）を行っている。
- ただし、IT投資を通じて「マネジメントの高度化」や「ビジネスの差別化」に踏み出そうとする企業も増えつつある。
背景には、投資サイクル…
基幹系業務システムの再構築サイクルは、平均14.6年。
これからのIT投資は、業務の効率化・ITコストの削減にプラスαが不可欠
IT投資の狙い…顕著になる新潮流
「迅速な業績把握」や「業務の効率化」、「ITコスト削減」は会社規模に関わらず永遠の共通課題といえる。
新しい課題（新たな潮流）としては、下記2点がポイントとして挙げられる。
- 「顧客重視」「営業強化」は会社規模に関係なく、多くの企業が重視している。
- 一方、会社規模が大きい企業ほど「グローバル化」や「企業間連携」、「差別化」、「ビジネスモデル変革」に関心が移りつつある。
新たな課題を見据えたIT投資の想定シナリオ
| Step1 | ・業務プロセスの効率化 ・ITコストの削減 ⇒パッケージやSaaSの採用も視野に…Step2も念頭に入力プロセスを検討… |
| Step2 | ・迅速な業績情報把握 ・グローバル化への対応 ⇒マネジメントのあり方を起点に、データのアウトプット等に焦点をあてて検討… |
| Step3 | ・顧客重視経営／営業強化 ・企業間の情報連携 ⇒自社の事業に沿ったあるべき業務のモデル化が不可欠。「既製品」では限界が… |
| Step4 | ・ビジネスモデルの変革 ・商品／サービスの差別化 |
事例：IT経営力の強化に向けたコードマップ（IT推進戦略）
マネジメント・システムでのクラ・タブ活用に向けて…
営業ステップ（営業展開シナリオ）の共有こそが、キーポイント
クラウドやタブレットの登場・普及で技術的なハードルは大きく低下している。
しかし、システム整備だけで対応しようと取組み、頓挫する事例が後を絶たない。
ポイントは、ツールで集めたデータを、如何にマネジメントで徹底して活用するかにあり！
「（集めたデータは）何かに使うだろう…」といった安易な考えは禁物。
また、「情報共有だけをIT化」しても、成果は限定的。
これからのIT投資…投資回収性に加え、“ユーザー指向と戦略性”がカギ
「アウトプット｣に焦点をあて、「IT整備後の業務モデル」を起点に…
- 先述の通り、「高度化」や「差別化」を目指した整備では、"ITからアウトプットされる情報"の用途と狙いを明確にする事なく､成果を挙げる事は適いません。
- 「ちなみに、ここで記載する用途とは、「評価」や「人事考課」ばかりではありません。（直ぐに評価や人事考課に反映しようとするあまり、頓挫するケースは少なくありません）
- むしろ、「社内会議での徹底利用」などを当面の目標に定め、IT整備と合わせて社内ルール（マネジメント活動）の見直しに取組む事こそが重要です。
- また、「迅速な業績把握・情報把握」へのニーズは依然として高い傾向にあります。従って、業務プロセスの効率化を狙ったIT整備であっても、「マネジメント活動の中で、どういった情報が必要」で、「“いつまで”にその情報をユーザーに提供しなければならないのか」を常に意識して、ルーチンワークの社内ルールの見直しを検討する事が重要です。
システム部は、経営者やユーザーの「下請け」から、「パートナー」に…
- 上述の通り、これからのIT投資では、「ToBeモデル」（IT整備後の業務モデル）の実現に向け、IT整備に加えて、社内ルールの見直し（業務改革）が不可欠です。
- その為には、経営者やユーザー社内のシステム利用者）から「リクエストを受ける」ばかりでなく、社内のシステム利用者に対して、「提案する」事が必要です。（※実際、大半の大手企業の情報システム部長は、提案の重要性を強く認識）
- ただ、一方で「提案力」「発言力」が、情報システム部長を始め、個人の能力・資質や過去の経験任せになっている企業も少なくありません｡こうした属人化した状態を脱する為には、
- 提案相手の立場に立って、提案内容を考える
- IT特有の難解な用語を使うのではなく、IT知識（背景）が乏しくても理解できる。“自分の言葉”を用いる
ことが重要です。
業務改革✕IT投資 ～一般的な取組みの流れ（全体像）～
適切なIT投資に向けて
（１）仮設定義～構想の具体化
（２）提案以来と選定
「出来レース」にしない
- 既に取引のあるベンダーが作成した「提案依頼書（RFP）」を使い、新規ベンダーを半ば"当て馬"にして、提案依頼をするケースがあります。
- しかし、こうした選定方法では「ITコストの適正化」や「スリムなITの導入」は、到底実現できません。
- 適正コストで適正規模のシステム導入を目指すには「提案依頼先に全力で知恵を絞って貰う」事が鉄則です。
情報格差はNG
- 提案依頼・RFP説明後の「丸投げ」は提案費用の高騰につながります。
つまり、提案内容を検討し始めると、RFPには記載の無い、詳細な部分で疑問点がベンダーには生じます。また、RFP記載事項でも、理解・解釈の違いが生じる事が多々、あります。 - 従って、ベンダーとは継続的にコミュニケーションを図り、しかも各社に同じ内容を伝える事が、各社の提案内容の大きなバラツキを無くすポイントです。
「カネ」だけで決めない
- 選定は提案価格のみならず、主に以下も含めた総合的な評価が必要。
- RFPの要件への適合性（不適合要件に対する提案）
- Q&Aの内容・レスポンスの早さ
- 契約書の内容（主な条項）
- 担当PM（SE）に対する評価
- プレゼン・提案書の出来栄え
- ベンダー体制（や責任者の役職）
- TCO（維持費用を含む総コスト）
最後に
クラウドの普及により、基幹業務系システムのスリム化（ITコストの削減）に向けた選択肢が広がりつつある。
また、タブレット端末の普及により、従来は自社のITサービス提供に制限があった、社外など多様なシーンで、ITサービスをより提供しやすくなりつつある。
こうした技術動向に加え、企業の経営環境の変化もあり、これからのIT投資には、「業務の効率化」「ITコストの削減」に加える、“+α”が重要になってきている。
この、“+α”の成果を挙げるIT投資を実現するには、
- システム部門が、経営者やユーザーの「パートナー」となり、
- アウトプット（業務）にも焦点をあて、新業務モデルを起点に構想をまとめ、
- 新しいソリューションの採用も視野に入れ、
- 過去の付き合いに縛られる事なく、公平にソリューションを選定する。
これら4点が、「クラウド・タブレット時代のIT戦略・ITマネジメント」に欠かせない。
第２部 コストと対応の両立を求めるベンダー・マネジメント（クリックして開く）
アジェンダ
そもそも、ベンダーマネジメントとは…
- 近年、情報システムのアウトソーシングや自前システムの破棄（Ｓａａｓ・クラウドに伴い）が進む中にあり、業務システムごとにベンダが変わるマルチベンダーが前提となってきている昨今、「ベンダーマネジメント」に対する必要性が高まりつつある。
- しかしながら、特定の方法論（ＳＬＡなど）にのみ関心が集中し、結果的にベンダーマネジメント効果を得る事ができていない企業も散見される。
ベンダーマネジメント不足から生じる不満
情報システム・ソフトウェア取引のトラブル原因分類
| No | 改善の余地のある事項 | 例 |
|---|---|---|
| A | 正式契約書締結以前の作業開始 | 正式契約書締結以前の作業開始、契約成立をめぐるトラブル |
| B | 作業に不適合な契約形態 | 一括請負契約、要件定義の請負契約、異なるベンダへの工程別発注に際しての調整、契約類型の不明確（請負か準委任か）さ |
| C | 業務範囲 | 提案書・見積書の効果についての誤解、議事録その他のドキュメントの効果についての誤解、業務範囲の誤解（瑕疵または債務不履行の主張がなされたがそもそも具備すべき仕様でないとされた場合（要件定義が不十分な場合など）） |
| D | 完成基準・検査 | ベンダへの丸投げ、仕様が決まらない（仕様確定についてのベンダとユーザの意識の乖離）、検査実施方法の規定の欠如、実態を伴わない検収書の発行 |
| E | 役割分担・プロジェクト推進体制 | ユーザの協力義務についての認識欠如、ユーザ側の業務推進体制の不備、ベンダの下請けへの丸投げ、マルチベンダ体制（ベンダ間の調整）、責任の所在の欠如、パッケージ選定責任に関する取決めの欠如 |
| F | 知的財産権 | 知的財産権への理解不足 |
| G | 第三者が権利を有するソフトウェア | 処理条項の欠如、責任が曖昧、不具合修正ができない |
| H | 変更管理 | 変更管理手続の欠如（作業範囲の変更に際しての納期・金額等の見直しルール）、連絡協議会の決定事項の効果が曖昧、ユーザの計上基準や規則が曖昧、技術的難易度の共通理解の不足 |
| I | 債務不履行・瑕疵担保責任 | 善良な管理者の注意義務違反 |
【ユーザー側の要件】
- きちんとした契約を取り交わす＆見直す
- 開発前の要件定義をちゃんと行い、システム要求を確定させる。
- PJ推進体制を整備し、ベンダーへの丸投げはやめる
- 変更管理手順を整備する。
ベンダーマネジメントの着眼点
| 構想策定支援ベンダー | ①TCO（※）をしっかり見積もる ②システム基本性能と犯意確定 ③対応の選定 |
| マネジメント支援ベンダー／開発ベンダー | ①きちんとした契約を取り交わす＆見直す ②要件定義時に詳細な仕様の確定 ③設計書のレビュー ④開発の進捗管理の実施 ⑤検収作業の実施 |
| 保守ベンダー／運用ベンダー | ①TCOに準じたい保守費用・運用費用での契約 ②プログラムバグ／変更対応を切り分けた対応 |
※TCO：情報システムの構築や運用などを通じて、サービスを受益する為に投入される経営資源の量
ベンダーマネジメントの着眼点 ①契約
きちんとした契約を取交わす＆見直す
- 局面に応じた契約形態をとる
- 新システム導入の際、要件等をまとめる局面と、その後の設計～開発、テスト局面では、対価の対象が異なる事が多い。（※また、運用・保守の際にも、多くの場合で同様）
- こうした場合、対価の対象が異なる契約を、「一括受託」などの形態でまとめて契約するのではなく、各々の局面に応じて、契約形態を変更する事が、相互の権利関係を明確にする上でも望ましい。
- 契約内容をきちんと詰める
- ベンダーとの取引関係の中で、特にリスクが大きい項目は、予め契約内容を双方で協議し、合意形成しておく事が望まれる。
- 具体的には、①知的財産に関する権利関係、②再外注（二次請け、三次請け）、③ベンダーの管理責任、④契約の更新、⑤（特に役務の）サービスレベル、⑥瑕疵担保責任の範疇、保障期間などはベンダーの「言う通り」に契約して後々、問題とならない様に注意する必要がある。
- 妥当性のある金額で契約する
- 「一式」などの内訳が分からない見積りや、ＳＥのスキルと作業に要するスキルの比較検証が出来ない見積りでは、妥当性のある金額での契約は望めない。
- また、「相見積り」による検証のみならず、経年効果（ベンダーのスキル蓄積効果）を考慮に入れた契約金額の見直しが重要。
（ご参考）契約書のチェック項目（弊社契約書ガイドラインより抜粋）
| No | 大分類 | No | 中分類 |
|---|---|---|---|
| 1 | 信義則条項 | 1-1 | 契約の履行姿勢 |
| 1-2 | 関連法規の遵守 | ||
| 2 | 契約締結の条件 | 2-1 | 仕様（要件）の原則 |
| 2-2 | 仕様（要件）の変更 | ||
| 2-3 | 発注条件の原則 | ||
| 2-4 | 発注条件の変更 | ||
| 3 | 再外注 | 3-1 | 再外注の原則 |
| 3-2 | 再外注の条件（制限） | ||
| 3-3 | 再外注先の管理・監督 | ||
| 4 | 履行管理 | 4-1 | 管理責任者 |
| 4-2 | 管理手続き | ||
| 4-3 | 緊急時の対応 | ||
| 5 | 契約解除の条件 | 5-1 | 与信条件 |
| 5-2 | 契約解除の条件 | ||
| 5-3 | 前渡金の返還請求 | ||
| 6 | 契約終了の条件 | 6-1 | 検収手続き |
| 6-2 | 検収期間 | ||
| 6-3 | 差戻し | ||
| 6-4 | 契約の継続 | ||
| 7 | 機密保持 | 7-1 | 機密情報の定義 |
| 7-2 | 機密保持 | ||
| 7-3 | 機密保持管理者 | ||
| 7-4 | 機密情報の返還 | ||
| 7-5 | 機密保持義務の存続期間 | ||
| 7-6 | 競業禁止 | ||
| 8 | 個人情報保護 | 8-1 | 個人情報の定義 |
| 8-2 | 個人情報保護責任 | ||
| 8-3 | 個人情報管理責任者 | ||
| 8-4 | 報告義務 | ||
| 9 | 所有権 | 9-1 | 貸与品の取扱い |
| 10 | 著作権 | 10-1 | 著作財産権帰属 |
| 10-2 | 共著部分の使用制限 | ||
| 10-4 | 再外注先の著作財産権 | ||
| 10-5 | 著作人格権行使制限 | ||
| 10-6 | 複製の許可 | ||
| 11 | 特許・実用新案・意匠権 | 11-1 | 特許権・実用新案権・意匠権帰属 |
| 11-2 | 乙保有権利の甲通常実施権 | ||
| 11-3 | 共有権利の使用制限 | ||
| 12 | 監査 | 12-1 | ユーザ又は第三者監査 |
| 13 | 損害賠償 | 13-1 | 賠償金額の上限 |
| 13-2 | 責任能力の担保 | ||
| 14 | 合意管轄 | 14-1 | 管轄裁判所 |
| 15 | 瑕疵担保 | 15-1 | 瑕疵担保期間 |
| 15-2 | 瑕疵担保能力の維持 | ||
| 16 | 危険負担 | 16-1 | 滅失時の対応 |
| 16-2 | 毀損時の対応 | ||
| 16-3 | 修復が著しく困難な場合の対応 | ||
| 17 | 保証 | 17-1 | 保証の継続 |
| 17-2 | 保証内容 | ||
| 17--3 | 保証の条件 |
| No | 大分類 | No | 中分類 | 内容 | 基本 | 請負 | 準委任 | 売買 | 賃借 |
|---|---|---|---|---|---|---|---|---|---|
| 3 | 再外注 | 3-1 | 再外注の原則 | 一括の再外注は禁止するものとする。 | ○ | ○ | |||
| 乙は再外注に際して、予め乙と再外注先の契約内容を甲に報告の上、甲に許可を求めなければならない | ○ | ||||||||
| 乙は再外注に際して、予め乙と再外注先の契約内容と再外注する業務範囲を甲に報告の上、甲の許可を求めなければならない | ○ | ||||||||
| 3-2 | 再外注の条件（制限） | 再外注は、乙に責任能力（規模等）があることを条件とする。 | ○ | ○ | |||||
| 再外注の可否は甲が最終判断するものとする。 | ○ | ○ | |||||||
| 再外注先が甲の定める条件（業績や規模等）を満たす事 | ○ | ||||||||
| 再外注する人材が甲の定める条件（実績や有資格等）を満たす事 | ○ | ||||||||
| 3-3 | 再外注先の管理・監督 | 再外注先の管理・監督責任は、外注先（乙）が有する | ○ | ||||||
| 5 | 契約解除の条件 | 5-3 | 前渡金の返還請求 | 本契約が解除された場合、乙は甲から支払われた着手金や前渡金を直ちに甲に返還しなければならない。 | ○ | ○ | |||
| 6 | 契約終了の条件 | 6-2 | 検収期間 | 甲は、乙の納入物や完了報告書の受領後、30日以内に検収しなければならない。 | ○ | ○ | |||
| 6-3 | 差戻し | 甲の検収過程において不備が発見された場合、甲は乙に対し納入物の差戻しを要求するものとする。 | ○ | ○ | |||||
| 乙は甲から納入物が差戻された場合、直ちに修正や交換等の対処を行う責任を負う。 | ○ | ○ | |||||||
| 7 | 機密保持 | 7-6 | 競業禁止 | 甲乙は、本契約の履行を通じて得られたノウハウ等は、互いの許可無く、第三者に対して活用してはならない。 | ○ | ○ | |||
| 10 | 著作権 | 10-2 | 共著部分の使用制限 | 共著部分を利用して、互いの許可無しに無断で、第三者に対して活用してはならない。 | ○ | ||||
| 共著部分に関して、甲乙の競合他社に対して、いかなる理由があっても使用してはならない。 | ○ | ||||||||
| 10-5 | 著作人格権行使制限 | 乙は、本契約に基づき甲に著作財産権を譲渡した著作物に関して、著作人格権を行使しないものとする。 | ○ | ||||||
| 12 | 監査 | 12-1 | ユーザまたは第三者監査 | 甲は、本件業務の履行状況につき、定期的又は随時監査を行うことができるものとし、乙はこれに協力し必要な情報を提供することとする。 | ○ | ○ | |||
| 13 | 損害賠償 | 13-1 | 賠償金額の上限 | 損害賠償の累計額の限度は、定めないものとする。 | ○ | ||||
| 15 | 瑕疵担保 | 15-1 | 瑕疵担保期間 | 乙がかかる修正責任を負うのは、検収完了後13ヶ月以内に甲から請求された場合に限るものとする。 | ○ | ||||
| 17 | 保証 | 17-1 | 保証の継続 | 乙は、本契約の保証について、検収後○○年間に渡り、継続する義務を負う。 | ○ | ○ | |||
| 乙は、本契約の継続期間に限り、甲に対して保証を継続する義務を負う。 | ○ |
ベンダーマネジメントの着眼点 ②要件定義
要件定義は、しっかりと考えて決める。決めたら変えない。
- しっかり時間をとる
- ユーザ部門が忙しい、といった理由で1回あたりのセッションの時間を決めて決められた範囲のシステム要件を確定させているケースが多い。
- こういった場合は、事前に討議内容と要決定事項を伝えてもらい、事前に回答を準備するといった対応が有効。
ユーザー部門担当者の考える時間が減ることはない。
- システムの目線からの判断が必要
- ユーザ部門担当者が必要とした判断が正しいか否か、システムの視点で判断するシステム部門の判断が必要。
業務の発生頻度等の業務以外の判断基準等で、システム化の要否を判断できる“目”が必要。
- ユーザ部門担当者が必要とした判断が正しいか否か、システムの視点で判断するシステム部門の判断が必要。
- システム技術に関する問題が発生したらできない前提で設計する
- システム技術で対応の要否が不明な点が発生し即答できない場合、まずできない前提で要件を定義していく。
対応が可能と判明し場合、システムの開発負荷が小さい場合には、対応を進める。
- システム技術で対応の要否が不明な点が発生し即答できない場合、まずできない前提で要件を定義していく。
ベンダーマネジメントの着眼点 ③開発・検収
開発納品物の進捗管理、検証作業のベンダー任せはNG
- 詳細な進捗管理を行う
- 発注契約で了解している生産性、成果物を前提にして、スケジュールは、必ずベンダーの責任者または担当者に立ててもらい、定期的（1回／週）に進捗会議を開催する。
- ベンダーが行う作業・成果物と開発担当者の対応付けされたレベルの進捗管理が必要。
- 品質管理基準を明示する
- 発注契約時に明示した品質管理基準に従ってベンダーの成果物を受け入れ検査する。
検査項目例としては、設計書のレビュー結果や、プログラムテスト仕様書と結果、等。 - 納品検収は、一度に納品を受けるのではなく、完成分を少しづつでも納品させることで、検収負荷を軽減させる。また最初の成果物は特に時間・工数をかけて細密なレビューを行うことが有効。
- 発注契約時に明示した品質管理基準に従ってベンダーの成果物を受け入れ検査する。
- 業務運用マニュアルは自社内で作成する
- 開発期間中、ユーザー部門は業務運用マニュアルを作成し、新業務について再確認を行うとともに、不明点はベンダーに確認し不明な項目はなくする。
- 業務運用マニュアルに沿って受け入れ検証テストを行うことで、本番に即した事前テストが可能となる。
- コミュニケーションをしっかりとる
- ベンダーの要員とのコミュニケーションはかかせない。そのためには相手を受け入れる姿勢で、関心を持ってお付き合いすることが必要です。時折慰労することも重要。
ベンダーマネジメントの着眼点 ④保守・運用
TCO及び契約に準じた保守運用の実施
- プログラム保守時のバグと変更対応の明確化
- プログラムバグなのか、変更対応なのかを明確にしてプログラム対応を行うことが重要。
この為、瑕疵担保責任と保証期間である程度のバグ対応が可能な契約の締結は必須要件となる。
- プログラムバグなのか、変更対応なのかを明確にしてプログラム対応を行うことが重要。
- システム企画段階で設定した年間の運用コストに準じた契約の締結
- システム企画段階で設定した年間の運用コストに準じた契約を締結し、その範囲内での対応を前提とする。
- システム部担当者は、ユーザー部門から出る変更対応について、ベンダーへの引き継ぎ役ではなく、変更要望の要否を判断し、優先順位づけを行う業務の仕分けを行う。
- 開発ベンダーにこだわらず、運用時に別途ベンダー選定を行うケースも増えている。
- 外部委託の推進
- 問い合わせ等、外部委託可能な業務の洗い出しを行い、システム部担当者に依存しがちなルーチン業務からの解放を進めること。
システム部門の業務とベンダーマネジメント
赤字（赤線）部分を中心に、ベンダーマネジメントは、様々な業務で必要に…
ベンダーマネジメントに必要なシステム部要員のスキル
システム部員は、ゼネラリストを目指せ
- バランスの取れたスキルセットを具える
- システム部員の知識や関心が技術的分野に偏向すると、ベンダーからの提案内容がどの程度、経営戦略の推進に役立つかを適切に評価する事ができない。
- 従って、「ＩＴ」のみならず、「業務やコンプライアンス」「経営・マネジメント」などの基礎知識を備え、且つ自ら考えを整理できる人材こそが、あるべきシステム部員の像。
- 関係者を巻き込めるコミュニケーション力を具える
- 社内の関係者やベンダーとのコミュニケーション不足が原因で、失敗に終るプロジェクトは多い。
- ＰＭ（管理者）のみならず、部員一人ひとりが社内外の関係者と意見を確認・調整する事で、始めてシステム部門と経営者、利用部門のスクラムが構築され、ＩＴを経営戦略に役立てる事ができる。
まとめ
企画段階から要件定義局面において、業務要件をしっかりと固めておくことが重要。
ユーザー側でシステムに必須の機能・あればよい機能・不要な機能について切り分けを行い、
その要件がベンダー側に伝わっていることが大前提となる。
Ｑ（品質）を担保するためには…
- 設計書（プログラム）のレビューには積極的に参加し、求める機能要件が充足されているかの検証を行うこと。
- ユーザーマニュアルを作成し、ユーザーマニュアルに従ったテストケースの洗い出しと受け入れ検証テストを実施して、本稼働前の事前確認を行うこと。
- 仕様変更は、なし崩し的に行わず、影響度を十分検討し、影響するプログラムをまとめて対応すること。
Ｃ（コストの妥当性）を担保するためには…
- 仕様変更が必要な場合は、起因がユーザー・ベンダーどちらにあるか事前に了解を取り、コスト負担責任を明確にすること。
Ｄ（納期）を担保するためには…
- 進捗会議は、セレモニーではない。サマリーされた報告からは、問題点を見つけることはできない。
（ベンダーが実施するような）詳細なレベルで進捗管理を行い、ユーザーとベンダーが情報共有することで問題を早期発見し、対応をとること。
上流工程で、ぶれない基本要件をしっかり確定させ、きちんとした契約を取交わすことで、初めて開発工程のＱＣＤチェック項目の実行が可能になる。