大切なユーザ(自社)のプロジェクトマネジメントの役割
このページは自社(ユーザ)で活用できるように、プロジェクトマネジメントに必要な
項目を整理し、チェックリストを兼ねるように作成してあります。
一つでも多くの項目に対応することが成功の秘訣です。印刷をして活用して下さい。
1.準備事項
|
「段取り八分」と言われるようにパッケージ導入においては、この段取り=準備が大切な作業になります。この準備内容がそのままその後の作業効率とシステム品質に影響を与えます。自社の出来る範囲で、経営者とともにベストな準備をします。ベストとは関係者が分かりやすく、ベンダコントロールを含めてやるべきプロジェクト活動の全体像を理解し行動できることです。準備内容の参考になる情報が次のページにあります。参考にして下さい。
(参考) 「ユーザとしてやるべきこと」ページ
|

|
1.プロジェクト方針
「何のためにパッケージ導入を行うか」の背景と理由を明らかにして、プロジェクトを立ち上
げる根拠を整理します。その根拠を基にして、プロジェクトの成果とプロジェクト活動の条件
を決めます。投資に対する目的と期待効果の内容であり、関係者が知っておくべきプロジ
ェクト活動の条件です。これらをプロジェクト方針としてまとめます。
① 成果(実現内容)
・ 目的達成 -- あるべき姿、ビジョン、事業基盤の改革ポイント
・ 期待効果 -- 業務改善、定量的数値(経営管理/顧客サービスの指標)
・ 人材育成 -- 知識・スキルの向上、ノウハウの組織蓄積
② 条件
・ 基本条件 -- 事業・対象業務、予算、稼動時期、期間、体制
・ 前提条件 -- 他業務との関連、現行システムの取扱い、既存環境の取扱い
③ 留意点
・ 取引先 --- 顧客・得意先・仕入先・協力先などの関連性
・ ベンダ --- ベンダの選択基準、ベンダとの役割分担
・ 社会的要因 - 法令、業界ルール、情報セキュリティなどの考慮事項
(参考) 「業務改善への情報システムの活用」ページ
|
|
2.プロジェクト定義
プロジェクトを発足させるためにはプロジェクト方針に沿って、プロジェクトの目的・方向性・
活動内容などを明らかにします。自社としてのプロジェクト活動の旗印です。プロジェクト方
針の具体化であり、「転ばぬ先の杖」でもあります。
【プロジェクト定義の構成例】
① 目的
・ 目的を達成した後の状況・仕組み・管理基準などを明記します。経営からの
視点とします。
・ 対象業務の複雑さから、複数の目的もあります。
② 期待効果
・ 現状と比較して、経営/取引/業務/管理の面で改善される内容を明記しま
す。
・ 定量的表現も入れることです。
③ 対象範囲
・ 対象となる業務範囲/管理系を明記します。対象としない業務 との関連性を
表現します。
④ 日程
・ 稼動時期/スケジュールなどを明記します。
⑤ 体制
・ プロジェクトマネジャーとメンバーを決めます。
⑥ 予算
・ 予算額を明記します。
⑦ その他
・ プロジェクト方針の「前提条件・留意点」などを明記します。
【参考】ダウンロード資料<540 「プロジェクト定義」サンプル>
|
|
4.基本手順
ベンダとのプロジェクト活動の開始をどの作業から行うかを決めます。また、自社でどこま
での作業を自力で行えるかの評価をします。「パッケージ導入」か「情報システムの開発」
かによってもプロジェクト活動の基本手順は異なります。投資に応える最適解はこの基本
手順にかかっている面が強いです。「基本手順とパターン選択」ページを参考に賢い基本
手順の決定が望まれます。
【基本手順を決める要因】
① 自社の課題解決力
・ 自社の課題解決を自力で行い、システム要件に落せるか否か
・ 自社でシステム活用の仕組みができるか否か
・ ベンダが納得できるドキュメントが作成できるか否か
② パッケージ商品/ベンダの評価
・ 自社のシステム要件へのパッケージ商品の適性評価
・ ベンダ選択に対する自社力量の評価
③ 予算
・ 総予算、概算予算、確定予算の決定タイミング
・ ベンダとの契約タイミングと作業フェーズ/成果物の関連
(参考) 「基本手順とパターン選択」ページ
(参考) 「予算と期待効果」ページ
|
|
5.導入計画(実行計画)
導入計画(実行計画)はプロジェクトマネジメントの必需品です。プロジェクト活動の羅針盤
であり作業管理の基準であります。プロジェクト関係者が共有して持つべき情報です。作
業を行うメンバー・関係者が作業内容と他作業との関連性を理解して、行動に責任を持つ
ためでもあります。
【作成の要領】
① プロジェクト方針、プロジェクト定義、基本手順をベースに作成します。
② メンバー・関係者で必要な作業を洗出し、「重複と漏れ・抜け」を精査して作成
します。この作業を通して、メンバー・関係者の強 み/弱みが分かります。
③ 「分からないこと・詳細に落せないこと」はそのままにして、その旨が後で分か
るようにします。
④ 最初からがっちりした計画にするのは不可能です。必要な作業の漏れを防ぐ
ことが大事です。後の作業フェーズで変更・詳細化が起こります。
⑤ 不明な点・リスク要因の作業項目はプロジェクトマネジャーの特別管理としま
す。そのことが分かるようにします。
この作業はベンダとともに行うことも必要です。自社とベンダの作業内
容と作業分担を理解し、合意します。
【計画の内容】
導入計画(実行計画)に含まれる内容は、当然個々のプロジェクト条件によって異
なります。ここでは一般的なモデルとしてあげます。
① 目的、期待効果
② 前提条件、制約条件
③ 対象範囲(対象業務・管理・取引、他業務との関連、システム)
④ パッケージ導入の方針・基本要件(情報システムの開発)
・ 情報システムのあり方
・ ハードウェア、ソリューション、ネットワーク
・ 運用、セキュリティ、内部統制、危機管理
⑤作業内容、作業相関性、作業担当(WBS)
*WBS=Work Breakdown Structureの略、
プロジェクト全体を細かい作業に分割した構成図
⑥ 作業スケジュール(大日程、詳細日程)
・ 「基本手順」に沿って
⑦ プロジェクト体制と運営
⑧ プロジェクト運営のルール
⑨ その他(WBS詳細、リスク要因・・・・)
(参考) 「やさしい導入計画(実行計画)」ページ
【参考】ダウンロード資料<545 「実行計画書」ミニサンプル>
【参考】ダウンロード資料<550 「実行計画書」構成モデル>
|
2.自社の体制・運営
|
中堅・中小企業における自社プロジェクトの組閣とそれに伴う体制の運営は厳しいものがあります。限られた時間と工数の中で、経験の少ないプロジェクト活動を行うことは多くの困難が伴います。その困難さと課題を乗り越えなければ、プロジェクト目的と期待効果の達成はできません。重い荷物を少しでも軽くするためには、プロジェクトマネジャーとメンバーのチームワークが必要です。そして、その役割の内容をしっかり理解し責任ある行動をとれば「楽になり、楽しいプロジェクト活動」にもなります。このことを目指すべきです。
|
【参考】ダウンロード資料<030 パッケージ導入と体制>
|
● マネジャー
自社プロジェクトの運営に関する責任を持ちます。プロジェクトメンバーを率いてベンダとと
もに、目的達成のためのリーダシップを発揮し、一つ一つの仕事をこなしていきます。「事
実・データ・ドキュメント」を基に、意見・要望・アイデアが活発にでるオープンな運営を心
がけます。
|
役割 |
- プロジェクト方針・定義をメンバー/関係者に徹底します。
(キックオフの開催、意思統一の徹底)
- メンバーの働きやすく環境と条件を整えます。
- 問題点/リスクを常にウオッチし、必要な対策を打ちます。
- 経営者への定期的報告と必要な支援依頼をします。
- メンバー/ベンダからの改善点と要望への対応をします。
- 各作業フェーズの成果物に責任を有します。
- システム部門/担当者の役割を明確にします。
- 情報共有、コミュニケーションのある環境を整えます。
|
打合せ |
- 定期的開催、時間、アジェンダ、資料提示の采配をします。
- 作業進捗、現状の問題点、品質状況などの報告をします。
- メンバ/ベンダからの意見/報告を判断して、議題に入れます。
- 経営者/関係者/ベンダからの要望/意見を伝達します。
- 打合せ結果の保留/アクション事項への5W1Hを決めます。
- 成果物レビューの場を設け関係者による検討を行います。
|
|
● メンバー
経営者の意図を汲んで、プロジェクトマネジャーを支援しつつメンバー担当の作業を消化
します。前向きな発想と姿勢・行動でもって、メンバー間/対ベンダとのチームワークを重
視します。また、小異を捨てて大同につくことも大事です。
|
メリット |
- 全社的な視点からの業務/管理を知ることができます。
- 他業務/管理/取引/顧客などの問題点と改善内容を知り、自社の赤裸々な姿に触れます。
- 情報システムを活用する術と見方、及び限界が習得できます。
- 打合せ、セッションなど「討議と合意」手法が体験できます。
(ベンダの力量と経験によりますが)
|
参加意識 |
- メンバー/関係者/ベンダとのコミュニケーションを重視します。
- プロジェクト関係者はお互いに対等であります。
- 自担当業務に捉われず、全社的視点からの発言をします。
- ゴールまでの責任の持つ困難さと楽しさを味わうことです。
- 批判的な意見にも耳を貸すことです。
|
役割 |
- 自担当の作業内容をスケジュール通りにこなします。
- 関係する他作業者との密な連携・確認を行います。
- 作業フェーズの成果物との関連性を考慮して、自作業を進めます。
- 問題点/矛盾点/抜けなどを見つけ、提起します。
- プロジェクト運営に対する問題点・改善点を提示します。
- ベンダの作業・成果物・進め方に対する問題点を提起します。
- テスト、教育、稼動準備、稼動サポートなどの作業を分担します。
|
3.ベンダとの共同・連携
|
信頼感なりコミュニケーションが自社とベンダの間には大事と誰でもが言います。そのことは当然ですが、一朝一夕には築けません。日常のプロジェクト活動における「お互いのやるべきことの明確化」と「両社メンバーの姿勢と責任ある行動」があって信頼の土壌ができます。
自社とベンダの約束・ルールに基づく作業スタイルとチェック機能を含めた運営ルールが「共同・連携」のベースになり、作業の積み重ねによって強い信頼感とコミュニケーションが生まれます。
*PMO=Project Management Office プロジェクト活動に責任を持つ組織、又は責任者
|

|
■ 基本確認事項
自社とベンダの間でドキュメントを基に約束を交わすことです。このことを曖昧にして「何と
かなる」方式がプロジェクト失敗の要因の一つです。誰も助けてくれない大海に船出するの
がプロジェクト活動の宿命です。
【 契約前後の初期 】
① 自社の弱み宣言によるベンダ支援・協力内容の明確化
(自社プロジェクト活動/課題解決策の提案、自社成果物への指導・・・・)
② プロジェクト運営ルール、情報共有の仕方、問題管理、進捗管理、品質管理
③ PMOからの定期的な報告と問題解決の場を設定
④ 作業環境、個人情報の取扱い、情報セキュリティ
【 作業フェーズ別の確認】
① 成果物の提示と理解,、他作業との関連性、次作業フェーズとの関連性
② 作業スケジュール、体制、役割分担、事前準備(資料・データ・事実情報)
③ 自社の弱み/問題点へのベンダからの支援、指導、提案
④ 不明事項への対応ルール(自社内・対ベンダ)、変更管理
⑤ 成果物レビューの実施(自社内・対ベンダ)、成果物の修正日程
■ 活動へのチェック項目
日々の活動の中で、活動の低下防止と作業品質の向上を図るためにチェックと牽制は必要です。
神経質になることは避けますが、ある程度の緊張感が無いとお互いの意思疎通と情報共有が活き
たものになりません。チェック項目に目を配ることは大切です。問題に気づいたとき、手遅れになる
ケースが多いです。これがプロジェクト活動の姿ですし、現実です。チェック対象はプロジェクト全
体とプロジェクトメンバーです。
(参考) 「トラブルの早期発見と兆候・現象・原因」ページ
【 対自社 】
① 作業フェーズごとの成果物(資料・データ・事実確認)の理解、内容
② 約束事項(打合せ・成果物・回答・情報提供)の厳守、変更のアクション
③ ベンダとの意見調整/情報共有/コミュニケーション、ベンダへの問題提起
④ 現状仕事との調整/兼ね合い/上司の理解
⑤ チームワークの保持、前向きな発想、目的達成への意識・姿勢
⑥ プロジェクトマネジャー(実行責任者)の役割と機能
⑦ 経営者の協力/意思決定/プロジェクト状況の把握
【 対ベンダ 】
① PMO・プロジェクトマネジャーの役割と機能、プロジェクト活動の把握
(作業スケジュール、成果物の品質、メンバーの姿勢・行動、コスト意識)
② 自社のプロジェクト方針/プロジェクト定義・実行計画への理解と行動
③ 自社の作業/問題点への支援、提案、指導
④ メンバーの問題管理力、スキル、業務知識、自社の業務理解、業界知識
⑤ メンバーの作業スケジュール厳守、成果物の理解と品質
⑥ チームワークの保持、目的達成への理解と行動
⑦ 「作業フェーズ」開始前の準備と説明、最終成果物との関連性の説明と理解
⑧ 作業品質、中間成果物との対価バランス(発注額)
【参考】ダウンロード資料<160 ベンダプロジェクトを見る目>
(参考) 「トラブル(問題)の解決策と予防策」ページ
|
4.作業フェーズの対応
|
上記の「3.ベンダとの共同・連携」の実施を前提に、各作業フェーズへの対応を行います。未経験の作業で戸惑いも起こりますが、作業目的と成果物を理解して作業にのぞむことです。作業開始前のベンダとの事前打合せを重視します。
|

|
● 共通の対応
各作業フェーズに共通した作業開始前の確認事項です。これらの内容を自社メンバーが
理解し行動できるようにします。あやふやな理解で作業を始めると決して良い成果物はで
きません。
① 作業目的・成果物を具体的なサンプル・事例で理解し、納得します。
② 作業スケジュール・納期に基づき、必要な工数・曜日・時間を把握します。
③ 作業に必要とする資料・データ・ドキュメントを用意します。(作成も有りえます)
④ 意思決定・合意・承認のルート/対象者を決め、徹底します。
⑤ 分科会方式での作業が必要あれば、分科会(グループ)の設置を行います。
⑥ 作業にメンバー以外の関係者が必要であれば、任命をします。体制を整えす。
⑦ 不明・疑問を含めた問題・要望の取扱ルールを決めます。
|
|
● 各作業フェーズへの対応
作業フェーズはベンダにより異なりますので、作業フェーズの名称に惑わされずその作業
内容を把握します。上記「共通の対応」を参考にして、作業フェーズ固有の作業への対応
を行います。
|
課題解決 |
|
要件定義
Fit&Gap
|
|
テスト |
|
稼動準備 |
- 現行システムからの移行対象(マスタ・トランザクション・・)を決めます。移行タイミング(稼動前・切替時・稼動後)も決めます。
- システム利用者に対する教育研修(システム操作・新業務処理・ルール・取引関連・・)を行います。 管理職も同様です。
- 必要があれば、取引先へのシステム稼動の案内を出します。
- 切替時の事前準備と役割分担(ベンダ、自社内)を決めます。
(情報システム、ハードウェア・ネットワーク・パソコン・・・)
- 自社内へ稼動時期・切替内容・改善事項などの周知徹底を広報します。
(参考) 「大切な稼動準備」ページ
|
「マネジメントとリーダシップ」は両輪
|
マネジメントとリーダシップはプロジェクトマネジメントの両輪です。この両方の側面があって、プロジェクト活動は効率的で活き活きしたものになります。メンバーのやる気なり責任ある行動は経営者とプロジェクトマネジャーの「頭・手・心・足」にかかっています。
|

● 「ユーザのためのパッケージ導入」セミナーのご案内
|
セミナーの目的
・ 受講結果、自社に戻り独力で必要な作業を消化できる。
・ 社内手続き、社内協力、資料作成及び問題解決を容易にする。
・ パッケージ選定、システム品質及び稼動に必要な知識が理解できる。
セミナーの内容
① 導入準備に必要な作業内容と実践ポイント
② 最良なパッケージ・ベンダ選定のための実施方法
③ 価値ある要件定義書を作成する実践ポイント
④ 安定稼動に必要なユーザテストと社内準備
開催の要領
「ユーザのためのパッケージ導入 徹底解説」セミナー
|
● プロジェクトマネジメントとしての問題解決策と予防策に関心のある方は
次ページを!
(参考) 「トラブル(問題)の解決策と予防策」ページ
● プロジェクトを成功させるために必要なプロジェクト管理の知識とスキルに
関心のある方は次ページを!
(参考) 「プロジェクト管理に必要な知識とスキル」ページ
● プロジェクト活動を統括する責任者の役割は大きいです。この統括責任者
のやるべきことに関心のある方は次ページを!
(参考) 「統括責任者のやるべきこと」ページ
● プロジェクト活動における問題の発見と現象、又は問題発生の原因に関心
のある方は次ページを!
(参考) 「トラブルの早期発見と兆候・現象・原因」ページ
