Just enoughな品質

JaSST関西のパネルを聞いていたら、アジャイルプロセス協議会の岡島さんが「Just enoughな品質を作るべき」みたいな発言をしていた。話の流れは確か、網羅テストをするのは時間的にも難しいとか何とかだった気がする。違ったかな。顧客満足をジャストに追求するという話だったかな。顧客が望んでいない余計な機能は実装するな、という話だったかな。うろ覚えで申し訳ないので、誰か教えてください。いずれにせよ、以下の話は岡島さんに対する批判ではない。だって発言のバックグラウンドを覚えていないのだから。

さて、そこかしこで話題になる"Just enough quality"論。僕も色々なコンサルの依頼の際に「うちはオーバークォリティ気味なんだよ。もっと効率的に製品を出荷したいんだよ」と宣う方を見たことがある。まぁ気持ちは分からないでもない。

かく言う僕も、日経BPの依頼で「品質とスピードを両立させる」というテーマのセミナーで話したことがある。まぁ僕の講演タイトルは「品質とスピードを両立させるなんてオイシイ話はあるのか？」でしたが、多少迎合気味なのは反省点。

最近思うのは、"Just enough quality"を口にする組織のほとんどは不具合や納期遅延の多発に苦しんでいるということだ。一方では不具合や納期遅延によるトラブルを撲滅したいと言い、舌の根も乾かぬうちに"Just enough quality"の話をする。もちろん背景にあるのはお客様のためとかなんとか。

彼らに興味があるのは、顧客満足度ではない。もちろん開発者満足度でもない。ただ財務指標を良くすることだけだ。だからトラブルも撲滅したいし、余計な品質も作り込みたくない。財務指標を良くする手段としての"Just enough quality"なのだ。

その財務指標というのは、いつからいつまでの財務指標のことなんだろうか、と思う。直近の1年、よくて2～3年なのではないか。これもまた一般論だが、品質トラブル撲滅と"Just enough quality"の両方を口にする人は、中長期的視野に欠けていると感じることが多い。

僕の経験というか感覚では、"Just enough quality"を目指している組織は、ひ弱である。技術的なしっかり感というか、要求や設計をあらゆる角度から眺める視座というか、トラブルの時の復旧力というか、そういった能力が低いと思う。ある条件でたまたまトラブルが無い開発ができても、次に同じ品質を達成できるような気がしないのだ。いつもギリギリ。いつもフラフラ。

そういう組織は「最適な開発」ができているのだろうか。成功したプロジェクトでは、そうかもしれない。しかしソフトウェア開発組織を中長期的に維持していくために必要なのは、ある程度条件が異なっても、品質の良いソフトウェアを安定して開発できることだ。統計用語で言うと、ロバストネス。ダーウィン的に言うと、適者生存かな。だから、"Just enough quality"を目指すということは、短期的には優位だが、中長期的には劣った戦略だと思う。

結局のところオーバークォリティというのは、技術力向上の機会なのである。それも、セミナーなどの座学や演習で得られない、様々な条件のプロジェクトへの対応力向上のトレーニングなのだと思う。開発と改善、教育をまとめて進められる、得難いチャンスに他ならないのだ。"Just enough quality"論者は、そのあたりのことを理解していないのであろう。きっと、開発は開発、改善は改善、教育は教育で分けて実施しているとか何とか主張するのかな。でも、それは効率が悪いし、別物として扱うと現場は改善や教育に時間を割かない。要するに、間違いなのだ。

こう主張すると必ず「オーバークォリティのソフトウェア開発はコストがかかるので、そもそも受注できないか、赤字になる」などと言う輩がいる。では、そのコストアップや赤字、納期遅れの原因は何だろうか。不具合やマネジメントトラブルへの対応のせいではないのか。そうした組織が今やるべきことは、"Just enough quality"を狙って組織をひ弱にし、不具合やマネジメントトラブルが起こるリスクを高めてしまうことではない。オーバークォリティを狙って組織を鍛え上げ、不具合やマネジメントトラブルそのものを減らすことでコスト削減や納期短縮を狙うことだ。

だから我々は、胸を張って「オーバークォリティを実現しろ」と言うべきだと思う。オーバークォリティを狙うことこそが、自社のスキルを本当の意味で（最も効率的に）向上させ、中長期的に優位に立ち続ける戦略なのだと。さもないと、ひ弱な組織に成り下がり、いつも品質トラブルにビクビクしなくてはならないのだと。