IT業界の常識と、私がその常識に対して小規模SIerとして
どう挑戦しているかを前編と後編の２回に分けて紹介します。

IT業界はピラミッド構造になっていると言われます。

この場合のピラミッド構造とは1次請け、2次請け、3,4次請けの多段構造のことを指します。
では、まずそれぞれの一般的な特色から説明します。

1次請け（建設業でいればゼネコンに該当）
　　メーカー、大手SIerなどのいくつかの会社が該当します。
　　実力に加え、知名度も活用して大型案件を受注します。

　　社員1人あたりの売上拡大のために、できるだけ下請けに発注するようにします。

　　社員には上流工程とプロジェクト管理を担当させ、
　　プログラミングはあまりしないことが一般的です。

2次請け
　　１次請けの会社に次ぐポジションです。
　　大企業でもこのポジションの会社は数多く存在します。

　　契約単位はプロジェクトではありますが、売上はプロジェクト毎の
　　人数×期間を実績で清算する契約が多く、その場合はリスクが少ない形態です。

　　あとは1次請けが切り分けた大きな単位の機能に対して、
　　一括で受注することも行われます。この場合の見積もり単位はプロジェクトです。

　　実は経営的に最も成長力が確保でき、収益性・安全性にも富むポジションです。
　　社員1人あたりの売上拡大のために、3次請けの会社から技術者を受け入れます。

　　補足：1次請け、2次請けの両方を実行する会社も数多くあります。

3次請け・4次請け

　　明示的な派遣業か、実質的に派遣業になっている会社が多いポジションです。
　　営業活動は2次請けへの技術者のスキルシート送付です。

　　売上は作業時間数で清算する契約がほとんどです。

　　ここには人材を融通しあう図式があります。他社のスキルシートを受け取って、
　　2次請けの会社に提案するのです。
　　仕事をとった会社は、中間マージンで利益を得ます。

　　参入障壁が低く、どう差別化するかが難しいポジションですが、
　　人材を大切にすることで、定着率を高め、成長を図ることが基本となっています。

まさにピラミッド構造になっていることがおわかりになるかと思います。

ただし、この構造には問題があります。
お客様ではなく、作り手の理論で構成されていることです。
中間マージンが何重にも乗ってしまいます。

孫請け・ひ孫請けにまで及ぶこのピラミッド構造は
システム開発にとって本当に必要なのでしょうか。

(次回の後編では当社の挑戦を紹介します。）