システム開発の流れを分かりやすく説明~要件定義って何?という方のために

更新日:2017年06月16日 | 公開日:2016年09月18日

システム構築外注時には、発注者にも専門用語の最低限の理解はあったほうが良い

システム構築を外注したい会社の担当者は、業務を遂行するプロであっても当然のことながらシステム構築のプロではありません。したがって、システム関連の言葉が出てきても、開発会社の人に「それは、お任せします」と言ってしまいたくなります。

しかし、システム構築を成功させたいなら、プログラミングを行ううえでの細かなプロセスは別としてプロジェクト全体の状況は発注側でしっかりと把握しておかねばなりません。そうでなければ、最悪のケースでは納期直前になって「やっぱりできません」「追加予算が必要です」といった、当初の計画をひっくり返すような出来事が起きないとも限りません。

実際に有名地方銀行の仕事を請け負った日本を代表するようなSIerが、その地銀に対してこれに近い対応をして訴訟問題に発展したこともあります。「相手はシステム構築のプロなんだから、専門的なことは任せました」という態度では、そうした悲劇が自分の会社で起きることもあり得るわけです。

まずはシステム開発の流れを外観しよう

システム構築の流れは、下記のようになります。まずはその全体を見てみましょう。

【システム構築の全工程】
 1. 開発範囲を決定し、RFP(提案依頼書)をまとめる
 2. 発注先候補に対してオリエンテーションを行う
 3. 相見積もりを検討して候補を絞り込んで決定
 4. 基本契約書締結
 5. 要求定義作成
 6. 要件定義作成
 7. 外部設計
 8. 内部設計
 9. 個別契約書作成
 10. テスト計画
 11. プログラムコーディング開始
 12. 単体テスト
 13. 結合テスト
 14. システムテスト
 15. 受入テスト
 16. 納品
 17. 本稼働
 18. 保守・メンテナンス

専門用語がズラッと並んでいる印象ですが、個別に理解していけば、もちろん全体を発注者側で管理できるようになります。

システム開発の流れを普通の言葉で説明するとこうなります

【一般的な言葉で説明したシステム構築の全工程】

1. 開発範囲を決定し、RFP(Request For Proposal)をまとめる

「RFP(Request For Proposal)」を普通の言葉にすると「提案依頼書」となります。
欲しいシステムの概要や目的、希望納期などを伝えるためのA4用紙で1枚ほどのドキュメントです。

2. 発注先候補に対してオリエンテーションを行う

「オリエンテーション」とはは前項目である1のRFPを開発業者に説明するプロセスです。
個別にRFPなしに打ち合わせをすると開発会社の担当によって打ち合わせ内容にバラつきが出てくるので各社共通に、RFPで説明するのがオリエンテーションだと考えておきましょう。

3. 相見積もりを検討して候補を絞り込んで決定

「相見積もり」は一般的な言葉ですが、金額だけでなくRFPに対する回答、提案内容をしっかりと見比べてください。

4. 基本契約書締結

「基本契約書締結」は、開発が進行したときの役割分担などは後回しにして、ざっくりとした金額や保守対応などの枠組みについての合意事項をドキュメントにします。
その名の通り「基本契約書締結」にすぎませんので、必ず項目9の「個別契約書作成」を行ってください。

5. 要求定義作成

「要求定義作成」は一般的な言葉にすると、RFPをもっとかみ砕いて、どんな場面でどんな問題が生じていて、それをどんな風に解決したいか、を開発者に伝えることです。

6. 要件定義作成

「要件定義作成」は一般的な言葉にすると、「要求定義」を開発者側から見て、システムに落とし込んだ必要機能などを指します。

7. 外部設計

「外部設計」は一般的な言葉にすると、全体のインターフェースや業務フローの画面遷移、データベース入出力画面などの外見的な見た目を設計することです。
システムが使いやすいかどうかの鍵になりますので、しっかり打ち合わせをして、その内容を詰めてください。

8. 内部設計

「内部設計」は一般的な言葉にすると、プログラミングの設計です。
この部分についてはシステム開発会社に任せてしまってかまいません。

9. 個別契約書作成

「個別契約書作成」は一般的な言葉にすると「作業分担内容」「共同作業内容」を明らかにし、「最終的な請負金額」を明記する契約書です。
これがないままに開発が見切り発車してしまうと、大きなトラブルを呼ぶことにもなりえますので、十分な注意が必要です。

10. テスト計画

「テスト計画」は一般的な言葉にすると、「納品時にどんな検証項目を設定するか」です。
Excelなどでチェックリストを作るのが一般的です。

11. プログラムコーディング開始

「プログラムコーディング開始」は文字通り、発注先での作業開始を指します。
システム開発の外注プロセスでは、すでにここまで10の項目があったわけですが、この項目11の「プログラムコーディング開始」を外注のスタートと考えてしまいがちなので要注意です。

12. 単体テスト

「単体テスト」は一般的な言葉にすると、分割して作成したプログラムが動くかどうかのテストです。
これは開発側に任せてしまって構いません。

13. 結合テスト

「結合テスト」は一般的な言葉にすると、分割して作成したプログラムを合体させたときに動くかどうかのテストです。
こちらも開発側に任せてしまって構いません。

14. システムテスト

「システムテスト」は一般的な言葉にすると、納品先の環境でプログラムが動くかどうかのテストです。
こちらも開発側に任せてしまって構いません。

15. 受入テスト

「受入テスト」は一般的な言葉にすると、10の「テスト計画」で作ったリストを元に、納品物の検収作業を行うことです。
項目17の本稼働後に、システムを動かしながら修正するのは困難が伴います。
期待された動作が正しく行われるかを漏れ無く確認しましょう。

16. 納品

文字通り納品です。
物品の注文とはことなり、システムの場合は稼働してこそ意味があるものです。
ここで気を抜かず、次の項目17の本稼働に向けて、社内での導入体制や手順を整えておきましょう。

17. 本稼働

「本稼働」は一般的な言葉にすると、「現場で業務を開始すること」です。
この段階で問題が明らかになった場合には、すぐに開発会社に報告して対応するようにしてください。
項目9の「個別契約書作成」のときに納品後どのくらいの期間まで無償で不具合に対応するかが書かれているはずです。
期間を過ぎると明らかにプログラムのバグだと思われる場合であっても、有償の対応となる場合もありますので注意が必要です。

18. 保守・メンテナンス

文字通り保守・メンテナンスとなります。
こちらは基本的には有償となりますので、契約書にて保守・メンテナンスに関わる金額を決めた上で対応してもらうようにしましょう。

【まとめ】開発者との密なコミュニケーションがシステム開発成功の鍵!

いかがでしたでしょうか?一見難しそうに見えて、システム開発の言葉も一般的な言葉に翻訳すれば、一部のプログラミング作業などを除いて、発注者がキチンとおさえて置かなければならないものばかりでしたね。
こうした部分を押さえて置き、開発側の担当者と密なコミュニケーションを取ることがシステム開発成功のコツです。

日本最大級の発注業者比較サイト『アイミツ』ではシステム構築に関する専門知識を持ったコンシェルジュが、信頼のおける会社を完全無料で紹介することができます。

システム開発には、大きな期間とコストが掛かるものです。
一度大きく切り替えると、もとに戻すことは現実的には不可能です。
外注の進め方や外注先の選定についてなど、まずはお気軽にお問い合わせください。
すぐれたコンシェルジュが、あなたの会社に合った企業選びを全力でお手伝いさせていただきます。

見積もり、取ってますか?

発注をする際に最も大切なことは適正価格を知ることです。
3~4社から見積もりを取ることで、
発注への納得度を高めることができます。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください