週報 2022/12/17 Less本、チーム内用語、ESLintのルール自作、趣味の哲学本

やったこと

Less本をすこしかじった

今年の10月から配属になったチームの中で「すこしかじる」という言い回しが使われることがあるのだけど、いまいちニュアンスが掴めておらず、『大規模スクラム Large-Scale Scrum(LeSS)』という本が元ネタだったので該当箇所を読んだ。

本に書いてある意味合いとしては、巨大な要求をぜんぶ分析してから開発しようとするといつまで経っても開発できないから、要求の一部分だけとりだして、その部分だけ詳しく分析して実装まで落とし込んでみようという話だった。実装しないとわからないことは、実装するまでわからないので、実装してみて学習を深めようという狙いらしい。アジャイル的にもそのほうがいい。

ただし、チーム内ではもう少し広い意味で使われていて、すでにそれなりに分析が終わっているタスクに対して、技術的にわからないことの調査の方法の一つとしてちょっと実装してみることを「すこしかじる」と呼んだり、あるいはもっとラフに、短い時間とりあえず手を付けてみるみたいな意味合いで「すこしかじる」が使われていたりして、いちどフレーズ化するとコミュニケーションのなかで意味が流動的に変化するところが自然言語のおもしろい部分だと思った。

「すこしかじる」に限らず、こういう用語のようなものが共通理解になっているとチーム内でのコミュニケーションコストが下がると思う一方で、前提や文脈を共有していない人に通じるような形で情報がストックされているほうが再現性が高まるので難しいとも思う。

貯める情報はローコンテクスト、流れる情報や議論はハイコンテクストで良いが、だれでも文脈に乗れるような工夫をする、というあたりが落とし所か。

ESLintのルールを自作する方法をレクチャーしてもらった

ルールの作り方とかコールバックでASTを受ける方法とかはここに書いてある。ここ以外にもいろんな解説ブログがある。
Working with Rules - ESLint - Pluggable JavaScript Linter

どういうコードを書くとどういうASTになるかはこのサイトでサクッと調べられる
https://astexplorer.net/

ルール適用までの流れをレクチャーしてもらって、試行錯誤しながら自分のルールが作れそうという気持ちになった。

いちどレクチャーしてもらうとたしかに公式ドキュメントに書いてあるとわかるのだけど、なぜかいままで見逃していた。それなりの動機と自分にもできるという確信がないと脳に情報が入ってこないのかもしれない。

その他

哲学の教員をやっている友人としゃべった。ぼくも理解できないなりに哲学の本を読むのが趣味なのだけど、どうしても入門書とか解説書ばっかりしか読んでいなくてなんとなく後ろめたい気持ちだった。でも、友人との会話の流れで、プロでも専門以外の分野は入門書めっちゃ読むし助けられていると聞いて、ちょっとうれしかった。もちろんぼくと友人とでは前提知識がちがうと思うので、それこそぱっと読んで入ってくる情報量もぜんぜん違うとかあるだろうけど、まあ趣味にしていても恥ずかしいことではないかと思えた。