宇宙開発と食品工業の品質管理

エンジニアになる前、新卒で食品OEM会社の品管にあーだこーだ注文を付ける仕事をしていた私です。¹

偽装とか食中毒とかネガティブな話が絶えない業界だというのは事実ですが、実は品質管理の側面ではかなり先進的な業界だと思っています。

食品工業の品質管理ノウハウは1960年代のアポロ計画において「医者のいない宇宙空間でクルーの体調を守るにはどうしたらよいか？」という命題に突き当たったことが大きな契機になっています。そもそも食品って鮮度が悪ければ当たって最悪死ぬというのが常識だったわけですが、宇宙食開発でそれはまずいだろうという話になったわけです。

「100%」とは

極めて稀に例外はあるが、基本的に安全が担保されている状態のこと。
本当に100%の安全は存在しないが、事故による損害が大きな場合には達成しなければならない。

食品工業における品質管理の考え方

しばらく食品工業の話を続けさせてください（IT記事なのに）。
アポロ計画より遡ることおよそ20年、医薬品の品質安定を目的として「GMP」という概念がアメリカの食品医薬品局によって提唱されました。「GMP」は品質水準を引き上げることにおいて大きな効果を発揮する概念で、医薬品業界からいまやあらゆる業種で採用されている考え方です。

アポロ計画が開始した頃にはGMPがアメリカの食品工業にもある程度浸透していましたが、NASAが求める100%の安全性を達成することはできていませんでした。そこで発案されたのが「HACCP」という概念で、このHACCPによってGMP単体では足りない残りの部分を埋めることで100%安全な宇宙食の生産が可能になり、NASAはアポロ計画を成功させることができたわけです。
以来、HACCPは欧米の一般の食品工業にも適用されるようになり、今や先進国の食品工業はGMP + HACCPの考え方に基づいて製品を生産することが当たり前になっています。¹

GMPとは

GMPは製造業における品質水準向上・および安定化のための品質管理フレームワークです。Good Manufacturing Practiceの略で、公式な和訳がない²ので意訳すると「良好な生産のための実践」といったところでしょうか。

例えばGMPの項としては以下のようなものがあります。

生産開始前にラインをアルコールで清掃して生菌検査により大腸菌群陰性を確認する
調味液の塩分濃度を測定してN%以下を下回らないことをモニタリングする

1つ1つの作業と密接に関わっており、比較的項目数が多く設定されるのが特徴です。

HACCPとは

HACCPは「100%安全な食品生産」の品質管理フレームワークで、Hazard Analisys(危害分析) + Critical Control Point(重要管理点) の頭文字からそのように名づけられています。
Critical Control Pointは日本語で「重要管理点」と訳されていますが、Criticalという単語の通り、「この項目を守らないと人が死ぬで」ぐらいの意味で捉えた方が正しい理解かもしれません。

HACCPの手順は、Hazard AnalisysをしてCritical Control Pointを定める
これをわかりやすく、かつITに少し寄せた日本語で表現すると

出荷製品が利用者に損害を与える要因を洗い出し、それぞれの損害の重大性を評価する
許容限度を超える損害を与える要因を出荷製品から100%取り除く管理方法を策定する

ということになります。

HACCPはGMPと異なり、作業ではなくスペックと密接です。また一般にGMPよりもかなり項目が少なく、1つでも満たされない場合は出荷停止になる強い管理項目です。

具体的には
- 最終加熱工程において中心温度のサーモ画像が120℃を連続4分間超えることを確認する
- 検出精度0.01mmの金属検知器を通過して検知されないことを確認する
といったものが例として挙げられます。

食品業界の品質管理手法はITでも使える

IT業界に移ってひそかに衝撃を受けていたのですが、IT業界のテストコードって組織によってノウハウや扱いにばらつきが大きいんですよね。例えばテストコードが品質管理よりも対外的な品質保証の色が濃く設計されていたり、そもそも再現可能なテストがなかったり。

しばらくは「そういう業界なのかー？」ぐらいにしか考えていなかったのですが、実際にプロダクトの開発から保守まで経験した後で、今明確に言える事は

テストを書かない or 品質管理的な発想で書かないのは、非常に生産性が悪い

ということです。

今に至るまでテストの書き方を系統立てて学ぶ機会がありませんでしたので有体に言えば我流でテストコードを書いています。作ったものにバグがないかといわれると、バグはあります。（堂々と明言するのもどうかと思いますが…）

ただ、そんなテストを書くのが上手くはない私でも
「食品業界の品質管理手法はITでも使える」
いやむしろ
「食品業界の品質管理手法はITでも使うべきだ」
と提唱してみたいと思っているのです。

さば明太を生産する

さば明太をご存じでしょうか？さばの切り身を味付けして、皮に切れ目を入れたところに明太子を詰めた食品です。
私も最近スーパーで見かけて初めて食べました。さばも明太子もどちらかといえば主張が激しい食材ですが意外とマッチしていて、その秀逸な設計に感激しました。

セブンイレブンとかだと焼いた状態のさば明太も売っているみたいですが、今回例に挙げるのは生の状態でパックされていて、ユーザーがスーパーで買ってきて自宅の魚焼きグリルで調理するタイプのプロダクトです。

このプロダクトの開発にあたっては、どんなリスクを考える必要があるでしょうか？

さば明太エンジニアが考えるべきリスク

リスクを3つのパターンに分けて考えていきます。
- 健康被害を起こすリスク
- 企業の信頼を損ねるリスク
- 今後買ってもらえなくなるリスク

健康被害を起こすリスク

さば明太を食べた人が体調を崩したり、死んでしまったりするのがこのリスクです。
さば明太の場合は

腸炎ビブリオ（海に多いが加熱すればいなくなる）による食中毒
ウェルシュ菌（加熱しても毒素が残る）による食中毒
O157など（高温で加熱すればいなくなるが致死率が高い）による食中毒
さばのヒスタミンによる中毒
明太子の亜硝酸塩による中毒

とりあえずこれぐらいにしましょう。この中でまず
- 腸炎ビブリオはユーザーが半生で食べる等の変な操作をしない限りは大丈夫
なので管理項目からは外してもよさそうです。
他の4つに関してはCCP（重要管理点）としてHACCPに盛り込みましょう。

企業の信頼を損ねるリスク

食べても問題はないのですが、企業の姿勢を疑われるバグもありますよね。例えば

さばがいつもより小さい
切れ込みが小さくて明太子の詰まっている量が少ない
小骨がたくさん残っている
間違ったさばの産地が書いてある

とか、主にフロントエンド側に多い問題でしょうか。産地を間違えているのは法令上も問題があるのでHACCPで対応しましょう。

今後買ってもらえなくなるリスク

システムは使い続けてもらうもの。以下のような点も大事です。

塩味がきつい
さばの漬けダレの香りがよくない
腐ったようなにおいがする

塩味やタレの香り多分漬けダレの調合をミスしない限り酷いことにはならないと思いますが、腐ったようなにおいはちょっと危険な感じがして嫌ですね。HACCP対応にしましょう。

ちょいまち？

今この時点で「HACCPって安全のためなんじゃないの？産地とか関係なくね？」と気が付いた方もいるかと思います。確かにそのような説明でここまで進んできたのでごもっともです。

HACCPの起源は安全にフォーカスしているのですが、実際の食品工業現場では事業継続性を考慮したうえで安全以外の項目をHACCP対象にすることもあります。HACCPフレームワークはリスクの種類にかかわらず、ヤバいものには適用してしまって構わないのです。

HACCPによる管理の構築

HACCPの対象になったのは次の6項目です。

ウェルシュ菌（加熱しても毒素が残る）による食中毒
O157など（高温で加熱すればいなくなるが致死率が高い）による食中毒
さばのヒスタミンによる中毒
明太子の亜硝酸塩による中毒
間違ったさばの産地が書いてある
腐ったようなにおいがする

これらの6項目については完成品に対して
- 一般生菌数の検査
- 大腸菌群の検査
- ヒスタミンの検査
- 亜硝酸塩の検査
- ラベルの目視確認
- 品質管理担当者による臭気の官能検査
を行うこととします。検査によって基準値を少しでも違反したり担当者が不可と判断した場合、製品は出荷されません。

GMPによる管理の構築

ひとまずHACCPフレームワークによって致命的なエラーは防げそうですが、まだ質の高いシステムになるとは言い難いですね。
高品質なさば明太を生産するためには以下のような項目を管理しなければならないでしょう。

加工ラインの衛生状態
スタッフの健康状態
機材の破損、錆、オイル漏れなどの状態
室温と湿度
さばの品質
明太子の品質
調味料の品質
調合されたさば浸漬調味液の塩分濃度など
さばの切り込みの幅と深さ
さばの浸漬時間
さばの浸漬温度
さば投入による調味液の成分変化
さばの解凍から浸漬までの経過時間
さばの浸漬完了から明太子を詰めてパック工程を完了するまでの経過時間
ラップ巻きの状態
ラベルの印字カスレ
ロット番号

HACCPで管理しているリスクもGMPの管理対象になっています。例えばさばのヒスタミンはさばの鮮度が落ちることで蓄積していくものなので、「さばの品質」「さばの解凍から浸漬までの経過時間」などが関係してきます。
HACCPで管理しているからGMPで管理しなくてもよいというわけではなく、GMPで管理しきれないからHACCPでも管理することになっているためです。

さば明太.co.jp

ユニットテストを設計する

ユニットテストはシステムを部品単位で試験するものですが、最小の関数に対して試験項目を設定することも、いくつかの関数を連続で実行して1つの結果を得るまとまりを関数化してテストすることもできます。

ユニットの集合をテストするとインテグレーションテストになりますが、正直どこからどこまでを「ユニット」と考えるべきかよくわかりませんね。。。

ただ、結局はGMPとして機能していることが大事だというのが私の考えです。
まずは全ての工程に基準があること、テスト設計で言えばカバレッジから抜け落ちている処理がないことをまずは考えたらよいと思っています。

カバレッジに加えて持つべき視点は
個々のユニットを考えていくと
- 「加工ラインの衛生状態」のような共通処理
- 「さばの切り込みの幅と深さ」のようにさほど重要ではない処理
- 「さばの浸漬温度」のように超重要な処理
があり、テスト内容にどこまでエネルギーを費やすか？
またリリース判断に対する重みはどうか？という視点。

また
- 「さばの浸漬時間」のような結果に決まった値を期待できるもの
- 「室温と湿度」のような振れ幅があるが制御可能なもの
- 「さば投入による調味液の成分変化」のように外部要因で結果が変わるもの
もあり、これらは繰り返しの回数や入力の範囲考慮が必要か？という視点になります。

さらに
- 「さばの品質」のようなサードパーティー製ライブラリ
は通常ユニットテストには含まれていないと思いますが、GMP的視点から言えば実は大事な要素なので何らかフォローしたいところです。

COCOAの件³もそうだし、私自身もあるシステムを調査してみたらGoogle Map APIの仕様変更で静かにバグを起こしているのを見つけたこともあって、サードパーティー製ライブラリの仕様変更とかって実はかなり厄介な気がします…。

システムテストを設計する

ユニットを繋ぎ合わせたシステム全体としての試験もまた、カバレッジの観点は出てくるでしょう。つなぎ合わせた瞬間に設計上不備が試験失敗としてキャッチされるので、カバレッジはカバレッジで大事だと思います。

一方、システムレベルまで結合してしまうと細かい条件の組み合わせで出てくるエラーまでフォローする試験項目はなかなか設計しにくい印象があります。
だからというわけではありませんが、システムテストでまず大事なことはCCP（重要管理点）の試験項目をしっかり設計することかなあと考えています。少なくともCCPだと思われる項目の試験が簡単なもので済まされていたりすると危ないですよね。

ところでさば明太のHACCP管理項目の中に
- 一般生菌数の検査
のように試験時のコンディションによって結果が振れるものや
- 品質管理担当者による臭気の官能検査
のようにオートメーション化が難しいものがあるように、システムテストもまた柔軟にこなしていく必要があるように思います。もちろんコード化されていてどんな環境でも再現可能なのが一番楽ですが、実際にはそうもいかないことが多いでしょう。

監視と対応措置を設計する

出荷が決まった後でも品質不良のロットが検査をすり抜けていたり、流通経路に思わぬ落とし穴があって想定した品質で食べてもらえないことがあります。

このため食品業界ではロットの一部は冷蔵庫や少々よくない環境で保管されて監視されることがよくあります。また工場直通の窓口がなくてもスーパーなどを経由して商品の異常を察知、リコールに走る仕組みが設計されているのが普通です。

システムもまた試験の想定を外れる状態でのエラーはつきものだと思います。自前でホスティングしているサービスであれば監視しない理由はありませんね。
テスト・監視・異常時の対応措置は別々の部署が設計するケースも多そうですが、試験の段階でリスクが見えているはずなので、モニタリングの設計も進めてしまったほうが効率的だと思います。

マニュアルを設計する

「さば明太を生産する」の中の「健康被害を起こすリスク」で腸炎ビブリオによる健康被害のリスクは切り捨てたのを覚えているでしょうか？
まあ、実際さば明太を半生で食べて腸炎ビブリオにかかったからといって訴えられても、現在の日本の裁判所は製造会社に賠償を命じたりしない気がします。

ただ世の中には明らかにおかしな使い方をする人が実際にいますし、IT業界に来てからシステム開発をしていてもそういう想定をすべきという話はよく耳にしているので、そうなのでしょう。⁴

スーパーでさば明太を手に取ったら商品をよく調べていただきたいのですが、恐らく「加熱してお召し上がりください」とか書いてあるんじゃないでしょうか。⁵

これは試験をクリアした製品であってもおかしな使い方をした場合に大きな被害が出ることが分かっていて、裁判沙汰になれば負けることはなくても企業としてダメージを負う可能性があるから書いているのですが、システム開発においても発想は同じだと思います。

終わりに

さて、ところで今自分が開発しているシステムは宇宙食なのでしょうか？
もちろん宇宙食のようにミスが許されないシステムを作っている企業もあると思いますが、一方では極端に言えば数日止まっても実害のないシステムだって世の中には存在します。

GMP + HACCPが優れているのは、発端が宇宙食の開発だったとしてもあらゆるリスクレベルの食品工業において信頼性と業務効率に寄与してきたことだと思います。

それにしても…今でもIT業界の話よりも食品業界の話の方が文章スラスラ書けるんだよなあ…。
どうなのこれ。

なので厳密いえば私は品管ではない。 ↩
あるにはあるが、歴史に基づいて対応したものを和訳としているので通常の文脈では意味が通らない ↩
Exposure Notifications APIの仕様変更にキャッチアップできなかったため、陽性者との接触が正しく判定できていなかったらしい。色々な角度から批判されているが銀の弾丸がある話ではないというのが個人的な感想。 ↩
システム作る側の人間って、自然にシステムが嫌がる手順を避けるようになる気がするんですよね。なので常識がずれるのかもしれない。 ↩
冷凍された食品の場合は法令要件だがなぜか冷蔵の場合は不要。書いていなくても販売元にクレームは入れないでください。 ↩