プロジェクト作成請負案件を円滑に受託、推進するために（１）～ トラブル発生要因 ① ～

これまで、システム構築、システム支援に関わるテーマで、４５回に渡り、ＩＴ部門の役割変革からそこに関わる人材の在り方まで、受託後のアフター作業関連を中心に、多面的に考察を行ってきました。
今回は、全ての始まりである「商談受託」という側面から考察したいと思います。トラブルの発生の「芽」は、商談受託時点から始まっているといっても過言ではないからです。
本稿では、「顧客（エンドユーザ）直受託の場合」や「大手ベンダーからの２次請負受託」といった両面を意識しつつ、受託を専業とする「中小のソフトハウス系 ＊１」で起こりそうな事象を軸に考察します。

一般的に、作成請負（SI） ＊２プロジェクトにおける統制の在り方、やり方については、既に各種の手法、技法が規定されており、基本的な取り組み方、仕組みについては確立しています。にもかかわらず、未だに根絶できないトラブルの要因がどこにあるのか、「商談段階」に起点を置いて考察したいと思います。

まずは、「トラブル発生要因」ということから始めたいと思います。第１回の本稿では、「顧客との交渉面」と、「社内マネジメント面」の２つの観点から考察していきたいと思います。

＊１：中小のソフトハウス想定
150～160名規模で、自社の組織的マネジメント体系が確立されていなくても運営できてきた規模の企業を想定。「個々人の力量」を軸にした運営。

＊２：作成請負（SI：System Integration）
システム構築（作成）を「一括」で受託する契約。作成責任は、受託側にある。契約方式には、この他に「作業請負契約」「派遣契約」形態がある。
・「作業請負」は、一般的に「SES契約」とも呼び、システム構築における「支援作業」を行う契約。作成責任は、発注側にある。ただ、作成責任は負わないが、支援要員のマネジメント責務は受託側にある。
・「派遣契約」は、全ての責任が発注側に生じる契約。（派遣要員のマネジメントも発注側にある）

１．顧客との交渉面（含む大手ベンダー）

トラブル発生に纏わる一番の問題は、商談時などに顧客から提示される要件に対し、顧客との条件闘争を「端から諦めてしまっている」ということではないかと、考えています。そこには、「仕方ない論」ということが蔓延していないでしょうか。特に、付き合いが長いお客様や大手ベンダーなどからのオファーなどに起こりがちだと考えており、そうした点を中心に、考察します。

■「仕方ない論」には、「お互い様」という意識が働いてしまう傾向。
・「顧客も、困った時には便宜を図ってくれることもある」という思い。
これは「我々は問題を起こさないように動くぞ」という意識・考え方を捨ててしまい、相手に対する「甘え」に頼っているとも言えます。（何かあっても分かってくれる、助けてくれるに違いない。過去にそうしてくれた、という経験則）

■相手に「忖度」して「（言っても）どうせダメだろう」という意識が常態化している傾向。
・顧客、依頼ベンダーにおいて、特に、先方の「気質、思い」を知っていると思い込んでいるような場合、暗に「自粛」してしまう傾向になること。

■受託すること、受託できる事を優先してしまいがちな、商談推進（提案内容、見積もり）意識に陥ってしまう傾向。
・自社の要求事項（担当体制（担当の技術力）、対応事項等々）を通そうとするより、顧客から「そう見られている（知られている）から仕方がない」ということを、少しも変えようとしない意識。
・少しでも変革しようとする取り組みを、回避してしまう体質（意識）になってしまっていること。（適正な収益確保より、赤字でなければ良い発想）

■要員計画において、「組織的な対応」の考え方が出来ない傾向。　
・個々人の力量に依存し、組織的にフォローする仕組み、どう使って行くか（顧客に新人だからと思わせない取り組みなど）が考えられていないこと。
・見積もりにおいて、安くしても「新人を当てるから仕方ない」論の意識が定着してしまっていること。（OJTで育成したい思惑）
・ビジネス遂行において、「新人だから」「未経験者だから」は、通用しないという考え方が出来ていないこと。（安くすれば良いという発想）

■顧客との関係性において、「担当者の経験則」に捉われてしまう傾向。
・契約が、「個人」としてではなく、背景としての「所属企業」に任せてくれていると考えられないこと。
・「能動的な行動」を回避する傾向になりがちで、そこから抜け出そうとしないこと。（「言ってくれたことはやる」といった受け身行動）
・自分ではなく、相手が変わってくれることを期待する「他力本願型」に陥ってしまっているということ。（楽したい思想）

これらの傾向は、担当者に「交渉する」という癖が付いていないということに尽きると思います。これは「能動的」に動くことに慣れておらず、社内においても、体系的な教育がされていないことにもあると考えられます。

２．マネジメント面

マネジメント面において、プロジェクトリーダーのマネジメント意識に加え、会社、組織的マネジメントに対し、しかるべき対応、運営、フォローがなされていないのではないかと言うことについて、考察します。

■「追求しない」「追及できない」マネジメント方式になっている傾向。（「自覚を促すだけ」の運営。「言うが、フォローまではしない」体質）
・社内商談検討会、見積もり審査会、ＰＡ会 ＊３などの社内マネジメント会議においても、その場で提起されたこと（問題としたこと）に関して、会議後フォローがされていないのではないか。（やるハズ、やっているハズという考え方で、その場限りになっている）
・マネジメント会議で使う資料において、内容が不十分であっても、厳しく追及しない、やり直しを促さず、許容し（会議を進め）てしまう運営になっていないか。
・時間制約（提案期日など）を優先せざるを得ないタイミングでの開催を、許容する社内マネジメント体制になっていないか。（差し戻し発想が弱く、しない体質）

＊３：ＰＡ会（PA：Project Assurance）
システム開発、プロジェクトの品質を担保するための「評価会議」のこと。

■プロジェクト運営の品質、安心、安全より、コスト抑え（提案総額抑え）中心になってしまう傾向。
・必要な体制（第三者チェックなど）であっても、顧客を説得しない・できないと思い込む体質になっていないか。（面倒ごとからの回避意識）
・顧客が「認めてくれないから入れられない」ということを、暗に容認してしまう社内マネジメントになっていないか。

■「やらせる」という意味を、理解していないリーダー資質傾向。
・「他人に作業を委ねること＝任せた（一任）」といった認識が強く、自らチェックすることを怠る傾向になっていないか。（出来るハズ、やってくれるハズと思うことで、自分自身を楽にしたいマネジメント方式）

■マネジメント要員が、マネジメントを十分に出来ない程の作業を持ってしまう体制作りにしてしまう傾向。
・自身が入らないと、受け入れてもらえないという思い込みがないか。
・自身を入れることで、全体工数を削減しようとしていないか。

■フィードバックすることの「必要性」認識が弱い傾向。（無い）
・報告は求めるが、その内容について「都度吟味する」癖が付いておらず、受け取るだけになっていないか。
・受託している内容（範囲）について、メンバー全員にレクチャーし、理解させることに時間を割いているか。
・メンバーに、包括的に考えさせるクセをつけさせていない。分担した内容（作業）だけの理解に留めるマネジメントになっていないか。

つまり、「自立できている人達だけ」で運営している「体制」、「マネジメント」であるかのような認識（マネジメント不要論）で推進し、さらに、「自分の範囲しか考えない、考えなくて良い」的な人材、運営マネジメントになっていないか、改めて、再検証してみることが重要であると考えます。

次回（４７回）は、「３．スケジュール面」、「４．プロジェクトチェック・リスク面」という２つの観点から考察したいと思います。