大手SIerから社内SEに転職して1年たった

やはり、サービスイン直前などの多忙な時期には100h/月近い(時には超えるような)残業をしなければならなかったり、場合によってはサービス残業をせざるを得ないケースもまれにあった。その一方で、毎日定時で帰れるような時期もあり、平均残業時間は40-50h/月ぐらいだったと記憶している。

今の環境と比較すると長時間労働であり、それなりに激務ではあったが、残業代は可能な限り支払おうとしてくれる意志のある会社だった。収入面でも人並み以上には貰えており、かつ、まとまった休みも取れるので、待遇面での不満というのは全くなかった。

辞めるに至るまで

「辞めようか」と考えはじめた理由と、やめるに至った経緯について述べる。

受託開発での価値創出の難しさ

一つ目は、受託というビジネスモデルで顧客に対して価値提供することに困難さを感じたことである。

RFPの時点で顧客の欲しい物は決められており、競合と入札でやりあう事になると、決まって価格面での勝負になってしまう。中身で勝負がしづらい。

やれることといえば、見積もりに都合の良い前提を置いて規模を小さくする、オフショア・ニアショアで単価を下げる、利益率を下げる、リスク費を下げるといった、SIer側にメリットの少ない方向性しか武器が無く、面白みを感じることができなくなっていった。

他社には真似できないような、圧倒的な生産性、品質、納期を出せるなどといったそういう革新的な強みを見つけられればよかった。

といったことが語られていた。

私が所属していた組織は後者の戦略を取り、受託ビジネスをこなしつつ、それなりに一生懸命にクラウドサービスを作っており、私もいくつかのサービス開発に企画段階から参画させてもらったが、今までオーダーメイドのモノづくりを生業としてきた人たちが価値創造することは困難なのではないか、という不安を感じていた。

「2015年問題」がIT業界に迫る覚悟 - ［2015年問題4］クラウド時代に自ら変革、日本のSIにパラダイムシフト：ITpro

キャリアパスへの違和感

ありがたい事に次々とステップアップさせて頂いていたのだが、プロジェクトを淡々としながらチームリーダー、プロジェクトリーダーを数年ずつこなしたあと、管理職まで上がってプロジェクトマネージャーになる、という未来に魅力を感じられずにいた。

そんな状態で悶々としながら、転職エージェント経由で定期的に情報収集していたところ、アベノミクスのおかげか、あるいは沢山の良い経験をさせてもらったおかげか、提示される年収が前職のそれを上回るタイミングが来た。

また年齢的なタイミング※もあり、本格的に転職活動に乗り出した、といった経緯である。
※エージェント曰く異業種転職は20代まで、30代以降は同業他社への転職が主になるとのこと

次になにをするか

結論としてはタイトルの通り社内SEに転職した。しかし、辞めようと決心した時点でこれといった明確な思いがあったわけではなく、次に何をやるか・将来何になるかについては相当に悩んだ。

コンサル、パッケージベンダー、Web系、社内SE、ベンチャーなどたくさん紹介してもらったが、どれも一長一短があったりして単純には決められない。

見かねたとあるエージェントには「決められないなら、まずコンサルタントに転職して2-3年ほど頑張ったらよい。市場価値が上がり、数年後に取れる選択肢が増える」といった趣旨のことを述べていたが、さらなる激務に立ち向かっていくほどの気概もなかった。

自己分析

そこで、自身が職業に対して求めている要件を明確化するために、新卒就職活動の際もまともにやらなかった「自己分析」に取り組んだ。

非常に参考になったのが、この本。

帯に書かれている「記入式の30のワークをこなすだけで、自分らしく働き続けられる人生戦略がわかる！」という文言が、明確にすべてを表しており、あんまり説明することが無い。その言葉に偽りなく、かなり納得感のあるキャリア戦略を立てることができる。

初めて人生を考える就活生や、なんとなくやめたくなってしまった第二新卒の方なんかには強くおすすめしたい。

本に従って、自分の歴史を振り返り、それぞれの成功/失敗体験から弱み強みを抽出する。自分がどんな価値観を持ち、どんな職業領域に興味関心があるのか、といったワークを行いながら最終的にキャリアの戦略が出来上がっていく。

個人的にとても腹落ちしたのが、仕事に対する価値観を確認するパート。いわゆる「出世」や「リーダーシップをとって人を率いること」にはそれほど大きな魅力を感じておらず、「他社への支援」と「ワークライフバランス」を最も重視している、という結果であった。

この結果に大きな納得感をもちつつ、自身の価値観にフィットしそうな、社内SEという道に進もうと決意した。

社内SEになった結果

業務内容

現職では、一般的な事業会社の情報システム部に所属し、システムの企画、開発、維持運用に関わる仕事に従事している。

具体的には

• ユーザ部門からの要件を吸い上げて要件定義書としてドキュメント化する
• それを使って発注したり検収する
• トラブルが発生したらユーザ部門に謝罪&影響の説明しつつベンダーに指示出しを行う
• ベンダーの出してきた見積もりをガリガリ削る

というものであり、SIerの立場から見た「お客さん」が主にやっていることであり、全くギャップはなかった。

待遇

待遇面では残業時間が20-30h/月と半減したにも関わらず、年収は100万円近く上がったため満足度は高い。

役に立った能力・スキル

情報システム開発に関する一般的な知見やスキルはほぼそのまま活用できる。元々いるプロパー社員が大体ITパスポートぐらいの知識で頑張っているので、SIerから入ってきた人は少々オーバースペックなぐらいの知識レベルとなる。

また当たり前だが、リーダーシップ、課題解決力、ファシリテーションなどのソフトスキルも引き続き活用できる。

ちなみに、開発規模予測(要は見積もり)や、皆が行ってる業務を抽象化してドキュメントに落とすというモデリングスキルについては、職務的には重要であるにもかかわらず、生え抜きの社員は体系的な教育を受けていないケースが多い。もしも社内SEになりたい方がいたらアピールポイントとして参考にされたい。

SIerのSEと社内SEの違い

いらない要件を切ることができるようになる

受託者/発注先として仕事をしていると「よくよく考えてみるとこの要件いらなくね？？」といったものも往往にして発生する。顧客も取り合ってくれず、請負責任に基づいて疑問を抱きながら作る→悪い予感が的中して結果的に誰も使わない（使えない）といったこともそれなりに発生する。

社内SEとして仕事をしていると、企画段階から自身で考えることができ、納得感を得やすい。また、意思決定者と距離が近く、不要さや難しさの甘さに気付いたときには、関係者との合意を取りつつ要件ごとバッサリ落とす、といったことがやりやすいため、前述のもやもやを感じることがかなり少なくなった。

孤独になる

SIerでは、仕事のまとまり単位でチームがあり、同じ役割を持つチームで、ひとつの仕事をすることが多いが、それと比較すると社内SEは孤独である。

広義ではユーザ部門もベンダーも同じモノをつくろうとするひとつのチームではあるものの、社内ITとして、自分と同じ立ち位置で仕事してる人間は自分だけた、みたいな状況も多い。

もちろん、ある程度チーム的な概念はあるが、プロジェクトは自分一人か、かなり大きいものでも二人程度で担当することが一般的であり、やはり単独行動が多くなる。

相手との付き合いが長期になる

これは至極当たり前の話である。頭では理解していたつもりでも、実際に働いて見るとすこし感触が異なった。

SIer時代は、万が一ケンカ別れで出禁をくらったとしても別PJにアサインしてもらえればよい。

そのため、仕様が決められない、あるいは下流工程で仕様変更要望を出してくる顧客やその先にいるユーザに対して戦う姿勢をとり、納期とコストを変えないとできない、受け入れられないのであれば降りる、といった交渉もアリだと思っていた。

一方、社内SEでは、相手が社内の人であり、付き合いが半永久的に続くのでそうもいかない。

そもそも、仕様変更を出されたとしても、仕事はさほど大変にならず、お金をかけて価値のないものを作ってしまうことの方が辛い/悪なので、ユーザーと共に仕様を決められるように一緒に考えたり、納期を守りつつ仕様変更無しで逃げきれる方法を考えてあげたりしている。

業務に占める各種調整の割合が飛躍的に増える。

SIerとして働いていると、調整先となるカウンターパーソンは顧客担当者1名なことが多いが、社内SEとして働いていると、ベンダーのリーダー、ユーザー側の担当者とその上司に加え、連携先システム担当との調整まで面倒を見なければならない。自身が相対するステークホルダーが5から10倍程度には多くなる。

数だけでなく、多様さも増える。場合によっては接続先が社外の人になったり、全くITリテラシーのない方になることもある。

加えて、かなり日常的に「偉い人」が登場するようになる。SIerでは、現場のトップはPMで、せいぜい課長級であり、役員などの偉い人との折衝ごとはほぼ発生しない一方で、社内SEとして働く場合は、わりと簡単にCxO承認案件となり、工程が遷移するたびに担当役員に対して承認をとりに行く業務が発生する。

まとめ

社内SEはITエンジニアのオアシスか？と言われると少々微妙である。待遇面は確かに改善したが、お金を貰う側から使う側へとシフトすることにより、色々と面倒なことも増えるので、「業務負荷」という観点で比べてみると大きな差は無い印象だ。調整ごとが苦手な方は潰れてしまうことも少なくない。