「最適」への終わらない旅

昔の話ですが、ある研究開発案件の企画資料を作成しているときに、企画説明文内の「〜の通信経路を最適化する」というフレーズをソフトウェア開発の大先輩であるYさんに見咎められました。

「最適というのは難しいよ」

この案件では、多数の通信経路の中で、制約条件を考慮し、最短となる経路を探す仕組みを作ろうとしていました。Yさんがおっしゃるには、一定の範囲の中で最短というのは導くことが可能だが、それが「最善」なのかどうかを証明するのは骨が折れるとのこと。

それを聞いて、目から鱗が落ちる思いでした。

私は、「改善する」くらいの軽い気持ちで「最適化」という言葉を使っていました。ですので、従来の方法に比べてより良い答えを出すことが出来ればそれで良いと考えていました。

ソフトウェア開発の用語で「最適化」という言葉があります。英語の”Optimization”（動詞で言えば”Optimize”）の日本語訳です。コーディングの際に「このコードを最適化します」と言えば、従来よりも改善できればOKで、それが「最善」かどうかまでは考えないのが一般的です。

一方で、数学用語に「最適解」という言葉があります。
これは、与えられた条件（制約）の中で、目的関数を最大化する解のことです。
つまり、最適解は特定の値に定まることになります。
こちらのニュアンスで考えると、「最適化」という言葉は安易に使うことは出来なくなります。

その後、「最適化」という言葉の使い方には慎重になりました。
ただ、自然言語は人によって用法や解釈の差があるのが当たり前で、厳密に定義づけられるものではありません。真に最適な状態までいかなくても、それに少しでも近づける行為を「最適化」と呼んでも良いと思っています。

加えて、ソフトウェア開発の世界では、最適化にトレードオフの考え方が絡んできます。

子どもの頃読んでいたコンピュータ雑誌の記事にこんなチェックリストがありました。

どんなプログラムもあと1バイト短くできる yes/no
どんなプログラムもあと1クロック早くできる yes/no

当時はメモリサイズが非常に限定されており、速度を犠牲にしてメモリ消費量を減らすことはよくありましたし、逆に速度を重視して冗長なコードを書く場合もありました。
つまり、速度最適化、メモリ最適化のように、目的によって何が最適なのかは異なり、トレードオフの関係にあるため、唯一の最適解というのは存在しません。

私はどちらもyesと答えました。考えてみると、yesというのは変な回答で、突き詰めるとプログラムサイズや実行時間が0になるので論理的に破綻しています。
ただ、上記の質問は真面目な設問というよりも、半分ジョークのようなもので、プログラマーとしてそのような心構えで最適化を突き詰めていくべきだということを学ばせてもらったと思っています。