システム開発プロセスを徹底解説
こんにちは！
ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤（やなぎさわ）です。
弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。
こちらの弊社運営サイト、「スタートアップ開発ラボ STaP（スタップ）」では、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。
さて今回は、システム開発のプロセスについて触れていきます。
システム開発プロジェクトの各プロセスついて、まずは見ていきましょう。
各開発プロセスについて
日本では初級ITエンジニアへのシステム開発理解のために、よくドイツで編み出された「V字モデル」の説明を行われることが多いので、今回もそれに準じます。
なにかを実現したいとき、いきなり企画実現のために行動することは普通ないでしょう。
最初は大枠を固めて、だんだん詳細を詰めていくという流れで企画は進んでいくはずで、これはシステム開発でも同じです。
V字モデルの左側部分は、上から下へと、大枠を決めるものから詳細を決めるものへと順に仕様策定方法・プロセスを並べています。
次にV字モデルの右側ですが、こちらは右側の仕様策定プロセスに対応する、レベル感にあわせたテストプロセスを明らかにしています。
右側が上から下へとより詳細なシステムの中身決めをしていたのと連動し、下から上へと、より広い視野でシステムが目的通りの動作をするのか確認をする必要があるわけですが、それを明確化したものです。
つまり、すでにお気づきの方もいらっしゃるかと思いますが、V字モデルを左上から右上へとなぞればシステム開発プロセスを完了することができるのです。
V字モデルについて概要が分かってきたところで、V字モデルで表現されている仕様策定プロセスと、それに対になるテストプロセスを確認していきます。
まずは、全体像から見ていきます。V字モデルでは、システム開発を大きく分けて５つのステップに分かれています。
システム開発の5ステップ
①要求分析―受入テスト
②基本設計―システムテスト
③機能設計―結合テスト
④詳細設計―単体テスト
⑤コーディング
では、それぞれについて①から見ていきます。
①-1 要求分析
左側にある要求分析とは、どんなシステムを作って欲しいのか明らかにするステップを言います。
もう少し分かりやすい言い方をすれば「システムを企画するステップ」です。
システム発注した時点で、現在どういったビジネス上の課題を持っていて、開発されるシステムになにを求めているのかは明らかにされているはずなので、この段階で「システムを使った業務のあるべき姿」を整理するのです。
一般的に整理の方法として、統一モデリング言語(UML)が使われることが多いです。
主なUMLとしては、業務フローを明らかにするアクティビティ図や業務機能関連図、業務の構成概要を明らかにするERDやクラス図などが良く使われます。
この過程は、それらの資料を確認し、新しいシステムの概要について発注側・開発側双方の合意が取れたら終了です。
①-2 受入テスト
次に右側の「受入テスト」とは、納品テスト・検品です。
これは完成したシステムが本当に求めるシステムになっているのかを、システム発注者側の視点で確認していく作業です。
漠然と問題なさそう、というレベルではなく、観点を明らかにし、それぞれを項目ごとに確認していく必要があります。
主な観点としては、「発注側と開発側で約束された通りのシステムになっているか」を基本に、「法律や社内規則などの規定への抵触の有無」、「マニュアルを含めたシステムに関するドキュメントの品質」にも注意を向けなくてはいけません。
限定したユーザーに使ってもらって、問題ないか確認してもらうベータテストを行うことも視野に入れましょう。
このテストをクリアできればシステムは完成した、と言えます。
次に来るのが、②の基本設計―システムテストです。
②-1 基本設計
基本設計とは、システムに求められている機能を整理することです。
もっと言えば、なにを作るのか、なにを作らないのかを明らかにするものです。
いわゆる要件定義がこれに当たります。
ここでいう要件とは、「このようなことができます」といった表面的な機能だけでなく、保守性や拡張性、システムの応答時間といった機能とは異なるタイプの要求も含まれます。
ここでシステム企画の内容を開発側がミスリードして要件定義を作成すると、思っていたものと異なるシステムが作られてしまうので、疑問点が残らないように発注側と開発側の間で会話することが非常に重要です。
このステップのゴールは、システム発注側と開発側でしっかりと認識を合わせた上で、要件定義について合意することです。
②-2 システムテスト
対となるシステムテストは総合テストという言い方をするIT企業もあります。
中身としては開発側の納品前の確認テストです。
受入テストと同等の観点で、セルフチェックするものだと考えてください。問題ければ、次のステップに進みます。
③-1 機能設計
要件定義の後にくる、機能設計―結合テストですが、ITエンジニアの視点でどうやって要件定義で求められた各種要件を達成するか考えるフェーズです。
アプリケーション側ではシステムを一度ブレークダウンし、会員情報データベース関連機能やショッピングカード管理機能と言った風に個々の機能単位に分解して、それぞれをどう実現するか検討していきます。
また、定められた応答時間などの非機能要件を達成するためには、システムが動く環境作りも重要です。
サーバなどのハードウェアやOS、それに関係データベース管理システムなどのミドルウェアなど様々な要素から最適な組み合わせを考えなくてはいけません。
なお、前者のアプリケーション側の対応を機能設計と呼ぶのに対し、後者の基盤側の対応を方式設計と呼びます。
③-2 結合テスト
対となる結合テストは、個々の機能レベルできちんと動くのか確認するものです。
当然のことですが、テスト条件は網羅的にリストアップして、漏れなく実施されなくてはいけません。
ここである機能にバグがあることに気が付かないでシステムテストへと進めてしまうと、バグの原因の切り分け作業に大変な労力がかかってしまいます。
結合テストでは主に、ブラックボックステストが使われます。
これはシステムの中身は分からない(＝ブラックボックス)けれど、αというデータを与えればβという結果が出てこないとおかしい、という理屈でテスト項目を作り上げていく考え方です。
なお、αの数の決め方について、更に境界値分析と同値分割法という二種類の考え方がありますが、複雑なのでここでは一旦、割愛します。
④-1 詳細設計
④の詳細設計―単体テストの詳細設計とは、機能設計で設定した機能を更にブレークダウンして、個々のパーツ、つまりプログラム単位で設計する作業です。
そのため、プログラム設計と呼ばれることもあります。
特定の値を入力されたらプログラムAはどのような計算を行ってから計算結果をプログラムBに引き渡すのかを定義したもの、と言えば分かりやすいでしょうか。
④-2 単体テスト
対となる単体テストは個々のプログラムの動きを確認するものです。
ここでも、テスト条件は網羅的にリストアップして、漏れなく実施されなくてはいけません。
ある機能にバグがあることに気が付かないで単体テストへと進めてしまうと、バグの原因の切り分け作業に大変な労力がかかってしまうでしょう。
なお、システムテストではブラックボックステストが主に使われていたのに対し、単体テストではホワイトボックステストを通常使います。
これはプログラムの内部構造を確認(＝ホワイトボックス)した上で、分岐条件があれば、すべての分岐条件で真/偽の両方に分岐するような入力値を用意するなどして、プログラム内にある全ロジックが意図通りに機能しているのかを確認することができます。
完全な網羅性が必要なため、少々テスト項目策定が難しいという難点があることは頭に入れておきましょう。
⑤コーディング
⑤のコーディングは、名前の通り、システムをITエンジニアたちが実際に作成していくフェーズです。
V字の一番底の部分にあたります。なお、V字モデル上ではコーディングについて検討されたりテストされたりがないように見えますが、実際は異なるように思います。
というのも、同じ結果を出せるけれど、このライブラリを使った方が拡張性あるだとか、読みやすいコーディングにするための記述ルールが会社ことにあったりだとか、コーディングの質を良くするための検討をITエンジニア同士で行っていることが多いです。
こういったドキュメントに問題があると、各機能のシステム的性質が分からなくなり、システムトラブルの原因究明に難航したり、システムの改修時に不適切なプログラム変更などでバグが埋め込まれる事態になってしまいます。
なお、V字モデルについては、あくまでシステムの各開発プロセスを明示したものであり、実際のシステムのライフサイクルという意味では開発完了後、運用・保守、つまり、システムを使い、必要に応じてメンテナンスや改修をしていく必要があります。
その際、システムの性質が分からなくなると困ってしまいますので、①～④各工程の設計資料及びテスト項目とその結果はシステムと一緒に発注側に納品されるのが通常です(厳密に言えば受入テストは、発注側で作成対応するので、納品物ではありませんが)。
逆に言えば、後から開発に関わらなかった人が見たときに、正しく伝わらないドキュメントが納品された場合、「マニュアルを含めたシステムに関するドキュメントの品質」が悪いとして、受入テストで突き返す必要があると言えます。
システム開発のプロセスを見て来たところで、合わせてシステム開発のプロセのモデルも確認してみましょう。
開発プロセスモデルの種類と特徴
ウォーターフォール・モデル
ウォーターフォールとは、水が落ちるという意味ですが、水は上から下にしか流れないようにシステム開発も上流工程から順番にやっていきますよ、という開発スタイルです。
先ほどご紹介したV字モデルの通り、プログラムの全機能を一斉に設計からテストまで順番に進めていきます。
ウォーターフォール・モデルのメリット
・ステップとステップの切れ目が明確
このウォーターフォール・モデルのメリットはステップとステップの切れ目が明確なことです。
つまり、
「来週から次のステップに進みたいので、明後日に一旦このステップで作ったドキュメントを発注側に見せて、今週末にはOK貰いたい」、
という風に具体的な進捗計画が思い浮かべやすいということです。
・ステップごとに何が必要か明確
また、ドキュメントについてもステップごとになにが必要なのか明確なのもウォーターフォールの良いところです。
ウォーターフォール・モデルのデメリット
デメリットは、システム開発は水と異なり下から上に戻る可能性があることを考慮していない点です。
往々にして、受入テストで「思ってたのと少し違う、この機能の動きを変更して欲しい！」と発注側に指摘されても、ウォーターフォール・モデルではテストのステップから開発のステップへと戻る、というアイデアすらないのです。
プロトタイプ・モデル/スパイラル・モデル
プロトタイプ・モデル、スパイラル・モデルは本来、別々のものですが、基本思想は同じなのでまとめてご説明します。
これらの開発の基本思想は、ウォーターフォール・モデルの欠点は全機能横並びに進める、最後にシステム発注者に確認してもらうことにある、と定義しています。
その上で、プロトタイプ・モデルの場合はプロトタイプ、つまり原型となるものを作成し、その原型を見て方向性に誤りがないかを発注側に確認してもらってから実際のシステムを実装していきます。
スパイラル・モデルやアジャイル開発の場合は、V字モデルで見ていただいた通り、機能設計はシステムを機能単位で分解して作業を行いますが、特定の機能だけを先行して詳細設計、コーディングと進めていって、その特定の機能が完成した時点で発注側に確認を受けます。
それで問題なければ、次の機能を詳細設計、コーディング、発注側確認、まだ問題なければ、その次の機能を、、、というように機能の数だけ繰り返す(＝スパイラルする)開発手法です。
プロトタイプ・モデル/スパイラル・モデルのメリット
プロトタイプ・モデル、ウォーターフォール・モデルともに、要求変更への対応力が高く、手戻りを減らすことに優れています。
また、プロトタイプ・モデルはプロトタイプを見ることで曖昧だった要求が明確化する、というメリットもあります。
プロトタイプ・モデル/スパイラル・モデルのデメリット
デメリットはどちらも、見せる度に「いや、やっぱり違う」といわれ際限がなくなる、ということも少なくないと言うことです。
また、プロトタイプ・モデルの場合は、プロトタイプといえそれなりのものを作成せねば評価になりませんので、開発側の負担が大きく、大規模開発には不向きと言われることが多いです。
まとめ
今回は、システム開発の各プロセスと開発プロセスモデルをご紹介しました。
いかにすれば効率よく開発を進められるか、開発プロセスモデルの模索は今なお進められています。
しかし、その多くはウォーターフォール・モデルのように各プロセスを行う順番を組み替えてみたり、詳細設計の粒度を変更したりと、大きくV字モデルから外れた開発アプローチではありません。
おそらく、今後もV字モデルを根本から否定するような開発アプローチは登場しないと思います。
システム発注者もV字モデルについて理解しておくと、開発者側とスムーズに会話することが可能になるため、ぜひ押さえておいてください。
