知っているSIerとは違う

type.jp

 

SIerにも様々な業態があるから、おっしゃるとおりの(まるでITProから引用してきたような典型的なSIerと思った)Sierもあるだろう。ただ、そうでないSIerもある。

 

他社にものを納品するビジネスモデルの会社は、同じような企業がたくさんある中での競争になるから、その競争に勝つためにはどうしたってコストを削減せざるを得ない。コストを削減すれば、当然給料も安くなる。それをしなければ競争に負けて潰れるだけ。

 

だから、かもしれないが納品をしない受託開発を行なっている会社(ベンチャーか)が一部では注目されている。納品ではなく価値を届けるのだったか。

自分の理解は、システム開発をいわゆる維持管理のモデルであるワークロードで契約しているのだろう。これは納品となる成果物を契約時に明確にできないアジャイル開発も契約するなら同じモデルで契約せざるを得ない。その理由は以前のエントリにも書いていた。端的に言えば、仕様が見積もり時に決められないから請け負えないためである。

話を戻して、競争になるのは提供する価値がエンジニアの数、ヘッドカウントでしかないからだ。他社ができないことが提供できれば比較される競合がない。

もちろん、オーダーされたエンジニアの数を揃えて労働力を提供するビジネスであれば、単なる人売りビジネスだから委託側の要求(価格、品質)に見合う業者が選ばれる。

給与の高低は、委託元への売りと従業員若しくは下請けの買う価格差、言い換えれば、人売りビジネスをしている経営者の利益幅(俗な言い方をすればピンハネ)に依存する。

 

でも、他社の仕事を請け負っているだけのSIerは、受注する仕事を増やして会社の規模が大きくなることはあるかもしれないけど、一件あたりの利益の幅が上がることは基本的にはない。だからひたすらに疲弊していくということです。

 

労働力をエンジニアの数で売っているビジネスモデルの限界がここで書かれている。上述したとおり、利益は売りと買いの差分であるから、利益幅は一定だ。ただし、契約外の労働をした場合の精算条項があれば、話は違う。いわゆる残業しただけ余禄となる。もちろん、精算ができる場合だけの話しだ。

あと、利幅が一定かどうかというと、下げる余地は残っている。社員を極限まで減らし、外から買うエンジニアの単価を下げれば良い。これで収益性は向上する。これはどこのSIerでも行なっていることだ。もちろん、安かろう、悪かろうで、エンジニアが持っているスキルやスキルレベルは下がるのでプロジェクトリスクはひどく悪化する。

では疲弊するかどうかと言えば、それは自社サービスのエンジニアだから疲弊しないといことはない。自社サービスであるかこそ、やり切らないとビジネスにその結果が直結するため、事業を揺さぶる。SIerのビジネスは、契約分の範疇でしかない。自社サービスを作るということはその自社サービスが事業であるから、体力のない会社は即死リスクを持っている。

ただ、自社サービスをサンセットするまでは継続することが前提となるため、先を見据えた対策は取りやすい。

 

でも、SIerにはそのインセンティブがありません。仕様書通り作らなくちゃいけないし、すごく優秀なアルゴリズムを組んだところで評価もされない。だから、工夫できなくなるんです。

 

インセンティブがないというよりは、規模が大きくなればなるほど標準化が行き届くので工夫する余地がなくなる、が正しいのかもしれない。その意味合いでは、工夫できなくなるは正しい。

ただ、本当にそうかと言えば、エンジニアが工夫する、自分のやりたいようにやるのは実現仕様やコードのアルゴリズムについては、どのような仕事でもエンジニア自身が決定できる。

実際のところ、コードレビューでアルゴリズムの書き換え指摘はパフォーマンスとかロジック間違いのような問題が起きない限り、問われない。技術的負債を産む一因でもあるが。

 

全体の主張を見れば、そうかもしれないがやはり、そうでもないSIerもあるよ、くらいだろうか。

 

ただ、4次受け以降の受託のエンジニアは早々に1つでも数字を減らせるSIerに移った方がいい。同じような仕事をしているはずなのに給与が違うことが少しだけなくなる。