JSQCニューズ 2015年 3月　No.339

略歴：1915年7月13日東京生まれ。39年東京帝国大学工学部応用化学科卒業。海軍、日産液体燃料勤務を経て47年東京大学工学部助教授、60年教授昇格、76年退官。東京理科大学教授を経て、78年武蔵工業大学学長に就任。89年4月16日没。享年73歳。

品質管理への貢献：東大就職後所属されていた燃料工学講座で石炭の研究に従事。その分析データの統計的処理の必要性から、統計学の勉強を開始。49年日科技連ベーシックコース講師、QCリサーチグループに参加。これを契機に品質管理の道に入る。以後、逝去まで40年間にわたり、水野滋先生、朝香鐡一先生らとともに日本の品質管理の普及推進に貢献。先生の最大の功績はQCサークルの創設である。また、かなり早い時期から、プロフェッショナル中心の米国の品質管理に対して、日本ではトップ主導でラインを巻き込み全社的に行うべきだと説き、今日のTQMの基盤確立に貢献。さらに、国際的にも、国際品質管理会議（ICQC、現ICQ）、国際品質アカデミー（IAQ）、国際QCサークル会議の創設およびデミング賞の海外企業への開放を主導した。

お人柄：先生の追想録「人間石川馨と品質管理」への寄稿から人柄についての記載313件にKJ法を適用すると次の言葉で要約された（山田秀氏による）。

	a．	スケール大、寛容でズバリ発言、
	b．	ザックバランの親分肌で面倒見良い、
	c．	実行力のあるコンピュータ付きブルトーザ、
	d．	幅広い趣味・慣習（ノムニケーション､ヘビースモーカー､ゴルフ、写真、花、重いカバン等）

エピソード　▽ある現場指導で、先生は熱心に道具箱を調べた後、会議室で、会社側から不良低減で大きな成果を挙げたという発表を聞いた。それに対し「道具箱の中には、やすりが全部で40本余りあり、ラインでも使われていたので合計は60本を超えている。この現場の作業員は60人位だそうだから、全員がやすりを使っていることになる。やすりを何のために使うのか？やすり掛けは標準作業なのか？今、不良低減の大変立派な発表があったが、やすりを使ってのバリ取りとか、ねじ穴の穴径の調節とかは、発表の不良に含まれているのか？」一本のやすりから当社の品質保証体制の本質に迫る議論に展開したのを目の当たりにし、大変感銘を受けた。
　▽別の現場ではハンマーを見て、「最新の機械工学では、精密品の製作にハンマーの使用を前提としているのか」と尋ねられ、技術担当役員が目を白黒させていた光景を思い出す。
　▽お客様への納入遅れをテーマとしたある大手企業の支店での指導会では、「無理な納期での受注が問題だ」「個々の受注は、支店長の承認を受けている。だから、無理な納期を引き受けるはずはない」と甲論乙駁。先生は、「最近の受注伝票の束を見せてください」と要請。 厚さ5センチ位の伝票の束を、最初は丁寧に一枚、一枚見ていたが、後はピッチを上げて全てを見終わり、「すべての伝票には、担当者、課長、支店長と3人の押印があった。ところで、 支店長さん、一番直近の先月末の○○社からの伝票に自ら押印されましたか。」支店長はしどろもどろ。先生曰く「3つの押印は実に不思議。3つの印の方向と位置関係がどの伝票も全く同じだったのです。担当者が3本の印を束ねて、“まとめ押し”したのなら分かるのですが。」支店長は「恐れ入りました。」と答える。「支店長印が本当に必要なのか、権限委譲についてよく検討したらどうですか。」と締めくくった。
　▽「酒が飲めないでQCができるか」が先生の口癖。「そんなに遅くまで飲んでいて、二日酔いにはならないのですか」「なに、毎日二日酔いだよ」

 生誕100年記念の主要な事業ご案内：
「人間石川馨と品質管理」英訳
 同書の日英両語版日科技連HP：http://www.juse.or.jp/resource/
 国際記念シンポジウム開催：9月28日（月）終日　東京大学伊藤ホールにて

　当たり前品質であるソフトウェア信頼性の定量的評価法には各種の手法が知られており、それぞれコスト面や技術面などの制約の下で各主体（ソフトウェアベンダーやメーカなど）により実践されています。これら各種手法のうち、出荷前の水際作戦とも言える、テスト工程（ここではウォーターフォール型開発を想定）でのバグの発見過程を分析する手法もよく用いられますが、これには観測データが１つしか得られないという難点があります（一綴りのソフトウェアテストは基本的に一度限り）。従って、同一条件の下で多数の標本が採れることを前提とする理論では、ブートストラップなどを利用しても、常にうまくいくとは限りません。
 　これに対し、ある実務者らにより数年前に行われたテスト手法は、2チームによる2段階ソフトウェアテストというものです。これはまず、開発スキルが概ね等しくなるようにチームを2つに分け、また、開発・テストすべきソフトウェアの機能群も独立な2群に分けます。設計から実装・テストケースの設計までは合同で作業を行いますが、ソフトウェアが実行可能となったとき、各チームがどちらかの機能群を担当し、互いに相談無しにテストとデバッグを行い品質（バグ）データを収集します。この時点で、2つの機能群は2つのチームによって一通りテストとデバッグがされているわけですが、ここで、『ダメ押し』として、各機能群を担当するチームを入れ替え、今度は他チームが使ったテストケースを用いてもう一度テストを行います。このとき、初回のテストとデバッグが適切であれば、テスト項目が同じなのでダメ押しテストでバグが出るはずはないのですが、この実験では数件のバグが検出されました。結果、これが残存バグ数の削減に貢献したことに加え、テストケース投入時の動作確認に関する人的エラーの混入とその原因とを明らかにでき、更に同一ソフトウェアとテストケースから2本の時系列標本が得られたことで、従来法より精度のよい信頼性評価結果・チーム能力評価値を得ることができました（出荷後現在までの不具合報告は予測通りゼロです）。
 　保守コスト増大の懸念があり、ソフトウェアのコンポーネントが中・小規模であれば試す価値はあろうかと思います。ソフトウェア開発管理者の皆様、このような工夫は如何でしょうか。