システム開発の発注をするなら必見！知っておくべき工程の流れを徹底解説

システム開発は非常に専門性が高く、どのように進めていけばいいか分からない方も多いのではないでしょうか？そこで今回は、システム開発を発注する過程や開発工程、さらに発注者としての役割などについて詳しく紹介します。

システム開発の発注者の役割

システム開発の発注者の役割は、主に全体の流れを把握し、トラブルを未然に防ぐことにあります。システム開発を依頼する側としては、よく分からない部分が多いため、依頼する会社にすべて任せてしまいたくなるでしょう。

しかしすべてを任せてしまうと、発注者側がイメージしている仕様とは違うものがつくられていたとしても気づくことができません。すると納期直前になって大幅な修正が必要になり、スケジュールの遅延や追加コストの発生が起こるなどのトラブルに発展してしまいます。過去には似た状況で訴訟問題にまで発展したケースも存在し、軽視できるものではありません。

そのため発注者は最低限用語を理解した上で、何をどのようにつくりたいかを開発者側に正しく伝え、工程ごとに細かく確認することが重要な役割となります。

システム開発の発注者が知っておくべき工程の流れ

システム開発の工程は、大まかに以下のような流れで行われます。

またこれらの工程もさらに細かく分かれています。では次に、この各工程の詳細について詳しく紹介します。

依頼会社の決定

システム開発を依頼する会社は、次のような流れで決定します。

依頼会社を決定する場合は、システムの概要や納期などを分かりやすく伝えて正確な見積もりを提出してもらい、複数の会社で比較検討した上で決定します。では次の項目で詳しく見ていきましょう。

提案依頼書（RFP）を作成する

まずシステム開発会社に正確な見積もりを出してもらうための情報をまとめます。これは一般的に提案依頼書(RFP：Request for Proposalの略称)と呼ばれており、開発してほしいシステムについて、以下のような内容をA4用紙1枚程度に記入します。

もちろんこれらの内容を口頭で伝えることも可能ですが、正しく伝わらない危険性もあります。そのため提案依頼書を作成し、開発会社が正確な見積もりを出せるようにしましょう。

オリエンテーションを行う

次にこの提案依頼書をもとに、依頼したいシステム開発会社3～4社に対して説明を行います。これがオリエンテーションです。

個別で打ち合わせを行うと、どうしてもシステム開発会社の担当者によって、打ち合わせする内容に差が出てしまいます。しかし差が出ると、後々会社ごとに比較検討がしにくくなります。これを防ぐため各社共通で提案依頼書を使って説明を行いましょう。

相見積もりで依頼会社を決定

オリエンテーション後は各会社に見積もりを提出してもらい、内容を比較検討し、自社に最適な会社を選びます。この時ポイントとなるのが金額だけを見ないこと。

もちろん安く発注できるに越したことはありません。しかし金額の安さばかりを見ていると、希望のクオリティに達しないなど、さまざまな問題が発生する危険性もあります。

そのため見積もりをチェックする際は、提案依頼書に対する開発会社の提案内容まで含めて比較することが大切。そのシステムで自社の目的を達成できるかに重点を置き、依頼する会社を検討しましょう。

システムの設計～テストまで

システムの設計からテストまでの工程は、どのような開発手法を使うかによって大きく異なります。開発手法の種類は以下の通りです。

開発手法	特徴
ウォーターフォール開発	1つの工程が完了したら次の工程に進む開発手法
アジャイル開発	少ない機能に絞り開発から検証のサイクルを多数繰り返してすすめる開発手法
プロトタイプ開発	開発の早い段階で試作品（プロトタイプ）をつくり、発注者が追加や修正を提案して開発を進める手法
スパイラル開発	開発工程を機能ごとに分けて重要な機能からつくり、出来上がったものを組み上げていく開発手法

今回は、最もベーシックな「ウォーターフォール開発」の工程について紹介します。なお「プロトタイプ開発」の詳細やそのほかの開発との違いなどについては、以下の記事で詳しく紹介していますので、ぜひ参考にしてください。

ウォーターフォール開発のテストまでの工程は、主に以下のような流れで進みます。

では次の項目で詳しく見ていきましょう。

要件定義

要件定義では、提案依頼書を更に深堀りしてシステムの内容を具体的に決定します。主な内容は以下の通りです。

システム開発はこの要件定義をもとに行われるため、プロジェクトの成功を左右する最も重要な工程となります。特にウォーターフォール開発は、この要件定義がすべてと言っても過言ではないでしょう。

そのため「この部分は譲れない」もしくは「この機能は絶対に必要」など、重要なポイントについては納得の行くまで話し合いをすることが大切です。

外部設計（基本設計）

外部設計（基本設計）では、決定した要件定義をもとにシステム全体の骨組みづくりを行います。操作画面のレイアウトなど、目に見える部分の設計を行うため発注者側から発言することも可能。

この工程はシステムの使いやすさにも影響を与えることから、開発会社の作成する「基本設計書」に対して、的確にフィードバックすることが求められます。

内部設計（詳細設計）

要件定義や外部設計をもとに、システムの内部やインフラなど、詳細な部分を設計していきます。内容はプログラミングや、運用時のメンテナンスのしやすさを決めるなど、エンジニア・プログラマーに向けたものとなっています。

そのため発注者側に開示されるものも少なく、内容を詳しく理解する必要はありません。基本的には、システム開発会社に任せてしまって問題ないでしょう。

プログラミング

詳細設計をもとに、エンジニア・プログラマーがプログラミングを行います。プログラミングは、システムの機能ごとなどにパーツを分割し、1つずつ行われます。

こちらも基本的には開発会社に任せてしまう工程です。もし不安に感じるようであれば、プロジェクト進行を可視化できるツールなどを活用し、情報共有ができるようにしておくといいでしょう。

テスト（単体・結合・総合・運用）

作成されたプログラムが正常に作動するかをチェックします。テストには以下の種類があり、上から下へ順番に行われていきます。

テストの種類	内容
単体テスト	分割したパーツごとのプログラムをチェック
結合テスト	プログラムを複数組み合わせたチェック
総合テスト	すべてのプログラムが設計通りに動くかのチェック
運用（受入）テスト	納品先の環境で正常に作動するかのチェック

テスト工程ではほとんどの場合バグが見つかります。本番稼働がスムーズにいくようにバグの修正対応についても確認しましょう。

システムの納品～運用・保守まで

システムは納品して終わりではなく、問題なく動かせるよういくつかの工程が入ります。主な工程は以下の通りです。

納品からの工程をスムーズに進めるために、誰がどのようにシステムを利用するかなど導入体制を整えておくことが大切です。では次の項目で詳しく見ていきましょう。

システムの納品

システム開発会社でのチェックが完了した後は、システムを納品してもらい、発注者側でも問題なく作動するかをチェックします。開発会社でもチェックはされていますが、それでもトラブルは発生する可能性があるからです。

またこの時、操作マニュアルや業務マニュアルなど、付属する書類も問題がないかチェックしましょう。

システムの稼働

開発会社側で初期設定が完了し、マニュアルの説明などが終われば本格的にシステムの稼働を始めます。ただし、この段階になってもなお外部サービスの影響やサーバートラブルなどの問題は発生します。

その際は、すぐに開発会社に連絡し対応してもらいましょう。後々になって修正を依頼すると、間違いなく開発会社のミスだったとしても、合意した対応期間が過ぎて追加で費用が発生するからです。

運用・保守・メンテナンス

システムは導入後も安定して稼働させ、トラブルが起こった際にすぐ対応してもらえる体制を整える必要があります。これは基本的に有償であるため、事前に方針や予算を決めておきましょう。

また運用・保守・メンテナンスは、システム開発会社にまとめて依頼するのが一般的です。そのためシステム開発会社を選ぶ際には、運用保守まで含めて検討してください。

発注者が外注先に丸投げすると起こりうるトラブルと予防策

冒頭でシステム開発を丸投げすると、トラブルに発展しやすいと紹介しました。では、実際にはどのようなトラブルが起こる可能性があるのでしょうか？そこで最後に、丸投げで起こりがちなトラブル例2つと、それを予防するための対策について紹介します。

丸投げの連鎖で使えないシステムに

システム開発を主導する上司が、デジタルを理解できないにも関わらず、プライドを優先して部下に丸投げ。部下も責任を負わされるのを嫌い、開発会社に丸投げしました。

優秀な開発会社はリスクの高さから依頼は引き受けません。この場合、依頼を引き受けるのは仕事の無い会社か、利益至上主義の会社です。

利益至上主義の会社は少しでも利益を出したいため、中抜きだけをして下請けへ仕事を丸投げ、下請けも同様に楽に利益を出すため孫請けへと丸投げを続けます。しわ寄せを受けた末端の現場では、まともなシステムをつくることはできません。

業務の流れと全く一致しない、画面や操作が分かりにくいなどのシステムが出来上がります。発注者側は修正を依頼しようにも、修正箇所が多すぎて断念。導入からしばらくすると、まともに使われなくなってしまいました。

大幅な遅延とコストの増加

システム開発の担当者が、専門的なことはよくわからないからと、要件定義からほとんどのものを「そちらにお任せします」と丸投げ。しかし開発会社は、発注者の業務をすべて把握することはできません。また開発会社はシステムを開発することが仕事です。

そのため、開発会社は与えられた情報から必要な機能を予測してシステム開発を開始。コミュニケーションも十分に取れずに双方でギャップが生まれ、システムが完成し動作をチェックする段階になって、重要な機能が抜けていることが発覚しました。

機能を追加せざるを得なくなったことで、システムの納品は2ヶ月の延期。コストも大幅に増加することとなってしまいました。

丸投げで起こるトラブルの予防策

上記のようなトラブルを防止するには、次のようなポイントに注意が必要です。

では次の項目で詳しく見ていきましょう。

分からないポイントをそのままにしない

システム開発はその専門性の高さから、内容が理解できない部分も数多くあります。特に見積や提案内容などはシステムの工数や費用が細かく記載されていることから、より難しく感じることもあるでしょう。

しかしこれを放置すると、上記のようなトラブルが発生する危険性があります。分からない部分は放置せず、担当者から説明を受けましょう。

対応窓口は一本化する

システム開発会社からの連絡を受ける窓口は、分かりやすいように1つにまとめるのがおすすめです。複数の窓口があると、情報が錯綜しどれが正しい情報かが分からなくなる可能性があります。

また窓口となる人物も重要です。業務内容を深く理解し、システムの仕様などを決定でき、これを上層部に理解させられる、などの条件をできる限りクリアできる人物を選びましょう。

まとめ

今回は、システム開発を発注する場合に理解しておくべき工程の流れや担当者の役割などについて、詳しく紹介しました。システム開発は専門性が高く、詳しくない方にとっては難しい分野です。

しかし自ら積極的に開発に関わらなければ、理想的なシステムはつくれません。ぜひ今回の記事を参考に、自分たちの手でシステム開発をする気持ちで臨んでみてはいかがでしょうか？

ご興味を持たれた方は、以下URLより弊社サービスをご覧ください。