「SI⇒Web」転職は可能？ 技術者に必要な能力と意識：特集：岐路に立つIT技術者たち（3）（1/2 ページ）
SI企業とWebサービス企業は、求められるスキルや考え方にさまざまな違いがある。SI企業で働いてきたエンジニアがWebサービス企業へ転職する際、どんなスキルや考え方が要求されるのか？ DeNAで採用と育成を担当するエンジニアが語る。
「プログラムや機器を動作させて、それを何かしらの役に立てる」。この点についていえば、SI企業でもWebサービス企業でもエンジニアの仕事は同じである。だから、SI 業界のエンジニアがWebサービス企業に転職しても、十分戦力になる。システム開発や運用をSI企業にアウトソースしているWebサービス企業の場合、求められる「スキル」や「考え方」はほとんど変わらないこともある。
ただ、ディー･エヌ･エー（DeNA） のように、エンジニアをビジネスの中核となる「戦力」としてとらえて仕事のやり方を最適化している企業の場合、SI企業とは違った「スキル」や「考え方」をエンジニアに求めることが多い。筆者は、DeNAでエンジニアの採用と育成を担当している。本稿では採用と育成を担当する者としての視点から、Web企業とSI企業で求められる「スキル」や「考え方」の違いを紹介し、SI企業に勤めるエンジニアがWebサービス企業に転職する際、要求されるポイントを説明する。
特集：岐路に立つIT技術者たち バックナンバー
- 第1回 「環境変化に対応した技術者」になる道を探して
- 第2回 【転職市場動向】あふれるPGとSEはどこへ行くのか？
- 第3回 「SI⇒Web」転職は可能？ 技術者に必要な能力と思考
- 第4回 現場の技術者が考える「1〜2年後の自分の姿」
- 第5回 「人月・受託の限界を超えよ」SIerでSaaSを立ち上げる
まずはスピード力：「考えた人が作るのが一番速い」
Webサービス企業の場合、サービスのリリースタイミングは早すぎても遅すぎてもいけない。例えば、「モバゲータウン」はパケット定額制が導入されて携帯電話向けの広告ビジネスが一般的になった後にリリースしている。もし、パケット定額制が導入されるよりも前にリリースしていたら、サービスの受け入れられ方はきっと異なっていただろう。
ただ、この世界のビジネス環境は変化が激しい。「いまがチャンス」と判断したら、他社が実現する前にリリースした方が勝機は高まる。顧客企業と約束した納期ではなく、自社ビジネスの成功確率を高めるための「開発スピード」が要求される。
また、Webサービス企業は前例がないものを作ることが多い。最近では、ソーシャルゲームの開発がそうだ。前例がないものの場合、提案書などのドキュメントベースでは「これがいいものなのか、そうでないのか」という判断がつきにくい。そのため、まずはWebサービスを作ってみて、できあがったものを見ながら機能を確かめ、改善していくことが多い。
このような背景があって、DeNAでは「『考える人』と『手を動かす人』を分けない」という方針を取っている。SI企業の場合、売り上げは人月で決まることが多い。つまり、かかわる人間が多いほどビジネス規模が大きくなる。Webサービス企業ではそのような原則はない。同じことを実現するなら、人数が少ない方がコスト削減できるし、意思決定や開発のスピードは上がる。そのため、DeNAでよくこういわれる。「考えた人が作るのが一番速い」。
上記のような環境では、
- 何を作るべきか自ら考える能力 ＝ 企画・要件定義力と能動性
- 考えたものを簡潔に実現できるコーディング能力
がエンジニアに求められる。
企画力と能動性：「何を作るべきか」考える
SI企業では「何を作るべきか」は、顧客企業が中心となって検討することが多いのではないだろうか。DeNAは、「エンジニア自らが考えることがベスト」と考えている。ほかに企画者がいる場合でも、エンジニアは体裁の整ったドキュメントから作るものを把握するのではなく、ラフスケッチや打ち合わせを通してどういうものを作るべきか理解し、よりよいものが思いつくのであれば逆提案する。「要求者が誰であるか」より「良いサービスを作る」ことの方が重要で、そのためにはかなりの能動性が必要となる。
受託開発においては、要求者は顧客企業であり、開発者は受け身の立場である。このような環境に慣れたエンジニアにとって、「役割の線引きをせずに目的達成のためにどれだけ能動的にかかわれるか」「自分で仕様を決定する力が持てるか」は、第1のハードルになっている。
「何を作るべきか考えられる」ということは、
- 担当サービスや競合サービスのみならず、それを取り巻くビジネス環境も理解している
- 「仮説を立ててデータなどを分析して検証する」というサイクルを回せる
ということだ。要求されたものを作る場合より、だいぶ広範囲の知識やスキルが要求される。整えられた一式の資料に目を通せば理解できる、ということではない。自発的に知識を吸収していく必要がある。この点では、Webサービスにもともと強い興味を持っている人の方が有利であるといえよう。
コーディング力：どれだけ「修正しやすい」コードを書けるか？
「考えた人が作るのが一番速い」ということは、つまり「企画力がある人がそのまま実装するのがベスト」ということである。つまり、コーディング能力が重要となる。とはいえ、企画したものを作ってしまえば目的達成というわけではない。作ったサービスが目標の売り上げやPVなどを達成したとき、初めてゴールとなる。
そのため、Webサービス企業にとっては、リリース後が勝負となる。実際、ユーザーに利用してもらって初めて気付くことは数多い。ユーザーの反応を見ながらサービスをチューニングしていくサイクルを回す。サイクルをどれだけ短く、数多くこなせるかが勝負である。これを実現するためには、「どれくらい修正しやすいコードを書けるか」が鍵になる。
SI 企業で働いていたITエンジニアの経歴を見ていると、新卒当初はコーディングをしていても、その後は外部仕様の設計を行い、実装は人に任せて、その設計に沿ったシステムになっているかの受け入れテストだけを担当するケースが多い。 背景には、「経験豊かなエンジニアは、コードより業務知識、仕様策定や人員管理に重点を置いた方がよい」という考え方があるのではないだろうか。
ここにもWebサービス企業とのギャップがある。仕様を決める人は、自分でコードを書いて、リリース後も処理の把握や修正が容易であるようなコードを維持する能力が求められている。
Copyright © ITmedia, Inc. All Rights Reserved.