Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
こんにちは、谷口です。
退職・転職エントリの記事は多々ありますが、転職を考えている人にとって参考になるのは、「転職を実際に経験した人が、その後どうなったのか？前職との違いをどう感じているのか？」といった後日談ではないでしょうか。
paizaを開発しているのは、ほとんどが転職を経て中途で入社したエンジニアです。
paizaで転職のご相談をいただく方の中には、SIerからWeb自社サービス系に転向したいという方が多いため、今回は、SIerからWebサービスを自社開発している弊社へ転職して半年～1年弱のエンジニア2人が、実際の業務を経験してみて感じた前職との違いを、開発環境や労働環境、モチベーションやキャリアについてなどあらゆる面において聞いてみました。
いずれは転職を考えている人、転職はまだ考えてないけどWeb開発ってどんなもんか興味がある人の参考になればと思います。
■聞いた人の簡単な経歴
◆中村
経歴：文系大学→文系大学院中退→SIer→自社サービス開発企業→paiza（ギノ）に来て1年弱です
※今回は一社目のSIerと比較しています
◆高村
経歴：大学（情報工学）→メーカー系の大手SIer(マネジメントに強みがあるところ…)→paiza(ギノ)に来て半年ぐらいです
■マシンなど
【前】
WindowsXP（Vistaをつかまされたらはずれ）のノートPCかデスクトップでモニタは増えぬ
Windows7(メモリ 4GB)、モニタは月額500円のレンタル制
【今】
MacBook Pro（16GB）＋大型モニタ
前職ではノートPCかデスクトップ一台で、モニタは追加なしでした。つらすぎたので、モニタ持参が許される常駐先には、自分で買ったやつを持参していました。許されない現場では泣きながらノートPCの画面だけで開発したりしてました。
今はノートの他にも大型モニタが支給されてますぅゎぁぃ！
余談ですが、前職で支給されていたマシンは、コンパイルをして新しいファイルができる度にウイルスバスターが動き出して全部のファイルをチェックするため、それで開発が中断されて全然進まない状況もよくありました。上司に「このウイルスバスターのチェックで生産性が落ちるから外してくれないか」と言ってみたら「できなくはないけど毎日外すための申請をする必要がある」と言われたので諦めました。
Macになったのも嬉しいですが、メモリが増えて固まらなくなったのが嬉しいです！前職のマシンはEclipseとChromeとExcelを同時に開くだけで固まっていたりしたので……。
前職では、大型モニタは月額500円のレンタル制でした。この500円はプロジェクトの予算から引かれるため、申請を出すとPMによっては「えーモニタ増やしただけの採算とれるの？」って聞かれるんですけど、「余裕でとれますが何か(^ω^#####)」って感じでした。
■開発言語
【前】
ほとんどJava
【今】
ほとんどRuby
Rubyは書きやすいし読みやすいんですが、今まで7、8年ぐらいほとんどJavaメインで開発し続けてきて、Rubyを業務で使うようになってからはまだ半年ぐらいなので、わからない部分や詰まっちゃうときも結構あります。
RubyはJavaより早く書けて書きやすい読みやすいのはとってもよいのですが、Javaみたいにコンパイル→エラーという段階を踏まなくても動かせて、実行して初めてエラーがわかったりするので、その辺はJavaに比べてちょっと怖いなーと思う場面もあります。プログラミング言語に貴賤なし…。
■テストツール
【前】
手動でテスト実施
【今】
自動でRspec+Capybara + PhantomJS
テストが自動になって、手間は本当に減りましたぅゎぁぃ！ただ、テストの重要さはもどこで何を開発するにしても変わらないことの一つだと思います。テスト大事。
■管理ツール
【前】
プロジェクト管理：Excel、バージョン管理：SVN
【今】
プロジェクト管理：JIRA、バージョン管理：git
JIRAはURLで情報共有できるし、変更ログも残るし、何より「【最新版】.xls」「【最新版】20161017_a.xls」とかの心配もなく、みんなで同じものを見られる安心感があります。
Excel時代のつらさはお察しください。つらすぎて先輩の中にはこっそりRedmineを使ったりしてる人もいました。
私はスケジュールが固まっている場合や長期にわたって管理をしなければならない場合はExcelでもいいと思っています。というか前職で自分がマネジメントに関わるようになってからは、タスク量が変わったりスケジュールが変わったりしないように（Excel管理でも不便が出ないように）心がけていました。タスクの増減が避けられない業務の場合はJIRAの方がいいです！
バージョン管理ツールに関しては、前職でも一度「git導入しましょうよ」となったのですが、そのとき社内のプロキシがそもそもGithubにアクセスさせてくれなかったのであえなく終了しました(-人-)ﾁｰﾝ
あとgitを導入するとなると、プロジェクトメンバー全員に使い方をマスターさせなければならないコストがかかるのも問題でした。技術に明るい人にとっては独学でgitを使うことなんて朝飯前だと思いますが、そうじゃないメンバーも多かったので…。
今はgitを使えるようになって、作業用ブランチを気軽に切れる（かつマージもめちゃくちゃ早い！！）ようになったのが嬉しいです。ネットワークにつなげない状態でも、ローカルだけで作業できるのもありがたいですね。
■その他環境について変わったこと
【前】
プロキシの設定によりアクセスできるサイトがあって調べものにも制限があった
【今】
プロキシ制限なし
繰り返しになりますが開発現場でGithubにアクセスできないってやばくないですか！？！？！？！？？！！！？システム開発を担う会社として本当にこれでいいの？？？とずっと感じていました。Githubだけでなく、調べ物をしていると頻繁にプロキシブロックにひっかかるので、「生産性とは……？」と思っていました。
【前】
ステージングサーバや本番環境に近い状態のテスト環境はなし、サーバは本番環境用のみ
【今】
ステージングサーバや本番環境とほぼ同じノック環境（※）がある
前職ではサーバは本番環境用のが一個あるだけのプロジェクトがほとんどで、軽い機能を一個追加しようと思っても、毎日決まった時間にしかデプロイできなかったり、デプロイを実行できる人が決まっていて、その人を通さないとできなかったりしたため、本当に無駄な手間が多くて泣きながら開発したりしていました。
今はステージングサーバや本番環境とほぼ同じのノック環境があって、機能を一つ作ったらすぐに本番に近い環境で動かしてみたり、本番環境に追加したりできるのが大変よいです。
※ノック環境：本番に反映する直前に利用するステージング環境とは別に、開発途中のものなどをチームメンバーで叩くための本番相当の環境を構築しており、内部的にノック環境（1000本ノックにちなんで…）と呼んでいます。
■開発手法
【前】
ウォーターフォール
【今】
基本はスクラム開発だけどまあ臨機応変（ウォーターフォールで開発することもあります）
企画や機能によって、作ってすぐにリリースしてユーザーの反応を見ながら手を加えていく場合もあれば、エンジニア以外の人が企画・立案したものを受けて、要件のすり合わせから始まってスケジュールを決めてそれに沿って開発する…というウォーターフォール形式で作る場合もあります。その辺は企画や機能によってまちまちなので臨機応変になっています。
完全に受託開発だった頃よりも調整しやすくはなりましたが、開発に当たって発案者とエンジニアの合意をとって意識をすり合わせておくのが重要なのは変わらないです。すり合わせ大事。
本来のウォーターフォール開発は、上流で一度ゴールを決めたらそれは変わらない開発手法なはずなんですけど、前職ではなぜか中流・下流に来てから頻繁にゴールが変わってそれなのに納期は変わらないという闇が…おや、誰か来たようだ…
今はスケジュールも相談の上で決められますし、今日は予定があるから早く帰ってその分明日作業しようとか、調整は前よりもずっとしやすくなりました。
あと手法というか大きな視点の話になりますが、改善し続けながら数値を追い続けなければならないので「ここまで作れば一旦終わり」だった前職と比べるとプレッシャーの質も変わりましたが、どんな企画や機能も突き詰めるとpaizaが掲げている「日本のエンジニアの地位を上げる」という目的が根底にあるため、納得感を持って開発できるようになりました。
■リリース作業
【前】
月一回程度、サービスを停止して夜間リリース（オンラインリリースの場合もある）
【今】
機能ができたら、随時リリース（通常サービス停止はしない）だけどまあ臨機応変（リリース日が決まっているものは、随時ではなくまとめてリリースすることも）
前職ではお客さんの環境へのリリースだったため、会社として責任の所在を明らかにしておくために、まず申請をして許可をとってから夜間にリリース…ということが多かったです。
今は自社サービスなのでそういったしがらみはなくなり、自分の判断で実装方式を決めて、本番環境に組み込む場面もあるのですが、自由度が高くなった分、不安に思うことも多いです。
開発自体も基本スタンドアロンで進んで行きますし。既存機能に関わる部分など、不安が出てきたときにどこまで人を巻き込むかは、自分でなんとなく不安の閾値を決めておいて、それを超えたら自分だけで進めないようにするとかしています。
どこまで自分の判断でやるべきかは、ジョインしてすぐはわからなくて戸惑うことが多いかもしれませんが、チームごとに文化があると思うので徐々になじんでいけると思います。
自分で判断する裁量はかなり増えました。逆に自分で決めたり判断したりするのが苦手な人や、決められた業務をきっちり進めていくことが得意な人などは、SIerの方が向いてると思います。（もちろん、根拠の無い勝手な判断をする人もWeb系には向いていないと思います。）
■会議形態
【前】
オンライン上で担当分の進捗報告をしてコメントを受ける、朝会でリーダーの決定が報告されるなど
適宜、自分が報告を受ける会議（なるべく減らしてた）と自分が報告をする会議があった
【今】
デイリースクラムミーティングが毎日30分ずつ、スプリント成果報告ミーティング・スプリント計画ミーティングが週各1回1.5時間ずつ
入ってすぐは正直「めっちゃミーティング多いな、負担になりそう…」と思っていたのですが、いつもきっちり時間を区切っていますし、自分が追いかけるべき数値ややるべき作業を明確にすることで、自分の頭の中を整理できる（必然的にしないといけなくなる）ので、思ったより負担には感じていません。
前は個々の進捗はPMだけが把握していればよかったのですが、今は他の人の進捗も気にするようになりました。「その作業とこの作業ってコンフリクトしそうじゃない？」といったことも未然にわかったり、合意をとったりできますし。開発者同士のコミュニケーション量はめちゃくちゃ増えましたね。
前職では、自分が報告を受ける側になる会議は「無駄だなー」と感じていたので、上の立場になってからは、普段から開発中に進捗を聞いたり様子を見るようにして、自分の判断で無駄な会議はなるべく減らしていました。自分が上に報告する会議は絶対にしないといけないのでどうしようもなかったですが……。
今のスプリントミーティングやスクラムミーティングは正直言って多いなーと思いますが、みんなが「そういう仕組みだから変えられない」とは思っているわけではなく、もっといいやり方があればすぐに変えてみたり、新しいやり方を取り入れたりということが会議形態に限らず実施できていますから、それは小さな組織ならではの強みだなと思います。今の会議形態も変遷を経てきた結果ですし。
前職では、大きな組織の中で組み込まれていて変えられない仕組みがほとんどで、疑問を感じても「そういうものだから」と受け入れるしかなかったことが多かったですが、今は組織全体の仕組みもどんどん柔軟に変わっていくので、その分、エンジニアも組織論や会議体のあり方などを勉強していかなければならないと思っています。（勉強できているとは言ってない）
■勤務形態
【前】
勤務時間はお客さん次第、残業代は全部つく
裁量労働制（裁量なし）
【今】
裁量労働制（裁量あり）
前職では残業代は全部出ていました。ただプロジェクトによっては三六協定にひっかかったりプロジェクトの予算を超えたりしちゃうから来月に回してくれーとPMに言われることもありました。
あと、勤務時間は常駐先の都合に合わせないといけないため、早いところでは8時半に出勤して、プロジェクトが炎上したら徹夜して…ということもありました。
今は完全に裁量労働制で、朝は大体10時半頃の出勤なので毎日二度寝できるし、今日は好きなバンドのライブに行くから定時より早く帰ります、とかもできるようになったので自由度はかなり高くなりました。もちろん自由がある分、各々でしっかり管理・調整をしないといけないため、効率よく働くことを常に考えるようになりました。
前職では残業30時間はみなし残業でした。一番ひどいときは大型連休中の休出も合わせて残業月200時間ぐらいでした。そのときは、とりあえず完成させてリリースすればこんな状態は終わるから！！というプロジェクトだったのでなんとか乗り切ったんですが、それよりも月80時間ほどの残業が一年ぐらい続いてた時期のがしんどかったかもしれません…。
当時は「裁量労働制（裁量があるとは言ってない）」という感じで、例えば前後の業務を調整してこの日は早く帰りたいと思っても、「保守作業」という魔法の言葉によって後から割り込みや突発的な業務が頻繁に入ってくるのでなかなか調整できませんでした。保守担当のメンバーが割り当てられているわけではないため、通常作業の手を止めて割り込み業務に当たらなければならず、生産性もがた落ちでした…。
今は保守みたいな業務に当たることはないので、計画がズレたりしても「どこがまずかったんだろう？」という分析がしやすくなりました。生産性も高められますからやる気もすごく出ます。あと本当に裁量があるので、自分で調整して今日は早く帰りますということができるようになりました。
朝の出勤時間は、私はそこまで変わってません、子供を保育園に連れていくのでその時間に合わせて出勤しています。
■給与
上がりましたとだけ……。
少し詳しく言いますと、前は残業代が全額ついてはいましたが、今は裁量労働制の年俸制で、一番残業してた頃と同じぐらいの額になってるかなと思います。その分業務範囲は大幅に広がってますが、トータルの労働時間は前よりもずっと短くなっています。
■評価制度
目標設定や振り返りを記入して、上司と面談……という評価方法自体は変わっていません。
ただ、前職はプロジェクトが炎上すると一律評価は下げられていたのです（所属部署やプロジェクトごとに予算は決まっているので仕方ないかもしれませんが…）、「この炎上、俺の頑張りでどうにかできたもんじゃないだろ！」というプロジェクトでもマイナス評価になってしまって、そこはやるせなかったです。
■オフィス内・近隣の設備など
【前】
コンビニ遠すぎ・オフィス内は自販機だけ・人が増えると開発スペースが減っていく
自販機、社員食堂、売店、近くのコンビニはローソン
【今】
コンビニ（セブンイレブン）まで30秒・オフィスグリコ・水は飲み放題・デュアルモニタを置ける固定スペース
自分が主に常駐してた現場は超郊外でコンビニが超遠くて飲み物やお菓子は自販機（争奪戦なのですぐに売り切れる）しかなかったし、あとプロジェクトが炎上して人が投入されると、その分一人一人のスペースを狭くされていくのがつらかったです。
今はコンビニがすぐそこにあるし、大型モニタが置けるスペースも固定で確保されてますぅゎぁぃ！
前はまあ大きな企業だったので社食があってそれはよかったんですが、今は水がタダで飲み放題だし、最寄りコンビニがセブンになったのが大変嬉しいです。コンビニの中でセブンが一番好きぃ！
■求められるスキルと勉強に関して
【前】
マネジメント力、折衝力、技術力
【今】
技術力（アイディアを具体的な形にするスキル）、企画力（0ベースでそもそものアイディアを生み出すスキル）、分析力（次のアクションをどうしていくべきか考えるスキル）
前職では、マネジメントのスキルや、何らかの問題が起きたときに解決に近づけるスキル、技術的な問題を発生させないためのレビュー力や問題が発生してしまった場合の解決策の立案などができることが求められていました。（できてないPMいっぱいいましたけど…）
今は技術力が求められるのはもちろん、開発だけしていればいいというわけでは全然なくて、エンジニアでもマーケティング力や企画・ブランディングを考えるスキルが必要になったと感じます。
前職でも仕事を得るために自分がお客さんへプレゼンすることもありましたが、その時の目的はあくまでお客さんウケを狙っていたので……。前は対お客さんで考えていたのが、今は対ユーザーに変わったのも大きいですね。
勉強に関しては、前職では会社的にPM系のマネジメントができるようになってほしいという感じで、マネジメントスキルの教科書が与えられたりしていました。
私は技術的な勉強の方がしたかったので、自分で新しいツールやフレームワークの勉強をしていましたが、そう簡単に導入はできないので、入れられるところにはこっそり勝手に入れたりしていました。(実績がないと新しいものは入れられないというジレンマ…)
正規ルートでの導入を目指すと、上層部に申請してかなりいろいろな検閲（めちゃくちゃに面倒くさい）を通過できないと導入できなくて本当に大変だったので……そこまでやる気がある人はあまりいませんでした。
今はリスクや費用対効果をエンジニアみんなで考えて、勉強したことをもとに導入すべきかどうかが柔軟に検討できるようになっています。前みたいなしがらみはなくなってよかったです。
前職は、自分がいた会社の場合はある程度業務経験を積んで中堅社員になってくると、マネジメントに回りつつ、ただどこのプロジェクトも人が足りなくて炎上し出すまで人が追加されないのがほとんどだったので、マネジメントもするし開発もしなければならない都合の良い役割を求められる状態でした。
今は、開発スキルだけでなく、収益を上げるためのPDCAを回すのに、自分でデータをとってきて分析をして、どう改善すべきかを考えないといけないので、その辺の分析力や企画力も必要だなと思います。まだまだ勉強中ですが…。
あと、それに伴う勉強に関してですが、前は技術的なことだけでなく、あまり汎用性のない業務知識を業務時間内に勉強しないといけないプロジェクトもありました。今は、Rubyとかフロントエンド周りの勉強が必要になっています。
ただ、前職ではプロジェクトによってはシステムの構成から考えないといけないこともあったため、それはかなり勉強になりました。
paizaは、既にサービスができていて機能やページを改良・追加していく状態なので、システム刷新でもない限り初期の構成から考える必要はないですから、その辺は前職の方が勉強になったかもしれないです。実装方法を選択する裁量があるので、RoRやフロントエンドに関する知識は現職の方が勉強になります。
■モチベーションについて
モチベーションになっていたこと
【前】
期間内に決められたとおりの開発を終えて納品すること
【今】
いかにサービスをよくするか・ユーザーの反応
前職ではプロジェクトごとに「この機能をこの期間で作り切る」という契約で、リリースを一回したらその後のことはわからない状態だったため、リリースまでが長いとモチベーションを保つのが大変だったり「リリース後にバグが出たらどうしよう」というプレッシャーもありました。
今は早い段階で作ってリリースしてユーザーの反応をすぐに見られるので、それはモチベーションにつながっていますね。
モチベーションの変遷
【前】
最初はできることが増えていくことがモチベーションだったけど、5年目ぐらいから右肩下がり。
【今】
日本のエンジニアの地位を上げるというサービスとしての目的
前職では、最初は開発業務を幅広く経験して、できないことができるようになっていくのがモチベーションになっていましたし、自分は開発が好きだと感じていたので、開発できることもエンドユーザーの反応もやる気につながっていました。
しかし、年数を重ねると「そろそろ開発やめてマネジメントに回って」って言われたり、5年目くらいからあまり変化のない既存プロジェクトの細かい修正ばかりが増えて、新しい勉強や挑戦が必要になる場が全然なくなってしまったりして、その頃からモチベーションは右肩下がりになっていきました。
私は前職で、よくない環境に置かれているエンジニアが多いと思っていたので、今はそこを課題視し、エンジニアの地位を上げるというサービスの主目的自体が大きなモチベーションになっています。
■キャリアについて
【前】
だんだんマネジメントにまわっていくというキャリアパスが用意されている
【今】
自分で考えて決めて実行していかないと何にもなれない
私は今後は開発とサービス企画両方を回していけるジェネラリストを目指したいとは考えているのですが、わかりやすいキャリアパスがあった前職と比べて、今はどんなキャリアを目指すのか、それに向かってどんなことに取り組んでいくのかは全て自分で考えて（もちろん相談はできますが…）実行していかないと何にもなれないので、そこはかなりプレッシャーに感じています。paizaを作ってる割に、自分のキャリアについて考えるのは苦手です。
前職では、早い段階から「マネジメントはあんまりやりたくないなあ」と思っていました。人事の人も「これからは技術のエキスパートも育てていかないと…」と言っていたので、「じゃあ『こいつにマネジメントやらせるのはもったいないぞ』って思われるぐらい技術を極めよう」と思ってずっとやってきたんですけど、「そろそろ開発は卒業して」って言われて、結局マネジメントのキャリアしか道がなかった（人事は言ってるだけだった）ので、だめだこりゃ…という感じでした。
今後のキャリアについてですが、paizaの中のエンジニアは徐々に増えてきていますから、いずれもっと大きなチームをまとめなければならなくなってくると思います。近々のキャリアとしては、その中でプレイングマネージャーみたいな立ち位置で、自分も動きつつ、周りの人も独立して動けるようにしつつ、新人を教育したりして、チームを推進していく立場になっていくことを考えています。
■業務遂行の目的
【前】
主に発注者のため
【今】
企業の目的として「日本のIT/Webエンジニアを、世界レベルに引き上げる」ため
SIerにいた頃は、主にコンシューマ向けサービスのプロジェクトにいることが多かったので、エンドユーザももちろん意識していました。が、受発注の契約である以上、どうしても契約遂行（≒納品)のためにどうするか、お客さん（エンドユーザではなく発注元）優先で考えなければならない場面が多く、大きなジレンマがありました。
当然ながらSIerの場合は開発業務の受発注が仕事なのに対して、自社サービス開発の場合、Web開発は開発自体が目的ではなくあくまで手段であって、それを使って何を成し遂げるかが重要になってきます。
■逆に変わらなかったこと
当たり前ですが、前半に言ったような開発における大事な部分の大事さは変わらないです。テストが大事とか、開発チームのみんなと合意をとっておくのが大事とか。
変わらなかったというか、入社してちょっと意外だったのは、エンジニアチーム、営業チーム、事務局チームというように、意外と独立・分断されていて横串が通ってないというか…今の組織規模でなら特に問題はないいいですけど、もっと人を増やしてスケールするなら、今のままだとシナジーが生まれにくいかもしれないなと思っています。
■前職への心残り
心残り…僕の力では「何事もstep数で換算するのをやめさせること」ができなかったのは悔しく思っています。
今は、「step数は多ければいいというわけではない（というか可読性が保てていれば少ないほうが素晴らしい）」という当たり前の価値観がある現場に来られたことが嬉しいです。
■まとめ
SIerとWeb開発における業務では、環境や求められる成果等で異なる部分が多く、「転職に興味はあるけど初めてだし不安で踏み切れないでいる」「どんな違いがあるのか把握できていない」「面接で聞かれた質問にうまく答えられなかった」という方からご相談を受けることもよくあります。
paizaの運営に携わっていて思うのは、転職したいエンジニアの方は本当にたくさんいます。しかし、例えば同じような転職活動をやったとしても、同じ企業に入社したとしても、その人の目指したいキャリアやこれまでの経験・スキル、転職先について重視したい点や、やりたいことや好きなことなどなどによって、感じ方や合う・合わないはかなり変わってきます。
転職について不安を感じている方、転職経験者の話を聞きたいという方も多いので、この記事があくまでひとつの事例として参考になればと思います。
paiza運営元のギノではRailsエンジニアを募集しています。今SIにいるけどWeb系に行きたいという方も歓迎です！
【paiza開発】Web開発Railsエンジニア（就職/転職/教育系事業）
↓トップ画像の漫画はこちら
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら
