はじめに
テスト設計レビューでは、以下のような課題をよく見かける。
- レビュー品質がレビュアー依存になる
- ベテランしか有効な指摘ができない
- 指摘理由が共有されない
- 同じ欠陥が繰り返される
- レビューが形骸化・目的化する
一方で、成熟したレビュー文化を持つ現場では、
- 観点共有
- 指摘理由共有
- ナレッジ蓄積
- 設計品質向上
が自然に行われている。
つまり、テスト設計レビューは、単なる欠陥検出ではなく、「知識共有と知識創造の活動」として捉えることもできる。
本記事の目的
前回投稿した
「ソフトウェア開発におけるSECIモデルを整理してみる」
では、
SECIモデルをソフトウェア開発全体へ当てはめて整理した。
本記事ではその続編として、「テスト設計レビュー」にフォーカスし、
- レビュー観点
- 指摘理由
- ナレッジ共有
- レビュー文化
がどのように循環しているかを、SECIモデルの観点で整理してみる。
1. SECIモデルのおさらい
SECIモデルは、野中郁次郎氏による知識創造モデルであり、
知識が以下の循環によって組織へ蓄積される考え方である。
| SECI | 内容 |
|---|---|
| Socialization（共同化） | 暗黙知 → 暗黙知 |
| Externalization（表出化） | 暗黙知 → 形式知 |
| Combination（連結化） | 形式知 → 形式知 |
| Internalization（内面化） | 形式知 → 暗黙知 |
前回記事では、ソフトウェア開発全体をこの観点で整理した。
今回は、レビュー活動へ適用してみる。
2. テスト設計レビューをSECIモデルで整理する
2-1. Socialization（共同化）
2-1-1. レビュー同席による学習
レビュー経験が浅いメンバーは、レビュー同席を通じて、
- どこを見るのか
- 何を危険と感じるのか
- どう違和感を検知するのか
を学習する。
これは明文化されないケースも多く、「レビューの勘所」という暗黙知共有が行われている状態と言える。
2-1-2. レビュー文化と知識共有
例えば：
- ペアレビュー
- レビュー会
- 指摘理由の説明
などは、暗黙知共有を促進する。逆に、
- 指摘だけ残す
- コメントのみ
- 指摘理由を説明しない
環境では知識共有が起きにくい。
2-1-3. 属人化という課題
共同化だけに依存すると、
- 「あの人しかレビューできない」
- 観点が継承されない
- レビュー品質が安定しない
といった問題が発生する。
2-2. Externalization（表出化）
2-2-1. 指摘観点の言語化
レビュー品質向上で重要なのは、「なぜその指摘になったのか」を言語化することである。
例えば：
- 境界値観点不足
- 状態遷移考慮不足
- 業務条件漏れ
- 異常系不足
などが挙げられる。
2-2-2. レビュー観点の形式知化
言語化された知識は、
- レビュー観点表
- チェックリスト
- 指摘パターン集
- 欠陥事例集
として整理できる。
ここで初めて、レビューが属人作業から脱却し始める。
2-2-3. 指摘数だけでは不十分
レビューでは、指摘件数だけが注目されるケースもある。
しかし本来重要なのは、
- なぜ見つかったか
- どう防ぐか
- どの観点で検知したか
という知識共有である。
2-3. Combination（連結化）
2-3-1. レビュー知見の体系化
レビュー知見は、単独で存在するだけでは弱い。
例えば：
- 欠陥分類
- 工程別観点
- リスク分類
- 品質KPI
などを組み合わせることで、「どの工程で、どの観点不足が、どの欠陥に繋がりやすいか」といった、より高度な組織知へ発展できる。
2-3-2. ナレッジ共有基盤
例えば：
- Confluence
- Backlog
- Redmine
- Wiki
などへ蓄積することで、「再利用」「横展開」「標準化」が可能になる。
2-3-3. レビュー文化の成熟
ここまで進むと、
- 観点共有
- 指摘理由共有
- 欠陥再発防止
- 学習速度向上
が起きやすくなる。
2-4. Internalization（内面化）
2-4-1. 観点が「自然に見える」状態
形式知化されたレビュー観点を繰り返し活用することで、
- 危険箇所が自然に見える
- 指摘前に自己修正できる
- 設計品質が向上する
の状態になっていく。つまり知識が再び暗黙知化する。
2-4-2. レビューが教育になる
成熟したレビューでは、「欠陥検出」だけでなく、
- 判断基準共有
- 品質観共有
- 思考共有
が行われる。
レビューとは単なる確認作業ではなく、「知識創造活動」とも言える。
3. レビュー文化が弱い組織で起きること
逆にSECIサイクルが回らない組織では、
- 指摘が属人化
- 同じ欠陥再発
- レビュー目的化
- 指摘数至上主義
- KPIだけ独立
が起きやすい。
つまり、「知識が循環していない状態」とも言える。
4. まとめ
テスト設計レビューとは、単なる成果物確認ではなく、
- 品質観共有
- 判断基準共有
- 思考プロセス共有
を通じた、「知識継承活動」とも言える。
SECIモデルで整理すると、レビュー文化や品質活動を、「知識循環」という観点で捉えやすくなる。
今回整理した内容は、レビュー活動だけでなく、プロジェクト運営全体にも当てはめられる。
特にPMOでは、
- KPIが形骸化する
- 会議だけ増える
- 管理資料が目的化する
- ナレッジ共有が起きない
などの問題が起きやすい。
これらも、「SECIサイクルが回っていない状態」として整理できるかもしれない。
次回は、「PMOが機能不全になる理由をSECIモデルで考える」として、PMO・会議体・KPI・組織知の関係を整理してみたい。