社内SIer的な働き方 結構楽しいという話
中小企業でひとりDX担当してます。社内の部署の課題や問題点をヒアリングし、AIやRPAを使って業務効率化をバリバリ進めてます。
最近、この本を読みました。
【なぜ、システム開発は必ずモメるのか？】
https://amzn.asia/d/15TGvZS
システム開発の発注者と開発者間の裁判の判例や、発注者の心構え、開発者が負うべき責任範囲などが書かれていて非常に勉強になりました。
私も社内で開発者側のような業務をやっているので、社外に開発を頼むと色々たいへんなんだなぁと思い、自分の置かれている状況がいかに恵まれたものであるか再認識したので、メモとして残しておこうとした次第です。
SIerとは？
SIer（システムインテグレーター）とは、企業や組織が必要とするITシステムの構築や運用を支援する企業のことです。SIerは、システムの企画段階から設計、開発、導入、運用までの全プロセスを担当し、クライアントのニーズに合わせた最適なシステムを提供する役割を担います。
SIerの業務範囲は広く、ハードウェアの選定からソフトウェアのカスタマイズ、ネットワークの構築、クラウドの活用など、さまざまな技術的なサポートを行います。特に、日本では企業が自社でITシステムを内製せず、外部に開発を依頼することが多いため、SIerは非常に重要な役割を果たしています。
SIerが関与するプロジェクトは、中小企業から大企業までさまざまな規模がありますが、共通しているのはクライアントのビジネスニーズを理解し、それに応じたITソリューションを提供することです。
本の中では依頼者側と開発者側のコミュニケーションの齟齬から、相互の不信感が育っていき、受け入れ検査の重大なバグをきっかけに裁判に突入することが多いようです。
SIerとSESの違いとは？
SIerとよく比較されるサービスにSES（システムエンジニアリングサービス）があります。これらは似たような分野で活動しているものの、役割や目的が異なります。
SIerは、プロジェクト全体のシステム設計や構築を請け負う企業でクライアントの要件を理解し、システム全体を一貫して管理する責任があります。これには、システムの要件定義、設計、開発、テスト、導入、運用が含まれます。
一方、SESはエンジニアをクライアントのプロジェクトに派遣し、特定の技術や業務分野においてサポートを提供するサービスです。SESの場合、派遣されたエンジニアはクライアントの指揮のもとで働き、特定のタスクを担当します。SESはプロジェクト全体の管理には関与せず、あくまでリソースを提供する形となります。
SIerとSESの主な違いは、SIerがプロジェクトの全体管理を担当するのに対し、SESは特定の技術的なサポートを提供するという点にあります。企業がどちらのサービスを選ぶかは、プロジェクトの規模や要件に応じて決まります。
SIerとSESの主な違いを旅行で例えると、SIerは出発から帰宅までの全行程をサポートし旅行を成功させる添乗員。SESは旅行の一部分を担う現地ガイドといったところでしょうか。
海外ではシステム内製が一般的
日本では、システム開発を外部のSIerに依頼するケースが多い一方で、海外、とりわけアメリカやヨーロッパの企業では、システム内製（インハウス開発）が一般的です。この違いには、いくつかの理由があります。
まず、海外の企業は技術力を戦略的資産と捉え、自社内でシステムを開発・運用することで競争力を高めようとしています。特に、IT技術がビジネスの根幹を支える場合、外部に依存せず、内製化によって技術のノウハウを自社に蓄積することが重要視されます。
また、コミュニケーションの面でも内製化は有利です。システム開発における要件変更や仕様の確認など、外部とのやり取りが不要であり、プロジェクトの進行がスムーズになることが多いです。さらに、内製化によってセキュリティ面のリスクも軽減できます。外部にデータやシステム設計を依存しないため、情報漏洩のリスクが低くなります。
これに対し、日本の企業は、システム構築を外部に依頼する文化が根強くあります。技術的な知識やリソースを外部から得ることがコスト効率の面で有利とされるケースも多いためです。しかし、最近では日本でも内製化の動きが進んでおり、特にDX（デジタルトランスフォーメーション）を推進する企業では、社内でのシステム開発が増えてきています。
日本の場合、依頼者側は「ITシステムとか全然わからんし、善きに計らってイイ感じのシステムよろしく！」みたいな態度で開発を依頼することが多く、対して開発者側は「お客さんに細かい仕様を聞いても、全然理解して回答してくれないし、恐らくこういうケースで使うのだろう…よく分からんけど…」って感じで開発する現場があるみたいです。
ここに加えて、日本語のハイコンテキストな言語の特徴と曖昧さを許さないプログラミング言語が合体すると、悲惨なことが起きがち
※ハイコンテキスト
話し手や聞き手が多くの情報を言葉にせずとも、お互いに理解し合える文化を指します。つまり、会話の中であまり細かい説明をしなくても、相手が何を言いたいかを察することができるということです。
通常、SIerは社外を指しますが、社内でSIer(海外だとインハウス)的なことをした場合にどのような特徴があるか確認してみます。
社内SIerのメリット・デメリット
メリット
依頼元が社内にいるため、要件調整や確認が迅速にできる。
外部に依頼する費用がかからないため、コストを抑えられる。
社内システムや業務に精通しているため、特定の業務に最適化されたシステム構築が可能。
フィードバックが早く、短い開発サイクルで対応可能。
社内開発のため、情報漏洩リスクが低い。
デメリット
依頼元との距離が近すぎるため、期待値が高くなり、過度な対応が求められることがある。
人件費やツール費用が発生するため、社内リソースにコストがかかる。
最新技術や他業界の技術をキャッチアップしにくい。
複数のプロジェクトを同時にこなすのが難しく、リソースが逼迫することがある。
セキュリティ対策は、社内リソースだけでは限界がある場合がある。
社外SIerのメリット・デメリット
メリット
外部であるため、適度な距離が保たれ、冷静な対応が可能。
契約によっては一時的なコスト削減が可能。
幅広い経験や専門的な技術を持つエンジニアが揃っている。
リソースが豊富で、大規模プロジェクトを迅速に対応可能。
外部のセキュリティ専門家を活用して、リスク管理を強化できる。
デメリット
外部のため、依頼元とのやり取りに時間と手間がかかる。
長期的に依頼し続けると、コストが膨らみやすい。
自社業務の詳細な理解に時間がかかることがある。
外部依存のため、納期遅延や不確実性が高まるリスクがある。
外部にデータを提供するため、情報漏洩リスクが高まる。
社内にひとりだけのDX担当なので、リソース×１しかないのは痛感しています。複数の部署から同時に依頼を受けたときはリソースの配分に苦労します。業務効率化は特に切羽詰まったものは少ないので、焦って開発することはないのですが、早く開発できればそれだけ依頼元の通常業務が楽になるので、早めに開発を完了させたい気持ちはあります。
自分が考える社内SIerの良いところ
依頼元とのコミュニケーションコストが低い
社内SIerの最大の利点の一つは、同じ組織内にいるため依頼元とのコミュニケーションコストが極めて低いことです。例えば、新しいシステム要件の確認や仕様変更の依頼が発生した場合、直接その部署と顔を合わせて話し合うことができます。
簡単な確認事項ならslackやTeamsのチャットで済むので、仕様確定までの待ち時間がほぼありません。社外への問い合わせになると理解しやすいように図や表を用いた説明が必要なのではないかと考えてしまい、余計な作業が発生します。
極論ですが手話でもモールス信号でも伝われば良いので、コミュニケーションコストの低さはプロジェクト全編を通して効いてきます。
フィードバックをもらいやすい
社内でのプロジェクトはアジャイル開発で進めています。プロジェクト後半でやっと触れるシステムができるよりも１～２週間で最低限の機能(MVP)を作りユーザーに触ってもらった方が軌道修正はしやすくなります。
いくらコミュニケーションコストが低いと言っても、別の部署の業務をやりやすくするためのシステムを開発するので、その部署の業務を完全に理解することは難しいです。
私はアジャイル開発を進める際はベクトルをイメージします。自分が想定している理想的なシステム像とユーザーが考えている理想的なシステム像は必ずズレます。これがベクトルのズレです。別の人間だからしょうがないですよね。
ベクトルのズレを修正するタイミングと頻度が重要です。もしかしたら、最初の打ち合わせの時点で180°くらいベクトルがズレているかもしれません。しかし、アジャイル開発では開発は少しずつしか進みませんので、ベクトルの長さはそれほど大きくありません。ユーザーが把握できる状態で見せたときに「これ全然違うよ！」とフィードバックがもらえます。ここでズレを早期に修正できます。
一方、ユーザーが把握できる状態のシステムになるまで何か月も経ってしまうと、最初にわずかなベクトルのズレだったとしても開発が進むにつれて大きなズレが生じます。
開発者側は「何で早く言ってくれなかったの！？」となりますし、依頼者側は「何でこんなシステムになってるの！？」と双方が不幸な結果になります。
開発の費用に関して気にしなくて良い
社内SIerの大きなメリットの一つとして、開発の費用に対して過度に気を使わなくても良いという点があります。社外SIerを利用する場合、プロジェクトごとに契約を結び、見積もりや予算に応じて開発します。したがって、開発が遅れたり、追加の要件が発生すると、その分の費用が上乗せされることが一般的です。これにより、コスト面のプレッシャーが開発者側と依頼者側両方にかかります。
一方で、社内SIerの場合、基本的に自社のリソースで開発を行うため、追加のコストが発生しにくいです。もちろん、開発者の人件費やツールの利用料は存在しますが、それは社内の固定費として扱われるため、プロジェクトごとのコスト管理がシンプルです。また、要件変更や追加機能の実装が必要になった際も、外部に発注する場合のように見積もりや追加費用の調整に時間を取られることなく、柔軟に対応できます。
プロジェクトの初期には見えていなかった要件も実際に画面を操作してみるとこんな機能が欲しいとか、このレイアウトは視認性が悪いとか色々改善点が出てきます。
社外SIerの場合、予備のリソース内で収まる仕様変更なら良いですが、ちゃぶ台をひっくり返すような根本的な部分から修正するとなると最初の見積もりからは採算がとれなくなりますし、コード全体への影響も再確認するために更に間接的な作業が発生します。
社内SIerの場合は会社の同じ財布からリソースを持ってくるので、開発期間が３倍になるみたいな余程のことがない限りは問題になりません。
まとめ
社内SIerという世の中一般的に存在するのか分からないようなポジションで働いていますが、社外SIerと比べてストレスの少ない環境で恵まれていると感じています。給与も1.5倍くらいにしてくれると最高なんですが・・・。