プロジェクト作成請負案件を円滑に受託、推進するために（２） ～ トラブル発生要因 ② ～
前回は、プロジェクトトラブル発生する場面として「１．顧客との交渉面（含む大手ベンダー）」、「２．マネジメント面」の２つの観点から考察しました。
今回は、「３．スケジュール精度（精緻度）面」、「４．プロジェクトチェックとリスク想定面」の２つの観点から、考察したいと思います。
３．スケジュールの精度（精緻度）面
作成するスケジュールは、「商談段階」、「受託段階」、「キックオフ段階（要件分析）」、「開発工程段階（設計～開発～テスト）」など、それぞれの段階（工程）ごとで、具体的な作業内容の固まり具合や進捗状況により、精緻さを深めていくことが重要であることは言うまでもありません。つまり、最初に策定したスケジュールに沿えば良いということではなく、プロジェクトの推進中の状況により、常にスケジュールの精度を上げる取り組みがなされていることが重要と考えます。
そこでは、「推進担当責任者」が、それぞれの段階・状況に応じて俯瞰的な考察を行い、効果的な取り組みを行っているかという観点で、検証し続けることが重要です。下記に、検証されるべき「要注意観点」について示します。
【作成されるスケジュールの精緻度検証内容】
■商談（提案）段階
顧客が求める要件が明確な形で提示（ＲＦＰ ）されている場合は、比較的明確なスケジュール（大線表レベル）提示が可能であると考えられますが、中には大枠な要件提示に留まり、口頭や「分かっているでしょ」的なことでの提案を求められる場合も少なくありません。
・ＲＦＰが提示されている場合
ＲＦＰに記載されている内容に関し、曖昧さが無いか検証されていること。説明会以外などの場も使い、十分な理解に努めること。
・ＲＦＰなどが無い場合
顧客に対し、リクエスト意図を理解する行動に努めること。より踏み込んだ理解を得るため、想定しえた「顧客要件」を逆提示しながら、確認をとること。
＊１：RFP（Request for Proposal）
「提案依頼書」のこと。提案を求めるベンダーやSIerなどに提示する、構築したいシステムに求める要件や機能をまとめたもの。
■受託段階
提案の結果、「受託」した際には、商談段階における提案内容を更に具体化し得るように、顧客との調整機会を作ること。
・受託したことに「浮かれる」ことなく、キックオフまでにそれまでの提案事項、スケジュールに関する補強を行うための取り組みを行うこと。（要件分析工程に必要な情報補強作業）
■キックオフ（要件分析）段階
受託段階で得た情報を基に、要件分析以降の「スケジュール」の策定と顧客との合意形成を図ること。特に、要件分析工程における「詳細作業項目と項目ごとのスケジュール」が提示できていること。
・作業項目、項目別作業規模に見合った体制、費用、条件（想定外事項発生時における対応）などが明示され、スケジューリングがなされていること。
■開発工程段階
要件分析工程での成果（生産物）を受け、開発工程における「詳細スケジュール策定」において、以下のレベル感が確保されていること。特に、本工程での精緻度が、プロジェクトの成否を決定づけると言っても過言ではありません。
・スケジュール作りにおいて、大線表（スケジュール）から「個人別の詳細作業スケジュール」まで、「ブレイクダウン型」のスケジュール（線表）が明確になっていること。
・特に、個人別作業スケジュールの「１作業内容ごとの期間」を確認すること。１作業期間が、週単位であるような場合は、再作成を要請または、指示すること。（週間単位は長い。最長「２～３日単位」になっていること）
・また、作業関係性（他の人やグループの持ち分との関連）について、明示されていること。（時期、連携タイミング、クリティカルパスなど）
■その他
開発に関わる現場部門の作業内容が、計画に規定（スケジュール化）されていること。
・現場部門に関わる「作業工程、内容」が、明確にされていること。
・運用テスト工程における「役割や責務」が、明確にされていること。
・現場場部門への「教育」に関わることが、明確にされていること。
以上のような事項を、具体的かつ明確に規定していることに加え、事前に「作業工程見直し条件」を明確化していることが肝要と考えます。
４．プロジェクトチェックとリスク想定面
トラブルを発生させないためには、以下に記した事項の「検証」を曖昧にすることなく、時間的制約があっても安易に許容しない「社内マネジメント」が重要と考えます。そのためには、商談検討会や見積検討会、さらにプロジェクト進行中の「ＰＡ会（前回を参照）」実施時などで、監査の甘さを回避できるかが肝要になると考えます。以下に、検証が甘くなる主なポイントについて示します。
【プロジェクトチェック体制、仕組み、取り組み意識検証内容】
■検証項目を「ひとつひとつ」潰す、チェック体制、仕組み不足傾向
・標準的なチェックシート（検証項目）があるにも関わらず、自社仕様ではない、自身の経験則や今回のプロジェクトには合わないといったことを言い訳に、使用することを回避する傾向や、それを許容する社内マネジメント。（「いちいち使うのが面倒くさい」が先行？）
・自分の経験や有識者の考えを「優先してしまう（信じてしまう）」傾向。
・あいつがやっているから大丈夫という、チェックサイドの「楽」したがり意識。（「人」依存型マネジメント）
■リスクを「数値化」することを回避、面倒くさがる傾向（安心・安全より、顧客忖度・社内意向優先）
プロジェクトを運営するには、そこに潜むリスクをどれだけ顕在化できるかが重要であることは言うまでもありません。しかしながら、往々にして、潜んでいるリスクを「最少化」しようとする傾向に走りがちです。
・リスクを数値化すると、見積もり値が大きくなることから、顕在化を回避したがる傾向。（熟練者ほど強い）
・今、物理的、具体的に解が見いだせないことから回避する傾向。
・挙げても、面倒になるだけ意識や、回答は出してもらえないとの思い込み傾向。（無駄感）
・社内チェックシート（見積もり審査会用など）の記載内容が未完成でも、提出を許容してしまう傾向。（内容不足、確認不足の許容）
・チェック内容が「人の使い方（誰がどれだけ)」になりがちな傾向。
・マネジメント工数が、十分に確保されない傾向。（コスト抑え）
・社内マネジメント（監査）サイドが、チェックすべき観点を十分に理解できていない可能性。（不慣れ）
■「現物」で確認、検証する癖が付いていない社内マネジメント傾向
・報告書に記載された事項を鵜呑みにする（したい）傾向。（性善説優位、楽したい意識）
・報告された内容を、裏付ける「現物」を確認しない傾向。
・工程終了時や、テスト（結合テスト、総合テスト）段階で、初めて「現物の質」が分かる傾向。（後手検証癖）
（単体テストは、プログラマー依存型運営（プログラマ責任）が多い）
･事前に検証するという「癖」が、ついていない傾向。（後の楽より、今の楽を優先する癖）
端的に言うと、作業の進捗やコスト、スケジュール合わせを優先するがあまり、必要なチェックポイントでの確認やリスク検証が「おざなりになる」社内チェック体制になってしまっていないかということです。
次回（４８回）は、推進中のプロジェクトの「⒌プロジェクト統制面」「⒍社内統制面」の２つの観点から考察し、最後に「７．まとめ（検証観点）」として、実践されているかの検証ポイントを示しておきたいと思います。
【過去の関連投稿】
・第４６回