どうも、カネスズです。
今回は、ＩＴエンジニアの労働形態である、受託開発について
書いていきたいと思います。
以前の記事で様々な労働形態について簡単にまとめてありますので、
良ければそちらもご覧ください。
目次
受託開発とは
受託開発は、企業からの依頼でシステム、又はシステムの一部を開発する形態です。
例えば、
「うちの会社の社員管理システムを作ってくれ」
「うちで製造している製品の品質管理システムが欲しいんだが…」
みたいな依頼を受けて開発を行うものです。
この依頼主から直接仕事を引き受けることを一次請け、一次請けの企業から
そのシステム開発を依頼されることを二次請け、次は三次…四次…
と続いていきます。（四次請け以降はあまり聞きませんが）
受託開発の特徴
受託開発の特徴としては、以下の4つが挙げられます。
- 携わるシステムのスパンが短く、変わりやすい
- 自社で開発を行うため、新たに人間関係を構築しなくていい
- 開発方法を依頼元に合わせる必要がある（開発の一部を依頼されている場合）
- ユーザ側とのやり取りにワンクッション挟む（開発の一部を依頼されている場合）
それぞれの特徴とメリット・デメリットについて解説していきます。
携わるシステムのスパンが短く、変わりやすい
一次請けの場合は、自社開発の様に開発から運用・保守まで任されることがほとんどですが、
二次、三次になってくると、上流工程へ納品後はそこで仕事が終了になってしまうことが
多いです。
もちろん仕様変更があった場合は、再見積もりを行い、追加料金で対応したり、
不具合が発生してしまったら瑕疵対応といって無償で修正を行わなければならない
場合もあります。
ですが、納品して上流工程でのテストが終われば基本的にそこで終了。
また別のシステム開発に移ることになります。
開発の二次請け・三次請けの場合はシステム全体ではなく、一部を開発することになるので
そのシステムに携わっている時間というのは短いです。
私の経験ですと、早くて半月。長くて半年くらいで受託開発は終わってしまいます。
一次請けの場合は1年以上の開発期間というのもあるのですが、最近は納期の短縮が
増えてきているようなので今後はもっと短いスパンになることが予想されますね。
まとめのメリット・デメリット
メリット
・色々な開発に携われることで、技術の幅を広げられる
デメリット
・開発のスパンが短いため、システムの仕様や使われる技術など、学習に掛かる負担が大きい
自社で開発を行うため、新たに人間関係を構築しなくていい
自社開発の特徴を紹介した記事でも同じ特徴がありましたが、
受託開発の場合は少し異なります。
自社開発の場合は、開発のスパンが長いためプロジェクトメンバーの変更が起こりにくく、
変更の都度人間関係の構築が少ないと書きました。
ですが受託開発の場合は、1次請けでない限り開発スパンが短くプロジェクトメンバーが
変わりやすいです。
そのためこれに関しては、この特徴に合致しません。
合致するのは、客先常駐開発との違いの部分です。
客先常駐は、システム開発を行っている会社に常駐しその開発を手伝うというものです。
そのため、プロジェクトチームが変わるどころか、会社すら変わってしまうので
人間関係の構築が大変なんです。
それに比べて受託開発は、プロジェクメンバーが変わったとしても開発を行うのは社内なので
人間関係の構築に対する負担が少ないんですね。
コミュニケーションに不安のある方（私の様な）には大きなメリットです！！
まとめのメリット・デメリット
メリット
・人間関係の再構築があまりない
デメリット
・人間関係を広げにくい
開発方法を依頼元に合わせる必要がある（開発の一部を依頼されている場合）
この特徴は、二次・三次請けの開発に限るものです。
自社開発や一次請けの場合、仕様書や設計書の書式やシステムの構造、
コーディング規約（ソースコードの書き方）を自社で決めることができます。
しかし、二次・三次請けの場合は上流工程の開発手法に合わさなければならないのです。
合わすだけなら簡単じゃん？
と思う方がいるかもしれませんが、そんなことはありません。
請け負ったシステムによっては、とても見ずらい設計書を作成しなくてはならなくなったり、
それ要るの？と思えるような謎の書類を作らなくてはいけない場合もあります。
そして、どうしても開発を行っていると、慣れというか癖の様なものが現れてきます。
「設計書の書き方はこうでいいよね～」
「ソースコードを書くときの変数名はこういう感じに～」
といった感じに習慣化してしまうのです。
それを請け負ったシステム開発毎に強制されるというのは、意外と苦痛というか
面倒に感じます。
ですが、その分良い設計書の書き方やコーディングの仕方の見分けがつくようになり、
技術者的に成長できるというメリットもあるので、一概に悪いことと言うことはできません。
（私としては、全企業で統一していただきたいです）
まとめのメリット・デメリット
メリット
・良い設計書の書き方・悪いコーディングの仕方などの見分けがつくようになる
・様々な開発手法を知ることで、開発に対する柔軟性が付く
デメリット
・開発方法に統一がなく、覚えるのが面倒
・前回の開発の癖が残っており、ミスをしてしまう
ユーザ側とのやり取りにワンクッション挟む（開発の一部を依頼されている場合）
この特徴も、二次・三次請けの開発に限るものです。
一次請けの場合は、仕様に関する質問をそのままお客さんに行えばいいのですが、
二次・三次請けの場合はそうはいきません。
例えば、出力ボタンを押した際データをExcelで出力するのか、CSVデータで出力するのか
はたまたPDFファイルで出力するのか不明点が出たとします。
仮に自分が二次請けだった場合、その不明点を一次請けに質問します。
そこで一次請けがすぐに答えられればいいのですが、一次請けが分からない場合は
システム開発依頼の大本（エンドユーザと言います）に一次請けが質問しなければ
なりません。
流れで言うと
二次請け（自分）
↓（質問）
一次請け
↓（質問）
エンドユーザ
↓（回答）
一次請け
↓（回答）
二次請け（自分）
という流れになります。
このユーザ側とのやり取りをワンクッション挟むことで、回答が返ってくるのに
時間がかかるのです。
時間がかかるだけならいいものの、時には質問自体を一次請けが忘れ、
回答がまったく帰ってこないときもあります。
それによってスケジュールが遅れる羽目になったらもう最悪です！！
まとめのメリット・デメリット
メリット
・無い！！（しいて言うなら、質問の回答が遅かった時スケジュールが遅れた際の言い訳になる）
デメリット
・スケジュールが遅れる場合がある
・また聞きになるため、間違いを教えられる場合がある
まとめ
ここまで受託開発について紹介してきましたが
いかがだったでしょう。
受託開発といっても、二次・三次請けの話が中心になってしまいました。
一次請けに関しては、自社開発（自社パッケージ開発）と似た部分がほとんどなので
そちらを見ていただければと思います。
この記事が、IT業界への就職・転職を考えている方の参考になれば幸いです。
それでは今回はここらへんで。
それでは！！