SIとはなんなのか?
「SI」という言葉について、少し整理したいと思ったり。
自分も普段使っている。周りからの理解や何を実施するのかという意味では伝わりやすいし、わかりやすいと思っている。
ただ、改めて本来の意味を考えてみると、実際の使われ方とは少し違かもなと思ったのだ。
SIの本来の意味
SIは「システムインテグレーション(System Integration)」の略だ。
文字通り解釈すれば、複数のシステムやソフトウェア、ハードウェアを統合して、一つのシステムとして機能させることを指す。企画から設計、開発、運用保守まで、一貫してシステムを提供することも含まれる。
しかし、実際には「SI = 受託開発」のような使われ方をしていることが多い。「SIの案件」と言えば、クライアントから発注を受けて開発するプロジェクトを指すことがほとんどだ。
自分も、会話の文脈によっては便宜上そういう使い方をすることがある。ただ、本来の意味とは少しズレているのかもしれないと思う。
本質的には同じことをやっている
ここで伝えたいのは、SIという言葉で語られる開発も、自社サービスの開発も、本質的には同じことをやっているということだ。
システムを開発する。要件を整理し、設計し、実装し、運用する。ユーザーに価値を届ける。
この本質は、契約形態や業態が違っても変わらない。
以前「受託開発と事業会社 違いは?」という記事でも書いたけれど、良いものを作りたいという気持ちは、どこに所属していようと変わらないと思う。
エンジニアとして目指すところは、みんな一緒なんじゃないだろうか。
これからの視点
SIという文脈で語られる開発は、プロダクトやサービスの視点が弱くなりがちかもしれない。クライアントの要件に応えることが主眼になるため、「このシステムがどう使われるか」「ユーザーにどんな価値を届けるか」という部分が、少し遠くなってしまうことがある。
もちろん、これはすべてのケースに当てはまるわけではない。クライアントのビジネス成功に真摯に向き合い、本質的な価値を考えて開発しているチームもたくさんある。
ただ、SIという枠組みの中でも、プロダクトやサービスの視点を持つことは大事だと思う。
言葉より、何を目指すか
今回はSIという言葉の意味について、少し整理してみた。
ただ、本質的なところは、エンジニアとして何を目指すかの方が大事だと思っている。
システムを統合することも、受託で開発することも、自社サービスを作ることも、やっていることの本質は同じだ。
良いシステムを作る。ユーザーに価値を届ける。
それが、エンジニアとして目指すところだ。
プロジェクトマネジメントやチーム運営に関する記事を定期的に更新しています。X(旧Twitter)でも日々の気づきを発信していますので、よければフォローしてください。
