そろそろ今年も終わりますね～。

今週もなんだかんだ色々やっていたのでしっかり振り返っていきたいと思います。

12 月 10 日(土)

すずめの戸締まりを観てきました

• 美容師の方から宮崎弁が登場するという話を聞いていて気になったので久しぶりに映画を観に行きました。個人的には色々話が最後に繋がる感じがあったり、登場人物やストーリーも良かったです。

12 月 11 日(日)

自分の部屋のものを断捨離しました

• 技術本とかも結構あったのですが、もう読まないだろうなという本もたくさんあったのでこの機会に整理しました。

合意形成に役立つ課題評価の 5 ステップ

• https://note.com/mercari_design/n/n16c34fc59f9e
• メルカリの方が書いている記事でとてもいい話でした。オールリモート企業での合意形成をスムーズにするために学ぶべき点はあるかという観点で読んでみました。
• 非同期で何を議論するか、同期ポイントではどうやって決めるのかという合意形成にいたるまでの流れをデザインしていたのが印象的でした。
• 例えば、気づきの洗い出しワークショップは全員で行うことでお互いの共通課題を可視化し、共有するという目的で行うという点であったり、選定ステップ前に準備ステップを用意して、選定前にある程度情報を加工して議論しやすい状態を作ってから選定ステップに進んだりととてもいい話でした。

開発フローを可視化する

• 今まで各々がいい感じに改善しながらやってきたところを一旦図にして可視化することで今後改善サイクルを回しやすい状況を作りました。細かいところを考え出すとキリがないので PJ 開発などは抽象度高めで描き、今後細かいところの解像度をみんなであげながら誰もが開発しやすいサイクルを作りたいです。

12 月 12 日(月)

最近は朝にアイデアが降りてくることが高確率

• 業務やプライベート含めて色々考えているのですが、頭の中で考えたりすると発散して終わることが多いのですが、朝になるとそれが繋がってアイデアが降りてくることが多いです。不思議です。

合意形成をスムーズにするための準備をするとスムーズに進んだ

• データを新テーブルに移行するための同期処理を書いていたのですが、おそらく実装した自分しか気づいていないような疑問を抱えていました。言語化できるまでに結構時間がかかってしまったのですが、ポイントを明確にした上で質問を投げ MTG を行うことでスムーズに回答を得られ次に進むことができました。

12 月 13 日(火)

初めての Go 言語が 6 章、7 章あたりから理解が怪しくなってきた

• インターフェースあたりの話から色々複雑になってきて、理解できずに進む状況が増えてきました。もちろん 1 回で全部理解できるとは思っていなかったもののモチベーションが少し下がってきました。
• そういえば、アウトプットが少ないと思い簡単なところからアウトプットしながら必要に応じて読み返してさらに理解を含めていこうと思います。

12 月 14 日(水)

合意形成していく方法については伸びしろ

• 基本オールリモートで仕事をしているのですが、それぞれが別々のことを並行しながら合意形成していくのは難しいですよね。その並行作業の期間が長ければ長いほど、お互いに知識格差が生まれます。
• 少ない人数でも難しいのですから、組織が大きくなればなるほど難易度は跳ね上がります。だからこそ、小さい人数のうちに試行錯誤して、スケールしてもうまくいくやり方や仕組みを作っておくのが重要だなと最近よく考えます。
• 同期・非同期の使い分けをうまくしながらさらに仕事しやすくなるように考えていきます。

勉強会についてジャストアイデアが出た

• 毎週水曜に 15 分勉強会を実施しています。できるだけ準備コストはかけず、それでいて題材は今のフェーズに合った実践的な内容という感じでやっています。
• 前回は React を題材にして実施していたのですが、実践にすぐ活きる内容でよかったです。
• 次回も実施していきたい気持ちはあるものの題材決めが難しいという課題がありました。
• そこで出たのが、勉強会は一度廃止し、適切な題材があれば復活を検討。勉強会を廃止することでなくなる知識共有部分は、開発定例の中で PR のコードベースで準備コストはかけずに共有し合うというものでした。
• 全員が全ての PR のレビューができているわけではないので、コードベースで出た気づきや苦労などを開発メンバー全員に還元できるのでこれはよいなと思いました。

12 月 15 日(木)

最近は発散したら収束しないと気持ち悪い体になってきた

• この週刊ニュースを始めてからもう 5 回目になりました。週刊ニュースはデイリーノートに書いたメモを振り返っています。振り返っていると、こんなこと考えていたなとか、これはアトミックノートにできるなとか、これはやっぱりこうじゃないかなど色々な発見があります。こうやってメモを取ったそのときにはできなかったアクションを取れるので、気持ちよく次に進むことができています。こうやって発散したことを振り返りで収束させるのは大事だな再認識しています。

勢いで最近している取り組みを diddyworks の記事として書いた

• この日振り返っていると最近よく業務改善に関することを考えていて、発信したり、改善するために動いているなあと改めて思いました。書き出してみると結構な動きをしていて、この動きのモチベーションにあるものはなんだろう？というところから振り返っているとこれはちゃんと言語化したいとなり、一気に書き上げました。こういうのはタイミングを失うと発散してしまい、収束しきれずに次に進んでしまうことがよくあるため先送りにせず書き上げることができてよかったです。

12 月 16 日(金)

うっすら理解だと自分の言葉で書くことは難しい

• 週刊ニュースのタイミングでも技術的な学びや気付きを書きたいと思うのですが、最近は深ぼらずに自分の言葉にもせずただ書き写しているようなメモが多いと思いました。そういうメモは後から見返しても役に立たず、そのとき一瞬通り過ぎて終わりだなと思いました。全部拾い上げるのは難しいですが、やりたいことが落ち着いてきたらひとつずつ拾っていきたいです（モチベやタイミングがあるので後からだとやらなくていいかなと大抵はなってしまいますが…）

途中でのタスク移譲はコミュニケーションコストとのトレードオフがある

• A さんと B さんで作業をしていて、途中で A さんから C さんに移譲して B さんと C さんで作業をすることになりました。
• このとき、C さんは作業内容を知らないので B さんから C さんに説明するコミュニケーションコストが発生しますし、C さんの業務習熟度や知識を把握するところからやらないといけなくなるかもしれません。
• A さんは別の作業をすることができる分、目に見えない所で B さん、C さんに無駄なコストが発生しているかもしれません。
• ケースバイケースですが、可能な限りタスク移譲をしないほうが無駄なコストが発生せずに安全に業務を進めることができそうだなという発見がありました。