HiRDBの高い信頼性ってどうやって実現してるの？
さて、本連載をこれまでお読みの方なら、日立のリレーショナルデータベース製品「HiRDB」のことは、もうある程度ご存じのはず。読んでない人は今すぐに読んでほしい。ちなみに今さらだが、HiRDBの読み方は「ハイアールディービー」なので、念のため。
「純国産」と聞くと、脊髄反射で「高品質」「高信頼性」をイメージしてしまうのは、筆者が昭和世代だからか？でもHiRDBに関して言えば、実際のところオープン系データベース製品としてはトップレベルの信頼性を持つと言われていて、銀行の勘定系システムや社会インフラ系システムといった、超ミッションクリティカルな領域で昔から使われ続けているのだ。
燦然と輝く「純国産品質」の印籠。その過大なまでのユーザーの期待に日立はどう応えていっているのだろうか。
品質保証部門が設計開発部門から完全に独立している
今回お話をうかがったのは、以下のお三方。
・偉い人代表／プラットフォームQA本部 担当本部長 梯雅人さん↓
・ベテラン代表／ソフトウェア本部 DB設計部 主任技師 板谷孝さん↓
・若手代表／プラットフォームQA本部 ソフト品質保証部 南部佑輔さん↓
ちなみに、板谷さんの所属先「DB設計部」というのは、何となくイメージしやすい。まさに、データベース製品の設計開発を担当する部署だ。だけど、梯さんと南部さんがいる「プラットフォームQA本部」というのは一体何だ？
「プラットフォームQA本部の“QA”は“Quality Assurance”の略、日本語に訳すと『品質保証』という意味です」（梯さん）
なるほど、つまり品質保証に関する活動を請け負う専門部署ということか。何でも、日立のソフトウェア製品における品質管理の第一の特徴は、この品質保証部門が設計部門から完全に独立している点にあるとのこと。それだけ、品質に気合いを入れてるということか。
じゃあこの品質保証部門って、具体的にどんな仕事をする所？ これは筆者の勝手な思い込みだが、リリース前の製品を「これでもか！ これでもか！ イッヒッヒッ……」といじり倒して（表現は多分に誇張しています）、ひたすらバグを洗い出していくような感じ？
「ハードウェアの世界ではそういうイメージに近いかもしれませんが、私たちは開発プロジェクトの上流から、もうそれこそプロジェクト計画を立てる段階から設計部門と一緒になって品質管理の取り組みを始めます」（梯さん）
プロジェクト計画立案の段階から？
「ソフトウェア製品って、既にほぼ完成した段階で不良を見つけても、今さら仕様を一から直せないんです。なので、なるべく上流から品質管理を行うのが重要になってきます」（梯さん）
具体的には、こんな感じらしい。まずは、設計部門が作成したプロジェクト計画書をレビューして、「どのような品質特性を目指すのか？」「そのスケジュールで本当に品質が確保できるのか？」などと、これから開発する製品の品質確保の観点から、もろもろと細かい突っ込みを入れる。と当時に、この段階でプロジェクト計画とは別に、「品質計画」なるものも立てるのだという。この品質計画とは、果たしていかなるもの？
「過去の開発経験や、ソフトウェア工学の知見を参考にすれば、『このプロジェクトの各工程で、どの程度の不良が出るか』をおおよそ割り出せるんです。そこで、プロジェクトの計画を立てる段階で、各工程で出す不良件数の目標値をもう宣言してしまうんです。それとともに、不良をなるべく作り込まないための具体的な施策、例えば『こういうテストツールやソース解析ツールを使います』といった具体的な方針も、品質計画の中に盛り込みます」（梯さん）
なるほど。で、そうやって計画を立てたら、次は設計・開発工程。ここでも、品質保証部門は設計部門が作成した各種仕様書を汲まなくチェックして、「こんな作り方じゃ危ないんじゃないの？」「ドキュメントが十分に詳細化されていないのでは？」と突っ込みを入れていく。さらにテスト工程に入っても、「不良が予定通り出てないじゃないか！」「不良が出過ぎている！」……。
そして最後に、設計部門のテストが完了した開発物に対して、品質保証部門が出荷前の最終テストを行い、これをパスすれば晴れて出荷という流れだ。
