Japanese Translation:

2022 年 1 月 20 日発表（2023 年 3 月 10 日更新）され、真のソフトウェア品質は単に誤りのない実行だけでなく、プロセスをエレガントに遂行し、システムが検出された時よりもさらに頑健な状態を残すことで定義される。ソフトウェアは世界の変化に合わせて無期に進化させねばならない純粋な概念であり、1976 年以来継続的に進化し続けている Emacs のように例示される一方、ZeroMQ や一部の Unix ユーティリティのように「完成性」を目指すツールとは対照的である。しかしながら、急速な変化と遅延するフィードバックループのため、孤立した「ベストプラクティス」や英雄行為では不十分であり、持続的な成功には継続的な進化を受容するレジリエントな文化が不可欠である。

従来の直線的なワークフロー（分析→製品→UX/設計→開発→"QA"→プロダクション）は、リスクを分析段階に前倒しにし、エラー検出をプロダクションまで遅らせる。その結果、クラッシュ、障害、構成エラー、データ漏洩、スケーリング失敗、その他多くの問題が発生する傾向がある。これらは単なる単純なバグではなく、蓄積されてきた角の切りという症状であり、市場のフィードバックループが遅延していたり不連続だったりすれば、バッチサイズに関係なく技術的負債として累加され、 ганゲレンのように時間とともに複合化していくものである。機械学習と AI の加速はさらに複雑性を高め、世界を察知し他者を動的に改訂するアルゴリズムを持たなければ、人間がソフトウェアを十分に速く見直すことは不可能となる。

品質破壊の手法には、テストを QA と誤認すること、QA を経験最少の人材に割り当てること、期限を優先して品質を軽視すること、構造的エラーの責任を個々に追及すること、部門間の競争、そして有毒な CEO を採用することが含まれる。運用上の崩壊を防ぐためには、深層組織的適応が必要であり、ステークホルダーと共進化するように組織全体にわたるシステムと文化を設計・構築するのではなく、一度限りのトリックに依存しないことである。最初のスキルは建設的に苦難することを学ぶことであり、これには『システムズインキング』、『No Silver Bullet（銀の弾丸などない）』、『神話の人月』、『ハイアウトプットマネジメント』、ジェーン・キム氏の『The Idealcast』をはじめ、システム、ソフトウェア複雑性、失敗、コラボレーション、セルフマネジメント、そして実用的な哲学を扱うその他のリソースが支援する。

千切れ傷による死を避ける：ソフトウェア品質の本質と実践

はじめに

本稿は『二輪車の維持』のような重厚な禅問答ではありません。**ソフトウェア製品の「品質」**について、そのプロセス体験を通じて思索を試みるものです。

万物は生れ、変化し、死にます。「良質な」状態とは、プロセスを優雅に完遂し、より良い状態で残すことに他なりません。

生命（生きる）のプロセスと、衰退（死ぬ）のプロセスは同時に進行します。
悲劇的な最期とは、治癒や意味のない、ゆっくりとした苦痛を伴う劣化です。これを俗語でいうと**「千切れ傷による死」**です。

遠くからそのような最期を目撃するのは避けたいものです。以下に述べるのは新奇なアイデアではありませんが、ソフトウェアが私達を裏切るのを防ぐためにもう一度明確にするべきメッセージです。ソフトウェアは変化し続けるからこそ裏切られ、甚大な結果を生み出し得るからです。

1. ソフトウェア製品の本性とは何か？

他の機械同様、ソフトウェアも多数の知恵と手によって作られ、保守が必要です。しかし、純粋な概念であるため、無限に変形・変化し続けます。

「完成された」ソフトウェアは稀

少数例: Unix ツール、ZeroMQ プロジェクト、Clojure プログラマの一部。
- マイナーな修正やパッチを要するだけで動作は維持されることがある。
大多数: 世界は常に変化するため、それを支えるソフトウェアも無限に変わらなければならない。
- Emacsのように半世紀近く進化し続ける「製品」が稀で貴重である。

加速するフィードバックループ

ソフトウェアは世界を変化させ、その変化に応じて自身もさらに速く変化する必要がある。
AI と機械学習の再来は、このプロセスの極致と言える。
OODA ループ: 人類の変化速度に追いつくために、ソフトウェアを再書き込むのが不可能になりつつある状況にある。
- システム目標を実現するためには、世界を感じ取り、動的にアルゴリズムを生成・再修正する能力が必要となる。

問いかけ:

絶え間ない変化の圧力下で、製品が繁栄し続けるための責任は誰にあるのか？

2. ソフトウェア品質保証（SQA）の責任は誰にあるのか？

「品質保証」を担うべき主体は多岐にわたります。以下のようなシナリオにおいて、顧客に直接影響を与える低品質状態が頻発しています。

典型的なバグと失敗

フレームワークとアプリの不整合: フレームワークは高性能だが、アプリケーション自体がクラッシュする。
使い方の問題: 機能が正しく動作するが、ユーザーが正しく利用しない。
市場との不整合: 開発に半分のリソースを投入したが、顧客はその製品を欲していない。
致命的なアップデート:
- 振る舞いがおかしくなり、ロールバック不能。
- 修正コストは配信時の5 倍になり、プロジェクトに数ヶ月の遅れが生じる。
スケーラビリティ失敗: ベンチマークが存在せず、拡張性が不足している。
デプロイメントミス: 設定不良により生産環境が破損する。
セキュリティとコンプライアンス:
- データ漏洩や SLA・規制違反が発生。
- CEO が声明を出して DevOps エンジニアを責めるなど、責任の所在が曖昧になる。
監視不全: 長引くバグにより深刻なデータ破損を引き起こす。
環境劣化:
- 頻繁な劣化（マスコットのような海生哺乳類）。
- 稀な劣化でも、インターネットの半分を巻き込む大規模な障害となる。

「千切れ傷」というメタファー

上記のどのシナリオも、**「角への短絡（corner-cuts）」**によって生み出され、最初は目に見えない蓄積を経て、やがて化膿へと至ります。

最初はバンドエイドで済む程度の傷。
ステッチと石膏が必要になる。
突然化膿し、組織が死に至る（あるいは僅かに息をしている状態で存続する）。

自白: 製品の生涯に関与するすべての機能が、「良い状態を保つ」責任を負っているのかもしれません。

3. なぜそうなのか？：線形モデルの限界

伝統的なワークフロー（分析 → 要件定義 → UX/設計 → 開発 → QA → 本番）は線形的に見えますが、これはリスクを最大化する構造です。

graph LR
A[分析] --> B[製品要件]
B --> C[UX/設計]
C --> D[開発]
D --> E["\"品質保証\""QA]
E --> F[本番]
F -.遅すぎるフィードバック^.-> A

このモデルの課題

リスクの集中: リスクの大部分は分析段階に先んじて発生しています。初期判断が間違っていれば、全てが間違ったものになります。
複利的な債務/リスク: 線形に見えるプロセスは、実は複利増大するリスクを抱えています。
「保証」の幻想:
- 品質を単一のグループ（QA）に委ねることで、「非常に間違っている状態」になる確率が増大します。
- 悪いニュースを完全に見逃す確率も高まります。

フィードバック遅延の問題

リスクの根底にはフィードバックの遅延があります。
配送圧力が強い時、弱い信号（小さなバグや不満）は死んでしまいます。
バッチ処理のリスク:
- 数ヶ月かけて大きなバッチで行う場合と、数日かけて小さなバッチで行う場合とは関係ありません。
- 市場フィードバックが遅延・不連続である場合、微小な線形化されたバッチこそが総合的なリスクを悪化させます。
- バッチが小さくなるほど、何バッチも前のフィードバックが今届く可能性が高くなります。

4. 製品のタイプによる違い

顧客によって定義される製品スペクトラムの両極端を比較します。どちらが「千切れ傷による死」のリスクが高いでしょうか？

特性	エンタープライズ製品	コンシューマー製品
主要成長指標	収益成長	ユーザー成長
主要販売ドライバー	紹介 + 執行役員への信用	紹介 + 友人や家族の体験
顧客リスク	アカウント単位で高リスク・高リターン	アカウント単位での極めて小さい経済性
契約リスク	破滅的なペナルティを伴う SLA	ユーザーが読むことのない EULA

共通の課題：組織全体の手術

すべてのソフトウェアは変化するだけでなく、それを生み出す組織についても**「深遠な手術（deep surgery）」**を行う必要があります。

製品と組織全体が柔軟にし、再構成され、インプラントのように再設計される速度は、他産業では珍しいほど速いものです。
なぜか？ ソフトウェアの本質は「人々の考え方の繰り返し」だからです。

「傷」の正体

分解してみても、以下のすべてが「傷」です。

ホットフィックス（緊急修正）
不満
アプリクラッシュ
サービス障害

各傷はゆっくりと治癒しますが、それにより品質と価値（評価）は破壊されます。

5. どのようにして品質を破壊するか？

品質を破壊する方法を理解することは、品質を生み出す方法を知るために有用です。以下のような行動が組織に浸透しています。

誤ったアプローチ

テスティング ≠ 品質保証: テスティングを QA と誤解し、誤ラベル付けする。
責任の分散と実質化の矛盾: チーム全員に QA の責任があるように見せかけ、実際には最も経験の浅い人々だけで日々の作業を任せる。
毒性な文化の醸成:
- 「こんにちは、スプリントに追加します。小さなことなので期限を遅らせないでください。」
- 「テスティングは退屈です。」
- 「顧客からの苦情が来たら直すでしょう。」
- 「このコード、誰が書いたんだよ？」
- 「ああ、あの脆弱なテストですね。ただビルドを再トリガーしましょう。」
- 「君の仕事を知らないから、これをリリースしろ」（※痛かったです）。
優先順位付け: デザイナー、開発者、テスターが他人によって設定されたタスクと優先順位のみに取り組ませる。
責任追及: 誰かが間違いのせいにされるようにする。
部門間競争: 部門間競争を促進するインセンティブを設定する。
不適切なリーダーシップ: Vogon（異星人）や Darth Vader に CEO を任命する。
逸脱行動の普通化: すべての種類の逸脱行動をさらに普通化する。

ヒント: CIA の非公開された『シンプル・サボタージュ・フィールド・マニュアル』の第 11 部「組織および生産への一般的中立化」を読むと、多くの事例が解説されています。

6. どのようにして品質を創造するか？

品質を生み出すためには、以下の 3 つのステップが必要です。

破壊要因を排除する（上記のリストを逆手に取る）。
逆のアプローチをとる（例：知恵を秘匿する代わりに共有する）。
高品質組織の特性を確認する。

組織全体システムの構築

「ベストプラクティス」のプロセスや、トリック的なスタイル介入では、壊れたシステムや人々を修復できません。
「道」は共進化しなければなりません:
- 協力するステークホルダーによって
- 組織全体に広がる
- 組織固有の文脈に適した
- 顧客・パートナー・エコシステムと共に

視点の重要性

「視点は 80 ポイントの IQ に値する。」 — アラン・ケイ

より良い品質へ航路をたてるため、我々の第一の義務は新しい視点（未知で、多様な、現状に挑戦するもの）を求めて意図的に非常に不愉快になることです。

7. 第一のスキル：建設的に苦痛を受け入れる

私たちは皆苦しみます。避けられないことです。しかし、生命が繁栄するのはこの苦しみのおかげです。

**「なぜ私たちは苦痛を受けるのか？」**という問い自体が素晴らしい議論を生み、建設的な苦痛は質の高い結果をもたらします。

回復のプロセスの例

一年間怠けていた後にフィットネスピークを取り戻すには：

筋肉痛、アラーム時計を呪う、苛立つような日々が続きます。
美味しい即効性の快楽（サボる）との戦いです。
先に難しくなってから先に簡単になります。
以前の高い S 曲線の頂点に戻り、次のサイクルを開始します。

我々の周りには対話が溢れています

急速に増加するトップクラスの研究報告や経験レポートへのアクセスがあります。
これらの教訓は多くの涙や血、そして生命によって支払われたものです。
直感を増幅させ、獲得した「追加の 80 ポイント IQ」を活用しましょう。

8. 注意点と自白 (Mea Culpa)

本稿は非常に未完成であり、我々の現在の直感に基づいています。

約20 年間のプロフェッショナル生活の中で、私の失敗、無知な間違い、そして稀な勝利からなる多くの意識的・無意識的な評価・適用ループによって強く色づけられています。
世界を遥かによく理解する人々と共に働くことで学び、幸運を得たことも反映されています。
壁や障害にぶつかり「怒り」を感じた後に頻繁に読書し、思考し、話し合った経験も影響しています。

ご利用にあたって: 有用な部分を取り扱い、残りは廃棄してください。ソース（私）と共にあります 🐙

千の切り傷で死ぬのを避けるか、またはソフトウェア品質について考える方法（2023 年）