Posts

息子が生まれてからというもの、時間に追われる生活をしている。昔はテレビゲームをしたり、(漫画) 本を読みふけるなどしたものだが、そういう贅沢は自分にはもうない。…ないんだけど、魔が差してテレビゲームを購入したり漫画を購入したりすると、やはり時間をどんどん溶かせてしまう。その結果、勉強時間と睡眠時間が削られる。

そこで “NOT to-do list” を作ろうかと思う。「自分はこれに時間を費やしていいのか?」と迷うときは NOT to-do list を参照して、迷いなく Yes/No の決断をできるようにしたい。NOT to-do list は時間をかけて項目を考えたいと思う。例として挙げた「テレビゲーム」と「漫画」は最初に入れる。

逆に時間を生み出すものには逆にどんどん投資していきたい。たとえば、今は家計簿をつけるためにレシートから CSV ファイルを手入力して支出の管理をしているけど、これは時間の無駄だ。すべての生活費をクレジットカードで精算して、支払い通知の E メールをトリガーにして Google Apps Script でスプレッドシートに直せば、時間を節約できる。こういうアイディアは昔からあったけど、腰が重くて手をつけられていなかった。しかし、未来の時間のために現在の時間を投資するという観点はやはり重要だ。姿勢をあらためていきたい。

「Learn or Die」を読んだ。副題は「死ぬ気で学べ プリファードネットワークスの挑戦」である。だいぶ主張の強いタイトルだ。

本書はプリファードネットワークス (以下 PFN と書く) の共同創業者二人が書いた本である。Startup DB の記事によれば PFN は日本のユニコーンの中でも最も時価総額が高く、かつ二位とはダブルスコア以上の差をつけている。広く業界からリスペクトを集めている企業だ。僕も PFN には注目している。

実は過去の職場で PFN の前進である PFI 出身の方と一緒に働いた経験があり、PFN も順風満帆であったわけではないという話は聞いていた。本書では「創業者同士で借金をしながら従業員の給与を払った」という過去のエピソードも紹介されている。輝かしい企業の生々しい苦労話を読むのは楽しい。こういう読書経験を通してこそ、自分自信の苦労も肥やしにする力がつくように思う。

著者らの Nerd な一面 (“一面” というより、こちらの方が本質なのかもしれない) を垣間見えるのもよい。著者の西川徹さんが中高生の頃に教室にパソコンを持ち込み、プログラミングをしながら授業を聞いていた話などは、率直に「羨ましい」と思った。西川さんは筑波大学附属駒場の中高一貫校のご出身らしく、その環境を「自由な校風」と表現している。僕が卒業した小・中学校にはそのような自由はなかった。せめて自分の子どもにはなるべく自由な世界で過ごしてもらいたいと思った。

ところで、つっこみたくなったのは Epilogue の次の一節である。

これからの5年、10年くらいで人間はコードを書かなくなるだろう。本編でも書いたとおり、私たちは、人間がコードを書かなくてもプログラムを組めるようなシステムを作っているということになる。

もしかしたら、そういう日が来るかもしれない。本書の出版は 2020 年なので、著者らは 2025~2030 年くらいに「人間がコードを書かなくなる」時代が来ると考えているのだ。しかし PFN は「小学生から始めるプログラミング教材」を作っている会社でもある。彼らの予想が的中すれば、今の小学生が大人になる頃がまさに「人間がコードを書かなくなる」時代ということになる。本当に 10 年後に人間がコードを書かなくなると思っているなら、このプログラミング教材は何のためのものなのか。ちなみに、僕は 2030 年でも人間はばりばりコードを書いているのではないかと予想している。

そのようなことを思いながら、本書を読んだ。

LeetCode で「難易度: Easy」とされている Repeated Substring Pattern を解いた。与えられた文字列が「部分文字列を繰り返している文字列かどうか」を判定せよという問題だ。たとえば "abab" は "ab" を繰り返しているので true であり、"aba" は部分文字列を繰り返してできる文字列ではないので false である。

文字列の長さが 10^4 なので、部分文字列を繰り返しているのであれば、最長でも 10^4/2 の範囲を調べればよい。このくらいであれば確かにブルートフォースできそうなので、難易度は Easy でもよいかもしれない。

しかし、解答の Approach #2 Concatenation はずっと簡潔である。

class Solution:
    def repeatedSubstringPattern(self, s: str) -> bool:
        return s in (s + s)[1: -1]

僕はこれを理解するのに時間がかかった。未来の自分のために、これが何をしているのか書いてみよう。

(s + s)[1: -1] は与えられた文字列を二度繰り返して、そこから先頭と末尾の1文字を削ったものだ。つまり、"ab" が与えられたのであれば "abab" から先頭と末尾を削って "bab" である。これには "ab" が含まれているので true が返る。"aba が与えられたのであれば、(s + s)[1: -1] は "baab" であり、これは与えられた文字列を含まない。

なぜこれでうまく行くのか。与えられる文字列 s が部分文字列を繰り返したものであれば、s + s は最小でも部分文字列を 4 つ含むことになる。前後の1文字を削ることで、少なくとも 2 つの繰り返される部分文字列を持つことになる。それこそが与えられる文字列 s となる。

「リモートワークの達人」を読んだ。「NO HARD WORK!」と同じく Basecamp の Jason Fried と DHH が書いた本である。

なぜ僕は Basecamp の創業者の本を読んでしまうのか…。だいぶ前に「小さなチーム、大きな仕事」を読んで、それに感銘を受けたからだろうな。過去にはそれに触発されて「僕も制約を受け入れ、副産物を売るぞ」という具合の記事を書いたりもした。

「NO HARD WORK!」についての記事を書いたときと同じく、Basecamp の主張をずっと読んできた身としては特に新しい話はなかった。自分は Basecamp のファンではあるけど、頷きづらいところもあった。たとえば「本当に集中したいときにオフィスに行こうという者はほとんどいない」という主張には「そうでもないんじゃないか」と思った。僕が「小さなチーム、大きな仕事」を読んでいた頃は独身で、こういう主張には頷かされたけど、家庭で乳幼児を育てている身としては、家よりオフィスの方がだいぶ集中できる。リモートワークの恩恵を受けられるのは、そういう家庭環境にある者だけだ。

今の職場では、東京都の緊急事態宣言に応じて「消極的にリモートワークを導入している」という感じだ。みな「一時的に」リモートワークをしているという認識なので、さまざまなほころびが出ている。具体的に言えばマイクの音質のせいでミーティングの音声が聞きづらかったり、オフィス側とリモート側で情報格差が出たりという具合だ。本書ではリモートワーカーの割合が低いとリモートワーカーは「少数派」になるので意識的にケアしようという主張がある。まったくだ。しかし、こういう意見は会社全体としてのコンセンサスがなければ通らない。消極的なリモートワーク導入では改善も難しかろう。「本を読んで翌日から実践」というわけには中々いかない。

現職の消極的なリモートワーク導入を経験て思うのは「オフィスには行きたくないが自宅で働くのも難しい」ということだ。この本では「リモートワークは必ずしも自宅で働くことではない。コワーキングスペースやカフェなどで働いてもいいのだ」と主張している。僕も数年後にはそういう働き方をしていそうな気がする。ただし、その場合はリモートワークという働き方に積極的に投資をしている会社に移っているという前提がありそうだ。