日本のソフトウェア企業の売上の約７割はSIです。多くの顧客は安心・安全を求めて発注先として大手ソフトウェア企業を選びます。大手ソフトウェア企業はシステム開発のプロジェクト管理と上工程（要求設計・機能設計・構造設計）を担い、下工程（詳細設計･コード化・テスト）は外注するのが一般的です。企業によっては、上工程の大部分を外注するケースもあります。中小零細企業はこの大手企業の下請けとなっています。下請け企業もまた外注するいわゆる孫請けを行うこともあります。このような慣習を指してＩＴゼネコンと呼ばれる多重構造が生まれました。多重構造であっても、末端の企業が正当な収益を上げることができるならば、何ら問題はありません。しかし、下請け、孫請け、・・・と階層が下になるにつれ、最下位の企業はピンはねされて、見るも無残な状況に甘んじなければならなくなるケースがあります。
ソフトウェアの“設計”は大きく機能設計（What）と構造設計以降（How）に分けることができます。そのどちらにもついても品質が問われますが、一般に、構造設計以降の品質について議論されることが多いようです。
機能設計の品質が悪いと、いくら構造設計以降の成果物の品質が良くても、顧客の信用は得られません。顧客の要求を満たしていなければ、どうしようもない訳です。
構造設計以降の品質についてはコード化されたプログラム（モジュール）のテストを開始した直後に決定的に明らかになります。品質が良いプログラム（モジュール）は一発目のテストでストーンっと走ります。品質が悪いプログラム（モジュール）は２０、３０ステップ毎にズッコケます。テストしながらソース・コードを見直すということを繰り返すようでは話になりません。このような悪戦苦闘しているSEやプログラマがいることに気づいていないプロジェクト管理者がいたとすれば最悪です。設計段階から何も見ていない状態だったのです。SEやプログラマを追加したり、交代させ、納期を大幅に遅れて納入できたとしても、顧客の信用は失墜してしまいます。
そもそもソフトウェアの品質を数値で表すことはできないのですが、前稿：計測の説明で品質を計測する尺度として“テスト項目数”、“欠陥件数”、“欠陥検出率”があることを述べました。これらはソフトウェアの品質を測る便宜的な尺度であって、ソフトウェアの品質を表す尺度ではありません。人の白血球の数は1ミリ立方メートル当り3,000～9,000個が正常値で、あなたは 4,500だ から正常ですと、成人検診などで言われますが、血液中の白血球の分布が体中で均一であることを前提に、サンプリングして評価しています。ソフトウェアの場合、欠陥がソフトウェア全体に均一に存在することはありません。むしろ、偏在することの方が多いのです。また、欠陥が多数含まれている場合にはサンプリングという手法は意味がありますが、欠陥数が少なくなっても欠陥が存在しないことを保証しているわけではありません。白血球の場合、白血球が存在しなければ異常ですが、反対に、存在しないことが正常であると仮定すると、ソフトウェアの場合と同様に完全に存在しないことを検証する手段はないでしょう。実際、癌細胞が存在しないことを検証することはできません。ソフトウェアの欠陥であれ、人の癌細胞であれ、“存在しない”ことを検証することは大変難しい問題です。
今回はITプロジェクト管理考としては少々ずれた話になりますが、ソフトウェアが重要な基幹産業であることをはっきりとさせておくべきと考え、敢えてこのテーマを取り上げました。
現在、我国には都市部と地方との格差など、解決しなければならない問題があります。
私は、都市部と地方の格差やそれに起因するいろいろな問題解決にソフトウェアの役割は非常に大きいと考えています。
そのことを述べるために、先ず、具体的な状況の一端と、経済産業省の報告書について紹介します。
１．都市と地方の格差問題
都市部に人口が集中し、地方が疲弊してきた。
住民基本台帳を基にした調査が新聞に掲載された。記事のうろ覚えであるが、首都圏、中部、大阪の人口は増加傾向だが、その他は減り始めた。特に人口減率が高いのは秋田県、その他の県も減る一方。北海道を見ると、４０年前も今も道の人口はおおよそ５００万人だが、札幌の人口は約８０万人から約１９０万人に増えている。その差分は道内の地方都市：小樽、旭川、釧路、函館、帯広などの人口減に相当。仕事がないので皆札幌に集まってきている。同じことが、首都圏、中部、大阪と他の府県との間に当てはまる。人がいなくなれば疲弊するのは当たり前。
少し大きなシステム構築のITプロジェクト、つまり数十人以上のITプロジェクトは顧客、元請け企業、その下請け企業など、複数の企業の社員から構成される混成プロジェクトとなるケースが殆どです。このようなITプロジェクトでは元請け企業の管理力不足が露呈することがよく見受けられます。
納期が守れなかった、費用がかかり過ぎた、品質が悪い、拡張性がない、性能不足などとなるケースは、失敗と言わざるを得ません。厳しいと言われるかもしれませんが、これらのいずれか１つでも顧客の満足が得られなければ“失敗”です。
混成プロジェクトでは元請け企業の力量が問われます。生半可なプロジェクト管理はできません。プロジェクトの規模が大きくなるほど徹底した管理を行わなければなりません。混成プロジェクトを成功させる最低の条件として、プロジェクトメンバが共通のコミュニケーション基盤（技術知識および管理知識）の上で仕事をする必要があります。構成メンバが異なる企業文化を持ち込んでくるとちょっとしたコミュニケーションさえうまく行かなくなります。
構成メンバが技術文書（要求仕様、機能仕様、構造仕様、詳細仕様、コード化標準、レビュー方式、テスト基準、品質評価基準、各種帳票、設計用語、etc.）やその作成手順、会議の種類・進め方などの知識を共有していなければ、コミュニケーションは躓きます。元請け企業は、こうしたコミュニケーション基盤を文書化し（これを「作業標準」と呼びます）、混成プロジェクトの構成メンバが作業標準に従うことを義務づけなければなりません。
