SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。 でもテーマが定まってない感がすごい。

SIerからベンチャーへ転職します

タイトル通りですが、現在勤めているSIerから、ベンチャー企業へ転職します。1月でちょうど二年働いたことになります。

当記事

以下の記事で触れている転職についての、具体的な内容となります。

2018年を振り返ってみた - SE(たぶん)の雑感記

2019年の目標を立てた - SE(たぶん)の雑感記

転職のきっかけ

2018年初頭

2018年の年初に書いた記事です。この時点で転職を視野に入れていました。

hiroronn.hatenablog.jp

とはいえ、業務内容自体は大きな不満はない状態であり、転職へのアクションは取っていませんでした。

今年の状況

2017年は、流されるまま仕事をしていました。4案件ぐらい同時期に回してやり切ったので、社内評価は高かったようです。

2018年は、不安定な保守業務から外す、新規のシステム構築案件(PoCとか)があったら私を割り当てる、新規でもRPAの案件は担当から外す*1など、私が飽きないようにいろいろ考えてくれていました。

別の記事でも触れている通り、PoCの案件に入れてもらい、要件定義の前段階から構築までの全工程に関わるチャンスもいただきました。

少なくとも、私が担当している業務内では、さほど不満はありませんでした。

きっかけ

10月あたりに、以下のような記事を書きました。このとき、自身の業務には不満はないものの、会社として仕事のやり方がまずいのでは?と思い始めました。

hiroronn.hatenablog.jp

そんなことがあり心が揺らいだところで、とあるスカウトが来る(かもしれない)サイトに登録していたことをふと思い出しました。

久々に自己紹介等を書き換えたところ、すぐにスカウトが来ました。きちんと自己紹介を読んでくれており、イベントやってるから気軽に話聞きに来ていいよ、とのことだったので、転職意思はないけど話聞かせてほしい、と返事した上で参加しました。

そこで感じた雰囲気は、本当に開発が好きで人が集まっているという感じで、すごく良い印象を受けました。

そこで、きちんとキャリアについて考えてみよう、と思いました。

キャリアに対する考え方

私は以前から、設計分野に進む形でキャリア形成したいと考えていました。主にBtoBもしくはBtoCのシステム、業務システム等が対象です。元々会計学をやっていた影響もあり、企業に関わっていきたいという考えです。

パッケージの開発会社からSIerに転職したのも、多くの企業に関われるだろう、という考えがあったからです。

設計能力を高めるため、テスト駆動やドメイン駆動等、設計手法を学んでみたり、システムアーキテクトを取得してみたり、システムは大抵ソースコード表現となることからプログラミング言語を習得*2してみたり、仮想インフラ技術を学んでみたりと、学習を行っています。

ただ、なぜ設計を高めたいのか。そもそもなぜ設計をやりたいのか。
今回の転職活動を行うまでは明確ではなく、好きだからとか楽しいからという理由でした。
読みづらいソースを相手に苦労してきた経験もありますが、プログラミングは楽しいと思います。綺麗であること、綺麗なソースを書くこと、良い設計で苦労を取り除くことが好きであり、そこにやりがいを感じていた部分はあります。

悪い設計に翻弄されて嫌いになる人を見たことがあるので、そういう人を少しでも減らしたい、という気持ちがあるのも事実です。

そういう中で面接を受け、二次面接で

今度どういう風になりたいとかありますか?

と聞かれました。設計をやりたいのだと話しました。

しかし、ふとその時、

なんで設計やるんだろう?

と疑問がよぎりました。設計技術高めてなんになるのかと。実装が好きなのに、なんで上流を目指しているのかと。

答えは自然と口から出ていました。いいシステムを作りたいのだと。そして、システムを設計させるならこの人、みたいな形で声がかかるような人間になりたいと。そのために設計能力を高めていきたいと。

私は、良い設計というのはシステムの価値につながると確信しています。対象ドメインを正確に把握し、その変化にも対応できるような設計があれば、そのシステムはとても強力なものになると思います。

いずれは、そのようなシステムを構築できるようになりたい。つまり、良いシステムを構築できるようになるために、設計能力を高めていきたい、というのが私の思いで、そのためには徹底的にシステムに関われる、自社サービスをやっている会社に身を置いたほうが良い、というのが、キャリアと絡めた転職理由となります。

SIerについて思うこと

さて、自分の話をしたところで、さらに自分の話をします。

前職はパッケージソフトを作っており、その販売だけでなく一連のサービスを提供している企業でした。給料はよく、現職に入る際に年収が180万下がっています。

そこまでして転職したかったのは、前職に不満があったことと、SIerで多くの企業を見て視野を広めることでした。そしてもう一つ、SIerが多い日本の仕組みがどういうものか、肌身を持って知ることです。

外から見て叩くのは簡単なことで、実際にSNS等でもSIerを叩く記事を見たことがあるので、実際に体験しようと思いました。

とりあえず二年は働いたので、何書いてもいいですよね、ということで。

以下の意見は私個人の意見です。また、私が見たものでしかなく、場所によって全然異なると思いますので、あくまで参考として見てください。

SIerの立ち位置

企業のIT関連業務の穴を埋めるためにいます。

どのような依頼をするか、企業によってまちまちです。例として、

  • 新しいシステムや仕組みの構築のために手を貸す
  • 既存システムのメンテナンス
  • 企業内部に入って社内業務を手伝う

などがあります。それ自体はいいのですが、企業側がそれに依存しているケースがあります。

SIerの社員がエンジニアとして育ちにくい

企業の中に入って仕事することが多いため、SIerの社員はその企業の業務を覚えればよく、エンジニアとしては成長しにくいです。

また、SIerとしても、社員がどこかの企業に入って仕事してくれないと利益を生まないので、最低限教えて企業に放り込む、が最適解となってしまいます。

エンジニアの側からしても、基本は会社に言われた企業に出向いて業務を行うため、新しい技術を習得する動機がありません。結果、成長するかどうかは本人次第になり、不満があれば辞めていく、という状況になります。

綺麗なソース、設計を推進する意味がない

SIerが、企業のシステム構築を行うとして、企業が品質に関心が無い場合、綺麗なソース等を目指す意味がありません。

むしろ、そのシステムを改良することを考えると、納品前の品質は高くないほうが良くなってしまいます。これは、人月単位で請求する場合、とても分かりやすいです。

案件1:システムの構築

案件2:案件1のシステムへの機能追加

上記二つの案件を考えます。

案件1で高い品質を確保し、案件2の機能追加を容易に行えるようにすると、案件2での人月は減ります。

一方、案件1で後先考えない作りにして、案件2の機能追加が簡単ではないようにしておくと、案件2で必要な人月が増えます。

結果、品質を下げたほうが受注側の収益が増えます。


SIerのエンジニアが学習して綺麗なソースを構築できるようになると、SIerにとっては損となる、とも言えます。

極端な例ですが、素早く改訂等が行えるほど、SIerにとっては人月が減るため、損です。

そして、企業にとっても、品質が低いものが納品される可能性があるため、良いとは言えません。

この問題は根が深いです。人月単位も悪いですが、時間でしか請求できない企業側も悪いです。受け入れ品質等を考慮できるようにならないと、この問題は解決しないように思います。

無関心

SIerや派遣の人が業務を穴埋めしている現状を見て分かったことがあります。

まず、企業の人はSIerや派遣の人がどういう業務を行っているか、ほとんど関心がありません。結果、そこがブラックボックスとなり、依存を生みます。

働き方改革等で、その部分を効率的にしようとしても、ノウハウ不足によりブラックボックス部分を企業で吸収できないため、そこは残り続けます。というか、あえて目を背けているのか、と思うほど無視されます。

そこで、予算削減等でSIerへの支払額が減るとします。SIer的にはお金もらっている立場なので、強く言えない可能性もありますが、やること変わらず売上が下がるのは普通じゃない*3ので、撤退がよぎります。その時困るのは企業なのですが。

無理解

仕事を依頼している部門が、担当システムについて理解していない場合があります。

たとえば、社内でシステムを導入して、新たな仕組みを作ったとします。

そのシステムの導入を他社に丸投げし、社内にノウハウが蓄積されていない状態で引き取り、それをそのまま他社に運用を投げる、などということが平気で起こります。

結果、システムが動いてしまっているため運用せざるを得ず、SIerへ依存します。

システムについて理解したSIerが、例えばリプレースの提案を出すとしても、企業としては当然そんな金は出せず、現実として業務は回っているため、現状維持を望みます。

SIerとしても、金にならない仕事を頑張る必要はないので、適度に現状維持します。そのシステムは、いつ誰が良いものにするのでしょうね。

企業のためになっているのか

私の疑問は、SIerのこのような業務が、本当に企業のためになっているのか、という点です。

なんで、社内業務を丸投げという形で外部に依存しているのでしょうか。それは企業としてみたら良くないと感じます。

企業の戦略転換期は、それに応じて社内も変化が必要となります。そのとき、ブラックボックス化した業務も変わらなければならないのに、SIerという便利屋による相互依存により、変化への障害になります。

私は、社内で推進すべきものは独力で推進し、適度にSIer等外部の力を使うべき、と考えています。

最近、私が携わっているわけではないですが、

RPAを推進したいから、ロボット作ってくれ

みたいな案件があり、そこそこの利益を生み出しています。

RPAのロボットは、自分たちで自動化できる業務を見つけ、自分たちで作って随時作り替えていくからこそ、自動化のメリットを最大限享受できます。

なのに、それを外部の人間に頼み、自分たちで変更できない*4状態にし、結果業務を遅延させることになる。しかも、自分たちでやらないなら、RPAである必要が全くない。これが企業の役に立つ仕事なのか、どうしても疑問が拭えません。

SIerが不要だとは思いませんが、今のような業務穴埋めという視点からすると、必要悪だと思ってしまいます。

どうなるとよいのか

企業視点では以下の通りです。

  • 企業は、ITエンジニアを直接雇用する
  • SIerにそれなりに払っているのなら、それと同じ額かそれ以上の額をITエンジニアに支払う
  • どこまで外部に頼るか、しっかり決めておく。外部者が抜けた時点でその業務やプロジェクトを推進できるのか、事前に考えておく

SIer視点では以下の通りです。

  • 最新技術をしっかりキャッチアップする
  • 企業にとって利益となるように動く*5
  • エンジニアの「エンジニアとしての成長」に投資する
  • 業務の穴埋めではなく、支援に特化する

SIerは、技術をもって支援するコンサルティング、みたいな立ち位置になったほうが良いと思っています。

結局、以下で触れられている内容とあまり変わりません。

www.meti.go.jp

企業もSIerも、どこかで転換が必要だと思います。

企業、特に大企業は、もっとエンジニアを雇うことを考えたほうが良いのでは、と個人的には思います。給料だけで転職するかどうかは分かりませんが、福利厚生含め相当良い待遇を用意できると思います。

自社のためだけに働くエンジニアは、絶対に必要です。

また、SIerとしても、もっと専門家として企業の力になっていかないと、企業が自社にエンジニアを雇い始めた時にお払い箱になります。それ自体は好ましいのですが、生き残るなら専門性を高めるべきかと思います。

少なくとも、まだ31歳程度の私が、コーディングや設計関連でトップクラスに仕事ができるという評価を取るような状況では、不十分です。

転職後

転職先は、創業5年ぐらいの、自社サービスを提供している企業です。Webだけでなく、アプリ等も出しています。

ポジションとしては、上流に近いところで仕事をすることになる予定です。入る時期にちょうど事業年度が変わるらしく、何をやるのか明確に言えない状況のようです。ソース書くところから離れないようにだけしてくれ、とは頼んでいます。

なお、給与はアップします。いいことです。

システム等を固める時期とのことで、私は「固い」システムの経験が長いことから、品質等の観点で力を出せそうとのことで評価いただいたそうです。

おわりに

長々と書いてしまいました。ここまで読んでいただいた方、ありがとうございます。

この記事を生み出すのに、一週間以上かかっています。特にSIer関連の記述がまとまっていません。申し訳ないです。

というか、転職にかこつけて言いたいこと書いています。

私が今の会社に入って二年ちょっとです。その間だけでも、業界は変化していると思います。

エンジニアは超売り手市場で、人材不足が叫ばれ、価値が高騰しています。

だからこそ、それに胡坐をかかず、実力を高めていきたいと私は思っています。

なお、ツッコミ等大歓迎です。よろしくお願いします。


*1:企業で内部的にRPAを推進するのはともかく、構築や作成を企業外部の人間が担当するのはおかしいと、日ごろから主張していたため。一方、その案件が金になるという話もされたので、理解は示した

*2:単に学ぶのが好き、という側面はある

*3:というか企業としてあり得ない。むしろノウハウを積み重ねて他社より価値がある状況なのに、それを無視して金額下がるのは合理的ではない

*4:変更できるだけの知識が社内に蓄積されないため

*5:RPAでやろうとしていることを、RPAなしで実現できることに関して内製化支援するとか。それ、API作れば良くね?というものは本当にいっぱいある