2018-08-18
■ サマータイムによって組織の決断力が問われるのかもしれない
サマータイムに対応する方法は3つある。
- なにもしない
- うまくやる
- きちんとやる
「きちんとやる」とは、「コンピュータが処理する全てのデータの時刻について、オフセット値を明確に定義した上で、そのデータの処理方法が適切か確認する」ということだ。
簡単に「きちんとやる」を行なうには、システム時刻、データベース、通信をUTCに統一し、画面上の入出力などでは既存の国際化ライブラリを使えばいいだろう。この考え方であれば、オフセット値がどうなるかはその項目が人の目に触れるものであるかどうかで判断できる。
全ての時刻の項目を見直すというのは、プログラマの作業量としては膨大なものになるが、個々の判断は簡単なことが多い。
「なにもしない」は、コンピュータのプログラムもシステム時刻も一切変更しないというものだ。時計に「9:00」と表示されていたら、人間がそれを見て「ああ、今7:00 か」と読みかえる。10:00 に買い物をしたら、8:00と印刷されたレシートを客に渡す。
こちらは、いちいち読み替えをするユーザの負担が大きくなるが、やれないことではないだろう。
「きちんとやる」と「なにもしない」は、作業量は大きいが不確定要素は少ない。
しかしおそらくこの二つは多くの場合、受け入れられず、たぶん、ほとんどの社長は「うまくやれ」と言うだろう。
「うまくやる」とは何かと言うと、ある部分では「きちんとやる」をして、ある部分では「なにもしない」を選択するということだ。「きちんとやる範囲はどこですか？」と聞けば社長は「それを考えるのがおまえの仕事だ」と言う。
確かに、世の中には絶対に落ちてはいけない、わずかな不整合でも許されないシステムがある。そういうシステムには「きちんとやる」しか選択肢がない。そういうシステムをリストアップすることはエンジニアの仕事だし、できるだろう。
また、すでに「きちんとやる」に近い形で構築されているシステムもある。これについては、プログラマをちょっと投入することでユーザの不便を無くせるのだから、合理的に考えて「きちんとやる」が正解になる。
しかし、そういう優先順位でやっていくと、客の目に触れるレシートの時刻が二時間ずれているのを放置することになる。これでいいのだろうか？
また、「うまくやる」の一つの手段として、コンピュータの時刻を二時間動かすという方法がある。個人のデスクにあるパソコンなどは、これでいいことも多いが、そのパソコンの中で動いているプログラムは全て「きちんとやる」の路線からはずれることになる。つまり、今動いているプログラムをいくつか使用中止にしないと、パソコンの時刻を動かすという方法はできないかもしれない。
「うまくやる」とは、会社の中にあるコンピュータを白、黒、グレーに塗り分けることで、確かにこの塗り分けを適切にやれば、最小のコストで最大の効果が得られるが、これに失敗すると、「きちんとやる」で対応すべきシステムが動かなくなる。
「うまくやる」の中にある決断は、相互に関連するものが多く、技術と業務の両面をバランスよく見た判断が必要なものが多い。上位のSEで、その会社の業務をよく知っている人が多数必要になる。
つまり「うまくやる」には、不確定性が大きいという問題があるということだ。
この「なにもしない」「うまくやる」「きちんとやる」のどれを選ぶのかという決断が、これから日本中のあらゆる組織の経営者に求められるのだ。
損切りができる経営者なら「きちんとやる」を選択するだろう。「きちんとやる」なら、当初の予想より膨らむ可能性は少ない。また、基本方針が明確なので、個別の作業(小さい決断)が相互関連することは少なく、平行して進められる。一部の遅れが他に響くことが少ない。人が足りなくなった場合、その業務や会社のことを知らなくても、国際化のライブラリの使い方さえわかっているプログラマなら誰でもいいから人員さえ追加すれば、収束できる。
つまり、損が膨らまないことを重視するなら「きちんとやる」になる。
「なにもしない」は、負担をするのはプログラマでなくユーザになることが大きく違うが、損の性質はこれと似ている。会社にある時刻は全部二時間ずれているという状態を想定して、どういうトラブルがあるか考えればいいわけで、考えやすいし事前の対策もたてやすい。レジの横に貼り紙をして「レシートの時刻は二時間ずれています。すみません」と謝ればいい。
日本でサマータイム制を絶対に導入してはいけない技術的な理由の一部：技術屋のためのドキュメント相談所：オルタナティブ・ブログで例としてあげられているジョブのネットワークなどは、「なにもしない」が正解だろう。そうすると、一部のデータが営業時間に間に合わなくて、9:00開店なのに11:00までコンピュータが動かないみたいな悲惨なことになるが、それでも、こういうのに下手に手を入れて一日中全く動かなくなるよりはましだ。
平常時でも、これのサマータイム対応を「きちんとやる」ことは難しい。まして、こういう複雑なバッチジョブのネットワークの経験がある技術者は、これから二年間確保することが非常に難しくなる。無理に獲得しても、他とかけもちでここに集中して作業できなかったり、疲弊していたりだろう。期待できる技術のレベルが相当下がることは(払うお金はふだんよりずっと高くなるのに!)折り込んでおくべきで、重要な難しいシステムほど「なにもしない」が正解になる可能性は高くなると思う。
私は、駅の表示板や電車の社内モニターの時間が二時間ずれていても絶対に怒らない。今何時でいつ次の電車が来るのか自分で簡単に計算できる。運行制御システムのトラブルで電車が止まったり衝突したりするよりは、ずっといい。そういう損切りはアリだと思う。
損切りできない経営者は、「うまくやる」を選んで、果てしなく膨らみ続けるコストを払った上に、どうしようもない混乱の二年間をすごすことになる。
最後に余談ですが、これを入れて3本のサマータイムに関する記事を書いたのですが、最初のエントリのアイディアを思いついて、頭の中で練っている時、妻に「どうしたの、なんか顔色が悪いよ。具合悪いの？」と言われました。二本目を考えている時にも同じことを言われて、
- 「サマータイムのことが心配でブログに何か書こうと思ってる」
- 「サマータイム？仕事に関係するの？」
- 「いや、うちの会社はほとんど国際化してあるから、仕事には関係ないんだけど...」
- 「じゃ、何をそんなに考えこんでるんだよ。顔色悪いなんてもんじゃないよ。ほとんど死相だよ」
うちの妻はいろいろおかしなことを言うので、あまり気にしてなかったのですが、このエントリのアイディアを思いついた時には、「今、サマータイムのこと考えてるでしょ。そうだよね、また死相が出てたよ」と当てられて驚きました。
自分では、「このアイディアで書いたらバズらないかな」とか「こんなムキになって結局中止になったらカッコ悪いな」とか思ってるんですが、エンジニアがサマータイムについて考えてると意図せずとも死相が出てしまうらしいです。
