ディスカッションを非同期でやるときの場づくりないしファシリテーションの方法、メーリングリスト世代の人が詳しそう
— こま (@koma_koma_d) 2022年2月22日
技術系メーリングリストで質問するときのパターン・ランゲージ https://t.co/BEMxHfp4Wf 質問するときについてはこれがあるわけだが
— こま (@koma_koma_d) 2022年2月22日
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 https://t.co/r0eYAyX1il 非同期でできることは非同期でやりきってから同期コミュニケーションするというのはまぁわかるんだけど、同期コミュニケーションのコストが高い環境と低い環境というのはあって「唯一の解」というのはないと思う
— こま (@koma_koma_d) 2022年2月22日
モブでみんなでコードやドキュメントを書いていくのが非常に効果的なケースがあり、同じようなことを非同期でやろうとすると極めて効率が悪いので、それを避けて誰かが原案を作るということになるのだが、原案作成能力というのはみんな持っているわけでもないので↓なんだよなhttps://t.co/yxN2YUo4oB
— こま (@koma_koma_d) 2022年2月22日
入社後10年の節目に｜Yuta Sawa @sawawww #note https://t.co/UffexusO0P この記事を読んでいてそうだよなと思った箇所があって→
— こま (@koma_koma_d) 2022年2月22日
"やっぱりコードを書かずに設計云々をごちゃごちゃ言うより、動くものをとりあえず出すというのはどこであっても強い。そこで問題があれば、さらに深い議論が出来るので。コードを書かずに設計議論をするのは、ちゃんとコードを書くことができるというのが大前提だと思うわけです。" なんだけど→
— こま (@koma_koma_d) 2022年2月22日
これは同じことがコード以外にも言えて、原案作れるのは強いと思うのですよね。出てきたものに対してやいのやいの言うのもそれはそれで大事なのだけど、原案作れる人は貴重、というのがこのスレッドの途中から自分が言っていたことです
— こま (@koma_koma_d) 2022年2月22日
関連して、原案作っていて肝心なところで「判断を仰ぎたい」と言っちゃうのはできれば避けたいよねというのはこれを見てせやなーとなって思ったことである（謙虚さは大事だけど）https://t.co/hVMucPwpqK
— こま (@koma_koma_d) 2022年2月22日
Fearless Change p.163 で引用されている「あなたが捜し求めているものは保険だ。もし計画がうまく行かなかった場合に、周囲の非難からあなたを守ってくれる保険を求めているのだ」のところ好きなんですよね。
— こま (@koma_koma_d) 2022年2月22日
「やってみなさい。 誰かに承認してもらうのを待つということは、失敗したら尻拭いをしてもらおうと考えているということだ。組織の上層部の人たちは、あなたを信頼し、任せることによって背負うリスクなど十分承知の上だ。」
— こま (@koma_koma_d) 2022年2月22日
パワーを身につけて物事を突破していきたい（いつもと同じ結論）
— こま (@koma_koma_d) 2022年2月22日
