SI企業と自社開発企業の違いについてのお話

はじめに

はじめまして。

現在、OLTAでエンジニアとして、クラウドバンキング『INVOY』の機能の設計や開発周りを担当している大網（おおあみ）です。このページにテック情報を期待してきていただいた方のご期待には添えないかもしれませんし、私が感じたことを書くので主観的な内容が含まれているかもしれません。そもそもこの記事を書くきっかけになったのは、現在SIerに所属している方に向けて、「転職先に自社開発企業の選択肢もある！！」ことを伝えたかったからです。

今後、自社開発企業への転職を検討されている方の参考になればと思います。

簡単な経歴

新卒で社員数50人規模の比較的小さなSIerに入り、2年間ヘルスケア系のWebアプリ開発を担当
1度目の転職で人材系のメガベンチャーに入り、1年間医療系のナビサイト開発を担当
2度目の転職でOLTAに入社

現在はエンジニア5年目で、バックエンドが得意です。

SIと自社開発の違い

私自身、新卒で入社したSIerを2年目が終わったタイミングで辞めて自社開発企業への転職をしました。初めての転職は不安でした。わからないことだらけで、自社開発企業を志望する考えにも至っていませんでした。周りはSIerでいう「上流（PM, PL）」を目指す方が多い印象でした。早くPLになってマネジメントをしてみたいとか、上流の役回りに就けたら、年収の高いITコンサルに転職したいとか…etc

私は上流工程への憧れはそこまでなくて、どちらかと言えば「手を動かしてモノを作る」とか「ユーザー（※1）目線」「ユーザー指向」で考えられる場所で仕事をしたいという想いが強かったです。SIerでもユーザー目線でシステムを作ることはありましたが、エンドユーザーに対して直接ヒアリングすることはできないし、仕様の最終的な判断はクライアントに依存してしまいます。今思えば、「実際にシステムを触るエンドユーザーを第一に考えたいが、クライアント（※2）ファーストに考えなければならない」という『葛藤』があったと思います。

※1. ユーザー: 実際にシステム（サービス）を利用する人 ※2. クライアント: 発注元

以下、項目ごとにSIerと自社開発について私が感じた違いと思っていることを書きます。

仕事の進め方

	SIer（※ 私が所属していた会社では）	自社開発
チームメンバーと役割	縦割り	横断的
開発手法	ウォーターフォール	アジャイル
スケジュール	一度決まればほとんどずれることはない	柔軟
仕様の決まり方	クライアントの要求定義から要件を落とし込む	事業としてやりたいことをプロダクトの機能に落とし込む

SIer

PLが引いたWBSをもとに業務委託のエンジニアとともに実装やテストを実施していました。分業がしっかりしていて、要件定義して仕様を決めるチーム、設計やDB設計するチーム、DB移行するチーム、テストするチーム、運用 / 保守するチームがありました。

一部の機能をオフショアでベトナムの企業に、デザイン・コーディングについては日経のベンダー企業に委託していました。各ベンダー企業に対して仕様の修正や変更を依頼する際には、必ずPLを通さなければならなかったりして、コミュニケーションコストが高くやりにくさを感じることもありました（イメージ図参照）。

1つの文言変更でも金銭が発生する可能性があるので、SIerの所謂上流の人がコミュニケーションを取ることになっていました。一方で、一つひとつの仕事の型がしっかりしていると捉えることもできます。

スケジュールをクライアントと握っているので、よっぽどのことがない限りはスケジュールをずらすことはできず、「とにかく形にする」「必死で間に合わせる」力はついたと思います。

＜流れ＞

①クライアントからある機能の修正依頼を受ける

②PL / PMが自社のエンジニアに対してタスクを振る

③修正範囲を洗い出して共有

④ブリッジSEを挟んで依頼

⑤～⑧オフショア企業が修正する

⑨成果物を自社のPL / PMに共有、受け入れテスト

⑩クライアントの受け入れテスト

自社開発

他職種とのコミュニケーションを密に取りながら、目的の機能を全員で作っていくような働き方になります。

テックリードにアドバイスを求めることもできるし、アウトプットに対してのレビューも丁寧にしてくれます。開発に関わる全般的なことを一人称で行うので、プロダクトに対しての責任を大きく持てるようになるし、できることが増えたと思います。

プロダクトのリリースは、PdMやデザイナーと仕様をすり合わせながら進めています。自社にPdMもデザイナーもいるので、対面やチャットですぐにやりとりができてコミュニケーションコストは少ないし、少なくなるように工夫していきます。

スケジュールは、ユーザーが最終的に何をすることができるのか（ユーザーストーリー）をはじめに洗い出して分解し、その後、チームのエンジニア全員で見積もりを行い、スケジュールを作成します。ただ、事業としてリリースしたい時期がある程度決まっているので、その場合はエンジニアのリソースを増やしたり、対象となるスコープを変更することもあります。

より良いやり方があれば周りに説明して、それを全力で取り組む姿勢が合理的で、面白い部分だと思います。

請負ではないので、スケジュールをずらしたりすることもありますし、本当に使ってくれるユーザーの意見がすぐに聞けるし分かるので、私のように「ユーザー目線」を大事にしながら仕事をしたい方には自社開発をおすすめします。

ドキュメント

	SIer	自社開発
主な目的	クライアントへの納品物	- 自社内で共有するもの - コミュニケーションコストの削減、効率アップ
作るもの	- 納品物　- 要件定義書　- 設計書　- テスト項目書 - その他　- 社内共有向けの作業手順書(Wiki等)	- アジャイル　- 実用的なありとあらゆるドキュメント - 設計　- 仕様書　- 各開発ツール / サービスのTips 　- UXの方針…etc

SIer

「実装されたコード」「インフラ」「基本設計書」「DB設計書」「テスト項目書」「テストカバレッジの向上」は全てクライアントのためのものでした。（納品したものに対価が支払われるため、当たり前だと思います。）

クライアントがフォーマットを指定する場合もあれば、フォーマットも含めて依頼を受けるケースもあります。クライアントはエンジニアではないことが多いので、他職種の方にもわかりやすいような仕様を書く必要があります。それを元にレビューを行ってもらい指摘があれば修正する、を繰り返し行っていました。

何から何までドキュメントに残して、常に最新に保っておくことが必要でした。クライアントからドキュメントに対してのフィードバックも厳しかったです。クライアントはシステムに対して必ずしも理解があるわけではなく、それは今後リプレースや運用する際にそのドキュメントを元にシステムの会社に再度委託したり、ユーザー対応をする必要があるからだと思います。ドキュメントが常に最新化されている一方で、自社のナレッジとしては残せないものが多いので、今後に役立つかは正直微妙だと感じていました。

自社開発

自社開発企業に入って一番最初に驚いたのは「基本設計書と詳細設計書がない」ことでした。

ただ、改めて振り返ると ”クライアントに納品するための” という修飾子が抜けているだけでした。

デザインと仕様をマッピングするドキュメントは存在するし、機能を追加する背景や意図が載っているドキュメントもあります。ドキュメントを残す目的がクライアント向けでは無くなりました。

実装に関わるドキュメントを作る時は、例えば「今後エンジニアが見てもわかるように」、DB設計は「DDM(Data Driven Managementチーム)がDBの構造やリレーションを把握しやすいように」と考えています。誰にどのような目的で利用されることが想定されるかを意識しながら作成するようになりました。

検索をかければ、欲しい情報と一致する内容のドキュメントはほとんど出てきます。機能やサービスの背景等が知りたいとSlackで聞くと、チームメンバーからそれがまとまっているドキュメントのリンクを共有してもらえます。ドキュメントが会社の資産になるということを身に染みて感じました。

技術選定

	SIer	自社開発
選定する人	クライアント	自分たち
選定基準	短期の安定/開発スピード	長期の利用を見越す
使える技術の選択肢	クライアントからの制限あり	特に制限なし
オープンソース利用可否	クライアントからの制限あり	制限なし、自分たちで判断
開発環境	決められた環境でなんとかする	都度よりよくする

SIer

SIerの頃は技術選定とかモダンな技術を取り入れたいとかはあまり考えたことがありませんでした。

クライアントの既存サービスに対しての機能追加や改修がほとんどだったので、もともとそのサービスが何で動いているか次第になることが多かったです。

一方で、新規やリプレースの案件だと技術選定から入ることができます。ただ、会社の利益率を考えると、受託開発は早く納品した方が良いのは明らかなので、過去のプロジェクトで使ったことのある技術やフレームワークを利用することがほとんどだと思います。とにかくプロジェクトを完遂し、クライアントに納品することが目的ではあるので、開発環境をよりよくする時間があれば、その分早く実装して納品することが求められていると感じてました。

自社開発

SIerの頃よりはモダンな技術や仕組みに触れることが多くなりました。それはWebを作る上でのフロントエンド / サーバーサイドの言語に限らず、インフラ部分やCI / CD環境、DXについても自動化したり最適化する意識が高くなったと思います。

ただ、常に最新の技術を取り入れるというよりは、「プロダクトをより良くするために」「開発効率を上げるために」どのような技術や設計を取り入れるのが良いか、目的を考えながら使っていくイメージです。

選定する際の基準もクライアントに依存せずに、自分たちで決めることができるので、長期的に見て何が良いか、を考えながら選ぶことができます。

文化

	SIer	自社開発
プロダクト開発で優先されること	クライアント	ユーザー（※会社による部分もある）
MissionVisionValue（MVV）の浸透	正直覚えてないので浸透していなかったと思う	浸透している
バグへの考え方	バグは可能な限り出さない、つぶす	バグが残っていても価値提供を優先して出す判断もする

SIer

SIerの文化としてプロダクト開発で優先されるのはクライアントだと思います。クライアントから仕事を請け負っている以上は当然かなと思います。

MVVについては、あったと思うのですが、正直覚えていないです。そのくらい、とにかく目の前の仕事に対してスピード感持って早く終わらせ、テストでなるべくバグを減らしていく作業をしていました。自分がどうなりたいか、会社がどうあるべきか等は考える時間が少なかったと思います。

自社開発

実装や設計についてはSIer時代と自社開発でやっていることに変化ないのでは？と思われるかもしれませんが、まずプロダクトを作る際の考え方が変わりました。設計する時も実装する時も「ユーザーの目線に立ったらこういう導線にしたほうがいいのではないか？」というようなユーザー目線で考えることが増えたと思います。PdMはもちろん、デザイナー、マーケ、エンジニアなど関係者全員がそれぞれの立場からプロダクトをよくするためのコミュニケーションを積極的に取っています。

OLTAでは、メンバー全員にサービスをよくしようとする文化が浸透しているからこそ、ユーザー目線で仕事ができていると思います。

また、SIの時と比べて考え方が大きく違うと感じたのは、バグに対しての捉え方です。クライアントワークの時はなるべくバグは出さないように最後の最後までテストをひたすら繰り返して品質を担保してからリリースすることが求められていました。一方で自社開発（特にスタートアップの会社）では、スピード重視でバグが残っていても価値提供やユーザーからのフィードバックを優先して出す判断もします。

（※会社による部分もある）について

ユーザー目線について、自社サービスを持っている企業だからできている訳では決してないと思います。前職では自社サービスを持っていましたが、ユーザー目線で考えるというよりはマーケの施策を淡々とこなすような状況でした。社内受託感があってSIerの時と（クライアントと社内の人で）相手が変わっただけで、やることが変わっていないなと違和感を覚えていました。

所感

今までSIerでの2年、自社開発での2年でやってきたことは、Webサービス開発で同じですが、上述の通り仕事の進め方や文化は違うことが多いと思います。目標やキャリアプラン、プライベート等々、色々な軸があると思うので選択は人それぞれです。

SIerでWebサービスの開発をされている方で「もっとユーザーや、システムがエンドユーザーにどう使われているか知りたい」というような指向性を持っている方にとっては、自社開発企業は合うのではないかと思います。また、大手の上流SEで「手を動かしてもらう」ところから「実際に手を動かす」ことを考えている方はぜひ。

一方で、自社開発企業ならどこでも手を動かせてユーザー指向で働けるか、と言われればそうでもないです。前述しましたが、実際私が2社目で働いた会社は営業やマーケの力が強すぎて、社内SI化してました。こちらについてはまた後日に第二弾として書きたいと思います。色々な意味でバランスが大切だということをそこで学びました。