【ページ構成】　■ 中堅・中小企業と大企業のプロジェクトマネジメントの違い
　　　　　　　　　　　　　　　　　　　 ■ 中堅・中小企業向けプロジェクトマネジメントのあり方
　　　　　　　　　　　　　　　　　　　 ■ プロジェクトを成功させる要因とリスクマネジメント
　　　　　　　　　　　　　　　　　　　 ■ 自社（ユーザ）とベンダのクールな関係

　中堅・中小企業におけるパッケージ導入（クラウド導入・システム開発も同様）のプロジェクトマネジメントは、大企業より中堅・中小企業の方が困難さと独自性を伴う側面が多々あります。その困難さと独自性を考慮しつつ、成果に責任を持つプロジェクトマネジャーとプロジェクトリーダに必要なポイント/着眼点/スキルをまとめました。また、リスクマネジメントの面からも触れています。
　今までの情報システムのプロジェクトマネジメントはベンダの立場のみを対象とする傾向があります。ここに、中堅・中小企業のプロジェクト活動を成功させる際の弱点があります。「ベンダ」「自社（ユーザ）」「ユーザとベンダの共同・連携」をプロジェクトマネジメントの対象領域として捉えることが肝要です。次のような分野に関心がある場合はそのページを訪問してみて下さい。

　　　　● プロジェクト活動における問題の発見と現象、又は問題発生の原因に関心のある
　　　　　　方は次ページを！

                        　　　　（参考） 「トラブルの早期発見と兆候・現象・原因」ページ 

　　　　● プロジェクトマネジメントとしての問題解決策と予防策に関心のある方は次ページを！
　　　　　　　　　　 　　　　（参考）  「トラブル（問題）の解決策と予防策」ページ

　　　　● ユーザ（自社）として、プロジェクトの準備内容・計画・体制・運営・チェックポイント・
　　　　　　成功要因に関心のある方は次ページを！
　　　　　　　　　　 　　　　（参考）　「ユーザのためのプロジェクトマネジメント」ページ
　　　　● ベンダとして、プロジェクト活動を成功させるための要因・計画・運営・ユーザ対応・
　　　　　　対象領域、及びプロジェクトマネジャーのスキルに関心のある方は次ページを！
　　　　　　　　　　　　　　（参考）　「ベンダのためのプロジェクトマネジメント」ページ 

　　　　●　プロジェクト成果の役割を担うプロジェクトマネジャーとプロジェクトリーダに必要な
　　　　　　 知識とスキル及びノウハウに関心のある方は次ページを！
　　　　　　　　　　　　　　（参考）　「プロジェクト管理に必要な知識とスキル」ページ 

中堅・中小企業と大企業の違いは事業規模・経営力・構成人員など、その立つ事業基盤が全く異なります（一部例外はあります）。そのため、プロジェクトに必要な力量・経験・スタイルの差が自ずからあります。その差を考慮したプロジェクトマネジメントが中堅・中小企業に求められます。
情報システムのプロジェクトに関する差（＝違い）は次のような点にあります。これらの差（＝違い）への理解がプロジェクトマネジメントの大切な下地になります。
    　　　　　　　　【参考】ダウンロード資料＜500　プロジェクトとプロジェクトマネジメント＞

プロジェクトを実行する上での制約条件と自社の抱えている問題を正しく認識することが、プロジェクトマネジメントの出発点です。無理をしたり背伸びをすると、プロジェクトマネジメントのほころびがすぐさま現れます。「対象と着眼点」を前提にして、次の４点に注視しつつプロジェクトマネジメントを行うことです。また、プロジェクト活動を効果的に導くリーダシップの役割も大きいです。

１． 早期な問題発見と解決策の実行

　　　 問題・リスクがあるから、プロジェクト体制でパッケージ導入（情報システムの再構築）を
　　　　  行う必要があります。自社・ベンダが一丸となって、それらの問題解決とリスク回避をプロ
　　　　　ジェクトマネジメントの先導で行います。
                                        （参考） 「トラブルの早期発見と兆候・現象・原因」ページ 

　　　　　① プロジェクト経験の浅さ・体制の弱さ・対象業務（上記：中堅・中小企業と大企業
　　　　　　　の「プロジェクトマネジメント」の違い）からの問題の整理をします。
　　　　　　　　　【解決策】　・ 経営者への問題提起と支援依頼
　　　　　　　　　　　　　　　　・ 導入事例（失敗・成功）からのヒントとポイントを入手
　　　　　　　　　　　　　　　　　　     　　　　　　　　　（参考）　「導入事例の紹介」ページ
　　　　　　　　　　　　　　　　・ ベンダ（又は自社）への提案/提示/意見の依頼
　　　　　　　　　　　　　　　　・ 早期な問題解決が無理な場合は、優先的な問題管理の実施

　　　　　② 作業フェーズ（要件定義・テスト・・・）で、作業の進め方などの問題の発見を行
　　　　　　　います。

　　　　　　　　　【解決策】　・ 作業の開始前に、作業内容（成果物・スケジュール・必要情報・メン
　　　　　　　　　　　　　　　　　バー・時間）の確認と合意
　　　　　　　　　　　　　　　　・ 前の作業フェーズでの持ち越し問題・保留事項の確認とその解決策
　　　　　　　　　　　　　　　　　の具体化と合意
　　　　　　　　　　　　　　　　・ 作業途中においては、事実把握と発生原因/解決策の明確化と体
　　　　　　　　　　　　　　　　　制・メンバーの見直し/強化
                                           （参考）  「トラブル（問題）の解決策と予防策」ページ

　　　　　③ 成果物に関する品質問題の発見を行います。
　　　　　　　　　【解決策】　・ 各作業フェーズで出来た成果物の「理解不能・範囲漏れ・不安事
　　　　　　　　　　　　　　　　　項/矛盾」に対するベンダへ改善要求（一部、自社もありえます）
　　　　　　　　　　　　　　　　・ スキル不足の場合、具体的根拠を持ってベンダに提起

 ２．「自社とベンダ」間の共同・連携

　　　 自社プロジェクトとベンダプロジェクトの信頼に基づく作業の進め方がプロジェクトの成
　　　　  果を出します。ベンダが自社（ユーザ）プロジェクトを如何にして支援・指導を行うかが
           カギです。
          ① 自社プロジェクトが主体になり、ベンダプロジェクトを引っ張ってゆく姿勢と行動
　　　　　　 が必要です。他人任せ/他力本願は徒労に終わります。
　　　　　　　　　【ポイント】　・ ベンダ提示の資料/ドキュメントのチェックを励行し、不明/理解不
　　　　　　　　　　　　　　　　　 能/漏れなどは改善をベンダに要求（一知半解は事故の元）
　　　　　　　　　　　　　　　　・ コミュニケーション/情報共有/問題共有をルール化して、その確認
　　　　　　　　　　　　　　　　　 と調整の場を定期的に実施（本音と信頼感を基に）
　　　　　　　　　　　　　　　　・ ベンダプロジェクトの問題は統括責任者に早めの提起
　　　　　　　　　　　　　　　　　　　　　　ープロジェクトマネジャー/リーダの資質/能力
　　　　　　　　　　　　　　　　　　　　　　－プロジェクトメンバーの資質/姿勢/責任感/適性

　　　　② ベンダは自社（ユーザ）プロジェクトの弱み・問題点を常にウオッチし、その改
            善を速やかに提案することです。
　　　　　　　　　【ポイント】　・ 自社（ユーザ）の事実確認/資料提供/ドキュメント作成などは、サン
　　　　　　　　　　　　　　　　　  プル提示など具体的な支援が必要
　　　　　                         ・ スケジュール遅れ/意思決定の遅れ・迷いなどの発生は、遠慮なく
　　　　　　　　　　　　　　　　　 自社（ユーザ）に対して警告とマイナス面の提示(遠慮は無用）
                                          　　　－納期と最終成果物の品質への影響
　　　　　　　　　　　　　　　　　　　　　  －自社プロジェクトの体制/メンバーの変更
                                         　　（参考）　「ユーザのためのプロジェクトマネジメント」ページ
　　　　　　　　　　　　　　　　　　　　（参考）　「ベンダのためのプロジェクトマネジメント」ページ
 

 ３．作業フェーズの組立てと作業内容

　　　 プロジェクトの開始における作業フェーズの組立てはプロジェクトマネジメントの最初の重
　　　　　要な作業です。この作業結果は少なからず最終成果物の品質と目的達成に影響を与え
　　　　　ます。当然、予算の制約を踏まえて効果のある作業フェーズの組立てを行います。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　（参考）　「基本手順とパターン選択」ページ
          ① 目的達成/課題解決の視点から、自社のスタートの作業フェーズを決めます。プ
　　　　　　 ロジェクト発足の準備作業で決めることが望ましいです。
                    【ポイント】　・ 情報システム以前の業務ルール/管理基準/取引条件/問題整理
　　　　　　　　　　　　　　　　　 などの範囲と大小の整理
                         　　　　　・ それらの課題/問題の消化が自社のみで行うことが可能か否かの
　　　　　　　　　　　　　　　　　 判断と実行計画の作成

　　　　　　　　　　　　　　　　　　　　　　　　　（参考）　「やさしい導入計画（実行計画）」ページ　　　　　　　　　　　　　　
　　　　② 各フェーズごとのベンダと自社の作業内容と役割分担、及びその作業の相関性
              を具体的に理解し行動できる条件を整えることが重要です。
　　　　　　　　　【ポイント】　・ 作業の成果物/スケジュール/納期、及び次作業フェーズとの連携
　　　　　　　　　　　　　　　　　 に関する理解と合意
                                    ・ 作業途中で発生した不明・疑問事項への対応ルール化とそれらの
　　　　　　　　　　　　　　　　　 情報管理の徹底
                                    ・ 成果物に対する「自社」「ベンダ」「自社・ベンダ共同」のレビューの　　　　　　　　　　　　　 　　　　　　　　　
　　　　　　　　　　　　　　　　　 スケジュール/参加者の計画と実施                                       

  ４．自社・ベンダともに学び、成長できる環境

　　　 成功したプロジェクトには成長したプロジェクトメンバーとSEが必ずいます。プロジェクト活
　　　　  動は人を成長させる場であり機会でもあります。「無から有」を創る側面と「全体観」「コミ
           ュニケーション」の重要さを持ち合わせているのがプロジェクト活動の特徴です。
      　　① プロジェクトメンバー/SEに対して、コミュニケーションと情報共有を基にオープ
              ンにして規律ある作業環境を作り活動をしやすくします。
                    【行動指針】　・ プロジェクト参加メンバー/SEに対して、プロジェクトの目的/対象
　　　　　　　　　　　　　　　　　　 範囲/担当業務などを説明し、理解をえます。
                       　　　　　　　・ 参加メンバー/SEからの要望を聞き、個人目標に近づけた作業依
　　　　　　　　　　　　　　　　　　 頼を本人と合意します。（不可の場合、今後の考慮事項とします）
　　　　　　　　　　　　　　　　　・ 参加メンバーに対して、可能なかぎり自由裁量権を与えます。
　　　　　② セッション/打合せの場を重視し、お互いに対等な関係で討議し合意を得る環
　　　　　　　境にすることです。
　　　　　　　　　【行動指針】　・ セッション/打合せルールを作り、そのルールに則って討議と合意
　　　　　　　　　　　　　　　　　　 及び意思決定を行う習慣にします。
                                       ・ 意見/討議は事実なりドキュメント資料に基づいて行い、なるべく
　　　　　　　　　　　　　　　　　　  主観的意見なり推測などは避けることです。
                                       ・ 全社的視点/社会的要因/事業環境などの観点も入れながら意
　　　　　　　　　　　　　　　　　　　見/討議を進めることです。
           　　 【参考】ダウンロード資料＜520　パッケージ導入における「セッション」の役割＞
                        

プロジェクトマネジャーは情報システムのプロジェクトを成功に導く要因を知っておくことです。これらの要因を自社（ユーザ）とベンダの立場から理解しておくことがプロジェクトマネジメントを豊かにさせます。また、成功要因は裏返せばリスク要因にもなりえることに注意を要します。
「蟻の穴から堤も崩れる」の諺のように、これらの大小の要因を一つでも軽く見ないこと、また、お互いの要因が城壁の石のように連携しあっている面を見ることがプロジェクトマネジメントとリスクマネジメントに必要な見方です。

　　・プロジェクト要因、システム要因に対して、そのリスク回避なり防止を行うには、プロジェクト
　　　活動において日常的にメンバー/SEが「生き生き」と活動することが大切です。その活動基
　　　盤を創るのはプロジェクトマネジメントの役割です。
　　　「時間・発想・運営」に注視したプロジェクトメンバーの活動基盤です。

     ① 限られた「時間」の活用
　　　　　→ プロジェクトの期間/納期/工数/メンバーなど限られた時間を有効に使うことです。
　　　　　→ メンバー間、自社・ベンダ間のコミュニケーションと情報共有により無駄の排除を徹底
　　　　　　　的に行い、作業効率と品質向上を図ります。

　　② 前向きな「発想」の結集
　　　　　→ メンバー/SEの意見、要望、アイデア、ノウハウなどの発想を尊重します。
　　　　　→それらのことが出しやすい討議と雰囲気を作り、ケジメのある結論に結びつくセッショ
               ン/打合せの場にします。

　　③ チームワークのある「運営」
　　　　　→メンバー/SEが自主的に行動し、プロジェクトの目的との関連で個々の責任を果たす
　　　　　　　運営を日常化します。
　　　　　→個々の作業目標と全体のプロジェクト目標をオープンにして、進捗管理・問題管理を行
　　　　　　　います。
　　　　　→問題のあるメンバー/SEへの対応は速やかに行うのが鉄則です。遅れればそれだけ
　　　　　　 失うものが大きいです。リカバリーに時間を要し、全体の足を引っ張ります。

　　・必ず問題が発生するのがプロジェクト活動です。その問題を未然に防いだり、問題発生を最
　　 小限のマイナスに押さえるのがリスクマネジメントです。プロジェクトマネジャーの優先すべき
      仕事ですし、プロジェクトマネジメントの中枢です。

　　　① 未然の防止
　　　　　　・ プロジェクト要因/システム要因に対して、要因の内容に応じた定期的な点検とレビ
　　　　　　　ューを行い必要な防止策を講じます。
             ・ 各作業フェーズにおいて、全体の要因に対して「重点管理」の対象を決め早めにチェ
　　　　　　　ックを入れます。全てを平等にマネジメントすることは不可能です。絵に描いた餅にな　　　
　　　　　　　りやすいです。
　　　　　  ・ リーダクラスのSE/メンバーからの声・意見を素直に聞き、事実確認/現場確認を行い
　　　　　　　ます。現象とその本質を見極め、事前の防止策を施します。

　　　② 問題発生への対策
　　　　　・ 問題が発生した場合は、その原因を特定します。原因は複数のケースが想定されま
　　　　　　す。真の原因から対策を打ち問題解決を図ります。
　　　　　・ 問題で生じたマイナス面（金額・スケジュール遅れ・品質低下）などを明らかにして、リ
　　　　　　カバリー策を含め関係者に報告します。
　　　　　・ 同じ問題、また類似な問題が発生しない予防策を立てて実行することです。
　　　　　　　　　　　　　【参考】ダウンロード資料＜530　「リスクマネジメント」に関して＞

            ・自社（ユーザ）とベンダの実力を「ランク」分けをしました。一つの目安としての参考情
              報です。
　　　　　 ・自社とベンダのランク別の組合せによる、プロジェクト活動の結果を示しています。
　　　　　　　　　　　（満足）　→　プロジェクトの成功を意味しております。ほぼ、目的達成の実現を
　　　　　　　　　　　　　　　　　　　果たした状況になります。
　　　　　　　　　　　（不満）　→　どちらかに問題を抱えていると、その問題を持っている方のランク
　　　　　　　　　　　　　　　　　　　のレベルに合ったプロジェクトの到達点になります。不満が多少
　　　　　　　　　　　　　　　　　　　残ります。
　　　　　　　　　　　（失敗）　→　プロジェクト活動の結果は、失敗と言えます。目的達成どころでは　　
　　　　　　　　　　　　　　　　　　　ないと想定できます。
                                                          （参考） 「信頼できるベンダ評価と選択」ページ