元SIエンジニアが、Web系に転職しても役立ったスキル5つ

f:id:paiza:20170217150650j:plain
Photo by Maryland GovPics
f:id:paiza:20140916135428p:plain こんにちは。谷口です。

エンジニアが自社サービス開発企業に転職する場合、「とにかく技術力が必要」だと言われがちです。paizaでも、よく「自分は自社サービスの開発経験がないので、転職は難しいですよね……」といった相談を受けることがあります。

エンジニアとして転職するのであれば、もちろん開発技術はとても重要です。ただ、実際に転職した人にとって「前職で身につけたスキルで、転職後も役立っているのは開発技術だけなのか？」と言うと、決してそうではありません。

実際、paizaでは業務経験がない分野への転職を叶えている方もたくさんいます。

さらに言うと、むしろ異なる分野の企業にいたからこそ身についたスキルが、転職先で重宝されている……という方も意外と多いのです。

そこで今回は、SIerから自社サービスを開発している弊社へ中途入社したエンジニア2人に、SIer時代に身につけたスキルや経験で、転職してからも役立っていることを聞いてみました。

転職に興味のある方の参考になればと思います。

■聞いた人の簡単な経歴

◆中村

経歴：文系大学→文系大学院中退→SIer→自社サービス開発企業→paiza（ギノ）に来て1年半です

◆高村

経歴：大学（情報工学系）→メーカー系の大手SIer→paiza(ギノ)に来て1年ぐらいです

■1.問題と解決手段を正しく見極める力

受託開発をしていて、お客さんに「××機能がほしい」と言われたけど、本当に必要なのは××機能じゃなかった……ということがすごく多かったです。

「××機能がほしい」とは、あくまでもその人が「私の悩みは××機能があればきっと解決するはず」と思ったから言ってきただけです。イコール本質的な課題の解決策なわけではありません。

根本的な課題は「××機能がほしい」に至った経緯にあるわけです。それを把握した上で、本当に××機能を作れば解決する話なのか、もっと違うところからのアプローチが必要なのかを考える必要があります。

別に、言われたまま××機能だけを作って「はいご注文の品ですよ」で終わっても仕事になるといえばなります。でも、本当に必要なのが××機能じゃなかった場合、それでは何も解決していませんよね。費やされた工数ももったいない。

そういうことをなるべく減らすために、言われるままに要件を固めるんじゃなくて、課題を見極めてから解決策を考える力は、SIerでかなり鍛えられたと思います。

今でも、事務局や営業の人が使うバックエンドシステムに対して「××機能ほしい！」みたいな要望は上がってきます。そういうときにSIerでの経験が役立っています。あと、フロントエンドを作る際も、ペルソナを立てて考えたりするときに活かせていると思います。

「受託じゃないんだからそこまで考えなくてよいのでは？」と思われるかもしれませんが、「××機能を追加することになったからただ作っているだけ」の場合と、「本質的な課題を把握した上で作っている」場合とでは、特にUIや画面フローに落とし込んだときに差が出やすいです。

SIerではお客さんの要望を聞いて、要件定義をするのにもかなり時間を使っていましたが、逆にそのおかげで要件定義力が身についたと思います。

今だと、例えば「××機能を作ったらユーザーがもっと増えるのでは？」という仮説が出てきたとして、特にスタートアップだと実行までのスピード感がめちゃくちゃ早いので、すぐに「いいね！それ作ろう！でき次第公開しちゃおう！」となる場合もあります。

ただ、ここでスピードを重視しすぎると、仮説の検証が浅くなってしまいがちです。誰かが言い出した仮説のようなものは、実は仮説として成立していなくて、よくよく検証すると思い込みにすぎなかった……といったパターンもあり得ます。

つい熱くなって、検証が欠けたままで××機能を作っても、結局誰にも使われなかった……ユーザーも増えなかった……これ何のために作ったんだっけ……？となってしまっては不幸な負の遺産が増えるだけです。

ここで（スピード感とのバランスも考えながらですが）しっかり仮説を検証して、先の例で言うと「開発工数に見合ったユーザーの増加が見込めるの？」「そもそも本当にユーザーは××機能を望んでいるの？」といった要件を詰めていく力はSIerで鍛えられたと思います。

■2.あらゆるソースコードを読み解く力

SIerにいた頃は、スキルのある先輩のもとできれいなコードを参考にさせてもらえる現場とか、逆にデータ構造がすごく複雑なのに全体を見通せる人がいない現場とか、実に様々な現場を経験しました。そのおかげで、ベストプラクティスに近いコードにも、アンチパターンにもたくさん触れてきました。（ちなみに一番のトラウマはEAVパターンです。参考→5章 EAV (エンティティ・アトリビュート・バリュー) - Qiita）

コードに限らず「このやり方が絶対的な正解だ」と思い込まずに「もっといいやり方があるのでは？」と考えるのは、エンジニアとして非常に重要です。また、当然ですがアンチパターンはなるべく回避しなければなりません。これはどこで何を作るにしても、どんな課題を解決するにしても、共通して言えることだと思います。

だから、よいコードにも、決してよいとは言えないコードにもたくさん接触できた経験は今でも役に立っていると思います。

SIerでは、仕様書よりソースコードを信じてきたというか、そもそも仕様書がなくて、信じられるものは既存のコードのみ……みたいな現場もよくあったため、とにかくコードは読みまくりました。

入社して2、3年でマネジメントもするようになってからは、コードレビューもよくしていたので、人が書いたコードをたくさん読みました。「この人は何でここでこんな書き方をしているんだろう？」とか「何がやりたかったんだろう？」とか、想像して考えながらコードを見るのが習慣になりました。

特にレビューの時は、頭ごなしに指摘をしてもお互いつらいだけで意味がありません。「ここってこういう処理がしたかったんだよね？でも、それだったらこっちのやり方のほうがよさそうじゃない？」といった感じでお互いに納得し合ってコードをベストの状態に近づけていかないといけないですから。

SIerだろうが自社サービスだろうが、いろいろな技術レベルの人が、いろいろな状況で書いたコードが集まってシステムはできています。

作者の気持ちじゃないですけど、コードを読んで「何でこういう書き方したのかな」といったことが想像できるようになると、既存のコードを読み取いて理解するとか、手を入れてリファクタリングするとかが、すごくやりやすくなりますよね。今でも、既存のコードを見ると「あの人がまだRubyを勉強したてほやほやの頃のコードだな…」「これ作ったとき質よりスピードが必要だったんだろうな…」とかいうことがわかります。

■3.スケジュールとタスクを管理する力

SIerでマネジメントをしていたころは、なるべく無駄な工数を発生させてしまわないために、タスクがかぶったり競合したりしないように気をつけていました。

どこで何を作るにしても、チームで開発をする以上タスクの競合は起こり得ることです。そして、なるべく回避したいことでもあります。

今でも常にアンテナを張るようにして、スクラム会議でタスクをチョイスするときなども「このタスクとそのタスクはかぶりそうだから同じ人がやった方がいいですよね」とかよく言っています。

あとは、宙に浮いている部分を明確にしてタスクに落とし込むようなこともよくやっています。

宙に浮いた部分を放置していると、SIerだとまず火種になります。「この機能、必要なのに誰も手をつけてない……？」という発覚が遅れると、みんな自分の担当タスクでいっぱいいっぱいなのに、追加業務まで発生しちゃう、でも納期には遅れられない……といった感じで炎上を避けられなくなってしまいますよね。

それを防ぐために、「ここ、誰がどう作るか曖昧になってない？」とか思ったらその時点でなるべく早く明確にする、タスクに落としてスケジュールに入れる、ということは徹底していました。もちろん今でもタスクを決める際は同様にして、手戻りとかスケジュールの遅れを最小限にできていると思います。

SIerだとタスクを細分割して、スケジュールを作ったり人を何人アサインしたり……ということを概算で見積もらないといけなかったので、見積もりを立てるためのいろいろな手法を学べたのはよかったです。

スタートアップだと、次々に機能を作っていかなければならない段階もありますが、それでも「いつ頃までにできそうか」と言う感覚は重要です。自分のタスクを管理して、事業的な優先順位と作業量から、どれが重要な機能なのかを見極めていかないといけないです。

■4.コミュニケーション

特にスクラッチ開発の場合、自分のチームの担当機能だけができればOK、なんて状況はあり得ないので、ほかの機能の担当者ともコミュニケーションがとれないといけません。

そういった時に、ざっくり「ここってどういう仕様ですか？」みたいな聞き方をすると相手もざっくりした回答になってしまいますよね。

例えば「そっちの機能でこういう形に加工されたデータがこっちに流れてくると思ってるんですけど、それで合ってますか？」みたいな、既に知ってる情報をもとにこっちの想定を提示した方が相手も答えやすいはずです。

こういったことは、SIerにいた頃に、他のチームともコミュニケーションがとれる窓口や、常に情報共有し合える状況を作ったりする中で学びました。

今はチーム単位ではなく個人で機能を担当していますが、チームでも個人でも、そのへんのすり合わせを普段から怠らないことは重要だと思います。

■5.何でもやるし誰とでも話す姿勢

エンジニアであればどんな会社でも言えるかもしれませんが、「とにかく何でもやろう」という姿勢でいたことは、ずっと生きています。

業種も技術環境も、本当に様々なプロジェクトのシステムに携わってきましたし、前述したような宙に浮いたタスクとか、炎上プロジェクトのヘルプとか、やったことある人がいない分野の作業とか、全部手を挙げてやってきました。もちろんめちゃくちゃ大変なときもあるんですが、乗り越えられたらそれは必ず自分のスキルになって、できることが増えます。

あと、お客さんもパートナー企業もあわせて本当にたくさんの企業の人たちと接してきたので、誰とでも臆せず話したり交渉したりできるヒューマンスキルやビジネススキルも上がりました。これは、例えばずっと特定の人達と同じサービスを作り続けるみたいな仕事をしていたら身につかなかったスキルだと思います。

SIerと自社サービスでは、得られるものが全然違います。中規模以上のSIerの場合はビジネスからプログラミングまで、かなりしっかりした教育をしている企業も多いので、先に経験しておいてよかったなと思っています。

だから、日本でももっと転職やフリーランスみたいな仕事の仕方が一般化して、やりたい人は受託開発も請けるとか、ずっと一つのサービスに携わるとか、もっと柔軟にできる世の中になったらいいなと思いますね。

■まとめ

転職で、今まで使ったことのない技術や開発経験のない分野へ飛び込んでいく場合、最初は誰でも不安を感じるかと思います。

ただ、実際に入社をしてみると、開発技術さえあればサービスは勝手にできていくわけではないことがわかるはずです。（当たり前と言えば当たり前のことですが）

既に運用されているサービスがあって、開発チームに入り、メンバーの人たちと一緒になって、新機能を考えて追加したり、既存部分を改修したりしていく……といった通常業務の中では、SIerで得たスキルや経験もすごく役に立ちます。

paizaでは、開発業務未経験の方や経験の浅い方でも、エンジニアとしての転職をサポートするサービスをスタートしました。

「EN:TRY」は、エンジニア職未経験者や経験が浅い方をITエンジニアキャリアへ導く転職サービスです。

これまでのpaiza同様、「EN:TRY」もプログラミング力、コーディング力で転職をする「コーディング転職サイト」です。転職希望者には「プログラミングスキルチェック」を受けていただき、提出していただいたコードをもとにスキルランクを評価します。求人には必要なスキルランクが設定されており、評価がそれを満たしていれば書類選考なしで応募が可能です。