プロジェクト作成請負案件を円滑に受託、推進するために（５）～ トラブル回避原則② ～
前回、請負プロジェクト受託、推進時におけるトラブル回避のための原則として、「１．プロジェクト推進上の原則」と「２．プロジェクト運営上の原則」という２つの観点から考察しました。今回は、「３．顧客契約形態上の原則」と「４．見積もり原則」の２つの観点から考察したいと思います。
３．顧客契約形態上の原則
顧客との契約において、「双方の企業責任範囲」の認識が重要であるということは言うまでもないでしょう。しかしながら、日本のビジネス社会において、「契約書」の一条項として、ほぼ、必ず含まざるを得ない条項がある ことはご存知のことと思います。もちろんこの条項があるからという訳ではありませんが、なかなか「１か０」というように割り切った対応が出来ないことも確かなことです。
さらに、同じ顧客との関係が長くなればなるほど、「お互い様的な関係」になりがちであるのも、日本人的な感覚であるような印象があります。「理解し合う」ことは重要なことと思いますが、「忖度し合う関係」は決して褒められた関係ではないと考えます。
と言うことを踏まえ、顧客との関係は、基本的な契約原則に則った対応を行うことが非常に重要なことと考えています。
■顧客契約形態 による、責任の在り方の再認識の徹底。（作成請負（一括）、作業請負（委任）、派遣）
・作成請負で受託した際は、「工程別」に契約形態を変えること。
システム構築全般を受託するような場合、以下に示すように「工程」ごとの契約形態を選択することが望ましい。
・要件分析工程 ： 作業請負形態（委任）
生産物、成否は「顧客責任」。（自社要員マネジメントは、受託者責任）
・設計工程～開発工程 ： 作成請負形態（一括）
一般的に、「システム設計からシステムテスト工程」まで「受託者責任」。
・運用テスト工程 ： 作業請負形態（委任）
成否は、「顧客責任」。（自社要員マネジメントは、受託者責任）
・保守工程 ：作業請負形態（委任）
システム完成後の「保守全般」。（自社要員マネジメントは、受託者責任）
・要件分析工程での内容不備（不十分、曖昧さ）による問題が、後工程（設計、開発）で発覚した場合の責任問題（増加コスト負担分）について、「泣き寝入りしない 」取り組みが重要。
・対応する担当者が、「作成請負か、作業請負か」のどちらで契約されているのかということを熟知、認識すること、させること。（契約形態の理解度と認識（責任範囲）教育の徹底）
・契約は「個人対個人」と言うことではなく、あくまでも「会社対会社」であるということの再認識の徹底。特に、個人（担当者）が過度な「忖度」をしないように対応する教育、意識付けが重要。
顧客との話し合いを効果的に進めるためにも、「証跡（検収書類や、検収済の議事録など）」の確保が必須であることは、言うまでもありません。
＊１：盛り込まれる条項例
第〇〇条 (協議事項)
「本契約に記載のない事項または本契約の条項の解釈に疑義が生じたときは、甲乙双方速やかに協議の上解決する。」
つまり、契約事項として規定していないことについても、一概に「拒否」することはできず、「話し合い」をしなければならないということになります。
＊２：顧客契約形態
第４６回で、（注記＊２：作成請負（SI：System Integration））に掲載していますので、参照ください。
＊３：泣き寝入りしない
顧客との間で「齟齬」が生じた場合、「突っぱねろ」と言っているわけではありません。プロジェクトの推進にとって、「必要だと思われることは、必要なこととして求める（言うべきことは言う）」ということが、双方にとって重要なことであるということです。
４．見積もり原則
案件を受託する際は、開発案件に関わらず、どれぐらいの費用で対応可能かを提示すること、つまり「見積もり」を行うことが求められます。
見積もりは、顧客サイドの予算取りや、予算に見合うモノかといった判断に必要な行為であることから、「それなりの精度」が求められることは言うまでもありません。しかしながら、商談段階（提案段階）で正確な見積もりを行うことは、ほぼ不可能なことであることを双方認識していることもあり、時に双方都合よく解釈するということが起こり得ます。何かあれば「調整してくれるだろう」的な感覚でしょうか。
ということで、「見積もり」についても、段階的な提示を行う機会を確保しておくことが重要であると考えています。
■「見積もり」に関する原則（段階的見積もりと契約形態の選択）の徹底
・商談段階（第一次見積もり）
言うまでも無く、ＲＦＰに記載された要件に基づく「見積もり」か、提案活動時に得た情報に基づく「見積もり」であることの提示となります。この段階では、「想定見積もり」と言うことになるでしょう。
・受託段階（第二次見積もり）
受託後直ちに顧客との打ち合わせを実施し、「要件分析工程」における作業規模を試算、「作業請負契約」という形での見積もりを行うこと。
・要件分析完了段階（第三次見積もり）
開発フェーズに進めるかの判断をした上で、要件分析で得た情報に基づき開発規模を試算、「作成請負契約」という形での見積もりを行う。その際、受託者責任に依らない事由で開発工数が増加することが明白となった際などの為にも、「再見積もり」が行えるように合意しておくこと。
・開発段階（第四次見積もり）
「作成請負契約」後、開発中に発生した顧客サイドの責任に伴う開発増に対し、「再見積もり」を提示する。（合意書などの取り交わし）
・最終テスト（運用テスト）段階（第五次段階）
開発工程完了（顧客検収完了）後に、必要（要請）に応じて、支援契約の為の「新たな見積もり」を実施。（「作業請負」形態とする）
■プロジェクト全般を通して、「第三者検証」を含めた見積もりの徹底
・受託者サイドとして、「第三者検証あり（内部監査）」をベースとした運営方式（体制、コスト）を提案すること。
・顧客サイドに対し、その「必要性理解」に努めること。（プロジェクトマネジメント強靭化）
■「リスク」を想定した見積もりの徹底。
・可能性のあるリスクについて出来るだけ想定し、その対応施策、掛かる想定工数を計上すること。（当然、リスク回避に努めること）
■見積もり検討会の設定と、適時での開催の徹底。
・見積もり審査会 ）の実施。
・必ず「顧客提示、顧客了解前（暗黙の了解などを含め）」での開催を前提とすること。（約束していないこと）
■対外社内標準工数規定（１人月 ）の定義。
・工数を試算する場合の「人月時間数」の設定。
・「社内規定工数」と「顧客提示規定工数」が定義されていること。
・社内規定1人月：会社として規定した、1ヵ月の標準業務時間数。
・顧客提示1人月：顧客に対し提示する、1ヵ月の標準業務時間数。
・「社内規定1人月」＞「顧客提示規定1人月」とすること。
■技術者レベルごとの「標準正価（売価）額」を設定。
・コンサル、ＰＭ、SE、PGなどの技術者レベル（スキル）毎の標準月額を設定すること。（技術者メニュー）
見積もり精度は、「想定リスクの精度」に関わっていると言っても過言ではないかもしれません。対顧客、対社内でのリスクを十分に検証（把握）していること、そのリスクを事前に回避する取り組みを行うことは、プロジェクトの成否に大きく関わるものと言えます。
リスク回避の実現は、プロジェクト収益の向上にも寄与することになるでしょう。
＊４：見積もり審査会
会社としての「案件見積もり承認」会議。会社責任者、案件推進責任者の出席必須。見積もり要件が発生したタイミングでの適時開催。
＊５：１人月
一人の技術者が、一か月で対応できる仕事量のこと。
「社内規定1人月」は、社内業務活動（事務作業、マネジメント活動や教育、自己研鑽時間など）を考慮した時間数であること。
「社内規定1人月」は、「顧客提示1人月」より、最低でも「１割から２割程度」以上、多く設定することが望ましい。
※一例 社内規定1人月：160時間/月 顧客提示1人月：128時間/月
本取り組みは、当然のことながら「相手があること」ですので、双方の理解が重要であることは言うまでもありません。よって商談、開発期間中に限らず、顧客との意思疎通、信頼獲得に十分な時間をとることが肝要です。特に、リーダー（プロジェクト責任者）の「行動様式」が問われることになります。
また、顧客サイドの「予算額」を想定することは重要ですが、それに捉われない対応を「心すること」も必要だと考えます。いずれにせよ、基本的に「一方通行的」な取り組みに陥らないことが、肝要だと思います。
次回は、「５．外注マネジメント原則」と「６．プロジェクト評価原則」「７．プロジェクトチェック原則」の３つの観点から、考察します。
【過去の関連投稿】
第４６回
第４７回
第４８回
第４９回