おすすめ書籍:正義の教室
本との出会い
コロナがこんなに長引くと思ってなかった今年の3月、映画をみた帰り道にさくっと立ち寄ったヴィレヴァン@松山で出会いました。本屋でビビッと買いはほとんどしないのだけど、表紙の「30 人の幼児と自分の娘、どちらを助ける?」の問いに自分が答えられなくて、正解が知りたくて買っちゃった本。
30 人の幼児と自分の娘、どちらを助ける?
非番だった日「娘が体調を崩したから迎えに来て欲しい」と保育園から連絡をもらう、職業:消防士の父。迎えに行ってみると保育園で火が出ていた。父は娘を助けるため、迷うことなく火の中に飛び込み娘のいる部屋に向かうが、途中 T 時路にぶつかった。右はたくさんの子供たちがいる保育室(しかも子供たちの絶叫が聞こえる)、左は体調の悪い娘がいる救護室だ。時間的に助けられるのはどちらかしかなく決めなくてはならない・・どちらを助けることが正しいのか?
プロローグの要約。
もちろん本にはどちらが正しいか?は書いておらず、自分だったらどちらの選択が正しいと思うのか?が突きつけられる…。つらい。だからこそ、そもそも正しいって何?正義って何?を求めて本を読み進めたくなる。素晴らしいプロローグ!
ざっくりストーリー
登場人物は4人の生徒会メンバー、主人公の「正義」と3人の女子高生「千幸」「ミユウ」「倫理」。生徒会によせられる苦情に対して、どう対処するべきか?そもそも問題なのか?を議論するんだけど、千幸、ミユウ、倫理の意見がバラバラすぎて話が進まない日々…。
そんなとき、倫理の授業で「正しさの判断基準は3つだけ」と教わる。
- 「平等の正義」を実現するための「功利主義」
→ 最大多数の最大幸福になるようにすれば OK - 「自由の正義」を実現するための「自由主義」
→ 他人の自由を侵害しない限り自由にやって OK - 「宗教の正義」を実現するための「直感主義」
→ 良心に従って道徳的な行動をしてれば OK
「正義」は千幸が功利主義、ミユウは自由主義、倫理は直観主義をもとに正しさを主張していたことを知り、意見が食い違う理由に納得する。それから倫理の授業を通して1つ1つの主義の歴史を振り返りながら良い面・悪い面を議論し、正しさとは何かを考えていく。
感想
焼きそばパンの転売は問題か?
生徒会で対処する1つ目の話題。「購買部に一番近い教室の生徒が人気の焼きそばパンを買い占めて、50円上乗せで他の生徒に売っていることについて」これは問題?
私はこういう転売行為にモヤっと。購買で誰も買わないパンを需要のある別の場所で転売するならまだしも、定価で焼きそばパンを買いたい人がいるにも関わらず転売する行為はなんか嫌だなぁと思う(私のモラルに反する)。でもこう思えるようになったのは実際に自分が過去に転売業をやってみて感じたからで、転売業をやっていなければ今でも転売?別にいいじゃんって思ってた気がする…。また、自分はやりたくないけど他人に対してまで「それは正しくないから辞めるべき!」という強い主張もなく、それでうまく回ってるなら自由にやればというスタンスは強い…。
なので、千幸が「購買部のおばさんは焼きそばパンが全部売れてハッピーだし、転売する人も儲かるし、多くお金を出しても食べたい人は食べれてハッピー!だから正義だよ!」って主張には違和感覚えるけど、ミユウさんの「自分のお金で何をどれだけ買うか?買ったものをどうしようが自由じゃん。」って主張はとても頷ける。けど倫理が最後に言った「他者の事情につけこみ、お金を得ること『だけ』を目的として経済活動を行う、これに私たちは不正な感覚を覚える。」というセリフは私のモヤっとを言葉にしてくれてる気がするけど、倫理ほど他者を否定する材料にはできない。正義くんと同じ立場…😂
わたしのこと
もちろん時と場合によるけど、私は自分の選択を他人に侵害されたくないと思ってる分、他人の自由(選択)を侵害したくない、自由主義的な発想を押してると思う。昔はもっとこうした方がいいよ!って自分の体験に基づくことを強く他人に主張してたけど…その時は私の幸福基準に準拠した功利主義だったのかもしれない🤔
今、テックプレイ女子部コミュニティのオーガナイザーをやってるんだけど、それはかなり自由主義に寄ってそうな気がしたので、自由主義だと仮定して良い面・悪い面を考えてみるのは面白いかも。あと運営含めコミュニケーションし合うチャットスペースを基本オープンにしてるんだけど、それってパノプティコン(監視状態による端正)的な形になってるような気がする。監視社会って生きづらいイメージだったけど、そもそも監視し合うメンバーがギュッと小さいと逆に心地良さ(平和な感じ)をもたらすのかもしれないなぁ。
最後に
おすすめ本 Advent Calendar 2020 2日目です。
久しぶりに読み返しても考えさせられる本で、この記事を書くにあたり改めて振替れて楽しかったです。
東京→地方移住者に聞く 移住前に知っておくべきことって?
この記事は Yuka さんにインタビュー & 書き起こしをしていただきました。
自己紹介を簡単にお願いします。
東京都内で生まれ育った、フリーランスの女性エンジニアです。現在、単身です。 地方移住を決めてから半年で移住しました。 新型コロナウイルスの流行前に東京へ戻りました。
移住を考え始めたきっかけを教えていただけますか。
東京にずっと住んでいたので、一度は地方に住んでみたいと憧れていました。都会暮らしに疲れを感じていた頃、真剣に移住を検討するようになったんです。
疲れの原因は、多忙な生活を送っていたことです。元々イベント好きですが、友人の誘いに乗り、休日も予定が埋まってばかりでした。週末に息つく暇がないと、仕事にも支障が出てしまいます。どうにかしなければ、と思ってました。イベントが少なく、友人のいない地方に移住すれば、一人でくつろぐ時間を確保できそうだなと。
移住先の地域はどんな所か教えていただけますか。
愛媛県です。自然が多く、生活に困らない、地方都市の近郊に位置する街です。家から徒歩5〜10分の距離にはスーパーがあり、買い物も便利でした。
『ハッピーいの町ターン』に掲載されている「田舎レベル」を使って説明させていただくと、生活に不便しないレベル1です。レベル1の特徴としては、
- 街の近く
- 電車が使える距離にある
- コンビニが近くにある
- マンションやアパートが周りにある
- 学校、病院などの生活に欠かせない公共施設が近くにある
です。 (特徴も参考記事から抜粋)
移住を検討する際に活用した情報サイトはありますか。
内閣官房・内閣府の総合サイトにある、移住支援金についてのページを確認したのを覚えています。基本的に、移住先に住んでいる知人から情報を仕入れました。
移住を機に転職されましたか。
いいえ。移住後しばらくは移住前と同じ会社でリモートワークをしていました。東京にいた時はリモートワークをしていませんでしたが、許可が降りたんです。その後、フリーランスになり、東京の会社から仕事をもらっています。
移住の準備
最低限の条件
- リモートで働ける仕事がある
- 帰る場所がある
- 最低一人は知り合いがいる
移住を検討し始めてから引越し完了まで、どれくらいの期間がかかりましたか。
半年です。 有難いことに、当時勤めていた企業でリモートワークの許可が降り、 引っ越しに注力することができました。
移住先の地域をどのように選ばれたのですか。
知人が住んでいた地域を選びました。知人が物件をいくつか見つけて、情報を送ってくれました。 移住先に知り合いが一人でもいるかどうかは、移住を成功させる上でかなり大事なポイントですよ。家の鍵を失くした時のため、スペアキーを知人に預けていました。
地方移住を検討するとき、何から始めると良いですか。
まず綺麗な家を探しましょう。地方で「綺麗な家」と呼ばれる物件は、都会の基準で見るとどうしても物足りないです。 田舎で暮らすとわかりますが、虫がたくさんいます。汚い家には色んな虫が入って来やすいので、最初は比較的綺麗な家を選びましょう。田舎暮らしに慣れてから、自分の許容範囲に応じて物件を選び直すと良いです。
どんなお家を選ばれましたか。
私が選んだのは、知人の家から10分ほどの距離にあるアパートの2階の1DKでした。都会のマンションのような綺麗な内装で、部屋も広々としています。 最初の1年間は賃料が55,000円が25,000円まで割引され、とても得をしましたね。この地域では2〜3万円の家賃で一軒家を借りられたからか、近所の方には「高いね」と言われましたが、私にとっては十分でした。
引っ越し直後にすべきことはありますか。
車を買いましょう。 東京と違って、地方の量販店は駅から離れた場所にあり、徒歩や自転車では行きにくいです。車があれば、楽に遠出できて休日を満喫できます。 私は、知り合いが手配してくれた中古の軽自動車を買いました。価格は10万円くらいです。
自転車は買われましたか。
いいえ。私が住んでいた地域では、車があれば生活に困りませんでした。国道が狭く、補正されていない道があり、自転車に乗るのは怖かったです。
移住生活
移住生活を成功させるポイント
- 綺麗な家に住もう
- 車を買おう
- 一人でも楽しめるものを探そう
引越し当初の感想をお聞かせください。
移住直後から快適な生活を送ることができました。ストレスがなくなりました。都内よりも人が少ない環境、在宅勤務が自分に合っていたのだと思います。
想定していなかった不便さはありますか。
電車が1時間に2本しか来ないことです。 電車に乗る時は時間を確認してから家を出るようになりました。移住するまで、時刻表をほとんど見た事がなかったんです(笑)
地元の人たちと上手く溶け込めましたか。
そうですね。近隣の方達とは、少しずつ仲良くなっていきましたね。散歩中に近隣の方とすれ違うと挨拶のついでに話したり、近所のマッサージ店に通って情報交換をしました。田舎は「しがらみが強い」というイメージを持つ人もいますが、程よい距離感で交流できます。
移住者と交流はしましたか。
愛媛に移住してきた人と交流したことはないです。 SNSで探せば移住者同士のコミュニティがあるので、そこで情報交換することもできます。
どんな楽しみがありましたか。
車を運転して温泉巡りによく行きました。釣りも行きたかったのですが、行けないまま帰京しました。
都内で一人暮らしをするよりは生活費を節約できそうですね。
そうでもないです。移住前後で収入は変わりませんが、車の維持費として月に3〜4万円かかっていたので。地方生活では車は必需品です。
FAQ
田舎レベル1の地域への移住はどんな人に向いてますか?
小さな変化を楽しめる人です。都会に比べると、地方は街の変化も少ないです。 散歩中に気付く季節の移り変わりなど、些細な変化に感動できる人は田舎暮らしを満喫できるように思います。
あとは、実家でも良いのですが、他に帰る場所がある人です。これは田舎レベルは問いません。新型コロナウイルスの感染者が日本で確認され始めた頃、私は帰京することにしました。これから感染が拡大するかもしれないと考えると、愛媛に留まることが心許なかったんです。いざという時に駆けこめる場所があると安心ですよね。
虫は多いですか
数が多いのはもちろん、虫のサイズが大きいです。最初の頃、とても大きなムカデが家に入って来て、追いやるのに何時間かかかりました。あと、蜘蛛がいつもベランダに蜘蛛の巣を張っていて…これは衝撃的でした。 殺虫剤で虫を殺す人もいるようですが、私は諦めましたね。ベランダの蜘蛛とは共生することにして、ベランダに洗濯物は干さないようにするなど工夫しています。
知らない土地で暮らして寂しいことはありませんか。
空港に着いた時、飲み会の後に迎えに来てくれる人がいないことに寂しさを感じます。
会ったことのない人とリモートワークするコツはありますか
私の場合、上司に自分の状況、感情を書いて伝えることを意識していました。例えば、「今日は〜という理由で簡単なタスクを片付けたいです。」という風にです。
エンジニアをされていると、周りから重宝されませんか?
かなり頼りにされます。「パソコンの修理を手伝って欲しい」と頼まれたりしていました。 エンジニアの仕事をよく理解している人は地方には少ないです。
移住先の方々によく聞かれる質問はありますか?
「どうしてここ(松山)を選んだの」という質問が多かったです。あまりによく聞かれるので、定型の回答が出来上がっていたくらいでした。
住んだこともない地域にいきなり引っ越すことを躊躇います。
移住するか悩んでいる方には、3ヶ月から半年のお試し移住をオススメします。 永住のためにいきなり家を売るよりも、旅行気分で住んでみると良いです。旅行気分で移住を体験できるプランもあるのではないでしょうか。
今は移住に関する情報を発信している媒体も多いです。移住先の候補の地域に知り合いがいなければ、自分からコンタクトを取ってみることもできます。
地方移住を検討されている方が抱えるであろう疑問点に答えて頂きました。逆に、地方の方々に伝えたいことはありますか。
その地域の良さを、もっと胸を張って伝えて欲しいです。 よく「田舎なので…」や「こんなところに…」と地方の方々は自分たちのことを下げて言っていました。謙遜のつもりで言っていたのだと思いますが、おもしろい場所や美味しい食べ物など、街の魅力を移住者にどんどん教えて欲しいです。
別の地域にも移住したいですか
そうですね。しばらくは都内に住む予定ですが、また田舎に住みたいと思っています。
最後に
移住を検討中の方にメッセージをお願いします。
東京や都市は「刺激が多すぎる」と感じる方には、田舎レベル1の地域への移住がおすすめです。私を含め、東京の人達って、自分たちが疲れていることを忘れるくらい感覚が麻痺していると思うんです。地方に移住して小さな変化を楽しんでいると、都内では得られない新たな発見もありました。
地方移住に興味はあるけど踏み切れない方には、半年か3ヶ月ほどのお試し移住をおすすめします。田舎生活が合うか合わないか分かるはずです。
基礎から学ぶ Vue.js - CHAPTER 3 -
朝活友達がブログで勉強のアウトプットをしていると聞いて、私もやってみるかという気持ちになったので書きます。
今は Vue.js を勉強中で、以下のサイトのサンプルコードをとりあえず全て実装してみて、気になったことを少し調べる勉強スタイルを実践中です。
CHAPTER 3 | 基礎から学ぶ Vue.js
以下は私が書きたくなったことしか書いてないです。
フォーム入力の取得 - 🔗基礎から学ぶ Vue.js
入力値に制約を追加したい時に便利そうだなぁと思いました。
- 住所を全角にしたい
- メールアドレスを小文字にしたい
など。
「入力値を大文字にする」をやってみた 😄👏
handleInput: function (event) { // 代入前に何か処理を行う… this.message = event.target.value.toUpperCase() }
イベント修飾子 - 🔗基礎から学ぶ Vue.js
.stop
正直どこで使うんだろう?という気持ちです。
公式サイトの説明をみても <!-- クリックイベントの伝搬が止まります -->
と書かれていてよく分からない・・。
別の記事(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 後に行動が変わったこと
- 最後に
前提
- Ruby
- Rspec 3.9.0
- Visual Studio Code
- K2iwai さん(ペア)
- kkd さん(TA)
講演(ラブコーディング付き)
ここでは私的感動ポイントをつらつら書いていきます。
きちんとした説明は実際の TDD Boot Camp に行くか、動画(50 分でわかるテスト駆動開発)もあるみたいなので、そちらを見てください。
動作するきれいなコード - どうたどり着くか
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
TDD は「動作するきれいなコード」を目指すための手段なのですが、この記事ではもう少し大きな概念の話で、「動作するきれいなコード」への道のりや、目的達成を阻む人類の性質にどう対応してきたか?今後どうしたらいいのか?など、とても面白かったです。
気になったことメモ
- 三脚椅子のメタファーの話🤣
- リファクタリングの付箋は剥がされない😂
- 単一作業に集中できる黄金の回転
- リファクタリングは弱いので、独立タスクにしない
- Unit テストと E2E テストのフィードバックの違い
「使いやすい」コードのためのテストファースト
もともと TDD という言葉は知っていましたが、「テストを先に書く」が私の頭の中で一人歩きしており・・なぜ、テストを先に?後に書いても同じじゃない?とモヤモヤしてた疑問が一気に解消されるお話でした。
「使いやすい」コードを目指す
- テストを先に書くことで、そのプログラムを使う側(読む側)の視点からテストが書ける
- 先にプロダクトコードを作ってしまうと、使う側(読む側)の視点を見えなくなる
- 作りやすいコードと、使いやすい(読みやすい)コードは違う。そして、使いやすい(読みやすい)コードを目指すべき
なるほど!🤩
「恐怖に支配された世界」から脱出するためのテスト
昔は「動いてるコードに手を付けるな」と言われてましたが、今は周りの環境(動作環境やライブラリなど)がどんどんアップデートされていくため、例え「塩漬け(手を付けない)」していても動かなくなる場合がある。
そのため、テストコードを書くことで
- 安心して既存コードに手が付けられる
- 常にこのコードは正しく動くのか?が判断できる
ようになり、安心を得ることができる。
以前、テストコードを書いていなかった時は、新しくコードを書いた部分のリリースでさえ恐怖を感じていました。そしてテストコードを書くようになった今でも、自分の書いたコードにバグがあったらどうしよう・・😨という恐怖がゼロになることは有りませんが、圧倒的に少なくなったなぁと思いますし、バグが出た時でも再発防止の修正が気軽になったなぁと思います。
テスト実装の優先順位
テストの優先度を決めるための軸は2つ。
- テストが書きやすいか?
- 重要度が高いか?
そして、最初は「1 番テストが書きやすい」Todo から倒す(テストを書く)と良い。
※ テストを書くこと自体に不慣れ・不安な場合の挫折予防です。
Todo はテストを書きやすい形にする
講演のお題は定番の「FizzBuzz」問題でした。
1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。
最初の Todo の作り方
Todo は上記に書いた FizzBuzz の問題文を元に、以下の作業を行います。
- 問題文をタスク(Todo)に分割する
- Todo 全体で表現、語尾などを揃える
Todo がどんどんブラッシュアップされてく感じはライブコーディングがとても分かりやすかったです!😍すごい!
この段階で全体を眺め、表現方法を合わせたり、粒度を揃えたりできるの良い!
テストを書きやすくする(テスト容易性をあげる)
例えば、以下の Todo があった場合
- 数が 3 の倍数のときは「Fizz」とプリントする
「プリントする」というのはテストが書きにくいのに、重要度が低い(そのテストができても嬉しくない)ので、以下のようにテストを分割する。
- 数が 3 の倍数のときは「Fizz」に変換する
- プリントする
そうすると、 (1) はテストし易くなり、(2) はテストが書きにくく、重要度が低い Todo として優先度を下げることができる。
テストは日本語(母語)で書いたほうが良い
テストコードは「動く仕様書」の要素が今後さらに強くなってくるので、母語で書いた方が良い。
テストはゴール(検証)から作る
テストで書くもの
- 前準備
- 実行
- 検証(ゴール)
テストはゴール(検証)から書こう!
なぜなら、複雑なテストの場合、前準備が数十行になってしまうと
- ゴール(検証)が分からなくなる
- ゴール(検証)を複数用意したくなる(頑張って作った前準備を有効活用したい欲)
という罠にハマってしまう可能性大!
(テストアンチパターン)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" にする
- テストの期待値とプロダクトコードの返り値に同じ具体値を入れて Green にする
- テストコードのテストをする
- 意図的に判別可能なバグを入れて Red にする(欠陥挿入)
- テストで expect "1"、プロダクトコードで return "2" にする
- 意図的に判別可能なバグを入れて Red にする(欠陥挿入)
例え 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 の場合など)
#tddbc pic.twitter.com/0C6GRbTw9p
— HITOMI@南極行きたい人 (@CorgiDaichan) 2020年2月15日
3 年後の誰か(自分を含む)のためにテストを書く
無駄なテストコードを消せるのは今の自分だけ
例えば、テストコードに不慣れで、歩幅を小さくしようと以下のように複数の値をテストした場合
- 1 を渡すと文字列 1 に変換する
- 2 を渡すと文字列 2 に変換する
今の自分にとっては安心に繋がる大切なステップでしたが、テスト全体としては「1」のテストが通れば「2」のテストを行う必要がないため、無駄なテストといえます。そして、これが無駄だと明確に判断できるのは今の自分だけです。
このテストをもし 3 年後の誰かが見た際、「この人はテストを書くことに不慣れだったらか、2 つの値を検証しているのだろう」なんて思わず、むしろ「あえて 2 つ書いてるのは意味があるのだろう。1 と 2 で挙動が変わるのかなぁ。まぁないよりあった方がいいし、プロダクトコード確認するの面倒だし、とりあえず置いておこう」と思うのがほとんどで、永遠に無駄なテストが残り続けます👹
無駄なテストを永続させないために、毎日 or 毎週など定期的に(記憶があるうちに)テストコードを整理しましょう!不慣れな自分に自信を与えてくれたテスト達を消せるのは、今の自分だけなのです!
また、3 年後の誰かは「未来の自分」の可能性も高く、過去のコードを見て「コレなんだろう・・?😕意味わからん」って思ったら自分だった😇パターンは悲しいですし(あるあるですが・・)、他人だったら迷惑かけても良いって訳でもないので、不要なテストをチェックする習慣は付けていきたいです。
足りないテストコードを追加できるのも今の自分だけ
上と同じ話ですが、もし FizzBuzz 問題のテストを書いている時、他の作業が忙しくなってしまった場合。「(1), (2) だけはちゃんとテストを書いた、(3) は目視で確認して動いてたっぽいし、残りは後でやろう〜」とか考えて放置したテストコードを 3 年後の誰かが見た時、どう思うでしょうか?
「(3) はテストが書き辛かったのかな?重要じゃないからテストしてないのかな?🤔まぁどちらにせよ、無理してテストを追加する必要はないか。変に追加して失敗しても面倒だし」になり、永遠にテストが足りない状態 & 機能追加・修正がやり辛い状態になります💀
仕様がテストコードだけで分かる状態が理想
せっかくテストが書かれていても、3 年後にプロダクトコードを確認しないと実装を理解できない状態は勿体ないです。
テストの粒度は誰がテストするのか?で変わる
「実装を知ってる人が書くテスト」と「実装を知らない人が書くテスト」は異なる(ベストプラクティスが違う)。実装を知らない人は品質保証を求める場合が多く、テストが手厚くなりがち。そして、品質保証を重視するテストにするか?はプロジェクトごとに選択できる。
意味のある数値でテストしてますか?
例えば、FizzBuzz 問題で
- 数が 3 の倍数のときは「Fizz」に変換する
をテストする時、2 つぐらいの具体値でテストしておけば品質高まるかなぁと考え、具体値を 2 つ用意する。
そして、品質保証の方から「なぜ 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 さんの拘り)引数のクラスが異なる場合メソッドを変えたい
今回のお題で「閉区間に含まれる」を表現する時
という、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 さんの言ってた通りになってる!」と思いました。
コードレビュー
前でレビューしてもらいました!
最後のレビュー、Rubyペアの発表中。愛媛でRubyペアは1組だけでした。#tddbc #agile459 pic.twitter.com/Q5CRKWogLr
— Takeshi Kakeda (@kkd) 2020年2月15日
コードレビュー後の差分です。
コードレビュー後 · 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!
TDDBC に参加したことで、たくさんの新しい視点を得れたことがとても嬉しいです。出来るところから実務に活かし、日々「動作するきれいなコード」を目指します!
また、agile459 の勉強会はいつも業務に直結するものが多く、学びが多いです。開催ありがとうございました!そして、いつも togetter してくれる HAL さん!ありがたいです。私は勉強会に参加しながらの Tweet が苦手なので、皆さんの実況を振り返りに使っています🙏✨
【自分用まとめ】TDD Boot Camp in 愛媛 #1 #tddbc #Agile459 - Togetter
個人レベルでのリモートワーク(テレワーク)について 〜歴 2 年の振り返り〜
新型コロナウイルスの影響でリモートワークの話題が盛んだし、みんチャレ友達から今のタイミングで記事書いたら良さそうと言われたので、リモートワーク歴 2 年の振り返りもかねて、リモートワークについて書きます。
ただ私はフリーランスのリモートワークなので、チームレベルのリモートワークの知見というより、個人レベルでの話になります。そして、ツールの紹介というよりは人間スキル的な話がメインです。
また結論として、下に書いてある人間スキルは「リモートワークだから必要」というより、オフィス勤務だろうとあった方が良いと思うものばかりになりました。しかし、リモートワークはノンバーバル情報がグッと減るので、これらの必要性が増すのだと思います。
↓ 長いので面白そうなタイトルをつまみ食いするぐらいがちょうど良いです。
前提
- ほぼ在宅ワーク
コワーキングスペースなどにはいきません。あまりに集中できない時だけ、短時間カフェに行ったりします。 - 田舎暮らし
- フリーランス(プログラマー)
- 一人暮らし
リモートワークが楽しくなるまでの道のり
今となってはリモートワーク楽しい!と胸を張って言えますが、正直楽しくなってきたのは最近です。以下は私が 2 年間で追ったリモートワークでの気分の浮き沈みです。
- 誰にも邪魔されない!ヤッホーい!めっちゃ集中できる
- 寂しい
- 生活が荒む・グダグダ・辛い
- 反省・改善
- 「生活が荒む・グダグダ・辛い」→「反省・改善」を 5 回ぐらい繰り返してくうちに、少しずつ「リモートワークスキル」がついてきた!
- リモートワーク楽しい(これを実感するのに 1 年半 〜 2 年ぐらいかかりました)
って感じだったので、最初の 2 ヶ月ぐらいでリモートワーク余裕だわ!って判断するのは、少し早いかもです。慣れてきてからが真のリモートワークです。
絶対必要なスキル
テキストコミュニケーションスキル(チャットスキル)
口頭でコミュニケーションを取る場合、フワッと伝えても相手がいい感じに解釈してくれることが多いと思いますが、テキストコミュニケーションになるとフワッとじゃ伝わらなかったり、前提条件を確認するだけの無駄な往復が発生するダラダラ会話になってしまうこともあるので、このスキルは必須です。
会社によっては、リモートワークでも口頭でコミュニケーションを取りやすくするために、音声会話ツールを繋ぎっぱなしにするなどの手段を取っている場合もありますが、リモートになることでオフィスにいた頃よりはテキストコミュニケーション量は増えると思うので、苦手だ・・辛い・・で完結せず、言語化することを諦めない姿勢は持っていた方がいいと思います。
テキストコミュニケーションだけで
- 細かい仕様の確認
- 議論・提案
- 悩み相談
- 雑談
ができるようになるとリモートワークがグッと働きやすくなると思います。
また、今振り返るとオフィスだった時は口頭で話したことを別の人にシェアするために、口頭の内容をテキストに起こす作業が多かったように感じます。しかも、それは結構面倒な作業なのでサボっちゃうこともあれば、テキストにしてる間に確認漏れが見つかって、何度も先輩に聞いちゃう・・みたいなこともありました😅 しかし、テキストコミュニケーションだと会話がそのまま議事録になるので、他者への共有のための作業が減ったように感じます。
もともと得意だったんじゃない?
NO です。もともと私はテキストコミュニケーションが大の苦手でした。
昔からオンラインゲームしてる人や Twitter バンバン投稿する人とかだと、チャットに抵抗ない人が多いと思うけど、私はそういうのやってこなかったので、最初はチャットで毎回メールみたいに「お疲れ様です」を付けないと失礼かも?😨って思ったり、「どういうことですか?」という質問文を見ただけで怒られたと感じてしまったり、チャットを追いすぎで開発が全然進まなかったりしてました。また、テキストコミュニケーションじゃ伝えられないから、聞くのを我慢しよう。来週会った時にまとめて聞こう。と考えてしまい、どんどん後回しにしちゃう癖もありました。すぐ電話したくなっちゃったりとかね。
なので、テキストコミュニケーションスキルが向上するまで、そしてテキストコミュニケーション環境に慣れるまでは結構辛かったです。
自分の機嫌を取るスキル
人間なので調子の良い時と悪い時、仕事が乗ってる時と乗ってない時など、浮き沈みがあると思いますが、皆さんは自分を意図的に調子の良い状態に持っていくことは可能ですか?また、調子の良い状態に持っていくために、どのような「前提条件」が必要ですか?
オフィスにいた頃はある程度人の目があるので、注意散漫な日でも仕事してる感は出せてたと思うのですが、リモートワークだと調子が悪い時は本当に集中できないし、眠くなるとその欲求に耐えられず布団に潜り込んでしまいがちです・・。ただ、その後の自己嫌悪もひどいですけどね😔
なので、常に自分の機嫌を取り、調子の良い状態を保つ力が必須です。
(私の場合)調子の良い状態を保つための前提条件
- 苦手な人と働かない
- 苦手な仕事を減らす
- 睡眠は 7 〜 8 時間取る
- お気に入りにサプリを毎日飲む
- 昼ごはんは炭水化物を抜く(食べ過ぎると眠くなるので)
- 1 週間の中である程度、 1 人の時間が必要(予定詰めすぎ NG)
- スマホの通知をオフにする(追われてる気分がするので)
私は特に誰と働くか?どんな仕事をするか?で仕事の質が全然違うということが分かったので、去年は苦手な人の排除、苦手な仕事の排除を積極的に進めてきました(これが出来たのはフリーランスならではかもしれません)
また、自分の機嫌が取れるよう努めていても、体調が悪い日も含めて、なかなか仕事が捗らない日もあると思います。特に生理がある人は週によって全然気分が違いますよね。そういう調子が悪い時でも、最低限の仕事を自分にさせるためにどうしたら良いのか?も知っておくと強いです。
(私の場合)調子の悪い時に最低限の仕事を自分にさせるための方法
- 単純作業多めにする
- クラシック音楽を流す
- 大きな声を出す・歌う
- 家の近くの散歩コースを走る
- 少し寝る
- カフェで仕事する
などがあります。人によっては食べ物などのご褒美を用意するパターンもあるかもしれないですし、人と話してると元気が出るのであれば音声会話ツールを繋ぎっぱなしにしてもらっても良いかもしれません。また、同じ場所にいると飽きるのであれば、お気に入りの場所を複数用意しておくとか、部屋でも外着に着替えた方がシャンとするって人もいますよね。
あと、不調になった時の行動パターンも知っておくこと良いです。
(私の場合)不調になった時の行動パターン
などです。自分が不調なことに気づけば、あとは不調を改善する行動を取るだけだったり、時間があれば根本改善するには?を考えることもできます。
また、この「自分の機嫌を取るスキル」は一般的な正解がないと考えているので、日々自分を観察し改善を繰り返しながら試行錯誤して「これかな?」を探していくしかないと思います。私はそれに 2 年弱かかってますし、現在も改善中です(ライフスタイルや年齢によっても変わってくるので、一生改善し続けるものなのかなぁと思います)
※ 日々の自分を観察するツールとして、私は「TaskChute Cloud」を使っています。
参考)【徹底解説】タスクシュート時間術の5つの基本ルール | ぞのjp
本当はオフィス勤務時代から「自分の機嫌を取るスキル」を知っていれば良かったのですが、たくさんの人と接触しすぎて(?)自分の不調の原因を特定しづらいですし、そもそも不調の原因を特定して改善しようなんて発想にならなかったです。。そういう意味でリモートワークをしたお陰で、自分の機嫌を以前より取れるようになったことは、人生においても有益だなぁと感じます。
あれば幸せになるかもしれないスキル
ここからは「私の場合」このスキルを付けたおかげでリモートワークが楽しくなったなぁと感じているものを紹介します。
鈍感力(即レス編)
リモートワークの記事を見てると「即レスしましょう」みたいな文言をたまに見ますが、個人的には「即レス」より「鈍感力」を鍛えた方がいいと思っています。特に知的労働であれば、ガッと集中してることもあると思うので、変に即レスを必須にせず、いつか見てくれるだろう、見てくれないなら明日もう一回送ってみよう、ぐらいの鈍感さを持ってる方がハッピーな気がしてます。
また、私は頭の切り替えが苦手でチャットの通知音がなるとチャットが気になって集中できなくなるタイプなので、チャットやメールの通知音はほぼサイレントにしてます(今の仕事の立場上、緊急ってこともないですし)そして、自分の集中力が切れる 30 分 〜 40 分に 1 回ぐらいのペースでメッセージを確認するようにしています。
脱・即レスを元にした仕事の優先順位
鈍感力を付けたお陰で仕事の優先順位も変わったように感じます。
例えば、何か悩みごとが発生してチームメンバーに相談したい時「今日中に返事が来ない」可能性を視野に入れるようなりました。そのため、複数あるタスクの中で他人に相談ごとが発生しそうなものを優先したり、一旦一通りタスクを眺めて相談ごとだけ片っ端から質問しておく場合もあります。
うまくいかない時もあるけど、相手から「今日中に返事が来ない」状態であっても、なるべく自分の仕事に支障がでないよう心掛けています。
鈍感力の鍛え方
私の場合は「自分がされて嫌だと思うこと(自分の中でのタブー)を自分がやる」です。
もともと私も即レスして欲しいタイプですし、絵文字のないメッセージに不安を感じるタイプでしたが、その原因は「自分はこんなに(無理して)頑張って気を遣ってるのに!」だということが分かったので、まずは自分が「タブー」だと思ってることをやり、「頑張って気を遣う作業を辞める」を実践しました。
最初のうちは即レスで返さない(自分の中でのタブーを犯す)ことで、仕事をサボってると思われないかな?仕事できない奴って思われないかな?など、不安でソワソワしてましたが、蓋を開けてみると、即レスの有無と仕事上の信頼関係はほぼ無縁であることを実感しました。
そして、その行動を通して、自分が即レスしたい時はすればいいし、したくない時(集中したい時)はしなくていい。また、自分が無理して頑張らなくなると、相手の行動も気にならなくなり、相手の行動に一喜一憂しない鈍感力を身に付けることが出来ました。
※ もし一喜一憂してしまっていたら「不調のサイン」と捉え、「調子の悪い時に最低限の仕事を自分にさせるための方法」を実践するのみです。
脳内ポジティブ変換(私は愛されてる)スキル
相手の言葉に勝手なネガティブ解釈をくっつけず、むしろ勝手なポジティブ解釈をくっつけるスキルです。ポジティブ変換ができるようになると相手のどんな言葉でも優しさが滲み出てるように感じたり、褒められてるような気がします(笑)
例えば最近の私の場合だと、自分の作ったプログラムで致命的なバグがテストで見つかったので(一般ユーザが管理者ページを閲覧できてしまう的な)その修正プログラムの確認依頼を担当者にお願いした時に言われた言葉について
言われた言葉
「ありがとうございます。テストで見つかってよかったです。」
ネガティブ変換の場合
「テストでこのバグ見つからなかったら、本当にやばかったです。しっかりやってくださいよ。」的な、少し嫌味な表現にも見えてしまいそうです。
ポジティブ変換の場合
「テストでこのバグ見つかったおかげで、お客様にも迷惑かけずにすみました。本当に良かったです。いつもありがとう。」ぐらいには脳内変換できるし、優しさが滲み出てるような気がします。
大前提「私は愛されてる」
心屋仁之助さんの影響を多大に受けていますが、根本的に自分は「愛される人間なのか?」「嫌われる人間なのか?」どっちだと思っているか(信じてるか)によって、脳内変換の結果が変わってくると思っています。
自分は根本的に「愛される人間」だと思っていれば、上に書いたようなネガティブなことを言われる訳がないと信じれるし、「嫌われてる人間」だと思っていれば、些細な発言でも怒ってるのかも・・と思ってしまいます。私も元々「頑張らないと嫌われる」と信じてきたタイプなので、性格改善は大変でしたが・・なんとかなりました。
詳細はこの辺の記事を読んでください。
※ もし、それでもネガティブ変換してしまったら「不調のサイン」と捉え、「調子の悪い時に最低限の仕事を自分にさせるための方法」を実践するのみです。
自分のことを伝える力
オフィスなら察してもらえるような情報を伝える
オフィス勤務で隣に人がいたら声や態度から察してくれるだろうなぁみたいな内容はリモートワークだとほとんど伝わらないので、自分から開示するようにしています。
- 体調が悪い
- 体調が回復した(元気になった!)
- これから精神的に重たい予定があるので、ソワソワしてる
- 不安・寂しい・嬉しい などの感情
- 家のことで緊急事態が起きた!
こういうのって敢えてチャットに書かなくてもなぁ・・と思いがちですが、リモートワークの場合、やせ我慢しようと思えばいくらでも出来ちゃう(誰も止めてくれない)世界ですし、インターネットの向こう側にいる同僚たちは、基本私が普通に働いてると思っているので、その認識に齟齬が生まれそうな場合(仕事に支障を来たす・来たしそうな場合)は自分で開示して、必要であればフォローしてもらう体制を作っておいた方がいい気がします。
自分はどんなことをされると嬉しいのか?を伝える
今の職場はチャットのメッセージに基本スタンプをくれないメンバーと働いていて、「心理的安全性を担保するために全員スタンプを押すべき!」とまでは思わないですが、自分がスタンプ押してもらうと嬉しい人間なのであれば、それを伝えた方がいいです。私は以下のような文言で伝えました。
もし負担じゃなければ「OK」みたいなスタンプもらえると嬉しいです。メッセージ見てるのかな?って不安になるので、スタンプもらえると安心します。(でも、面倒であればやらなくて大丈夫です、見てるだろうって思うようにします)
結果、スタンプを押してもらえるようになりました😍感謝!
また、以前の勤務先は「即レス文化」があったのですが、私はそれが苦手だったので「集中力が削がれるので通知を切っています、ごめんなさい。でも 1 時間に 1 回はメッセージを確認しています。」と伝えていました。
ただここで注意点があって、要望を伝えるのは大事ですが、自分の伝えた要望が通るか?(相手が期待通りの行動を取ってくれるか?)は期待しすぎない方がいいです。精神衛生上のために。また、一定期間経って相手が期待通りの行動してくれなくなったら、再度お願いすれば良いと思います。
Twitter で無言マージは辛いとか、文章「。」で終わるより「!」で終ってほしい、テレビ会議は顔を出してよ!など、たまに見るし気持ちわかるけど、変に我慢してベキ論でイライラするより、サクッと自分がされたいことを伝えた方が健全だと思っています。
休憩スキル
リモートワークはサボるんじゃない?と思われがちですが、普通の人は(?少なくとも私は)サボろうという発想より、見られてないからこそキッチリ成果を出そうと考えるタイプなので、頑張り過ぎちゃうことの方が多いです。また、生活空間の中に仕事場があるので「あ!あれどうだっけ?」と思い付いた時、物理的にはすぐ対応できてしまうので、根本的に仕事が好きという方は「仕事したい欲」もコントロールできた方が長い目で見て有益だと感じます。
よく考えるとオフィス勤務の時だって、たまに「ランチで喋りすぎて休憩 2 時間取っちゃった・・!」とか、「やる気なさすぎて午後はダラダラして何も進まなかった・・!」とかあるじゃないですか。まぁそういうのがいい意味で息抜きになってたと思うのですが、リモートワークだと邪魔が入りづらく集中しやすい環境を構築しやすいので、意識的に休憩するスキルを身につけた方がいいと思います。仕事は何十年も続きますからね。
ポモドーロ・テクニック
私の場合はポモドーロ(25分実行+5分休憩)を応用して、50分実行+10分休憩のペースで仕事をしています。楽しくて仕事が止まらず集中モードで 3 時間とか休憩なしにガッと働いちゃう時もありますが、そうすると結局その後の仕事や翌日の仕事で集中力が少し落ちてるので、コンスタントに働けるよう時間を区切って休憩するようにしています。
参考)はたらき方の可能性を拡げるメディア「Work Switch」サービス終了のお知らせ | ニュースリリース | パーソルプロセス&テクノロジー株式会社
仕事の断捨離スキル
リモートワークだと本当に
- 苦手な仕事
- これって意味なくない?と心が感じてる仕事
- 面倒くさい仕事
- 心理的にストレスの多い仕事(苦手な人に連絡を取るとか)
などを後回しにしちゃいがちです。
特に私は「心理的にストレスの多い仕事」を何度も頑張ろうとトライしたのですが本当に指が動かなくて・・😫最終的に周りの人に迷惑をかけちゃう・・という自体を数回やらかしてます(ごめんなさい)そのため、今では苦手な人と極力働かない、嫌な仕事は辞める、頼む、自動化・・など、積極的に推進しています。 それでもこういう仕事ってゼロにはならないので、「面倒な仕事は朝一に1つだけ頑張る!」って決めるのも有用です。
リモートワークのメリット
運動習慣を見直せる
本当に運動しないと、1 日 8 時間元気に働くこともままならなくなるので・・このままだとヤバイ!という危機感を自然と覚えます。オフィス通勤してた時の運動って、人生における+α(美とか健康とかのためにやってる)のイメージだったのですが、リモートワークだと「生きるため」に運動が必要になってくるので、本気度が変わります。私の場合、それでもまだ冬は運動をサボりがちになるので・・もうちょっと改善が必要だなぁと思っています。そして通勤って意外と運動になってたんだなぁと実感してます。
息抜きの多様化
オフィスの休憩って
- ボーッとする
- 人と喋る
- タバコを吸う
- 散歩する
- 業務外のネットサーフィン
ぐらいしかやることがないですが、家だと
- 家事
- 筋トレ
- 風呂
- 1 人で喋る
など、家でしかできないことも選択肢に含まれるので、調子の良い日の休憩では皿洗いや洗濯物、料理などが出来ちゃうので本当に良いです。でも「人と喋る」はやりづらくなりましたね。。
毎日お洒落しなくていい
社会人になると化粧やオフィスカジュアルがデフォルト的な風潮がありますが、もともと私は自分の容姿を整える行為にあまり興味がなかったので(でも、可愛くいたいって気持ちはあります!)毎日オフィスレディに変身するのは結構苦痛でした(毎日お洒落することに抵抗を感じない人、羨ましい)そしてトイレに行く度にマスカラ落ちてない?ファンデーションよれてない?を確認して・・。今考えれば頑張ってたなぁと思います。懐かしい。
意外と男性より女性の言葉の方が厳しくて「女なんだから化粧しなよ!」とか「(化粧してるのに)スッピンかと思った〜」とか言われると、うぅぅ・・😣となります。
今は家にいる時はスッピン ・楽な服ですが、たまに外出する時に化粧・お洒落すると「楽しい!」「可愛い!」ってなるので、お洒落が嫌いなわけじゃないです。「毎日」が苦痛なだけです。
部屋のレイアウトが自由
先月までは窓側を背にしてたのですが、急に部屋のレイアウト変えたい!と思い立ち、今の配置に転換しました。手前側が寝る場所です。あと、空調を独占できるのもリモートワークの強みですね。
人と会う時間を大切にできる
普段人と会わない分、人と会う予定を全力で楽しめるようになった気がします。以前は惰性的な飲み会もありましたが、今は全部の飲み会・イベントが全力だし、全部楽しい!と心の底から思います!
体調悪くなった時に即布団に行ける
結構、通勤って体力いりますよね。
在宅ワークで体調悪くなったとき秒でお布団入れるとこ好き。トイレも独占できるし。
— しいの (@Dobby618) 2020年2月6日
出勤してたとき体調悪くなっても帰る気力残ってなくて、薬飲んで会議室で寝たことあったなぁ、、つら〜
体の悲鳴が聞こえやすい
オフィス勤務時代は微熱や生理不順を放置して働いていたのですが、リモートワークになってから電車に乗る、人に会うなどの外的要因が少ないからか「あれ?今日調子悪いかも・・」が感じやすい気がします。特に私はストレスが体の不調に出やすいタイプなので、それをキャッチして改善ができるのは良いことだと思います。
仕事仲間を信頼する基準が仕事の質になる
オフィス勤務の時、最初は「人当たりが良さ」や「積極的に声掛けてくれるか?」などを基準に仲間を信頼しがちなのですが、ある程度長く一緒にいれば「あの人、口は達者だけどお願いした仕事はやってくれない」とか「あの人、最初は怖いと思ってたけど仕事は本当に頼りになる」とか、仕事の質にフォーカスが当たってくると思います。
私の場合、前職の上司が口の達者なのらりくらりタイプで、入社当初は人当たりの良さに騙されて(?)この人は信頼できる人だ、と思っていましたが、1年も一緒に働いてれば「この人は口だけだなぁ・・」ということが分かってきたので、最初の印象だけで仕事仲間として信頼できる人か?を判断するのは難しいなぁと感じます。
一方、リモートワークだと雑談が少なめなので(これはこれで問題かもしれないですが・・)最初から仕事の質にフォーカスを当てて、相手が信頼できる人なのか?を判断するようなった気がします。なので、口だけでのらくら働いてる人にとっては少しシビアかもしれないですが、私はそれぐらいの方が好きです。
真の意味でインターネットの偉大さを感じる
家にいるのに普通に仕事が回ること自体がすごいことだし、特に私はリモートワークと田舎暮らし(元々東京生まれ東京育ちです)を同時に始めたタイプなので、田舎の 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 月に開催して
Rails Grils 愛媛 後半も頑張ってま〜す😄目標は知恵熱😂#rg_ehime #railsgirls #fridayhug #rubyfriends pic.twitter.com/BRMepNwacX
— しいのあや (@Dobby618) 2019年6月15日
2020 年 2 月に Rails Girls Ehime 2nd を開催します!
Rails Girls Ehime 2ndを2020年2月7日-8日に開催します! 🎉😊
— しいのあや (@Dobby618) 2019年11月18日
女性優先、はじめてプログラミングする方向けの 1日半かけた勉強会です🍊自分で手を動かす感じです💻
参加者の募集は来月ぐらいの予定です〜🙆♀️https://t.co/8lbGXbZPpq @railsgirlsさんから
↓ この記事にはこんな感じのこと書いてます。
なんでやってるの?
自分が大学生だったときに独学でプログラミングの勉強をしたいなって思ってもなかなか出来ず・・挫折した経験があって(情報学科だったのに!😔)あのとき先にプログラミングって楽しいなぁ、プログラマーの人達って楽しそうだなぁを感じてたら、挫折してなかったかもしれないなぁと思って。
私は社会人になってプログラミングの楽しさを感じれる機会に恵まれたので今があるんだけど、大学生の私と同じように楽しさを感じる前に諦めてしまう人も多いような気がしてるので、そういう人が参加できるイベントが増えたらいいなぁという気持ちで開催してます。
なんで 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 作成」で、メッセージ文言に「プログラミング」を入れることで、心の折り合いをつけました。
プログラミングよりHPって言葉の方がわかりやすい、プログラミングって言葉を聞くだけで苦手意識かんじる人多い、わたしの写真載せたほうが安心感ます、などいろいろフィードバックもらってできたRailsGirls愛媛のチラシ🍀#rg_ehime
— しいのあや (@Dobby618) 2019年5月15日
写真はお家にいたみきゃんと pic.twitter.com/6X1KNWlnyb
2nd でやりたいこと
私もコーチやりたい
他のオーガナイザー・スタッフメンバーがとても頼りになる方々なので!
託児つけたい
1st でチラシを受け取ってくれた店舗のお姉さんに「良かったら参加しませんか?」と誘ったら、「土曜は子供がいるから行けないんだよね〜」と言われて。私に子供がいないので、あんまり託児の必要性に実感が沸いてなかったんだけど(ごめんなさい🙏)目の前のお姉さんがそう言ってるんだから、そうなのかぁという感じで。子供を理由に行けないっていうのは少し寂しいし、基本的には「やる気」と「パソコン」があれば誰でも参加できる環境を作りたいと思ってるので、託児やってみるかぁ〜という気持ちになりました。
12/8 時点(記事公開日)で、場所は確保できたのですが、あとはベビーシッターさんの会社探しや見積もり、調整など。今の時点でどうなるか分からない(12/15 託児をやるか?確定予定)のですが、託児やろうと思って動いただけでも一歩だと思ってるので無理せず、良しなになったらなぁと思います。
(追記:12/25) 託児の受付を土曜日のみ行うことになりました。詳細は以下をご確認ください。 Rails Girls Ehime 2nd(託児受付) - Rails Girls Ehime | Doorkeeper
※託児に関して参考にした記事
そして相談に乗ってくれてる方々、ありがとうございます!
野望:愛媛は広いぞ
今は愛媛で 1 番の都市、松山で開催してますが個人的には
- 今治(美味しい焼き鳥屋さん知ってるので)
- 新居浜(コワーキングスペースできたらしいので)
- 伊予市(最近 CoderDojo伊予 でお世話になってるので)
- 大三島(オオミシマスペース行きたい!)
- 内子・大洲方面(なんとなく盛り上がってそうだし)
とかでも開催したいです。
愛媛県内でのコーチ人口が 5 名超えたら何とかなりそうかも〜とぼんやり考えてます。
最後に
参加してくれる Girls のみなさんが、頭の中だけでモヤっとプログラミングに対してイメージしてたことが、イベントを通して手を動かしプログラマーのコーチと話すことで、ほんの少しでも何か変化が生まれると嬉しいなぁと思っています。
そして、運営やコーチを手伝ってくれる方々、支援してくれるスポンサーの方々、ツイッターのシェアをしてくれる方々、皆さんのおかげで 2nd も開催できそうです。ありがとう。
今後ともご協力よろしくお願いします。