狠狠撸

业务系厂贰の今后について
消費税増税と年金問題が与える影響

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万はないと厳しい


んで、厂滨の现状をマクロから
? 産業別人口 ~最近話題の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 倍の生産性がでるのか？
? 能力が高いほど生産性があがる
– これは事実としてある
– できる人の設計?コードは、別格であり追随を許さないということはあ
る

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

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


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

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

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


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

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

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

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


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

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

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

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

业务系厂贰の现実
? 認識すべき背景
– 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.「応用する」
? 大事なのは、個々の仕様ではない
? 「考え方」を学ぶこと
? 「考え方」を常識にとらわれずに転用すること
– 転用することで、オリジナルへの理解が深まる


狠狠撸

业务系厂贰の今后について

Recommended

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to 业务系厂贰の今后について (20)

业务系厂贰の今后について