確保すべき品質とは？
従来「標準化」とは、「生産性向上」の取り組みという位置づけでとらえられますが、効果はそれだけではありません。
作業の属人化解消による「品質向上」と、テンプレート導入時の意識改革による「スキル底上げ」を同時にもたらし、その結果「生産性向上」につながるといった仕組みになっているのです。
しかし、残念ながら昨今の開発現場ではそのような取り組みがほとんど為されていません。
そういう意味では、市場全体において、"楽ができる"フレームワークやツールの導入に対する意欲的はあっても、その反面、仕組みを考えようとするエンジニアがどんどん減ってきているのは、この業界の行く末の心配が尽きません。
ソフトウェアの品質には、ISO 9126（JIS X 9126）やISO 25010等が示すように、ただの製品品質（プロダクト品質）だけではなく、様々な品質があります。「利用時の品質」「設計（内部）品質」「製造（外部）品質」「プロセス品質」といった、工程別に確保するべき品質を定義した考え方もあります。システム開発では、それぞれの品質とそれを確保する工程は次のようになるでしょう。
これは、
「なんのために工程が分かれているのか？」
という原始的な問いを図示したものです。設計だけでも複数個、テストだけでも複数個の工程があるのは、"モノを作るため"に必要だからではなく、"作るモノの品質を確実にするために"必要だから策定されています。ただ、つくるだけだったら製造工程だけあって、試行錯誤しながら作ればいいだけです。
しかし、あえて設計工程を用意するのは、作るモノの全体像をあらかじめ決めておくことで、
・製造時に複数人で取り掛かっても、認識齟齬が起きないように
・量産品を作る際に、同じものを再現できるように
することが求められているからです。こういう、本質的な"Why"を理解できていないエンジニアは、大抵の場合、設計書不要論を提唱することになります。
まずはこのことがイメージできていないと、正しい開発は絶対にできません。また、品質には「当たり前品質」「魅力的品質」と言う、顧客満足度別に確保するべき品質を定義した考え方もあります。
これらと組み合わせて考えると、「当たり前品質」とは「利用時の品質」の内容が、顧客とのコミュニケーションによって共有化することで確保されるものといえます。ちなみに「設計品質」は「ねらいの品質」、「製造品質」は「できばえの品質」ともいいます。
上図から１つ例を挙げてみましょう。
単体テストとは、詳細設計書に書かれているとおりにプログラムが作成されているかを検査する工程です（テスト工程は、あくまで「設計通りか否か？」を確認する工程であると言うことを忘れないようにしましょう。これはアジャイルでも基本的には同じです）。
先の工程別品質で考えると、「設計品質」「製造品質」に相当し、「ねらい」どおりの「できばえ」となっているかをチェックする工程ともいえます。
昨今のソフトウェア開発では、おそらく単体テストと結合テストの明確な切り分けができている現場はとても希少となっていることでしょう。
色々と言い訳も出てくることでしょうが、
「その結果、本当に品質は保証されているのか？」
「保証できていることを証明する術はあるのか？」
と聞かれて、自信を持って明確に"Yes"と言えなければ、いかなる言い訳も、言い分も意味を持ちません。したがって、単体テストのチェックリストのあり方を考える場合、まずは詳細設計書の記載項目が、すべて漏れなく単体テスト仕様書にも存在しているような工夫が必要です。そういった意味では、詳細設計書に単体テスト用のチェック項目があればいいはずですね。
しかし、それだけではなかなかうまく進まないケースもあります。
まず１つ目の理由としては、詳細設計書がお客さま指定の場合があるからです。たとえば、システムのリプレース（再構築）案件でお客さま側に情報システム部門があると、見慣れている前システムの設計書フォーマットに合わせてほしいという要望が出てきます。
２つ目の理由は、単体テストのチェック項目をマージしてしまうと、設計書自体が読みにくくなるからです。テスト結果を記載する欄といっても１項目だけではないため、それらをあらかじめ設計書に用意すると、ページの右半分はテスト関連項目になってしまい、設計時や実装時に読みにくく非効率になります。
３つ目の理由は、設計書にWordを利用されている場合があるからです。設計書はExcelとWordのどちらがいいかという、よくある議論になってしまうので、ここで細かく述べるつもりはありませんが、Word文書は、
・顧客へのドキュメント納品物としてはとても体裁がよい
・見出しマップや目次機能により必要な個所へのアクセスがよい
・文書校正の機能などによって、誤字脱字等の問題が起きにくい
などのメリットがあるため、自分たちが開発する際の自己都合だけでなく、納品後、あらためて当社ではなく他社に改造等の依頼を行ってしまうとしても引き継ぎやすいように、設計書がWordとなっていることも珍しくありません。
しかし、設計書はWordでも、単体テストのチェックリストは断然Excelの方が都合がいいのです。なぜなら、単体テストでは集計値が必要だからです。お客さまに対するほとんどの実績報告は、定量的な集計値となっているはずです。
以上のような理由で、単体テストのチェックリストは、Excelで詳細設計書とは別に独立して作成することが理想的であると言えるでしょう。まぁ「詳細設計」という工程を含むようなプロジェクトであれば…の話ですが。裏を返せば、詳細設計レベルの設計を行っていないにもかかわらず、単体テストをしても、ほとんど意味がありません。
「正しい」と評価するための根拠が伴わないからです。
また、単体テストは「できばえ」の品質を見るために行われるわけですから、自ら作成した全てのプログラム1行1行に対して、"出来"の"映え"を確認しなければなりません。そのため、カバレッジ(coverage)が100%となることは絶対的な命題となるのです。カバレッジとは、所定の網羅条件がテストによってどれだけ実行されたかを割合で表したものです。"網羅率"とも言います。
網羅条件が「命令」であれば、命令網羅と呼ばれ、すべての実行可能な命令のうち、テストで実行された命令の割合を意味します。つまり、作成した関数に対して、実際に呼び出し、テストした数を割合として産出するわけです。
すべての判定条件のうち、テストで実行された判定条件を意味する条件網羅などもあります。テストを実施するにあたって、カバレッジを測定／分析することは、ソフトウェアの品質向上に非常に大きな意味を持ちます。なぜなら、カバレッジ情報からテストそのもの実行進度を定量的に測ることができるからです。
テストのカバレッジを測定する方法は、コードや仕様、要件、設計など、さまざまな側面から計測する方法がありますが、単体テストの段階では、コードベースのカバレッジでテストの品質を測ることが一般的です。コードカバレッジを測定し、テストが実施されていないコードを確認することにより、
・絶対に通過しない到達不可能なコードは無いか？
・想定した条件（設計書に記述した条件）通りに通過しているか？
と言った、詳細設計や製造の妥当性を向上させることができます。逆に言えば、そのことを理解せず漠然とカバレッジテストを実施しているだけでは、
たとえば、
「どうしても網羅率が100%にならないから、無理やり通しちゃえ」
と言った、品質には何も貢献しない、不誠実極まりない対応を平気で行ってしまうようになります。実際、そういうごまかし方をするエンジニアも多いと聞きます。品質に対する姿勢とは、つまるところ、対象とするモノや仕事あるいは人に対して
「どれだけ誠実であろうとするか？」
と言う姿勢です。
たとえば、好きな人に料理をふるまう際に、「不味くてもいいや」とは思わないでしょう。子供のクリスマスプレゼントに、あえて嫌がるモノを用意することもないはずです。
ソフトウェアの品質も同様に、納める先のお客さまに対して、あるいは納めた先で利用する人たちに対して、どれだけ真摯さを貫けるかが、そのまま形となって顕われていることを理解しましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。