基礎から学ぶ Vue.js - CHAPTER 3 -

Vue.js early_sleeping

朝活友達がブログで勉強のアウトプットをしていると聞いて、私もやってみるかという気持ちになったので書きます。

今は Vue.js を勉強中で、以下のサイトのサンプルコードをとりあえず全て実装してみて、気になったことを少し調べる勉強スタイルを実践中です。
CHAPTER 3 | 基礎から学ぶ Vue.js

以下は私が書きたくなったことしか書いてないです。

フォーム入力の取得 - 🔗基礎から学ぶ Vue.js

f:id:meikotan:20200316100025p:plain
フォーム入力の取得

入力値に制約を追加したい時に便利そうだなぁと思いました。

  • 住所を全角にしたい
  • メールアドレスを小文字にしたい

など。

「入力値を大文字にする」をやってみた 😄👏

f:id:meikotan:20200316100503g:plain

handleInput: function (event) {
  // 代入前に何か処理を行う…
  this.message = event.target.value.toUpperCase()
}

イベント修飾子 - 🔗基礎から学ぶ Vue.js

f:id:meikotan:20200316102323p:plain
イベント修飾子を使って呼び出すメソッド

.stop

f:id:meikotan:20200316102844p:plain

正直どこで使うんだろう？という気持ちです。
公式サイトの説明をみても <!-- クリックイベントの伝搬が止まります --> と書かれていてよく分からない・・。

別の記事（Vue.jsイベント修飾子.stopと.preventの使いどころ）でサンプルを眺めてたら、以下のことが分かりました。

  • .stop は JavaScript の stopPropagation を呼び出すこと
  • 例えば、ボタンを構成する要素が入れ子（<div><button></button></div>）になっていて、かつ親要素（<div>）・子要素（<button>）ともにクリックイベントが存在する時、通常はボタンをクリックすると <div> 、<button> 両方のイベントが発動する。子要素（<button>）のイベントだけ発動させたい場合、<button> に .stop を追加する。

以下の場合、button タグに click.stop をすることで、childClick だけ実行させることができます。

<div class="father" @click="fatherClick">
  <button class="child" @click.stop="childClick">呼び鈴</button>
</div>

Vue.jsイベント修飾子.stopと.preventの使いどころ のサンプルから抜粋しています。

具体的な使い所は？

ただ、仕組みは分かっても、具体的にどこで使うんだろう？はピンとこなかったので、今度は stopPropagation の使い所を調べました。

以下の記事では、モーダル画面の非表示処理において、「閉じる」ボタンではなく、モーダルの外側（背景）をクリックしても「非表示にする」という部分で stopPropagation が使われていると書かれていました。
www.tam-tam.co.jp

  • モーダルの外側（背景）をクリックして「非表示にする」という機能を追加すると、モーダルの内側の背景をクリックしてもモダールが非表示になってしまう不具合が発生する
  • モーダルの内側（子要素）がクリックされたときは、stopPropagation を使って親要素への伝搬を止める処理を追加し、非表示にならないようにする

というものでした。なるほど！
私自身

  • モーダルの背景クリックで閉じる機能の実装をしたことない
  • モーダルの背景クリックで閉じる機能の実装を考えたこともない
  • 今やモーダルの実装は bootstrap や JqueryUI などのライブラリに全お任せ状態だった

ので、知れてよかったなぁと思います。

ブログを書いてみての所感

書くのは楽しいし、頭整理されていいけど・・全然勉強進まない。。

今日のところで、よく分からないところ

Vue.js の公式ドキュメントに書かれていた、#なぜ HTML にリスナを記述するのですか が、書かれてる内容、そもそも論的なところも分からない・・今度聞いてみよう。

（追記）20200327：よく分からないところが少し分かった

なぜ HTML にリスナを記述するのですか これまで説明してきたようなイベント監視のアプローチは、”関心の分離”という古き良きルールを破っているのではないか、と心配されるかもしれません。安心してください。すべての Vue ハンドラ関数と式は、現在の View を扱う ViewModel に厳密に閉じています。それによってメンテナンスが難しくなることはありません。実際、v-on を利用することでいくつかの利点があります。

この利点の書かれてる内容が分からなかったのですが、お陰様で 1 つ分かるようになりました。

HTML テンプレートを眺めることで、JS コード内のハンドラ関数を探すことを容易にします

ハンドラ関数とは？→ ボタンをクリックする、フォームを submit するなどのイベント時に実行される関数のこと。jquery の場合、JavaScript のコード上に id や class を使って HTML タグを指定（$('#test_id')）してたので、JavaScript の処理を追わないとその HTML タグにハンドラ関数が紐づいてるか分からなかった。だけど Vue.js は v-on でハンドラ関数を紐付けるので、どの要素に関数が紐づいてるのか View から確認できるので分かりやすくなった！

TDD Boot Camp in 愛媛 に参加しました！

勉強会

TDD Boot Camp in 愛媛 #1 - connpass

TDDBC（ 2 / 15 sat ） から 2 週間経ちましたが、いまだ興奮冷めない感じで日々の開発に活かせること満載な勉強会でした！改めてここで振り返りをします。

www.instagram.com

前提

講演（ラブコーディング付き）

ここでは私的感動ポイントをつらつら書いていきます。

きちんとした説明は実際の TDD Boot Camp に行くか、動画（50 分でわかるテスト駆動開発）もあるみたいなので、そちらを見てください。

動作するきれいなコード - どうたどり着くか

動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ

TDD は「動作するきれいなコード」を目指すための手段なのですが、この記事ではもう少し大きな概念の話で、「動作するきれいなコード」への道のりや、目的達成を阻む人類の性質にどう対応してきたか？今後どうしたらいいのか？など、とても面白かったです。

気になったことメモ

  • 三脚椅子のメタファーの話🤣
  • リファクタリングの付箋は剥がされない😂
  • 単一作業に集中できる黄金の回転
  • リファクタリングは弱いので、独立タスクにしない
  • Unit テストと E2E テストのフィードバックの違い

「使いやすい」コードのためのテストファースト

もともと TDD という言葉は知っていましたが、「テストを先に書く」が私の頭の中で一人歩きしており・・なぜ、テストを先に？後に書いても同じじゃない？とモヤモヤしてた疑問が一気に解消されるお話でした。

「使いやすい」コードを目指す

  • テストを先に書くことで、そのプログラムを使う側（読む側）の視点からテストが書ける
  • 先にプロダクトコードを作ってしまうと、使う側（読む側）の視点を見えなくなる
  • 作りやすいコードと、使いやすい（読みやすい）コードは違う。そして、使いやすい（読みやすい）コードを目指すべき

なるほど！🤩

「恐怖に支配された世界」から脱出するためのテスト

昔は「動いてるコードに手を付けるな」と言われてましたが、今は周りの環境（動作環境やライブラリなど）がどんどんアップデートされていくため、例え「塩漬け（手を付けない）」していても動かなくなる場合がある。

そのため、テストコードを書くことで

  • 安心して既存コードに手が付けられる
  • 常にこのコードは正しく動くのか？が判断できる

ようになり、安心を得ることができる。

以前、テストコードを書いていなかった時は、新しくコードを書いた部分のリリースでさえ恐怖を感じていました。そしてテストコードを書くようになった今でも、自分の書いたコードにバグがあったらどうしよう・・😨という恐怖がゼロになることは有りませんが、圧倒的に少なくなったなぁと思いますし、バグが出た時でも再発防止の修正が気軽になったなぁと思います。

テスト実装の優先順位

テストの優先度を決めるための軸は２つ。

  1. テストが書きやすいか？
  2. 重要度が高いか？

そして、最初は「1 番テストが書きやすい」Todo から倒す（テストを書く）と良い。
※ テストを書くこと自体に不慣れ・不安な場合の挫折予防です。

Todo はテストを書きやすい形にする

講演のお題は定番の「FizzBuzz」問題でした。

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに｢Fizz｣と、5の倍数のときは｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣とプリントすること。

参考）どうしてプログラマに・・・プログラムが書けないのか?

最初の Todo の作り方

Todo は上記に書いた FizzBuzz の問題文を元に、以下の作業を行います。

  • 問題文をタスク（Todo）に分割する
  • Todo 全体で表現、語尾などを揃える

Todo がどんどんブラッシュアップされてく感じはライブコーディングがとても分かりやすかったです！😍すごい！
この段階で全体を眺め、表現方法を合わせたり、粒度を揃えたりできるの良い！

テストを書きやすくする（テスト容易性をあげる）

例えば、以下の Todo があった場合

  1. 数が 3 の倍数のときは｢Fizz｣とプリントする

「プリントする」というのはテストが書きにくいのに、重要度が低い（そのテストができても嬉しくない）ので、以下のようにテストを分割する。

  1. 数が 3 の倍数のときは「Fizz」に変換する
  2. プリントする

そうすると、 (1) はテストし易くなり、(2) はテストが書きにくく、重要度が低い Todo として優先度を下げることができる。

テストは日本語（母語）で書いたほうが良い

テストコードは「動く仕様書」の要素が今後さらに強くなってくるので、母語で書いた方が良い。

テストはゴール（検証）から作る

テストで書くもの

  1. 前準備
  2. 実行
  3. 検証（ゴール）

テストはゴール（検証）から書こう！
なぜなら、複雑なテストの場合、前準備が数十行になってしまうと

  • ゴール（検証）が分からなくなる
  • ゴール（検証）を複数用意したくなる（頑張って作った前準備を有効活用したい欲）

という罠にハマってしまう可能性大！

（テストアンチパターン）1 つのテストに多数の検証

1 つのテストに多数（検証が縦にいっぱい並ぶ）の検証を書いた場合、途中の検証が失敗するとそこでテストが止まるので、1 度のテストでどれが失敗するのか？判断できない。また、どの検証が失敗しているのか分かりづらいので、アンチパターンです。

これは「ただ乗り（The Free Ride / Piggyback）」と呼ばれるようです。
参考）TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary

Rspec だと 1 テスト 1 検証が一般的になっている気がしてて、私がテストを書き始めた頃、ネット上の記事を参考にしてたのですが、ほとんどの記事が 1 テスト 1 検証（1 expect to）だったような気がします。gem RuboCop RSpec を入れるとデフォルトで 1 テスト 1 検証しか書けなくなりますし。
参考）RuboCop::Cop::RSpec::MultipleExpectations

ただ、1 テスト 1 検証だからといって、以下のように事前データを配列 or Hash を使ってまとめて書かれると、失敗したときに何個目で落ちたの？？になりやすく、辛い思いをすることが多いです。せめて it にループした時の具体値を埋め込むなど、別の人でも検証しやすいテストコードが作れるよう気を付けたいです。

[true, false, true].each do |boolean|
　it "状況に応じた結果が返されること" do
　　expect(boolean).to eq true
　end
end

また、テストパターンによっては 2 つの検証が成功しないと意味がないものもあるので、それを 1 つのテストにまとめるべきか否かはメンバーと要相談かもです。

残酷な瞬間との早期出会い（抽象から具体）

「いざ書き始めようとすると指が動かない」という残酷な瞬間に早めに出会える。

例えば、以下の Todo

  • 数を文字列に変換する

だと、期待値は何にしたらいいのか？テストで何を検証したらいいのか？🤔になるので、以下のように具体値を使った Todo を追加する。

  • 数を文字列に変換する
    • 1 を渡すと文字列 1 に変換する

実際、プロダクトコードを書いてても、頭の中では書けそうなのに指が動かない・・みたいなことあります・・😂 自分の深掘りが甘ければ、遅かれ早かれ残酷な瞬間に出会うことになるので、テストを通して「そのタイミングを早める」という考え方が素敵です。

テストコードのテスト

「テストコード自体にバグがあったらどうするの？」という問いは確かに・・と思いました。結局、テストも人が書いてますからね・・。前職ではテストを目視でやっていたのですが、テストをする人がミスしても品質が担保できるよう、ダブルチェッカー体制にしてたこともありましたが・・じゃぁ 2 人とも間違えたら・・？とか、考え始めたらキリがないですね。。

テストの書き始めにテストコードをテストする

これは「テストコードのテスト」を最小限コストに抑えるためです。

テストコードのテスト方法

  • 最短で Green にする
    • テストの期待値とプロダクトコードの返り値に同じ具体値を入れて Green にする
      • テストで expect "1"、プロダクトコードで return "1" にする
  • テストコードのテストをする
    • 意図的に判別可能なバグを入れて Red にする（欠陥挿入）
      • テストで expect "1"、プロダクトコードで return "2" にする

例え Red であっても期待通りに動いていれば成功なのです！でもこの「テストコードのテスト」は、慣れてくると飛ばしがちです・・。

テストの実行順はランダムにする

ライブコーディングでは Java を使っており、 Java のテストツール（JUnit）はデフォルトで実行順序をランダムにしてくれるそうです。知らなかった！

ランダムにすることのメリット

  • 各テストの依存関係がなくなる（A のテストを実行しないと B は成功するか分からない、などがなくなる）
  • 依存関係をなくすことで、テスト完了スピードが遅くなった時に並列実行に移行できる

Rspec の場合

デフォルトでランダムになっているだろうと予測してたのですが、設定ファイル（spec_helper.rb）に明示する必要がありました。私の環境では、Rspec を設置した時に自動生成した設定ファイルの実行順序指定（config.order = :random）はコメントアウトされており、これまで定義順でテストしていたことが判明しました🙄

spec_helper.rb

# Run specs in random order to surface order dependencies. If you find an
# order dependency and want to debug it, you can fix the order by providing
# the seed, which is printed after each run.
#     --seed 1234
config.order = :random

設定ファイルの実行順序を指定しない場合、rspec コマンドのデフォルトである defined（定義順）が反映されるようです。
参考）`--order` option - Command line - RSpec Core - RSpec - Relish

また、実行順序に依存したい場合、seed 番号（Kernel.srand config.seed）を使ったり、テストケースごとに順序指定したりできるみたいです。

不安があるなら歩幅を小さくする

テストコードの実装に対する不安を和らげるため、自信を付けるために細かいステップを踏む（歩幅を調整する）ことが可能です。細かいステップは「不安を埋めること」が目的なので、石橋は叩いても良いし、叩かなくても良いのです。そのため、以下の手順は任意です。

  • 仮実装（return "1" とかの固定値で返す実装のこと）
  • 三角測量（複数の道を試すこと、1 の場合、2 の場合など）

3 年後の誰か（自分を含む）のためにテストを書く

無駄なテストコードを消せるのは今の自分だけ

例えば、テストコードに不慣れで、歩幅を小さくしようと以下のように複数の値をテストした場合

  • 1 を渡すと文字列 1 に変換する
  • 2 を渡すと文字列 2 に変換する

今の自分にとっては安心に繋がる大切なステップでしたが、テスト全体としては「1」のテストが通れば「2」のテストを行う必要がないため、無駄なテストといえます。そして、これが無駄だと明確に判断できるのは今の自分だけです。

このテストをもし 3 年後の誰かが見た際、「この人はテストを書くことに不慣れだったらか、2 つの値を検証しているのだろう」なんて思わず、むしろ「あえて 2 つ書いてるのは意味があるのだろう。1 と 2 で挙動が変わるのかなぁ。まぁないよりあった方がいいし、プロダクトコード確認するの面倒だし、とりあえず置いておこう」と思うのがほとんどで、永遠に無駄なテストが残り続けます👹

無駄なテストを永続させないために、毎日 or 毎週など定期的に（記憶があるうちに）テストコードを整理しましょう！不慣れな自分に自信を与えてくれたテスト達を消せるのは、今の自分だけなのです！

また、3 年後の誰かは「未来の自分」の可能性も高く、過去のコードを見て「コレなんだろう・・？😕意味わからん」って思ったら自分だった😇パターンは悲しいですし（あるあるですが・・）、他人だったら迷惑かけても良いって訳でもないので、不要なテストをチェックする習慣は付けていきたいです。

足りないテストコードを追加できるのも今の自分だけ

上と同じ話ですが、もし FizzBuzz 問題のテストを書いている時、他の作業が忙しくなってしまった場合。「(1), (2) だけはちゃんとテストを書いた、(3) は目視で確認して動いてたっぽいし、残りは後でやろう〜」とか考えて放置したテストコードを 3 年後の誰かが見た時、どう思うでしょうか？

  1. [x] 数が 3 の倍数のときは「Fizz」に変換する
  2. [x] 数が 5 の倍数のときは「Buzz」に変換する
  3. [ ] 数が 3 と 5 の倍数のときは「FizzBuzz」に変換する

「(3) はテストが書き辛かったのかな？重要じゃないからテストしてないのかな？🤔まぁどちらにせよ、無理してテストを追加する必要はないか。変に追加して失敗しても面倒だし」になり、永遠にテストが足りない状態 & 機能追加・修正がやり辛い状態になります💀

仕様がテストコードだけで分かる状態が理想

せっかくテストが書かれていても、3 年後にプロダクトコードを確認しないと実装を理解できない状態は勿体ないです。

テストの粒度は誰がテストするのか？で変わる

「実装を知ってる人が書くテスト」と「実装を知らない人が書くテスト」は異なる（ベストプラクティスが違う）。実装を知らない人は品質保証を求める場合が多く、テストが手厚くなりがち。そして、品質保証を重視するテストにするか？はプロジェクトごとに選択できる。

意味のある数値でテストしてますか？

例えば、FizzBuzz 問題で

  • 数が 3 の倍数のときは「Fizz」に変換する

をテストする時、2 つぐらいの具体値でテストしておけば品質高まるかなぁと考え、具体値を 2 つ用意する。

  • 数が 3 の倍数のときは「Fizz」に変換する
    • 数が 3 のときは「Fizz」に変換する
    • 数が 6 のときは「Fizz」に変換する

そして、品質保証の方から「なぜ 3, 6 を選んだの？」と聞かれ、「なんとなくです・・」となりがち。とりあえず 2 つ選べばいいと思ってしまった、自分の浅さにに気づく。

意味のある数値の 1 つとして境界値という提案。境界値は要件に書いてあることが多い。FizzBuzz の場合、「1から100までの数をプリントするプログラムを書け。」なので、99 を選ぶと良さそう。

ペアプログラミング

私のペアは Rails で自社サービスを作成している K2iwai さんで、Ruby + Rspec で TDD ペアプロをしました。

（良かった）ペアで知識の基礎レベルが同じだった

お互い

だったので、例えば以下のような前提が当たり前になるので、そもそも論で情報格差がなく、とてもペアプロしやすかったです。

  • 一般的にファイル名・メソッド名はスネークケース、クラス名は頭大文字を使う
  • クラスの初期化処理は initialize メソッドを使う
  • getter, setter は attr_accessorを使う（メソッドの綴りは調べないと書けなかったけど）
  • 真偽値判定のメソッドは ? を使う
  • メソッドの最後の式を返り値にする場合は return を省略できる
  • Rpsec は describe, context, it を使う
  • テストファイルは接尾語に _spec を付ける

（気付き）お互いの拘りをシェアするのが楽しい

お互い仕事でプログラムを書いてる分、仕様書やコードへの拘りが少しずつあり、それをシェアし調整しながら実装するのはとても勉強になりました。また、自分が何に拘ってるのか？なぜ拘ってるのか？や、逆にそこまで拘ってない部分などが見えて面白かったです。

（私の拘り）Todo やテストを仕様書にしたい

私は実装より日本語の表現に拘っていることが判明しました。

最初は以下のように Todo を作ってたのですが

  • 閉区間クラスを初期化する
  • 閉区間クラスは下端点と上端点のプロパティを持つ

クラスとかプロパティって仕様書らしくない！と考え

  • 整数閉区間を作成する
  • 整数閉区間は下端点と上端点を持つ

に変更しました。

私の中で「仕様書らしい」というのは「プログラマー以外の人が読んでも理解できる」だと考えます。

（K2iwai さんの拘り）メソッド名は短い方が良い

例えば、お題の閉区間を表すのに ClosedSection を提案した時、「短くしたい！」と言われ Range を検討しました（結局、Ruby の組込みクラスだったため断念し、ClosedSection に落ち着きました）。私はメソッド名の長さをほとんど気にしておらず、むしろ分かりやすくなるなら、ある程度長くても良いと思ってる派です。kkd さんに「今は editor 補完が可能なので長さを気にする人は少なくなった」と教えて頂きました。

（K2iwai さんの拘り）引数のクラスが異なる場合メソッドを変えたい

今回のお題で「閉区間に含まれる」を表現する時

  1. 閉区間に数値が含まれるか？
  2. 閉区間に別の閉区間が含まれるか？

という、2 つのパターンが存在しました。個人的には 1 つのメソッドを使いメソッド内で実装を分ければ・・？と思ったのですが、K2iwai さんは別のメソッドが良いと言っていたので分けることにしました。
ただ、メソッドを分けた場合、以下のようになるのが嫌だったので、新しい単語を考えました。

  • include_number?
  • include_closed_section?

結果、(1) を between? 、(2) を include? にしたのですが、コードレビューで (1) の between? は意味が逆じゃない？と指摘され確かに・・となり、kkd さんから Ruby の組込みクラスである Range を参考に members? や cover? はどうか？と提案いただき、それいい！🤩となりました。改めて Ruby の命名の素晴らしさを感じました。

（気付き）役割分担が自然とできた

最後の方は私が Todo の修正やテストコードを作り、 K2iwai さんが実装する、的な流れができてるように感じました。

そのため、私がテストコードを書いたら K2iwai さんにお願い！ってパスしたり、私が例外発生の書き方で迷ってたら「ちょっと貸して」とドライバーを奪われたり、多分、最初に t-wada さんが話してた「良いペアプロ」ができたんじゃないかなぁと思います。

また、程々に性格が似てた（ざっくりな感じとか）ので、小さいことで褒め合ったり、ちょっと実装してすぐ休憩したり（笑）で楽しかったです。

次回、K2iwai さんとペアプロする時は、あえてプロダクトコードを私が、テストコードを K2iwai さんが、というように書ける場所を制限するのも面白そうだなぁと思いました。

（気付き）t-wada さんの説明通りの手順を踏んでた

最初はテストコードだけでなく、ペアプロ自体にも不安（慣れない感）が合ったので、割と歩幅を小さくしながら（仮実装、三角測量を織り交ぜながら）実装しました。しかし、後半はテストコードの書き方、ペアプロの感じも分かってきたので、歩みを刻まず、いきなり「テスト → 実装」に自然となっていました。また、後からテストコードの一覧を見返した際に「無駄」を発見し整理する作業（消す・文言を調整するなど）もしたので、「わ！t-wada さんの言ってた通りになってる！」と思いました。

コードレビュー

前でレビューしてもらいました！

コードレビュー後の差分です。
コードレビュー後 · dobby618/tddbc-ehime-1st@c97541e · GitHub
※ 問題等も上げているので、もし TDDBC にこれから参加するよ！という方は、当日楽しむために見ない方がいいかもです。

TDD 後に行動が変わったこと

テスト一覧を確認するようになった

$ rspec -f d --dry-run --order defined

参考）RSpecで作ったexampleの一覧をテストの実行なしに出力する - Qiita

一覧を眺めながら

  • この一覧だけでやりたいことが伝わるか？
  • 仕様書らしい表現を使っているか？
  • 表現が揃っているか？
  • 階層が揃っているか？
  • 無駄なテストはないか？
  • 足りないテストはないか？

などを確認するようになりました。
これまでテストを書いたら終わり！だったのですが、一覧を確認するようになり俯瞰する視点が身に付いたように感じます。

第三者に伝わる言葉を考えるようになった

例えば、会員登録で以下の 2 つ画面に別れるようなパターンで

  • ユーザ情報（名前など）の登録画面
  • 趣味の登録画面

「ユーザ情報」の登録済み判定を「氏名」の登録有無で判断していた場合

context '氏名を登録している場合' do
　it '趣味の登録画面に遷移する' do
　　expect(response).to redirect_to xxxxx_url
　end
end

と書いており、ロジック的にはその通りなんだけど、そもそも「氏名を登録してる場合」ってなんだよ！と思うようになり

context 'ユーザ情報を登録している場合' do
　it '趣味の登録画面に遷移する' do
　　expect(response).to redirect_to xxxxx_url
　end
end

に直しました。

他に、投稿記事の公開日を登録するメソッドのテストで

it `published_at に日付が登録されていること`

と書いてたのですが

it '公開日が登録されていること'

とかの方がいいのかなぁ〜🤔など、考えるようになりました。正解は案件ごとにあると思いますが、この表現って伝わる？という視点が加わったことは、個人的にとても有益だなぁと感じます。

ただ、「完璧主義」が出てくると細かい所がずっと気になり・・めっちゃ時間過ぎてる！ということもあったので、少しずつ調整していきたいなぁと思いました。

使いやすさを意識するようになった

TDD の復習として、以前参加した Coderetreat のお題である「ライフゲーム」を TDD で実装しました。

GitHub - dobby618/life_game
※ 記事公開の 2/27 時点でまだライフゲームの実装は途中です。3 月中に終わらせたい。

ライフゲームでは Cell クラスに「生・死」のステータスを持たせており、「生・死」の判定に cell.status を使っていたのですが

class Cell
　attr_accessor :status
　
　def initialize(status:)
　　@status = status
　end
end

cell = Cell.new(status: true) # 「生」のステータスを持つセル
if cell.status
　# 「生」のステータスを持つセル
else
　# 「死」のステータスを持つセル
end

TDD で「どんな風に使いたい？」と先に考えることで、「生・死」の判定は ? メソッド使いたいなぁと思い修正しました。

class Cell　
　def initialize(alive:)
　　@alive = alive
　end

　def alive?
　　@alive
　end

　def dead?
　　!@alive
　end
end

cell = Cell.new(alive: true) # 「生」のステータスを持つセル
if cell.alive?
　# 「生」のステータスを持つセル
else
　# 「死」のステータスを持つセル
end

最後に

個人的に

  • 作りやすやよりも、使いやすさ
  • 無駄なテストコードは自分しか消せない

という言葉は大変刺激になりました！

また、t-wada さんの最後の話で TDD を生み出した方でさえ「テスト書きたくない・・」と思うことがあるそうで、そんな時グリーンバンドに刻まれた「acts_as_professional」を見て奮い立たせている！という話を聞いて、私も見える位置に飾ることにしました。

t-wada さんのメッセージ入りです！ Run with Tests！

f:id:meikotan:20200226205403j:plain:w150
グリーンバンド

TDDBC に参加したことで、たくさんの新しい視点を得れたことがとても嬉しいです。出来るところから実務に活かし、日々「動作するきれいなコード」を目指します！

また、agile459 の勉強会はいつも業務に直結するものが多く、学びが多いです。開催ありがとうございました！そして、いつも togetter してくれる HAL さん！ありがたいです。私は勉強会に参加しながらの Tweet が苦手なので、皆さんの実況を振り返りに使っています🙏✨
【自分用まとめ】TDD Boot Camp in 愛媛 #1 #tddbc #Agile459 - Togetter

個人レベルでのリモートワーク（テレワーク）について 〜歴 2 年の振り返り〜

振返り

新型コロナウイルスの影響でリモートワークの話題が盛んだし、みんチャレ友達から今のタイミングで記事書いたら良さそうと言われたので、リモートワーク歴 2 年の振り返りもかねて、リモートワークについて書きます。
ただ私はフリーランスのリモートワークなので、チームレベルのリモートワークの知見というより、個人レベルでの話になります。そして、ツールの紹介というよりは人間スキル的な話がメインです。

また結論として、下に書いてある人間スキルは「リモートワークだから必要」というより、オフィス勤務だろうとあった方が良いと思うものばかりになりました。しかし、リモートワークはノンバーバル情報がグッと減るので、これらの必要性が増すのだと思います。

↓ 長いので面白そうなタイトルをつまみ食いするぐらいがちょうど良いです。

前提

リモートワークが楽しくなるまでの道のり

今となってはリモートワーク楽しい！と胸を張って言えますが、正直楽しくなってきたのは最近です。以下は私が 2 年間で追ったリモートワークでの気分の浮き沈みです。

  1. 誰にも邪魔されない！ヤッホーい！めっちゃ集中できる
  2. 寂しい
  3. 生活が荒む・グダグダ・辛い
  4. 反省・改善
  5. 「生活が荒む・グダグダ・辛い」→「反省・改善」を 5 回ぐらい繰り返してくうちに、少しずつ「リモートワークスキル」がついてきた！
  6. リモートワーク楽しい（これを実感するのに 1 年半 〜 2 年ぐらいかかりました）

って感じだったので、最初の 2 ヶ月ぐらいでリモートワーク余裕だわ！って判断するのは、少し早いかもです。慣れてきてからが真のリモートワークです。

絶対必要なスキル

テキストコミュニケーションスキル（チャットスキル）

口頭でコミュニケーションを取る場合、フワッと伝えても相手がいい感じに解釈してくれることが多いと思いますが、テキストコミュニケーションになるとフワッとじゃ伝わらなかったり、前提条件を確認するだけの無駄な往復が発生するダラダラ会話になってしまうこともあるので、このスキルは必須です。
会社によっては、リモートワークでも口頭でコミュニケーションを取りやすくするために、音声会話ツールを繋ぎっぱなしにするなどの手段を取っている場合もありますが、リモートになることでオフィスにいた頃よりはテキストコミュニケーション量は増えると思うので、苦手だ・・辛い・・で完結せず、言語化することを諦めない姿勢は持っていた方がいいと思います。

テキストコミュニケーションだけで

  • 細かい仕様の確認
  • 議論・提案
  • 悩み相談
  • 雑談

ができるようになるとリモートワークがグッと働きやすくなると思います。

また、今振り返るとオフィスだった時は口頭で話したことを別の人にシェアするために、口頭の内容をテキストに起こす作業が多かったように感じます。しかも、それは結構面倒な作業なのでサボっちゃうこともあれば、テキストにしてる間に確認漏れが見つかって、何度も先輩に聞いちゃう・・みたいなこともありました😅 しかし、テキストコミュニケーションだと会話がそのまま議事録になるので、他者への共有のための作業が減ったように感じます。

もともと得意だったんじゃない？

NO です。もともと私はテキストコミュニケーションが大の苦手でした。
昔からオンラインゲームしてる人や Twitter バンバン投稿する人とかだと、チャットに抵抗ない人が多いと思うけど、私はそういうのやってこなかったので、最初はチャットで毎回メールみたいに「お疲れ様です」を付けないと失礼かも？😨って思ったり、「どういうことですか？」という質問文を見ただけで怒られたと感じてしまったり、チャットを追いすぎで開発が全然進まなかったりしてました。また、テキストコミュニケーションじゃ伝えられないから、聞くのを我慢しよう。来週会った時にまとめて聞こう。と考えてしまい、どんどん後回しにしちゃう癖もありました。すぐ電話したくなっちゃったりとかね。

なので、テキストコミュニケーションスキルが向上するまで、そしてテキストコミュニケーション環境に慣れるまでは結構辛かったです。

自分の機嫌を取るスキル

人間なので調子の良い時と悪い時、仕事が乗ってる時と乗ってない時など、浮き沈みがあると思いますが、皆さんは自分を意図的に調子の良い状態に持っていくことは可能ですか？また、調子の良い状態に持っていくために、どのような「前提条件」が必要ですか？

オフィスにいた頃はある程度人の目があるので、注意散漫な日でも仕事してる感は出せてたと思うのですが、リモートワークだと調子が悪い時は本当に集中できないし、眠くなるとその欲求に耐えられず布団に潜り込んでしまいがちです・・。ただ、その後の自己嫌悪もひどいですけどね😔

なので、常に自分の機嫌を取り、調子の良い状態を保つ力が必須です。

（私の場合）調子の良い状態を保つための前提条件

  • 苦手な人と働かない
  • 苦手な仕事を減らす
  • 睡眠は 7 〜 8 時間取る
  • お気に入りにサプリを毎日飲む
  • 昼ごはんは炭水化物を抜く（食べ過ぎると眠くなるので）
  • 1 週間の中である程度、 1 人の時間が必要（予定詰めすぎ NG）
  • スマホの通知をオフにする（追われてる気分がするので）

私は特に誰と働くか？どんな仕事をするか？で仕事の質が全然違うということが分かったので、去年は苦手な人の排除、苦手な仕事の排除を積極的に進めてきました（これが出来たのはフリーランスならではかもしれません）

また、自分の機嫌が取れるよう努めていても、体調が悪い日も含めて、なかなか仕事が捗らない日もあると思います。特に生理がある人は週によって全然気分が違いますよね。そういう調子が悪い時でも、最低限の仕事を自分にさせるためにどうしたら良いのか？も知っておくと強いです。

（私の場合）調子の悪い時に最低限の仕事を自分にさせるための方法

  • 単純作業多めにする
  • クラシック音楽を流す
  • 大きな声を出す・歌う
  • 家の近くの散歩コースを走る
  • 少し寝る
  • カフェで仕事する

などがあります。人によっては食べ物などのご褒美を用意するパターンもあるかもしれないですし、人と話してると元気が出るのであれば音声会話ツールを繋ぎっぱなしにしてもらっても良いかもしれません。また、同じ場所にいると飽きるのであれば、お気に入りの場所を複数用意しておくとか、部屋でも外着に着替えた方がシャンとするって人もいますよね。

あと、不調になった時の行動パターンも知っておくこと良いです。

（私の場合）不調になった時の行動パターン

  • 無意識に YouTube ばかり見てる
  • 全ての会話が責められてるように感じる
  • 部屋が荒れてる
  • PMS（生理前）

などです。自分が不調なことに気づけば、あとは不調を改善する行動を取るだけだったり、時間があれば根本改善するには？を考えることもできます。

また、この「自分の機嫌を取るスキル」は一般的な正解がないと考えているので、日々自分を観察し改善を繰り返しながら試行錯誤して「これかな？」を探していくしかないと思います。私はそれに 2 年弱かかってますし、現在も改善中です（ライフスタイルや年齢によっても変わってくるので、一生改善し続けるものなのかなぁと思います）

※ 日々の自分を観察するツールとして、私は「TaskChute Cloud」を使っています。
参考）【徹底解説】タスクシュート時間術の5つの基本ルール | ぞのjp

本当はオフィス勤務時代から「自分の機嫌を取るスキル」を知っていれば良かったのですが、たくさんの人と接触しすぎて（？）自分の不調の原因を特定しづらいですし、そもそも不調の原因を特定して改善しようなんて発想にならなかったです。。そういう意味でリモートワークをしたお陰で、自分の機嫌を以前より取れるようになったことは、人生においても有益だなぁと感じます。

あれば幸せになるかもしれないスキル

ここからは「私の場合」このスキルを付けたおかげでリモートワークが楽しくなったなぁと感じているものを紹介します。

鈍感力（即レス編）

リモートワークの記事を見てると「即レスしましょう」みたいな文言をたまに見ますが、個人的には「即レス」より「鈍感力」を鍛えた方がいいと思っています。特に知的労働であれば、ガッと集中してることもあると思うので、変に即レスを必須にせず、いつか見てくれるだろう、見てくれないなら明日もう一回送ってみよう、ぐらいの鈍感さを持ってる方がハッピーな気がしてます。

また、私は頭の切り替えが苦手でチャットの通知音がなるとチャットが気になって集中できなくなるタイプなので、チャットやメールの通知音はほぼサイレントにしてます（今の仕事の立場上、緊急ってこともないですし）そして、自分の集中力が切れる 30 分 〜 40 分に 1 回ぐらいのペースでメッセージを確認するようにしています。

脱・即レスを元にした仕事の優先順位

鈍感力を付けたお陰で仕事の優先順位も変わったように感じます。
例えば、何か悩みごとが発生してチームメンバーに相談したい時「今日中に返事が来ない」可能性を視野に入れるようなりました。そのため、複数あるタスクの中で他人に相談ごとが発生しそうなものを優先したり、一旦一通りタスクを眺めて相談ごとだけ片っ端から質問しておく場合もあります。
うまくいかない時もあるけど、相手から「今日中に返事が来ない」状態であっても、なるべく自分の仕事に支障がでないよう心掛けています。

鈍感力の鍛え方

私の場合は「自分がされて嫌だと思うこと（自分の中でのタブー）を自分がやる」です。

もともと私も即レスして欲しいタイプですし、絵文字のないメッセージに不安を感じるタイプでしたが、その原因は「自分はこんなに（無理して）頑張って気を遣ってるのに！」だということが分かったので、まずは自分が「タブー」だと思ってることをやり、「頑張って気を遣う作業を辞める」を実践しました。

最初のうちは即レスで返さない（自分の中でのタブーを犯す）ことで、仕事をサボってると思われないかな？仕事できない奴って思われないかな？など、不安でソワソワしてましたが、蓋を開けてみると、即レスの有無と仕事上の信頼関係はほぼ無縁であることを実感しました。

そして、その行動を通して、自分が即レスしたい時はすればいいし、したくない時（集中したい時）はしなくていい。また、自分が無理して頑張らなくなると、相手の行動も気にならなくなり、相手の行動に一喜一憂しない鈍感力を身に付けることが出来ました。

※ もし一喜一憂してしまっていたら「不調のサイン」と捉え、「調子の悪い時に最低限の仕事を自分にさせるための方法」を実践するのみです。

脳内ポジティブ変換（私は愛されてる）スキル

相手の言葉に勝手なネガティブ解釈をくっつけず、むしろ勝手なポジティブ解釈をくっつけるスキルです。ポジティブ変換ができるようになると相手のどんな言葉でも優しさが滲み出てるように感じたり、褒められてるような気がします（笑）

例えば最近の私の場合だと、自分の作ったプログラムで致命的なバグがテストで見つかったので（一般ユーザが管理者ページを閲覧できてしまう的な）その修正プログラムの確認依頼を担当者にお願いした時に言われた言葉について

言われた言葉

「ありがとうございます。テストで見つかってよかったです。」

ネガティブ変換の場合

「テストでこのバグ見つからなかったら、本当にやばかったです。しっかりやってくださいよ。」的な、少し嫌味な表現にも見えてしまいそうです。

ポジティブ変換の場合

「テストでこのバグ見つかったおかげで、お客様にも迷惑かけずにすみました。本当に良かったです。いつもありがとう。」ぐらいには脳内変換できるし、優しさが滲み出てるような気がします。

大前提「私は愛されてる」

心屋仁之助さんの影響を多大に受けていますが、根本的に自分は「愛される人間なのか？」「嫌われる人間なのか？」どっちだと思っているか（信じてるか）によって、脳内変換の結果が変わってくると思っています。

自分は根本的に「愛される人間」だと思っていれば、上に書いたようなネガティブなことを言われる訳がないと信じれるし、「嫌われてる人間」だと思っていれば、些細な発言でも怒ってるのかも・・と思ってしまいます。私も元々「頑張らないと嫌われる」と信じてきたタイプなので、性格改善は大変でしたが・・なんとかなりました。

詳細はこの辺の記事を読んでください。

※ もし、それでもネガティブ変換してしまったら「不調のサイン」と捉え、「調子の悪い時に最低限の仕事を自分にさせるための方法」を実践するのみです。

自分のことを伝える力

オフィスなら察してもらえるような情報を伝える

オフィス勤務で隣に人がいたら声や態度から察してくれるだろうなぁみたいな内容はリモートワークだとほとんど伝わらないので、自分から開示するようにしています。

  • 体調が悪い
  • 体調が回復した（元気になった！）
  • これから精神的に重たい予定があるので、ソワソワしてる
  • 不安・寂しい・嬉しい などの感情
  • 家のことで緊急事態が起きた！

こういうのって敢えてチャットに書かなくてもなぁ・・と思いがちですが、リモートワークの場合、やせ我慢しようと思えばいくらでも出来ちゃう（誰も止めてくれない）世界ですし、インターネットの向こう側にいる同僚たちは、基本私が普通に働いてると思っているので、その認識に齟齬が生まれそうな場合（仕事に支障を来たす・来たしそうな場合）は自分で開示して、必要であればフォローしてもらう体制を作っておいた方がいい気がします。

自分はどんなことをされると嬉しいのか？を伝える

今の職場はチャットのメッセージに基本スタンプをくれないメンバーと働いていて、「心理的安全性を担保するために全員スタンプを押すべき！」とまでは思わないですが、自分がスタンプ押してもらうと嬉しい人間なのであれば、それを伝えた方がいいです。私は以下のような文言で伝えました。

もし負担じゃなければ「OK」みたいなスタンプもらえると嬉しいです。メッセージ見てるのかな？って不安になるので、スタンプもらえると安心します。（でも、面倒であればやらなくて大丈夫です、見てるだろうって思うようにします）

結果、スタンプを押してもらえるようになりました😍感謝！

また、以前の勤務先は「即レス文化」があったのですが、私はそれが苦手だったので「集中力が削がれるので通知を切っています、ごめんなさい。でも 1 時間に 1 回はメッセージを確認しています。」と伝えていました。

ただここで注意点があって、要望を伝えるのは大事ですが、自分の伝えた要望が通るか？（相手が期待通りの行動を取ってくれるか？）は期待しすぎない方がいいです。精神衛生上のために。また、一定期間経って相手が期待通りの行動してくれなくなったら、再度お願いすれば良いと思います。

Twitter で無言マージは辛いとか、文章「。」で終わるより「！」で終ってほしい、テレビ会議は顔を出してよ！など、たまに見るし気持ちわかるけど、変に我慢してベキ論でイライラするより、サクッと自分がされたいことを伝えた方が健全だと思っています。

休憩スキル

リモートワークはサボるんじゃない？と思われがちですが、普通の人は（？少なくとも私は）サボろうという発想より、見られてないからこそキッチリ成果を出そうと考えるタイプなので、頑張り過ぎちゃうことの方が多いです。また、生活空間の中に仕事場があるので「あ！あれどうだっけ？」と思い付いた時、物理的にはすぐ対応できてしまうので、根本的に仕事が好きという方は「仕事したい欲」もコントロールできた方が長い目で見て有益だと感じます。

よく考えるとオフィス勤務の時だって、たまに「ランチで喋りすぎて休憩 2 時間取っちゃった・・！」とか、「やる気なさすぎて午後はダラダラして何も進まなかった・・！」とかあるじゃないですか。まぁそういうのがいい意味で息抜きになってたと思うのですが、リモートワークだと邪魔が入りづらく集中しやすい環境を構築しやすいので、意識的に休憩するスキルを身につけた方がいいと思います。仕事は何十年も続きますからね。

ポモドーロ・テクニック

私の場合はポモドーロ（25分実行＋5分休憩）を応用して、50分実行＋10分休憩のペースで仕事をしています。楽しくて仕事が止まらず集中モードで 3 時間とか休憩なしにガッと働いちゃう時もありますが、そうすると結局その後の仕事や翌日の仕事で集中力が少し落ちてるので、コンスタントに働けるよう時間を区切って休憩するようにしています。

参考）はたらき方の可能性を拡げるメディア「Work Switch」サービス終了のお知らせ | ニュースリリース | パーソルプロセス＆テクノロジー株式会社

仕事の断捨離スキル

リモートワークだと本当に

  • 苦手な仕事
  • これって意味なくない？と心が感じてる仕事
  • 面倒くさい仕事
  • 心理的にストレスの多い仕事（苦手な人に連絡を取るとか）

などを後回しにしちゃいがちです。

特に私は「心理的にストレスの多い仕事」を何度も頑張ろうとトライしたのですが本当に指が動かなくて・・😫最終的に周りの人に迷惑をかけちゃう・・という自体を数回やらかしてます（ごめんなさい）そのため、今では苦手な人と極力働かない、嫌な仕事は辞める、頼む、自動化・・など、積極的に推進しています。 それでもこういう仕事ってゼロにはならないので、「面倒な仕事は朝一に１つだけ頑張る！」って決めるのも有用です。

リモートワークのメリット

運動習慣を見直せる

本当に運動しないと、1 日 8 時間元気に働くこともままならなくなるので・・このままだとヤバイ！という危機感を自然と覚えます。オフィス通勤してた時の運動って、人生における＋α（美とか健康とかのためにやってる）のイメージだったのですが、リモートワークだと「生きるため」に運動が必要になってくるので、本気度が変わります。私の場合、それでもまだ冬は運動をサボりがちになるので・・もうちょっと改善が必要だなぁと思っています。そして通勤って意外と運動になってたんだなぁと実感してます。

息抜きの多様化

オフィスの休憩って

  • ボーッとする
  • 人と喋る
  • タバコを吸う
  • 散歩する
  • 業務外のネットサーフィン

ぐらいしかやることがないですが、家だと

  • 家事
  • 筋トレ
  • 風呂
  • 1 人で喋る

など、家でしかできないことも選択肢に含まれるので、調子の良い日の休憩では皿洗いや洗濯物、料理などが出来ちゃうので本当に良いです。でも「人と喋る」はやりづらくなりましたね。。

毎日お洒落しなくていい

社会人になると化粧やオフィスカジュアルがデフォルト的な風潮がありますが、もともと私は自分の容姿を整える行為にあまり興味がなかったので（でも、可愛くいたいって気持ちはあります！）毎日オフィスレディに変身するのは結構苦痛でした（毎日お洒落することに抵抗を感じない人、羨ましい）そしてトイレに行く度にマスカラ落ちてない？ファンデーションよれてない？を確認して・・。今考えれば頑張ってたなぁと思います。懐かしい。
意外と男性より女性の言葉の方が厳しくて「女なんだから化粧しなよ！」とか「（化粧してるのに）スッピンかと思った〜」とか言われると、うぅぅ・・😣となります。

今は家にいる時はスッピン ・楽な服ですが、たまに外出する時に化粧・お洒落すると「楽しい！」「可愛い！」ってなるので、お洒落が嫌いなわけじゃないです。「毎日」が苦痛なだけです。

部屋のレイアウトが自由

先月までは窓側を背にしてたのですが、急に部屋のレイアウト変えたい！と思い立ち、今の配置に転換しました。手前側が寝る場所です。あと、空調を独占できるのもリモートワークの強みですね。

f:id:meikotan:20200220181829j:plain
my-room

人と会う時間を大切にできる

普段人と会わない分、人と会う予定を全力で楽しめるようになった気がします。以前は惰性的な飲み会もありましたが、今は全部の飲み会・イベントが全力だし、全部楽しい！と心の底から思います！

体調悪くなった時に即布団に行ける

結構、通勤って体力いりますよね。

体の悲鳴が聞こえやすい

オフィス勤務時代は微熱や生理不順を放置して働いていたのですが、リモートワークになってから電車に乗る、人に会うなどの外的要因が少ないからか「あれ？今日調子悪いかも・・」が感じやすい気がします。特に私はストレスが体の不調に出やすいタイプなので、それをキャッチして改善ができるのは良いことだと思います。

仕事仲間を信頼する基準が仕事の質になる

オフィス勤務の時、最初は「人当たりが良さ」や「積極的に声掛けてくれるか？」などを基準に仲間を信頼しがちなのですが、ある程度長く一緒にいれば「あの人、口は達者だけどお願いした仕事はやってくれない」とか「あの人、最初は怖いと思ってたけど仕事は本当に頼りになる」とか、仕事の質にフォーカスが当たってくると思います。

私の場合、前職の上司が口の達者なのらりくらりタイプで、入社当初は人当たりの良さに騙されて（？）この人は信頼できる人だ、と思っていましたが、１年も一緒に働いてれば「この人は口だけだなぁ・・」ということが分かってきたので、最初の印象だけで仕事仲間として信頼できる人か？を判断するのは難しいなぁと感じます。

一方、リモートワークだと雑談が少なめなので（これはこれで問題かもしれないですが・・）最初から仕事の質にフォーカスを当てて、相手が信頼できる人なのか？を判断するようなった気がします。なので、口だけでのらくら働いてる人にとっては少しシビアかもしれないですが、私はそれぐらいの方が好きです。

真の意味でインターネットの偉大さを感じる

家にいるのに普通に仕事が回ること自体がすごいことだし、特に私はリモートワークと田舎暮らし（元々東京生まれ東京育ちです）を同時に始めたタイプなので、田舎の IT 勉強会がオンライン◯◯会が多いことに驚いたし「インターネットありがて〜」と改めて感じた記憶があります。

オンライン◯◯会

  • オンライン読書会
  • オンラインもくもく会
  • オンライン LT 会

東京にいた頃を振り返ると、会える距離にいるからってオフライン開催が当たり前で。でも、会える距離といえども、我が家から渋谷まで片道 40 分・交通費は片道 300 円ぐらい掛ってたし、これって結構時間とお金の無駄だったのかもなぁと思います。もちろん飲み会や交流がメインなのであればオフラインがいいと思いますが、私は飲み会とかは「たまに」で良い派ですし、LT だけ聞いて懇親会出ずに帰るとかも結構やってたタイプなので、オンライン◯◯な勉強会に抵抗感はないです。そして、東京の勉強会ももっとオンライン色を強めてくれたらなぁと思います。

また、オンラインだとやりづらいんじゃない？と思われるかもしれないですが、それはやり方次第だと思うし、個人的に少人数であればオンラインの方が距離も近く話しやすいような気がします。（でも東京は人が多いからなぁ・・）

オンライン飲み会

最近、遠方の友達・職場の人たちとは「オンライン飲み会」ばかりしていますが、オフライン（居酒屋など）の飲み会とほぼ変わらないコミュニケーションが取れてるように感じます。

オンライン飲み会の好きなところは

  • 静かで声が聞こえやすい
  • スマホをいじっててもバレない（気軽にいじれる）
  • 調べごとがパソコンでできる
  • 画面共有やリンクのシェアも楽
  • 安い
  • 好きなものを食べれる・飲める
  • 飲んだ後に帰宅という作業がない（もう既に家なので）

など。もともと私は飲み会で「わーわー」と盛り上がるのが苦手だし、周りのうるささに対抗して声を張り上げたり、誕生日コールが始まって会話が止まったするのが嫌で、オフラインで飲んでいても個室でゆるゆるとお喋りする方が好きなタイプなので、オンライン飲み会に全く抵抗感がないです。

デメリットを挙げるなら

  • 人数が多いと喋り出しが被りやすいので、3 人から多くても 5 人ぐらいで話すのが理想的
  • 珍しい料理が食べれない（いつものご飯になってしまう）

ぐらいかなと思います。

リモートワークのデメリット

寂しい

今はだいぶ慣れましたけど、最初の方は「寂しい」「孤独だ」とよく思っていました。

ただ、寂しいからといってリモートワークを辞めたいとは思わなかったので、以下のことを考えるようになりました。

  • 寂しいってどういう状況で感じるんだろう？
  • 誰でもいいから横に人がいて、喋れたら寂しくないの？
  • リモートワークで寂しさを感じないようにするにはどうしたらいいの？

私の場合、リモートワークとフリーランスを同時に始めたタイプで、「会社」というコミュニティに属しているだけで、当たり前のように自分の時間を割いて私の相談事に耳を傾けてくれる仲間がいること、「オフィス」という場所に毎朝向かうだけで、横には仲間がいて「おはよう」が言えて、「昨日嫌なことがあって仕事やる気でない・・」とか、雑なお喋りができて。それが程よく息抜きになってたし、会社で寂しさを感じないのは、そのようなコミュニケーションを通して所属感（帰属意識？）が生まれていたからだと考えるようになりました。（当時は煩わしいと思うことの方が多かったですが）

結果、私は働く時に所属感を感じたい人間だと分かったので、リモートワークで働ける会社に就職したいなぁと思うようになりました。

雑談しにくい

仕事をする上で困ったことがあればチャットで質問できますけど、雑談ってもっとフワッとしたことを聞きたい・相談したいって時に特に必要だなぁと思います。

例えば、

  • A と B の選択肢がある場合、自分的には A が妥当だと思ってるんだけど、少し不安なので、あなただったらどっちを選ぶか意見聞きたい
  • 新しく〇〇なやり方を学んだんだけど、あなたは〇〇を使ってる？使ってる場合、どんな感じで使ってるか聞きたい
  • 今のプロジェクトの〇〇な点が気になるんだけど、どう感じているか聞きたい

など。聞いても聞かなくても業務には支障ないレベルだけど、なんとなく心に積もってくモヤモヤを私は雑談で解消していたんだなぁと思います。あとプライベートな雑談（ふるさと納税やった方がいいよ！とかマンションを買う時にローンを組むと国から補助金が出るらしいよ！とか）も楽しいし、一緒に働くメンバーの生活環境や人となりが分かっていいですよね。

いま私はフリーランスですが、お陰様で知り合いがいる会社で働いているので、上記に書いたようなフワッとした話（雑談）はその人に相談しています。でも、横にいるわけじゃないので、意外と聞きたいなぁと思ってから実際に話しかけるまでのハードルが心理的に高く・・。結果、いまは先に相談日（雑談日）を決めて話したいことの有る無しに関わらず、ミーティングを開いてもらうようにしてます。感謝！

そして私個人としては、雑談も大事だけどリモートワーク環境も大事で、雑談がしたいがためにオフィス勤務の仕事になるのは嫌なので、リモートだけど雑談ができる環境があると理想だなぁと思います。

参考）リモートワークだけど雑談できる仕組みを作ってますよ！という会社の勉強会に行った話。 「ザッソウ 結果を出すチームの習慣」ABD読書会 in 徳島 に参加しました - FreeDrop

光熱費が高い

冬は電気代だけで 15,000円 ぐらいになります。。（普段は 6,000 円ぐらいです）

顔が幼くなる

Twitter で見かけたやつですが共感します。前職のリモートワーク歴が長い先輩はタレ眉だったなぁ。 https://twitter.com/OgiharaRyo/status/1224918936086441985

最後に

私の姉は海外に住んでいて、今年 3 週間ぐらい遊びに行きます。そして平日は姉の家で仕事をする予定です。姉も向こうで働いてるので「平日働くのなら長く居てもいいよ、週末は一緒に出かけよう！」と言われて、リモートワークが出来て良かったなぁと思いました。

働き方として「全員リモートワークにすべき！」とまでは思わないですが、以下のようなイレギュラーがあった時に、選択肢としてリモートワークを持っておくと、物理的な制約により何かを諦めるという選択が減るかもしれないですね。職種にもよるけど。

前職の先輩でオリンピックの時期は東京にいたくないと言っていた人もいましたね。私は逆に東京に行きたいですけどね。

また、家が好きな人、周りに人がいるだけで少し気が散っちゃうタイプの人はリモートワーク楽しめるかもしれないです（私のことです😌）

終わりです。

参考

私の考え方については、以下のメディアに多大な影響を受けています。感謝！

IT 勉強会の活用方法

勉強会

IT 勉強会っていろんな種類があるけど活用方法が少しずつ違うなぁと思ったので、書く。

参考：IT 勉強会のいろんな種類
【初心者必見！】初めてIT勉強会に参加する時に気をつける事

LT（ライトニングトーク）

新しい何かとの偶然的な出会いを求めて

もちろん LT する側（発表する側）であれば

  • 知識の言語化・整理ができる
  • より深く理解できる
  • 人前で話す練習になる
  • 懇親会で話しかけてもらいやすくなる

などメリット盛り沢山だと思うのですが、LT 会は聞いてるだけでも十分勉強になると感じていて。

Google のお陰で何でも調べられる世界になったけど、結局自分が調べたい！知りたい！って思う起点がないと調べられないので、視野が狭くなってたらどうしよう。もっと私の知らない何かがあるのでは？と不安になる時があるんです。

そんなとき LT 会に行くと

  • へ〜こんなのあるだなぁ
  • 知らなかったなぁ

がいっぱいあって。たまに自分が引っかかってた答えを偶然 LT 会で聞けることもあります（あ〜それ聞きたかったー！みたいな）
発表者にとって当たり前のことでも私にとって当たり前じゃないこと沢山あって、それをざっくばらんに聞ける機会はとても貴重なので、最近新しい視点に触れてないなぁって時は LT 会に行きたくなります。

オンラインもくもく会

まとまった勉強時間の確保

普段やりたいと思ってたけど優先度下げちゃうなぁ〜的なものを勉強する時間にしてます。

私の場合、オフラインだと周りの動きが気になって作業が進まないんだけど、オンラインはテレビ電話越しに誰かのカタカタ音で聞きつつも周りの動きが気にならないので、もくもくが捗る感じがする。

読書会

挫折せず本を読み切りたい

技術書は一人で読んでると途中で挫折しがちなので、みんなで少しずつ読んだり、担当制にしてもらえるとやる気が出る。仲間の力！

あなたの会社はどうしてる？を交換する

例えばテストに関する本を読んでる場合、あなたの会社ではテストどこまで書きます？とか、こういう時にどんな風にテスト書きます？とか。その本から派生した会社独自のルールをシェアし合えるのもいいなぁって思っています。

ハンズオン

新しいものに触れるハードルを下げる

全く触ったことない言語、フレームワークの勉強ってつい後回しにしがちで、そういう時にハンズオンを利用してます。
普段は Ruby を使っていて、今年行ったハンズオンは Firebase, Kotlin, Go 。ハンズオンしたからってすぐ使うようになるわけじゃないけど、今後いざ触ってみようかな？って思った時の心のハードルがグッと下がる。しかも、講師の人からそれを使う理由、使い所、困ってることなども聞けるので有益すぎます。

カンファレンス *1

未来を見に行く

カンファレンスの主題である言語やフレームワークを作った人、最前線で改善・提案してる人たちが講演するので、その人たちから直接「これまで」と「これから」を聞けるのはとてもワクワクします。え〜そんな野望があるのかぁとか。しかもその人たちの考え方が良いなぁって感じると、よりその言語を学び続けたいって気持ちになります。

終わり

女子部はいつもワイワイしてて楽しいです！
TECHPLAY女子部 Advent Calendar 2019 - Adventar 17日目

*1 会場に企業ブースが出展される規模感をイメージしてます。

Rails Girls in Ehime 2nd 開催します

勉強会

Rails Girls Ehime 1st を2019 年 6 月に開催して

2020 年 2 月に Rails Girls Ehime 2nd を開催します！

↓ この記事にはこんな感じのこと書いてます。

なんでやってるの？

自分が大学生だったときに独学でプログラミングの勉強をしたいなって思ってもなかなか出来ず・・挫折した経験があって（情報学科だったのに！😔）あのとき先にプログラミングって楽しいなぁ、プログラマーの人達って楽しそうだなぁを感じてたら、挫折してなかったかもしれないなぁと思って。

私は社会人になってプログラミングの楽しさを感じれる機会に恵まれたので今があるんだけど、大学生の私と同じように楽しさを感じる前に諦めてしまう人も多いような気がしてるので、そういう人が参加できるイベントが増えたらいいなぁという気持ちで開催してます。

なんで Rails Girls なの？

カリキュラムが好き

1 日半かけるカリキュラム、コーチがほぼマンツーで教えてくれる体制、そんな贅沢な感じが好きです。
未経験者向けに短い時間で「概要の説明」と「ちょろっとソースコードコピペ」で終わるようなイベントじゃ少し物足りなくて、1 日半かけて「あ〜頭パンク🤯」ぐらいの経験を通して初めて見える世界ってあると思うんです。そして常に横にコーチがいるので、チュートリアルを進めてく過程で自分が今気になるポイントをダイレクトに教えてもらえる。そういうのが良いよなぁと思います。

Rails Girls JP の支援が心強い

@emorima さんを始め RubyKaigi の emori house でお話しした別の地域のオーガナイザーの方々に沢山のアドバイスとご協力を頂いています。感謝！

Ruby 界隈で知名度が高い

かつ、愛されイベントなのでコーチが集まりやすい。1st では愛媛県外から 4 名のコーチが来てくれました。感謝！

女性優先の姿勢に賛成してる

これまで私は女性プログラマーと働いたことがないので、女性が増えたらどうなるのか？あまり想像ができておらず・・正直、IT 業界に女性が増えても増えなくても、どっちでもいいと思ってました。

だけど 2 年前に東京で開催してる「TECH PLAY 女子部」の勉強会に参加して女子だけ 30 人ぐらい集まって LT 会をしたのですが、これまで職場で感じたことがない、IT の話を友達と取り止めもないお喋りをしてるような雰囲気で話せて、それがとっても居心地良くて。女子どうしで IT のこと喋るのも楽しいんだなぁって思ったんです。

まぁだからといって女性プログラマーが増えるべき！までは判断付かないんだけど、ただ IT 業界の男女バランスが改善されたあと、職場はどんな雰囲気になるのか？その環境で自分はどう感じるか？ってことには興味を持ったし、そんな世界を見てみたい、面白そうだなぁという気持ちが芽生えました。なので Rails Girls の Affirmative action に賛成しています。

1st の振返り

勇気が必要だったこと

「チラシをお店に置いてください」と依頼する

インターネットの海に Girls はいない！と思っていたので、最初からチラシをリアル店舗（本屋や専門学校など）に配りたいなぁと考えていたのですが、いざ「チラシをお店に置いて欲しいんですけど・・」と頼むのは、初めての体験だったこともあり想像以上に何度も二の足を踏みました。

メンタルの限界で 1 日最大 3 件ぐらいしか訪問できず‥ 4 回ぐらいに分けてチラシの依頼に行ってきて。最終的に断られたのは 3 件（しかも、申し訳なさそうに断って頂いて、ありがとうございます）で、世間の優しさ身に染みました！

そして集客の結果として、当日チラシを見てイベントに参加した Girls はゼロ！😇！ でも、インターネット経由で参加した Girls も 3 割ぐらいだったので 2nd もチラシ配ります。もう置いてくれる店舗把握してるからラクチンなはず！

※チラシの依頼に関して参考にした記事

悩んだこと

未経験の人はプログラミングって言葉にビビる？

最初は Girls が全然集まってなかったので（コーチの方が先に集まってて）、愛媛のプログラミング経験のない知り合いにチラシの添削をして貰ってたのですが、そのとき

未経験の人からしたら「プログラミング」って言葉があるだけで私には無理って思ってビビっちゃう人多いから、「プログラミング」を「簡単HP作成」みたいな言葉に変えて、参加しやすくしたら？

と言われて。これは悩みました。

個人的には「プログラミング」って言葉を見て「私には無理・・」って思う人には来て欲しくなくて、プログラミングって言葉は知ってるし、難しそうなことも知ってるし、自分にできるのか分からない、けどやってみたい。という人に来て欲しいなぁって思ってるんです。

なので、人が集まらないからって「プログラミング」という言葉を外してまで参加者の敷居を下げたくないし、でも実際集まってないのだから改善はしなきゃなぁ・・とモヤモヤしてて。結果、タイトルは「誰でも作れるはじめての HP 作成」で、メッセージ文言に「プログラミング」を入れることで、心の折り合いをつけました。

2nd でやりたいこと

私もコーチやりたい

他のオーガナイザー・スタッフメンバーがとても頼りになる方々なので！

託児つけたい

1st でチラシを受け取ってくれた店舗のお姉さんに「良かったら参加しませんか？」と誘ったら、「土曜は子供がいるから行けないんだよね〜」と言われて。私に子供がいないので、あんまり託児の必要性に実感が沸いてなかったんだけど（ごめんなさい🙏）目の前のお姉さんがそう言ってるんだから、そうなのかぁという感じで。子供を理由に行けないっていうのは少し寂しいし、基本的には「やる気」と「パソコン」があれば誰でも参加できる環境を作りたいと思ってるので、託児やってみるかぁ〜という気持ちになりました。

12/8 時点（記事公開日）で、場所は確保できたのですが、あとはベビーシッターさんの会社探しや見積もり、調整など。今の時点でどうなるか分からない（12/15 託児をやるか？確定予定）のですが、託児やろうと思って動いただけでも一歩だと思ってるので無理せず、良しなになったらなぁと思います。

（追記：12/25） 託児の受付を土曜日のみ行うことになりました。詳細は以下をご確認ください。 Rails Girls Ehime 2nd（託児受付） - Rails Girls Ehime | Doorkeeper

※託児に関して参考にした記事

そして相談に乗ってくれてる方々、ありがとうございます！

野望：愛媛は広いぞ

今は愛媛で 1 番の都市、松山で開催してますが個人的には

とかでも開催したいです。
愛媛県内でのコーチ人口が 5 名超えたら何とかなりそうかも〜とぼんやり考えてます。

最後に

参加してくれる Girls のみなさんが、頭の中だけでモヤっとプログラミングに対してイメージしてたことが、イベントを通して手を動かしプログラマーのコーチと話すことで、ほんの少しでも何か変化が生まれると嬉しいなぁと思っています。

そして、運営やコーチを手伝ってくれる方々、支援してくれるスポンサーの方々、ツイッターのシェアをしてくれる方々、皆さんのおかげで 2nd も開催できそうです。ありがとう。
今後ともご協力よろしくお願いします。

Rails Girls Japan Advent Calendar 2019 - Qiita 8日目

「ザッソウ　結果を出すチームの習慣」ABD読書会 in 徳島 に参加しました

勉強会

10月に Agile459 が主催する
リーダーに聞いて欲しい「ザッソウ　結果を出すチームの習慣」ABD読書会 in 徳島 に参加しました。

なんで参加したの？

もともとソニックガーデン（倉貫さんが社長の会社）のことは、Rspecな伊藤さんが所属する会社ってイメージで知っていて、社員が完全リモートでかつ、納品のない仕事の形ってすごいなぁと思っていました。

そして私は現在、愛媛でフリーランス＆在宅ワーカー2年目でして。
在宅ワークを始めた当初は、邪魔が一切入らず仕事できるのすごい！捗る！と喜んでいたんですけど、気づくとなんか寂しいなぁとか、あぁモヤッとした感じのこと聞きたいけど、言葉にできないからチャットで何て聞いたらいいか分かんないなぁとか、なんとなく周りの人忙しそうだし聞きづらいなぁ・・とか感じるようになって。
会社員で出勤してた時、隣に当たり前のように同僚がいて、ゆる〜い話しをしたり、頭の整理のために喋ったり、分かんないとこ一緒に調べ合ったりできる環境って有り難かったんだなぁと思うようになりました。

ただ、在宅ワークになったことで

  • 電車に乗らなくても良い
  • 心落ち着く家で仕事ができる
  • 隙間時間を有効活用できる
  • 外出用の見た目を作る必要がない

など、気に入ってる部分も多かったので、リモートワークと雑談を両立してるソニックガーデンの話を聞いてみたいなぁと思い参加しました◎

本の内容は？（ざっくり）

ザッソウ　結果を出すチームの習慣

ザッソウは「雑談＋相談」の略で、これまでのホウレンソウ的な一対多や、型式ばったコミュニケーションじゃなくて、雑に相談できるような、雑談と相談を混ぜた（ザッソウ）コミュニケーションを取ると良いよ！って感じの内容です。

ABD読書会とは？

  1. 参加メンバー全員で書籍を分担
  2. 自分の担当を要約
  3. みんなで要約した部分を発表する
  4. 発表内容をもとに少数グループでディスカッション

という流れで行いました。

詳しくはこちら：未来型読書法 アクティブ・ブック・ダイアローグ®（ABD）公式サイト

本、まったく読んだことないのに読めた気分になるがすごい。

リモートワークで雑談を実現するには？

個人的には雑談をリモートワークで実現できる理由が気になってて、聞いてみたらリモートワークで雑談しやすいツールを作ってしまった！とのこと。

この辺の倉貫さんの記事が参考になりそう。後、本にも詳しく書いてあります。

リモートワークでも雑談がしやすい条件として

話しかけたいと思う人が今席に座っているか？が分かった方が良い

→ 2分に一回、席に座っている人を撮影して表示する
→ 今そこに本人がいるのが確認できるので、今話しかけても大丈夫そうかも？ってのが分かりやすくて、話しかけやすい

雑談が全員に通知が行くと発信しづらいし、他の人もワイワイ雑談してる感があると良い

→ Twitter みたいなタイムライン画面を導入
→ 個人用のチャンネルで発せられた内容（全員には通知がいかない）をタイムライン上に流すことで、自分以外の誰かが話てる感じが伝わるので、自分も雑談しやすい

今あるチャットツールで、リアルオフィスのようなリモートワークの実現って難しくて、独自ツールで実現してるのかぁ〜が知れて面白かったです。リモートワークで働いてるんだから、自分でしっかり質問できるようになってね！を求めるだけじゃなくて、少しでも話しかけやすく、孤独感を感じさせないような仕組みを大事にしてるっていいなぁと思いました。

ABD読書会の感想

チームのコミュニケーションに、ホウレンソウや雑談、会議など。名前がつくと、それっぽい会話をしなきゃ、関係ない会話は止めようとか、考えがちでした。でも、コミュニケーションはすべてザッソウだと思えば、今のこの会話しても大丈夫かな？など考えずに、話せそうなので、良いなぁと思いました。

本を全部読んだ感想

告白しますと、それは他ならぬ私自身、雑談が苦手だったのです。

私も面白い話できないし、雑談って難しいなぁと何度も悩んだことがあったので、今後はザッソウを少しずつ取り入れていきます◎

徳島に行って分かったこと

  • そごう徳島店がもうすぐ閉店になり、全国唯一の「デパートゼロ県」になるらしい
  • 電車じゃなくて、汽車（ディーゼル車）
  • バスで降りる時に「ありがとう」って言う

徳島観光

  • 阿波踊り一緒に踊って、手拭いもらった！
  • 渦潮見に行ったら、船で酔った・・！

Agile459運営のみなさん

いつも面白そうな勉強会が多いので、参加したいなぁという気持ちになります。運営ありがとうございます！これからもタイミング合えば、参加していきます😊

Agile459 Advent Calendar 2019（1日目）

Rails 5.1～ [ form_for / form_tag ] => form_with に統合！

Rails

5.1~ form_withという form_for, form_tag を統合するメソッドが追加になり、form_for, form_tag は非推奨になります。

今まではmodelあり、なしで form_for, form_tag を使い分けてたけど、form_withの場合はそれが必要ない。モデルある、なしに関わらず同じように記載できます。

以前（form_for / form_tag）

モデルあり

from_for @user do
　= text_field :email
end

モデルなし

form_tag root_path do |f|
　f.text_field_tag :email
end

5.1（form_with）

モデルあり

form_with model: @user do |f|
　f.text_field :email
end

モデルなし

form_with url: root_path do |f|
　f.text_field :email
end

注意

5.1ではform_withのinput 要素に id が付かない。

form_for @user do |f|
　f.text_field :email
end

↓

<form class="new_user" id="new_user" action="/users">
　<input type="text" name="user[email]" id="user_email" />
</form>         

form_with model: @user do |f|
　f.text_field :name
end

↓

<form action="/users">
　<input type="text" name="user[email]" />
</form>

5.2 〜はもとどおりつくよ！

非同期（Ajax）がデフォルト

今まではform_forで非同期（Ajax）するとき、form_for .. remote: true オプションをつける必要があった。

なんでデフォルトに？

DHHのコメント

Make remote: true the default. Full-page changes after submissions are rough. When using Turbolinks,
a normal redirect will generate a Turbolinks.visit() call, and otherwise there's SJR.
(We could consider having config.action_view.forms_remote_by_default that you could set to false, for people going old school).
  • リクエストを全部ajaxにして、フルページ再読み込みを避けたほうが早い
  • これまではturbolinksでリンクはajaxになり、今回はformもajaxに！
  • turbolinksを使ってるとき、submitはredirectはturbolinks.visit()が呼び出されて、通常と同じようになる。
  • ただし入力エラーになったとき、SJR(Server-generated JavaScript Responses)で対応する

SJR(Server-generated JavaScript Responses)とは？

サーバ側（view）にレスポンス後に処理したいjs（xxx.js.erb）を書いて、レスポンスと一緒にそのjsを送る. ただエラーのたびにそれを書いているのは大変。。
↓便利そうなgemがありました。

  • ajax_error_renderer

    render_ajax_errorという、ajaxでエラーメッセージを表示するメソッドを提供する小さなgemです。Controller にAjaxErrorRendererをincludeすると使えるようになります。

今まで通り（remoteじゃない）の通信にしたい！

全体を変える

config.action_view.forms_remote_by_default

form_tag ごとに変える

form_with model: object, local: true do |f|
end

参考