2022 年（令和 4 年）の振り返り
去年 に引き続き、振り返ります
今年は文章を書く気力をどんどん失って、過ぎ去ったことを言葉にするのが難しいです。 前は少しずつでも文章を書けていたのに、いまは待てど暮らせど文章が出てこないのです。きっと文章を書くときは「ちゃんとしなきゃ」が発揮されてしまうのでしょう。そして去年までは「ちゃんと」できてたのだと思います。でも今年は「ちゃんと」センサーが発動しないので‥ゆるい文章になりそうだけど出てくる言葉を残します。
1年の振り返りワーク
今年もやりました、1年の振り返りワークシート。去年は The Coach メンバーと一緒に行いましたが、今年は TechPlay 女子部のメンバーと行いました。やっぱり一人で振り返るのと誰かに1年を語るのとでは心にじんわりくる感じがまったく違うので、来年も誰かとやりたいです。
振り返ってみてどうだったのか？
なんか色々もがいてる気がした。いろんなことを始めたい感覚と、なんかしっくりこなくて軌道修正してる感覚と。一生懸命に何かあるんじゃないかって広くなのかな、深くなのか探してるけど、既に作り始めてる感じもする。もがいてるって表現するとネガティブに聞こえちゃいそうだけど、私自身はネガティブに捉えていなくて、もがきたい時もあるし、もがく元気があるのは良いことだと思った。だって何もせずにずっと寝てた時期もあるから。あぁ年取って涙もろくなったわ。過去を振り返ると昔の自分が愛おしくて泣けてくる。
多分来年ももがくと思うんだけど、今年よりは解像度上がってる気がします。
チャッピーが我が家にきた5月
在宅ワークの最大の敵は運動不足。何度もチャレンジしたジム通いに終止符を打ち、私が運動するにはワンコを飼うしないと判断。すでに猫がいるのに我が家に犬を迎え入れました。元々は大型犬を考えてたんだけど、友達から大型犬は15キロ以上あって犬の体調が悪いときにその重さを持ち上げられないなら飼うな！と言われて小型犬をを探しました。吠えなくて愛嬌のある犬を飼いたくてパグに。実際、我が家にきたチャッピーはほとんど吠えないし（いびきはうるさいけど）、愛嬌120%です。最近はコタとも仲良くなって一緒に寝たり戯れたり、毎日の散歩の成果で前より元気に駆け回れる体力がついてきたのもよかった。来年はパグ MeetUp デビューを予定しています。
コロナになった8月
親からウィルスをもらい39度超えの熱が出た。久しぶりに熱で起き上がれなくて、コロナ専用のコールセンターに電話したとき担当の方に泣きながら症状を伝えました。私の住んでいる地域は幸いにコロナ対応の病院に空きがあったので2時間後には受診、次の日にコロナ判定の電話。県からお粥や缶詰などの緊急食材をもらえたのが新鮮でした。病院の解熱剤で熱は下がったけど、結局3週間の倦怠感で5キロ痩せた。。咳の後遺症はいつも通っている鍼治療のおかげで治りました（マジ感謝）。風邪をひくと改めて元気であることの喜びを感じますね。元気が一番。
おわりに
他にもいろいろなことがあったのだけど、今年は振り返るのが難しい。でも振り返りシートは作れてるから、出来事たどれば 2022 年を思い出せるでしょう。今年はこんなもんで無理しなくて良いのじゃないかなと思った。ではまた来年 👋 I Love Ayachan!!
（途中）読書メモ：SQL アンチパターン
SQLアンチパターン の読書メモです。
ジェイクウォーク（信号無視）
多対多の関係の場合に交差テーブル（中間テーブル）を作らず、参照先を1フィールドに「カンマ区切りのリスト」で格納するのはアンチパターン。
これはやらないなぁ。
交差テーブルを作るメリットとして以下は大きい。
交差テーブルにさらに列を加えることによって、各エントリに属性を追加できます。例えば、製品に連絡先が追加された日付を記録したり、連絡先の優先順位を示す属性をつけたりできます。
私は多対多の関係を表すテーブルのことを「中間テーブル」と呼んでることもあり、名前からは内容が想像できなかったパターン。Wiki では 連想エンティティ - Wikipedia や 連想テーブルだった。英語ではなんて呼ばれてるんだろう。
多対多関連のテーブルの呼び方ってどれが一般的なんだろう。SQLアンチパターンでは「交差テーブル」を使ってるし、他にも「中間テーブル」あたりはよく聞く。 英語版Wikipediaではcross-reference tableがjunction tableにリダイレクトされるが。
— 局所解 (@s_osa_) 2013年12月17日
そして交差を避けるから信号無視なんだって。
ナイーブツリー（素朴な木）
組織図やスレッド形式の掲示板のような階層構造を実装する場合、ノードが parent_id を持つことで階層を表現する隣接リストと呼ばれる設計をするのはアンチパターン。問題点は隣接していない子孫へアクセスして集計などをする操作や、途中のノードを削除してノードを昇格させるなどの操作が難しくなる。
階層構造を実装する設計方法として以下がある。
- 隣接リスト（アンチパターン）
- 隣接リスト ＋ 再帰クエリ
WITH キーワードの後に共通テーブル（階層構造の Path 列がある）式を指定する形式を用いることで、隣接リストに格納された階層構造をサポートする。ただし、全てのデータベースでサポートされているわけではないので注意が必要。
※ MySQL は 8.0、PostgreSQL は 8.4 でサポートしている
参考）再帰CTE（共通テーブル式）で階層構造のパスを作る - 経路列挙
経路パス（ファイルシステムのパスのような文字列）を格納する列を保有する。ただし、ジェイウォークのように長さの制限（階層の深さの制限）があったり、参照整合性を DB で維持できないのが欠点。 - 入れ子集合
ノードのレコードは自分より下の階層にあるすべてのノードが持つ値より「小さな値」と「大きな値」を保有することで階層を表現する。得意なことはサブツリーに対するクエリ実行で、欠点はノードの挿入や移動をすることで関係する全てのノードの再計算が必要になるので複雑になりがちなところ。 - 閉包テーブル
階層パス情報を格納するテーブルを別に作る。
参考）テーブル設計まで細かく書いてくれてる。
階層構造(a.k.a ツリー構造・ディレクトリ構造・フォルダ)をDBでどう設計すべきか - @teitei_tk Blog
子孫へのクエリ実行や参照製合成の意地などを考慮すると、再帰クエリが使える環境であれば再帰クエリを、それ以外であれば閉法テーブルが良いのでは？
自分が階層構造を実装したら…？を考えると隣接リストしか思い付かなかったけど、、読み進めていくうちに以前、階層構造を実装したときは入れ子集合モデルのライブラリ使っていことを思い出した。なんかいい感じに動いてるってだけでライブラリのことをよく知らずに使ってた証拠だね。。反省です。選択肢と選択肢ごとのメリデメを知れたので、今後はライブラリ選定に活かしたいです。
＊Rails の場合
（参考）Railsで木構造を扱うには｜TechRacho by BPS株式会社
- 隣接リスト / awesome_nested_set
- 経路列挙 / ancestry
- 入れ子集合 / awesome_nested_set
- 閉包テーブル / closure_tree
※ 直近の親や子にアクセスするクエリをより容易に書く方法として、ノードテーブルに parent_id を持たせている。
ID リクワイアド（とりあえず ID）
すべてのテーブルに主キーとして「id」列を用いるのはアンチパターン。
まさに私は Rails に依存してることもあり、何も考えずに id 列を生成してる。。
id という名前は明確な意味を持っていなから、bug テーブルなら bug_id にした方が良いという主張について。いやいや SQL で table 名を付けて列を指定（bug.id）すれば良いじゃんと思ったんだけど、以下の主張に確かになぁとなった。
主キーは「あるテーブル上の1つの行」を識別するためのものなので、主キーの列名でもそのテーブルの種類がわかるようにしておくべきです。そうすれば「bug_id = 1」という情報だけで、データベース上の1行を特定することができます。
あと主キーと外部キーの名前を揃えることで結合条件を on 句の代わりに USING でっていうのも良かった。USING って新人研修的なので習った記憶ある。
これを読んだうえでも主キーを自然キーにする場合以外、すなわち擬似キーを作る場合は id 列にするだろうな。
キーレスエントリ（外部キー嫌い）
外部キー制約をしないというアンチパターン。
具体例ではまだ外部キー制約をサポートしていない MySQL の MyISAM ストレージエンジンを使っていたから、参照整合性を満たせなくなって、数字の不整合やデータの重複が発生して。そのためにゴミレコードを探すようなスクリプト書いて対応していたそう。
そうか、外部キー制約がなかったときもあるのかぁ。外部キーがなくても良いと思ったことはないけど、強く必要性を求めたこともなく一度つけ忘れたことがあるので、改めて参照整合性の大事さを感じた。
外部キーで関連付けられたレコードに対してどのように対応するかは Rails で書いてしまう（Active Record の関連付け - :dependent）ので、DB 側でも同様の機能をサポートしてること知らなかった。
参考）MySQLの外部キー制約RESTRICT,CASCADE,SET NULL,NO ACTIONの違いは？ - Qiita
EAV（エンティティ・アトリビュート・バリュー）
EAV はカラムの可変性をサポートするために Key, Value のようにデータを格納するパターンで、これを使うことがアンチパターン。
EVA のデータ構造。
RDB はそもそも EAV に対応してない、外部キーもデータ型も集計でも使いづらいので基本は使うな。EVA したいなら Key Value で格納できる DB を使うこと。
この記事が分かりやすかった）SQLアンチパターン勉強会 第五回：EAV(エンティティ・アトリビュート・バリュー) - Qiita
アンチパターン回避策として
2021 年（令和 3 年）の振り返り
去年に引き続き、今年も振り返りますよ。
1年の流れ
今年はコーチング仲間が募集していた振り返り会に参加しました。この振り返りでは事前にワークシートに今年一年のイベントごとやメモを書き込んで、当日はこのワークシートをもとに他の参加者に自分の一年を物語として伝えるというもの。話してる途中や最後に他の参加者から質問を受けて自分の一年をさらに深堀していくという形でした。
ワークシート
感想
自分でワークシートを作っていたときは物語として語れるのか心配してましが、いざ話してみると一貫した物語のようだったと言ってもらえて嬉しくなりました。自分でも確かに繋がっでるわ〜って実感できたし。人に語るってすごい。
他のメンバーからの質問を通して、Bob の講演で内面的に影響を受けた後から少しずつ現実が変化していったことを改めて認識。今年の最初には想像も出来なかった年末を迎えて一年のプロセスも結末も素敵すぎるなぁと思えた。ありがとうAyachan🥺おめでとうAyachan🎉
あと他のメンバーの物語を聞いて、セッションのような「ここはどんな気持ちだったの？」って問いが沸いてくる沸いてくる。THE COACH メンバーどうしだからこそ寄ってたかって語り部にコーチングしてるみたいな雰囲気になって面白かったです。来年もやりたい！
今年終わった読書会
Team Geek
Team Geek 読書会の感想 #techplaygirls - FreeDrop
Clean Architecture
クリーンアーキテクチャ読書会の感想 #techplaygirls - FreeDrop
デザインパターン
デザインパターン読書会の感想 #techplaygirls - FreeDrop
Domain Driven Design（ドメイン駆動設計） Quickly
Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
DDD を読むきっかけになった Podcast で DDD 本のコードは古いと言っていたので、概念を学ぶ目的であれば quickly 版でも良さそうと思って読書会を始めました。
ユビキタス言語を作ることの大事さ
そのプロダクト（ドメイン）に関わるメンバーが同じこと言葉で話せるようになる必要があり。 例えばプロダクトオーナーは従業員と呼ぶけどコードでは user を使ってるのはダメとか、プロダクトオーナーは退会したいって言ってるのに技術者は論理削除って言ってたら共通言語じゃない。共通言語を作る過程で認識を合わせていくことこそドメイン駆動なんだと理解。ただ日本語圏の私たちは会話は日本語だけど英語にすると認識バラバラみたいなのがよくあるから、日本語、英語のユビキタス言語を作る必要があるなぁと思った。
あと Evans 氏の英語圏以外は DDD どうしたら良いの？の回答。
"(DDDを)英語以外の言語ではどう実践すべきか" "Evans氏発言要旨: ソースコードでも日本語を使え。以上。" "ドメインエキスパートがこの言葉を使っているのなら、なぜクラス名にこれを使わない？" / “A Life in…” https://t.co/iyT7Anqncg
— Takuto Wada (@t_wada) 2017年5月12日
実現は難しいけど DDD の思想としては一貫しててめっちゃ納得した。
軽量 DDD
もう一つは技術的な面での DDD です。巷では軽量 DDD と言われてるものという認識。 DDD で語られる要素は広く Entity や Value Object、Repository、Service とかかな。
・Entity → 識別子によって等価の判定をする。 ・Value Object → 値によって等価の判定をする。 ・Service → 内部に状態を保持せず、単純に機能だけを提供する
技術的な部分はもう一度読み直したい。
この辺の知識を得たことで「プロダクトで DDD やってます」的な記事ではどのレベルで語ってるのか深く観察できるようになったし、DDD の文脈で語ってる記事も理解できるようになったのは成果です。
楽々 ERD レッスン
DB 周りの復習本。DB のビュー機能を使うポイントが自分の選択肢になかったので仕事で使えそう。 途中 DB 設計するのに飽きちゃったけど、karorie さんと一緒に「この場合どうなるだろう？」と考えれたのは楽しかった。
スクラムブートキャンプ
SCRUM BOOT CAMP 読書会の感想 - FreeDrop
これまでのスクラムチームは少人数制だった分コミュニケーションコストが少なくて課題が見え辛かったと思う。だけど今月まで配属されていたチームは開発者だけで10人ほど、他の関係者合わせると20名以上いたので、どうすればより良いチームになるのか考えざるおえなくなったし、課題感を持った状態でスクラム本を読んだことで体に染みる学びになった。次のチームでは組織としてチームの作り方をどう分けていくかの指針としてチームトポロジーという考え方を取り入れてるようで（全然わからん）、組織やチームの在り方って技術のように常にアップデートされてるんだなって思った。面白いね。
その他の学び
今年は元気がなかったから全然勉強できなかった…仕事は過去に勉強したもので食い繋いでる…なんて思ってたけど、こうやって並べると新しいもの学んでるじゃぁ〜んと思えた（Ruby / Rails をやってないだけ🥲）。やったことリストは偉大です。
生産性向上には「やることリスト」より「やったことリスト」が効く！ おすすめアプリもご紹介 - STUDY HACKER｜これからの学びを考える、勉強法のハッキングメディア
TDD の写経をオンライン配信
Ayaのページ | 作業中×ライブ配信 - 00:00 Studio
勉強風景を生配信するのは自分の集中力が増すので良い。来年は Youtube で Study with me 的なことをしたい。
本の内容的には普通に難しくて自分じゃ思いつかないよ…って感じのコードでした。。新しい言語を学ぶときはこの本を写経をその言語でやりたい。
AWS（ソリューションアーキテクト）に合格
仕事のインフラ環境で AWS 使ってるのは当たり前だから、お客様とコミュニケーション取るのに最低限の AWS サービス知識を知っておかないと会話できないと思って受験。愛媛にいたときに一度落ちて、AWS の試験がバージョンアップしたあとにもう一回チャレンジ。フリーランスの仕事が始まる前の、日光の Airbnb に住んでた時期だったなぁ。Udemy の試験対策の問題購入して過去問繰り返し勉強した。
勉強したおかげで デプロイ周りで利用する CodeCommit / CodeBuild / CodeDeploy を知れたし、今は EC2 じゃなくて ECS（Elastic Container Service）だってことも知れた。今の案件でめっちゃ役に立ったよ。勉強中に気になったのはロードバランサを使うときのセッションの管理方法。これは来年に改めて勉強したいです。
Haskell かじった
読書会ではないのだけど、もっちーとアウトプットする日程を決めて勉強したやつ。
仕事で Vue.js
去年は Rails をちょっとリッチにするって目的で Vue.js を導入してた案件にいたけど、今年はフロントとバック完全に分けて Vue Router や Store を使いながら開発する案件に入れて、Vue.js をさらに深く学ぶことができた。さらに Vue.js 経験者が周りにいたので Js の細かい点を確認できたし、Composition API や TypeScript もかじれて満足してる。
来年の課題点としては
コードレビューはまだまだ難しい
もっと良くするのにこう書いたら良さそう的な知見がないし、コードレビューしてても目が滑っちゃいがち。Rails のコードレビューも最初は目が滑っちゃってたので数こなすのが大事だよな…。
TypeScript 周りの知識が全然足りない
ジェネリックとか全然知らんままだったし。次回チャレンジするときは言語として機能をきちんと勉強して望みたい。
参考）TypeScript始めたての頃知りたかったこと - Qiita
Composition API を活かした書き方ができなかった
Composition API が入る前は Vue.js の構文ルールによってライフサイクルメソッドや computed、methods など役割ごとに処理を書く必要があったんだけど、Composition API の導入で全て setup の中で記述するので使用目的ごとに処理が書けるようになったことが大きな変化だと認識してる。だけど、前の書き方に引っ張られて役割ごとに並べて処理書いちゃったり、ファイルを分割するポイントが全然分からなかった。。
課題が認識できてるだけ十分。少しずつ進んでいきましょう！
コーチングスクール受講
THE COACH Academy 受講後の振り返り - FreeDrop
直感で「やりたい！」と思って受講したのが本当に正解だった。これまで悩み相談されたときの私の対応が「自分の経験談からアドバイスする」か、「ただ『うんうん』と聞いてる」かの2パターンしかなかったけど、コーチングを学んだことで傾聴による相手の声のトーンや表情の観察、裏側にある願いの予測、状況や気持ちを詳しく知るための多面的な質問などができるようになった。相手の魅力や想いを引き出すコミュニケーション方法って感じ。
THE COACH の授業はスキルを学んだというより、考え方の根本から変わる体験をさせてくれるので自然と日常でのやりとりもコーチングマインドが混ざってくるから不思議。この前、小学校からの友達の悩み相談でも自然と友達が次のアクションを決める流れになって、無理に私が誘導する必要ないんだって分かって感動した。仕事でもチームのファシリテーションとか 1on1 する人とか、そういう役割もやってみたいと思えるようになった。
今年を一言にまとめると
自分を信じ始めた年。これまで先が見えないとすぐに不安になってコントロールしようと行動していたんだけど Bob の講演から自分に足りないのは自己確信的なマインドだって気付いて。いまは不確実な状態でも自分なら必ず道を見つけることができる、私なら大丈夫って信じれるようになった。今年最大の成果だよ。そして一年を振り返るとほんとに良いタイミングで次の一手に導いてもらえた気がする。ありがとうAyachan🥺（2度目）。人生を無理にコントロールしなくても繋がっていくんだなぁと心の底から感じれる一年でした。おつかれAyachan😌
来年
いまは組織やチーム作りをすること、コーチング的な関わり方を通して人の魅力を引き出すことに興味がある。今のチームの EM さんのように「失敗は学習する機会」を強調できる人になりたい。あと正社員就職するのが大きな変化だよね。どんな展開になるか分からないけど自分の内面を語れる関係性、人間関係を築けるように関わっていきたいな。がんばれAyachan👍
SCRUM BOOT CAMP 読書会の感想
katorie さんと chako さんと共に朝5時に起きて読書会をしました。久しぶりの5時起き頑張りました〜。
概要
公式のスクラムガイドを元にスクラムの基本とスクラムあるあるを漫画形式で知れる本。
読む前の気持ち
1,2週間に1回のスプリント、リリース、振り返り。仕事では当たり前になってたけど、アジャイルやスクラムの基本を勉強したことがなくフワッとした状態で実践していたので、うまく回っていないときにやり方を見直す指標がないというか、チームとしてどう仕組みを変えていったら良いのか目星が付かないなぁと漠然と悩んでる状態でした。
だからアジャイルやスクラムの基礎がわかる本を読もうと思ったんだよね！
読み終わったあと、いまの私、いまのチームを振り返る
PdM と PM の違い
今のチームでは PdM（プロダクトマネージャー）という役職の人がいて明らかに PM（プロジェクトマネージャー）との違いを表現してるんだけど、私の中では PdM でも PM でも「仕様どうなってますか？どうしますか？」って聞く相手であったり、ガントチャートを作って全体のスケジュール感を握ってる人的な認識だったので、違いを理解できませんでした。。
「プロダクトマネージャーとプロジェクトマネージャーの違い | AIdrops」では
プロダクトマネージャー
「何を」「なぜ作るのか」を担っているのがプロダクトマネージャーです。なぜ作るのかといえばそれは顧客の課題解決を図るためで、何を作るのかはすなわちビジネスモデルに直結します。プロジェクトマネージャー
「いつまでに」「どうやって作るのか」を担うのがプロジェクトマネージャーです。これはすなわち予算やスケジュールの管理に当たります。
この記事読んで、これまで PM が担ってた「どうやって作るのか」の部分をスクラムでは開発チームが担うことになるのかな。
プロダクトへのフィードバックができていない
今のチームは既に PdM とデザイナーが UI / UX を考えてくれるので、開発チームからプロダクトに対してのフィードバックをあまりしない状況。振り返りも開発者メンバー内で行うので開発者どうしのコミュニケーション問題だったり、コードの品質問題に終始している感じ（もちろんこの内容も大事だけど）。同じスクラムチームなのに開発者は PdM やデザイナーが抱えてる問題を認識できてないし逆も然り。振り返りする単位が改善できる範囲の限界な気がするので、やはり振り返りはスクラムチーム全員でやりたいよね・・。
来年に就職する会社では「どうやって作るのか？」を開発者が考えれるチームに入る予定なので、もっとこういう方が使いやすいとか（A/B テストとかして）そもそもこの機能は画面でやる必要がないかも？とか、UI / UX に対してフィードバックできる開発者になりたいな。そして katorie さんから教えてもらった コラボレーティブデザインも試してみたい。
振り返りが個人の反省になりがち
振り返りの内容が「自分の技術力が足りませんでした」的な個人の反省になりがちな現状。改善するには視点の転換が必要そう。この本では振り返りのことはほとんど触れられてなかったので別の本も読みたい。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き | Esther Derby, Diana Larsen, 角 征典 |本 | 通販 | Amazon
紛争を避けがち
自分はこれが正しいと思う、こっちの方が良いと思うって意見言うの苦手で、正直そんなの当たり前じゃん！なんで分かってくれないの🤨って思ってストレス抱えちゃってる…。自分の意見に自信がないのもある…。
ただタックマンモデルでも「混乱期は必要なこと」と言われてるように、紛争はお互いの価値観や前提条件を合わせることだから。短期的に見たら相手に合わせておく方が楽なんだけど、長期的に見ると混乱期に手を抜いたり我慢したりしたら自分にとって最高のチーム（納得感を持って開発ができるチーム）は永遠に訪れないよなぁ…と思ったり。
紛争は悪じゃなくてより良いチームを作るために必要なんだ！という認識を持って前向きに取り組みたい。
チームビルディングでファシリテーターである私が初めに話すこと｜タックマンモデル | 今が最高のプレゼント Present is the best gift
やってみたい
インセプションデッキ（SCENE NO.2）
インセプションデッキはスクラムチームの向かう先の認識を合わせたいときに作りたいもの。一方的にプロダクトマネージャーから説明を受けるだけだと疑問や不安を抱えたままになってしまうので、プロダクトマネージャーが叩き台を作ってスクラムチーム全員で議論していくのが良い。
インセプションデッキを作ることでスクラムチームが自分たちに期待されていること、すなわちゴールやミッションを毎日意識して作業することができる。ただし、本質的にはインセプションデッキを作れば OK なのではなく、ゴールやミッションの認識を擦り合わせる場を作るためにインセプションデッキを作っているだけ。インセプションデッキがあればスクラムチーム全体に大事なことを浸透されていると思わないように。
chihiro さん曰く、チームメンバーが自分たちの作るものやそれが生み出す価値について興味があるかも重要と言ってて、そりゃそうだよなって思った。その温度感大事。
ユーザストーリー（SCENE NO.16）
プロダクトバックロでうまく開発者にプロダクトオーナーの意図が伝わらないときに試したいこと。
ユーザストーリーとは？
実現したいものを実際に使う人たちの立場で表現する伝え方。
なぜ必要？
プロダクトオーナーは何を実現したいかについて考えているし、開発チームはどうやって実現するかを考えている。各自が責任を持つ部分に集中できる利点がある一方で、考えている部分が違うので誤解を生みやすいから。
フォーマット
＜どういったユーザや顧客＞として
＜どんな機能や性能＞がほしい
それは＜どんなことが達成したい＞ためだ
大事なこと
フォーマット3行目の「どうして必要なのか？」という理由を伝えることがすごく大事。意図が書かれていることによって、スクラムチームは動きやすくなる。
たとえば、「営業担当として、自分宛てのメッセージを外出先で見られるようにしてほしい」だけでなく「それは移動中でも商談に関係する仕事上の重要な連絡を見逃さないためだ」という意図を開発チームが知っているとする。開発チームはユーザストーリーをを実現するときに、モバイル端末で見ることが多そうだからもっと大きい文字にしようとか、重要なメッセージは赤で目立つようにしようといったことが考えやすくなる。 そして、何かの項目をあきらめるときにも、こうした意図は大事な判断材料になる。
判断材料があると動きやすいの確かに🤔
ユーザストーリーはあえて短い
短く書くことでスクラムチームが話し合う機会を頻繁に持つようにしている。（そうなんだ😲）
何を作るかは開発者が決める
これは chihiro さんに聞いた話。
達成したいことが「アプリの利用状況を確認したい」だと、
誰が？（マーケティング部？開発わりとわかる人？）
どこまで（とりあえずログイン数なのか、〇〇機能を使っている人の数なのか・・）
なんのために？（上司に報告したい？マーケティングの調査に使いたい？）
とかで掘り下げる。そうすると開発チームはこれってそもそも画面必要なくて、定期的にCSVに吐き出したデータ渡せば良いのか？など、どうやってユーザストーリーを達成するか？（何を作るか？）の議論がしやすい。
何を作るか？を開発チームで議論するチームにいた経験がないのでユーザストーリーから考えていくスクラムチーム、プロダクト作ってる感あって楽しそう😎
最新のスクラムガイドをチェック
そもそもこの本を読んでスクラムガイドなるものを知ったのですが、スクラムガイドは定期的に更新されてるそうで。この本でも 2017 年時点のスクラムガイドを元に作られているのですが、2020 年にスクラムガイドが更新されたので気になった部分を取り上げます。
スクラムガイド2020のアップデートについて - Scrum Inc. Japan #TeamworkMakesTheDreamWork
朝会で話すことが変わった
「昨日やったこと」を話すことにあまり意味を感じてなかったので、朝会でどんなことを話すと良いのか？からチームで考えれるの良さそう。
開発チームはなくなり、スクラムチームだけに
いまでも開発チームと PO とデザイナーチームに分かれてしまっている現状なので…そもそも開発チームという線引きをなくしてしまうのは良さそう。
参考）
感想
読書会を通してこれまで向き合ってこなかったチームの在り方を考える良い機会になりました。ひとまず現状でもチームは回っているし、もう少し様子見しよう、と後に後に回してる改善っていっぱいあるなぁと思います。またその皺寄せが気付かないうちにコードやプロダクトに反映されてると思うと悲しいです😢自分のできることからチームに向き合っていきたいです。
読書：世界一やさしい「やりたいこと」の見つけ方
おすすめ本 Advent Calendar 1日目の記事です。 adventar.org
今回のおすすめ本は・・「世界一やさしい「やりたいこと」の見つけ方 人生のモヤモヤから解放される自己理解メソッド」です。
内容
説明はオリラジあっちゃんの動画を見てもらうのが一番ですが、ざっくりいうと『やりたいこと』は「大事なこと」、「得意なこと」、「好きなこと」の組み合わせで見つけることができて、「大事なこと」、「得意なこと」、「好きなこと」はそれぞれ 30 個ずつ用意されている質問に答えることで自然と発見できるようになっているので、難しいことは一切なく『やりたいこと』を探求できる本です。
きっかけ
去年から転職活動をしていたのですが、面接中に「働く上で大事なものはなんですか？」「あなたにとって心地良い環境とはどんなものですか？」など、自分の価値観に迫る質問で言葉に詰まる場面が多く、これまでそういうこと考えてこなかったなぁとモヤってたんです。そして、そんな話を友達にしたらこの本を紹介してもらって、友達自身もこれでやりたいことがハッキリしてきたと言っていたので読んでみようと思いました。
やってみて・感想
自分の得意は当たり前過ぎてエピソードとしても思い出せず…分析するのが難しかったです。。なので、書籍の質問の中にあった「周りの人に自分の得意なことを聞いてみよう」を5人ほど実行しました。私のことをよく知る人に聞くことで確にそれ得意だわ〜と自分でも納得するものがたくさん出てきたし、こうやって周りの人に相談できるような質問があることで1人で悶々しなくて済んだので良いなぁと思いました。
また、人生を振り返ると20代は好奇心だけで色んな初めてのチャレンジに飛び付いていたのですが、30代になって好奇心だけで飛び付く元気がなくなったというか、なんだろうな…年齢を重ねるうちに自分の苦手なことや好きじゃないことが見えてきたり、リスクや面倒くささも感じるようになってきて身軽さがなくなった気がするんですよね。それを行動力がなくなったな…とネガティブに捉えていたのですが、この本を読むことで今の私のフェーズは瞬発的に行動するよりも、もう少し長い目線で考え行動していきたい時期だったんだなぁと捉えれるようになりました。
5年後、10年後など定期的に自分を振り返るためにこの本を読み返したいです。
私の場合
大事なこと
- 【ありのまま】自分の気持ちに正直になる。肩肘張らずに自然体でいたい。
- 【寛容】自分と他人の存在、行動をそのまま許容し、許し見守れる存在でありたい。
- 【調和】人との繋がりがあるからこそ生まれる空気感を大事にしたい。
- 【納得感】考えて行動してトライアンドエラーをする中で自分で考えて決める。
- 【好奇心】物事を楽しもうとする。興味を持つ。運命思考。
得意なこと
- やるからには楽しもうとする
- 人の話を先入観なく聞ける
- タスクを小さく分割できる
- 試行錯誤が好き
- 自分ごとにするのが上手い
- 協力的
- 役割分担がうまい
- 自分のやりつつ、人にもやらせる武将タイプ
- 自発的に行動できる
- 自分の限界を知ってるし、伝えられる
- 人に共有する力がある（なぜやるのか？が伝えられる）
- ビジョンを語れる
- 自分の意見を言語化できる
- 人を巻き込むのがうまい
- 探究心がある
- 良いと思ったものを柔軟に取り入れる
- 観察力（変化とか他人の機微に敏感）
- 戦略的（何からやれば良いのか？道が見える、見えないものはやらない）
- パターン認識力（着想）
好きなこと
- 人の考えてること
- 対話
- コミュニティ作り
- チーム・関係性
- 人が協力してより多くの価値を生み出すにはどうすれば良いか
- 自己探究
- 自己開示
- 食べ物は国産のものを極力買いたい
心が疲れたときに多くの気づきをもらった考え方
もともと頑張り屋で優等生タイプの私ですが、2019 年に一緒に仕事をしていたメンバーと不仲になったことがきっかけで、急に頑張れない自分に転落していきました。それが自分自身と向き合うことに繋がっていくのですが、そのときに多くの気付きをもらった考え方を紹介します。
心屋仁之助さん
心屋さんは「ずるく生きる」とか「いい人辞めちゃえ」的なことを提唱してる人で、もっと頑張らなきゃ、もっとちゃんとやらなきゃって考えて生きてる人にグサグサ刺さると思います。心屋さんは歌も歌ってて下手だけど、歌詞が沁みます。
公開カウンセリング
これまで迷惑をかけたくない、他人にお願いするが心苦しい、自分が出来ないって言うのは嫌、失敗を許してもらえる気がしない、などと思って無意識ですが常に気を張って良い子・気が利く子・褒められる子になるよう努力していました。が、そうしてしまう原因が親に甘えることが出来ないからだということを、この公開カウンセリングを通して質問者の言葉を一緒に繰り返したときに涙がポロポロ出てきたことで気付くことができました。
「お母さん私を見て。私のこともっと大事にして。」って声に出すと、すっごく泣けて😢 数日後に勇気を出してお母さんに電話で弱音を吐きました。
心屋のカウンセリング
心屋の提供している「言ってみる」ことで、自分の知らなかった本心に気付き、さらにその「呪縛」「禁止」「制限」を解いて行くのが「心屋リセットカウンセリング」（対面カウンセリング）です。
https://www.kokoro-ya.jp/counseling/
Podcast - 心屋仁之助の「ホントの自分を見つけるラジオ」
https://podcasts.apple.com/jp/podcast/id1112406793
深い話なのにトークが軽快で冗談も多めなので笑いながらサクサク聞けちゃいます。Podcast の第3回目と第4回目で「前者・後者」という話があるのですが、そこで私は自分はダメなやつだ〜と唱えたことで涙と共に頑張るのを辞める方向へ、人に頼る方向へと少しずつ舵を切ることができました。
話してる最中に頭が真っ白になる（シャットダウンする）人は私と同じ後者です！Podcast 聴くと楽になりますよ。
■【永久保存版・全体概要】前者・後者は世界を救う?! 前者後者ってなんだ? | 心屋仁之助オフィシャルブログ「心が風に、なる」Powered by Ameba
＜ Podcast の中で記憶に残ってる話 ＞
- 後者はお姫様ポジション
- 自立と自活は違う
- 後者はすでに答えを知ってる人
- 浮気しないは 100 点満点と同じ。数回の浮気は込み
- 嫌いにな人に嫌われるって最高！
- 人生ハードモードを選んでる
- コンビニの店員さんにムスッとする練習をする
- 自分が一番怖い人と揉める
- 頼ることはその人に活躍する場をあげてること
オープンカウンセリング
オープンカウンセリング | 性格リフォーム 心理カウンセリング 心屋 KOKORO-YA
無料で心屋カウンセリングを受けれる場所です。私は以前、心屋の初級セミナーに参加して人前で泣けない自分に気付き、人前で泣く練習がしたくてオープンカウンセリングに参加しました（めでたく人前で泣けました👍）。そして、その時のカウンセラーが月星キレイさんで話しやすくて心地よかったので個人カウンセリングも受け、さらに心のブロックを外すことができました。心屋さんの YouTube 見て言ってみるカウンセリングに興味を持った方はお試しとしてとてもオススメです。
【漫画】パラダイムシフト
「【漫画】パラダイムシフト①ぼくんち こんな感じの漫画です、表現とか苦手な方はす」|-EMI-の漫画
去年、仕事で私の依頼を進めてくれない上司へのイライラと自分がその場凌ぎで付いた嘘が許せず、頭の中は「なんで私ばっかり！？」「嘘を撤回するにはどうしたら良いか…？」などの思考・妄想の嵐。そして、そのとき流行っていた香水の「人を傷つけてまた泣かせても何も感じ取れなくてさ」が無限トリガーになって 2 ヶ月ほど毎日毎日涙が止まらず、また徐々に起き上がるのが辛くなり 2 時間仕事して 4 時間寝て、2 時間仕事して…を繰すような無茶苦茶な日々を過ごしていました。けれどこのままじゃヤバイと思い勇気を出してメンタル病院に行き睡眠薬と抗鬱剤で少し回復してたころ、偶然 Twitter で見つけた漫画です。
漫画の「気持ちには寄り添うけど事実とは分けて考える」という考えに感動しました。
私は自分の気持ちと表面の態度は一致していることが良いこと、そこに裏表のないのが良い状態だと考えていましたが、そうすると相手のことが嫌いなのに表面上嫌いという態度が出せない場合、この人を嫌いだと思う感情を持っちゃいけない、好きになるよう努力しなきゃいけないと考え自分の気持ちを押し殺していました。しかしそれが自己虐待なのです。自分は自分の気持ちに全く寄り添わず自己虐待ばかりしていたことに気付けました。
漫画を読んだあとにふっと「もう薬飲まなくてもだいじょぶだ」と思えて、その日から抗鬱剤を辞めることができました。
前田大輔先生
心療施術のスペシャリスト心理の達人前田大輔 | トップページ
前田大輔 - YouTube
漫画の中に出てくるカウンセリングの先生で、前田先生の Youtube で語られる「自己愛・自己虐待」の話はとても泣けました。我慢は自分の味方にならず相手の味方になったということなのです。
ザ・メンタルモデル（由佐美加子さん）
前提として人は不快な感情（痛み）を避けて生きており、その痛みを避け続けると不都合な現実に直面していくので、その痛みが何なのか見てみようって感じの話です（ざっくり🥲）。YouTube で由佐さんがめっちゃ分かりやすく説明しているのでそれ見るのをオススメします。いま自分の人生がうまくいっていない、常に思考がぐるぐる回っているという方は結構グッとくると思います。そして自分のメンタルモデルが分かると自分がどんな痛みを避ける傾向があるのか、またこうあったら良いなぁと思える世界が分かるようになります。
私はメンタルモデルが「欠陥欠損の克服型」です。常に私はこれをやって良いのか？ダメって思われてるんじゃないか？自分がここにいて良いのか？という存在不安があるんですよね。。でもその不安は無理に無くそうとするものじゃなくて、その不安は在って良い、在るものは在るんだもんの世界に入ることが大事だって気付きました。
感情を感じる
心屋さんのお話の中で悲しいをもっと感じて、怒りを出してって言われることがあるのですが、私はそれがピンとこなくて…でも由佐さんの感情を感じるワークは順序立てて感情を感じにいけるので、感情を感じるってこういうことだったのか…と頭と体で実感することできました。いまは自分が痛みを避ける瞬間に気付くようになってきて、心がシャって防衛的になるんですよね。そんなときにこの感情のワークの動画を見て感情を感じる・感情は何を私に伝えようとしているのかを見つけるトレーニングをしています。
Journey to the Source （JTS）
基幹講座JTS(Journey to the Source) および Free Creators | Human OS Migration Technology
現在受講中なので感想は comming soon です。
由佐美加子のメンタルモデル・ワークショップ（由佐塾）
由佐美加子の「メンタルモデル」ワークショップ | 天外伺朗公式サイト
受講したい。
さいごに
こうやって振り返りと本当に良いタイミングで素敵な気付きに出会えたなぁと思いますし、これらの気付きに出会うために悩むこと病気になることは必要だったのだと感じます。また過去の私は自分がカウンセリングに通っていたこと、心屋さんや由佐さんの考え方がオススメだよ！と紹介することに抵抗感があったので、いまこうやって公開できるようになったのは信じられない変化で驚いてます。ここまで長かったなぁ。お疲れ様でした、あやちゃん。
Haskell を触ってみる
Haskell・純粋関数型言語 への興味
オブジェクト指向でなぜつくるのかの最終書は関数型言語への言及でした。そこで出されてたクイズ。
純粋関数型言語の Haskell がサポートしてないな仕組みはどれでしょうか？
（複数回答可）
① 戻り値が void 型の関数定義
② return 文による関数からの復帰
③ ローカル変数の書き換え
④ for 文によるループ処理
正解は「全てサポートされてない」で、え？まじかと思って関数型言語に興味がわきました。
こんなときにどうするの？
これを見てぱっと浮かんだ疑問です。
① 戻り値が void 型の関数定義
-> まぁこれはなくても書けるか。② return 文による関数からの復帰
-> ガード節的なのはどうするの？③ ローカル変数の書き換え
-> これもなくても大丈夫そう？だけど言語レベルでサポートしてるって斬新④ for 文によるループ処理
-> map 使うのか？どうやって定義するの？
ガード節的なのはどうするの？
例えば割り算をする関数があったときに、分母になる値が 0 の時だけ割り算させないように 0 を返したい場合。
Javascript の場合
ガード節を使って以下のように書きます。
function warisan(x, y) { if(y === 0) return 0 return x / y } console.log(warisan(9, 3)) // => 3 console.log(warisan(9, 0)) // => 0
haskell の場合
パターンマッチで事前に弾く。
-- ハイフン 2 つでコメントアウト -- 型定義 warisan :: Int -> Int -> Int -- 引数と戻り値の型 -- 関数定義 -- 分母が 0 の場合、0 を返す warisan x 0 = 0 -- それ以外の場合は割り算をして値を返す warisan x y = (x `div` y) -- / は int の割り算では使えないので div を使う
普通に if も書ける。
-- 関数定義 warisan x y = if y == 0 then 0 else (x `div` y)
ガードという書き方（| を使って分割する）を使うともう少し見やすく場合分けが書ける。
-- 関数定義 warisan x y | y == 0 = 0 | otherwise = (x `div` y)
参考）ここで書かれてる haskell で書かれた fizzBuzz 関数はガードを使って綺麗に書かれてる。
関数型言語Haskellでfizzbuzzプログラムを作成する
ループ処理どうやってやるの？
再帰関数とパターンマッチを使う。
再帰関数の勉強
階乗を求める関数 factorial を作る。
factorial(3) => 3 + 2 + 1 = 6
再帰関数を使わない場合
function factorial(n) { let result = 0; for(let i = n; i > 0; i--){ result = result + i } return result; }
これを再帰関数にすると？
function factorial(n) { if(n === 1) return 1 return n + factorial(n - 1) }
これを Haskell にすると？
factorial :: Int -> Int factorial 1 = 1 factorial n = n + factorial(n - 1)
each を作る
配列の値を 1 つずつ取り出して表示させる関数を作る。
each([1, 3, 10]) =>
1
3
10
再帰関数を使わない場合
function each(array) { for (let element of array) { console.log(element); }
これを再帰関数にすると？
function each(array) { element = array[0] new_array = array.slice(1) // 配列の最初の値を抜いた配列を取得 if(array.length === 1) return console.log(element) console.log(element) each(new_array) return }
これを Haskell にすると？
表示する関数（print）を foreach に渡してあげる必要があるんだね。
-- 返り値の型が分からないから型定義はしない -- 型推論） > :t foreach :: Monad m => (t -> m a) -> [t] -> m a -- Monad が分からないね… foreach f [element] = f element foreach f (element:new) = do f element foreach f new main = foreach print [1,10,3]
参考）Haskell > 繰り返し処理(foreach相当)を行う
map 関数を作る
haskell には map 関数は存在しますが、map 関数の仕組みを再帰関数で書いてみたかったので Javascript で map 関数を作ってみる。
array = [1, 10, 3]
console.log(map(array, increment)) // => [2, 11, 4]
再帰関数を使わない場合
function increment(n) { return n + 1 } function map(array, transform) { mapped = [] for(let element of array) { mapped.push(transform(element)) } return mapped }
再帰関数（自分で考えて書いた => 複雑になった…）
function map2(array, transform) { return recursion0(array, array.length, [], transform) } function recursion0(array, length, mapped, transform) { if(length <= 0) return mapped.push(recursion0(array, length - 1, mapped, transform)) return mapped }
再帰関数（haskell の map の実装を見て書き直した）
function map3(array, transform) { if(array.length <= 0) return [] x = array.slice(0, 1) xs = array.slice(1) return [transform(x[0])].concat(map2(xs, transform)) }
filter, reduce 関数を作る
map と同様、haskell には filter 関数、foldr, foldl 関数（reduce と同じ）がありますが仕組みを理解したかったので再帰関数で書いてみる。
感想
- もっちーとの勉強会のおかげで勉強サボらずにできた。約束の力👊
- Haskell のコードを Javascript で書き換えたりしたので、Haskell のコードをだいぶ読めるようになった👏
- 階乗の再帰関数なら javascript も haskell もコードの見やすさは変わらないけど、map など複雑さを増してくると haskell の宣言的な書き方の方がスッキリしてる。
- パターンマッチが強力で引数の配列の最初の値だけ束縛することができるのもコード量を減らしてるポイントだと思った。
- haskell のサンプルを見たときに（）がなく、スペースで判断なことが多かったので読み辛く感じた。
- Ruby は関数型言語っぽく書ける部分が多いので「if, while を使ったループ」と「ローカル変数の書き換え」はあんまりやってないことに気付いた。
- map 関数、filtter 関数、reduce 関数の実装楽しかった。自分で作ったのだと無駄が多かったので、haskell の実装（正解）を見て感動した。
- 高級関数をきちんと学べてよかった。
- 今後：モナドを頑張って勉強したい…！文脈を持つ計算とは？？
