Magnolia Tech

いつもコードのことばかり考えている人のために。

YAPC::Kyoto 2023にオンライン参加した

久しぶりのオフライン開催YAPC!!

(オンライン開催が当たり前になってきたので、わざわざオフラインって言うようになったのは、回転寿司に対する固定寿司みたいな言い方ですよね)

自分がスタッフ参加したYAPC::Tokyo 2019が終わった後に「次は京都か?」という話が出て、実際に2020年に開催が決まったものの、無念の延期決定...そこからの復活!

とはいえ、残念ながら現地参加は叶わず......そしてオンラインも夕方になってようやく参加できた、ということでちゃんと通してみれた発表はyusukebeさんのHonoの開発経緯と、LT、大西さんのキーノートくらい

yusukebeさんのトークも、大西さんのキーノートも、「人とのつながりが有って、今ここに居る」感がすごく良かったですね。二つの発表は時間軸こそ全然違うんですけど、色々なことが繋がって、その先へ進んでいく感じが(偶然にも)シンクロしてて、いい話だなーって思って聴いていました。


自宅からのオンライン参加だったので、TwitterのTLで現地参加している人たちの楽しそうな様子が見えて、ちょっと羨ましかったです

次回の開催も有りそうなので、次回こそは現地参加したいと思っています

『Go言語プログラミングエッセンス』を読み始めた

普段、Go言語のコードを書くことは無いのだけど、ざっと読むくらいのスキルは身につけておきたいなーと思って、『Go言語プログラミングエッセンス』を読み始めた。

単に言語の仕様とか、ツールの使い方を知りたいだけならば公式ドキュメントを読んで、他の人のコードを読んで、実際に書いてみればいいのだけど、この本ではしつこいくらいに、「他の言語との比較」や、「仕様が決まった背景」が語られている。

変数や関数の定義の記述順に関しては、わざわざC言語構文解析の難しさを図を使ってまで説明した上で、「一方、Go言語ではこうなっている」と説明されてとても分かりやすかった。

このように、著者であるmattnさんの長年の経験から「ここは背景を踏まえて説明しないと納得感が得られないな」と思われるところにはページ数を割いてしっかり説明されているところが、本書の良いところ。

エラー処理が一見冗長に見えるけど、なぜこう書いた方がいいか、というコラムはなんと4ページも使っている。

その後もテストや、コマンドラインオプション、ベンチマーク、データベースと、「実際のアプリケーションを書くためには、ここを押さえておくよね」という所がしっかり解説されてて、実際にコードを書き始めたら読みたくなるテーマが網羅されている。

他の言語でも入門書の次に読むべき本って無いよね、という話になりがちだけど、この本はまさにそんな1冊だと思います。

モデルを作り上げるときの、目の前にあるもの、思いついたものを全部入れようとすることとの戦いについて

ドメインモデルを作るんやーと言っても、それぞれユースケースや、具体的な入出力の内容と紐づいた具象に強く引っ張られ過ぎると、「目の前にあるものぜんぶ」を詰め込みたくなるけど、そうじゃないよねーって一回戻す作業をする強靭な心を身につけることが設計だったりしませんか。

今はそれは議論しない!取り込まない!なぜならばーと強く言えるように、深く対象のドメインと、ユースケースと、過去の経緯と、周りの価値観と、スケジュールと、予算と……その他人間のこころとからだのぜんぶを理解して設計していくんですか、そうですか、たいへんですね。


追加


『学びの構造』を読んで、自分の学び方や、他人の学び方を見直そう

TwitterのTLで見かけた、佐伯 胖さんの書かれた『学びの構造』という本が気になって読んでみた。

昭和50年に発行されて、今年になっても増刷されている歴史ある1冊。


元々、学校教育の現場の人向けに書かれている本みたいだけど、「学ぶことを指導する立場」の人であれば必ず刺さる内容ばかりだった。

特に第二章の”「おぼえる」ことと「わかる」こと”で語られている、「わかる」の定義は必読。

「わかる」とは「わからないところがわかる」ことだと定義し、そこから「わからない部分」に行き当たると「疑問がわき」、それが全体を統合する働きをする、という流れは非常に納得感が有った。

そう、確かに分かっていないと疑問にも思わないし、質問も出てこない。そして「分かった気になって」、やろうとしても実は理解していないから「手順通りのこと」はできても、その先ができない。

自分が、「この分野をある程度は理解した」と言える知識領域があると言えるときって、矛盾や空白が有ればそれを指摘できる状態だし、他人があることに学んだ状態を確認するときに、「もう少し背景や、関連する知識も押さえておいてほしいな」と思うことがあるのは、「それだけだと今はいいけど、ちょっと応用が発生するとできないな」と感じるからだし。

この「わかる」こととは何か?という定義を理解するだけで読む価値が有るし、続く章も、学びにまつわる、興味深い考察が続く。

第三章「道徳はいかに学ばれるか」 第四章「機械で学ぶことはできるか」 第五章「学び続ける存在としての人間」


あと、第一章「学ぶ人、学ばぬ人」の冒頭に出てくる「学べない人間」の3タイプが、「無気力型」「ガリ勉型」「ハウ・ツゥ型」の3種類挙げられているのが、初手でがツンとくる構成になっているのも良かった。最初の一つ目は当然として、なぜ後者二つも「学べない人間」に分類されているかは、本書を読んでみてください。

わかるーって思わず言ってしまうと思います。


追記

この本では、「学ぶこと」の先の振る舞いや、思考に対して一定の期待値、こうあってほしいという思想が有る。

一方で、みんながその思想の通りになるべきなんだろうか、というのも有って、例えば上記のツイートのように、「志高く、事業にコミットするための学びを発揮してほしい」という期待値が経営サイドに有る時に、果たしてどこまで、そのような振る舞いをすべきなのか、というところは、「他人がとやかく言うこと」でも無いし、強制できるものでもないじゃないか、とも言えるかもしれない。

結局、「人による」となってしまうと、要はバランス、みたいになってしまうんだけど、難しいよね(誰視点?)

TimeTimerを買った

年齢も上がってきて、集中力の持続力が落ちてきたなーと思うことが多くなってきたので、あらためてポモドーロ・テクニックをやってみることにした。

まずはなにごとも形から、ということでTime Timerというタイマーを買った。

見ての通りの、最大60分までの、設定は手動(ダイヤル回すだけ)、カウントダウンは単三電池駆動の電動、というシンプルなもの。

ダイヤルを回して設定する感じがよくて気に入っている。スマホだと、余計な情報も出てしまうし、思わず別の通知とかも見ちゃうので、この手の専用品の方がいいなと。

改めて25分を意識するとそれはそれで持続できることもわかったので、しばらく続けてみよう。


Time Timer、けっこういろんな種類がある。

Time Timer | All Time Timer products | Visual Timers + more

10年前のRebuild.fmを聴いていると、技術に対する価値観の変遷を感じた

なぜかiPhonepodcastアプリの再生状態がリセットされてしまって、購読しているpodcastの再生回が分からなくなってしまった。

そこで、ふと一番よく聴いている宮川達彦さんのRebuild.fmを第一回から聞き直してみると、丁度10周年(先日のエピソードでそう言っていた)ということで、10年前の空気感が感じられて面白くなってずっと聴いている。

いくつかピックアップしてみると...

rebuild.fm

記念すべき第1回。

LTSVの話題が懐かしい。シンプルな解決方法なんだけど、色々な言語のパーサーが一斉に広がったところとか、インターネット感溢れるムーブメントだった、みたいな話が良かった。構造化ログの話を今でもしているので、そこに通じるものがありますね。

rebuild.fm

まつもとゆきひろさんを迎えての、Ruby20周年の話。

それから10年経って、今年30周年を迎えてもまだまだ進化を続けているところが凄い。

rebuild.fm

Perlコミュニティの話。

自分はPerlコミュニティが最初の出発点だったから、この辺の話がとにかく懐かしい。

今年もYAPC::Kyoto 2023という形でコミュニティの活動が続いているのも凄い。

rebuild.fm

全編Perlの話。

Perl 5.18の新機能の話だけで話題が尽きないところが、今ではもう無いなーという回。

rebuild.fm

この回が聞き直した回の中では一番面白かった。

出たばかりの頃のDockerに対する感想というか、ここからどう環境構築が変わっていくか、みたいな話が非常に興味深かった。

この先生き残るのか分からないけど、実際残った技術に対する出始めの頃の生の評価が聞けるのは貴重だなー。

rebuild.fm

Go言語の話。

Tour of Go、とりあえずやったなーみたいな頃。

rebuild.fm

なんとこの回からタイトルがRebuild.fmになった。

第1回からではなかったのだ。

rebuild.fm

Perlのツールチェーンとか、Perl6とかの話。これまた全編Perlの話だった。

rebuild.fm

この回もすごく興味深くて、ChromebookがマイクロUSBで充電できる、PCがUSBで充電できるなんて!という驚きが語られている。

その後のUSB PDの普及で逆に「専用のACアダプタが必要なの?」という方に時代が変わったのが面白い。


DockerとかGoが出始めて、Perlがメジャーな言語から外れてきている、そんな時代の転換期感がブログとか、書籍では分からない生々しさで面白かったなー。

まだ半年分くらいしか聴けてないので、移動時間とかに引き続き聴いてみよう。

2023年に『リモートワークの達人』を読む…10年目のリモートワーク環境を考えながら

blog.magnolia.tech

今から約3年くらい前、色々な会社でコロナ禍によるリモートワーク強制移行が話題になっていた頃『強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」』という単行本が、文庫化にあたって『リモートワークの達人』というタイトルになって出版された。

タイミング的には絶妙なタイトルの変更。

コロナ禍による「とりあえずのリモートワーク移行」が始まり、みんなが「リモートワークとの向き合い方」に悩み始めた頃で、まさに「人々が求めていたもの」感が半端なかった。それに単行本の書名にある「37シグナルズ」は2014年に「Basecamp」と社名も変わっていたので、ずばり『リモートワークの達人』と変えてしまうところが絶妙。

自分も「リモートワークでのチームビルディングってどうすればいいのか」という話していて、「それはもう全部この本に買いてある」と言って紹介してもらって読んだ。リモートワークに関する興味も有ったし、Ruby on Railsを産んだBasecampのジェイソン・フリードと、ディビッド・ハイネマイヤー・ハンソン(DHH)の共著、というだけでも興味が有ったし。

当時の感想は、冒頭のブログエントリに書いた通り。


原著の『REMOTE: OFFICE NOT REQUIRED』の出版が2013年なので、今年で丁度10年経過して、書かれていることが今でも通じるのかな、と思って読み直してみた。

元々この本の良かったところは、実際にリモートワークを実践し、成功したサービスを生み出した”経営者の二人”が書いているところだったと思っている。経営者目線だからこそ、細かいテクニック的なところよりも、それが組織や、個人にどう良い影響をもたらすのか、それは実践可能なことだ、というメッセージが有り、それが有るからこそ人材採用や、マネジメントに関する説明が説得力を持っているし、今でも読み直してもいいかなと思わせる理由になっている。

技術やツールは変わっても採用やマネジメント上のポイントはそうそう変わらないから。

(逆にセキュリティのことが書かれたページは、間違ってはいないけど、今では全然足りない)


さて、2023年に読み直した感想だけど、帯に書いてある「存在感は仕事でアピールしよう。」「部下を見張るのはやめにしよう。」「怠けより働きすぎに注意しよう。」というメッセージは相変わらず刺さるけど、前半の啓蒙的な章は「そうですね」以上の感想は抱かなくなってしまった。

後半の「リモートのコラボレーション術」「リモートワークの落とし穴」「リモート時代の人材採用」「リモート時代のマネジメント」といった章も多かれ少なかれ、「そうだなー」「できているなー」という部分もあった理、「そこまで徹底できているか?」という振り返りに使える部分は有るな、とは思ったけど、結局は「見えない不安」との付き合い方なんだなと。

それはリモートワークかどうかは実はあまり関係無くて、それがたまたま極端に出てしまうリモートワークという形態では意識的にやっていかないと上手くいかないけど、リモートワークでなくても多かれ少なかれ意識しないといけないことばかりだった。


アフターコロナになって「リモートワークでなければならない社会的な強制力」は無くなってしまった。

それまでのリモートワーク主体の働き方を止めて、出社主体に戻す会社も出てきたし、もっとリモートワークに移行するといっている会社も出てきた。

色々な選択肢が有って、濃淡が出てきている中で、少なくとも「通勤って避けられるなら避けた方がよくない?」とか、「そんなにミーティングいらなくない?」とか、みたいな価値観は共通認識になってて、さすがにそこは戻らない気もする。

それに、リモートワークだろうと、そうでなかろうと「必要な情報は記録され、オープンに共有されている」「すべてのコミュニケーションを同期にしない」といったプラクティスに反対する人もいないだろうし。

そういう意味ではリモートワークするかどうかじゃなくて、「自分たちに合ったやり方は、自分たちでちゃんと考えましょう」でしかないんだろうな。

新卒で会社に入った瞬間からリモートワークが当たり前だった、という世代の人たちが組織の中心になっていくと、組織文化も勝手に変わっていくしね。

世の中がどんどん変わっていく時代に、過去の成功体験を捨てて、自分の振る舞いを変えるのには丁度良い体験だったと思うんだよなー。


ただ、やっぱり働き過ぎは良くないよね、それはそう。


リモートワークという制約と自由が同居するスタイルに合わせて働き方を見直してみましょう、という本だと思って読むと、今でも読む価値は有る、というのが今回読んだ感想のまとめです。


ちなみに、この本の舞台であるBasecamp社は、2021年に社内での政治的な議論を禁じるという経営陣の決定を契機に大量離職が起きている。

報道されている内容を読む限りは、リモートワーク中心のワークスタイルを起因とするコミュニケーションロスが原因、ということではなさそうだけど、コミュニケーションの難しさを感じる出来事だった。

techcrunch.com

www.theverge.com


あ、あとリモートワークの心得といえば、コロナ禍が始まる前に、えいのうさんのブログエントリを読んでいて、”リモートワークをやるにあたって個人として気をつけるべきこと”として「気持ちを切り替えるために着替える」だけは事前に学習できていました。これだけはずっと守っています。まずは個々人の営みとしての、気持ちの切り替えを意識的にやるって大事ですね。

blog.a-know.me


とりあえず、オンラインミーティングの印象の良い終わり方、挨拶の仕方のベストプラクティスを誰か教えてください、よろしくお願いします。