ODC分析についてのよもやま話〜ソフトウェア不具合についてのあれやこれや・・・〜第9回（最終回／前編）「不具合の萌芽：なぜソフトウェア不具合が起こるのか？」

私がコンピュータメーカーに就いた頃すでに言われていた事として「中国4000年、ハードウェア200年、ソフトウェア ん十年?」という、悠久の歴史の中で18世紀後半から19世紀初頭にかけての第1次産業革命を機械化文明（ハードウェア）の始まりとすれば、それに比してソフトウェアの歴史の浅さを揶揄する表現として使われていました。

そもそもソフトウェアというものはいつ生まれたのか？

その手がかりとして次の資料*1（図表1）を参照します。

この資料は、私がIPA（情報処理推進機構）に海外動向研究員として勤務していた当時の資料です。その頃、盛り上がっていたIoT (Internet of Things) において、航空機・自動車など製造業分野で先進的で実用化が進んでいたIndustrie4.0構想をリードしていたドイツ フラウンホーファー研究所IESEから提供を受けた資料にあるものです。
ちなみに、「Industrie 4.0」はドイツ発祥の概念で、ドイツ語の正式表記です。英語では「Industry 4.0」と表記されます。

第4次産業革命 (Industrie4.0) を推進する研究集団の産業機械に対する見解では、18世紀後半からの水力機関や蒸気機関の発明による第1次産業革命を経て20世紀初頭の電力を使った電動機器による流れ作業を実現した大量生産時代を第2次産業革命としています。さらに機械による自動化（オートメーション化）を実現するため、人間の意のままに機械を運行・制御するための仕掛けが必要となり、PLC (Programable Logic Controller) いわゆる「プログラム」という概念の出現時期となる1970年代前後からを第3次産業革命としています。

ネットワークコンピューティング技術が進歩した現代、ネットワークを介してサイバー空間と物理的な機器群を融合して時間や地理的空間の枠を超えて連動・制御できるシステム空間 (Cyber-Physical Systems) を構築するのが第4次産業革命 (Industrie4.0) と位置付けられました。これは、2010年にドイツ主導によりEUが提唱したのが始まりとなります。

産業革命をマイルストーンとしたIndustrie4.0の産業機械の歴史観と並行して、もう一つの大きな技術潮流の見方としてコンピュータの誕生と発達史があります。

ENIAC（2026年9月18日09:00）『Wikipedia』。
https://ja.wikipedia.org/wiki/ENIAC

1946年米国では大砲の弾道計算の高速処理のためにペンシルベニア大学のエッカートとモークリー両博士が開発したENIAC (Electronic Numerical Integrator and Computer) が誕生しました。巨大な真空管の塊のような機械こそが人類最初の「コンピュータ」と称されています（図表2）。
ENIAC開発から現在まで、フォン・ノイマン博士が提唱したプログラム内蔵方式であるノイマン型コンピュータが進化を続けています。コンピュータの歴史に詳しい方々は既にご存知のことでしょう。

産業機械向けのPLCであれ、コンピュータの祖ENIACであれ、機械制御のためには人間の意思、意図を機械に伝える必要があります。そのために機械が認識できる機械語に変換してくれる言語が多く開発されました。それらを使って機械を動かすための命令群を「プログラム」と呼び、プログラムを作成する作業をプログラミングと呼ぶようになりました。私がこの業界に入った頃もそう呼ばれていました。

ではここで、「ソフトウェア」という言葉はどう定義されているかを見てみましょう。

Wikipediaによると、

「ソフトウェア（英: software）は、コンピュータ分野でハードウェア（物理的な機械）と対比される用語で、何らかの処理を行うプログラムや、さらには関連する文書などを指す。」

とあります。

他の用語辞典でも同じような表現で、物理的な機器を「ハードウェア」と呼び、ハードウェアを人間が意のままに動かすための命令を組込んだものが「プログラム」であり、その総称（？）を「ソフトウェア」と呼ぶ、というような説明までで「プログラム」と「ソフトウェア」とは明確な区別や定義はないようです。共通するのは「目に見えないもの」ということです。

人間が機械を制御する命令群である「プログラム」の必要性が先に生まれ（1946年以降）、後の世で数多く生み出された「プログラム」の総称を「ソフトウェア」と呼ぶようになったと解釈できます。

ここまでなぜ歴史話をしているかというと、次のことを考えてみたいからです。

機械（ハードウェア）はその生産技術の向上と生産プロセス改革により高精度で高品質な製品を機械が自動で生産できるようになりました。それを支えているのは、いつ誰が操作しても「同じものが均一な品質で生産できる」という生産技術の信頼性と確立された生産プロセスがあるからだと考えます。

ハードウェア製造の世界で使われる不良率（不良品数/製造数%あるいはppm）は、現代の水準で一般製品で3σ (0.3%未満)、航空機や医療分野では6σ (0.0003%未満) を目安としています。この生産技術はすごい数字に見えますが、利用者の安全・安心を確保する上で、製造現場での不良は即コストに直接影響するのでシビアにならざるを得ません。

この高品質を生み出す生産プロセスや、設計を含むハードウェアの開発プロセスが、モノづくりの基本とされてきた所以です。

では、ソフトウェアの生産技術は進歩したのでしょうか？

前述の通りコンピュータの聡明期、大砲の弾の弾道計算を手計算や計算尺でやっていたことをコンピュータに計算させるには、人間が弾道方程式をコンピュータが理解できるよう通訳（変換）する必要があり、その手段として「プログラム」が生み出されました。

人間の意図を機械であるコンピュータに伝えるには、プログラムという形にする作業が必要になるという「人間と機械の構図」の始まりと言えます。

以来、コンピュータの利用技術はわずか数十年で驚異的な発達を遂げ、世の中はプログラム＝ソフトウェアで動いていると言われるようになりました。

この「人間と機械の構図」は今でも変わっていないことからソフトウェアの生産技術は産業革命以前の人手に頼る家内制手工業の域を出ていないように見えます。
近年ソフトウェアを開発するためのツール（これもソフトウェアです）が多く出回り、またモデリングによるコード自動生成するツールもあります。いずれも人間の考えを機械語へ変換する過程でのツールであって、肝心な人間（設計者）の考えていることの正しさ、伝え方の正しさまでは今のところ・・・、疑問が残ります。

AIだと果たしてどうでしょうか？

その辺りに「なぜソフトウェア不具合が起こるのか？」という闇（「人間と機械の構図」の宿命と言ってもいいのでは？）があると筆者は考えています。

私見ではありますが、その闇には次の二つの要因があると考えています。
この二つに対して、「では、どうしたら良いのか？」今日明日何をすべきか？について私の知見・経験からくる4つの改善案（①〜④）を付記します。

要因の一つ目は、

ソフトウェア開発にハードウェア開発と同じプロセス思想を持ち込んでしまっている

開発プロセス通りに作れば「同じものが均一な品質でできる」という考えを前提に、属人化を排し、機械生産の如く作業指示をしておけば誰でも設計通りに同じ品質のものが作れるという妄信があると、こうなってしまいます。

ソフトウェア開発するのは、意志を持たず黙々と何時間も働き続ける機械ではなく、個々に意思を持ち、やる気という感情に左右され時に疲弊する、また悲しいかな個々の資質が万人均一でないわれわれ人間です。故に個々人の作業の質に差が生じ、そこから不具合が生まれてしまうのではないかと推察しています。

少しでもその差を平滑化するには、各企業、各組織での自助努力にはなりますが次のことが必要だと考えます。

① ソフトウェア開発プロセスでの個々の作業指示に対する作業完了基準の明確化と客観的検証

近年、ソフトウェアの巨大化と複雑化で開発体制の分業化が進み、設計、コーディング、テストをそれぞれ異なるチームで分担するようになりました。そうなると、人間の考え（要求や仕様）を他者に正しく伝達し、時に議論し理解してもらうためのコミュニケーション能力が必要となります。その難しさを克服する工夫や手法を持ち合わせないと、ますます不具合が生じやすくなっています。そこで次の工夫を推奨します。

② 要求、仕様の可視化とひも付けによる共通理解の確実化 = USDM　の活用

もう一つが最も厄介な要因である

ソフトウェアは「目に見えないもの」であるということ

機器の中でソフトウェアがどう動いて働いているかは目視できません。

それゆえ、こういうつもりで作りますという設計仕様書による表現、またこう機器に伝えましたというプログラム（ソースコード）の検証、そしてテストにてこれだけの動きを確認しましたという外からの観察結果、などで「目に見えないもの」の確かさを信じようとしています。

「見えていない」がために、見落としや漏れ以前に「気づいていない」ことに起因する不具合が残存してしまうと考えます。そのことに示唆を与えてくれるのが、これまで解説してきたODC分析です。

③ 「見えている事象」と「見えていない事象」への示唆 = ODC分析の活用

これらのことから、私はソフトウェア不具合の起こる可能性を次のように表現しています。

「品質の変容」とは、正確に言うと「品質表現の変容」です。

一件の要求品質であっても扱われる工程あるいは担当する人たちによって、それぞれが捉える品質表現は変化し、また品質メトリクスという形に変容していくことを指します。

人伝てに共有される要求品質は都度表現が変容することで、その解釈にギャップ（隙間、誤解、曲解など）が生じやすくなり、そのことが実装で不具合となって現れてしまうのではないかと考えています。あるいは全く考慮していなかったことを指摘されたりします。

次の一連の図でその顛末を図解します。

1)　まず、求められている要求品質は、開発工程の中で概ね次のように展開されます。（図表3）

2)　すると、求める要求品質の本質は一つであっても、設計工程、テスト工程でその要求表現を自分たちが理解できる言葉あるいはメトリクスという形に変容させ検証評価されます。

ここに、不具合の原因となる「品質表現の変容による理解のギャップ」が生じていると考えています。（図表4）

ギャップが生じる要因は、設計、テストそれぞれの工程で実装を前提に思考しているところにその芽が出ると考えます。つまり自分たちの知っていること、知っている技術で理解しようとし、その範囲で解決に努めようとすることで、視野が限定され、思考に枠ができてしまっているのです。

ここまで考えてくると、どうやら不具合の萌芽はこの辺りにありそうです。
「不具合の芽は設計で芽生える」ということです。この芽は設計者の思いだけではなかなか取り除けません。

そこで必要なのが基本に立ち戻った意識改革として、『「お客様（ユーザー）は、ソフトウェアを介して要求を満たす（操作する）」そのため「お客様（ユーザー）に受け入れられる」ことが第一』という認識が求められるのです。

視野の拡張として、設計、テストにおいて、お客様（ユーザー）の言葉の意味、真意、あるいは暗黙知を知って、お客様（ユーザー）の指向、思考、嗜好に対する品質観点を設計やテストに反映する必要があります。その観点が近年重要視されている「利用時品質」です。

④ 「利用時品質」の考慮を設計、テストに取り入れることが必要

図表3の「要求の展開」では、設計時に「利用時品質」の考慮を設計やテストに組込むことで、次の図表5のようになり、要求とのギャップが低減して、考慮不足、抜け、漏れ、手戻りが防げ、不具合の減少につながります。

以上のことを、さらに「個々にどう考え、どうすれば取り込めるか？」を体系的に標準化したのが、第8回の後半で触れたISO25000シリーズ (SQuaRE) です。

と、ここまで連載の最終回として「なぜソフトウェア不具合が起こるのか？」というテーマで、私のODC分析経験から派生して得た不具合に対する知見のよもやま話を述べさせてもらいました。
しかし、前述で付記した「では、どうしたら良いのか？」という改善案の解説が紙面の都合で今回に入りきらなくなりました。

本記事では以下、四つの改善提案をしました。

① ソフトウェア開発プロセスで作業指示に対する作業完了基準の明確化と客観的検証
② 要求、仕様の可視化とひも付けによる共通理解の確実化 = USDM
③ 「見えている事象」と「見えていない事象」への示唆 = ODC分析
④ 「利用時品質」の考慮を設計、テストに取り入れることが必要

これらのうち、この連載で初登場の②「USDM」と④「利用時品質」については是非説明したいと思います。

そこで、今回を前編、次回を後編として追加執筆しますので、次回後編もご愛読いただけるよう、よろしくお願いします。

参考文献：

*1) Industrie4.0 History (Fraunhofer IESE)

Orthogonal Defect Classification – A concept for In-process Measurement
Ram Chillarege, Inderpal S. Bhandari, Michael J. Halliday, etc., IBM Thomas J. Watson Research Center　
IEEE Transactions on Software Engineering Vol .18, No. 11, Nov. 1992ⒸIEEE

｢ソフトウェア不具合改善⼿法ODC分析」 〜 ⼯程の「質」を可視化する 〜
⽇科技連ODC分析研究会編 杉崎眞弘・佐々⽊⽅規
株式会社⽇科技連出版社 (ISBN978-4-8171-9713-9)