ＳＷ品質まとめ④品質の問題

ここでは「不良」「故障」「障害」「バグ」、etc.…といった事象分類の話ではなく、さまざまな呼び方を統合したうえで、開発フェーズのなかで想定しない事象によってスケジュールに支障をきたすような要因のことを、まとめて”問題”と呼びます。

不良であっても、故障であっても、エラーであっても、要は開発そのものが進められない、あるいはソフトウェアの利用が進められないといったものはすべて「問題」なわけですね。

問題は、解かねばなりません。
子供の頃からそうだったはずです。

ランダム故障と決定論的故障

まずは、問題そのものを読み解きます。

システムを「仕組み」「ハードウェア」「ソフトウェア」などすべてを包括したものとした場合、共通的に呼ばれる『事象』には大別して２種類存在します。

これは、ISO 26262などの自動車の機能安全と呼ばれる規格の中でよく使われていたような気がしますが、源流がどこかまでは私も把握していません。別に歴史がどうってのは関係ないので。要するに、この分類が「問題」の根本を説明するのに非常に都合がいいというだけです。

原則として、ソフトウェア開発上に発生する問題はすべて”決定論的故障（つまり、人の手によってある意味意図的に組み込まれた故障）”であり、問題と原因の因果関係が確実に特定できるようになっているものです。

ランダム故障のように「使っていたら摩耗して、老朽して壊れた」という事態には決してなりません。「人が組み込んだから、組み込んだとおりに忠実に実行し、その内容や結果が人から見ると故障に見える」だけなのです。言い換えるなら"人災"なわけですね。

このことから言えるのは、

　"人災"である以上、人の営みを紐解けば原因が特定できる

ということです。

問題の原因

決定論的故障と分類されてはいるものの、そうなった原因にも「技術的要因」と「動機的要因」があります。人が行ったものであるからこそ『動機的』な原因も必ず存在するわけです。

「〇〇の方がいいと思ったから」
「〇〇をすっかり忘れていたから」
「ルールの〇〇を△△と誤解していたから」

と言った具合です。
これらの動機自体が悪いなんてことは絶対にありません。原因は、そういう動機でも実行できるよう曖昧なままにしている仕組み側にあります。仕組みを改め、予期せぬ思考や判断に至らぬように改善すればいいのです。

技術的要因とは、技術、仕組み、環境および情報、またルール、規定などハードスキルを介した要因特性を指します。動機的要因とは先述の通り、仕組みやルールで定められていない部分（思い込みや認識齟齬、人間の柔軟な対応）などソフトスキルによって生じる要因特性を指します。これらは、一方のみが原因で問題を起こすのではなく、

　問題には常にそれぞれの側面が存在する

ことを意味します。

ここから先はファイルにて。
（である調→ですます調に変えるのが面倒なので(:3_ヽ)_）

4. 問題
　4.1 ランダム故障と決定論的故障
　4.2 問題の原因
　　4.2.1. 技術的要因
　　4.2.2. 動機的要因
　4.3 問題のスコープ
　4.4 問題のレベル
　　4.4.1. 混入不良レベル
　　4.4.2. 発生防止レベル

あえて「問題解決」をここに記載していないのは、具体的な解決方法を書き出すとキリがない…という点と、その問題解決をマネジメント上で正しく運用するための手順やルールについては、すでに別途書き終えてしまっているからです。

問題解決管理｜Takashi Suda / かんた｜note

「【問題解決管理】」と書かれたタイトル群がこれにあたります。現時点(’20/08/16)では有償化していませんが、こちらもマニュアルは別途用意しているので、各章ごとにちりばめて、いつか有償化するかもしれません。