前回の記事で、「安全は創発性であり、創発性は要素の知識からは演繹されえない」、「演繹できないような問題に対するエンジニアリングは難しい」ということを書いた。
それを書きながら、AI（機械学習）のことを連想した。
機械学習の品質確認の難しさ
機械学習を「帰納的プログラミング」、従来のプログラム開発を「演繹的プログラミング」とする対比がよくされる。
「機械学習工学に向けて」（丸山宏, 日本ソフトウェア科学会第34回大会）では、摂氏を華氏に変換するプログラムを例にとり、以下のような分かりやすい対比を示している。
- 演繹的プログラミング： "F = 1.8 x C + 32" という変換式（先験的知識）に基づくモデルから、段階的に詳細化し実装を得る。（※ Fは華氏温度、Cは摂氏温度）
- 帰納的プログラミング：摂氏と華氏の２つの温度計を用意し、それらの値を同時に読み取ることで「訓練用データセット」を得る。それを対象として機械学習アルゴリズムを適用し、モデルを得る。そのモデルを用いて摂氏を華氏に変換する。
作られたソフトウェアが「正しいかどうか」を確認するには、「正しさの基準」が必要になる。
もう少し慎重な言い方をすると、「『正しさの基準とされるもの』があれば、正しいことの確認がやりやすい」ということが言える。
演繹的なプログラミングであれば、上記の例の "F = 1.8 x C + 32" という式のような先験的知識があり、それが正しさの基準となり、品質確認の拠り所となる。
例えば、テストを行う際に、この式を用いてテストオラクルを作ることができる。または、「正しさの基準」から段階的に詳細化することでプログラム実装する、そのプロセスの妥当性（詳細化の正確さ）を評価することで、実装されたプログラムの正しさを評価することができる。
「ソフトウェア工学」は、高品質なソフトウェアを効率的に開発する方法論として確立されてきたものであり、工学（Engineering）として科学的なアプローチを目指す。したがって、上記のような、正しさの基準に基づく論理性、客観性が成立することは非常に都合が良い。
しかし、機械学習は演繹的ではない。"F = 1.8 x C + 32" のような正しさの基準がない。
逆に言えば、この式のように、入出力の関係性が明確で固定的である場合は、演繹的なプログラミングが可能なので、機械学習を使う必要がない。
したがって、機械学習を適用する場面では、多くの場合、以下のことが言えるであろう。
- 入出力の関係性が明確に分からない
- 入出力の関係性が時間とともに変化する
１つ目の「入出力の関係性が明確に分からない」とは、「入力に対してどのような出力が期待されるか」の因果関係の定式化は難しい、ということである。
２つ目の「入出力の関係性が時間とともに変化する」とは、ある時点では正しいと思われる入出力の因果関係が成立していても、時間経過とともにその因果関係が正しくなくなる場合がある、ということである。
このような性質を持つ「機械学習」の品質保証は、厄介だ。
機械学習の性質を踏まえた、機械学習用のソフトウェア工学が必要であるとの認識が高まり、「機械学習工学」に関する取り組みが熱心に行われている。
機械学習の品質とシステム安全の類似性
ところで、上に書いた「機械学習の品質保証」を、「演繹的に解決できない問題を対象とした品質保証」という風に抽象化すると、「システム安全の評価を如何に行うか」という課題との類似性を感じる。
上に書いた「入出力の関係性が不明確」という性質について、「入出力の関係性」を「システムの構成要素とシステム安全の関係性」と置き換えると、共通性が見えてくる。「システムの構成要素がこうだから、システム全体の性質（安全性）はこうなる」という因果関係の定式化は難しいということだ。
同様に、「入出力の関係性が流動的」という点も、システム安全においても言える。システムが稼働する環境は常に変化しているので、ある時点で安全を確認しても、時間経過とともにそれが通用するとは限らない。機械学習では、運用中に精度の変化を監視しながら、モデルの再学習の検討を行うべきであるとされている（MLOpsの考え方）。システム安全でも同様に、「SafetyOps」のような考え方が必要かもしれない。
前回の記事に、システム安全のための「エンジニアリング」は難しいと書いたが、機械学習のための「エンジニアリング」も同様に難しく、その底には共通性があるように思われる。
「飛んだ」発想 － モノづくりの本質的な難しさ
このように、システム安全と機械学習の類似性を考えていると、つい、極端な考えを膨らませてしまう。
「上に書いたようなことは、モノづくり全般にいえるのではないか？」
「モノづくり」とは何か。ちょっと調べてみると、オーソライズされた定義が確立されているわけではなさそうだが、単に「ものを作ること」だけではなく、
「それによって人間が幸せになることを期待して、ものを作ること」
と言えるのではないかと思う。
人間が日々行う、大小取り混ぜたあらゆる活動は、すべて、「幸せになることを期待して行う」と言えるのではないか。それは、「人間はなぜモノづくりをするのか」の究極的な理由にもつながると思う。
モノづくりをそういうものだと考えたとき、では、「幸せ」とは何か？
客観的な定義は難しいし（多分に主観的なもの）、こうであれば幸せだ、という因果関係を定式化することは不可能であり、時間的な変化もある。
モノづくりの品質とは、「それによって幸せになれるかどうか」だとすると、それを「科学的に」確保したり評価したりすることは、とてつもなく難しいことに思える。
しかし、何らかの科学的な（属人性が低く、再現性の高い）方法がないと、分業化や大量生産が難しいので、科学的なアプローチ（エンジニアリング）が考えられてきた。
ソフトウェア開発で言えば、「こんなことができたら嬉しい（幸せだ）」という要求・願望に対して、その実現に必要な「要件」を客観的な表現で定める。それを「正しさの基準」として、ソフトウエアを設計し実装する。このようなやり方を前提として「ソフトウェアエンジニアリング」を確立してきた、といえる。
しかし、問題は、「こんなことができたら幸せだ」という願望と、定義した要件が合っているかである。
冒頭の例のような、「華氏温度を摂氏温度に自動変換できたら嬉しい」という願望であれば、それを満たす「要件」は比較的ダイレクトである。そこに齟齬は生じにくい。
ソフトウェア産業の発展初期の時代には、「OA化」という言葉があった。OAはオフィス・オートメーションであり、従来手作業で行っていた事務処理を「電子化（ソフトウェア化）」するというニーズがたくさんあった。従来、手作業で行っていたことなので、「どういう場合に、どうなれば嬉しいか」という「正しさの基準（幸せの定義）」が明確であった。
したがって、「電子化（ソフトウェア化）」が目的であるようなソフトウェア開発では、エンジニアリング（科学的なアプローチ）も比較的考えやすかったと言えるのではないか。
しかし、時代は変わり、ソフトウェアに期待される役割も変わってきている。ソフトウェアがなければ実現不可能であるようなビジネスやサービスを作りたい、というニーズが増えている。既存のものの「ソフトウェア化」ではなく、新しいビジネスの「付加価値創造」イコール「ソフトウェア」といってもよいようなニーズが出てきている。そこでは「正しさの基準」が明確ではなく、したがって「要件」もすぐには決まらない。
「こんなことができたら嬉しい」という主観的な「幸せ」を模索しながら、それを満たすソフトウェアを模索するような感じになる。
このような目的で作られるソフトウェアの品質を、どのように評価・確保すればよいのだろうか？
こう考えてくると、「ソフトウェア化」を想定した品質保証の方法論（演繹的プログラミングを想定した従来のソフトウェア工学）は、むしろ、特殊な状況を前提としたものだったというべきなのではないか、と思えてくる。時が過ぎ、本来のモノづくり（=今ない価値を創造して幸せになるためのモノづくり）に即したソフトウェアづくりがされるようになってきた。機械学習の登場は、その具現化を後押しした。機械学習の品質保証が今課題になっているのは、象徴的な現れである。そう、思えてくる。
作ろうとするシステムの複雑性が増し、従来の「安全工学」では不足となり、STAMPのような考え方が提案された。同様に、ソフトウェアに期待される役割が「〇〇のソフトウェア化」から、「新しい価値の創造」に変わり、従来の「ソフトウェア工学」の不足感が見えてきた。両者の流れには、共通性を感じてしまう。
あえて究極的に言ってしまうと、次のように感じる。
「モノづくりの品質保証」というのは、本質的には、科学的な（属人性が低く再現性が高い）やり方が難しいのではないか？
その難しさに対して、これまで、工学的な方法論が適用できる落としどころを確立し、なんとか対応してきたということではないか？
今の時代、「こんなことができたら嬉しい」という人間の願望レベルは高まり、それを満たすような「モノづくり」の複雑さも高まり、従来考え出された「工学」では不足になってきている。「モノづくりの本質的な難しさ」が、いよいよ顕在化してきた、といえるのではないか。
これは、人類に突き付けられた大きな課題なのではないだろうか。「程度問題」ではなく、「解決すべき問題の質が変わった」ということ、少なくとも、「既存の工学では対応しきれない時代になった」ことの認識はすべきではないか。（既存の工学の延長線的応用で、なんとか対応しようとする方向に努力を傾けるよりも。）
これは、既存の工学に携わり、発展に貢献されてきた方々に対しては失礼な物言いになるかもしれない。しかし、物事の流れをぼんやりと眺めていると、上記のように感じられてくる。
システム安全の分野における STAMPの考え方の登場は、上記のような課題への対処の一例として位置づけられるのではないか、と思える。そして、STAMPの考え方の底にあるものは、様々な同様の課題に応用できるのではないか、と思える。
