W3er

最近よく聴くおすすめ Podcast - 2022年春版

yoosee — Mon, 30 May 2022 09:16:23 +0000

以前に書いたのが6年も前になっていたので、最近聞いているポッドキャストについての更新エントリー。6年前から変わったものも変わってないものもあり。英語のポッドキャストが多めです。

Planet Money : NPR

名前の通りマネー・経済系を中心にワントピック20分程度を一話にしたPodcast。話の範囲が幅広く豊富で、また時々出てくる「やってみた」系のネタ「ジャンク債を買ってみた（そして紙くずになった）」「原油を買い付けて製油して売るところまで頑張った」、グッズ販売までしている「MARVELのスーパーヒーローを買い取るぞ！」みたいなのが楽しい。また「夕食の席で死について話す街」なんていう日本でも考えたくなるエピソードもある。

英語の発音もクリアだし、難しい単語もそこまで多く出てこないので分かりやすい。手軽な長さ、かつ話題が豊富で飽きないこともあり英語ポッドキャストを試しに聞きはじめてみたいという人にもよいと思う。新型コロナやウクライナ情勢などの時事ネタを経済面からタイムリーに解説してくれるのもよい。お勧め。

Radiolab

これも以前からずっと聞いているPodcastで、米国ではラジオ放送もされている有名な番組。番組として作られていることもあって話し方や構成、音楽のエフェクトなども凝っていて、活劇的で楽しく聴きやすい。扱う話題も科学、歴史、人物、経済、芸術、などなど幅広く、Planet Money よりも長尺な分だけトピックを掘り下げてくれる感がある。

大体週に1回更新で30分から1時間くらいの長さ。ストーリーとしてまとまっているので、ちょっと長めの時もあるけど一度で聞き切るのがおすすめ。ラジオ番組として始まってからちょうど20周年だそうですよ。

TED Radio Hour : NPR

TEDの数多いトークの中から、なにかしらテーマを決めて4,5エピソードをピックアップし、トークの一部を切り出しつつ解説も含めてまとめてくれる。TEDはとにかく種類が多くて個人的興味からのあたり外れもあるので、こうした公式まとめがあるのはありがたい。

トータルだと1時間くらいのポッドキャストなのでちょっと長いが、エピソードが分かれているので個別に聴くつもりであればさほどの負荷ではない。タイトルを見て気になったテーマの時に聴くのにも向いていそう。

Trash Taste Podcast

以前聴いていたStill Untitled; が終わったので代わりに聴き始めたアニメ・マンガ・オタク系ポッドキャスト。レギュラーは有名アニメ系Youtuberの3名。アニメの話題だけではなく、日本文化と英語圏文化の差異や違和感などもよく扱われていて、なるほど日本はこう見えているのね、と言うのも楽しめる。

構成は 3名のホスト＋αで、皆が一斉にわちゃわちゃ話すほぼ完全フリートークかつ割り込みや笑い声も多く、全般的にかなり聞きづらい。が、英語での趣味の雑談や飲み会の会話ってこういう感じなので、雑談聞き取りの練習を兼ねるのもありかもしれない。

Dan Carlin’s Hardcore History

歴史もの大作ポッドキャスト。某Slackで教えてもらった。1話が数時間から長いものだと5時間を超える超ヘビーウェイトの構成だが、歴史の語り口調がとても上手で、各種文献の引用含めて内容もよく練られているのがすごい。世界史好きならばまず興味深く聴けると思うのでお勧めしたいが、とにかく長いので聴くのには気合と時間が必要。Serial みたいに分割してくれてもいいんだけどな。

The Naked Scientsts Podcast

サイエンス系ポッドキャストは数多いので色々聴いて好きなものを選ぶのが良いと思うが、個人的にはこのポッドキャストが割と好みでよく聴いている。トピックは物理・化学・地学・生物などなど様々で、基本的に科学者個人へのインタビューを中心にした構成になっている。扱う話題もトレンドにかかわらず幅広く、こんな研究をしている人もいるんだなと言う自分の知らない科学の話題に触れられるのが楽しい。

週1度更新で約1時間弱。電話インタビューの形をとるのと、話をするサイエンティストが必ずしもPodcast向けの話し方をしてくれるわけじゃないので、たまにリスニングがしんどい時もある。

Misreading Chat

森田さんと向井さんによる、Computer Science の論文を読んでなるほどって感心するPodcast。これを聴いていると本当にCSの世界は広くて深いなと思うし、その一端に触れられるこのPodcastは大変ありがたい。CSはIT業界と地続きなので、あの技術の裏にはこんな研究や試行錯誤があったんだ、というのが身近に感じられて興味深い。

1本だいたい40分前後で、たまに1時間くらいの長さになることもある。しばらくお休みしていたが最近再開されたようで大変嬉しい。

texta.fm

ピクスタCTOの @_yasaichi さんがホストで、@t_wada さんと主にRuby On Railsを軸にプログラミング・ソフトウェアアーキテクチャの話題を扱っている。_yasaichi さんの話題の振り方と、そこへの t_wada さん解説の切れ味が素晴らしい。

現在のプログラミングトレンドを過去の経緯を話してくれるので、上の年齢の人には「〇〇年代にこれをやっていた業者がたくさんいましたが彼らは全て消えました」みたいなあるあるネタがほっこりする。ウェブ系プログラミングの話題と見せかけて t_wada さんからはエンタープライズ系の話題もよく出てくるのでそうした点でも興味深い。本職がお忙しいようで更新頻度は低いけど新作が出ると楽しみに聴いてる。

Subcscriptions List に入っているその他の Podcast

リストに入れているけど定期的には聴いておらず、トピックを見てたまに聴いているもの。解説は簡潔に。

a16z podcast
a16z として著名な Andreessen Horowitz 企画のPodcastで、大企業の創業者・CEOクラスが登場することも多い。ちょっと意識高いなと思いながらたまに聴く。
Serial
連続殺人もののストーリー仕立てPodcast。1つのトピックを複数の回で扱う。話題が重たくて長いので気合を入れて聞かないと聞けない感あり。作り自体はよくできていて面白い。
Stuff You Should Know podcast
テック、ソーシャルからドラッグまで幅広く扱うPodcast。独特の雰囲気がある。
BBC World Service - The Science Hour
BBCの提供するサイエンスニュース。旬の話題が多いのでニュースを追いたい人はこっちが良いかも。
Science Friday
これもサイエンス系Podcast。生物や医学系のネタが多めな印象。COVIDトピックが充実していたので一時期はよく聴いていた。
Tech Break - Twit
ガジェット系ニュースの短めPodcast。ガジェット系でAppleに偏らないPodcastをあまり見つけられてないので良いのがあったら教えてください。
Clockwise
Tech系トピックを2人のホストと2人のゲストで語るPodcast。1本30分弱で軽く聴きやすい。
Decode with Nilay Patel
The Verge のチーフエディターによるPodcast。Tech企業系のトピックが多く、こちらも The Verge 主催だけあってゲストが結構豪華。
Turing Complete fm
@rui314さんによるプログラミング、それも結構低レイヤー(コンパイラ、リンカ、OSなど)の話題が多いPodcast。大変面白いし個人的には難しいけど何とかわかるレベルの話題で勉強になってたけど、更新が止まって久しいのが残念。

リストにあるのはこれくらいかな。

Podcast クライアント

参考までに、Podcastクライアントは以前と変わらず Android の Podcast Addict が主。Podcast Addict は別アプリから直接操作をするIntentsが公開されているので、Bluetooth ヘッドセットが接続されたのをトリガーにTaskerから即座にPodcastの続きを再生する、等ができるのが便利。アプリとしてもまだ更新が続いているし、機能としても特に不満がない。

最近の人たちは Apple Podcast や Spotify で聞いているんですかね?

Shockz OpenComm のマルチファンクションボタンでTeams会議のミュート・アンミュートを切り替える

yoosee — Tue, 26 Apr 2022 03:36:13 +0000

Shockz OpenComm の右こめかみ部分についているマルチファンクションボタン、これにTeamsなどのテレビ会議アプリのミュートを割り当てたい。標準だとミュートは音量＋とーの同時長押しで、かつこれはデバイスのミュートなのでアプリと連動してくれない。残念ながらShockzにはキーのカスタマイズ機能がないため、Autohotkey を使ってWindows側でキーコードの動作を切り替える。

Shockz OpenComm はとても評判の良い骨伝導型ヘッドセットで、耳を直接ふさがないので長時間の電話会議でも耳が痛くならず、音質も会議の用途なら良好で、ノイズキャンセリングもあるのでリモートワークに大変役立っている。

このOpenCommにはマルチファンクションボタンというハードウェアキーがついていて、電話着信・切断や音楽再生・一時停止などシーンに応じた機能を提供してくれるのだけど、テレビ会議で頻繁に使う「ミュート / アンミュート」のトグルがアサインされておらず、ミュートは「音量+/-キーを両方長押しする」などと言う非常に使いづらい操作にアサインされている。

Autohotkey をつかってキーコードをWindowsでの別の動作に割り当てていくのだが、まずはOpenCommがなんのキーコードを飛ばしてきているかを確認する。Autohotkeyの使い方にはここでは触れないので各自検索ください。

適当なファイルに #InstallKeybdHook を記載してAutohotkeyとして有効化。
有効化したAutohotkeyのウィンドウを開く（タスクバーのアイコンからOpenするなど）
ウィンドウのメニューから View ⇒ Key history and script info を開く
OpenComm のマルチファンクションボタンを押し、どのキーコードが飛んできたか確認

Teams 会議中にボタンを押すと Media_Play_Pause が飛んできている。HSPだと思っていたんだけど、AVRCPとして操作している様子。

これが分かれば後は Media_Play_Pause をキーにした Teams の Mute Toggle を Autohotkey に記載すればいい。

TeamsMuteByOpenCommBtn.ahk:

Media_Play_Pause::
WinActive, ahk_exe teams.exe
Send, +^m
return

#z::Reload
return

このスクリプトでは以下の処理を行っている。

Media_Play_Pause が送られてきた際に
teams.exe のウィンドウをアクティブにし
Teamsでのミュートのショートカット (Ctrl + Shift + M = +^m) をアクティブウィンドウに送信

これで概ね機能していてミュートの切り替えが OpenComm のマルチファンクションボタンで出来るようになった。

ただ使っていると、会議開始直後などでキー操作を取りこぼす事がたまにある。似たような操作を F1 キーに割り当てた際も取りこぼしが発生したので、恐らくはAutohotkey側の問題なのかと思う。とは言えさほど気になるほどの頻度でもないし、ヘッドセットのハードウェアキーでミュート切り替えができるのはやはり便利である。

上記設定はとりあえず OpenComm と Teams の組み合わせで使えるものなので、他のヘッドセットと会議システムであれば別の記載が必要になるだろうが、上記手順をいじれば概ね簡単に実現できると思うので各自チャレンジして頂ければ。

追記: AutoHotKey 2.x ではフォーマットが変わったようで以下のように変更した。

Media_Play_Pause::
{
WinActive "ahk_exe teams.exe"
Send "+^m"
return
}

#z::Reload
;return

DXのゴールをコスト削減とするなかれ

yoosee — Fri, 18 Mar 2022 05:33:27 +0000

DXを進めたいと思う企業はコスト削減をゴールにしてはいけない。DXによる新たな収益の創造や経営判断のアジリティなど、将来価値に向けて投資するべきである。

企業がDXを進める際にコスト削減をゴールにしてしまうと、DXの効果の最大値が現行コストで頭打ちしてしまう。つまり、DXには現行コストの更にその一部しか投資が出来なくなる。本来のDXは新規事業の開拓による新たな収入の創出や、経営判断にアジリティをもたらすと言った、現在持ち得ていない将来価値に向けて投資すべきもの。コスト削減をゴールにするとやれることが大幅に狭まる。

なおかつ、ITでのコスト削減と言うのは概ね人員削減なので、これを続けると会社から人が減り、企業として新しいことをする体力が無くなってしまう。DXで新たな収益開拓をしようという目的に対して、これでは真逆の結果になってしまう。

なのだが、現実にはこれは結構難しい。コスト削減と言うのは成果をコミットしやすく測定も容易だが、将来価値の創造と言うのは少なくとも現場レベルではコミット出来ない。つまりこれは経営判断でやるしかない。また事業が新たな収益を生んだとして、それがDXによる効果かどうかは自明ではない。こうした問題を乗り越えるには、経営者がDXで実現できる未来を理解し、確信をもって投資し、先頭でDXの旗を振るリーダーシップを発揮する必要がある。

攻めのITを成功させるためには「経営者の確信」が必要不可欠 - W3er

ところが日本企業は往々にしてITのエキスパートが経営層に居ない。ITの力を確信できていない経営者は、現場がコミットする案件にしか投資判断ができない。そして現場がコミットできるのはコスト削減くらいしかない。欧米企業のCxOはITに詳しくないまでもITのもたらす利益は体験済みだったりするが、IT化が遅れている日本企業の生え抜きの経営陣はそうした体験もないのでITへの確信が持てていない。

歴史的に見ても、欧米の労働者と比べて日本の労働者は現場の工夫と苦労で一定以上の品質に仕事を仕上げてしまうので、そうした現場回りのIT化が思ったほどの効果にならない、という原体験が経営者にある。つまりITよりも人間の方が安かったので、日本企業の経営者は合理的判断としてIT投資よりも人手による作業を選んできた経緯がある。

一方で欧米企業ではそもそも現場の作業員はそこまできちんと働かない。例えばこれは2008年のComcast、全米最大のCATV及びインターネットプロバイダーの窓口対応である。

Comcast との長い戦いの記録 - World Wide Walker

こうした状況はそれこそITの導入により2015年頃にはかなり改善された。改善されたがしかし、それでも日本のカスタマー対応レベルには及んでいないのである。つまり米国企業にはITを導入しなければならない切実な理由があり、一方の日本企業は現場の労働者がそれより高いレベルまで人力でどうにかしてしまってきたという歴史がある。

当初のITは人間の仕事の置き換えや人間の作業の支援だったので、人間が安く、また複雑な作業も身に着けられるならば人間を使う判断もありだった。だがしかし、今のITは人間が出来ないレベルの巨大なデータを高速に処理して迅速なビジネス判断を提供するものになっている。遅いからと言って乗らなかった船が、今は高速ジェット機になっている。

なによりソフトウェアにはビジネス上最強の武器である「後出しジャンケン」、つまり「売った後に商品を改善する」ことが可能なので、市場競争力的に圧倒的に優位に立てる。これを使えない企業の立場は非常に厳しくなる。DXとはそもそも「シリコンバレーの企業の真似をすることで彼らとなんとか競争できる立場に持ち込む」のが本来の目的で、そのためにはソフトウェアの力を活用しないといけない。

日本企業も遅ればせながらジェット機に乗り換えようとしているのだろうが、今まで乗っていた自転車からジェット機へ買い替えるには当然ながら巨大なコストがかかる。DXの進んだ企業が10年かけて段階的に払ってきた費用を、DXが遅れた企業は一括で払わなければならない。ここで投資額が大きくなると当然ながら「費用対効果」を正しく理解し、株主を含めたステークスホルダーに説明しなければならなくなる。かつ、この新しいジェット機のパイロットがいない。これも育てていなければ外から雇わなければいけない。

つまりだ、DX投資の金額はコスト削減だけで説明するにはとても足りない規模に巨大化しており、将来価値に向けての投資を説明できないといけないのだが、巨額の投資を正当化するのに確実なのはコスト削減の方であり、将来価値を理解し、説明し、決断するのは非常にハードルが高い。ましてや日本の経営者には、前述のとおりITの専門知識が足りてない企業が多い。

……どうするといいのか。一応、方法はある。ITの利益を深く理解した経営者を雇うのだ。例のやたがらす人材、これを期待するなら経営陣、しかも最低でも副社長クラスの全社判断に直接指示を出せるところに置くべきなのだ。日本企業がそうした人事をできるのかという不安はあれど、やらなければどろ船で飛行機を追いかける競争を続けることになるだけだ。他企業、特にグローバル企業は待ってはくれないのだから。

Mailman2 から Mailman3 への移行の備忘録

yoosee — Fri, 18 Mar 2022 04:18:11 +0000

個人グループのメーリングリストをここしばらく mailman で運用しているのだが、ある日いつものように apt update & upgrade をかけたら気づかぬうちに mailman (2.1.29) が uninstall されていて大変困ったことになった。多分 python2 を抜いたタイミングだろうか… 見ると mailman3 という新しいパッケージがあるのでこれを入れれば戻るかなと思ったが、そんな簡単な話ではなく、ほぼ最初からの導入設定が必要だったので、備忘録として記録しておく。

なお導入と移行は一応本家にドキュメントがあるにはあるが、英語だという事を差っ引いても分かりにくい。

Mailman3 の導入

インストール自体はいつものように apt で終わり。

# apt install mailman3-full

同時に導入される mailman3-web のデータベースは標準のsqlite3を選択。特に普通のSQLサーバを使う規模でもない。

インストールが終わったらまずは mailman3 の基本設定。以下、example.com は自分のドメインに置き換えてください。

/etc/mailman3/mailman.cfg

site_owner: xxx@example.com

ここには自分のメールアドレスを入れておく。続いて mailman3-web の設定も修正。

/etc/mailman3/mailman-web.py

EMAILNAME = 'example.com'

https が使えない場合は ACCOUNT_DEFAULT_HTTP_PROTOCOL を “http” にしておくとよい。

また恐らく mailman の設定が /etc/cron.d/mailman に残っているのでこれは消しておく。

Postfix の設定

メーリングリストなので、メール配送周りを色々と調整しないといけない。mailman2 は /etc/aliases で配送アドレスをコマンドに転送していたので、まずは /etc/aliaces の記載を削除し、 # postalias /etc/aliases で更新しておく。その上で postfix の設定を変えていく。

/etc/postfix/main.cf にこんな記載を追加・更新

# Mailman configrations adding lmtp
unknown_local_recipient_reject_code = 550
owner_request_special = no
transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:/var/lib/mailman3/data/postfix_lmtp
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination}:{}} hash:/var/lib/mailman3/data/postfix_domains

配送先や relay の書き換えをしているので、postfix 再起動後はきちんとログを見たりテスト配送しておかしな影響が出ていないことを確認したほうがいい。私の場合は local_recipient_maps や relay_domains が上書きされてしまい、以前に入れていた設定が無効になるというやらかしがあり、あわてて修正した。

apache2 の設定

mailman3-web を利用するためにウェブサーバ側の設定も必要。ここでは apache を使っている。mod_proxy_uwsgi を有効化。

# a2enmod proxy_uwsgi

続いてapacheにmailman3-webのURLを解釈させるよう、設定を持ってくる。名前は何でもいいんだけど分かりやすいように。

# ln -s /etc/mailman3/apache.conf /etc/apache2/conf-enabled/mailman3.conf

Debianのmailman3-webパッケージで導入されるこの設定ファイルには何故か不具合が残ったままらしいので修正しておく。localhost/ の最後についているスラッシュを削除するだけ。

ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost

ここまでやったら postfix, apache, mailman3 のサービスをそれぞれ再起動しておく。一応これでセットアップ自体は完了。

Mailman (2.x) から Mailman3 へのメーリングリスト移行

幸いなことにメーリングリストのデータ移行コマンドは提供されているのでそれを使う。まずは元々あったメーリングリストを新たに mailman3 で作成し、そのリストにデータをインポートする。なお LIST-ID は各々移行したいリストに読み替えたうえで、移行するリストの数だけ下記作業を繰り返し行う。

# mailman create LIST-ID@example.com
# mailman import21 LIST-ID@example.com /var/lib/mailman/lists/LIST-ID/config.pck

メールアーカイブも移行したいのであれば mailman3-web に含まれるコマンドを使って移行する。

# cd /usr/share/mailman3-web
# python3 manage.py  hyperkitty_import -l LIST-ID@example.com /var/lib/mailman/archives/private/LIST-ID.mbox/LIST-ID.mbox
# python3 manage.py update_index_one_list LIST-ID@example.com

ここまで root で作業しているのでおかしくなっている permission を修正する。これをやらないとログにエラーも出ずにメール配送がひたすら内部で bounce して retry していたりするので気づくまで厄介だった。

# chown list:list /var/lib/mailman3/lists/ LIST-ID.example.com
# chown list:list  /var/lib/mailman3/template/lists/LIST-ID/ja/

これで一応の移行までは完了しているはず。

mailman3-web のウェブインターフェイス側での設定

mailman3 ではフロントエンドを postorius という django ベースのサービス上で構築している。なので django としてのサイト設定など、セットアップの範囲が多少広い。

まずは django / postorius の管理ユーザを作成する

# cd /usr/share/mailman3-web
# python manage.py createsuperuser

ここで管理ユーザのアカウント名、メールアドレス、パスワードを入力してCLI側の作業は一旦完了。ウェブサイトの方にアクセスして設定を継続する。

https://example.com/mailman3/

にアクセスすると、apache の設定がちゃんとできていれば postorius の画面が立ち上がるのでログインする。なおログイン時には登録したメールアドレスに確認メールが来るので、一旦そちらのメールを開いて確認リンクをクリックすることでアクティベーションを完了する。

ログイン後、上部メニューの Domains からデフォルトドメインを自分のドメインに変えておく。一覧にある SITE_ID = 1 のドメインが example.com になっているはずなので、この隣にある Edit リンクから Django Administration サイトに入って自分が使うウェブサーバのFQDNに書き換えておく。これで一旦完了。

mailman-web からのリスト管理

これで mailman-web も問題なく使えるはずなので、後は List 管理から移行されたメーリングリストのメンバーリストが正しく移行されているかなどを確認しておくとよい。mailman 2.1 に比べてもかなり細かく設定ができるし使い勝手もよくはなっているが、とは言えさほどいじるものでもないかと思う。

無駄な検討を止めるために必要なもの

yoosee — Tue, 18 May 2021 08:50:46 +0000

かなり間が空いてしまったが、生産性を上げたいならまずその「検討」を止めよの続きとして、ならばどうやったら「検討」を止められるのかを考えてみたい。

基本的に検討はなんらかの判断をするために行うものなので、「判断」が行われた時点で検討が終了する。であれば判断はどうしたら迅速に行うことができるのか。それに必要な3つの要素は「情報」「専門知識」「裁量」である。判断をするために必要な材料が情報、判断をするための能力が専門知識、組織の中で判断を承認させるための権限が裁量、という形になる。

大事なのは、この「情報」「専門知識」「裁量」を同一人物が持ち合わせること。外からもらえる情報はともかく、専門知識と裁量は同じ人物の中に同居している必要がある。つまり無駄な検討を止めて迅速な判断を行うには裁量を持つ意思決定者が十分な専門知識を持っている必要がある。

多くの場合の判断は未来に対して行うものだ。未来は未知なものであり、未来を判断する情報が全て揃っていることはまずない。そうした状況でも判断するために必要なのが専門知識だ。専門知識によって「明確に劣る選択肢」や「非現実的な選択肢」は即座に破棄できるし、追加検討に何が必要なのかも指示として明確に示すことができる。

日本に限らずどの国でも上級管理職になるほど現場に近い専門知識からは距離が開いてしまうものではある。しかしながら体系だった専門知識を更新するのは不可能ではないし、事実海外の管理者はかなりの量を勉強に費やしている。そもそも専門知識なしに判断するのは非常に困難なのだから、専門知識は必要に迫られて身に着けるものなのだ。

企業における専門職経営層の重要性

多くの国の海外企業では昨今、C-タイトルの種類が増えている。C-タイトルは CEO、Chief Executive Officer (最高経営責任者) のように、ある業務領域での経営トップを示す呼称だが、旧来からある CEO, CFO, CTO, CIO, COO など以外にも、最近は CSO (Strategic), CMO (Marketing), CCO (Communication), CHRO (Human Resource) などなど、C 付きの役職が増えている。

List of corporate titles - Wikipedia

これは内部の昇格や外部からよい人を取るために待遇と見栄えの良い新しいポジションを作っている事情の企業もあろうが、本質的には経営層レベルに業務領域に応じた専門職が必要になっているという事でもある。各業務の専門性が深まってきており、一人の経営者が全ての専門知識を身に着けて意思決定するのが難しくなっているのだ。

専門経営職の必要性は CFO が分かりやすいかもしれない。CFO を置いている企業で、社長や副社長がCFOを兼ねることはあまりない（もちろんCFO専任の副社長はいるだろうが）。CFOは財務や会計に関するスペシャリストであり、その道の専門知識とキャリアが必要だと認識されているからだ。日本でも恐らく財務担当の上級職は財務畑のキャリアを積んできた人が多いだろう。ところがこれが CTO や CIO になるとそうした認識が薄くなり、副社長等がそうしたCタイトルを数多く兼務している企業もある。

現代のビジネスにおいて専門知識は深化を続けているが、そこには企業経営にITシステムが浸透してきたことが関係している。ITシステムにより、今まで個人の暗黙知やノウハウで行われてきた様々な業務、例えばマーケティング、人事、財務、会計、営業、等々がシステムに実装されることにより形式知として可視化されたのだ。形式知はこれまでのように人間の転職や退職によって消滅せず、よりよい方法を模索しつつ深化していく。この深化についていくために、人間側も個別の業務領域ごとの専門知識を深める必要が高まってきているのだ。

ここでの専門知識とは「20年前はこうだった」や「私の経験からいうと」などという不確かなものではない。専門知識は形式知であり、体系だった学問であり、大勢が業務の中で知識と経験を積み上げたプラクティスの上澄みであり、業界で用いられる標準的なフレームワークである。これは業務経験があれば必ずしも身につくものでもなく、自発的に体系を学ぶことが必要なものが多い。業務からは業務で扱っている事象しか学べないからだ。

特に IT で言えば、情報技術に関する「基礎技術」と共に、また業界の「ベストプラクティス」と呼ばれる知識のライブラリを踏まえることが多い。つまり IT に関する判断には、自身のビジネス現場を理解しつつ、ITが適用される業務ドメインに対して、業界標準に照らしてベンチマークするだけの知識と手法が必要になる。

これは CIO についてのみの話ではなく、他の Cタイトルについてはこの条件が反転する。つまり今の意思決定レベルの人たちは、自身が担当する業務領域の専門知識に加えて、それが駆動するITシステムについての知識もある程度必要になるという事だ。

日本企業における課題としての「プロの不在」

翻って日本企業を見ると、流石に最近はジョブ型だの言われ始めていて専門性の高いキャリアも効力されるようになってきているが、相変わらずジェネラリスト育成を主眼においた定期人事異動をしている企業も少なくないのではなかろうか。まして残念なことに、専門知識のない管理職は再生産される。何故ならいま管理職をやっている専門知識のない人たちは、専門知識がある人をきちんと評価できないからだ。

日本企業、特に大企業における謎の風習に、人事異動時の挨拶がある。「全く新しい業務なので慣れるまで皆さんにご迷惑をおかけするかもしれませんが」というあれだ。若手の担当社員ならともかく、課長職や部長職、下手するとそれ以上の経営層に近い職ですらこうした挨拶を聞くことがある。謙遜されているならばまだしも、実際に未経験の業種に移動させられる管理職は決して少なくないだろう。

これはつまり、その分野の素人が意思決定の責任を負わされているという事だ。別にそうした人たちを責めたいわけではない。彼ら・彼女らもつまるところ制度の被害者なのだから。しかしそれ以上に悲劇なのは、そうした管理職の下で働く人たちだ。そうした人たちは、つまるところ前出の「意味のない利益に結び付かない無限の検討」を続けることになるのだから。

ここから脱する手段は明らかだ。意思決定者に専門知識を持たせる。そのためには企業としてのキャリアパスを見直す必要もあるだろう。意思決定者層に向けた教育プログラムも見直すべきだ。また手っ取り早く会社を変えることを考えるならば最初の経営層専門職は外部から雇用することも必要だろう。専門性のない上司は専門性の高い部下を評価できないので、トップ層に専門職がいることは非常に重要になる。

まとめ

無駄な検討を止めるため、迅速に意思決定を行うためには、「情報」「専門知識」「裁量」が意思決定者に集中することが望ましい。このなかでも外部から与えるのが難しく、意思決定の礎になるのはその判断領域に関わる「専門知識」である。

業務の専門性が深化した現代では、専門知識なしに意思決定をするのはほぼ不可能になっている。特に日本の大企業がよくやるようなジェネラリスト育成、専門性のない人を上級管理職として配属するような人事はやめるべきだ。またとっかかりを作るためにも経営レベルの専門職者が存在すること、いないなら外部から採ることが必要になる。

ダイエット成功のコツはカロリー収支赤字の習慣化

yoosee — Tue, 21 Apr 2020 06:34:37 +0000

2019年の8月から12月にかけてダイエットを実践してそこそこ成功したのでその記録。成果としては 5か月間で体重 6 kg / 体脂肪率 7% の減少。 筋量を殆ど落とさずに脂肪を落とすことができた のがポイント。ズボンもウェストサイズが緩くなった。

やり方は基本的に食事制限と筋トレ。消費カロリーが約2,200kcal/日に対して摂取カロリーがざっくり1,600kcal/日ほどで、カロリー収支を赤字にするのが全てのダイエットの大原則だ。

朝食は牛乳200ml ⁺ プロテイン (約200kcal)
昼食はお握り1個とサラダチキンバーにドリンク (約400kcal)
夕食は普通に食べるが炭水化物(主にお米)は半分以下にする (約800kcal)
間食ほどほど (約200kcal)

間食を辞めればもっと早いベース、ないし朝昼をもう少し食べられたんだけど、辞められなかったので割り切ってその分は食事から減らす。

これにあわせて運動・消費は以下の通り。

1日8,000歩以上（行き帰りの1駅分追加で歩いた）
Home Workout の運動を1日1セット (上半身・下半身・腹筋をローテーション)
プールで主にクロールを週に1 or 2回、平均 1.5km / 回

消費カロリーは 2200kcal 程度だとするとカロリー収支が1日マイナス 600 - 700kcal くらいあるが、実際にはあまり歩かない日やランチを外食している日、飲み会などで夕食のカロリーが多い日がある。30日間で計算すると、脂肪重量減が月に 1.5kg 程度なので逆算して 7200 x 1.5 = 11,000kcal 前後、1日当たりで400kcal程度の計算になる。ここでは脂肪の1㎏あたりのカロリーを7200kcalとする。

歩行以外の運動は消費カロリーの収支を改善するよりも、筋量の維持・向上を目的としている。筋量・代謝量的には下半身が支配的なので足の筋肉を鍛えるのがおすすめだが、嗜好としては上半身もそれなりには鍛えたい。

余談だがプールは筋量のみでなく心肺機能によく効くので大変よろしい。週1,2回程度でも以前に比べて明らかに心配能力が向上して、多少走っても息切れもしなくなったし風邪をひきにくくなった気もする。なにより 1.5km だと1時間もかからない運動なのに充実感が高い。設備がないとできないのが難点だが、都内だと公共プールやジムなどそれなりに見つかる。

ダイエットを成功させるために必要な3つのこと

という訳で一応きちんと成功したのでえらそうに書いておくが、ダイエットを行う上で大事なことは3点。「カロリー収支の赤字化」「筋肉の維持」「習慣化」だ。

1. カロリーの収支を赤字にする（ために食事を減らす）

ダイエットに必須な条件は消費カロリーが摂取カロリーを上回る、つまりカロリー収支が赤字になること。方法は2つで、食べるのを減らすかカロリー消費(運動)を増やす。一般生活を送っているだけでは消費カロリーは大きく増やせないので、摂取カロリーを減らすのが王道になる。運動だけで減らすには、最低でも週に3度以上2時間以上の運動か、毎日5㎞走る・1時間半以上自転車に乗る、程度は必要になる。

安静時の1日あたり消費カロリーは男性で 2000kcal , 女性で 1600kcal 程度なので、摂取カロリーがこれを下回るのが望ましい。これは意外と難しくて、1日2000kcalとして3食食べていれば1食あたり 700kcal を下回る必要があり、これは間食や飲み物を含まない。コンビニ弁当などを見るとカロリーが書いてあるが、普通の弁当でも700kcal程度は簡単に超えてしまうので、それなりに気を付けないと減らせない。

脂肪 1kg あたり 7200kcal なので、脂肪だけで体重を1カ月に 1kg 減らすには 7200 / 30 = 240kcal は減らさないといけない。それ以上の体重を減らしたいのならそれに応じて摂取カロリーを減らす必要がある。現実的には1日 300-500kcal 程度減らせると成果が見えやすい。

2. 筋肉を維持する（ためにプロテインを飲む）

摂取カロリーを減らすと何が起きるかと言うと筋肉も痩せる。特別な運動をしなかった場合、脂肪と筋肉の減り方は概ね半々と想定される。仮に 3kg 痩せた場合、脂肪が 1.5kg 減るのと同時に筋肉が 1.5kg 減ってしまう。

筋肉が 1.5kg 減った場合、基礎代謝と運動代謝を合計して1日当たり約 100kcal の代謝が落ちる。カロリー収支をダイエット前に戻したとして、1日100kcalの支出が減っている状態なので、単純計算で1カ月で3000kcalが過剰になる。脂肪量でおおよそ 0.4kg 程度だが、効果が永続するので半年たつと 2.4kg の脂肪増になる。

という事でダイエットをする際には筋量を増やさないまでも維持することがとても大切だ。このためには適度な運動・筋トレが必要だが、そもそもカロリー収支を赤字にする量の食事では、筋肉どころか代謝に必要なたんぱく質が足りなくなる。タンパク質は1日最低60g、できれば80gは取りたいが、肉や魚でタンパク質をそれだけ取ろうとすると相当量の脂肪がついてくる。グリコのサイトから可食部100gあたりのタンパク質・脂肪量の表を引用する。

摂取 1g 当たりのカロリーはタンパク質 4kcal、脂質 9kcal、炭水化物 4kcal 程度なので、上記のように食物からタンパク質を補充するとそれと同じくらいのカロリー分の脂質を取ることになってしまう。ダイエットを考えたときに、これはいささか効率が悪い。脂肪も大事な栄養素ではあるが、ダイエットの際には真っ先に減らすべき栄養素でもあり、通常のダイエット程度得あればさほど不足しない。

余計なカロリーを取らずにタンパク質を補充するのに役立つのがプロテインである。私は SAVAS ウェイトダウンヨーグルト風味を1日1度、水泳など運動が多かった日は2度飲んでいる。またこれは個人の感想だが、ソイ(大豆)プロテインはそれなりに腹にたまりやすく、朝食をプロテインのみにした際にも何も食べないよりは耐えやすい。

3. 習慣化する（ためにルールとルーチンをシンプル化する）

今回は朝昼については食事をほぼ完全に定型化・習慣化している。人間なにかを続けようと思ったら習慣化するべきで、習慣化できるのは毎日ルーチンとして定型化できるものなので、特定のものしか食べない・特定のものを抜く、などはシンプルで習慣化しやすい。

ちなみに1月時点でもまだ続けていて、もう1㎏くらい減らしたらもういいかなと言う気分ではあるのだが、半年近く習慣化してしまうと逆に辞め時が難しいというか食事の戻し方も考えないといけないのが少し悩ましい。それくらいしっかり習慣化できたという事ではあるのと、あと朝昼については食事が非常にシンプルなので実は手間的には楽、と言うのがあったりする。

ダイエットに役に立つツール

Wifi体重計

ダイエット前からのものだが、体重体脂肪計は Withings の Smart Body Analyser WS-50 を使っている。乗るだけで Wifi 経由でクラウド・スマホに体重と体脂肪率が同期される大変便利な体重計だ。体重の増減はダイエットのモチベーション維持に重要な要素だが、短期的な（数日内での）増減は殆どが体の水分が増減しているだけなのでダイエット的には全く意味がない。最低でも1カ月以上のトレンドを見るにはグラフにする必要があり、体重計に乗るだけでグラフを作ってくれるこうしたデバイスは大変便利である。

ウェラブル活動量計

Fitbit Versa を常時つけていて歩数管理をしている。ターゲット歩数を設定できるので少し足りない時にちょっと追加であるこう、といったモチベーションになる。またダイエットに直接関係はないが、スリープトラックをしていて睡眠時間や睡眠の質を改善するのにも役立っている。

こうしたツール類は個人の好みもあるが、可視化はモチベーションに意外と強く効くのでなんらかのツールを使ってみるのは良いと思う。いまだとスマホで気軽にレコーディングダイエットをする方法もあるだろう。

運動促進用アプリ

毎日の運動用に使っている Home Workout は、自宅で道具を使わずに出来る腕立て・腹筋・スクワットなどの動きを中心に10分から15分ほどの運動を指導してくれる。道具がなくても運動できるので始めやすいし、最初は Full Body の 7x4 チャレンジを低負荷から始めると、毎日の運動 28日間指導してくれる。毎日の運動を通知もしてくれるし、月の実施日を表示してくれるのもモチベーション維持に役立つ。

この手のアプリは何種類もあるので（Workout で検索するとたくさん出てくる）、いくつか試して自分に合うものを見つけるのもよい。

結局のところ、人間は難しいことを継続できないので、シンプルで実効性のあるルールを習慣化することがおすすめ。その場合の絶対的ルールはカロリー収支を赤字にするなのは言うまでもない。

EDCとしてのたった119gの超軽量折りたたみ傘

yoosee — Wed, 13 Nov 2019 00:19:03 +0000

日本に戻ってからどうもEDCネタが遠くなってしまったが、思えば折り畳み傘も毎日持ち歩けばそれこそEDCだなと思ったのでひとネタ。いわゆる Urban EDC というものである。そういうジャンルもあるのですよ。

モノはこれ。小さくて軽くて素敵。重さは 119g しかない。

hands＋　17　超軽量折りたたみ傘　55cm　ターコイズ｜【東急ハンズネットストア】 (Amazon.co.jp)

55㎝のモデルは119gだが、ひとサイズ小さい 50㎝だとなんと 100g を切る 99g 。

hands＋　17　超軽量折りたたみ傘　50cm　ネイビー｜【東急ハンズネットストア】 (Amazon.co.jp)

この軽さとサイズになると持ち歩くのに本当にストレスがない。大抵のカバンに場所を取らず入るし、カバンに 100g が足されてもほとんど重さなんて感じない。100g は今どきのスマホより軽くて、だいたいキュウリ1本くらいの重さ。

軽量化重視なので自動開閉だのの機構はないし、少し華奢な感じではある。特に下ろくろと上はじき（というらしい、開いた傘を止める部分）の強度はちょっと不安。広げるのも畳むのも少し手間だ。とはいえこれはあくまで非常用の傘、日常の利便性よりも携帯性という替えがたい長所がある。

普段使っている小型ショルダーバッグ、AS2OV BALLISTIC NYLON MINI SHOULDER 02 にスッと入ってしまうのは素晴らしい。これで 55㎝傘なので、さした時のサイズは普通に大きめの傘で、携帯傘にありがちな、傘が小さくて体が濡れてしまうみたいな問題はない。また華奢とは書いたものの普通の風雨程度で壊れる感じはなく、その辺は hands+ ブランドを付けているだけあってきちんとしている。

元々ミニマリストを自称しているので日常持ち歩くものは極力少なく軽くしたく、実際カバンの中は財布と e-book リーダー、多少の文房具くらいしか入っていないのだけど、この傘はそこに足すだけの価値があった。不意の雨でも慌てなくていいし、雨が降りそうな気配があるがまだ降っていない、なんて時に傘を追加で持っていく必要がない。ミニマリストの強い味方である。

ちなみに雨が降っている日はこれとは別の自動開閉折りたたみ傘を持って出かけている。これは本体重量 430g でそこそこ重い。その分だけ丈夫で1年以上使っていて今のところヘタってないし、自動開閉で畳むのも簡単。折りたたみ傘というよりは普通の長い傘の代替品である。吸水折りたたみ傘カバーとあわせて使っているので駅で畳んでカバーに入れてしまえば満員電車でも迷惑かけたりしない安心感があり、こっちはこっちで重宝している。

日本企業のITが既に陥っている危機的状況について

yoosee — Wed, 28 Aug 2019 09:06:16 +0000

日本企業のIT投資が増えるの減るのという話が未だにニュースに出ているが、2019年の現時点において、日本でITを導入するハードルが他国に比べて既にけた違いに難しくなっていることを指摘する声は少ないように思う。これは不可逆であり、今後はより難しくなるだろう。

日本ITの辺境化

なにが問題なのかと言うと、グローバルで展開しているエンタープライズ向けのソフトウェアベンダー、サービスベンダーが既に日本市場に対する投資や個別の対応をほとんど行っていないという現実、つまるところITにおけるジャパンパッシング、日本ITの辺境化である。

ITシステム・サービスは既にグローバル市場が戦場になって久しい
グローバル市場ではグローバルで標準化された仕様をそのまま (Out-of-Box) 持ち込むことが推奨され、また言語は原則として英語である
グローバル市場において日本市場は言語や商習慣の障壁が高い割に小規模な辺境市場に過ぎない
辺境市場である日本市場に対して、開発的にも導入人材的にも気合を入れて投資する企業は既に少ない

ITマーケットでよさそうなサービスを日本で使おうとしても日本法人などなく、下手すると代理店もなく、日本語の解説資料なども乏しく、日本市場向けのカスタマイズなどしてくれる人もいない。導入コンサルを受けようにも日本語で作業できる人材も少なく、導入事例も当然少ない。既に無い無い尽くしに陥っているのだ。

社名は伏せるが、日本に昔からある外資の大きな日本法人ですら、シンガポールのアジア統括会社などと比べると体制も技術力も本国との交渉力も弱い、と言う状況が増えている。日本法人と一か月話しても埒が明かなかった契約交渉がアジアの統括マネージャーと30分話したら当人の権限で一発OKになったり、日本法人とシンガポール法人から異なった導入条件やサービス仕様を示されて確認すると毎度シンガポール側が正しい、などという状況は既に日常的に起こり始めている。

「英語」という基本かつ高いハードル

サービス提供元の企業が供出する製品情報や事例、Webiner (ウェブ上のセミナー動画) といったコンテンツも、英語のそれに比べて日本語コンテンツは非常に少ない。ITエンジニアの人であれば色々と体験しているだろうが、日本語だけの情報では既に仕事が出来ない、ないし、日本語で情報提供や対応されることを要求条件とすると選択できるシステムが一気に減ってしまう、と言うのがいまの日本でのITシステム導入に関する現実である。

この背景にはそもそもITというものが世界中でコモディティ化している状況がある。しばらく前ならば「ITも各国の状況を踏まえてローカライズ」などという認識もある程度あったが、今では「まずはグローバルでの標準化と共通化ありき」である。つまりは日本に限らず海外の大半の国でも似たような状況になっており、これに対応する方法自体はごく単純であって一般的なものだ。「英語で仕事をする」のである。単純かつ一般的なのだが、今の日本企業には恐らく非常にハードルが高い。

システムの仕様と海外の事例を英語のまま理解して日本企業に展開する
導入・保守・更改といった契約と運用を海外の法人と直接議論する
社内プロセスをパッケージをそのまま使った形を基本として標準化する

ITシステム担当者が少なくともこの程度できる必要があり、かつこれはまだ入り口に過ぎない。

更に難しいのは、ITを導入するチーム自身が英語や海外とのやり取りに慣れているというだけでなく、ITシステム導入に置いては企業内の業務部門を強く巻き込むのが必須であることだ。ITは現代企業においては即ちビジネスそのものであり、つまりIT部門のみではなく業務部門の人たちも正しく要件を伝える必要がある。つまりそうした要求部門・関連部門の人たちも海外のベンダーやコンサルとやり取りできないと甚だ効率が悪い。しかしこれは「社内公用語を英語にしろ」みたいな話であり、殆どの日本企業では流石に無理に見える。

ところで最近聞いた話をひとつ。グローバルにビジネスを展開している企業が各国拠点に対して統合されたITシステムを張り出すにあたり、ITシステムサポートのヘルプデスクを開く話になった。多言語対応をどうするかなども検討があったようだが、結論は「サポート言語は英語だけでいいよ」という国がほとぼ全てで、ローカル言語対応を要求した国は日本の事業所だけだった、などという笑えない話もある。実体験としても、欧米圏は既に当然として、少なくともグローバルに顔を向けて仕事をしている企業において、アジアや中東の国でも英語で仕事の話ができない社員がいる国などほとんどない。

恐らくこうした危機感を持っている企業自体が現時点では少ない。それは大抵の日本の大企業はSIerと呼ばれる日本国内のIT導入ベンダーを抱えており、基本的にはそこに丸ごと頼る形が変わってないからだ。本来であればそうした企業が上記のような「翻訳」業務も受けるべきで、実際に海外ベンダーを担いで日本対応のフロントに立つ形も少なくはない。とは言え海外の豊富なシステムに比べるとそうした日本対応されているベンダーは少なく、選択肢に乏しい状況には変わりがない。

この話にオチや打開策はない。最終的には選択の余地なく、アジアの一地方としてグローバルの一部にならざるを得ない日本だが、恐らくそれまでの間、非常に制限された国内で使えるITを使いまわし続けるのだろう。それは他国の企業が既に当たり前のものとして享受している、ITが作り出す非常に強力な競争力の底上げを享受できないままグローバルのプレイヤーと闘わなければならないという、竹やりでB29を墜としに行く、ヒノキの棒でラスボス退治に駆り出される、そんな未来が既に来ていることをどれくらい真剣に危機と感じるのかという話であり、楽観的な未来はえがけない。

生産性を上げたいならまずその「検討」を止めよ

yoosee — Fri, 17 May 2019 06:46:15 +0000

ビジネス新書みたいなタイトルを付けてみたのはさておき、日本企業の生産性がどうのという話をする際に「検討」というキーワードは避けて通れない。

日本の特に大企業でなにかをやろうという際には膨大な「事前検討」が欠かせない。検討資料が作られ、上司に事前レビューされ、打ち合わせで説明が行われ、コメントされ、コメントを反映するために更に追加の検討が行われ、確認のために打ち合わせが再度、再再度、再再再度設定され、と、これが下から上に向かって階層の数だけ繰り返される。またこうした事前検討の多くは机上検討で、あちこちから情報収集をし、情報収集のために打ち合わせをし、それを整理をして資料にまとめてという行為を繰り返す。こうした検討は、関係する全ての人々が「納得」するまで続く。

結論から言えばこんな「検討」は無駄だから止めるべきだ。

「検討」は金を稼がない

コミュニケーションは金を稼がないという話は以前書いたが、同様に「検討」も金を稼せがない。検討が価値を生むのは少なくとも検討を踏まえて「決断」が成された時点からである。生産性を考えるのであれば、金にならない行動は可能な限りで最小にするのが基本なのだから、検討に費やすコストと時間は必要最小限にするべきだ。

「検討」は経験値を増やさない

ゼロとは言わないまでも、検討をいくら続けても蓄積できる専門性や経験値はたかが知れている。特にスペック比較や市場調査などの机上検討は率直に言って本質的な知識や経験をほぼ全く増やしてくれない。多くの場合において深い経験をつめるのは実装や運用のフェーズに入ってからである。

今の時代、特にクラウドサービスであれば多くは5分もあればテストアカウントを作って試し始められるし、クレジットカードでもあれば本番環境での小規模な利用を試すこともできる。検討と言っても少なくとも早々に現物に触るべきだ。少なくともほぼ何の役にも立たない、往々にして自社が優位だと恣意的に言うだけの「機能比較表」のような〇×表を作っている場合ではない。

「検討」は無限に続けられる

検討はつまるところ決断の先送りなので、十分検討したという客観的な指標に乏しい。意思決定者が必要だといい続けていれば検討はいつまでも際限なく続けられる。

日本企業の意思決定者は、少なくない割合で残念ながら、部下から上がってきた資料に「コメント」することが仕事だと思っている。コメントを受けた下のものがどうするのかと言えばそれは「追加検討」するのである。端的に言って無駄でしかない。意思決定のために追加の検討が必要なのだとしたら、意思決定者は「意思決定のためにはこの点の検討が必要である」と調査事項を明示すべきであり、それ以外の検討は意思決定に不要なのだから無駄である。

生産性に寄与する意思決定とは「やらないことを決めること」だ。検討を増やすだけの意思決定は生産性に対して害である。

サマータイム（DST）に関する個人的な経験と好き嫌いの話

yoosee — Wed, 26 Sep 2018 08:29:30 +0000

別記事で一般的に認識されるサマータイムの社会影響についてまとめてみたが、じゃあ個人としてはどうなのかという話を少し書いてみる。結論としては、夜が明るいのはたぶん皆が思っている以上に嬉しいことが多いと感じている。

実生活における影響（個人的な体験）

私個人は2017年まで米国フロリダのマイアミ付近の街に在住していて、サマータイム・DST は何年も経験している。最初に書いておくが、個人的にはDST導入推奨派だ。夕方から夜の入り口が明るいと、屋外での活動が問題なく出来るので好きだった。米国の場合はそもそも暗い屋外は安全面から出歩きを控える必要があるという背景もあるのだが。

DST には（もちろん）良いところがある

DST中は夜も屋外が明るく、フロリダの 8月だと大体21時くらいまで外が明るいし、9月後半になっても20時台までは明るい。在住当時だと仕事帰りや夕食後に Ingress や Pokemon Go をしたり、夕食を屋外席のレストランで食べたり、（ビーチが近い街だったので）夕方のビーチを散策したりと、なかなか有効に活用できていたやに思う。あとアメリカ人的には夕食に裏庭でBBQをするという大変重要なイベントの助けにもなる。

これは6月末だが、こんな感じで夜7時を過ぎたビーチがまだまだ明るい。ここから1時間くらいは明るいので散歩などが気軽にできる。

またDST入りのあたりは朝が暗くなる。具体的には住んでいた辺りだと朝6時には日が昇っていたのが朝7時に日が昇るようになる。個人的には外の明るさに邪魔されずに安眠できるのはありがたかった。

日本での導入を考えると、8月の東京は日没が18時半前後、日の出は5時前後だが、これが日の出6時、日の入り19時半になれば夜にやれることが増えそうに思える。まして 9月に入るとあっという間に日の入りが17時台になってしまう一方で日の出はまだ5時台と言う（個人的な感覚では）アンバランスな状態なので、日の入りが 18時台になると屋外でやれることも増えるんじゃないかと思っている。

ちなみにフロリダは Permanent DST 、つまりDSTの切り替えなしに1年中DSTにすることを議会で可決する（米国連邦法の制約で実施はされていない）くらいにDSTに前向きな州であったことも、個人的にDSTに前向きな背景になっているのかもしれない。

Year-Round Daylight Saving Time? Florida Says Yes, but It’s Not So Simple - The New York Times

なおフロリダ半島は標準時であるEST (Eastern Standard Time) の基準経度 75° に対して 80° から 85° くらいの位置である。南北に長い州だが住んでいた場所は北緯25度くらいの場所で、大体沖縄と同じくらいの緯度だった。

DSTの切り替え日と（個人的な）生活への影響

米国でも批判されがちなのはDST切り替えのタイミングでのコストで、時差の調整という人間の生理リズム的な問題もあれば、単純に時計をあわせ直すのが手間と言う理由もある。

現在の米国ではDSTの切り替え日は3月の第二日曜及び11月の第一日曜と決まっている。時計が変わる日は事前に会社でも通知が出たりSNSやニュースでも流れたりするが、それでも結構忘れていて、ちょうど秋のDST終了時に旅行をしていて朝起きてもレストランが開いておらずようやくDSTに気づくなどもあった。

仕事でいうと米国内ならば一部を除いて同じ日に時計が一斉に変わるので、ミーティングの時間などに影響はないが、日本や欧州との打ち合わせが1時間ずれたり、また南米だとそもそもDSTのタイミングが逆（米国の夏はブラジルの冬）という事もあって時差を考慮してミーティングを調整しなおすのは多少面倒だった記憶はある。

最近の時計は自動時刻合わせ機能があるものが多く、スマホやPCはもちろん、家の時計も電波時計は自動的に変更されるし、腕時計も電波時計搭載のものかスマートウォッチであれば自動で調整される。車の時計も新しい機種だと勝手に修正されるようになってきているので、時計を手で直すのはそうした機能のない時計を 2,3個程度だった。まあ古い自動車の時計などは直されないままシーズンを超えたりすることもあり、時計合わせが必要な時計は面倒だったのは間違いないが、言うほど大した手間ではない。

春のDST（時計が進む）は睡眠時間を1時間奪われるので確かに厄介なのだけど、そもそも米国内でもタイムゾーンをまたぐ出張をすると1時間どころか2時間3時間の時差調整は発生するので、個人的には慣れたものであり例によってメラトニンで解消するようになってからは大したダメージはなかった。ただ子供など家族は 1週間くらいは朝起きるのが辛そうにしていた様子はあった。

ちなみにDSTの切り替え日にITシステムの特別保守を取るようなことは個人的な観測範囲では全くなかった。2007年のDST期間延長時などにはあったのかもしれないが、毎年のDST切り替え日はサポートもオペレーションも注意は払うものの、なにか特別な事前準備や当日の体制強化をするなどは記憶にない。

結論と言うほどではないが

そんな感じでDST・サマータイムは個人的に好きだし悪影響ばかりというわけではないし日本でも導入すればいいのにと思っている。現在の情報システムが運営する社会に置いて時計を動かすことは簡単ではないのは承知なので、それなりの時間とコストをかけて準備しつつ、生活上の問題はまあそういうこともあるよね、と流せるような社会を目指すのもいいかもしれない。

Permanent (Year-Round) Summer Time と言う選択肢

ちなみにEUがサマータイム廃止に舵を切ったことも契機なのだろうが、最近は上のフロリダの話でも書いたような Permanent Summer Time と言う話も目立つようになってきた。つまり1年ずっと夏時間にしようという話で、現実的にはタイムゾーンを1時間分丸ごと動かす話と等しい。これだと冬の朝がどうしようもなく暗くなるというデメリットはあるものの、サマータイムの最大の問題である「年に2回時計をずらす必要がある」問題が解消され、社会コストも健康リスクも回避される。これも日本でも検討したらいいんじゃないかなあ。