|
|
|
|
|
|
|
|
|
|
|
商習慣の大幅変更も-「工事進行基準」にゆれるSIer
|
|
|
|
工事進行基準の導入を前に、システムインテグレータ各社は、その準備に向けて余念がない。
工事進行基準とは、2009年4月1日以降開始される事業年度に着手する工事契約から適用するもので、最短となる企業では、あと9カ月後に適用されることになるのだ。
そもそも工事進行基準とはなにか。あらためて、俯瞰(ふかん)してみたい。
■ 企業の経営実態の明確化に効果的な工事進行基準
工事進行基準とは、決算期末に工事進行の程度を見積もり、適正な工事収益率によって、工事収益の一部を当期の損益に計上する基準を指す。
簡単にいえば、システム開発の進ちょく具合にあわせて、売り上げを計上するというものだ。
だが、もともと、日本のシステムインテグレータの多くは、工事完成基準と呼ばれる手法を導入していた。
これは、その言葉の通り、工事が完成し、引き渡しが完了した日に、工事収益を認識し、計上するというものだ。
すでに、数年前から工事進行基準を導入しているベリングポイントのワールドクラス・ファイナンスシニアマネージャーの山田和延氏は、「日本のソフトウェア業界では、収益の計上は、客観性、確実性が高い工事完成基準が用いられてきた経緯がある。これは、売り上げの基本的な考え方である、対価の確実性が確保できた時点で売り上げを計上する実現主義に合致していたからだ。日本の企業が保守的な会計を指向しているという背景も、工事完成基準を導入していた理由のひとつだろう。しかし、工事が長期化、大規模化した場合には、工事(システム開発)が完了するまでの数年間にわたり、売り上げが計上されず、企業活動の実態を表すことが難しいという問題を抱えることになる」と、工事完成基準のメリットとデメリットを指摘する。
つまり、今回の工事進行基準の適用は、工事完成基準では不確かだった、企業の経営実態を掌握するという点を明確化する狙いがあり、とくに大規模システム開発を行うシステムインテグレータにとっては不可欠なものとなっているのだ。
実際、「会計基準上では、工事進行基準を導入することが義務化されてはいない。また、税法上では、1年以上、10億円以上というプロジェクトに関して工事進行基準適用の対象になることが定められているだけ」(山田氏)ということから、一見、中小規模のシステムインテグレータは対象外のように見える。
また、会計基準上では、「工事収益総額」、「工事原価総額」、「工事進ちょく度」を見積もれることが、工事進行基準適用の条件となるため、このいずれかを見積もれないといった場合には、工事進行基準を採用しなくてもいいということになる。
しかし、下請け、孫請け構造が一般化しているソフトウェア業界においては、当然、大手システムインテグレータが工事進行基準を適用すれば、同じプロジェクトに携わっているという立場から、下請け、孫請けのソフト開発会社にも、元請け企業の管理の都合上、同じ基準での管理が求められることになる。
また、「工事収益総額」、「工事原価総額」、「工事進ちょく度」のひとつがで見積もれないという言い訳も、実際には通用しないといえそうだ。
工事収益総額とは、工事契約の対価であり、この金額が決定しており、この工事を完成させる能力があるということを示すもの。工事原価総額とは、工事に必要や原価の見積総額であり、実際の原価と対比することが可能で、適宜に見直しが行われるもの。そして、工事進ちょく度は、工事の進ちょく度合いを指すものであり、多くの場合、原価比例法を採用して算出することが多いという。
つまり、この3つの要件は、システム開発の受発注契約の最低限必要とされる大原則といえるものであり、「これができないというのは、発注元に対して、システム開発における管理能力に問題があるということを、自ら示しているのと同義語」(山田氏)ということになるからだ。
だからこそ、管理進行基準の適用は、実際には、多くのシステムインテグレータが対象となってくるのである。
■ 日本的なあいまいな契約が成立しなくなる
だが、システムインテグレータにとって、課題は山積である。
というのも、これまでの商習慣を大きく見直す必要に迫られるからだ。
例えば、契約形態ひとつとっても、大きな見直しが必要だ。
日本におけるシステム開発は、大規模システム構築であればあるほど、発注元と受注元の親密な関係のもとに推進されるケースが多かった。それがベースにあるため、金額や納期が事後的に確定されることや、正式な契約前に、とにかくプロジェクトをスタートさせるといったことが、頻繁に行われてきた経緯がある。
また、契約形態として、ハード、ソフト、保守などを一式契約とすることで、システム開発への投資費用全体を低く見せるといったことも、日常的に行われてきた。
工事進行基準の適用によって、こうした契約形態は、すべて改善しなくてはならない。日本的なあいまいな契約が成立しなくなるというわけだ。
とくに、一式契約の見直しは、実現主義が前提となるハードウェア、進行基準が基本となるソフトウェア、引き渡し後に発生する保守費用の計上というように、3つが異なる基準のなかで計上されることになる。工事進行基準の適用は、これらを分離して契約内容を提示することが求められるともいえる。
■ 工事進行基準で管理体制が強化される
一方で、プロジェクト管理を適切に行えるのか、という問題もある。
建設業界のように、10階建てビルを建てるというのであれば、最終の成果物の形が理解しやすく、さらに、6階まで完成したら6割の進ちょくということが、外見上からもわかる。だが、ソフト開発では、成果物が最終的にどうなるのか、また進ちょく状況が、目に見える形で推し量りにくいという特徴がある。
そのため、成果物を契約段階で明確化しておくこと、要件定義と開発契約を分離することで、費用と原価の管理を明確にできるようにすることが必要になるという。
「工事進行基準を適用するなかでは、成果物を設計図という形で、明確にしておくことが大前提として求められる。これができないと費用が見積もれない。成果物が不明確であると、想定以上の工数が発生することになり、また、費用範囲が不明確であると、余計な費用が発生する温床になる。結果として、赤字プロジェクトが発生することになる」というわけだ。
加えて、工事進行基準を適用すると、管理体制が自ずと強化されることになる。
例えば、見積もりの要素が強くなることで、これまでのようにプロジェクトマネージャの管理だけでは、不十分と見なされ、上長や品質管理部門の承認など、組織としての対応が求められるようになるからだ。
さらに、人員配置などについても、契約段階前から明確に示すことも必要だろう。そうしなければ、開発工数や期間などが提示できないこともつながるからだ。場合によって、エンジニアの最適配置をシミュレーションするような、人員管理システムなどを稼働させる必要に迫られる可能性もある。
こうした仕組みの変更や管理の強化が、社内体質の改善に向けた流れととらえることができるかどうか、経営側にとってのテーマともいえよう。
振り返れば、工事進行基準の導入は、国際会計基準導入の一環として推進されているもの。工事進行基準以外にも、さまざまな会計基準の変更が求められている。「個々の会計基準の変更としてとらえるのでなく、経営のルールそのものが変化しているという大きな枠組でとらえることが、経営者には求められている」というのが、本質的なとらえ方なのだろう。
■ 先行適用した建設業界との違い
ところで、工事進行基準の選択適用をすでに開始し、2009年4月から原則適用となる建設業界からみると、工事進行基準の導入であたふたするソフトウェア産業は、まさに管理体制の脆弱性を露呈したように映るようだ。
ある建設会社のCIOは、「今回の慌てぶりは、見える化を推進すべきだ、管理体制強化のためのIT導入強化を進めるべきだと、ユーザーに提案しながら、自らの業界でそれができていないことを示すもの。まさに紺屋の白袴」と手厳しい。
とくに、ユーザー企業の立場から、「要件定義を行うことができないシステムインテグレータのエンジニアが多すぎる。これでは、工事進行基準に最低限必要とされる成果物の明確化、費用、納期などの提示ができないのと同じ」だと続ける。
システム開発では、開発途中に要件定義が変更することがある。それに対して、建設業界では、そうしたことが少ないため、同じ工事進行基準でも、ソフト業界の手法に当てはまらないとの指摘もある。
だが、それに対しても、「建設業界においても、要件が変わることはある。細かいことをいえば、壁の色や、使っている材料を変えたいなどという要求変更は日常茶飯事。それで費用や納期が変化するケースは数多い。こうした変化にも、柔軟に対応する仕組みを、管理部門を交えた体制で構築しておくべき」とする。
一方で、建設業界の多階層型下請け構造は、ソフトウェア業界の構造とも似ているが、そこにも大きな違いがある。
それは、建設業界においては、建築手法がしっかりと確立されていること、そして、資格制度によって、高いスキルを持った人が一定以上の品質で構築する環境ができていること、加えて、法制度によって、それが厳しく規制され、その結果として品質が保証されている点にある。これを破れば、法的に罰せられるのは、耐震強度偽装事件を見ても明らかである。
ところが、ソフトウェア業界では、国が認定する資格制度がなく、誰もが、システム開発に取り組むことができる。つまり、品質に対する姿勢に自ずと大きな差があるのだ。
こうした管理体制の違いが、工事進行基準の適用に対して、ソフトウェア業界が大慌てしている理由のひとつでもある。
ソフトウェア業界では、要件定義や仕様確定への厳密性、プロジェクト管理に求められる高い品質、そして柔軟で強固な管理体制を、法的拘束がないままで取り組んでいく必要がある。
ソフトウェア業界は、自主的な取り組みが求められる分、志を高く持って、これに取り組んでいく必要があるといえよう。
( 大河原 克行 )
2008/07/11 00:01
|
|
|
|
|