保守におけるソフトウェア品質確保・管理に必要なことは何か€¦ · 企業システム開発の現状. 新規開発プロジェクト（スクラッチ開発）

Copyright © 2013 IT Holdings Corporation

企画本部事業推進部小田雅一

平成25年9月13日

保守におけるソフトウェア品質確保・管理に必要なことは何か

SQiP2013

Copyright © 2013 IT Holdings Corporation 1

企業システム開発の現状

新規開発プロジェクト

（スクラッチ開発）保守プロジェクト

（維持改修・機能改良）

サービス化（所有しない）

PaaS、パッケージ利用

IT投資の縮小・抑制

要因

再構築のリスク回避

IT投資の縮小・抑制

無理な改修による複雑化、品質低下

要因

既存資産の更なるブラックボックス化

保守によるシステム障害は、新規開発以上に企業や社会生活に大きなインパクトを与える

影響

SQiP2013


定量品質管理に関する新規と保守の違い

同じようなものを作る際、人は同じような過ちを起こすという前提から・・・

・どんな開発でも、1,000行作れば10個程度のバグが潜在する

・ならば、10,000行作れば、100個程度のバグ数が潜在するはずだ

新規開発では、こんな推測が成り立つ → バグ密度などの指標が有効

しかし、保守では・・・

・100行修正しても他の部分に全く影響しない場合もあれば、

・たった１行の修正が100箇所に影響する場合もある

100行修正すれば5個程度のバグが潜在する、などとは言えない

ソフトウエアの場合、品質を直接計測できる訳ではないが、

過去の類似プロジェクトにおけるバグ数を規模で正規化すれば比較もできる

SQiP2013


新規との違いから生じる疑問

そもそも過去の品質データを集めて指標にできるのだろうか？

品質状況を定量化すること自体が目的になっていないだろうか？

・目的は品質向上、障害撲滅だったはず

・ならば「どのように品質を定量的に計測しようか」ではなく、

保守の品質を悪化させる要因を洗い出し、

その要因への対応がどの程度出来ているかを定量化（見える化）する

という方が現実的ではないか

素朴な疑問

新規と同様に、「定量品質管理」と称してバグ密度やテスト密度を求め、

過去のプロジェクトと比較することに意味があるのだろうか？

SQiP2013


研究開発活動の立ち上げ

保守プロジェクトの特性を踏まえた品質確保、

そのための管理の方法について、

企業の壁を越えて知見を共有し、その成果を広く産業界に公開する

活動の目的は？

「保守において品質を低下させる要因は何なのか、

どうすればその要因を排除できる（悪影響を最小限にできる）のか、

保守における品質状況をどのように管理すればよいのか」

を考える

活動の内容は？

この趣旨に賛同する人達（主にIPA/SECで活動したメンバー）が集まり、

2013年4月に野中准教授を中心とする５名でスタート

SQiP2013


活動メンバー（現在）

東洋大学野中誠

（以下五十音順）

ＩＴホールディングス株式会社小田雅一

株式会社アグレックス青木克之

株式会社インテック相澤武

AJS株式会社前野智広

スミセイ情報システム株式会社小浜耕己

TIS株式会社力丸巌

日本ユニシス株式会社沖汐大志

富士通株式会社（調整中）

三菱電機インフォメーションシステムズ株式会社藤原良一

三菱電機インフォメーションシステムズ株式会社大谷晶子

USOL北海道株式会社服部克己

USOL北海道株式会社佐野浩

SQiP2013


保守作業の流れを知る

典型的な保守作業の流れを共有するところからスタート

改修依頼影響範囲の見極め見積実施判断

改修計画

お客様との調整

A

A ソース

の修正単体テスト

テスト項目

の抽出

結合・総合

テストリリース

通常は依頼票で受け取るが、その形式や受け渡し方法は様々

多くの場合、ドキュメントが信用できず、一応は見るが、ソースを追うケースが多い。

ツール等の利用は少なく、経験による属人的対応が多い。過去の経緯などは人の異動で失われがちで、気付く範囲で対応しているのが現状。

多くの場合、構成管理ツールを利用しているが、中にはファイルサーバで管理しているケースもある。

コードのブランチは、後のマージにリスクが大きいため、実施するケースは少ない。

全件テストは工数的にも難しく、滅多に行わない。改修した部分に関わるテスト項目を如何に抽出して確実にテストするかは保守プロジェクト共通の課題。

まずは、どこに品質を低下させる要因があるのかを知るところから・・・

「影響範囲の見極め」「必要なテスト項目の抽出」に的を絞って良いと結論付けた

SQiP2013


保守の品質を阻害する要因

影響範囲の見極めで、なぜ考慮漏れが起こるのか？

ドキュメント更新されていない（信用できない）きちんと書かれていない（説明不足、日本語の問題）

・そもそも開発から引継いだ全てのドキュメントが保守に必要なのか

・逆に、保守で独自に必要なドキュメントもあるのではないか

システムコーディングルールが守られていない

変数名などに一貫性がなく、ロジックを追えない

・改修で使われなくなった（絶対通らない）部分にどう対応するか・DB等を介して別システムに波及する影響をどう見極めるか

業務知識改修依頼の意図が正しく伝わらない

関連する業務処理の改修が漏れる

・保守に必要な業務知識とは何なのか

・相互理解（コミュニケーション）が出来ているかをどう評価するか

検討事項

検討事項

検討事項

出来て当然のことも、現実には限られた予算と納期の中で実現するのは難しい

SQiP2013


保守の品質を阻害するその他の要因

品質に影響するのは「ドキュメント」「システム」「業務知識」だけではない

しがらみ情報 →過去の経緯、システムの歴史、特別対応の理由・・・

事例１：中間ファイルが思わぬ部分（設計書に記載がない）で参照されている

影響：中間ファイルの変更が入った時に、参照部分の修正漏れが起こる

原因：追加したシステムで中間ファイルを使ったが、設計書を更新しなかった

事例２：画面表示に数秒間のDelayが入っているが、その理由が分からない

影響：関連部分を改修する場合、このDelayにどう対処したら良いか分からない

原因：キーパンチャーの入力が速すぎてデータチェック機能の起動が間に合わない

事例３：マスターにないコードを処理するロジックが組み込まれている

影響：このロジックの影響範囲が分からない

原因：設計を見直す余裕が無かったため、コードのパターンで逃げた

経緯を知らないことによる漏れは品質への影響大

SQiP2013


しがらみ情報とは何なのか

特別な理由があって対処した過去の経緯などで、

・必要な時に、必要な人の目に止まりにくい情報（記載すべき場所が特定できない）・特定の人の頭の中にだけあり、明文化されていない情報（暗黙知）・当時は常識的に共有できたことが、時間経過と共に常識的では無くなった情報

「しがらみ」とは、その情報が置かれている「状態」？それとも情報自体の「性質」？

状態：必要な人の目に止まる所定の場所に明記されれば「しがらみ」ではなくなる

性質：どこかに明記されている、いないに関わらず、常に「しがらみ」である

我々は「しがらみ」が何かを定義したい訳ではなく、

これらの情報が影響範囲の見極めにおいて漏れないようにすること！

どのような対処をしたのか何故そうしたのか

がセットになったもので、どちらが欠けても情報として不十分

（例）対処：画面表示直前にＤｅｌａｙを入れた

理由：チェック機能の起動が間に合わない

これを「過去の対応と根拠」と呼び、「しがらみ」という呼び方をやめる

SQiP2013


影響範囲見極めに必要な要素

重要なのは保守担当者が必要な情報を知り得るかどうか

業務知識

ドキュメント

システム

保守担当者

過去の対応と根拠

どう対応したのか

何故そうしたのか

記載場所（必要な時に保守担当者の目に止まる）が明確なものは所定のドキュメントに反映する

記載場所が定まらないものは別管理し、保守担当者が常にチェックできるようにする必要がある

ここをどうすればよいのか、

どのように「見える化」するのか、

について考えてゆく！

SQiP2013


保守品質を決める要因の関係

システム

ドキュメント（仕様書等）

業務知識（＋経験）

精度を更に上げるための仕組み

見極め精度がどの程度できているかを確認する指標

過去対応と根拠

過去の経緯を知ることで影響範囲の抽出漏れを防げる可能性がある

過去の改修に対して修正したプログラムの一覧

類似した改修での対象プログラム抽出漏れを防げる可能性がある

既存資産の利用状況

通らないロジックや、業務で利用されない部分は無視できる

保守に本当に必要なドキュメントとは？

開発から

引継ぐもの

保守独自に

作るもの

保守に必要な業務知識とは？

業務用語業務間

の関係

どのような状態が望ましいのか？

ソース

コード

ＤＢ

データ定義

SQiP2013


ご清聴ありがとうございました

・この活動について、是非、ご意見をお聞かせください

・ヒアリングさせて頂ける事例があればご紹介ください

SQiP2013

SQiP2013

Documents

保守におけるソフトウェア品質確保・管理に必要なことは何か€¦ · 企業システム開発の現状. 新規開発プロジェクト （スクラッチ開発）

保守におけるソフトウェア品質確保・管理に必要なことは何か€¦ · 企業システム開発の現状. 新規開発プロジェクト（スクラッチ開発）