良いコードとは良い感じのコードである
こんにちは、imazです。10年ちょっとRailsエンジニアをしています。
インフラは苦手、CSSやJavaScriptも得意ではない、アーキテクチャとか設計も得意ではない…
SQLとかデバッグが好きです。答えがあることが好き！
作業中めちゃくちゃ独り言が出るのでオフィスで働けないタイプです。
Re: 良いコードってどんなコードですか？という質問を受けたら何と答えるか
今日はしまださんの記事を読んで、私ならどう答えるかなぁ、自分の場合はこうだなぁ、と思ったことを書いておきます。
良いコードを書くために
私がコードを書くときに心がけているのは「コードがなぜそうあるのか説明できるようにすること」です。 コードの一行一行に対して、どういう選択肢があってなぜそのコードを選んだのかというのが理解できているのが良い状態だと思っています。
簡単な例
たとえば、コード中のリテラル(即値)について考えてみます。 私がリテラルを書こうとしたとき、ざっくり3種類の選択肢が思い浮かびます。
思い浮かぶ選択肢をあげる
- リテラルのまま書く
- 定数にする
- コメントをいれる
それぞれのメリット・デメリットを考え、どういうケースに適しているかを考える
- リテラルのまま書く
- メリット
- コードを読んで、またはデバッグしていて値がすぐわかる
- デメリット
- 複数箇所ある場合に変更に手間がかかったり漏れたりしやすい
- 使うケース
- 同じ意味の数値が現状存在せず、増える可能性も低い
- 上記かつ以下のいずれかの場合
- メソッド名や周りの文脈でその数値が何を表すかがわかる
- その数値である理由が特にない（CSSの局所的な調整など）
- メリット
- 定数にする
- メリット
- 複数箇所にまたがっても変更が容易
- 適切な名前だとどういう意味の値なのかがすぐわかる
- デメリット
- コードを読んだときに値がパッと見でわからない
- 使うケース
- 同じ意味の値が複数ある・増えることが想定される場合
- この場合デメリットは飲み込んだほうが良いことが多い
- 同じ意味の値が複数ある・増えることが想定される場合
- メリット
- コメントをいれる
- メリット
- コードを見たらそこだけですべてがすぐわかる！値も意味も！
- デメリット
- テストにかからないため、修正漏れを機械的に検出できない
- "動くコードとして意味を持たない" ので誰かの気まぐれなどで急に消える場合があるぞ（びっくり）
- 使うケース
- コメントがメンテできるチームの場合
- 局所的だが値が意味を持ち、周りのコードから意味が読み取れない場合
- コードを読んで数値がすぐにわかったほうが良い場合
- あと定数にするほどじゃないなーめんどくさいなーってとき…
- いいの？他の可能性を考えて判断した結果ならいいです！コードでもトレードオフは発生するのだ…!! ※1
- メリット
※1 トレードオフについて書いてたら長くなっちゃったので一番下の項目にしました！
最終決定する
ここまで出した上で、今使うならどれなのかを考えます。 リテラル程度であれば手癖で書くことも多いのですが、手癖の思考過程が確立していくまでには上記のような思考を何度も行っているはずです。
この例は主観的でミクロな例ですが、仕事をする上ではサービスの段階（立ち上がったばかりなのか、大きくしているところなのか）、チームの形態（分野専門の人がいるか、入れ替わりが激しいか）、アーキテクチャなどの設計や現状のコードに照らし合わせて、最適な選択肢を選んでいくことになるかと思います。
コードの説明ができるようになる方法
本を読んだりコードを書いたりと知識を身につける方法は色々ありますが、私自身はコードレビューを通して覚えたことが多いように思います。（勉強より先に現場に入ったからかも…） コードレビューをしてもらうときは自分が抜けがちな、あるいは自分が持たない視点からの指摘がもらえるのでダイレクトに知識が増えてそれも良いのですが、説明力がつくのはコードレビューをするときです。
レビューをしはじめた頃、私は雰囲気で「良い感じのコード」を書いていたので、レビューで指摘するときも「なんとなく嫌だな」という感覚しか持っておらず、最初の頃はそれをそのままレビューコメントとして残していました。しかしチームメンバーから別の「なんとなく嫌」な意見がでると平行線になってしまい、結論が出なくて放置状態になることがしばしば。これはよくないなと思い考えを改めました。
他の人に何かを変えてもらうのならそれ相応の根拠や理由が必要！ ということで、コメントをするより先に現状のコードのメリット・デメリット、別の案を採択したときのメリット・デメリットも考え、説明できると思ったときにだけ指摘をするようになりました。そうすると面白いことに、多くの「良い感じ」「嫌な感じ」には明確に理由があることに気づきます。
理由を言語化して認識できれば、たとえ環境が変わっても、環境にあわせて最適な選択をする手がかりとなります。「良い感じ」の再現性が得られるということです。
「良い感じ」…これはまさに「良いコード」への道といえるのではないでしょうか。
良い感じを突き詰めた先には良いコードがある！
それはそう…そうなりますよね。主観としての良さね。
このコード好きだな〜と思ったら（またはヤだな〜と思ったら）それがなぜなのかを考えて言語化する、というのを繰り返すことが「良い感じ」をみつける訓練になるのだと思います。 その機会が多いのがコードレビューなのかも。
結論：良いコードとは！
良いコードを書くには「コードがなぜそうあるのか説明できるようにする」。
では良いコードとは？
私の出した結論は「最善の選択肢を選んだコード」です！
良い感じはどこいったの!? あれは主観としての良さを表現していて最高なのですが、主観として・客観としての良さを両方表せるのはこちらかな〜と思って選びました。選択は常にトレードオフなのだ… ※1
「1年後にいいコードが書ける、上手に書ける」というのは、コードを書くときの選択肢が見えるようになること、その選択肢から最善を選びとるための知識が増えるということなのかなと考えています。 最善を選んだと言えるためには明確な理由が必要である、それができていると証明できるのが「説明できること」なのではないかなと思います。
この考え方の良いところは、チームの制約があっても達成できるところです。自分がベストだと思う選択肢がとれない場合でも、「本当はどうありたいのか」「なぜいまこうあるのか（どうして理想の形をとれないのか）」を説明することはできる。ベストのコードを捨てて何かを選んでいるはずなんですよね。短いスパンの中の時間とか。
良いコードが書ける人はみんなこれができるなぁと思います。一緒に仕事してると頼りになるし、めちゃくちゃかっこいいんですよねえ。
そうありたいものだな……
オススメ本の紹介
※1 トレードオフ
トレードオフというのは「何かを得るとき何かを失う」という、どちらかしか選べない関係のことです。
先のリテラルの例で、「1. リテラルのまま書く」と「2. 定数にする」のメリット・デメリットにはまさにその特徴が現れていますね。どちらも得ることはできないのだ…
私は『ソフトウェアアーキテクチャの基礎』の翻訳原稿レビューに参加させていただいたのですが、その本でトレードオフのことをはっきりと知り、初めて開発に関わる様々なトレードオフのことを考えました。本の中の大好きフレーズはこちら
アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していないだけの可能性が高い。
慧眼〜！この師匠が弟子に言う感じのフレーズ、めっちゃ好き…!!
アーキテクチャ決定をするときの考え方として覚えていましたが、原稿レビューの過程でコードのトレードオフについてしまださんから教えていただいていました。
この頃から答えを求めていて笑ってしまう… 正解は、ないのだ…( ˃̣̣̣̣̣̣ ω ˂̣̣̣̣̣̣ )
トレードオフ関連リンク
- snoozer05.hatenablog.jp
- 過去に現場で納得のいかないめんどくさいだけの変更に見舞われたことはないだろうか…私はある。しかしあれにも理由があったのだ。われわれの手間のトレードオフとして、プロダクトやチームに何らかのメリットがもたらされていたはず…そして専任者は責任もってそれを決定していたのだから気軽に決まりを破ってはいけない…
- という考えを身に着けました。おすすめ！（それまでの近視眼的思考が感じられる…）
- 続く本だ…! よ、読むぞ…いつか… 『ソフトウェアアーキテクチャ・ハードパーツーー分散アーキテクチャのためのトレードオフ分析』 - snoozer05's blog
- 過去に現場で納得のいかないめんどくさいだけの変更に見舞われたことはないだろうか…私はある。しかしあれにも理由があったのだ。われわれの手間のトレードオフとして、プロダクトやチームに何らかのメリットがもたらされていたはず…そして専任者は責任もってそれを決定していたのだから気軽に決まりを破ってはいけない…
- magazine.rubyist.net
- かくたにさんによる紹介文だ！「トレードオフ」ある…!!
- 読んでいないので買って読みます（小声）
南風に乗って Ruby "enbugging" quiz が届いた
只今札幌の気温は9℃…
Ruby "enbugging" quiz
これはなに？
あらかじめ用意されたコードを修正して、お題のエラーが出るように修正するよ！
変更文字数によってスコアが変わる、より小さいスコアを目指そう！
やったったぜ
やってる途中に思ったこととか調べたことのメモをこの下に載せます。
ここから先はネタバレがあります！！！
やった人だけみるとよさそう！
やったときのメモ
Stage 1
- n = 'no error' + nil = 'no error'
これで Score 2 で通ったのでゲラゲラ笑ってた。とりあえずSocre2のまま次へ
Stage 2
10 このあたりで全て Score 1 でいけるという情報を得る。
Stage 3
-3 シンプル
Stage 4
Expected error: nil can't be coerced into Integer (TypeError)
nilはintにならんよってエラー。
n = 3 puts "I dunno error"[2 + n..]
nを別の変数に変える方法は2つくらい知ってる！ お金で解決しました。
※ここでStage 1に戻って同様の方法でクリア
Stage 5
Expected error: index -4 too small for array; minimum: -3 (IndexError)
# Out of bounds? ary = [1, 2, 3] ary[3] = "no error" puts ary[3]
これは ary[-4] = "no error" にすると発生させられる。
とりあえず ary[3-7] にしてエラーを発生させる。
それ以外のやり方がありそうだけど思い浮かばないのでScore 2のまま次へ…
Stage 6
Expected error: negative argument (ArgumentError)
puts "rhino error!!"[n * -1..-3]
わ、わかりづれーーーー
私がレビューしたら絶対(n * -1)ってカッコつけてもらうからな!!! (そこ？)
1文字リテラルにするのはすぐわかったけど書き方は覚えてなくてちょっと調べた。
Stage 7
一瞬悩んでから「これ、みたことあるぞ…これ…ツイッターでやったやつだ！」ってなって解けた。かなりの罠だよなぁ。ツイッターで見てなかったらすんなりは解けなかったかもしれないけど、Score 1で解けると考えたらすぐ気付ける可能性もある。
いまとなってはわからないこと…
Stage 8
そこまるっといらないじゃん！って笑った（ちゃんと気を取られた）
Stage 9
def x=1
この定義なに!? うちのRubyだとエラーになるんですけど…
うちの
> puts RUBY_VERSION > 2.7.3
サイトの
3.4.0
なるほどね……
困ったときのputs
puts method(:x) してこのファイルがtest.rbであることがわかった。ちゃんと def x = 1 を書いた場所でメソッドとして定義されている。シンプルに代入されたものを返すメソッドを作れるんだなー。再代入も変数のようにできる。不思議…
エラー起こす方法は、メソッド呼ぶならここしかないな、と思ってからわりとすぐ解けた。これはできたときちょっと気持ちよかった！
Stage A
Expected error: cannot clamp with an exclusive range (ArgumentError)
def foo(...) "no error".clamp(...) end puts foo("a", "z")
まず def foo(...) ってなんだ？
https://docs.ruby-lang.org/ja/latest/class/Range.html
p(...) # Ruby 2.7 で導入されたメソッド引数の forward として解釈されてしまう
なるほど、丸投げするやつ！
それでこのエラーはなに…そもそもclampメソッドってなに…(調)
clampは範囲内にまるめるメソッドで、このエラーは引数に未満のRange(A...B：A以上B未満)を渡すとBをこえたときの値が不定になるからダメってエラー、なるほど。
つまりfooの中で呼んでるclampに("a"..."z")が渡ると例外がおこせる。 でもforward引数はそのまま渡すから、現在は("a","z")が渡っている。解法の候補は
- clamp("a", ? ) で同じエラーを起こせないか
- clamp("a"..."z") を渡せないか
- forward引数が渡ってきたときにRangeと解釈するようなclampの挙動がないか
- def foo(...) の引数をRangeとして定義できないか
みたいなこと考えてdocs.ruby-lang.orgのメソッド定義とRangeとclampのページ眺めてたらclampの引数変えればいけることに気づいた。...5
正解はシンプルだったけど色々知らないこと多くて結構時間かかったなぁ。
記法自体は知ってたけど使わないとすぐ頭からでてこないない。全然違うものに変化するので、先入観が邪魔してなかなかでてこなかったのかも。
Stage B
Expected error: 0: 1 === 0 does not return true (NoMatchingPatternError)
r = (0..1) 0 => ^r puts "no error"
なにその2行目!?
irb(main):090:0> r = (0..1)
=> 0..1
irb(main):091:0> 0 => ^r
Traceback (most recent call last):
3: from /Users/imaz/.rbenv/versions/2.7.3/bin/irb:23:in `<main>'
2: from /Users/imaz/.rbenv/versions/2.7.3/bin/irb:23:in `load'
1: from /Users/imaz/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
SyntaxError ((irb):91: syntax error, unexpected =>, expecting end-of-input)
0 => ^r
^~
!!!
そろそろRuby3の世界にいくか……
今回はせっかくだからドキュメント読んで確認していこ！
=> を調べてみた
https://docs.ruby-lang.org/ja/latest/doc/symref.html#eq
rescue => XXX
例外処理で例外結果を変数 XXX に代入します。
これくらいしか載ってない…まさか3.4の機能か…!?
と思って試したらrに左の結果が入っていることがわかる。
0 => r で0になる!! 右代入できたの!!! 前回参加したRubyKaigiで聞いたぞ…(何年前だ) その時にも「例外のときに右代入が使われているんですよね」という話がでていた気がする。
ドキュメントには書いてないんだなと思ってフィードバックを送るリンクからリポジトリに飛んでissue検索したらRuby3.0の変更まとめてissue立ててあった。なんて親切なスレ…ここを見れば行けるかもしれない、3.0の世界に…!
https://github.com/rurema/doctree/issues/2458
^ を調べてみた
そんで… ^r はなんなの？ハットなんて正規表現のときにしか使わない…
https://docs.ruby-lang.org/ja/latest/doc/symref.html#hat
この記号のページ大好き大好き大感謝。NoMatchingPatternErrorだから正規表現ってことでいいのかなー。
=> ^ ってなんなの
エラーメッセージを見るに => ^ は === と等価なのかな。
=== と同じ？
挙動は結構違う…一体何者なんだ…戻り値がないからif文とかにも使えない。 含まれていないときにエラーを出すためだけに存在している…?
puts 0 => ^r #=> syntax error puts (0 => ^r) #=> void value expression puts r === 0 #=> true puts (r === 0) #=> true
右代入は戻り値がないとどこかでみたので試した。
puts 0 => r #=> {0=>0..1}` puts (0 => r) #=> void value expression
カッコつけるとvoid valueになるけど……
はっ！上の行はhashで解釈されてるのか！
右代入演算子は戻り値ないということであってるっぽい。
挙動から確認してみる
試しに 2=>^r にしたらエラーが出た。範囲に含まれるかどうか確認しているっぽいな。
test.rb:2:in '<main>': 2: 0..1 === 2 does not return true (NoMatchingPatternError)
ここでもう一回コードをみてみよう
r = (0..1) 0 => ^r puts "no error"
今回出したいエラーは 0: 1 === 0 だから、指定のバグを出すためには2行目は変更せず、rの内容を1にする必要がある。
r を 1 にしたい
Rational 1/1 って 1じゃない？
色々試しているうちに 3r #=> 1/3 という記法に気づいた！（こういう記法のドキュメントみつからなかったけどあれば読みたい）
これ勝ったなと思って 0 => ^1r にしたけどパターンマッチではRationalはつかえないぽい…はいぼく…
ビット演算の記号でなんとかならんか
^ はビット演算子のXORなのでその前に数字とかいれてなんとかならんかなと思ったけど当然なんともならなかった。単体で使える ~ をつけてもエラー…Rangeに対してビット演算はできないのだ。そりゃそうか。
そもそも右辺をxorの式にしちゃうと右代入演算子がなにをすればいいかわからなくてsyntax errorになる。
rの定義方法をどうにかできんか
2行目を変えることができないなら r = (0..1) の方で1と認識させる必要がありそう。
- rみたいに一文字でRange -> Integerに変換できるものとかありそうか
- (0..1) をRangeじゃなくて引数とかそういう感じにできそうか（且つ最後の1を使いたい）
- , だめそう、これは一番最初に試したな
- ; これじゃエラーになるよなぁと思って入力したらなんかいけちゃった！！でもなんでこうなるかわからない…なにこれ…??
(;0..;1;) って古の顔文字みたい
r = (0..;1) でrには1が入っていることが確認できた。なにしてんのこれ…?
試しに ;1) を消してみたらsyntax errorになったので、カッコの中で使うことに意味があるっぽい。
(;0..;1;)とかでもいけた。あ、もしかしてカッコの中で関数スコープ的な感じで完結してる…!? で最後の行を返してる？
そうなんだ…演算子の優先順位的な感じで考えたとき、()より;が先なのか…! たしかにブロック引数を1行で書こうとしたときに ary.sum{|i| puts i; i+1 } って感じで書くもんなぁ。ふつうのカッコの中身が区切れてもおかしくないか…
これめっちゃ悩んだけど正解してみるとすごくシンプルだなぁ。さすがのExtra stage。
Stage C
Expected error: invalid radix 52 (ArgumentError)
puts "no " + 9219755.to_s(034)
実行すると no error がでてくる！すごい！なにこれ？？？
カッコの中身を0384にしたらエラーになって、03にしたら0/1/2の数列になった。ビットの単位か…? ビットというかx進数かな。
puts 9219755.method(:to_s) #=> #<Method: Integer#to_s(*)>
Integerクラスのto_sを調べる。
https://docs.ruby-lang.org/ja/latest/class/Integer.html#I_INSPECT
引数を指定すれば、それを基数とした文字列表現に変換します。
ほえ〜 なるほどね〜 基数っていうのはx進数のxのとこね！
今回出したいエラーは "invalid radix 52 (ArgumentError)"
radixは基数という意味らしい。つまり52進数なんてないって言われてるの？
puts "no " + 9219755.to_s(052) #=> ArgumentError (invalid radix 42)
42...なんで？ わからないままひとつずつずらしたところ、以下のコードで該当のエラーがでることがわかった。
puts "no " + 9219755.to_s(064)
これは…私の知ってるのはこれしかないですけど……
puts "no " + 9219755.to_s(0x34)
クリアー！ 数値を変換する単純な方法を試しただけでそうなる気がしていたわけではない…
ブログを書いてる今思うけど、基数エラーの問題を基数で解決するのオシャレだなー。
…あ！052って10進数に無意味に0ついてるわけじゃなくて8進数の書き方か！
なんか違和感感じてirbで試して気付いた。そういえばそんなのあったなぁ。
irb(main):079:0> 01 => 1 irb(main):080:0> 08 SyntaxError ((irb):80: Invalid octal digit) irb(main):081:0> 07 => 7 irb(main):082:0> 010 => 8
Stage 5
ここまできて唯一スコア2で残っている Stage 5 に戻ってみる。
3を-4にするしかなさそうなんだよなぁ…と考えてStage Bで通過した大好き大好き大感謝記号ページで見た単体で使えるビット演算（反転）をやってみたらうまくいった！なんで!?
そもそもマイナスの2進法知らないんだよなぁ。いちばん左端が符号ビットになってると考えるのが自然かも。
0 -> -1 になることを考えると、すべて1だと-1になる。そこから…あ、反転か！-1基点で、普通の1が 00001 なら反転すると 11110 になり、左端が1だからマイナス、基点から-1だから-2みたいな感じか…へぇ〜おもしろ〜！ビット反転すると絶対値がずれるのがおもしろい。へぇ〜 いつ使うんだろ…
クリアしたぜ！
全部クリアしたやったー！報酬なにかなー！ってあけたらスタッフに話しかけてもらってねってあった。それはそう…これはRubyKaigi2024 STORESブースで出されし問題……( ˃̣̣̣̣̣̣ ω ˂̣̣̣̣̣̣ )
楽しかった〜！
ありがとうございました！
この問題の解説記事もあるみたい。これから読みます！
RubyKaigi 2024のSTORESブースで開催した『Ruby "enbugging" quiz』の解答を公開しました！ #rubykaigi
— STORES Tech (@storesinc_tech) 2024年5月27日
Ruby "enbugging" quiz の解説 - STORES Product Bloghttps://t.co/SrIwJ7wtoN
認知特性の違いがおもしろい
むかし違うとこに書いたやつ。該当記事読んでやっぱり楽しかったのでちょっと加筆修正してここにもおいとく！
http://decinormal.com/2015/09/30/alexandria_library/
これと、その続きの反応まとめ
http://decinormal.com/2015/10/03/alexandria_comment/
が好きでたまにふりかえって読む。
最初の記事の中盤で引用されている本に関して疑似科学である旨の注釈が追記されているのに気づいた。
疑似科学の本って、その旨が明記されていない場合は「悪」になってしまうよなー。
この本はそういう類なんだろうか。記事見るとそんな気がする。
2つ目の記事にあるように人それぞれ認知の自覚が違うってことは、やっぱり特性はあるんだろうなあ。
いつかこのあたりの研究がすすんで、科学で解明できるようになるといいな。楽しいだろうなあ。
私は普段常に音声で思考してるタイプで、文を書くときも読む時も考えるときもずっと頭のなかで喋ってるし（よって思考はあまり速くない）、特に何も考えてないときは音楽が流れっぱなし。脳内BGMって言ってる人ってもしかして音声思考タイプなのかもしれないなー。
これは完全にそうじゃなきゃ思考できないわけじゃないと思うけど、得手不得手があるんだろうね。私は映像を想像するのが意外と苦手なんだけど、アウトプットして絵を描くことはできるんだよな。頭のなかで映像を浮かべるっていうのはすごく苦手で、目の前に映像があるように考えるのはできなくもないというか、絵も描いてる途中でインプットして想像ができるようになるというかその、思考の発端が映像にないみたいな。頭の中から映像が出てくるわけではないのだよなぁ。
思考タイプは訓練でも変わる気がしている。絵を描く日々を過ごしていれば頭の中にも映像が出てくるんだろう。描きたいものが頭の中に存在するようになる。映像の思考が苦手だけれど、タビネコだけはいくらでも想像することができる。ただ、色だけは思考で再現するのが難しい。私の思考の中は黒いフィルターがかかっているようにいつも明度が低いのだ。きれいな空を見て何度でも感動できるのは、記憶でなかなか再現できないからだと思っている。
夢をみるのもあれは一種の映像思考なんじゃないだろうか。覚醒に気づいた瞬間に映像が薄く暗くなってしまうのが不思議だ。あれは脳のフルパワーなのだ。いつもフルパワーであってくれ…
小学生のころ一輪車クラブに入っていたのだが、一輪車のことを考えるときはいつも、乗る瞬間の左足ふくらはぎの力加減を思い出す。これは映像でも音声でも言語でもなく、体の感覚の記憶だ。感覚のことを考えるときはいつもとはちょっと違う脳をつかう感じがあるなぁ。一輪車のこと、テニスのこと、編み物のこと、タイピング とか。
私が音声で思考しがちなのも訓練の結果で、3歳の頃からピアノを習っていたからではないかなぁ？ と思うけどどうなんでしょうな！
稼働日を火-金から月-木に変えた
😊🌙🔥💧🌴😊😊
ここ3年ほど、火-金で働いていたのだが、このまえ金曜日に私用があって 月-木 で働いたら、気分の切り替えがとてもうまくいって思いの外よかった。
今のチームは月曜日に人が少なくレビューが回らない状態だったので、それも解消できてちょうど良いなと思い、8月からは月-木で働くことにした。
曜日と気分
休み明け気分の月曜日🌙
もともとわたしは月曜日に休みの気分になったことがないのだ。仕事のチャットも確認してしまうし、日曜日になると休みが終わる気がして気が沈む。月曜日はこころは仕事だけど実際は休日みたいな中途半端な精神状態になり、仕事をしたほうが落ち着くことが多いので結局なんらか仕事をしてしまう。どうも気分の切り替えが週明けにあって、それは動かせないっぽい。
最近気づいたんだけど、まわり（TLにいる人とか）が休んでいる休日じゃないと休日と思えないみたいだ。月曜日も祝日なら休日気分でいられることが多い。気分の切り替えの「週明け」はつまり「世界の休み明け」って感じだ。
花金気分の金曜日💰
月曜日の休み気分になれない問題が、金曜日だとあっさり解決する。
簡単に休みモード…というか花金モードになることができ、平日のアクティブさを保ったまま休日としてプライベートを謳歌できるのだ！
（実は金曜日は働いていても花金モードになってしまって集中できないことが多い）
さらにその前日である木曜日は、ほぼ確実に仕事の精神状態なので花金モードになることがない。月曜はじまってから木曜の最後までちゃんと集中した上で金曜日にアクティブな休日の気分になることができる。「明日は世界の休み」と思いながら過ごすお休みの金曜日、なんという贅沢…!!
お仕事気分の 水曜日💧 と 木曜日🌴
いまのチームは水曜の夕方にミーティングをしていて、そこで1週間のタスクを振り返ったり、目標をたてたりしている。次の1週間ではここまで進めたい、というタスクを決め、今週中に終わらせたいものが見えてくる。
私にとってはその時点で残り木曜日しかないので、「ひとの作業を止めないためにこのあたりだけフルパワーで片付けよう…!!」という気持ちになることがわかった。実際に片付けられるとは…言っていないが……（やります）
自分のパターン
ちょっと行動パターンを変えるだけで、自分のモチベーションや気分を左右するものがみえてくるのが面白い。自分が、曜日や世界の雰囲気にこんなにも左右されて生きているとは思ってもみなかった。動じやすい…いや、感受性が豊かなのだ！
気分ややる気が上下するとき、近視眼的に原因や解消法を探してしまうけれど、こういう大きなパターンをみつけられたほうが改善には寄与しそうだなあ。
今回はコントローラブルだったけど、苦手なパターンに陥ったときにどういうアプローチをするかは今のうちに考えておきたい。すぐ余裕がなくなっちゃうんで！
と いうわけ
今日もフルパワーで片付けなきゃいけないものがいっぱいあるような気がする。ブログ書いてる場合じゃない… がんばって❢
(火曜日は？🔥)
マチマチの渋谷オフィスに行ってきた (575)
1/17 Fri. （13:30-15:10 CTS→HND）
ひとつきチョイ前の金曜日、渋谷のマチマチオフィスに行ってきた！
訪問当日に札幌から飛行機で移動。なんやかんやあって17時くらいにオフィスに到着し、2時間ほどオフィスで作業などをした。
どうもこんにちはimazです
- 札幌在住のフリーランスプログラマ
- 普段は札幌の自宅で仕事をしている
- 3年くらいご近所SNSマチマチの開発に携わっている
- リモートワークで週4日仕事をしている
- Rails React PostgreSQL などさわっている
オフィスにいってきた
去年渋谷に移転したマチマチのオフィスにはじめて出社した！
マチマチのオフィスは渋谷から徒歩7分(ref: オフィス移転のお知らせ | 株式会社マチマチ)のところにある。
ビル名のとおり青山エリアなのか、周辺がしずかで落ち着いていてきれいだった。
普段は夕会でモニタ越しに見ているオフィスが、実際に行ってみると想像の3倍くらいの広さでびっくりした！
入ってすぐの靴を脱ぐスペース、中央のソファーまわりに余裕があり、扉がガラスなこともあって開放的な雰囲気がある。会議室も扉と壁がガラスっぽかった気がする。ゆったりしていてよかった。
床が黒、机が木目で、少し暗めの電球がたくさんある。部屋は十分明るいが作業に没頭できる程度の明るさで落ち着く。オシャレオフィスは蛍光灯使わない。スキ！
適温で、なんだか爽やかな風がふいてた。適度なノイズがあり、誰も喋らなくても沈黙感がなくてよかった。静かすぎるオフィスがちょっと苦手なのだよな。
ちゃんと仕事した
オフィスで遊ぶでも寝転ぶでもなくちゃんと仕事をしてきた！ めずらしい！（？）
私はオフィスに行くと人の気配が気になってしまってあまり集中できないんだけど、マチマチオフィスは前述のように集中できる環境だった。自分とインテリアの相性が良いのかもしれない。
作業をしていて出てくる独り言と鼻歌を抑えるのが大変だった。
一人作業に慣れすぎている……。
オフラインミーティング
普段はリモートで参加している夕会と、普段は参加しない週次ミーティングに参加してきた。
夕会🌇
オフラインでやる夕会はだいぶやりやすい！
話している人の声のトーンやその場にいる人の表情・動きが見えるので、話したことが伝わっているかどうかがすぐにわかる。
ノイズがないので人の話も頭に入りやすいし、遅延がないのでトークの隙間をみつけて思ったことをすぐ言えるのがとても良い。
あとは、オフラインだと夕会の流れでその後に質問がしやすいので、疑問や質問があっても報告は報告としてすぐ切り上げることができるな、と思った。リモートの状態は思った以上に問題を抱え込んでいるのかもしれない。
私は困ったことがあったらとりあえずSlackに「○○がわからなくて調べている」「○○のやり方がわからない、ひとまずベタ書きで実装中」などと書くようにしているが、そこに至るまでに結構ハマっていることが多いんだよなぁ。
オフィスで話してみて思ったけど、オフィス側の声がリモート側に届いているかどうか、というのはほんとに全然わからない（このときは他に2名リモートで繋いでいた）。リモート側で聞こえづらいときはちゃんとフィードバックしなきゃだめだなぁ。
週次ミーティング📆
毎週の流れを把握していないので聞いているだけだったけれど、開発チームがやったこと、今やっていること・これからやろうとしていることが、チームの誰のどういう行動に役立つのか、というのが具体的にみえるのがとてもよかった。実際に関わっている人の発言を聴くことで、普段は資料を読むだけの情報に「焦っている・今後困りそう・わりと大丈夫」などの温度感が付与される。優先度というものが本当にわかるのは、この温度感がわかってからだな、と思う。
自分はエンドユーザーに向くより、もっと近い人の方を向いて仕事するほうが向いているんだよな、ということを思い出した。特定少数に対する想像力しかないんだよなぁ。関わり方でも違うのかもしれないけれど。
リモートミーティングのこと
普段参加しない週次ミーティング、参加してみて良かったのでこれからの自分の関わり方を考えていたんだけど、一概にリモート参加するのが良いとも言えない。
普段はやっぱりインターネット越しだから「今しゃべると話の腰を折ってしまうかも」「みんなの思考を止めてしまいそう」「タイムラグで上手く伝わらないかも」「そもそも発言拾えてなくてニュアンス違うかも」など色々発言を躊躇う要素が多く、もともと決めていたまとまった内容しか口に出せない。本題と関係のない「タイミング」について考えることが増えるのは、リモートコミュニケーションの弱点よな。
何かを伝えるときの情報量も全然違う。姿勢や表情、動作などの非言語コミュニケーションができると、伝達がめちゃくちゃはやいし正確に伝わる…気がする。少なくとも「伝わっていない」という状態の把握は格段に速い。たぶん、非言語コミュニケーションの影響が大きいのは、一次的な発信よりもリアクションの方なんだろうな。会話っていうのはリアクションの繰り返しだから。そういう面でもリモートだと「まとまった内容しか口に出せない」と感じるのだと思う。
リモート参加メンバーがいるミーティングのこと
ローカルで多人数でやっていたミーティングに1人がリモート参加すると考える。
まず多人数側
ミーティングにリモート参加のメンバーが増えると、今まで場に向いてた注意が一定量リモート側に割かれる。マイクを通して声が伝わることを意識しなければならない、リアクションが見えづらい人間が聴いている違和感、みたいなものは常にあると思う。
逆にリモートのことを忘れるケースも多い。なにせかなり意識しないとリアクションが受け取れないので、そうなると何も伝わらない上に重要ではないというイメージだけ残り、主にリモート側の士気が下がる。
個人的な感想だが、必須ではない「知っていた方が良い」情報はリモートでは落ちることが多い。耳だけで得る情報は頭に入りづらい／
多少聞き取りづらくてもその場では問い返しづらいので、あとでわかっている人に聞けばよいか、となる（そして必須ではないので聞かない）。
その場のやりとりが増えるミーティングは、オフラインに限定するからこそ良いのかなぁ、という感じがする。一部リモートでやるミーティングは気を使わなければいけないことが増えるので、できるだけ削ぎ落とすのが正解。と、最近は思っている。（もちろんチームやケースによる！）
おしまい
普段、思っている以上に温度感がキャッチできていないな、というのがわかったのがとても良かった。1ヶ月経って相変わらずミーティングにはあまり参加していないけれど、このときのことを思い出して「今から作るものはチームの誰が必要としていて、無いとどれくらい困るか」というのが、スケジュールや夕会の報告から想像できるようになった。
あとはそれを支えられるように、必要最小限で、手早く質良く実装していくだけ！それに追いつくわたしになっていきたい…! はやくなって！おしまい！！
『「共感」ではなく「理解」からはじめるデザインセッション ++ Gaji-Laboブログ』を読んで思い出した
わかる〜！ ←🤔
わたしはだいぶ、「共感」を切り離して考えるのに手こずった。
5年ちょっと前くらいに自分をかえりみたのを思い出したので、その時のログを抜粋しておいておく。このときの私は「共感」が主で、「理解」から入るチームメンバーがすごいと思ったんだな。
以下ログ
メンバーが変わったり、一緒に働いている人との関係が悪くなってしまうと、ガクッと気持ちが下がる。
後者（関係悪化）はともかく前者（入れ替り）はどうにかしたほうがいいし割と頻繁にある話だ。
メンバーが変わった当初、相手の気持ちや考えがどこにあるのか理解しきれていないとき、信用できなくてすごく警戒するし、なんだったら軽視してるかもしれない。自覚すると毎回ハッとして心を正すんだけど、自覚するのも正すのも毎回なかなかうまくいかない。
ここ2年くらいは、一緒にやっている人から学ぶことが多かった。新しい人と一緒に仕事の話をするときに、事実をみる、事実だけで話す、相手の話をきく、自分の考えを話す。そういう淡々とした繰り返しと積み重ねで、自然と相手の考えの傾向や、重きをおいているところがみえてくる。
私は、「気持ちが理解できて近い」「不安や心配事をうちあける」とかそういうところから入らないとうまくできないっぽくて、そこが弱点だなと思った。弱点というか、入り口がそこに偏っている、思考の癖という感じ。癖は愛嬌だと思っていて、癖がある自分かわいい！ じぶんが、ほんとに、すき！（そうですか）
思考の癖がわかると、次に同じ気持ちになった時に、そういう気持ちになるロジックがわかる。そうすると思考の偏りが見えて、違うアクションがとれそうな気がする。（自分の警戒心に対して）こっちからアプローチしようかな、ここは知りたいけどあとまわしかな、みたいな気持ちがわいてくる。それが楽しみ。前向きで明るくて人にやさしい。
Rubyistに支えられて生きてきた
Rubyのすごい人、という表現で紹介されることがあり、違うんですよ私はRubyは基本的な構文以外はリファレンス見て書くくらいしかできないんですよそもそもRailsの外でRubyあんまり使ったことないしRailsもいつまでたっても子鹿みたいな感じだし、という旨発言すると、Rubyのすごい人とたくさん知り合いですごい、と言われ、それならまあわからなくもないですね、ってなる。
RubyKaigiスタッフやったり、コミュニティなんやかんやしたり、一緒に仕事したりすると知り合いはどんどん増えてくから、コミュニティに関わってから年数が長いということなんだよね。
当時の出向先の取引先(遠い)のこだまさんに誘ってもらって、一緒に働いていた人達と一緒に参加した2010年12月4日の札幌Ruby会議03(印象深すぎて日付覚えてる)で、楽しんでコードを書いている人がたくさんいるんだということを知った。こだまさんにしまださんを紹介してもらったり、Ruby札幌のことを知ったりしたおかげで勉強会に行く勇気ももらえた。
はじめて参加するRubyKaigi(Final)ではよく喋る札幌勢がほとんどスタッフとして参加していてしょんぼりしていたのだけど、mrknさんがずっと一緒に回ってくれていてとても嬉しかった。当然なんだけどmrknさんについてまわってるとなんかよくわからないくらいすごい人達と喋ることができる(よくわからなくて喋れない)。Ruby札幌の知名度のおかげで自己紹介がしやすく、懇親会で知らない人とたくさん知り合うことができた。
闇RubyKaigi2011で銅鑼乙女やってチャイナドレス着たのもデカかったかもしれない。自己紹介のネタとしてキャッチーだった。RubyKaigiのドラ娘に応募して闇RubyKaigi2011の銅鑼乙女になったんだけど、あれはRubyKaigi2011とは関係ない、別だから、と言ってドラ娘3人の中で唯一スタッフとして http://rubykaigi.org/2011/en/team/ に載せてもらえなかった恨みはずっと持ち続けている(闇を抱え込むタイプ)。話が逸れた！
そういうとこからはじまり、SapporoRubyKaigi2012やRubyKaigi2013でスタッフをやって、アジャイル札幌とかtorubyとかtotekaとかSendagaya.rbとかいろいろ参加したり開催したり、そこから知り合った人たちと一緒に仕事したりして今があるんだよなあ。だから私のすごいとこは、時間で蓄積された故のすごいところ。時間や人々の重みが私を支えてくれているから、すごいと表現してもらえるんだろうな、みたいなことを感じる。
余談だけどspring_akiさんと話をするたびに、あのとき話しかけてもらったから今があるんですよ、と言ってもらえるのめちゃくちゃ嬉しい。たしかFinalの懇親会のとき、せっかくだから知らない人と話そうと思って、でも集団に話しかけるのはこわいからぼっちか二人組を狙おう、と話しかけたら何故か立て続けに大阪の人で、今回がはじめての参加なんですよはじめてなのにFinal、大阪から何人か来てるんですよね、という感じで話した中にakiさんがいたのかな。一番最初に話したのかも。気さくに喋ってくれて救われていたんだけど、お互いにそうだったのかなと考えると嬉しいんだよなー。みたいなのを毎年思いだす。
