SPI Japan 2023

設計ドキュメントから抽出した品質確保観点の活用によるソフトウェア品質の向上
テキストマイニング技術を活用した設計ドキュメント分析
2023/10/11
株式会社 日立製作所 デジタルシステム＆サービス
デジタルプラットフォーム事業部 ミドルウェア本部 生産技術部

内田智也(発表者)、香西周作© Hitachi, Ltd. 2023. All rights reserved.

はじめに自己紹介

内田 智也 (うちだ ともや)
• 所属：(株)日立製作所 デジタルプラットフォーム事業部
ミドルウェア本部 生産技術部※設立より一貫して社会インフラの基盤に使用される基幹ソフトウェア製品(メインフレーム用OS、DB、アプリケーションサーバ、運用管理製品等)を開発・保守している事業部• 経歴：➢ 分散トランザクション基盤製品の開発・保守➢ Enterprise Service Bus製品の開発・保守➢ アプリケーションサーバ製品の開発・保守➢ ソフトウェア開発環境の整備➢ 基幹製品の生産性向上・品質向上の推進

製品開発の現場経験を生かして、SEPGで活動中。

© Hitachi, Ltd. 2023. All rights reserved.

1

Contents
１. 課題と解決方針
２. 施策の仕組みと工夫点
３. 適用事例と効果
４. まとめ© Hitachi, Ltd. 2023. All rights reserved.

2

１. 課題と解決方針© Hitachi, Ltd. 2023. All rights reserved.

3

１. 課題と解決方針（１）背景⚫ 当事業部ではミッションクリティカルな社会IT基盤で使用されるソフトウェア製品の開発・保守を行っている。
⚫ 古いもので1970年代から長年エンハンスをし続けてきている。
⚫ 停止すると社会的にも大きな影響を与えることから、品質を維持することが重要。
金融システム公共システム産業システム・アプリケーション・サービス・アプリケーション・サービス・アプリケーション
・サービス

社会IT基盤
メインフレーム製品

データベース製品

システム運用管理製品
アプリケーションサーバ製品(1970年代～)© Hitachi, Ltd. 2023. All rights reserved.

4

１. 課題と解決方針（２）
品質維持の課題⚫ 品質を維持するために重要なことは、過去のノウハウやトラブル事例から導き出したテスト観点を設定してテストを実施すること。
⚫ テスト観点は熟練者や経験者の知見に依存する。
⚫ テスト観点表は長年かけて蓄積されて、量が膨大で利用が難しい。
再発防止
チェックリスト

テスト観点集テスト観点
1970年代～トラブル事例

現在引継ぎがうまく行われず、テスト観点が漏れてしまう© Hitachi, Ltd. 2023. All rights reserved.

5

１. 課題と解決方針（３）
課題の解決策⚫ テキストマイニング技術を使用して、開発時に作成されたドキュメントからテスト観点を機械的に抽出し、含まれているテスト観点をチェックする。
⚫ 抽出する観点は事業部共通のテスト観点事例集を基に設定。

開発ドキュメント
テキストマイニング
テスト観点事例集✓テスト観点A✓テスト観点B
テスト観点C：

テキストマイニングとは、文章に含まれる情報を取り出して分析する方法。
文章を用語や文節で区切り、それらの相関関係を確認したり、指定したルールに該当する内容の抽出が行える。

© Hitachi, Ltd. 2023. All rights reserved.

6

１. 課題と解決方針（４）
課題の解決策⚫ 仕様書およびテストドキュメントの双方から抽出したテスト観点を突き合わせることで、テスト観点の網羅性をチェック。

テスト作業

設計作業
確認

基本設計

確認

機能設計
詳細設計

仕様書
✓テスト観点A✓テスト観点B
テスト観点C
：

確認
実装

突合わせ

システムテスト
結合テスト
単体テスト

テストドキュメント
✓テスト観点A✓テスト観点B
テスト観点C：© Hitachi, Ltd. 2023. All rights reserved.

7

２. 施策の仕組みと工夫点© Hitachi, Ltd. 2023. All rights reserved.

8

２. 施策の仕組みと工夫点（１）
施策の全体像⚫ テキストマイニングにはKH Coderというフリーソフトを使用。
⚫ テスト観点の抽出を①～⑤の手順で実行。
⚫ 各手順における工夫点の内容を以降のスライドで説明。
②辞書の自動生成①コーディングルールの作成

工夫点２
製品固有の用語辞書

工夫点１

KH Coder

開発ドキュメント

コーディングルール
DB処理

抽
出実
行( ＳＱＬ or トランザクション ) and ・・・

権限に関する確認
アクセス権 or ( 実行権限 and ・・・結果出力

抽出結果

：

③開発ドキュメントの入力
工夫点３④テスト観点抽出の実行
工夫点４

テスト観点事例集⑤抽出結果のレポート出力
工夫点５© Hitachi, Ltd. 2023. All rights reserved.

9

２. 施策の仕組みと工夫点（２）
KH Coderの概要⚫ テキスト型（文章型）データを統計的に分析するためのフリーソフト⚫ 「テキストマイニング」 または「計量テキスト分析」と呼ばれる方法に対応⚫ URL：http://khcoder.net/

KH Coder
多変量解析によるデータ要約の機能作成した基準に従い言葉を分類する機能• 対応分析
• クラスター分析• 自己組織化マップ• 共企ネットワーク 等• コーディングルールを扱う機能 等

データ検索の機能• KWICコンコーダンス 等※参考文献[2]を参考に記載© Hitachi, Ltd. 2023. All rights reserved.

２. 施策の仕組みと工夫点（３）KH Coderのコーディングルール⚫ コーディングルールとは、注目したい独自のコンセプトを取り出すためのルール。
⚫ コーディングルールを作成してコンセプト(テスト観点)を抽出する。
⚫ テスト観点との関連が分かり易いテストドキュメントからのテスト観点抽出を通してルールを整備

文１：SQL/を/実行/して/結果/を/確認/する。
文２：ファイル/の/編集/には/管理者/の/権限/を/必要/とする。
形態素解析
コーディングルール
コンセプト(テスト観点)
DB処理
ＳＱＬ or トランザクション or ・・・

論理式

権限に関する確認( ファイル or フォルダ or ・・・ ) and 権限 ・・・

文１

DB処理のテスト観点あり

文２

権限に関する確認のテスト観点あり© Hitachi, Ltd. 2023. All rights reserved.

11

２. 施策の仕組みと工夫点（４）工夫点１ 過去ノウハウ・トラブル事例も含めたコーディングルール作成⚫ 検査部門が纏めている事業部共通のテスト観点事例集を基にしてコーディングルールを作成。
⚫ テスト観点だけでなく過去ノウハウやトラブル事例から抽出した用語もコーディングルールに含めることで、幅広い用語をカバー。
KH Coder

テスト観点過去のノウハウ
過去のトラブル事例

テスト観点

：

:

：

コーディングルール

大分類

中分類

：
リソース管理：資源効率性（ＣＰＵ・メモリ・ディスク等）

タイミング処理

：

テスト観点

：
ＣＰＵ利用率が妥当であることを確認すること
無駄に領域を使用しすぎていないかを確認すること
メモリ使用量が妥当であるかを確認すること
資源のリークファイル操作時に不当に資源が増加しないこと。
ＯＳ資源を使用する場合は、生成・消滅のタイミングを十分に検証したか。
処理の順番が保証されているかを確認すること
自プログラム製品の資源利用状況確認
プロセスＩＤを保持して他製品のプロセスをｋｉｌｌしないことを確認すること
ポート番号が重複しないことを確認すること
局所的なタイミングの確認（システム全体） システム全体での局所的なタイミングを考慮した項目を設定すること
処理中にＯＳのシャットダウンやサービス停止要求がきても異常にならない
局所的なタイミングの確認（ＧＵＩ操作）
複数同時に画面描画を行うテストを実施すること。
局所的なタイミングの確認（起動・停止）
ＧＵＩ画面の起動・停止が重なる場合の項目を設定すること：：© Hitachi, Ltd. 2023. All rights reserved.

12

２. 施策の仕組みと工夫点（５）
工夫点２ 製品固有の用語辞書の自動生成⚫ 抽出対象の開発ドキュメントから製品固有の用語辞書を自動生成してKH Coderに登録し、誤検知を防止。
➢ 用語辞書なし
機能名/Data /Management /Console

抽
出実行

KH Coder
ログ・トレース
ログ or Console or ・・・

結果
出
力ログ・トレース
テスト観点あり

結果
出
力ログ・トレース
テスト観点なし➢ 用語辞書あり
製品固有の用語辞書“Data Management Console”
自動生成

機能名
/Data Management Console/

抽
出実
行

KH Coder
ログ・トレース
ログ or Console or ・・・© Hitachi, Ltd. 2023. All rights reserved.

13

２. 施策の仕組みと工夫点（６）

工夫点３ 文書の細分化⚫ 観点の抽出元を特定できるように、抽出対象の開発ドキュメントの文章の細分化を行う。
⚫ 仕様書は章/節/項の単位、テストドキュメントはテスト条件-結果の単位に、それぞれ分割してKH Coderに入力する。

仕様書
1章. --------

テストドキュメント
KH Coder

テスト条件-結果A.

KH Coder1.1節 -------1.1.1項 --------------------

テスト条件-結果B.
テスト条件-結果C.

© Hitachi, Ltd. 2023. All rights reserved.

14

２. 施策の仕組みと工夫点（７）
工夫点４ 文書に合わせたコーディングルールの適用設定⚫ 誤った抽出を防ぐため、文書に合わせてコーディングルールの適用設定をする。
⚫ 仕様書は文(文章を構成する各文)の単位、テストドキュメントはテスト条件結果の単位に適用して、関係のある内容から正しく抽出されるようにする。
資源リーク

資源状況確認(メモリ and 解放)(メモリ and 所要量)

仕様書

テストドキュメント

１．○〇〇機能
このプロセスはメモリの状態を管理する。
・・・。ファイルの更新が完了すると排他制御によりロックを解放する。・・・
テスト観点あり（誤検知）
１．○〇〇機能
このプロセスはメモリの状態を管理する。
・・・。ファイルの更新が完了すると排他制御によりロックを解放する。・・・
テスト観点なし○〇〇機能
テスト条件：実行時のメモリの状態を表示
テスト結果：所要量はXバイト
テスト観点なし（未検知）○〇〇機能テスト条件：実行時のメモリの状態を表示
テスト結果：所要量はXバイト
テスト観点あり© Hitachi, Ltd. 2023. All rights reserved.

15

２. 施策の仕組みと工夫点（８）
工夫点５ 抽出結果を製品開発者へ直接説明⚫ 結果の有効活用・施策の定着化のため、抽出結果を製品開発者へ直接説明をする。
⚫ 主な説明内容は、テスト観点の全体傾向、突き合わせの結果、不足している観点、前バージョンの抽出結果との比較など。
主な説明内容製品A テスト観点抽出結果
観点・・・＊008-インタフェース＊009-開始＿終了＊010-機能確認＊011-処理方式＊012-限界・境界条件＊013-異常処理＊014-適用範囲内の詳細確認＊015-ＤＢ処理＊016-権限に関する確認＊017-国際化プログラミング＊018-大量データの入出力
・・・

開発項目
・・・
10.0%
0.0%
80.0%
0.0%
40.0%
30.0%
0.0%
20.0%
40.0%
0.0%
0.0%
・・・

１．テスト観点の全体傾向
２．仕様書とテストドキュメントの＋観点突き合わせ結果
３．不足している観点
４．前回バージョンの抽出結果との比較© Hitachi, Ltd. 2023. All rights reserved.

16

２. 施策の仕組みと工夫点（９）テスト観点抽出結果のレポート出力例
テスト観点の項目

テスト観点の抽出結果
開発項目

テスト観点あり

テスト観点なし© Hitachi, Ltd. 2023. All rights reserved.

17

２. 施策の仕組みと工夫点（１０）観点の抽出精度⚫ 機械抽出を最初に実行して抽出される精度は90%以上であり、残りは対策を行い機械抽出を再実行して100%にする。
⚫ 対策内容➢ 誤検知防止のため製品固有の用語辞書を追加➢ 必要に応じてコーディングルール自体の見直しも実施(誤検知の要因となる用語の削除、同義語や類義語等の追加、論理式の見直し等)
機械抽出の最初の実行結果
仕様書
抽出する
全テスト観点数
76個

テストドキュメント

正しく抽出できた

71個(93.4%)

69個(90.8%)

正しく抽出できなかった

5個( 6.6%)

7個( 9.2%)

対策を行い、機械抽出を再実行して100%にする© Hitachi, Ltd. 2023. All rights reserved.

18

３. 適用事例と効果© Hitachi, Ltd. 2023. All rights reserved.

19

３. 適用事例と効果（１）適用事例⚫ 事業部の主要製品に施策適用を実施。
⚫ 適用前は、過去のテスト観点資料を参考にしつつ、開発者が開発ドキュメントを作成して、熟練者・経験者がチェック。
⚫ 適用後は、作成した開発ドキュメントを機械的にチェックして、必要なテスト観点が網羅されているかを確認。
[適用前]

[適用後]

過去のテスト観点資料

過去のテスト観点資料

作成
修正

開発者

テスト観点を取出し
チェックルール化

開発
ドキュメント開発
ドキュメント

作成
チェック

熟練者・経験者

修正

KH Coder

チェック
機械化

開発者

© Hitachi, Ltd. 2023. All rights reserved.

20

３. 適用事例と効果（２）適用事例⚫ 適用した製品の開発ドキュメントに対してテスト観点漏れのチェックを実施。
⚫ 仕様書とテストドキュメントのテスト観点抽出結果の突合せでテスト観点漏れを発見。
製品

アプリケーションサーバ製品A バージョンX

開発項目

４個

開発ドキュメント

機能仕様書 （Wordファイル：約70ページ）
結合テスト項目 （テスト条件-結果 約140個）

適用方法

・開発ドキュメントから、開発バージョンの内容だけを取り出し。
(前回バージョンとの差分を取得)
・取り出した開発バージョンの内容を、４つの開発項目に分類。

適用結果
開発ドキュメントとテストドキュメントのテスト観点の突合せを実施し、開発項目の１つで、２件のテスト観点漏れを発見。
➢ 製品の一部で障害が発生した場合の対処に関する確認➢ 同一資源への操作を繰り返した場合の動作確認
開発者にフィードバックして対策を実施。 © Hitachi, Ltd. 2023. All rights reserved.

21

３. 適用事例と効果（３）
施策の適用効果’21年度/上期～’23年度/上期までに、施策適用した主要製品全体で、テスト観点漏れ発見 １製品あたり平均２.３件

製品開発者からの声作成した開発ドキュメントの内容がどういうテスト観点に分類されるか、客観的に分かったのが良かった。
開発者
具体的なテスト観点が整理されていて、テスト観点に抜けがないか確認するのに有用であると感じた。

開発者© Hitachi, Ltd. 2023. All rights reserved.

22

３. 適用事例と効果（４）
開発者からの要望・意見⚫ 新たなテスト漏れ事例の検出の要望、および不足しているテスト観点の指摘に関する意見があった。
テスト漏れの具体事例があり、それを施策で検出できるようにしてほしい。
開発者⇒具体事例を調査して必要な観点項目（コーディングルール）を追加。
事業部全体の基準に沿った画一的な指摘だけでなく、開発内容を加味したチェックをしてほしい

開発者⇒開発ドキュメントを元に開発内容を考慮して必要なテスト観点を選択・提示するように改善。将来的に、この結果を蓄積して必要なテスト観点の選択・提示を自動化できるようにする＜製品Xの抽出結果＞「2038年問題対応」 テスト観点B、テスト観点C＜製品Yの抽出結果＞「2038年問題対応」 テスト観点A、テスト観点B「2038年問題対応」
製品共通で必要なテスト観点を蓄積

テスト観点
Ａ

要否不要

Ｂ

必要

Ｃ不要

© Hitachi, Ltd. 2023. All rights reserved.

23

３. 適用事例と効果（５）
施策適用した製品件数⚫ 事業部の主要製品に’21年度/上期から施策適用を開始。
⚫ １度適用したプロジェクトの継続適用があり、新規適用するプロジェクトも増えている。
⚫ 製品開発者と連携して施策内容を充実させて件数を増やしていく。

© Hitachi, Ltd. 2023. All rights reserved.

24

４. まとめ© Hitachi, Ltd. 2023. All rights reserved.

25

４. まとめ取り組みの成果⚫ 実際の製品開発に施策を適用して、課題に対する効果が得られた。
⚫ 開発者からのフィードバックをもらい、今後の予定に繋がった。
⚫ 適用製品の件数が継続・増加しており、ニーズが高いことが分かった。

今後の方針
今後も熟練者や経験者の退職・事業シフトが進むため、継続して引継ぎの課題に取り組んでいく必要がある。
今回の成果により、蓄積された過去の知見を抽出して機械的に活用していくことは有効であることが分かった。

今後は、カバーできていない実装作業について、生成ＡＩにソースコードを入力して解説文を出力し、今回の仕組みで観点を抽出する。
ソースコード
生成ＡＩ

ソースコードの解説文

テスト観点© Hitachi, Ltd. 2023. All rights reserved.

26

参考文献
[1] 香西 周作、内田 智也、北川 福太郎 (2022). 設計資産分析による大規模ソフトウェアのエンハンス作業効率化～熟練者/前任者ナレッジの活用～ SPI
Japan 2022
https://www.jaspic.org/event/2022/SPIJapan/session1B/1B2_004.pdf[2] 樋口 耕一 (2020). 社会調査のための計量テキスト分析 第2版 ナカニシヤ
出版[3] 保田 勝道 (1995). ソフトウェア品質保証の考え方と実際 日科技連出版© Hitachi, Ltd. 2023. All rights reserved.

27

END
設計ドキュメントから抽出した品質確保観点の活用によるソフトウェア品質の向上
テキストマイニング技術を活用した設計ドキュメント分析

2023/10/11
株式会社 日立製作所 デジタルシステム＆サービス
デジタルプラットフォーム事業部 ミドルウェア本部 生産技術部

内田智也(発表者)、香西周作© Hitachi, Ltd. 2023. All rights reserved.

28