システム開発の形態を知ろう

システム開発に携わっていると、開発方式について「受託開発」や「自社開発」という言葉が聞こえてきます。ほかには、「SES」や「SE派遣」、「請負」といった用語もあります。

こうした契約や取引は営業や上層部が決めていますが、エンジニアとしても自分の仕事がどれに属するのか、それらがどんな意味を持つのかを知っておく必要があります。

ここではエンジニアとして知っておくべき開発の方式について、「受託開発」を中心に採り上げながら、やさしく解説し、皆さんの疑問に答えていきます。

ITエンジニアの視点から、受託開発と自社開発の違いを見ていきましょう。

■受託開発とは

受託開発とは委託先からシステムの開発を委託され、委託先の要求内容に従って開発する方式を指します。

受託開発のイメージを具体的な例として表すと次の通りです。

1.A社はB社に、あるシステム(ソフトウェア)の開発を依頼します。

2.B社はシステム要件についてA社からヒアリングし、システム提案書と見積書を提示します。

3.A社はB社からの提案書、見積書を精査し、社内調整を経て開発に関する経営側の承認を得ます。

4.B社はA社との間に、受託開発に伴う請負契約を締結します。

5.B社はA社との間でプロジェクトを編成し、要件定義、基本設計、詳細設計、プログミング、単体テスト、結合テスト、総合テストを経て完成品をA社に納品します。

6.A社は納品されたシステムを稼働させて検収を行い、問題がなければ委託費用の支払いを行います。

大まかには以上が受託開発の流れです。

■自社開発とは

自社開発はまさに、自社でシステムを開発する方式です。自社の企画部門などで考えたアイデアを企画書にして、然るべき会議体(企画会議、経営会議など)で承認後にシステム開発部門にシステム開発の依頼をします。社外向けにパッケージ製品として開発するケースもあれば、自社内システムとして社内だけで利用する場合もあります。また社内開発では、開発パワーの不足をSESなどで補うケースもありますが、開発主体が社内であれば、社内開発と言えます。

ITベンダーやSIerでは、受託開発という言葉に対して、SESという言葉をよく耳にします。SESとは(System Engineering Service)の略語で、IT企業などにエンジニアを常駐させて業務をおこなう契約形態を指します。「準委任契約」とも呼ばれる契約形態で、人月単価契約となります。例えばSEは1人月80万円、PGは1人月60万円といった形で報酬額が決まります。報酬額はエンジニアのスキルや仕事内容によって変わってきます。このSESでは、あくまでも労働力の提供であり、ソウトウェアなどの完成責任は負いません。派遣する側としては、リスクが少ないのがメリットです。

SIerとSESの違いとは？それぞれの詳細から将来性まで徹底解説

「SESってSE派遣と同じでは？」と考えた方は多いと思いますが、実はこの2つは異なりますので、説明しておきます。ここを間違えると法令違反となりますので、注意しましょう。

SES契約でクライアント企業に常駐するエンジニアは、外注契約を受注した側の企業の指揮の下に仕事を行います。

これに対して、労働者派遣の形でクライアントに派遣されたエンジニアは、クライアントの管理、監督下で仕事を行います。両者は非常によく似ていますが、契約形態によって指示命令系統が大きく異なるのです。

SESのエンジニアに対して、クライアント側の企業が直接、指示や命令を行うことは違法です。これがよく言われる「偽装請負」です。

またITベンダーがSEを派遣する場合は、「派遣元責任者資格」が必要です。「派遣元責任者資格」を得たら、さらに「派遣事業の許可」を得る必要があります。

「受託」と「請負」という契約形態があります。

「受託」とは、クライアントからの依頼により、業務を行う契約のことです。その契約には期間、条件などが定められていますが、成果物などの納品義務はありません。一方、「請負」もクライアントからの依頼によって業務を行いますが、請負の場合は成果に対する責任を負います。クライアントに対して、完成物や成果物の納品義務がある点が大きく異なります。

受託契約には「納品義務」がないことが分かりましたが、では「受託開発」にも納品義務がないのでしょうか？実は「受託開発」は請負契約なのです。言葉が紛らわしいので混乱してしまいそうですが、「受託開発」は完成義務、納品義務を負いますので誤解のないようにしてください。

受託開発のメリット

受託開発の概要については理解されたと思いますが、より理解を深めるために、そのメリットについても確認しておきましょう。但し、メリットはあくまでも発注者側の視点でのメリットです。

自社で新たにシステムを開発する場合、システム開発のリソース(要員、時間、手間)確保の負担が大きくなりがちです。受託開発方式を採用し、システム開発を外出しすることで、自社のリソース負担を抑えることが可能になります。受託開発の場合は、複数社によるコンペが一般的で、価格競争によるコスト引き下げが期待できます。

自社開発方式では、自社内にエンジニアを確保する必要があります。システム開発の業務量に波があるため、ある程度の余裕を持った人員確保が必要なため、人件費が水膨れしがちです。受託開発を併用することで、要員過剰や要員不足を防ぎ、安定開発が可能になります。

受託開発を採用することで、自社だけではなかなか獲得ができないシステム開発ノウハウを、外部企業から吸収することが可能となります。このノウハウを吸収するためには、外部企業に丸投げするのではなく、自社も主体的に関わるという姿勢が求められます。

受託開発のデメリット

受託開発には前記のようなメリットがある反面、デメリットがあることも理解しておくことが求められます。デメリットは発注者側の意識や姿勢によっては解消することも可能ですので、デメリットを理解した上で採用することが必要です。

当然のことですが、自社のシステム開発を外部企業に委託すれば、自社エンジニアが関わる機会は減り、成長の機会が制限されるのは致し方ないことです。それを防ぐには、可能な限り、自社のエンジニアもプロジェクトに関わらせることが必要です。開発作業そのものはアウトソーシングしても、定例ミーティングやレビュー会議など、受託開発企業との接点をできるだけ設け、自社エンジニアの参画機会を極力増やすことが望ましいでしょう。

幅広いIT知識とスキルを求められる「社内SE」について徹底解説！

丸投げのような形で、システム開発の外出しをしてしまうと、仕様変更が難しくなるばかりか、システム稼働後の改良も困難になります。ユーザーの立場から要件定義やレビューに能動的に関わり、あくまでもプロジェクト管理の主体は自社にあるという意識を持って受託開発を活用することをおすすめします。

受託開発は終わった?

「受託開発は終わった」「受託開発はオワコン」といった声がありますが、実際のところはどうなのでしょう。そう言われる理由と、今後の受託開発の方向について考察をしてみましょう。

受託開発は終わったと言われる主な理由は次の通りです。

1.人月単価ベースの限界

受託開発を依頼すると、見積書に提示される人月単価に唖然とすることがあります。この見積もり方式は何十年も変わっていません。まるで人をモノのように扱うことには抵抗すら覚えます。また"人月単価が高い=優秀"ではありません。こうした前時代的な見積もりを続けている限りは受託開発への期待は下がる一方です。

一方、ステップ単価での見積もりをする受託開発会社もありますが、ステップ単価にも合理性は見出せません。クライアントを納得させられる見積もり方式を編み出す必要性を感じます。

2.クラウド化の流れ

クラウド技術の進展と普及が、システムの形を根本から変えようとしています。SIer業界のあり方を大きく変えると言われています。クラウドが普及する以前は、メーカー系の大手SIerが自社の大型サーバと抱き合わせで大規模システムの開発を請け負っていました。ハードとシステム開発がセットになり、その価格の合理性、妥当性もあいまいなまま、出精値引きという文言に誤魔化され、顧客は何の疑問も持たず発注をしてきました。

クラウドの進展によって、今はハードを1から調達する必要もなく、初期投資は最小限で、利用した分だけ費用を払うという従量制料金体系のおかげで、システム開発が見える形になってきました。

このクラウド化の結果、中小企業やベンチャー系IT企業の活躍分野が広がり、しかも従来型のウォーターフロー型開発から、アジャイル型開発に移行し、大手SIer企業による受託開発の強みが失せてきたというのが現実ではないでしょうか?

政府系、自治体、大企業中心の大規模案件はDXブームのおかげで残っていますが、中小を中心にクラウドやWeb、スマホ中心のシステム開発が中心となっており、大手Sierがその辺をカバーしきれていないのが実情です。

とは言っても、企業のシステム化ニーズがある限り、受託開発はなくならないでしょう。専門分野は専門家に任せるという発想は一般化しており、アウトソーシング化の流れは変わりません。まして、DX推進が企業の義務にもなっている今日、システム化の需要は増えることはあっても、減ることはありません。しかし、その需要に応えていくには、受託開発の在り方そのものが見直される必要があります。エンジニアの単価で見積もるような受託開発はもはや限界です。またSIerもその認識は持っており、クライアントを納得させられる見積もり手法を編み出しています。システムは投資です。投資を上回るリターンがあれば、システムを開発する意味があります。そのリターンを見積もる手法が求められています。

DX推進、エンジニア不足という追い風がある一方、その先を考えた時にエンジニアの方々が将来に不安を感じるのは当然のことです。しかし、現実を直視し、未来を見据えて、未来に備える事はできます。

クラウドやアジャイル開発に関する知識やスキルを身に着けることは必要です。それに加えて受託開発、SES、自社開発のすべてに対応できるエンジニアを目指すこと、さらには自身のキャリアパスを明確に描いて、目標に向かって自己研鑽に努めること、それがこれからもエンジニアとして活躍していく方法です。

DXとは？その意味と日本の現状、DX推進の障壁となる要因を分かりやすく解説！