業務系SEの今後について

業務系SEの今後について
消費税増税と年金問題が与える影響

2012//
株式会社ノーチラス・テクノロジーズ
http://www.nautilus-technologies.com/
mailto:contact@nautilus-technologies.com
Tel: 03-6712-0636 Fax: 03-6712-0664

Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS Proprietary & Confidential

自己紹介
 okachimachiorz
– 省略

 キャリアの中で共通点として

– 「今後ふくらむ人件費どうします？」にいつも直面していた。

– 「働いている人たちのキャリアパスってどう思っています？」とか、考
えないといけない立場の連続だった。

NAUTILUS Proprietary & Confidential 1

さて現在の社会状況〜マクロ
 年寄りが増える
– 圧倒的に一人当たりの生産価値が減少する
 体力が減れば、生産できる価値はどうしても減る
 補うだけの勉強を「常に」にしていれば別だが、少数派

 社会的コストの増大
– 社会インフラの維持コストの問題
 公共事業で景気維持というスタイルの後遺症
 ランニングコストまで考えてないので、結果の辻褄があってない

– 全体のパイの縮小均衡
 人口減
 売上の減少->よって利益フォーカスの操業
 コスト削減の圧力


さて現在の社会状況~個人（特に20-30代）
 年金問題
– もはやスキームとして成立しない
– 払っても戻ってこない
– 後だしじゃんけんで何が悪いという居直りのおじさん軍団
 「俺たちの世代が一番ワリを食ったという意識」は強い
 被害者意識層は遠慮しません

 消費税の増額
– 5% -> 8% -> 10%
– どんどん逝きます。直接税が減額されないので、実施所得減少

 要するに実質所得は（体感的に）減少する
– 都内で一家を構えて、嫁さん＋子供と食わすには
– 額面年収1000万＋貯蓄5000万はないと厳しい


んで、SIの現状をマクロから
 産業別人口 ~最近話題のIPAの調査結果 (これはIT全般の資料）
– http://www.ipa.go.jp/jinzai/jigyou/docs/global-report_01.pdf
 （このp21の「2）IT人材の動向：IT サービス企業、及びユーザー企業内のIT
関連業務就労者数」を参考）
– ITサービス技術者数だけであれば、日本はほぼ米国と同等

 そして、お給料様の現状ですよ・・
 （おなじくこのp23「2）IT人材の動向：IT技術者給与比較」を参考）

– 平均給与はほぼ米国の半分。アイルランド・デンマーク・フィンランド
以下

 （一部で購買力平価の考えが足りないという指摘等もあったので、
ま、それはそうだなとも思います、全文みた上で、各自判断してく
ださい。）


つまりどういう事かというと・・・
 日本のIT業界は
– 例えば、米国に比べて
– または他の国々と比べても

 まず「人が多過ぎる」

 つぎに「給料が安い」

人が多すぎて、
給料が安い

というわけで、ここで良く言われる格言
 「プログラマーの生産性は、低い人と高い人と比べると10倍以上の
開きがある、ということが良くある」
– 割と現実に見ることが多い。
– 例）
 3人x 3ヶ月で出来たSQLバッチ->激遅い
– そもそも実際の環境で走らせていないとか
– コードが酷いとか
 ベテランが一週間で書き直して、普通に動く

 ということで、よく言われること

「できるやつの給料をあげなさい」
– でないと携帯ゲーム屋にいっちゃうよ、という流れ


本当にそうなのか？
 まず、「プログラマーの生産性は、低い人と高い人と比べると10倍
以上の開きがある、ということが良くある」ということ

 IT業界で結構言われる

 他の業界で言われることは、実は少ない
– あっても３倍というケースが多い
 極めて例外的に10倍ということはある

– 普通はそんなに一人当たりの出力がズレたら商売にならない
– 「同じ労働集約的な産業においても、10倍も変わるということが日常茶
飯事である」ということはない

 「プログラマーの生産性は、低い人と高い人と比べると10倍以上の
開きがある、ということが良くある」ということがあること自体
が、まず異常だと思うべき。

なぜ10 倍の生産性がでるのか？
 能力が高いほど生産性があがる
– これは事実としてある
– できる人の設計・コードは、別格であり追随を許さないということはあ
る

 他方、そもそもばらつきが酷くないか？
– 参入障壁がない
– 受託が、人数で数合わせをしているビジネスモデル
 できなくても、チームに無理矢理組み込む

 優秀な人の生産性が高い、というよりも低い人が多すぎるのではな
いか？
– 設計とかコードとか普通におかしいだろということが、ままある
– 普通に５秒で気づくことに気がつかない


そこで、経営層は普通どう考えるか？
 「できるやつの給料をあげる前に、できないヤツの給料を下げる（または
上げない。または首を切る）」

 んでコイツは建前で、実態は・・・・
– 「できないヤツの給料を上げないついでに、できるやつの給料も適当に据え置
く」
– 現実問題として、人員が多い組織では人件費を上げるということは至難の業
– モチベーションは給与では上がらない、むしろ落ちる
 他人が給料あがったことのマイナスは、自分の給料があがったことでは補えない
 つまりあげるなら、一斉に上げるということが必要
 そんなことやると即死する会社が多い

 つまり「人が多く、給料が安い」＋「能力のばらつきがヒドイ」＝まず
当面の対策としては、人件費の据え置きに走る→恒久化する


そこで、ITのあり方について
 SI自体が成り立たないという現実
– 「人が多すぎて、給与が安い」
– しかし、人力での大規模SIに頼る現実

– 若年層人口の減少
– 社会的なコストの増大
– 一般に労働集約的産業の行き詰まり

 かつ、前述の「特に人件費の扱い」を考えると、一人当たりの賃金
が上がる要素はゼロに近い。

– 特に大規模SIを商売にしているところは、そうなってしまう
– これは経営層の資質という問題ではない
– そうせざる得ないという現実もある


SIの現実
 SI屋
– 単純な売上増を安易なSIで稼ごうとする経営スタイル
 一度こちらに振ると脱却が難しい
– 特に上場会社で右肩成長圧力があるところに顕著

 ユーザー層
– ITのリソースを外部から調達すればよいというユーザー層の考え方
 人は外からとればよい、という考え方
– 特にITは本業ではない、と公言するユーザー様に顕著

 この「需要と供給」というパーフェクトな図式のなかで成立してきた
SI事業は当然の背景として、明確な「市場としてのビジョン」は皆
無。

– 需要者と供給者で、市場を維持しようというモチベーションが薄い
– IT業界特有の問題
– 結果として成立しているだけ
– 要するに「なくなるときは、簡単になくなる」という言っています。

業務系SEの現実
 認識すべき背景
– SIがマーケットとして非常に厳しい
– 企業環境として給与は上がり辛い
– 年金・消費税で実質所得は間違いなく下がる

 なので、どうすべきか？という問題を真剣に考えるべきである。
– 考えるべきこと
 マーケットがどう変化するか？
 変化するマーケットにどう自分自身をビッドするのか？
 賭けるチップ（自分の能力）は手元にあるか？

– この辺を間違えて、ビッドすると大負けする
 例）安易なゲーム会社への転職とか


マーケットがどう変化するのか？
 まずSIビジネスが縮小していく
– 縮小とゼロになる、ということは違う
– ゼロにはならない
– 縮小して、どうバランスさせるのか？という問題

 中規模・小規模SIの増加
– 投資余力の減少から規模の縮小が始まる

 SI自体の数の減少
– 先送り案件が増える
– 投資自体がシュリンクする
– 運用や追加補修の増加


変化するマーケットにどうビッドするのか？
 少ない人員で回せる仕組みが必要になる
– とはいえ、5人とか10人とかそういった話ではない
– 100人月→70人月
– 50人月→20人月
– こういったサイズの縮小が増える
– 「アジャイルには大きすぎる」

 ある程度マルチでできることが必要になる
– 能力のある人間が1.5役ぐらいをやっていく感じになる
– 単一能力ではなく、複数の領域でのノウハウが必要

 業務系のニッチな仕事はむしろ増える
– SI屋を抜きに直接発注が来ることも増える
– 間違って拡大するとすぐに死ぬ


手持ちのチップは十分か？
 手持ちの武器は何が必要か？
– 「カードは多ければ多いほどよい」
– 最強のカードは、複数の「最強−１」のカードには勝てない
– 最強のカードになるにはかなりコストはかかるが、最強-1であれば実は
真面目にやればいけてしまう。

 スーパースターになる必要はない
– 設計
– アーキテクチャ
– アプリ
– インフラ
– 運用
– 基礎技術
– 業務系ノウハウ
– 「どこか複数の領域で、ほぼ万全（完全ではない）な状態」が望ましい


エンジニアとしてのキャリア・パス
 単一の道で最強をめざす
– おすすめしない
– 日本で最強はない
 日本で最強だと、ガラパゴスな感じで勢力争いになる

 複数の道で最強-1をめざす
– おすすめする
– 90点を100点にするのではなく、 30点を90点にする
– 「50点では妥協しないが、100点は目指さない」

 それ以外
– 「別の業界への転職をお勧めします」
– おすすめは・・・
 考えたけど特に思い浮かばない感じ


経験知として
 そもそもITの流れを理解しておくこと
– 歴史は繰り返している
 汎用機→オープン化→クラウド

– その都度車輪の作り直しになっている
 特にミドル系

– 車輪の作り方を知っておく必要はある
 実際に作るべきかどうか？というときには必ず再考すること

– 「流行に飲まれるな」
 HTML5、Hadoop、関数型
 一回退いた上で、自分なりに咀嚼してから「目的をもって」取り組むこと


何もしないとどうなるか
 まず実質所得は下がる
– これは決定的
– しかも、あと5年後に確定

 SIビジネスは縮小する
– 予算がないので、スケジュールが短縮され、デスマが増える
– 「政治ができない」順に仕事がなくなる
 技術とは関係ない

 つまりモチベーションとか、生きがいとか、そういった精神的な充
実の以前に、そもそも食べていくことが辛くなる
– 正直、消費税は想像以上にきついですよ。
– 税金には消費税はかからないので、手取りがさっくり減る計算に近い


いままで何が違うのか？
 座っていても大丈夫という時代が「本当に」なくなりつつある
– 大企業でも倒産や合併という憂き目にあう

 SNS等のつながりで、情報の流れが速い
– 選択肢の幅が広がる
– また逆に、競争が激しくなる

 企業の壁が薄くなる
– 個人を守ってくれない
– 自力救済

 「勉強するモチベーション」と「自分の能力をどう評価するのか」
ということが、非常に重要になる


つまり
夢も希望もない
わけよ。
自分で作らない

何をカードにしておくか
 設計
 アーキテクチャ
 アプリ
 インフラ
 運用
 基礎技術
 業務系ノウハウ


 設計
– 「普通の設計」ができるようにしておく
 特定の要素技術に依存しない
 画面設計・データモデル設計・フロー設計・・・

– 例外処理を拾えること
 やり過ぎると死ぬ
 やらなくても死ぬ
 程度を押さえる

– 設計時点でパフォーマンスボトルネックを想定する
 どこが詰まるのか、想定しておく

– 「適度に行う」という適度感を身につける


 アーキテクチャ
– すべての基本はIO
 各物理階層をちゃんと理解する
 限界を理解する
 パフォーマンスはアーキテクチャで決定される

– 障害設計から考える
 トラブル中心で考える

– 「何が何をするのか」がわかるようにしておく
 過度に複雑なってはいけない
 「フレームワークの役割」の理解


 アプリ
– 基本はプロジェクトマネージメント
 普通にWFができること
 WBS・課題管理・・・・

– 要素技術の共通点を押さえる
 制御構文
 ライブラリーのあり方

– 書きすぎないこと
 「作らない技術」を持つこと
 少ない人数でどうするのか？
 手をどう放すか、ということも常に意識すること


 インフラ
– とにかく情報収集
 ただし、枝葉末節にこだわらない
 仕様は変わる
 マニュアルも変わる

– ネットワークの基礎技術は押さえること
 物理階層
 プロトコル
 設計
 障害
 パフォーマンス
 上には上がいるが、最低限というものはある。

– ハードはいろんなものが出てくるが、最後はIO
 パフォーマンス
 障害


 運用（継続開発）
– 設計が命
 運用設計は絶対一度は経験すること
 今まで「見えなかったもの」が見える

– 継続的なインテグレーションのマスター
 システムは使われてなんぼ
 生きているシステムは、変更される～どんどん変わる
 割と常識になっているので、マスターすること

– コスト意識をもつこと
 運用コストは馬鹿にならない


 基礎技術
– 以下の基礎は「絶対にマスター」しておくこと

– 「計算」についての基本知識
 計算量
 確率統計
– 高校生～大学学部程度で十分
 計算とはなにか

– 「品質」についての基本知識
 品質は作り込むもの
 手法は様々だが、完璧なものはない

– 「論文が読めるようになっておくこと」
 我々は巨人に肩に乗るべき
 TX・分散・並列・・・・


 業務系ノウハウ
– 1.「考える」
 なぜ、こういう仕組みになっているのか？
 書籍を読む・基礎知識を積む
– 例）会計処理 → 一応簿記ぐらい知っとく
– 例）最適化 → ORぐらい知っとく

– 2.「聞く」
 なぜなのか？聞いて聞いて聞きまくる
 いやがられるけど、めげない

– 3.「応用する」
 大事なのは、個々の仕様ではない
 「考え方」を学ぶこと
 「考え方」を常識にとらわれずに転用すること
– 転用することで、オリジナルへの理解が深まる


業務系SEの今後について

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (10)

Destacado

Destacado (9)

Similar a 業務系SEの今後について

Similar a 業務系SEの今後について (20)

業務系SEの今後について