WirelessWire News The Technology and Ecosystem of the IoT.

by Category

最適化の経営学と時代遅れのルール

2014.03.17

Updated by Ryo Shimizu on March 17, 2014, 07:08 am UTC

スクリーンショット 2014-02-18 14.50.50.png
 プログラミングの世界には、「最適化(オプティマイズ)」という言葉があります。

 文字通り、プログラムを「最適」な状態にさせることです。チューニング(調律)とも呼びます。
 何にとって最適な状態にするかといえば、マシンにとってです。環境と言いかえてもいいかもしれません。

 一般に、最適化しないブログラムと最適化されたプログラムにはその実行速度や効率において大きな違いが生まれます。

 その効果は何倍になるか見当もつかないほどです。
 


 最適化というものがどういうものなのか、解り易く説明すると、有名なのは「1から100まで足し算した結果を求める」というプログラムがあります。

 普通にこのプログラムを書くと1+2+3+.....98+99+100=5050となります。99回の足し算が必要というわけですね。
 これを最適化すると、101*100/2=5050となります。一回の掛け算と一回の割り算で済むことになりますね。

 なぜ101*100/2が1から100まで足すのと同じかというと、1+2+3+...98+99+100と、その逆の100+99+98+...3+2+1を足し合わせると、101(1+100)+101(2+99)+101(3+98)+.....101(98+3)+101(99+2)+101(100+1)=10100ということになり、これは二つを足し合わせたものなので、最後に2で割ると正しい答えが出てくる、という考え方からです。

 今のコンピュータでは、足し算を100回くらいしても屁でもないので、あまり意味のある差にはなりませんが、仮にこれを1000万回繰り返すとすると、筆者の手元のコンピュータでJavaScriptでやったところ、100倍近い計算効率の差があることが解りました。計算回数がそのまま差となっているわけですね。

 この最適化は、ガウスという数学者が子供の頃に考えたそうです。
 最適化すると全く同じハードウェアで全く同じ演算結果を得るのに100倍もの差(場合によってはもっと)が得られることは良く知られています。

 ところが、最適化には大きな副作用があります。それは、最適化されたプログラムを読んでも何が書かれているかよくわからないということです。

 たとえば先ほどの1から100まで足す、というのをプログラムで書くと

 n = 0;
 for(i=1;i<=100;i++)   n=n+i;  となります。なんとなく、i=1とi<=100をみれば、プログラムに詳しくない人でも、「1から100までなにかするんだな」ということは解ります。ループの中身も、「n=n+i」しかないので、足し算を繰り返しているのだということはわかります。  ところがこれを最適化すると   n=101*100/2;  これが何を意味しているのか、サッパリ解りません。また、これは最適化として不十分です。なぜなら100/2は毎回でてくるので、予め割った数字を入れておくべきだからです。従って   n=101*50;  となって、さらに意味がわかりません。いや、むしろ  n=5050  が本当の意味の最適化です。  計算するのではなく答えを先に入れておく。これは速いに決まっています。  ただし、仮にこのようなコードがプログラムの一部に入っていたとして、それだけを見ても何が起きてるかはわかりません。また、1から100ではなく、1から15とか、1から2000まで足すような汎用的なプログラムが必要になったときに、n=5050とだけ書かれていると、どうすればいいのかわからなくなります。  そこでこのプログラムを抽象化してみましょう。  最適化を全くしない1からxまで足すプログラムは以下のようなものになります。  n = 0;  for(i=1;i<=x;i++)   n=n+i;  さっきの100がxになっただけですね。わかりやすいです。  これを最適化すると以下のようになります   n=(x+1)*x/2;  これで抽象化できました。  ところが1からxまで足すのではなく、1からxまで引くとか、1からxまで乗算する(数学で言えば階乗ですね)プログラムを書こうと思うと、このガウスの最適化は全く適さなくなってしまいます。最初のforループを使うやり方なら  n = 1;  for(i=1;i<=x;i++)   n=n*i;  と、「+」を「*」に変更するだけで済むというのに、です。  こういう、「あとからコードの動きを追いかけたい、あとからコードを部分的に変更して使いたい」という目的のためにプログラムが読み易い状態で保たれているコードを「保守性が高いコード」と呼びます。  ただ、昔のコンピュータは動作が全体的に遅かったので、場合によっては、保守性を犠牲にしてでも最適化をしてコードを高速化する必要があったのです。  家庭用ゲーム機の世界で最適化と言えば、プログラマーの腕の見せ所でした。  数々のプログラマーが己の知恵を絞り、非力なマシンの性能を限界まで引き出してプログラミングしたものです。有名なのは「ドラクエ」こと「ドラゴンクエスト」の初代版では、カタカナが50音全て用意されていなかった、というものがあります。  メモリーが小さくてそうした文字がとても全部は入りきらなかったのです。  そこで名前を工夫することにより、なんとか物語を表現したというわけです。これも立派な最適化です。  ある事象が起きている時に、その時点で「ああダメだ」と諦めず、いまある道具だけでやれるところまでやってみよう、というのが最適化の根本にある信念です。  さて、ところが今日はすっかり最適化というのが軽視される時代になってきてしまいました。  保守性という金科玉条があれば、わざわざ最適化にアタマを悩ませなくてもプログラムを書くことが出来るからです。我々に言わせれば軟弱な、しかし保守性の高いコードが今日も量産されています。もちろんゲームプログラミングの一部の世界では未だに最適化に凌ぎを削る世界が残っていますが、残念ながら今は小数派と言って良いでしょう。  皮肉にも、筆者らが開発し、普及活動をしているenchant.jsにしてからが最適化を不要にしたままゲーム開発できることを目標にしています。  経営の世界では、最適化は命綱です。  たとえば問屋を通さない直販流通や、ファミレスのセントラルキッチン方式は最適化の一つの例です。  トヨタのカンバン方式などは企業が最適化を継続するための工夫であるとも言えます。    経営の最適化とは、時代にあわせて変化をし続けること、また変化を受け入れることを意味します。  ところが経営の世界では、逆に保守性が軽視されていることが少なくありません。  つまりなぜそうなったのかわからないルールや、時代遅れなルールが未だに成立したりしています。  たとえば病院内で携帯電話の電波を出しては行けない、というルールもその一つです。  携帯電話がまだ大出力の不安定な電波を出していた頃、病院内の機器がそうした環境下で正常に動作できるか保証できなかったため、病院内での携帯電話の使用は制限されていました。  未だに待合室でメールすら見てはいけない、という病院は少なくありません。  もはやとっく意味がなくなっているのに、ルールのためのルールとして放置されているのです。  東大病院など、一部の大病院では、携帯電話を使用しても良いエリアというのがあり、そこまで移動すれば使っても良いことになっています。これはこれで合理的ではあります。  しかしいまどき、携帯電話の電波で影響を受け、誤動作するようなペースメーカーや医療機器があるとすれば、そっちのほうが大問題です。医療機器メーカーの知人によれば、たいていの機器はとっくに携帯電話の電波などから干渉を受けないことは確認されているが、世の中にまだまだ残る、古い機材で確認が完全にとれていないため、どうしてもこのルールは残ってしまうそうです。  似た話で、飛行機の中での携帯電話の使用ルールというのがあります。  筆者は以前からこれが大変不愉快でした。  離着陸など、不安定な姿勢のときにPCを出してはいけない、というのは解ります。  しかし、機内でのBluetoothやWiFiなど、電波を出す機能は一貫してNGでした。  だけどそんなわけはないのです。  WiFiごときで飛行機が安全に運行できなくなるとしたら、そっちのほうがよっぽど問題です。  テロリストに爆弾はいらずWiFiルータだけ持ち込めれば飛行機の安全を脅かすことができるなんてかなりおかしな理屈です。もちろんWiFiなんかで飛行の安全が脅かされるわけはないのです。  少し前のニュースですが、連邦航空局が機内での個人用電子機器の利用制限を大幅に緩和しました。

 これも、個人用電子機器がとても珍しい時代に定められたルールで、時代の変化とともにとっくに意味がなくなっていたにも関わらず、「ルールだから」という理由で愚かにも守られ続けていた慣習でした。

 こうした時代遅れのルールは利用客に一方的に不便を押し付けるだけで、それが経営の差別化要因になっている、と看做されない限りは放置されがちです。

 それどころか、そもそも「なぜそのルールが出来たのか」「そのルールは現代に最適化されているのか」という観点が抜け落ちているので見直そうという声がなかなかでてこないのです。

 また、いざ見直そうとしても、どこから手をつけたらいいのかわからない、ということになります。

 しかし全てのルールには理由があり、どれだけ意味のわからないルールであろうと、それが作られた背景があるのです。そしてその理由を知らなければ、ルールを時代にあわせて改善していく、再度の最適化をしていくということができなくなります。企業は自らが必要に応じて定めたルールによって硬直化し、進歩への気力を次第に奪われて行くことになります。

WirelessWire Weekly

おすすめ記事と編集部のお知らせをお送りします。(毎週月曜日配信)

登録はこちら

清水 亮(しみず・りょう)

新潟県長岡市生まれ。プログラマーとして世界を放浪した末、 '17年にソニーCSLとWiL LLC.とともにギリア株式会社を設立し、「ヒトとAIの共生環境」の構築に情熱を捧げる。 '17年より東京大学先端科学技術研究センター客員研究員を兼務。著書として「教養としてのプログラミング入門(中央公論社)」「よくわかる人工知能 (KADOKAWA)」「プログラミングバカ一代(晶文社)」など。

RELATED TAG