SIerとネット企業の違いを、前提条件も含めて考えてみる。

1. +
IT業界の2つの世界
- SIerとネット企業 -

2. +
概要
 一般にIT業界と呼ばれる中でも、いわゆる「SIer」と「ネット
企業」という2つの区分が存在し、文化が大きく異なる。
 このことを意識しないと、同じITエンジニア職でさえ話が噛み合わ
ないことがある。実質的に異なる業界と言っても良いくらい。
 参照：「IT業界」「エンタープライズ系」という言葉のコンセンサ
ス: IT Pro
 http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/
073100019/?ST=ittrend
 この2つの世界の違いは、開発スタイル等に現れるものの、明
確な定義や条件は曖昧である。本スライドでは、2つの業界
（「SIer」と「ネット企業」）の文化の違いと、その前提条件
を考える。
2

3. +
筆者の前提
 経歴
 新卒でSIerに就職。金融系SEとして主にシステムの新規開発を担当。
 2年後、ネット企業にサーバサイドエンジニアとして転職。主に既
存システムの運用を担当。
 さらに2年後、非エンジニア職に異動。
 本スライドで挙げる内容には、「SIer」と「ネット企業」の以
外の違い（「新規開発」と「運用・開発保守」の違い等）も含
まれてしまっている可能性がある。
 筆者はアプリ寄りのエンジニアだったため、インフラ寄りの事
情は記していない。
3

4. +
筆者の考える定義
 次の特徴を持つビジネスに対応するために
 環境の変化（＝要件の変化）が速く予測不可能
 「99.9%の品質」よりも「95%の品質＋スピード」が重要※
 結果として次の開発環境の特徴を全て満たすのがネット系
1. リリース前よりもリリース後の運用がメイン
2. 質の高いエンジニアが同じプロジェクトに一定期間は参画
3. 開発スコープやスケジュールは、変えずに厳守することよりも、臨
機応変に変える方が良いということを、ステークホルダー全員が認
識している
※ちなみに「100%の品質」「バグが全く無い」は実質的に実現不可能！
（仮に膨大なリソース（時間・人員etc）を利用可能だとしても）。もちろん品質
とスピードはトレードオフの関係にある。
4

5. +
SIerとネット企業の一般的な特徴
 SIerとは
 発注企業が使用するシステムを開発
 代表的な企業
 NTTデータ, 日本IBM, 野村総合研究所(NRI), 富士通系列, 日立製
作所系列, 新日鉄住金ソリューションズ(NSSOL), 伊藤忠テクノ
ソリューションズ(CTC), …
 ネット企業とは
 自社が使用するシステム（＝ビジネスそのもの）を開発
 代表的な企業
 Google, Amazon, Facebook, Twitter, Yahoo, ミクシィ, GREE,
DeNA, 楽天, サイバーエージェント, …
5

6. +
SIerとネット企業の一般的な特徴
 SIerの特徴
 システムの新規開発時に仕様をすべて決めてしまい、機能の実装やテ
ストもすべて行ってしまう。
 実際には、数段階にリリースを分けて少しずつ機能を実現すること
も多い。ただ、各段階で決めたことの実装・テストはその段階で全
て行う。1段階1段階が大きい。
 システムの新規開発時に最大のリソースを投入する。
 開発が完了したら、プロジェクトチームは解散。その後の運用や保
守は少ないリソースで行う（運用を別会社に投げることもある）
 稼働後はあまりシステムに変更を加えない
 設計書を大量に作成する
 実際のコーディングは下請け会社に投げることが多い。
 枯れた（十分な実績のある無難な）技術を好む
6

7. +
SIerとネット企業の一般的な特徴
 ネット系の特徴
 システムを新規開発する際は、どれだけ使われるかは予測不可能
（特に一般人向けのB2Cシステムの場合）。場合によっては数ヶ月
で放棄することも想定内。
 システムの新規開発時には、最小限の機能だけを作ってリリース。
 機能は後から追加する前提（←重要な機能でもあり得る）
 システムの新規開発時とリリース後のメンバーはあまり変わらない。
 稼働開始後もシステムを変更しまくる。むしろ運用がメイン。
 うまく運用を行いユーザ数が拡大すれば、リソースを増やす。
 設計書よりもコードがメイン
 大まかな設計書は作る場合があるが、それ以外は基本的に作らな
い。但しモックは積極的に作る。
 マネージャであってもコーディングを行う場合がある。
 比較的新しい技術を好む
7

8. +
筆者の考える定義
 さて、次のようなビジネスのシステムを作る場合…
 環境の変化（＝要件の変化）が速く予測不可能
 「99.9%の品質」よりも「95%の品質＋スピード」が重要
 ビジネスが成功するまで試してみるしかない。
 そのためには、最小限のコストでビジネスとシステムを立ち上げ、
うまく行きそうな場合のみ拡張していく（そうでなければ、早めに
諦めてすぐに次のビジネスにリソースを割く）というアプローチが
適している。
 準備にリソースを多く割いて、品質を高めれば成功率が上がりそう
に見えるが、ユーザの好みは予測不可能であり、見合う効果が出る
かが怪しい。もちろん普通に使える最低限の品質は必要。
1. リリース前よりもリリース後の運用がメイン
8

9. +
筆者の考える定義
 さて、次のようなビジネスのシステムを作る場合…
 環境の変化（＝要件の変化）が速く予測不可能
 「99.9%の品質」よりも「95%の品質＋スピード」が重要
 より多くのビジネスアイディアを試すために、スピードが重要。
そのためには、1つ1つ設計書を細かく書いていく前に実装した
方が速い。
 ただし設計書が無い場合は、システムの全体の構成や実装の細部が、
ある程度頭の中に入っていることが必要。そのためには、一定期間
は同じプロジェクトに張り付いている必要がある。
 新しい技術は、スピードと品質の両方を向上させるのに有用。ただ
し技術的なリスクも伴うため、新技術を速く習得し、なおかつリス
クも見極めることができるハイレベルなエンジニアが必須。
2. 質の高いエンジニアが同じプロジェクトに一定期間は参画
9

10. +
筆者の考える定義
 さて、次のようなビジネスのシステムを作る場合…
 環境の変化（＝要件の変化）が速く予測不可能
 「99.9%の品質」よりも「95%の品質＋スピード」が重要
 ユーザの反応を見ながら、様々なアイディアを臨機応変に実装
してリリースする必要がある。
 初めに描いた青写真よりも適切な形に気づく場合がよくある。
 優先順位やスケジュールを臨機応変に変えることが必要
 エンジニア等の技術職と直接対話しながらリリース順序を決めた方
が、意思決定がより速く、より正確になる。（要件やスケジュール
を決める場には、技術職のリーダも参加して口出しするべき）
3. 開発スコープやスケジュールは、変えずに厳守することよりも、臨機応変
に変える方が良いということを、ステークホルダー全員が認識している
10

11. +
結論
 筆者の考える定義
 2つの特徴（変化が速く予測不可能で、スピード重視）を持つビジ
ネスのシステムを作るのに必要な、開発環境の3つの特徴（リリー
ス後の方がリリース前よりも重要etc）を満たすのがネット企業
 SIerにネット企業特有の文化を持ち込むことを想定すると…
 ビジネスが2つの特徴の1つでも満たさない場合は、無理に特有の文
化を持ち込む必要性は無い。
 3つの開発環境の特徴を1つでも満たさない場合は、効果を発揮しに
くい。
 2つのビジネスの特徴と、3つの開発環境の特徴を満たせば、B2Bか
B2Cかはあまり関係ない。
 SIerとネット企業は、優劣を付けるものではなく、住み分けが
されているもの。
11