【ページ構成】　■ 効果のある「問題解決の枠組み」
　　　　　　　　　　　　　　　　　 ■ 解決につながる「問題」の捉え方
　　　　　　　　　　　　　　　　　 ■ 確かな結果を出す「問題解決」の方法
　　　　　　　　　　　　　　　　　 ■ 作業工程別の「問題」への対応
　　　　　　　　　　　　　　　　　 ■ 問題を起こさない予防策の実行
　　　　　　　　　　　　　　　　　 ■ 「トラブル予防」の余話　　　　　　　

中堅・中小企業におけるパッケージ導入プロジェクト（システム開発も同様）のトラブル対応は、次のような背景を有しているのが一般的と考えます。

　　　　　　　  ① プロジェクト活動が進行中であり、止められない作業を抱えている。
　　　　　　　  ② 計画とその進捗において、工数・時間・資源に余裕がない。
　　　　　　　  ③ トラブルの影響範囲がどこまでか読めない、対策が不明な面がある。

プロジェクト活動の厳しい状況の中で、トラブル（問題）に立ち向かうことになります。トラブル解決への第一歩はその問題をしっかりと把握し認識することです。この真の問題の捉え方を履き違えるとトラブルの解決どころかトラブルの深みにはまります。「問題」とは何かを知ることです。目先の現象に振り回されると、せっかくの問題解決が徒労に終わります。

　　      
問題解決を行うためには、トラブル現象から「問題」を正確に捉えることです。その「問題の根っこ＝根本原因」を理解し、関係するメンバーの協力を得て解決策と解決手順を決めます。

また、作業工程別（要件定義・テスト・・・・）の作業特性を踏まえた問題解決を行うことが必要になります。プロジェクトマネジメントとして、トラブル（問題）の予防策を立案し実行することです。
          【参考】　ダウンロード資料 ＜630　「ベンダ向けプロジェクト・コントロールの要点」＞
　　　　

問題が発生すると問題の大小にかかわらず、現象にとらわれたり目先のことに注意しがちです。
真の問題解決に至らず第二の災害（問題発生）を招くことにもなりかねません。限られた時間と資源の中で、効率的で効果的な問題解決を行うには腰を据えた取り組みが必要不可欠です。「問題解決の枠組み」を理解し応用することです。
　
　　　　　１．前提条件
　　　　　　　　　　・ ユーザとベンダのプロジェクト契約内容、約束事項
　　　　　　　　　　・ プロジェクト活動の進捗実績、資源・工数・期間の消化と残
             　　　　・ 問題発生の場所は主にユーザとベンダとの現場
　　　　　２．「問題」の捉え方
　　　　　　　　　　・ 「兆候・現象の把握」による問題発生の確認
　　　　　　　　　　・ 問題発生に関連する「情報収集と事実確認」
　　　　　　　　　　・ 「原因分析」「影響範囲」による基本原因の重要度整理
                          （参考）　「トラブルの早期発見」ページの「兆候・現象・原因」の関連性
　　　　　３．「解決」の方法
　　　　　　　　　　・ 何が本当の問題かの「問題特定」
　　　　　　　　　　・ ５Ｗ１Ｈと責任者を明確にした「解決策」作成
　　　　　　　　　　・ リカバリーの対応を含めた解決のための「解決手順」作成
　　　　　４．姿勢
　　　　　　　　　　・ プロジェクト活動（連携・作業・ＷＢＳ)に対するリーダシップ
　　　　　　　　　　・ 「４ Relation」「５ Ｂｏｘ」「３ Ｖｉｅｗｐｏｉｎｔ」の基本的な捉え方
　　　　　　　　　　　　　　　【参考】　ダウンロード資料 ＜570　「４－５－３視座」＞

           ５．当事者意識の保有
　　　　　　　　　　・ 問題解決者（プロジェクトマネジャー）が自分の責任で解決する覚悟
　　　　　　　　　　・ 特に、プロジェクトマネジャーの交代による問題解決においては、前任者・
　　　　　　　　　　　担当ＳＥに問題原因・責任転嫁を行わない当事者意識を持つ重要性
　　　　　　　　　　・ 愚痴・嘆き・ボヤキ・評論家的言辞・第三者的発言は禁句

この「問題解決の枠組み」を有効に機能させるための留意点があります。問題解決を図ることは、メンバー・関係者へのプロジェクト活動の最終ゴールへの再確認と再発防止の教育機会の場でもあります。「禍を転じて福となす」です。福は無事なシステム稼働というゴールです。

　　　　　　　■　ベンダ主体の作業でユーザの協力を最大限に得る。
　　　　　　　■　解決策はクールな判断・指示とともに、メンバーへの指導・支援を兼ねる。
　　　　　　　■　目先にとらわれず、大局観（会社組織・統括責任者の立場）を持つ。
　　　　　　　■　問題の「現象・原因・解決策」をメンバー/関係者に公表し、情報共有を図る。
　　　　　　　■　どんな小さな問題でも、この「問題解決の枠組み」を使用する。

何が本当の問題かを明確にする「問題の特定」とその「問題の対象」はどこにあるかを明らかにすることが問題解決の肝です。この「問題」の捉え方を間違えると問題解決どころか問題の傷を深めることになります。ユーザの方が問題の把握をしているケースも多いです。
.
　●　問題の特定　
　　　　　１．情報収集　（現場の声・現場の問題を重視）
　　　　　　　　　　・ ユーザの声（責任者・メンバー）、ベンダメンバーの声
　　　　　　　　　　・ 「なぜ」という問題意識で、質問の組立と実施
　　　　　　　　　　・ 関係する成果物、ドキュメント、マネジメント資料の収集と評価
　　　　　２．事実確認　（ユーザとの現場・現物・客観性を重視）
　　　　　　　　　　・ 口頭でなく、成果物・ドキュメント・マネジメント資料で問題の把握
　　　　　　　　　　・ 「計画／実績の差異」「品質・スケジュール」「プロジェクト運営」の
　　　　　　　　　　　どこが問題かを特定（複数もあり得る）
　　　　　３．原因分析　（真の原因を究明）
　　　　　　　　　　・ 「なぜ」「どうして」の問いと問題意識で、因果関係の整理
　　　　　　　　　　・ 「情報と事実」の材料を基に実施（思惑・憶測は一切排除）
　　　　　４．影響範囲　（「鳥の目」で実施）
　　　　　　　　　　・ 他作業、スケジュールなどへの影響有無の確認と判断
　　　　　　　　　　・ 「真の原因」からの因果関係でチェック
                                    【参考】　ダウンロード資料 ＜812　「問題解決」の進め方＞

　●　問題の対象
　　　　　１．マネジメント・オペレーション
　　　　　　　　　　・ ＷＢＳ、スケジュール、方針、運営、作業環境などのプロジェクト計画
　　　　　　　　　　・ 作業の仕方、スキル、知識、必要情報、工数などの作業関連
　　　　　　　　　　・ 主たる問題はマネジメントかオペレーション（作業）かの判断が大事
　　　　　２．個人・リーダ・チーム・ＰＭ・ユーザ
　　　　　　　　　　・ 「人」が行っている故、「人」が対象（責任云々は別）
　　　　　　　　　　・ 働き、知識、スキル、姿勢、経験、工数などの評価と判断

　　　　　３．過去・現在・先行き
　　　　　　　　　　・ 顕在問題と先行きに生じる潜在問題の有無と確認
　　　　　　　　　　・ 時系列での問題の変化（縮小・拡大）への評価と判断

「問題の特定・問題の対象」を絞り込む際に、プロジェクトの全体観を有して作業を行うことです。プロジェクト活動は大海原を航海する船であり、乗組員の果たす役割が大きいです。
　　　　　　　　①　プロジェクト活動の雰囲気・メンバーの士気・チームワーク・情報共有
　　　　　　　　　　 などの状況を把握します。
　　　　　　　　②　プロジェクト全体の作業進捗・成果物の品質などを「全体の中の部分」「部分の
　　　　　　　　　　 積重ねとしての全体」としてつかみます。
　　　　　　　　③　ユーザとベンダ間のチームワーク・役割分担の働き具合を押さえます。

問題の特定と対象が明らかになると、それに対する問題解決の作業を実務的に行うことになります。解決策は限られた時間の中で、間違いのない結果をだすことです。解決策に必要な検討対象と手順をまとめました。   

　原因の除去

• 問題発生の原因の全てを除去する対策をたてます。
• 原因の対象は、スキル・プロジェクト運営・計画の立て方・担当の姿勢・ＰＭなどが想定されます。
• ユーザ/ベンダ、マネジメント/オペレーションの側面もあり得ます。

• 間違いなく原因除去と改善効果のある具体的解決策を創りだします。
• 原因に応じた個別解決策の集合がトータル解決策になります。個別解決策の仮設検証も必要です。
• 対策実行のために必要なコスト/工数/期間/スキルが根拠として必要不可欠です。　

　マイナス面の
　　　　リカバリー

• 問題発生による品質劣化/計画ロス/スケジュール遅れなどの失った事項への回復対策も必要です。
• 問題発生により影響を受けた範囲（作業・成果物・スケジュール・・・）が対象になります。

•  解決策の一つに、二度と起こしてはならない再発止策が必要です。
• この策があって、真の具体的解決策となります。

• 解決策の中に、作業途中でチェックする内容/時期をいれます。（例：成果物、技術、作業進捗、運営、計画・・・・）
• 大きなトラブルほど、このチェックポイントをきめ細かく設定することです。

• 上記の内容を明らかにして、５W２Hを含めた現実的な計画を作成します。必要があれば解決策専用の要員を入れた解決策チームを立ち上げます。
• プロジェクト計画の見直しから実行計画を組むこともありえます。「急がば回れ」です。

　ベンダレビュー
　ユーザレビュー

• それぞれの統括責任者を入れての「解決策・実行計画」のレビューを行います。いろいろな人の意見・指摘には少なからず参考情報があります。
• 実行計画に対する協力を含めて、解決策の承認を得ます。

トラブル（問題）発生への解決策は、基本的にはマネジメントの強化/スキル・知識の増強/計画の見直しのいずれかに帰着します。おのおのの作業工程において生じる問題に対しても、同様です。解決策の深さと広さを別にしても、その一つか複数に関わりがあります。また、問題発生は、その作業の前工程の成果物に原因がありえます。このことに注意することも必要です。

　要件定義

　ＦＩＴ&ＧＡＰ

• 成果であるドキュメント内容を具体性／網羅性／論理性を明らかにし、次工程以降で使えるようにします。
• スキル・知識担当のＳＥ／ＰＭを含めて体制を強化します。
  【前工程の問題】
  　　　・ プロジェクト体制、契約事項、成果物確認の曖昧さ・・
  　　　　　　（参考）　「要件定義・ＦＩＴ&ＧＡＰ」ページ

　カスタマイズ

　製造

• スキル・工数・期間・作業の相関性などの問題の所在を明らかにし、その原因の除去を行います。
• 作業に必要なドキュメント内容を点検し、欠陥を補います。
  【前工程の問題】
  　　　・ 成果物の網羅性／論理性／具体性の欠如・・・
                （参考）　「価値ある要件定義の成果物」ページ　

　テスト

• テスト現象の問題分析を行いその原因除去の策を作ります。
• テスト実施の前に、プレテストを行い問題有無を確認します。
• テストの計画／管理／体制の基本を重視します。
  【前工程の問題】;
  　　 ・ 単体テストの軽視、ドキュメントの曖昧さなど多様な原
  　　　　因の関連性 
     　　　　　（参考）　「テスト作業と品質管理」ページ

• 問題分析に応じて、緊急性と保留対応に分ける。改善要望もこの作業に含めます。
• 問題の原因（前作業の工程）を明らかにし、その原因の除去を行います。 その際、基本事項（カスタマイズ・テストのミスなど）を明確にします。
  【前工程の問題】
  　　・ 全ての工程に関して点検、真の原因究明

プロジェクト活動は最小限に問題発生を押さえることが大きなテーマですし、プロジェクトマネジャーの重要な仕事です。問題の発生を事前に防止したり、問題の芽をつぶしたりする予防策が必要になります。無防備では決して問題発生を防ぐことはできません。その予防策を身に着け実行することがプロジェクトマネジメントの要諦です。
　　　　　　　【参考】　ダウンロード資料 ＜635　「プロジェクトマネジメント向上のために」＞
    
　　■　「予防策の３原則」
　　　　　　この３原則を根底において、プロジェクトマネジメントなりプロジェクト活動を行うことが
　　　　　　予防の出発点と考えます。

　　　　　　　　　　①　「品質」が全てにおいて優先する。品質評価なきマネジメント・判断は
　　　　　　　　　　　　 羅針盤なき航海に等しい。
　　　　　　　　　　②　成果物はドキュメントをベースにした事実確認を必ず行う。人任せ・意
　　　　　　　　　　　　 見・推測などの評価は無責任なマネジメントに陥り易い。
　　　　　　　　　　③　ユーザ/ベンダの経営者・関係者を含めて、全てのプロジェクト資源を
                           有効に使う。無用な遠慮は貴重な機会を失う。

 　　　　　●　プロジェクトマネジメントの実践
　　　　　　　　　　①　トラブル兆候を軽く見ない。
　　　　　　　　　　　　　　　・　小さな芽を見つける（トラブルはつまらないことから始まる）
　　　　　　　　　　　　　　　・　ユーザ・ベンダともにメンバー・関係者の話をよく聞く
　　　　　　　　　　　　　　　　　　　　　　　　　（人は自分以外のことをよく見て、感じている）
　　　　　　　　　　　　　　　・　「計画」「成果物の品質」との小さなズレを見逃さない　
　　　　　　　　　　②　チェックポイントを持つ。
　　　　　　　　　　　　　　　・　作業の途中で、進捗状況・成果を点検する（ゴールでの事故防止）
　　　　　　　　　　　　　　　・　新技術の採用、初めてのメンバー、ユーザの動向、リスクのある
　　　　　　　　　　　　　　　　　タスクなどに適用する（チェック基準を設ける）
　　　　　　　　　　　　　　　・　人は信頼する、しかし、「人の成果物は疑え」で臨む
　　　　　　　　　　③　重点管理を行う。
　　　　　　　　　　　　　　　・　WBSにも特別に管理するリスクの高い作業項目がある
　　　　　　　　　　　　　　　　　　　　　　　　　（支援・指導を含めた体制を敷く）
　　　　　　　　　　　　　　　・　要件定義での重要仕様、ＰＧテストでの重要プログラム・仕様、
　　　　　　　　　　　　　　　　　新技術の適用などに対して行う（適格なメンバーアサインが前提）
                                        【参考】ダウンロード資料＜570　「４－５－３」視座＞

　　　　　●　体制・運営へのクールな対処
　　　　　　　　　　①　メンバーの実力を見極めて、責任ある体制にする
　　　　　　　　　　　　　　　・　肩書きなり会社所属などで決めない（不適格者が上に立つと、その
　　　　　　　　　　　　　　　　　　　　　　　　　　チームはそれ以下の成果しか出せない）
　　　　　　　　　　　　　　　・　必要に応じて、体制の変更を行う（ＰＭの仕事）
　　　　　　　　　　②　参加メンバーの動機付けを行う
　　　　　　　　　　　　　　　・ 　メンバーの実力（技術・知識）を確認、合意する
　　　　　　　　　　　　　　　・　やる気、積極性、問題意識は大事なプロジェクト資源である
　　　　　　　　　　③　運営ルールを「見える化」する
　　　　　　　　　　　　　　　・　情報共有、情報伝達、変更情報の取扱に関してユーザ、メンバー
　　　　　　　　　　　　　　　　　を含めて公平にルールを決める　
　　　　　　　　　　　　　　　・　ユーザ、メンバー、関係者からの問題提起・意見を吸収する
　　　　　　　　　　　　　　　　　機会を設ける　

　　　　　●　ずれる計画への管理方法　
　　　　　　　　　　①　計画は予定通りに進まない
　　　　　　　　　　　　　　　・　差異／漏れ／深化が発生するのが計画の一面である
　　　　　　　　　　　　　　　・　どんな作業でも他の作業／成果に影響を与えるリスクがある
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（作業計画・WBSへの過信は禁物）
　　　　　　　　　　②　計画は早めに作る
　　　　　　　　　　　　　　　・　関係者の目に触れさせ、レビューを受ける
　　　　　　　　　　　　　　　・　非現実的な目標と計画を立てない、あせらない
　　　　　　　　　　　　　　　・　関連する計画／ＷＢＳ／作業との相関性を重視する
　　　　　　　　　　　　　　　・　コストも考慮に入れる
　　　　　　　　　　　　　

プロジェクト活動のトラブル（問題）予防は、つね日頃からの行動なり仕事への姿勢が大切です。第一の予防はそこにあります。
　　　　　　　　・　プロジェクトマネジャーは足を使って、プロジェクト活動の現場を観察する。その観
　　　　　　　　　　察の結果、頭を使って事実確認と情報整理及び分析を行う。
　　　　　　　　・　トラブルは「つまらないこと・小さなこと・どうでもよいこと」から始まる。
　　　　　　　　・　プロジェクトマネジャーのエネルギーの多くが自社内に向かっているときは、プロ
　　　　　　　　　　ジェクト活動がうまくいっていない。相手をクールに見る余裕を失う。
　　　　　　　　・　トラブル対応は正常に対して「３倍のエネルギー」が消費することを肝に銘じる。
　　　　　　　　・　SEの仕事を集中させる環境と条件を最優先する。不要な打合せは避ける。
　　　　　　　　・　「トラブルは最高の学びの場」と心得て、二度と起こさない予防ノウハウを学ぶ。