株式会社 ソフテック
制御用ソフトウェアの受託開発を手がけて５３年の経験と
受注案件７０７９件（2024年9月末時点）の実績
受注案件７０７９件（2024年9月末時点）の実績
「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより（発行日順）のページへ
ソフテックだより 技術レポート（技術分野別）のページへ
ソフテックだより 現場の声（シーン別）のページへ
私は、ソフテック社内でも大きな規模のシステム開発の管理をしています。
過去の開発では、不適合対応が収束せずに納期が遅れたことや、出荷後に不適合を出してしまうなど、品質面でお客様へ迷惑をかけたことがありました。
管理をする立場であるため、顧客満足はもちろんですが、開発担当者も満足できる製品を作るために、書籍を読んで知識を広げ、品質を高める方法を考え、改善に努めています。
品質を高めるためには、プログラムを作るフェーズで、品質が高いプログラミングが要求され、そのプログラムを作るためには、様々なことを考慮した設計が必要です。
つまり高い品質のソフトウェアは、上流フェーズから品質を作りこまなければなりません。
上流フェーズから品質を意識して開発し、その品質の記録を残すフェーズとしてシステムテストを実施します。
システムテストで不適合を見つけ出すようでは、上流で品質を作りこめていないため、問題があるシステムとなります。
今回の「ソフテックだより」では、出荷前に実施するシステムテストを題材にします。
私は8年前に、大規模システムの管理をする機会を頂きました。
その当時の私は、「システムテスト」とは仕様書に記載されている機能が正しく動作することを確認する作業と考えていました。
また、「不適合を見つけるためにシステムテストを実施する」と間違った考えを持っていました。
その考えで開発を進めた結果、システムテスト段階になってから品質を高める作業に時間を使い、納期や品質面で大きな失敗をしました。
実際に、自分が1人で担当していた小さなソフトでは、機能が正しく動作することを確認し、不適合が見つかっても、ちょっと修正すればそれで正しく動作して、出荷後に不適合が出ることも、ほとんどありませんでした。
しかし、大きな失敗を経験して、この考えではソフトウェア品質を高めるには不十分であると気が付きました。
例えば、「機能は正しく動作するが操作や表示の反応が遅い」問題が出ると、機能確認だけでは不十分と気づきます。
また「不適合を修正したが別なところに2次バグが発生した」という問題が出ると、テストで発見した不適合だけ修正していても「モグラ叩き」になり、品質は向上しないのだと気づきます。
ソフトウェア品質を向上させるために、設計方法、プログラミング手法、テスト方法、様々なツールについて学習する中で、ISO9126というソフトウェア品質評価に関する国際規格があることを知りました。
ISO9126では、品質モデルを構造的に定義しています。
概略は以下のとおりです。
| No. | 品質特性 | 内容 |
|---|---|---|
| 1 | 機能性（functionality） | 正確に機能が動作することに関する内容 |
| 2 | 信頼性（reliability） | 連続稼働や異常回復などに関する内容 |
| 3 | 使用性（usability） | 操作や運用方法に関する内容 |
| 4 | 効率性（efficiency） | ソフトウェアの性能に関する内容 |
| 5 | 保守性（maintainability） | 安定動作や問題が発生した場合の解析のしやすさに関する内容 |
| 6 | 可搬性（portability） | OSやハードウェアなどソフトウェアの開発および動作環境に関する内容 |
表1. ソフトウェア品質特性
ISO9126の考えは要求仕様作成フェーズ、設計フェーズ、プログラミングフェーズ、テストフェーズなど、様々なフェーズで利用できます。
このような規格に沿ってシステムテストの項目を作成し、テストを実施することで、ソフトウェア品質を記録に残すことが出来るのではないかと考えるようになりました。
私が8年前に実施していたシステムテストは、『ソフトウェア品質特性の「1．機能性」』確認だけを実施していたことになります。
ここで、最近の開発で導入したシステムテストの手法を紹介します。
ISO9126や様々な書籍をヒントにしているため、新しい技術ではありませんが、少しでも参考にしていただければと考えています。
ソフトウェアは要求仕様書→設計書→プログラム→テストという流れで開発します。
この場合に、テスト仕様書を作成するタイミングはプログラム作成の終盤に入ってから実施することが多いと思います。
理由は、開発を進める途中で仕様変更が入ることがあり、テスト仕様書を先行して作成すると、仕様変更部分があった場合にテスト仕様書へ反映する後戻り作業が発生するためです。
図1. 従来の進め方
図１のようにテストは、テスト仕様書に記載された内容のとおりソフトウェアが動作することを確認します。
ソフトウェアもテスト仕様書も、元は外部設計書であるため、外部設計書の品質が悪ければ、どちらの品質にも影響を与えます。
そこで、外部設計書の品質を確認するために、テスト仕様書の作成を先行し、外部設計書の問題があれば、それを早い段階でフィードバックする進め方としました。
図2. 新たな進め方
外部設計書からテスト仕様書を作成出来ない場合は、その部分の仕様が不明であるため、プログラムを作る時にも同じ不明点となります。
また、テスト項目を抽出する際に、ソフトウェア品質特性を意識していれば、外部設計書に記載されていない仕様を、プログラム作成前に抽出することも出来ます。
実施した結果、開発効率面では高い効果を出すことが出来ませんでした。
テスト仕様書を作成するため、早い段階で外部設計書の不明点を洗い出すことが出来ましたが、内部設計とテスト仕様書作成が並行しており、お互いに情報をフィードバック出来なかったことが原因だと考えています。
不明点を早期に洗い出せるメリットも見えているため、情報のフィードバックの仕組み作りが今後の解題となっています。
良かった点は、早い段階でテスト仕様書が出来たため、テスト内容の認識合わせをお客様と早い段階で実施出来た点です。
テスト仕様書はプログラムと違い、日本語で記述されているため、プログラム言語が分からないお客様とも、これから完成するソフトウェアの認識合わせをする成果物として有効に利用できることが分かりました。
テスト仕様書を作成する際に思いつきでテスト項目を抽出するのは効率的ではありません。
このため、ISO9126などを参考にしてテスト目的を分類化し、その分類ごとにテスト項目を抽出しました。
分類内容は以下のとおりです。
機能は要求仕様を見れば分かりますが、お客様がどのように利用するのか意外と分からない場合があります。
ここでテスト項目を抽出する際に、お客様から利用方法を具体的に聞き出すことで、設計不足など見つかる場合もあります。
上記のようにテスト目的を分類化した成果として、外部設計書に記載されていない内容や、顧客も想定していない問題を上記のテスト項目の抽出中に発見することが出来ました。
書籍などに書かれている一般な内容ですが、私が担当したシステムに導入した例を含めて紹介しました。
システムテストは、動作を確認するフェーズであり、システムテストを実施する時点のソフトウェア品質が悪ければ、良いテスト仕様書を導入しても意味がありません。
しかし、その品質を確認するシステムテストが甘ければ、市場へ不適合のあるソフトウェアを流出させることに繋がるため、良いテスト仕様書で確認することも重要なことです。
10年ほど前に、私が入社する前の1990年頃に開発されたソフトウェアを修正する機会がありました。
ソフト修正をする前に、仕様を把握する一環として当時のテスト仕様書を確認すると、通信テスト項目には「正しく通信すること・・・OK」と1文だけ記載されており驚いたことを覚えています。
このシステムで出荷後に不適合が発生した話は聞いたことがありませんでしたが、これではテストを本当に実施しているのか？と疑問が出てきます。
その一方で、私が数年前に担当したシステムではテスト項目が2万件程度あり、期間にして1ヶ月のシステムテストを実施したシステムでも、顧客から多くの不適合の指摘を受けたことがあり、品質とテストの関係については、自分にとって今でも課題です。
今回、紹介した方法が答えではなく、今後の勉強や経験で変わってくると思います。
しかし、システムテストの1つの方法として参考にしていただければと思います。
（T．O．）
関連ページへのリンク
関連するソフテックだより