DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、システムの品質状況を「見える化」するための有効なツールである、品質マップをご紹介しました。多面性のある品質を「見える化」するために、いろいろな切り口で障害を分類することは、有効な品質向上策を打つために必要なことです。

障害を分類する切り口は、できるだけ「漏れなく、だぶりなく」、いわゆるMECE（ミーシーもしくはミッシー、Mutually Exclusive and Collectively Exhaustiveの略）となるようにしたいところですが、実際にはそんなに簡単じゃないですよね。。。（※１）

【　障害とは何か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
そもそも「障害」とは何でしょうか？「障害」と同じように使われる言葉に「故障」「欠陥」「不具合」「バグ」・・・などさまざまなものがあります。これらの言葉について、プロジェクトのステークフォルダー間で共通認識が無いと、あらぬ方向にプロジェクトが迷走する原因にもなりかねないので、ちゃんと定義する必要があります。それに、システム開発を行う組織として、障害数などの定量データを収集・蓄積して、継続的改善による組織成熟度の向上を目指すなら、プロジェクトごとに収集するデータの内容にばらつきが出ないよう、定義の明確化は必須です。（※２）

しかし今回のブログでは、「障害」の厳密な定義というよりも、実際に私がシステム開発プロジェクトに携わってきた中で気を付けた方が良いと感じてきたことをご紹介したいと思います。少し言い方を変えると、厳密な意味での「障害」という定義に収まらない事象や原因についても、システムの本番稼働の支障になるようなことは、限りなく減らすための活動が必要だという趣旨になります。

少し前のことですが、分子生物学者の福岡伸一氏が著した『生物と無生物のあいだ』という本が、サントリー芸術賞を受賞し話題となりました。実は、私は高校時代に生物の授業が好きで理系クラスにいながら、大学は文学部を選択して「理系と文系のあいだ」にいたのです。生物と無生物の境界というテーマにも、たいへん興味を持っており、この本を興味深く読ませてもらいました。（※３）

私の中では、生物と無生物の境界は明確であり、どのようにして無生物から生物が生まれたかということに興味があったのですが、意外に生物と無生物の境界はそんなに明確なものではなく、実は定義の問題でもあるんだと考えさせられたのです。

システム開発の現場でも、特にシステムテストやユーザテストにおいて、障害なのか非障害なのかをめぐり、発注側と受注側でもめるのを何度も目の当たりにしてきました。システム開発の現場では、どうしても瑕疵なのか瑕疵ではないのか、つまり、受注側の責任なのか、そうではないのかという政治的な争いになることが多かったため、そんな無駄な争いに時間を費やすよりも、お互いが協力してより良い方向に進むために時間を使った方が建設的だと考えてきました。

そのまま放っておくと本番業務に支障を与えかねない問題は、それが障害か非障害か、瑕疵かどうかに関係なく、発注側と受注側が協力して、知恵を出し合ってきちんと分析し、効率的に対処すべきだと思います。今回のブログでは、どんな事象や原因が「障害と非障害のあいだ」にあるのか、考察したいと思います。

【　データ不正は障害分析に含めなくて良いか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
最初は「データ不正」についてです。久々にプロジェクトマネジメント研修を受けてきたばかりの新人Ｐ子さんに登場してもらい、意見を聞いてみたいと思います。

＜新人Ｐ子さん＞　：　「うーん。データ不正だから、プログラムのロジックは間違ってなくて、データが間違ってるってことでしょ？どう考えてもバグとは言えないんじゃないかしら？」

＜ベテランＰＭのＭ男氏＞　：　「いったい何をくだらん質問しとるんじゃ？障害管理票に『データ不正』って分類があるんじゃから、さっさとそこに分類して品質分析の対象から除外するんじゃ！」

さあ、いかがでしょう？システムテストで、プログラムのロジックは間違っていなくて、プログラムが読み込んだデータが間違っていたために、思った通りの動作をしなかったという原因、事象です。Ｐ子さんもＭ男氏も、プログラムのバグでは無いので、品質分析の対象からははずすべきと主張しているようです。

では、ごく簡単な例を考えてみましょう。図１に示すPGM100というプログラムは、入力ファイルのＡという項目が”1”という値であった場合に、帳票を出力するというロジックになっています。（フローチャートは簡略化のため、少し不正確ですがご容赦ください）

図１の右側にあるテストケース表では、入力ファイルの1件目のデータはＡに”0”を設定しておくという条件になっており、「帳票は出力されない」という結果が期待値となります。入力ファイルの2件目と3件目のデータはＡに”1”を設定することで、「帳票が出力される」という結果が期待値です。

ところが、テストを実施した際、3件目のデータのＡには誤って”9”を設定してしまったために、テストケース表で期待した結果が得られず、テスト結果は不合格です。その原因は入力データの誤りだったため、「データ不正」として、プログラムの品質が悪いということには結びつかないので、品質分析の対象外とするのは納得がいきますね。

次に図２をご覧ください。図１と同じ要求仕様を実現しようとしていますが、将来的に帳票の出力条件が変わるかもしれないので、帳票制御情報というファイルを新たに設けて、プログラムを修正しなくても帳票出力条件を変えられるようにしています。

図２では、入力ファイルのデータは誤っていませんが、帳票制御情報の設定が誤っていたために、テストケース表で期待した結果が得られませんでした。これもPGM100というプログラムのロジックに誤りがありませんでしたので、「データ不正」として片づけてしまっても問題無いでしょうか？

もちろん、そんなことは無いですよね。このような障害がシステムテストで発見されたら、きちんと帳票制御情報が誤ってしまった原因を追究して、他の帳票制御情報にも誤りが無いか横展開してチェックするなど、それなりの品質向上策を打つ必要があります。

プログラムのロジックに責任を持つプログラマーの視点としては、帳票制御情報を準備するテスト担当者の問題だと意に介さないかもしれませんが、システムを利用した本番業務を円滑に稼働させるという視点に立てば、図２のケースもきちんと品質分析の対象に含める必要があることは明らかだと思いませんか？

【　障害と非障害のあいだ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「データ不正」の例と同じように、厳密な意味で障害とは切り分けられませんが、本番業務を円滑に稼働させるという目的のために、しっかりと品質分析の対象に含める必要があるものをいくつかあげてみます。

１．仕様変更

当ブログの　【第５３回】仕様変更と設計不良のグレーゾーンのさばき方　でもとりあげましたが、システムは設計書通りに動いているが、設計書が本来の要求とずれていたというケースです。このケースは仕様変更扱いとなることが多いと思いますが、仕様変更も品質分析の対象に含める必要があります。

仕様変更が発生した原因、たとえば要件定義が不十分だったのか、本当に突然の社内規定の改定などによる変更か、などをきちんと分析することで、横展開や再発防止を検討すべきかどうかを見定める必要があります。

仕様変更が多発する原因は、システムの企画や要件定義の超上流工程にあることが多いので、超上流工程のプロセスをどのように見直しするか、きちん分析する必要があるのです。

２．環境設定ミス

先ほど取り上げた「データ不正」と同じようなものに「環境設定ミス」というのもあります。大規模プロジェクトでは、インフラ構築と業務アプリの設計・開発を別体制で実施することが多く、アプリ担当の視点では「環境設定ミス」は品質分析の対象に含めないことが多いかもしれません。

しかし、性能などの非機能要件については、どこまでがアプリの責任範囲なのか、どこまでがインフラ環境設定で保証すべきなのかなどが不明確で、責任があいまいとなって、なかなか問題が解決しないことをよく見かけます。

システムテスト以降は、アプリケーションだけでなく、環境やデータの組合せなど、複合的な原因でシステム障害につながることも出てくるので、チーム間の垣根を越えた、品質分析と品質向上策の実施への協力体制が欠かせません。

３．操作ミス

いわゆるオペミス（オペレーションミスの略）も、その内容によっては、きちんと分析して、対策を講じる必要があるケースがあります。

たとえば、ユーザテストで、エンドユーザの入力ミスが多発してテストが進まないというときは、データを入力する画面の設計が悪く、入力ミスを誘発するようになっていないかを疑う必要があります。また、入力画面のチェック機能を少し強化するだけで、入力ミスに伴うエンドユーザの作業ロスを大幅に削減できるかもしれません。もちろんユーザテストだけではなく、本番業務の効率アップにもつながるはずです。

要件定義、外部設計を通して、がっちりと画面、帳票を固めてきたとしても、せっかくユーザテストを通じて、本番業務をより円滑に稼働させるための気づきを得られた場合には、ある程度柔軟に対応する余裕をもっていたいものです。もちろん、過度の変更取り込みによって、プロジェクト全体の品質、コスト、スケジュールに影響を与えるリスクがあるので、対応すべきかどうかは慎重に判断する必要がありますが。。。

「品質分析を行う際は、本番業務が円滑に進められるかという、少し広い視点で考えてみよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「MECE」『フリー百科事典　ウィキペディア日本語版』
2015年11月5日 (木) 10:41 utc https://ja.wikipedia.org/wiki/MECE

※２　障害やバグの定義については、以下文献が参考になります。
・独立行政法人情報処理推進機構（IPA）、ソフトウェア・エンジニアリング・センター（SEC）（2013）『組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]』
https://www.ipa.go.jp/sec/publish/tn12-005.html

※３　福岡伸一（2007）『生物と無生物のあいだ』講談社現代新書