CIOパートナーズ株式会社
         … 当社は、お客様の業務を分析する為のスポット・サービス【シンプルコンサルティング】でお客様のイノベーションを支えています。


サイト内検索

TOP 会社案内 Simple Consulting
セミナー・研修 コラム・レポート テンプレート 採用・パートナー

トップページコラム・レポート > 経営者が疑問に思うシステム構築リスクと対処法 ~コスト編~

関連サービスのご案内
RFP作成・提案評価サービス
業務フロー分析サービス


関連レポート・セミナー資料
◇ 【セミナー】
  業務改革・コスト構造改革セミナー
【レポート】業務改革の進め方

CIOパートナーズ株式会社

〒550-0014
大阪市西区北堀江 1-19-8 四ツ橋KMビル 7F

TEL 06-6599-8661
FAX 06-6599-8666

info@cio-partners.co.jp

自社のITに自信が持てない経営者必見!
経営者が疑問に思うシステム構築リスクと対処法
                           ~コスト編~

・掲載日:2016.5.11
・筆者 :吉田 明弘(CIOパートナーズ株式会社 代表取締役)【自己紹介



はじめに

ITに精通し、自社のITに自信を持てている企業経営者は、ほんの一握りに過ぎません。
殆どの経営者は、IT業界特有のコトバの意味すら解らず、多くの疑問を抱えたまま、大きな費用負担が必要な意思決定を迫られています。

本レポートは、こうした企業経営者向けにまとめています。私たちが日頃のコンサルティングで接する多くの企業経営者の皆様が疑問に感じているシステム構築リスクとその対処法をQ&A方式でまとめて解説したものです。

Q1 そもそも、どうやってシステム開発の見積り金額を算出しているのか?

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

多くのシステム開発案件の見積りでは先ず、プロジェクト(以下、PJ)体制(作業チームの分担と主要メンバーの陣容)を決める事からはじめます。具体的には、開発対象となる業務の範囲や開発すべき機能数、開発期間をもとに、PJにアサインできそうなコア・メンバー(チーム・リーダー格など)の目星を付け、どの程度のチームに分けて開発を進め、各チームに何人くらいが必要で、どこまで外注に依存するのか…を順に検討します。

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

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

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

ここで注意が必要な点として、業界慣習として殆どのベンダーは、外注コストにもマージンを乗せる点があります。例え、孫請け・ひ孫請けまで至る場合でも、間に入った各社でマージンを乗せます。結果、度重なるマージン上乗せで見積り金額が膨れ上がるだけでなく、品質管理リスクの増大等も招きます。(だから、PJマネジャーは、余計にバッファー(=予備費)を確保したがります。)

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

話を本論に戻すと、見積り金額は、こうしてPJ体制の骨格が固まった後は、粛々と算定します。想定されるアサイン人数をもとに、労務費を概算ではじき、外注費や管理費を加算して総原価を積算し、マージンを上乗せして算定します。つまり、システム開発の見積り金額は、機能数ありきで算出しているのではなく、コア・メンバーのアサインとPJ体制ありき(つまり、人ありき)の工数をベースに算出している…これが実態です。

Q2 ビックリする程の高額見積り!でも価格交渉の成果があがらない。何故なの?

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

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

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

Q3 再構築する際も、いままでと同じベンダーに発注した方が良い?

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

その上で、同じベンダーに継続発注する時には、注意点があります。
それは「ベンダーが同じでも、担当SEが同じ保証はない!」という点です。

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

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

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

Q4 システムを再構築する際の投資は本当に回収できる?

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

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

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

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

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

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

Q5 そもそも納期は守れるのか?また、遅延はユーザー企業側だけの責任?

最近、はじめの提案時に短い開発期間で見積り価格を抑えて提案を行い、予定通りに本番稼働できなかった時点になって「ユーザー企業側の責任」を主張し、SEを確保しておく為といって多額の追加費用を請求する事例が散見されます。しかも、こういった事例は我が国を代表する様な大手ベンダーであっても生じています。
(実際、こうした事態が更にこじれて、訴訟にまで至る案件は大手ベンダーも抱えています。)

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

1.ユーザーの要求通りに作ってさえいれば良い…というベンダー側の割り切った姿勢
  … ベンダーは昔の様に問題が解決する迄、汗をかいて付き合ってくれる…というのは今や幻想です。
    最近は、ベンダー社内でもPJの採算を徹底して管理している為、昔の様な融通は利きません。
    しかも、「ユーザーテストはユーザー側の仕事(=ウチは関係ない)」と、高を括っているPMや
    SEが非常に多いです。

2.あまい設計・要件整理
  … 自分達の社内ルールに則ってきちんと設計書を作っていない(作れない)SEがあまりに多い。
    酷いPJでは、画面と帳票の設計、テーブル設計だけで終わらせてしまう事例もあります。
    この背景には、一時期、多くのベンダーがパッケージばかりに傾注し、一から開発できるSEが
    極端に減ってしまった業界の構造があります。

3.ベンダーにPJ管理を丸投げのユーザー
  … 上記1と2が前提にあり、更に本稼働の延期が避けられなくなった時点で、ベンダーからユーザー企業
    の瑕疵を主張します。この際、ユーザー企業が抗弁できず、ベンダーの要求を受け容れるしか選択肢
    がなくなっている事例が少なくありません。

ユーザー企業は、こうした事象を放置せず、しっかり手当しておく事が、納期遅延リスク、遅延コスト負担リスクを抑える上で欠かせません。その為には、以下の3つの対策が有効です。

1.ユーザーテストなど、(取りあえず)作った後のベンダーの役割を最初から明確にして合意形成する。
2.設計や要件整理で作成する成果物の一覧を発注前に確認して合意形成する。
3.PMOを設け、提案内容とのギャップを継続的に管理する。

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



本レポートをお読み頂き有難うございます。今後は、スケジュール編、品質編、契約編などを順次、リリース予定です。
また、皆様からのご意見、ご質問などをお待ちしています。(メールでお願いします。)
(宛先)info@cio-partners.co.jp

Links

会社案内と当社設立の想い
支援テーマと実績
コンサルタントの紹介

リレーションシップ
資料請求
個別相談会のお申込み

セミナー案内
キャリア採用とパートナー募集

コラム・レポート掲載
業務改革プロジェクト実践研修

コンサル標準テンプレート
ニュース一覧

お問い合わせ
プライバシーポリシー

 

copyright©2016 CIO-Partners Co.,Ltd all rights reserved.