型が求める本質的な品質に対する理解とコントロール

従来、標準化とは「生産性向上」につながる取り組みという位置づけでとらえられていますが効果はそれだけではありません。

作業の属人化解消による「品質向上」とテンプレート導入時の意識改革による「スキルの底上げ」を同時にもたらし、その結果「生産性向上」につながるといった仕組みになっているのです。

しかし、残念ながら昨今のシステム開発現場…なかでもプロジェクト内部ではそのような取り組みがほとんど為されていません。

そういう意味では市場全体において、楽ができるフレームワークやツールの導入に対する意欲的はあっても、反面、仕組みを考えようとするエンジニアがどんどん減ってきているのはこの業界の行く末の心配が尽きません。

ソフトウェアの品質にはISO 9126やその後継であるISO 25010等が示すように、ただの外部品質（プロダクト品質）だけではなく、様々な品質があります。

また「企画品質」「設計品質」「製造品質」「使用品質」といった、工程別に確保するべき品質を定義した考え方もあります。システム開発ではそれぞれの品質とそれを確保する工程は次のようになるでしょう。

Ｖ字モデルと品質の定義

これはそもそも

　「なんのために工程が分かれているのか？」

という原始的な問いを図示したものです。

設計だけでも複数個…テストだけでも複数個の工程があるのは"モノを作るため"に必要だからではなく、"作るモノの品質を確実にするために"必要だから策定されているのです。

そうした背景を理解していれば、同じような流れで

　「設計」→「製造」→「テスト」

と進ませる以上、何よりも定められたスケジュール、定められたコスト、限られたリソース内で如何にして品質を落とさずに進めるべきかということを真っ先に検討すべきであろうことがわかるのではないでしょうか。

ただつくるだけでいいのであれば製造工程だけ用意して、試行錯誤しながら作っていけばいいだけのはずです。

しかし、あえて設計工程を用意するのは作るモノの全体像をあらかじめ決めておくことで、

　・製造時に複数人で取り掛かっても齟齬が起きないように
　・担当が途中で変わることがあっても品質が下がらないように
　・何度作ることになっても同じモノを再現できるように
　・保守運用や次期開発時に余計なコストがかからないように

とすることが求められているからです。

こういった本質的な"Why"を理解できていないエンジニアは、大抵の場合が

　設計書不要論

を提唱することになります。
まずはこのことがイメージできていないと正しい開発は絶対にできません。いえアジャイル型の開発モデルのようにプロジェクト"だけ"は成功したとしてもその後の保守運用や次期開発までは考慮されておらず、中長期的に見ればユーザーに多大な負担をかけていた…なんてことも考えられます。

また、品質には「当たり前品質」「魅力的品質」と言う顧客満足度別に確保するべき品質を定義した考え方もあります。サービス業という視点から見た場合、とてもわかりやすいのではないでしょうか。

狩野モデル

先ほどの品質の定義と組み合わせて考えると「当たり前品質」とは「企画品質」の内容が顧客とのコミュニケーションによって共有化することで確保されるものといえます。

ちなみに「設計品質」は「ねらいの品質」、「製造品質」は「できばえの品質」ともいいます。

先ほどのＶ字モデルから１つ例を挙げてみましょう。

単体テストとは、詳細設計書のとおりにプログラムが作成されているかを検査する工程です。先の工程別品質で考えると「設計品質」「製造品質」に相当し、「ねらい」どおりの「できばえ」となっているかをチェックする工程ともいえます。

昨今のソフトウェア開発では、おそらく単体テストと結合テストの明確な切り分けができている現場はとても希少となっていることでしょう。特にWeb系の開発現場ではその傾向が顕著です。

色々と言い訳も出てくることでしょうが、

　「その結果、本当に品質は保証されているのか？」

と聞かれて自信を持って明確に"Yes"と言えなければ、いかなる言い訳も意味を持ちません。

したがって、単体テストのチェックリストのあり方を考える場合、まずは詳細設計書の記載項目がすべて漏れなく単体テスト仕様書にも存在しているような工夫が必要です。そういった意味では詳細設計書に単体テスト用のチェック項目が網羅されていればいいはずです。

しかし、それだけではなかなかうまく進まないケースもあります。

まず１つ目の理由としては、詳細設計書が顧客指定の場合がある点です。
たとえば、システムのリプレイス（再構築）プロジェクトで顧客側に情報システム部門があると、見慣れている前システムの設計書フォーマットに合わせてほしいという要望が出てきます。

２つ目の理由は、単体テストのチェック項目をマージしてしまうと設計書自体が読みにくくなる点です。テスト結果を記載する欄といっても１項目だけではないため、それらをあらかじめ設計書に用意するとページの右半分はテスト関連項目になってしまい、設計時や実装時に読みにくく非効率になります。

３つ目の理由は、設計書にWordを利用されている場合がある点です。設計書はExcelとWordのどちらがいいかというよくある議論になってしまうので、ここで細かく述べるつもりはありませんが、Wordは、

　・顧客への納品物として体裁がよい
　・見出しマップや目次機能により必要な個所へのアクセスがよい

などのメリットがあるため、自分たちが開発する際の自己都合…だけでなく、納品後にあらためて他社に改造等の依頼を行っても引き継ぎやすいよう、設計書がWordとなっていることも珍しくありません。

しかし、設計書はWordでよくても、テスト仕様書は断然Excelの方が都合がいいのです。

なぜなら単体テストでは集計値が必要だからです。お客さまに対するほとんどの実績報告は集計値となっているはずです。

以上のような理由で、単体テストのチェックリストはExcelで詳細設計書とは別に独立して作成することが理想的であると言えるでしょう。

また、単体テストは「できばえ」の品質を見るために行われるわけですから、"出来"の"栄え"を全確認しなければなりません。そのため、多くの現場では必ずと言っていいほどカバレッジ(coverage)が100%となることは絶対的な命題であるとなります。まさか自ら作成したプログラムを一度も実行しないまま品質として「OKである」なんて言えるわけもありませんから、必ず１度以上実行したことを証明するのは当然の責務です。

可能であればC1（ブランチ）カバレッジで十分となるようにしたいところですが、そうするためには本来『設計』の時点で正しくクラス設計やモジュール設計が行われていなければなりません。『設計』に不安がある場合、C1カバレッジで十分な品質が保証できない場合は、嫌でもC2（コンディション）カバレッジを見据えなければならなくなることでしょう。

カバレッジとは、所定の網羅条件がテストによってどれだけ実行されたかを割合で表したもので「網羅率」とも言います。テストを実施するにあたって、カバレッジを測定／分析することはソフトウェアの品質保証に非常に大きな意味を持ちます。なぜなら、カバレッジ情報からテストそのもの品質を定量的に測ることができるからです。

カバレッジそのものの値はソフトウェア品質を一切保証しませんが、カバレッジを測定することで作成したプログラムの実施率がわかります。これを100%と証明できなければ、単体テスト工程の品質が十分であると証明することは論理的に困難となる…というわけです。

テストのカバレッジを測定する方法はコードや仕様、要件、設計などさまざまな側面から計測する方法がありますが、単体テストの段階ではコードベースのカバレッジでテストの品質を測ることが一般的です。

コードカバレッジを測定し、テストが実施されていないコードを確認することにより、

　・絶対に通過しないコードは無いか？
　・想定した条件（設計書に記述した条件）通りに通過しているか？
　・テストケースは本当に網羅されているのか？

と言った詳細設計や製造の妥当性を向上させることができます。

逆に言えば、そのことを理解せず漠然とカバレッジテストを実施しているだけでは、たとえば、

　「どうしても網羅率が100%にならないから、無理やり通しちゃえ」

と言った、品質には何も貢献しない不誠実極まりない対応を平気で行ってしまうようになります。

品質に対する姿勢とはつまるところ、対象とするモノや仕事あるいは人に対して

　どれだけ誠実であろうとするか？

という姿勢です。

たとえば、好きな人に料理をふるまう際に「不味くてもいいや」とは思わないでしょう。子供のクリスマスプレゼントに、あえて嫌がるモノを用意することもないはずです。

また同時に

　どれだけプロフェッショナルとしての意識が高いか？

を表す試金石のようなものでもあります。

そもそも契約時点で見積もられた金額や期間は、きちんと100%の品質で納めることを前提としたものであるはずですし、その契約通りに遂行する意思があるからこそ請求前の段階でも私たちエンジニアに報酬が支払われているはずです。

私たちエンジニアは、品質を100%保証することを前提として前金という名の給与をもらっている状態なわけです。である以上、その契約を完遂するためのプロ意識を持つのは当然のことです。

ソフトウェアの品質も同様に、納める先のお客さまに対してあるいは納めた先で利用する人たちに対してどれだけ真摯を貫けるか、その姿勢の結果がそのまま形となって顕われていることを理解しましょう。

　『品質が低い』

ということは、それだけお客さまを相当ナメているということです。