『地域政策研究』（高崎経済大学地域政策学会）
IT 産業の分業体制の類型化
第 12 巻 第１号 2009 年７月

185 頁〜 194 頁＜研究ノート＞

IT 産業の分業体制の類型化
藤

本

理

弘

Patternizing of subcontract structure of IT industry

Masahiro FUJIMOTO

キーワード： 地域情報化政策 IT 産業 下請け構造 分業体制 開発工程 地域間分業 ソフトウェア開発

Ⅰ．はじめに数々の地域情報化政策が行われた結果、IT 産業の地方展開が進んでいる。こうした政策の多くは、重要な目的の一つとして、IT を活用した地域振興を掲げている。しかし、大都市圏と地方の情報
格差はむしろ拡大しているといわれている。こうした状況への対策として、近年では「地理的デジ
タル・デバイドの解消」を目指した地域情報化政策が図られてきている 1)。
地域の情報化を担うはずの IT 産業の地方展開が進んでいるにもかかわらず、大都市圏と地方の情報格差がむしろ拡大するのはなぜだろうか。IT を利用している現場にヒアリングすると、IT 利用の企画立案については、東京など大都市の IT 企業に依存する割合が高いという声が聞かれる。
一方、地方の IT 産業関係者からは、地方の IT 企業は他地域（特に首都圏）からの下請け作業に追われることが多く、8 〜 9 割をそういった開発案件の受注に頼っているのではないかという声も聞かれる。統計数字でみると、2006 年のソフトウェア産業の売上高のうち、「下請け」に位置付けられている「同業者向け売上高」は全国で約 18.2%、地方部（東京・神奈川・大阪を除いた地域）
でも約 24.4% に過ぎず 2)、意識と統計値との間に大きな乖離がみられる。
なぜこのような意識の乖離が発生するのか。また、なぜ地方に数多くの IT 産業が立地しているにもかかわらず、IT 利用の企画立案が大都市の IT 企業に依存することになるのか。その一因を明らかにするために、下請け構造を中心とした IT 産業の分業体制の仕組みを類型化し、この問題の抜本的な対策を検討するための視点を提示するのが本研究の目的である。
なお、本稿では基本的にソフトウェア産業を対象に分析を行うが、他の IT 産業についても同様の問題をはらんでいると考えられる。
− 185 −

藤

本

理

弘

Ⅱ．従来の認識
ソフトウェア産業の地域間分業（すなわち下請け）という観点における過去の研究事例は少ない
が、代表的なものとしては今野浩一郎・佐藤博樹〔1990〕がある。
この研究では、情報サービス産業が東京に集中する傾向が、1980 年前後を境に事業所数、従業員数、売上高のいずれを見ても緩和されてきており、特にソフトウェア業では顕著であるとしている。この原因として、(1) 首都圏の大手コンピュータメーカーやソフトウェア会社が、人材を求めて地方にソフトウェア生産工場として子会社を設立する動きが活発化したこと、(2) 地方においてはまず官需が拡大し、追って民需も拡大してきたため、地場の独立系ソフトウェア会社が設立されてきたこと、の 2 通りがあるとしている。しかし、地方の需要には限界があることと、情報シス
テムの導入をディーラーが主導するという地方独特の取引構造のためにソフトウェア開発費用が低く抑えられるという構造的な理由により、結局地方に設立された独立系ソフトウェア会社も、首都圏の需要を狙わざるをえない状況にあると指摘している。（今野浩一郎・佐藤博樹〔1990〕pp.50〜 57）
また、同研究は地方において、地場系独立系ソフト会社にとっては大手の生産工場の進出が、優秀な人材の獲得の上で障害になりかねないと危惧する材料になっていることを指摘している（同pp.60 〜 62）。他にも、大手企業では顧客との頻繁な折衝を必要とする上流工程を首都圏グループが担当し、骨格が決まった後の中流工程は地方が担当するという分業の仕組みが成立しており（図1）、地方の地場系独立系ソフト会社も、この構図に乗って首都圏の案件の中流工程を分業・下請
けの形で積極的に獲得していくべきだとしている。これによって地方の下請け化は進むものの、地場市場に固執すれば経験できる仕事の幅に限りがあるため、首都圏からの下請けのほうが受注の安定化、受注価格、技術力の向上の面でメリットが大きいとしている。そういった案件をこなす中で、技術力を獲得して成長するチャンスをつかむ

図1

べきだと指摘している。
（同 pp.63 〜 67）

首都圏と地方の分業関係
首都圏

今野浩一郎・佐藤博樹〔1990〕の研究は、地方にソフトウェア産業の立地が進んだ理由

上や、地方における地場系独立系企業と進出し流てきた大手企業との人材確保をめぐる競合関係、首都圏と地方の間のプロセス分業による

中

分業関係の成立など、重要な指摘をしている。

流

しかし、この研究は 1980 年代の認識に立ったものであり、現状には合わない点も多い。
第 一 に、1990 年 代 後 半 以 降、 ま た 東 京

下
流

営

業

●

システム分析

●

概

念

設

計

●

詳

細

設

地方

計

●

プログラム設計●

コーディング

●

テ
納

ス

ト

●

入

●

（出所）今野浩一郎・佐藤博樹〔1990〕p.66。

− 186 −

IT 産業の分業体制の類型化への集中傾向が復活していることである。

図２

情報サービス産業の東京都への集中度

70％

1990 年代前半までは、確かに東京都への集中度が緩和される方向に動いていたが、 60％
1990 年代後半になると、事業所数の集中度

50％は依然として漸減傾向にあるものの、従業40％

者数と売上高については集中する傾向に転じている（図 2）。また実数ベースでみても、
1998 年以降は東京都の従業者数が増加を続30％けているのに対し、東京都以外の地域では漸10％減している（表 1）3)。すなわち、東京都内

0％の再開発等により事業所の統合化、巨大事業所化が進んでいる上に、地方から東京への人

事業所数
従業者数
売上高

20％

1980

1985

1990

1995

2000

2005

（出所）『特定サービス産業実態調査』より筆者作成。

材の移動もあるとみられる。

表１

第二に、ソフトウェア開発が複雑多岐化していることである。当時と比較して、開発されるソフトウェ
アは巨大化・複雑化しており、開発要員動員力の弱い地方のソフトウェア会社に発注される部分は、巨大なシステムの中の細分化されたモジュールの、かつ部分的な工程の開発にとどまる傾向にある。こうした「部分的な」開発作業は労働集約的・画一的なものであり、高い技術力や企画力を必要としない。
また、類似するシステムを繰り返し受注できるとも

情報サービス産業の従業者数推移（単位：人）

調査年
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005

東京都
191,655
196,754245,581244,917
249,026
249,821260,576
260,445
263,984
278,156

東京都以外
225,432
230,181290,256
289,834
266,436
276,497
274,155
275,447
269,078
258,838（出所）『特定サービス産業実態調査』。

限らないため、特定分野のシステムに関する開発ノウハウも収集しにくい。そのため、このような開発作業を下請受注するソフトウェア会社が、案件をこなす中で技術を獲得することは難しくなっているといえる。
第三に、ソフトウェアの開発モデルが変化しつつあることである。第 III 章にて詳述するが、ソフトウェア開発を上流工程から下流工程に向けて順次進めるウォーターフォールモデルに代わり、スパイラルモデルやアジャイルモデルなどが採用されつつある。こうしたモデルを採用した場合、ソフトウェア開発の一部分を切り出して遠隔地に発注することが困難になる場合がある。
第四に、ソフトウェア下請け市場の低価格化である。情報処理推進機構が 2007 年に行った調査によれば、元請けの立場の会社と下請けの立場の会社の労働生産性を比較すると、前者は 6,415
円であるのに対し後者は 3,719 円（元請け企業の 58.0%）にしかならない。特に、下請けの中でも「元請けが系列会社（あるいは親会社）である」とした企業の労働生産性は 3,480 円（元請け
企業の 54.2%）と、際立って低い結果となっている。（情報処理推進機構〔2008〕p.7）− 187 −

藤

本

理

弘

こうした状況の原因として考えられるのが、市場のグローバル化である。今まで地方企業に発注されていた部分が、コストや開発要員動員力に優れた中国など海外への発注に切り替わりつつある。
これにより、国内の地方のソフトウェア会社は、大手企業の系列内・系列外を問わず、コスト・開発要員動員力の両面で外国との競争に巻き込まれることになり、受注の安定化や受注価格の維持なども難しくなってきている。

Ⅲ．開発工程と取引慣行
今野浩一郎・佐藤博樹〔1990〕の研究で注目すべき点は、図 1 にあるように開発プロセスにおける地域間分業の存在を明らかにしたことであるが、地域間分業体制を推奨している点を見ると、開発工程における作業内容や、取引慣行の実態を正しく把握しているとは言いがたい。そこでまず、
ソフトウェア開発を行う際の開発工程や取引慣行について整理しておこう。

(1) 開発モデルと開発工程
ソフトウェア開発作業は、開発工程と呼ばれる段階を踏んで進められる。開発工程の設定方法によって、ウォーターフォールモデル、プロトタイピングモデル、スパイラルモデル、アジャイルモ
デルなどの開発モデルが存在し、開発時にどのモデルに基づいて開発するかを選択する。また、開発工程としては要求定義、基本設計、詳細設計、製造、テスト 4) といった工程（ウォーターフォー
ルモデルの場合）がある。しかし、開発モデル・開発工程ともに厳密な定義は存在していない。たとえば開発工程については、JIS X 0160 ではシステム要求分析、システム方式設定、ソフトウェ
ア要求分析、ソフトウェア方式設計、ソフトウェア詳細設計、ソフトウェアコード作成、テスト 5
工程（省略）の全 11 工程が定められているものの、この工程名が開発作業で使われることは少な
く、開発会社や開発プロジェクトにより様々な工程の設定がなされているのが現状である。本稿では、ウォーターフォールモデルにおける開発工程を表 2 のとおり定義しておく。
ここで注意が必要なのは、ソフトウェアの開発工程において用いられる「製造」の名称が、製造
表２

開発工程名
作業内容

工程名

要求定義

開発するシステムの機能や範囲を決定する

基本設計

要求定義に従い、システムの外的な機能を設計する

詳細設計

基本設計に従い、システムの内部構造を設計する

製

詳細設計に従い、コンピュータのプログラムを作成する（プログラミングともいう）

造

テ ス ト

プログラムが設計通りに動作するかどうかを検証する（出所）筆者作成。
− 188 −

IT 産業の分業体制の類型化

業における「製造」のような製品を大量生産する工程ではなく、1 人 1 人に違った出力が求められる、製造業でいえば「設計」にあたる工程であるということである。ソフトウェア産業ではこの部
分に最も人員を割く必要があることから、この部分を慣習的に製造工程と呼んでいる。
ウォーターフォールモデルの場合、川の流れになぞらえ、前の工程（通常は要求定義、基本設計）
を上流工程、後の工程（通常は詳細設計以降）を下流工程と呼んでいる 5)。それ以外の開発モデルにおいても、上流工程から下流工程に向けて作業を進めるのが原則であるが、近年開発された開発モデルでは、スパイラルモデルのように上流工程から下流工程に向けての流れを何度も繰り返したり、アジャイルモデルのように上流工程と下流工程を同時に進めたりするものもある。しかし、いずれのモデルにおいても、表 2 で示した開発工程の要素は、何らかの形で取り込まれている。
上流工程になるほど、技術者はシステム化する業務に精通する必要がある。また技術者の裁量が大きくなるため、高いスキルが求められる。特定の業務に精通した技術者は、類似する開発を行う
場合の生産性が高くなりやすい。逆に、下流工程は上流工程で定められた仕様に従って設計やプロ
グラミングを行う作業であり、技術者の裁量が小さく、システム化する業務に精通していなくても開発をこなすことができるため、技術者のスキルが上流工程ほど重要ではない。上流工程と比較して多くの人員を必要とするが、ほぼ全てを人手に頼る労働集約的な作業であり、生産性を向上させるために努力可能な余地は小さい。

(2) 取引慣行
ソフトウェア産業の取引形態には、元請けか下請けかにかかわらず、大きく分けて派遣契約、準委任契約、請負契約の 3 種類の契約方法がある。その違いは表 3 の通りである。この中で、派遣契約は基本的に発注側に赴いて作業し、労務管理も発注側が行う。準委任契約も多くの場合は発注側に赴いて作業をするが、そうでない場合もある。労務管理はどちらの場合でも受注側が行う。請負契約は基本的に自社内で作業をするが、発注側に赴いて作業を行うこともある。よって、地域間分業に使われるのは基本的に請負契約である。

表３
契約方式

派遣契約

準委任契約

請負契約

ソフトウェア開発業務の契約形態
契約の特徴

労働者派遣法に基づき技術者を派遣する。労務管理は派遣先が行う。
作業工数に対して対価を支払う。

「委任した作業」（作業工数）に対して対価を支払う。労務管理は派遣

作業場所

発注側

発注側

元が行う。瑕疵担保責任はない。

（自社内）「仕事の完成」に対して対価を払う。通常、瑕疵担保責任がある。

（発注側）

契約時に仕事の範囲を明確化する必要がある。

（出所）日本アプライドリサーチ研究所〔2008〕p.64 を元に筆者作成。
− 189 −

自社内

藤

本

理

弘

この中で、派遣契約と準委任契約については、同様に作業工数に対する対価支払いとなっている
ため、外見上区別がつきづらい。派遣契約の場合には、派遣先監督者の指示の下で作業に従事するのに対し、準委任契約の場合には、発注側が受注側従業員に対して直接作業指示を行うのは違法であるという点が異なる 6)。しかし、作業指示に該当するかどうかが曖昧な場合もある。たとえば、
三菱 UFJ リサーチ & コンサルティング〔2007〕によれば、(1) 発注側の社員が主導で受注側社員との合同会議を行った場合、(2) 仕様の明確化のために受注側社員が発注側社員と直接コミュニケー
ションをとった場合、(3) 受注側から再委託されたコンサルタントがコンサルティング業務を行う
場合に、発注側社員と直接コミュニケーションをとる場合、(4) 発注側社員が受注側社員に対して進捗確認やスケジュール確認を行う場合、などが作業指示に該当するかどうか曖昧としている（三菱 UFJ リサーチ & コンサルティング〔2007〕pp.14 〜 16）。
その他、ソフトウェア業界の取引慣行として重要な点を 3 点指摘しておく。
(1) 個人事業主が広く活躍していること。ソフトウェア業界は建設業界と業界構造が似ているとされているが（新川正子〔2002〕）、建設業界ではプロジェクトに個人事業主が参加する場合、基本的に設計・デザインといった上流工程への参加になる。しかし、ソフトウェア業界では下流工程にも多数の個人事業主が参加しており、多くの場合は準委任契約で契約先に常駐し（請負契約の場
合もある）、システムエンジニアやプログラマの立場で開発に参加している。
(2) 請負契約の場合、発注側から受注側に対する「与信」というべきものが存在すること。ソフ
トウェア開発は時間と工数をかけて開発したとしても、設計に瑕疵があると正しく動作しない。この場合、請負契約ならば瑕疵担保責任として、受注側にこれを修正する義務があるが、受注側の能力（動員力・技術的能力）を超えるような規模の調査や修正が必要になった場合、結果的に発注側がシステム開発に掛けた費用が回収できなくなるおそれがある。そのため、規模の小さいソフトウェ
ア会社には、その能力に見合った規模のソフトウェアしか発注できない。
(3) いわゆる「横請け」が多いこと。ソフトウェア産業は人手に頼る割合が高く、従業者にスキルが必要であるため、供給弾力性が低い。そこで、競合する企業同士でも互いに仕事を融通しあう場面が多くみられ、「丸投げ」などの発注形態が横行しやすいと考えられる。7)(3) ソフトウェアプロダクト
ソフトウェア産業には、上記で示した受注ソフトウェア開発業務の他に、予めソフトウェア会社
が企画して開発したソフトウェアを販売する「ソフトウェアプロダクト」業務がある。ソフトウェ
アプロダクトは一般的に利益率が高く、またプロダクトアウト型のビジネスとなるため、大都市から離れた地方のソフトウェア会社でも競争力を確保できそうにみえる。
しかし、ソフトウェアプロダクトには、流通ルートに乗せるもの（いわゆる「パッケージソフト」）と直販主体のものとがある。このうち、直販主体のものは販売時にカスタマイズ作業を必要とすることが多いという点が見逃されやすい。カスタマイズ作業を行う場合、顧客とのカスタマイズ仕様− 190 −

IT 産業の分業体制の類型化のすり合わせや顧客先でのテストなどが必要になる場合もあり、この場合は製品の供給とはいえ、受託ソフトウェア開発と同様の作業を行う必要がある。そのため、プロダクト供給型の企業であっても下請けの立場になりうるのである。

Ⅳ．下請け取引の類型化
統計上でいえば、ソフトウェア産業の「下請け」とは、同業者（すなわちソフトウェア業）からの受注のことを指すと認識されることが多い。たとえば、ソフトウェア会社を「元請けの立場」「中間下請けの立場」「最終下請けの立場」で分類していたり（三菱 UFJ リサーチ & コンサルティング〔2007〕p.33）、「下請けの立場」の定義を「売上の半分以上は他のソフトウェア会社からの下請けである」としていたりしている（情報処理推進機構〔2008〕p.69）。
しかし、図 1 で示したような地域間分業形態の場合、首都圏側の企業はソフトウェア業とは限らず、大手コンピュータメーカーなど別業種になることも少なくない。この場合、作業内容は明らかに下請け作業であるが、上記の「下請け」の範疇には含まれないことになる。そこで、上記のような「同業者（すなわちソフトウェア業）からの受注」を「伝票上の下請け」と定義し、現場で下請けと認識しやすい「作業上の下請け」の姿を追ってみることとする。
「伝票上の下請け」と「作業上の下請け」を含め、ソフトウェア開発における代表的な下請けの

図３

下請け取引の類型

ゼネコン型
（�）

コンサル型
（�）

丸投げ
（�）

名義貸し
（�）

発注元
発注元

発注元
発注元

発注元
発注元

発注元
発注元

実
実
作
作
業
業

一次請け
一次請け
（要・設・試）（要・設・試）

一次請け
一次請け
（要・試）
（要・試）

二次請け 二次請け
二次請け
二次請け（開・試） （開・試）
（開・試）
（開・試）

二次請け
二次請け
（設・開・試）（設・開・試）

二次請け
二次請け（要・設・開・試）（要・設・開・試）

メーカー直接型（�）

ユーザー直接型
（�）

発注元
発注元
（要・設・試）（要・設・試）

発注元
発注元
（要・試）
（要・試）

下請けの
下請けの
要素が強い
要素が強い
作業
作業

一次請け
一次請け 一次請け
一次請け
（開・試）
（開・試） （開・試）
（開・試）

一次請け
一次請け
（設・開・試）（設・開・試）営
営
一次請け
業 一次請け業（出所）筆者作成。
（出所）筆者作成。

− 191 −

営
営
業
業
�
�
実
実
作
作
業
業

金
金
�
一次請け �
一次請け
流
流
れ
れ

二次請け
二次請け
（要・設・開・試）（要・設・開・試）

伝票上の下請け伝票上の下請け要：要件定義要：要件定義設：基本設計設：基本設計開：詳細設計・製造
開：詳細設計・製造
試：テスト
試：テスト

藤

本

理

弘

形態を示したのが図 3 である。この図は請負契約または準委任契約による流れを示したものであり、派遣契約は含めていない。また、三次請け以上の多重下請けの場合は、この下請けパターンが繰り返されると考えられるため、ここでは二次請けまでの考え方のみを示す。
「ゼネコン型」は、発注元から受注したソフトウェア開発を「一次請け」が上流工程のみを実施
し、下流工程を下請け（二次請け）企業に分散発注する方式で、建設業の業界構造とよく似た分業形態である。前掲の今野浩一郎・佐藤博樹〔1990〕が認識している主な取引形態もこの形である。
この場合、「二次請け」の作業は「伝票上の下請け」にも「作業上の下請け」にも該当するといえる。
「コンサル型」は「一次請け」が受注し、要件定義とそれに対応するテストのみを担当して、それ以外の開発をすべて「二次請け」（通常 1 社）に再発注する形態である。開発案件の業務知識に精通している会社が一次請けを担当することが多いためにこう呼ばれる。二次請けが担当する作業は、「ゼネコン型」と比較すれば、基本設計を担当する分だけやや下請け的な要素が薄くなる。無論、
この取引形態も「伝票上の下請け」「作業上の下請け」の両方に該当する。
「丸投げ」は「一次請け」が営業と受注を行うが、発注元とのコミュニケーションを含めたすべての実質的な開発作業を下請けが行う取引形態である。メーカーやユーザーの関連会社・子会社が一次請けとなり、独立系の企業が二次請けとなる場合や、先に示した「横請け」の場合などに多く見られる。この場合、「伝票上の下請け」には該当するが、受注側は実質的に元請けと同様の作業を行うため、「作業上の下請け」には当たらないといえる。
「名義貸し」は「二次請け」の企業が営業から実作業まですべてを行うが、契約書や金の流れは「一次請け」を通すという取引形態である。これは、前章で指摘したように、発注側から受注側への「与信」が通らなかった場合などに使われる。この取引形態も「伝票上の下請け」に該当するが、「作業上の下請け」ではないといえる。
「メーカー直接型」は「ゼネコン型」の「一次請け」が担当する部分の作業を発注元が行うもので、一次請け（すなわち伝票上の元請け）が行う作業内容は、「ゼネコン型」の「二次請け」と変わらない。
これは、「伝票上の下請け」には当たらないが、「作業上の下請け」には該当する。電気機器に対す
表４類型

下請け取引の類型のまとめ
伝票上の下請け作業上の下請け(1)

ゼ ネ コ ン 型

○

○

(2)

コ ン サ ル 型

○

○

(3)

丸

げ

○

×

(4)

名

し

○

×

(5)

メーカー直接型

×○(6)

ユーザー直接型

×

○

投

義

貸

（出所）筆者作成。
− 192 −

備考

IT 産業の分業体制の類型化

る組み込みソフトウェアなど、電機メーカー等からの発注で多い形態と考えられる。
「ユーザー直接型」も同様の関係であり、「一次請け」は伝票上の元請けであるにもかかわらず、
作業内容は「コンサル型」の「二次請け」と変わらない。すなわち「伝票上の下請け」には該当しないが、「作業上の下請け」には該当すると言える。
これらをまとめると表 4 の通りとなる。「伝票上の下請け」で見える範囲は (1) 〜 (4) の範囲であるが、「作業上の下請け」になるのは (1)(2)(5)(6) の形態である。また、第 II 章で示した地域間
分業も、この 4 形態で機能する。(3)(4) の形態の作業は、遠隔地で作業することが困難だからである。逆に (5)(6) の形態が、地方のソフトウェア会社で多い受注形態であると考えられる。
しかし、この作業上の下請けである (1)(2)(5)(6) を統計的に把握することは容易なことではない。
それは、開発工程が通常伝票上に現れず、1 つ 1 つの取引の契約書や仕様書を精査しなければ、どの開発工程を担当する受注であるかが分からないからである。そのため、『特定サービス産業実態調査』を始めとするほとんどの統計では、これを把握することができていないのが現状である。

Ⅴ．その他の先行研究に対する評価
三菱 UFJ リサーチ & コンサルティング〔2007〕は、全国のソフトウェア産業に対してアンケートを行い、その下請け構造について様々な分析をしている。その中で、地域別の元請け・中間下請
け・最終下請けの立場の事業所の割合を示し、北海道・東北地方、近畿地方、中国地方、九州地方等において、中間下請け、最終下請けと比較して元請けの事業所の割合が高いとしている。
（三菱
UFJ リサーチ & コンサルティング〔2007〕p.36）
これは、地方において下請けが多いという今野浩一郎・佐藤博樹〔1990〕の研究とは反する結果になっている。そこで集計を精査してみると、四国地方と沖縄県について、中間下請け、最終下請けの割合がともに 0％となっている。しかし、四国地方には、2006 年の全売上高に対する同業者向け売上高の比率が全国一（62.1%）である高知県が含まれており、また沖縄県も、同売上高比率は全国第 6 位（44.9%）である 8)。この地域に下請けの立場の事業所がないとは到底考えられず、
サンプルに地域的な偏りがあったとみられ、考察の妥当性は低いと考えられる。
また、日本アプライドリサーチ研究所〔2008〕においては、特定サービス産業実態調査報告書の「同業者向け売上高」よりも「営業費用」中の「外注費」が大きい実態をとらえ、この理由を次の 3 通りとして分析している。(1)「同業者売上」も「ソフトウェア外注費」も概念上のずれがないとした場合、「ソフトウェア業務外注費」の外注先に、ソフトウェア業以外の産業が含まれている可能性。(2)「同業者売上高」が過小に計上されている可能性。たとえば丸投げの場合、下請けの受け手企業が実質的に元請けであるという認識から、発注側の産業からの受注として計上している可能性。(3) ソフトウェア業務外注費が過大に計上されている可能性。たとえば派遣要員への人件費支払いを「外注費用」に計上している場合など。
（日本アプライドリサーチ研究所〔2008〕− 193 −

藤

本

理

弘

pp.45 〜 47）
しかし、この考察は重要な点を見逃している。それは、『特定サービス産業実態調査』で調査対象とされない個人事業主等への発注である。個人事業主への発注は「外注費」に計上されるが、受注が「同業者向け売上高」には計上されないことから、「外注費」の方が大きい理由には、個人事
業主に対する発注の多さという要因も含まれると考えられる。

Ⅵ．おわりに地方の IT 産業が首都圏の下請け開発を行うという分業形態は、地方の IT 産業を育てると言われてきたが、実際に与えられてきた役割は、単なる労働力の供給基地であったといえる。それでも、開発に旺盛な需要がある時期には、その供給弾力性の小ささのためうまくいっていたように見えていたが、市場の落ち込みやグローバル化の影響を受けやすい性質もある。
一方、地方において IT を積極活用する場合、大都市部の大手企業に頼らざるを得ないという逆転現象も起きている。しかし、本質的に細部にわたるすり合わせが必要な IT 利用において、遠隔地の企業を頼ることが、地域における健全な IT 利用を促すものだろうか。地方の時代となった現代だからこそ、地方の IT 産業は自分の地域に回帰し、地域の情報化を担っていくべきではないの
だろうか。
（ふじもと

まさひろ・高崎経済大学大学院地域政策研究科博士後期課程）

注釈1) 総務省編『平成 20 年版情報通信白書』では、第 1 章第 1 節において「情報通信による地域経済の活性化」が掲げられ、その第 2 項において「地域間デジタル・ディバイドの解消」が強調されている。しかし、ここで分析が行われているのは通信インフラと自治体の施策の状況に限られ、ここで指摘するような状況がなぜ発生しているのかについては、情報化関連予算割合、推進体制の整備、情報化計画の策定、広域連携、国の支援策というように外的な側面しか分析されていない。
2)『平成 18 年版特定サービス産業実態調査』による。
3) ここで利用している『特定サービス産業実態調査』は、実態調査としては網羅率が低く、また度々調査対象が見直されてきていることから、時系列でみた場合に実態以上に数値が大きく変動していることがある。
4) 本来はテスト工程も細分化されており、単体テスト、結合テスト、総合テストなどというように、設計工程と等しい数の工程が用意される。しかし、これについて詳述するのは本稿の趣旨ではないので省略する。
5) この分類方法は、今野浩一郎・佐藤博樹〔1990〕による分類方法（上流・中流・下流）とは異なっているが、実際には下流工程を担当した業者が最終テストまで参加することが多いことから、ここでは上流・下流の 2 通りの分類としている。
6) 請負契約の場合も、発注側から受注側従業員への直接指示は違法である。
7) 人手に頼る割合が高く、従業者にスキルが必要であるため供給弾力性が低く、横請けが多い取引構造を持っているという特徴は、河藤佳彦〔2009〕p.38 が指摘している伝統的製麺業（稲庭うどん製造業）の場合と共通している。
8)『平成 18 年版特定サービス産業実態調査』による。
参考文献
今野浩一郎・佐藤博樹〔1990〕『ソフトウェア産業と経営』東洋経済新報社
新川正子〔2002〕「研究ノート：建設外注費の本質とその真実性」（『千葉商大論叢』40-3、千葉商科大学国府台学会）
三菱 UFJ リサーチ & コンサルティング〔2007〕『情報サービス・ソフトウェア産業の取引の高度化に関する調査研究報告書』
情報処理推進機構〔2008〕『第 29 回情報処理産業経営実態調査報告書（2007 年度調査実施）』
日本アプライドリサーチ研究所〔2008〕『情報サービス・ソフトウェア産業における取引慣行・競争実態に係る調査研究報告書』
河藤佳彦〔2009〕「製造業における取引ネットワーク構造と振興策に関する考察―秋田県湯沢市を例として―」（『日本地域政策研究』7、日本地域政策学会）− 194 −