SIerの問題点

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

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

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

SIerの問題点

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

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

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

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

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

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

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

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

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

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

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

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

どうしてこうなのか?

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

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

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

どうすればよいのか?

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

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

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

最後に

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