「NO HARD WORK!」を読んだ

1 月末の一泊二日の出張中に読むことができました。
日常だと在宅勤務と家事全般（週の間に妻と交代しているが、食事を作るか娘を迎えに行って風呂入れたりするかの違いなので自由時間はいずれにしろお互い無い）でゆっくり本を読む時間は週末に実家で娘を放置できる時ぐらいしか無いんですが、飛行機とか乗るとホントに読書が捗ります。（とはいえ、毎日電車乗ってた東京勤務時代にめっちゃ本読んだかと言えばそうでもないので、まあたまの機会だからでしょう 😅）

読んで時間も経ってしまったので早くも忘れて来てしまっていますが、なんとなくの感想記事です。

前もって言っておくと、僕はこの作者コンビの本はこれまでも読んできているし、単純にファンでもあるので悪い感想を書くことは無いです。

全体的に

これまでの本の記憶もあるので、会社をバージョンアップしてきている感じが伝わってきます。
後は、タイトル通りというか原題が「It Doesn't Have to Be Crazy at Work」なので、そういう働き方に対しての意見が多くて、自分の周りを見回してみたり、自分を振り返ってみたときに、悪い意味で頷ける部分が多かったです。まあ、彼ら自身も過去を振り返って「こうした時もあったが・・・」みたいに書いてあるとおりで、会社もフェーズを経て変わっていくものだと思うので「今、自分の所属する組織がどうか」というのはそこまで大事じゃないとは思います。ただ、「どう変わっていけるかの可能性」は見極めないといけないと思いますが（または、ここまでで変わってこれているかとか）。

ただ、「世界を変えるな」はだいぶ笑いました 😇 いろんな会社がそういう「世界〜」的なミッション掲げてますもんね。

個別で

正直だいぶ忘れてきてるんで、個別に記憶に残ってるのがほとんど無い。。

生産性より効率

いくつかの作業をある時間内につめこんだり、できるだけ多くの仕事をできるだけ短い時間にすませたりすることに意味などない。

仕事が速い人は、どんどんタスクが積まれていく問題にも通じそうですけど、生産性で語ることに感じていた違和感をズバッと言われた気がしました。

同意ではなく協力を求めよう

これは、すぐに妻に話したぐらいで一番良かった項目でした。

僕自身、これまで「全員で同意してこそ、同じゴールを目指せる」みたいな気持ちを持っていて、何かを決める時にできるだけ全員の同意を取ろうとしてきました。
ただ、この項目読んで、実際（自分が同意する側であっても）渋々同意していたり、内心は同意していないみたいなケースはやっぱりあったよなぁと思い出しました。

「反対だけど、コミットする」これは明日から使いたいフレーズです。

ベストプラクティスは幻

毎年「Rails は死んだ」的な記事を見ますし、目新しいフレームワークや言語・ツールは日々出てきて、それに対する「これがベスト」的な記事もたくさん出て、僕自身「ほうほう、JAMStack というのがいいのかぁ」とか日々流されています 😣

Rails 自体が本の作者の DHH が作ったものですが、当時は Ruby 自体「ベスト」なものでは無かったはずですし、フロンエンドに対する手法も世間が React だ Vue だと騒いでいる中で pjax のような turbolinks を作ったり、最近だと小さなフロントエンドのフレームワークである stimulasjs を作っています。
iOS/Android に対しても、turbolinks と連携するそれぞれのネイティブの小さな WebView ラッパー（だいぶ乱暴な説明なので詳細は公式ページを 🙏）を用意したという感じです。

たぶん、フロントエンドやネイティブの最前線を追っている人達にとっては面白みのない取り組みに見えるのだろうと思いますが、Basecamp のカルチャーやメンバー、メンバーのスキルセット等からチームとして最も calm に運用できる仕組みを求めた結果なのだろうと想像します。

組織拡大を目標に持ってしまうと、「採用に有利になる、人員を確保しやすい」のような理由で「ベストプラクティス」に登場してきそうな技術選択をする事もありますが、なにか、そういう姿勢を貫く感じを実際の技術選択からも見せてもらえた気がして、この項目はグっときました。

最後に

総じて、日本のメディアで話題になるイケイケのベンチャーみたいな働き方とはだいぶ違うので、誰におすすめとかは無いのですが、働き方を見直したいなと思ってる人はさっと読んでみるといいかもしれないです。まあ、この本自体もベストプラクティスではないので、軽い気持ちで。