miroを使って相談とフィードバックのやり取りをした話
こんにちは。 コロナの影響でリモートワーク等のTipsが色々と共有されている今日このごろ。 せっかくの機会を活かして(?)よくあるFaceToFaceの「お悩み相談」的なものもリモートチックに開催できないかな？ と思いやってみました。会社とか関係なくプライベートで。
なお、相談に乗ってくださった方は完全に私に一方的に巻き込まれた形になります。ほんとうにありがとうございます。
準備編
勢いで、「ちょっと、いま悩みポイントがあって相談したいんですが」とLINEしてみたものの 実は自分の中でちゃんとした「整理」ができていないなと言うことに気付きます。 私は会話の中でガンガン短い文章をつなげておしゃべりを展開するタイプなので、よくあるのです....。 ふんわり、話を聞いてほしい、というケースだと整理は必要ないと思うんですが、今回は明確に「問題解決Tips」という光明を得たかったので 自分の考えてることをマインドマップ的に整理してから相談することにしました。
使ったツール
一部で爆流行中のmiroを使用しました。 miro.com
なんでmiroなのか？
先述したとおり、目的としては
「前提やおこった事実」から
「どのような感情や思考」が生まれ
「何がもやっとの肝なのか」を整理して伝える
なのでマインドマップツールであれば、極論「図」を描くことができれば、ツールは何でも良かったです。 付箋というインターフェースがしっくり来たのでmiroを選びました。色別で前提・事実・感情・思考を分けてグルーピングしました。
また、(おそらくですが)双方、口頭でのやり取りよりチャットでのやり取りのほうが冗談を交えつつもストレートに思っていることが言えるのでは？ ということもありチャット機能がついているというのも後付ですが良かったです。(miroにうとくて、途中であることに気づきました！)
お悩み相談開始編
こんな塩梅で図を共有しました。
相手の方からは一通り感想をcomments機能でもらいつつ、おもにchat機能で対話を繰り返していきます。 付箋を指定できるので、chat上で付箋のuriを貼り付け
相談相手「ここなんですけど〜〜〜〜〜〜ってことですかね？」
私「はい、XXXXXXXな感じで....」
相談相手「なるほど！それであれば〜〜〜〜〜」
というやり方ができて、付箋一枚ごとのミクロな視点での壁打ちから、shapeごとのFB、マクロっぽい壁打ちへ移行していく(逆もマタ然り) みたいなことができました。
口頭での相談だと頭のワーキングメモリが優秀な方はいいのですが、私のようにすぐに揮発してしまうタイプは最初に話してた内容と結論に微妙なズレが起こる場合があります。 図になることでこの部分を外部装置に移設できたのでずれずに結論をまとめることができました。
今回の学び編
私はよく「とってももやもやするんだけど、何にもやもやしてたか忘れた！」「もやもやしてるんだけどこれは自分の感情の問題だ！」で終了してしまうのです。 が、今回もやもやを図解したことでわかったことが何点かありました。
図解から自分に還元できたこと
いくつかあるのですが、
- もやもやが「ただ認知が歪んでいるだけなのか、そうでないのか」を客観視する
- 感情として持っている部分が本編と関係あるのか、芋づる式に湧いてきた感情なのかを分解する
- TRYを持ってして自分で咀嚼可能なものと、分解や客観視してもどうしても咀嚼しきれないものを分ける
ことに成功しました。 もうちょっと詳しく述べると....
私は割と溜め込み型なので、普段から色んな所に地下茎がしこまれています。 すると、本編と芋づるがぐちゃぐちゃになって波に飲まれてしまい「あ、面倒だどうでもいいや流れに乗ろう....」みたいなパターンになりがちなのです。 しかし、今回のケースはそこを切り出して整理することで飲まれることを回避できました。
「どうしても咀嚼しきれない部分」はいわば「もう自分ではどうしようもねー／(^o^)＼」というポイントなので第三者の出番になってきます。 他人と壁打ちすることで新たな発見があったり対話の中で解消されていったりするのだろうな、と思っています。 すなわち今回一番の注力ポイントとしてお話したい部分の輪郭としてはっきり浮き出てくるのでした。
対話の相手について
少し本題と外れた話も差し込みます。
今回は対話の相手には「自分と270°タイプが違う人」*1を選ぶといいなあと思ってそうしました。 経験上、どんずまってるときって「すでに出来上がっている価値観」や「感情パターン」から抜け出せていない事がほとんどだったからです。
なので、新しい価値観をもっていたり、はたまた悩みが二項対立的だったばあいは反対側にいる人こそブレイクスルーのきっかけをくれる方なんじゃないかなと思って 壁打ちをお願いしています。 ここは多分目的によってdegreeを変えるのが良いのではないかなあと思います。90°の人がいい日もきっとある！ 結果として、今回はいい気付きをいただけたので正解だったなぁと思います。
さいごに
お話中は楽しく、学びも多かったのですがこの記事を書いてる時点で脳が疲れてるので多分めっちゃ向き合いにエネルギーを使ったのだと思いますｗ 1on1やコーチングプロ勢力はこの辺がすべてツール無しで完結してるのかな？すごい。
言語化が得意な人は当たり前のルーティンかもしれないですが、不得手な人はまずお絵かきから悩みを分解してみるとヒントが得られるかもしれません、というお話でした！
*1:角度の量的には離れてるんだけど、円運動的には近づいてくる的な...。絶対値的に同じである90°だとベクトル的には一度離れていく印象なので
CircleCIからGitHub Actionsに移行する際に迷ったポイント・ハマったポイント
こんにちは。最近cosme kitchenで新しいコスメを試すことにハマっている @super_mannerです。 今年大人買いした漫画がBEASTARSと鬼滅の刃と進撃の巨人で、ちょっと買いすぎなのでは？と思っています...。 普段はRailsやVue.jsを書いています。PHPer歴が長いので、色々と気づきがあって面白いです😊
さて、今回は業務で取り扱った 「CircleCI => GitHub Actionsへの移行」 でいくつか無駄にハマったポイントについて書こうと思います。 超初歩的なポカから、なるほどなーというところまで色々とあったので今後導入される方の助けになれば幸いです🍎
この記事はTECHPLAY女子部 Advent Calendar 2019の12日目の記事です。
目次
導入したjob
今回移行したものは大きく分けると3種類です。
まだすべてを移行しきれていないので移行できたものだけを列挙します。
- lint系のjob
- rubocop
- slim-lint
- stylelint
- test系のjob
- rspec
- jest
- 定期実行系のjob
- bundle update
これらを一つずつ移行していき、問題がなければCircleCIから外すというオーソドックスなやり方で実施しました。 詳しいworkflowの書き方は、公式ドキュメントがかなり丁寧なことと、昨今流行っているのか(?)ググるといい記事がたくさん出てくるので本エントリでは割愛させていただきます。
迷ったポイント
workflowの分け方
さて、早速洗い出しが終わった段階で一つ迷った点がありました。
それは「workflowにどのような切り口で仕事をもたせるか」です。
GitHub Actionsのベストプラクティスがまだよくわかっていないのが大きいのですが、
- 使っているライブラリ群でworkflowを分けるのがよいのか(gemが必要なjobとnode_modulesが必要なjobでworkflowをわける)
- 担っている責務ごとにworkflowを分けるのが良いのか(lint/test/cronでworkflowをわける)
の2パターンを思いつき、どちらにするべきなのかの判断がが非常に悩ましかったです。
私が悩んだ観点はそれぞれこんな感じでした。
| ライブラリで分ける | 責務で分ける |
|---|---|
| 処理時間が早そう。workflowが分散されていない分セットアップの時間が短縮できそうだ | 利用者がわかりやすそう。それぞれのジョブが失敗したときに何が要因なのかが一発でわかりそうだ |
並列で実行されるかつ、cacheがうまく機能していそうだったことから(有効範囲はこのあたりを読むとわかりやすいです) 今回はメンテナンス性や利用者がわかりやすいように後者の「責務で分ける」でいくことにしました。
ハマったポイント
さて、ここが本日の本丸です。 やることは決まっているのでサクサク行くだろうなと思ってやり始めたのですが、いくつか無駄に時間を使ったポイントが出てしまったので 一挙大放出します。
cache keyを間違えていた
11月頃に、GitHub Actionsにも待望のcache機能が登場しました。
意気揚々と使っていたのですが、掲題のとおりです。。。はい。
でもそこそこあるケースだと思うのでしっかり確認しましょう...。
bundle installタスクがうまく動かない
これはものすごいポカミスでした!
当初このように, bundle installしたものをキャッシュしておき、変更があればcontainer内部で再installするという至ってシンプルなworkflowを書いていました。
- name: Run Bundle install
if: steps.bundle_install.outputs.cache-hit != 'true'
run: |
bundle config --local build.mysql2 "--with-ldflags=-L/usr/local/opt/openssl/lib"
bundle install --jobs=4 --retry=3 --path vendor/bundle --clean
- name: Run rubocop
# 以下略
しかし、想定したとおりにrubocopが動きません。
それもそのはず、 .bundle/config はcacheしておらず引き継がれない(もちろんgit管理もしてない) のでせっかく入れていた設定が全て吹っ飛んでしまったのです。
なので、初回とキャッシュヒット時で処理を分岐させて回避しました。
- name: touch bundle config
if: steps.bundle_install.outputs.cache-hit == 'true'
run: |
mkdir .bundle
touch .bundle/config
echo BUNDLE_PATH: "vendor/bundle" >> .bundle/config
今回は、rubocop実行時にpathがほしかっただけなので最低限の設定を注入して終了です。
ということで、結構力技ではありますがなんとななりました。設定をworkflow内部で注入している場合は気をつけたほうが良さそうです。
git diffする対象を間違えていた
すべてのファイルをlint対象にしてもいいんだけどちょっと実行時間が気になるよね...と思った私は
「よし、git diffして差分が合ったファイルだけlint対象にしよう」
と思い下記の様に書いていました。
- name: Run rubocop run: git diff --name-only | egrep '.+rb$' | xargs bundle exec rubocop -D
パット見でお気づきの方もいるかもしれないですが、私は何も変更対象にならないことに気づかないまま数分が闇に葬られていきました👼
色々気づいて最終的に修正した結果こうなりました。
- name: Run rubocop run: git diff --name-only origin/master --diff-filter=d | egrep '.+rb$' | xargs bundle exec rubocop -D --force-exclusion
修正したポイントは
- 自分自身とdiffをとっていたので origin/masterとのdiffを取るようにした
- 本当はPRが向いているbranchとのdiff取りたかったのですが調べきれずに今の所origin/master差分で見ています(releaseにこまめに差分を取り込んでれば問題ないと判断しました)
--diff-filter=dをつかって削除ファイルはlint対象から外した- review時にこれ意味ないことしてるような...という指摘をもらって直しました
--force-exclusionをつけて.rubocop.ymlの設定を読み込めるようにした- パイプで明示的にファイル名を渡しているのでこれをつけていないと除外ファイルの設定が反映されなかったです
という点です。
GitHub Actionをつくった
定期実行タスクの一つにbundle updateで更新があれば自動的にPRを飛ばすといったものがあったので
いい感じのactionがないか探していたのですがなかったので...作ってみました！
機能としては至極単純で
「お好みのトリガでbundle updateを行い、差分があれば指定したユーザーをreviewerにしてPRを飛ばす」
というものです。PRのdescription表示にはbundler-diffを使わせていただきました。ありがとうございます!!
事前に見ていただいた方からもうすでに提案を頂いているくらいに完全に網羅したわけじゃないのですがw、世の中に出してみようと思い切ってreleaseしてみました〜🎉
PRやIssueをいただけると勉強になりますし、今後のメンテの励みになるので、もしよかったら使ってみてください😊そしてPRください😏
最後に
というわけで、GitHub Actionsなかなかたのしいぞい！ということがちょっとでも伝われば嬉しいです！！ 読んでくださりありがとうございました🙆
