チーム・ジャーニーを読んだ。いつも自分には何かできることがある
と思った。カイゼン・ジャーニーをだいぶ前に読んだときもそうだったが、物語が面白いので、どしどしと読める。ストーリーがあって、そのストーリーに対する専門的な解説が続く、そしてまたストーリーとなる。続きが気になって解説を読み飛ばしたくなるほどだ。それほど毎回、主人公やそのチームは、これ一体どうするんだろう、という状況に追い込まれる。何か問題が起きている、ただそれにどう対処したらいいかわからない、、、そこに誰かが助け舟となるアイデアや助言をくれるといったように展開していく。困難に対処したかと思えば、さらに状況は変化し、都度その対応を求められる。
とても面白い本だった。現実に僕が所属するチームに対して課題感を持っているので、何か現実に適応できる施策へのヒントはないのかと、高い温度感で主体的に読めたことと、それに呼応して本書が知識を提供してくれたからだろう。よし、ここの部分を適用できそうだ、とそっくりそのまま施策例を使うことはできないだろう。それは本書の問題ではなく、読み手である僕の問題だ。所属するチームが抱える課題をまだ正確に把握できていないからだ。ただ、本書のあのあたりの施策はヒントになるだろう、という感じはあった。大収穫である。もう少し整理すれば、来週のどこかで提案ができそうだ。
スクラムの知識が増えた、だから本を読んで良かった、という単純な感想ももちろん持ったが、それよりも本書を読んで心にグッと来たのは別のことだ。それは、どのような状況であれ自分にできることはまだある、と思えたことだ。そのような想いを体全体で受け止めることができた。何よりの収穫だった。根底にそのことを信じることができるからこそ、具体的な行動を実行できるのではないか。そして現場経験の日が浅い僕にとっては、もちろんその実行方法には舌を巻くことがあった。その手があったのか！と。課題に対処するためには、自分が巻き込めると思う人間関係の範囲を乗り越えていく必要があるのだ。チームはときとしてその形を柔軟に変化させるのだ、という当たり前のことも新鮮に思えた。
チームの問題や課題（あるいは自分のそれら）だと思うことにぶち当たると、うわーと言って思考停止になる瞬間（の積み重ねとしての時間）がある。どーしたらいーんだー、と嘆く時間がある。そんなとき「まだ自分にできることはある」と強く思って、自分にできないのであれば、できる人に聞く、それもできるだけ上手く聞く、というようなネクストアクションを取る必要がある。まだ自分にできることはある、と念じることは前向きの思考を呼び出せそうでいい。
と思うだけでは状況は変わらないので実行していきたい。そしてそのために施策を中心に再読したい。カイゼン・ジャーニーも。
（了）
モジュールの include と extend と prepend
モジュールをクラスや別のモジュールへ読み込ませること、つまりモジュールの機能を追加することをミックスインという。そのミックスインの方法には include と extend に大別できる。
例えばクラスにモジュールを include すると モジュールのメソッドを、クラスのインスタンスで利用することができる。一方で、クラスにモジュールをextendすると、クラスの特異メソッド（クラスメソッド）として利用することができる。両者の利用シーンは、ミックスインされたクラスに関して、モジュールのメソッドを、インスタンスメソッドとして利用したいのか、クラスメソッドとして利用したいのかの違いとなる。腹落ちしてしまえばそんなに混乱することはない。
そして include の亜種としてprependが存在する。メソッド探索の順番が異なる。include でモジュールをミックスインした場合、メソッド探索は 【ミックスインされたクラス→モジュール】 となる。一方で、prepend でモジュールをミックスインした場合、メソッド探索の順番が 【モジュール→ミックスインしたクラス】 となる。とにかく先にモジュールをメソッド探索して欲しい場合に、prependを使うよう。
参考 第８章
（了）
【Rspecメモ】before内で定義した変数は、it内で使えない
表題のとおり。テストコードを書いていて詰まった。before内にbinding.pryを仕込んでみたら、ローカル変数からテストしたいメソッドは呼べたのに、it内では呼べない、という現象だった。
よく考えればあたりまえのことだ。before内はひとつのブロックとみなせば、そこで定義された変数の適用範囲はそのブロック内ではないか。詳しい人に教えてもらって解決した。対処法としては、インスタンス変数にしたり、letで用意したり、あるいはitのなかで変数を定義したりと考えられる。今回は最後の方法を採った。
（了）
チームで働くということの何が好き？
個人でひそひそと作業することは好きだ。一時期少しだけ早く起きて小説を書いてから他人との生活へ戻ることを習慣にしていたし、別の時期には深夜にstand.fmなるラジオアプリでちょっとしたエッセイみたいなものを毎日投稿していたこともあった。個人でひそひそと何かを継続することが好きなようだ。一方で、チームで働くことも好きだ。サッカーを高校まで続けていたのも、チームプレーが好きだったからだと思う。そしていま会社ではスクラムを取り入れた開発体制のもとで、チームで開発している。そこでもっと上手くできるのではないか、、、？ともんもんとしている。もちろん僕の技術力があれば解決できることもあるのだろうけど。それでも、何かもやもやしている。みんないい人だし、一生懸命働いているのに、ときにうまくいかないことがあるからだ。
ということでチームジャーニーを読んでいる。面白い。いずれ別の記事で印象に残った点を紹介したい。
なんで面白いのかなーと思った。きっとチームがいい感じに機能していくさまが心地よくて、その土台にチームで動くことが好きという気持ちがあるからだと思った。なので、チームで働くことのどこに魅力を感じているかを言語化しておこうと思う。なぜなんだろう？
まず、ひとりではできなかったことができる、ことが挙げられる。確かにそうだけれどあんまり響かないので、この点はそこまで重要じゃないのかもしれない。「助け合いが見れる」、ということが最も大きいことかもしれない。僕は自分にできないことをやってのける人を見て感心することが好きなのだ。おぉーすごいー！と思う。母親譲りだ。チームで働くと誰かの助けを借りることになる。悩んでいたことをパッと解決されると、おぉーと思う。正直なところ嫉妬も感じる。人として未熟なのだ。一抹の嫉妬はあるものの、おぉーすごい、と思うことはとても楽しい。本人に取っては取るに足らないことでも、その能力を僕に向けて発揮してくれたこと、それ自体にも感謝してしまう。やや大げさかもしれないけれど、時間と労力は必ずかかるのだから大感謝だ。
助け合いが見れる、という点の他には、「何かよい雰囲気が漂うと実力を少し越えた力が出る感じがする」という点も好きだ。まったく客観的ではない。主観的に何かそういう重力のようなものを感じたことがある。お互いの信頼感が渦潮のように漂い、その力に背中を押されてチャレンジの姿勢になれる、気がする。実力を超えるパフォーマンスができるような気がする。またそういう風なチームメンバーの姿に出会うことがある。いとをかし。こういうときに足元をすくわれることもあるだろうが、なんというかそういう力学の存在を信じてしまう。ストレングスファインダーの上位５つに運命思考がランキングする所以だ。
それら２つが好きでチームで動くことが好きなのだろう。なんかいいなー、もっとよくなればいいなーと漠然と思っていたのだけれど、最近は違う。もっと積極的に働きかけをしたいなと思っている。現場で具体的な大小の問題が起きて考えが変わったせいもある。もちろん一人で張り切ったところで空回りしてしまうことはあるだろうけど、チャレンジをして失敗しても別にかまわないだろう。
チームが好き、チームっていいと思うだけでその解像度は粗いままだった。チームって何だ？その定義は？どういうリソースが必要？どういうフローが必要？問題が起きたときはどう対処するの？などについて調べようともしていなかった。会社の同僚のtimesで紹介されていたし、知り合いのアジャイルコーチにも勧められたのでチームジャーニーを手に取った次第だ。チームは状況に対して変化していく。理論と実践が交互に語られている。これいまの現場と似ているな、と思う箇所もあった。もっと自分で働きかけられることもあるかも、と思えた。もう少し整理したらチームで小さくアクションしたい。
チームメンバーとよい雰囲気でよりよく働くことを整えることに興味はあるので、スクラムやアジャイルの分野へとキャリアパスを描くのもいいのかもしれない、なんて思う。さて、明日は月曜日だ。
（了）
チェリー本の第７章クラスを復習した。
クラスの復習をしている。超マイクロアウトプット
- クラス内にて、メソッド内でインスタンス変数の属性をセットする（更新）する際にはselfをつける必要がある。でないとローカル変数を格納するだけになり、期待した結果を得られない。
なんとなくでいつもselfをつけているので、すっきりした。更新するときはselfが不可欠なのだ。
- attr_accessorって何をしてるんだっけ？ インスタンス変数の指定した属性に対して読み書きするメソッドを追加できる。
公式の説明はわかりやすい。 Module#attr_accessor (Ruby 3.1 リファレンスマニュアル)
- 既存の実装を上書きして期待する挙動に変更することを「モンキーパッチ」と呼ぶ。
なるほどー。説明が簡潔でわかりやすい。
- 特定のオブジェクトにだけ紐づくメソッドのことを特異メソッドと呼ぶ（英語だとsingleton method）。
なるほど！Rubyのリファレンスマニュアルにある特異メソッドとは、そのクラスオブジェクトのみが持っているメソッドのことを指しているのか。と閃いた次のページにそのものズバリが解説されていた。昔読んだ記憶が喚起されただけなのかもしれない。
- コードを実行する瞬間のみにRubyは関心がある。そのメソッドが呼出せるか否か？と。ゆえに（？）、データ型をチェックしたりしない。オブジェクトのクラスが何であろうが、メソッドが呼べるかどうかのみを気にするプログラミングスタイルのことを「ダックタイピング」という。なのでモジュールやスーパークラス内に存在しないメソッドを書くことも可能。モジュールを取り込む側や継承先のコードに、そのメソッドがあればいい。
ということはつまり逆の観点だと、静的型付け言語は（goとかtypescript?）ダックタイピングではないことになる。例えばモジュール内に存在しないメソッドを呼んだりはできないのかな。
- （8章）inculdeすると、モジュールのメソッドをインスタンスメソッドとして使える。一方で、extendすると、モジュールのメソッドをクラスメソッドとして使える。
もやもやしてたことが腑に落ちた。このへんは初学者の頃に読んでもあまり実感をともなった理解にいたれなかった思い出があるので、すっきりしてよかった。
（了）
整数っぽくない文字列をto_iすると0が返る
整数ぽい文字列に to_i をすると数値に変換してくれる。このことがわからず詰まったのでメモしておく。
irb(main):001:0> '100'.to_i => 100
このメソッドを例えば整数っぽくない文字列に対して利用するとエラーにはならず、０が返る。
irb(main):002:0> 'tawara'.to_i => 0
公式にわかりやすく書いてある。
（了）
ブログを書く暇がないほど忙しいことは健全なのか？
健全ではない、と思う。起きて仕事ばっかりしている。ある業務委託のエンジニア曰く「瞬間最大風力を出すのはときに必要だが、それが続くと長期的に働く意欲が減る」とのこと。 仕事仲間はみんないい人なので仕事をすることは根本的に楽しい。チームで開発しているので、もっとうまく段取りをうまく回せるようになれば負担は減るはずだと思う。強く思う。なので、エンジニアとしての技術力はもちろんのこと、仕事の段取り、特にチケットに切り方については学習したい。アジャイルやスクラムをキーワードにして、その周辺を学習したい。なんとなく書籍を購入して読んでいたけれど、身体的にようやっと学習の準備が整った感じがする。
マイクロアウトプットできないと、気持ちよくないし。読者を気にしない、毎日アウトプット続けるぞ。
（了）
