1. これからのエンジニアリングを考える Vol.2
これだけは知っておきたい
SI業界のよもやま話
ゆもと みちたか (@gothedistance/ござ先輩)
2012/03/10 @ Oracle Aoyama Center Building

2. 超簡単なSI業界構造
上流工程と下流工程が分断されていることを是非覚えておいて下さい！
開発プロセス SIピラミッド よくわかる解説
要件定義 • BIG5(7だったかも)と呼ば
BIG5 れるIBM,NTT,日立,NEC,
富士通グループが大きな
外部設計 市場シェアを持つ
• 大人の事情によりシステ
内部設計 中堅 ム屋がシステム屋にエン
ジニアを派遣する形態が
横行している。
実装
• 左記の赤線のライン(要件
中小/零細 と実装)のあいだに大きな
テスト 壁があります。
この工程の分断がSIオワコン節の元凶です。それを説明していきます。

3. 工程分断の弊害(1)
工程の分断が引き起こす大きな弊害の１つは、自分でITによる問題解決が
出来ない人材を産んでしまうこと。設計者と実装者は同一であるべき。
• 工程が分断されてしまうと、｢自分でITによる問題解決が出来ない人材｣
が増えるから。
• 本来は設計からテストまで自分で行わなければ、エンジニアとしてのレ
ベルアップは望めない。全体を俯瞰して細部に落とし込むことで初めて、
何が良くて何が悪いのかを知ることが出来る。それが、プログラミング。
• 言われた仕様に沿ってコードを書くだけのお仕事では、より高度な実装
を行う意欲が湧いてこない。立場上、言われた仕様を覆す決定権が無い
ので、仕様と実装の乖離を埋めることが出来ない。
• 上流工程だけを行うエンジニアも不幸だし、下流工程だけを行うエンジ
ニアも不幸。ソフトウェアを作る醍醐味を知る機会が乏しい。

4. 工程分断の弊害(2)
もう弊害の１つは、後工程(要はエンジニア)にしわ寄せが来てしまうこと。
開発者に優しい開発プロセス
機能A 要件定義 設 計 実 装 テスト
機能B 要件定義 設 計 実 装 テスト
機能C 要件定義 設 計 実 装 テスト
機能毎に要件定義からテストまでを１つの工程として捉える考え方。
SIerの一般的な開発プロセス
要件定義 設 計 実 装 テスト
機能A 機能A 機能A 機能A
機能B 機能B 機能B 機能B
機能C 機能C 機能C 機能C
後工程が問題ないことを前提にシステムを開発しようとする考え方。

5. 工程分断の弊害(2)
後者の進め方の弊害は、要件を受けて実装した時に問題が発生してしまう
と、要件から見直さなくてはならない。これが常態化するとデスマになる。
こんなプロジェクトがあるとしましょう
3月 4月 5月 6月 7月 8月 9月
要件定義 稼
基本設計 問題 動
発生 開
実 装
手戻り発生 始
テスト
• 要件と仕様がマッチしていているかどうかは、実装して初めてわかるもの
• しかし、工程が分断されていると複数箇所の仕様の誤りがあると整合性を
取ることが出来ずに、本当に正しい仕様が何なのか誰も分からなくなる
• 要件定義がずるずると続き開発工程が圧縮されてしまうので、エンジニア
にしわ寄せが来るし、要件が決まれば誰でも作れるから人海戦術で遅れを
取り戻そうとするが・・・・あれりえぽあｔぽあじょれいぺじゃｒじぇぱいｒぺあ

6. 人月見積の甘い罠
なぜアジャイル的な開発が出来ないかと言えば、人月見積もりが原因。
人月を見積りに使った場合の価格設定の方程式
単価 期間 人数 価格
アジャイル的な開発手法を取り入れて、期間が３ヶ月から１ヶ月に短縮
できるとしても、期間の減少と人数の減少が見積価格の低下に直結する
また期間と人数を小さくするには設計から開発まで同一人物が行うしかな
いのだが、外注に出せない開発モデルなので誰もやりたがらない。
｢いいじゃんいいじゃん。要件固めてこれ以外やりませんって言えばいいじゃ
ん。なんでそんな苦労して値段下げてやるのよ。期間と人数圧縮したらめっ
ちゃリスクでしょ？おまえがやれるかわかんねぇだろ？どうすんのよ。」
人月は成果物が不定型なサービス事業とすこぶる相性がよいのです。

7. 黒 船 来 襲 ！
SaaS/PaaSのビジネスが海外より来襲したことにより、｢何でもかんでも
受託開発すればおｋ」という時代は終わったんだよ！(なんだってー！
• クラウドが破壊的なのはアプリケーションを顧客別にカスタマイズして
利用できる｢マルチテナント｣なビジネスを行っているからです。顧客か
らすれば、EC2だろうがさくらのクラウドだろうが安定稼働すればおｋ。
サーキットの作りで騒いでいるのは業者だけ。
• さっきの人月見積もりの方程式をいくらはじいても、「YOUたちサイン
アップすれば今すぐ使えますよ」というビジネスモデルには価格面でも
スピード面でも勝ち目がないのは明白。
• かといって、受託開発がなくなることは有り得ない。だが、SaaSや
PaaSのビジネスと同じ土俵で勝負したら勝ち目がない。喫緊の課題は、
どこで差別化要因を構築してクラウドの懐に入って戦うか。
SIビジネスで生きていくために、どのようにして優れたサービスを生み出す
のかを必死で模索しているという群雄割拠の時代に突入したと言えます。

8. 強引にまとめますと
工程の分断で振り回されてしまうのは本当にマイナスなので、工程の分断
を是として何も変わろうとしないSIerは全力で否定していいです。
SI業界がオワコンなのはピラミッド構造がオワコンになりつつあるという
ことなので、受託開発がオワコンというのは間違いです。受託が悪なのは
工程の分断によるサラリーマンの悲哀が強いということだけです。
自分の持ってる技術で何が出来るのか、真剣に見つめ直して下さい。
技術それ自体は１円にもなりません。活用できない技術はクズ同然です。
自分の持っている技術の「ひきだし」を増やす努力をしましょう。
業界構造がどうなろうとも、自分が活用できるIT技術をそれがわからない
ヒトに説明し価値を説明でき、かつシステムが作ることができるのなら、
色んな所からエンジニアとしてオファーが来ます。プログラミングをする
ことは、出来なくても独立してコンサルやってる人も結構います。
その訓練としては、ソーシャルメディアで情報発信をするのが効果的です。