システム開発の工程には型があります。上流から下流までの工程が、おおむね定型化されています。
しかし開発に慣れていない方、開発を他社に委託する方のなかには「システム開発は、どんな工程で進むんだろう？」「漏れがないように、一般的な開発の流れを知りたい」と考えている方も多いのではないでしょうか。
そこで今回はシステム開発の工程をステップごとに紹介します。工程ごとに、弊社ファンリピートのエンジニアが気を付けていることも掲載します。
システム開発の各工程について気になっている方は、参考にしつつ取り入れてみてください。
監修者
竹村貴也
株式会社ファンリピートCEO
著書:「ChatGPTによるPythonプログラミング入門. AI駆動開発で実現する社内業務の自動化」
＼ ノーコード/ローコードやAI関連の情報をお届け ／
無料のBOLTメールマガジン
不定期でノーコード/ローコードやAI関連のお役立ち情報をお届けするメルマガです。
- ノーコード/ローコードの基礎・応用情報がわかる
- 個人利用やビジネスで生かせるAI活用方法がわかる
- 限定オファーや資料公開、ウェビナー情報がいち早く届く
ノーコード/ローコードを用いたシステム開発やAI利活用に興味がある方はぜひご登録ください！
システム開発の主要工程
まずはシステム開発の主要な工程について紹介します。システム開発の手順は、一般的に以下の6ステップです。
- 要件定義
- 設計
- 実装
- テスト
- リリース
- 保守・運用
ステップごとに具体的な内容、またファンリピートで実際にシステム開発に取り組んでいるシステムエンジニアからの情報を紹介します。
弊社・ファンリピートでは、企業様のシステム開発の支援を行っています。ローコード・ノーコードを積極的に用いることで、他社と比較して短納期かつメンテナンスしやすい形で納品できることが魅力です。
気になる方は、無料で資料をダウンロードしてみてください。
要件定義
まずは開発する内容について要件定義をします。要件とは「システムの機能・条件」のことです。
開発に入る前に要件を定義することで、システム開発のゴールが明確になります。またリリース後の保守・運用について迷いなく推進できるでしょう。
具体的に、以下の要件を定義しておく必要があります。
ビジネス要件
| 項目 | 詳細 |
| ビジネス目標 | システムの導入目的ビジネスゴールとKPI必要な予算期待されるROIリリース後の業務の変化 |
| 機能要件 / 非機能要件 | 必須機能と希望機能のリスト各機能の優先順位付けパフォーマンス要求（速度など）セキュリティ要件ユーザビリティ |
| ステークホルダー / 座組み | 開発チームの設計会議の設定関連する利害関係者の特定 |
開発要件
| 項目 | 詳細 |
| 技術要件 | システムアーキテクチャ使用するプラットフォーム技術スタックインターフェースとAPI要件 |
| インフラ要件 | ハードウェアとソフトウェアの要件ネットワークとセキュリティの設定可用性とバックアップ計画 |
| 開発プロセス | 開発モデルプロジェクト管理ツールとコミュニケーションツールコードレビューとテストのプロセス |
| スケジュールとリソース | プロジェクトのタイムラインとマイルストーン必要なリソースリソースの割り当てと管理計画 |
| テスト計画 | テスト戦略テストケースの定義 |
| デプロイメントと運用計画 | 運用と保守の計画ユーザーサポートとトレーニング |
厳密にいうと、要件定義の前に「要求定義」があります。まずはユーザーからのシステムに関する要求を定義したうえで、スケジュールや予算と相談しながら「要件」に落とし込んでいきましょう。
社内SEに聞いてみた！
要件定義の際に最も重視していることは何ですか？
クライアントのご要望を鵜呑みにするのではなく、機能を開発したい意図や背景を確認している。 理由としては機能が冗長、複雑になり使用感が損なわれる恐れや、現場側と管理側での認識齟齬が発生している可能性があるため。 要件を確認してこちらから提案することもあります。
顧客との認識齟齬を防ぐために、どのような工夫をしていますか？
要件定義を行った際に改めて認識に間違いがないのか認識合わせを行っています。
設計
要件定義が完了したら、システム設計をします。
上記の要件をもとにデータベース、ハードウェア、ソフトウェア、アプリケーション、インフラネットワークなどの構造を設計書に落とし込んでいく作業です。
具体的には以下の4つの項目について設計しましょう。
| 項目 | 詳細 |
| 方式設計 | システム全体の技術的な枠組みや方針を設計します。 |
| 基本設計（外部設計） | 主にシステム概要図、画面・帳票といったUI部分など、ユーザーの目に触れる範囲について設計します。 |
| 機能設計 | アプリケーションとして実装する機能やデータベースなどを設計します。 |
| 詳細設計（内部設計） | システムの各モジュールやコンポーネントをプログラムレベルで詳細に設計します。 |
社内SEに聞いてみた！
設計工程において、特に重要だと考えていることは何ですか？
論理設計で実装時によるreworkを減らすことだと思います。 設計をせずに実装を行うと、「機能が実現できなかった」「テスト時に必要なシナリオを洗い出せていなかった」「この機能は他の機能と干渉してしまう」といったケースが発生しがちです。 そうなると、システムの保守性、期日まで遅れてしまうといった事象が発生してしまい、結果的にクライアントにとって悪印象を与えてしまう原因になりかねません。 なので、実装前に処理フロー、テストケースを作成しておくことによって、カバーすることができるため、大事なフェーズかと思われます。
設計の段階で、開発の効率や品質を向上させるために意識していることはありますか？
定期的に実装後のコードや設計を見直すことだと思います。 設計段階においては最適な処理を組んだとしても、他の機能との相性が悪く、パフォーマンスが著しく低下してしまうことや時間が経つことによって、新しいソリューションが見つかったりすることがあるので、定期的にログから各機能の処理速度、エラー出力の確認、既存設計を見直すようにしています。
実装
設計した内容に従って実装・開発を進めていきます。設計した内容に従って、実際にコーディングを進めていき、レビューします。細分化すると、以下のステップです。
| 項目 | 内容 |
| コーディング | ・モジュール開発・コードレビュー |
| インテグレーション | ・モジュール統合・連携後の動作レビュー |
| ドキュメント作成 | ・エンジニア向けマニュアル作成・ユーザー向けマニュアル作成 |
社内SEに聞いてみた！
開発中に発生したバグやトラブルには、どのように対応していますか？
明らかにツール側でのバグの場合は、サポートセンターに問い合わせます。 他実装箇所との兼ね合いで想定外のバグ等が出ている場合は、対象箇所の実装者と連携等しながら対応を進めていきます。 要件が不鮮明だった場合は洗い出して先方に確認後、再度実装します。
開発チームで円滑にコミュニケーションを取るために、どのような工夫をしていますか？
たまに口頭で進捗を確認し、悩んでいる個所が無いか等を確認しています。 実装が難しそうな箇所も口頭で会話をしながら積極的にアイデアを出し合っています。
テスト
実装・レビュー後に、テストを行います。リリース前に「開発したシステムが正しく動作するか」を確認する作業です。
ユーザー側の動作はもちろん、システム内での動作も確認する必要があります。また開発で使用するプログラムは複数にまたがります。
そのため、ユーザー側の動作テストはもちろん、内部テストを行いましょう。また、単体だけでなく統合されたプログラムを確認しなくてはいけません。具体的には以下のテストを行います。
| 項目 | 詳細 |
| 単体テスト | プログラムの動作について、1つずつチェックします。 |
| 統合テスト | 複数のプログラムについて動作をチェックします。 |
| 総合テスト（システムテスト） | 実際に使用するのと同じ環境・負荷で動作をチェックします。「確認テスト」「負荷テスト」「評価テスト」に分けられます。 |
| 受入テスト（ユーザーテスト） | 実際のユーザーが行うテストです。ユーザーからのフィードバックをもとにユーザビリティを高めていきます。 |
ただし、開発モデルによっては、これらのテストに時間を割かないこともあります。システム開発のテストについては、以下の記事で詳しく紹介しています。
社内SEに聞いてみた！
テスト工程で、特に重点的にチェックしている部分はありますか？
テスト仕様書がある場合は、その指示に従います。特に視覚的な表現と機能性に重点を置いてチェックします。イレギュラーケースも可能な限り確認します。
テスト工程において、品質を担保するためにどのような工夫をしていますか？
新しいシステムの場合、エンドユーザーにとって視覚的に快適で、UI/UXが良好であることを確認します。また、機能的であると同時に、便利性・見た目も兼ね備えたシステムが重要であると考え、そのバランスを保つよう努めています。
リリース
テスト後のフィードバックをすべて修正しきったらリリースです。リリースとは「想定しているユーザーが使える状況にすること」を指します。
リリース前にはこれまでの工程を見直すことが大切です。例えば以下のような「リリース前チェック項目」を確認します。
- 機能確認
- すべての必須機能が実装されている。
- すべての機能が正しく動作する。
- ユーザーインターフェースが期待通りに動作する。
- テスト完了確認
- 単体テストが完了し、成功している。
- 結合テストが完了し、モジュール間の連携が確認されている。
- システムテストが完了し、全体的な動作が正常である。
- パフォーマンステストが完了し、負荷に耐えられることが確認されている。
- セキュリティテストが完了し、脆弱性がないことが確認されている。
- 受け入れテストが完了し、ユーザーからの承認が得られている。
- ドキュメント整備
- 技術ドキュメントが最新である。
- ユーザーマニュアルが完成し、ユーザーに提供可能である。
- リリースノートが作成され、変更点や新機能が明記されている。
- デプロイメント準備
- デプロイメント手順書が整備されている。
- デプロイメントスクリプトがテスト済みである。
- ロールバックプランが準備されており、緊急時に備えている。
- 環境確認
- 本番環境が準備されている。
- 必要なハードウェアおよびソフトウェアが配置されている。
- 環境間の設定（開発、ステージング、本番）が一致している。
- データ移行
- 必要なデータ移行が完了している。
- データ移行のテストが完了し、データの整合性が確認されている。
- バックアップが取得されている。
- セキュリティ確認
- セキュリティポリシーに従っている。
- アクセス制御が適切に設定されている。
- 機密データが保護されている。
- パフォーマンス確認
- システムが期待される負荷に耐えられる。
- レスポンスタイムが許容範囲内である。
- キャパシティプランニングが完了している。
- 運用準備
- 運用マニュアルが作成されている。
- サポート体制が整備されている。
- モニタリングツールが設定され、アラートが機能している。
- ステークホルダー承認
- すべての主要なステークホルダーから承認を得ている。
- リリースに関するすべての関係者に通知されている。
これらの項目を問題なくクリアできればリリースとなります。
社内SEに聞いてみた！
リリース前に必ず行うチェック項目はありますか？
いくつかありますが、例を挙げると、本番に反映させるブランチと開発ブランチで差分がないかのチェックや、DBやアプリのバックアップを取っています。 リリース前に行うチェックリストはasanaでテンプレート化していて、手順通り進めることでミスが出ないようにしています。
ユーザーに安心してシステムを使ってもらうために、どのようなことを心掛けていますか？
リリースに関してだと、スケジュール通りにリリースすることはもちろんですが、本番環境に反映後、動作が問題ないことを確認してます。 反映内容によっては、リリース後も適時動作を確認しています。
保守・運用
リリース後は安定して使えるように、システムの保守運用をする必要があります。ちなみに保守とは「システムの修理、メンテナンス、アップグレードなど」を指し、運用とは「監視、操作の指示」のことです。
具体的にはそれぞれ以下の作業を続けていく必要があります。
| 項目 | 詳細 |
| 運用 | 監視メンテナンスアクセス制御バックアップマニュアル化 |
| 保守 | 不具合の復旧アップデート |
社内SEに聞いてみた！
システムトラブル発生時、ユーザーへの影響を最小限に抑えるために、どのような対策をしていますか？
トラブル発生後にいかに早く対応し始められるかというのを考えて、最小限に抑えようとしています。 そのため、お客様の不具合やお問い合わせ等の連絡にすぐに気づけるような体制をとっています。 また、ローコード開発ツールについてはツール自体の不具合によってトラブルが発生することもあるので、 ツールの不具合発生の通知設定をしています。
保守運用において、特に難しいと感じる部分は何ですか？また、それをどう克服していますか？
どこまで柔軟に対応していく線引きが難しいなと感じます。 お客様に満足してもらうことを考えつつも、急な要件変更や追加要望にどこまで対応するべきか悩むことが多いです。 ですので、○○日までに連絡をいただけないと対応しかねることはお客様に伝えています。
システム開発工程のモデル
こうした工程はシステム開発において一般的なものです。ただし、開発のモデルはさまざまであり、1つの工程に長い時間をかけたり、逆にカットしたりします。
具体的なモデルには以下の7つが挙げられます。
- アジャイル
- ウォーターフォール開発
- V 字モデル
- プロトタイプ開発
- スパイラル開発
- DevOps
- MVCモデル
続いて、それぞれの特徴やメリット・デメリットをみていきましょう。
アジャイル
アジャイル開発では、開発工程を細かく区切ったうえで、一つの工程が完了するたびに、利用者などに確認を取りながら進めます。
アジャイル開発については以下の記事で詳細に解説していますので、こちらも参考にしてみてください。
メリット
アジャイル型の開発のメリットは以下です。
- ユーザーのフィードバックを早期に反映できる。
- 変化に柔軟に対応できる。
- リリースサイクルが短く、価値の提供が迅速。
- チームのコミュニケーションが向上。
他の開発手法と比べて、早くフィードバックを収集できるのが魅力です。そのため、実装の時間が長くなり、テスト工程の時間は短くなります。
デメリット
一方でアジャイル開発には以下のようなデメリットもあります。
- プロジェクトの範囲が拡大しやすい。
- 組織全体のアジャイル文化の導入が必要になる。
- 大規模プロジェクトでは管理が複雑になることがある。
アジャイル型開発ではユーザーの協力が必須になり、工数もかかります。そのため、事前にユーザーに説明し、工数を確保してもらう必要があります。
ウォーターフォール開発
ウォーターフォール開発とは、上流から下流にかけて基本通りに進めていくモデルです。大方の要件が定まっている場合は、開発途中で大きな変更点は生まれにくいといえます。そのため、ウォーターフォール型の開発を採用しやすいです。
ウォーターフォール開発については、以下の記事で詳しく説明しています。こちらも参考にしてみてください。
メリット
ウォーターフォール開発のメリットは以下です。
- 明確なステージとプロセスで進行するため、管理がしやすい。
- 計画が詳細に立てられるため、リソースを配分しやすい。
- 進行状況を管理しやすい。
ウォーターフォール開発の場合は、チーム内で打ち合わせながら実装を進めます。テストまでステークホルダーが介入しないため、開発中の変更が少ない点がメリットです。
デメリット
一方でウォーターフォール開発のデメリットは以下です。
- 初期の計画変更が難しい。
- ユーザーのフィードバックを反映しづらい。
- 後戻りが困難で、バグの修正が遅れる可能性がある。
- 開発完了までユーザーが成果を確認できない。
アジャイルと比較して、実装中にユーザーが機能を確認できません。そのため、システムの方向性が変わりやすい場合はあまり適していないモデルといえます。
V字モデル
V字モデルとは要件定義、設計の段階でテストを進める手法です。
要件定義の内容をシステムテストで確認し、基本設計の内容を結合テストで確認、詳細設計の内容を単体テストで確認していきます。
メリット
V字モデルのメリットは以下です。
- テストが各開発フェーズと連動しているため、品質保証しやすい。
- 開発プロセスが明確なため、管理がしやすい。
- 要件定義とテスト計画を早めに立てられる。
V字モデルは各フェーズでテストを丁寧に行うモデルであるため、品質を高めやすいのが大きなメリットです。
デメリット
一方でV字モデルのデメリットは以下です。
- 初期の計画変更が難しい。
- フレキシビリティが低く、変更に弱い。
- 開発の後半でバグが見つかると修正が困難である。
序盤にテストを進めるため、開発の後半でバグや漏れが見つかると、リカバリーしにくいといえます。変更が少ないシステム開発で使うのがおすすめです。
プロトタイプ開発
プロトタイプ開発とは、システム開発の初期段階で必要最小限の機能を搭載した「プロトタイプ（試作品）」を開発し、早期段階でレビューしてもらいながら作るモデルです。レビュアーは、実際に使うユーザーになります。
プロトタイプ開発については、以下の記事で詳しく紹介しています。
メリット
プロトタイプ開発のメリットは以下です。
- ユーザーのフィードバックを早期に得られる。
- 要件が明確でない場合でも、必要な機能を確実にチェックできる。
- リリース後の修正が生まれる可能性が低い
プロトタイプ開発では、リリース前に、実際のユーザーのリアクションを吸収できます。そのためリリース後の修正が生まれにくく、機能要件を固めやすいです。
デメリット
一方でプロトタイプ開発には以下のデメリットがあります。
- 開発コストが高くなる可能性がある。
- プロトタイプの品質が低いと誤解を招くことがある。
- 本番とプロトタイプとの違いが伝わらず、無駄なフィードバックを集める可能性がある。
プロトタイプ開発では、試作品をつくる必要があります。そのため、通常よりコストがかかります。また、プロトタイプで搭載する機能を定義し、レビュアーに伝える必要があります。
スパイラル開発
スパイラル開発は、機能ごとに「要件定義・設計・開発・テスト・評価・改善」を繰り返す手法です。機能ごとにプロトタイプをつくってユーザーからの評価を受けます。
一般的なプロトタイプ開発より、さらに細かく丁寧にレビューをもらいながら開発をします。
メリット
スパイラル開発のメリットは以下です。
- リスク管理がしやすい。
- フェーズごとにフィードバックを得られる。
- 柔軟に要件変更ができる。
- 大規模プロジェクトに適している。
スパイラル開発では、各機能を区切ったうえでそれぞれプロトタイプをつくります。そのため、修正が発生しがちな複雑で大規模な案件で活躍するモデルです。
デメリット
一方でスパイラル開発には、以下のデメリットがあります。
- 開発コストが高くなる。
- プロジェクト管理が複雑になる。
- 開発期間が長くなる。
スパイラル開発では、各機能のスパイラルサイクルごとに計画が必要になります。またプロトタイプも必要です。そのため開発工数がかかり、コストが膨れます。予算が大きい場合におすすめの手法です。
DevOps
DevOpsとは開発（Development）と運用（Operations）を組み合わせた言葉です。開発担当者と運用担当者が連携して開発を進めていきます。
開発と運用は、意思の疎通ができず衝突することもあります。当初から共同で開発を進めることで、運用しやすい状況になるのが魅力です。
メリット
DevOpsのメリットは主に以下のとおりです。
- 開発と運用の連携が強化される。
- リリースサイクルが短くなる。
- 自動化により効率性が高まる。
運用を見据えることで、リリース後に開発担当者と運用担当者との意志の疎通がしやすくなります。追加機能の開発などがしやすいことがメリットです。
デメリット
一方で、BizOpsには、以下のようなデメリットもあります。
- 組織文化の変革が必要になることがある
- 初期の導入コストが高い。
- セキュリティの考慮が必要になる。
通常であれば開発担当者だけで進める工程に、運用担当者が参入するため、業務フロー全体を見直す必要があります。
そのため事前に組織文化を変える必要があり、また専門的なツールを導入することもあります。
MVCモデル
MVCモデルとはプログラムを「Model」「View」「Controller」の3つに分けて管理する設計モデルを指します。それぞれの役割は以下です。
| 項目 | 主な役割 |
| Model | データベースとデータのやり取りを行う機能を実装する取得したデータを変換する |
| View | Webブラウザに表示するHTMLを動的に生成する |
| Controller | 想定ユーザーのリクエストURLに応じて処理する |
メリット
MVCモデルのメリットは主に以下のとおりです。
- 専門性が高いため、品質が高まりやすい。
- 開発の分担がしやすい。
- 変更などの対応を柔軟にできる。
Model、View、Controllerで役割分担できるため、作業が効率的に行えます。また、役割ごとに専門性が高い人材が担当できるため、品質も高めやすいです。
デメリット
一方でMVCモデルのデメリットは主に以下です。
- 情報データを管理しにくい
- コントローラーの処理コストが高まりやすい
- ViewとControllerの依存性が高い
製品規模が大きくなるとModelやControllerの負担が高まり、管理しにくくなることがあります。
システム開発工程のポイント
最後に、システム開発を成功させるためのポイントを工程ごとに紹介します。
明確な要件定義とコミュニケーション
要件定義は非常に重要な工程です。最初の計画が論理的に固まっていないと、開発途中で機能要件が変わってしまいます。
また予算や納期などのビジネス要件が大きく変わり、会社全体として損害が発生する場合もあります。まずは最初期の要件定義をロジカルに行い、丁寧にレビューしましょう。
また要件が変わった際に対応できるよう、頻繁にコミュニケーションを取ることも必要です。
プロジェクト管理と進捗確認
開発に入ったら、プロジェクトの進捗確認が重要になります。通常、スケジュールとともにWBSを作成して週次などでミーティングをしながら進捗確認を行います。
この際に、プロジェクトマネジャーと作業者で意志の疎通が図れていないと、納期に間に合わなくなる恐れがあります。プロジェクト管理は、専任のメンバーを設けたうえで行いましょう。
テストと品質保証の確認
リリース前のテストは入念に行う必要があります。リリース後にバグが起きてしまうとユーザー満足度が下がってしまうからです。
単体テスト、統合テスト、総合テスト、受け入れテストなど、チェックリストを設けたうえで丁寧に確認しましょう。
まとめ
今回はシステム開発の各工程について解説しました。品質の高い成果物を開発するうえで基本の工程を知っておくことは重要です。そのうえで状況に適したモデルを組み合わせて開発を進めましょう。
弊社・ファンリピートでは、お客様のご要望に合わせたうえで開発しております。「自社に開発リソースがない」「エンジニア人材がいない」などでお困りの方はぜひご相談ください。
