Hatena::ブログ(Diary)

zyake_mk2の日記

2014-05-18

SIerの問題点

世間一般では、SIerは非効率、プログラマのスキルが酷い、ガラパゴス化している等、評判が悪く袋叩きにあっているようです。実際にはグローバル水準で戦える高スキル者はいるし、特に某親会社の人達はみな頭の回転が速いし、志が高いです。

一方で私の5年そこそこの短い経験の中でも、世間の評判通り、開発現場の信じられないような体たらくっぷりをたくさん見てきました。すごく立派な看板の裏でのしょぼい設計実装、ミス等 etc...
(私も人のことを言えないですが・・・)

そこで、私の見える範囲の世界で、どうしてこのような現状なのか考えてみました。
(私の見える範囲なので、他社だと全く状況は違うだろうし、他者には違った世界が見えているかもしれません。)

SIerの問題点


1. 技術力向上のインセンティブが少ない
恐らく最大の原因はこれではないかと思います。要するに、必死に技術力を磨くインセンティブが乏しいのです。例えば、私のグループでは、それぞれのメンバの時間給が示されますが、桁が違うくらい高スキルな人と、他人の手助けが必要なぺーぺーの新人でも、せいぜい1.x倍にしかなりません。スキルを磨いてすごい能力を持っていても、まるで対数関数の極限に近づくように、たいして単金があがりません。(もちろん、「セット価格」ということもあると思いますが・・・)

そうすると、必死にスキルを磨いて、スムーズに仕事を進めるよりも、「土方仕事でも良いから、BPをいっぱい引き連れていけ(技術よりマネージメントのほうが稼げる)」となるし、(実際にやってることはしょぼくても)、炎上プロジェクトで土日出勤を繰り返したほうが金を稼げてしまいます。また、単金交渉も難しく、たかだか数%の単金を上げるだけでも大騒ぎです。(さすがに名前で一本引きされるくらい突出すると、価格交渉ができるかもしれませんが・・・。)

もちろん、人の評価に恐らく正解はないし、「○○倍の能力」なんて定量的に測れませんが、ソフトウェア開発の仕事は専門的で極めて難しく、現実に品質、生産性に比較にならない差が出ます。そこをもう少し評価して、単金の下限と上限のメリハリがあっても良いではないかなぁと素朴に思います。

また、これも日本的ですが「雇用制度が硬直的=似たような人たちで、看板を変えながら似たようなことを繰り返す、タコツボ化の促進」という問題もあり、「スキル磨いてすごい成果物を出すよりも、有力な○○さんと仲良くなって、仕事してるふりをする」方が、なぜか評価されたりします。実際には、まともに一人で仕事ができなくても、です。
(もちろん、まわりの人はみんないらいらしてるのですが、スキルを定量的に測るすべはなく、見かねた周りがどうにかするので、そのままです。)

実際に私が某プロジェクトに参画したときにリーダーに「守ってあげるからね」と言われましたが、私はこの言葉に非常に頭にきました。小学校の仲良しクラブじゃあるまいし、その人の成果物、貢献度等で外すかどうかは判断すべきで、それ以上でも、それ以下でもないはずです。「だれでも平等にチャンスを与える」というのと「私情、恩情」は違います。
(余談ですが、「失敗の本質」という書籍を読みましたが、この国は何十年も前から、本質的なところは何も変わっていないようです・・・。たぶん、数百年単位で培われてきた日本人の基本的な性質なのでは。)

2. ソフトウェア開発の技術力に対するコモンセンスがない
「1.」と密接に結びついていると思いますが、「ソフトウェア開発の技術力」という言葉に対するコモンセンスがないというのも、大きな問題です。要するに「なんだかわからないので評価できない」のです。単金が対数関数的にしか上がらないのも、スキルレベルの差により、生産性、品質が桁違いに変わるという現実がわからないので、考えるのを放棄しているではないかと疑っています。

私の場合は、たまたま上司や先輩が天然記念物みたいな人で、ソフトウェアの技術(デザインパターンアーキテクチャパターン等のOOP、並行処理、RDBMSアーキテクチャ、複雑なソフトウェアの設計 etc...)に強く、がっつり教え込まれて、怪しい仕事ばかり任せられたのでそういう方向に進んでしまいました。もちろん、文法やAPI、フレームワーク、ツールの使い方を知っているのも重要ですが、ソフトウェア開発における技術力は、アーキテクチャや思考法、設計手法等がどれだけ身についているかが重要であって、どんな道具をかついでいるかは、そこまで重要ではないはずです。
(コンテキストごとに、最適なものを選ぶだけ。)

このような「ソフトウェア開発の技術力」に対するコモンセンスがないので、「頻繁に更新されるカラムにインデックスを張って性能劣化で大騒動」とか、「よくわからないから、とりあえずsynchronizedしちゃおう」、「保守性も責務の分割もあったものでないクラス設計」等の目を疑いたくなるような成果物が淘汰されないのだと思います。別に難しいことをやる必要はなく、「当たり前のことを当たり前にやる」ことが重要なのでは・・・。

謎の資格信仰も、恐らくコモンセンスがないことが原因で、とりあえず国家資格かベンダーの資格と取らせてお墨付きを得ようということなのでしょう。
(余談ですが、某社のP-CDPは、テスト勉強のしようがなく、極めて実践的だと思いました。)

3. 基本的に外注である
これも、「1.」「2.」と密接に関わっています。基本的に外注なので、人を選べないのです。もちろん、「チェンジで!」もないわけではないですが、会社間の関係もあるし、次の人が都合よく捕まるわけもなく、現実に目の前に仕事があるので、結局、「いる人に合わせる」やり方をせざるを得ません。もちろん、「低い方」にです。
しかも、私も生粋の日本人なので、あんまりはっきりものを言えず、他メンバとの関係を悪くしないように、うまく取り繕いながら仕事を進めざる負えなくなります。

外注なのは、ノウハウの蓄積、共有の上でも大きな障害となっています。それぞれのプロジェクトに数人ずつで常駐し、数か月に一回、打ち合わせで集合する感じなので、やる気のある人は勝手に伸びますが、そうでない人はいつまでも放置で一向に改善されませんし、優秀者ほど打ち合わせに参加できないのが常なので、ますます情報共有の場がなくなっていきます。
(そのことに気づいた私は、最近、メールでノウハウをやり取りするようにしています。これなら遠隔地にいても情報共有できます。)

4. プロセス重視である
とにかくプロセス重視です、何が何でも。もちろん、開発プロセスは必要ですし、無茶苦茶なカウボーイプログラミングを称賛するわけではないですが、手段が目的化しており、膨大なコストをかける割には、だれもうれしくないことが間々あります。しかも、それが「プロセス通り仕事を進めている」と称賛される傾向さえあります。
たぶん、責任を負いたくない、不確実性が怖いということなのでしょうが、顧客不在の自己保身的な仕事で、生産性も何もあったものではないです。

どうしてこうなのか?


私が思うには、前述したすべての問題の原因は、「雇用の流動性が低い」という一点に帰着するのではないでしょうか。
雇用の流動性が低いので、外注せざるを得ません。外注のリスクを減らすために、プロセスを徹底的に重視し、不確実性をつぶす方向に動きます。縛れば縛るほど自由度がなるし、外注はコスト競争が激しくなるので、単金の上げ幅が少なくなります。それでも仕事はあるので、技術力向上のインセンティブはなかなか働かないです。

これがもっと雇用の流動性が高く、弱肉強食の戦場のような業界ならば、淘汰圧力が働くので、しょぼいスキルの人は生き残れないはずです。
(そんな人に仕事は回ってこない、切られるだけ。)

もっとも、現実はもっと複雑だろうし(たぶん、そこまで技術は関係ない)、SIerでも、ちゃんとしたスキルを持った人はいっぱいいるので、そうとう偏ったものの見方ではあると思います。

どうすればよいのか?


できる範囲で、もっと競争を促進すべきではないでしょうか。
恩情主義ではなく、成果、貢献度主義にする。例えば、最近流行りのチケット駆動などを厳密に適用し、生産性、貢献度を見える化する。能力のランク分け、単金等にもっとメリハリをつける etc...

成果物、貢献度の競争が激しければ、ツールやフレームワークも、効率の良い新しいものを使わざるを得ないし、設計ミスや問題点が誰の責任か問われるようになれば、みんな勉強せざるを得なくなるはずです。
(責任も取れないのに、設計するなという気もします・・・。)

もっとも、現実には難しいだろうし、このままだらだら続くのかも・・・。

最後に


以上、長々と書いていきましたが、周りを変えられなくとも、せめて私一人だけでもスキルを磨いて、改善していけたらなぁと思ってます。
いろんなことを言う人がいますが、最後は立場や経歴等ではなく、「あなたが今、できることな何ですか。」と問われるだけのはずなので・・・。

kiya2015kiya2015 2014/05/20 12:51 どうしてそこで結論がネオリベになるのか理解に苦しむ

sakurai_youheisakurai_youhei 2014/05/20 18:37 日本人は「何をどうすべきか」に答えを出そうとよく考えるけども、「誰が」と「何のために」が欠落する傾向にあると感じる。結果、欠落した部分を省略かつ一般化して、「ドキュメントは必ず作成すべき!」となる。そうすれば「私が今までそうしてきてこれからも同じようにしていくために」とか「客先が納得するために」とか「チームが変わっても記録を残すために」とか色々とバリエーションが。。。副作用もコスト対効果も「誰が」と「何のために」がないと測れないのに。

zyake_mk2zyake_mk2 2014/05/20 21:32 >kiya2015さん
単純に雇用の流動性が高ければよいというわけでもないと思いますが、
現状の技術力、生産性が素直に単金に反映されない(少なくとも私の)環境では、
技術力、非効率性を是正するのは難しいと思います。

>sakurai_youheiさん
結果でなくて意気込みが評価されやすいとか、自己否定ができないとか、昔から言われているらしいですね。そのあたりをまじめに考えたら、自分の過去の仕事、やり方を否定することにつながりかねないですし。

athensathens 2014/05/21 02:50 読ませていただきましたが、私の経験からも似たような知見を得ることができ、労働市場の流動化の点も含めて全面的に同意します。

政府機関の公表している数字では、
日本で全IT技術者と外注請負業者所属のIT技術者の比率は75%(25%がユーザー系)、米国では28%(72%がユーザー系)

米国・日本との技術者の給料の格差は熟練技術者なると倍以上となります。米国ではシニアソフトウェア技術者の「平均」年収は1100万ほどで、日本では540万と名目上はそうなりますが、実は米国でのシニアソフトウェア技術者とはプログラマーを指しているので、日本では390万円程度の平均年収にとどまります。

まさに米国では知識集約型の産業の花形であるIT産業は、日本では古典的な労働集約産業になっています。

こうした産業構造では仕事ができて頭のよい人間は最終的に、労働集約カーストの上にいこうとしますので、どんどん現場から離れていきます。優秀でも技術がそれでも好きな場合は外資ユーザー系などに転職することになり、ますます人材難になるという悪循環です。

>いろんなことを言う人がいますが、最後は立場や経歴等ではなく、「あなたが今、できることな何ですか。」と問われるだけのはずなので・・・。

ハードワークをした人間は報われるはずです。あなたの過去ログをみた限りでは、仮に流動化が実現した場合は、今までの苦労は決して無駄にはならないでしょう。

SASA 2014/05/21 23:54 誰に向けて書いているのでしょうか…同業者ですか?
違うのなら、伝え方が下手だと思います。

zyake_mk2zyake_mk2 2014/05/31 18:30 >athensさん
海外だと、高給取りなのですね・・・。
悪循環というのは、確かにその通りかと思います。
私の周りを見る限りでは、ごく一部の突出した人 + その他大勢という構成なので、
「どれだけ高度なスキルを発揮するか」よりも「どれだけ仕事を単純作業に噛み砕いて丸められるか」が重視される傾向があるように感じます。
(高スキル者は単なる変人扱い)

>SAさん
特に読者を意識しているわけでなく、チラシの裏のつもりで、衝動的に書いただけです。
おっしゃるように、伝え方が下手なのは同意します・・・。

なまえをなまえを 2015/11/02 00:30 流動性が高くなったら、いつメンバーが入れ替わるかわからないから
必ずドキュメントつくってプロセスもガチガチに固めておこう
ということになるかもよ。

pqpq 2015/12/29 12:30 自分も流動性の低さが問題だと感じていました。おそらく一番の問題でしょう。
流動性の低い職場はなにもかも淀んでしまいます。
入れ替わりを心配する人もいますが、評価され認められて雇われると責任感も高くなると思います。
引き抜くにしても雇う側はちゃんと後始末までできる人かどうかも見て判断すると思うからです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/zyake_mk2/20140518/1400418070