VNEXTの会社紹介資料

資料ダウンロード

ホーム > V-BLOG > 技術・サービス

ある日突然システム開発担当に!システム開発の流れをおさらい

2024/03/12

ある日突然、「今度、このシステム開発の担当を任せることになったから、よろしく!」と言われたら、まったくの初心者のあなたは、「システム開発って?どうやって進めていくの?」と大いに焦ることでしょう。

 

あるいは、「昔、システム開発を担当したことはあるけど、どうやって進めたのかよく覚えてないな」と不安に思っている人もいるかも知れません。

 

ひとくちにシステム開発といっても、ターゲット分野や機能内容はさまざまです。しかし、どの分野のシステムでも、どんな機能のものでも、開発の進め方は基本的に同じです。

 

本記事では、システム開発の工程と進め方について解説します。システム開発未経験の方も、大昔にシステム開発を経験した方も、ここでシステム開発の流れについておさらいしておきましょう。

 

 目次 

● システム開発の工程・進め方

 ▶︎ 1. 要件定義

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

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

 ▶︎ 4. 開発(プログラミング)

 ▶︎ 5. テスト

 ▶︎ 6. リリース(システム移行)

 ▶︎ 7. 運用・保守

● 開発手法ごとの工程・進め方

 ▶︎ ウォーターフォール開発

 ▶︎ アジャイル開発

● 工程表の作成とスケジュールの立て方

● システム開発でプロセスが重要な理由

● システム開発の工程で使う略称一覧

● まとめ

 

 

|システム開発の工程・進め方 

システム開発の工程

 

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

要件定義や基本設計などを「上流工程」、コーディングやテストなどを「下流工程」と分類します。

 

工程 概要 全工程に対する工程比率
要件定義 実装すべき機能や納期、必要な人員(工数)などをまとめる 15〜20%
基本設計(外部設計) システムのおおまかな構造やインターフェース、データの保存場所や取得方法などを設計する 10〜15%
詳細設計(内部設計) 基本設計で定義されたシステムの詳細な実装方法(プログラミング方法)を計画する 10〜15%
開発(プログラミング) 設計内容を実装する 30%程度
テスト 作成したプログラムが正常に動くかをテストする 20~25%
リリース(システム移行) 旧システムから新システムに切り替える 数%
運用・保守 システムの稼働が停止しないように監視や、不具合が起きたときの改修などを行う 継続的に実施

 

フェーズごとの作業内容について詳しくみていきましょう。

 

 1. 要件定義 

要件定義とは、開発するシステムの目的に基づいて実装すべき機能や納期、必要な人員(工数)などをまとめた設計図のようなものです。

要件定義をしっかり行うかどうかが、システム開発の成否を左右するといっても過言ではないほど、重要な工程です。

 

このフェーズでは、ユーザーのニーズを明確に把握し、システム開発の目的とスコープ(機能実現するものと機能実現しないものを区分けする作業)を定義します。

 

ここで定義する機能は、主に「機能要件」「非機能要件」の2種類に分けるのが一般的です。

 

・機能要件:発注者(クライアント)から求められるシステムの機能のこと

・非機能要件:ユーザービリティ、性能、拡張性、セキュリティなどの機能以外の要件のこと

 

このようにして、システムの要件を定義づけるのが「要件定義」の工程で、その内容は「要件定義書」にまとめます。

要件定義をしっかりと行い、要件定義書にきちんと明文化しておくことで、発注側と開発側の認識の相違によるトラブルを防ぐことが可能です。

 

また、要件定義は、一般的に発注側の責任で行うべきとされることが多いですが、知見がない場合は要件定義が不十分になり、納期の遅れや費用の増大などのトラブルが生じることもあります。

そのため、発注する側に知見がない場合は、開発会社が要件定義の支援を業務として行ってくれるのかなども事前に確認をしておくとよいでしょう。

 

 

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

基本設計では、要件定義の内容を基に、システムの大まかな構造や画面などの見た目(UI、ユーザーインターフェース)、データの保存方法や取得方法などを設計します。

 

ここでは、要件定義の内容を差異なく反映させることが大切で、そのためには開発チームと綿密に連携する必要があります。


基本設計は発注側と開発側が意見のすり合わせをできる最後の工程なので、打ち合わせではしっかりと内容を詰めていくことが重要です。

 

 

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

詳細設計とは、基本設計で定義されたシステムの詳細な実装方法(プログラミング方法)を計画するフェーズです

 

それぞれの機能を実現する処理をフロー図などに落としながら、タスクやモジュール(機能一つひとつのこと)といった小さい処理に分割します。

 

これは、異なる機能でも、その中の一部分は同じ処理である場合が多く、そのような処理を共通化できるようにしておけば、プログラミングの際に効率がよくなるためです。それぞれのタスクやモジュール内で実行させる処理や、どのようなデータがどのようにやり取りされるのかといった定義も行います。

 

このようにして決めた内容を「内部設計書」にまとめます。


また、ここまでの流れ(要件定義、基本設計、詳細設計)を「上流工程」といいます。

 

 

 4. 開発(プログラミング)

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

 

上流工程で決定した仕様に沿って、開発者(SEやプログラマー)が開発を行います。

内部設計書に基づいて、所定のプログラミング言語で各機能のタスクやモジュールのプログラムを作成していくのが「コーディング」の工程です。

 

内部設計書がしっかりと書かれていれば、効率よくプログラミングを進めていくことができます。

 

また、プログラミング言語にはいくつかの種類がありますが、開発するシステムの種類によって使う言語が異なってきます。

 

《システム開発に使用される開発言語の一例》

PHP(ピーエイチピー):WebシステムやWebサービスの開発によく使われる言語

Ruby(ルビィ):Webサービスのバックエンド開発、Webアプリの開発によく使われる言語

C言語C++(シー言語、シープラプラ):ゲーム制作や汎用系システムの開発によく使われる言語

 

 

 5. テスト 

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

 

このテストのフェーズでは、以下の4種類のテストが行われます。

テストの種類 概要
単体テスト プログラミングのモジュール(対象単位)ごとのテストを行います。最初の要件定義で求められている基準を満たしているかを確認していきます。
結合テスト 複数のプログラムを組み合わせた状態で、それらがうまく機能するかを検証する工程。先程の各モジュールを結合して、データの受け渡しなどでプログラム同士が正常に連携するかをテストします。
総合テスト すべてのプログラムが、要件定義の通りに動くのかを確認する工程。このときに、アクセスへの耐久性や処理速度などもテストします。
運用テスト 実際にシステムを運用する環境下において、システムに不具合がないかをテストします。ここでは、実際に業務に取り入れることができるかという点をテストしていきます。

 

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

 

 

 6. リリース(システム移行)

テスト工程が完了したら、システム移行をおこないます。システム移行とは、実際に使えるように、旧システムから新システムに切り替える工程です。

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

リリースが完了したら発注側が動作確認などをおこない、問題がなければ納品完了となります。

 

 

 7. 運用・保守 

システムは、開発してリリースしたら終わりではありません。リリース後、間もないシステムでは、予期せぬ不具合が発生することもあります。また、実際に使ったユーザーのフィードバックから、改修しなければならないこともあるでしょう。

 

このように、システムは作った後もメンテナンスし続ける必要があります。それが「運用・保守」です。

 

・運用:システムの正常状態を維持し、状況に合わせて変化、拡張させること

・保守:システムに不具合が生じた際に適切な対応をすること

 

運用・保守の工程は自社で行うことが理想的ですが、難しい場合は外部に依頼することも可能です。

 

ここまでが一般的なシステム開発の工程となりますが、開発手法に違い工程に差が出ることがあります。ここまで紹介してきた工程は、「ウォーターフォール型」と呼ばれる開発手法ですが、近年ではより柔軟に開発ができる「アジャイル型」での開発も増えてきています。

 

次は、開発手法ごとの工程をみていきましょう。

 

 

|開発手法ごとの工程・進め方 

開発に取り掛かる手順には、いくつかの種類がありますが、代表的な開発モデルとしては、「ウォーターフォール」「アジャイル」というモデルがあります。

システム開発の工程は、開発手法により各工程をどのように進めていくかが変わってくるため、ここからはそれぞれの違いをみていきましょう。

 

|ウォーターフォール開発 

ウォーターフォール型とは、ここまで紹介したような開発工程を、1つずつ順番に完了させていく開発モデルです。まず初めに要件を厳密に固めてから、それに沿って工程ごとに開発を完了させていきます。

 

ウォーターフォール型は、プロジェクトによって例外はあるものの計画的に工程が進むため、進捗状況の把握が容易であることや、品質が担保しやすいという特徴を持っています。

 

V字モデル

 

ウォーターフォール開発の理解に欠かせないのが、上図の「V字モデル」です。V字モデルとは、開発工程とテスト工程の対応関係を表したものです。

 

単体テストでは、詳細設計での内容が正しく実装されているのかをテストし、結合テストでは基本設計の内容、総合テストでは要件定義の内容、といったように進めることで、検証作業を効率よく完了させることができます。

 

 

|アジャイル開発 

アジャイルとは、日本語で「素早い」という意味を持ち、とにかくスピード感のある開発方法です。

機能ごとに「企画→開発→テスト→リリース」のサイクルを回していくので、開発を進めながら随時変更や修正を行うことができます。

アジャイル開発

 

この開発方法は、要件定義が明確にできておらず、まずは作りはじめてみて随時修正をしたい時には最適な開発方法です。スタートアップや新規事業に向いている開発モデルといえるでしょう。

 

ウォーターフォール開発やアジャイル開発についてより詳しく知りたい方は、以下をご覧ください。

▶︎ システム開発とは?工程や開発手法、費用から依頼時の注意点を徹底解説!

 

 

|工程表の作成とスケジュールの立て方 

システム開発を進めていく時は、WBS(Work Breakdown Structure:作業分解構成図)を作成して、管理していくことが一般的です。WBSでは作業項目を一覧にして洗い出し、タスクの種類や粒度によってツリー構造で引き下げていくことで、抜け漏れなく各工程を進められます。

 

同時にガントチャートなどを作成し、プロジェクト全体を見える化してスケジュール管理をしていきます。

WBS

ガンチャートのイメージ

 

工程表のもっとも重要な役割は「納期管理」です。

納期の遅延は、後工程や顧客関係にも影響が出て、最悪の場合、売上損失・会社の信頼損失に繋がります。工程表を作成して開発を進めていくことで、そのようなリスクを最小限に抑えることができます。

 

 

|システム開発でプロセスが重要な理由 

ここまで、システム開発の「プロセス=工程を分けて流れに沿って進めること」について説明してきました。

そもそもなぜシステム開発はこのように工程を分け、一定の流れに沿って行う必要があるのでしょうか?

 

ここでは、システム開発におけるプロセスの重要性を考えておきましょう。

 

|プロダクトの品質確保

まず第一に、システムをプロセスに沿って開発することで、成果物のクオリティを確保することができます。

ウォーターフォール型であれば各工程ごと、アジャイル型であれば各機能の開発サイクルごとに確認やレビューを行うため、品質が細かくチェックされます。

その繰り返しがあることによって、システムのクオリティを保つ、あるいは高めることが可能になります。

 

 

|プロジェクト内での認識統一 

開発の流れや各工程ですべきことがあらかじめ決まっていれば、プロジェクトチームのメンバーが共通の認識で開発を進めることができます。

どの段階でどんな作業をするのか、今どこまで進んでいるのかを全員が把握することで、齟齬がなくスムーズに分担作業が可能になるのです。

 

また、開発を外注する場合は、発注側と開発会社側の認識統一も必要です。

プロセスが決められていれば、それを基に「今どこまで進んでいるのか」「これから何をするのか」「この機能開発はどの段階で行われるのか」といった進捗やスケジュールを共有できるため、コミュニケーションもとりやすく、結果として発注者の満足度を高めることにもつながります。

 

 

|納期の遵守 

システム開発を自由度高く進めていると、変更や修正がたびたび発生することで開発期間が延長されやすく、納期遅れにつながるリスクがあります。

その点プロセスが決まっていれば、それに沿ってスケジュールも立てやすく、進捗管理がしやすいというメリットがあります。

納期遅れを未然に防ぎ、予定通りのリリースを目指せるのです。

 

 

|コスト削減 

納期の順守と同時に、コストコントロールがしやすくなるのもメリットです。

開発がどのように進められるか、どこで誰が何をするか、どの程度の工数と期間がかかるかといったことが把握できれば、それに対して最少のコストで対応する方法を考えることも可能です。

無駄なコストが発生させず、全体の開発費用削減につながります。

 

 

|経験値の活用 

あらかじめ決められたプロセスにのっとって開発すると、それはプロジェクトメンバーにとって経験値として蓄積されます。

そうすると、次に同じプロセスで開発をする際に、その知見を活かしてよりよい成果があげられるようになります。

 

たとえば、同じウォーターフォール型の開発でも、回数を重ねれば失敗は少なくなり、成功するためのポイントが身についていきます。これが毎回プロセスを決めずに自由な進め方で開発していると、そこで得た経験や知識を体系的に積み上げることは難しいでしょう。

 

システム開発を成功させる要因はさまざまですが、そのひとつがエンジニアのスキルと経験です。それらを高めるためにも、プロセスに従って開発を進める必要があるのです。

 

 

|システム開発の工程で使う略称一覧 

最後にもうひとつ知っておきたいことがあります。それは、システム開発のプロセスでよく用いられる略語とその意味です。

これらを知っておくことで、開発に携わるメンバー同士、または発注側と開発側との間でコミュニケーションがとりやすくなり、プロセスをスムーズに進捗させることができるでしょう。

システム開発 略称

 

 

|まとめ 

企業にとって、システム開発はとても大切な要素の一つです。

企業や組織の生産性はシステム品質に影響される部分が大きいため、利便性が高く高品質なシステムを開発することが、そのまま競合優位性に直結します。

 

また、システム開発には決められた工程(流れ)があるため、この記事を読み返して基本に忠実に進めてください。

世の中には多くの開発手法が存在しますが、どれも一連のプロセスは共通しているため、基本を押さえておくことで様々なシーンに対応できます。

 

ぜひ、大きな視点を持ってシステム開発に取り組んでください。