トヨタの品質管理には、自動化（Automation）とは異なるニンベンの付いた自働化（Autonomation）という概念があります。海外でも英語でも判別できるように異なるスペルが存在します。日本語では同音異句なので、口頭では英語の方が分かりやすいでしょう。

この違いを抑えておくと、ソフトウェアの品質向上に繋げられると考えているので、広めるためにもこの記事を書きました。

なお、トヨタ関連の本は読んだことは無く、インターネットの情報をまとめているだけなので、トヨタ情報に関しては誤って発言している可能性はあります。ご了承ください。

対象

品質を高めたい人
知識を深めたい人

意味

それぞれの単語の意味を引用します。

自動化（Automation）

weblio辞書：IT用語辞典バイナリ引用

オートメーションとは、ある機構や機器が、人手の介入を要することなく、自動的に制御、動作、連携することである。あるいは、そのための技術のことである。

オートメーションによる機械的な制御が実現されると、長時間連続して稼動させても、生産物が均一の品質、生産ペースを保ち、個体差が発生しなくなる。また、人手の介入を必要としないため、ヒューマンエラーが発生する余地もなくなる。オートメーションの導入・実現は、このように、各種業務効率や安全性を大幅に向上させることを可能とする。最近はコンピュータ制御によってシステムが一層複雑化している。

オートメーションのうち特に、製造業において、一連の工程をロボットに行わせる形態が、FA（ファクトリーオートメーション）と呼ばれている。また、オフィスにおける事務処理や管理業務において作業をオートメーション化する機器は、OA（オフィスオートメーション）と呼ばれている。

自働化（Autonomation）

weblio辞書：OR辞典引用

自働化とは, 機械に人間の知恵を付与することであり, 良品のみを生産する理念である. すなわち, 異常を自動的に検知して停止する自動機械, さらには不具合が発生すれば作業者がラインを停止させ, 再発防止のための改善を行う生産ラインを生み出している. この理念は, 発明王豊田佐吉(1867年-1930年)によるものであり, 縦糸が切れると自動的に停止し, 横糸は自動的に補充されるG型自動織機(1925年完成)で実現されている.

意味の違い

自動化
- 人が介在しないように作業を機械に置き換えています。
- 不正な挙動をした時は、後続の処理をします。
  - 想定外のデータに対してデータパッチをあてる必要がある。
  - 処理を止めないので、機会損失は少ない。
自働化
- 人が介在するように作業を機械に置き換えています。
- 不正な挙動をした時は、後続の処理をしません。
  - 想定外のデータが登録されることが無いので、データパッチ等の作業はない。
  - 処理を止めてしまうので、機会損失が発生しがち。

自働化という概念は、不良品が生まれ続けることによるムダを最小限にするという考えから生まれています。物理的なムダもそうですし、後で不具合を取り除くよりも、不具合の発生した時点で取り除く方が工数を削減できるでしょう。

ソフトウェアのV字モデルでも、後で発覚するよりも最初に発覚する方が工数削減できますからね。

自働化を進めるには

ソフトウェアで自働化を進めるには、3つが必要です。

エラーを検知できる仕組みがあること
エラー発生した断面を記録できること
高速にリリースできる仕組みがあること

エラーを検知できる仕組みがあること

当たり前ですが、エラーを検知できる仕組みが無ければエラーと検知できません。

ZabbixやPrometheusやMackerel等々でサーバを監視しましょう。

エラー発生した断面を記録できること

「よく分からないけど壊れた」というのが一番怖いです。データが不整合を起こしている段階ですぐにアラートを発砲したり、エラー発生した行を出力しましょう。throw Exceptionをしたせいで、エラー発生した行が判別できないパターンがたまにあります。「ぬるぽ」とか、発生行が原因行が異なるケースいっぱいあります。

また、エラー時の画面を出力できる仕組みも欲しいです。私は使用経験が無いのですが、フロントのエラーを取得するSentry等々のツールもありますので、いつ壊れたかは確認できるようにしたいです。

あと、障害が発生したタイミングのDBのスナップショットを取得するツールもあります。ただ、こちらのツールはかなり高価です。知ってるツールとしてはアシスト様のDelfixです。

2014年の記事ですので、現在はもうちょっと高いでしょう。

4vCPUライセンス
- 年額998万円
8vCPUライセンス
- 年額1900万円

価格が書いてあるページ。

アラートが出たタイミングで、AWSのRDSのスナップショットをCLIで取得したり、Dockerのコミットで障害時のDBの状態がわかるようにしている現場はあるんですかね。

私は知らないので、そういうアーキテクチャの仕組みを記事にする・既に実施しているような記事を教えていただけると助かります。私が非常に知りたい。

高速にリリースできる仕組みがあること

後続処理ができないので、機会損失は起きてしまいます。

発生した場合は即座に対応し、アプリのリリースをする必要があります。

リリースに1週間かかる、という状態だと話にならないので遅くとも当日中に対応できるような仕組みになっているべきでしょう。

マスタドリブンで処理を持たせる方法であればアプリのリリースは不要ですが、マスタドリブンは分岐処理をアプリの外側に持つことになるのでテストができません。その点が私は好きではないです。リグレッションテストもしづらいですし、バグが埋め込まれても気付けません。

とはいえ現実的に…

可能な限り自働化を進めていくべきと考えていますが、現実的には厳しい点もあります。

自働化では、高速に開発者が対応できる環境が必須です。受託開発して運用は別の会社だという場合は、高速で対応するということが難しいです。そうでなくても、親切心でいれたバリデーションが誤っていて、修正工数がとられてしまった経験がある人は、仕様に含まれていない限りは二度とバリデーションを入れないのではないでしょうか。

データ保護のために開発者と運用者は分けるべきだという現場も、高速対応は厳しいでしょう。

総合工数が削減できると言われても、機会損失は1回でも発生するのは嫌と言われたら導入は難しいですね。

あとは、余計な対応してしまう恐れもあります。作成時は問題なくても、連携先システムの改修で不整合を許容するようになったりすると、こちらも対応しなければなりません。

自働化は開発者も積極的にシステムに関わるDevOpsの概念とは相性がいいのですが、現実問題はそう上手くいっていないケースがソフトウェア世界では多いように感じています。