プロジェクト作成請負案件を円滑に受託、推進するために（８）～ まとめ② トラブル回避に向けた取り組み施策 ～
まとめの第２回目は、商談段階からプロジェクト完了段階に至るまでの全工程に渡り、「留意すべきトラブル発生要因と回避に向けた取り組み施策」という観点で、工程ごとにまとめます。
1．主なトラブル発生要因について
商談段階から、プロジェクトの発足、推進、完了まで、それぞれのタイミングで起こり得る主要なトラブル発生要因と、その回避のための取り組み施策について、以下に再度まとめておきたいと思います。
■商談段階
・技術者（SE）が、動けない環境下にある。
商談段階から、SEが参画することが望ましいと考えますが、それが難しい環境下 にあるというのが、多くの中小ソフトハウスの現状です。
そのため、営業中心に「商談獲得に動かざるを得ない」という社内事情を抱えているということです。（対応可否の技術的な判断が甘くなる）
・適切な商談情報取得が難しい環境下にある。
中小ソフトハウスの場合、主ベンダーからの「二次請負型」の商談が多く、「間接的な情報だけ」を基に、受託可能性を検討することになりがち。さらに、発注される範囲の情報しか得られないことや、主ベンダーの事情（提案期間など）に縛られがち。
・適切な顧客（最終仕向け先）情報取得が難しい環境下にある。
商談内容同様、顧客キーマンなどの把握や、顧客サイドの体制、役割（責任範囲など）の掌握が受託後傾向になりがち。その為、自社体制、コストの見直しが必要と考えても、後手を踏むことになっています。
■見積もり段階
・主ベンダーとのやりとりが、不十分になりがち。
受託のための打ち合わせは、通常１～２回程度で済まされがち。そのため、担当SEの「経験や類似案件に基づく」想定（提案時）見積もりを、活かさざるを得ない状況になりがち。（実情より経験値での見積もり）
・主ベンダーの要請を、重視する傾向に陥りがち。
発注許容予算を意識し、受託額を抑えようとする傾向になりがち。特に、付き合いが長い相手ほど、その思い（想定発注額）を汲みがち。（リスク要素（必要なマネジメント工数など）を抑える傾向）
・会社組織としての「検証意識、体制」が弱い。
商談検討会、見積もり審査会は開催するも、形式的な検証 が中心で、本質論（本音）を戦わせない傾向になりがち。（議論回避体質）
■提案段階
・見積もり前提条件は付けるが、その実践が担保されない。
初期見積もりにおいて、一般的に「再見積もり条件」の記載は行われています。ただ、必要な事象が発生した際に、タイムリーに再見積もり要請できてはいないのが実情。往々にして、トラブル時が多いため、後回しになる傾向が高い。時間的制約に加え、責任論も重なり、要請タイミングを逸してしまい、請求できない事情も。
■プロジェクト発足段階
・マネジメントの実効性担保が、不十分での体制作り。
プロジェクトの体制作りにおいて、マネジメント要員、工数設定が形式的になり、実効性が疑わしい工数配分（時間が取れない）になりがち。（全体工数抑制のしわ寄せ）
・作業内容とメンバー体制に対し、組織的検証不足。
メンバーの「実力、実効性判断」をリーダー任せにし、会社としての「要員ノウハウ」に関して、組織的な検証がされていないのが実情。
・プロジェクトメンバー全員の意思疎通、理解度醸成不足。
メンバー担当分の消化を優先しようとする傾向が強く、「俯瞰的なものの見方」を奨励することなく、担当範囲のみの説明に限る傾向になりがち。歯車意識を醸成してしまっていると言えます。（連帯感非醸成）
■プロジェクト推進時段階
・現物を見ない報告を受け入れ、判断してしまう傾向。（性善説は楽）
進捗報告において、「報告書に書かれた字ずらだけ」で判断しようとする傾向が高い。「書かれていないコト」に、目を向けない心理が働きがち。
・フィードバックを、口頭で済せてしまう傾向。
報告に限らず、課題に対しても、言葉でのフォローで済ませる傾向に加え、その対応状況をフォローしないで済ませる傾向になりがち。
・報告、生産物について、作業中「実物検証」をしない傾向。
報告、検証における、内容要件や生産物について、曖昧さを許容してしまう傾向があり、現物確認や検収印を実際に得ることが少ないのが実情。
・テスト段階、工程検収段階で、初めて「現物検証」に動く傾向。
「プログラム検証時」や「次工程判定会議」時になって、初めて「現物の出来」を確認する傾向になりがち。特に、単体テストはプログラマー役割としていることが多いため、ＩＴ（結合テスト）工程で初めて「品質」を知ることが多く、後手を踏む大きな要因に。
・プロジェクト推進中の検証会議やＰＡ会の役割、主旨の形骸化。
「余計な仕事」意識があり、本質、本音的な会議の場にならない、しない傾向になりがち。「アリバイ的開催」という側面になっているのが実情。
■プロジェクト完了後
・プロジェクトは、「単発」対応意識が蔓延。
プロジェクト完了後、プロジェクトマネジメントに関する「継承性」を担保する取り組みがない。あくまで担当した「個人」のノウハウ止まりの傾向に。結果、会社、組織としての知的財産蓄積（ノウハウ）にならず、相手が変わると、同じことが繰り返される。
＊１：難しい環境下
SEの多くが、「顧客常駐型」の業務契約（派遣契約や常駐型ＳＥＳ契約）下にあり、自社内要請（商談活動）に簡単に動けないということ。
＊２：形式的な検証
会社規定の「売上、粗利」が許容値内か、社内事情を意識した社内本位（新人育成とか）の体制にしているかなどの検証。
２．解消のための基本的な取り組み観点
第一項に示した「解消するべき傾向」に対し、基本的な取り組み観点についてまとめます。
■段階別標準作業チェック集の整備と、教育の整備
・各作業段階別に、取り組むべき事項についての整備。
各作業段階における「確認事項漏れを最小限に抑える」ため、その作業項目などをまとめた「作業チェック集」を整備すること。
例：「作成請負プロジェクトにおける確認ポイント集」
・「確認ポイント集」を基にした、活用教育の整備。
作業レベルの向上、ノウハウの継承を実現するため、参考書的な位置づけとすることなく、実践での活用を徹底すること。そのための「教育」体制と、「受講時間」を確保 すること。
■作成請負プロジェクトノウハウの組織的強化
・作成請負プロジェクトを、専門にする「組織」整備。
個々人の「経験則」を、「組織ノウハウ」として拡充する仕組みを整備すること。ノウハウ継承の実現のため、「組織（係とか課）」化が望ましい。
■報告ということに関する「基本的な」取り組みの徹底
・「報告」「報告書」の意味の再定義と、その実践の徹底。
報告相手に「正確に分かってもらう、知らせる」ことの再徹底。その実践のために、「どうあるべきか、どうすべきか」の学習環境を整備すること。
・「事象」が書いてあれば良いという、認識回避の徹底。
事象（やったこと、起こったこと）だけを書くのではなく、その事象における問題点や課題、要因（背景）認識など、自分なりの見解も記載させることの意義を徹底すること。
・「自分の常識」で報告事項を捉える傾向の回避。
報告を上げる際、出来るだけ時系列に、「事実とその背景など」について、極力客観的な記載を行うように心がけさせること。
■厳格な会社規定の「運営」の徹底
・各標準手法、技法で規定されている進め方、作業内容の徹底。
プロジェクト作業工程において、適用する技術、方式、統制などについて、会社として「厳格に順守させる運営」を行うこと。（原則論）
・トラブル発生を想定した取り組みの徹底。（性悪説論）
人が行う限り、トラブルは避けられない事かもしれません。それ故、事前に発生リスクを想定し、その対処方法を検証しておくこと。その徹底を、義務付けること。リスクの数値化（工数や金額）は必須。
以上、トラブル発生要因とその回避に向けた主な取り組み施策についてまとめました。中でも、「トラブル要因の芽」は、商談段階に隠れていると言う意識で、取り組まれることが重要だと考えています。
再検証の際など、参考になればと思います。
＊３：「受講時間」の確保
教育時間を確保するためには、派遣契約や作業請負契約における、1か月の契約時間を見直すことが不可欠。（第50回「対外社内標準工数規定」の項参照）
次回最終回は、「作成請負商談受託の妥当性検証手順」についてまとめておきたいと思います。
【過去の関連投稿】
・第４６回
・第４７回
・第４８回
・第４９回
・第５０回
・第５１回
・第５２回