このエントリーをはてなブックマークに追加LINEで送る

3.2. 発注側

ハッピィ・エンジニアリング表紙

 情報システム開発をめぐって、ユーザ企業が抱えている問題のほとんどは、丸投げを原因とするITガバナンスの崩壊を原因としている。ユーザ企業のシステム部門は、企業の方針としてシステム開発の外注化を選択した時点から、経営戦略と密接に関連したシステムの企画部門という位置づけになっているはずだが、現状では、発注と運用管理部門のみを受け持つだけの部門になり下がっている。

 

 実際の開発に参画しないため、ノウハウが失われていく。それに従いSIベンダへの依存度が高まり、「自社のシステムがSIベンダに支配されている」という状況に至っている。

 

 一方で、特に日本の場合、大手SIベンダも、自身ではせいぜい基本設計までしか行わず、下流工程を下請けに丸投げしている。ユーザ企業のシステム部門が開発に参画しないことと同様の理由で「SIベンダの空洞化」が発生している。下請けも階層構造をなしており、中間段階で数次にわたり「管理コスト」を引かれるため、末端では非常に安い人月単価で実際の開発にあたっており、教育に費やすコストなどかける余裕もない。したがって、現場のスキルは著しく低下しているのが実情である。ところが、失敗したプロジェクトに人員追加を続々と行うため、表面的には「システム技術者の不足」という現象を引き起こしており、一見景気がよいように見えるから皮肉な話である。

 

 従来ならば、ROIの低さに目をつぶれば、SIベンダに丸投げでも「なんとかしてくれた」状況があった。しかし、現在のように「次々にプロジェクトが破たんしている状況」のもとでは、今までの流れに逆行し、より下流に至るまで情報システム部門が関与する必要性が増大している。

 

 ユーザ企業は今後、どのように軌道修正していかなければならないのだろうか? システム化に関しては、企画部門・ユーザ部門・システム部門の3部門が連携してシステム化を行う。それぞれの部門が何をどのように行わなければならないのかを、以下に整理する。

 

戦略部門

● 経営層

 

 現在では、専業のCIOは企業にとって必要不可欠であると言われている。CIOは次期社長候補者が就任するものとも言われているほど、その重要性と期待は大きいものの、社団法人日本情報システム・ユーザー協会(JUAS)が2005年に行ったユーザ企業IT動向調査(*1)によれば、役職として定義されたCIOは968企業中わずか6.5%にとどまっている。

 

 企業規模が大きくなるに従いCIOとしての役割を持つ役員がいる企業の割合は増加する傾向にあり、IT部門・業務を担当する役員がCIOとしての役割を持っている企業は43.9%だが、専任のCIOを含め、CIOとしての役割を持つ役員がシステム関連の業務に利用する時間は25%以下という低い数字である。

 

 経営者向けのシステム専門誌では時折、システム部門出身のCIOが少ないことを問題視するような記事が見受けられる。しかし、CIOに求められているのは、技術的な知識や能力ではない。自社の経営戦略を打ち出すこと、ビジネス部門とシステム部門の意思の疎通を図ること、経営戦略を企画部門とシステム部門に徹底することなどである。

 

 システムは経営の最重要ツールであり、経営に必要不可欠な仕組みにすることが求められているはずだが、それを各企業が現実の姿にするまでには、まだまだ意識改革が必要と言えよう。

 

 CIOの役割は、経営者の一人としての側面と、システム部門のリーダとしての側面がある。経営者としては、ほかの経営陣に対して、

 

  • システム投資費用の適正化
  • システム化によるROIの妥当性の評価
  • 経営的観点からのシステム投資の優先順位付け
  • システム調達戦略および調達方針の策定

 

などを行う必要がある。

 

 また、システム部門のリーダとしては、

 

  • システム調達方針の徹底
  • システム部門に対する動機づけ

 

などが役割として期待されている。

 

 システム部門以外、特に経営層には、自社のシステム予算は常にSIベンダに食いものにされているのではないかという疑念が働いている。実際問題として、ITガバナンスを失っているシステム部門にとっては、自らのミッション(実は勝手に自己規定しているだけで、本来はシステム戦略の立案などの、もっと高い次元の戦略性が要求されていることが多々ある)である「システムの納期通りのカットオーバ」を保証(?)してくれるSIベンダは「ありがたい存在」である。経営層は、こうした一種のなれ合いに近い雰囲気を感じ取り、システム部門とSIベンダの間に甘えと癒着の構造を見いだし、その結果として、必要以上の経費を要しながら同業他社より水準の低いシステムしか稼働していないのではないか、という思いにかられるわけである。

 

 システム部門がSIベンダから自社のシステムの主導権を取り戻すには、まだまだ多くの課題が残されているままであるが、ごく一部では開発プロジェクトをコントロールするための取り組みが行われている。

 

 具体的には、プロジェクトマネジメントの部分のみを独立した専門家に別契約で依頼するようなケースである。しかし、この方法を実現するのはなかなか難しい。プロジェクトマネジメントの専門家が少なく、このような業務委託を受けるにはかなりのスキルを必要とする。その半面、実際のモノ作りをしないプロジェクトマネージャに通常のSE単価以上の金額を支払うのは難しい。また、投入人員も実質的には数名程度であろう。

 

 ユーザ企業側の貧弱なプロジェクト体制を考えればわかるように、ひとつのプロジェクトに多数の人数を貼りつけるという発想は浮かぶことがない。仮に1億円程度の発注金額のプロジェクトとして、管理支援に2,000万円使うのは現実的ではないと判断するのが普通であろう。そうなると、SIベンダは結局、難しく受注規模の小さい管理支援よりも、単純で規模の大きい開発を行う道を選択するだろう。

 

企画部門

 企画部門は、経営戦略に基づき、業務プロセスの再構築、システム化の優先順位づけ、ROI指標の作成などを行う。ここから個別のプロジェクトが発生する。

 

個別プロジェクトの決定後に行うこととしては、ユーザ部門からの機能要件の取りまとめ、業務フローの精査、機能要件と業務フローのマッピング、各部門調整などがある。開発するシステムの利害関係者を適切に抽出し、各部門から参加させることが重要なポイントである。社内の利害関係者の取りまとめがプロジェクトの結果に大きく影響を与える。

 

 しかし、現実はこのようなあるべき姿と大きくかけ離れていると言わざるを得ない。前述の「ユーザ企業IT動向調査2005」では、ユーザ企業がシステムベンダに対する不満の第1位として「企画提案力不足」を挙げており、ほかの不満要因よりはるかに高い件数となっている。

 

 本来、ユーザ企業側が主導で行うべきシステムの企画提案を、システムベンダに依存している姿が浮き彫りとなっているのである。日本では、人材の流動性が低いため、システム業界のみならずひとつの業界に10年や20年いることは珍しくない。経験を積んでいるはずの企画部門やシステム部門の担当者が、コンピュータの知識不足を言い訳にして、システム開発しか経験しておらずろくな業務知識を持ち合わせていないSIベンダの提案に期待するというのは非常におかしな姿であると言わざるを得ない。

 

 企画部門には、個別の開発プロジェクトでは、役割のひとつとして要求仕様について調整することが求められている。エンドユーザ部門では、システムの機能がもたらす価値を金額として換算できず、仕様追加の是非を語ることが不可能である。そのために、いたずらに仕様の膨張を招きがちである。また部門間の意識の違いにより方向性の違いが表面化することもある。そうした中で、部門ごとの「個別最適化」を超えた、全社としての「全体最適化」を実現するための意思決定が企画部門には求められているわけである。

 

 開発機能が大幅に追加された場合、元請けとなるSIベンダは当然追加費用を要求してくるため、コストが増える。発注側としては、ギリギリのところまでは優先順位づけをして対応することになるだろう。

 

 ユーザ企業の中には追加の費用を出し渋る企業もある。結果的にSIベンダ側が泣く泣く追加機能分をただ働きさせられることもある。しかし、SIベンダも慈善事業を行っているわけではない。そのような場合には、バージョンアップや二次開発以降で巧みに回収されたり、それ以降の新規プロジェクトの見積もりで機能追加分を上乗せして提案してきたりする。発注側から見れば、一時的には出費を抑えたように思えるケースでも最終的には帳尻を合わされていることは少なくない。

 

 さて、費用の面から要求のすべてを開発することが不可能な場合がある。また、ユーザ部門は要求した機能がすべて実装されていないということで、作られたシステムに対しての不満を持つことになる。

 

 ROIの側面から、あるいは経営戦略の観点から見た機能追加の精査や優先順位づけを行い、適切に判断を下すのは企画部門の役割である。

 

現業部門

●ユーザ部門

 

 ユーザ部門の重要な役割は、企画部門による事業戦略や業務プロセスの再構築要求を受けてシステム化の業務要件を提示することである。

 

 今のシステム開発のスコープは、経営戦略を具現化し、業界内での競争優位を確立することが中心であるため、元の経営戦略がいいかげんであればあるほど、具現化において混乱をもたらす。例えば、経営戦略が単に「売り上げ向上」というものであったならば、業務要件提示以前の問題となってしまう。売り上げを向上させるために、企業としてどのような戦略をもって臨むかが示されない限り、単なる掛け声あるいは一方的にノルマを課す行為にすぎない。

 

 システム化の業務要件をまとめるにあたって、まずは、そのシステム化の目的は何か、現業にどのような影響を与えるのかを分析することから始めなければならない。

 

 業務要件の提示は、システム開発が成功するか、失敗に終わるかの最初の分かれ目である。ユーザ部門は自身の業務の詳細から全体を組み立てていくが、システムとして考えた場合、全体の正確性・一貫性・継続性の確保という観点を考慮したものでなければならない。業務がシステムに優先することは自明であるが、だからといってシステム化に回収できないほどの多大なコストがかかるようなことは避けなければならない。

 

 企業価値を高める迅速なシステム化を実現するうえで求められていることは、この業務の詳細から考えるユーザ部門と、システム全体から考えるシステム屋とのギャップを埋めるための方法論の確立である。

 

● システム部門

 ユーザ企業のシステム部門は、自社のビジネスとシステムを融合する戦略性を持った専門家集団としてCIOを補佐する立場に立つべきである。しかし、実際にはシステム開発の発注・開発管理・運用が主要な業務になってしまっている。現在のようにビジネスの変化が激しく、数年先すら読めない状況下では、システム部門に対する戦略性への要求は高まっているといえる。

 

 オープンシステム全盛の現在は、製品の組み合わせによる開発スピードが向上した半面、そのデメリットも生まれている。

 

  • 自由に製品を組み合わせることが可能なため、システムごとにさまざまな製品・バージョンが混在する
  • 製品数に比例して保守コストが増大する
  • 多くの製品に対する専門的なノウハウが必要となり、構築・運用・保守の局面でツールベンダのサポートを必要とする
  • 開発が速い半面、システムごとに作り込んでしまうことによりデータの分散やシステム連携が複雑となる

 

 この状況をふまえ、自社の経営戦略とシステムの技術動向を把握したうえで、自社のシステムに対する要求に迅速に対応可能なシステムインフラの整備が求められている。

 

 システム部門には、発注者としての側面、個別プロジェクトへの要件の取りまとめの側面、個別プロジェクトのマネジメントの側面がある。

 

 発注者としては、予算化と見積もりの責任がある。システム化は巨額の投資となるうえに、そのシステムにトラブルが発生した場合には、ときとして社会的問題に発展する可能性があり、その責任は非常に重い。また、RFP(Request for Proposal:提案依頼書)作成、社内の調達方針に従った調達と検収の責任がある。

 

 要件の取りまとめの側面には、システムの機能のみならず、運用要件や非機能要件も重要である。運用をアウトソーシングしている場合には、アウトソーシング先より運用要件を取りまとめて開発側に提示する必要がある。

 

 プロジェクトマネジメントとしては、開発側に対しての支援業務が重要な役割のひとつである。特にテスト時に必要となるのが本番データをマスク処理してテストデータとして流用したり、マスタとなるデータを提供したりするような業務である。こうした作業は地味な仕事ではあるが、プロジェクトを推進するうえで進捗に大きく影響するので、事前に計画を立てて進めるようにしたい。

 

 

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

3.2. 発注側 ハッピィ・エンジニアリング関連ページ

3.1. 利害の対立
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
3.3. 開発側
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング