システム開発を他社へ発注する場合、必ず押さえておきたいのがシステム開発の工程に関する知識です。
要件定義、結合テスト、アジャイル、、、なんとなく聞いたことがあるけどちゃんとは理解していないという方も多いのではないでしょうか？
発注側がシステム開発の工程をちゃんと理解しておらず、開発に失敗するケースは非常に多いです。
そこで当記事では、システム開発の発注で失敗しないよう、システム開発の種類や工程、目的について解説いたします。
システム開発にも工程が存在する
システム開発を行うには、必要な作業（プロセス）を順番通りに進めていく必要があります。
車の開発を例に挙げると、必要な部品の洗い出し、部品の発注、部品の組み立て、などが必要な工程です。
システム開発の場合も同様に、開発の流れのようなものが存在します。
具体的には、システム開発の要望を具体化・ヒアリングする要件定義、システム実装する機能の設計、プログラミング、品質確保のためのテスト、などがあります。
システム開発工程を理解する重要性
システム開発における工程チェックは、本来、システム開発工程を理解した事業担当者が行います。
なぜなら、システムには実際の業務内容を反映させる必要があり、そのためにも事業担当者の協力や助言が不可欠だからです。
とはいえ、実際のところ案件の責任者がシステム開発工程を理解していないがため、システムエンジニアや外注先に工程チェックなどを任せきりにしてしまい、結果として経費の追加や工期の遅延などのトラブルを招くケースが多々あります。
大きく分けて２つの開発モデルが存在する
システム開発モデルには、「ウォーターフォールモデル」「アジャイル開発」の2種類が存在します。
この2つのどちらを選択するかにより、システム開発の工程も変わってきます。
それぞれの特徴や具体的工程について解説していきます。
ウォーターフォールモデルの特徴
高いところから水が落ちるように、上流の工程から下流の工程まで、後戻りなく工程を進めていく開発方法です。
新車の開発で例えるなら、新しいコンセプトの車を企画し、必要な機能を設計し、工場で生産し、テストを行い品質を担保し、市場に出す、という流れです。
メリット
- プロジェクト全体の計画が立てやすい
- 進捗管理がしやすい
- 品質の担保がしやすい
ウォータフォールモデルでは後戻りせず一方通行で工程が進むため、プロジェクトの計画が立てやすく、進捗状況も分かりやすいため管理もしやすいです。お金や人員などのリソースも、前もって準備がしやすいです。
また、一つひとつの工程をしっかりと完了させてから次の工程へ進むため、品質の担保がしやすいという点もあります。
デメリット
- プロジェクト計画に柔軟性がなく、要望の変更がしにくい
- 手戻りが発生した場合、大幅に遅れが生じる
一度ウォータフォールモデルで進み出したプロジェクトにおいては、基本的に前工程へ後戻りすることができないため、プロジェクトの初期段階でまとめた要望を後から大きく変更することが困難です。
またプロジェクト後半の下流工程になって手戻りが発生した場合、これまで行った途中工程も再度やり直しになってしまうため、納期にも多大な影響が出てしまいます。
向いているプロジェクト
期間的には1年以上かかり、関係者も数十人〜数百人以上になるような大規模プロジェクトでのシステム開発にウォーターフォールモデルは向いています。
向かないプロジェクト
コストや開発工数を抑えてスピーディーにシステムを開発したいような新規プロジェクトにおいては、ウォーターフォールモデルは向いていないと言えます。
ウォーターフォールモデルの工程
大きな流れとして、以下の流れでシステム開発を行います。
各工程ごとに重要な役割が存在します。
- 要件定義
- 外部設計
- 内部設計
- プログラミング
- 単体テスト
- 結合テスト
- 総合テスト
- 運用テスト
- 本番移行・リリース
- 保守・運用
V字モデルといい、要件定義の内容は運用テストで検証を行い、同様に、外部設計の内容は総合テストで、内部設計の内容は結合テストで、プログラミングの内容は単体テストでそれぞれ検証を行うという考え方もあります。
以降、厳密には間違っているかもしれませんが、イメージしやすいように車の開発も例に交えながら各工程について説明いたします。
要件定義
最初にシステム要件を定義する、一番重要な工程です。
ここが失敗するとプロジェクト全てが失敗すると言っても過言ではありません。
具体的には、開発するシステムに盛り込みたい機能や性能などについて、システム発注側と開発側とで打ち合わせを重ね、認識をすり合わせます。双方が責任を持って進めることが重要です。
プロジェクト後半では後戻りできないため、予め要望をまとめておくことが重要です。
既存のシステムがあれば、実際に利用しているユーザーや、業務システムであれば現場の声を吸い上げておくことがポイントです。
要件定義ですり合わせる要件には「機能要件」と「非機能要件」の2種類があります。
ここで取り決めた内容は要件定義書として残し、発注側と開発側の双方が責任を持ちます。
要件通りに動作するよう、開発側ではSEが責任を持って監督します。
詳しくはこちらの記事で解説しています。
機能要件
目に見えて分かるような必ず実装したい機能に関する要件のことを指します。
車で例えると、前後に進める、左右に曲がることができる、などの要件が機能要件です。
非機能要件
目に見えて分からないような機能に関する要件のことを指します。
システムの使い勝手や処理速度などです。
クリックしてから何秒以内に画面遷移するか、1秒間に最大何アクセスまで耐えられるかなどを定義します。
車で例えると、燃費や乗り心地などの要件が非機能要件です。
外部設計（基本設計）
システムを操作するための画面（ユーザーインターフェース）を設計する工程です。
基本設計とも呼ばれます。
車で例えると、デザイン・内装を設計します。
ユーザーが直接見て触る部分ですので、ユーザーの立場になって必要な機能を決めることが大切です。
また、この工程でデータベース設計やプログラミング言語の選定、セキュリティなど機能設計を行います。
ここで取り決めた内容は外部設計書（基本設計書）として残します。
内部設計（詳細設計）
外部設計はユーザー側の視点で設計を行いますが、内部設計は開発者の視点でシステム内部を設計します。
車で例えると、エンジンなどのパーツの設計が内部設計です。
システム開発の場合、機能をどのように実装するかプログラム設計を行います。
詳細設計とも呼ばれます。
ここで取り決めた内容は内部設計書（詳細設計書）として残します。
一般的にここまでの工程が上流工程と呼ばれます。
プログラミング
内部設計で作成した仕様書をもとに、実際にプログラミングをして、システム構築する工程です。
プログラミングのことをコーディングと呼んだりもします。
この工程の担当者は一般的にプログラマー（PG）と呼ばれます。
開発環境を構築し、開発ツールなどを用いて効率的に制作します。
車で例えると、工場でパーツを製造する工程です。
単体テスト
実際に開発したプログラム一つひとつが正しく動作するか、バグがないかを確認するテスト工程です。
車で例えると、ハンドルは回るか、タイヤは傾くか、などを確認します。
開発したパーツ同士をいきなりつなげず、まずは小さい単位でテストを行います。
モジュールテストとも呼ばれます。
結合テスト
単体テストで動作確認を行なったプログラム同士をつなげてテストを行う工程です。
結合テストで確認するつながりには、「内部結合」と「外部結合」の2種類あります。
内部結合
プログラムをつなげたサブシステム内の連携のことを指します。
サブシステムとは、全体のシステムの一部に含まれるがそれ自体が独立した機能を持つシステムのことです。
車で例えると、ハンドルを回したらタイヤも傾くか、などを確認します。
外部結合
内部結合はサブシステム内の連携のことでしたが、外部結合はサブシステム間や他システムとの連携のことを指します。
車で例えると、直進する機能と左右に曲がる機能はうまく連動するか、カーナビやETCとうまく連動するか、などを確認します。
総合テスト（システムテスト）
構築したシステム全体をつなげ、ユーザーが要求するテストを行う工程です。
車で例えると、実際に全て組み立て、想定していた全ての機能が正しく動作するか（前後に進むか、左右に曲がることができるか、など）を確認します。
システムテストとも呼ばれます。
運用テスト
実際にユーザーが利用する環境下でソフトウェアのテストを行う工程です。
車で例えるなら、レース場や公道での試運転を行います。
本番移行・リリース
上記のテスト全てを終えたら、システム導入・システム移行する工程です。
システム受託開発会社目線では、お客様に成果物を納品するタイミングでもあります。
無事に移行・リリースが完了したら、ここからがシステム運用の開始です。
車で例えると、生産ラインの稼働開始・販売開始のタイミングです。
保守運用
本番稼働したシステムをメンテナンスしたり、安定的に稼働するために運用したり、運用保守する工程です。
車で例えるなら、マイナーチェンジやリコール対応などが当てはまります。
アジャイル開発の特徴
素早くシステムを開発するための手法で、一度に全てシステム構築するのではなく、まずは機能を分割し、一つの機能に絞って開発していくような形をとります。
新車の開発であれば、例えるなら今までにない車の開発（空を飛ぶ車など）を開発する際に、まずは空を飛ぶという機能について要件を固め設計し、製造してテストを行い、さらに必要な機能や削ぎ落とす機能を見定めてもう一度要件定義を行う、といった方法です。
スタートアップのIT企業など新規開発で、顧客の反応やデータを見ながらサービスや製品を開発する「リーンスタートアップ」で、よくアジャイルモデルが採用されます。
「リーンスタートアップ」については以下の記事で詳しく解説しています。
メリット
- システム開発期間を短縮できる
- 仕様変更や不具合に柔軟に対応できる
重要な機能から先に開発を行うため、システムとしてすぐに形に現れます。
また、ウォーターフォール開発と違い仕様変更や不具合が後から出てくる前提で進めるため、不測の事態にも柔軟に対応できます。
デメリット
- プロジェクト管理がしづらい
ここの機能を切り分けて小さく開発を進めるため、プロジェクトの全体像が見えにくいのがアジャイル開発の欠点です。
柔軟に対応できることはメリットですが、全体像が見えない中開発していると、結果としてスケジュールが伸びたり開発費用が膨れ上がったりするのが注意点です。
向いているプロジェクト
小さくスピーディーにシステムを開発でき仕様変更などに柔軟に対応できるため、新規事業立ち上げ後の継続改善に向いている開発手法と言えるでしょう。
向かないプロジェクト
プロジェクト管理が行き届きにくい開発手法のため、関係者が大勢いる、開発期間が数年単位、といった大規模なプロジェクトには向きません。
また、弊社では新規事業のリリースまではウォーターフォールモデルで開発する場合が多いです。
なぜなら、初期リリースまでにはサービスを成り立たせるためのある程度の機能を開発する必要があり、機能ごとに分割して開発するよりも、リリースまでに必要な機能をまとめて開発した方が効率が良いからです。
例えば、会員のマッチングサービスをリリースするために、会員登録・ログイン機能とマッチング機能が必要だとします。
会員登録・ログイン機能だけではサービスは成り立たないので、マッチング機能の開発まで必要です。
このような場合、会員登録・ログイン機能とマッチング機能は同時に開発した方が効率が良いのです。
サービスリリース後の機能改善・追加などは弊社でもアジャイルで開発しています。
アジャイル開発の工程
まず大まかな要求や仕様を決めます。
そしてシステムを機能で分割し、開発順を決め、それらの機能をひとつずつ開発します。
機能実装は、「計画」→「設計」→「開発」→「テスト」という開発単位（イテレーション）で行います。イテレーションは一般的に1週間～4週間であり、イテレーションごとに毎回機能をリリースします。
全機能を実装するまでイテレーションを繰り返し、改善を重ねながらシステム全体を構築していきます。
計画
一つの機能について要件定義を行い、そのイテレーションにおける機能実装のための計画を立てます。改善要望や不具合なども精査して、開発計画に盛り込みます。
設計
機能実装のための設計を行います。アジャイル開発でも最低限のドキュメントは作成しますが、ウォーターフォールモデルで作成するような膨大なドキュメントは作成しないのが一般的です。
開発
プログラミングを行います。開発チーム内で密にコミュニケーションを取り、短期集中で機能を実装します。
テスト
実装した機能のテストを行います。ここで仮に不具合が見つかったとしても、大きな手戻りなく修正が可能です。
まとめ
今回は、システム開発の工程・種類ついて解説しました。
まずは自社が開発したいシステムはウォーターフォールかアジャイルかどちらが向いているのかよく判断しましょう。
ウォーターフォールモデルで開発する場合は、開発前の要件定義が重要になってくるため、実際に利用しているユーザーや現場の声を吸い上げるなど、依頼する前に要望をまとめておくことが大切です。
すべての工程を理解し、内容をチェックしながら開発を進めるには、専門知識が必要なため、事業担当者だけでは難しいこともあります。
スムーズにシステム開発を行うためには、システムの検討段階からシステム開発会社に相談することをおすすめします。
見積もり依頼時に注意する点をこちらで紹介していますので、見積もり依頼時に参考にしてみてください。
