VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0

40,080 views

Published on

Published in: Technology
0 Comments
37 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
40,080
On SlideShare
0
From Embeds
0
Number of Embeds
28,900
Actions
Shares
0
Downloads
128
Comments
0
Likes
37
Embeds 0
No embeds

No notes for slide

VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0

  1. 1. これからのエンジニアリングを考える Vol.2これだけは知っておきたい SI業界のよもやま話 ゆもと みちたか (@gothedistance/ござ先輩) 2012/03/10 @ Oracle Aoyama Center Building
  2. 2. 超簡単なSI業界構造上流工程と下流工程が分断されていることを是非覚えておいて下さい!開発プロセス SIピラミッド よくわかる解説要件定義 •  BIG5(7だったかも)と呼ば BIG5 れるIBM,NTT,日立,NEC, 富士通グループが大きな外部設計 市場シェアを持つ •  大人の事情によりシステ内部設計 中堅 ム屋がシステム屋にエン ジニアを派遣する形態が 横行している。 実装 •  左記の赤線のライン(要件 中小/零細 と実装)のあいだに大きな テスト 壁があります。この工程の分断がSIオワコン節の元凶です。それを説明していきます。
  3. 3. 工程分断の弊害(1)工程の分断が引き起こす大きな弊害の1つは、自分でITによる問題解決が出来ない人材を産んでしまうこと。設計者と実装者は同一であるべき。•  工程が分断されてしまうと、「自分でITによる問題解決が出来ない人材」 が増えるから。•  本来は設計からテストまで自分で行わなければ、エンジニアとしてのレ ベルアップは望めない。全体を俯瞰して細部に落とし込むことで初めて、 何が良くて何が悪いのかを知ることが出来る。それが、プログラミング。•  言われた仕様に沿ってコードを書くだけのお仕事では、より高度な実装 を行う意欲が湧いてこない。立場上、言われた仕様を覆す決定権が無い ので、仕様と実装の乖離を埋めることが出来ない。•  上流工程だけを行うエンジニアも不幸だし、下流工程だけを行うエンジ ニアも不幸。ソフトウェアを作る醍醐味を知る機会が乏しい。
  4. 4. 工程分断の弊害(2)もう弊害の1つは、後工程(要はエンジニア)にしわ寄せが来てしまうこと。開発者に優しい開発プロセス機能A 要件定義 設 計 実 装 テスト機能B 要件定義 設 計 実 装 テスト機能C 要件定義 設 計 実 装 テスト機能毎に要件定義からテストまでを1つの工程として捉える考え方。SIerの一般的な開発プロセス 要件定義 設 計 実 装 テスト 機能A 機能A 機能A 機能A 機能B 機能B 機能B 機能B 機能C 機能C 機能C 機能C 後工程が問題ないことを前提にシステムを開発しようとする考え方。
  5. 5. 工程分断の弊害(2)後者の進め方の弊害は、要件を受けて実装した時に問題が発生してしまうと、要件から見直さなくてはならない。これが常態化するとデスマになる。こんなプロジェクトがあるとしましょう 3月 4月 5月 6月 7月 8月 9月要件定義 稼基本設計 問題 動 発生 開実 装 手戻り発生 始テスト•  要件と仕様がマッチしていているかどうかは、実装して初めてわかるもの•  しかし、工程が分断されていると複数箇所の仕様の誤りがあると整合性を 取ることが出来ずに、本当に正しい仕様が何なのか誰も分からなくなる•  要件定義がずるずると続き開発工程が圧縮されてしまうので、エンジニア にしわ寄せが来るし、要件が決まれば誰でも作れるから人海戦術で遅れを 取り戻そうとするが・・・・あれりえぽあtぽあじょれいぺじゃrじぇぱいrぺあ
  6. 6. 人月見積の甘い罠なぜアジャイル的な開発が出来ないかと言えば、人月見積もりが原因。人月を見積りに使った場合の価格設定の方程式 単価 期間 人数 価格アジャイル的な開発手法を取り入れて、期間が3ヶ月から1ヶ月に短縮できるとしても、期間の減少と人数の減少が見積価格の低下に直結するまた期間と人数を小さくするには設計から開発まで同一人物が行うしかないのだが、外注に出せない開発モデルなので誰もやりたがらない。「いいじゃんいいじゃん。要件固めてこれ以外やりませんって言えばいいじゃん。なんでそんな苦労して値段下げてやるのよ。期間と人数圧縮したらめっちゃリスクでしょ?おまえがやれるかわかんねぇだろ?どうすんのよ。」人月は成果物が不定型なサービス事業とすこぶる相性がよいのです。
  7. 7. 黒 船 来 襲 !SaaS/PaaSのビジネスが海外より来襲したことにより、「何でもかんでも受託開発すればおk」という時代は終わったんだよ!(なんだってー!•  クラウドが破壊的なのはアプリケーションを顧客別にカスタマイズして 利用できる「マルチテナント」なビジネスを行っているからです。顧客か らすれば、EC2だろうがさくらのクラウドだろうが安定稼働すればおk。 サーキットの作りで騒いでいるのは業者だけ。•  さっきの人月見積もりの方程式をいくらはじいても、「YOUたちサイン アップすれば今すぐ使えますよ」というビジネスモデルには価格面でも スピード面でも勝ち目がないのは明白。•  かといって、受託開発がなくなることは有り得ない。だが、SaaSや PaaSのビジネスと同じ土俵で勝負したら勝ち目がない。喫緊の課題は、 どこで差別化要因を構築してクラウドの懐に入って戦うか。SIビジネスで生きていくために、どのようにして優れたサービスを生み出すのかを必死で模索しているという群雄割拠の時代に突入したと言えます。
  8. 8. 強引にまとめますと工程の分断で振り回されてしまうのは本当にマイナスなので、工程の分断を是として何も変わろうとしないSIerは全力で否定していいです。SI業界がオワコンなのはピラミッド構造がオワコンになりつつあるということなので、受託開発がオワコンというのは間違いです。受託が悪なのは工程の分断によるサラリーマンの悲哀が強いということだけです。自分の持ってる技術で何が出来るのか、真剣に見つめ直して下さい。技術それ自体は1円にもなりません。活用できない技術はクズ同然です。自分の持っている技術の「ひきだし」を増やす努力をしましょう。業界構造がどうなろうとも、自分が活用できるIT技術をそれがわからないヒトに説明し価値を説明でき、かつシステムが作ることができるのなら、色んな所からエンジニアとしてオファーが来ます。プログラミングをすることは、出来なくても独立してコンサルやってる人も結構います。その訓練としては、ソーシャルメディアで情報発信をするのが効果的です。

×