ソフトウェア技術者のためのバグ百科事典（6）不信感を生む“文書作成のバグ”：山浦恒央の“くみこみ”な話（127）（2/3 ページ）

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第6回は、ソフトウェア開発業務の中で圧倒的に大きな比率を占める「文書作成」における間違い、「文書作成のバグ」を取り上げます。プログラムの動作には影響しませんが、その文書を読んだユーザーに不信感を与えかねない危険なバグなのです。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

4．文書作成のバグのケーススタディー

　文書作成のバグは皆さんも多くを経験していると思います。筆者が作った文書作成のバグのケーススタディーを以下に示します。

4.1 英単語の間違い

※写真はイメージです

　日本語を第一言語とする日本人は、ちょっとした英単語を間違えることが多くあります。

　かなり前の話なのですが、筆者が品質関連の英語のプレゼンテーション資料を作成していて、「Deadrock（デッドロック）」という単語を使いました^※3）。それを見たエンジニアから、「この単語は、『Deadlock』ではないですか。rockだと音楽になってしまいますね」と笑われ、かなり恥ずかしい思いをしました。学校を卒業して就職すると、一部の人を除き英語との関わり合いが少なくなります。ソフトウェアエンジニアの場合、変数名や単語のスペル間違いをよく見掛けます。

※3）2つ以上のスレッドやプロセスなどがお互いの動作終了を待つ状態（いわゆる「待ち待ち」）となり、先に進めない現象です。このバグを作ると叱られます。

4.2 変換ミス

　ワードプロセッサで文書を作成する場合、変換ミスをすることがあります。例えば、「128バイトの領域を動的に確保し、データを送信後、すぐに開放する」という文面の場合、「メモリを開放する」とも言えなくはないのですが、「メモリの解放」と書くのが一般的です。変換ミスは、仕様書を書いている最中は気付きませんが、読み直すと間違って変換していることに気付きます。

4.3 図・表番号が入っていない

　よくやってしまう例を図1に示します。

図1　三角形判定プログラムの図番号がない

　図1には、三角形判定プログラムのモジュール構造図が描いてあります。ただし、「三角形判定プログラムのモジュール構造図を図1-1に示す」と書いてあるのですが、参照する図番号が振ってありません。この例では、すぐ下の図と分かりますが、図や表が離れた場所にあると、途端に判別できなくなります。

4.4 状態遷移図の線が抜けている

　仕様の記述方法はさまざまありますが、組み込み系開発で多く使う記述方法が状態遷移図です。炊飯器、自動車、エレベーター、自動販売機など、状態遷移図や状態遷移表を作成すると、機能や動作を簡潔に表記できます。

　状態遷移図を記述することは大変有効なのですが、状態遷移図の遷移先を書き忘れることがあります。図2に例を示します。

図2　音楽プレイヤーの状態遷移図、状態遷移表の例

　図2は、音楽プレイヤーの状態遷移図、状態遷移表の例を示したものです。表2.1の一時停止モード時の停止指令を見ると、アイドルモードに遷移するはずが、図2.1には矢印が存在しません。通常の音楽プレイヤーならば、一時停止モードで停止指令を出すと、アイドルモードに戻るはずですが、線の引き忘れかどうか仕様定義者に確認する必要があります。ちなみに、例題の音楽プレイヤー自体の停止処理は記載していません。