Web上のエンジニアの愚痴をみていると、SIerに対する嫌悪感が多い。かくいう私もSIerの硬直化した組織はやりづらいとは思ってる。
一口にSIerと言ってるが、定義としては以下のように絞られるだろう。
- 自社サービスを持つのではなく、クライアント企業の依頼を受けて動く
- 割と大規模（だからこそクライアント企業の中の人間ではできない）
- ビジネスモデルとしては受託（業務委託契約）
- 納品ベースでお金が動くので、仕様書が契約書に近い効力を持つ
以上の切り口そのものに、何ら問題はない。
SIerと対比される業態に「Web系」とか「自社サービス」などという表現もある。
Web系も定義がはっきりしないが、整理をすると、Web系とはこういうことだろう。
- 開発費をもらうのではなく完成したシステム自体が稼ぐ
- 広告費や月額使用料で稼ぐモデルなので、インターネットビジネスが比較的多い
- 自社で要件定義をするので、常に仕様はアップデートされていく
Web系のツラミとツヨミは別のところで解説するとして、ここではSIerに絞って説明する。
まずツラミ
硬めのクライアントが多い
SIerにとって太い客といのが、官公庁や銀行などだ。多くのSIerが銀行の子会社からスタートしている。だからどうしてもクライアントのカルチャーに引っ張られる。金融系のSIを担当するということは、ソフトウェアビジネスではなく金融ビジネスをしているのに近い。だからスーツだ。自社の新人研修でSIerがやってるプログラミング研修にやると、「机の上にペットボトルがあると叱られた」と帰ってきた。そういう研修をお願いした覚えはないのだが、1文化とも思わず、社会人エンジニアとしての常識ということなんだろう。
硬いこと自体は悪くないのだが、何かとマナーにうるさい。さらに根回しの世界。太鼓持ちを仕事にしたくなくて技術者になったのに、なんでご機嫌を伺うことが最優先になるんだろうという矛盾。
仕様書の通りに作ることが仕事
仕様書どおりに作って納品するというのがビジネスなので、仕様書にかかれていることがどんなに使いづらくともその通りに作らないといけない。逆に仕様書に書かれてないことは作っちゃいけない。そして厄介なのは、その仕様書を作ってるのが、「UIの専門家でもなければコンピュータの専門家でもない人」が作っているというのが辛いポイント。だいたい間違ってる。間違ってる仕様書の通りに作らないといけない。
そしてどんなにクレームが来ても仕様書の通りなら「それは仕様です」と言って突っぱねるのが大事な仕事になる。
技術に疎いクライアントが相手
クライアントが技術に疎いからこそ、外注をしている。先の仕様書の間違いも指摘するのは苦労をする。レクチャーにかかるコストはお金にならない。
新しい技術は使えない（使っちゃいけない）
メーンフレームCOBOLという組み合わせはまだまだ多い。せっかくだから新しい技術も使いたいかもしれないが、年金のシステムは向こう50年は動いてもらわないといけない。毎年変わるアーキテクチャは使えない。
本当に新しい技術が使われているなら、銀行の口座番号なんて、664289d2-dc45-44b8-8b00-c5a20d789e50 となっていてもいいはずだ。ところが、2019年時点の三菱銀行では三和銀行の口座番号とIDとパスワードがそのまま使える。これは技術では解決しない。
ツヨミ
逆にいえば、上記のツラミがあったにせよ、ビジネスとして成功しているからこそ存在しているのがSIerだ。しっかり稼げてうらやましけしからん。
待遇がいい
自社サービスだと自社のサービスの売上が分母となって、従業員に賃金が支払われる。儲かってないWebサイトのエンジニアの給与はそれなりだ。ところがSIerだと客が太いから会社そのものもまぁまぁ潤ってる。そこでのエンジニアの給与も高い。
ホワイト
仕様書の通りに作るというのは一見ホスピタリティは悪いが、仕様変更にいちいち付き合ったのではいくら時間があっても足りない。仕様書通りに作るというのは自分たちを守るための手段でもある。また、SIerからも下請けにながす。本当に労働環境としても辛いのは、二次受け三次受けだ。
業務には強い（これが一番言いたいこと）
例えば、会社のビジネスが変わって、会計システムを入れ替えたいという話がある。クライアント企業の担当は会計システムを入れ替えた経験など、ほぼない。ところが、SIer側はそんなことばっかりやってる。だから会計システムの入れ替えの時の「あるある」がめちゃくちゃ溜まってる。他の会社の事例をしっている。守秘義務があるにせよ、競合他社含めてのバックオフィスの知識と経験は、喉から手が出るほど欲しい。クライアント企業も仕様書をいきなり作るのではなく、RFPという形で、「SIerからの提案募集」をすることもある。
逆にここが強すぎて、入札には手を上げないというケースも発生する。マイナンバーのシステムとかは、入札段階で「あー、これやんない方がいいやつだわー」とSIer個別には手をあげなかった。実際にはSIerの合同で仕方なく国に付き合うという形で落ち着いたが、実際にリリースされたものをみると、確かに国がやりたいことと手段がミスマッチだ。SIerの人たち賢いね。
この「業務に強い」は、SIerの中では常識で、PG→SE→PMという形で出世するというコースが描かれている。「出世したらコーディングできなくなっちゃうよ」という恨み節も聞こえてくるが、SEの市場価値なめんなよと。「ECの倉庫のシステムを構築したことあります。」というのは、「Railsでサクサクサイト作れます」とは別次元の価値がある。
欲を言えば、「業務に強い」のその業務によって当たり外れがあるということ。先に挙げた「ECの倉庫システム」はとても今求められている。「店舗のポイントカードの仕組みとECの在庫の仕組みの両方経験あります」だとさらに価値が高まる。
この業務に強いというのは「複数の会社の類似業務を見ていている」ということもある。これは社内エンジニアにはできない経験だ。不満をもっても何と比較して駄目なのか良いのかが分からない。
ベンチャーも習うべきところは多い
SIerにエンジニアがたくさんいるというのは、それなりのビジネス的な理由がある。とにかく金が動かないと話が始まらない。そして「人を便利にするシステム」を作るには、業務の事例をたくさん知ってるということが、市場価値を生む。
ベンチャーであっても「便利」という価値を生むなら、受託じみた形からサービスや新機能をスタートして「この領域ならクライアントより業務の知識が多いですよ」という領域ができると強い。
