開発工程の中の製造・単体テストの説明です。
１．単体テストについて
単体テストは、人によって対象とする範囲が異なるため、プロジェクト計画書で以下のどちらを指すのかを明確にして、プロジェクト内での共通認識を持つことが重要です。
①正しい意味での「単体テスト」
いわゆるプログラムテスト。モジュール単体のテストです。JavaであればJUnitなどのツールを使ってテストをしたりします。「ドライバ」とか「スタブ」とかいったテスト用のモジュールが登場するのも、この単体テスト工程です。
大規模のスクラッチ開発のプロジェクトでは、こういったモジュール単体のテストで、最低限の品質を担保してから結合テスト（機能テスト）を実施します。
小規模のプロジェクトの場合には、この単体テスト（プログラムテスト）は実施しないことが多く、プログラマーが画面等を動かして、動作確認する程度で本来の意味での単体テスト工程を終えます。
また本来の言葉の意味とは異なりますが、この簡単な動作確認をデバッグと呼んだり、単体テストのことをデバッグと呼んだりすることもあります。
②間違って理解している人の多い「単体テスト」
私の経験上では、単機能の結合テストを単体テストと呼ぶことが多いです。日本でトップクラスの大手ベンダーのプロジェクトマネージャーでも、そのような勘違いをしている人が多いです。
単機能の結合テストとは、具体的には１画面内のバリデーションチェック（入力値のチェック）やエラーメッセージの出力タイミングや文言等のテストのことです。
プロジェクトによっては、連続した画面遷移も含めて単体テストの範囲にすることもあります。
事業会社のシステム部門はプログラミング経験の無い人が多いので、①の単体テストのテスト仕様書は見ても分かりません。そのため単体テストのテスト仕様書は通常はレビュー対象外としますが、これをベンダーは②の単体テストと勘違いをして、後になってベンダーと揉めるケースがあります。
ベンダーはレビュー対象外かレビュー対象かで、ドキュメンテーションの力の入れ具合を変えます。そのためレビュー対象外と思っていた単体テスト仕様書がレビュー対象になると、ドキュメントをキレイにするための余計な工数が発生するため、難色を示します。
そのようなことを避けるためにも、プロジェクト計画の工程定義をする段階で、きちんと単体テストの範囲を明確にした上で、レビュー有無を合意する必要があります。
２．製造でやること
プログラミングする際に重要な役割を担うのは、コーディング規約です。
コーディング規約は、変数やメソッド等の命名規約を定めたり、ソースの可読性を高めたりするためのルールをまとめたものです。
例
・文字コードはMS932で記述すること
・改行コードは「CR+LF」にすること
・SQLに実値をハードコーディングしないこと
・マジックナンバーは使用しないこと
・インデントはタブではなく、半角空白とすること
これらは遵守しなくても、システムが仕様通りに動かないといった不具合は発生しませんが、プログラマーによってソースの書き方が異なると、他の人が修正する際にソースを解読するのに時間がかかったり、誤って解釈してしまったりといった弊害が発生します。
プログラムソースのソースレビューでは、サンプリングしたソースコードに対して、コーディング規約を遵守しているかをチェックすることが主目的になります。
３．ITエンジニアの一般的なイメージ？
ITの仕事を知らない一般の人が抱くITエンジニアの仕事のイメージは、まさのこの製造・単体テストのイメージかと思います。
実際に２０年くらい前までは、プログラミングはシステム開発の主流の工程でした。新人はまずはプログラミングを経験し、設計、要件定義といった順番でスキルアップしていくのが王道でした。
でもプログラミング言語の生産性が高まることで、製造工程は全体の工程の中でどんどん短くなっていき、最近ではプログラミングしなくてもGUIだけでシステムが作れるようになりました。
RPAにいたっては、すでにユーザー部門が自分たちでシステムを作ってしまえる状態です。今後、パッケージ製品やSaaS等を作るコアなプログラマーと、それらを利用してシステムを開発するライトなプログラマー？の二極化がどんどん激しくなっていくと思います。
【振り返り】
