セミナー講演資料（2012年11月29日）

アジェンダ

クラウド・タブレットの導入状況

大手企業ではグローバル化の進展（海外進出）が顕著であり、
情報系（メール、掲示板、WEB）でのクラウド採用に留まらず、営業管理（CRM、SFA）、人事・総務管理などで、
クラウド（SaaS）を採用するケースも少なくありません。

また、クラウドで普及が進む「情報系」「営業管理」機能はモビリティ（特性）が大きく、利便席を高める点に特徴があります。

タブレットの普及（企業での採用）がさらに加速する兆し

クラウド・サービスのメリットと留意点

クラウドの良し悪しを踏まえつつ、如何に各社が上手く取り入れていけるかが重要

そもそも、ITを経営に如何に活かすべきか…

• 現状、多くの企業が効率化に主眼を置いて、IT投資（整備）を行っている。
• ただし、IT投資を通じて「マネジメントの高度化」や「ビジネスの差別化」に踏み出そうとする企業も増えつつある。

背景には、投資サイクル…
基幹系業務システムの再構築サイクルは、平均14.6年。

これからのIT投資は、業務の効率化・ITコストの削減にプラスαが不可欠

IT投資の狙い…顕著になる新潮流

「迅速な業績把握」や「業務の効率化」、「ITコスト削減」は会社規模に関わらず永遠の共通課題といえる。

新しい課題（新たな潮流）としては、下記2点がポイントとして挙げられる。

新たな課題を見据えたIT投資の想定シナリオ

事例：IT経営力の強化に向けたコードマップ（IT推進戦略）

マネジメント・システムでのクラ・タブ活用に向けて…

営業ステップ（営業展開シナリオ）の共有こそが、キーポイント

クラウドやタブレットの登場・普及で技術的なハードルは大きく低下している。

しかし、システム整備だけで対応しようと取組み、頓挫する事例が後を絶たない。

ポイントは、ツールで集めたデータを、如何にマネジメントで徹底して活用するかにあり！

「（集めたデータは）何かに使うだろう…」といった安易な考えは禁物。
また、「情報共有だけをIT化」しても、成果は限定的。

これからのIT投資…投資回収性に加え、“ユーザー指向と戦略性”がカギ

「アウトプット｣に焦点をあて、「IT整備後の業務モデル」を起点に…

• 先述の通り、「高度化」や「差別化」を目指した整備では、"ITからアウトプットされる情報"の用途と狙いを明確にする事なく､成果を挙げる事は適いません。
  • 「ちなみに、ここで記載する用途とは、「評価」や「人事考課」ばかりではありません。（直ぐに評価や人事考課に反映しようとするあまり、頓挫するケースは少なくありません）
  • むしろ、「社内会議での徹底利用」などを当面の目標に定め、IT整備と合わせて社内ルール（マネジメント活動）の見直しに取組む事こそが重要です。
• また、「迅速な業績把握・情報把握」へのニーズは依然として高い傾向にあります。従って、業務プロセスの効率化を狙ったIT整備であっても、「マネジメント活動の中で、どういった情報が必要」で、「“いつまで”にその情報をユーザーに提供しなければならないのか」を常に意識して、ルーチンワークの社内ルールの見直しを検討する事が重要です。

システム部は、経営者やユーザーの「下請け」から、「パートナー」に…

• 上述の通り、これからのIT投資では、「ToBeモデル」（IT整備後の業務モデル）の実現に向け、IT整備に加えて、社内ルールの見直し（業務改革）が不可欠です。
• その為には、経営者やユーザー社内のシステム利用者）から「リクエストを受ける」ばかりでなく、社内のシステム利用者に対して、「提案する」事が必要です。（※実際、大半の大手企業の情報システム部長は、提案の重要性を強く認識）
• ただ、一方で「提案力」「発言力」が、情報システム部長を始め、個人の能力・資質や過去の経験任せになっている企業も少なくありません｡こうした属人化した状態を脱する為には、

1. 提案相手の立場に立って、提案内容を考える
2. 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マネジメント」に欠かせない。

アジェンダ

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

• 近年、情報システムのアウトソーシングや自前システムの破棄（Ｓａａｓ・クラウドに伴い）が進む中にあり、業務システムごとにベンダが変わるマルチベンダーが前提となってきている昨今、「ベンダーマネジメント」に対する必要性が高まりつつある。
• しかしながら、特定の方法論（ＳＬＡなど）にのみ関心が集中し、結果的にベンダーマネジメント効果を得る事ができていない企業も散見される。

ベンダーマネジメント不足から生じる不満

情報システム・ソフトウェア取引のトラブル原因分類

ベンダーマネジメントの着眼点

※TCO：情報システムの構築や運用などを通じて、サービスを受益する為に投入される経営資源の量

ベンダーマネジメントの着眼点　①契約

きちんとした契約を取交わす＆見直す

• 局面に応じた契約形態をとる
  • 新システム導入の際、要件等をまとめる局面と、その後の設計～開発、テスト局面では、対価の対象が異なる事が多い。（※また、運用・保守の際にも、多くの場合で同様）
  • こうした場合、対価の対象が異なる契約を、「一括受託」などの形態でまとめて契約するのではなく、各々の局面に応じて、契約形態を変更する事が、相互の権利関係を明確にする上でも望ましい。

• 契約内容をきちんと詰める
  • ベンダーとの取引関係の中で、特にリスクが大きい項目は、予め契約内容を双方で協議し、合意形成しておく事が望まれる。
  • 具体的には、①知的財産に関する権利関係、②再外注（二次請け、三次請け）、③ベンダーの管理責任、④契約の更新、⑤（特に役務の）サービスレベル、⑥瑕疵担保責任の範疇、保障期間などはベンダーの「言う通り」に契約して後々、問題とならない様に注意する必要がある。

• 妥当性のある金額で契約する
  • 「一式」などの内訳が分からない見積りや、ＳＥのスキルと作業に要するスキルの比較検証が出来ない見積りでは、妥当性のある金額での契約は望めない。
  • また、「相見積り」による検証のみならず、経年効果（ベンダーのスキル蓄積効果）を考慮に入れた契約金額の見直しが重要。

（ご参考）契約書のチェック項目（弊社契約書ガイドラインより抜粋）

ベンダーマネジメントの着眼点　②要件定義

要件定義は、しっかりと考えて決める。決めたら変えない。

• しっかり時間をとる
  • ユーザ部門が忙しい、といった理由で1回あたりのセッションの時間を決めて決められた範囲のシステム要件を確定させているケースが多い。
  • こういった場合は、事前に討議内容と要決定事項を伝えてもらい、事前に回答を準備するといった対応が有効。
    ユーザー部門担当者の考える時間が減ることはない。

• システムの目線からの判断が必要
  • ユーザ部門担当者が必要とした判断が正しいか否か、システムの視点で判断するシステム部門の判断が必要。
    業務の発生頻度等の業務以外の判断基準等で、システム化の要否を判断できる“目”が必要。

• システム技術に関する問題が発生したらできない前提で設計する
  • システム技術で対応の要否が不明な点が発生し即答できない場合、まずできない前提で要件を定義していく。
    対応が可能と判明し場合、システムの開発負荷が小さい場合には、対応を進める。

ベンダーマネジメントの着眼点　③開発・検収

開発納品物の進捗管理、検証作業のベンダー任せはNG

• 詳細な進捗管理を行う
  • 発注契約で了解している生産性、成果物を前提にして、スケジュールは、必ずベンダーの責任者または担当者に立ててもらい、定期的（1回／週）に進捗会議を開催する。
  • ベンダーが行う作業・成果物と開発担当者の対応付けされたレベルの進捗管理が必要。

• 品質管理基準を明示する
  • 発注契約時に明示した品質管理基準に従ってベンダーの成果物を受け入れ検査する。
    検査項目例としては、設計書のレビュー結果や、プログラムテスト仕様書と結果、等。
  • 納品検収は、一度に納品を受けるのではなく、完成分を少しづつでも納品させることで、検収負荷を軽減させる。また最初の成果物は特に時間・工数をかけて細密なレビューを行うことが有効。

• 業務運用マニュアルは自社内で作成する
  • 開発期間中、ユーザー部門は業務運用マニュアルを作成し、新業務について再確認を行うとともに、不明点はベンダーに確認し不明な項目はなくする。
  • 業務運用マニュアルに沿って受け入れ検証テストを行うことで、本番に即した事前テストが可能となる。

• コミュニケーションをしっかりとる
  • ベンダーの要員とのコミュニケーションはかかせない。そのためには相手を受け入れる姿勢で、関心を持ってお付き合いすることが必要です。時折慰労することも重要。

ベンダーマネジメントの着眼点　④保守・運用

TCO及び契約に準じた保守運用の実施

• プログラム保守時のバグと変更対応の明確化
  • プログラムバグなのか、変更対応なのかを明確にしてプログラム対応を行うことが重要。
    この為、瑕疵担保責任と保証期間である程度のバグ対応が可能な契約の締結は必須要件となる。

• システム企画段階で設定した年間の運用コストに準じた契約の締結
  • システム企画段階で設定した年間の運用コストに準じた契約を締結し、その範囲内での対応を前提とする。
  • システム部担当者は、ユーザー部門から出る変更対応について、ベンダーへの引き継ぎ役ではなく、変更要望の要否を判断し、優先順位づけを行う業務の仕分けを行う。
  • 開発ベンダーにこだわらず、運用時に別途ベンダー選定を行うケースも増えている。

• 外部委託の推進
  • 問い合わせ等、外部委託可能な業務の洗い出しを行い、システム部担当者に依存しがちなルーチン業務からの解放を進めること。

システム部門の業務とベンダーマネジメント

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

ベンダーマネジメントに必要なシステム部要員のスキル

システム部員は、ゼネラリストを目指せ

• バランスの取れたスキルセットを具える
  • システム部員の知識や関心が技術的分野に偏向すると、ベンダーからの提案内容がどの程度、経営戦略の推進に役立つかを適切に評価する事ができない。
  • 従って、「ＩＴ」のみならず、「業務やコンプライアンス」「経営・マネジメント」などの基礎知識を備え、且つ自ら考えを整理できる人材こそが、あるべきシステム部員の像。

• 関係者を巻き込めるコミュニケーション力を具える
  • 社内の関係者やベンダーとのコミュニケーション不足が原因で、失敗に終るプロジェクトは多い。
  • ＰＭ（管理者）のみならず、部員一人ひとりが社内外の関係者と意見を確認・調整する事で、始めてシステム部門と経営者、利用部門のスクラムが構築され、ＩＴを経営戦略に役立てる事ができる。

まとめ

企画段階から要件定義局面において、業務要件をしっかりと固めておくことが重要。

ユーザー側でシステムに必須の機能・あればよい機能・不要な機能について切り分けを行い、
その要件がベンダー側に伝わっていることが大前提となる。

Ｑ（品質）を担保するためには…

• 設計書（プログラム）のレビューには積極的に参加し、求める機能要件が充足されているかの検証を行うこと。
• ユーザーマニュアルを作成し、ユーザーマニュアルに従ったテストケースの洗い出しと受け入れ検証テストを実施して、本稼働前の事前確認を行うこと。
• 仕様変更は、なし崩し的に行わず、影響度を十分検討し、影響するプログラムをまとめて対応すること。

Ｃ（コストの妥当性）を担保するためには…

• 仕様変更が必要な場合は、起因がユーザー・ベンダーどちらにあるか事前に了解を取り、コスト負担責任を明確にすること。

Ｄ（納期）を担保するためには…

• 進捗会議は、セレモニーではない。サマリーされた報告からは、問題点を見つけることはできない。
  （ベンダーが実施するような）詳細なレベルで進捗管理を行い、ユーザーとベンダーが情報共有することで問題を早期発見し、対応をとること。

上流工程で、ぶれない基本要件をしっかり確定させ、きちんとした契約を取交わすことで、初めて開発工程のＱＣＤチェック項目の実行が可能になる。