書いた人：NEO-TAKAHASHI（システムエンジニア）

どうもこんにちは。Zooops Japan（ズープス ジャパン）一のナイスミドルなマネージャー（目下修行の身）・NEO-TAKAHASHIです。 最近、公園にはまっていて、小さなテントを購入しました。公園でテントを出して昼寝や読書をするのが日課になりつつあります。 さて、前回はV字モデルの各工程から、「詳細設計」を紹介しました。今回は、その続き。 いよいよ来ましたプログラマー（以下、PG）の花形！ 「製造（プログラミング）」についてのお話を中心に、テスト～システムリリースまでの流れを説明します。

▼目次 １．ついに来ました「製造（プログラミング）！」 ～ここでちょっと寄道～　プログラミングって何？ ２．「テスト！テスト！テスト！」 ３．そして迎えた「システムリリースリリース（本番稼働）！」 ４．本日のおさらい ５．あとがき ▼関連記事 ・（その１）V字モデルで「システム開発」の流れについて知ろう！ ・（その２）「要件定義」と「基本設計」 ・（その３）「詳細設計」 ・（その４）「製造」から「システムリリース」まで

ついに来ました「製造（プログラミング）！」

と言うわけで、ようやくたどり着きました「製造（プログラミング）」です。この工程を面白い、楽しいと感じ、システム開発会社に入る、という人も多いのではないでしょうか。プログラミングが中心となり、システムエンジニア（以下、SE）という職業の中でも一番分かりやすい工程であると言えます。 主にPGが担当し、前回説明した詳細設計書をインプットとして、プログラムをアウトプットします。製造においては、詳細設計書に記載されている通りにプログラミングすることが重要です。設計に記載されている仕様を無視してPGの好みでプログラミングしては……後々SEとの禍根を産むことになるでしょう……。 まあ、半分は冗談ですが（半分だけねw）、この仕様通りにプログラミングするということはとても大切です。 仮に、あるモジュールでバグ（プログラムの不具合）が発覚したとします。システムリリースに至るまでに、このバグを管理し、分析した上でシステムリリース時の判断材料のひとつとするのですが（※１）、設計書通りにプログラミングをしていない場合、このバグが製造時のバグ（製造バグ）なのか、設計時のバグ（設計バグ、あるいは仕様バグ）なのか、責任の所在が不明確になってしまいます。逆に、設計書の通りに製造すると矛盾が生じ、どう動いてもバグとなってしまう場合は設計バグとなるわけですが、いずれにしても問題を解消した上でプログラム作成を再開させるべきです。 ※１：バグが発生した場合、そのバグを修正して正常に動作しなければリリースすることは出来ません（当たり前ですが）。バグの発生したフェーズが後になれば後になるほど、その影響は大きくなります。 例えば、後述するシステムテスト実施時にバグが発生した場合、バグの元凶であるモジュール（１つとは限りません）を修正し、再度単体テスト、結合テスト、システムテストを実施するのが、本来あるべき姿です。ただ、工数やリリース時期の兼ね合いで、いずれかのテストを省略する場合があります。さらには障害を生み出すことがわかっていても、修正をすることによるリスクの方が大きいと判断し、運用・保守フェーズに対応を見送る場合もあります。こうしたバグの特性、発生個所、発生条件、などを管理することがバグ分析です。システムの規模が大きくなるほどに、こうしたバグは後を絶たず、止む無くデータ修正（データパッチ）や、特殊なオペレーションをユーザに依頼したりすることでこれ以上システムを破壊しないよう対応することがあります。

～ここでちょっと寄道～

プログラムって何？

プログラムをひと言でいうと、コンピューターに対する命令（処理）を記述したものです。コンピューターはプログラムに記載された順番で計算、入出力を実行します。 Java（ジャバ）やC言語（シー言語）と言ったプログラミング言語でソースコードを作成し、コンピューターが理解できるよう機械語に変換（コンパイル）した結果として生成される実行ファイルやライブラリがイメージしやすいでしょうか。 この他にも、事前のコンパイルが不要なPHP（ピー・エイチ・ピー）やJavaScript（ジャバスクリプト）、シェルスクリプトなどのスクリプト言語で書かれたコードもプログラムです。 これに対し、HTML（エイチティーエムエル）、XML（エックスエムエル）はマークアップ言語と呼ばれ、タグにより印付けをする言語であり、これによってコンピューターは計算処理を行わない（マークアップ言語では計算処理を表現できない）ため、厳密にはプログラミング言語ではありません（※２）。 コンパイル方式ごとの分類の一例 ※２：プログラミング手法や開発手法などの詳細は、ネットで検索すれば大抵のことは調べられるのと、本稿の本筋からそれてしまうので今回は割愛します。知っておいてほしいプログラミング技法などあったら、今後、どこかのタイミングで記事にしていこうと思います。

「テスト！テスト！テスト！」

さて、プログラミングが済んだら次はテスト工程です。テストを実施する順序としては、「単体テスト」、「結合テスト」、「システムテスト」と続いていきます。 各テストの目的・用途や実施方法などの詳細については別途記事にしたいのでここでは省略しますが、ざっくり言うならば、下記のようなことを行います。

【単体テスト（UT：Unit test）】 単一の部品（モジュール）で実施するテスト。開発者が実施することが多い。 【結合テスト（IT：Integration test）】 複数のモジュールを組み合わせて実施するテスト。モジュール間の接続点（インタフェース）のテストやモジュールを結合することで得られる結果が正しいか、といった部分をテストする。SEやQA（Quality Assurance：品質管理）チームが実施することが多い。 【システムテスト（ST：System test）】 システム全体を通して実施するテスト。本番環境とほぼ同等な環境で実施することが多い。要件通りにシステムが動くか、レスポンスなどの性能が十分か、などを検証する。SE、QAが主に実施するが、ユーザに参加いただく場合もある。

このように、各テストは、作ったシステムの品質を担保する証明となります。 ちなみに、私もはじめはそうだったのですが、バグを出すのは「カッコ悪い」「恥ずかしい」と思う人がいますが、それは違います。 確かにケアレスミスや、スキル不足で出してしまうバグは恥ずかしいことかもしれません。しかし、そもそもテスト工程は本番稼働を迎えるために、そうした人的ミスなどが無いかを検証する工程ですので、むしろしっかりとバグを出すべきなのです。 テスト工程である程度バグを出さないと、「バグ発生数が基準に満たないからリリースは出来ません！」なんていうプロジェクトもあるくらいです。 一概にバグがゼロだから品質が低い、バグが想定通り（もしくは想定以上）に発生し、回収できているから品質が高い、というわけではありませんが、発生したバグを管理することで、類似機能への反映や、別のプロジェクトへの流用も可能になってきます。何より、PG個々人の経験につながることなので、しっかりとバグを出して、同じようなバグは生まないように管理・蓄積していく気持ちを持っていってください。 また、テストをするにあたり、「テストケース（テスト内容をまとめたもの）」を作成してテストを実施することになりますが、このテストケースは詳細設計をベースに作成することが多いです。設計書がしっかりと機能を網羅出来ていないと、必然的にテストケースも穴だらけになり兼ねません。

そして迎えた「システムリリースリリース（本番稼働）！」

上述したテスト工程をしっかり踏んでいれば、リリースはそれほど大変な作業はありません。 すべきこととしては、以下のようなものが挙げられます。

・本番稼働の日程調整 ・リリース作業を実施する体制の構築 ・リリース当日の詳細なスケジュール（タイムスケジュール） ・稼働後の監視体制など

本番稼働に際しては、万全の準備をしていてもトラブルは発生してしまうので、万が一に備える体制作りが主な作業になってきます。

本日のおさらい ●「製造」「テスト」そして「システムリリース」 今回、製造、テストを通して、我々エンジニアがすべきことを説明してきました。 「製造」とは詳細設計をインプットにしてアウトプットされるものであり、それに基づいて、テストへつながるもの、ということを理解してくれればよいと思います。そして、このテストであらかたバグを摘出し、品質を担保した状態で本番稼働につなげる、という一連の流れが、V字モデル後半の流れです。

あとがき

昨年の暮れあたりから、少しずつ書いては直し書いては直し……を繰り返しながら、前編、中編、後編と3回に渡ってV字モデルの工程を紹介してきました（もの書きを専門にしている人は本当にすごいな、とつくづく思った次第です……）。 各工程はそれぞれが密接に関係しています。プロジェクトを成功させるには、各工程全てが重要であることを理解してくれたら嬉しいです。 プロジェクトの規模が大きくなればなるほど、全てを把握することは難しくなりますが、「要件はもう決めたから、あとはベンダーにぶん投げればいいや」とか、「製造にしか関与しないから設計は知らなくていいよね」とか、「設計しかしないから、製造のことはまるっと任せるよ」、といった考えのエンジニアばかりだと、あれよあれよという間にプロジェクトは破綻に近づいていきます。 この記事は、できるだけそうした悲しいプロジェクトが減れば（切実）という期待も込めて、日々プロジェクトに関わるエンジニアの皆さんや、これから関わる新人の皆さんの少しでも役に立つ知識や考えを提供できれば、と思って書いてきました。 自分自身もこの執筆を通して、知らず知らずのうちに様々なことを知りたい、と以前よりも欲するようになったかなと思います。 今回ひと区切りついたので、次回は少し軽めの記事にしようかと思っています。今後も継続して技術的な部分で皆さんのためになるようなことを取り上げて記事にしていきたいです。 次回も、こうご期待！

関連記事

・（その１）V字モデルで「システム開発」の流れについて知ろう！ ・（その２）「要件定義」と「基本設計」 ・（その３）「詳細設計」 ・（その４）「製造」から「システムリリース」まで