【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選エンタープライズシステム(大企業の業務管理のためのシステム)の構築に関わっていく場合、Vモデルというワークフローに従って仕事をしていくことになります。
この記事では、Vモデルを中心にウォーターフォールモデル、アジャイル開発モデルも含めてプロジェクト管理モデルについて徹底解説していきます。
まずはVモデルについてですが、Vモデルは実はその前身がありまして、これをウォーターフォールモデルといいます。
ウォーターフォールモデルとは、要するに
「大まかな要件から徐々に細かい仕様を決めていきましょう、そして細かいテストから全体を動かすテストをしていきましょう」という考え方のことです。
Vモデルには、次に述べるプロセスが順に並びます。
「要件定義」から「詳細設計」までは、システムの仕様を設計する段階です。
そして「製造」というのがまさにプログラミング。
そして「単体テスト」から「UAT」までは、作られたシステムが設計通りに動作するかどうかの検査、テストです。
Vモデルはあまりにもシステム業界で自明視された概念であるために、その欠点が見落とされがちです。
が、その分かりやすさから幅広くIT業界で使われているものです。
また、最近は、開発者とクライアントがチームを組んで、「要件定義」→「開発」→「テスト」の3プロセスを高速に回していくことにより素早いシステムの構築を急ごうとする方法論も提唱されています。
それでは、以上のことについて、詳述したいと思います。
ウォーターフォールモデルとは何か
そもそもコンピュータシステムを作り出したのは1950年代のことです。
どのような技術もそうですが、技術の草創期には一線の技術者の暗中模索によってなんとか成果物を作り上げるものです。
しかし、1968年、ヨーロッパにおいて「ソフトウェア開発の製品開発工程をマニュアル化しよう」という意見が持ち上がりました。
こうして生まれたのが「ウォーターフォールモデル」です。
「ウォーターフォール」とは読んで字のごとく、「滝」という意味です。
滝の水は高い所から低い所にしか流れません。
これは、ウォーターフォールモデルが原則、後工程から前工程に逆戻りすることのないという考えに基づいていることを意味しています。
ウォーターフォールモデルは、概ね、以下のプロセスから成り立っています。
- 要件定義
- 設計
- 製造(プログラミング)
- テスト
プロセスの性質上、テストで不合格になれば製造過程に逆戻りしますが、それは後工程から前工程に戻らない、という話とは別論です。
しかし、何を決めるにしてもそうですが、大体具体論を考慮しなければ全体的な決定は正しくできないものですから、具体的な業務プロセスや技術制約を考慮する設計段階に要件定義で決定した大方針自体に修正が必要である、ということが分かることは往々あるのです。
このようなことは、少しでも仕事をしたことがある人ならば難なく理解できることですので、それにもかかわらずウォーターフォールモデルがこのように流布しているのは…、おそらく「要件定義に携わっておられる偉い方々の決定には下々は須らく従え。」という官僚組織的な論理と親和性が高いからではないかという密かな仮説を個人的には持っています。
これを裏付けるように、ウォーターフォールモデルにはもう一つ大きな問題があります。
ウォーターフォールモデルの大きな問題
私の知る限り、日本のシステム開発の実務では、要件定義フェーズについてまず契約を交わし、その要件定義の結果に基づいて人員と予算、機器購入の必要性の見積もりを立ててシステム構築の見積を出します。
発注者側は、この当初見積もりに基づいて契約を結びます。
多くの場合この種の契約は請負契約といいまして、「これこれの要件を満たしたシステムを修めた対価として、いくらいくら払います。」という契約になっています。
これが何を意味するかというと、見積もりに狂いが生じますと（大体において見積は過少に見積もられているので、予算や人員は不足することが明らかになるのです…）、足が出た分は受注者(システム製造企業)側において負担しなければいけないことになります。
としますと、システム企業側の管理者は目の色を変えて社員にサービス残業をさせます。
そうでもしなければそのプロジェクトが赤字になるからです。
以上述べたように、ウォーターフォールモデルというのは、受注者よりは発注者に、労働者よりは管理者に、具合がよくできているのです。
なお、実際には全く原案に修正の余地が効かないと本当にシステムができなくなってしまいますので、「コンティンジェンシー」という予備費をプロジェクトで確保してあることが多いです。
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選ウォーターフォールモデルで重要な「コンティンジェンシー」
「コンティンジェンシー」といいますのは、何かプロジェクトの進行を阻害し得る事態(これをリスクとシステム業界では言います。
金融業界の用語法とは違います。)が起きた時の対応策、という意味でして、日本では「リスクが現実化した時に対応するための予備費」という意味合いを持つようになりました。
これは、ウォーターフォールモデルの系統の考え方ではありませんで、アメリカの宇宙開発プロジェクトの経験をもとに作られたPMBOK理論というものが源流です。
実務では、色々原案で想定していなかった事態に対応するための人の採用や残業代の支払のために、コンティンジェンシーをちびりちびり切り崩して事態に対応します。
しかし、物事の筋から行けば、例えば要件に大きな対応を加える必要があるとか、要件定義時に予期していなかった業務的・技術的制約によって要件を修正すべきであるならば、これを公にして、案を修正してシステムを作り直すための工数や予算を算出し、改めて見積を出すべき筋合いのものです。
といいますのも、システム構築の仕事は非常に膨大な情報量を集約しなければきちんとした意思決定ができないものですので、プロジェクトにとって重要なヒト・モノ・カネ・時間といったリソースの問題を、不透明に処理することは、さらなる問題の混迷を招くからなのです。(まぁ、現実には社内政治の壁は厚いのですがね…)
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選Vモデルとは何か
Vモデルとは、ウォーターフォールモデルに対して、どの段階のテストでどの段階の設計仕様が満たされているかを確認するか、の対応関係を示す要素を付け加えたモデルです。
以下の図に沿って、Vモデルの考え方を説明いたしましょう。
Vモデルの考え方もウォーターフォールモデルと同様、基本的には後工程から前工程への後戻りを許さない考え方です。
このような考え方に立つと、こういう発想になります。
「製造(プログラミング)工程でのミスは、純粋なプログラミング技術上のミスに限られるはずであり、またそうでなければおかしい。なぜならば、技術的な仕様は全て詳細設計によって定められているはずだからである。」
(ところが実際問題としては、日本では、プログラマが業務仕様をヒアリングしたうえで、基本設計と詳細設計をすっ飛ばしてコーディングをしていることも多々あります。
特に中小規模のプロジェクトや、歴戦の名うてのプログラマはこのようなことをやってのけたりします。
話が脱線して恐縮ですが、理論と実際は異なることがほとんどです。
皆さんにとって重要なのは、理論が勝手に変形するに任せるのでなく、理論の基礎的な思想を理解したうえで、その理論が生まれた環境と自分のベースの環境とを比較し、元の理論の具体的な部分の削るべきところを削り、加えるべきところを自ら加えてオリジナルな応用理論を作ることです。)
要件定義～詳細設計
さて、話が脱線しました。
システム構築のプロセスは、上図の左上から始まります。
要件定義
「要件定義」とは、その業務システムをつかう社員の視点から、その社員が業務システムを使って何をどのようにできるようにしたいかを定めることを言います。
この段階では、システム関係者でなくてもわかる言葉でどのようなシステムを作りたいか、記述されます。
基本設計
次に「基本設計」で、業務上のイベントが発生した時に、どのようなシステム上の動作を起こすかを決めてしまいます。
これを機能要件といいます。
対して、非機能要件と言って、何万件のデータを処理するのには何秒以内で終わるようにするとか、そういうシステムの動作する速度とかシステムがいっぺんに処理できるデータの容量だとか、そのような「こういう業務イベントが起きたらこのようなシステム上の動作を起こす」という要件ではない要件(非機能要件)も同時に決めます。
この段階では、大体クライアント企業のシステム部門の社員が分かるくらいの言葉で文書が書かれます。
私の経験上、「基本設計」に取り掛かった時点で、技術的な条件や細かい業務的な要望を突き合わせて具体的なシステムの仕様を決定していきますので、そもそもの要件定義に無理無茶があることが露見することが多いです。
露見はするのですが、大体の場合、まだ最終的な納期まで時間がありますので、「なんとかあとでリカバーしよう」というプロジェクトマネージャーの希望的観測により、納期・予算の組み直しの問題は俎上に上りません。
詳細設計
「詳細設計」は、基本設計で定まったシステム仕様を、コンピュータに命令するためのプログラミング言語に記述し、また色々のソフトウェアやミドルウェアの設定をするための参考資料となるような文書が作られます。
この文書は、非常にテクノロジーに強い技術者でなければ完全には理解できず、いわゆるシステムインテグレーター企業でシステムエンジニアとして採用された半エンジニア的な人が、何となくわかるかな？位の言葉で記述されます。
どこまでもテクニカルな文書ですので、基本設計で定まった要件をコードやソフトウェア・ミドルウェア・ハードウェアの設定に落とし込むにはどうすればよいか、正確に(機械的に)翻訳された文章になります。
ですから、基本設計での要件設定がハチャメチャですと、必然的に詳細設計での要件設定も無茶苦茶になります。
製造
そして、いよいよ「製造」工程に移ることになります。
特にITコンサルティング系企業だったりしますと、プログラミング作業なんて価値が低いという価値観に染まり切っていたりします。
しかしながら、この考え方はどうもおかしいのではないかと思います。
その理由はいろいろありますが、大要３点あります。
第一に、当たり前といえば当たり前なのですが、コードに1byteのミスがあってもシステムは正常に稼働しません。
従いまして、その意味で、そのコードを書くプログラミング工程は非常に重要な工程です。
第二に、同じインプットに対するアウトプットを出すコードがあるにしても、書きようはいくらでもあります。
そしてこの書きよう次第で、プログラムの処理速度は早くも遅くもなります。
システムの処理速度は非機能要件の中で最も重視されるものですから、これを左右するプログラマの技量の巧拙はとても重要です。
第三に、コードは後々にメンテナンスされるものであるだけに、可読性の高いコードを書いてもらう必要があります。
言い換えると、前任者の書いたコードを後任者が読んで、後任者がそのコードの意図を理解できるような、論理的なコードを書いてもらわないと、システムの運用保守に大きな支障が出るのです。
そのような論理的なコードが書けるかどうかは、プログラマの腕次第であって、しかもその出来不出来は、システム構築後の運用保守フェーズの業務効率に大きな影響をもたらします。
単純にクライアントと話せる人が偉いというわけではないのです。
システム屋は、あくまでどこまでエンジニアなわけですから。
単体テスト
コーディングが終わると、次に「単体テスト」を行います。
大体、単体テストというのはコードを書いたプログラマ自身が行いまして、しかも単体テストは自動化されていることが多いです。
「単体」というのはモジュール単体、という意味で、そのモジュールに与えられたインプットに対して予期したアウトプットが出されているかどうかを確認します。
この単体テストには二つの手法があり、1つ目はホワイトボックステスト、2つ目はブラックボックステストといいます。
ホワイトボックステスト
ホワイトテストというのは厳密でして、プログラムの分岐の組み合わせ全てを通るようなデータセットを用意して、これらすべてのデータセットに対して予期するアウトプットが得られるか否かを検査します。
ブラックボックステスト
ブラックボックステストというのは略式であり、モジュールの中身はブラックボックスに見立て、テスターが任意に設定したデータセットについて予期したアウトプットが得られれば単体テスト合格とします。
この段階で見つかるバグについては、修正も容易なので、問題はそれほど大きくありません。
結合テスト
次に、「結合テスト」を行います。
どこまで結合することを以て結合テストというのかはケースバイケースですが、大体「一機能」と呼ばれている塊単位でシステムが動作するかを確認することが多いと思います。
この結合テストでは、あるビジネス的なイベントが発生した時に、期待されたシステム上の動作が起きるか否か、つまり基本設計書通りにシステムが動作するか否かを検査します。
そのため、テストシナリオを作るときは、クライアントの業務に類似するシナリオを作ります。
そして、クライアントの業務担当者が実際にやるよう画面上で操作をしてみて、予期した結果が画面上に現れるか、そしてデータベース上にも画面と齟齬ないデータに変更されているかを確認します。
結合テストや、後に述べるシステムテストのシナリオを考えたりテストデータを作ることは、お客さんの業務とシステムとを複眼的に深く理解する意味で、とても良い勉強になる仕事です。
さて、結合テストでバグが出たということは、システムロジックに漏れがあったということを意味しますので、基本設計書を修正して詳細設計書も修正し、コーディングもし直して単体テストもやり直し、そして結合テストをやり直してやっとそのバグを解消できたということになります。
要は業務要件をシステムに落とし込めなかったシステムエンジニアの考慮漏れということになります。
システムテスト
その次に、「システムテスト」を行います。これは、納品後にクライアント担当者が使うのと同様のシステム環境で、正常にシステムが使えるかを検証します。
このシステムテスト、第1の難題は、どこまでをクライアントの実行するケースとして想定したらよいのか、一概に範囲が確定できないことです。
ベーシックな操作だけでいいのか、半年に一度は生じるケースも検査するのか、半年に一度のケースまで、なんていう話になってきますと、これを一覧するだけでも大変な難事業ですが、大体その情報を持っているユーザー部門はシステムテストにそんなに協力的ではありません。
しかも、システムテストを実施する側には、ある操作に対する正解となる結果が何になるか、わからないのです。
わかるのはユーザ部門の職員です。
しかし彼らはシステムのために時間を使おうとしません。
ということで、システムテストのシナリオ作りは大変な難事業なのです。
システムテストの場合、何が正解か、はっきり言ってシステム屋にはよくわかりませんので、バグが否か疑わしいような結果が出た場合、システム屋、IT部門、ユーザ部門の間でそのバグの問題についてのやり取りが延々と繰り返されて、結局どうしていいかわからないことになります。
このころになると、大体のプロジェクトではバグ一覧表なるモノが作られだして、毎朝その一覧表をスクリーンに映し出しながら、関係者一同、」これはあーするかどーするかと延々語られるのが通例です。
UAT（ユーザ受入テスト）
「UAT（ユーザ受入テスト）」とは、実際に業務ユーザにシステムを使わせてみて、これで納品していいですよね？と確認を取るテストのことです。
この時、テストの合否基準は、ずばり、業務担当者の何となくの感想です。
ですので、ほぼ100％のUATで、「ここは思っていたのと違った。」とか、「こんなのじゃ今のシステムのがよっぽど使いやすい。」とか、「こんなのじゃ私仕事できません！」とか、そういうクレームが続発するのが常です。
ですので、UATの肝は、こうしたクレームを如何に政治的にさばくか、この段取り次第にあります。UATのフィードバックは、バグか仕様変更かのいずれかに分類されます。
バグであれば納品の前に直さなければいけませんが、仕様変更ということであれば別途見積もりを取った別契約扱いです。
山と押し寄せるクレームを、このいずれかに効率よく分類することが、肝要です。
その為には、まずシステム屋としては、IT担当部署の最高責任者と、バグと仕様変更との分け方の基準を明確に合意しておくことです。
IT部門の責任者としては、「できれば同じ予算でITベンダーに仕事を余計にさせてユーザ部門に恩を売っておきたいけど、あまり無理をさせて納期が大幅に遅れたら自分の責任になるから困る」という考えがあります。
ですから、手元に現状の人員稼働状況や工数見込みなどを共有しながら、「現実的にどこまでなら無理が効くか」というスタンスで話をしてあげると、IT部門の責任者としては、話をしやすいでしょう。
VモデルはITエンジニアのスキルを定義できる
なお、ITエンジニアにとってVモデルの各プロセスは、自分の持つ技能を端的に表すための用語になっている面があります。
一般に、「業界×Vモデルのプロセス」で、その人の持つ技能を表現します。
例えば、「金融業界の結合テストの経験があります」とか、「小売業の基本設計の経験があります」とか、そのような言い方をします。
なぜこのような表現の仕方をするかというと、同じ基本設計でも、スーパーマーケットのシステムの基本設計と会計管理システムの基本設計では大分ノウハウが違います。
しかし、クライアントの違いこそあれ、同じ会計管理システムであれば、どこのクライアント企業の基本設計でもノウハウはおよそ共通するのです。
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選アジャイル開発モデルとその実態
ウォーターフォールモデル及びこの派生形であるVモデルは、後工程から前工程へとさかのぼることがないことが前提のシステム開発管理技法であることをお話いたしました。
しかし、後工程に入り前工程で作成した計画や仕様の修正が必要になることは多々あるとして、たびたび批判されてきました。
その批判のうちの一つが、アジャイル開発モデルといわれるもので、有名になっています。
ウォーターフォールモデルは、要件定義の段階でそれ以降システム納入の段階までのスケジュールや人員、工数を先に決めてしまい、以降原則としてプロジェクトに割り当てられた資源の追加調達は認めません。
進捗管理は文書に従って行われ、テスト結果もエヴィデンスという文書を作成して行います。
これに対してアジャイル開発といいますのは、全体の開発業務を細かい作業単位に分割し、作業単位一つ一つ毎に作業を進めていきます。
当初から作業全てをいついつまでに何人月で行うというような決定はしません。
アジャイル開発は、作業に関係する者全員が、ひとところに集まるのが理想とされます。
つまり、業務ユーザ、IT部門社員、プロジェクトマネージャー、システムエンジニア、プログラマ、インフラエンジニア等すべてが一つの部屋に集まるべきなのです。
そして、その場でVモデルが言うところの要件定義・基本設計・詳細設計・製造・各種テストをいっぺんにやってしまうのです。
いっぺんにやってしまうのですから、文書化はしません。
「唯一の文書はコードだ」が彼らの合言葉です。何か問題が起れば、そのプロジェクトルーム内で解決して、さっさと製品をリリースしてしまいます。
これがアジャイル開発モデルです。
確かに、後工程で発見された前工程の成果物の修正が即座に為されるという点で、ウォーターフォールモデルの弱点を見事に補強しているように見えます。
しかしながら、ウォーターフォールモデルに慣れ親しんだ私から見ますと、納期ひっ迫で大混乱しているプロジェクトルームの地獄絵図をと変わりがないように見えてしまうのも事実です。
まず、いくらウォーターフォールモデルの当初スケジュールへの固執が問題だとはいっても、スケジュールをいったん立ててみることと、ノープランでプロジェクトをスタートさせることはまるで違います。
まずはスケジュールを可能な限り精緻に立て、予定と実績の比較を正確に行い、必要に応じて適当にスケジュールを変更することこそが望ましいと思います。
また、ドキュメンテーションは省略するというのは、決していいことではありません。
コードだけ見てロジックを読み取れるのは、熟練のプログラマだけであって、業務ユーザ側が同じ土俵でシステムを議論するのに適していません。
また、プロジェクトの方針としてスタッフの責任の所在は問わないということであるにしても、システム構築の問題点を振り返るとき、原因の探求は何らかの資料がなくては不可能です。
また、そのシステムの作り変えの検討をするときも、資料がなくては検討の手がかりがないように思う私は、時代遅れな20世紀型システムエンジニアなのでしょうか…？
プロジェクト管理モデルについてのまとめ
さて、この記事では、実際のシステム構築プロジェクトがどのように進むかについて、ウォーターフォールモデル、Vモデル、そしてアジャイル開発モデルという3タイプのプロジェクト管理モデルに従って、説明を進めてみました。
エンタープライズシステム（大企業で使うシステム）を作るシステム企業に勤められる場合は、今述べたようなお仕事をすることになります。
この記事を読んで、具体的なイメージを持っていただけたようであれば、幸いです。
最後までお読みいただき、ありがとうございました。