変わりゆく品質の定義

泣く子と悪い品質には勝てない

ユビキタスという言葉を使うまでもなく、あらゆる局面でソフトウェアがある一定の役割を担うことが当たり前になってきました。むしろ、「いかなる形であれソフトウェアが介在しないモノ」を想像することの方が難しくなってきた感があります。

ITシステムの引き起こしたトラブルが巡り巡って会社の株価を左右する時代…。業界一筋20年の筆者にもITがビジネスのキーコンポーネントとなったことが実感させられる昨今です。

 

この連載で何を語るか？

筆者はユーザ企業やSIerにお邪魔して、開発プロセス改善のお手伝いすることを生業としています。立場や事情は違いますが、共通するのは「より高い品質」であり「さらなる効率化」です。しかし品質向上ほど、総論賛成、各論反対となるものはありません。それにはいくつか理由（表1）があります。
 

このような状況下では、立場の異なる人たちを集めてわいわいがやがや議論しても、結論はおそらくでません。品質向上の取り組みを真剣に考えるためには、「細かいテクニック（各論）の羅列」でなく「対立点の存在しないほどおおざっぱな総論」でもなく、「ある考え方をリファレンスとして自分たちのやり方の過不足を検証する」ということが、より具体的な指針を見いだす一番の方法です。

筆者の所属するRational事業部（IBMの一部門）は、ソフトウェア開発をターゲットに、開発プロセスやツールを使った改善活動をお手伝いする部隊です。当然一連の製品はRationalの考えるソフトウェアのあるべき姿に則って作られています。

この「姿」はあらゆるケースに完璧に当てはまる…などといってのけるほど傲慢ではありません。しかしリファレンスの1つとしては十分有効だと考えています。本連載中に何度かIBMのツールの話がでるかと思いますが、ツールの営業活動の一環ではありません。「その機能を提供する背景」を明示することで、「なにをすべきか」を議論したいと思います。

ということで、道を外れて「なんでもやります、なんでもできます」という話題にはならないようにしつつ、本題に入ります。