毎日野菜を摂取するようにいいニュースを継続的に摂取

私は、なるべく野菜の多く入ったメニューを意識的に選ぶようにしているのだが、それと同じような感覚で、毎日、Enlightenment Nowという本を少しづつ読んでいる。

Enlightenment Now: The Case for Reason, Science, Humanism, and Progress

Enlightenment Now: The Case for Reason, Science, Humanism, and Progress

これは、まだ日本語訳は出てないが、このブログに、章ごとの詳細な要約がある。

B073TJBYTB の検索結果 - shorebird 進化心理学中心の書評など

「ファクトフルネス」と似たような本だが、もっと厚くて「どう言う観点から見ても世界は良くなっている」としつこくしつこく言い続けてる本だ。

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

「ファクトフルネス」は、この伝わりにくいメッセージをどう伝えたらいいか誠実に考え抜いて練りに練ったもので、読者を自分の仲間にしていこうという優しさを感じるが、スティーブン・ピンカーは、なんだかちょっとキレ気味で、読者は論争相手だと思っているみたいだ。宮本武蔵が寝てる時に刺客に襲われても軽々やっつけてしまうように、ピンカーはいつ何時どこから反論されても、即論破して相手には情けをかけず一刀両断する。その分だけ、常に油断なくデータから実証的かつ多面的に論じていて、ぶ厚い本になっている。自分の目的にはこちらの方があっている。

「野菜は年に一度だけ食べません」とか言ったら、来年の健康診断の時に、栄養士さんに栄養指導の時に、相当怒られると思う。私は、数年前から健康診断の時に「栄養指導」といって、栄養士さんの面接を受けて、一週間分の食事のメニューをチェックされているのだが、ラーメンとか甘いものが多いとネチネチとしつこく注意を受けてしまう。

「それが好きだから」と言ってももちろん許してくれなくて、「あなたの体のために、少しだけ我慢して、なるべく野菜の多い定食とかを選びましょう」と言われる。言い方は丁寧だけど、有無も言わせぬ圧迫感で言われるので、この指導の時間が苦手だ。

感情的には納得できてないのだけど、この指導が必要なことはわかっている。自分の体は狩猟採集で10万年生き抜いた原始人のDNAからできていて、甘いものや油物がめったに手に入らない環境に最適化されている。だから、本能は「そういうものは全て摂取せよ」と命じるのだけど、現代の生活ではそういうものがいくらでも手に入るので、その本能を押さえて行動を変えなくてはいけないのだ。

「ファクトフルネスを一冊読んだら、当分その手の本を読みません」というのはダメだと思う。「Enlightment Now」はぶ厚いし、英語なので、1日数ページしか読めない。そこが自分にはちょうどよくて、毎日、毎日少しづつ読む。

自分の頭は、部族の中で10万年生き抜いた原始人のDNAからできていて、悪いニュースがめったに手に入らない環境に最適化されている。だから、本能は「そういうものは全て摂取せよ」と命じるので毎日毎日はてなブックマークツイッターを読んでしまうんだけど、その本能を押さえて行動を変えなくてはいけないのだ。

「Enlightment Now」には、各章にグラフが二、三個あって、もちろん全部データの出所が明らかになっている。グワーンと右肩上がりになるやつと、ふらふらしつつも長い目で見るとジワジワ下がってるやつかどちらかで、どのグラフも執拗に世の中が平和で安全になっていることを示している。こういう話はなかなか頭に入ってこないので、一年くらいかけて読み終えたら、もう一周しようかなと思っている。

ファクトチェックというより、必要なのは栄養指導だ。原始時代に、何かが毎年少しづつ良くなって、30年くらいで複利計算して倍増とか数十倍なんていうものはなかった。だから、そういう変化を見れないように人類ができているのは、よく考えてみれば当たり前のことだ。テロや通り魔や航空機事故は、「その辺にライオンがうろついている」という情報と相似形で、油物や甘いものと同じように我々をひきつけるし、摂取されたら長く人体の中に蓄積する。

でも、実際に今世の中を動かしているのはいいニュースで、「世の中は少しづつ少しづつよくなっていて長い目でふりかえって見るとその蓄積は相当なものだ」系の情報を基盤として考えることが、功利的にも実存的にも絶対必要だと思う。もちろんなにごともバランスは重要だが、今時、悪いニュースに不足するなんて心配はまず無用だろう。

21世紀には暴力のない「死」をイマジンしたい

「イマジンが20世紀を代表しているような意味で、21世紀を代表できる音楽」というのは面白い問いかけだと思って、少し考えてみたら、これを思い出した。

www.youtube.com

( ↑YouTube Premiumに登録するとみれます。今だと一ヶ月無料なので、登録してすぐ解除するのがオススメ)

この短いクリップの中で、コムアイはなんども「死と再生」を繰り返すのだけど、その「死」に少しも暴力の香りがなくて、エネルギーだけがあるのが新鮮で21世紀的だと思う。

そして、この音楽の中で、テクノロジーと自然が見事に融合している。

「融合」というのは、境界を壊すことだから、いかなるかたちでもいつも暴力的で、それは僕たちが境界を守ろうとしているからだ。境界を守ることが「生」であって、その努力を粉砕するのが「融合」であり、国境のない世界だ。「イマジン」が暴力的な言葉を喚起するのは、だから必然かもしれない。

しかし、「屋久の日月節(やくのじつげつぶし)」のミュージックビデオの中には、それがない。コムアイは菩薩顔で大地に溶け出し、またよみがえり、蘇るとまたすぐ死ぬ。すぐ死ぬことが重要で、「死」が次の「生」のタネにしかならないのは、暴力的だと思う。そういうのではなくて、「生」と対等の関係にある「死」が描かれている。

テクノロジーがそういう「死」に対して中立的であり、そういうタイプの「死」を表現するために使えるというのが、驚きだった。境界を守ろうとしてない人たちにとっては、テクノロジーはそういうもので、中立的なのだろう。そこに21世紀の可能性があるのだと思う。

Webの次はすでにいつでもそこにある

Webが死につつあると最近よく聞くようになってそうかもしれないと思いかけたが、IPFSを知って考え直した。

と言っても、IPFSがHTTPを置き換える未来を確信した訳ではない。ホワイトペイパーを眺めてみて、「最近は革命もお手軽にできるようになったもんだな」と思ったからだ。

IPFSの構想は壮大だが、その技術はすでによく使われているものの使い回しだ。DHTベースのP2P, BitTorrentベースのファイル転送、gitとほぼ同じデータ構造の組み合わせで、Filecoinという仮想通貨ベースのシステムで、データの永続性のためのインセンティブを与えるということらしい。

実装に使われたGo言語も含めて、全てしっかり実証された技術だけを使っているので、これはうまくいくだろうと思った。

しかし、たとえば、公開鍵暗号とか表計算のような、本物の天才のヒラメキは感じない。誰でも思いつきそうだし、ちょっと腕のある人なら誰でも実装できそうなものだ。この組み合わせがうまくいくなら、これを作った人は天才と呼んでもいいかもしれないが、公開鍵暗号の発明が数十年に一人の天才だとしたら、こちらは、一年に一人とも言えなくて、一年に10人くらいは、これくらいの人が出てきてもいいように思う。

でも、一年に10人くらいのレベルのそれくらいの天才の人にとって、今は、とても仕事がしやすい時代なのだと思う。DHTとBitTorrentとgitがすでにあって、その技術はソースコードレベルで公開されていて、それくらいの人なら、一瞬で自分の武器として使える。

つまり、世界は特異点を越えたのだ。特異点とは、ターミネータが人類に反逆する日のことではなくて、AIがAIを賢くする正のフィードバックがかかり始める日のことで、それと似たような意味で、過去の天才の成果物が現在の天才を支え、その現在の天才の成果が、明日の天才を超加速する、そのフィードバックが止まらなくなる日だ。

Webの未来を予測するには、衆愚の行き着く先ではなく、1年に10人くらいの天才のやることをウォッチすべきだ。数十年に一人の天才は、いつ生まれるかわからないし、何をするかわからない。でも1年に10人くらいのレベルだと、そういう人が継続的、安定的に生まれてくることは確実だ。そういう人たち同士の相互作用が、これからすごいことになって、IPFSくらいのレベルのプロジェクトを次々起こしていくというのが私の予測だ。

そういうものがどれくらい使われるようになるかは、GAFAがどれくらいEvilになるかにかかっていると思う。

GAFAが、何もしなくても今の独占的地位を保っていられると思うのが間違いだ。GAFAは、こういうIPFSのようなプロジェクトに追われているが、それに負けないくらいの勢いで革新し続けているので、今の地位を保っている。Evilになる暇はないしそれはよくわかっていると思うが、もし仮にEvilになれば、一瞬でそういう新顔に抜かれてしまうだろう。

GAFAが世界を支配しているそのすぐ下に、ダイナミックで不安定なレイヤーができていて、この層の厚みが一方的に増して行くというのが、これからの世界だ。これはプログラマだけに見えるいびつな世界観なのだと思うのだが、ご承知のようにソフトウエアは世界を飲み込むので、この世界観がスタンダードになるべきだと思う。

Webが使いづらくなったら、IPFSのような別の選択肢が注目を集め、注目を集めれば一瞬でスパークするだけの潜在的能力を持ったプロジェクトは他にもたくさんある。

そして、それらの屍をサーベイして、さらにいいものを作るであろう1年に10人レベルの天才は、今も生まれ続けている。その人たちは、IPFSの時よりもっと豊富な過去の成果をスタート地点として仕事を始めるのだ。

衆愚とGAFAだけ見ていてはWebの未来はわからない。そこに割り込んでいくる中くらいの天才の集団(の予選を勝ち抜いた人)の動きが最も重要で、むしろそれが一番重要なファクターになる特異点を越えたような気がする、というのが、IPFSを見て感じたことだ。

だから、Webがこれからおかしくなって崩壊することは充分あり得ると思っているだけど、それを待ってそこから飛び立つ人を世界はこれから必要以上に供給し続けると私は思う。それは感情的な希望的観測ではなくて、物理学の法則のようなメカニズムとして、何かが確立したような気がする。

武勇伝を忘れる勇気


オリエンタルラジオ 武勇伝

  • 「あっちゃん、渋谷まで山の手線で一本だな」
  • 「いやだ!」
  • 「じゃあ銀座線」
  • 「いやだ!」
  • 「じゃあ半蔵門線
  • 「いやだ!」
  • 「じゃあ埼京線?」
  • 「いやだつってんだろう!」
  • 「どうして!」
  • 「誰かの敷いたレールの上を走るなんてもうまっぴらなんだよ」
  • 「あっちゃんキャッコイイー!」

日本では、公的なルールというのは、誰にでも平等に適用され、誰もが真剣に守るものではなくて、常に適切なポイントより少し前に置かれる線である。

制限速度が40kmだったら、誰もが39km以下で走るわけではなく、それよりちょっと上の45kmとか50kmで走る。40kmピッタリで走ることは、どちらかと言えば顰蹙を買う行為で、悪くすれば煽り運転とかのひどい目にあう。

ルールというものはそういうもんだということを、学校の中にいる間に体で覚える。校則や先生の言うことをきちんと守る奴は、どちらかと言えば、ガリ勉キャラや風紀委員キャラとして嫌われる危険性が高い。人気があるのは、それをちょっとハミ出す「武勇伝」を持った人間だ。

この公的な制度やルールをちょっとハミ出す「武勇伝」的な感覚は、社会に出てからも必要とされる。教室で覚えるべきことは、勉強だけではなく、そういう「公的なルールを補助線として、どのくらいそこからはみ出た所に、適切なラインがあるか」感じ取る能力だ。

バカッター騒動を起こしてしまう人は、鈍感で非常識な人なのではなく、むしろ、そういう「武勇伝」的感覚が敏感で、友達の多い、ある意味では社会性のある人なのだと思う。少なくとも誰もが動画を共有して一緒に楽しむ友人を持っているからこそ、それを撮影、投稿してしまったのだろう。

もちろん、交通法規でも制限速度とは違って、たとえば、一方通行なんかを破ればすぐにトラブルを起こすし、一発アウトで取り締まられる可能性も高い。言われている通りに厳守すべきルールもあり、そうではないルールもある。本来の社会性とは、その違いを見抜くことも含まれていて、そこは欠けていると言わざるを得ない。

しかし、日本の伝統では、「やんちゃ」が行き過ぎた場合、一発アウトとなるケースは少なく、多くは偉い人の裁量によって処分が決められる。

スクリーンショット違法化という流れも、そういう伝統に戻したい人の意向が多く反映されていると思う。そういう場面の裁量権が権力の源泉だからだ。誰もがラインの少しだけ外にいて、誰を捕まえるかを裁量で決められる状態が一番都合がいい。

動画や音声が気軽に飛び交うインターネットというものは、人治主義と相性が悪い。

バカッター動画も関係者の本音としては「今回だけは大目に見てやるからもうするなよ」と一つの「武勇伝」として終わらせたい所ではないかと思うが、動画があちこちで共有されてしまったら、そういう裁量を効かせる余地がない。

やっぱりテクノロジーは、強引に世の中を変えてしまうと思うが、「ブランド」というものもその中で再考を迫られると思う。

不適切動画は、その店ではなくブランドを傷つける。みんなどことどこの不適切動画が騒動になっているか知っていると思うが、それがどこの県の何店なのか即答できる人は少ないだろう。みんな不適切動画の強烈な印象にブランド名を被せて記憶する。

今までは、ブランドが大きいほど有利だった。一つのテレビコマーシャルが全国何百件全部の店の宣伝になるからだ。

しかし、不適切動画を撲滅するのは、店の数が多いほど困難になる。どこの世界にも先生の言うことをそのまま真面目に聞かない人間が少数存在する。ブランドを持つ店の大半で適切な指導をするのは可能だが、全部というのは困難だ。先生の言うことの多くはタテマエだと学習した人間の何割かは、店長やスーパーバイザーが厳しく言ったことも同じように受け取る。これは「武勇伝」を作るチャンスだと。

「あっちゃんかっこいい」はどう見ても、あっちゃんを痛い人として笑ってもらうためだが、そういう「あっちゃん」はどこにでもいるのだろう。

むしろ、こういう事故はごく少数はどうやっても起こるもんだとして、その被害範囲を狭くする工夫をした方が現実的だと思う。つまり、ブランドを分断して、たとえば、コンビニ名がその県の中でしかないブランドだったら、その県以外の人は不適切動画を見ても笑って自分の家の近くのコンビニには気にしないで行ける。

ブランドが大きいことが有利な理由は、ほとんどマスメディア上での宣伝のためなので、SNSを使えば、同じくらいのコストや労力で小さいブランドを個別に展開していくこともできるのではないだろうか。

今一番重要な教育は、「忘れる」ことを教えることである。

不適切動画予備軍に、「SNSへの投稿は注意すること」とか「食品を必ず衛生的に扱うこと」とか説教しても意味がない。「武勇伝」という概念の危険性を教えなくてはいけない。物理的な証拠があったら裁量の効かせようがないので、法律通りに処理される。ルールを教えるのではなく、「君が学んできたルールのとらえ方を忘れなさい」と教えなくてはいけない。

とりあえず、教室という空間で長く生きた経験を持つ人は、そこで知らずに学んでいることを総点検した方がいいと思う。そこで学ぶことは無意識に学ぶことも含めて社会で役に立つものが多かった。だから、制限速度の標識から本当に走るべき速度を知るということの、数字では表現できないもっと難しいバージョンを、みんな覚えていて、しかもそれを学習したということを意識してもいない。

そういう裁量ベースのルールがすぐに消える訳ではいが、これから「裁量」が物理的証拠と対立した時どうするかの激しい葛藤があちこちで起こる。意識的でいないと思わぬところでその葛藤に巻き込まれてしまう。だから、何を覚えたかではなくて、自分が何をどこでどのように学習したか点検して、必要に応じて、それを忘れることが重要だと思う。「裁量」や「武勇伝」以外にもそういう忘れるべきものがたくさんあるだろう。

サマータイムによって組織の決断力が問われるのかもしれない

サマータイムに対応する方法は3つある。

  • なにもしない
  • うまくやる
  • きちんとやる

「きちんとやる」とは、「コンピュータが処理する全てのデータの時刻について、オフセット値を明確に定義した上で、そのデータの処理方法が適切か確認する」ということだ。

簡単に「きちんとやる」を行なうには、システム時刻、データベース、通信をUTCに統一し、画面上の入出力などでは既存の国際化ライブラリを使えばいいだろう。この考え方であれば、オフセット値がどうなるかはその項目が人の目に触れるものであるかどうかで判断できる。

全ての時刻の項目を見直すというのは、プログラマの作業量としては膨大なものになるが、個々の判断は簡単なことが多い。

「なにもしない」は、コンピュータのプログラムもシステム時刻も一切変更しないというものだ。時計に「9:00」と表示されていたら、人間がそれを見て「ああ、今7:00 か」と読みかえる。10:00 に買い物をしたら、8:00と印刷されたレシートを客に渡す。

こちらは、いちいち読み替えをするユーザの負担が大きくなるが、やれないことではないだろう。

「きちんとやる」と「なにもしない」は、作業量は大きいが不確定要素は少ない。

しかしおそらくこの二つは多くの場合、受け入れられず、たぶん、ほとんどの社長は「うまくやれ」と言うだろう。

「うまくやる」とは何かと言うと、ある部分では「きちんとやる」をして、ある部分では「なにもしない」を選択するということだ。「きちんとやる範囲はどこですか?」と聞けば社長は「それを考えるのがおまえの仕事だ」と言う。

確かに、世の中には絶対に落ちてはいけない、わずかな不整合でも許されないシステムがある。そういうシステムには「きちんとやる」しか選択肢がない。そういうシステムをリストアップすることはエンジニアの仕事だし、できるだろう。

また、すでに「きちんとやる」に近い形で構築されているシステムもある。これについては、プログラマをちょっと投入することでユーザの不便を無くせるのだから、合理的に考えて「きちんとやる」が正解になる。

しかし、そういう優先順位でやっていくと、客の目に触れるレシートの時刻が二時間ずれているのを放置することになる。これでいいのだろうか?

また、「うまくやる」の一つの手段として、コンピュータの時刻を二時間動かすという方法がある。個人のデスクにあるパソコンなどは、これでいいことも多いが、そのパソコンの中で動いているプログラムは全て「きちんとやる」の路線からはずれることになる。つまり、今動いているプログラムをいくつか使用中止にしないと、パソコンの時刻を動かすという方法はできないかもしれない。

「うまくやる」とは、会社の中にあるコンピュータを白、黒、グレーに塗り分けることで、確かにこの塗り分けを適切にやれば、最小のコストで最大の効果が得られるが、これに失敗すると、「きちんとやる」で対応すべきシステムが動かなくなる。

「うまくやる」の中にある決断は、相互に関連するものが多く、技術と業務の両面をバランスよく見た判断が必要なものが多い。上位のSEで、その会社の業務をよく知っている人が多数必要になる。

つまり「うまくやる」には、不確定性が大きいという問題があるということだ。

この「なにもしない」「うまくやる」「きちんとやる」のどれを選ぶのかという決断が、これから日本中のあらゆる組織の経営者に求められるのだ。

損切りができる経営者なら「きちんとやる」を選択するだろう。「きちんとやる」なら、当初の予想より膨らむ可能性は少ない。また、基本方針が明確なので、個別の作業(小さい決断)が相互関連することは少なく、平行して進められる。一部の遅れが他に響くことが少ない。人が足りなくなった場合、その業務や会社のことを知らなくても、国際化のライブラリの使い方さえわかっているプログラマなら誰でもいいから人員さえ追加すれば、収束できる。

つまり、損が膨らまないことを重視するなら「きちんとやる」になる。

「なにもしない」は、負担をするのはプログラマでなくユーザになることが大きく違うが、損の性質はこれと似ている。会社にある時刻は全部二時間ずれているという状態を想定して、どういうトラブルがあるか考えればいいわけで、考えやすいし事前の対策もたてやすい。レジの横に貼り紙をして「レシートの時刻は二時間ずれています。すみません」と謝ればいい。

日本でサマータイム制を絶対に導入してはいけない技術的な理由の一部:技術屋のためのドキュメント相談所:オルタナティブ・ブログで例としてあげられているジョブのネットワークなどは、「なにもしない」が正解だろう。そうすると、一部のデータが営業時間に間に合わなくて、9:00開店なのに11:00までコンピュータが動かないみたいな悲惨なことになるが、それでも、こういうのに下手に手を入れて一日中全く動かなくなるよりはましだ。

平常時でも、これのサマータイム対応を「きちんとやる」ことは難しい。まして、こういう複雑なバッチジョブのネットワークの経験がある技術者は、これから二年間確保することが非常に難しくなる。無理に獲得しても、他とかけもちでここに集中して作業できなかったり、疲弊していたりだろう。期待できる技術のレベルが相当下がることは(払うお金はふだんよりずっと高くなるのに!)折り込んでおくべきで、重要な難しいシステムほど「なにもしない」が正解になる可能性は高くなると思う。

私は、駅の表示板や電車の社内モニターの時間が二時間ずれていても絶対に怒らない。今何時でいつ次の電車が来るのか自分で簡単に計算できる。運行制御システムのトラブルで電車が止まったり衝突したりするよりは、ずっといい。そういう損切りはアリだと思う。

損切りできない経営者は、「うまくやる」を選んで、果てしなく膨らみ続けるコストを払った上に、どうしようもない混乱の二年間をすごすことになる。


最後に余談ですが、これを入れて3本のサマータイムに関する記事を書いたのですが、最初のエントリのアイディアを思いついて、頭の中で練っている時、妻に「どうしたの、なんか顔色が悪いよ。具合悪いの?」と言われました。二本目を考えている時にも同じことを言われて、

  • サマータイムのことが心配でブログに何か書こうと思ってる」
  • サマータイム?仕事に関係するの?」
  • 「いや、うちの会社はほとんど国際化してあるから、仕事には関係ないんだけど...」
  • 「じゃ、何をそんなに考えこんでるんだよ。顔色悪いなんてもんじゃないよ。ほとんど死相だよ」

うちの妻はいろいろおかしなことを言うので、あまり気にしてなかったのですが、このエントリのアイディアを思いついた時には、「今、サマータイムのこと考えてるでしょ。そうだよね、また死相が出てたよ」と当てられて驚きました。

自分では、「このアイディアで書いたらバズらないかな」とか「こんなムキになって結局中止になったらカッコ悪いな」とか思ってるんですが、エンジニアがサマータイムについて考えてると意図せずとも死相が出てしまうらしいです。

サマータイム対応を0円でやるたった一つの方法

それは、実施日の10年前に告知すること。そうすれば、0円は言いすぎだとしても現実的なコストで問題なく対応できるよ。



自分にとってこれは、「明日から電卓の+キーで引き算をして−キーで足し算をすることに決めた」みたいな話に聞こえる。

誰がうれしいのかちっともわからないけど、「明日から」というところを「10年後から」にしてもらえば、何の困難もない。+と-のキートップの刻印を逆にすればいいだけで、電卓の設計には何の変更もいらない。キーの配置を変えてはいけないと言われたなら、中の配線を二箇所変えるだけ。「電卓の+キーと-キーを逆にすることは不可能である」なんて言う人は誰もいないと思う。

しかし、「明日から」と言われたら、今、あちこちにある電卓はどうするの?

付箋紙をキートップのサイズに切り抜いて、日本全国の家庭やオフィスで、明日の朝一番にそれを貼りつけて、「+」「-」という字を手書きすればいいだろうか。でも、文具店や100円ショップの店頭にあるものはどうする?開封して同じことをして、またパッケージに入れる?そんなもの売り物にならないよね。では、今店頭や倉庫にある電卓は全部廃棄して、新しいのと入れ替えるか。急遽増産したとして、それが行き渡るまでは、電卓が品不足になって値段が高騰するよね。

つまり、流通の途中にある電卓を修正するっていうことは、とても難しい。

電卓だったら半年くらいかな、流通の途中にある製品に手を入れないでいいようなプランになれば、それほど難しいことではないし、お金もそんなにかからない。

今ある工場の生産計画に合わせて、「次の製品から+-逆のキートップで製造してね」と言っておいて、それが十分に行き渡ってから、切り替える。そうすれば、「店頭で全店員総出で電卓を箱から出して、キートップにシールを貼り、また箱に詰めて陳列棚に並べる」なんて、変な作業は発生しない。

それでね、この話で重要なことは、電卓の基盤とか筐体を設計している人が「そんな変更は簡単です、すぐできます」と言っても信じてはいけない、ということだ。むしろ、文具店や100円ショップの店長みたいな人に聞くべきだ。

これは、電卓の専門家でなくてもよくわかる話だし、説明するのも簡単だ。電卓の在庫の山を見せて、その在庫の山の前で、電卓を箱から出してキートップにシールを貼って、また梱包する、そういう一連の作業を見せて、「明日までに、この山を全部消化しなきゃならんのです。社員総出で徹夜でやってますが、とても間に合いません」と言えばいい。

まあでも、ソフトでも同じです。

残業計算でも電車の運行管理でも航空管制システムでも電波時計でもビデオレコーダーでもなんでもいいけど「次の製品からサマータイムするのに、どれくらい余分にかかる?」と聞いてみたら、99%は「別に、次の製品サイクルから対応するなら大した問題じゃないよ」って言うだろう。まあ、さすがにコンピュータで、1%くらいはそれでも何やら難しいこと言って、「無理だ無理だ」って言うかもしれない。でも、それは残りの99%の人がちょっと手を貸してやればいい。なんたって国の威信をかけた大事な問題なんだから、それくらいしたっていいだろう。「次の製品から」とハッキリ言えば、文句を言う人はごく少数だ。

でも、仕掛り中の製品、流通在庫について、同じことをしてくれと言うと、みんな顔色が悪くなる「それはちょっと...」次の言葉が出て来ない。

彼らは、「在庫の山の前で、電卓を箱から出してキートップにシールを貼って、また梱包する、来年までに、この山を全部消化しなきゃならんのです。社員総出で徹夜でやってますが、とても間に合いません」みたいな泣き言を言っている自分を想像しているのですが、その状況がうまくイメージできんのです。

ソフトはリードタイムが滅茶苦茶長い。特に、タイムゾーンのようなOSのレベルの変更だと、基本的には、OSの新バージョンのリードタイムと配布の期間を別に見て、それが完了してからアプリケーションのリードタイムが来る。常に5年から10年の在庫をかかえて商売してるようなもんです。

私が、コンピュータシステムのサマータイム対応を巡る二つの楽観論で通信の問題を中心にとりあげたのは、通信がからむとさらにリードタイムが長くなるからです。つまり、通信というのは、複数の組織がそれぞれのコンピュータで通信することが多くて、その場合、組織同士のマウンティングみたいなことが終わらないと、エンジニアは作業できない。犬が唸りながら睨みあうみたいに、どっちが偉いのか決めてからでないと、通信の仕様を決めるのがどっちか決まらない。

通信の仕様を決めるのは簡単だけど、通信の仕様をどっちが決めるのか決めるのは大変で、私が「リードタイム」と言う時問題にしてるのは通信の仕様を決める時間ではなくて、通信の仕様をどっちが決めるのか決める時間、つまり、マウンティングの時間です。

普通、システム開発はマウンティングが終わってから始まる。そしてマウンティングの結果がひっくり返ることはほとんどない。普通の開発の見積りには、そういう時間は入れない。

でも、サマータイム対応は、マウンティングからやり直すことになって、これは長くなりそうだな、というのが、上記のエントリの話です。

ちょっと違う言い方をすると、コンピュータっていうのは、変動費を固定費に変えるものです。

給料計算をして給与明細を書くのが、社員一人につき30分かかるとします。これを手作業でやってると、このコストは、社員の人数に比例するので変動費です。

コンピュータでやると、プログラムを書くのに、たとえば1000万円かかる。しかし、プログラムを書いてしまえば、社員が1000人でも10万人でもコストはほとんどかからない。固定費です。

もし、そのプログラムに間違いがあって、印刷した給与明細を一枚ずつ修正しなきゃならんとしたら、固定費になったはずのコストが、また変動費に戻る。その時には、社員が1000人と1万人で大きな違いが出る。

そして、今の話の中で固定費と言っているプログラム開発の中にも同じ構造があります。

1000本のプログラムを書くとして、そのプログラムの中に共通の、たとえばタイムゾーン対応があったとして、これを共通の部品にして誰か一人が書けば固定費です。その部品を使うプログラムが1000本あっても10万本あっても費用が変動することはありません。

しかし、その共通の部品が出荷されてから、それを修正しようとすると、1000人のプログラマが、全員、自分のプログラムがその部品の新しいバージョンと動くかテストしなくてはいけない。そして、その1000人が、それぞれ、修正版を客先のコンピュータにインストールしなくてはいけない。これは変動費です。

ソフトの設計、製造、テスト、配布といったサイクルの中には、この「変動費になることを固定費にしてコストを圧縮する」という構造が何重にも入れ子になっています。普通に見えている費用は、圧縮された固定費の費用です。

しかし、サマータイム対応のような想定外のことを後から入れようとすると、いろいろなところで固定費として圧縮されたコストが、変動費としてあらわれてきます。

こういう、ソフトの製品サイクル、その中にあるマウンティングとか変動費を固定費におさえる仕組みというのは、狭義のプログラミングとは別の話で、しかも、業界ごとにかなり事情が違います。

たとえば、私の今の職場では、昨日言われたことを、今日の朝のミーティングで「今日これこれをデプロイ(本番稼動)します」なんていうことが日常茶飯事です。テストは自動化されているし、自動化テストで動作確認できないところは、別のルートがあって別のルートで承認されます。

でも、20年前には、私は、ダムの制御システムを開発していて、これは、ダムのゲートを開きすぎると下流の水位が急激に上がって危険になるという、そういうゲートをコンピュータであけしめするものなので、ありとあらゆる確認を何重にもやります。ここでは、小さな仕様変更でも、基本的に二年後の次のバージョンに回していました。

ただ、どちらも、(狭義の)流通在庫の期間の範囲なら、通常運用で変更できることは同じで、それより短いサイクルで変更を要請されると、かなりアタフタして、他の作業を止めて社員総出でみたいな状況になるのも同じです。

そういうサイクルをひっくりかえすなんてことは、非常事態でなければありえない。

まあ、宇宙からサマータイム星人が攻めてきて、「来年までにサマータイムになってない国は全員滅ぼす」とか言ったならやりますよ。みんな文句も言わずにがんばってやると思う。

そうでない限り、固定費として不可視化されているコストが変動費として爆発して、それを処理するためにマウンティングからやり直す未来しか見えない。

コンピュータシステムのサマータイム対応を巡る二つの楽観論

いきなり来年から日本でサマータイムを導入するという話が出てきて、私には到底実現できない話としか思えなかったが、自民党の少なくとも一部の方々は本気で考えているようだ。そもそも、私にはメリットがどこにあるのかわからないがそれは置いておいて、コンピュータシステム側の対応が非常に困難であるということを、なるべく一般の方にわかるように説明してみたいと思う。

5chとツィッターを眺めて見ると、同業者の人は私と同じ意見が多数であるように見えるが、一部楽観的に見ている方もいるのに驚いた。何事にもいろいろな見方があるので、賛否両論の意見があって議論していけばいいことではあるが、その楽観論を見ていると、全く違う立場の二種類の楽観論がある。何がなんでも自分の立場が正しいと主張する気はないが、この二種類の楽観論が絶対両立しないことは確かで、ここだけはハッキリしておかなければならないと強く言いたい。

最悪のケースは、エンジニアの意見を聞いた所、楽観論Aの人が30%、楽観論Bの人が30%、悲観論の人が40%となった場合だ。AB足して60%だからと言って強行すると、楽観論Aの考えていた方法では、楽観論Bが成立せず、楽観論Bの人の方法だと楽観論Aの人が悲鳴を上げて、結局、どちらの楽観論も実現不可能で悲観論が正しかったということになる。

だから、最終的な結論はエンジニア同士の議論になるなるのかもしれないが、回りの人も、その議論の構図はきちんと理解しておく必要があると思う。

楽観論A: 既存の国際化機能を前提とした楽観論

最初のタイプの楽観論は「サマータイムを実施している国はいくらでもあって、そういう国では普通にコンピュータを使っているではないか!」というものだ。

これは正しい。この手の機能は、インターナショナライザイション(国際化)と言って、画面上の英語のテキストが、日本人が見た時には日本語になるのと同じグループの共通化機能とされている。今では、OSでもプログラミング言語でも、ほとんどが国際化の機能を標準で持っており、その中には、サマータイムを含むタイムゾーン(時差)の処理がある。

だから、日本でのサマータイム導入も、対応するのはOSだけで、ユーザもアプリケーションも何も変更なしで、そのまま対応できるケースもある。

特に、スマートフォン用のアプリなどは、逆に、OSや開発ツールが提供している国際化の枠組みからはずれる方が難しいので、何もしなくてもそのままでサマータイムに対応できるものも多いかもしれない。

ただ、注意すべき点は、この国際化とは、コンピュータ内部では、UTCで時刻の情報を持っていることを前提としていることだ。そして、データを保存したりやりとりしたりする時には、UTCで行う。国ごとのローカルタイムに変換するのは、画面に表示する直前で、それ以外では、時刻が全部UTCになっているということが暗黙の前提となっている。

たとえば、私が 8/7 の 午前 10:00 に5ちゃんねるにコメントを投稿したとする。国際化対応されているプログラムでは、この投稿に、「01:00 UTC」という時刻をつけて保存する。UTCとは時差の基準になる時刻のことで、日本の時間より9時間前になっている。そして、表示する時に、「01:00 UTC」を日本時間(JST)に変換して、「10:00 JST」という投稿時刻を表示する。

もし、5ちゃんねるが国際化対応していて、イギリスの人がこの投稿を見ると、「2:00 BST」という投稿時刻が見えるはずだ。イギリスは現在サマータイム期間中で、その時の日本との時差は8時間になる。サマータイムが終わればそれは「1:00 GMT」になる。

多くの国で使われるプログラムはほとんどそうなっているし、アメリカは国内に複数のタイムゾーンがあるので、アメリカ人専用のプログラムでもそうなっている。

ところが、日本人だけが使うプログラムはほとんどそうなっていない。5ちゃんねるもそうだろうと思ったら、案の定そうだった。

日本のプログラムでは、普通、10:00 に投稿したら、そのまま「10:00」という情報を保存する。そして、専用ブラウザに対して、「10:00」という情報を送信して、専用ブラウザは、それに何の変更もしないで、「10:00」と表示する。

どちらが自然だと思いますか?

10:00 に投稿された情報を「10:00」で保存するのと、10から9を引いて「1:00」で保存して、表示する時に9を足して、「10:00」で表示するという二度手間をかけるのと、どちらが自然だと思いますか?

この「9を引いて」とか「9を足して」という処理が、サマータイム期間中は「11を引いて」と「11を足して」になる。こういう所は、国際化の機能を使うと自動的にやってくれるのだが、日本人しか使わないものは、そもそも足したり引いたりする処理を入れる必要がなくて、自然に10:00で保存して自然に10:00で表示する。

それは、国際的に見て標準的とは言えないし、今後はそれではダメだろうと私も思うが、日本人が日本国内でプログラムを作ると、5chのようなやり方になるのが自然だ。

それに、仕事で作るプログラムでは、エンジニアが必要と思っていても客が必要と思わなければ、そういう機能を入れることは許されない。

楽観論B: システム時刻変更を前提とした楽観論

そして、5ちゃんねるのようにローカルタイムで処理することを当然と思っている人の中にも楽観的に見る人がいる。そういう人は「システム時刻を変更してしまえばよい」と言うのだ。

そういう人も年に二回ある切り替えの日には、いろいろややこしい問題があることは認識しているようだが、そういう時は数時間コンピュータを止めてシステム時刻を変更して起動すればよい、と考えている。

もし、サマータイムの時にシステム時刻を進めれば、私の(サマータイム以前の日本標準時で言う)10:00 の投稿は、12:00 で記録される。そして、それを見る時はそのまま 12:00 で配信され、12:00 で表示される。

つまり、こういう人は、システム時刻=ローカルタイムという前提を持っているので、サマータイム対応というのは、そのシステム時刻を年二回進めたり遅らせたりすることだと思っている。

私には、随分乱暴なやり方に思えるが、単体で動いているコンピュータで信頼性より運用コスト低減の方が重要なシステムならば、そうすることにも一理あるとは思う。

というか、私も以前は、こういう考え方をしていた。

私は、1980年代から2010年頃まで国内のメーカー系SIでエンジニアとして仕事をしてきた。その後、フリーランスになって、国際化の必要な仕事をした。その仕事では、仕様書が英語で書かれていて、最新のWEB技術を使った仕事だったが、技術と英語には困らなかった。しかし、国際化機能の使い方がわからなくて、すごく苦労をした。

だから、今では「そうすることにも一理あるとは思う」とか偉そうに言っているが、ついこの間まで「システム時刻=ローカルタイム」と普通に考えていて、それが一番自然だと思っていた。

1990年頃には、証券に関連するシステムの通信制御システムの開発をしていて、このプロジェクトは「一分落ちたら一億円賠償」とか言われるシステムで品質にはすごく厳しくて、WEB系には技術面でその時のプロジェクトリーダーより上の人はいない、と今でも思っているが、そういう難しいシステムでも確か電文上の時刻はローカルタイムだった。

だから、システム時刻を2時間進めたり遅らせたりと考える人がいて、ローカルタイムで通信しようと考える人がいることも間違いないと思う。

二つの楽観論が出会う時

たとえば、あなたが5ちゃんねるの専用ブラウザの作者だとして、「あなたのアプリではサマータイム導入の時どういう影響がありますか?」と聞かれたら、どう考えるだろうか。

専用ブラウザは、ローカルタイムで送られてきた時刻をローカルタイムのまま表示するだけだから、「こちらで対応することは何もない」と思うかもしれない。つまり、あなたは楽観論Bをもとに「たいしたことない、関係ない」と言う。

しかし、5ちゃんねるのサーバ側は、「サマータイムを導入する以上、これを機会に5ちゃんねるもちゃんと国際化しよう」などと考えて、「来年からUTCで時刻を送ります。専用ブラウザの人は、それをローカルタイムに変換して表示してね」と言うかもしれない。これは「OS標準の国際化機能を使えば、処理は簡単でしょ」という楽観論Aの人だ。

確かに追加する処理は簡単かもしれないが、「何もない」と思ってた所に予定外の作業を入れるのは大変だ。

こういう行き違いがたくさん起こると私は考える。

5ちゃんねるであれば、力関係がハッキリしているからまだいい。

もし、専用ブラウザ側の方が権力を持っていたら、さらに話がややこしくなる。

つまり、「こちらが作業するのが大変だから、サーバ側でサマータイムに対応しろ」と言い出す。従来の日本標準時で10:00に投稿されたものを、「10:00」や「12:00」にして送ってこい、ということだ。

おそらく、ローカルタイムで通信しているシステムでは、こういう問題が必ず起きる。技術的な正論は簡単で通信電文上の時刻はUTCであるべきだ。しかし、それによって作業量が増えてしまうケースもあって、通信のあっち側が負担するかこっち側が負担するかという話だと、これは技術者だけでは決められない。ビジネス的、あるいは政治的な力関係の問題になってしまう。

そういう技術と政治のからんだ綱引きを、納期が絶対に動かせないタイトなスケジュールの中でやることになる。

まとめ

私の懸念することをまとめると「通信電文上の時刻の扱いをどうするか合意が取れないケースには、サマータイム導入への対応方法は簡単には決まらない」ということだ。

つまり、掲示板に10:00に投稿された書き込みをサーバはどう配信すべきか

という選択肢があって、現状すでに 1:00 UTC で統一されているケース以外では、揉めることが避けられないだろうということだ。

「3:00」というのはどういう意味かと言うと、「うちのシステムは、NTPで時刻同期をしてるから、おおもとのタイムサーバの時刻を二時間進めれば問題ない」という意見を見たからだ。

つまり、「NTPが配信している時刻はローカルタイムの事情に動かされることがない固定のUTCである」という前提を理解せずにシステム時刻を変更しようとしているわけで、こういう人は、UTCで通信していてもそのUTCを動かすことを考えるかもしれないと思ったからだ。

そして、この結論によって通信のこっち側とあっち側で対応の工数が変わってくるので、これは簡単に決まらない。

それと、データベース内にローカルタイムが保存されているケースにも、似たような問題が発生して、この場合は、その時刻項目を参照する箇所を洗い出すのが大変だと思う。

そもそも

私は、こういう時に技術者の話が通ることは、日本ではあまりないと思っているのですが、それについては、こちらを参照してください。