概要
QAとしてソフトウェア開発の品質保証に携わる中で感じた、「誤った標準化」と「効果的な標準化」について筆者の考えをまとめた。
本記事では主に「標準プロセス」と「標準観点」について筆者の意見をまとめている。
なお、基本的な説明がない限りは、日本のWeb業界（アジャイル開発）に対する品質管理を想定した記述とする。
Web業界に関わらず、標準化について様々な意見やご指摘等を頂けたら嬉しい。
標準化とは？
まず、標準化について筆者の考えを共有する。一般的な標準化については下記のリンクを参照。
ソフトウェア開発の品質保証に関しては、従来の標準化とは違う考え方が必要ではないかと考えている。
その理由としては、IT業界では日々新しい技術が生まれ進歩し続けているため、標準化により「統一した規格」や「一定の品質」を実現できたとしても、その規格や品質レベルが新しい技術に適用できる保証はない。
特にWeb業界では新しい技術をいかに活用できるかがサービスを成長させる必須条件とも言える。そのため従来の標準化の考えでは新しい技術へのチャレンジや成長の機会を阻害してしまう可能性があるためだ。
筆者が考えるソフトウェア開発の品質保証における標準化の目的とは車輪の再発明を防ぐことだと考える。
「誤った標準化」とは？
標準化に対して筆者が経験した誤った標準化を２つ紹介する。
1. マニュアル化した標準プロセス
残念ながら、どんなに素晴らしい標準プロセスを考えたとしても、開発の現場ではプロセスが守られない場合が多々発生する。
標準プロセスをマニュアル的に運用してしまった場合、ルールが増えて単純に各担当者に追加作業が発生するだけになってしまう結果に落ち入りやすい。
新規参画者や経験が浅いメンバには有効な場合もあるが、効果のある範囲が作成コストや運用コストを上回る場合は少ない。
2. 使用方法がわからない標準観点
膨大な量の観点をまとめた標準化観点をよく見かけるが、ほぼ全ての担当者が標準観点をどのように使用するか把握できていない。
レビューや観点漏れのチェックに使用するなどの使用方法が話される場合もあるが、筆者は活用されている状況をあまり見たことがない。
設計スキルがなくても設計(観点作成)ができることを目的としているはずが、必要な観点を選択するために設計スキルが必要となってしまっている。
「効果的な標準化」とは？
続いて、筆者が効果的と感じている標準化について２つ紹介する。
1. 標準プロセスはツール
マニュアル的なルールとして標準プロセスを設定するのではなく、プロジェクトの方針や方向性を共有できるツールとして設定する。
フロー図のような見える化も大切だがフロー図だけでは利用方法の具体性に欠けるため、WBSのように担当者が直接利用可能なドキュメント化（仕組み化）まで行うことが重要だ。
標準プロセスのまま対応できる場合では各担当者ごとに同じことを考える時間を削減できる。標準プロセスを単純に利用できない場合こそ、担当者が頭を使って考えなければならない重要な仕事だ。
また、振り返りを行う時にも標準プロセスは重要な役割を持つ。単純にプロセスを守れなかったことを問題としてあげるのではなく、プロセスを守らないと判断した理由や、そもそも適切な判断がされていたのかを検討することが重要だ。更に言えば、プロセスを守っていた部分に対しても、プロセスを守った故に発生した問題がないかも検討し、必要に応じて標準プロセス自体の変更も検討する。標準プロセスを基準として「あるべき姿」を描き、現状との差分から本当の問題が明確にできる。
2. ナレッジを抽出した標準観点
観点の考慮漏れゼロという理想を追いかけて、使用するかも分からない標準観点を大量に作成するよりも、検証対象の検証範囲の中で共通する観点を洗い出し、標準観点として開発メンバーに共有する方が効果が高い。
例えばページネーションの機能はほとんどのWebアプリケーションで利用されているが、別アプリどころか同一アプリの設計でも画面が違うだけで設計担当者が異なり、それぞれがページネーションの設計を行っているような状況は度々発生している。車輪の再発明を行わないように、共通する観点を標準観点としてチーム内で共有することは、１つ１つの観点で見ると大した工数ではないが、観点が増え共有するメンバーの増えていくと決して無視できない効果が出てくる。
また、標準観点は工数削減だけではなく、観点や項目の粒度の統一にも効果がある。
案件によって要求される品質や開発体制が異なるため、ほとんどの場合で観点や項目の粒度にバラツキが発生する。標準観点では全ての観点を網羅できていなくても、ある程度設計範囲内に該当する標準観点があるだけで、粒度のバラツキを抑える効果がある。
最後に
具体的な使用方法を考慮されずに作成されている標準化はほぼ現場では活用されない。効率化を行うことが標準化の目的のはずが、標準化を行うこと自体が目的となっていて手段と目的が逆転している。
最初から大規模な標準化を行うのではなく、効果範囲は小さくても具体的な目標や運用が明確にできる範囲でスタートすることが大切だと感じている。
今回の標準化に対する考え方は、筆者の経験した環境において効果的であると考えた内容であり、効果の低いと表現した標準化についても、最適な対応となる環境は存在すると思う。
筆者の考えが読者の方々に少しでもプラスになれば嬉しい。また、意見やアドバイス等のコメントを頂くことで、筆者も一緒に成長させて頂きたい。
反対意見については単純にダメだなどのコメントだけではなく、何故ダメなのか？どうしたら改善できるのか？
前向きな反対意見を頂けると大変嬉しい。（賛成コメントは簡単でも良いので頂けるだけで嬉しい）