経営者が疑問に思うシステム構築リスクと対処法

殆どの企業経営者が誤解していますが…
多くの場合、システム開発の見積り金額は、開発すべき機能数（例えば、画面や帳票の種類など）を基準に算出している訳ではありません。
工数（投入すべきマンパワー量）が見積り金額の算出の出発点で、機能数は工数を出す為の基礎情報の１つにすぎません。

多くのシステム開発案件の見積りでは先ず、プロジェクト（以下、ＰＪ）体制（作業チームの分担と主要メンバーの陣容）を決める事からはじめます。

具体的には、開発対象となる業務の範囲や開発すべき機能数、開発期間をもとに、ＰＪにアサインできそうなコア・メンバー（チーム・リーダー格など）の目星を付け、
どの程度のチームに分けて開発を進め、各チームに何人くらいが必要で、どこまで外注に依存するのか…を順に検討します。

この際、見積り金額は、スケジュールや開発する機能数の他に「コア・メンバーの力量」や「どこまで外注に依存するのか」に大きく左右されます。

特に、コア・メンバーの力量に関しては、どのベンダーでも、候補となる優秀なエンジニアは、常にフル稼働の状態です。
彼らのアサインには、社内調整が欠かせません。

しかも、社内調整は開発案件の規模や収益性に加えて、ベンダー内における今回の開発案件の重要性などの政治的ファクターが大きく影響します。
つまり、優秀なコア・メンバーをアサインするには、見積りを担当する営業担当者やＰＪマネージャーにとって大きな労力が必要です。
それでも、運よく優秀なコア・メンバーや頼りになるプロパー社員を適正にアサインできたＰＪは、外注に丸投げせずに済みます。

しかし、優秀なコア・メンバーがアサイン出来ない場合、一人ひとりに任せる仕事の範囲を小さくして、それぞれに担当を付けざるを得ません。
すると、ＰＪ全体で必要な人数が膨らみ、結果的に外注に大きく依存する状況が生じます。
場合によっては、外注が孫請け・ひ孫請けまで至るケースもあります。

ここで注意が必要な点として、業界慣習として殆どのベンダーは、外注コストにもマージンを乗せる点があります。
例え、孫請け・ひ孫請けまで至る場合でも、間に入った各社でマージンを乗せます。

結果、度重なるマージン上乗せで見積り金額が膨れ上がるだけでなく、品質管理リスクの増大等も招きます。
（だから、ＰＪマネジャーは、余計にバッファー（＝予備費）を確保したがります。）

ただ、ＰＪマネージャーは、分かっていても外注に大きく依存するしかない…そんなＰＪが少なくありません。

話を本論に戻すと、見積り金額は、こうしてＰＪ体制の骨格が固まった後は、粛々と算定します。
想定されるアサイン人数をもとに、労務費を概算ではじき、外注費や管理費を加算して総原価を積算し、マージンを上乗せして算定します。

つまり、システム開発の見積り金額は、機能数ありきで算出しているのではなく、コア・メンバーのアサインとＰＪ体制ありき（つまり、人ありき）の工数をベースに算出している…これが実態です。

Q1でも触れましたが、見積り金額の趨勢は、ＰＪ体制の骨格が固まった時点で決しています。

「蓋を開けてみたら、ビックリする程の高額見積りだったので、慌てて値引き交渉をした」といった話をよく聞きますが、
ＰＪ体制が固まってしまった後では、ベンダー側も調整の余地は限られています。

従って、どうしても、見積り金額のギャップが埋まらないのであれば、時間はかかりますが、
一旦白紙に戻して、ベンダーにもＰＪ体制を一から再検討してもらう…といった選択肢も視野に入れるべきです。

再構築する際に、同じベンダーに継続発注する一番の理由は「当社の業務を理解してくれているから」です。

これは、特殊な慣行などが多く残る業務のシステムを再構築する時ほど重要になってきます。
こうした業務は特に「相手のある契約処理や販売管理などの営業管理業務」や、「社内で改善が繰り返されてきた生産管理・原価管理業務」などで多く見受けられます。
その上で、同じベンダーに継続発注する時には、注意点があります。

それは「ベンダーが同じでも、担当SEが同じ保証はない！」という点です。

最近は、人材の出入りが激しいベンダーが少なくありません。
また、Ｑ１でも触れた通り、外注先のＳＥが実際のプロジェクトのコアメンバーになっている事例も多々あります。
こうしたベンダーの状況を顧みず、いままでのベンダーに安易に継続発注していまい
「やってきたメンバーには当社の業務をまた、一から説明しなければならなかった…」という状況に陥ってしまっては、同じベンダーに発注する意味などありません。

こうした質問を投げかけると「社内で引き継いでいるから大丈夫です」と説明するベンダーの営業担当者が殆どですが、
そもそも、引き継ぎ（≒現行システムの設計資料などを読み込んでおさらいする程度）を伴うのであれば、新しいベンダーに発注しても同じ事です。
（しかも、新しいベンダーを加えた公平な競争環境の下で最も有利な提案をチョイスできる様になります。）

従って、いままでと同じベンダーに発注する際は「ベンダーのコアメンバー」を確認してからにする事、
そうした確認ができずに中途半端に継続発注する位なら、ベンダーに拘らず、オープンな競争環境にして最も有利な提案をチョイスする事、が肝要といえます。

近年は、ベンダーの提案内容の通りに合理化効果が表れて、目論み通りに投資が回収できる様なハッピーエンドはまず、ありません。

１９８０～９０年代は、ベンダーの提案内容の通りに合理化効果が表れて、何億円もする投資を回収する事が可能でした。
これは主に手作業で処理していた業務を自動化した為です。
経営者は、自動化によって余ったマンパワーを営業などの直接業務に振り向け、市場の成長を取り込み、事業の拡大につなげる事ができました。

しかし、最近では既に多くの業務がシステム化され、更なる自動化によって合理化の効果を上げる余地は、投資額に比べてあまりに僅少です。
昔と同じロジック（論法）は通用しません。

では、どうすれば何億円もする投資を回収する効果をあげる事ができるのか…
その答えは『業務の割り切り』（シンプル化）にあります。

多くの企業では、部署毎に何度も繰り返すチェック、100円でも100万円でも同じ様に処理を求める紋切り型の社内ルール、
よく似ているのに用途毎に別々に作成された管理レポートなど、まだ多くの無駄を抱えています。
つまり、業務を割り切る余地は大いに残っています。

従って、システムを再構築する際の投資を上回るリターンを得るには、
システム再構築をきっかけにして、業務の割り切り（シンプル化）を進める事こそが肝要です。
その為には勿論、目的（＝業務のシンプル化）と手段（＝システム再構築ほか）を混同しない事、目的に沿った取組み計画や社内体制を整える事も不可欠です。

最近、はじめの提案時に短い開発期間で見積り価格を抑えて提案を行い、予定通りに本番稼働できなかった時点になって「ユーザー企業側の責任」を主張し、ＳＥを確保しておく為といって多額の追加費用を請求する事例が散見されます。

しかも、こういった事例は我が国を代表する様な大手ベンダーであっても生じています。
（実際、こうした事態が更にこじれて、訴訟にまで至る案件は大手ベンダーも抱えています。）

なぜ、こうした状況に陥るのでしょうか？
その原因として主に以下に３点が挙げられます。

ユーザー企業は、こうした事象を放置せず、しっかり手当しておく事が、納期遅延リスク、遅延コスト負担リスクを抑える上で欠かせません。

その為には、以下の３つの対策が有効です。

最後に、これらの対策を講じても、納期遅延リスクや遅延コスト負担リスクは残ります。
それでも、より確実にシステム再構築を進める為には、これらの対策は欠かせない、といえます。