「システム開発を依頼したいが、流れが分からず予定を立てられない」

「ベンダーの言葉が意味不明。意思疎通に問題があるので予習しておきたい」

システム開発をスムーズに発注、納品してもらうには依頼者側の理解も必要です。

事前にシステム開発の流れや工程を理解し、用語を学ぶことで打ち合わせもうまくいくでしょう。

今回はシステム開発の2つの基本工程とシステム開発の流れ、そして頻出する用語集をご紹介します。

記事を最後まで読めばスムーズにシステム開発の発注が行えるでしょう。

１．システム開発の２つの基本工程

システム開発の2つの基本工程を説明します。

1. ウォーターフォールモデル
2. アジャイル開発

開発で主に用いられるのはこの2つのモデルです。

1つずつ具体的に説明します。

（１）ウォーターフォールモデル

システム開発の1つ目の基本工程はウォーターフォールモデルです。

ウォーターフォールモデルとは、システム開発における工程を最初から最後まで順番に行うモデル。つまりAの工程が終わったらBへ、Bが終わったらCへと進んでいきます。

ウォーターフォールモデルの名前の通り、Aから順次に工程が進み、逆に進むことができないため融通は効きづらいでしょう。

世界的にも最も一般的なシステム開発のモデルがウォーターフォールモデルです。

（２）アジャイル開発

システム開発の2つ目の基本工程はアジャイル開発です。

アジャイルとは素早いという意味で、システム要件の定義・開発・テスト・リリースを細分化された工程に分けて、クライアントと打ち合わせをしながらシステム開発していきます。

一気にシステムを作り上げるのではなく、随所で確認が入るため修正が効きやすいのがメリットです。

ただし短期間で開発とテストまでを繰り返すため、時間がかかりやすくクライアントの方針転換によってシステムの方向性にブレが生じる可能性があります。

2,000年ごろから活用されている新しいシステム開発工程で、ウォーターフォールモデルと同程度にメジャーになってきました。

２．２つのモデルのシステム開発の流れ

2つのモデルのシステム開発の流れを詳しく解説します。

1. ウォーターフォールモデルのシステム開発の流れ
2. アジャイルモデルのシステム開発の流れ

システムリリースの予定を立てる上でも、事前に流れやどの程度の期間がかかるか把握する必要があります。

打ち合わせの回数等を検討するにあたり、事前に流れを知っておきましょう。

（１）ウォーターフォールモデルのシステム開発の流れ

ウォーターフォールモデルのシステム開発の流れは以下のようになります。

1. 要件定義の話し合い
2. UI（ユーザーインターフェイス）の設計
3. プログラミングの設計
4. 設計に基づいたプログラミング
5. プログラムの単体テスト
6. 連携テスト
7. システムの総合テスト
8. 実務環境下でのテスト
9. システムのリリース
10. 本番環境での運用

1つずつ解説します。

＃１：要件定義の話し合い

まずは要件定義について話し合いをします。要件定義とはユーザーの目的やシステムの必要性から、実装すべき機能を明確にすることです。

ウォーターフォールモデルは後戻りができないシステム開発のやり方なので、要件定義の時点で詳細を決めておかなければシステム設計が失敗します。

打ち合わせを重ねて要件を決めていきましょう。

＃２：UI（ユーザーインターフェイス）の設計

UI（ユーザーインターフェイス）の設計とは、システムの操作画面など視覚的に触れる部分を決める工程です。

具体的にシステムのテーマカラーやフォントサイズ、ボタンの設計などの細かい部分を決めていきます。

ユーザーが毎日目にするものなので、従業員目線でクライアントの意向を取り入れたデザインの希望を伝えましょう。

デザインが悪ければ操作感が悪くなるので、実際に使用を想定してどのような見た目にするかを決めていきます。

＃３：プログラミングの設計

次にプログラミングの設計を行なっていきます。先程のUI設計まではクライアントの目線で話し合いがなされますが、ここからはシステムのベンダーや開発会社の領域になります。

開発者目線で、クライアントが希望するシステムを作るにはどのようなプログラミングが必要か、概要を決定する工程です。

＃４：設計に基づいたプログラミング

設計が完了したら、エンジニアが実際にプログラミングを行なっていきます。システムが稼働するように必要な機能を実装させる工程です。

開発会社にて定めたスケジュールに基づき、プログラミングをチーム単位で行い、Wチェック等を行っていきます。

＃５：プログラムの単体テスト

プログラミングが完了したら、それぞれの分野ごとにシステムを動かしてテストを行います。それぞれの機能が設計通りに稼働しているか確認し、機能に問題ないかチェックする工程です。

＃６：連携テスト

次に各機能が連携できるかどうかのテストを行います。プログラム単体ではうまく機能しても、AとBのシステムが連携しないというケースがあるからです。いくつかのプログラムを複合してテストします。

＃７：システムの総合テスト

最終的に全てのシステムがうまく稼働するかどうかの総合的なテストを行います。このテスト段階で問題が見つかれば修正し、再度テストを繰り返していきます。

＃８：実務環境下でのテスト

最終テストで問題なければ、次はクライアントの実務環境においてテストを行います。実際のサーバーやPCを用いてのテストで、いくつかの部署に協力を仰いでWエントリーなどを用いて既存システムと遜色なく動くかをチェックする工程です。

＃９：システムのリリース

実務環境下のテストが問題なく行われたら、本番環境での運用のためのデータ移行を行います。既存システムで使用していたデータを全て移動させ、従業員がシステムを運用できる準備をする工程です。クライアント側もデートの移し漏れがないかなどチェックする必要があります。

＃１０：本番環境での運用

リリースが終わったら本番環境での運用開始です。クライアント側は運用に問題が起きないかを監視し、トラブルが起きた時は開発者へ報告、開発者側は保守作業に入ります。

依頼する開発会社にもよりますが、システム稼働後しばらくは常駐、または遠隔でサポートをすることが多いです。

（２）アジャイルモデルのシステム開発の流れ

アジャイルモデルのシステム開発の流れを説明します。

1. ヒアリング・システムの概要の決定
2. システム計画を分割・手順の決定
3. イテレーション

細かいスパンで開発とリリースを繰り返すため、それぞれの工程自体は短いです。1つずつ説明していきます。

＃１：ヒアリング・システムの概要の決定

まずはクライアントと開発者が打ち合わせを行い、システム全体の概要を決定します。

要望などは後で細かく修正可能ですが、できるだけこの時点でシステム要件を伝えておきましょう。

途中で要望や修正を入れると、システムの方向性がブレたり、納期が遅れるリスクがあります。

＃２：システム計画を分割・手順の決定

次に概要からシステム計画を分割し、どの機能から作業していくか、エンジニアの割り振りなどを決めます。

概要を決めた後に細部のプログラムの概要を決めていく作業です。この段階は開発会社がヒアリングの情報を元にして行います。

＃３：イテレーション

イテレーションとは短期間で設計＞開発＞テスト＞改善を繰り返すことです。

分割されたシステム計画をもとにして、細かい部分からプログラミングとテストをしていきます。

要所要所にクライアントとの打ち合わせと修正を挟み、システム全体が完成するまでテストを繰り返していきます。

３．クライアントもシステム開発の流れを知っておくべき３つの理由

クライアントもシステム開発の流れを知っておくべき3つの理由を解説します。

1. 修正や要望を伝えるタイミングが分かる
2. 実際にシステムを利用する現場への説明ができる
3. ベンダー・開発会社選びが楽になる

1つずつ説明します。

（１）修正や要望を伝えるタイミングが分かる

開発の流れを把握しておけば、大体のスケジュールを把握できるため、修正や要望を伝えるタイミングがわかりやすいです。

モデルによってはすでに完成した工程の修正はできないため、流れを把握しておかないと追加料金や大幅な修正が発生し、リリースが遅滞します。

開発者へ打ち合わせの申し入れをするタイミング等をはかるのに、開発の流れを知っておくべきです。

（２）実際にシステムを利用する現場への説明ができる

実際にシステムを動かす従業員に、開発の流れやテストの予定のスケジューリングの説明や指示が出しやすくなります。

通常業務と並行してのテストは現場に負担をかけるので、繁忙期を外したり、人員を配分してスムーズにリリースやテストを行いましょう。

（３）ベンダー・開発会社選びが楽になる

事前に開発の流れやメリットを把握しておくことで、ベンダーや開発会社を選ぶのが楽になります。

無知の状態ではベンダーや開発会社の良し悪しを見分けられず、予算や相手のプレゼン頼りになるでしょう。

しかし開発の流れを把握していれば、相手方に質問や提案をしやすくなり、自社が求める開発会社を選べます。

４．システム開発会議で頻出する用語集

システム開発会議で頻出する用語集を紹介します。

1. BD
2. FD
3. DD
4. M
5. UT
6. IT
7. ST
8. UAT

用語理解が足りないと開設に時間を取られてしまい、本題を議論する時間が不足します。また理解できないまま話が進み、結局クライアント側の意向をうまく伝えられない可能性があるからです。

1つずつ説明します。

（１）BD

BDとはBasic Designの略称で、基本設計を意味します。要件定義で、クライアントからのヒアリングを行い、どんなシステムを作るかを設計する工程のことです。

（２）FD

FDとはFunction Designの略称で、機能設計のことを言います。

機能設計とは、クライアントの要望を叶えるためにどんな機能が必要かを考える工程で、要件定義の一部です。

（３）DD

DDとはDetail Designの略称で、要件定義で決めたシステムの概要からさらに細かく設計を行うことです。

概要の設計を参照しながら、どのようなシステムで必要な機能を稼働させていくかを決めます。

（４）M

MとはManifacutureの略称で、製造過程のことを言います。要はエンジニアが設計に基づいて、プログラミングを行うことです。

工程表に略語で記載されることがあるので、頭に入れておくと良いでしょう。

（５）UT

UTとはUnit Testのことで単体テストのことです。完成したプログラムを機能ごとに稼働させて、適正な動きをするかを試します。

（６）IT

ITとはIntegration Testのことで、結合テストを意味します。

結合テストとは複数の連携するシステムを動かして、適正に連携ができるか、不具合が出ないかテストすることです。

複合システムに失敗した場合はコードの修正等を行い、スムーズな稼働ができるまで修正とテストを繰り返します。

（７）ST

STとはSystem Testのことで、システムやプログラミングが改正した後に包括的に行う全体テストのことです。

最終的に全ての機能が問題なく動き、連携等に障害が起きないかテストをします。

（８）UAT

UATとはUser Acceptance Testのことで、ユーザー受け入れテスト、つまり現場での実践テストのことです。

実際にシステムを動かしていく従業員が実務と同じようにシステムを動かし、障害情報やデータの正しい抽出をチェックします。

このテストに置いて見つかった問題は開発者側に報告され、修正されて再度機能テストが行われる流れです。

最後に

今回はシステム開発を外注する場合の流れについて説明しました。システム開発には主に2つの主流な手法があり、ウォーターフォールモデル・アジャイル開発のどちらかを使用しているシステム開発会社が多いです。

それぞれメリットとデメリットがあるため、事前に開発会社を選定する際に開発のモデルや予定を聞き、なるべく予定の納期に余裕を持って納品してくれる会社を選びましょう。

事前に工程の流れを把握しておけば、自社従業員にシステムリリース予定の準備をさせたり、人員の割り振りもスムーズになります。

クライアントと開発者の意思疎通をスムーズにして、希望のシステムを作れるように工程を把握しておきましょう。