読者です 読者をやめる 読者になる 読者になる

>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

軽量品質保証 - Lightweight Quality Assurance In Software Development-

軽量品質保証の部品


はじめに

「ソフトウェア品質保証」という活動や技術分野にみなさんはどのような印象をお持ちでしょうか。工業製品で無敵を誇った品質大国ニッポンの志はソフトウェア品質保証にも受け継がれ、特に「モノづくり」の課程に対する姿勢は欧米からも範とされています。世界初のソフトウェア品質知識体系ことSQuBOKも日本の編纂によるものであり、その多くの知識エリア、特にテスト技法や経営まで視野にいれた品質マネジメントについては日本発の考え方や方法論が存在感を示しています。それだけに、「何かとっても難しそう」「具体的にどうしたら”出来た”と言えるのか、言っていいのかわからない」と感じる方も多いのでは無いでしょうか。特に、組織からの支援や潤沢な資金を与えられることの少ない非クリティカルシステム、超短期開発の現場において。さらに懸念されることは、そういう印象を持った結果、「ソフトウェア品質保証」という取り組み自体を諦めてしまう、または目の前にあるいくつかのそれらしい方法を組み合わせてお茶を濁してしまうことです。



”正しい”方法は、対象とする製品に見合った適切な品質の見極めとそれを保証する方策自体をデザインすることです。しかし、それにはソフトウェア品質保証技術に対するそれなりの造詣と経験が求められます。だからこその技術分野なのですが、余裕のない現場がこの技術分野への取り組み自体を諦めてしまう、おざなりにしてしまうのはとても残念なことに感じます。言うなれば、いまこれから「ソフトウェア品質保証」を学ぼうとする人には「富士山」しかない状況です。これから登山を嗜んでみようかと考える人が「富士山以外は山と呼ばない」と言われたら多くの人は怯むと思います。おそらく、これが現状です。

ソフトウェア品質保証の「高尾山」を

はじめて登山をする人が周りに居たら、関東なら誰もが「まずは高尾山に登ってみたら?」と薦めるハズです。山登りの厳しさではなく、楽しさを先に実感してもらうことで、さらなる高みを目指すモチベーションの土台を作る意図がそこにはあると思います。これをソフトウェア品質保証の世界にも当てはめられないか。もっと言えば、非クリティカルシステム、超短期開発の現場で悩むQAエンジニアにいったん「それでいいんだよ」「しっかりやってるよ」と言ってあげたい。そうして、まず小さな、確実な成果を出してもらうことで、プロセス自体の改善や、さらなる高みを目指すモチベーションを持って貰いたいと考えました。

できるの?そんなこと

直接的な動機の面は以上ですが、本当にそんなプロセスを定義することが出来るのでしょうか?先人たちの研究の成果や、ツールの発達によって、品質保証技術自体の適用も低コストで行える芽が出てきたと感じています。例えば一昔前に「レビュー指摘数」というメトリクスを採取するのはかなりのコストを必要としました。しかし、現在レビューはSCMに付属の機能や、専用のOSSツールを利用することが特に非クリティカルシステム、超短期開発の現場においては当たり前になっており、指摘数とその対応程度、及びターンアラウンドタイムなどを採取することが容易になっています。

ここがキモで、こういう現場はツールの導入やプロセスを変えることを厭いません。ということは品質保証技術を適用するためのツールや技術の導入のハードルも低く、残りの関門は「何があるのか、何を選べばいいのか知らない」だけである可能性が高いのです。であれば、そこだけビシっと定義してあげれば割と容易に成果を出すことが可能になるのではないでしょうか。

具体的なプロセスや利用する技術の選定はこれからですが、本ブログや書籍で何度か触れたことがある品質モデルの定義は最初のステップとして入れたいと考えています。ハードルを下げると言っているのにそんな難しそうな手順を入れて大丈夫なのかと感じられるかもですが、ここを外すとすべてを大きく間違えてしまう、外せない技術のひとつであると考えています。もちろん、1, 2時間で出来るようにデザインします。

軽量品質保証 - Lightweight Quality Assurance はどんな特徴を持つか

現時点での要件やメッセージを考えてみました。

  • ひとり、またはふたり程度で実現可能であり、組織を必要としない
  • 2週間程度のプロジェクトにゼロから適用出来る
  • 極限まで人的、調達的コストを掛けない
  • 省いた部分のリスクを明らかにする
  • 継続的改善へのアプローチを盛り込む
    • 何度も行うことを前提とする
  • 正確に間違えるよりも、漠然と正しくありたい
  • 安い、早い、うまい

検討を進める中で落ちるかも知れませんがまずはここを達成したいなと思います。

軽量品質保証 - Lightweight Quality Assurance は何で無いか


いまあるソフトウェア品質保証を革新/刷新するものではない

ミッションクリティカルな製品や多くの組み込み系など、いまある体系を正しく理解し、適切に設計すべき分野もたくさんあります。そういう分野ではどうしても軽量というわけには行かないことが多いと思われます。

対立軸ではない

もし仮に重量品質保証というものがあり、そう感じておられる方がその対立軸として本件を捉えられているとしたらそれは明確に誤りです。どちらも単なる現場へのアプリケーションであり、重視する品質概念自体に違いはありません。

特定の開発プロセスを前提とするものではない

適用出来る開発プロセスの種類を限定するつもりは無いです。結果として向き不向きが生まれてしまう可能性がありますが、継続的改善は盛り込みたいと思っています。

興味があるので議論に加わりたい

ありがとうございます。下記にグループを作成しましたので、お気軽にご参加ください。ほとんどの資料、議事録等の管理にGoogleのインフラを利用する予定です。他のメールアドレスをご利用の方は、Googleのアカウントに、現在ご利用頂いているアドレスをひもづける形で、インフラを利用できる体制を整えて頂けますよう、お願い致します。

https://groups.google.com/group/Lightweight-QA

もしかしたらこのアドレスは取れない(他の人が取ってる)かなと思いましたが、案外あっさり取れました。

その一歩先にあるもの

この考えの大本は、各地の非クリティカル、超短納期開発に関わる若手のQA、テストエンジニアから「本当にできているのか自信がない」「やり方がわからない」という生の声をたくさん聞いたことがキッカケになっています。中には「おお!すごいじゃないですか!」と手放しで称賛できるプロセスもあったのですが、僕が言うだけでは何の足しにもなりません。いったん、公で作られた低いハードルを超えてもらうことで、ソフトウェア品質保証技術者としての矜持をきちんと持ってもらい、その先の探求に興味を持ってもらうことで、これがスコープとしないクリティカルシステムや大規模開発の分野における研究とも対流が発生するようになると考えています。そうして、この技術分野全体の活性化とさらなる発展に繋がっていくと良いな、とも考えてはいますが、達成できなくてもいいです。ゲンバの人たちが楽しく仕事できることがゴールです。

references