はじめに

ほとんどの開発組織においては、総合テストは最終的なバグ出し工程であると思われているようです。本当にそれでよいのでしょうか。信頼性は当然のこととして、継続的な稼動能力、保守のしやすさ、使いやすさ、設置の容易性などの検証はどこにいってしまったのでしょうか。

#64：重症患者の取扱い方～トリアージ

ソフトウェア開発における主な成果物をその工程の順に見ると、見積もり回答書、要求仕様書、基本設計書、詳細設計書、プログラムコード、各種テスト設計書、評価結果報告書などがある。これらの成果物の品質は重症から健全なものまでさまざまなレベルに分けることができる。

戦場や大規模災害時において患者の数が医療者側の資源（人・医薬品）を上回る場合、助かる見込みのある者から助けようとする人命救助の効率的優先順位の決定手法としてトリアージがある。ソフトウェア開発の世界においてもこの手法を用いて、トリアージ黒・赤と判断された助かる見込みのない低レベルの成果物は直ちに提供者に返却しやり直しを要求する必要がある。いつまでもだめな提供物につきあって時間を浪費してはいけない。

トリアージ（triage；選別）

患者の容態の軽重の程度を4分類し色分けする。救命処置の優先順位は、Ⅰ→II→IIIの順とし、0は無処置とする。黒はカテゴリー0（死亡群）救命の見込みがないもの。赤 はカテゴリーI（最優先治療群）生命に関わる重篤な状態で一刻も早い処置をすべきもの。黄はカテゴリーII（待機的治療群）赤ほどではないが、早期に処置をすべきもの。緑はカテゴリーIII（保留群⁠）⁠。

Wikipedia

#65：とりあえずの結論に飛びつくヒューリスティクス

ヒューリスティクス（heuristics）とは、ある問題に関して熟考や論理的思考をほとんど行わずに判断を下すという人間が陥りやすい思考・行動のことを指す行動経済学用語である。特に単純化ヒューリスティックとは近道の解決法とも言われ、目前の問題に対して誤るリスクはあっても、とりあえずの解答を出してみるという思考である。これが俗に言うところの“⁠やっつけ仕事⁠”の本性なのである。問題の解決に当たっては行動に取りかかる前の一呼吸が必要だということだ。

ヒューリスティクス

脳の働きで驚くべき特徴の一つは、めったにうろたえないことである。ふだんは出合うものすべてについて、直感的に感じたり判断したりする。完全に理解できていない質問に対しても何かしら答えを持っている。ただし、そのときあなたが根拠とする証拠は、説明もできず立証もできないような代物ではあるが。

ヒューリスティクスの専門的な定義は、「⁠困難な質問に対して、適切ではあるが往々にして不完全な答えを見つけるための単純な手続き」である。ヒューリスティクスという言葉は、「⁠見つけた！」を意味するギリシャ語のユーレカを語源に持つ。

ダニエル・カーネマン、『⁠ファスト＆スロー』

#66：最初から完全を望まないこと

最初から完全を望んでも普通は適わない。ましてチェックの対象物の正体をおぼろげにしか把握できていないものを完璧に仕上げることなどできるわけもない。未知のものをできるだけ正確に把握するためには事前調査に時間をかけ、チェック作業中においてはそこで得られた情報を小まめに記録し蓄積しておくことが必要となる。

減災という考え方

今後の復興にあたっては、大自然災害を完全に封ずることができるとの思想ではなく、災害時の被害を最小化する「減災」の考え方が重要である。

御厨貴（東大名誉教授⁠）⁠、『⁠復興への提言』

#67：統合しないと機能しない

バラバラに散らばったものはシステムとして機能しない。分散したもの同士を一定のルールに従ってまとめ、ある目的として機能するようにしたものがシステムである。人も物も、同じ原理で社会的な機能を果たしている。ものごとをシステムとして機能させる本質は、この“⁠まとめる⁠”という作用ないしは行為である。このまとめ役を担う者をリーダーと呼び、ばらばらな人間集団を統合管理することで、開発モジュールに一定のルールを持たせ、ある目的に従った機能を果たさせることができる。開発モジュールは開発者の分身である。開発者がルールを逸脱すれば、作成されたソフトウェアもルールを逸脱する。リーダーの責任は重い。

ラグビー式アプローチ：scrum

逐次段階的すなわちリレー式のアプローチのもとでは、プロジェクトは段階ごとに一つ一つのフェイズを通り抜け、前フェイズの要求がすべて満たされたときはじめて、次のフェイズヘと移っていく。このようなチェックポイントはリスクを最小化するが、同時に、このアプローチでは統合の余地はほとんどない。あるフェイズで生じた難関によって全開発過程のスピードが遅くなったり、停止したりしてしまうからである。

全体的すなわちラグビー式のアプローチのもとでは、フェイズは相当に重なり合い、そのことによってグループは、開発プロセス中に生じる振動や⁠”ノイズ⁠”を吸収できる。ボトルネックに直面したとき、ノイズのレベルは明らかに増す。しかしそれによってプロセスが突然止まってしまうわけではなく、チームは何とかして前へ推し進むべく努力するのである。

野中郁次郎・竹内弘、『⁠製品開発革新 ラグビー方式による新製品開発競争』

#68：類似不具合の解消法

類似不具合を解消するには類似不具合とその解決法をまとめた『類似不具合集』を作成し、全員でそれを共有すればよいだけのことである。学ぶことで問題は確実に減る。

不祥事の再発を防ぐ四つの「安全文化」

情報を隠さない「報告する文化⁠」⁠、信賞必罰を行う「正義の文化⁠」⁠、失敗の経験を生かす「学習する文化⁠」⁠、必要に応じ組織や仕組みを改編する「柔軟な文化⁠」⁠。

ジェームズ・リーズン（心理学者）

#69：逸脱の法則

一定の割合で販売台数が増えていくビジネスプランは販売現場のコミットメントを取っていない企画者の創作であり、美しい不具合習熟曲線は後付けで作成されたものであり、いずれも虚偽のデータであると考えたほうがいい。

規則的すぎるデータは、観察の結果ではない。作為の結果である。

G.M.ワインバーグ、『⁠コンサルタントの道具箱』

#70：RASUI～商品の命は信頼性だけではない

優れた商品の5つの条件はRASUIにある。耳慣れない言葉であるが次の5つの特性を備えたものが良い商品の条件である。

• Reliability：信頼性
• Availability：可用性（継続的稼動能力）
• Serviceability：保守性
• Usability：使用性（使いやすさ）
• Installability：設置容易性

総合テストは、これらの5つの特性検証の場であって、単なるバグ潰しの最終工程ではない。

儲かりますか、その製品で

当たり前のことだが、儲かるかどうかは、製品に盛り込まれた技術が高度か否かで決まるのではない。自社以外に同等品を提供できる会社が何社あるかで決まっている。たとえ盛り込まれる技術が高度であっても、同じくらい高度な知識を製品に盛り込める会社が世界中に何社も存在するなら、残念ながら利益は手に入らない。

沼上幹（一橋大商学部長⁠）⁠、朝日新聞 2012/3/16

おわりに

総合テスト・運用テストにおける問題点を整理すると次のようになります。

• ベンダー側においては既に評価業務についての実行能力は大幅に低下しており、また下請け評価チームの評価業務能力が低いため、適正な評価業務が遂行されていない。
• 仕様検討工程・設計製造工程の不良および評価業務遂行能力の不足により十分なテスト計画・チェックリスト・評価用ドキュメントの策定ができていない。
• 不具合に対する感覚の鈍さ、不具合に対する実務能力の不足により、適切な不具合対応ができていない。

ベンダー側においては、劣化した開発能力の再生を図るために、統合プロジェクト管理の実行および要件定義能力の強化が必要であり、下請け側においては、自律した開発組織に生まれ変わるために、プロジェクトマネジメント能力・要件定義能力・設計能力の強化が必要でしょう。