これだけは知っておきたい SI業界のよもやま話

これからのエンジニアリングを考える Vol.2

ゆもと　みちたか (@gothedistance/ござ先輩) 2012/03/10 @ Oracle Aoyama Center Building

超簡単なSI業界構造

BIG5

中堅

中小/零細

SIピラミッド

上流工程と下流工程が分断されていることを是非覚えておいて下さい！

要件定義

外部設計

実装

テスト

開発プロセス

内部設計

よくわかる解説

•  BIG5(7だったかも)と呼ばれるIBM,NTT,日立,NEC,富士通グループが大きな市場シェアを持つ

•  大人の事情によりシステム屋がシステム屋にエンジニアを派遣する形態が横行している。

•  左記の赤線のライン(要件と実装)のあいだに大きな壁があります。

この工程の分断がSIオワコン節の元凶です。それを説明していきます。

工程分断の弊害(1)

工程の分断が引き起こす大きな弊害の１つは、自分でITによる問題解決が出来ない人材を産んでしまうこと。設計者と実装者は同一であるべき。

•  工程が分断されてしまうと、｢自分でITによる問題解決が出来ない人材｣が増えるから。

•  本来は設計からテストまで自分で行わなければ、エンジニアとしてのレベルアップは望めない。全体を俯瞰して細部に落とし込むことで初めて、何が良くて何が悪いのかを知ることが出来る。それが、プログラミング。

•  言われた仕様に沿ってコードを書くだけのお仕事では、より高度な実装を行う意欲が湧いてこない。立場上、言われた仕様を覆す決定権が無いので、仕様と実装の乖離を埋めることが出来ない。

•  上流工程だけを行うエンジニアも不幸だし、下流工程だけを行うエンジニアも不幸。ソフトウェアを作る醍醐味を知る機会が乏しい。

工程分断の弊害(2)

もう弊害の１つは、後工程(要はエンジニア)にしわ寄せが来てしまうこと。

要件定義 設　計 実　装 テスト

開発者に優しい開発プロセス

要件定義 設　計 実　装 テスト

要件定義 設　計 実　装 テスト

機能毎に要件定義からテストまでを１つの工程として捉える考え方。

SIerの一般的な開発プロセス

機能A

機能B

機能C

要件定義 設　計 実　装 テスト

機能A

機能B

機能C

機能A

機能B

機能C

機能A

機能B

機能C

機能A

機能B

機能C

後工程が問題ないことを前提にシステムを開発しようとする考え方。

工程分断の弊害(2)

後者の進め方の弊害は、要件を受けて実装した時に問題が発生してしまうと、要件から見直さなくてはならない。これが常態化するとデスマになる。

4月 5月 6月 7月 8月 9月 3月

要件定義

基本設計

実　装

テスト

稼 動 開 始

こんなプロジェクトがあるとしましょう

問題発生

手戻り発生

•  要件と仕様がマッチしていているかどうかは、実装して初めてわかるもの

•  しかし、工程が分断されていると複数箇所の仕様の誤りがあると整合性を取ることが出来ずに、本当に正しい仕様が何なのか誰も分からなくなる

•  要件定義がずるずると続き開発工程が圧縮されてしまうので、エンジニアにしわ寄せが来るし、要件が決まれば誰でも作れるから人海戦術で遅れを取り戻そうとするが・・・・あれりえぽあｔぽあじょれいぺじゃｒじぇぱいｒぺあ

人月見積の甘い罠

なぜアジャイル的な開発が出来ないかと言えば、人月見積もりが原因。

単価 期間 人数

人月を見積りに使った場合の価格設定の方程式

価格 アジャイル的な開発手法を取り入れて、期間が３ヶ月から１ヶ月に短縮 できるとしても、期間の減少と人数の減少が見積価格の低下に直結する また期間と人数を小さくするには設計から開発まで同一人物が行うしかないのだが、外注に出せない開発モデルなので誰もやりたがらない。

｢いいじゃんいいじゃん。要件固めてこれ以外やりませんって言えばいいじゃん。なんでそんな苦労して値段下げてやるのよ。期間と人数圧縮したらめっちゃリスクでしょ？おまえがやれるかわかんねぇだろ？どうすんのよ。」

人月は成果物が不定型なサービス事業とすこぶる相性がよいのです。

黒　船　来　襲　！

SaaS/PaaSのビジネスが海外より来襲したことにより、｢何でもかんでも受託開発すればおｋ」という時代は終わったんだよ！(なんだってー！

•  クラウドが破壊的なのはアプリケーションを顧客別にカスタマイズして利用できる｢マルチテナント｣なビジネスを行っているからです。顧客からすれば、EC2だろうがさくらのクラウドだろうが安定稼働すればおｋ。サーキットの作りで騒いでいるのは業者だけ。

•  さっきの人月見積もりの方程式をいくらはじいても、「YOUたちサインアップすれば今すぐ使えますよ」というビジネスモデルには価格面でもスピード面でも勝ち目がないのは明白。

•  かといって、受託開発がなくなることは有り得ない。だが、SaaSやPaaSのビジネスと同じ土俵で勝負したら勝ち目がない。喫緊の課題は、どこで差別化要因を構築してクラウドの懐に入って戦うか。

SIビジネスで生きていくために、どのようにして優れたサービスを生み出すのかを必死で模索しているという群雄割拠の時代に突入したと言えます。

強引にまとめますと

工程の分断で振り回されてしまうのは本当にマイナスなので、工程の分断を是として何も変わろうとしないSIerは全力で否定していいです。

SI業界がオワコンなのはピラミッド構造がオワコンになりつつあるということなので、受託開発がオワコンというのは間違いです。受託が悪なのは工程の分断によるサラリーマンの悲哀が強いということだけです。

自分の持ってる技術で何が出来るのか、真剣に見つめ直して下さい。 技術それ自体は１円にもなりません。活用できない技術はクズ同然です。 自分の持っている技術の「ひきだし」を増やす努力をしましょう。

業界構造がどうなろうとも、自分が活用できるIT技術をそれがわからないヒトに説明し価値を説明でき、かつシステムが作ることができるのなら、色んな所からエンジニアとしてオファーが来ます。プログラミングをすることは、出来なくても独立してコンサルやってる人も結構います。 その訓練としては、ソーシャルメディアで情報発信をするのが効果的です。