ソフトウェア品質とスイスチーズモデル

こんにちは。
この記事は、グロースエクスパートナーズ Advent Calendar 2023 14日目の記事です。

私はソフトウェア開発の中で、品質向上というのを最も困難な挑戦であると考えている。
華々しくもなく泥臭く厄介で面倒くさく面白味もない(個人の感想です)。
しかしとても挑戦し甲斐がある困難さだ。

今回はそのソフトウェア品質を、スイスチーズモデルをもと書きたいと思う。
ソフトウェア品質対策をスイスチーズモデルを使って語ることは、別に目新しいことではないが、私の視点で書いてみる。

スイスチーズモデルとソフトウェア品質

スイスチーズモデルとは

スイスチーズモデルとは、組織事故を検証するにあたり、それがどのように発生しどう防ぐかを検証するため、イギリスの心理学者ジェームズ・リーズン氏が提唱したモデルである。
航空や医療安全等、事故の発生が重大な損害を発生させる分野で利用される。

事故を防止するため、いくつもの防護策が立てられる。
それぞれの防護策は決して完全ではなく、まるでスイスチーズのように穴があいている。
そのすべての穴を通過したエラーが、事故として損害を発生させる。
という考え方である。

組織事故におけるスイスチーズモデル

組織事故とは組織全体・社会に影響が及ぶ重大な事故のことである。
組織事故の対策を考える際、スイスチーズモデルを元に、発生し得る穴の分析しその防護策を検討する。その分析・検討の範囲は幅広い。

事故の原因はヒューマンエラーに留めたりはせず、その対策は直接的な対策に限らない。そのヒューマンエラーが発生した背景を考え、文化の醸成や組織作りにも言及される。

ソフトウェア品質への適用

これをソフトウェア品質に適用して考える。
我々がバグを運用に流出させてしまったとき、数多くの防護策の穴を抜けてしまっているはずである。
にも拘わらず、ヒューマンエラーを原因とし、たった一つの再発防止策が打たれることが多いように感じる。

ソフトウェア品質を考える際も、幅広く分析と改善を行うべきと考える。

以降の記事

本記事の主旨は以上となる。
以降は、どのような観点あるか考えていく。

• 開発各工程で積み重ねるチーズ
  開発工程での防護策について
• リリース後に向けて
  バグを流出させないという観点だけではなく、流出してしまったときの考慮
• 追加したチーズが品質を下げる
  必要と考え実施した品質向上対策が、逆に品質を下げ得るケースについて

以下2項目は、ポエム要素が強くなるため別記事とする。

• 文化と品質
  チーム・組織の文化が、ソフトウェアに影響を与えると考える例

• 組織に空く穴
  私が見た重要な防護策に空く組織の穴について

開発各工程で積み重ねるチーズ

開発上流・下流その各工程で行われる活動。作成されるアウトプット。
それを効果的に、より良く行うための手法。
それぞれの工程の検証作業。レビュー,各試験。

これらはそれぞれ別の形のチーズであり、
どれを行えば、どれを行わなくてよいというものではない。
数多く重ねることで品質を保つことができる。

ソフトウェア品質を語るとき大抵ここが厚く語られるが、他に書きたいことが山ほどあるので割愛する。

リリース後に向けて

スイスチーズモデルをソフトウェア品質に適用して考えるのであれば、
「リリース前までに十分な品質を積み上げるので、運用にバグが流出したときのことを想定する必要はない」
とはならないだろう。運用にバグが流出したとき、如何にユーザーの不利益を減らすかの観点も重要になると考える。

バグ影響の限定化・軽減

・ある異常が発生したとして、その中で最もユーザー利益となる動作・不利益を減らす動作をするか。

正常状態への復帰

・異常系における自動復旧制御の実装
・ユーザーへの復旧操作方法の提示
・サービス復旧手順の確立と文書化

不具合の早期・事前検出

・システム監視,リソース監視等

バグ発覚から修正までの期間の短縮

・ログ・統計情報の取得・蓄積
・問題発生時、蓄積された情報の回収手段確立
・サポートと開発チームの連携体制作り

ユーザーが受けた不利益の補填　

ソーシャルゲームでは何か不具合があったとき、お詫びと称してゲーム内通貨・アイテムをユーザーに配布する文化(?)がある。
そのためバグが発覚するとユーザーが喜ぶという不思議な光景が見られる(ただし限度はある)
これもバグによるユーザーの不利益の低減だろう。

自らが生み出せるデータで、ユーザーに利益を提供できるソーシャルゲームならではであり、他のソフトウェアサービスでは不可能に思える。
こういう別の観点の発想も大切ではないかな。

追加したチーズが品質を下げる

我々は品質への対策（＝チーズ）を追加するとき、良かれと思って必要不可欠だと考えて追加する。しかしそれ自体が品質の低下を招くことを考慮することは重要だと考える。

限られたリソースの中で

ここでは人的・物的・金銭的・時間的その他必要とされる全てをリソースと表現します。
チーズを増やすには当然ながらリソースが必要となる。
リソースをかけることは、最終的にユーザーへの負担となる。まずそれ自体が不利益なのだ。

リソースをかけずチーズを増やそうとする行為は最悪である。
間違いなく他のチーズがが薄くなり別の穴が開く。
正論で語れば「やらねばならぬ」ことは山ほどあり、その全てをやるべきである。
だがそうであったとしても現実のリソース合わせて取捨選択しなくてはならない。

誤った安心感

他の工程でもバグを検出し得るということが、誤った安心感を生むことがある。

次の工程で確認するからヨシ!
前の工程で確認されているからヨシ！
味のあるデザインのネコが指差し確認しているあの絵を貼りたかったが、著作権関連が不安だったので止めた。

ダブルチェック・トリプルチェック行う全ての作業者が、他がチェックしているから大丈夫だろうとOKを出してしまう。工事現場・工場のあるあるネタのようだ。

ソフトウェア開発と比較し、直接人命にかかわるような場面で発生するのであるから、
ソフトウェア開発でも発生すると考えるのが自然だと思う。
品質を保つには一部を行えばよいのではなく、全てをしっかり行うことで品質が保たれると強く認識することが大切であると考える。

作業の複雑化によるヒューマンエラーの誘発

チーズを積みすぎた手順は複雑化し、必ず作業者のミスを誘発する。
何かの対策を打つとき可能な限り作業者に負荷のかからない方法が望ましい。
「作業者のキャパシティを超える状況がヒューマンエラーを生む」
というのが組織事故防止の考え方のようだ。

一つヒューマンエラーが発生する毎に、まるで罰ゲームかのように面倒な確認手順が増えるというのはよく見られると思う。
対策案として直接的で容易であるし、ある程度はそれで良いかもしれない。
ただ、一つの工程で何度もヒューマンエラーが発生する場合、確認手順を積みまくることをやめ、開発のシステムが悪いことを疑った方が良いだろう。
作業者の負荷を軽減し、そもそもヒューマンエラーが発生しない・発生しても問題ないシステムを作れないだろうか。
我々はソフトウェア開発者なのだから、システムを作り手順を自動化し、楽して効果あげることは得意分野であるはず。

終わりに - 何をすれば品質が上がりますか -

以前、「何をすれば品質が上がりますか」と問われたことがある。
私は「全てをやるしかない」と返した。
望まれた回答ではなかったと思う。しかし間違った回答はしてはいないと考えている。

スイスチーズモデルで考えるのであれば、この「全て」は多岐にわたる。
ここで書いたようなことは、その中の極々一部だろう。

我々が行う品質への対策一つ一つは完全には程遠い。
穴だらけのスイスチーズしか持ち得ない。
ならば地道に一つ一つ重ねるしかないだろう。