ソフトウェア品質保証マニュアル

ざっと、これまでの私のエンジニア人生のすべてをまとめたマニュアルの概要ができてきました。完成度は70…60%ほどですかね。現在のページ数にしてＡ４用紙に250ページ弱です。全部完成すれば、400ページ弱くらいにはなるんじゃないでしょうか。

目次は次のようになっています。

1. 品質ってなんですか？
　1.1 品質を理解しないと、正当性は保証できない
　1.2 「品」の歴史
　1.3 要するに「品」とは？
　1.4 「品」という文字の由来
　1.5 現代における「品」
2. ソフトウェア品質
　2.1 測定との関係と視点
　2.2 世の中の製造業がQC活動などを行うことが当たり前な理由
　2.3 それぞれの品質の関係性
　2.4 基本的な考え方
　2.5 ソフトウェア品質の優先順位
　2.6 利用時の品質（品質の効果）
　2.7 外部品質（プロダクト品質）
　2.8 内部品質（外部品質を支えるバックボーン）
　2.9 プロセス品質（正しい仕組みと正しい手順）
　2.10 ソフトウェア品質とマッチングしない現場
　2.11 ソフトウェア開発方法論は欧米流が随所に紛れている
3. ソフトウェア品質特性
　3.1 各品質特性の依存性
　3.2 機能性 -functionality-
　3.3 信頼性 -reliability-
　3.4 使用性 -usability-
　3.5 効率性 -efficiency-
　3.6 保守性 -maintainability-
　3.7 移植性 -portability-
4. 問題
　4.1 ランダム故障と決定論的故障
　4.2 問題の原因
　4.3 問題のスコープ
　4.4 問題のレベル
5. 品質は、モノを作る前にすでに決まっている
　5.1 開発/製造作業の大原則
　5.2 すべてのプロセスに紐づくインプット/アウトプットも連動している
　5.3 設計工程の重要性
　5.4 品質が安定しない理由
　5.5 ＱＡによって引き起こされる問題プロジェクト
　5.6 なぜ、ＱＡが存在しているにもかかわらず、プロジェクトはトラブルを起こすのか？
　5.7 役割分担がもたらす「不良（バグ）」
6. ＱＡ（品質保証）プロセス
　6.1 品質保証の必要性
　6.2 一般製造業とソフトウェア開発業の違い
　6.3 品質保証担当者に求められるスキル
　6.4 品質保証担当者が絶対にやってはいけないこと
　6.5 品質保証体制
　6.6 品質保証の流れ
　6.7 まず、すべてに明確なゴール（目標）を決定する
　6.8 ＱＡ確認方法
7. 品質観点ポイント
　7.1 要件定義
　7.2 外部設計／基本設計
　7.3 内部設計／詳細設計
　7.4 設計レビュー
　7.5 製造
　7.6 単体テスト（Unit Test / Program Test）
　7.7 結合テスト（Join Test / Integration Test / Combined Test）
　7.8 総合テスト／システムテスト
8. プログラム調査ガイドライン
　8.1 プログラムの新規追加、変更を行う場合
　8.2 プログラムの削除を行う場合
　8.3 プログラムの再利用を行う場合
　8.4 その他推奨事項
9. テスト工程を制する
　9.1 はじめに
　9.2 テスト工程を１つのプロジェクトとして考える
　9.3 テスト工程
　9.4 テストの種類
　9.5 テスト計画
　9.6 テスト観点の作成手順
　9.7 なぜ、不良を検知するためのテストフェーズで、不良が見つけられないのか
10. 単体テスト（Unit Test / Program Test）
　10.1 観点
　10.2 網羅性
11. 結合テスト（Join Test / Integration Test / Combined Test）
　11.1 テスト観点作成手順
　11.2 観点
12. システム切替／データ移行
　12.1 切替／移行について
　12.2 切替の種類
　12.3 切替の計画
　12.4 移行業務管理
　12.5 切替／移行作業手順
　12.6 移行リハーサル
13. データ移行検証
　13.1 検証対象
　13.2 検証方法
　13.3 検証タイミング
　13.4 検証実施体制
　13.5 検証手順
　13.6 検証基準
　13.7 移行結果報告
14. トラブルシューティング
　14.1 不良発生時
　14.2 納品後不良トラブル

そして、別紙、あるいはまだ整理中でマニュアルのどこに挟もうか、シナリオの流れで悩んでいるものは、附則側にまとめています。何度も読み返しながら、挟み込んでいこうかと思います。

X. （附則１） ソフトウェア品質特性一覧
X. （附則２） 当前で、最低限で、自己防衛するための作業品質を保証するための取組み
　1. 「問題とは、バグや失敗を指すのではない」
　2. 「対処・対策は必要だ」
　3. 「前提・全体をまず知るべきだ」
X. （附則３） 仕事において問題が生じた際の対策フレームワーク
　1. 原因、要因の特定について
　2. 対策について
X. （附則４） 排他制御で懸念される不良事象
　1. 楽観的排他を使用する機能と使用しない機能が混在する場合
　2. 悲観的排他（ロック）を使用する機能と排他の概念がない機能が混在する場合
　3. 排他制御が存在しない処理において更新を行う場合①
　4. 排他制御が存在しない処理において更新を行う場合②
　5. 悲観的排他（FOR UPDATE）が複数回実施される場合
　6. 悲観的排他（FOR UPDATE）によるテーブル共有ロックが輻輳する場合
　7. 悲観的排他（FOR UPDATE）による行共有ロックが輻輳する場合①
　8. 悲観的排他（FOR UPDATE）による行共有ロックが輻輳する場合②
X. （附則５） アジャイル開発モデルは正しく理解しないと効果が出ない
　1. アジャイルの勘違い①
　2. アジャイルの勘違い②
　3. アジャイルソフトウェア開発宣言
　4. 「設計はなるべくしない」とか
　5. いつでも仕様変更できると思ってアジャイル開発を始めると痛い目に遭う
X. （附則６） ソフトウェア開発アプローチ
　1. POA（プロセス中心アプローチ）
　2. DOA（データ中心アプローチ）
　3. OOA（オブジェクト中心アプローチ）
　4. それぞれのメリットとデメリット
X. （附則７） 当たり前品質と魅力的品質
　1. 当たり前品質
　2. 魅力的品質
　3. 一元的品質
　4. 無関心品質
　5. 逆品質
X. （附則８） 一般的な品質保証の現実
　1. システム開発プロジェクトの平均成功率
　2. プロジェクト成功の阻害要因として直面した課題頻度
　3. まずは、きちんと理解すべき品質と仕事の相対関係
　4. 一般のＱＡ活動ではどうしているのか？
　5. なぜ、そんなに手戻りが多くなるのか？
　6. なぜＱＡはそんなマネジメントを無視した方法を選択するのか？
　7. 品質保証上の困難な事情
　8. なぜ、こう言うことが起きるのか？
X. （附則９） プロジェクト運用の問題点
　1. 理想と現実
　2. そもそもＱＡ⇔技術⇔営業は価値観が相容れない
　3. 会社として顧客の信頼（品質）を守れない品保に存在価値はない！
X. （附則10） 効率性を上げるために用意されたテンプレートやフレームワーク
　1. 自ら検討することなく、模倣すべきテンプレートやフレームワークを欲しがると
X. （附則11） レビュー
　1. レビューの種類
　2. 手順
X. （附則12） 事故報告書／顛末書の書き方
　1. 顛末書とはトラブルの一部始終を報告するための文書
　2. 顛末書の意味と果たすべき3つの役割
　3. 顛末書作成のポイント
　4. 顛末を報告する際の注意点
X. （附則13） Java言語でテストが実施できない事例
　1. private 指定されたコンストラクタ
X. （附則14） IPO(input Process Output)
X. （附則15） ＯＳＳ（オープンソースソフトウェア）
　1. OSSライセンスのカテゴリ
　2. OSSライセンスの種類
　3. コピーレフト型
　4. 準コピーレフト型
　5. 非コピーレフト型
　6. その他注意事項
　　①デュアルライセンス、トリプルライセンス
　　②ライセンスの混在時、「製品全体のライセンスは最も強いライセンスに引きずられる」という原則
　　③クリエイティブコモンズ（CC）
　7. 日本を取り巻く法律
　　①著作権法
　　②契約法
　8. OSSを正しく使うためのチェックポイント

たまに、自らの答えを持とうとせず、会社としての「基準」「規程」を欲しがるエンジニアがいますが、先に答えを言っておくと「そのようなもの実際には存在しません」。こうした知識の集大成は、結局のところ

　個人の知識群／経験則群

をまとめたものに他ならないからです。そこに、後付けで学術的な論文や権威がある人の言などをくっつけて、経験から学んだ手法や方法が正しかったと証明するだけのことなのです。

それを考えられなかった人たちが、「それいいな！会社の基準にしよう！」と言って決まっているにすぎません。最初はすべて個人知から始まっているのです。であれば、同じように経験してきた人ならば、誰でも基準は作れて不思議ではありません。

苦労はするでしょう。大変かもしれません。

要は、それを受け入れる気があるかないか（楽をしたいかしたくないか）、それだけのことでしかないのです。

もちろん、失敗する方法をまとめても意味はないので、こうしたまとめが行える人は、何らかのプロジェクトで成功したのだと思います。ですが、それが様々な条件下でも全く同じ成果になるかは別問題です。

こうしてまとめたものも、所詮、ＩＴ業界全体から見れば、私が経験してきた分野・領域なんてごくわずかな知識でしかありません。他の成功に至る方法もあるでしょうし、私ごときでは思いもつかない未知の方法もあるかも知れません。

今後も、新しい体験をし、新しい成功をすれば、ここに書きこんでいくのでしょう。少なくとも、私はそのつもりですし、全てを書き残していこうと考えています。

もしも、私が経験してきたプロジェクトたちと同じある程度条件が一致していれば、ここに書かれた手法は概ね成功へと導いてくれるはずです。

特に、私は「トラブルプロジェクト」の立て直しや尻ぬぐいを多く経験してきた関係上、そうした多種多様な異例のシチュエーションでも対応できる汎用性がある内容となっていると思っています。でなければ今まで、私自身が開発したわけでもない、自分の会社で起こしたわけでもない未知のトラブルに、いきなり参画した第三者が解決なんてできるわけありませんしね。

今まで書いてきた note の中にも、ほんのり書いたテーマがあるかも知れませんが、他もおいおい書いていければと思います。