実体験からSIerと自社製品/自社サービス開発部門の違いを書いてみる

キャリア | ワークスタイル | 職場 | 転職活動

» 2014/08/19

■両方経験しました
　少し前に「ソフトを他人に作らせる日本、自分で作る米国(谷島宣之著・日経BP社)」という本を読みまして、これは日本のIT産業の構造的問題を理解する上では非常に役に立つ良書だと思ったのです。日本ではシステム構築をSIerに丸投げすることが多く、アメリカでは外注せず自社内で開発することが多い、という違いが種々多様な違いを生み出しているんですよね。最近では日本企業もシステムの内製化を進めているという話ですが、業界構造が変化するにはまだまだ時間がかかるでしょう。そういえば僕自身もけっして大規模ではないとはいえ「SIer」と「自社製品/自社サービス開発部門」の両方を経験した身であります。そこで今回は、自分の実体験をもとに感じていることを書いてみたいと思いました。

　僕の略歴としては、社会人2年目に電機メーカーからIT業界に転職し、最初はエンジニア派遣とSI業を営む小さな会社に入りまして、まず派遣エンジニア、次に自社内でSI業の業務を行いました。その後さらに転職し、現在はIT企業で自社製品/自社サービスの開発を行う部門にいます。（ちなみに派遣時代の派遣先としてもSIerと自社製品/自社サービス開発部門の両方の経験があります。）

　なお、「ユーザー企業のIT部門」と書かずに「自社製品/自社サービス開発部門」と書いたのは、情報システム部などの間接業務部門ではなく、ビジネスに直結する部門であることを示すためです。

■開発プロセスの違い
　まずは、開発プロセスの違いについてです。この点の違いは巷で言われている通りだと思います。派遣先のSIerにいた時も、自社でSI業務をしていた時も、基本的にウォーターフォール型の開発プロセスでした。最初に要件定義があり、基本設計、詳細設計、実装、テスト、納品という流れです。教科書通りですね。全てのプロジェクトでこれらの全部の工程に最初から最後まで関われたわけではなく、実装からとかテストからとか、途中から参加することもありました。もちろんガントチャートは必ず渡されて、スケジュールは今どのあたりなのか、は全員で共有してました。

　一方、自社製品/自社サービス開発部門の場合、開発プロセスなどほとんど無いようなものです。要件定義・設計・実装などの明確な区切りは存在しません。アジャイルですらない現場もあります。その場合、管理するのは期限のみで、進め方は各エンジニアの勝手に任せるという感じになります。スケジュールのスピード感もまるで違います。ある新機能を2日後までに追加しろ、とか実際に言われたこともあります。こうなると確かに開発プロセスなど意味がありません。とにかく求められるスピードが全然違うことだけは確かですね。

　このように書くと自社製品/自社サービス開発部門の方が大変に感じるかもしれませんが、SIerにおいて、もしプロジェクトが炎上すると激務度は急激に跳ね上がるのでむしろSIerの方が大変になります。デスマーチに巻き込まれ、極限まで働いたが結局プロジェクトは失敗して大赤字を出しチームは解散、なんてことも実際にありました。

■求められる知識や経験の範囲の違い
　SI業務をしている場合、求められる知識は経験は限定的なことが多いです。例えば、最初の現場ではテスターでしたので、テスト仕様を考え、動作確認をして、バグ報告をする。その繰り返しでした。その現場ではUI担当、業務ロジック担当、バッチ担当など役割が技術領域ごとに分かれていました。それによって使用する言語も分かれていたりします。例えば「Javaでバッチを書く専門家」がいるわけです。また、プログラマとSEといった伝統的区分も存在します。場合によっては兼務だったりペルプのために役割を飛び越えたりすることもありますが、一応分かれています。特定の分野・役割に特化した専門家が活躍している印象です。

　一方、自社製品/自社サービス開発部門の場合、いわゆる「フルスタックエンジニア」として振る舞うことが求められます。必要なら何でも学んでやっていかなければいけません。特定の技術領域だけやっていればいいなんてことはありません。ある時は要件定義とUI設計とDB設計をこなし、ある時はLinuxの起動プロセスとログ出力の設定を行い、ある時はSQLをカスタマイズし、ある時はHTML5とCSS3でデザインをいじり、ある時はPHPとRubyとPythonの全部が別々の場所で使われているソースコード群をそれぞれ同時に変更する、といったことが起きます。求められる知識の幅は広いです。と言うか、プロジェクトに関わることなら全部です。もちろんプログラマとSEの区分は意味を成しません。

■給料に対する考え方の違い
　実はこれも違ってくるんですよ。残業代に関する考え方まで異なってきます。

　SIerにおいて、エンジニアの給料は受託したプロジェクトの売上が元手です。プロジェクトの受託を決めた契約の時点でプロジェクトの売上は（ほとんどの場合）決まっており、そこからエンジニアへの報酬を差し引くことになります。会社からすると、エンジニアの給料は単純にコストです。残業については、スケジュールに間に合わせるためやむを得ない場合に行われます。エンジニアが残業をすると、その分会社の利益は減ります。エンジニアの残業は、会社にとって損でしかありません。この構造は現場のエンジニアの意識に対しても影響を与えることになり、「自分たちはコストであり、やむを得ず残業することは会社に損害を与える行為である」という意識につながります。

　一方、自社製品/自社サービス開発部門の場合、エンジニアの給料の元手は自分たちが創っている製品/サービスの売上です。これは、プロジェクトが進行中の時点では当然ながら確定しません。むしろ、自分たちの仕事次第では増える可能性もあります。会社にとってエンジニアの給料は、売上を生み出すための投資です。残業については、ビジネスチャンスを獲得するためやむを得ない場合に行われます。エンジニアが残業して行った作業により、ビジネスのタイミングを逃さずに済み、売上が増える可能性があります。現場のエンジニアに対しては「自分たちは利益の源泉であり、やむを得ず残業することも貢献につながる行為である」という意識につながります。

　別に残業を肯定したいわけじゃありませんが、捉え方が全く違ってくるということです。

■結局どっちがいい？
　それで結局僕自身はどちらがいいと思っているかというと「自社製品/自社サービス開発部門」です。実際に両方の立場を経験してみた身として、こちらのほうが楽しいと感じました。よりクリエイティブな仕事ができると思いますし。