【発注担当必見】システム開発の開発プロセスと外注管理のポイント解説

システム開発を外注する際、発注担当として、システム開発にどのように関わるとスムーズにいくのでしょうか。丸投げはダメだけれど専門的なことはよくわからない等、特に初めてシステム開発の担当となった場合には不安なことも多く出てきます。
今回は、システム開発を外注するにあたり、知っておいたほうが良い開発の基本プロセス、そして開発手法、発注担当者が関わるべきポイントについてご説明します。

システム開発をご検討でしたら、リカイゼンにご相談ください！
リカイゼンでは、様々なシステム開発実績のある会社をネットワークしており、希望条件に応じて適した相談先の開発会社をご紹介いたします。
手数料やサービス利用料は一切発生しませんので、お気軽にご相談ください。

１． システム開発の基本的な流れ

システム開発を外注する際は、発注担当者として、システム開発の基本的な流れや、開発手法がどのようなものがあるのかを最低限理解しておくと、システム開発会社とのコミュニケーションが取りやすくなります。何かトラブルが起きたり、仕様に関わる不具合が起きたりした時に、その対応を素早く取れるようになるためにも、まずはシステム開発の基本的な流れを説明します。

システム企画

ここは発注側が担当する項目です。まず、どのようなシステムに仕上げたいかについて関連部署で話し合いをします。そして、それらの内容を発注者側がRFP（提案依頼書）として取りまとめ、外注候補先へ配布します。このRFPは後の開発でも重要な資料になってきますので、しっかりとまとめる必要があります。

要件定義

発注者からの要望をまとめることを「要求定義」と言います。発注者作成するRFPからも要求定義を進めることができます。この要求定義をベースにし、システムとして動かすために「要件定義」を行います。要件定義は技術的側面から作成していきますので、システム開発会社が行う内容になります。
基本的にRFPがしっかりまとめられていて、要求定義の内容が明確であれば、要件定義はスムーズに作成することができます。

概要設計

要件定義をもとに、システム開発ができるようにシステム設計を行います。ここでは、外部設計、画面設計、内部設計をそれぞれ作成することになります。ここからは、実装するエンジニアも積極的に参加するフェーズに入ります。

詳細設計

実装に向けてのプログラム設計、データベース・各テーブル設計を進めます。このフェーズでは、かなり専門的な中身になってきますので、発注者が積極的に口を出す場面はほとんどありません。

プログラム設計

「詳細設計」において機能ごとに分割したプログラムにつき、コーディングレベルでの設計を詰めます。基本的にはプログラマがプログラムを行うための指示書を作成するフェーズになります。

プログラミング

プログラム設計書に沿って、実装が進められます。この工程でも、発注者はほとんど関わりがないのですが、実装を進める中で、想定していなかった仕様などの確認は出てくる場合があります。

テスト

テストは、プログラムの単体テスト（機能ごとに分割して作業を進めたプログラムのテスト）、結合テスト（各プログラムをつなげた整合性テスト）、システムテスト、イレギュラーテスト、運用テストと種類があります。 最終的に、発注者による受け入れテストを実施してもらいます。

運用保守

開発、納品が終了したのち、システムを使えるように指導したり、細かい不具合を直したり、正常稼働できるようにメンテナンスを行い、運用保守のフェーズへ入ります。

２．システム開発の代表的な３つの開発手法を解説

システム開発の基本的な流れを踏まえて、実際の開発現場ではどのような開発手法が用いられているのか、代表的な３つを紹介します。

ウォータフォール型開発

ウォーターフォール型開発では、開発工程を上流から下流へと、滝の水が植えから下へ一方向に流れるように開発をしていきます。この開発手法の特徴としては、あらかじめ厳密な設計を行い、仕様や機能を確定させておいて、全工程で仕上がった成果物を次の工程へ引き渡す形で順番に開発のステップを踏みます。

基本的に手戻りはなしという考え方の開発手法になります。発注者は開発がほぼ終わる頃に初めてどうなっているかが見えるというような開発のやり方です。
この開発手法は、インターネットの登場以前の大手基幹システムなどで基本的には大きな仕様変更が発生しない開発現場で用いられている手法です。昨今のWEB系システムで、開発しながら仕様を詰めていく方法では向いていないです。

プロトタイプ型開発

プロトタイプ型開発では、開発の初期段階で試作品（プロトタイプ）を作成して検証を行います。UIや機能のお試しになります。プロトタイプの検証を行うことで仕様を固めてしまいます。発注者にとっては、早い段階で目に見えてイメージがつきやすいということと仕様の確認ができるので、とてもわかりやすい開発手法です。 但し、プロトタイプ型開発は開発期間に余裕を持たせる必要があることと、コスト的には試作品作成分がかかってきます。スケジュールとコストに余裕があるプロジェクトであれば、効率的な開発手法です。

アジャイル型開発

アジャイル型開発は、開発内容を細分化できる単位まで細かく分けて、その単位ごとに納品と検証と修正を繰り返す開発手法になります。最近の開発の現場では、アジャイル型開発が主流になっています。
というのも、業務系システムだけではなく、WEB系システム開発の場合、新規ビジネスのための開発も数多くあり、最初の段階で仕様を決めきれない部分があるからです。アジャイル型開発であれば、暫定的に仕様を決めておいて、各納品物の粒が小さいので、柔軟に仕様修正が可能なのです。そういった小回りのきく開発手法が、WEB系システムの現場では人気があります。

３． システム開発における発注側の役割

ここまで、システム開発の基本的な流れ、そして代表的な開発手法について紹介してきました。発注担当者は、開発会社へ丸投げをするのではなく、自社案件にフィットする開発手法を開発会社とともに選定する必要があります。

開発工程を３段階に分け、発注者の役割と関わり方について紹介します。

開発序盤

開発における要件定義、設計部分を進める序盤では、発注者は積極的にプロジェクトへ関わっていきましょう。この序盤で決まったことが実装されていくことになります。終盤になってから色々と出してしまう発注者を見かけることがありますが、そのやり方は開発現場の士気を下げるだけではなく、良いシステムは出来上がりませんので注意してください。

開発中盤

中盤では、詳細設計から実装がメインになります。この段階では要件はおおよそ決まっていますので、発注者が積極的に関わることはありません。但し、定期的な進捗確認は行なって、問題が起きてないかどうかの確認を行う必要があります。なかなかこの部分は発注者へ伝えられない現場もあり、開発が大遅延して初めて知ったというようなこともありますので、そういったところは避けるべきです。

開発終盤

終盤では、いよいよリリース前の検証になりますので、発注者は積極的に検証へ参加するべきです。要件が満たされているか、実稼働に耐え得るかどうかなど、検証を行います。

４． まとめ

ここまで、システム開発を外注する際に知っておいたほうが良い基本的なことを説明してきましたが、いかがでしょうか。
システム開発のプロセス自体はどの時代でも大きく異なることはないですが、開発手法に関しては時代とともに変化してきています。自社に合った開発手法で開発を行うことが大切なので、外注先となる開発会社とよく話し合って、方針を決めるのが良いでしょう。