はじめに
ソフトウェアの品質について、ワインバーグは「品質は誰かにとっての価値である」と述べています。品質を語る時，その背後にいる人をイメージしなければならないという考え方です。背後にいる人の代表は,製品・サービスに投資する経営者や利用者です。このような方々にとっての価値，言い換えれば“顧客満足”の精神を説いた教えとして、日立製作所には「落穂ひろい」という独自の活動があります。事故やトラプルの技術的要因と動機的要因を発明し、それぞれから再発防止策を立て遂行責任者と期限を約束するものです。製品事故の事例を通じて顧客に対する思いやりの心を指導することが狙いです。日立ハイテクノロジーズは2001年10月、㈱日立製作所の計測器グループ・半導体製造装置グループ,およびハイテク関連専門商社の日製産業務が事業統合して発足しました。このため,製品開発において落穂ひろいの精神と活動が綿々と受け継がれています。
品質向上施策の有効性を高める不具合分析
製品開発プロジェクトが終了すると，プロジェクトサマリとしていろいろな数値をまとめます。その中には，不具合の混入密度，不具合防止に要した工数，不具合検出に要した工数などのソフトウェア品質に関するものも含まれます。我々は、こうした数値をもとにプロジェクト全体を概観するだけでなく，個々の不具合を詳細に分析する活動を重要視しています。不具合は，自組織の弱みや本質的な問題を明らかにするとともに，開発ノウハウを見出す金脈になり得るからです。このため、不具合分析を設計者自身が行っています。不具合分析を行うには，不具合情報が適切に蓄積されていなければなりません。不具合情報は、例えば表1に示すようなものです。技術的原因(№ 7 )と動機的原因(№ 8 )は, № 1 ～ 6の情報をもとに,なぜ本来発見すべき工程で発見できなかったのかを技術的な観表１　不具合情報の例数  AR発見した工程どの工程(レビュー /テスト)で発見されたか正常系か異常系か不具合の種類３ 腎微なものか、重大なものか期待した結果とテスト結果がどのように違っていたがどの工程で作り込まれたが発見すべき工程どの工程で発見すべきであったが千本来発見すべき工程で発見できなかったのかゲ本来発見すべき工程で発見できなかったのか8動機的原因点と動機的な親点から考察したものです。このような不具合情報を利用して自組織の強み・弱みを明らかにしていきます。その際,不具合の全体像を捉えいくつかの視点から仮説を立て，これを要付けるつもりで一つひとつの不具合を見ていくのがコツです。例えば弱い工程を探すのなら、不具合を作り込んだ工程(№ 5 ),本来発見すべきであった工程(№ 6 )の統計をとります。すると，工程内作業の完成度がわかり，強化すべき点が明らかになります。あるいは,リスクのある機能やチームを探すのであれば，機能やチームごとに不具合の統計値を算出し比較したり、改変の度合いを比較したりします。これにより，機能ごとあるいはリソース配分による特徴を把握することができます。この結果，自組織の強み・弱みを設計者自身が客観的に把握できるようになり，有効な改善施策を発想できるようになります。
トップダウンとポトムアップの施策の融合
不具合分析を起点にして小集団活動で考案した施策を部門全体で実践し、品質を向上させた事例があります。小集団活動とは，おおよそ10人以下で構成されるグループが、自主的な活動を通じて企業の目的達成に貢献する活動です。日立ハイテクノロジーズの那珂地区では,この活動を長年継続しています。当時，設計内テストが長引いたり，品質保証部門による妥当性確認工程で不具合が多数発見されたりする傾向が顕著になっていました。これを問題視したある小集団が不具合分析を行いました。不具合情報によれば、発見すべき工程はすべて設計内テストとなっており，技術的要因は，テスト仕様を網羅的に設計できていないことにあるように見えました。しかしその小集団は，設計／コード／テストの各レビューを実施して不具合の早期発見に取り組んでいる事実に着目し、テスト仕様の網羅的設計をレビューで確認できない原因がドキュメントにあると考えました。機能仕様書とテスト仕様書が別々の文書であったため，両者の対応付けと内容の精査が十分になされていない状況だったのです。そこで，Wordのコメント機能を使い機能仕様書にテスト仕様を埋め込むツールF2T (Function toTest)を作成しました。一方,部門のトップは,設計者の意識の変化に気づいていました。製品に搭載する機能が急増し設計とテストが分薬され, “私設計する人,あなたテストする人”という意識になっていたのです。そこで，機能設計者がテスト設計にも責任を持つべきと考え、小集団活動の成果であるF2Tを用い。機能の設計者が機能設計と同時にテスト設計を行うプロセス(Wモデルの応用形)を部門全体に普及させました。 F2Tにより，機能仕様とテスト仕様のトレーサビリティがとれるようになります。仕様変更に伴う追加のテスト項目も確実に設計できます。設計レビューに参加する品質保証部門のメンバーは，テスト仕様から設計内容を理解できるため，的確な指摘が増え品質向上への貢献を実感できるようになりました。設計者は,機能仕様と同時にテスト仕様を記述しなければならないため、自ずと検証可能性や検証の効率性を考慮した設計をするようになりました。このプロセスは，現在では外注先にも定着しています。
チームによるドナイン知識不足の克服
不具合分析を起点にした代表的な改善施策をもう一つ紹介します。品質保証部門が指摘した不具合を，“ドメイン知識があれば防げたか？ ”という視点で分析した結果,ある主力製品では46%がこれに該当しました。日立ハイテクノロジーズの那珂地区の製品はシリーズ開発で,主力製品は20年以上に耳り継続して開発されています。産業や法規制などの社会の変化や技術開発により、要求や実現方式も変遷してきました。このような変遷の中で蓄積されてきたドメイン知識は，今後も継続して製品を開発する上では大変重要なものです。ところが、ソフトウェア開発は、少数精鋭による開発から多人数かつ多様なリソースでの開発に移り，ドメイン知識を持つ人が少なくなってしまいました。前述の通り，設計／コード／テストの各レビューは実施されていましたが，有識者が限られているため,必要十分な指摘が困難な状況だということが，調査の結果わかりました。また，レビューで的確な指摘がなされても，指摘を受けた設計者側の知識が限定されているために正しい変更がなされないといった問題もありました。このような事態に対し部門のトップは、ドメイン知識やノウハウを広く共有する必要性を強く感じ、有識者から暗黙知を抽出し文書化して共有する施策を推進しました。個々の設計者の知識を拡充させることで，品質を作り込むことが狙いです。この施策では，あるシリーズ製品開発に関わる39人の設計者がチームを組み、４.５ヵ月間(平均従事率４ %)かけ、シリーズ製品の基本的な知識を報った解説書（約200ページ）を完成させました。この活動によって，解説書作成に関わった設計者達は各々の知識を拡充させ，専門家としての自信を深めました。成果物である解説書は、プロジェクトに新たに入った設計者に活用されています。これまでは経験しないと獲得できなかった知識を，すばやく広範囲に獲得できるようになりました。このような施策は効果を直接的に計測することが難しく個人差もあるため，実践をためらわれるケースがあります。従って，問題意識や価値観を共有できる組織でないと成功しない施策です。
“品質中心の組織文化“という強み
紹介した２つの事例は，不具合分析を利用して，不具合に繋がった行動や環境を明らかにし、独自のコンセプトで施策を実践しています。対症療法ではなく根本治療となる施策を考え実践し成果を出せた背景には，品質中心の組織文化がありました。さらに，トップダウンとボトムアップの連鎖が、品質中心の組織文化の醸成を加速させています。 「品質は誰かにとっての価値である」というワインバーグの言葉に戻ると，ステークホルダーの暗黙のニーズを見つけ提供するという広義の品質向上活動が、今後ますます重要になってきます。品質中心の組織文化は価値観を共有する土壌でもあり，暗黙のニーズを見つけ出し価値に変換する際に活かされます。つまり，容易に模倣できない組織の強みを作り出す源泉になるものです。