Team Geek 読書会の感想 #techplaygirls

勉強会

Team Geek 読書会 with Saki さんが終了しました。その感想です。

  • 2021/01-2021/02
  • 朝 6:00 - 7:00
  • 週 火・木・土

Team Geek のざっくり概要

優れたソフトウェアを届けることを目的とし、プログラマがソフトウェア開発を効果的かつ効率的にするために、HRT（Humility:謙虚 - Respect:尊敬 - Trust:信頼, 読み方はハート）をまずは自分から実践し、チーム、組織、そしてサービスを使うユーザまで影響範囲を広げていきましょう。ここでは Geek な奴らの HRT を紹介します。君はそれができてるかい？😎

本の感想

謙虚とは？

謙虚のいくつのかの実践項目の中で以下の文章があったのですが

早い段階で失敗する・学習・反復する（P.22）
必要なのは、不完全なソフトウェアを見せても構わないという謙虚と、ユーザがぞの対応を賞賛し、迅速な改善を望んでいるという信頼だ。

これを読んだときには私は謙虚を勘違いしていると思いまた。謙虚は自分のスキルに傲慢になりすぎず、常に改善していく姿勢をのことだとは思っていたのですが、不完全なソフトウェアを見せることは周りの人に迷惑かけそう…が勝って遠慮気味だったなぁと気付きました。この本の HRT は「優れたソフトウェアを届けたい」という目的に沿って書かれているもので、確かにその目的を改めて認識すると早めにフィードバックをもらう形が大事なんだと分かりました。

自分はなぜリーダーになりたくないのか？

もともと下っ端が好きで上の立場になりたくないと日頃から思ってるタイプなのですが。自分がなぜリーダーをやりたがらないのか？が分かりました。

みんなの友達になる。（P.74） エンジニアがリーダーになるときは、今までいたチームのリーダーになることが多い。それまでに築いた関係を壊したくないので、リーダーになった後も友人関係を続けようとする。これが間違いの原因だ。

リーダーになると友人関係が崩れてしまうのではないか？友達に仕事に関して注意しないといけない日がくるのか…？と考えると憂鬱になります。だけど自分が下の立場のとき、フレンドリーだけど頼んだ仕事をやってくれないリーダーは嫌だなぁと思っていたので、リーダーとチームメンバーとの関係かと友人関係は混同してはいけないなと思いました。

エゴをなくす（P.76）
リーダーは何でも正しくやって、全てを把握して、あらゆる質問に答える責任があると思っいる。全てを正しくやる必要はないし、あらゆる質問に答える必要もないし、そんなことをしていたら逆にチームの信頼を失ってしまう。

リーダーは全知全能じゃなきゃいけない、私にはまだまだ…😩って思ってる自分がいました。自分でハードル上げて自分の首を絞めるパターンです。大事なのは知っていることじゃなくてフィードバックと批判をオープンに受け止めること！

悪い人はいない

有害の定義（P.99）
排除するのはあくまでも振る舞いであり、特定の個人ではない。個人を「いい」とか「悪い」とかで考えるのは単純すぎる。目に余る振る舞いを特定して、そのことを批判するほうが建設的で実践的だ。

この文章はハッとさせられたし、この本の中で一番好きな部分です。これまでの経験でこの人苦手だなって感じた時に、明らかに振る舞いじゃなくて個人にフォーカスを当てているなぁと思います。（『この人』って言ってるしね…）また、振る舞いに注目するスタンスを持つことで自分が間違いを指摘された時も自分はダメな奴だぁと考えることもなくなりそうです。

HRT に優先順位はあるのか？

過去に苦手だと感じていた人に対して、私は信頼してなかったし、謙虚でもなかったし、尊敬も一部だけって感じでした。振り返って、その人との関係を HRT で実践するにはどうすれば良かったのか？HRT のどの柱から実践していけば良かったのか？HRT に優先順位はあるのか？悩みました。私の結論は「HRT に優先順位はない」ということです。HRT は全部オモテとウラで繋がっていて、尊敬してるから信頼できるし、信頼してるから謙虚になれる、謙虚だから周りを尊敬できる、といったグルッと繋がってるイメージなのだと解釈しました。だからこそ HRT のどの柱から？じゃなくて、自分から、出来るところから HRT を実践していくことが大事なんだと思いました。

読書会の感想

今回は Hackmd に読書会ログを入力しながら進めました。もともと読みながら or 人の話し聴きながら記録を取るのが得意じゃないので、この読書会のやり方は避け気味でした。しかし、読書会が終わった後にログを見返すと本の内容やその時考えたことを思い出す良い index になってるなぁと感じたので頑張って書いて良かったです。

また、こういうチームビルディング的な本は誰かと一緒に読むのが楽しいなぁと思いました。自分以外の人の考えに触れることで、あぁそういう視点もあるのかと視野を広げることが出来たり、その場で自分が「なぜそう思ったのか？」を言語化するので自分の認識を改めて考える良い機会になりました。あと Team Geek は比較的読みやすい本なので、1人で読んでるとパラパラ進んでしまいがちですが、読書会の場合だと自分と相手では同じページでも気になるポイントが異なるので、自分がフンフンと進んでしまった箇所を掘り下げてもらえて、一人で読むより丁寧に読むことができました。感謝でっす。

NVC の感謝を実践する

NVC

「NVC（非暴力コミュニケーション） 人と人との関係にいのちを吹き込む法」を読んで、私は感謝表現が足りていないことに気付きました。ありがとうや相手への賞賛の言葉で感謝を終わらせていたし、感謝をする時の自分の感情をゆっくり味わっていなかったことが分かったのです。

そこで毎日 NVC の感謝を実践しようと思い日記に書き留めていたのですが、ある時ネットで「感謝のノート」というものを見つけて、まさにこれだと思いました。

感謝の気持ちを育む感謝ノートの実践方法は英語で書かれていたので、以下はそれの翻訳です。

原文は Radical Compassion - Practices for Integrating NVC の「1. Cultivating Gratitude」です。

  1. あなたの人生をより素晴らしいものにしてくれた特定の誰かの行動を書いてください。
    （これは観察する練習になります。）
  2. その行動が貢献したニーズ（自分が必要としていること）を書いてください。
    （これはニーズの語彙とニーズを意識することに役立ちます。）
  3. 感謝の気持ちを書きながら、今の自分の感情を書いてください。
    （これは感情の語彙と感情を認識すること役立ちます。）
  4. 感情を味わってください。
    （これは感情の存在を感じることの実践と活力を養うのに役立ちます。）
  5. この行動を可能にするのに役立ったあなたがしたことを書いてください。
    （これは観察の練習ができ、貢献、共有力、相互依存の意識が高まります。）

1日に3つの例を書いて味わい、少なくとも30日間は練習に取り組むことをお勧めします。
30日間の練習後、radicalcompassion@gmail.com にフィードバックをください。

30日続けたら feedback を送りたいです。

Observer パターン for Ruby / Rails

デザインパターン Ruby Rails

この記事は本の感想、備忘録です。

各項目のサンプルコードは本書に掲載されているものではなく、復習のために自分で書いたものです。

Observer パターン

プログラム内のオブジェクトのイベントを他のオブジェクトへ通知する処理で使われるデザインパターンの一種です。（by wikipedia）

ざっくりしたシーケンス図です。 f:id:meikotan:20210223101759j:plain

パターン適用前の構造がオブジェクトのイベントと他のオブジェクトへ通知する処理が密結合だった場合、他のオブジェクトへ通知する処理に変更が発生するたびにイベント発行オブジェクトを書き換える必要があります。Observer パターンでは通知する処理に共通インターフェースを適用することで、イベント発行オブジェクトはそのインターフェースに依存するのみで、具体的な通知処理への依存をなくすことができます。

例えば、社員の給料計算が終わった後に結果を社員とその上司にメール通知する場合を考えます。Observer パターンを使わない場合、給与計算するイベントはメール通知処理の具体的なことまで把握しています。一方で Observer パターンを適用した場合、給与計算イベントはメール通知処理のことを把握しません。把握しているのは給与計算イベントの後に何らかの処理をするということだけです。

# Observer パターンを使わない場合
def calculate_salary
  # 給与計算処理

  # 計算後にする処理
  NotificationMailer.exe(user) # ユーザにメール送信
  NotificationMailer.exe(manager) # 管理者にメール送信
end

# Observer パターンを使う場合
def calculate_salary
  # 給与計算処理

  # 計算後にする処理
  @observers.each do |observer|
    observer.update(self) # 具体的な処理内容を知らない
  end
end

「観察」より「通知」になっている

Java のデザインパターン本には

observer という言葉の本来の意味は「観察者」ですが、実際には Observer 役は能動的に「観察」するのではなく、Subject 役から「通知」されるのを受動的に待っていることになります。Observer パターンは、Publish-Subscribe パターンと呼ばれることもあります。publish（発行）と subscribe（購読）と言う表現の方が、実際にあっているかもしれませんね。

と書いてあるのですが、Observer パターンと Pub/Sub パターンは異なるパターンと説明されている記事もあります。

Observer パターンとは異なる Pub/Sub パターン

ここでの Pub/Sub パターンと Observer パターンでの大きな違いは、通知に必要な「通知先を把握する役割」と「通知する役割」をどのクラスが持つか？ということです。Observer パターンではそれを Subject が持っていましたが、Pub/Sub パターンはそれを別のクラス（Channel クラス）に切り出します。結果、Publisher と Subscriber の間に通知を管理する Channel が挟まり、Publisher と Subscriber が直接やり取りすることはなくなります。

Observer vs Pub-Sub pattern
Observer vs Pub-Sub pattern | Hacker Noon

参考）PythonにおけるPub/Subパターンの実装

ActionCable もこの形ですね。

Ruby / Rails

標準ライブラリに Observable がある

module Observable (Ruby 3.0.0 リファレンスマニュアル)

require 'observer'

class LifeGame
  include Observable
  
  def next_generation
    # xxx 何かしらの処理

    changed # 通知する・しないのフラグ更新が必要。引数はデフォルト true
    notify_observers(self) # これを呼ぶとフラグは初期化（false）される
  end
end

Observer の処理をコードブロックで渡しても OK

class LifeGame
  def initialize
    @observers = []
  end

  def add_observer(&observer) # ブロックを受け取れるようにする
    @observers << observer
  end

  def next_generation
    # xxx 何かしらの処理
    notify_observer
  end

  private

  def notify_observer
    @observers.each do |observer|
      observer.call(self) # proc.call
    end
  end
end

# main
life_game = LifeGame.new
life_game.add_observer do |changed_field|
  puts("次の世代になりました。")
  # 次の世代のセルを表示する処理
end

ActiveRecord::observer

ActiveRecord::Observer

モデルの callback 処理を Observer クラスに切り出すことができます。Observer クラスはファイル名からモデルのマッピングを行うため（COC）、クラス名を変えない場合はマッピングを明示する必要はありません。

class UserObserver < ActiveRecord::Observer
  def after_create(user)
    Notifications.create_user("Registration completed", user).deliver
  end
end

今度使いたいです٩( 'ω' )و

#hayaoki_girls １年の軌跡 ＊ TECH PLAY 女子部 #techplaygirls

振返り early_sleeping

TECH PLAY 女子部で #hayaoki_girls チャンネルが立ち上がってから１年が経ちました👏 いまは立ち上げ当初予想もしなかった良い感じのチャンネルになってとっても嬉しいです。そして最近 hayaoki_girls の最初ってどんな感じだったの？と聞かれることが増えてきたので記事にすることにしました。記事中の（〇〇期）は完全に私の主観です。

What is hayaoki_girls?

hayaoki_girls については既にりほやんと katorie さんが記事を書いてくれたし、yancan.fm でも放送してもらったのでそれを参照してください。

The path of hayaoki_girls

きっかけ

2019 年 TECHPLAY 女子部の Advent Calendar で ぱんさんが「みんチャレ」イイぞ的な記事の投稿を通して、りほやんが女子部内で「毎日 IT の勉強をする」みんチャレグループを作ってくれて。仕事以外の IT の勉強を継続したい…！と思っていた私は楽しそう！と思って参加しました。
んで、私はそのとき既に6時起きの人だったのでみんチャレの更新は基本朝行っていたのですが、みんチャレ中に chihiro さんから「早起き自分もしたい」と言ってもらって、私も一緒にやる人探してたので「嬉しいです！」となり、2019年12月に早起き用のチャンネルを作ってほぼ今のルールで運用を開始しました。

＊補足＊
いま運用してる hayaoki_girls の仕組みは私が以前所属していたライフエンジンというオンラインコミュニティで行われていた朝活の仕組みを元に作っています。そして元々はライフエンジンのメンバーと早起きしていたのですが、ちょうどみんチャレを始めたタイミング当たりでそれを辞めてしまったので、一緒に早起きしてくれる誰かを探していました。
詳細は女子部で hayaoki_girls をやる前を見てください。

だから chihiro さんが声掛けてくれて本当に嬉しかった。ありがとう😘

始まり（細々期）

chihiro さんの仕事の関係上、6時だともう出勤準備する時間だから5時起きが良いと言われて、もともと6時起きで満足してた私はちょっと躊躇しましたが、チャレンジしてみたい気持ちもあったし早起き友達が欲しかったので5時でいきましょう！ということになりました。また、最初は平日限定でやってました。（理由は覚えてないけど、土日まで早起きする気にはなれなかったんだと思う）

f:id:meikotan:20210108155615p:plain
5時起きのみのスケジュール

最初の数ヶ月は chihiro さんと、その後 katorie さんが入って来てくれたり（同じぐらいのタイミングで chihiro さんが来なくなり…）他にも数人、知り合いに声を掛けて少しずつ人数増やしながら細々と早起きをしていました。 当時、zoom にいるのが私ともう1人（合計2人）のことが多かったので自分が休むと相手は1人だ…という使命感からほぼ休まず参加してた気がします。特に最初は寒かったので布団の中にパソコンを持ち込んで喋ってたり、5時に雑談してもくもくタイムは2度寝して、6時の雑談でまた起きるみたいなことも頻繁にやってました😂

布団の中で雑談

あと slack を見返すとこの頃にデザインパターンの読書会を始めたり、同じアプリをみんなで作るレビュー会を始めたりしました。早起きの仕組みとしては6時起きの人のために雑談時間を延長したり、毎日早起きしたいという人のために「平日のみ」→「毎日」に変更したりしました。（要望がある度に出来る限り仕組みを拡張・見直しています）

チャンネル名は最初 #goodmorning でした。ただ数ヶ月細々と早起きを続けてると女子部の運営の方（ほくりんさん）から女子部内や外部に発信したいと言われ、どうしても「意識高い感じでやってるんじゃない。ただ早く寝てるだけで…睡眠時間削ってウォーって感じではない」を強調したくて、チャンネル名を #early_sleeping にしました。私たちの早起きは意識高くないんです。早く寝てるだけ。睡眠時間を削ってるんじゃなくて寝る時間を前倒ししてるだけです。

大量に人が増えた（拡散期）

その後りほやんがガッツリ早起きを始めるようになって「ハッシュタグほしい」と言われ、#hayaoki_girls を作りました。

いろんな候補を出し合ったの懐かしい😌

  • techplay_asakatsu_girls
  • asakatsu_girls
  • morning_girls
  • hayaoki_girls
  • early_sleeping_girls
  • hayane_girls

そしてりほやんが tweet するとワラワラと興味ある！という人がチャンネルに入ってきました。

↓ その時の私の個人的な感想です。

私は誰かを巻き込むときは草の根運動派で仲の良くなってきた人に少しずつ声を掛けて進めるタイプだったので、りほやんの大多数の人にわーっと拡散できる影響力に感嘆しました。エンジニア界のインフルエンサー！ほんとにりほやんが日々 tweet するたびに新しい人がどんどん増えて…そのパワフルな影響力を肌で感じた。すげー！

ときには5時、6時に7人とか人が集まり…そんなことある…？個人的に #hayaoki_girls の一番の転機だったなぁと思います。そしてりほやんは雑談で出てきたリンクを slack にバンバン載せてくれるタイプで、その影響で今はみんな slack に載せるようになったと思うし、Read Only の人でも楽しめるチャンネルになっていきました。

夜にやってることをやりたい（イベント期）

hayaoki_girls は寝る時間の前倒しなので、元々夜やってたことを朝にやりたい！という思いがずっとあって。（個人レベルでいうと夜やっていた皿洗いなどのタスクを朝やるようになったら生活がスムーズになりました。）んで、この頃わたしは女子部のオーガナイザーになったこともあり、とりあえず夜やってたイベントを朝やりたいぞ！という欲がムクムク出てきて思いつくままに企画しました😌✨

最初の企画はチャレンジングな「Morning オンライン飲み会」です！

f:id:meikotan:20210108162328p:plain
オンライン飲み会

その後、外部にも告知をした雑談会を2回開催したり、新年には katorie さんが「新春🌅初夢 LT会」を企画してくれました。 techplay.jp techplay.jp

最近（いい感じにまわってる期）

いい感じにまわってるの定義は誰かがいなくちゃ！って感じじゃなくて、参加してる人がこの場を大切にしていこう、維持していこうという気持ちでまわってるイメージで、最近はそんな感じな気がします。ありがたや。
そしてこの前、初夢 LT 会の後に「夜型もいるぞ！」ということで #mayonaka_girls チャンネルが爆誕し、それに対になるようにチャンネル名を #early_sleeping → #hayaoki_girls に変更しました（ハッシュタグと同じになったよ）。

こっからは私の話

女子部で hayaoki_girls をやる前（ライフエンジン期）

私が早起きを始めたのは2019年の5月〜です。私は2017年〜在宅ワークを始めていたのですが、それまでの私は9時出勤なのに8時55分ぐらいまで寝てて、まだ頭がぼーっとしている状態でパソコンの前に座り仕事しなきゃ…とか思いつつ、でもお腹空くからパソコン眺めながら朝ごはん食べたり歯を磨いたり…ダラダラ仕事をしていました。そして夜もダラダラで YouTube 見たりアニメ見たりして日々夜更かししてたのですが、心の中でずっとこの状態は良くない…！早起きできるようになりたい…！と思って、たまに早起き頑張ってみるんだけど続かずまた夜更かし…を繰り返していました。

そんな時にひらめきラジオで早起きは友達とすると続くよ。寝る時間を削るんじゃなくて寝る時間を前倒しにしてるだけだよ。と聞いて「なるほど！」となり、ライブエンジンというオンラインコミュニティでそういう朝活をやっているよ。と聞いて次の日にはライフエンジンに参加してました。そして初めてzoomで待ち合わせをする早起きを体験して、本当に本当に6時に起きれた！🥺 と感動しました。

ただ残念なことに既にライフエンジンでは朝活ブームが過ぎ去っており…朝活がそろそろなくなるらしいよ…という雰囲気でした。そして本当に3ヶ月ぐらいでなくなっちゃって（泣）でも早起きの方が私の体に合ってる！は既に実感してたので1人でも朝活を続けようと決意してたのですが、1人だと意志が弱すぎて寝坊しちゃうことも多く、まただんだんと夜型に引っ張られていきました…（悲） そんなときライフエンジンで友達になった1人がなんでも屋的な仕事を受けていて、その子に早起きを一緒にやってもらえるようにお願いして zoom で待ち合わせをする早起きを復活させました。そこから半年ほど継続してだいぶ体に染み付いてきたなぁと感じたので、2019 年の12月にその子への早起きの依頼を辞めてまた1人で早起き頑張ろう…！と決意してた頃、でもやっぱり1人は寂しいなと思ってた頃、chihiro さんに声をかけてもらった！に至ります。

hyaoki_girls 雑談の功績 for me

slack 眺めながら書き出してみた。

雑談を通して買ったもの（もっとありそうだけど…）

雑談を通して始めたもの

  • デザインパターンの読書会
  • テックプレイ女子部のオーガナイザー
  • 低用量ピル（OC）
  • Go の勉強（途中で挫折）
  • 月曜断食
  • Go To トラベル

女子エンジニアのお友達ができた！

これが一番だね。hayaoki_girls 始めるまで、女子エンジニアの友達ほぼいなかったので。それが一番嬉しいし偉大な雑談の功績です。

おわりに

個人的に一番の発見は目を覚ますためにやってた10分間の雑談がこんなにも有益でこんなにも尊いものなんだ！と気付いたことです。 近頃は喋りたいから明日は絶対早起きするぞ！とかある（笑）

また、女子部の運営方針に書いてある

皆さんがこのコミュニティで自分が楽しめる形を見つけて欲しいし、なければ創って欲しいです。

を体現できたのが hayaoki_girls だとも思っています。素晴らしい。おかげさまですわ👏
これからも「いい感じ」を維持していけたら良いなと思います。

宣伝

#hayaoki_girls に興味を持った方がいれば、TECH PLAY 女子部に参加する必要があるので気になる方はこちらを確認してください😌 最近、夜型の人向けの #mayonaka_girls もできたので自分の体に合う方に参加できると思います。
techplay.jp

2020 年（令和 2 年）の振り返り

振返り

risacan の年末振り返りブログを見て私も書きたいなって思ってたので、今年のライフイベントから技術、仕事とか印象に残ってるものを振り返り（というか箇条書き）する。
正直、今年の初めには想像もしてなかった今を過ごしてるので１年を振り返ると感慨深い。だってコロナになってなかったら今年は春にオランダ旅行、夏にオリンピック、秋には ウラジオストク、冬は AWS re:Invent に行く予定だったし（お金は貯め終わってた）、愛媛で参加してた山登りサークルのメンバーと石鎚山のぼってただろうし、大好きな家で相変わらずお仕事してちょっと良い椅子でも買ってみようかな？みたいな楽しい計画もあったのに。まぁでも振り返るとコロナになったからこそ挑戦できたことや広がった選択肢もいっぱいあって、自分の適用能力ほんと優秀じゃん！ってなってる。otsukare Aya chan !! (ﾟ∀ﾟ)

イベント

2月：Rails Girls Ehime 2nd 開催した

本当にコロナ前に開催できて良かった。花粉症のコーチが3月、4月は嫌だって言ってくれたおかげ( ^ω^ )グッズは何度みても可愛いね❤️ 越智さんのセンス最強。

Rails Girls 関連ブログは他にもあるので興味がある方は見てください。

2月：TDD Bootcamp に参加した

このタイミングで TDD Bootcamp 参加できたのは良かったなぁ。なんで先にテストを書くのか？とかフワッと疑問に思ってた点がスッキリしたしテストが好きになった。
参加ブログ：TDD Boot Camp in 愛媛 に参加しました！

あと t_wada さんのことも好きになって過去 Podcast を聞いたり、記事読んだりするようになった。説明わかりやす過ぎる…！！

6月・7月：CodeCamp の Youtube 配信にでた

エンジニアの本音！座談会

東京 / 地方のエンジニアの働き方の違いやリモートワークについて話した。
www.youtube.com moriyama さんファシリテータ安心感すごいし、他の先生達ともともと面識あってリハもシッカリあったから話しやすかった。

人気講師が教える　プログラミング学習効率アップ！「なぜ」の魔法

初学者の方向けに自習中に自分だけの「なぜ・疑問点」を持つと成長がはやいよ。という話をした。
www.youtube.com

初めて1人40分オンラインで話す講義だったのだけど、想像以上に当日は孤独感と緊張感があって辛かった。この Youtube は自分の中ですごく失敗したって印象が強くて半年ぐらい自分で動画を見返すことができなかった…（先週やっと見返せたよ）。
失敗したって思った部分は受講生からの質問への回答のしかたで、その時はあまりにもテンパりすぎて正直にズバズバ言っちゃったの。まぁでも動画見返したら今同じ質問が来たても同じように返してなって思うし、私らしかったなと思った。Goog Job !! Aya chan !! そして質疑応答以外は良い内容を伝えられたなって思ったし、まだ初学者の人に伝えたいことがあるので来年は月一本ペースで Youtuber やろうと思ってる ٩( 'ω' )و

7月：TECH PLAY 女子部のオーガナイザー始めた

techplay.jp

結構急に決めたことだったんだけど想像を超えて良い経験だった。（まだ終わってない😅）
私がコミュニティ運営するときは「私はこういう形がいい！私はこういうことがやりたい！」が強くあって、その理想さえ描ければあとはそれに向かって猛進するだけって感じの運営スタイルで（Rails Girls のときもそんな感じ）。でも TECH PLAY 女子部はもともとの運営の形もあるし、ある程度規模の大きいコミュニティだったので同じように自分の理想を実装する運営スタイルを推し進めて良いのか不安はあったけど、それに挑戦できて良かったな。人数が多くて色んな人がいるからこそ、自分の理想に共感してもらうこともあれば、別の視点で意味付してる人、逆の発想を教えてくれて私の固定概念をいい意味で崩してくれる人。色んな人と話して本当に良い学びが多くて楽しかった。（まだ終わってない😌）

今オーガナイザー振り返りブログを書き始めて来年公開予定なので、続きはその記事で。

8月：東京に引っ越した

2年半ほど住んだお家。横が海で最高の散歩コースだった。さよなら北条 😭👋

愛媛のお家

8月：オランダ旅行に3週間いった

コロナで行けるかヒヤヒヤしたけど奇跡的にコロナ落ち着いてる時期で入国できた。オランダでの時差勤務もスンっとこなせてびっくり。ほんとにどこでも働けるじゃん。
あとこの時フリーランスで良かったって思った。会社員だったら「もしコロナになったら会社に迷惑が掛かる」って思考が働いてたと思うんだけど、それが全くなかった。守るものがないってこういうことか。

風車前

10月：Rails チュートリアル完走！

念願の Rails チュートリアルやったことある人になれた 🙌 1人じゃ何度も挫折してたので…ほんとうにみんチャレメンバーのおかげ 😘 ありがとう。

11月・12月：Airbnb 生活始めた

Airbnb の長期滞在割と Goto トラベルの組み合わせで月に6万〜8万で 1K に住める。ちょーお得だし楽しい。だけど仕事ができる広めの机と普通の椅子がある家は少ないので、本当に一時凌ぎだなって感じする。

来月は沖縄 ٩( 'ω' )و と思ってたけど Goto 一時停止になったのでどうなることやら…。
→ （追記 2021/01/04）Goto 割引を宿の人が持ってくれることになり変わらない費用で泊まりに行くことになりました。やっぴ。

技術

CircleCi & Github Actions

やらなきゃ…やらなきゃ…って思ってた技術 No.1。仕事で設定ファイル書かせてもらえる機会があって楽しかった。そして想像より簡単(๑˃̵ᴗ˂̵) 腰が重いだけでしたね。
今年の開発現場は困った時に教えてくれる先輩がいたので、新しいことたくさんできた。おかげさまです。

Docker

これもやらなきゃ…リストに入ってた技術。色んな記事読んでても Docker と docker-compose の違い分かんないし、run とか exec などのコマンドの違い分からないし…現場で支給された Docker 環境、なぜかコンピュータのディスク容量食いまくって 🤬🤬🤬 ってなってたんだけど…「自宅ではじめるDocker入門―人気のコンテナ型「仮想化ソフト」を使ってみる!」を読んでほんとに悩みごとスッキリした。

本の内容が良すぎて、興奮冷めないまま技術書で始めて Amazon レビュー（docker に対するモヤモヤが解消されました！）書いちゃったぐらい ♪( ´▽｀)

結局、今はローカルで Rails 動かす環境は Docker じゃなくても良いかな…という気持ち。でも DB だけは Docker にしようかなって思ってる。まだ MySQL 5.7 の案件ばかりだから大丈夫だけど、今後別のバージョンも入ってきそうだしな。

今年 Docker を有効活用できた仕事は PostgreSQL の環境から MySQL の環境にデータを移行する Script を書く仕事。PostgreSQL 環境を Docker で立てて Script の動作検証できたのは Docker の力量発揮って感じだった◎

Kintone

就職希望先の会社から出された課題に Kintone アプリ作成があって、今年初めてちゃんと Kintone 触った。Kintone は以前にお客様から使用感聞かれることもあったし、松山に住んでた分サイボウズの Kintone イベントにも行ったことあったから前々から触っときたいなぁと思ってて、良きタイミングで課題（請求書作成アプリ作成）がもらえて良かった。

Kintone やっぱすげなぁって思ったのは利用者とプログラマーの開発分岐点が利用者に大きく振られてるとこ。社内システム作ってると「そこはもう自分で直してくれない？」って愚痴りたくなるような要望が多くて、例えば一覧の表示順とかフォームのデフォルト値とか。しかも利用者の皆さんもどれが正解かもちろん分かってないから一発でこの UI で決定ですっ言えるわけでもないし、でもそういう細かい改善が使い勝手を劇的に良くする可能性があることもよく分かるんだけど…開発する側としてはめんどい！って言いたくなりがち。さらに利用者側からもプログラマーにこんな小さい部分の修正お願いしても良いのかな？って躊躇しがち。結果、もう社内の人しか使わないんだし少しぐらい使い勝手悪くても我慢しませんか？になりがち…。

それを素敵に解決してくれるサービスが Kintone で UI とかほんのちょっと使い勝手を良くする改善はプログラミング知らない人でも、少し使い方を伝えれば簡単に覚えられるような GUI になってるから利用者は日々使いながら自分たちでイジって使い勝手を試行錯誤できるし、でも複雑な計算や初期設定の土台部分はきちんとプログラマーが作り込める。これのおかげでお互いのストレスがグッと減ると思う。すごい！

テンプレートメソッドパターン（デザインパターン）

今年は「オブジェクト指向設計実践ガイド」でオブジェクト指向を勉強したり、「増補改訂版Java言語で学ぶデザインパターン入門」でデザインパターンを勉強してるんだけど、仕事のコードで始めて「これテンプレートメソッドパターンでいけるじゃん！」ってなって書けたの。感動した。やっぱり勉強したことが実務で活かせるの楽しいね。

テスト（E2E テストは今年初めて書いたよ）

今年は職場に恵まれててテストの書き方教えてくれる先輩がいたし、E2E テストの環境整えてくれる先輩がいたからテストたくさん書けた。E2E テストはほんとに文字書いてるのにブラウザで画面ポチポチしてる感覚があって面白い。
テストの好きなところは脳内メモリに入ってる頭の中の条件を吐き出せるとこ、ぼんやりしてた仕様がハッキリしてくる感じ、抜け漏れが発見できたりするとこ。あとコードやテストを並行して書きながらどんどんコードがリファクタリングされてく感じも好き。

おわりに

今年はコロナに振り回されたけど、結果オンラインで出来ることが増えたり（気づいたり）、働く場所・住む場所の選択肢がより柔軟になったりと色々視野が広がったなぁという印象。ありがとうコロナ。柔軟な自分ナイス！コロナで仕事なくなるかもって不安で体調崩したり、仕事でストレス抱えてもう毎日泣く😭 みたいな時期もあったけど、おかげで精神面で他人や薬に頼る選択肢に挑戦できたのも良かったかな。

東京への引越しについて。愛媛ライフはすごく好きでもっと住んでたいなぁと思ってたから、いま Airbnb で馴染みゼロの土地で生活してる自分がいまだに実感が持てない。東京ライフを送ってるとあの愛媛ライフはわたしの生み出した妄想？って思うときあるぐらい恋しいな。まぁ 20 代のうちに経験として地方に住むことが出来たのは本当に貴重だったし自分は地方向きだってよーく分かったので、いつかまたどこか地方に住みたいな🍊

今年を一言にまとめると

「長期戦ができるようになってきた年」
昔から飽きっぽいのだけど、今年は意識的に細く長く継続しようって思ったことを続けられるようになってきて、きっと継続するためのコツが掴めてきたんだと思う。継続するにはハードルの低い所から習慣化していったり、友達を巻き込んだりすれば良さそうってことに気づけたことが今年の成果だな。

以上。
Aya chan 来年もがんばってね〜👋

Rails Girls Ehime 2nd で託児を受付けました

勉強会

Rails Girls Japan Advent Calendar 2020 - Qiita 5 日目の記事。
2020 年 2 月に Rails Girls Ehime 2nd を開催し、託児ありにしたのでその記録記事です。

railsgirls-ehime.doorkeeper.jp

前提

  • 地方（愛媛県）での開催
  • 参加者全体で 20 名程
    （Girls: 10 名、コーチ: 5 名、スタッフ: 3 名、その他）
  • 運営メンバー全員、イベントで託児を受け付けるの初めて

Rails Girls で託児を受け付ける理由

以前、別の記事に書いたのでそちらを見て欲しいです。
Rails Girls in Ehime 2nd 開催します - 箱庭のエンジニア

簡単にいうと「やる気とパソコンがあれば誰でも参加できる環境を作りたい」からです。

託児結果を数字で見る

時間

  • 託児受け入れ時間：土曜日 9:00-18:00
    ※ イベントの開催時間は 9:30-17:30
    ※ インストールデイ（金曜日）の託児受付はなし

人数

  • シッター数：　1 名
  • 託児預かり数：1 名（1 歳）

費用

  • シッター利用料：16,200 円
  • イベント保険料：5,000 円
    ※ イベント単位での託児保険はないので、イベント全体に保険をかけました
  • 託児室の利用料：0 円
    ※ イベント会場であるサイボウズさんが個室を貸してくれました
  • 託児に関する雑費：2,004 円
    ※ 救急用品など

悩んだこと・難しかったこと

シッター探し

愛媛はシッターを派遣してくれる会社がないので、個人の繋がりでシッターさんを探す形になりました。ありがたいことにシッターを紹介してくれそうな団体と繋がりのある運営メンバー（non さん）がいて、そこ経由でシッターさんを見つけることが出来ました◎ しかし、non さんがいなければ託児は諦めてたと思うので…振り返ると「シッターを見つけられるか？」が結構大きい関門だったなと思います。

募集の年齢制限をつける

今回の託児募集では預かれる子どもの年齢制限を付けました。

託児可能なお子様は、4 歳以上から小学校低学年までです。（※ 託児の空き状況によっては4歳未満のお子様を預かれる可能性がございますので、事前にお問い合わせ・ご相談ください）

託児は預かる子どもの年齢や人数やに合わせてシッター数を調整する必要があるのですが、今回は先に「シッターは1人」と決めていたので 1人が預かれる託児数に調整する必要がありました。そのため 4 歳未満の子どもの場合は全て事前に相談してもらって、現在の託児申し込み状況から預かり OK / NG を決める形を取りました。

土曜日のみ託児を実施

Rails Grils Ehime は 1 日半（金曜日の夜、土曜の終日）のイベントなのですが、託児は土曜日だけ実施しました。最初は両日実施する予定だったのですが、Rails Girls Japan の @emorima さんに相談したところ「夜は子どもが眠くなっちゃうので金曜日に預けるのは大変かも？」と言ってもらい「確かに〜」となったからです。

土曜日だけの託児になったため、託児希望の Girls には金曜日の対応を申し込みフォームで確認しました。

f:id:meikotan:20201130122218p:plain

今回、託児を利用した Girl の方は金曜日欠席されましたが、もともと別の言語のプログラミング経験があった方だったので問題なさそうでした。

シッター利用料の給与補償

事前に託児予約はあったけど、子どもの体調不良などで当日の託児がゼロになってしまった場合のシッター利用料をどうするか迷いました。

今回はシッターさんと個人契約だったので、特に決められた規則もなく・・。結局、開催１ヶ月前にそのような場合でもシッター利用料は変わらず全額お支払いすることに決めました。理由は私がシッターさんだったら給料補償して欲しいなぁ・・と思ったからです。

結果、予約のあった子は元気に参加されたので託児ゼロの事態にはならなかったのですが、イベント当日、シッターさんに他のイベントでの給料補償について聞いてみたところ

「当日まで預ける人がいるか分からないけどイベント会場で待機してて欲しい」みたいな依頼もあって、当日預ける人がいなければ給料なしになる場合もある

と仰ってて、そうなのか〜という気持ちになりました。

次回 Rails Girls で託児を受け付けるなら？

個人的には参加者 20名ぐらいの規模感ならイベント会場に託児室を設けるより、外部の託児室利用料を Rails Girls で補助する形でも良かったのかもなぁと思いました。イベント会場に託児室を設けるための準備は初めてだったこともありますが、利用者の割に負荷が大きかったように感じます。

「イベント会場に託児室があった方がいいか？利用料を補助してもらえるなら、外部の託児室に預ける形でもいいか？」今回、託児を利用頂いた Girl の方に聞いてみると「イベント会場に託児室があった方が近くに子どもがいるので安心」だと仰っていました。また、当日は Girl の方以外の大人のご家族 2 名も一緒に会場に来られたので、そういうパターンを考えると会場に託児室があった方が良いのかな〜とも感じます。

そのため次回 Rails Girls で託児を受け付けるなら、イベント会場に託児室を設置するメリットをもう少し考えてみたいです。

Rails Girls の運営を通して感じたこと

正直、Rails Girls の運営をするまで子どもがいるエンジニアが勉強会にどうやって参加するのか？勉強会に託児室が必要か？考えこともなかったので、気付きの多い運営だったなぁと感じます。そして私の中で「勉強会に託児はない」という無意識の当たり前を一度壊せたので、これから意識的に託児をする / しないを思考ができる気がします…！また、これからも可能な範囲で常識を広げる努力をしていきたいなぁと感じました。

終わりに

この記事はアドベントカレンダー用にしようと思ってたので、Rails Girls 終わってすぐに 8 割ぐらい書いて寝かしておいたのですが…今清書しても当時とテンションが違いすぎて書きづらかったです…🤦‍♀️ 鉄は熱いうちに打て！ですね。。
まぁとりあえず Rails Girls を2回も運営・開催できて幸せでした。そしてコロナになった今、世の中はオンラインイベントばっかりで…このブログを書いてたらオフライン恋しい〜ってなってます。早くオフラインも普通に開催できる世界に戻らないかなぁ。。

f:id:meikotan:20201205073440j:plain
Rails Girls Ehime 2nd 集合写真
しいのあや on Twitter: "全員 Rails App を世界に公開できてよかった！！☺素晴らしい️👏 #rg_ehime #railsgirls #rubyfriends #fridayhug… "

謝辞

今回 Rails Girls Ehime 2nd に託児室が設置できたのも運営メンバー、Rails Girls Japan、また事前にブログ等を書いてくれた方々のおかげです。感謝！
安定の参考記事、ありがとうございました！

輪読会楽しいよ

勉強会

去年から技術書を複数人で読む輪読会にハマってるのでそれの紹介。

どんな感じで読んでるの？

書籍の内容を参加メンバーで順番に声に出して読んでます。疲れたら交代お願いしますといって変わってもらいます。また、読んでる途中に理解できない一文が出てくれば同じ一文を復唱しても良いし、「これってこう言う意味かな？」と輪読メンバーに聞いても OK。読み終わることより理解に重きを置いてる節あります。

輪読会のオススメ構成

人数

２〜３人ぐらいです。
多すぎるとみんなのペースに合わせる必要があるので、納得しないまま進んじゃって不完全燃焼になりやすい気がする。

日時

週１、１回２時間ぐらい。１時間だとあっという間、３時間だと集中力がもたない。

輪読会はどんな人に向いてる？

  • 技術書を積読気味な人
  • 人と話すのが好きな人
  • 人と話した方が理解が深まりやすい人

今年読んだ本（途中含む）

  1. オブジェクト指向設計実践ガイド
    at オブジェクト指向設計実践ガイド輪読会 #1 - connpass
  2. Java言語で学ぶデザインパターン入門
    with かとりえさん
  3. Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) | Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ, 角 征典, 高木 正弘 | 工学 | Kindleストア | Amazon
    with ほくりんさん、ちろひさん

f:id:meikotan:20201125221413j:plain

良いところ

  • 予習の必要がない
  • 分からないところを言葉にしながら読むので理解が深まる
  • 疑問点をその場で聞ける
  • 人と一緒にやると続く
  • 輪読メンバーの考え方や会社の話が聞けて面白い
  • 脱線して雑談できるの楽しい🥰たまに全部雑談になる😂

辛いところ

  • 一冊読み終わるのに時間がかかる

こんな本が輪読会にオススメだと思う

  • 理解が難しいもの（抽象的なものや設計思想的なもの）
  • チームビルディング的なもの
  • 1人だと挫折しそうなもの

来年読みたい本

誰か読みたい人いれば一緒に読みましょうー。

  1. 新装版 達人プログラマー 職人から名匠への道 | Andrew Hunt, David Thomas, 村上雅章 |本 | 通販 | Amazon
  2. レガシーコード改善ガイド (Object Oriented SELECTION) | マイケル・C・フェザーズ, ウルシステムズ株式会社, ウルシステムズ株式会社, 平澤 章, 越智 典子, 稲葉 信之, 田村 友彦, 小堀 真義 |本 | 通販 | Amazon
  3. Ruby on Rails ガイド：体系的に Rails を学ぼう
  4. 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 | 増田 亨 |本 | 通販 | Amazon

終わりに

これは女子部アドベントカレンダー２日目の記事です👋
TECHPLAY女子部 Advent Calendar 2020 - Adventar