開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ）

元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。

[きのこる先生，＠IT]

　皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。

　師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。

繰り返す、ここはSIerではない

　さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。

　SIerは、長引く不況とIT業界の構造変化から、じりじりと減益しています。そのため、SIerに所属しているエンジニアからは、スマートフォンやソーシャルゲームなどで勢いのある「Web系企業」への転職志望者が増えています。私のところに届く書類にも、かなりの割合で「SIerから脱出したい」という気持ちがにじみ出ています。

　しかし！ ここで採用担当菌類として声を大にして言いたい！

　「お前ら準備しなさすぎ！」

　同じソフトウェア開発の仕事であっても、SIerとWeb系企業には大きな違いがあります。それを認識しないまま突撃しても、手元に届くのは「お祈りメール」の山だけかもしれません。

　今回は「SIerからWeb系企業へ転職したいなら、事前に知っておくべきこと」を紹介します。

　その前に、まずはざっくりと用語の定義をしておきましょう。

　「SIer」と「Web系企業」とざっくりくくりましたが、厳密な線引きは難しいところです。研究開発をしたり、自社プロダクトを出しているSIerもあるし、受託開発がメインのWeb系企業もあります。

　いろいろな業態や社風があるため、上の図はあくまで参考です。マトリクスの左上に行くほどより“SIer的”、右下に行くほどより“Web系企業的”と思ってください。

●このビッグウェーブ、乗るしかない……？

　人事担当として日々書類選考や面接をしていると、左上（業務寄り／受託寄り）から右下（コンシューマ寄り／自社寄り）を目指す、強い“流れ”のようなものを感じます。転職活動に踏み切った理由や志望動機を聞いてみると……

• ユーザーの声をダイレクトに聞ける環境を志望しています
• 納品して終わりのシステム開発ではなく、自分のサービスとして開発に関わりたいと考えています
• エンジニアとしての意見が反映される仕事がしたいです

という話がとても多いです。「受託開発で手離れしてしまうものより、自社サービスや自社プロダクトを」「使い道の想像できないBtoBのシステムよりは、皆が使うBtoCのサービスを」という意向が強いようです。

●見てるだけじゃ何も始まらない

　なるほど、右下に行きたい気持ちは分かりました。しかし、そういう人々の応募書類には「上流工程に進みたい」とか「顧客折衝が得意です」と書いてあります。「左上スキル」をアピールして、Web系企業でどんな仕事をしようというのでしょうか。あなたを採用すると、弊社にどんなメリットがあるのでしょうか？ イオナズンとは何のことですか？

　おっと、圧迫面接っぽくなってはいけませんね。きのこの名がすたります。お伝えしたいのは、「郷に入っては郷に従え」ということ。左上から右下に行きたいなら、そこで歓迎されるアピールをし、そこで要求されるスキルや考え方を身に付ける必要があります。

「Web系企業への転職」でこの先生きのこるには

　では、左上出身のエンジニアが右下への転職を目指す場合、どうすればいいのでしょうか。気を付けるべきは、「SIerとWeb系企業のギャップ」です。

　Web系企業でエンジニアとして活躍するためには、受託開発／業務システム開発の世界での常識を、いろいろ投げ捨てる必要があります。かつて私も、さまざまなものを捨てました。捨てるべきものは、大きく3つに分類できます。

• 開発手法を捨てろ
• コミュ力を捨てろ
• 幻想を捨てろ

開発手法を捨てろ

　はい、まずは開発手法を投げ捨てましょう。

　ここでいう開発手法とは「ウォーターフォール」とか「アジャイル」とか呼ばれるもののことです。「SIer＝ウォーターフォール」「Web系企業＝アジャイル」とまとめると各所から粘菌が飛んできそうですが、私の経験上、そういう傾向は確かに存在します。

●開発スタイルの違い

　SIerはどちらかといえば、ウォーターフォールモデルで開発することが多いようです。「要件定義→設計→開発→試験」の各工程を厳密に分割して行い、前の工程に戻ることを基本的に良しとしません。つまり、手戻りはプロジェクトの失敗に直結しています。こういう開発手法がなぜ生まれ、なぜ定着しているかは長くなるので割愛しますが、業務システムを受託開発する場合はこのスタイルが大半、といってもいいでしょう。

　逆にWeb系企業では、アジャイル開発手法を取り入れているところが多いです。自社のサービスを日々運用する上では、刻々と変化する社会情勢やユーザーニーズに対応していく必要があります。そのため、「アジャイル開発を取り入れています」と標榜していなくても、自然とアジャイル開発手法の要素を取り入れている現場はたくさんあります。おそらく、がっちりしたフォーターフォールでは変化についていくことが難しいためでしょう。

●「変化を受け入れる」ことを受け入れる

　つまり、程度の差こそあるものの「変化を受け入れる」というスタイルに馴染む必要があるのです。

　「SIer残酷物語」定番のエピソードとして「ころころ変わる仕様のせいでプログラマはデスマーチ」などというものをよく目にします。しかし、Web系企業では、仕様どころか要件さえ日々変化することが日常茶飯事です。ですから、「変化を受け入れる」という考え方に、まずはエンジニア自身が「変化」する必要があるのです。

　しかし、常に変化の連続と立ち向かいながら開発を行うWeb系企業へ転職しようというのに「上流工程の経験があります」「プログラマのみならず設計者として成長したいと思っています」という真逆のアピールをしてくる候補者が後を絶たないのは、とても嘆かわしいことです。

　Web系企業では、サービス開発において「企画」「設計」「 開発」といった職務境界が曖昧です。日々変化する要求に素早く対応するためには、担当職務にとらわれている場合ではないのです。

●上流も、下流も、ないんだよ

　いかがでしょう、Web系企業への転職を考えているにもかかわらず「上流／下流」とか「プログラマ／SE」とか言い出すのがどんなに馬鹿馬鹿しいことか、お分かりいただけるでしょうか。設計しかできない人、「プログラミングは下流の仕事だからやらない」という人は、残念ながらWeb系企業に居場所はありません。

　Web系企業では、役割を厳密に規定しない「職能横断型チーム」で開発していることが多いので、「職務を限定するような考え方」は敬遠されます。「職能横断型チームの一員」としての要求に応えるために、応募書類や業務外の取り組みでは、以下のことを心掛けてみましょう。

• 設計が得意な人

　設計は非常に重要なスキルです。良い設計は実装を簡潔にし、バグを減らします。しかし、Web系企業においては「設計書」は重要な成果物ではありません。自分で手を動かし、設計を実装に落とし込む経験とスキルを磨き、アピールしましょう。

• 実装が得意な人

　もちろん、プログラミングスキルが大事なのは言うまでもありません。しかし、SEから降りてきた設計書をコードに書き写すだけでは「プログラマ」ではありません。今は上流工程の経験がないとしても、SEの仕事を盗むことはできないでしょうか？ 仕事で経験することができないのなら、業務外でやりましょう。Webサービスの設計から実装、リリースまで1人で行った、というアピールは有効です。