【ページ構成】　■ 「兆候・現象・原因」の関連性
　　　　　　　　　　　　　　　　　 ■ プロジェクト活動とトラブル発見
　　　　　　　　　　　　　　　　　 ■ 「要件定義・ＦＩＴ&ＧＡＰ作業」におけるトラブル現象
　　　　　　　　　　　　　　　　　 ■ トラブル防止のチェックポイント
　　　　　　　　　　　　　　　　　 ■ 「プロジェクト活動への参加」余話　　　　　　　　　　

パッケージ導入プロジェクト（システム開発も同様）のトラブル発生は、避けて通ることはできません。プロジェクトマネジメントは想定外に起こる問題（やっかいなこと、事故、計画外・・・）に対処するためにあるとも言えます。また、トラブルを最小限に抑えたり、未然に防止することです。
トラブル発生によるプロジェクトへの影響から見ると、情報システム作業のプロジェクト特性は次のような点があります。

　　　　　　　  ① 全ての作業がお互いに関連し、影響し合っている。
　　　　　　　  ② 当初の作業計画（実行計画）通り、作業は完璧に進まない。
　　　　　　　  ③ 人に依存しているため、作業品質にバラツキがある。

如何にしてトラブル発生の芽を早期に見つけその芽をつぶすかがプロジェクトマネジメントの仕事になります。プロジェクト活動のトラブル兆候を見逃さないことです。次に、その兆候がどのようなトラブル現象になるかを速やかに見極めることです。そして、その現象が生じた根本原因を特定することです。「兆候・現象・原因の関連性」を頭に入れて、日常的にプロジェクト活動を観察することがトラブルの対策と防止に有効と考えます。
      
プロジェクト活動は、さまざまな経験の異なる人が目的達成のために作業を行う場です。また、作業工程の成果物に対して機械装置による品質検査が行いにくく、人の判断に成果物の品質が依存します。プロジェクト活動の特質を次のようにたとえることができます。
この特質を理解して、プロジェクトマネジメントを行なうことです。　

　　　　　　　■　積み木
　　　　　　　　　　　　　　　人のさまざまな作業・仕事の積み重ねで成果物が生まれてきます。
　　　　　　　　　　　　　　　その成果物はお互いに関連し合っています。そのため、品質不良の
　　　　　　　　　　　　　　　成果物があるとバランスを失い「積み木」のように崩れおちる可能性が
　　　　　　　　　　　　　　　あります。

　　　　　　　■　御神輿（おみこし）
　　　　　　　　　　　　　　　 プロジェクト活動はメンバー・関係者で作業のかたまり（実行計画・
　　　　　　　　　　　　　　　 WBS)を支え合って前に進めます。
　　　　　　　　　　　　　　　 支える人が手を抜いたり力不足であると周りの人に、その分の負担が　
　　　　　　　　　　　　　　　 かかり「御神輿」を支え切れなくなります。
　　　　　　　　　　　　　　　　　　　　　＊WBS=Work Breakdown Structureの略、
　　　　　　　　　　　　　　　　　　　　　　　　　　プロジェクト全体を細かい作業に分割した構成図
　　　　　　　■　坂道
　　　　　　　　　　　　　　　安心できるシステム稼働という最終成果物を目指して、苦労しながら
　　　　　　　　　　　　　　　一歩一歩登っていきます。
　　　　　　　　　　　　　　　品質・納期・費用（予算）の基準・計画を外れると、その瞬間、重力に逆
　　　　　　　　　　　　　　　らえず登って来た「坂道」を転げ落ちることがあります。

　　　　　　　　　　　　　　　　（参考）　「成果をあげるプロジェクトマネジメント」ページ　　　　　　　　　

トラブル対策を行う事態になる前に必ず何らかの兆候・前触れがあります。その兆候が積み重なってトラブル現象になります。その現象にはそれを発生させた原因が隠れています。自然現象はありえません。この兆候の発見を見逃したり、現象・原因への適切な対策を怠ったりして無用なトラブルを招くケースが多いです。プロジェクト関係者はこの「兆候・現象・原因」の関連性と事実を把握し、観察力を身につけることです。事実ありきです。
　　　　

1. 「基準・計画・予定・約束・・・」などから少し外れた結果、行為、発言などに現れます。
2. 兆候は全て「現場」にあります。事実の把握です。
3. 外れた内容が同じ兆候で時系列に発生しているか、異なる兆候が同時に発生してるかを押さえます。

1. ベンダの声、ユーザの声、関係者の声
2. 当事者の沈黙・反応なし・言い訳・約束不履行・曖昧発言
3. 作業計画の遅れ、成果物の品質不良、作業の漏れ・抜け
4. プロジェクト方針／ルールの違反、理解不足
5. マイナス思考の意見・判断、他人批判、プロジェクトへの不信

1. 複数の兆候から継続性・傾向・体質を見極めます。
2. 「なぜ」と考え、個人・チーム・プロジェクトのトラブル対象範囲を見極めます。トラブル現象の事実確認です。
3. 現象から、その影響範囲とリスクを決めます。
4. 現象を発生させた原因を整理します。因果関係です。

1. スケジュール遅れ、見通しがきかない、納期厳守の困難 
2. 成果物が使えない、不十分、出来ない
3. 作業を任せられない、不安、スキル不足、知識不足
4. プロジェクト方針・目的からのズレ・抜け
5. チームワークの乱れ、プロジェクト情報の混乱

 「原因」の特定

1. 「個人・チーム・リーダ・プロジェクトマネジャー」の視点から事実の確認と整理を踏まえた原因分析を行います。
2. 上記１の視点とともに、マネジメントとオペレーション（作業）との関連もあります。マネジメントとしては、計画作成の無理・ＳＥアサインの失敗・プロジェクト運営の拙さ・情報共有の欠如などが考えられます。オペレーションは作業指導のミス／スキル不足／責任姿勢の欠如／経験不足などです。
3. ユーザとベンダの契約ミス・連携ミス・コミュニケーション不足もあります。 プロジェクト体制の不備もあり得ます。

相手のプロジェクト活動に対して、トラブルの兆候と現象を感じ発見することが大事です。ユーザからベンダ、ベンダからユーザに対してプロジェクト活動を日常的に注視することです。この客観的な観察から、早期なトラブル発見が容易になります。気付いたおかしな点・問題点などを相手に事実として速やかに伝えることです。遠慮は無用です。遅れは事故につながります。

    
噂・伝聞でなく、事実を把握して相手に伝えるべきです。事実に基づかない情報はプロジェクト活動に混乱を招くだけです。この情報収集と事実確認が、プロジェクトマネジャー・プロジェクトリーダのトラブル対応の仕事になります。

　　　　　■　「ユーザ」から見た「ベンダのトラブル兆候・現象」
　　　　　　　　　　・　ベンダ成果物の内容が理解できない、漏れている、抜けている
　　　　　　　　　　・　成果物作成の納期が守れない、作業（ＷＢＳ）のスケジュール変更が多い
　　　　　　　　　　・　プロジェクトメンバーの変更が頻繁に行われている
　　　　　　　　　　・　プロジェクトマネジャー、リーダの指導力が発揮されていない
　　　　　　　　　　・　プロジェクトメンバーの意見／発言／理解に、統一性が欠けている
　　　　　　　　　　・　ベンダからの提示・提案・提起の行為が見られない
　　　　　　　　　　・　ユーザの要望なり要求が打合せ、成果物に一向に反映されない
　　　　　　　　　　・　ＳＥのユーザ業務及びユーザの改善要求に関する理解力が弱い
　　　　　　　　　　・　パッケージ商品が約束した対象範囲、システム品質に対応できない
　　　　　　　　　　　　　　　　　（参考）　「ベンダのためのプロジェクトマネジメント」ページ

　　　　　■　「ベンダ」から見た「ユーザのトラブル兆候・現象」
　　　　　　　　　　・　打合せ、セッションへの出席者がばらついている
　　　　　　　　　　・　要望・要求した情報や資料の提示が遅れる、また、内容を満たしていない
　　　　　　　　　　・　経営者の参画度合いが弱く、経営者の顔が見えない
　　　　　　　　　　・　決定・確認・承認すべき事項の行為が遅く、ベンダ作業に影響が出ている
　　　　　　　　　　・　エンドユーザ・経営者に対する必要な情報収集と整理がやられていない
　　　　　　　　　　・　経営者・幹部に対する信頼感が薄く、プロジェクト活動への熱意がない
　　　　　　　　　　・　プロジェクトマネジャー（実行責任者）の指導力が弱い
　　　　　　　　　　　　　　　　　（参考）　「ユーザのためのプロジェクトマネジメント」ページ

要件定義・ＦＩＴ&ＧＡＰ作業におけるトラブルはプロジェクト活動に大きな影響を与えます。この作業のトラブル・ミスはあとあとの作業に必ず尾を引きます。特に、この作業には大きな注意を払う必要があります。
次のようなトラブル現象を起こさないために、その兆候と原因の関連を理解しプロジェクト活動の実践のなかで「観察と判断」を鍛えることです。
　　　　　　　　（下記ダウンロード資料の「現象－兆候－原因」関連表を参考にしてください）
　　　　　　　　　　　　　　【参考】　ダウンロード資料 ＜600　ベンダに関するトラブル発見＞
　　　　　　　　　　　　　　【参考】　ダウンロード資料 ＜610　ユーザに関するトラブル発見＞

　　　　　　■　ベンダのトラブル現象
　　　　　　　　　　　　　・　作業計画から漏れている作業がある
　　　　　　　　　　　　　・　作業スケジュールが遅れている
　　　　　　　　　　　　　・　作業スケジュールの変更が多い
　　　　　　　　　　　　　・　打合せ内容が充実していない
　　　　　　　　　　　　　・　プロジェクト運営がいい加減である
　　　　　　　　　　　　　・　プロジェクト体制又はプロジェクトマネジャーが機能していない
　　　　　　　　　　　　　・　プロジェクト体制の変更が多い、要員の変更がある
　　　　　　　　　　　　　・　ユーザが成果物に不安を持っている
　　　　　　　　　　　　　・　ＳＥがユーザの業務を理解していない、ＳＥのスキルが低い
　　　　　　　　　　　　　・　要件整理が進んでいない
                                    （参考）　「要件定義作業でのベンダ力量のチェックと判断」

　　　　　　■　ユーザのトラブル現象
　　　　　　　　　　　　　・　現状業務を押さえていない
　　　　　　　　　　　　　・　作業スケジュールが遅れている
　　　　　　　　　　　　　・　作業成果物の品質が落ちている
　　　　　　　　　　　　　・　プロジェクト運営がいい加減である
　　　　　　　　　　　　　・　メンバーが作業内容を理解していない
　　　　　　　　　　　　　・　要件整理の仕方が理解できていない
　　　　　　　　　　　　　・　要件定義作業が前に進まない

　　　　　　　　　　　　　　　　　（参考）　「要件定義・FIT&GAP」ページ
　　　　　　　　　　　　　　　　　（参考）　「価値ある要件定義の成果物」ページ

トラブルを起こさないことがプロジェクトマネジメントの目的の一つです。トラブル防止はプロジェクト活動を、クールな目で観察しチェックすることです。その観察は「なぜ、どうして」と疑問を常に持つことです。その疑問に対して、「兆候・現象・原因の関係」に基づて分析することがトラブル防止策を生きたものにします。他人任せでなく、自分の目と足で情報収集と事実確認を行う習慣が大事です。
　　　　　　　①　トラブル現象の最終結果は全て成果物の「品質」に辿りつきます。
　　　　　　　②　「対象範囲」「プロジェクト基本方針」「作業スケジュール」などのトラブル兆候
　　　　　　　　　・現象を早めにつかむことです。
　　　　　　　③　トラブル兆候・現象の原因には「プロジェクト運営」「プロジェクトマネジャー」「
　　　　　　　　　ＳＥ/担当者 スキル・姿勢」が関わっています。
                            （参考） 「トラブル（問題）の解決策と予防策」ページ 

【　トラブル防止のチェックポイント　】

(ユーザ) 　　 　・メンバー・関係者の納得、理解、合意による判断
　　　　　　　　　・最終成果物（システム稼働）との関連性
　　　　　　　　　・「目的・期待効果」の実現保証、稼働準備
(ベンダ) 　　　　・目的達成のシステム稼働の保証
　　　　　　　　　・最終成果物への有用性、必要性
　　　　　　　　　・レビュー、検証の実施
　　　　　　　　　・パッケージ商品の適合性、FIT率

(ユーザ)   　　　・契約の内容（提案書、見積を含む）、作業分担
　　　　　　　　　・最終成果物の保証、満足
　　　　　　　　　・パッケージ商品の対象範囲、システム機能
（ベンダ）　 　　・契約の内容（提案書、見積を含む）、作業分担
　　　　　　　　  ・要件仕様、システム機能の詳細、インターフェイス
　　　　　　　　　・パッケージ商品のカスタマイズ内容

　プロジェクト
　　　　基本方針

（ユーザ）　　　・「予算」内、プロジェクト定義
　　　　　　　　  ・「目的・期待効果」の達成
（ベンダ）　　　 ・「予算、契約」内、プロジェクト定義
　　　　　　　　　・「納期、品質、性能」の保証

（ユーザ）　　　・経営者を含めた要件、懸案事項の早期決定
　　　　　　　　  ・関係者の協力度合い
　　　　　　　　　・メンバー間の情報共有と意志統一
（ベンダ）　　　 ・プロジェクト情報（方針、問題管理の共有）
　　　　　　　　　・メンバー間の意志疎通 
　　　　　　　　　・ユーザプロジェクトへの支援、指導

（ユーザ）　　　 ・メンバー、担当者の支援、指導
　　　　　　　　　・チームワークの維持、経営者との意志疎通
（ベンダ）　　　  ・指示、判断、問題解決の実施
　　　　　　　　   ・プロジェクト状況の把握とリスク管理

　ＳＥ/担当者
　　スキル・姿勢

（ユーザ）　　　 ・打合せ、セッションへの参加
　　　　　　　　　 ・情報提供、資料作成の約束実行（内容・納期）
（ベンダ）　　　　・必要な知識、技術の保有（実績・経験）
　　　　　　　　　 ・プラス思考、責任感、コミュニケーション力
　　　　　　　　　 ・担当成果物の品質、納期

プロジェクト活動は貴重な体験の場であり、その機会を生かすか否かは参加する本人次第です。トラブル対応を含めて「プロジェクトの現場」は参加者を成長させる数少ない実践道場です。次のようなことを考慮して、プロジェクト活動に参加することです。

• プロジェクトを成功させる信念と姿勢で行った場合のトラブルは最大の学びの場です。苦しくとも逃げないことです。
• プロジェクト活動は品質管理が全てです。作業と成果物の品質管理なきプロジェクト管理と進捗管理は無に等しいマネジメントです。
• 「人を信じること」ですが、「人の成果物は疑え」です。レビュー・検証という関係者の行為でもって「人が作成した成果物」を認めることです。「猿も木から落ちる」です。
• ドキュメント重視で「確認・承認・了承」を行うことです。言葉はその場で終わりであり、証拠に残りません。また、言葉は「その場逃れ」の一面も現にあります。
• パッケージ導入は他の仕事スタイルと同様に扱うことです。特殊化して見ることに落し穴があります。業務改善の行為と同じように考えることです。
• 規模の大きいプロジェクト案件・難易度の高いプロジェクト案件ほど、トラブルが発生すると坂道を転がるのは速いです。 プロジェクトの失敗が目に見えます。
• 「１００％」の作業目標では１００％に達しません。「１２０％」程度の目標設定で１００％の目標達成が可能になります。品質・スケジュール・成果物に自分なりの作業目標を持ち、工夫とチャレンジをすることです。 そのことが「プラス２０％」という意味です。