システム開発工程
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

システム開発の工程とは?基本的な流れから、注意点まで詳しく解説!

目次

はじめに

システム開発の成功のためには、エンジニアチームの経験と実績、適切なプロジェクト管理、トラブル発生時の対応力など、さまざまな要因があります。

ただ、システム開発を経験したことがない人は、システム開発がどのように進んでいくのかイメージしにくいのではないでしょうか。

複雑に思えるシステム開発にも、実は、いくつかの手法・メソッドが定義されており、多くのシステム開発は、いずれかの手法・メソッドに沿って進められます。

この記事では、日本で広く使われている標準的なシステム開発工程「ウォーターフォール」について、概要からメリット、注意点についてまでご紹介いたします。

システム開発のコストを半分以下に?!「オフショア開発」についてまとめた資料はこちら

システム開発工程とは

「開発工程」とは、システム(もしくはアプリ)を最小限の時間・コストかつ高品質で開発するための枠組みです。言い換えると、十分にテストされた高品質のシステムを迅速に開発できるようにするための、構造化されたフェーズです。

開発工程の各工程(フェーズ)には、要件定義、設計、開発、テスト、リリース、運用・保守、新規・拡張開発(エンハンス)などがあります。

システム開発に必要な期間は、開発するシステムの規模にもよりますが、3ヵ月から6ヵ月、長い場合は1年以上かかることもあります。完成されるシステムがすべての要件を満たすようにするためには、開発工程のすべてのフェーズを正しく行う必要があります。

システム開発工程があることによって、プロジェクトの進捗管理や状況把握がしっかりと行え、開発するシステム(もしくはアプリ)の品質向上が期待できます。

 

開発工程の仕組みと役割

繰り返しになりますが、開発工程を理解することで、システム・アプリ開発にかかるコストや、品質確保のために注意すべき点を把握しやすくなります。

一般的な開発工程のステップは以下の通りです。

  1. 要件定義
  2. 基本設計(外部設計)
  3. 詳細設計(内部設計)
  4. 開発(コーディング/プログラミング)
  5. テスト
  6. リリース
  7. 運用・保守

特に「1. 要件定義」は最初の段階でありながら、最も重要なフェーズだと考えれています。

要件定義は、プロジェクトの残りの部分の基準となり、完成したシステムが使い手(ユーザー)の期待に応えられるかどうかを左右する重要な役割を果たします。そのため、何よりもまずこの段階では、自分の意図や計画を率直に開発者(会社)と共有する必要があります。

システム開発工程の各フェーズ

それでは、開発工程の各フェーズについて、詳しく見ていきましょう。

1. 要件定義

開発したいシステムによって、どのような課題を解決したいのか、何を実現したいのかを洗い出す=定義するフェーズ(段階)です。

一見、自分の願望を伝えるだけのシンプルな作業に見えますが、多くの人がこの要件定義の段階で、関係者も含んだ網羅的な願望(要件)を伝えることができません。

よくある失敗例をご紹介しましょう。

現場を知らない部門長が、「現場スタッフの作業を可視化して、フィードバックしやすいように、作業ログ取得システムを作って欲しい。」とリクエストするとします。

ここで重要なのが、この要件定義の段階で、現場から代表者が参加しているかどうかです。

もし、現場の代表者が参加していれば、「作業ログ取得は良いですが、作業をしたら、いちいちシステムに入力をしないといけないのは、非現実的です。現場スタッフの作業効率が下がります」と、部門長のリクエストに対する懸念点を指摘してくれるはずです。

もし、現場代表者がいなければ、部門長の要望だけを汲み取った「無用の長物」になりかねません。

「やっぱりこうしたい」に注意!

また、要件定義のフェーズでは、漏れなくダブりなく要件を伝える必要があります。

もし漏れがあると、後々の開発フェーズで「やっぱりこういう機能も欲しい」とリクエストが出ることになり、開発者は混乱します。

これがシステム開発プロジェクトでよく問題視される「仕様変更」です。仕様変更はプロジェクトの期日に影響を及ぼすだけでなく、追加の費用発生など、さまざまなリスクを招きます。

仕様変更を見越して開発スケジュールを決めるプロジェクトマネージャーもいますが、開発を依頼する側は、漏れなくダブりなく(MECE)、要件定義できるよう心がけることが大切です。

要件定義のフェーズでは、まず誰を参加させて、何がどこまで必要か、誰の何のためのシステムなのかをしっかり定義することが重要です。

2. 基本設計(外部設計)

基本設計(外部設計)とは、UI(ユーザーインターフェース)つまり、システムの操作画面などの「見た目・デザイン」を設計するフェーズです。

UIはシステム・アプリの操作性、効率性、アクセス性を最大限に高め、ユーザーの関わり方(UX:ユーザー・エクスペリエンス)に影響を与えるため、見栄えの良さだけを優先しないことが重要です。

ユーザーの視点から見ると、UIはシステム・アプリの性能を決定する重要な役割を果たすため、ユーザーにとってストレスなく使いやすい設計をすることが大切です。

このフェーズでの成果物は「基本設計書」となります。

3. 詳細設計(内部設計)

詳細設計(内部設計)とは、システム・アプリの「中身(機能・動作)」に関する設計です。開発言語、サーバー・データベース、APIとの連携など技術的な要素を中心に検討・設計されます。

家の設計に例えるならば、基本設計が外壁や内装=「人の目に見える部分」の設計であるのに対し、詳細設計では、「人の目に見えないが、家として機能するために必要なもの」を設計することになります。

このフェーズの成果物は「詳細設計書」となります。

ここまでの、「要件定義」「基本設計」「詳細設計」のことをまとめて、一般的に「上流工程」とよばれています。

4. 開発(コーディング/プログラミング)

開発のフェーズは、いよいよ「欲しいものを作る」フェーズです。この開発フェーズから、「下流工程」が始まります。

上流工程(要件定義と基本・詳細設計)で決定した仕様に沿って、開発者が開発を行います。

このフェーズでは、C++、PHP、Java、Ruby、Pythonなどの開発言語(プログラミング言語)で開発を行うほか、インフラ(サーバーやデータベース)部分の構築も行われます。この開発フェーズと後述するテストフェーズで、一番、時間と労力が必要とされます。

このフェーズの成果物としては、実際のシステム・アプリやソースコード(プログラミングが記述されているファイル)などがあります。

5. テスト

テストのフェーズでは、テスターとよばれる担当者が、作成したプログラム(システム・アプリ)を納品する前に不具合(バグ)がないか、求められている機能が正しく動作するか、などを検証します。

テストの過程で不具合(バグ)が発見されることも、もちろんあります。

問題が発見された場合、テスターは開発者に通知し、開発者(プログラマー)は修正して、テスターが再度、検証します。

さらに、このテストフェーズには複数種類のテストがあります。

以下に、代表的なテストの種類を紹介します。

ユニットテスト

ユニットテストとは、システム・アプリを構成する個々の機能(ユニット)を検証するテストです。

たとえば、勤怠管理システムを開発する場合、「従業員の勤怠を記録する機能」や「給与を計算する機能」は、それぞれ別のユニットとなります。

結合テスト

結合テストとは、上述した各ユニットを結合し、1つのグループとしてテストすることです。

こちらも、要件を満たしているか、不具合(バグ)がないかを検証します。

総合テスト

総合テストとは、システム・アプリ全体のテストです。統合テストとよばれることもあります。

開発したシステム・アプリが、完成品として機能するかを検証するテストです。

運用テスト

システム・アプリを納品・リリースする前の最終工程です。

ユーザーが実際にシステム・アプリを操作したときに、期待通りに機能するかを確認するためのテストです。総合テストとの違いは、運用テストでは実際のユーザーが操作するのに対し、総合テストでは実際ユーザーは関わらないことが一般的である点です。

ここまでさまざまなテストをご紹介しましたが、煩雑だと感じたのではないでしょうか?

しかし、テストフェーズは、目的のシステム・アプリができているかどうかを確認するとても重要なフェーズです。

納品・リリース日を優先するために、テストフェーズをおろそかにすると、市場・ユーザーに「未完成」のシステム・アプリを届けることになります。そうなると、システム・アプリの評判が下がり、中長期的に失敗する可能性が上がります。

6. リリース

システム・アプリは、上述した各テストで徹底的に検証され、品質が保証された後、実際の市場・ユーザーにリリース(公開)されます。

実際のリリースでは、企業のビジネス戦略に応じて、予定されているすべての機能が一度にリリースされるわけではなく、段階的にリリースされることもあります。

7. 運用・保守

リリース後、間もないシステム・アプリでは、予期せぬ不具合が発生することもあります。

また、実際に使ったユーザーのフィードバックを元に、改修する必要があるかもしれません。

この運用・保守フェーズでは、システム・アプリが安定稼働するために、人員を確保する必要があります。開発時ほどの人員規模は必要ありませんが、不具合や急なトラブルに対応するためにも、運用・保守担当者が必要です。

以上のことから、システム・アプリ開発は「作って終わり」ではなく、作った後もメンテナンスし続ける必要があることがわかるでしょう。

システム開発工程に従って開発を行うメリット

開発工程は、最終製品(システム・アプリ)の目的や、解決したい課題を明確にするためのものです。開発を成功させるために、関係者に対してロードマップの役割を果たします。

また、今後、必要となる施策を計画するためのツールでもあります。

すべてが前もって計画されていれば、プロジェクトはよりスムーズに進行します。開発工程は、プロジェクトマネージャーが進捗を把握することをサポートし、開発チームが予定・予算内で完成できるようにします。

開発工程における各フェーズの成果物やトラブル対応についてのドキュメントが整備されていれば、新しいプロジェクトメンバーへの引継ぎや、プロジェクトが迷走し始めたときにも役立ちます。

システム開発工程の注意点

システム・アプリ開発工程を参考にする際の注意点をいくつかご紹介します。

不明瞭なコミュニケーション

開発の遅延や障害を避けるためには、すべての関係者がお互いに適切なコミュニケーションを取る必要があります。

特に、要件定義は既述の通り、最も重要な段階ですので、このフェーズでのコミュニケーションは、しっかり取りましょう。

度重なる仕様変更

プロジェクトが下流工程に入ってからの仕様変更は、当初の目的や製品(システム・アプリ)が変わることを意味します。

仕様変更をリクエストする方は、ほんの一部分の変更だけだと認識していますが、開発側にとってはそうではありません。一部分の変更は、連携する機能(ユニット)にも影響が出るため、大きな見直しと修正コストがかかります。その結果、スケジュールが遅延し、開発コストがかさんだりします。

そのため、できるだけ上流工程(要件定義、基本・詳細設計)での仕様確定が求められます。

どうしても仕様変更が必要な場合は、仕様変更にかかるリスクを把握した上で行いましょう。仕様によっては、リリース後の「運用・保守」フェーズで、修正・追加対応ができる場合があります。

まとめ

今回はシステム・アプリ開発工程の各フェーズの概要や必要性と注意点について紹介しました。

システム・アプリ開発には、リリース後の運用・保守も含めると、決して安くはない費用とある程度の期間がかかることがわかると思います。

開発・運用コストを抑えたい、開発人員を増やしたいなら、オフショア開発がおすすめ!

オフショア開発とは、システム・アプリ開発や、運用・保守などの業務を海外の開発企業にアウトソースすることです。

東南アジアなど、日本の人件費より安い海外人材を活用することにより、採用・教育などにかかるコストを抑えることができます。

たとえば、80万円/月の日本のエンジニア1名を確保する場合、ベトナムであれば、同じ費用で2~3人のエンジニアを確保することができます。

オフショア開発をもっと知るなら

オフショア開発について、もっと詳しく知りたい方は以下のコンテンツをぜひご参照ください。

【ブログ】知っておくべき!オフショア開発とは?概要から注意点まで

このブログでは、具体的にオフショア開発はどのようにしてそのような期待を実現するのか、オフショア開発について知っておくべきこと、そしてオフショア開発プロジェクトを成功に導くために注意すべきことについて、解説します。

【動画】【2022年版】2分でわかる!オフショア開発とは?

本動画では、日本のIT開発プロジェクトと深く関係がある「オフショア開発」の概要とメリットについて、サクッとで解説しています。

【無料相談】ベトナム第二位のICT企業が提供するオフショア開発|CMC Japan

CMC Japan株式会社は、ベトナム第二位のICT企業「CMC Corporation」グループ初の日本法人です。約30年間、グループ全体で培ってきたノウハウと実績をもって、高品質なオフショア開発を提供しています。オフショア開発に関して、ご興味があれば、お気軽にお問い合わせください。

【お役立ち資料】 ベトナムオフショア開発入門書
資料ダウンロード

資料は下記のフォームを送信して頂くと完了画面またはメールにてダウン口一ドできます

Previous
Next

アフター/ウイズコロナの開発リソース支援なら、CMC Japan

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
この記事を書いた人
この記事を書いた人

Hien(ヒエン)
ベトナムハノイ貿易大学のビジネス日本語学部卒。2018年に東京でインターンシップ、その後4年間マーケティング業務に従事。「マーケティングで、社会を変える奇跡を作る」ことを目標に、2020年からはB2B市場を中心に活動。趣味は自己改善、読書、座禅。