Lean UX 第2版を読みました #techplaygirls #hayaoki_girls #leanux

TECHPLAY 女子部の朝活時間を利用して、年明けから「Lean UX 第2版」を読みました。

 

読み始めたきっかけは、朝活の雑談からでした。
前職で採用していた「デザインスタジオ」を取り入れた開発スタイルがとても気に入っていたという話をしていて、デザインスタジオのやり方などが掲載されている本書を紹介したところ、第2版が出ていることに気づきました。
第1版は手元にあったのですが、デザインスタジオのやり方の部分だけを拾い読みしただけだったので、全体を読んでみようと思い読書会のスタイルにして女子部メンバーに呼びかけました。

私が時間を作りやすいのが朝5時からの1時間のため、月水金の朝5時からZoomを利用したオンライン読書会というのを基本のスタイルとして、「朝5時はちょっと。。」という方はSlackでの非同期参加を可能にしました。
非同期参加のメンバーがいることを踏まえて、オンラインで読むときも「今からここを読みます!」とSlackに書き込んで各自黙読し、読書メモや会話メモをスレッドに残していきます。
非同期メンバーはそれを読んで、さらに自分のメモなどを残していきます。
該当日が祝日の時はスキップしたり、朝5時に起きれなかったり、ということもありつつ、約3ヶ月で読み終わりました。

 


本書は「リーンシリーズ」とされているうちの1冊で、「リーン・スタートアップ」を起点としてデザイン・コンテキストへの適用方法を包括的にまとめたものとされています。
はじめ「リーン・スタートアップ」を読んでいないけれど大丈夫かな?と思いましたが、私は今までいわゆるアジャイル開発と呼ばれるような環境の中で仕事をしてきたので、あまり違和感なく読み進められたと思います。
(リーン・スタートアップの思想とアジャイル開発の思想の違いについてはネットの情報をながめた程度なので、厳密には違うという理解であることをここに記しつつ、今回はこの件については深く触れません!)

 

 

まず第Ⅰ部を読み始めた時、その基本原則がものすごくわかりやすく簡潔にまとめられていて、あらためて驚きました。
たしか第1版のときも第Ⅰ部は読んだはずなのですが、簡潔に書かれすぎていてちょっと読み流してしまったように思います。
今回はそうならないように慎重に読むようにしました。
とにかく知見の塊、さまざまな場面ケースを想定され網羅されていると思います。
ただやっぱり簡潔に書かれているので、あまり読んでいてもおもしろくない部分かもしれない。。

 

 

第Ⅱ部は、基本原則を踏まえたうえで実践的な手法について書かれていて、本書の要となる「チームが共通理解をもってコラボレーションすること」「フィードバックとリサーチを継続的に行うこと」における具体的な動き方が解説されています。
私が大好きな「デザインスタジオ」がなぜ必要か、どんな成果をもたらすのか、そしてその後どのように活用していったらいいのか、ということをより深く理解できたと思います。

 

特に印象に残った部分をいくつか取り上げていきます。

 

①課題ステートメントのテンプレートが埋められない
3章の「ビジョン、フレーミング、アウトカム(成果)」ではチームの出発点としての課題ステートメントに対して、とてもわかりやすいテンプレートが提供されています。
テンプレートは既存のプロダクトおよびサービス用と、新規のプロダクトおよびサービス用にわかれています。

私が現職で開発しているサービスについて、「なんとなくわかっている」気になっているけれど、このテンプレートにのせてみてより理解を深めてみたいと思います。
さてあなたも現在開発しているサービス・プロダクトについて考えてみてください!

 

「(サービス名)」は、「(目標)」を達成することを目標にしている。
しかし、このサービスは「(目標)」を達成しておらず、私たちのビジネスに「(悪影響)」を生じさせている。
「(測定可能な標準)」に基づき、ユーザーの成功率を向上させるためには、どのように「(サービス名)」を改善すれば良いか?

 

目標?悪影響?測定可能な基準???

え、どれも答えられない。。(ごめんなさいごめんなさい)
復職したらここの確認からはじめたいと思います!!

そのあとに出てくる「ビジネスに関する前提」や「ユーザーに関する前提」についてワークシートもめちゃくちゃ参考になりました。
こちらも全然埋められないので、復職したら以下同文。

 

②プロトペルソナは更新する
ペルソナを作成する場面は多くあると思いますが、一度作成してしまうとそのままだったりしていませんか?
そもそもペルソナがチームメンバーなかで共通理解されていますか?

本書では仮説の構築と検証を継続的におこなっていくなかで、ペルソナの更新も継続的におこなっていくべきとしています。
たしかに、はじめ想定していたペルソナがあったとして、チームが学習していったり社会が変化したりサービス・プロダクトが成長していく中で、ペルソナも変化していく可能性は十分にあり得ます。
ただ、たいていの場合その変化はチームメンバーの暗黙知として流れていってしまうもので、「ペルソナが変化」していることがドキュメントとして更新されていくことがのぞましいよなぁと思いました。
ドキュメントの更新、、(また別の問題ですね)

 

③コラボレーティブなデザインでチーム全体のプロダクトIQとデザインIQがあがる
ここほんとうに大好きなところなんですけど、
デザイナー職のメンバーがつくった成果物を開発者が実装する、という流れはよくあると思うのですが、
そのときに、そのデザイナーさんのつくった成果物がどういう背景でどういう思考を経てそうなったのか、あまり理解しないで実装することもあると思います。
Lean UXでは、それだとチーム全体で共通理解ができていない、チーム全体が当事者意識をもっていない、としています。
当事者意識はひとまず置いておいて、共通理解という点は大いに共感します。
とくにデザインスタジオだったり、デザイナーさんがデザイン案を起こす前に機能要件についてデザイナーさんと開発者で話をする機会があると実感するのですが、
メンバー全員で課題を理解して仮説をたて、アイデアを提案しあうことができるので、いざデザイン案を作成するときや開発に着手するときのコミュニケーションが減らせたりスムーズだったり、ドキュメントの作成が不要になったり、いいことが多いと感じます。
本書ではその状態を「チーム全体のプロダクトIQが高まりデザインIQが高まる」としています。

職能ごとに分業することで効率化をはかることもできると思いますが、既存プロダクトに新たな機能を追加したいときなどは、チーム全体でコラボレーションすることでよりよいものが作れるのではないかなぁと思います。
(私はそんな開発がしたい!)

 

④MVPで得られるものの大きさ
MVP(Minimum Viable Product)は実用最小限の製品と訳され、確実性が証明されていないアイデアに投じる労力を最小限に抑えながら、アイデアの取捨選択に大いに役立ちます。
わりとなんでも作りたがるのがエンジニアのサガですが、ここはグッとこらえて、その仮説を最小限の労力で検証するためにはどうしたらいいか?を考えます。

 

今回この本を読んでいる間に、個人的にはじめたサービスでそれを実体験しました。

私は以前より煎茶道をたしなんでおり、お茶会を開いたりお点前を教えたりしていました。
今回、茶道具とお菓子とオンラインレッスンをセットにしたサービスを考えたのですが、そのリリース方法を悩んで足踏みをしていました。
当初考えていたのは、ECサイトを構築できるプラットフォームを利用して、セットを販売することでした。
プラットフォームを利用するとさまざまな恩恵が受けられるうえに、見た目もよいと思ったからです。
しかしそのプラットフォームを利用するまでの準備が大変に感じてしまい、かつ私が考えていた、セットの販売からオンラインレッスンまでのフローがそのサービスだけでは簡潔しないため、いろいろ思案しているうちに億劫になってしまったり、進捗がよくありませんでした。
そこで本書でMVPを項目を読み始めたときに、ふと自分のサービスについて立ち返りました。
「そもそも、このサービス利用してくれる人がいるかわからないのに、こんなに準備に手間取っているのは時間の無駄では?」
「まずはこのセットを購入しようとしてくれる人がいるのか検証したほうがいい!」
そう思い、まずは私がササッと作成できるサービスを利用してセット販売をできる部分だけ用意して、リリースしました。
(具体的には、ペライチをesaで作成して、申し込みをGoogleフォーム、連絡手段はEmailとしました)
するとリリースからひと晩で数件の申し込みがあり、このセットの需要があることが確認できたのです!
その後は、まずはその数件の申し込みからオンラインレッスンまでの流れを構築しつつ、仮説検証しながら、フローができあがりました。
次は、よりよい申し込み体験をつくるべく、新しい課題を見出しています。(続く!)

 

本書では「MVPを構築するには?」という項にこのあたりの重要ポイントがきれいにまとまっています。
ほんとうにほんとうに参考になる箇所なので、個人サービスなど作っている人やプロダクトオーナーは絶対読んだ方がいいよ!と言いたいです。(いやもうみんなすでに読んでいるのかもしれないけど)

 

実装例として笑ったのは、「嘘の機能」というどこにもつながらないボタンを設置してその需要を確かめる例で、そんなの遭遇したらイヤだ!と思いました。
あと「オズの魔法使い」の例として、(これは本書にあった例ではなくて人に聞いた話ですが)プロトタイプのAlexaは中の人が本当のヒトだったとか。。

でも実際に動くものが触れると、体験できると、そこから得られる情報は量も質も確かなものになりますね。

 


第Ⅲ部は、実際の組織の中でLean UXを実践していくにはどういった問題に直面するか、その問題とどう折り合いをつけるか、著者の実体験などにもとづいたTipsが丁寧に書かれていて、とても参考になりました。
アジャイル開発との共存方法や最後のケーススタディから学べることはたくさんありましたが、おそらくLean UXをこれからはじめていこう!という時には、第8章にある「組織に求められる変革」という項目がより参考になるのではないかと思われます。
この部分は読んでいて著者の熱が感じられたので、さまざまなクライアントと接するなかで得られた知見なのだろうと容易に推測できます。

 


全体を読み終えて、あらためて感じたのは、、

「サービスおよびプロダクトについて、チーム全体で共通理解をして、協働(コラボレーション)して、学習し続ける」
そんな環境で開発するの、めっちゃ楽しそう〜!!

私もこれまで以上に、当事者意識をもって、時には部門も横断して、チームみんなでいいモノを作っていきたいな!!と思いました。
4月からの復職前にこの本を読むことができてよかったです。

 

(ちなみにこの本は現在所属している会社の福利厚生で購入しました!)
(育休中でも福利厚生は利用できるよ!)
(え?どの会社?と思ったかたはこちらをみてね! https://www.bm-sms.co.jp/recruit/

2021年を振り返る #techplaygirls #hayaoki_girls

これは TECHPLAY女子部 Advent Calendar 2021 - Adventar 1日目の記事です。

アドベントカレンダーに参加して、1年の振り返りをしようと思って自分のブログをみてみたら、 なんと、前回の投稿から約1年が経ってしまったことに気づきました。。

振り返りの次の投稿が翌年の振り返りって、一体何をしていたんだ… といきなり残念な気持ちになりましたが、気を取り直して今年の振り返りをしました。

総括すると、今年もTECHPLAY女子部とともに過ごした1年でした! (いきなりまとめ)

ちなみに、第二子出産による産休・育休を取得中(2022年4月復職予定)のため、 お仕事関係の振り返りはありません。

新春初夢LT会

1月2日の朝6時からLT会を開催しました!

お正月の早朝からにもかかわらず、登壇者も視聴者も集まり、

LT初体験の方がいたり、今年の抱負を語る方がいたり、いい話もたくさん聞けて、

とても清々しい1年のスタートを切りました。

ちなみにLT会を無事終えて、1月5日の夜に第二子を出産しましたw

デザインパターン読書会からのERD読書会

昨年から朝活仲間の shiinoaya さんとデザインパターンの本を読んでいたのですが、

出産で一度中断し、産後2ヶ月過ぎた頃(だったかな?)から再開して読み切りました。

しいのさんが読んだ感想をブログに書いていらっしゃいます!

one-person.hatenablog.jp

Javaで書かれているサンプルコードを一緒にRubyで書き直したり(VSCodeのライブシェアでやりました) Zoomで同期的にやる時間がとれない間はSlackを使って非同期的に進めたり、

ふたりだったからこそ、その時の状況で柔軟にやり方を変えて、読み切りました。

デザインパターンの本はRubyで書かれたものもありますが、絶版になっていて入手困難です。

たまたま私もしいのさんも手元にあったので、時にはそちらも開きました。

www.amazon.co.jp

でもJavaとの違いが大きすぎて、デザインパターンそのものよりもJavaRubyの仕様のことでつまづいてしまったりしたので、いったんRuby本は置いておいて、Javaで読破することにしました。

(結局、Java本を読み切ったあとしいのさんも私もそれぞれRuby本を読みましたが、その頃には理解が進んでいて楽しく読めました!)

それにしても結城さんの本は、親切丁寧でとても読みやすいですね…!!

デザインパターン本を読み終えたあとは、続けてしいのさんと「楽々ERDレッスン」を読みました。

実はエンジニアになってすぐの頃一度読んだことがあったのですが、その時は「フーン」と読み流してしまっていました。

今回あらためて読み直しましたが、これまでに経験したサービスのDB設計やテーブル追加などの経験を思い出しながら読めたので、とてもおもしろかったです。

初めて読んだ時には気づかなかったところにもたくさん気づくことができました。

とくに付録が参考になりました。

余談ですが

この週に一度の読書会の時間だけは、第二子(通称ムスコ)を一時保育に預けたり、ベビーシッターにみてもらったり、実家に帰って親にみててもらったり、と集中して参加できるようにしました。

ムスコはわりとよく寝てくれる子ですが、それでも「何時から何時までZoomで会話する」というような約束をしづらいのが赤子のいる生活。

そのなかでスキマ時間をやりくりしてもいいのですが、週に一度だけは確実に何も気にせず時間が欲しかったので、 積極的に保育を依頼してみました。

多少、お金などはかかりますが、24時間フル稼働の母親業をすこしの間休むことができるのは、とてもいいリフレッシュになりました。

(読書会しているから休んでないじゃん!ていうツッコミありそうだけどw)

(技術に関する雑談とかもしてて楽しかったんだよ)

そしてスクラム本読書会(早朝)

10月からはおなじみ朝活時間を利用して、SCRUM BOOT CAMP THE BOOK を読んでいます。

そうです、朝5時からです。

毎日ではなくて、月水金の朝5時から6時です。

これもしいのさんと「読みたいね〜」という話になったのですが、これまでのスタイルで週に一度ペースだとちょっと時間がかかってしまう。

私が毎日時間を作れるとしたら朝時間になってしまうけど、その時間だったら時間がしっかりとれていいペースで読み進められそう、ということでこの時間になりました。

約2ヶ月ほど経ちましたが、年内には読み終わるのでは、というペースです!

私としいのさん以外に参加者はいるのか…?という心配はありましたが、 今のところ同じ育休中のちゃこさんが参加していて、それぞれの開発現場と照らし合わせながら読むのがすごくおもしろいです!!

私自身、スクラム開発自体は前職と現職で経験があるので、自分の経験を交えつつ他の方の話も聞きつつ。

読んでいるとだんだん「開発現場に戻りたい〜!」という気分になってきます。 復職までの道のりは(まだちょっと)長い。

こちらは「朝起きれないよ〜!」という方のためにSlackチャンネルでも読んでいる箇所の同期をとっているので、 あとから読んだ人はコメントくれたりして、知見を共有しています。

女子部以外の活動

女子部のアドベントカレンダーの記事ではありますが、振り返り記事でもあるので女子部以外の活動も。

Kaigi on Rails 2021 運営チーム

kaigionrails.org

今年もオンラインで開催されました!

立ち上げから仲間に入れてもらっているのですが、ミーティングはどうしても子どものお世話時間とかぶるので、なかなかお役に立てず。

そして当日も子どものことなどで穴を開けては大変なので、重要なポストにはつかないように配慮してもらって。。

しかしかなり少人数で運営しているので、すべてのポジションが重要。

けっきょく私はなんの力にもなれず、でした。

会自体は、オンラインスポンサーブースを設置したり初の2日開催をしたり、 「Kaigi感」のあるとてもいいイベントでした!

okuramasafumi.hatenablog.jp

来年も開催予定なので、運営興味ある方はぜひぜひぜひぜひぜひ一緒にやりましょう!!!!!

色彩検定を受けた(3級・UC級)

以前からWebデザイン領域に興味があって、産休育休中はデザインまわりのお勉強をすすめていきたいと思っていました。

それでなんとなく良書とされる本を何冊か眺めていたのですが、なんとなくおもしろいけど、なんか「なんとなく」から抜け出せない。

レイアウトの基本は「ノンデザイナーズ・デザインブック」や他の本にもあるように「デザイン4原則」で学ぶことができたけど、色についてはどうだろう?と思い至り、

今まで感覚的に判断していた色について、一度きちんと勉強してみようと思い、受検しました。

3級は知らないことだらけだったのでしばらく公式テキストにかじりついていましたが、 わりと高得点(ほんとは満点狙っていたけどダメでした…)で合格できたので、 UC級のほうもすんなり勉強を進めることができました。

(UC級は11月初旬に受検したので結果待ち)

3級ではまだまだ実務レベルではないといわれていますが、 配色の基礎を学んだ影響は、実生活レベルでも意外とあります。

洋服の選び方、お花の選び方、料理の盛り付け、インテリアの配色、 ちょっとした判断が必要な時に参考になります。

UC級の勉強によって高齢者と色覚異常の人たちの色の見え方について学んだことで、 ユニバーサルデザインへの意識が高まっています。

先天性の色覚異常って、日本人の男性の20人にひとりの割合でいるんです。 だいたいクラスにひとりはいる、みたいな感じです。

私の感想は「思っていたより多いな」でした。

UC級ではそういった人たちへの配慮をしながらデザインを進めていくための手法も紹介されていました。

また、高齢者について学んでいくと、近い将来自分もこうなるのか…とちょっと暗澹たる気持ちに。

将来の自分達を助けるためにも、高齢者の見え方に配慮したプロダクトを作っていきたいと思いました。

まとめ

今年は第二子の出産があり、二人育児への覚悟は決めていたつもりでしたが、新型コロナウィルスの流行による影響は凄まじく、とくに8月と9月は上の子が保育園に行かれなかったので、想像していた生活とはまったく異なる日々でした。

それによる「よかったこと」もたくさんあるのですが、やはりこうして1年を振り返ってみると「やろうと思っていたことができなかった」という悔しさは、残ります。

今年の目標で 1年を通して「3ヶ月ごとの振り返りを実施して、都度鮮度のいい目標をたてる」ようにしたい というものがあったのですが、これに対して実際は 毎月末に振り返りをして次の1ヶ月の振る舞いをイメージする ということができました。

これは本当によかったので、来年も続けていきたいと思っています。

それに加えて、年初にたてた目標を毎月ちゃんと眺める 必要がありますね。。

2020年に続いて2021年もきちんと振り返りができたので、来年もやっていくぞ!という気持ちで終わります。

2022年の目標
  • 復職(それまでにReact+TypeScriptの復習しておこう)
  • 運営をお手伝いしているECサイトの売り上げアップ!(具体的な数値目標も設定)
  • 趣味のお茶セットサービスのリリース(ECサービス利用したりして知見を深めたい)

2020年を振り返る

2019年の私をちゃんと振り返っていなかったけど、2019年末の達成感はけっこうあって、 なぜなら「子育てしながらWebエンジニアで転職できたぞ!」という自負があったからでした。

転職活動はけっこうきびしくて、それは主に自分の技術力の低さからくるものだったと思うんだけど、 だからこそ、技術力アップできる環境に身をおきたい!!という思いが強くなり、転職活動をがんばりました。

当時の私にとっての「技術力アップ」は「Railsアプリの開発をすること」だったので、 それができる環境に転職できたこと、しかも絶賛イヤイヤ期のムスメとともに、が2019年の最大のトピックでした。

そして2020年を迎え、コロナ禍とか第二子の妊娠とかいろんなことがあるなかで、 いったい自分は何をしたのか、今後何をしようと思うか、年の瀬押し迫るこのタイミングで整理したいと思います。

ひとりで振り返りをした

まず、GitHub の pull request 一覧を眺めながら、この1年どんな仕事をしたのか振り返りました。

それを月ごとに日本語でまとめて、そこにプライベートなトピックも書き足して、タイムラインを作りました。

この記事ではそのタイムラインをともにトピックをピックアップし、文章でまとめています。

ちなみに各トピックに与える影響要素として、第二子の妊娠があります。 これにより2020年12月1日より産休に入っています。

タイムラインまとめ

Rails アプリのチーム開発をした!

2019年終わりの転職をきっかけに、2020年は Rails アプリを開発するチームに所属した状態でスタートすることができました。

2019年12月に入社したので、年始はちょっと会社に慣れてきたところでした。

全般的に、それまでと異なる技術スタックだったので、何をするにも学びの多い1年でした。

もう少し具体的に書くと、インフラがすべてAWSで、構成がコード管理されていたり、フロントエンドが TypeScript で書かれていたことが一番大きかったかなと思います。

あと一部 React も使っていて、今後増やしていきたい雰囲気だったので「りあクト!」を読んだりして勉強しました。

1年やってみて、自分にとって足りないところが明確になったのはすごく良かったと思います。 今後は「RESTful な設計」と「フロントエンド開発力」を課題にしたいと思っています。

チームメンバーとのコミュニケーションで課題を感じた…のを乗り越えた!

技術面以外では、前職より少人数のチームになったのでコミュニケーションがとりやすくなるのでは!と期待していましたが、 2月の半ばにはコロナ禍の影響で完全リモートワークに切り替わり、4月と5月は保育園の休園もあってフルタイムで働くことができなかったこともあり、なんとなくメンバーとの距離を感じたまま過ごしてしまいました。

第二子の妊娠で夏頃までは私の体調も安定せず、しかしチームメンバーは皆やさしくフォローしてくださり、精神的にはすごく助けられました。

夏の終わりくらいから、スプリント(2週間)の進め方にすこしモヤモヤするところがあって、1on1で相談しつつ、チームの振り返りでも思い切って問題提起発言をしてみるなど、一歩踏み出してコミュニケーションをとるようにしてみました。

結果、プランニングやタスク・PRのレビューにいい変化があらわれて、すごく良くなったと感じています。

ひとつひとつはあまり具体的にはここで書くつもりはありませんが、ひとつやってよかった例としては、「デザインスタジオ」があげられます。

デザインスタジオは前職でわりとよくやっていたのと、個人的に好きだったので、転職してからもずっとやりたいと思っていました。

たしか入社して1、2ヶ月くらいで「デザインスタジオやるとよさそう」と発言していたのですが、 うまくその魅力をメンバーに伝えることができなかったのと、開発の流れが前職と異なっていたので、デザインスタジオを実施するタイミングがうまくはかれずにいました。

秋口になって事業に少し変化が起こり、新しい課題がみえてきたところで「これはデザインスタジオをやるチャンスでは?」という出来事がありました。

実際チームメンバーに提案してみると、今度は「よさそう」「やってみようか」という声があがり、はじめてオンラインでのデザインスタジオを実施しました。

経験者が私だけだったので、ファシリテーションをつとめましたが、最後のみんなの意見をまとめるところやその後の開発にどう落としていくといいかを共有するところに、課題を感じました。

ただ、デザインスタジオ自体に対するチームメンバーの所感は良好で、私が産休に入った後も実施されているようです!

ちなみにデザインスタジオについては「リーンUX」の「コラボレーティブ・デザイン」の章に詳しく書かれています。

TECH PLAY 女子部の朝活 #hayaoki_girls に参加するようになった!

もうこれは本当に影響が大きくて書ききれないのですが… 2月くらい(ちょうどコロナによるリモートワークが始まるころ)から5時起きあるいは6時起きを習慣化し、同じような生活リズムの女性エンジニアの皆さんと交流するようになって、いい影響がいっぱいありました。

別記事で良さを書いているので、よかったらご覧いただけるとうれしいです。

katorie.hatenablog.com

ここで重ねて朝活についてひとこと書いておくと、 仕事仲間や家族以外との雑談はすごく精神的にいい、ということです。 私はその時間を作りやすいのが朝だったので、どハマりしました。

ちなみに年明けすぐ、1月2日朝6時から、「新春🌅初夢 LT会」を企画しています。 すごい日付と時間に設定しましたが、今年は帰省できない人もいるだろうし、朝だから時間作れる人いるのでは?と思っています!

デザインの勉強をはじめた!

これまではエンジニアとしての成長を一番に考えて過ごしていましたが、 実は、私、ずっとデザイン分野に興味があって、本棚を整理していてあらためてそれに気付きました。

12月から産休に入るのをいいタイミングと思い、まずはイラレとフォトショの使い方から学び始めています。

道のりは長いですが、コーディングまで含めてひとりでLPを作れるようになりたいな…!という目標をたてています。

マインドマップを作って振り返りをした!

産休に入ることが決まり、それまでの過ごし方をどうしたらいいんだと一人悶々と考え始めたので、 マインドマップを書いて振り返りをしました。

すると頭の中がすっきり整理されて、次にするべきことが明確になり、優先順位もつけられました!

私にとっては手書きで書いていくのがよかったみたいです。

できれば毎月やるといいんだろうけど、ひとまず3ヶ月に一度くらいはやりたいなと思いました。

2021年にやりたいこと

振り返りをふまえて、来年やりたいと思っていることをまとめます。

…と思ったのですが、「年単位」で考えるとはじめはいいんですが、 きっと変更したくなったり、実際今月なにすればいいのかなと迷ったり先延ばししてしまったりすると思うので、 1年を通して「3ヶ月ごとの振り返りを実施して、都度鮮度のいい目標をたてる」ようにしたいなと思っています!

3ヶ月ごとの短期目標をたてるための長期目標としては

  • RESTful な設計を身に付けるための読書と実践(なにすればいいんだろう、アプリつくる?)
  • React + TypeScript でアプリを作ってみる
  • コーディングまで含めてLTを作ってみる

あたりを考えています。 子どもが二人に増えて、どこまでできるかなぁ〜

無理せず楽しんでいきたと思っています!

TECH PLAY女子部の #hayaoki_girls ご紹介

TECHPLAY女子部 Advent Calendar 2020 - Adventar 初日の記事です!

冬です!師走です! 今年もアドベントカレンダーの季節がやってきました。 もう今年は本当に…大変な1年でしたね。

…とうっかり今年の振り返りをしそうになりましたが、 本日は TECH PLAY女子部 の「朝活」である #hayaoki_girls についてご紹介したいと思います!

TECH PLAY 女子部

まずアドベントカレンダー初日なので、TECH PLAY女子部とは?からご説明しますと、

TECH PLAY 女子部は特定技術や特定のテーマを設けず、普段なかなか相談できない女性エンジニアあるあるや技術相談、はたまたキャリアの相談、一緒にやりたいこと・なりたい姿を実現してくれる仲間探し、など色んなテーマで集ってステキな女子エンジニアライフを送りましょう!という目的で設立を致しました。

TECH PLAY の TECH PLAY 女子部のページより引用

というこで、女性エンジニアみんな集まれ〜!というコミュニティです。(雑) COVID-19 の影響もあって最近はオンラインイベントの開催が盛んなので↑からチェックしてみてください。

TECH PLAY 女子部の朝活

それで、TACH PLAY 女子部の朝活はどんなものかというと、 こちらも今のところすべてオンラインでの開催となっています。

  • 活動場所: おもに Slack と Zoom
  • 活動時間: 毎日午前5時から7時くらい

活動時間を見て「なが!」と思われるかもしれませんが、もちろん出入り自由です。 (7時くらいまでの参加者が多いのですが、基本ルールでは9時までとなっています)

こんな感じでやってます↓

5:00 〜 5:10 zoom で雑談、お喋り
5:10 〜 6:00 各自朝活(ミュート)好きなことやってください、宣言する必要もないです
6:00 〜 6:10 zoom で雑談、お喋り
6:10 〜 7:00 各自朝活(ミュート)好きなことやってください、宣言する必要もないです
・・・繰り返し
9:00 今日も1日頑張りましょう〜の挨拶で終了

見ていただくと毎時00分〜10分は雑談タイムになっているので、ここでおしゃべりすると目が覚めます! (しかしその後もくもくタイムで二度寝する方も…笑)

私も朝ごはんの用意をしたり、家事をしたり、ただ Twitter を眺めているだけのこともあります。 あとは雑談が盛り上がってしまってそのままおしゃべりを続けることも…(ここでお悩み相談聞いててもらったことも)

とにかく、もくもくタイムに何をしたかよりも、「起きた!えらい!」という気持ちを大切にしています。 緩いです!

ハッシュタグは #hayaoki_girls を使用していますが、この言葉には 「早起きするには早寝が大事だよ!!」 というメッセージがこめられています。

睡眠時間を削って朝早く起きようとすると、つらくて続かないんですよね。 なので、まずは早く寝る習慣を心がけましょう、ということです。

私も体調をみながらだいたい5時か6時から参加していますが、 寝る時間は21時半から22時を習慣にしています。

ここまで読んで気になったかたは、ぜひ TECH PLAY 女子部の Slack に参加して、雰囲気どんなかのぞいてみてください! 緩いです!笑

朝活に参加してよかったこと

私はこの朝活に今年の2月くらいから参加しており、 途中お休みした時期もあったのですが、かれこれ10ヶ月近く続いています。

そのなかで何度か「参加しててよかった〜!」と感じたのでそれをまとめたいと思います。

健やかな「自分時間」をつくることができるようになった

子育てしていると特に感じるのかもしれませんが、とにかく仕事・家事以外の「完全ひとり時間」をつくるのにすごく苦労します。 おそらく子供の寝かしつけが終わってからが自分時間、という方も多いのではないでしょうか。

はじめは、私も子供を寝かしつけてから起きて時間を作っていたのですが、 「子供が寝たら絶対起きるぞ!」と思っていると意外とすぐ寝てくれなかったり(そしてイライラ)、 寝かしつけている自分が寝落ちしてしまったり(そしてガッカリ)、 そうなったらすぐ目が覚めるように適当に横になっていて風邪をひいたり(そしてガックリ)、 いざ起きたけれど眠くて椅子に座りながら寝てしまったり(コックリ)、 あんまり効率がよくありませんでした。。

それならばいっそ子供と一緒にしっかり寝てしまい、先に起きればすっきりした体で自分の時間を過ごすことができるだろう…!!と期待して朝活をはじめることにしました。

予想通り、はじめてみると1日のうちで一番体も元気で頭もスッキリした状態で朝活の時間を過ごせています!

「雑談」できる場所ができた

今年は新型コロナウィルスの流行で、春先から生活がすっかり変わってしまいました。 出社しなくなったし、緊急事態宣言下では同居している家族以外とは会わなかったし、 私としては小さなストレスがチリのように少しずつ少しずつ積もっていく感じでした。

そんな中、朝活はオンラインだったので続けていたのですが、 はじまりの雑談タイムで家族以外の仕事仲間以外の人と話すことで、 ちょっとした気分転換ができ、積りかけたストレスを払うことができる場所になっていました。

「給湯室の雑談」じゃないけど、友達に電話をかけるほどでもない、他愛もない話・雑談ができる場所があることが、 こんなに精神的にいいことだとは思ってもいませんでした。

時には雑談から派生して、次に書くような読書会がはじまったり、新しい Slack チャンネルが作られて交流が拡がったり、おすすめしてもらった家電を購入したり、仕事での悩みを相談したり… いろんな「きっかけ」が生まれる場所になっています。

読書会がはじまった

朝活でどんなことしている?という話をしていたら、少人数の読書会っていいよね、という話になり、 朝5時10分から読書会をするという取り組みもしました。 こちらは今は5時台ではなくなったのですが、参加者が2人なので都合をつけやすいのもいいところ。 デザインパターンの本を読んでいますが、サンプルコードが Java なので、たまにペアプロをして Ruby で書き直したりしています!

私にとってのメリットをあげてみましたが、最後に朝活に関するマイルールを。

マイルール

もちろん眠くて起きれないときもあります。 そんな時は「黄色信号が出ている」と思って、体を休めることを優先しています。

健康第一ですからね!

あと、私は夜より朝の方が元気だし活動しやすいけど、 なかには夜の方が調子いい!という方もいらっしゃると思います。 それはもう「合う・合わない」の問題でどうすることもできないと思うので、 「朝活!絶対!最高!」と思って人にお勧めしないようにしています。

24時間は平等。どう使うかは、自由。

最近の活動状況・マップという言葉

最近

6月と7月は体調を崩したりしていたので、朝活はお休み気味でした。 (起きてはいたけど、もくもくはあまりしていなかった)

相変わらず TECH PLAY 女子部の朝活に参加しているので、 そこで2月(だったかな)にはじめたデザインパターンの読書会は継続中。 あと最近Go言語の読書会もスタートしました!

Goならわかるシステムプログラミング

Goならわかるシステムプログラミング

  • 作者:渋川 よしき
  • 発売日: 2017/10/23
  • メディア: 単行本(ソフトカバー)

まだ序盤ですが、ポインタ型とか「???」でググりながら…

毎日暑くて普通に生活するのがしんどいですが、体調は戻ってきたのでリズム整えていくぞ!

マップ

「マップ」と聞くとつい名詞の「地図」を思い浮かべてしまうんだけど、 動詞としての「なにかとなにかを対応づける、関連づける」という意味のほう。マッピング

マップはES2015で導入されたので、それ以前はオブジェクトをマップとして使用していたとのこと。 しかしこれは意図しないマッピングが生じたり、 プロパティとして値を持つので文字列しかシンボルしかキーに使用できない、 という問題がある。 マップはプロパティとは異なる値の持ち方をするため、プロトタイプがもつメソッドやプロパティとキーが衝突することは、ない。

最近の活動状況

TECH PLAY 女子部のSlackチャンネルのひとつに、朝活をする人たちが集まるチャンネルがあって、 そこをベースに朝5時から活動しています。 最近メンバーが増えて(COVID-19による在宅勤務が増えた影響かな)、Twitterハッシュタグ #hayaoki_girls をつけてつぶやくことも増えました。

私は最近は #jsprimer 「JavaScript Primer」をオンラインで読んでいます。

jsprimer.net

ほんとうはオライリーの「プログラミング TypeScript」を読みたいんだけど、その前にJavaScriptにちゃんと入門しようと思ったからです。

はやく業務に活かしたい。

Firestore のセッティングではまった

GW前くらいから朝活の記録をする時間がなかなかとれなくていたのですが、細々と活動は続けています。。

今はりあクト!シリーズ3作目をやっています。

oukayuka.booth.pm

Firestore のセッティングではまった

本の通り順調に進めていましたが、 1-2. Firebase プロジェクトの作成と初期化 のところで、 Firestore Setup でエラーがでました。

=== Project Setup
? Please select an option: Use an existing project
? Select a default Firebase project for this directory: mangarel-demo (mangarel-demo)
=== Firestore Setup
? What file should be used for Firestore Rules? firestore.rules
? What file should be used for Firestore indexes? firestore.indexes.json

Error: Error fetching Firestore indexes

ちょっとググってみましたが、これはGCPコンソールで - Firestoreの設定を Datastore モードから Native モードに変更 - API の有効化 のふたつを実行する必要がありました。

おなじところではまる場合は debug オプションをつけて Firebase 初期化をおこなうと、ヒントが得られます!

$ firebase init --debug