こんにちは！
ねこじょーかー（@nekojoker1234）と申します。
「そういえば、SIerの仕事や体験談についての記事って読んだことないかも」と思ったので、この記事にまとめようと思いました。
私は誰??
私は中小企業のSIerとして６年間働いてきて、要件定義フェーズから保守まで幅広くやっています。中小企業のSIerの特徴かもしれませんが、「プレイングマネージャー」として管理だけでなく実際に手を動かすこともやっています。
大手のSIerになると外注比率が高くなり、管理作業が多くなって実装しなくなる確率も上がります。
ですが中小の場合は、プロジェクトの規模もそこまで大きくないので、PM（プロジェクトマネージャー）やPL（プロジェクトリーダー）が実際に手を動かすことも少なくありません。リーダー層の人も手を動かしながらプロジェクトを進めていく人のことを、プレイングマネージャーと呼んでいます。私はその立ち位置です。
なお、プレイングマネージャーの人がタスクを抱えすぎて管理作業ができなくなるケースもあるので、あまりこのポジションを作ることは望ましくありません。
SIerの仕事が発生する仕組み
少し脱線しますが、ここでSIerの仕事が発生する仕組みについて解説します。知っている方は読み飛ばして構いません。
仕事が発生する流れとしては、以下の図になります。
具体的な流れとしては以下のとおりです。
- 顧客は大企業に仕事を依頼する
- 大企業は中小企業に仕事を外注する
- 大企業は外注した仕事が問題なく進んでいるか管理する
- 中小企業はSES企業などに仕事を外注する
- 中小企業は外注した仕事が問題なく進んでいるか管理する
つまるところ、１次請け、２次請け、３次請けと進んでいくにつれて手を動かす作業が増えて、逆に１次請けに近づくほど管理作業が増えるという仕組みです。
また、顧客はいきなりSES企業に発注するということはありえません。まずは、ネームバリューのある企業に発注をするのが一般的です。
「じゃあ大企業以外は仕事がないのでは？」
そう思った人もいるかも知れませんが、一次請けをする企業は、作業自体を他の企業に外注することでたくさんの仕事を回しています。
例えばお客さんから「1人が1ヶ月かかる作業を100万円」で依頼があった場合、大企業は100万円を受け取ります。ただしここで大企業が実際の作業をしてしまうと、その1ヶ月間は他の作業ができなくなってしまいますよね。そうなると、別のお客さんから発注があっても人の手が足りなくなるため、受注することができなくなってしまいます。
そこで、受注した金額（100万円）よりも安い金額（60万円）で他の企業に再度発注する、ということをするのが一般的です。そうすると一次請け企業としては別の受注ができ、二次請け企業としては仕事を貰えるというメリットが生まれてきます。
これを「外注」といいますが、IT企業にかかわらず世の中一般的な仕事の流れはこのようになっていることを理解しておきましょう。二次請け企業としても同じように、受注した金額（60万円）よりも安い金額（40万円）で外注することになります。こうして、三次請け、四次請け・・・と外注していき、どんどん発注金額が少なくなっていく仕組みです。
このように「◯次請け」した企業のことを「下請け企業」と呼びます。
下請け企業になればなるほどプログラムしか書かなくなる
「プログラムを書きたいなら、下請け企業に入ればいいのでは？」と考えるかもしれませんが、そうもいきません。
確かにプログラムを書けるのですが、下請け企業には以下のデメリットもあります。
- 何がなんでも納期に間に合わせなければならない
- 会社にお金がないためコストは徹底的にカットされる
- 客先に常駐することがある
下請けになればなるほど、納期は厳しくなり、仕事も忙しくなります。また、忙しいわりにもともとの発注金額が少ないため、社員に還元できる給料も少なくなってしまいます。さらに、自社で仕事をすることは難しく、客先に常駐して仕事をしなければいけないケースも多く、「自分が何の企業に所属しているのか」が曖昧になっている人も少なくありません。下請けになればなるほど、自分の企業ではなく、常駐先の企業を名乗らなければいけなくなるからです。
１次請け企業の実態
「やっぱり１次請け企業に就職した人が勝ち組だよな」と考えるかもしれませんが、そうとも限りません。
私がPLとしてやっていた案件では、２次請けで仕事をうけて、１次請けの会社の人と一緒に仕事をしていたこともあります。
誰もが知っているような企業ですが、一緒に働いていて違和感しか感じませんでした。
打ち合わせに参加しても、一言も発言せず内職をしていたり、本来やるべきPMの仕事も全然回っておらず、結局は私がフォローないとダメ、みたいな状況が続いていました。
しまいには、お客さんから直接私の方に電話なども来るようになり、１次請けの人は空気と化していたこともあります。
私の例は極端かもしれませんが、１次請けの企業の中には実際に何も作業をせず、「お客さんがこう言ってますよ」と伝言してくれるだけの人も中にはいます。
１次請けができる大企業に入ることだけでも素晴らしいのですが、自分で手を動かすことが少なすぎて、成長する機会がなかったのかもしれません。逆に、そういう環境で仕事ができたからこそ、私はその分成長することができたと思っています。
中小企業は幅広く経験できる
これも会社によるかもしれませんが、中小企業の場合は幅広く経験できると思っています。
私の場合は上流から入り、お客さんの新しい業務の流れを一緒に決めたりもしますし、プログラムを書いたり、保守をしたりもします。また、外注している仕事のスケジュール管理をしたり、ソースコードレビューをしたりなんかもします。
何か特定の分野に限らず、幅広く仕事ができるのは、中小企業のメリットと言えると思います。自分で手を動かすことが、一番の成長になると感じました。
SIerになるメリット
ここからは、SIerになるメリットとデメリットを書いていこうと思います。
独学では学べないことが身につく
「独学で身に着けられないことを学ぶことができる」というのが、SIerになる大きなメリットになると感じています。
技術力に関しては独学である程度のレベルまで到達できますが、お客さんとの打ち合わせの進め方や、わかりやすい伝え方などは、SIerでかなり勉強になったところです。私はSIerになる前までは、声も小さく人見知りで、とてもお客さんと打ち合わせができるような感じではありませんでした。しかし、打ち合わせを重ねていくうちに、声を出せるようになり、お客さんともしっかりと話しができるようになりました。
また、電話で問い合わせがあった場合に、「いかにわかりやすく伝えるか」というのも重要になってきます。私のお客さんの中には、「リモートデスクトップ」や「タスクバー」という用語が通じない方もいらっしゃいます。そういった方に「どうすれば伝わるか」というのを常に考えて仕事をするようになりました。エンジニアの中には、「SQLのチューニングが必要ですね」とか「異常終了したらロールバックしているので大丈夫です」のような用語を使って説明する人も少なくありません。「相手のITレベルに合わせた会話」が必要になるというのも、なかなかできない人が多いと思います。
直接お客さんに感謝される
プログラムを書くのは楽しいですが、それがどういった形で社会貢献につながっているのか実感することが難しいと思います。SIerをやっていると、お客さんから直接感謝の言葉をもらう機会が多く、モチベーションの維持につながっています。お客さんから「プログラムの構造、いいね！」と言われることもなければ、「リファクタリングしてくれてありがとう！」と言われることもありません。「社会貢献感」が出やすいのも、SIerの特徴だと思います。
SIerになるデメリット
実装力が上がりにくい
SIerは管理や打ち合わせの仕事が多いため、実装する機会が少なく、実装力が上がりにくいのは間違いありません。また、企業の規模が大きくなればなるほど、外注比率が高くなり、実装しなくなる確率も上がります。
エンジニアになるからには、「自分でものづくりがしたい」「技術力を上げたい」という気持ちがあるのは当然です。
私も技術が好きなので、プログラムを書くことが好きです。「自分で何かものづくりができたらいいな」「実装力が上がるといいな」という考えもあります。ただ、製作フェーズに入らない限りは、プログラムを触る事はほとんどありません。
自分の仕事が終わっても帰れない
管理側にまわる以上、外注先の仕事が終わるまでは帰れないという制約があります。仕方がないことなのですが、自分のスキルをいくら磨いても、業務効率化を進めても、残念ながら帰れないということになってしまいます。
あまり良くありませんが、私の場合は外注先にお願いすべき仕事を自分でやって、外注先の負担を減らすことで早く帰ってもらうということを実践しています。付き添い残業だけはしたくないので、自分でやった方が早いものは自分でやってしまうという戦法です。大規模なプロジェクトになると使えない戦法ですが、そこまで大きくないプロジェクトの人は試してみる価値はあるかもしれません。
社員と働く機会が少なくてちょっとさみしい
SIerは、外注比率を上げて、社員１人でいかにたくさんのパートナーさんを抱えて案件を回せるかが勝負になってきます。なぜかというと、外注をしたほうがコストが安く済むからです。そうなると必然的に、社員同士で働くことが少なくなります。これがちょっとさみしかったりします。
ソースレビューで怒りが湧いてくることがある
SIerは関係ないかもしれませんが、外注先のソースレビューをしていると、カオスなものも出てきます。
- メソッド化しないでコピペの嵐
- 使う必要のない技術を使って複雑になっている
- 変数名が a b c など１文字
- if文ですべてを解決する人
- if文の中身が2000行
書ききれませんが、記念に写真を取りたい事案がまだまだたくさんありました。
最後に
「SIerは成長できない」と言われることもありますが、私はそうとは思いません。
そもそもなぜ「SIerが成長できない」と言われるのかというと、「プログラムを書く機会が少ないから」という理由が挙げられると思います。
確かに、SIerはプログラムを書く機会が少ないです。
しかし、「プログラムを書く機会が少ない → 実装力が上がりにくい」が事実だとしても、「プログラムを書く機会が少ない → 成長できない」というのは違います。
実装力の面ではあまり成長できないかもしれませんが、人間の基礎の部分は確実に成長できます。
つらつらと書きましたが、６年間やって感じたことはこんなところですね。
長文を最後まで読んでくださった方、ありがとうございました！
おまけ
PlayFab というバックエンドサービスの専用ブログも運営しています。
もし良ければご覧ください。
https://playfab-master.com