さよなら、タイムゾーン

はじめに

2020年の東京オリンピックに向けたサマータイム導入の是非について、主にIT業界を中心に(?)世論が白熱する今日この頃。
私のタイムラインに、こんなツイートが飛び込んできた。

正直、目から鱗だった。

サマータイムを止めるかどうかの議論の前に、そもそも時差の概念をなくしてしまう。
――例えるならば、争いにどう勝つかを考えるのではなく、争いそのものをなくしてしまう。
そんな発想の転換を感じた。

直観的にこれは筋が良さそうなアイディアだと思ったのだけど、だからこそ想定され得る懸念は排除するか、議論を深めておきたい。
そんな意味合いもあってこのエントリを書いている。

そもそも、UTCとは

このブログを読む9割の人には説明不要だと思うのだけど、念のため補足しておくと、「協定世界時*1」と呼ばれる時刻系のことだ。
グリニッジ標準時GMT*2」や「世界標準時」と言った方がピンと来るという人もいるだろうか。
これらは等価な時刻系で、世界各地の標準時の基準となっている。

UTCを採用したらどうなるの?

UTCは今の日本標準時JST)に対して9時間遅れている。
ので、もし日本がUTCを標準時として採用した場合、数字の上では今より9時間早く生活する形になる。
会社員が出勤するのはAM0:00頃、ランチタイムはAM3:00、サザエさんが始まるのはAM9:30といった具合である。

この@sakaikさんは少しの間「UTCトライ」と称してUTC時間での生活を試みたようだ。

…正直、今のところ全然ピンと来ないけど、慣れたら普通になるだろう。…きっと。

予想される懸念

移行時に混乱があることは当然考えられる。
他に何があるだろうか?

パッと思いついたのは、以下のようなものだった。

これに対しては、次のようなリプライを頂いた。

確かに。

この程度なら、大した懸念ではないかな、と思った。

追記

Facebookで下のような指摘を受けた。

「今日」っていう概念が日が昇って沈むまでを前提にしてるものとか、正午≒南中を前提にしてるものの方に不整合が出てきますよねー。「今晩」が日付としては明日になる地域では時差以上の混乱かも

これも確かにありそうだけど、上の私のツイートのように現在の常識を前提にした考えとも言えそうだ。
UTC時間での生活が当たり前になれば、自然に概念が変化していくのではないだろうか。

考えられるメリット

時差に関する諸問題がなくなるというのが最大のメリットだ。

時差に関する問題は枚挙に暇がない。
いくつか例を挙げよう:

  • ニューヨークと東京にいる人同士で電話会議をする場合。「8時に」と言ってもどちらのタイムゾーンでの話か、朝か夜か誤解があるかもしれない。
  • アメリカへの出張から帰って来る場合。9/12に帰って来るつもりが、日付変更線を越えるので9/13になってしまった。(いや、普通はちゃんと計画するだろうけど、考慮が必要だということ。)
  • 時差のある国に旅行に行くと iPhone 腕時計の時刻を合わせなければならない。(iPhoneは勝手に合う。むしろ日本時間のままにしておきたい時に不便か)
  • イリノイ州からインディアナ州に車で出かけると1時間時刻が進む。
  • タイムゾーンを導入している地域から導入していない地域に移動すると時間が戻る。
  • ワールドワイドな期間限定のキャンペーンを実施するとき、ローカルタイムを考慮する必要がある。
    • もし、サマータイムも考慮すると、サマータイムの切れ目とキャンペーンの切れ目の重なりを考慮すると相当ややこしいことになる。

たぶん、私よりも時差について日常的に頭を悩ませている人はもっと色々思いつくと思う。

どちらかというと、アメリカやロシアのように1つの国の中に複数のタイムゾーンを抱えている国の方が、UTCへの統一による恩恵が大きいのではないだろうか。
本来的には、時差というのは1時間や30分の単位で区切られるものではなく、経度に沿って切れ目なく変化するものだ。
ある地点から別の地点に移動したらいきなり時刻がジャンプするより、ずっと共通のUTCを使う方が、よほどわかりやすそうだ。

また、コンピュータが時差やサマータイムを考慮しなくて良くなるというのも大きなメリットだ。
プログラマは時差を考慮する必要がなくなるので、浮いた工数を他に回すことができるようになるだろう。

まとめ

以上、自分が思いついたわけではないけど、世界からタイムゾーンを取っ払って、みんな1つの時刻系で生活するというアイディアを紹介した。

サマータイムがきっかけではあるけど、サマータイムが今後世界からなくなったとしても、更に時差をなくすことにも意味が有って、良い考えだと思う。

「いいじゃん、これ」と思った方は、時計をUTCにして、時差のない世界へ旅立ちましょう。

参考

少しだけぐぐったら次のような2011年のエントリを見つけた。

元記事は海外のものだが、同じことを考える人はいるものだ。

脚注

企業人 or Web技術者として生きる若者に薦めたい幾つかの本

はじめに

先日、勤め先の若手社員とランチに行く機会があり、「何かオススメの本はありますか?」と訊かれた。

SEが20代で身につけておきたいこと

咄嗟に出てきたのは、『SEが20代で身につけておきたいこと(技評SE選書)』という本だった。
これは私が社会人になりたての頃に読んだ本で、IT業界のベテラン数名の方が自身の経験を踏まえて、タイトルに沿った内容のことを書いた本だった。
ただ、内容については正直そこまではっきりと覚えてはいない。が、当時、将来のキャリアを考える上で参考にはなったと思う。

これまでそういう質問をされることがほとんどなかったので、その場ではそういう回答しかできなかった。
少々申し訳なく思ったので、「他に何があり得るだろうか?」と本棚と記憶を振り返りながら考えてみることにした。

もちろん、その人にどういう能力や適性があって、どういうキャリアを描いているのかによっても変わってくると思うのだけど、若者の未来というのは概して定まっていないものだ。
一般的に通用しそうなものや、自分の興味を惹き付けてきたジャンルについて、心の中にオススメ本を用意しておいても良いだろう。

というわけで、以下では私がこれまで読んできた本の中からいくつか紹介する。

想定読者

会社勤めをしている人、ビジネスに関わる人。
あるいはWeb系のエンジニア職をしている人。
または、これらのどれかになろうとしている人。

(タイトルを「会社員」としてないのは、色んな働き方を考慮してのもの)

どんな職種でも役立ちそうな本

戦略フレームワークの思考法

初めに、ロジカルシンキングについて。
ロジカルシンキングは思考のツールとして役に立つことがあるし、他者を説得するときや、会議を首尾よく進めるときなどビジネスにおいて有用なシーンが多い(と思う)。
よく使う思考のパターンやフレームワークと、その使い方を解説している本を1冊ほど読んでおくといいのではないだろうか。

私は社会人1〜2年目ぐらいの時に『戦略フレームワークの思考法』という本を買って、一通り読んだ。
ほとんど読み返すことはないが、今でも手元に持っている。

次に役立ちそうなジャンルとしては、プロジェクトマネジメント系の本が考えられる。
社会人であるあなたはきっと、なんらかのプロジェクトの一員として働く機会が多いはず。
プロジェクトを炎上させず、いい感じに進めるために、先人の知恵を学んでおくことは、プロジェクトでどんな役割を果たすとしても役に立つと思う。
…のだけど、残念ながら私はこの分野の本を読んだことはないので、ここでオススメ本を挙げることはできない。
誰か良い本を知っている方は教えてください。

伝え方が9割

もし、あなたがコミュニケーションに課題を感じているのだとしたら、コミュニケーションに関する本を読むのも良いと思う。
コミュニケーションは多分に気質や性格に影響を受けると思うのだけど、後天的に「技術」を身に着けることも可能だと、個人的に考えている。
この分野で有名、かつ、オススメの本は、『伝え方が9割』だ。

5年ほど前に出版された本だが、手元にあったのは初版第二刷(2013/3/13発行)のものだった。
この本の主張はタイトルに尽くされているようとも取れるが、「じゃあ、どう伝えればいいの?」という方にとっては一読以上の価値はあるだろう。

他にも、ヒューリスティック or 心理学的な観点でコミュニケーションのテクニックを記している本は多数あるように思う。

ソフトウェアエンジニア向け

メジャーな本にそれほど目を通しているわけではないけど、自分がこれまで読んだ本の中からいくつか紹介しておく。

リーダブルコード

プログラムを書く全てのエンジニアにオススメなのは『リーダブルコード』だ。
あなたの書くコードは、(多くの場合においては)あなたが書く時間よりも、あなたも含めてレビュワーやメンテナといった関係者一同が読む時間の方が長いはずである。

また、プログラマーであれば、オブジェクト指向プログラミングは身に着けておくべきと思う。
これについては、特定の本を読むというより、JavaRubyなどオブジェクト指向プログラミングに向いた言語の入門書などを通して身に着けるのが良いのではないか。(…というと、言語差別的になるだろうか?)

SQLアンチパターン

RDBMSを扱う初心者ではないエンジニア、中でも特にアプリケーションエンジニアにオススメなのは『SQLアンチパターン』だ。
この本については、遅まきながら最近読了したので、書評エントリ(?)を書いた。

SRE サイトリライアビリティエンジニアリング

サーバーサイドのシステム全般に興味がある人(or インフラ寄りの人)なら、『SRE サイトリライアビリティエンジニアリング』はオススメ。
ただ、初心者が最初に手に取るべき本ではないかもしれない。
また、とても長いのでまずは1〜5章ぐらいまでを読んで、各論は後回しにして汎用的なチーム運営やワークフローに関する章を先に読むのが良いのではないか。

[24時間365日] サーバ/インフラを支える技術

初心者がイチからWeb技術を学ぶという文脈では、『[24時間365日] サーバ/インフラを支える技術 』という良書がある。…が、なんともう初版から10年も経ったので、やや内容が陳腐化してしまったかもしれない。
2018年のオススメ本がある人は教えてください。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

サーバ・インフラを志す人は、まずインターネットの仕組みや全体像をざっくり理解するのが良いのではないだろうか。
その点では、最近読んだ『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』はオススメといって良さそうだ。
これについても読後に感想記事を書いた。

この本は取り扱っている技術要素の幅が広く、若干out-of-dateな内容も入っていると思うが、L1〜L7までざっくり見渡せるし、1つ1つの話題をそんなに深く掘り下げないので、全体観を掴む上で役立つと言えそうだ。

その他にも、コンピュータ・サイエンスの本やLinuxカーネルに関する本など、挙げようと思えばまだまだ出てくるが、段々ニッチになっていくのと、キリがなくなりそうなので、今回はこのぐらいにしておく。
あるいは、もっと賞味期限の長い、理論や低レイヤ寄りの本の方が良いんじゃないの? という気もするのだけど、そちらに寄れば寄るほど、多くの人にとって確実に役立つかわからないのが難しいところ(と感じたので割愛)。

マネージャー or ハブ的立場の人向け

HIGH OUTPUT MANAGEMENT

HIGH OUTPUT MANAGEMENT』を4月に読んで、感想記事を書いた。

…というか、その手の本ではこれぐらいしか読んでない。
が、間違いなく良書だと思う。

感想記事にも書いたけど、チームリーダー以上の中間管理職のみならず、「ノウハウ・マネジャー」――いわば「生き字引き」的な人も対象とした本だ。
組織のナレッジ管理や、共通機能の抽出・集約といったことに興味がある人にとっても有用だと思う。
また、最近流行りの1 on 1ミーティングをどう組織に取り入れ、実践していくかを考える上でも役立つだろう。

他には、コーチングに関する本とか、マーケティングや経営に関する本とか、データ分析、あるいは研究開発をする人向けの本とかあるかもしれないが、あまり読んでないし思いつかないので踏み込まないことにする。

まとめ

以上、9冊ほど挙げた。
ややWeb技術のそれもサーバサイドに寄っているのは、私のキャリア・経験上仕方のないことだ。

文中に述べたように全てがオススメというわけではないし、自分に向いていると思う本をチェックしてもらえればと思う。

ご参考まで。

最近買ったフィットネス関連用品

平成最後の夏も終わろうとしている今日この頃、みなさまはいかがお過ごしでしょうか。

私は今年の1月末ごろに体調を崩し、それまで週1ペースでコンスタントに行っていたジム活動を休止していました。
その時はただの風邪だったので、体調はすぐに回復したのですが、その後ゲーム沼にハマったり、ラノベにハマったりしている内に、およそ半年ほど英気を養う形になってしまいました。

そんなわけで、ジムワークを再開したのはつい最近のことです。
この半年間でお腹に溜めてしまった備蓄を、燃焼させなければなりません。

さて、そんな私が昨年末〜最近の間に買ったフィットネス関連用品をつらつらと紹介します。
特に結論はありませんので悪しからず。

  • トレーニングシューズ
  • シューズ袋
  • Bluetoothイヤフォン
  • デジタルウォッチ
  • ウェストポーチ
  • まとめ

トレーニングシューズ

実は、それまで学生時代に買った卓球シューズを15年ぐらいジムで流用して、トレッドミルで走ったりしてたのですが、さすがにそれなりに傷んできたし、そもそもランニングに向いてないので、もう少しマシな靴を買う決心をしました。

続きを読む

(メモ)著作物を翻訳し公開することは違法になり得るということ

はじめに

※まだ法令原文には当たってないので、この記事は3次情報です。もし誤りなどあればお知らせ頂けると幸いです。

私は日本で働くソフトウェアエンジニアなので、技術文書の邦訳記事を参照することはよくあります。
また、私自身もまだ翻訳されてないものについては翻訳してみたくなることがあることがときどきありますが、どこまでが法律で許可されてるんだっけ? というのがふと気になったので調べてみました。

翻訳を公開したら違法になり得る

著作権は原著者にあるので、勝手に翻訳して公開すると基本的には違法になると思って良さそうです。
特に、翻訳権というものがあるようですね。

違法になるケースは全文訳に限らず、要約であってもNGのようです。

違法にならないケース

けっこう色々あります。

  • 私的利用に留まる場合
  • 正当な引用の範囲に留まる場合
  • 著作者の許諾を得た場合
    • CCライセンスなどで改変を許可している場合
      • ※CCライセンスでも改変が許可されてないとNG
      • ※CCライセンスで非営利利用に限定している場合、営利利用はNG
    • Webサイトなどで、翻訳を許可する記述がある場合
    • 著作者に尋ねて許諾を得た場合

他に、教科書や試験の問題文といった特殊ケースもあるようです。

どうするか

翻訳して公開したいものがある場合、

  1. 翻訳が許可されているか確認する
  2. 許可されていなければ、許可を得る
  3. 許可が得られなければ諦める

とすべきのようです。

参考

『HIGH OUTPUT MANAGEMENT』を読んだ

会社の先輩に薦められたのがきっかけで、この1〜2週間ほどで読了した。

結論から言うと、とても良かった。

元々この手のビジネス書やマネジメントを題材にした本は敬遠していたのだけど(後述)、4月から会社でチームリーダーをやることになって、チームの運営をどうしようかと考えていたので、丁度よかった。

内容紹介

この本は1984年に発行された『ハイ・アウトプット・マネジメント』に加筆・修正して、1996年に発行された『インテル経営の秘密』の復刻版らしい。
その題に違わず、著者であるアンディがCEOとしてどのようにインテル社を経営してきたかの、根底にある考え方が事例とともに描かれていると言えよう。

理系出身の著者らしく論理的な文章で、抽象化が上手く、事例が的確で、陳腐な(自明な)内容は少ないと感じた。

想定読者層

この本が読者層として強く想定しているのは「ミドル・マネジャー」と呼ばれる人たちである。
日本語にすると、「中間管理職」となるだろうが、それだけでなく、組織の中で知識や技能に秀でた「ノウハウ・マネジャー」という人たちも加えたいとしている。
その人たちも組織の複数の人々に影響を与え得るからである。

本書の一部では人事考課など本当の管理職しか実施しないであろう仕事について取り扱っているが、その他の7〜8割の内容は、これらの「ノウハウ・マネジャー」の人たちにとっても参考になるだろうと思った。*1

そういう意味で、ターゲットの裾野がとても広い本である。

章立て

第1部では、単純なモデルケースとして「朝食工場」なる工業会社を考案し、生産管理に関する考え方を述べている。

第2部では、「マネジャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット」という等式が出てくる。
マネジャーは自分の組織の中の「小CEO」として、テコ作用(=レバレッジ)を最大化するように行動すべし、と述べられている。

第3部では、組織が数十名以上の規模に肥大化した状況を考え、組織構造や人をどのように所属させるか、といった話が述べられている。

第4部では、動機付けや人事考課、採用、研修といった話題が出てくる。

1 on 1の実施方法

インテル社ではマネージャーと部下の間の1 on 1ミーティングを実施している。
これの意義や効果的な実施方法については、主に第2部 第4章「ミーティング」で述べられている。

この本を読む何ヶ月か前に下の記事を読んだことを覚えていたが、この記事の元ネタが『HIGH OUTPUT MANAGEMENT』だったことに、読み返してみて気づいた。

1 on 1ミーティングの意味は色々あると思うけど、新米のチームリーダーとしては、メンバーからチームの課題など情報収集できる貴重な機会だと思っている。

経営の問題とは関係ないけれど、本の中で「ワン・オン・ワン・ミーティングは家庭生活においても役に立つ」と述べられていたのは面白かった。

感想

チームの大小を問わない「マネジメント」に関する多くの仕事について概観した本であり、ロジカルでわかりやすく実践的なので、色んな場面で参考書的に使えるのではないかな、と思った。

また、「ノウハウ・マネジャー」的な人はたぶんどこの組織にもいるが、その価値を適切に評価することは難しそうである。
だが、その人たちが組織のアウトプットに寄与しているケースは多いだろうから、ちゃんと計測して評価に反映できると良いなぁと思った。

終わりに

自分やチームのテコ作用を最大化させられるように行動したいものである。

次に読むマネジメント関係の本の候補としては、『エンジニアリング組織論への招待』が気になっている。

余談:マネジメント系の本を敬遠していたこと

これの主な理由として、第一には、職種がソフトウェアエンジニアで、これまで管理職に就いた経験がない、というのもある。
他方、マネジメント系の本については、なんとなく、経験則に基づいた話が多かったり、考えればわかるような自明のことをわざわざ書いているような印象を持っている、というのも理由に含まれる。

でも、『HIGH OUTPUT MANAGEMENT』は良かったので、きっと良い本は良いのだろう。

先日、下のようにつぶやいたが、過去からもっと学んでベストプラクティスを実践したいものだ。


*1:日本のIT業界では「〜に詳しい男性」という意味でよく「〜おじさん」と称される。

デビットカードを導入して3ヶ月が経った

「現金、バイバイ」

…のキャッチコピーでおなじみの緑の銀行のデビットカードをご存知でしょうか。

昨年10月に思い立ってこちらを入手し、以降、日常的に使うようになりました。
本記事では、その経緯や用途、良かったことなどを記します。

結論的には、完全に現金にバイバイとは行きませんでしたが、ある程度はキャッシュレス化できて良かったです。

導入理由

  • 現金は不便だから。時代はキャッシュレス(日本ではなかなか進んでないけど)。
    • 個人的には、小銭のやりとりだったり、ATMから引出したりと些細なことだけど面倒だった。
  • 一方で、決済をクレジットカードに寄せるのは不安があった。
    • 引き落としまでタイムラグがあるので、支出のコントロールが難しくなる。
    • 当時も今も、クレジット払いによる支出については、どのカードでいくら使ったかぐらいしか管理できていない。

デビットカードそのものは昔からあるものなので、同じ理由でもっと早く導入しても良かったのですが、後述するiD対応が(現時点では)かなり便利なので、件のカードが登場したこのタイミングで良かったと言えるかもしれません。

このカードの機能・特典

機能:

  • iD対応
    • iDは、ドコモが提供する電子マネー。公式サイト: http://id-credit.com/
    • 多くのコンビニやスーパー、ドラッグストアなどで、タッチ1つで会計できる。*1
  • VISAのクレジットカードとして使える
  • Web上で明細を確認できる

特典:

  • 月の利用額の0.25%が翌月にキャッシュバックされる
    • 他のクレジットカードのポイント率よりは低いので、無いよりはマシ、というぐらい。

用途

現在、私がデビットカードをどんな用途で使っているかを記します:

  • 近所のスーパーでiDが使える。スーパーのポイントカードと併用できるので嬉しい。
  • コンビニでの買い物(iD)。こちらもローソンパスやTポイントカードと併用できる。
  • そのほか財布を出すのが面倒なとき。

現金を使わなくて済むシーンが増えたので、財布をカバンにしまったままでも、そんなに不便なく生活できるようになりました。

現在の現金利用シーン

それでも、どうしても現金を使わないといけないケースがあります。
以下のような場合です:

  • 飲食店。特に少額のランチ。
  • 私がよく利用するマッサージ店や整体院。
  • 飲み会の割り勘。KyashやPaymoのようなソリューションがもっと普及するといいのですが。
  • 保険診療。保険を使わないことはまずないので、これもほぼ全て現金。
  • 稀なことだが、プリペイドカードで残額が足りないとき、現金でないと駄目ということがあった。

この辺りが、今後もっと便利になっていくと良いなあと思います。

導入して良かったこと

  • 銀行から預金を下ろす回数が減った。だいたい2分の1から3分の1ぐらいになった。
  • 会計時の小銭のやりとりがなくなり、ストレスが減った。
  • 支出を管理しやすくなった。
    • 以前は、現金で使った支出については、銀行からいくら下ろしたかというざっくりとした管理しかできていなかった。
    • デビットカードでは、決済の度に口座から引かれるので、何にいくら使ったか把握しやすくなった。
  • わずかだけどキャッシュバックがあるので、現金で払うよりはメリット。
    • 上述のように、店によってはその店のポイントカードと併用できる

イマイチなこと

  • Web明細について。承認番号しかわからないので、突き合わせがしづらい。。せめて加盟店名ぐらい出してほしい。。

まとめ

iD付きのデビットカードを導入して、現金払いの頻度が減り、生活がやや便利になりました。

もっとキャッシュレス化が進んで、世の中が便利になると良いなと思います。

2017年を振り返って

2017年がどうだったか、仕事の点で個人的に振り返ります。

Capistrano Pluginを作った

capistrano-net_storageなどのgemを作りました。

これらについては、前職の技術ブログで紹介記事を書きました。

検索すると、前職以外でも使ってくれた方もいるようです。
OSSにして良かったな、と思います。

初めての転職と新しい職場で

8年半ほど勤めた会社を離れ、11月から新しい職場で働いています。
転職の経緯などについては、簡単に↓のエントリに記しました。

まだ勤めて2ヶ月なのですが、色々「興味あります」と手を挙げていたら、なんだか色々なプロジェクトに関わるようになりました。
メインの業務としては、サーバインフラに近いレイヤのソフトウェア・エンジニア業をやっていますが、他に3〜4つぐらい、全く関係ない案件に巻き込まれました。

詳しくは本記事では割愛しますが、純粋なソフトウェア・エンジニアリングに留まらないものもあります。

※ぶっちゃけ手が2本では足りなくなってきたので、手伝ってくれる人を大募集しています。

ソフトウェアエンジニアとして

昨年*1に比べるとアウトプットは少なかったなと思います。

ただ、上に書いたように色々な案件に巻き込まれていることもあり、技術のみに集中する方向でキャリアを伸ばす感じではなくなってきているように感じます。
それは、決して唯々諾々と受け身で巻き込まれているわけではなく、敢えて流れに乗って自分からそういう向きに動いているところもあります。

といっても、まだ仕掛かり中の案件が多いので、キャリアについては来年以降も悩んで模索していくことになるだろうと思います。

まとめ

転職したばかりですし、まだまだこれからというところですね。

今年もお疲れ様でした。

良い新年をお迎え下さい。