2012/10/09に開催された『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』のノートです。
SIをやっている人には是非読んでほしいです。私のノート作成スキルを
※(2012/10/10追記)上の文について、言葉の選び方が不適切だったので修正致しました。「私の資料作成能力の限界で、okachimachiorz1様の伝えたいことの半分も伝わっていないかもしれない。だけど、それでも読む価値がある内容です」ということが、上の文で私が言いたかったことです。申し訳ないです。
◆今日の勉強会について
◇今日の構成
・最初にokachimachiorz1様の話を40分くらい
・その後休憩を挟んで来ている人達で感想、深く聞きたいということを皆で話合う
・Q&A
◇この回をやろうと思った経緯
・okachimachiorz1様のブログを一生懸命呼んでいるうち、その内容が自分の仕事の話になっていた
・自分が危機感を持てる内容になっていた
・そういう文を書く人の話を聞きたいと思ってお願いした
◆本編
◇はじめに
・どちらかというとAsakusaやHadoopの人
・SIの話ははじめて
◇自己紹介
・元々はITの人ではない
・ハゲタカファンドの人だった
→バブル崩壊後、日本が買い叩かれたときに買い叩く側の仕事をした
・次に上場している流通企業でCIO, CTOをやった
→ユーザ企業のインハウス
・その後ウルシステムズ
→コンサル・SIでは食べられないので業務系のミドルウェアを作って売っていた
・キャリアとしてはマネジメントの方が長い
→働いている人の給与・コストを考えざるを得ない立場である
→自分も手は動かしているが、どこでも人件費の問題に突き当たる
◇エンジニアのキャリアは難しい
・前の会社では優秀なSEをコンサルにしていた
→前の会社にはエンドとしてのエンジニアのキャリアがないということ
→→NAUTILUSの設立にはエンジニアのエンドのことも考えている
◇日本の現状
・年寄りが増える
→勉強していくことが必要だがそういう人も少ない
→年を取るとアウトプットが減っていく（手を抜かないと体が持たない）
・社会的コストが増大する
→公共事業で景気維持というスタイルを20年続けている
→公共事業には立法が必要。単年度単位で行う
→→2～3年後のことは誰も考えない（ランニングのコストは考慮されない）
・結果とつじつまが合わない
→ランニングのコストが考慮されていない社会インフラ（情報システム）が残り続ける
→橋などは壊れるが社会インフラ（情報システム）は壊れない
・人口が減る
→総生産が減るので売り上げが減る
→→利益の確保に走る
→→コスト削減
・これらが社会全体の流れ
◇年金問題
・スキームとして成立していない
→払っても戻ってこない
→若者には遠慮しない
・消費税の増税
→5%には直間比率を変えるという名目が合った
→8%, 10%の増税にはそれがない
→所得がそのまま減少する
・「都内で一家を構えて、嫁さんと子供を食べさせるには …額面年収1000万＋貯蓄5000万ないと厳しい」
◇ITサービス産業について
・ユーザ企業におけるITエンジニアの就業人口について
→米国は他国と比べて圧倒的に多い
→日本はベトナムやロシアと比べると多い
・しかし給与は相対的に低い
→IT業界は人が多すぎ
→IT業界は給与が安い
→→これが世界と比較した場合の現状
◇プログラマの生産性は低い人と高い人で10倍以上違うという
・これは本当だと思っている。実際にある
→だからできる奴の給与をあげろ、と言われる
→そうしないと携帯ゲーム業界に行ってしまう
◇本当にそんなに生産性が違うのか？
・他の業界ではそう言われない
→会計士
→流通
→→SIと同じ労働集約型の産業
→→あっても生産性の差は3倍くらい
→→→そんなに差はない
・そもそも労働集約産業で10倍もずれたら商売にならない
→これは異常
→でもIT業界では散見されている
→→COBOLでは10倍もなかった
→→そして今はもっと開いている
◇なぜそんな差が？
・能力が高い = 生産性が高いのは事実
→できる人の設計やコードは別格
・そもそもばらつきが酷い
→言葉がでないくらい
→→それは参入障壁がないから
→→その辺の人を連れてきて書かせたりすることが普通にある
→→「なんでこんな人連れてきたの？」「10人月で計算しているんで…」
・優秀な人の生産性が高いというより低い人が多すぎるのでは？
→「これはないよね」という（酷い）コードを見たことがない人はこの中にはいないと思う
→→差が非常に激しい
◇これはよろしくない
・いい人の足を引っ張ると言う話ではない
◇では、この状態を経営者層はどう考えるか？
・経営者層はできる奴の給与を上げたりはしない
・経営者層はできない奴に合わせる
→下の給与を下げるか首を切る
→できる奴の給与も適当に据え置く
→→人間の給与はモチベーションでは上がらない。むしろ劣る
→→ライバルが上がるとモチベーションが落ちるが、自分が上がってもこの程度か…としか思わない
→→マネジメントは一斉に上げるしかない
→→→できない奴を入れると全体が上がらなくなるということ
◇SIは基本的には成り立たない
・人が多すぎて給与が安い
→人力の大規模SIに頼る現実はなかなかなくならない
・だが若年層人口が減っている
→労働集約的産業は行き詰っている
・人件費の扱いを考える
→一人当たりの賃金が上がる要素はゼロに近い
→経営者はできるSEの給与を上げたいと思っている
→でもできない。現実にはそうせざるを得ない
→→大規模SIを商売にしているところはそうなってしまう
・NAUTILUSが小規模なのは給与を上げやすいから
→積極的にそういう選択をせざるを得ない時代になっている
◇SIの現実。マーケットの現状
・単純な売り上げ増をSIで稼ごうとする
→一度こちらに振ると脱却が難しい
→特に上場会社
→→右肩上がりの成長圧力がある会社で顕著
・ユーザ層は内製したいというが…
→結局は丸投げ
→→ITは彼らの本業ではない
→→外部から調達すればよいという考えがある
→だからといって無くてよいわけではない
→→だが、そういった社内の声があっても実際には入れられない
→→ITは間接部門なので真っ先に切られる立場
・需要と供給がこの中途半端な状態で成立している
→どちらもお互いのことを考えてない
→市場をよくしようというモチベーションが薄い
→お互いのビジネスモデルを理解していない
→→結果として成立しているだけ
→→この市場は、なくなるときには簡単になくなる
・マーケットを維持しようとするインセンティブなプレイヤーにない
→崩れても持ち直そうとする人がいない
・かなり厳しい
◇参入障壁を上げて、できる人でやろうとすればよかった
・でも、人でスケールアウトするモデルをとってしまった
→にっちもさっちもいかなくなった
・どうすべきか真剣に考えないといけない
→SIが行き詰った後どうするのか？
→そのとき何をかけるか？
→そもそもかけるものがあるか？
→手持ちの札をどうふやすか？
・↑がSI系のエンジニアには必要になってくる
◇私は何をやったか？
・いいエンジニアの受け皿を作ろうと思った
→こういう会社がもっとできるべきだと思っている
◇マーケットはどう変化していくか？
・"SIは終わコン"という説がある
→同意する
→だが0にはならない
→現状は覆らない
→だが縮小する
・単純な投資の先送り
→中規模・小規模SIの増加
→→投資余力の減少から規模の縮小が始まる
→見積もりをミスると赤字がどんとでる
→市場だけで決めてしまうので不経済が発生している
・先送り案件が増えると
→投資自体がシュリンクする
・運用や追加補修の増加
◇少ない人数でどう回すかを真剣に考えるべき
・100人月を80人月でとか
→アジャイルは答えではない
→どうムダなくやるかをユーザと話をして、説得できないといけない
→→ミスなく効率よくできないと駄目
→そのためには個々人のレベルが高くないと駄目
→→1人1.5役くらいやらないと厳しい
◇私が関わったプロジェクトの9割は失敗していた
・でも、できるPMが複数入ってサポートすると成功する
・エラーを摘出して修正するスピードが速いプロジェクト
→そういうのはリスク管理ができる
→excelの表に書いてリスク管理とか本当に意味ない
→報告書を書けばリスク挙がってくるの？
・実質的なリスク管理は1人ではできない
→その人よりレベルが高い人が見ないと分からない
→そういう人が見て気付くだけでも全然違う
→→だから、皆でやって壁に貼ってというアジャイルのスタイルは良い
◇業務系のニッチな仕事が増える
・ユーザが丸投げできなくなっていく
→仕事を切り分けて出すようになる
・ちょっと間違えると大変なことになる
・流通は死亡率が高い
→一見簡単に見える
→でもそのとおりやっても業務は回らない
→→それは例外処理の塊だから
→→その取り決めのルールが非常に多い
・知らずに入ると大変なことになる
→業務知識が必要になる
→エンタープライズの例外系を知っている人がいないと厳しい
→→厳しいけど、そこできっちり回るならエキサイティングで楽しい仕事ができる
◇手持ちのチップは充分か？何が必要か？
・1枚の最強のカードは「複数の"最強-1"のカード」には勝てない
→最強のカードには沢山のコストがかかるが、"最強-1"は実は真面目にやればいける。
→最強の手前を目指す
→スーパースターになる必要はないが、複数の組み合わせでいけば強い
◇チップ
・この中で複数あったら強い
→設計
→アーキテクチャ
→アプリ
→インフラ
→運用
→基礎技術
→業務系ノウハウ
・そういう人がいたら欲しいでしょ？
◇エンジニアとしてのキャリアパス
・日本だけで最強を目指しても仕方がない
→それはガラパゴスになってしまう
・90点を100点にするのではなく、30点を90点にする
→50点では妥協しないが、100点は目指さない
・それができなかったら？
→給与も上がらないし、SIの現状がこんなもの
→→転職したほうがよい
◇経験知として
・歴史は繰り返す
→汎用機->オープン->クラウド
・繰り返すたび、車輪の作り直しになる
→作り直す必要はあるか？
→でも作り方は知っておいた方がよい
→知らなくて作るのは最悪
・流行に飲まれるな
→Hadoop. HTML5, 関数型…
→1回退いた上で自分なりに咀嚼し、「目的を持って」取り組むこと
→何のために必要？ 何のために使う？
◇何もしないとどうなるか
・実質的所得が下がる
→税率とかで
→これは決定的
・SIビジネスが縮小する
→「モチベーションが上がらない」とか言ってられなくなる
→あと5年以内に、「食べていけるのか？」というレベルになる
→→消費税の5%は半端じゃない。手取りがざっくり減る
◇今までと何が違うのか
・座っていても大丈夫と言う時代が本当になくなりつつある
→大企業でも倒産や合併の憂き目にある
・SNSなどのつながりで情報の流れが早い
→自分の状況がわかる
→選択肢が広がる
→競争相手が日本全体になっている
→→今までは会社だったけど、そうではない
・企業の壁が薄くなっている
→個人を守れなくなっている
・個人は
→モチベーションをどうするか
→自分の能力をどう評価するのかが非常に重要になる
「自分で作らないと、夢も希望もない」
◆何をカードにするか
◇設計
・普通の設計ができるようにしておく
・画面・データモデル・バッチ
・正常系は馬鹿でもできる
・例外系が重要
→やりすぎるときりがない
→やらなくても死ぬ
→程度を抑える
・きちんとした設計なら設計時点でパフォーマンスがわかる
・適度にやる感覚を理解する
◇アーキテクチャ
・全ての基本はI/O
→どうすれば限界まで出せるか
→どこがボトルネックか？
・障害のことを考えていないI/Oが多い
→ここは性能とトレードオフになる
・今は（一般的に）複雑すぎる
→どこで何をしているかがわかるアーキテクチャが作れると強い
◇アプリ
・ただ書くだけではない
→wfで設計・実装・テストできる。こういう基本的なことが大事
→書く量をコントロールしないといけない
・みんな書きすぎる
→書かない技術を極めたほうがよい
→リファクタリングしている暇なんか普通はないよ？
→→最初から少なく書く
・コードから手をどう放すか、ということを常に意識する
◇インフラ
・とにかく情報収集
→すごい勢いで変わる
→仕様、マニュアルが変わる
・基礎技術を押さえる
→物理階層
→プロトコル
→設計
→障害
→パフォーマンス
→セキュリティ
・最後はI/O
→パフォーマンス
→対障害
→→追えるように
◇運用
・できると強い
→一度は経験すること
→今まで見えなかったものが見える
・継続的なインテグレーションのマスター
→システムは使われてなんぼ
→生きているシステムはどんどん変わる
・コスト意識を持つこと
→運用コストは馬鹿にならない
→分かると非常に強い
◇基礎技術
・計算は絶対
→計算量の計算ができないとか…
→確率・統計を知らないとか…
→→高校生～大学生レベルでいいので抑えておく
・品質
→昔よりは言われるようになっている
→品質 = テストではない
→→もっとトータルなもの
→出来上がるものではなく作りこむもの
→→「予見可能性が高いもの（どういう挙動か分かりやすいもの）」が品質が高いと考える
→→バグの量は関係ない。バグがあることが明確ならそれは品質が高い
・論文
→すらすらじゃなくても読めるようにしたほうがよい
→我々は巨人の肩に乗るべき
◇業務系
最終的にはエンドユーザには絶対に勝てない
でも（業務知識を）盗むことはできる
・考えることが大事
→なんでこういう仕様に？
→→何か理由がある
→前提の基礎知識は知っておく
→→会計なら簿記
→→最適化ならORとか
・聞く
→とにかく聞く
→捕まえて聞く
→→「こうなってるはずだと思うんですけど？」と聞くこと
→→「どうなってるんですか？」ではない
・応用する
→業務知識は仕様ではなく考え方。文化
→"アカウンティングのセンス"みたいなものがある
→→そのセンスがある人が見たときに、どう考えても直感的におかしいものとか
→→会計のマインドがあれば全員が分かる。「これは筋が悪い」
→そのセンスを何とかつかむ
→→なんでそうなっているかが分かるようにする
→その根底にある考え方を常識にとらわれず転用する
・これをやるだけでお客様の信頼が全く違う
・そうすれば、ヘルプで入っても見た瞬間に「これがおかしい」と分かる
◆質疑応答
Q.
非常に大きなユーザ企業の仕事は、少数精鋭の規模では請けられない場合があると思う。
そういうものを受けられるようにし、成長していくためにはどういうことをやっていけばいいのか？
A.
・原則からいくと受けないほうがよい
・少数精鋭がそういう仕事を受けに行くのは自殺行為になる
・どういう形態なら受けられるかということを話し合うべき
→ユーザが「そういう発注はできない」というなら受けない
・「大規模SIが成り立つか？」と言うこと自体をユーザが考えないといけない
→だってほとんどが失敗している
・大手ですら、ユーザからの内示が出た後に拒否するケースが出てきている
・そもそもユーザが大規模の案件を発注するのか？というのもある
→インクリメンタル
→パーティション
→サービス
で発注するとか
Q.
大手だからまっとうな経験が積めないわけではないし、そこでしかできないこともある。
でも、配属によってはまともな経験ができないことがあって、そういう人はSIが無くなると死んでしまう。
そういうことを考えたときに大企業の中にいる人は何をすべきなのか？
A.
・中でちゃんと提案すること
・喧嘩別れは簡単
・「このままでは具合が悪い」ということを、個人ではなく部の意見としてきちんと話をする
→1人の意見で話をもっていっても「お前が言っているだけ」で終わる
・部の意見なら、経営層も話合う力量がある
→話し合えないなら全員辞めればよい
Q.
「マクロで見たとき日本でSIやるのは厳しい」というのがここでのコンセンサスだと思う。
生き残りの作戦として、エンドユーザに入ってITを軸としたイノベーションを起こすというのはアリだと思うがどうか？
A.
・そうだと思う
・でも、ユーザサイドから見るとそういう人のモチベーションを維持するのは難しい
→ITの投資は景気が悪くなると真っ先に削られる
→努力が簡単に否定される
→→それでもモチベーションが維持できるか？という問題
→→→それでも頑張れるのであればエンドユーザに行くのはありだと思う
Q.
（上の質問の続き）現場上がりの人がCIO, CTOになっているような会社を探せばあるのではないか？
A.
・ユーザにはR&D部隊があるようなところにいけばあるのでは？
・でも「まずは現場に行け」という話になる
・ある例
→技術のある人間をまず現場に送った
→彼は棚卸しをさせられた
→結局2日で辞めてしまった
・中の人間とある程度コンタクトをとって、中の情報を取って行く
→オーナーやトップがきちんと見ているということがカルチャーとしてあるか。
→それから現場としてどうなっているか。
→→そういうことを調べてから行くならよいのでは？
Q.
アメリカはユーザ企業の比率が高いと言う話があった。
でも、それは解雇が簡単だから開発フェーズごとに人数が変えられるという話。
日本では、開発のフェーズごとに人数が変わるところをSIがバッファしているというのがある。
ここの問題を解決しないと、シュリンクするSI業界に人材が取り残されて給与だけが下がっていくと言う状態になるのでは？
A.
・USがインハウスであれだけ人を取れるのは人材の流動性が高いから
・では日本ではどうなるか？
→別の業務をさせる（製造業なら現場とか）
・ただ、IT系で優秀な人は違ってくる
→会計・流通と比べてIT系で違うのは、どこでもプロジェクトマネジメントをやっているということ
→ユーザは驚くほど線を引かない
→→それをやるだけでもかなりプラスになる
→IT企業にはそれがあるが、それをユーザに提供していないのが現状
→ITできちんとやれる人は企画系（スタッフ）なら力を発揮できる
→→きちんとしたマネジメントならそう考える
・でもそういう枠が沢山あるわけではない
Q.
SIがシュリンクしたときに取り残されたユーザも困る。そのときのユーザの出口は？
SIが倒産したときにユーザはどうすればよいのか？
A.
・エンドユーザがそういうときどうするか？
→引き抜きにかかる
→人ごと受ける
・それは今まで払ってこなかったコスト
→「これだけかかる」「もうどうにもならない」ということを社長に話す
・こういうときに外部不経済が発生してしまう
・『基幹系で先遅りしてベンダとべったり』だと、それが原因で倒産することもありえる
・お互い打つ手なしと言う感じ
Q.
そもそも情報工学に人気がなく、内定がない人がSIに入ってきている。
SIとして質を上げるためには何をすればよいか？
A.
・まずはそういう人を取らない
・きちんとテストをやるとか
→三角形のテストとか、だいたい書けない
→→書ける人からとっていけばよい
・論理的に考えられ、日本語が書けて、でたらめでないコードが書ける
→それでよい
→後は2年間教育に放り込めばなんとかなる
・テストして適当な人がいなければ取るべきではない
Q.
ユーザ自体にお金がない。でもシステムを構築したい。
こういう場合、結果的にダンピングされる。
ユーザ「来年の予算は決まりました」
会社「受ければこれだけの利益になります。だからやれ」
で、いくつかのプロジェクトで赤字になったりして会社からいろいろ言われる。
どうすれば？
A.
・やるべきではない
→お金がないけどやってくれというのをやるのがそもそもの問題
→上が「やれ」というなら「赤になるぞ」ということをきちんと言わないといけない
・赤字は赤字
→自分の手足を食べているというだけの話
→それを下に投げている時点で経営層失格
・お客様との付き合いとして取らないといけない場合
→それは投資
→どこで回収するかをきちんと決めてもらわないといけない
・赤字だからダンピングでも受けてしまう
→そうやってきたのがSIがこうなっている原因でもある
・「赤字になってどうするかを考えるのは自分の仕事ではない。俺はその分の給与を貰っていない」と言ってよい
okachimachiorz1様, DevLove様, 日本マイクロソフト様、ありがとうございました。
0 件のコメント:
コメントを投稿